UDP flood на 180 Гбит/с обрушивается на primary-ЦОД финтех-компании - входящий трафик превышает baseline в 40 раз. Дежурный инженер NOC лезет в wiki за инструкцией, набирает команду активации scrubbing-центра вручную. BGP-анонс уходит, конвергенция глобальной таблицы маршрутизации - 4 минуты, стабилизация GRE-туннеля - ещё 2. За эти 6 минут платёжный шлюз лежит, а месячный SLA-бюджет (99.95% uptime = ~22 минуты даунтайма) сгорает на четверть.
Post-mortem показал: anycast-сеть из 20 PoP распределила бы атаку автоматически - по 9 Гбит/с на точку, inline scrubbing за 3 мс, без единого BGP-изменения. Разница между "сервис лежит" и "строчка в логах" - не бюджет на железо, а архитектурное решение, принятое задолго до атаки.
Бизнес-логика DDoS-атаки: TTPs по MITRE ATT&CK и что должен видеть SOC
Прежде чем строить DDoS-устойчивую инфраструктуру, разберём, как атака выглядит через призму TTPs - без этого корреляционные правила и детекция будут кривыми.Подготовительная фаза. Атакующий собирает IP-адреса целевой инфраструктуры - IP Addresses (T1590.005, Reconnaissance) - и формирует или арендует ботнет - Botnet (T1583.005, Resource Development). По данным Terrazone, ботнеты уровня Aisuru в 2025 году насчитывали от 1 до 4 миллионов заражённых устройств, а DDoS-for-hire платформы снизили порог входа до нескольких сотен долларов и Telegram-аккаунта. Заказать DDoS сейчас проще, чем настроить от него защиту.
Ударная фаза - Impact по классификации MITRE ATT&CK. Каждый тип требует собственного слоя защиты, и путать их - типичная ошибка:
- Direct Network Flood (T1498.001) - volumetric: UDP flood, ICMP flood. Цель - забить канал. По данным Terrazone, объёмы достигали 31,4 Тбит/с в конце 2025 года.
- Reflection Amplification (T1498.002) - атаки через DNS, NTP, Memcached с коэффициентом усиления. Источник - открытые рекурсивные DNS-серверы и misconfigured Memcached, которых в интернете до сих пор хватает.
- Service Exhaustion Flood (T1499.002) - SYN flood, исчерпание таблиц состояний на stateful firewall и балансировщиках. Тут не канал забивают, а убивают connection tracking.
- Application Exhaustion Flood (T1499.003) - HTTP flood, Slowloris, API abuse. Каждый запрос выглядит легитимно, но жрёт непропорционально много ресурсов бэкенда.
Атакующие не дураки: пока один вектор отвлекает NOC, второй пробивает другой слой.
DDoS как отвлекающий манёвр - красный флаг для SOC. Пока все разгребают входящий трафик, атакующие могут тащить данные или закрепляться через скомпрометированные хосты внутри периметра. Аномальный исходящий трафик с внутренних серверов во время DDoS - сигнал, который надо отрабатывать параллельно с митигацией, а не после. По OWASP A09:2021 (Security Logging and Monitoring Failures), организации, у которых логирование деградирует под нагрузкой DDoS, пропускают именно этот вектор. Я видел такое в каждом третьем разборе.
Финансовый импакт - конкретные цифры. По данным Terrazone, средняя стоимость DDoS-инцидента: $52 000 для SMB и $444 000 для enterprise. И это без репутационного ущерба и регуляторных штрафов.
DDoS-устойчивая инфраструктура: anycast, scrubbing и гибридная архитектура
BGP Anycast: геометрическое преимущество против объёма
В anycast-топологии один и тот же IP-префикс анонсируется с нескольких Points of Presence (PoP) одновременно. Входящий трафик - и легитимный, и атакующий - маршрутизируется к ближайшему PoP по BGP shortest-path selection.Преимущество тут геометрическое: объём атаки делится на N точек. По данным Haltdos, атака в 2 Тбит/с на anycast-сеть из 30 PoP приземляется примерно по 67 Гбит/с на каждую точку - в пределах scrubbing-ёмкости одной площадки. Грубо говоря, чем больше PoP - тем меньше каждому достаётся.
Latency при anycast определяется inline-scrubbing пайплайном PoP. На ASIC-ускоренных платформах - 1-4 мс. При начале атаки PoP фильтрует без BGP-изменений, без tunnel establishment, без convergence wait. Чистый трафик выходит из ближайшего к пользователю PoP.
Ограничение: плотность PoP. Сеть из 5 PoP - это аргумент про ёмкость, но не про latency. По оценке Haltdos, anycast-провайдер с менее чем 15 PoP не даёт реального распределения атаки. При оценке провайдера смотрите количество PoP в вашем регионе и тип scrubbing - ASIC-based (hardware-accelerated) или software-based (с существенно меньшей пропускной способностью per-PoP). Разница между ними - порядок magnitude.
Ограничение: L7-атаки. Anycast-PoP на L3/L4-фильтрации с sampled NetFlow (sampling 1:1000 или 1:2000) на интерфейсах 10 Гбит/с+ имеет статистический detection floor. Низкобандвидтовые HTTP floods на sub-Gbps уровне проходят незамеченными 60–120 секунд, пока плотность flow-записей не достигнет порога. Для L7-атак нужна WAF-интеграция - anycast тут слеп.
Центр очистки трафика: принцип работы и скрытая цена BGP-диверсии
В модели on-demand scrubbing трафик в штатном режиме идёт напрямую к origin. При обнаружении атаки - по telemetry клиента или мониторингу провайдера - BGP-анонсы модифицируются, весь входящий трафик перенаправляется в scrubbing-центр. Очищенный трафик туннелируется обратно к origin через GRE или MPLS.Ёмкость тут реальная: один scrubbing-центр тянет 10-20 Тбит/с чистой пропускной способности. Для гипер-объёмных атак, направленных на один префикс, это критично.
А вот скрытая цена - latency spike в момент активации. BGP-конвергенция - это propagation новых анонсов, сходимость глобальной таблицы, установление GRE-туннеля, стабилизация маршрутов. По моделированию Haltdos для enterprise-сценария (атака 10 Гбит/с, origin в одном регионе, scrubbing в соседнем, tier-2 BGP transit), полный цикл detection + diversion + stabilization занимает 3-10 минут. Для real-time приложений (VoIP, торговые платформы, платёжные шлюзы) с требованием RTT <20 мс - latency SLA нарушается даже после начала митигации, в окне стабилизации.
Те самые 6 минут из postmortem в начале - это и есть эта цена.
Decision matrix: anycast vs scrubbing vs гибрид
Зрелые production-инсталляции стекируют оба подхода, распределяя ответственность по классам атак.| Критерий | Anycast (always-on) | On-demand scrubbing | Гибрид |
|---|---|---|---|
| Latency в штатном режиме | 1-4 мс | 0 мс (трафик напрямую) | 1-4 мс |
| Latency при атаке | 1-4 мс | +3-10 мин (BGP-конвергенция) | 1-4 мс, <60 сек для эскалации |
| Scrubbing capacity per site | Total / N PoP | 10-20 Тбит/с | Комбинированная |
| Время активации | 0 сек (inline) | 3-10 мин | 0 сек для типовых атак |
| Детекция L7-атак | Ограничена (sampling) | Ограничена (telemetry) | WAF-слой |
| Стоимость | Высокая (always-on) | Ниже (on-demand) | Определяется конфигурацией |
Гибридная архитектура на практике:
- Anycast PoP - inline ASIC-фильтрация volumetric L3/L4-атак. Без BGP-изменений, без latency spike.
- Scrubbing-центр - в резерве для гипер-объёмных событий, превышающих per-PoP capacity. Активация через pre-configured BGP communities (не реактивная flow-triggered диверсия) - convergence time менее 60 секунд.
- WAF - закрывает L7: HTTP flood, API abuse, Slowloris - всё, что ниже volumetric detection threshold.
- GSLB - health-check и перенаправление трафика от PoP/регионов с остаточной деградацией.
Rate limiting от DDoS: пороги без ложных срабатываний
Rate limiting защищает прикладной уровень, когда volumetric-фильтрация уже отработала. Неправильный порог ломает легитимных пользователей раньше, чем останавливает атаку - я видел, как компания сама себе устроила DoS, выставив лимит в 5 r/s на эндпоинт, через который ходил мобильный клиент.
Sliding window vs fixed window. Fixed window (100 запросов в минуту) создаёт boundary burst: атакующий отправляет 100 запросов в последнюю секунду одного окна и 100 в первую секунду следующего - 200 запросов за 2 секунды. Sliding window через Redis sorted sets устраняет эту дыру:
Python:
# Sliding window rate limiter (Redis sorted sets)
# Источник: адаптация из easecloud.io
def check_rate_limit(client_id, limit=100, window=60):
r = redis.Redis()
now = time.time()
key = f"rate:{client_id}"
pipe = r.pipeline()
pipe.zremrangebyscore(key, 0, now - window)
pipe.zadd(key, {str(now): now})
pipe.zcard(key)
pipe.expire(key, window)
return pipe.execute()[2] <= limitlimit_req_zone $binary_remote_addr zone=api:10m rate=10r/s с burst=20 nodelay - 10 запросов в секунду с возможностью кратковременного burst до 20. Аутентифицированные пользователи получают повышенный лимит через отдельную zone.Ответ на превышение: HTTP 429 с заголовками
Retry-After, X-RateLimit-Remaining, X-RateLimit-Reset. Корректно написанные клиенты (и продвинутые ботнеты с human-like поведением) будут соблюдать Retry-After, снижая нагрузку.Ограничение: rate limiter на application-уровне (nginx, HAProxy, Kubernetes Ingress) работает только если volumetric-атака уже отфильтрована на edge. При 100 Гбит/с UDP flood ваш nginx не увидит ни одного HTTP-запроса - канал забит до него. Rate limiting - последний рубеж, не первый. Без edge-фильтрации полагаться на него бессмысленно.
Автоматическое отражение DDoS: от детекции до blackhole за секунды
Ручная активация scrubbing - это те самые 6 минут из начала статьи. Инженер увидел алерт, полез в wiki, набрал команду, ошибся, перенабрал. Автоматизация сокращает время реагирования до секунд, но требует калибровки: false positive приводит к самоналоженному DoS.Fastnetmon - open-source детектор DDoS-аномалий по NetFlow/sFlow/IPFIX (последний релиз - активно поддерживается, GitHub 3.5k+ звёздочек). Вычисляет baseline (packets per second, bits per second, flows per second) для каждого /32 и при превышении порога в N раз (обычно 3–5x) запускает action. Требования: GNU/Linux (Ubuntu 22.04+/Debian 12+), 4+ CPU cores, 8 ГБ RAM, коммутаторы с поддержкой NetFlow v9 или sFlow.
Варианты action при срабатывании:
- RTBH (Remotely Triggered Black Hole) - анонс атакуемого /32 через BGP community с next-hop blackhole на upstream-роутере. На Juniper:
routing-options static route X.X.X.X/32 discard, на Cisco:ip route X.X.X.X 255.255.255.255 Null0. IP становится недоступен, но остальная инфраструктура живёт. Жёсткий вариант - когда IP можно временно пожертвовать. - BGP FlowSpec - гранулярная фильтрация: drop только UDP на порт 53 с определённого source, оставляя TCP. Поддерживается не всеми upstream-провайдерами - проверяйте заранее, а не в момент атаки.
- Webhook в scrubbing API - автоматическая активация перенаправления через API провайдера, без ручного вмешательства.
Prometheus alerting - раннее предупреждение до срабатывания основной автоматики:
YAML:
# Prometheus: раннее обнаружение DDoS-аномалии
- alert: DDoSTrafficAnomaly
expr: >
rate(node_network_receive_bytes_total[5m])
> 2 * avg_over_time(
node_network_receive_bytes_total[7d])
for: 2m
labels:
severity: warning
annotations:
summary: "Входящий трафик >2x baseline"Detection-чеклист для SOC при DDoS-инциденте
Чеклист для передачи дежурной смене - конкретные действия и источники данных. Базируется на NIST CSF DE.AE-01 (установление baseline сетевых операций).Большинство организаций вкладываются в scrubbing-ёмкость, которую никогда не используют на полную, и при этом игнорируют detection lag - те самые 3-10 минут BGP-конвергенции, которые реально стоят им uptime. Я видел десятки postmortem'ов, где root cause был не в недостаточной пропускной способности очистки, а в отсутствии автоматизации: инженер увидел алерт, полез в wiki за инструкцией, набрал команду вручную, ошибся, перенабрал. Шесть минут.
Гибридная архитектура - anycast для inline-фильтрации типовых volumetric + scrubbing в резерве для гипер-объёмных аномалий - закрывает 95% сценариев. Но без связки Fastnetmon + RTBH + webhook в scrubbing API эта архитектура - дорогая картинка на слайде.
Отдельный слепой spot - DDoS как прикрытие. Пока все смотрят на входящий трафик, данные утекают по исходящему каналу через скомпрометированный хост, который никто не проверяет в момент инцидента. В каждом третьем разборе, к которому я подключался, этот параллельный вектор не отрабатывался - не потому что его не знали, а потому что playbook не предусматривал корреляцию inbound DDoS + outbound anomaly.
Если настраиваете пороги детекции в Fastnetmon или выстраиваете корреляционные правила DDoS + exfiltration в SIEM - на codeby.net коллеги разбирают рабочие конфигурации и playbook'и по автоматизации реагирования в профильном треде.
Последнее редактирование модератором:
