Обнаружение DNS-туннелирования в корпоративной сети: индикаторы скрытых каналов передачи данных и противодействие на уровне резолверов

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

Однако DNS-протокол редко хорошо контролируется. Именно поэтому особый риск для компаний представляет DNS-туннелирование. Оно может использоваться для эксфильтрации данных, связи зараженных узлов с управляющей инфраструктурой и обхода сетевых ограничений. Ключевая задача для команд ИБ – научиться выявлять аномалии на уровне запросов, поведения клиентов и контекста обращения к доменам.

Механика DNS-туннелирования

Механизм DNS-туннелирования представляет собой инкапсуляцию произвольных данных в поля стандартных DNS-запросов и ответов. Передаваемая информация разбивается на фрагменты, кодируется и встраивается в поддомены целевого доменного имени.

Примером такого туннеля является запрос на следующий домен: «JBSWY3DPK5XXE3DE.skydns.ru», где «JBSWY3DPK5XXE3DE» – это закодированный в Base32 текст «HelloWorld», а «skydns.ru» – целевое доменное имя.

Сформированный запрос направляется на локальный рекурсивный резолвер. Поскольку трафик на 53-й порт разрешен межсетевыми экранами, пакет проходит через периметр сети без дополнительной фильтрации и проверки.

Далее рекурсивный сервер обрабатывает запрос, как и любой другой DNS-запрос, последовательно передавая его через корневые узлы и серверы доменов верхнего уровня до авторитативного сервера целевой зоны. На этом этапе сервер извлекает закодированные данные из структуры поддомена, выполняет их обработку и формирует ответ. Обратная информация помещается в поля DNS-ответа, чаще всего в TXT-, CNAME- или MX-записи, после чего возвращается по тому же маршруту к исходному клиенту. Клиент декодирует полученный пакет, завершая цикл обмена данными.

Легитимность использования DNS-туннелей

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

Со временем этот подход вышел за рамки узкоспециализированных сценариев и стал частью архитектуры многих массовых сервисов. Например, продукты Microsoft активно используют механизмы туннелирования для обеспечения устойчивой работы собственного ПО. Аналогичные принципы лежат в основе маршрутизации в некоторых распределенных CDN. Сервисы доставки контента используют структуру поддоменов в запросах для динамического определения оптимальной точки присутствия с учётом геолокации пользователя, типа устройства и состояния кэша.

Нестандартным применением DNS-туннелей является использование технологии VoWiFi (Voice over Wi‑Fi): для снижения нагрузки на вышки сотовой связи и обеспечения телефонии в тех случаях, когда связь недоступна. В таких случаях операторы мобильной связи используют DNS-запросы для автоматического обнаружения ближайшего шлюза в своей инфраструктуре. Телефон отправляет специальный запрос к домену оператора, получает адрес сервера, который обрабатывает вызов, и устанавливает защищенное соединение для передачи голоса. Поскольку DNS-трафик разрешён практически везде, звонок работает даже в корпоративных сетях со строгими правилами. Для пользователя весь этот процесс происходит незаметно: он просто нажимает кнопку вызова, а сеть сама подбирает оптимальный маршрут через доступный канал.

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

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

Методы DNS-туннелирования, используемые злоумышленниками

Технология DNS-туннелирования, как и любая другая технология, не стоит на месте и постоянно развивается. Вектор развития определяют поставленные к технологии требования, и для различных задач постоянно используются разные методы, направленные на повышение эффективности передачи данных и усложнение обнаружения. Разберем некоторые из таких методов:

• Маркировка поддоменов. Базовый подход, при котором злоумышленники создают ряд поддоменов во вредоносном домене и кодируют данные в этих поддоменах. Каждый поддомен может содержать часть скрытой информации. Он часто используется в сочетании с другими методами скрытой передачи данных.
  
• Манипуляция DNS-запросами. Злоумышленники изменяют легитимные DNS-запросы, чтобы включить в них данные, не относящиеся к DNS, используя различные методы кодирования. DNS-ответ сервера содержит скрытые данные. Этот метод используется, когда злоумышленники хотят замаскировать свое общение под обычные DNS-запросы и ответы.
  
• Кодирование Base64. Данные кодируются с использованием Base64, схемы кодирования двоичного кода в текст, чтобы сделать их совместимыми с метками поддоменов DNS, которые принимают буквенно-цифровые символы и дефисы. Кодировка Base64 обычно используется в туннелировании DNS для представления данных, не относящихся к DNS, в метках поддоменов DNS, поскольку она обеспечивает эффективное кодирование и декодирование.
  
• Шестнадцатеричное кодирование. Данные преобразуются в шестнадцатеричный формат, а затем встраиваются в метки поддоменов DNS. В этом методе кодирования используются числа от 0 до 9 и символы от A до F. Шестнадцатеричная кодировка используется, когда злоумышленникам необходимо работать с двоичными данными, так как она позволяет представить двоичную информацию в DNS-трафике.
  
• Двоичное кодирование. Данные напрямую преобразуются в двоичный формат и вставляются в метки поддоменов DNS, где 0 и 1 представляют информацию. Двоичное кодирование используется, когда злоумышленники хотят свести процесс кодирования к минимуму и работать с максимально компактным представлением данных.
  
• DNS-туннелирование с высокой и низкой пропускной способностью. Этот метод характеризуется значительным изменением объема DNS-трафика в один конкретный домен или несколько доменов. Длина DNS-запросов к доменам увеличивается, а время между запросами сокращается. Подобно DNS-туннелированию с высокой пропускной способностью, этот метод использует протокол DNS для передачи данных, которые не связаны с DNS-запросом. Однако он предназначен для более медленной передачи данных и может дольше оставаться незамеченным, чем туннелирование с высокой пропускной способностью.
  
• Законные DNS-серверы. Злоумышленники могут скомпрометировать или злоупотребить законными DNS-серверами для туннелирования. Они используют эти серверы для управления скрытой связью, используя доверие, связанное с установленной инфраструктурой DNS. Такой подход может помочь злоумышленникам избежать обнаружения, замаскировав свои действия среди законного DNS-трафика.
  
• Туннелирование IP-over-DNS. Поверх протокола DNS эмулируется полноценный сетевой стек. Клиентское приложение создает виртуальный сетевой интерфейс, перехватывает исходящие IP-пакеты, инкапсулирует их в тело DNS-запросов и отправляет через стандартный резолвер. На стороне авторитативного сервера пакеты извлекаются, декодируются и маршрутизируются дальше во внутреннюю сеть злоумышленника.

Индикаторы канала передачи данных

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

Анализ трафика

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

• Множество уникальных FQDN (Fully Qualified Domain Name) к одному домену. Большинство туннельных утилит и схем с генерацией доменов (DGA) создают большое количество поддоменов в рамках одной зоны. Если вы видите сотни запросов к доменам «xyz123.malware.com», «abc456.malware.com» — это повод для проверки. Для снижения ложных срабатываний рекомендуется исключать из анализа известные легитимные сервисы с динамической генерацией поддоменов (CDN, антивирусы, облачные платформы).
  
• Аномальная частота запросов. Туннели часто характеризуются либо «всплесками» запросов к одному домену (активная передача данных), либо стабильными интервалами между обращениями (beaconing/heartbeat-паттерн для поддержания C2-канала). В отличие от хаотичного пользовательского трафика, такая регулярность выглядит подозрительно.
  
• Частые ответы NXDOMAIN. Запросы к несуществующим поддоменам могут указывать на работу туннеля или DGA. Однако признак требует комбинации с другими: некоторые инструменты настраивают сервер на возврат NOERROR даже для сгенерированных имён.
  
• Объём трафика и размер пакетов. Протокол DNS имеет ограничения на размер пакета (512 байт без расширений, до 4096 с EDNS0). Злоумышленники стремятся максимизировать полезную нагрузку, поэтому запросы в туннеле часто достигают предельных размеров. Мониторинг объема трафика к конкретному домену за единицу времени помогает выявить аномалии.

Анализ содержимого

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

• Длина и вложенность доменного имени. Легитимные домены обычно короткие (12-15 символов) и имеют 2-4 уровня вложенности. Запросы с общей длиной более 50 символов или глубиной более чем 4-5 уровней (a.b.c.d.e.example.com) требуют внимания.
  
• Высокая энтропия строки. Доменные имена, созданные для передачи данных, часто кодируются и демонстрируют равномерное распределение символов. Если расчёт энтропии Шеннона больше либо равен 3.5-4.0 – это служит показателем зашифрованных данных. Важно исключать из проверки легитимные сервисы, использующие сгенерированные имена (например, некоторые CDN).
  
• Признаки кодирования. Ограничения DNS протокола (разрешены a-z, 0-9, -) сужают набор используемых кодировок. Наиболее распространены Base32 и модифицированный Base64 (где /, +, = заменены на -, _ или удалены). Статистический анализ соотношения букв, цифр и спецсимволов помогает предположить тип кодировки. Также стоит проверять наличие префикса xn-- (Punycode): если после декодирования получается нечитаемый текст с высокой энтропией — это повод для углубленного анализа.
  
• Нестандартные типы записей. Массовое использование записей TXT, NULL, KEY, CNAME вместо привычных A/AAAA может указывать на попытку увеличить ёмкость канала. Особенно подозрительны запросы, начинающиеся сразу с TXT/NULL без предварительного резолвинга через A-запись.
  
• Низкие значения TTL. В легитимных сценариях DNS-записи кэшируются (минимальный TTL у крупных провайдеров – примерно 300 секунд). В туннелях часто встречаются значения 0-60 секунд, чтобы избежать кэширования и скрыть следы. Признак эффективен в комбинации с другими, но требует исключения сервисов, намеренно использующих короткий TTL.
  
• Дисбаланс размера запроса и ответа. При эксфильтрации данных запрос часто содержит больше информации, чем ответ (который может быть просто подтверждением). Соотношение размера запроса к ответу более чем в 1,5 раза может служить дополнительным сигналом.

Контекстный анализ

Контекстный анализ помогает оценивать DNS-запросы не изолированно, а в связке с инфраструктурой, историей домена, поведением конкретного узла и профилем активности организации. На этом уровне туннелирование можно выявить по следующим признакам:

• Репутация инфраструктуры. Злоумышленники часто повторно используют одни и те же NS-серверы, хостинг-провайдеров или автономные системы (ASN) для разных туннельных доменов. Сопоставление подозрительных зон с базами угроз (Threat Intelligence) помогает выявлять такие связи.
  
• Аномальный порядок типов запросов. В нормальной работе домена существует предсказуемая последовательность: сначала резолвинг через A/AAAA, затем, при необходимости, CNAME или MX. Запросы, начинающиеся сразу с TXT/NULL, могут указывать на туннель.
  
• Одиночные DNS-запросы. В обычном сценарии за резолвингом следует установление соединения (HTTP, SMTP и др.). Если после получения IP-адреса из DNS-ответа никаких дальнейших подключений не происходит — запрос можно считать одиночным. Массовое появление таких запросов характерно для туннелей, где DNS выступает единственным транспортом.
  
• Географические аномалии. Если запросы от инфраструктуры компании направляются к авторитетным серверам в регионах, где бизнес не ведёт деятельность, это может указывать на компрометацию. Требует ведения профиля «нормального» трафика для конкретной организации.
  
• История домена. Недавно зарегистрированные домены (NRD), частая смена NS-записей или регистратора — признаки, характерные для временной инфраструктуры атак. Интеграция с пассивными DNS-базами и WHOIS-данными позволяет обогащать детекцию.
  
• Активность вне рабочих часов. Если хост, обычно неактивный ночью или в выходные, начинает генерировать регулярный DNS-трафик — это аномалия. Профилирование типичной активности по сегментам сети повышает точность обнаружения.

Эффективная система детекции не полагается на один слой анализа. Комбинация поведенческих, структурных и контекстных индикаторов, настроенная под специфику инфраструктуры и дополненная исключениями для легитимных сервисов, позволяет минимизировать ложные срабатывания и своевременно выявлять попытки скрытой передачи данных.

Противодействие туннелированию на уровне резолвера

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

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

Развертывание подобной аналитики на собственных серверах вполне реализуемо, однако её поддержка требует выделенных мощностей и постоянного участия ИТ-команды. В таких случаях можно рассмотреть облачные сервисы DNS-фильтрации как способ перенести эти задачи на сторону провайдера. Однако полностью полагаться только на локальный или облачный резолвер не стоит. Это важный, но всё же один из нескольких эшелонов обороны. Он работает по-настоящему эффективно только в связке с мониторингом конечных точек, анализом сетевого трафика и грамотным управлением доступом.

Автор: Андрей Корепов, младший специалист по информационной безопасности SkyDNS.