Утро. Grafana показывает 340 Gbps входящего UDP-трафика на пограничных маршрутизаторах финтех-компании, где полгода назад настраивали эшелонированную защиту. Обычный baseline - 12 Gbps. SOC-дежурный классифицирует NTP reflection/amplification из четырёх ASN, через пару минут переключает трафик на облачный scrubbing-центр. Канал восстановлен спустя ещё 20 минут. А ещё через 20 минут - второй алерт: WAF фиксирует 2400 rps на эндпоинт авторизации. L7-вектор стартовал ровно когда команда разбирала volumetric-инцидент. За 55 минут частичного простоя - незавершённые транзакции на миллионы рублей и postmortem на неделю.
По данным отраслевых отчётов за 2025 год, больше половины DDoS-атак уже многовекторные, а крупнейшие ботнеты насчитывают миллионы IP-адресов. Именно второй вектор - тот, что прилетает, пока все разгребают первый - ломает красивые планы. Ниже - сравнение DDoS mitigation стратегий 2026, корреляционные правила для SIEM и чеклист, чтобы SOC не пропустил этот второй удар.
Бизнес-логика DDoS: зачем атакуют и сколько стоит простой
DDoS (распределённая атака типа «отказ в обслуживании») - техника из тактики Impact в MITRE ATT&CK. Атакующие используют её не только ради того, чтобы «положить сайт». Четыре основных мотива в 2026 году:- Вымогательство (Ransom DDoS) - атака начинается с угрозы, требуется выкуп в криптовалюте. Порог входа снизился за счёт DDoS-as-a-Service платформ: по данным Ideco, к 2024 году появились коммерческие платформы с поддержкой многовекторных атак за несколько сотен долларов. Буквально - подписка дешевле Netflix.
- Дымовая завеса - volumetric-атака отвлекает SOC, пока параллельно идёт эксплуатация уязвимости или эксфильтрация данных. По данным Mandiant M-Trends 2025, эксплойты остаются самым популярным вектором initial access (38% инцидентов), и DDoS нередко маскирует именно этот этап.
- Хактивизм - политически мотивированные атаки на государственные сервисы и критическую инфраструктуру. Согласно IBM X-Force Threat Intelligence Index 2025, 70% зафиксированных инцидентов затронули объекты критической инфраструктуры.
- Конкурентный саботаж - вывод из строя сервисов конкурента в пиковый период. Чёрная пятница, распродажи, запуск нового продукта - классическое окно.
DDoS-техники в терминах MITRE ATT&CK
Для SOC-инженера маппинг DDoS-техник на MITRE ATT&CK - фундамент корреляционных правил и playbook-ов. В матрице ATT&CK DDoS разнесён по двум техникам: Network Denial of Service (T1498, Impact) и Endpoint Denial of Service (T1499, Impact), с подтехниками для конкретных векторов.
| MITRE ATT&CK ID | Название | Тактика | Уровень OSI | Типичный вектор |
|---|---|---|---|---|
| T1498.001 | Direct Network Flood | Impact | L3/L4 | SYN flood, UDP flood, ICMP flood |
| T1498.002 | Reflection Amplification | Impact | L3/L4 | NTP, DNS, CLDAP, SSDP amplification |
| T1499.001 | OS Exhaustion Flood | Impact | L4 | TCP state table exhaustion |
| T1499.002 | Service Exhaustion Flood | Impact | L4/L7 | SSL/TLS renegotiation flood |
| T1499.003 | Application Exhaustion Flood | Impact | L7 | HTTP slowloris, API abuse, heavy queries |
| T1583.005 | Botnet | Resource Development | - | Создание или аренда ботнета для атаки |
T1583.005 (Botnet) - тактика Resource Development, подготовительный этап на стороне атакующего. Для защитника он невидим (ботнет собирают не у вас). Зато видно другое - зондирующие запросы: короткие burst-ы разного типа трафика на разные порты. Это фаза рекогносцировки, маппится на T1595 (Active Scanning, тактика Reconnaissance). По отраслевым данным, число таких зондирующих атак в 2024–2025 годах заметно выросло. SOC, который фиксирует зондирование и поднимает порог готовности заранее, получает критическое преимущество во времени реакции. Разница между "увидели за 3 минуты" и "увидели за 30 секунд" - это разница между простоем и штатной отработкой.
Многовекторная атака из постмортема в начале статьи - комбинация T1498.002 (NTP reflection) на L3/L4 и T1499.003 (Application Exhaustion Flood) на L7. Если SIEM настроен на корреляцию этих двух техник как единого инцидента, время реакции сокращается кратно.
DDoS mitigation стратегии: сравнение подходов 2026
Критерии отбора
Русскоязычный рынок уже располагает детальным DDoS protection сравнением сервисов по 180 критериям (anti-malware.ru, 2026). Здесь задача другая: сравнить архитектурные стратегии противодействия DDoS на уровне сети, потому что именно выбор стратегии определяет класс решений. Не "какой вендор лучше", а "какой подход подходит под вашу архитектуру".Четыре подхода: облачный traffic scrubbing, on-premise appliance, гибрид по модели "три слоя" (detection + on-network filtering + upstream/edge scrubbing, как описывает Kentik), и BGP blackholing как аварийная мера.
В категории облачного scrubbing на российском рынке: DDoS-Guard, StormWall, CURATOR.ANTIDDOS (Qrator), Kaspersky DDoS Protection, Garda Anti-DDoS. В on-premise сегменте: Arbor Sightline/TMS (NETSCOUT), Radware DefensePro, F5 BIG-IP AFM. Cloudflare Magic Transit и AWS Shield Advanced доступны, но с оговорками по локализации данных.
Trade-off: облачная защита vs on-premise vs гибрид
| Критерий | Cloud Scrubbing | On-premise Appliance | Гибрид (3-layer) | BGP Blackholing |
|---|---|---|---|---|
| Ёмкость mitigation | Десятки Tbps | Ограничена каналом (1–100 Gbps) | Комбинированная | Зависит от upstream |
| Добавленная задержка | 5–30 мс (зависит от PoP) | Менее 1 мс (inline) | Варьируется по слоям | Минимальная |
| L7 inspection | Да (требует TLS-сертификат) | Да (полный контроль) | Да | Нет |
| Время активации | 3–10 сек (auto) | Мгновенно (inline) | 3–10 сек | 1–5 мин |
| Модель стоимости | Подписка per-Mbps или фиксированная | CAPEX + годовая поддержка | Оба компонента | Включена в BGP peering |
| Контроль над трафиком | Ограничен | Полный | Полный | Нулевой (drop all) |
| Ключевое ограничение | Зависимость от вендора, TLS-инспекция у третьей стороны | Бесполезен при volumetric > ёмкости канала | Сложность интеграции двух слоёв | Блокирует ВЕСЬ трафик на IP |
On-premise appliance захлебнётся при volumetric-атаке, превышающей ёмкость канала. Arbor за несколько сотен тысяч долларов бесполезен при 500 Gbps на 10 Gbps канале - арифметика беспощадна. BGP blackholing формально "работает", но атакующий добивается цели: легитимный трафик тоже заблокирован. Облачный scrubbing зависит от вендора - если его scrubbing-центр перегружен или мисконфигурирован, вы это не контролируете. У каждого подхода есть дыра, и честность в этом - первый шаг к нормальной архитектуре.
Поведенческая детекция (behavioral-based mitigation), описанная Radware, строится на отклонениях от нормальных паттернов трафика - не статические пороги, а ML-модель, обученная на baseline конкретного клиента. Такие модели встроены в Radware DefensePro и Arbor Sightline. У облачных провайдеров behavioral detection работает на стороне scrubbing-центра: вы получаете результат, но не управляете моделью. В одном из проектов это стало проблемой - модель на стороне провайдера начала резать легитимный трафик после изменения паттернов из-за маркетинговой кампании.
Отдельная головная боль для автоматических систем - pulse wave DDoS: серия коротких мощных всплесков с паузами. Каждый burst может не достигать порога auto-detection, но суммарная нагрузка выводит сервис из строя. По данным Ideco, pulse wave набирает популярность с 2025 года. Классический rate limiting тут не спасает - нужна аналитика по скользящему окну.
Когда какой подход выбрать
- Канал менее 10 Gbps, бюджет ограничен - облачная защита от DDoS закрывает volumetric-вектор без капитальных затрат. Для большинства веб-проектов этого хватает за глаза.
- Latency критична (финтех, VoIP, гейминг) - гибрид: on-premise inline-фильтрация + cloud scrubbing как failover при volumetric > ёмкости канала. Дороже, но 5–30 мс добавленной задержки для HFT-платформы - недопустимо.
- Volumetric превышает канал, облачного scrubbing нет - BGP blackholing / RTBH на отдельные IP через upstream. Крайняя мера: атакующий фактически добился отказа в обслуживании для этого IP. Но хотя бы остальная инфраструктура жива.
- Нужна полная видимость L7 - on-premise appliance или WAF с DDoS-модулем. Облачные решения видят L7 только если им передан TLS-сертификат - а это значит, что третья сторона расшифровывает ваш трафик.
Detection при DDoS: WAF и DDoS-защита в SIEM
Большинство инструментов защиты от DDoS работают на уровне сети. Но SOC-команда должна видеть DDoS-инцидент в SIEM - не только факт атаки, а контекст: параллельные события, аномалии на L7, попытки эксплуатации под шумок. WAF и DDoS-защита работают в связке, и SIEM - точка их пересечения.Минимальный набор источников для DDoS-корреляции:
- NetFlow/sFlow с пограничных маршрутизаторов - объём, пакеты, порты, ASN источников
- Логи WAF - rate per endpoint, HTTP-коды ответов, geoIP
- Логи firewall - dropped connections, state table exhaustion
- Алерты анти-DDoS - если используется облачный или on-premise scrubbing
Псевдокод правила для детекции reflection/amplification (не валидный Sigma - адаптировать condition под конкретный SIEM: EQL для Elastic, KQL для Sentinel, CorrLang для MaxPatrol SIEM, Sigma v2 correlation block):
YAML:
# Пример для демонстрации концепции - адаптировать пороги под baseline
title: DDoS Reflection Amplification Suspected
logsource:
category: netflow
detection:
selection:
dst_port: [53, 123, 389, 1900, 11211]
condition: >
selection AND
sum(bytes_in) over 5m > baseline_avg_5m * 10
level: high
tags:
- attack.impact
- attack.t1498.002baseline_avg_5m * 10 - десятикратное превышение среднего за 5 минут - отправная точка. Калибруйте под свой профиль трафика: у стримингового сервиса и корпоративного портала baseline отличается на порядки.Корреляция: DDoS как дымовая завеса
Критическое правило: если volumetric DDoS-алерт (T1498) совпадает по времени с любым из событий ниже - это P1, без вариантов:- Аномальный рост failed login attempts на VPN/SSH
- Новый IP в административной панели
- Нехарактерные SQL-запросы от application-сервера
- Алерт от EDR (CrowdStrike Falcon, SentinelOne, Kaspersky EDR Expert) на хостах в DMZ
Во время инцидента полезно обогащать source-IP через AbuseIPDB (API endpoint
/api/v2/check). Рекомендуемый порог - abuseConfidenceScore > 75. Бесплатная квота: 1000 запросов в сутки - при массированном DDoS этого мало, но для проверки Top-100 IP по объёму трафика хватит. Категории #4 (DDoS Attack) и #17 (Spoofing) - два маркера, на которые стоит смотреть. Трафик из известных bulletproof-хостингов (Datacamp и аналогичные ASN) - дополнительный сигнал для фильтрации.Чеклист: как защититься от DDoS-атаки на уровне сети
Нумерованный чеклист для сетевого инженера или включения в отчёт по аудиту.Требования к окружению: GNU/Linux-сервер с nftables (ядро 4.14+), доступ к конфигурации пограничного маршрутизатора (BGP-сессии), настроенный сбор NetFlow/sFlow в SIEM.
- Внедрить BCP38/BCP84 фильтрацию на границе сети - блокировать исходящий трафик с поддельными source-адресами. По данным NIST, развёртывание anti-spoofing - цикл: конфигурация, анализ производительности, мониторинг и верификация. Для edge-сети: uRPF strict mode (
ip verify unicast source reachable-via rxна Cisco IOS). - Настроить rate limiting на nftables для защиты от volumetric атак:
Bash:
# nftables: rate limiting SYN flood + UDP amplification
nft add table inet ddos_filter
nft add chain inet ddos_filter input \
'{ type filter hook input priority 0; }'
nft add rule inet ddos_filter input \
tcp flags syn limit rate over 100/second burst 50 packets drop
nft add rule inet ddos_filter input \
udp dport '{ 53, 123, 1900 }' \
limit rate over 500/second burst 200 packets dropПротиводействие DDoS изнутри периметра: скомпрометированные хосты
Все описанные стратегии работают против внешнего трафика. Но есть сценарий, который облачный scrubbing не закроет: DDoS изнутри сети. И вот тут начинается самое интересное.
Если атакующий получил foothold (через эксплойт, фишинг или скомпрометированную учётную запись - по данным Mandiant M-Trends 2025, 57% организаций узнают об инциденте от внешней стороны), внутренние хосты используются для:
- Горизонтальный DDoS - перегрузка внутренних сервисов (AD, DNS, DHCP) трафиком от легитимных машин. Облачный scrubbing не видит этот трафик - он не проходит через периметр. Ваш Qrator или DDoS-Guard здесь бесполезен.
- Ботнет-нода - скомпрометированный хост участвует в DDoS-атаке на внешнюю цель (T1583.005, Resource Development). Организация невольно становится соучастником, исходящий трафик забивает uplink.
- Low-and-slow L7 - медленные запросы к внутренним API от легитимных учётных записей. Rate limiting по IP бесполезен: source - ваш собственный сервер. Slowloris изнутри - это боль, потому что все фильтры заточены под внешний трафик.
- Baseline исходящего трафика по каждому VLAN - аномальный рост outbound UDP с рабочих станций = немедленный алерт. Рабочая станция бухгалтера, генерирующая 500 Mbps UDP - это не баг, это инцидент.
- Корреляция с EDR - если CrowdStrike Falcon, SentinelOne или Kaspersky EDR Expert фиксирует подозрительный процесс, а из того же VLAN одновременно идёт аномальный трафик - это P1.
- DNS-аналитика - внутренний хост, резолвящий сотни уникальных доменов за минуту, скорее всего получает команды от C2 для участия в ботнете.
Заключение
Большинство компаний покупают облачный анти-DDoS, ставят галочку в compliance-чеклисте и считают задачу закрытой. За последние три года я разбирал postmortem-ы после DDoS-инцидентов у десятка организаций с "полной защитой" - и в большинстве случаев проблема была не в мощности scrubbing-а.Проблема - в процессах. SOC не тренируется на DDoS-сценарии, потому что "это задача сетевиков". Сетевики не заглядывают в SIEM, потому что "это задача SOC". Playbook на DDoS существует в виде PDF на SharePoint, который никто не открывал с момента написания. Когда приходит L7-вектор - все смотрят друг на друга.
Многовекторные атаки станут нормой. Доля многовекторных атак, по отраслевым оценкам, уже превышает половину. К 2027 году одновекторный DDoS останется уделом скрипт-кидди. Стратегия "купить облачный scrubbing и забыть" перестаёт работать. Нужны внутренние корреляционные правила, протестированные playbook-и и SOC, который отличает дымовую завесу от реальной цели атаки.
Единственное, что реально меняет готовность - регулярные dry-run: симуляция DDoS-инцидента, замер time-to-detect и time-to-mitigate, разбор по ролям. Не PDF на SharePoint, а четырёхчасовая тренировка с секундомером. Если строите или обновляете DDoS-playbook для своей команды - на codeby.net коллеги ведут тред с разбором конкретных многовекторных кейсов и адаптацией Sigma-правил под российские SIEM-стеки и scrubbing-провайдеры.
Последнее редактирование модератором:
