Обнаружение DNS туннелей05.09.2024 08:45

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

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

DNS и методы создания туннелей

Протокол DNS (Domain Name System) [1,2] изначально создавался как механизм для преобразования доменных имен в соответствующие IP-адреса и наоборот. Однако злоумышленники, проявив изобретательность, начали использовать этот протокол не только для идентификации узлов в сети, но и в качестве канала передачи данных. Такие каналы получили название DNS-туннели.

DNS-туннели создают «скрытые каналы», позволяя передавать данные через стандартные DNS-трафик, внедряя информацию в служебные поля протокола, которые в обычной жизни не используются для передачи данных. Их основной целью является обход обычных механизмов обнаружения и блокировки. Почему именно DNS? Этот протокол широко распространён, так как служит для преобразования имен в адреса и обратно и не блокируется средствами защиты информации.

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

Схема DNS туннеля [3]

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

• Заголовок DNS-пакета: включает в себя идентификатор запроса, флаги контроля (QR — определение запроса или ответа, Opcode — код операции, AA — ответ полномочного сервера, TC — признак обрыва связи, RD — признак рекурсии, RA — признак доступности рекурсии), количество вопросов, ответов, авторитетных и дополнительных записей, а также другие контрольные параметры.

• Запросы DNS: в этой части содержится информация о DNS-запросах, включая доменные имена и типы запросов (например, A — запрос IPv4-адреса, MX — запрос почтового сервера, CNAME — запрос канонического имени и т. д.).

• Ответы DNS: здесь содержится информация о найденных записях, соответствующих DNS-запросам. Каждый ответ может включать в себя тип ответа (например, A, CNAME, MX), запись IP-адреса и время жизни записи (TTL).

• Авторитетные записи DNS: этот раздел может содержать информацию о серверах, имеющих авторитет для данного доменного имени.

• Дополнительные записи DNS: здесь могут содержаться дополнительные записи, которые могут быть полезными для интерпретации ответа.

Пример обычного DNS-запроса

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

Пример туннелированного DNS-запроса

Обзор существующих методов обнаружения туннелей

Проблема обнаружения DNS-туннелей привлекает исследователей и специалистов в области кибербезопасности. Множество статей, исследований и инструментов посвящены этой проблеме. [4,5,6,7,8,9,10,11,12] Существующие методы обнаружения варьируются от статистического анализа трафика и мониторинга поведения сети до разработки сигнатур для определения характерных особенностей DNS-туннелей.

переведено со статьи [4]

На рисунке выше представлены некоторые пути решения данной проблемы.Кратко опишу каждый из них:

• Сигнатурный метод: анализ сигнатурных признаков, характерных для объектов или явлений, с целью классификации или детекции нелегитимного трафика.

• Метод пороговых значений (Thresholding): классификации или детекции на основе порогового значения для выбранных характеристик.

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

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

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

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

1)[7] DNS Tunneling Detection by Cache-Property-Aware Features: Для решения проблемы авторы фокусируются на «следе», оставленном DNS-туннелированием, который нельзя легко скрыть. В контексте утечки данных через DNS-туннелирование вредоносное ПО подключается напрямую к кэширующему DNS-серверу , и генерируемые запросы DNS-туннелирования обязательно вызывают кэш-промахи (cache misses).А поскольку обычные DNS-транзакции чаще всего сопровождаются успешными кэш-попаданиями (cache hits), то отношение cache hit/cache miss может являться индикатором аномальной активности в сети.

2)[8] A Hybrid Method of Genetic Algorithm and Support Vector Machine for DNS Tunneling Detection: В данной статье предлагается гибридный метод, который объединяет метод генетического алгоритма для выбора наилучших характеристик с классификатором метода опорных векторов (SVM). Авторам удалось достигнуть F-меры в 0.946.

3)[10] DNS Tunneling: A Deep Learning based Lexicographical Detection Approach: В данной работе предлагается метод обнаружения на основе сверточной нейронной сети (CNN) с минимальной сложностью архитектуры для увеличения быстродействия. Несмотря на простую архитектуру, разработанная модель CNN правильно обнаруживает более 92% общего числа доменов DNS-туннелирования с вероятностью ложных срабатываний, близкой к 0.8%.

После обзора научных статей по теме DNS туннелирования, необходимо отметить, что на практике для выявления и предотвращения этих угроз активно используются разные коммерческие решения. Эти решения предлагают комплексным подходы, сочетающие в себе современные методы анализа и фильтрации трафика, что позволяет обеспечить более высокий уровень безопасности корпоративных сетей. Примерами таких коммерческих инструментов являются ZenArmor и CloudFlare DNS. ZenArmor — это инструмент, который использует глубокий анализ пакетов (DPI) и машинное обучение для мониторинга сетевого трафика и выявления аномалий, таких как DNS туннели, путем анализа поведенческих моделей и шаблонов данных. CloudFlare DNS обеспечивает безопасность и производительность DNS-запросов, активно отслеживая и фильтруя подозрительные активности, что позволяет эффективно обнаруживать и предотвращать попытки DNS-туннелирования. Также для детектирования туннелей может использоваться Suricata с определёнными наборами правил, например emerging threats. Далее в статье будет сравнение нашего решения с Suricata.

Обзор наборов данных (датасетов)

Разработка и оценка методов обнаружения DNS-туннелей с помощью машинного обучения, как и любая другая задача машинного обучения, требует наличия качественных датасетов. В данном исследовании мы опирались на разнообразные источники данных для создания обучающих и тестовых наборов. В качестве обучающих данных использовались данные, полученные с нашего собственного стенда. Для их генерации мы создали две виртуальные машины (клиент и сервер), зарегистрировали доменное имя и установили NS запись, чтобы виртуальная машина-клиент обращалась к виртуальной машине-серверу. Мы генерировали как чистый трафик, так и трафик с использованием DNS-туннелей при помощи различных программ, таких как tcp2dns[13], iodine[14] и tuns[15]. Это позволило нам создать разнообразные сценарии туннельного трафика для более эффективного обучения наших моделей.

Для проверки и оценки эффективности нашей модели мы использовали дополнительные наборы данных. В частности, мы использовали файлы формата pcap из открытых репозиториев на GitHub[16,17,18], а также данные из статей, включая открытый датасет CIC (Canadian Institute for Cybersecurity)[19]. Эти наборы данных предоставили дополнительные случаи трафика, с которыми наша модель могла столкнуться в реальных условиях, и позволили нам более всесторонне оценить ее эффективность.

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

Использование LightGBM

Для эффективного обнаружения DNS-туннелей в данной работе был выбран алгоритм  машинного обучения с учителем LightGBM (Light Gradient Boosting Machine)[20]. Этот алгоритм основан на градиентном бустинге и характеризуется высокой производительностью и точностью. LightGBM способен эффективно обрабатывать большие объемы данных и выявлять сложные зависимости между признаками, что делает его подходящим выбором для туннелей в DNS-трафике.

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

Важной стратегией, выбранной для обнаружения DNS-туннелей, было разделение трафика на DNS-запросы и DNS-ответы, а затем создание двух отдельных моделей (Request и Response) для анализа каждого типа сообщений. Это позволило упростить задачу модели, работающей с одним конкретным типом трафика:

Схема обработки DNS-трафика

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

Request:

• 'qd_qname_len» / 'qd_qname_shannon» — длина / энтропия запрашиваемого домена

• 'ancount» / 'nscount» —  количество записей в блоке answer / name Server

• 'chars» — количество букв в доменном имени

• 'digits» — количество цифр в доменном имени

• 'ratio» — отношение количества гласных к согласным в доменном имени

Также имеется возможность графически определить причину, по которой модель обозначила тот или иной пакет как аномальный. На каждый пакет выводится 2 графика (принадлежность к 0 и 1 классу соответственно). Признаки синего цвета уменьшают уверенность модели в текущем классе, а красные наоборот увеличивают.

График влияния признаков на уверенность request-модели в нормальности пакета

График влияния признаков на уверенность request модели в аномальности пакета

Response:

• 'qd_qname_len» / 'qd_qname_shannon» — длина / энтропия запрашиваемого домена

• 'an_rdata_len','an_rdata_shannon» — длина / энтропия данных ответа

• 'an_rrname_len','an_rrname_shannon» — длина / энтропия домена в ответе

• 'ancount» / 'nscount» —  количество записей в блоке answer / name Server

График влияния признаков на уверенность response модели в нормальности этого пакета  

График влияния признаков на уверенность response модели в аномальности этого пакета  

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

Полученные метрики и результаты

Для успешной работы модели важно избегать ложных срабатываний, так как «белого» трафика очень много, и частые ошибки могут привести к отключению модели. При оценке её производительности рекомендуется ориентироваться на F1-score (weighted), который учитывает дисбаланс классов и предоставляет более сбалансированное представление о точности и полноте, особенно в условиях неоднородного распределения данных.

В процессе оценки эффективности нашей моделей мы использовали три различных тестовых датасета. Рассмотрим результаты на каждом из них:

Датасет GitHub:

Датасет из репозиториев на GitHub[16,17,18] предоставил нам множество тестовых случаев, созданных сообществом исследователей. Мы использовали этот датасет для проверки обобщающей способности модели на разнообразных вариациях туннельного трафика.

Request-модель:

Response-модель:

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

Датасет CIC:

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

Request-модель:

Response-модель:

На датасете CIC модель так же хорошо отработала, это показывает, что модель не переобучилась и способна работать в новых для нее ситуациях. Однако 6 пакетов первого класса не было обнаружено. Поскольку количество примеров класса 1 очень малое, в этих случаях возможно использовать дополнительный метод блокировки. Например, можно блокировать парой запрос-ответ в одном соединении.

Обученные модели были успешно интегрированы в решение UDV NTA (Network Traffic Analyzer). UDV NTA (Network Traffic Analyzer) — передовое решение для анализа сетевого трафика, обеспечивающее эффективное выявление аномалий и вредоносной активности.

Пример инцидента, созданного по сработке модели в интерфейсе UDV NTA

Сравнение с Suricata

Suricata — это мощная и гибкая система обнаружения вторжений (IDS) и предотвращения вторжений (IPS), а также инструмент для мониторинга сетевой безопасности, созданный и поддерживаемый организацией Open Information Security Foundation (OISF). Suricata предназначена для анализа сетевого трафика в режиме реального времени и выявления подозрительной активности, используя комбинацию сигнатурного и аномального обнаружения. Благодаря своей многофункциональности и поддержке различных протоколов, Suricata широко используется в корпоративных сетях для защиты от кибератак и обеспечения безопасности данных.

В этом блоке мы проведем сравнение эффективности работы Suricata с нашими моделями. Оценка будет проводиться на наборах данных, предоставленных на GitHub [16,17]. В рамках нашего анализа мы будем рассматривать детектирование каждого пакета отдельно, а также пары пакетов, представляющие одно соединение. Это позволит нам детально оценить точность обнаружения угроз, скорость обработки данных и общую эффективность обеих систем. 

Конфигурация Suricata:

Suricata 4.1.2, Набор правил: Emerging Threats 2024–07–19T20:49:10Z

Request:

Response:

Соединение:

Suricata показала сработки только на одном файле, при этом 222 из них — «Misc activity» и только 38 — «ET TROJAN Suspicious Long NULL DNS Request — Possible DNS Tunneling». Кроме того, в ходе эксперимента было выявлено, что Suricata не детектирует туннели, сгенерированные утилитой dnscat2 [21], которые обнаруживаются нашей моделью.

Заключение

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

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

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

Автор статьи: Никита Быков, младший исследователь исследовательского центра UDV Group

Ссылки:

© Habrahabr.ru