WAF и защита от DDoS для сайта небольшой компании

Сайт компании подвергается двум разным угрозам: попыткам использовать уязвимости приложения (подбор паролей, SQL-инъекции, загрузка вредоносных файлов) и перегрузке, когда запросов так много, что он перестаёт отвечать. От первых защищает WAF (межсетевой экран веб-приложений) в сочетании с исправлением самих уязвимостей, от вторых — ограничение запросов и услуги защиты от DDoS. Ниже разбор, что нужно небольшой компании, настройки nginx и порядок внедрения WAF без остановки сайта.

Статья опирается на логику направления «Сетевая безопасность» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Конфигурации перед применением проверяйте на тестовом сервере и командой nginx -t.

Что должно получиться

Уровень	Что это значит на практике
1. Базовый	На границе стоит межсетевой экран, наружу открыты только нужные порты
2. Гигиенический	Сеть сегментирована, правила firewall пересматриваются, удалённый доступ идёт через VPN с MFA, журналы ведутся; публичные сервисы защищены от типовых атак

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

WAF и защита от DDoS: в чём разница

Что	От чего защищает	Чем реализуется
WAF	Атаки на логику приложения: инъекции, межсайтовые сценарии, обход путей, подбор паролей, сканеры	ModSecurity с правилами OWASP CRS, облачный WAF, функции балансировщика
Защита от DDoS на уровне сети	Заполнение канала и перегрузка серверов огромным объёмом трафика	Услуга оператора связи или провайдера защиты, расположенная перед вашим каналом
Ограничение запросов (rate limit)	Небольшие перегрузки, подбор паролей, агрессивные боты	nginx, балансировщик, CrowdSec

Важно: WAF не заменяет исправление уязвимостей. Он снижает риск, пока вы закрываете найденное: управление уязвимостями. Мощную сетевую атаку вы на своём сервере не отразите: канал забивается раньше, чем запросы доходят до nginx, поэтому нужна внешняя услуга.

Нужна ли внешняя защита от DDoS

Нужна, если сайт приносит деньги или доступность критична, вас уже атаковали или вы работаете в чувствительной отрасли.
Может быть достаточно базовых мер, если сайт информационный, а простой на несколько часов не приведёт к потерям: ограничения запросов, кэширование и быстрое восстановление.
Выбирая услугу, проверьте: способ подключения (смена DNS, прокси, туннель), влияние на передачу персональных данных через стороннего провайдера (условия трансграничной передачи и поручения: трансграничная передача ПДн), порядок действий в момент атаки и стоимость.

Шаг 1. Ограничение запросов в nginx

Первый и самый дешёвый рубеж: ограничить число запросов с одного адреса и защитить чувствительные адреса (вход, поиск, формы). Пример конфигурации (значения подберите по реальной нагрузке; блоки limit_req_zone и limit_conn_zone размещаются в http):

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;

server {
    listen 443 ssl;
    server_name example.com;

    limit_conn connperip 20;
    limit_req zone=perip burst=30 nodelay;
    limit_req_status 429;

    location = /wp-login.php {
        limit_req zone=login burst=5 nodelay;
        # остальные директивы проксирования или fastcgi
    }
}

Что делает конфигурация: не более 10 запросов в секунду с адреса с разрешённым всплеском 30; для страницы входа 1 запрос в секунду; не более 20 одновременных соединений с адреса. Превышение получает ответ 429. Проверка: sudo nginx -t, затем sudo systemctl reload nginx. Риск: за общим NAT или прокси много пользователей имеют один адрес; слишком жёсткие значения заблокируют их. Если перед nginx стоит прокси или CDN, настройте передачу настоящего адреса клиента (real_ip), иначе ограничение сработает по адресу прокси. Ориентиры по HTTPS: настройка SSL в nginx.

Дополнительно: автоматическая блокировка по журналам, например CrowdSec, а также кэширование статических страниц, чтобы нагрузка на приложение снижалась.

Шаг 2. WAF: ModSecurity и правила OWASP CRS

ModSecurity — открытый движок WAF; OWASP Core Rule Set (CRS) — набор общих правил против типовых атак. Для nginx используется библиотека libmodsecurity с коннектором. Порядок для внедрения без простоев:

Установите движок и набор правил по документации вашего дистрибутива и проекта CRS.
Запустите в режиме наблюдения. Движок только пишет в журнал, ничего не блокируя:
```
SecRuleEngine DetectionOnly
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.log
```
Две–четыре недели разберите журнал. Найдите ложные срабатывания на ваших формах и приложениях, добавьте точечные исключения правил для конкретных адресов, не отключая правила глобально.
Включите блокирование на низком уровне чувствительности, поднимая его по мере готовности: SecRuleEngine On.
Отправляйте события WAF в систему сбора и настройте оповещения на всплески: сбор логов.

Что должно получиться: типовые тестовые атаки (например, простая попытка инъекции в параметре) фиксируются в журнале, а на этапе блокирования получают ответ 403, при этом обычные запросы приложения проходят. Тестируйте только свой сайт.

Шаг 3. Продумайте план на время атаки

Этап	Что сделать
До атаки	Определите контакты провайдера и услуги защиты, порядок включения, нагрузочные границы, страницу-заглушку, резервный канал
Во время	Подтвердите, что это атака, а не рост трафика; включите защиту; оповестите руководство и клиентов; не ищите причину в приложении, пока канал забит
После	Соберите журналы, оцените ущерб, обновите правила и план: разбор после инцидента

Диагностика

Симптом	Причина и что делать
Реальные пользователи получают 429	Лимиты слишком жёсткие или общий адрес NAT. Увеличьте значения, настройте исключения, проверьте `real_ip`
WAF блокирует нормальные формы	Ложные срабатывания. Добавьте точечные исключения конкретных правил для этих адресов, не отключайте WAF целиком
Сайт недоступен, nginx почти не получает запросов	Забит канал. Нужна внешняя защита от DDoS на стороне провайдера
Подбор паролей идёт с разных адресов	Лимиты по адресу не помогают. Включите MFA, блокировку по числу попыток и CAPTCHA для входа

Где это в модели зрелости

Материал относится к направлению «Сетевая безопасность» (материалы направления, карта зрелости). Уровень 1 закрывает межсетевой экран на границе, уровень 2 добавляет защиту публичных сервисов от типовых атак наряду с сегментацией и контролем правил: сегментация сети.

Как проверить

Ограничения запросов включены, nginx -t проходит, нагрузочный тест своего сайта подтверждает ожидаемую реакцию (ответы 429 выше лимита).
WAF работает, события пишутся в журнал и попадают на сервер сбора, ложные срабатывания разобраны.
Есть договор или план на случай DDoS-атаки, контакты и порядок включения защиты проверены.
Известные уязвимости сайта закрываются по процессу, а не только прикрываются WAF.

Источники

Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
Модуль ngx_http_limit_req_module, документация nginx: nginx.org.
OWASP Core Rule Set: coreruleset.org. OWASP Top 10: owasp.org. Международная практика, не российский норматив.