DNS‑трафик как скрытая уязвимость: риски и защита корпоративной инфраструктуры
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
Email: petukhov@legascom.ru
DNS‑трафик кажется «техническим фоном», но на деле - это богатый источник данных о компании: по нему можно восстановить используемое ПО, структуру подразделений, облачные сервисы и даже текущие проекты. Если трафик уходит во внешние резолверы без контроля, эти сведения становятся доступны злоумышленникам. В статье - что именно раскрывается через DNS, какие угрозы это создаёт и как выстроить безопасную работу с DNS‑сервисами.
Что можно узнать о компании по DNS‑трафику
В каждом DNS‑запросе содержится набор метаданных: запрашиваемые домены, частота и время обращений, последовательность запросов, а также IP‑адреса источников. В совокупности эти данные отражают и техническую инфраструктуру, и поведение пользователей.
На практике такой массив позволяет построить детальный профиль организации:
направления деятельности и потенциальные проекты;
список подразделений и их специализацию;
используемые ОС, ПО, оборудование, инструменты тестирования безопасности;
продукты конкретных вендоров, мессенджеры, посещаемые ресурсы;
виртуальные машины с доступом во внешнюю сеть;
взаимодействия с внешними организациями.
Эксперимент, проведённый юридической компанией ЛЕГАС, показал, что даже ограниченный набор DNS‑запросов (выгрузка в CSV за несколько дней) в связке с локальной LLM‑моделью позволяет автоматически сформировать такой профиль с высокой точностью.
Особую опасность представляет передача этих данных через недоверенные публичные резолверы: это расширяет возможности анализа и корреляции активности, фактически раскрывая часть внутренней инфраструктуры.
Основные категории DNS‑угроз
Угрозы, связанные с DNS, можно разделить на три группы:
Атаки на инфраструктуру DNS. Это DDoS‑атаки (в т. ч. DNS Amplification и DNS‑флуд), а также попытки отравления кеша (DNS Cache Poisoning). Современные механизмы (DNSSEC, DNS cookies) усложняют такие атаки, но риски доступности остаются высокими.
Использование DNS для управления и вывода данных. Злоумышленники применяют DNS как канал C2 (управления заражёнными устройствами), а также для туннелирования данных. DNS‑туннели сложно детектировать, особенно на фоне большого числа ложных срабатываний и аномалий.
Маскировка вредоносной инфраструктуры. Сюда входят алгоритмы генерации доменов (DGA), техника DNS Rebinding (обход защиты веб‑приложений) и другие методы, позволяющие скрывать активность под легитимный трафик.
По данным исследований юридической компании ЛЕГАС, структура нелегитимного DNS‑трафика выглядит так:
25 % - DNSSEC‑аномалии;
6,8 % - запросы к DGA‑доменам;
около 6 % - попытки DNS Rebinding;
DNS‑туннели фиксируются тысячами событий в год даже при наличии IDPS и NTA.
Отдельная категория рисков - поведение пользователей: по статистике, каждый второй нелегитимный DNS‑запрос связан с попытками доступа к заблокированным ресурсам, а 61,6 % таких запросов - это переходы к доменам, запрещённым корпоративными политиками. Даже случайные обращения могут приводить к взаимодействию с фишинговыми или вредоносными ресурсами.
Почему DNS - точка раннего предотвращения угроз
Для пользователя DNS‑запросы происходят «в фоне»: при открытии почты или браузера автоматически отправляется поток запросов. Их генерируют и легитимные приложения, и вредоносное ПО. Важное преимущество - на этапе DNS‑запроса атаку часто можно остановить: значительная часть угроз (фишинг, доставка вредоносного ПО) требует соединения с доменом злоумышленника. Блокировка таких обращений на уровне DNS предотвращает дальнейшее развитие атаки ещё до установки соединения.
Критерии выбора доверенного DNS‑резолвера
Выбор резолвера - это вопрос контроля над сетевой телеметрией. При работе с публичным резолвером компания фактически передаёт часть данных о своей инфраструктуре за периметр. Чтобы минимизировать риски, нужно оценивать три ключевых параметра:
Прозрачность обработки данных. Важно понимать, какие логи собираются, как долго хранятся, в какой юрисдикции находятся и передаются ли третьим сторонам. Отсутствие этих гарантий повышает риск утечки информации об инфраструктуре.
Управляемость и наблюдаемость. Организация должна иметь доступ к телеметрии в объёме, достаточном для расследований: исходные IP, домены, ответы, временные метки. Если данные агрегируются на стороне провайдера, DNS становится «слепой зоной».
Поддержка политик безопасности и интеграция в процессы ИБ. Резолвер должен позволять не только базовую фильтрацию, но и блокировку DGA‑доменов, выявление аномалий, контроль DNS over HTTPS, ограничение обхода через сторонние резолверы. Обязательна интеграция с SIEM и возможность реагирования в режиме, близком к реальному времени.
Использование публичных или Open Source‑резолверов без оценки этих параметров приводит к потере контроля: компания не управляет логированием, политиками и детектированием, что создаёт условия для незаметного развития атак.
Практические модели безопасной работы с DNS
На практике применяют две модели:
Собственные рекурсивные резолверы. Дают полный контроль над логированием, политиками, форматом и сроками хранения данных.
Специализированные решения, где доверие, прозрачность и безопасность заложены в архитектуре.
В обоих случаях DNS рассматривается не как вспомогательный сервис, а как инструмент контроля и раннего предотвращения угроз. Поскольку DNS - первый шаг при установлении соединения, отсутствие доверия и контроля на этом уровне делает все последующие уровни защиты менее эффективными из‑за неполной видимости трафика.
Вывод
DNS‑трафик - это не просто техническая деталь, а значимый вектор риска и одновременно точка раннего блокирования угроз. Грамотная стратегия включает:
минимизацию утечки метаданных (контроль резолверов, политика маршрутизации DNS‑запросов);
применение DNS‑фильтрации как первого эшелона защиты;
использование телеметрии DNS для детектирования и расследований;
выбор доверенных решений либо развёртывание собственных сервисов с полным контролем.
Такой подход превращает DNS из «невидимого» канала в управляемый элемент системы информационной безопасности.
