DDoS Incident Response Playbook: пошаговый план реагирования для SOC и NOC — от детекции до post-mortem

Три часа ночи, 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 playbook для SOC превращается в набор рефлексов без стратегии. Дежурный, который видит только трафик, не видит полной картины.

Классификация DDoS-атак через MITRE ATT&CK​

Правильная классификация в первые минуты определяет стратегию митигации. Ошиблись с типом - потеряли время на бесполезные контрмеры.


Отдельно - 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-соединений на балансировщик

Пороги алертинга: baseline + 3 стандартных отклонения для volumetric, +200% для RPS. Для e-commerce с сезонными пиками (Black Friday, распродажи) множитель - x5 от среднегодового значения; пороги пересчитываются за неделю до ожидаемого пика.

Trade-off таблица: инструменты DDoS mitigation​

Матрица коммуникаций​

Роли, не имена. Контактный лист - отдельный документ с ограниченным доступом, обновляется ежеквартально.

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 атаку.

Шаг 3: Определение severity (3-5 мин).

Фаза 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: выбор стратегии по типу атаки​

BGP RTBH - когда применять и когда нет​

RTBH (Remote Triggered Black Hole) - радикальная мера для DDoS защиты предприятия. По сути, ампутация: вы анонсируете маршрут к атакуемому IP с BGP community, которое провайдер интерпретирует как "дропнуть весь трафик к этому хосту на своём edge". Трафик не доходит до вашей сети - но и легитимный тоже.
Когда RTBH оправдан: атака более 100 Гбит/с, один целевой IP, нет scrubbing-контракта, провайдер не поддерживает flowspec. Потерять один сервис лучше, чем всю сеть.

Когда 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):
Если одновременно с DDoS обнаружена аномальная аутентификация - severity повышается до SEV-1, инцидент переклассифицируется в "комплексная атака" с подключением отдельного DDoS response plan NOC для трафиковой части и IR-процесса для intrusion.

Фаза 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 минут мониторинга перед следующим):

1. Уменьшить geo-block: добавлять по одному региону
2. Повысить rate limit на WAF до 150% от нормы
3. Снять экстренные ACL
4. 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-центром

Характеристики атаки: пиковый объём (bps/pps), тип и вектор (MITRE ATT&CK ID), гео-распределение source IP, характеристики ботнета (IoT, серверы, резидентные прокси), amplification-фактор.

Метрики для трекинга между инцидентами​

Отслеживайте поквартально: 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.