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

DNS (Domain Name System) — одна из базовых инфраструктурных систем Интернета. Её главная функция проста и понятна: переводить удобные для человека доменные имена (например, example.com) в IP-адреса, которые используют компьютеры для маршрутизации и обмена данными. По сути, DNS — это распределённая «телефонная книга» сети: пока имя не разрешено, соединение чаще всего просто не начнётся.

Но на DNS редко смотрят как на рубеж обороны — и это стратегическая ошибка. DNS находится на самом раннем этапе большинства сетевых взаимодействий и поэтому отлично подходит для контроля, обнаружения и сдерживания угроз. Практически любая современная атака так или иначе оставляет след в DNS. В терминах kill chain DNS часто оказывается одним из первых «сигналов», которые можно заметить ещё до того, как на хосте появятся явные признаки компрометации.

Почему DNS – один из любимых векторов атакующих

Представьте, что ваш периметр сети – это крепость. Вы закрыли все ворота, поставили стражников на стены. Однако есть один туннель под самой стеной, который никто не охраняет, хотя о нем могут догадываться – и этот туннель называется UDP/53.

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

На практике ряд сетевых артефактов может прямо указывать на компрометацию системы.

Во-первых, вредоносное ПО часто выполняет DNS-резолвинг доменов C2-серверов (Command & Control), через которые осуществляется управление зараженными узлами. Наличие регулярных DNS-запросов к таким доменам может служить индикатором заражения.

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

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

Архитектура DNS-защиты

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

Корневых серверов не так много, в мире их около 13. Они содержат информацию о доменах верхнего уровня и направляют запросы к соответствующим серверам.

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

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

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

Важно понимать, что DNS-защита – это не один инструмент, а использование совокупности.

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

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

Блокировка вредоносных доменов: как не выстрелить в самого себя

Самый простой и очевидный подход к защите от вредоносных доменов – это взять список всех плохих доменов и ответить NXDOMAIN (то есть несуществующее имя) на любой запрос к ним. Звучит это довольно просто. Реализовать это также не составит труда. Но вот получить звонок от разъяренного СЕО, которому заблокировали рабочий инструмент – еще проще.

Ниже сформулировали несколько правил выживания для DNS-блокировки:

• Никогда не используйте единственный источник индикаторов компрометации (IoC). Необходимо использовать минимум три с разными методологиями.

• Внедряйте список блокировки поэтапно: сначала использовать режим аудита (логировать, но не блокировать), потом режим предупреждения, а затем уже блокирование.

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

• Следует настроить алерты (уведомления) на любые попытки доступа к заблокированным доменам – это само по себе очень ценный сигнал.

Если следовать данным правилам, то риск блокировки критичных ресурсов будет минимальный. А ваш телефон не будут разрывать гневные сотрудники, у которых нет доступа к важным данным.

Response Policy Zones (RPZ): швейцарский нож DNS-фильтрации

RPZ – это стандартный механизм для DNS Firewall, поддерживаемый BIND, PowerDNS и рядом коммерческих решений. Он позволяет внедрять собственные политики поверх стандартного DNS.

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

⚠️ Важно: политика NXDOMAIN более агрессивна, чем перенаправление на заглушку. Первая говорит «домен не существует», вторая — «этот ресурс заблокирован». Для корпоративной среды рекомендуется использовать заглушку с информационной страницей: это снижает поток обращений в helpdesk.

Фильтрация по категориям: работаем с «серыми зонами»

Наличие репутационных индикаторов компрометации (IoC) – это хорошо, но они закрывают лишь известные угрозы. Напрашивается вопрос: что делать с недавно зарегистрированными доменами? Которые, например, были зарегистрированы три дня назад и не попали ни в один фид IoC?

Ответ на этот вопрос довольно прост: фильтрация по признакам домена, то есть по категориям. Вот несколько эффективных практик:

• Возраст домена меньше 7 дней: блокировать или требовать явного наличия белого списка. Легитимные корпоративные ресурсы не появляются из ниоткуда.

• Энтропия имени домена больше 3.5: DGA-домены (domain generation algorithm) имеют высокую энтропию (пример: abc123xqz.com — подозрительно. google.com — нет).

• Длина поддомена больше 50 символов: типичный признак DNS-туннелирования или DGA.

• Множество уникальных поддоменов одного домена: если, например, за час к одному домену было 500 запросов к разным поддоменам – это не CDN, это туннель.

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

Касаясь темы защиты DNS невозможно не упомянуть расширение системы DNS, обеспечивающее выстраивание цепочки доверия для домена, а именно — DNSSEC. Это напрямую служит защитой от подмены запросов, например, при заражении кэша или атакой на рекурсивный резолвер.

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

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

Данное расширение позволяет защититься от атак, вроде DNS cache poisoning, DNS hijacking, DNS spoofing.

Обнаружение DNS-туннелирования: ловим крота

DNS-туннелирование – это по сути процесс злоупотребления DNS-протоколом для передачи произвольных данных. Злоумышленник кодирует нагрузку (payload) в имя домена (например, base32 или base64), а DNS-сервер, участвующий в атаке, декодирует его на другом конце. Инструменты вроде dnscat2, DNSExfiltrator делают это в несколько кликов.

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

Реальный кейс: в 2020 году группировка OilRig (также известная как APT34) из Ирана использовала DNS-туннелирование для C2-коммуникаций в атаке на телекоммуникационную компанию на Ближнем Востоке. Трафик выглядел как обычные DNS-запросы к легитимно выглядящим доменам — обнаружить его стандартными средствами было практически невозможно. Злоумышленники использовали новую на тот момент утилиту DNSExfiltrator.

Статистические признаки туннелирования

В этом всем есть хорошая новость: само туннелирование оставляет следы. Однако тут же приходит и плохая: они видны только при анализе паттернов, а не отдельных запросов.

То есть существует два способа обнаружить злоупотребление DNS:

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

• Анализ числа запросов DNS подоменно по сравнению с каким-нибудь нормальным средним уровнем.

Следовательно, можно выделить некоторые аномалии, которые следует искать:

• Средняя длина запроса – в типичной корпоративной сети длина полного доменного имени (FQDN) чаще всего не превышает ~40 символов. Существенное увеличение средней длины запроса или появление регулярных обращений к доменам с длиной более 50–60 символов может свидетельствовать о DGA-активности или попытке передачи данных через DNS. Важно оценивать отклонение от собственного статистического профиля сети.

• Количество уникальных поддоменов одного домена за единицу времени – для большинства легитимных сервисов число различных поддоменов, к которым обращается клиент за час, ограничено. Резкий рост количества уникальных поддоменов (десятки и сотни в час для одного базового домена) является характерным признаком DNS-туннелирования или алгоритмически генерируемых имён.

• Частота и регулярность обращений к одному домену — в нормальном пользовательском трафике запросы распределены неравномерно и зависят от активности пользователя и приложений. Появление строго регулярных, периодических DNS-запросов с фиксированным интервалом (beaconing) может указывать на C2-коммуникацию.

• Есть несколько утилит, которые будут полезны для обнаружения туннелирующих атак:

• reassemble_dns – утилита python, открывающая .pcap файлы и анализирующая DNS-запросы;

• dnsHunter – модуль Python, который считывает .pcap файлы, извлекает DNS-запросы и производит выявление геолокации, что в дальнейшем поможет при анализе.

Итого: с чего начать прямо сейчас

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

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

Шаг 2. Подключить 2-3 Threat Intelligence фида и запустить в режим аудита на неделю.

Шаг 3. Настроить базовый мониторинг аномалий: длинные запросы, регулярная структура, редкие типы записей.

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

Шаг 5. Включить блокировку поэтапно, начиная с IT-отдела. Необходимо замерить FPR (False Positive Rate), то есть доля отрицательных примеров, неправильно воспринятых как положительные.

DNS – это не только инфраструктура, это разведка.

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