Защита от DNS-tunneling в корпоративной сети: как мониторить и блокировать подозрительные запросы

DNS-tunneling опасен тем, что выглядит как обычная сетевая активность. Пользователь открывает сайт, приложение обращается к API, система обновляется — и всё это сопровождается DNS-запросами. Проблема начинается там, где DNS перестают использовать как способ найти адрес и начинают использовать как канал передачи данных: выгрузки файлов, обхода блокировок, управления вредоносным ПО.

В корпоративной сети задача не в том, чтобы «запретить DNS». Это невозможно без поломки работы сервисов. Задача практичнее: видеть аномалии в DNS-трафике, быстро отделять странные запросы от легитимных и иметь понятный механизм блокировки без хаоса.

Что именно нужно защищать

DNS-tunneling обычно строят вокруг домена, который контролирует злоумышленник. Вместо обычного запроса вида:

update.example.com

в логах появляются длинные и странные имена:

aGVsbG8td29ybGQtdGVzdC1kYXRhLTAxMjM0NTY3ODk.evil.example

В поддомен могут кодировать данные, команды, фрагменты файлов. Ответы тоже могут быть нестандартными: TXT-записи, длинные CNAME, необычные A/AAAA, частые обращения к одному домену с разными поддоменами.

Для защиты нужно держать под контролем три вещи:

• какие клиенты куда обращаются;
• как выглядят сами DNS-запросы;
• что делать, если запрос подозрительный.

Если хотя бы один из этих пунктов не закрыт, защита будет неполной. Можно поставить фильтр, но не видеть обходные каналы. Можно собирать логи, но не иметь правила блокировки. Можно блокировать домены по спискам, но пропустить новый туннель на неизвестном домене.

Где ловить DNS-трафик

Первое решение — не «какой продукт купить», а где проходит DNS в вашей сети. В идеале все корпоративные клиенты должны резолвить имена через управляемые DNS-серверы или защищённые forwarder’ы. Тогда вы видите запросы централизованно и можете применять политики.

На практике часто встречаются четыре схемы.

Схема	Что видно	Что можно сделать	Главный риск
Клиенты используют корпоративный DNS	Домены, типы запросов, клиентов, время, ответы	Фильтровать, логировать, блокировать по RPZ/политикам, строить отчёты	Обход через DoH/DoT или ручной DNS
DNS проходит через firewall	Куда уходят UDP/TCP 53, иногда имена при инспекции	Разрешить DNS только на свои резолверы, блокировать внешние 53-й порт	Зашифрованный DNS не всегда раскрывает содержимое запросов
Логи снимаются с EDR/NDR	Процессы, хосты, подозрительные связи, корреляции	Связать DNS-аномалию с конкретным процессом или пользователем	Без DNS-инфраструктуры сложнее управлять блокировкой
Логи разрознены: DNS, proxy, firewall, DHCP	Частичная картина по каждому источнику	Свести данные по IP, MAC, DHCP lease, пользователю	Много шума и задержки при расследовании

Если сеть уже зрелая, лучший вариант — централизованный DNS с логированием и политиками, плюс запрет прямого DNS наружу. Если инфраструктура старая, начните с простого: собрать логи с существующих DNS-серверов, понять, кто и куда обращается, затем постепенно ограничивать обходные маршруты.

Какие признаки выдают DNS-tunneling

Один признак редко доказывает проблему. В DNS-tunneling смотрят на сочетание поведения. Например, длинное имя само по себе не всегда опасно: бывают CDN, сервисы телеметрии, специфичные SaaS. Но длинное имя, высокая частота запросов, много NXDOMAIN и один и тот же клиент — уже повод разбираться.

Практически я бы смотрел на такие сигналы.

• Длина доменного имени. Ненормально длинные qname, особенно с большим количеством символов в поддомене.
• Высокая энтропия. Строки вида x7k2p9q1m4 чаще встречаются в туннелях, чем в обычных бизнес-запросах.
• Много уникальных поддоменов одного базового домена. Например, тысячи обращений к *.strange-domain.example за короткий период.
• Необычные типы записей. TXT, NULL, CNAME, длинные ответы. TXT не запрещать автоматически: у него есть легитимные сценарии, но аномалии здесь частые.
• Высокий процент NXDOMAIN. Если клиент массово генерирует несуществующие имена, это подозрительно.
• Регулярный ритм. Запросы идут каждые несколько секунд или минут, как heartbeat.
• Большой объём DNS-трафика на одном хосте. Обычно DNS компактен. Если хост внезапно «говорит» через DNS слишком много, это сигнал.
• Клиент обращается к неизвестному внешнему DNS. Особенно если этот DNS не разрешён политикой.
• Запросы идут от серверов, где DNS не должен быть активен. Базы, файловые хранилища, производственные системы часто не должны самостоятельно резолвить случайные домены.

Хорошее правило: не искать «один идеальный индикатор». Ищите поведение, которое не похоже на нормальную работу клиента или сервиса.

Что логировать, чтобы потом было что анализировать

Если в логах только домен и IP клиента, расследование будет мучительным. Для мониторинга DNS-tunneling желательно собирать минимум такой набор полей:

• время запроса;
• IP-адрес клиента;
• имя пользователя или привязку к DHCP lease;
• полное доменное имя запроса;
• тип запроса: A, AAAA, TXT, CNAME, MX и т.д.;
• ответ DNS-сервера;
• код ответа: NOERROR, NXDOMAIN, SERVFAIL;
• время ответа;
• размер запроса и ответа;
• DNS-сервер, который обработал запрос;
• флаг рекурсии и источник запроса, если доступен.

Особенно полезны размер запроса и ответа. В туннелях часто пытаются протолкнуть больше данных, чем в обычном DNS. Также помогает корреляция с DHCP: IP сам по себе ничего не говорит, а связка «IP → пользователь → устройство → VLAN» уже даёт направление для проверки.

Как строить мониторинг без бесконечного шума

Главная ошибка при запуске мониторинга — сразу включить жёсткие правила и получить десятки алертов в день. Лучше идти поэтапно.

1. Соберите базовую картину на 1–2 недели. Посмотрите, кто генерирует больше всего DNS-запросов, какие домены чаще всего возвращают NXDOMAIN, какие типы запросов встречаются редко.
2. Исключите известные легитимные системы. Системы мониторинга, антивирусы, обновления, CDN, сервисы облачной инфраструктуры могут выглядеть странно, но быть нормой для вашей среды.
3. Сделайте несколько мягких правил. Например: много уникальных поддоменов одного домена, необычно длинные имена, высокий NXDOMAIN, нестандартные типы запросов.
4. Проверьте алерты вручную. На старте лучше разбирать подозрительные случаи руками, чтобы понять реальные пороги.
5. После настройки добавьте автоматические действия. Сначала — только алерт. Потом — sinkhole для явных случаев. Затем — блокировка или изоляция при подтверждении.

Пороги лучше задавать не «как в интернете», а по вашей среде. Для маленькой компании 500 запросов к одному домену за час могут быть аномалией. Для крупного офиса с обновлениями и SaaS это может быть обычным делом.

Какие правила блокировки работают на практике

Блокировка должна быть не только «по чёрному списку». Чёрные списки полезны, но они ловят уже известное. DNS-tunneling часто поднимают на новых доменах, поэтому нужны правила по поведению.

Тип блокировки	Когда использовать	Плюсы	Минусы
Блокировка домена по списку	Есть подтверждённый вредоносный домен	Быстро, понятно, легко объяснить	Не ловит новые домены
RPZ / response policy zones	Нужно централизованно перенаправлять или блокировать DNS-ответы	Удобно для DNS-инфраструктуры, можно быстро распространять правила	Требует аккуратного управления и тестирования
Sinkhole для подозрительного домена	Есть признаки туннеля, но нужно не терять клиента из виду	Позволяет остановить связь и сохранить логи обращений	Нужно правильно оформить ответы, чтобы не сломать легитимные сервисы
Ограничение типов запросов	На части сетей TXT/NULL почти не нужны	Снижает риск скрытой передачи данных	Может сломать отдельные легитимные механизмы
Rate limiting	Клиент делает слишком много запросов к одному домену	Хорошо против автоматизированных туннелей	Есть риск false positive, если порог выбран грубо
Блокировка внешнего DNS	Политика требует идти только через корпоративный резолвер	Закрывает простой обход	Нужно отдельно разбирать DoH/DoT и исключения

Я бы не начинал с жёсткого запрета TXT или rate limiting на всей сети. Сначала — мониторинг, затем точечные политики для сегментов, где такие ограничения безопасны.

Как блокировать, чтобы не потерять расследование

Если вы просто отбрасываете подозрительный запрос, злоумышленник может заметить обрыв связи и сменить домен. Иногда полезнее направить запрос на sinkhole — внутренний адрес, где можно продолжить сбор логов и понять, какой процесс или хост пытается установить связь.

Практичный порядок такой:

1. Получили алерт по подозрительному домену.
2. Проверили, кто обращается: хост, пользователь, VLAN, время начала активности.
3. Посмотрели объём запросов, типы записей, ответы, динамику по времени.
4. Сверили домен с репутационными источниками и внутренними исключениями.
5. Если подозрение высокое — отправили домен в sinkhole или заблокировали через RPZ.
6. Проверили, не повторяются ли обращения после блокировки.
7. Если активность продолжается — изолировали хост и начали разбираться с процессами, задачами, автозагрузкой, сетевыми соединениями.

Блокировка без расследования закрывает симптом. Иногда этого достаточно для остановки утечки, но не всегда достаточно для очистки сети.

Что делать с DoH и DoT

Зашифрованный DNS усложняет защиту. Пользователь или вредоносный процесс может обойти корпоративный DNS и уйти напрямую к публичному резолверу. В логах firewall это может выглядеть как обычное HTTPS-соединение, а содержимое DNS-запросов вы не увидите.

Подход зависит от зрелости сети:

• если у вас нет контроля над клиентами, начните с запрета DNS наружу кроме разрешённых DNS-серверов;
• если есть EDR, отслеживайте процессы, которые используют DoH/DoT;
• если используется браузерный DoH, управляйте политиками через групповые политики или MDM;
• если есть proxy/SSL inspection, продумайте, где и как вы будете контролировать зашифрованный DNS;
• если сеть чувствительная, вводите запрет публичных DoH/DoT-резолверов, но заранее тестируйте бизнес-сервисы.

Не стоит блокировать DoH «вслепую» для всей компании. В некоторых средах это ломает обновления, браузеры, приложения или удалённую работу. Но оставлять его полностью бесконтрольным — тоже плохая идея.

Как понять, что это действительно туннель, а не просто странный сервис

Перед блокировкой полезно ответить на несколько вопросов:

• Этот домен связан с известным бизнес-сервисом?
• Клиент раньше обращался к этому домену или активность появилась внезапно?
• Есть ли связь с конкретным процессом?
• Сколько уникальных поддоменов было создано?
• Есть ли регулярность запросов?
• Какие типы DNS-записей используются?
• Есть ли большой объём данных в ответах?
• Пытается ли хост обращаться к другим подозрительным доменам?

Если домен принадлежит крупному облачному провайдеру, решение сложнее. Там могут быть и легитимные сервисы, и вредоносная инфраструктура. В таких случаях блокировка всего домена второго уровня может навредить бизнесу. Лучше искать более точные индикаторы: конкретные поддомены, ASN, клиентские процессы, поведенческие аномалии.

Сценарии выбора: как действовать в разных ситуациях

Если у вас малая сеть и нет отдельной SOC-команды, начните с управляемого DNS или DNS-фильтра, который даёт логи и политики. Запретите клиентам уходить на внешний DNS. Настройте 3–5 понятных алертов: длинные имена, много NXDOMAIN, много поддоменов одного домена, необычные типы запросов, резкий рост DNS-трафика.

Если у вас крупная корпоративная сеть, стройте централизованную схему: корпоративные резолверы, RPZ, SIEM, корреляция с DHCP/AD/EDR, отдельные политики по сегментам. Для серверных VLAN правила должны быть строже, чем для пользовательских сетей.

Если у вас уже был инцидент, не начинайте с тонкой настройки мониторинга. Сначала ограничьте подозрительный домен, изолируйте активные хосты, сохраните логи DNS, firewall и EDR, затем разберите цепочку заражения.

Если у вас много ложных срабатываний, не отключайте мониторинг. Разбейте сеть на группы: пользователи, серверы, IoT, гостевая сеть, производственные системы. Для каждой группы пороги будут своими.

Если у вас нет возможности смотреть содержимое DoH/DoT, хотя бы контролируйте, куда уходят соединения на публичные резолверы, и управляйте политиками на конечных устройствах. Это не идеальная замена DNS-логам, но лучше, чем полная слепота.

Частые ошибки при защите от DNS-tunneling

На практике проблемы чаще возникают не из-за отсутствия «волшебного правила», а из-за простых просчётов в инфраструктуре.

• Блокируют DNS наружу, но забывают про DoH/DoT. В итоге обычный порт 53 закрыт, а обходной канал продолжает работать.
• Собирают логи без нормализации. IP есть, а кто пользователь и какое устройство — непонятно.
• Ставят жёсткие пороги без базовой линии. Через день приходят жалобы, что «что-то не работает».
• Блокируют весь домен крупного облачного провайдера. Останавливают туннель, но вместе с ним ломают часть рабочих сервисов.
• Не исключают легитимные системы. Обновления, мониторинг, антивирусы и SaaS могут выглядеть подозрительно, если не знать их поведения.
• Не проверяют серверные сегменты. Сервер с DNS-tunneling часто опаснее обычного ноутбука, потому что у него больше доступов.
• Оставляют только ручную проверку. При большом объёме трафика аналитик быстро утонет в событиях.
• Блокируют и забывают. Если домен заблокирован, но хост продолжает попытки соединения, это уже отдельный сигнал для изоляции.

Практические рекомендации для запуска защиты

Если нужно собрать рабочую схему с нуля, я бы делал так:

1. Направьте весь DNS через контролируемые резолверы. Это основа. Без неё мониторинг будет фрагментарным.
2. Запретите прямой DNS наружу. Разрешите клиентам ходить на DNS только к вашим серверам или approved forwarder’ам.
3. Включите подробное логирование DNS. Минимум: клиент, qname, тип запроса, ответ, код ответа, время, размер.
4. Свяжите DNS с пользователями и устройствами. Интегрируйте с DHCP, AD, MDM или EDR.
5. Настройте базовые алерты. Длинные имена, высокая энтропия, много уникальных поддоменов, высокий NXDOMAIN, необычные типы запросов, резкий рост трафика.
6. Сделайте whitelist аккуратно. Не заносите в исключения всё подряд. Исключение должно быть связано с понятным сервисом и владельцем.
7. Подготовьте механизм блокировки. RPZ, sinkhole, политики DNS-фильтра или firewall — выберите то, что реально обслуживается в вашей команде.
8. Разделите политики по сегментам. Серверам, пользователям, гостевой сети и IoT не нужны одинаковые правила.
9. Регулярно проверяйте ложные срабатывания. Если правило постоянно шумит, его нужно уточнять, а не терпеть.
10. Имейте план реакции. Кто смотрит алерт, кто принимает решение о блокировке, кто изолирует хост, кто сохраняет доказательства.

Минимальный набор правил для старта

Для начала не нужно строить идеальную систему машинного обучения. Достаточно набора правил, которые покрывают самые частые сценарии.

• Алерт на домены с аномально длинными именами.
• Алерт на клиентов с большим числом уникальных поддоменов одного базового домена.
• Алерт на высокий процент NXDOMAIN по одному клиенту.
• Алерт на необычные типы запросов, особенно если раньше этот клиент их не использовал.
• Алерт на резкий рост DNS-запросов к одному домену.
• Алерт на обращение к внешнему DNS вне разрешённого списка.
• Алерт на DNS-активность от серверов, где она не должна быть обычной.

Пороги лучше задавать как «отклонение от нормы для этой группы». Например, для сервера 20 запросов к новому домену может быть странно, а для ноутбука пользователя — нет. Для пользовательской сети 1000 запросов за час могут быть нормой, а для контроллера домена — уже поводом проверить.

Итог: как сделать защиту рабочей

Защита от DNS-tunneling строится не вокруг одного правила, а вокруг управляемого DNS. Если вы видите запросы, понимаете, кто их делает, можете отличить нормальное поведение от аномального и быстро заблокировать подозрительный канал — вы уже закрываете большую часть риска.

Начните с централизованного DNS, полного логирования и запрета обходных резолверов. Затем добавьте поведенческие правила, sinkhole или RPZ для блокировки, корреляцию с пользователями и EDR. Не гонитесь за идеальной точностью с первого дня: сначала соберите базу, отстройте пороги, разберите ложные срабатывания и только потом автоматизируйте жёсткие действия.

Самый практичный путь такой: увидеть DNS-трафик, понять норму для своих сегментов, настроить несколько точных алертов, подготовить блокировку и регулярно проверять, не появился ли новый обходной канал. Именно эта связка даёт реальную защиту, а не просто красивый отчёт о мониторинге.