Три часа ночи, PagerDuty орёт, latency API-шлюза подскочил с 40 мс до 12 секунд за полторы минуты. Дашборд NETSCOUT Sightline показывает 47 Гбит/с входящего трафика при норме в 2.5 Гбит/с. Дежурный NOC-инженер смотрит на экран и думает - звонить провайдеру или руководителю. Для этих секунд и существует DDoS incident response playbook: не методичка на полку, а последовательность шагов, которая отрабатывается на автомате, когда времени думать уже нет. Ниже - план реагирования на DDoS-атаку, собранный из реальных дежурств и tabletop-учений, с конкретными командами, порогами и ролями.
Бизнес-логика DDoS-атаки: зачем это атакующему
Прежде чем разбирать процедуры реагирования на инциденты DDoS, нужно понять мотивацию. В классификации MITRE ATT&CK DDoS относится к тактике Impact: Network Denial of Service (T1498) и Endpoint Denial of Service (T1499). Но DDoS - не всегда конечная цель.Три основных сценария:
- Прямая атака на доступность. Вымогательство (ransom DDoS), конкурентная борьба, хактивизм. Цель - уронить сервис, нанести финансовый и репутационный урон.
- Дымовая завеса. DDoS перегружает SOC алертами, пока параллельно идёт lateral movement или exfiltration. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты. Если SOC-команда залипла в трафиковых дашбордах - это окно расширяется кратно.
- Разведка защиты. Проверка порогов срабатывания, скорости реакции, наличия scrubbing-центров перед основной операцией.
Классификация DDoS-атак через MITRE ATT&CK
Правильная классификация в первые минуты определяет стратегию митигации. Ошиблись с типом - потеряли время на бесполезные контрмеры.
| Тип атаки | MITRE ATT&CK ID | Примеры | Ключевые индикаторы |
|---|---|---|---|
| Volumetric (L3/L4) | T1498.001 Direct Network Flood | UDP flood, ICMP flood | Всплеск bps/pps при стабильном числе уникальных сессий |
| Reflection/Amplification | T1498.002 Reflection Amplification | DNS amp, NTP monlist, Memcached | UDP с портов 53, 123, 11211; коэффициент усиления до x50 000 |
| Protocol (L4) | T1499.001 OS Exhaustion Flood | SYN flood, ACK flood | Переполнение таблицы TCP-соединений, рост half-open сессий |
| Application (L7) - Service | T1499.002 Service Exhaustion Flood | HTTP flood, HTTPS flood | Рост RPS при нормальном bps; высокая нагрузка backend |
| Application (L7) - Logic | T1499.003 Application Exhaustion Flood | Slowloris, R.U.D.Y. | Минимальный трафик, долгоживущие соединения, максимальное потребление ресурсов |
Отдельно - T1583.005 Botnet (Resource Development): подготовительная техника, обеспечивающая инфраструктуру для большинства распределённых атак. Характеристики ботнета (гео-распределение, тип устройств, user-agent паттерны) пригодятся при post-mortem DDoS анализе.
Таблица работает для "чистых" атак. На практике значительная доля серьёзных инцидентов - мультивекторные: volumetric + application-layer одновременно. Runbook DDoS атака должен предусматривать параллельные контрмеры для нескольких уровней сразу. Об этом подробнее в конце.
Подготовка до инцидента: что должно быть готово
Plan реагирования на DDoS без подготовленной инфраструктуры - бумага. Согласно NIST SP 800-61r3 и CSF 2.0 (функции Govern, Identify, Protect), основная работа по incident response происходит до инцидента. NIST IR-1 (Incident Response Policy and Procedures) требует: политика, роли, процедуры - всё документировано и протестировано заранее.Требования к окружению
- Мониторинг трафика: NETSCOUT Sightline/Arbor, Kentik, ntopng или flow-collector с поддержкой NetFlow v9/IPFIX. Минимум - sFlow-агент на каждом edge-маршрутизаторе, коллектор с 8 ГБ RAM и 500 ГБ SSD для хранения 30-дневной истории
- SIEM: Splunk (минимум 100 ГБ/день license), IBM QRadar (3000 EPS), ELK-стек (32 ГБ RAM на ноду) - с настроенными парсерами для netflow, syslog от маршрутизаторов, логов WAF
- Edge-маршрутизаторы: поддержка BGP communities для RTBH - Cisco IOS-XE 16.x+, Juniper JunOS 18+, MikroTik RouterOS 7.x
- Минимум 2 аплинка от разных провайдеров для selective blackholing без полной потери связности
- Контракт с scrubbing-сервисом (Cloudflare Magic Transit, Akamai Prolexic, DDoS-Guard, Qrator) с SLA на активацию менее 15 минут. Стоимость: порядка 50-150 тыс. руб./мес для полосы до 10 Гбит/с
- WAF перед application-layer: nginx с модулем rate limiting, Cloudflare WAF или аналог
Baseline трафика
Без baseline нет обнаружения DDoS-атаки. Фиксируйте и обновляйте ежемесячно:- Средний и пиковый входящий трафик в bps и pps (разбивка по интерфейсам)
- Распределение протоколов (TCP/UDP/ICMP в процентах)
- Нормальные значения RPS на каждый критический endpoint
- Гео-распределение клиентского трафика (топ-10 стран)
- Типичное число одновременных TCP-соединений на балансировщик
Trade-off таблица: инструменты DDoS mitigation
| Инструмент / подход | Преимущества | Ограничения | Когда использовать | Когда НЕ использовать |
|---|---|---|---|---|
| BGP RTBH | Мгновенная разгрузка канала, не требует допоборудования | Блокирует весь трафик к IP, включая легитимный | Volumetric превышает полосу аплинка, нет scrubbing | Единственный production IP без failover |
| Cloud Scrubbing (Qrator, Cloudflare, Akamai) | Фильтрует атаку, пропускает легитимный трафик | 50-150 тыс. руб./мес, latency +5-20 мс, false positives | Volumetric и amplification L3/L4 | Атаки менее 1 Гбит/с (overhead не оправдан) |
| WAF Rate Limiting | Точечная защита конкретных endpoints | Не помогает при L3/L4, требует тюнинга под каждый endpoint | Application-layer flood (T1499.002/003) | Volumetric, SYN flood |
| BGP Flowspec (RFC 8955) | Гранулярная фильтрация по 5-tuple на edge провайдера | Зависит от поддержки провайдера, сложнее в настройке | Когда RTBH слишком грубый, нужна фильтрация по source port | Провайдер не поддерживает Flowspec |
| SYN Cookies (ядро ОС) | Нулевые затраты, встроено в Linux | Не помогает при volumetric, ломает TCP options (window scaling) | SYN flood при достаточной полосе канала | Мультивекторные атаки |
Матрица коммуникаций
| Роль | Действие при DDoS | Канал |
|---|---|---|
| Дежурный NOC (L1) | Первичная детекция, классификация, эскалация | PagerDuty / Opsgenie |
| SOC-аналитик (L2) | Подтверждение атаки, исключение false positive, проверка на дымовую завесу | Slack #incident + bridge call |
| Сетевой инженер (L3) | RTBH, ACL, координация с провайдером | Bridge call + тикет провайдеру |
| Incident Commander | Решения об эскалации, коммуникация с бизнесом | Bridge call |
| PR / Communications | Обновление status page при влиянии на клиентов | Email + status page |
Роли, не имена. Контактный лист - отдельный документ с ограниченным доступом, обновляется ежеквартально.
Pre-authorized действия
Заранее согласуйте с руководством список действий, которые дежурный выполняет без дополнительного одобрения. Если в три часа ночи инженеру нужно ждать подписи для включения RTBH - playbook бесполезен.Типовой набор: активация RTBH для IP под атакой; включение rate limiting на WAF до согласованных порогов; активация scrubbing-сервиса; изменение DNS TTL; блокировка geo-регионов, из которых нет легитимного трафика.
Фаза 1 - Детекция и классификация (0-5 минут)
NIST CSF 2.0, функция Detect (DE.AE-01): "A baseline of network operations and expected data flows for users and systems is established and managed.""Устанавливается и контролируется базовый уровень сетевых операций и ожидаемых потоков данных для пользователей и систем." Первые пять минут - подтверждение и классификация.Шаг 1: Валидация алерта (0-1 мин). Источники: CloudWatch/Grafana по latency и error rate, NETSCOUT Sightline TMS, flow-аномалия в SIEM, жалобы в service desk. Первое действие: открыть дашборд трафика и отличить легитимный пик (маркетинговая кампания, вирусный контент, начало рабочего дня в другом часовом поясе) от аномалии. Маркеры аномалии: трафик растёт, но число уникальных source IP не коррелирует; преобладание одного протокола (95%+ UDP при обычных 30%); трафик на один destination IP.
Шаг 2: Классификация типа атаки (1-3 мин). Decision tree для обнаружения DDoS-атаки:
- bps растёт, pps растёт пропорционально, пакеты крупные (более 500 байт)? Volumetric (T1498.001) или Reflection Amplification (T1498.002). Проверьте source ports: 53 (DNS), 123 (NTP), 11211 (Memcached) указывают на амплификацию.
- pps растёт, bps умеренный, пакеты мелкие (40-60 байт)? SYN flood (T1499.001). Проверка:
netstat -an | grep SYN_RECV | wc -l- если значение выше 5000, это SYN flood. - bps и pps в норме, но RPS на application растёт, latency деградирует? Application-layer flood (T1499.002/003). Смотрите access logs на однотипные запросы и подозрительные user-agent строки.
- Минимальный трафик, но соединения висят долго? Slowloris или R.U.D.Y. (T1499.003). Число established-соединений и среднее время жизни connection - значения выше 120 секунд при нормальных 5-10 указывают на slow-rate атаку.
| Severity | Критерии | Реакция |
|---|---|---|
| SEV-3 (Low) | Трафик до 2x baseline, нет влияния на latency | Мониторинг, фиксация в тикете |
| SEV-2 (Medium) | Трафик 2-10x baseline, latency деградировал на 50%+ | Активация pre-authorized мер, bridge call |
| SEV-1 (Critical) | Трафик более 10x baseline или сервис недоступен | Немедленная эскалация, все руки на палубу |
Фаза 2 - Containment и DDoS Mitigation Steps (5-30 минут)
NIST CSF 2.0, функция Respond (RS.AN-01): "Notifications from detection systems are investigated.""Проводится расследование уведомлений от систем обнаружения." На этом этапе параллельно работают SOC (проверяет lateral movement под прикрытием DDoS) и NOC (митигирует атаку).Decision tree: выбор стратегии по типу атаки
| Условие | Действие | Инструмент |
|---|---|---|
| Volumetric превышает полосу аплинка | Активировать upstream scrubbing | Звонок провайдеру / API scrubbing-сервиса |
| Volumetric, source IP в узком диапазоне | ACL на edge-маршрутизаторе | ip access-list extended DDOS-BLOCK (Cisco) |
| Reflection Amplification (UDP, source port 53/123/11211) | RTBH + фильтрация по source port | BGP community blackhole + ACL deny UDP eq 53/123 |
| SYN flood | SYN cookies + connection rate limiting | sysctl -w net.ipv4.tcp_syncookies=1 (GNU/Linux) |
| Application-layer flood | WAF rate limiting + bot detection | nginx limit_req_zone / Cloudflare Rate Limiting |
| Slowloris / R.U.D.Y. | Сократить таймауты, ограничить connections per IP | nginx: client_header_timeout 5s; client_body_timeout 5s; |
| Мультивекторная атака | Комбинация: scrubbing для L3/L4 + WAF для L7 | Параллельная активация обоих уровней |
BGP RTBH - когда применять и когда нет
RTBH (Remote Triggered Black Hole) - радикальная мера для DDoS защиты предприятия. По сути, ампутация: вы анонсируете маршрут к атакуемому IP с BGP community, которое провайдер интерпретирует как "дропнуть весь трафик к этому хосту на своём edge". Трафик не доходит до вашей сети - но и легитимный тоже.
Код:
! Cisco IOS-XE - настройка RTBH trigger
ip route 198.51.100.1 255.255.255.255 Null0 tag 666
route-map BLACKHOLE permit 10
match tag 666
set community 65535:666 ! Well-known BLACKHOLE (RFC 7999); замените на community вашего провайдера при необходимости
set origin igp
router bgp 64500
redistribute static route-map BLACKHOLE
neighbor 203.0.113.1 send-communityКогда RTBH - ошибка: атака на единственный production IP при отсутствии failover. В этом случае RTBH выполняет работу атакующего за него. Альтернатива - BGP Flowspec (RFC 8955), позволяющий фильтровать по 5-tuple, но его поддержка зависит от провайдера.
Параллельная задача SOC: проверка на дымовую завесу
Пока NOC разгребает трафик, SOC-аналитик обязан проверить: нет ли аномальных логинов в AD/VPN/облачные консоли за последние 30 минут; нет ли нетипичных DNS-запросов (возможный C2-канал); нет ли аномалий в объёме исходящего трафика (возможная exfiltration).Запрос в Splunk для проверки аномальных RDP-логинов (LogonType=10) параллельно с DDoS. Для VPN и облачных консолей нужны отдельные запросы по соответствующим sourcetype (
sourcetype=cisco:asa для VPN, sourcetype=aws:cloudtrail eventName=ConsoleLogin для AWS):
Код:
index=auth sourcetype=WinEventLog:Security EventCode=4624
LogonType=10
| where _time > relative_time(now(), "-30m")
| stats count by src_ip, user
| where count > 5
| sort -countФаза 3 - Стабилизация и восстановление (30 минут - 2 часа)
NIST CSF 2.0, функция Recover (RC.CO-01): управление коммуникациями. Но сначала - подтверждение, что митигация вообще работает.Мониторинг эффективности каждые 2 минуты: если после активации scrubbing latency не вернулся к baseline за 10 минут - scrubbing-центр пропускает часть атакующего трафика или режет легитимный. Если packets dropped на edge растёт, а latency не падает - ACL не покрывает весь вектор. Error rate на application (5xx) должен быть менее 1%.
Порядок снятия ограничений (каждый шаг - 15 минут мониторинга перед следующим):
- Уменьшить geo-block: добавлять по одному региону
- Повысить rate limit на WAF до 150% от нормы
- Снять экстренные ACL
- RTBH снимать последним, с готовностью вернуть за 30 секунд
Post-mortem DDoS анализ
Post-mortem проводится в течение 48 часов после инцидента, пока детали свежи. Формат - blameless: цель не наказать, а улучшить процесс.
Шаблон отчёта
Timeline - с точностью до минуты: начало аномального трафика (по логам мониторинга), первый алерт, подтверждение атаки дежурным, активация первой контрмеры, стабилизация сервиса, окончание атаки, снятие всех экстренных мер.Ключевые метрики:
- Time to Detect (TTD): от начала аномалии до первого алерта. Цель: менее 2 минут для volumetric, менее 5 минут для application-layer
- Time to Respond (TTR): от алерта до первой контрмеры
- Time to Mitigate (TTM): от первой контрмеры до стабилизации. Цель: менее 15 минут при наличии scrubbing-контракта
- Total Downtime: суммарное время недоступности сервиса
- False positive rate: процент заблокированного легитимного трафика scrubbing-центром
Метрики для трекинга между инцидентами
Отслеживайте поквартально: Mean TTD, Mean TTM, процент автоматически митигированных атак (сколько scrubbing или WAF погасили без участия человека), число ложных срабатываний (алерты, классифицированные как DDoS, оказавшиеся легитимным пиком).Чеклист DDoS Incident Response
Часть DDoS playbook'ов, с которыми приходилось работать, содержат одну системную ошибку: они описывают реагирование на чистый тип атаки - volumetric или application-layer. На практике за последние два года каждый серьёзный инцидент, в котором я участвовал, был мультивекторным. Атакующий начинает с UDP amplification на 30-40 Гбит/с, команда бросается на scrubbing, а через 8-10 минут подключается HTTP flood на конкретный API endpoint, который scrubbing-центр пропускает как легитимный трафик. План реагирования на DDoS, написанный под один вектор, ломается именно в этот момент - и дежурный оказывается без инструкции.
Второе наблюдение: ни один playbook не выживает без учений. Можно написать документ на 50 страниц, но если дежурный ни разу не набирал руками BGP community для RTBH и не звонил провайдеру в три ночи на тестовом сценарии - в реальной атаке он будет листать инструкцию, теряя минуты. Tabletop-учения раз в квартал - не формальность, а единственный способ убедиться, что люди помнят последовательность. В одном SOC удалось сократить TTM с 23 до 9 минут после серии из трёх учений с нарастающей сложностью: чистый volumetric, затем мультивектор, затем DDoS + credential stuffing параллельно.
И последнее - про RTBH. Каждый раз, когда в playbook'е написано "при атаке включить blackhole" без упоминания flowspec, selective scrubbing или anycast - автор этого playbook'а не терял production-сервис из-за собственного blackhole. Контракт со scrubbing-провайдером за 50-150 тысяч рублей в месяц кажется расходом - до первого часа простоя, который для среднего e-commerce обходится в разы дороже. Если хотите отработать эту цепочку на практике - на HackerLab (https://hackerlab.pro) есть лаба с мультивекторным DDoS-сценарием, где можно потренироваться без риска уронить production.
Последнее редактирование модератором:
