Post‑mortem атаки на 812 Гбит/с: что мы делали в первые 17 минут

TL;DR

• UDP amplification, пик 812 Гбит/с, источник — порядка 240 тысяч отражателей в 14 странах
• Цель — публичный медиа‑ресурс одного из наших клиентов на тарифе Бизнес
• Auto‑mitigation отреагировал за 38 секунд от начала атаки, конечные пользователи влияния не заметили
• В 4 точках присутствия (MOW‑3, EKB‑1, SPB‑2, KAZ‑1) пришлось вручную поднимать ёмкость канала с upstream‑партнёрами
• Изменили процесс — теперь rebalance запускается автоматически по триггеру утилизации > 70% более 60 секунд

Хронология

02:47:12 — начало

Сигнатура UDP‑amplification на узлах MOW‑1, MOW‑3 и SPB‑2. Стартовый объём — 124 Гбит/с. На графике это выглядит как вертикальная линия: за 8 секунд ушли с фонового 18 Гбит/с до 124. Дежурный SRE получил пуш в Telegram через 6 секунд после первого триггера.

02:47:50 — auto‑mitigation активирован

Сработали правила scrubbing на L3/L4 уровне. Трафик с отражателей (характерные порты 53, 123, 389, 11211) автоматически дропается на ближайшем edge до прохождения в backbone. На клиента — origin — пошло меньше 0.4% входящего объёма.

02:51:30 — пик 812 Гбит/с

Через 4 минуты после начала. К этому моменту в атаку включились серверы из США, Германии, Индии, Бразилии и Беларуси — это видно по AS, через которые шли пакеты. Утилизация каналов в MOW‑3 и EKB‑1 ушла за 80%.

02:53:20 — ручная rebalance

Дежурный SRE инициировал переключение части префиксов через альтернативные транзитные каналы. Внутренний инструмент capacity-shift делает это командой:

$ capacity-shift --prefix 91.247.x.x/24 --from MOW-3 --to MOW-1,SPB-1

Через 90 секунд каналы перебалансировались, утилизация на MOW‑3 упала до 60%.

03:04 — атака начала затихать

К этому моменту с amplifier‑серверов начали приходить меньшие объёмы — вероятно, координирующая сторона переключилась на другие цели. К 03:18 фоновый трафик нормализовался.

Что заметили клиенты

В 95‑м перцентиле клиент потерял доступ к источнику аналитики на 11 секунд — это окно между активацией auto‑mitigation и стабилизацией маршрутов. Конечные пользователи сайта получали ответы из кэша без перебоев. В status‑странице у клиента не появилось ни одного инцидента — мы сами повесили informational note задним числом.

Что мы поменяли

1. Авто‑rebalance по триггеру

Раньше переключение каналов делалось дежурным SRE по ситуации. Теперь — автоматически, если утилизация исходящего интерфейса > 70% более 60 секунд. Логика учитывает текущую загрузку соседних узлов, чтобы не утащить за собой второй сегмент.

2. Расширение сетевой ёмкости

Договорились с двумя дополнительными upstream‑партнёрами в Москве и Санкт‑Петербурге. Доступная единовременная ёмкость на московском кластере выросла с 1.4 до 2.2 Тбит/с.

3. Прозрачность для клиентов

В панели управления у клиентов на тарифе Бизнес теперь есть отдельная вкладка «События безопасности», где видно все срабатывания защиты на их доменах. Раньше это было видно только нам.

Уроки

Главный урок не технический. На стороне клиента в этот момент дежурил один админ. К нему в Telegram пришло уведомление в 02:48: «зафиксирована атака, ваш сайт работает нормально». Утром он узнал из новостей, что несколько других ресурсов в эту ночь лежали несколько часов.

«Я работаю с CDN восемь лет. В первый раз случилась атака такого масштаба и я узнал о ней наутро. Это не норма для индустрии. Это будущее.» — слова клиента в почте на следующий день, цитируем с разрешения.

Готовы рассказывать о таких событиях подробно — потому что доверие строится не на «99.99% SLA» в маркетинге, а на конкретике, которую вы можете проверить.