В октябре 2016 года DNS-провайдер Dyn (сейчас часть Oracle) лёг под мультивекторной атакой Mirai-ботнета. Среди прочего ботнет гнал pseudo-random subdomain запросы (water torture) - скомпрометированные IoT-устройства долбили рекурсоры случайными поддоменами, и те вместе с авторитативными серверами захлебнулись. Twitter(на тот момент), Reddit, GitHub и десятки других сервисов ушли в оффлайн для миллионов пользователей. В России аналитики StormWall фиксируют тот же тренд: с 2020 года DNS water torture и DNS amplification атаки растут, причём одной из заметных целей стала инфраструктура RU-CENTER. По данным IBM X-Force Threat Intelligence Index 2025, 70% расследованных инцидентов затронули организации критической инфраструктуры (энергетика, финансы, здравоохранение, транспорт), и DNS-инфраструктура внутри этих секторов - одна из главных точек отказа. Ниже - разбор механики атак, detection-подходы для SIEM и конкретные конфигурации для защиты DNS-инфраструктуры.
Как water torture убивает кэш рекурсора
DNS water torture (random subdomain attack) эксплуатирует фундаментальное свойство рекурсивного резолвера: если записи нет в кэше, он обязан выполнить полный цикл рекурсивного разрешения - сходить к авторитативному серверу. Атакующий генерирует запросы видаa1b2c3.target.com, x7y8z9.target.com - каждый поддомен уникален, кэш бесполезен.Цепочка деградации:
- Ботнет (T1583.005, Resource Development) шлёт тысячи запросов к несуществующим поддоменам
*.target.comчерез легитимные рекурсоры - ISP-резолверы и корпоративные DNS - Рекурсор не находит записи в кэше и пересылает запрос авторитативному серверу
target.com - Авторитативник отвечает NXDOMAIN - домен не существует
- Рекурсор передаёт NXDOMAIN клиенту, но уже потратил ресурсы на lookup и ожидание ответа
- Параллельные outstanding-запросы забивают очередь рекурсора, таймауты растут, легитимные запросы встают в хвост и начинают дропаться
NXDOMAIN flood - более широкий термин: любая атака с массовым потоком запросов к несуществующим доменам. Water torture - частный случай, при котором запросы нацелены на случайные поддомены конкретного домена-жертвы. Разница в целевом воздействии: чистый NXDOMAIN flood бьёт по рекурсору любыми несуществующими доменами, water torture целится через рекурсор в конкретный авторитативный DNS-сервер.
Скомпрометированные легитимные хосты как источник атаки
Отдельная головная боль - когда источником water torture оказываются скомпрометированные машины внутри корпоративной сети. Внутренние хосты, заражённые вредоносным ПО, генерируют DDoS-атаки на DNS через корпоративный рекурсор, и со стороны периметра трафик выглядит абсолютно легитимным. Для SOC это значит: мониторить нужно не только входящий DNS-трафик, но и аномальную DNS-активность от внутренних клиентов. Рост уникальных QNAME с одного хоста на порядок выше baseline - сигнал компрометации.DNS amplification vs NXDOMAIN flood: TTPs через MITRE ATT&CK
Два основных DDoS-вектора на DNS-инфраструктуру различаются по механике, требуемым ресурсам и методам detection.
DNS amplification (Reflection Amplification, T1498.002, Impact) - объёмная атака. Атакующий шлёт маленький DNS-запрос (ANY или DNSSEC-зона) на открытый рекурсор с подменённым source IP жертвы. Ответ в десятки раз больше запроса - коэффициент усиления достигает 28–54x при ANY-запросах к DNSSEC-зонам (US-CERT TA13-088A). Ирония: DNSSEC - протокол, который разработали для повышения безопасности DNS - увеличивает размер ответов и тем самым делает amplification-атаки жирнее. Ключевой ресурс атакующего - открытые DNS-резолверы, принимающие запросы от любого IP.
Water torture / NXDOMAIN flood (Service Exhaustion Flood, T1499.002; Application Exhaustion Flood, T1499.003, Impact) - атака на уровне приложения. Объём трафика может быть скромным, но каждый запрос заставляет рекурсор выполнить полный цикл резолвинга. Ключевой ресурс - ботнет (T1583.005 / T1584.005, Resource Development) или скомпрометированная инфраструктура. Цель - исчерпать CPU и connection slots DNS-серверов.
| Параметр | DNS Amplification | Water Torture / NXDOMAIN Flood |
|---|---|---|
| MITRE ATT&CK | T1498.002 Reflection Amplification | T1499.002 / T1499.003 Exhaustion Flood |
| Вектор | Open resolver, отражение на жертву | Botnet, через рекурсор к авторитативнику |
| Подмена source IP | Обязательна | Не обязательна |
| Объём трафика | Высокий (десятки Гбит/с) | Относительно низкий |
| Кэш рекурсора | Не задействован | Полностью обходится |
| Основной урон | Канал связи | CPU, memory, connection pool |
| Сложность детекции | Низкая (volume spike) | Высокая (выглядит как легитимный трафик) |
По данным StormWall, в 2025 году DDoS-атаки на DNS входят в ТОП-5 векторов в мире, и на DNS нацелены до трети всех DDoS-атак.
Detection: метрики, корреляция в SIEM и анализ трафика
Для Blue Team критично выстроить baseline сетевых операций (NIST CSF DE.AE-01) до того, как прилетит инцидент. Water torture особенно коварна - NETSCOUT указывает, что её основные признаки: высокая загрузка CPU на DNS-серверах и высокий rate NXDOMAIN-ответов. Но эти метрики нужно правильно собирать и коррелировать.
Ключевые метрики для мониторинга
На рекурсивном резолвере (Unbound, BIND, PowerDNS Recursor):- NXDOMAIN ratio - процент NXDOMAIN-ответов от общего числа. Baseline обычно 5-15%, при water torture поднимается до 60-90%
- Cache hit ratio - процент запросов, обслуженных из кэша. Нормальный baseline для нагруженного рекурсора: 80-95%. При water torture падает ниже 50%
- Outstanding queries - количество одновременных незавершённых рекурсивных запросов. Рост выше baseline на 300%+ - алерт
- Unique QNAME entropy per source IP - если один IP запрашивает десятки уникальных поддоменов одного домена за секунду, это аномалия
Правила корреляции для SIEM
Логика detection-правила (адаптируемая под Elastic SIEM, MaxPatrol SIEM, KUMA):Water torture от внешнего ботнета: за скользящее окно 60 секунд с более чем 10 различных source IP приходят DNS-запросы к поддоменам одного домена второго уровня, при этом более 80% ответов авторитативника - NXDOMAIN. Порог рекурсора: NXDOMAIN ratio > 60% - warning, > 80% - critical.
Скомпрометированный внутренний хост: один внутренний source IP генерирует более 100 DNS-запросов в минуту с уникальными QNAME к одному домену. Это сигнал компрометации - хост может быть частью ботнета, генерирующего water torture.
DNS amplification входящая: объём входящего DNS-трафика (UDP/53) превышает baseline на порядок, множество source IP (отражатели), крупные DNS-ответы (>512 байт), один destination IP.
Пороговые значения зависят от инфраструктуры - прежде чем настраивать алерты, нужен минимум двухнедельный baseline (RS.AN-01 по NIST CSF: расследование начинается с уведомлений от detection-систем, а качество уведомлений определяется качеством baseline).
Анализ pcap при расследовании
При подозрении на water torture - захват трафика:tcpdump -i eth0 port 53 -w dns_capture.pcap. В Wireshark фильтр dns.flags.rcode == 3 покажет все NXDOMAIN-ответы. Если в поле QNAME видны случайные строки перед доменом жертвы ([random_string].target.com) - water torture подтверждена. Утилита dnstop в реальном времени покажет top queried domains и top NXDOMAIN-источники.Митигация DDoS на рекурсивных DNS-резолверах
Рекурсор - первое звено, принимающее удар. Меры защиты DNS-сервера от DDoS делятся на конфигурационные и архитектурные.Конфигурационные меры
Rate limiting по source IP. В Unbound директиваip-ratelimit: 100 ограничивает число запросов с одного IP в секунду. Для корпоративного резолвера нормальный rate от одного хоста - 5-20 qps, при water torture - сотни. В BIND для ограничения входящих рекурсивных запросов используются fetches-per-server и fetches-per-zone; директива rate-limit в BIND - это механизм RRL для исходящих ответов авторитативника.Ограничение: rate limiting по source IP не спасает, когда ботнет использует десятки тысяч уникальных адресов (каждый генерирует по 5-10 qps, в сумме - flood). Нужна комбинация с лимитом по QNAME.
Снижение таймаутов. В Unbound параметр
jostle-timeout (по умолчанию 200 мс) управляет вытеснением старых запросов из очереди. Снижение до 100 мс ускоряет освобождение слотов для легитимных запросов при атаке. Параметр outgoing-num-tcp ограничивает число исходящих TCP-соединений - при water torture рекурсор не должен тратить TCP-ресурсы на запросы к NXDOMAIN.DNS-прокси dnsdist. PowerDNS dnsdist ставится перед рекурсором и фильтрует трафик на основе правил. Пример конфигурации для замедления подозрительных клиентов:
Код:
addAction(
MaxQPSIPRule(50),
DelayAction(500)
)Архитектурные меры
Разделение ролей. Совмещение рекурсивной и авторитативной функций на одном сервере - ошибка, которая до сих пор встречается повсюду. При атаке на одну функцию деградирует и вторая. Разносите по разным хостам - это первое, что нужно сделать.Ограничение доступа. Рекурсор обязан отвечать только на запросы из доверенных сетей. В BIND:
allow-recursion { 10.0.0.0/8; };. В Unbound: access-control: 10.0.0.0/8 allow. Открытый рекурсор - одновременно цель для water torture и оружие для DNS amplification атаки. Если ваш рекурсор торчит наружу без ACL - считайте, что вы уже участвуете в чьей-то атаке.Защита авторитативных DNS-серверов
Авторитативник - конечная цель water torture. Даже если рекурсоры выдерживают нагрузку, тысячи рекурсоров из разных сетей одновременно пересылают ему запросы к случайным поддоменам.Response Rate Limiting (RRL)
RRL - механизм, встроенный в BIND (начиная с 9.9.4), NSD и Knot DNS. Он ограничивает скорость идентичных или похожих ответов для одного destination-prefix. Конфигурация RRL в BIND:
Код:
rate-limit {
responses-per-second 5;
nxdomains-per-second 3;
window 15;
slip 2;
};nxdomains-per-second 3 - не более 3 NXDOMAIN-ответов в секунду на один prefix /24. slip 2 - каждый второй заблокированный ответ отправляется с битом TC (truncated), заставляя легитимного клиента повторить запрос по TCP. Боты, не умеющие TCP, отсекаются.Ограничение RRL: при масштабной water torture с десятков тысяч IP RRL не снимает входящую нагрузку на CPU авторитативника - запросы всё равно обрабатываются, даже если ответы дропаются. RRL хорош против amplification (снижает исходящий трафик), но для water torture нужны дополнительные меры.
Anycast DNS защита
Anycast - архитектурное решение, при котором один IP анонсируется из нескольких географически распределённых точек. Входящий трафик маршрутизируется к ближайшему узлу, и при DDoS-атаке на DNS нагрузка размазывается между всеми anycast-нодами. Для организаций без собственной anycast-инфраструктуры - вторичные DNS-провайдеры с anycast (зоны реплицируются через AXFR/IXFR). При атаке на primary авторитативник secondary anycast-серверы продолжают обслуживать запросы.RPZ как DNS-файрвол
Response Policy Zones позволяют рекурсору блокировать запросы на основе policy-фидов. В контексте DDoS RPZ не защищает авторитативник напрямую, но помогает рекурсору не стать инструментом атаки: запросы к известным вредоносным доменам из RPZ-фида блокируются до отправки к авторитативнику. Это пересекается с задачей детекта DNS-туннелирования (T1071.004, Command and Control) - те же RPZ-фиды содержат домены C2-серверов.Чеклист: hardening DNS-инфраструктуры
Готовый перечень для передачи сетевой команде или включения в отчёт по аудиту безопасности DNS-инфраструктуры:По опыту аудитов DNS-инфраструктуры - пункты 1-3 не выполнены в большинстве организаций среднего размера, и именно они дают максимальный эффект при минимальных затратах. Пункты 4-9 требуют более глубокой настройки, но без них детектировать water torture до момента деградации сервиса практически невозможно. Защита DNS-сервера от DDoS работает как эшелонированная оборона: каждый слой снижает нагрузку на следующий, и ни один из них сам по себе не достаточен.
Тренд, который я вижу последние два года: water torture всё чаще комбинируется с DNS amplification в одной кампании. Первая фаза - amplification забивает канал, вторая - water torture добивает рекурсоры, которые переключились на резервные линки. К такому сценарию с двойным вектором мало кто готов, потому что митигация amplification (фильтрация по объёму) и митигация water torture (фильтрация по поведению) - разные наборы правил, разные пороги и зачастую разные точки фильтрации. Организации, которые закрывают только один вектор, остаются открыты ко второму. Выстраивать detection для обоих сценариев с baseline-метриками и правилами корреляции - не рекомендация, а необходимость. Если в вашем SIEM пока нет правил для DNS-аномалий, на codeby.net (Форум информационной безопасности - Codeby.net) есть тематический тред с playbook'ом по DNS DDoS detection - конфигурации dnsdist, пороги алертов и разбор реальных инцидентов.
Последнее редактирование модератором:
