DNS Security: как через 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, то есть «несуществующее имя», на любой запрос к ним. Звучит просто. Реализуется тоже несложно. Но получить звонок от раздраженного CEO, которому заблокировали рабочий инструмент, еще проще.

Чтобы DNS-блокировка не превратилась в источник операционных проблем, стоит соблюдать несколько правил.

Не используйте единственный источник индикаторов компрометации. Минимум — три источника с разными методологиями.

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

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

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

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

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

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

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

Репутационные индикаторы компрометации полезны, но они закрывают только известные угрозы. Остается вопрос: что делать с доменами, которые зарегистрированы три дня назад и еще не попали ни в один фид IoC?

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

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

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

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

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

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

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

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

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

DNSSEC помогает защищаться от атак вроде DNS cache poisoning, DNS hijacking и DNS spoofing. При этом важно понимать: DNSSEC не заменяет DNS-фильтрацию и мониторинг. Он решает задачу целостности ответа, но не определяет, является ли запрашиваемый домен вредоносным.

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

Опасность в том, что DNS-трафик разрешен почти везде. Даже в жестко сегментированной сети UDP/53 часто открыт. Через него можно передавать команды ботам и незаметно выводить данные.

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

Хорошая новость: DNS-туннелирование оставляет следы. Плохая — эти следы видны не в отдельных запросах, а в паттернах.

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

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

На практике стоит искать несколько типов аномалий.

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

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

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

Для анализа могут быть полезны утилиты:

reassemble_dns — Python-утилита, которая открывает .pcap-файлы и анализирует DNS-запросы;

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

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

Первый шаг — включить полное логирование DNS на используемых резолверах.

Второй шаг — подключить 2−3 Threat Intelligence-фида и запустить их в режиме аудита минимум на неделю.

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

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

Пятый шаг — включать блокировку поэтапно, начиная с ИТ-отдела. На этом этапе важно замерять FPR (False Positive Rate), то есть долю нормальных событий, ошибочно распознанных как вредоносные.

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

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