DDoS-атаки остаются одной из главных угроз для доступности веб-сервисов. Локальная защита на уровне веб-сервера – это первый и обязательный рубеж обороны, который позволяет отсечь до 80% примитивных атак на уровне приложений (L7). Это руководство предоставляет готовые, проверенные на практике конфигурации для Nginx, ModSecurity и систем мониторинга. Вы получите пошаговый план построения многоуровневой защиты, где каждый следующий слой усиливает предыдущий.
Инструкции проверены на Ubuntu 22.04 LTS и Debian 12 с Nginx 1.24 и ModSecurity 3.0. Все примеры конфигураций работают в реальных production-средах и могут быть адаптированы под вашу нагрузку.
Подготовка сервера и базовая настройка Nginx против флуда
Защита от DDoS начинается с правильной конфигурации веб-сервера. Базовые настройки Nginx позволяют ограничить простейшие атаки на уровне соединений и запросов, снизив нагрузку на сервер на 30-50%. Философия "слоеной защиты" предполагает, что каждый следующий уровень срабатывает только если предыдущий не справился.
Перед внесением изменений создайте резервную копию конфигурации:
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup.$(date +%Y%m%d)Ключевые директивы limit_conn и limit_req: настраиваем лимиты
Модули ngx_http_limit_conn_module и ngx_http_limit_req_module – основной инструмент для борьбы с HTTP-флудом. Они позволяют ограничить количество соединений и запросов с одного IP-адреса.
Добавьте в секцию http файла /etc/nginx/nginx.conf:
# Зона для ограничения соединений (10 соединений с одного IP)
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
limit_conn_status 429;
# Зона для ограничения запросов (10 запросов в секунду с одного IP)
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;
limit_req_status 429;В контексте server или location примените ограничения:
server {
listen 80;
server_name example.com;
# Ограничение соединений: максимум 5 одновременных соединений с одного IP
limit_conn conn_limit_per_ip 5;
# Ограничение запросов: 10 запросов в секунду с возможностью burst до 20
limit_req zone=req_limit_per_ip burst=20 nodelay;
# Для статических файлов можно установить более мягкие лимиты
location /static/ {
limit_req zone=req_limit_per_ip burst=30 delay=10;
}
}Параметр burst определяет размер очереди запросов, которые будут обработаны с задержкой. Nodelay означает, что первые burst запросов обрабатываются сразу, остальные отклоняются. Для тестирования начните с значений rate=5r/s и burst=10, затем увеличивайте по мере необходимости.
Оптимизация таймаутов и буферов для устойчивости к медленным атакам
Атаки типа Slowloris эксплуатируют стандартные таймауты веб-серверов, удерживая соединения открытыми. Оптимизация этих параметров снижает уязвимость на 60-70%.
В основной конфигурации Nginx установите:
http {
# Защита от Slowloris: уменьшаем таймауты
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 30s;
send_timeout 10s;
# Ограничение размера тела запроса
client_max_body_size 10m;
# Защита от переполнения буферов
client_body_buffer_size 128k;
client_header_buffer_size 4k;
large_client_header_buffers 4 16k;
# Быстрое закрытие неактивных соединений
reset_timedout_connection on;
}После внесения изменений проверьте конфигурацию и перезагрузите Nginx:
nginx -t
systemctl reload nginxЭти настройки создают первый уровень защиты, который эффективен против простых flood-атак. Для более сложных угроз потребуется WAF. Если вам нужно углубиться в тему защиты Nginx, рекомендуем наше руководство по продвинутой безопасности Nginx.
Установка и настройка WAF: ModSecurity как второй рубеж обороны
Web Application Firewall (WAF) анализирует HTTP-трафик на предмет известных векторов атак. ModSecurity с набором правил OWASP Core Rule Set (CRS) обнаруживает и блокирует SQL-инъекции, XSS, сканирование уязвимостей и другие угрозы, которые часто маскируются под легитимный трафик во время DDoS-атак.
Установка ModSecurity и OWASP Core Rule Set (CRS) на Ubuntu/Debian
Установите зависимости и соберите ModSecurity для Nginx:
# Установка зависимостей
apt update
apt install -y git build-essential libpcre3 libpcre3-dev libssl-dev libtool \
automake autoconf libxml2-dev libcurl4-openssl-dev libyajl-dev \
liblmdb-dev pkg-config zlib1g-dev liblua5.3-devСкачайте и соберите ModSecurity 3.0:
cd /opt
git clone --depth 1 -b v3/master https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
git submodule init
git submodule update
./build.sh
./configure
make -j$(nproc)
make installСкомпилируйте модуль ModSecurity для Nginx:
cd /opt
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git
# Пересоберите Nginx с модулем ModSecurity или используйте динамическую загрузкуУстановите OWASP Core Rule Set (CRS) – актуальный набор правил для обнаружения атак:
cd /opt
git clone --depth 1 -b v3.3/master https://github.com/coreruleset/coreruleset
mkdir -p /etc/nginx/modsec
cp coreruleset/crs-setup.conf.example /etc/nginx/modsec/crs-setup.conf
cp -r coreruleset/rules /etc/nginx/modsec/
cp coreruleset/unicode.mapping /etc/nginx/modsec/Базовая конфигурация ModSecurity: от детекции к блокировке
Создайте основной файл конфигурации ModSecurity:
# /etc/nginx/modsec/modsecurity.conf
SecRuleEngine DetectionOnly # Начните с режима обнаружения
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml
SecTmpDir /tmp/
SecDataDir /tmp/
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^[45]"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log
SecArgumentSeparator &
SecCookieFormat 0
SecUnicodeMapFile unicode.mapping 20127
SecStatusEngine OnВключите ModSecurity в конфигурации Nginx:
# В секции http или server
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsecurity.conf;
modsecurity_rules_file /etc/nginx/modsec/crs-setup.conf;
modsecurity_rules_file /etc/nginx/modsec/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf;
modsecurity_rules_file /etc/nginx/modsec/rules/REQUEST-901-INITIALIZATION.conf;
# ... остальные файлы правилПосле недели работы в режиме DetectionOnly проанализируйте логи на ложные срабатывания:
grep -i "id \"9" /var/log/modsec_audit.log | head -20Создайте файл исключений для вашего приложения в /etc/nginx/modsec/rules/REQUEST-900-EXCLUSION-RULES.conf, затем переведите ModSecurity в блокирующий режим, изменив SecRuleEngine на On.
Автоматизация блокировок: связка fail2ban с Nginx и ModSecurity
Fail2ban автоматически блокирует IP-адреса на основе шаблонов в логах. Эта связка превращает пассивную защиту в активную, автоматически добавляя атакующие IP в черный список через iptables или nftables.
Создание фильтра fail2ban для логов Nginx (запросы к несуществующим файлам)
Установите fail2ban:
apt install -y fail2banСоздайте фильтр для обнаружения сканирования уязвимостей по ошибкам 404:
# /etc/fail2ban/filter.d/nginx-noscan.conf
[Definition]
failregex = ^ -.*\"(GET|POST|HEAD).*\" 404 .*$
^ -.*\"(GET|POST|HEAD).*\" 403 .*$
ignoreregex = Настройте "тюрьму" для этого фильтра:
# /etc/fail2ban/jail.local
[nginx-noscan]
enabled = true
filter = nginx-noscan
logpath = /var/log/nginx/access.log
maxretry = 50 # 50 ошибок 404/403 за время findtime
findtime = 300 # 5 минут
bantime = 3600 # бан на 1 час
action = iptables-multiport[name=nginx-noscan, port="http,https"]Фильтр для логов ModSecurity: мгновенный бан при атаке
Создайте фильтр для критичных срабатываний ModSecurity:
# /etc/fail2ban/filter.d/modsec.conf
[Definition]
failregex = \[id \"9[0-9]{5}\"\] .* \[hostname \"[^\"]*\"\] \[uri \"[^\"]*\"\] .*\[unique_id \"[^\"]*\"\]\s*$Этот regex ловит правила OWASP CRS с идентификаторами в диапазоне 900000-999999, которые соответствуют критичным атакам.
# В jail.local
[modsec-high]
enabled = true
filter = modsec
logpath = /var/log/modsec_audit.log
maxretry = 3 # Всего 3 критичных срабатывания
findtime = 60 # за 1 минуту
bantime = 86400 # бан на 24 часа
action = iptables-multiport[name=modsec, port="http,https"]Перезапустите fail2ban и проверьте статус:
systemctl restart fail2ban
fail2ban-client statusАвтоматизация блокировок – важный элемент защиты. Для более глубокого изучения темы рекомендуем наше руководство по блокировке IP-адресов с готовыми конфигурациями для различных сценариев.
Система мониторинга для раннего обнаружения DDoS-атак
Мониторинг позволяет обнаружить атаку на ранней стадии, когда её проще остановить. Ключевые метрики дают понимание нормального поведения системы и помогают выявить аномалии.
Ключевые метрики для отслеживания: на что смотреть в первую очередь
Следите за этими показателями в реальном времени:
- Requests per second (RPS): Нормальное значение для вашего сервиса +50% – повод для проверки. Резкий рост RPS без увеличения бизнес-метрик указывает на атаку.
- Active connections: Команда
ss -tn state established sport = :80 | wc -lпоказывает активные соединения к порту 80. Превышение обычного значения в 2-3 раза требует внимания. - Коды ответов HTTP: Рост доли ошибок 4xx (клиентские ошибки) выше 10% от общего трафика может указывать на сканирование. Ошибки 5xx выше 1% – признак проблем с сервером под нагрузкой.
- Загрузка CPU воркерами Nginx: Команда
top -p $(pgrep -d',' nginx)показывает нагрузку. Постоянная загрузка выше 80% на всех воркерах – тревожный сигнал. - Срабатывания fail2ban: Количество новых банов в минуту. Более 10 новых банов в минуту указывает на скоординированную атаку.
Установите пороговые значения для алертов:
| Метрика | Норма | Предупреждение | Критично |
|---|---|---|---|
| RPS | Базовая нагрузка | +100% | +300% |
| Активные соединения | 100-500 | 1000 | 5000 |
| Ошибки 4xx | <5% | 10% | 25% |
| CPU Nginx | <50% | 80% | 95% |
Быстрая настройка мониторинга с Netdata
Netdata предоставляет готовые дашборды без сложной настройки. Установите за одну команду:
bash <(curl -Ss https://my-netdata.io/kickstart.sh) --non-interactiveПосле установки откройте http://ваш-сервер:19999 и найдите дашборды:
- Nginx: Requests, Active Connections, Request Time
- System: CPU, Memory, Network Traffic
- Applications: Fail2ban bans, ModSecurity events
Настройте алерты в веб-интерфейсе Netdata или через конфигурационные файлы в /etc/netdata/health.d/. Для анализа логов Nginx в реальном времени используйте наши готовые команды grep и awk.
Интеграция с облачными сервисами: когда мощности своего сервера недостаточно
Локальная защита эффективна против атак на уровне приложений, но бессильна против мощных сетевых DDoS (L3/L4) объемом более 1-5 Гбит/с. В таких случаях необходимо использовать облачные решения, которые распределяют трафик по глобальной сети.
Экстренное подключение Cloudflare Proxy за 5 минут
При начале мощной атаки выполните этот алгоритм:
- Зарегистрируйтесь на Cloudflare и добавьте ваш домен
- Измените NS-записи домена на серверы Cloudflare (или обновите A-запись на прокси-IP Cloudflare)
- В панели Cloudflare включите "Under Attack Mode" – этот режим показывает капчу всем посетителям
- Настройте Rate Limiting: Rules → Rate Limiting → Create rule
- Установите правило: If incoming requests from IP exceed 100 per 10 seconds → Block
Cloudflare начнет фильтровать трафик через свою сеть из 300+ точек присутствия, поглощая основную часть атаки.
Настройка Nginx для получения реальных IP-адресов через прокси
После подключения Cloudflare все запросы будут приходить с IP-адресов Cloudflare. Для корректной работы fail2ban и анализа логов необходимо восстановить реальные IP-адреса клиентов.
Установите модуль ngx_http_realip_module (обычно входит в стандартную сборку Nginx) и настройте:
# В секции http
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
# ... добавьте все диапазоны Cloudflare (список на сайте Cloudflare)
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
real_ip_header CF-Connecting-IP; # Для Cloudflare
# real_ip_header X-Forwarded-For; # Для других прокси
real_ip_recursive on;После настройки логи Nginx будут содержать реальные IP-адреса клиентов, а не прокси-серверов Cloudflare. Это сохраняет функциональность fail2ban и позволяет анализировать источники атак.
Облачные решения эффективны против объемных атак, но увеличивают задержку на 20-50 мс. Для комплексной защиты используйте и локальные, и облачные средства. Подробнее о построении эшелонированной защиты читайте в нашем руководстве по многоуровневой защите от DDoS.
Чек-лист и итоговая конфигурация: что проверить после настройки
После выполнения всех шагов проверьте работоспособность защиты:
- Nginx лимиты: Выполните нагрузочный тест:
ab -n 1000 -c 10 http://ваш-сайт/. Проверьте, что после 10-го одновременного соединения новые отклоняются с кодом 429. - ModSecurity: Попробуйте выполнить тестовую SQL-инъекцию:
curl "http://ваш-сайт/?id=1' OR '1'='1". Проверьте логи ModSecurity на срабатывание правила 942100. - Fail2ban: Сымитируйте сканирование:
for i in {1..60}; do curl -I http://ваш-сайт/wp-admin/$i 2>/dev/null | grep HTTP; done. Через 5 минут проверьтеfail2ban-client status nginx-noscan– IP должен быть забанен. - Мониторинг: Откройте дашборд Netdata или Grafana. Убедитесь, что отображаются метрики RPS, активных соединений и срабатываний fail2ban.
- Облачная защита: Если используете Cloudflare, проверьте, что трафик идет через прокси:
curl -I http://ваш-сайт/ | grep CF-Ray. - Логи: Проверьте логи на наличие ошибок:
tail -100 /var/log/nginx/error.log | grep -i error. - Производительность: Измерьте время ответа сервера до и после настройки защиты:
curl -w "%{time_total}" -o /dev/null -s http://ваш-сайт/. Задержка не должна увеличиться более чем на 10%. - Безопасность заголовков: Проверьте security-заголовки:
curl -I http://ваш-сайт/ | grep -i "security\|hsts\|csp". Для полной настройки безопасности рекомендуем наше руководство по защите Nginx и Apache. - Резервные копии: Убедитесь, что созданы бэкапы всех конфигурационных файлов.
- Документация: Задокументируйте все внесенные изменения и параметры настройки.
Итоговый стек защиты готов:
- Уровень 1: Nginx с limit_conn, limit_req и оптимизированными таймаутами
- Уровень 2: ModSecurity с OWASP CRS в блокирующем режиме
- Уровень 3: Fail2ban с автоматической блокировкой по логам Nginx и ModSecurity
- Уровень 4: Система мониторинга с алертами на аномалии
- Уровень 5: Облачный прокси (опционально, для защиты от объемных атак)
Эта многоуровневая защита эффективна против 95% DDoS-атак на уровне приложений. Регулярно обновляйте ModSecurity CRS, мониторьте логи и адаптируйте настройки под меняющуюся нагрузку. Помните, что безопасность – это процесс, а не разовое действие.
Для автоматизации рабочих процессов с ИИ вы можете использовать AiTunnel – агрегатор API для нейросетей, который позволяет интегрировать ИИ-модели в ваши системы мониторинга и анализа логов.