DNS – это один из источников бизнес-метаданных, который позволяет понять, какие сервисы использует ваша компания, с кем она интегрируется, какие инструменты внедряет. Давайте посмотрим, как DNS-трафик может использоваться для анализа корпоративной инфраструктуры и какие риски это создает для бизнеса.
Автор: Дмитрий Царев, руководитель управления облачных решений кибербезопасности BI.ZONE
Активность DNS может меняться в кризисных ситуациях, при реализации масштабных проектов или переходе на новые облачные решения. Для злоумышленников такие данные представляют ценность: на их основе можно формировать профили компаний, определять используемые технологии, мессенджеры и наличие функциональных подразделений.
Что можно узнать о компании по ее DNS-трафику
DNS-трафик формируется в процессе обработки DNS-запросов, которые проходят через рекурсивные резолверы. В зависимости от архитектуры запросы могут обрабатываться внутри корпоративной сети либо передаваться внешним резолверам.
В процессе такой обработки формируется массив метаданных: доменные имена, к которым обращаются пользователи и сервисы, частота и время запросов, последовательность обращений, а также сопоставление этих запросов с исходными IP-адресами. В совокупности эти данные отражают как техническую инфраструктуру компании, так и поведенческие особенности ее пользователей.
На основе этих данных можно сформировать профиль организации, включая посещаемые сервисы и используемые технологии. Поскольку исходный IP-адрес (source IP address) виден резолверу, иногда удается установить принадлежность трафика конкретной организации и даже восстановить используемый пул IP-адресов. Это особенно актуально, если хосты компании напрямую используют внешние резолверы или запросы проходят через корпоративный рекурсивный резолвер, по которому можно определить источник трафика.
Впрочем, такие данные доступны не во всех сценариях: если рекурсивный резолвер напрямую обращается к авторитетным серверам за информацией, без промежуточных узлов определить принадлежность трафика и особенности внутренней инфраструктуры, как правило, невозможно.
Чтобы проверить, насколько информативными могут быть такие данные, в BI.ZONE провели эксперимент с использованием сервиса BI.ZONE Secure DNS. Эксперты выгрузили CSV-файл с DNS-запросами и ответами за несколько дней, проходившими через внутренний рекурсивный резолвер компании. Полученный массив данных был обработан локальной LLM-моделью для автоматического построения профиля организации.
Результаты оказались показательными. На основе DNS-трафика модель смогла достаточно точно определить направление деятельности компании и потенциальные проекты, в которых она может участвовать. Она также определила список подразделений, их специализацию, используемые программные решения, оборудование, операционные системы и даже инструменты, применяемые специалистами по тестированию безопасности.
Удалось также выявить информацию об используемых продуктах различных вендоров, популярных мессенджерах, посещаемых веб-ресурсах сотрудников, виртуальных машинах, имеющих доступ во внешнюю сеть, а также потенциальных проектах и взаимодействиях с внешними организациями. При этом все перечисленное – лишь часть возможных данных. Даже ограниченный набор DNS-запросов способен раскрывать значительно больше деталей о внутренней инфраструктуре и поведенческих паттернах пользователей.
Передача таких данных через недоверенные публичные рекурсивные резолверы создает дополнительные риски для конфиденциальности корпоративной среды, поскольку расширяет возможности анализа и корреляции активности.
Риски при использовании DNS
DNS-угрозы условно можно разделить на несколько категорий. Во-первых, это атаки на сами DNS-серверы и инфраструктуру разрешения имен. Во-вторых, использование DNS-запросов для взаимодействия между зараженными устройствами и управляющими серверами (C2). В-третьих, маскировка вредоносной инфраструктуры: например, через генерацию доменных имен или использование динамических доменных зон.
Несмотря на то что такие техники применяются реже, чем классические веб-атаки, их трудно выявлять из-за ограниченной наблюдаемости DNS-трафика и отсутствия у организаций инструментов и данных, позволяющих детектировать подобные активности.
Злоумышленники используют DNS для скрытого управления вредоносными программами, вывода данных через туннели и обхода защитных механизмов сети. Нелегитимный DNS-трафик составляет заметную долю в общем объеме DNS-запросов, а его структура варьируется в зависимости от среды наблюдения. По данным BI.ZONE Secure DNS [1], DNSSEC-аномалии составили 25% нелегитимного трафика. Еще 6,8% приходятся на запросы к доменам, сгенерированным алгоритмами DGA, а около 6% – на попытки использования техники перепривязывания DNS (DNS Rebinding), позволяющей обходить защиту веб-приложений. Даже относительно редкие DNS-туннели фиксировались более тысячи раз за год, несмотря на наличие в инфраструктуре систем обнаружения вторжений (IDPS) и анализа сетевого трафика (NTA).
Сохраняются и угрозы, нацеленные прямо на DNS-инфраструктуру. Один из примеров – попытка отравления DNS-кеша (DNS Cache Poisoning). Сегодня реализовать такую атаку значительно сложнее, чем раньше: современные механизмы (DNSSEC, DNS cookies и дополнительные параметры сессии) существенно усложняют подбор UDP-порта, угадывание TXID и подмену ответа сервера.
Помимо атак на целостность данных, актуальными остаются и атаки на доступность DNS-сервисов. В частности, авторитетные DNS-серверы регулярно становятся целью DDoS-кампаний. Например, атак типа DNS Amplification или DNS-флуда, которые часто входят в стандартный инструментарий ботнетов.
Особое место занимает DNS-туннелирование – техника, позволяющая передавать данные через DNS-запросы, маскируя активность под легитимный трафик. В наблюдаемом трафике регулярно фиксируются тысячи событий с признаками DNS-туннелирования, однако их часть оказывается ложноположительными срабатываниями или аномалиями, не связанными с реальной передачей данных через DNS. Это создает дополнительную сложность: на фоне большого количества подозрительных, но не вредоносных событий снижается точность детектирования, и реальные атаки могут оставаться незамеченными. В результате повышаются требования к качеству анализа DNS-трафика и корреляции с другими источниками данных.
Сложность выявления туннелирования дополнительно возрастает при использовании технологий, затрудняющих анализ DNS-трафика. Например, DNS over HTTPS шифрует запросы и ограничивает возможности их анализа, если трафик не терминируется на стороне рекурсивного сервера. Алгоритмы генерации доменов (DGA), применяемые вредоносным ПО, могут использоваться не только для динамической смены адресов управляющих серверов, но и в отдельных сценариях – как механизм передачи информации. В совокупности это усложняет выявление и блокировку каналов управления и передачи данных.
Хотя атаки с использованием DNS встречаются реже по сравнению с другими типами сетевых угроз, они остаются потенциально опасными – особенно в тех случаях, когда инфраструктура разрешения имен не находится под полноценным контролем организации.
Отдельную категорию рисков формирует поведение пользователей внутри корпоративной сети. По данным BI.ZONE Secure DNS за 2025 г. [1], каждый второй нелегитимный DNS-запрос связан с попытками сотрудников получить доступ к заблокированным ресурсам. При этом 61,6% таких запросов приходится на переходы к доменам, запрещенным корпоративными политиками. Остальная часть связана со случайными переходами по устаревшим ссылкам или ошибками пользователей. Но даже такие запросы могут приводить к взаимодействию с фишинговыми или вредоносными ресурсами.
Для обычного пользователя DNS-трафик остается практически невидимым. Когда человек открывает почту или запускает браузер, фоном формируется постоянный поток DNS-запросов. Их автоматически отправляют как легитимные приложения, так и вредоносные программы, о существовании которых пользователь может даже не подозревать. При этом именно на этапе DNS-запроса во многих сценариях атаку еще можно остановить: значительная часть угроз, включая фишинг и доставку вредоносного ПО, требует установления соединения с доменом злоумышленника. Блокировка таких обращений на уровне DNS позволяет предотвратить дальнейшее развитие атаки до установления соединения с вредоносным ресурсом.
Как выбирать публичный DNS-резолвер?
Выбор DNS-резолвера – это вопрос доверия. Любой публичный резолвер обрабатывает данные о DNS-запросах, включая запрашиваемые домены и связанные с ними сетевые метаданные. Если резолвер не является доверенным, организация теряет контроль над тем, кто и как анализирует этот трафик, где он хранится и может ли быть использован для сторонних задач. В этом контексте выбор DNS-поставщика сопоставим с передачей части сетевой телеметрии за пределы периметра. Доверенность резолвера – это не характеристика по умолчанию, а набор проверяемых свойств.
Во-первых, прозрачность обработки данных. Должно быть понятно, какие именно логи собираются, как долго они хранятся, в какой юрисдикции находятся и используются ли для аналитики или передачи третьим сторонам. Отсутствие этих гарантий напрямую повышает риск утечки информации о внутренней инфраструктуре.
Во-вторых, управляемость и наблюдаемость. Организация должна иметь доступ к DNS-телеметрии в объеме, достаточном для расследования инцидентов и построения детектирующих правил: как минимум – исходные IP-адреса, домены, ответы и временные параметры. Если эти данные недоступны или агрегированы на стороне провайдера, DNS становится слепой зоной.
В-третьих, возможность применения политик безопасности. Резолвер должен поддерживать не только базовую фильтрацию, но и более продвинутые сценарии: блокировку DGA-доменов, выявление аномалий, контроль DNS over HTTPS и ограничение обхода через сторонние резолверы. Без этого DNS остается каналом обхода защиты. Важно, чтобы резолвер встраивался в процессы кибербезопасности: интегрировался с SIEM, участвовал в корреляции событий и позволял реагировать на инциденты в режиме, близком к реальному времени.
Использование публичных или Open Source-резолверов без оценки этих параметров фактически приводит к потере контроля над DNS-трафиком. В таких сценариях компания не управляет ни логированием, ни политиками, ни механизмами детектирования, что создает как риски утечки данных, так и условия для незаметного развития атак.
На практике это приводит к двум моделям. Либо организация разворачивает собственные рекурсивные резолверы с полным контролем над логированием и политиками, либо использует специализированные решения, где требования к доверенности, прозрачности и безопасности реализованы на уровне архитектуры. В обоих случаях DNS рассматривается не как вспомогательный сервис, а как инструмент контроля и раннего предотвращения угроз. DNS – это первый шаг при установлении соединения. Если на этом этапе отсутствуют доверие и контроль, все последующие уровни защиты работают в условиях неполной видимости.