Эффективная защита от DDoS-атак строится на трёх столпах: оперативное обнаружение аномалий, своевременное оповещение и автоматическое реагирование. Это руководство предоставляет готовые рабочие конфигурации для настройки системы мониторинга с Prometheus и Grafana, создания алертов и реализации автоматической блокировки через Fail2ban, скрипты и API облачного WAF. Вы получите пошаговый сценарий автоматизации, который позволит не только диагностировать начало атаки, но и минимизировать её воздействие без ручного вмешательства.
Базовый анализ трафика и ручное реагирование: фундамент для автоматизации
Прежде чем внедрять сложные системы, важно освоить инструменты ручной диагностики. Они служат основой для любой автоматизации и позволяют быстро проверить состояние сервера во время аномалий.
tcpdump: первая диагностика при аномалиях трафика
Утилита tcpdump - это основной инструмент для моментальной проверки сетевой активности. Она показывает, приходят ли пакеты на сервер, что является первым шагом в диагностике DDoS или других сетевых проблем.
Для фильтрации трафика по конкретному порту используйте команду:
tcpdump -i eth0 port 80Замените eth0 на имя вашего сетевого интерфейса, а 80 на целевой порт (например, 5060 для SIP). Чтобы отслеживать трафик с конкретного IP-адреса:
tcpdump -i eth0 host 203.0.113.5Вывод команды показывает время, IP-адреса источника и назначения, порты и флаги пакетов. Большое количество SYN пакетов с разных адресов на один порт может указывать на SYN-flood атаку.
iptables: ручная блокировка нежелательного трафика
Когда источник атаки идентифицирован, временное решение - ручная блокировка через фаервол iptables. Это даст время для настройки автоматизации.
Для блокировки одиночного IP-адреса выполните:
iptables -A INPUT -s 203.0.113.5 -j DROPЧтобы заблокировать целый диапазон CIDR (например, /24):
iptables -A INPUT -s 203.0.113.0/24 -j DROPПроверить текущие правила можно командой iptables -L. Для удаления ошибочного правила найдите его номер в цепочке (iptables -L --line-numbers) и удалите:
iptables -D INPUT 3Практический кейс: при проблемах с регистрацией SIP-телефона в Asterisk системный администратор сначала использует tcpdump для проверки прихода пакетов на порт 5060, а затем анализирует правила iptables, если ответные пакеты не уходят.
Важно помнить, что ручные правки - временная мера. Для постоянной защиты требуется автоматизация и регулярное обновление системного ПО для закрытия уязвимостей, как это делается в обновлении Unraid OS 7.3.0, включающем исправления для CVE-2026-31431 и CVE-2025-43284.
Настройка системы мониторинга трафика с Prometheus и Grafana
Централизованный мониторинг предоставляет исторический взгляд на трафик и необходим для раннего обнаружения аномалий. Prometheus собирает метрики, а Grafana визуализирует их.
Сбор метрик сетевого трафика с помощью Prometheus экспортера
Для сбора данных установите node_exporter - стандартный экспортер для системных метрик. После установки он будет доступен на порту 9100.
Добавьте конфигурацию для его scrape в файл prometheus.yml:
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['your-server-ip:9100']Ключевые метрики для отслеживания DDoS:
node_network_receive_bytes_total- объём входящего трафика на интерфейс.node_network_transmit_bytes_total- объём исходящего трафика.node_netstat_Tcp_CurrEstab- количество установленных TCP-соединений.
Эти метрики станут основой для алертов и анализа. Для более детального мониторинга сетевых атак можно использовать специализированные экспортеры, например, для Nginx или HAProxy.
Визуализация и дашборды в Grafana для оперативного контроля
Создайте в Grafana дашборд для оперативного контроля. Импортируйте готовый дашборд, например, с ID 1860 (Node Exporter Full), или создайте свои панели.
Критические графики для выявления DDoS:
- Трафик по интерфейсам (бит/сек): используйте метрики
rate(node_network_receive_bytes_total[1m])*8иrate(node_network_transmit_bytes_total[1m])*8. Резкий пик на графике - первый признак аномалии. - Количество новых TCP-соединений: метрика
rate(node_netstat_Tcp_ActiveOpens[1m]). Аномальный рост может указывать на атаку на уровне соединений (L4).
Настройте временные диапазоны для сравнения трафика «тогда и сейчас». Это помогает отличить атаку от легитимного всплеска нагрузки, например, во время маркетинговой акции. Подробнее о построении дашбордов для высоконагруженных систем можно узнать в нашем руководстве по наблюдаемости.
Создание и настройка алертов для раннего обнаружения атак
Алерты автоматизируют диагностику начала атаки, избавляя специалиста от постоянного наблюдения за дашбордами. Настройка происходит в Prometheus Alertmanager.
Определение пороговых значений и условий для алертов
Первый шаг - вычисление базового уровня трафика. Используйте функцию avg_over_time за период низкой нагрузки, например, ночью:
avg_over_time(node_network_receive_bytes_total{device="eth0"}[7d])Создайте правило алертирования в файле rules.yml. Алерт на аномальный рост входящего трафика (в 10 раз за 5 минут):
groups:
- name: network_alerts
rules:
- alert: HighNetworkTraffic
expr: rate(node_network_receive_bytes_total{device="eth0"}[5m]) > avg_over_time(node_network_receive_bytes_total{device="eth0"}[7d]) * 10
for: 2m
labels:
severity: critical
annotations:
summary: "Входящий трафик превысил норму в 10 раз на {{ $labels.instance }}"
description: "Текущее значение: {{ $value }} байт/сек"Алерт на всплеск новых соединений:
- alert: HighNewConnectionsRate
expr: rate(node_netstat_Tcp_ActiveOpens[2m]) > 1000
for: 1m
labels:
severity: warningНастройка Alertmanager и каналов оповещения
В файле alertmanager.yml настройте маршруты и получателей. Пример конфигурации для отправки в Slack и Telegram:
route:
group_by: ['alertname']
receiver: 'slack-notifications'
receivers:
- name: 'slack-notifications'
slack_configs:
- api_url: 'YOUR_SLACK_WEBHOOK_URL'
channel: '#alerts'
title: '{{ .GroupLabels.alertname }}'
text: '{{ .CommonAnnotations.summary }}'
- name: 'telegram-notifications'
telegram_configs:
- api_url: "https://api.telegram.org"
bot_token: 'YOUR_BOT_TOKEN'
chat_id: YOUR_CHAT_ID
message: '{{ .CommonAnnotations.description }}'Для настройки полного стека мониторинга с нуля, включая оповещения, следуйте инструкциям в нашей статье «Стек мониторинга серверов: настройка Prometheus, Grafana и оповещений».
Автоматическое реагирование: от Fail2ban до интеграции с облачным WAF
Автоматизация ответных мер минимизирует время воздействия атаки. Сценарий реализует цепочку: алерт → анализ → блокировка.
Fail2ban как инструмент автоматической блокировки по шаблону
Fail2ban мониторит логи и автоматически блокирует IP по шаблону, аналогично принципам плагина DiamondProtector для Minecraft. Настройте его для реакции на внешние триггеры, например, на срабатывание алерта Prometheus.
Создайте jail в /etc/fail2ban/jail.local:
[prometheus-ddos]
enabled = true
filter = prometheus-ddos
action = iptables-multiport[name=Prometheus, port="http,https", protocol=tcp]
logpath = /var/log/fail2ban-prometheus.log
maxretry = 1
bantime = 3600
findtime = 60Создайте фильтр /etc/fail2ban/filter.d/prometheus-ddos.conf, который будет искать в логе определённые маркеры:
[Definition]
failregex = ^.*ALERT: HighNetworkTraffic from IP .*$ Когда скрипт (описан ниже) запишет IP в лог, Fail2ban его заблокирует.
Скрипты для интеграции мониторинга и фаервола
Для прямой связи алерта с действием напишите скрипт, который получает данные из Alertmanager и выполняет блокировку. Пример скрипта на Python (webhook для Alertmanager):
#!/usr/bin/env python3
import json
import subprocess
import sys
from http.server import BaseHTTPRequestHandler, HTTPServer
class AlertHandler(BaseHTTPRequestHandler):
def do_POST(self):
content_length = int(self.headers['Content-Length'])
post_data = self.rfile.read(content_length)
alerts = json.loads(post_data)
for alert in alerts.get('alerts', []):
if alert.get('status') == 'firing':
# Извлечение IP из аннотаций или лейблов алерта
ip_to_ban = alert['labels'].get('attacker_ip')
if ip_to_ban:
# Блокировка через iptables
subprocess.run(['iptables', '-A', 'INPUT', '-s', ip_to_ban, '-j', 'DROP'])
# Логирование для Fail2ban
with open('/var/log/fail2ban-prometheus.log', 'a') as f:
f.write(f"ALERT: {alert['labels']['alertname']} from IP {ip_to_ban}\n")
self.send_response(200)
self.end_headers()
if __name__ == '__main__':
server = HTTPServer(('0.0.0.0', 9095), AlertHandler)
server.serve_forever()Укажите этот вебхук в конфигурации Alertmanager как получатель для критических алертов.
Интеграция с облачным WAF для комплексной защиты
Для организаций, использующих облачные решения, автоматизацию можно расширить до интеграции с API WAF (например, Cloudflare, AWS WAF).
Пример фрагмента скрипта для добавления IP в blacklist Cloudflare через API:
import requests
API_KEY = 'your_cloudflare_api_key'
ZONE_ID = 'your_zone_id'
IP_TO_BAN = '203.0.113.5'
url = f"https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/firewall/access_rules/rules"
headers = {
'Authorization': f'Bearer {API_KEY}',
'Content-Type': 'application/json'
}
payload = {
"mode": "block",
"configuration": {"target": "ip", "value": IP_TO_BAN},
"notes": "Banned via automated DDoS response script"
}
response = requests.post(url, json=payload, headers=headers)Облачные WAF эффективны против сложных атак на уровне приложений (L7), но требуют бюджета. Локальные решения, такие как связка iptables + Fail2ban, бесплатны, но требуют ресурсов сервера и не защитят от атак на канал связи. Для глубокого изучения стратегий блокировки IP обратитесь к нашему полному руководству по блокировке IP-адресов.
Тестирование, откат и поддержка рабочей системы
Внедрение системы автоматического реагирования сопряжено с риском ложных срабатываний. Безопасное тестирование и чёткие процедуры отката критически важны.
Безопасное тестирование системы алертирования и реагирования
Тестируйте систему в изолированной staging-среде. Для генерации контролируемого тестового трафика используйте инструменты вроде Apache Bench (ab) или hping3.
Пример теста нагрузки, который должен вызвать алерт:
ab -n 10000 -c 100 http://your-staging-server/Для имитации SYN-флуда (только в изолированной сети!):
hping3 -S --flood -p 80 your-staging-server-ipНастройте в Prometheus отдельную группу алертов для тестового окружения с пониженными порогами срабатывания. Это позволит проверить всю цепочку - от метрики до блокировки - без риска для production.
Процедуры мониторинга и отката на случай ложных срабатываний
После внедрения настройте дополнительный мониторинг для отслеживания ложных блокировок. Например, алерт на резкое падение легитимного трафика после срабатывания правила блокировки.
Подготовьте скрипт для быстрого отката всех правил, добавленных автоматической системой. Самый простой способ - помечать такие правила отдельной цепочкой в iptables:
# Создание отдельной цепочки
iptables -N AUTO_DDOS_BLOCK
# Перенаправление трафика в неё из INPUT
iptables -I INPUT -j AUTO_DDoS_BLOCK
# Скрипт добавляет блокировки в эту цепочку
# Скрипт для полной очистки цепочки:
iptables -F AUTO_DDOS_BLOCKВсе автоматические действия должны детально логироваться. Анализ этих логов поможет настроить пороги алертов точнее. Для автоматизации резервного копирования и отката конфигураций используйте проверенные скрипты из нашего руководства по автоматизации резервного копирования.
Поддержка системы включает регулярное обновление всех компонентов: Prometheus, Grafana, node_exporter, ОС. Подписывайтесь на рассылки безопасности для используемого ПО, чтобы оперативно закрывать новые уязвимости, подобные CVE-2026-31431. Для оперативного анализа логов веб-серверов на предмет атак после инцидента держите под рукой готовые команды grep и awk.
Построение описанной системы требует времени, но результат - автоматизированный щит, который сокращает время реакции на атаки с часов до минут. Это прямая экономия на простое и защита репутации сервиса. Для автоматизации других рутинных задач DevOps рассмотрите возможность использования агрегатора AI API, например, AiTunnel, который предоставляет единый интерфейс для работы с более чем 200 моделями ИИ, что может помочь в написании скриптов или анализе инцидентов.