Привет! 👋 сейчас будет много букв 🙀

Сколько проектов ты видел, где HTTPS накинут "для галочки"? Сертификат самоподписанный, редирект кривой.

Давай с этим разберемся. Настраиваем HTTPS так, чтобы и SSL Labs поставили A+.

Любой HTTPS запрос = браузер и сервер договариваются, как шифровать данные, проверяют сертификат и только потом начинают передачу. Если сертификат просрочен, имя не совпадает или цепочка не доверенная — браузер выдаст предупреждение и не пустит пользователя.

Наша задача: сделать передачу надежной, быстрой и безопасной.

Для этого будем поднимать : Nginx + Let's Encrypt (Certbot). Это бесплатно, автоматически и мейнстримно. Для демо берем Ubuntu 22.04, но на Centos/Rocky всё аналогично (только пакетный менеджер другой).

Шаг 1. Получаем честный сертификат

Certbot сам сходит в ACME, подтвердит домен и разложит сертификаты. Устанавливаем:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Дальше запускаем магию:

sudo certbot --nginx -d example.com -d www.example.com

Certbot сам подправит твой конфиг Nginx, включит HTTPS, настроит редирект. Но! Он сгенерит конфиг в минимальном стиле. Мы же хотим не просто HTTPS, а правильный HTTPS. Поэтому после получения сертификата залезем в конфиг и докрутим.

Шаг 2. Правильный конфиг Nginx для HTTPS

Открываем /etc/nginx/sites-available/example.com и приводим к виду ниже. Объясню ключевые моменты:

# HTTP — только редирект на HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

# HTTPS блок
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # Пути к сертификатам (Certbot положит их сюда)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # Современные протоколы и шифры
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # Оптимизация handshake
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP Stapling — ускоряет проверку сертификата
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Заголовки безопасности (security headers)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # Корень сайта и индекс
    root /var/www/example.com;
    index index.php index.html;

    # Логи
    access_log /var/log/nginx/example.com_access.log;
    error_log /var/log/nginx/example.com_error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

Что здесь важного

- listen 443 ssl http2 — включает HTTP/2 поверх TLS. Ощутимо быстрее.
- ssl_protocols — разрешаем только безопасные версии TLS (v1.2 и v1.3). SSLv3, TLSv1.0, TLSv1.1 — в топку.
- ssl_ciphers — набор шифров, рекомендуемый современными стандартами (Mozilla Modern).
- ssl_prefer_server_ciphers off — отключаем устаревший механизм выбора шифра сервером, доверяем клиенту (он уже знает, что лучше).
- ssl_session_cache / timeout / tickets — ускоряем повторные соединения.
- OCSP Stapling — сервер сам ходит проверять валидность сертификата и отдаёт результат браузеру, экономя время.
- Security Headers:
- Strict-Transport-Security (HSTS) — заставляет браузер всегда ходить по HTTPS (даже если пользователь вбил http://).
- X-Frame-Options — запрещает встраивать сайт в iframe (защита от clickjacking).
- X-Content-Type-Options — запрещает браузеру угадывать MIME-тип.
- X-XSS-Protection — включает встроенный фильтр XSS.
- Referrer-Policy — ограничиваем передачу referer.
- Content-Security-Policy — базовое разрешение (можно ужесточить под своё приложение).

Шаг 3️⃣. Проверяем и перезагружаем

sudo nginx -t
sudo systemctl reload nginx

Теперь можно зайти на сайт и проверить замок в адресной строке. А для хардкорных тестов идём на SSL Labs — вбиваем свой домен и ждём отчёт. Там должно быть зелёное "A+".

Почему это работает?

Потому что мы не просто повесили сертификат, а:
- Отключили всё слабое и древнее.
- Включили оптимизации (OCSP Stapling, session cache, HTTP/2).
- Защитили пользователя заголовками даже на уровне протокола.

Что дальше?

Настроить HTTPS — это лишь один из кирпичей в стабильной и безопасной инфраструктуре. Если хочешь разобраться во всём стеке LEPP (Nginx + PHP-FPM + PostgreSQL) от установки до продакшен-оптимизации и упаковки в Docker — приходи на курс.

🔥 Старт: 24 февраля
📄 Программа курса LEPP Stack
💰 До 23 февраля включительно — 22 000 ₽ 25 000 ₽.

👉 Купить LEPP Stack

Освоишь то, что реально нужно в работе: понимание архитектуры, траблшутинг, безопасность, автоматизацию. Без скучной теории, только практика.

⚫ Многие из вас уже бывали на наших открытых онлайн-практикумах с Василием Озеровым, Андреем Бурановым, Денисом Колпаковым, Андреем Шабалиным и другими спикерами. Мы регулярно проводим такие встречи по DevOps и инфраструктуре и каждый раз убеждаемся, насколько это полезный формат.

Почему вообще стоит заходить на открытые вебинары и митапы:
🟢 реальные кейсы и разборы из практики, а не теория
🟢 возможность услышать, как команды решают задачи «в полях»
🟢 быстрый способ держать руку на пульсе рынка и инструментов
🟢 новые идеи и подходы, которые можно применить в работе
🟢 возможность не выпадать из профсообщества, даже если много операционки

Иногда один вечерний вебинар даёт больше инсайтов, чем неделя чтения статей, просто потому что это живой опыт и обсуждение.

Мы сами периодически сохраняем разные подборки мероприятий, чтобы не пропускать интересные темы и спикеров. В канале IT Meeting, например, регулярно собирают бесплатные онлайн-вебинары и митапы по разным IT-направлениям — удобно иногда открыть и посмотреть, что сейчас обсуждают в индустрии.

Делимся, какие доработки внедри по мессенджеру:
🟢Расширили окно чата и поле ввода сообщения.
🟢Возможность перейти в урок, из которого задан вопрос/сдано задание.
🟢Поиск среди чатов по теме, названию урока или названию курса.
🟢Markdown поддерживается в чате.
🟢Можно удалять свое последнее отправленное сообщение (если на него нет ответа и после отправки вы не меняли статус). Редактирование отправленного сообщения- объемная задача, и пока что в бэклоге.
🟢Возможность прикрепить файл драг-дропом или вставить изображение через ctrl+v.
🟢В чате отображается имя ментора.

Мы разбираем вашу обратную связь и берем ее в работу. Если у вас есть пожелания, то пишите в поддержку, мы собираем ее в бэклоге и постепенно/по мере возможностей ее внедряем.

3… 2… 1… 🚀 Уже завтра стартует Kubernetes Live Class с Васей Озеровым

Если давно хотели системно разобраться в Kubernetes — это тот самый момент. Ещё есть время запрыгнуть в последний вагон🙌

Почему стоит присоединиться?

🟢 6 живых встреч с Васей, где разберём архитектуру кластера, базовые ресурсы и руками поработаем с Kubernetes
🟢 обновлённый практикум с логичной структурой и реальными сценариями
🟢 возможность задать вопросы и разобрать сложные моменты вживую с Васей
🟢 записи останутся только у участников

Выбирай формат, который подходит тебе:

- практикум Kubernetes Base + Live Class
- только практикум Kubernetes Base
- только Live Class

🟡 Старт уже завтра — 26 февраля

↘️ Узнать подробности и занять место

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Протокол динамической маршрутизации EIGRP. Часть 2
↘ Регистрация

Время проведения:
3 марта 2026, вторник, 19:00 по МСК

Программа практикума:
🟢Алгоритм DUAL: основные теоретические сведения;
🟢Базовые манипуляции с маршрутами
🟢Настройка EIGRP Named Mode

Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------

2️⃣ Оценка загруженности сервера
↘ Регистрация

Время проведения:
4 марта 2026, среда, 20:00 по МСК

Программа практикума:
🟢Нагрузка на CPU
🟢Нагрузка на диски
🟢Насгрузка на сеть

Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов.
---------------------------------------------------------------------------------------

3️⃣ Пентест внешних сервисов организации
↘ Регистрация

Время проведения:
6 марта 2026, пятница, 20:00 по МСК

Программа практикума:
🟢Какие внешние сервисы выбирать в первую очередь
🟢Эксплуатация уязвимостей со сканерами
🟢“Ручная” эксплуатация без сканера
🟢Первичное закрепление после эксплуатации
🟢Написание отчета

🔹 Приходите, если хотите на практике разобраться, как хакеры атакуют периметр компании, и научиться отличить реальную угрозу от ложного срабатывания. Будем работать руками, жечь и эксплуатировать.

🎯 Если вам увлечет наш формат и подача, то уже в марте мы запускаем полноценный углубленный курс «Эксплуатация уязвимостей внешних сервисов». На вебинаре дадим старт и расскажем, что будет в основном треке.

Кто ведёт?
Константин Зубченко — ведущий инженер-разработчик в компании BI.ZONE. За годы работы в отрасли прошёл путь от анализа защищённости промышленных систем до инженерных и экспертных ролей в крупных российских компаниях. Участвовал в сложных проектах на стыке разработки и информационной безопасности, усиливая команды и процессы.

🔥 Решите задачу по Kubernetes и выиграйте место на новом практикуме Васи Озерова

9 марта стартует новая инженерная головоломка «Призрачный Kubernetes». Регистрация уже открыта.

Это техническое соревнование по диагностике Kubernetes, поиску и устранению ошибок в кластере.

Что вас ждёт:

🟢 доступ к рабочей инфраструктуре
🟢 ошибка в кластере, которую нужно найти и исправить
🟢 ваша задача — устранить проблему как можно быстрее
🟢 в конце — эфир с Васей Озеровым и подробный разбор решения

🎁 Призы:

🏆 Инженер, который быстрее всех решит задачу, получит место на новом интенсиве Васи Озерова по Kubernetes
🟢Ещё два места мы разыграем среди участников, которые успешно справятся с заданием
🟢Также все участники получат специальную скидку на интенсив Васи Озерова по Kubernetes и на практикум Kubernetes Admin

↘️ Участвовать бесплатно

Задача для решения будет доступна с 9 по 16 марта. Проверьте свои навыки и попробуйте решить её быстрее других!

Оценка загруженности сервера

Сервер тормозит, ты заходишь, смотришь top — load average высокий, а что дальше? CPU упирается? Или диск? А может, сеть захлебнулась? Обычно на этом месте начинаются гадания и бессистемные танцы с бубном. Но если копнуть глубже, за каждым таким симптомом стоит конкретная техническая причина.

Например, знакомо?

🔹 Load average зашкаливает, CPU простаивает, а сервер еле дышит — и неясно, где корень: диск или софт?
🔹 Процессы зависают в состоянии D (uninterruptible sleep) и не убиваются даже с -9?
🔹 PostgreSQL или Redis внезапно падает из-за OOM Killer, а ты узнаёшь об этом постфактум?
🔹 SSD-диск ведёт себя как древний HDD, потому что планировщик I/O не под стать NVMe?
🔹 Сеть захлёбывается под Highload: тонны TIME_WAIT, нехватка портов, дропы пакетов на ровном месте?
🔹 Ночью сервер «шумел», а утром всё чисто — и кто виноват, непонятно?
🔹 Приложение висит, логов нет, исходников нет — как понять, на чём оно застряло?

Если хотя бы один пункт отозвался — приходи на вебинар

Завтра = 4 марта (среда) в 20:00 по МСК пройдет вебинар «Оценка загруженности сервера». Не общая теория, а конкретная диагностика: где болит и как это вытащить наружу.

Что разберем за час:
🟢 Нагрузка на CPU — чем отличается user time от system, почему процесс висит в состоянии D и как это связано с iowait.
🟢 Нагрузка на диски — IOPS, latency, очередь запросов. Когда диск реально "в дугу", а когда просто капризничает.
🟢 Нагрузка на сеть — дропы пакетов, переполненные буферы, состояния соединений (этот ваш TIME_WAIT).

Кто ведет?
Андрей Буранов — системный администратор в департаменте VK Play. 10+ лет в продакшене с Linux, 8+ лет учит людей. Входит в топ-3 преподавателей образовательных порталов (не ради красного словца, реально там). Живой опыт, никакой воды.

Регистрация по ссылке

Это пригодится, если вы: DevOps, разработчик, сисадмин, QA — любой, кто хочет перестать гадать и начать точно знать, почему сервер плохо себя чувствует.

---

Если тема зайдет — не останавливайся. 📣Завтра сделаем отдельный анонс 🔥нового модуля «Linux: Анализ производительности и тюнинг»🔥, там расскажем все детали. Программа 🧨💣💥 от глубокого копания в /proc до трассировки системных вызовов и итогового разбора «больного» сервера.

Заметим, что этот модуль в голосовании в конце 2025 года набрал больше всего ваших голосов🗣 а мы стараемся сделать продукт для вас💚

А пока просто регистрируйся на веб, будет плотно и полезно. Будем на связи!

📊 Прод начинает тормозить. Метрики вроде нормальные: CPU не упирается в 100%, памяти хватает, графики зелёные.

Но latency растёт, сервис отвечает медленнее, пользователи уже пишут в поддержку, а в логах ничего очевидного.

И начинается знакомый сценарий: смотришь дашборды, проверяешь логи, перебираешь гипотезы, но root cause всё ещё не очевиден.

Часто причина лежит на уровне самой системы Linux:

- скачки iowait
- процессы с высоким CPU usage
- сетевые задержки и проблемы с очередями
- утечки памяти и срабатывание OOM killer
- неудачные настройки kernel и сетевого стека

И это не всегда видно на обычных дашбордах мониторинга.

➕ Поэтому мы запускаем новый практикум Linux: Анализ производительности и тюнинг

Это практикум про то, как диагностировать проблемы производительности на уровне операционной системы, а не просто смотреть графики.

На практикуме вы научитесь:

🟢 анализировать состояние системы через /proc и системные метрики
🟢 использовать strace для анализа поведения приложений
🟢 разбирать инциденты и проводить ретроспективный анализ с atop
🟢 настраивать сетевой стек и параметры ядра Linux
🟢 работать с CPU, памятью и I/O, чтобы система стабильно держала нагрузку

В финале вас ждёт практическая задача: нужно будет диагностировать и оптимизировать проблемный сервер с утечками памяти, сетевыми задержками и I/O-bottleneck и показать метрики до и после оптимизации.

⭐️ Старт первого потока 24 марта, сейчас действует специальная цена 💰 30 000 → 25 000 руб.

🎁 А для всех, кто покупал практикумы на нашей платформе ранее, мы даем дополнительную скидку 3 000 руб., чтобы учиться было еще выгоднее

↘️ Подробнее о программе

↘️ Купить курс со скидкой