Как защитить Nginx от DDoS

Nginx предоставляет набор встроенных инструментов для наблюдения за трафиком и ограничения запросов — статусная страница, ограничения скорости (limit_req/limit_conn), блокировки по IP и фильтрация по URL. Для серьёзной защиты комбинируйте настройки Nginx с CDN/WAF, fail2ban и сетевыми правилами на уровне ОС. Внизу — чек‑листы, план инцидента и примерные тесты.

Nginx Prevent Ddos Attack Featured

Введение

Распределённые атаки типа «отказ в обслуживании» (DDoS) пытаются исчерпать ресурсы сервера с помощью большого количества вредоносных сетевых запросов. Nginx — лёгкий и гибкий веб‑сервер/реверс‑прокси — содержит несколько полезных механизмов, которые позволяют значительно снизить эффективность таких атак. Этот материал рассказывает об основных приёмах защиты, о сценариях, когда они работают или не работают, и предлагает практические чек‑листы и методики.

Важно: приведённые примеры подходят для большинства Unix‑серверов с установленным Nginx. Для публично доступных продакшен‑сайтов рекомендуем комбинировать локальные меры с облачными сервисами (CDN/WAF) и аппаратными/сетевыми средствами.

Резервная копия конфигурации

Прежде чем менять настройки, создайте резервную копию основного конфигурационного файла:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup-original

Nginx Copy Config

Создание резервной копии позволяет быстро откатиться при ошибке.

Наблюдение за трафиком

Наблюдение — ключ к корректной защите. Сначала нужно понять, что является нормой, а что — аномалией.

Статусная страница (stub_status)

Модуль http_stub_status_module показывает базовую статистику: активные соединения, количество запросов и т. п. Проверьте наличие модуля:

nginx -V 2>&1 | grep -o with-http_stub_status_module

Если модуль отсутствует, установите пакет Nginx с поддержкой этого модуля или перекомпилируйте Nginx.

Добавьте в блок http в /etc/nginx/nginx.conf минимально разрешённый доступ к статусной странице (замените server_name, путь и IP под свои нужды):

server {
    listen 80;
    listen [::]:80;
    server_name localhost;

    ##
    # Настройки статусной страницы
    ##

    location /status_page {
        stub_status on;
        allow 127.0.0.1;
        allow ::1;
        deny all;
    }
}

Протестируйте конфигурацию и перезагрузите Nginx:

sudo nginx -t
sudo systemctl reload nginx

Затем откройте статусную страницу в браузере или с помощью curl:

curl localhost/status_page

Nginx Curl Status

Статусная страница даёт быструю картину нагрузки. Если вы видите резкий рост подключений или запросов — это сигнал расследовать дальше.

Просмотр логов доступа

Файл /var/log/nginx/access.log содержит цепочку запросов: метод, URL, временные метки, user‑agent и IP. При аномалиях фильтруйте и агрегируйте логи (grep, awk, goaccess, ELK). Частые подозрительные паттерны: много одинаковых путей, подозрительные user‑agent, множество запросов с одного префикса IP.

Nginx Access Log

Ограничение числа и скорости запросов

Одна из самых эффективных тактик — ограничить скорость и «удары» от одного клиента.

Основные директивы:

limit_req_zone — задаёт зону памяти и скорость (rate).
limit_req — применяет правило в локации и задаёт «burst» (буфер).
limit_conn_zone и limit_conn — ограничивают параллельные соединения.

Пример в http‑блоке:

# Задаём зону для ограничения по IP: имя=zone_name, размер=10m, скорость=10 запросов/сек
limit_req_zone $binary_remote_addr zone=speedbump:10m rate=10r/s;

# Ограничение параллельных соединений (по IP)
limit_conn_zone $binary_remote_addr zone=addr:10m;

Применение в server/location:

server {
    ...
    location / {
        limit_req zone=speedbump burst=20 nodelay;
        limit_conn addr 10;
        # остальная конфигурация
    }
}

Пояснения:

rate=10r/s — допускаемая средняя скорость (10 запросов в секунду от одного IP). Это ориентир, подстраивайте под ваше приложение.
burst=20 — короткий буфер для всплесков. Если превышает burst, клиенту вернётся 503.
limit_conn addr 10 — максимум параллельных соединений от одного IP.

Совет: комбинируйте rate и limit_conn — один ограничивает поток запросов, другой — соединения TCP.

Nginx Limit Code

Чёрные списки IP и блокировка URL

Если вы выделили конкретные атакующие IP, заблокируйте их в конфигурации:

location / {
    deny 123.123.123.0/28;
    # ...
}

Если атака нацелена на конкретные ресурсы (например, /xmlrpc.php у WordPress), блокируйте прямые запросы к этим файлам:

location = /xmlrpc.php {
    deny all;
}

Эта простая мера экономит ресурсы при целенаправленных атаках.

Дополнительные меры защиты (уровни и альтернативы)

CDN и облачный WAF (рекомендуется для публичных фронтов)
- Перенаправляет трафик через распределённую сеть, фильтрует бот‑трафик, скрывает реальный IP сервера.
Fail2ban + анализ логов
- Автоматически добавляет правила брандмауэра при повторных подозрительных попытках.
Правила на уровне ОС: iptables / nftables
- Блокировка по IP/подсетям, rate limiting на уровне сетевого стека.
Kernel‑tuning (tcp_tw_reuse, netfilter_conntrack)
- Уменьшение количества состояний, настройка таймаутов.
Аппаратные/провайдерские защиты
- DDoS‑защита на уровне провайдера, фильтрация на магистральном оборудовании.

Когда локальные меры недостаточны: сетевые и облачные решения помогают в случае масштабных ботнет‑атак или UDP‑амплификаций.

Интеграция fail2ban с Nginx (простейший пример)

Установите fail2ban и создайте фильтр /etc/fail2ban/filter.d/nginx‑ddos.conf с правилами поиска подозрительных запросов в access.log.
Создайте jail в /etc/fail2ban/jail.d/nginx.conf:

[nginx-ddos]
enabled = true
filter = nginx-ddos
action = iptables-multiport[name=nginx-ddos, port="http,https"]
logpath = /var/log/nginx/access.log
maxretry = 50
findtime = 60
bantime = 3600

Настройте значения maxretry/findtime/bantime под вашу нагрузку.

Когда эти механизмы могут не сработать

UDP‑амплификационные атаки (NTP, DNS) — Nginx не обрабатывает их, надо фильтровать на уровне сети/провайдера.
Массивные ботнет‑атаки со спуфингом — блокировка по IP малоэффективна.
Атаки на сетевой стек (SYN flood) — нужны сетевые/ядровые и провайдерские меры.

Важно понимать зоны ответственности: Nginx — это прикладной уровень (L7); для L3/L4 атак нужны другие инструменты.

Мини‑методология реагирования (SOP)

Оперативно: включите статусную страницу, снимите текущие метрики.
Идентификация: изучите access.log — источники, user‑agent, URL.
Быстрые меры: примените limit_req/limit_conn, добавьте deny для очевидных IP, заблокируйте целевые файлы.
Среднесрочно: добавьте fail2ban, накатите правила iptables/nftables.
Долгосрочно: подключите CDN/WAF, договоритесь с провайдером о фильтрации DDoS.

Инцидентный план и откат

Шаг 0: Резервная копия nginx.conf (см. выше).
Шаг 1: Применить минимальные ограничения (сохраните старую конфигурацию как backup‑1).
Шаг 2: Наблюдать 5–15 минут. Если поведение ухудшилось — откат к backup‑1 и пробуем другой набор ограничений.
Шаг 3: При добавлении iptables правил — сохраняйте правила в файл и проверяйте доступность SSH (в отдельной сессии).

Критерии приёмки

Статусная страница доступна только для доверенных IP.
Базовые ограничения не приводят к блокировке >1% легитимных клиентов (по логам).
Инструменты блокировки (fail2ban, iptables) документированы и имеют откат.

Тесты и приёмка

Примеры тестов:

Генерация нагрузки с одного IP (ab, siege) — убедиться, что n‑й запрос получает 503 после превышения burst.
Моделирование нескольких параллельных клиентов — проверить limit_conn.
Проверка логов после блокировки — IP попал в deny или fail2ban.

Примерные команды для тестирования (не на продакшн):

ab -n 1000 -c 50 http://localhost/
siege -c50 -t30s http://localhost/

Чек‑лист для ролей

Администратор (DevOps):

Сделать резервную копию nginx.conf
Включить stub_status и ограничить доступ к ней
Настроить limit_req_zone/limit_req, limit_conn_zone/limit_conn
Настроить fail2ban, проверить правила iptables
Протестировать и откатить при необходимости

Разработчик:

Проверить, что механизмы ограничения не нарушают UX (API‑клиенты, мобильные)
Убедиться, что важные endpoint‑ы (webhooks) защищены и приоритетны

Оператор поддержки:

Знать процедуру отката и контакт провайдера
Наблюдать статусную страницу и метрики каждые 5–15 минут

Снижение риска и приватность

Log retention: храните логи минимум для расследования, но очищайте старые логи согласно политике хранения данных.
GDPR/LPD: при блокировке IP не отправляйте личные данные в открытые службы; ограничьте доступ к логам.

Шпаргалка (cheat sheet)

Показать модуль: nginx -V 2>&1 | grep -o with-http_stub_status_module
Тест конфигурации: sudo nginx -t
Перезагрузка: sudo systemctl reload nginx
Базовый limit_req: limit_req_zone $binary_remote_addr zone=speedbump:10m rate=10r/s;
Базовый deny: deny 123.123.123.0/28;

Решение на основе диаграммы (упрощённый алгоритм)

flowchart TD
  A[Наблюдение: резкий рост трафика?] -->|Да| B[Проверить статусную страницу и access.log]
  B --> C{Атака L7 или L3/L4?}
  C -->|L7| D[Включить limit_req/limit_conn, блокировка URL/IP, fail2ban]
  C -->|L3/L4| E[Обратиться к провайдеру, включить фильтрацию на сетевом уровне]
  D --> F{Эффективно?}
  F -->|Да| G[Мониторить и закрыть инцидент]
  F -->|Нет| H[Подключить CDN/WAF, применить сетевые правила]
  E --> G

Когда приглашать провайдера

Если атака генерирует сотни гигабит/сек — привлекайте провайдера или облачный DDoS‑сервис.
Если наблюдается UDP‑амплификация — фильтрация на магистральном уровне обязана выполняться вне вашего сервера.

Резюме

Nginx даёт эффективные средства для защиты от большинства прикладных DDoS‑атак: статусная страница для мониторинга, limit_req/limit_conn для ограничений, возможность блокировать IP и пути. Для серьёзных и масштабных атак комбинируйте локальные меры с fail2ban, правилами ОС и сторонними CDN/WAF. Всегда имейте план отката, тестируйте изменения и документируйте правила.

Важно