Как вы построили бы управление инцидентами DDoS атаки (runbook)?

Question

Accepted Answer

Runbook для DDoS превращает панику в чек-лист. Его основной принцип: **подготовиться до атаки, а не во время неё** — аккаунты подготовлены, контакты известны, и панели мониторинга собраны, так что ответ — это выполнение, а не импровизация.

## Подготовка заранее

- Имейте **уже интегрированного CDN/провайдера скрабинга** (DNS указывает через него, режим "под атакой", который вы можете активировать).
- Сохраняйте **базовые панели мониторинга и алерты** для трафика, частоты ошибок и коэффициента попадания кэша, чтобы аномалии выявлялись быстро.
- Заранее напишите **правила WAF и уровни rate-limit**, которые вы можете усилить мгновенно.
- Ведите **список контактов**: дежурный, поддержка CDN/ISP, лидерство, и готовый **шаблон страницы статуса**.

## Шаги runbook

1. **Обнаружение и объявление** — алерт или коррелированная аномалия (см. DDoS detection) запускает инцидент. Назначьте командира инцидента немедленно.
2. **Определение типа и цели атаки** — это Layer 3/4 (объёмная) или Layer 7 (HTTP flood)? Какая конечная точка, IP или регион? Тип определяет, какие средства контроля вы задействуете.
3. **Включение защиты** — включите режим CDN "под атакой" / скрабинг, **ужесточите правила WAF** и **снизьте rate limits**. Начните с самых дешёвых и широких средств контроля.
4. **Блокировка / null-route источников** — блокируйте нарушающие IP-диапазоны или геолокации на краю сети; в крайнем случае попросите ISP **null-route** целевой IP, чтобы спасти остаток платформы.
5. **Коммуникация** — опубликуйте на **странице статуса**, обновите заинтересованные стороны и ведите временную шкалу. Ясная коммуникация предотвращает второй кризис путаницы.
6. **Масштабирование при необходимости** — автомасштабируйте или переподготавливайте пропускную способность origin для поглощения трафика, который проходит через фильтры, пока они ужесточаются.
7. **Post-incident review** — после стабилизации проведите безвинную ретроспективу: что сработало, что было медленным, какие правила сделать постоянными и какие пробелы закрыть.

```text
DETECT -> IDENTIFY -> ENGAGE (CDN/WAF/rate-limit) -> BLOCK/null-route
       -> COMMUNICATE -> SCALE -> POST-INCIDENT REVIEW
```

## Почему это важно

При реальной атаке задержка и адреналин заставляют людей пропускать шаги и ухудшать ситуацию. Runbook дает известную последовательность, заранее построенные инструменты и чёткие роли, так что команда смягчает ситуацию за минуты вместо того, чтобы спорить о вариантах, пока сайт отключен. Наиболее ценная строка в любом DDoS runbook — это подготовка, выполненная заранее — вы не можете интегрировать провайдера скрабинга или найти номер экстренной помощи ISP, пока вас заливают.