РАЗБОР Статья

DNS-туннелирование. Как обнаружить скрытую передачу данных в сетевом трафике.

Qwerty Pirogov Script Kiddie · 13 сообщений

35 Сегодня в 15:00

[ обложка статьи ]

Режим чтения

Введение

DNS (Domain Name System) обычно воспринимается как служба преобразования доменных имён в IP-адреса. Когда пользователь открывает сайт, компьютер обращается к DNS-серверу, получает соответствующий IP-адрес и устанавливает соединение с нужным ресурсом. Этот процесс происходит практически незаметно и является неотъемлемой частью работы любой IP-сети.

Однако DNS может использоваться не только для разрешения доменных имён. Особенности протокола позволяют передавать через DNS-запросы и ответы произвольные данные. Такой подход получил название DNS-туннелирования (DNS Tunneling).

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

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

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

1. Как работает DNS и почему его используют для туннелирования

DNS работает на прикладном уровне модели OSI. В традиционном сценарии клиент отправляет запрос DNS-серверу, указывая доменное имя и тип необходимой записи. Сервер возвращает соответствующий ответ.

Например, при обращении к example.com клиент может отправить запрос типа A, чтобы получить IPv4-адрес домена. Для IPv6 применяется запись AAAA.

Наиболее распространённым транспортом DNS является UDP с портом 53. TCP также используется, например, при передаче больших ответов, некоторых операциях между DNS-серверами и в других предусмотренных протоколом сценариях.

Ключевая особенность заключается в том, что DNS-запрос содержит имя, сформированное из отдельных меток (labels). Каждая метка может иметь длину до 63 октетов, а полное доменное имя в DNS-представлении ограничено 255 октетами.

Это создаёт возможность размещать данные непосредственно внутри поддомена.

Рассмотрим условный пример:

aGVsbG8td29ybGQ.example.com

Последовательность aGVsbG8td29ybGQ может представлять собой закодированную строку hello-world. В обычной ситуации DNS-сервер интерпретирует её как часть доменного имени. Однако специальный сервер, контролирующий домен, может извлечь эту последовательность и обработать её как переданные данные.

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

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

Важно учитывать: DNS сам по себе не обеспечивает конфиденциальность содержимого запросов. Кодирование данных, например Base32 или Base64, не является шифрованием. Оно лишь изменяет представление информации.

2. Архитектура DNS-туннеля

Типичная схема DNS-туннелирования включает три основных компонента:

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

Условная последовательность взаимодействия выглядит следующим образом:

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

Для обратного направления передачи данных могут использоваться TXT-записи или другие типы DNS-ответов.

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

Такая архитектура позволяет организовать удалённое управление устройством без использования традиционного соединения с управляющим сервером по HTTP или HTTPS.

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

3. Какие задачи решает злоумышленник с помощью DNS-туннелирования

DNS-туннелирование может использоваться на разных этапах атаки. Его назначение зависит от целей злоумышленника и возможностей скомпрометированного устройства.
3.1. Обход сетевых ограничений
В корпоративных сетях исходящий трафик часто ограничивается правилами межсетевых экранов. При этом DNS-запросы обычно разрешены, поскольку необходимы для работы инфраструктуры.
Если организация не контролирует, куда именно устройства отправляют DNS-запросы, злоумышленник может попытаться использовать разрешённый канал для передачи данных.
Сам факт разрешённого DNS-трафика не означает, что через него можно беспрепятственно организовать туннель. На практике результат зависит от конфигурации резолверов, сетевых фильтров и DNS-инфраструктуры.
3.2. Вывод информации из внутренней сети
Один из наиболее опасных сценариев связан с эксфильтрацией данных.
Предположим, что злоумышленник получил доступ к рабочей станции и обнаружил на ней конфиденциальные документы. Если прямое соединение с внешним сервером блокируется, DNS может рассматриваться как альтернативный канал передачи.

Файлы предварительно обрабатываются, разбиваются на фрагменты и передаются через последовательность DNS-запросов.

При этом необходимо учитывать ограничения DNS на размер имён и сообщений. Поэтому передача крупных объёмов информации требует большого количества запросов и может создавать заметные аномалии.

3.3. Удалённое управление
DNS-туннель может использоваться для передачи команд с управляющего сервера на заражённое устройство.

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

Такой механизм способен выполнять роль канала Command and Control (C2), который в терминологии MITRE ATT&CK соответствует технике T1071.004 DNS.

3.4. Сохранение канала связи

DNS-туннелирование также может применяться для поддержания связи с устройством после первоначального проникновения.

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

Поэтому при расследовании инцидента важно анализировать не только момент первоначального появления подозрительных запросов, но и их динамику на протяжении всего периода компрометации.

4. Признаки DNS-туннелирования в сетевом трафике

Обнаружение DNS-туннеля осложняется тем, что отдельный подозрительный запрос не всегда свидетельствует об атаке. Некоторые легитимные приложения используют длинные доменные имена, большое количество запросов и нестандартные типы записей.
Поэтому анализ должен строиться на совокупности признаков.
4.1. Необычно длинные доменные имена
Один из первых признаков заключается в увеличенной длине поддоменов.
Обычные DNS-запросы часто содержат относительно короткие и понятные имена. При туннелировании в них могут присутствовать длинные последовательности символов, представляющие закодированные данные.
Например:
aGVsbG93b3JsZDEyMzQ1.example.net

MFRGGZDFMZTWQ2LK.example.net

Сами по себе такие строки не доказывают наличие туннеля. Однако регулярное появление длинных меток, особенно с высокой вариативностью, требует дополнительной проверки.

4.2. Высокая энтропия поддоменов
Энтропия позволяет оценить степень непредсказуемости последовательности символов.

Для DNS-аналитики этот показатель полезен при поиске доменов, в которых поддомены содержат случайные или закодированные последовательности.
Например, имена:

mail.company.ru

portal.company.ru

имеют понятную структуру.

В то же время:

7GQ4M2XK9P8L3D5.example.net

выглядит значительно менее естественно.

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

fragment001.example.net;
fragment002.example.net;
fragment003.example.net;
fragment004.example.net.

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

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

Такая активность может свидетельствовать о работе автоматизированного клиента.

4.5. Использование нестандартных типов записей

В обычной сетевой активности часто встречаются запросы A и AAAA.

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

TXT-записи особенно интересны для анализа, поскольку позволяют передавать текстовые данные в ответах DNS.

Однако использование TXT само по себе не является признаком атаки. Такие записи применяются для SPF, проверки доменов и других легитимных задач.

4.6. Необычное соотношение запросов и ответов

При анализе стоит учитывать не только количество запросов, но и размер DNS-сообщений.

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

Обратная ситуация также заслуживает внимания, особенно если ответы содержат необычно длинные TXT-значения.

5. Практический анализ DNS-трафика в Wireshark

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

Шаг 1. Выделение DNS-трафика
После открытия PCAP-файла в Wireshark используем фильтр:

dns

Он позволит оставить в рабочем окне только DNS-пакеты.

Для дополнительного ограничения можно использовать:

udp.port == 53 || tcp.port == 53

На этом этапе необходимо определить:

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

Особое внимание следует уделить устройствам, которые обращаются к одному внешнему домену с большим количеством различных поддоменов.
Шаг 2. Анализ длинных DNS-имён

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

dns.qry.name

Сам по себе этот фильтр отображает все DNS-запросы. Для оценки длины имён удобнее экспортировать данные в CSV и выполнить дополнительную обработку.

Например, можно использовать Python и библиотеку Scapy.

Код:

from scapy.all import rdpcap, DNS, DNSQR
from collections import Counter

packets = rdpcap("dns_traffic.pcap")

domains = []

for packet in packets:
    if packet.haslayer(DNS) and packet.haslayer(DNSQR):
        name = packet[DNSQR].qname.decode(
            errors="ignore"
        ).rstrip(".")

        domains.append(name)

lengths = Counter(
    (domain, len(domain))
    for domain in domains
)

for (domain, length), count in lengths.most_common(20):
    print(
        f"Length: {length:3} | "
        f"Count: {count:4} | "
        f"Domain: {domain}"
    )

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

Шаг 3. Поиск повторяющихся обращений

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

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

В Wireshark можно использовать:

dns.qry.name contains "example.net"

Вместо example.net указывается исследуемый домен.

Далее следует изучить последовательность запросов, временные интервалы и повторяемость обращений.

Шаг 4. Анализ содержимого DNS-запросов и ответов

Для изучения конкретного пакета необходимо выбрать его в списке и раскрыть раздел Domain Name System.

Нас интересуют следующие поля:

Queries: имя и тип запрашиваемой записи;
Answers: данные, полученные от DNS-сервера;
Transaction ID: идентификатор транзакции;
Response Code: код результата обработки запроса.

Особое внимание следует уделить длинным последовательностям в поддоменах и содержимому TXT-ответов.

Если встречаются строки, похожие на Base32 или Base64, можно проверить гипотезу о кодировании данных. При этом необходимо помнить, что визуальное сходство со строкой кодирования ещё не подтверждает наличие туннеля.

Шаг 5. Формирование гипотезы

После первичного анализа необходимо объединить полученные признаки.
Например:

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

Такая совокупность признаков позволяет сформировать обоснованную гипотезу о возможном DNS-туннелировании.

Однако окончательный вывод требует проверки самого устройства, процесса-источника запросов и сетевой инфраструктуры.

6. Автоматизация обнаружения с помощью Python

Ручной анализ большого объёма DNS-трафика занимает значительное время. Поэтому в SOC применяются механизмы автоматизации, позволяющие выявлять аномальные характеристики запросов.

Для демонстрации рассмотрим простой анализ длины доменных меток и энтропии.

Python:

import math
from collections import Counter

def entropy(value):
    if not value:
        return 0

    counts = Counter(value)
    total = len(value)

    return -sum(
        (count / total) * math.log2(count / total)
        for count in counts.values()
    )

def analyze_domain(domain):
    labels = domain.rstrip(".").split(".")
    suspicious = []

    for label in labels[:-2]:
        label_entropy = entropy(label)

        if len(label) >= 30 and label_entropy > 3.5:
            suspicious.append({
                "label": label,
                "length": len(label),
                "entropy": round(label_entropy, 2)
            })

    return suspicious

domains = [
    "mail.example.net",
    "portal.example.net",
    "7GQ4M2XK9P8L3D5N7B2Q4.example.net",
    "aGVsbG93b3JsZDEyMzQ1.example.net"
]

for domain in domains:
    result = analyze_domain(domain)

    if result:
        print(f"[!] Suspicious: {domain}")

        for item in result:
            print(item)

В данном примере анализируются отдельные метки доменного имени. Если длина метки превышает заданный порог и её энтропия достаточно высока, она попадает в список подозрительных.

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

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

7. Как обнаруживать DNS-туннелирование на стороне SOC

Для SOC-аналитика важно перейти от единичного подозрительного запроса к полноценному расследованию.

Практически полезно разделить обнаружение на несколько уровней.

Первый уровень: сетевой мониторинг.

Система должна собирать DNS-запросы и ответы, фиксировать источник, назначение, тип записи, имя домена, размер сообщения и время обращения.

Для этого могут использоваться сетевые сенсоры, DNS-логи корпоративных резолверов и системы анализа сетевого трафика.

Второй уровень: выявление аномалий.

Необходимо отслеживать:

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

Отдельно полезно вести статистику по каждому внутреннему устройству. Это позволяет определить, какое именно рабочее место создаёт аномальную активность.

Третий уровень: корреляция событий.

DNS-аномалия становится значительно интереснее, если одновременно фиксируются другие признаки компрометации.

Например:

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

Корреляция таких событий позволяет перейти от предположения о DNS-туннеле к расследованию возможного инцидента.

Четвёртый уровень: реагирование.

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

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

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

8. Как снизить риск использования DNS для скрытой передачи данных

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

Централизация DNS-запросов. Рабочие станции и серверы должны использовать утверждённые корпоративные DNS-резолверы. Прямые обращения к внешним DNS-серверам следует ограничивать в соответствии с архитектурой сети.

Контроль исходящего трафика. Межсетевые экраны должны ограничивать несанкционированные DNS-соединения. При этом необходимо учитывать DNS-over-TLS и DNS-over-HTTPS, которые используют другие транспортные порты и требуют отдельных механизмов контроля.

Мониторинг DNS-активности. Следует собирать и анализировать DNS-логи, отслеживать аномальные домены, длину меток, частоту обращений и объём трафика.

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

Сегментация сети. Ограничение взаимодействия между сегментами уменьшает возможности злоумышленника по перемещению внутри инфраструктуры и затрудняет развитие атаки.

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

Важную роль играет и MITRE ATT&CK. Техника T1071.004 помогает связать обнаруженную DNS-активность с тактикой Command and Control и использовать единый язык описания поведения злоумышленника при построении правил мониторинга.

9. Ограничения обнаружения и типичные ошибки аналитика

Даже хорошо настроенная система мониторинга не гарантирует обнаружение каждого DNS-туннеля.

Существуют реализации, которые используют короткие сообщения, изменяют периодичность запросов или применяют дополнительные механизмы кодирования. Это затрудняет выявление по отдельным статистическим признакам.

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

Поэтому при расследовании важно избегать нескольких ошибок.

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

Вторая ошибка связана с анализом только DNS-запросов без изучения ответов. При туннелировании информация может передаваться в обоих направлениях.

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

Четвёртая ошибка связана с отсутствием базовой линии. Без понимания нормального DNS-поведения инфраструктуры трудно определить, какие отклонения действительно заслуживают внимания.

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

Заключение

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

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

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

На практике наиболее эффективный подход заключается в сочетании централизованного контроля DNS, анализа сетевой активности и расследования на конечных устройствах.

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

Полезно

#dns #python

Ещё по теме

DNS как слепая зона Kubernetes: от разведки кластера до туннелирования данных grizzzer_lsp_men·16.07.2026·Облачная безопасность и DevSecOps 0 1 тыс. 16.07.2026

СтатьяDNS пентест: от разведки и zone transfer до cache poisoning, rebinding и туннелирования Сергей Попов·16.05.2026·Сетевая безопасность и беспроводные атаки 0 2 тыс. 16.05.2026

СтатьяСкрытые каналы передачи данных C2: DNS tunneling и HTTP covert channels от настройки до детекта Сергей Попов·07.06.2026·Сетевая безопасность и беспроводные атаки 1 2 тыс. 17.06.2026

СтатьяВыявление ботнет-маяков (C&C) в сети: Охота на скрытые коммуникации samhainhf·20.02.2026·Hardware Hacking / Аппаратный хакинг 0 3 тыс. 20.02.2026

DNS-туннелирование. Как обнаружить скрытую передачу данных в сетевом трафике.

1. Как работает DNS и почему его используют для туннелирования​

2. Архитектура DNS-туннеля​

3. Какие задачи решает злоумышленник с помощью DNS-туннелирования​

4. Признаки DNS-туннелирования в сетевом трафике​

5. Практический анализ DNS-трафика в Wireshark​

6. Автоматизация обнаружения с помощью Python​

7. Как обнаруживать DNS-туннелирование на стороне SOC​

8. Как снизить риск использования DNS для скрытой передачи данных​

9. Ограничения обнаружения и типичные ошибки аналитика​

Заключение​

Комментарии

1. Как работает DNS и почему его используют для туннелирования

2. Архитектура DNS-туннеля

3. Какие задачи решает злоумышленник с помощью DNS-туннелирования

4. Признаки DNS-туннелирования в сетевом трафике

5. Практический анализ DNS-трафика в Wireshark

6. Автоматизация обнаружения с помощью Python

7. Как обнаруживать DNS-туннелирование на стороне SOC

8. Как снизить риск использования DNS для скрытой передачи данных

9. Ограничения обнаружения и типичные ошибки аналитика

Заключение