DNS-защита в корпоративной инфраструктуре: почему фильтрации уже недостаточно

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

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

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

Почему DNS важен для корпоративной безопасности

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

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

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

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

DNS также может быть полезен для расследований. Даже если запрос не был заблокирован, сам факт обращения помогает понять, когда устройство впервые связалось с доменом, были ли похожие запросы у других хостов, какие типы записей использовались, была ли активность регулярной и совпадает ли она с событиями EDR, NGFW, Proxy или SIEM.

Базовый уровень: DNS-фильтрация доменов

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

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

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

Такой подход полезен, но фильтрация по категориям и известным индикаторам — это только первый слой. Он хорошо работает там, где домен уже классифицирован, категория понятна, а политика заранее описана. Сложнее с динамическими угрозами: недавно зарегистрированными доменами, DGA, DNS-туннелированием, C2-коммуникацией, которая быстро меняется.

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

Почему одной фильтрации недостаточно

Классическая DNS-фильтрация отвечает на вопрос: «Известен ли этот домен как опасный или запрещенный?» Но в реальной атаке этого вопроса часто мало.

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

Поэтому более зрелая DNS-защита должна учитывать контекст: кто делает запрос, с какого устройства и из какого сегмента, является ли поведение нормальным для этого актива, насколько домен новый или редкий, какие типы DNS-записей запрашиваются, есть ли всплеск NXDOMAIN, не похожи ли поддомены на DGA или туннель, были ли похожие события на других устройствах и что в это же время показывают EDR, NGFW, Proxy или SIEM.

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

Контекст устройства и пользователя

Один и тот же DNS-запрос может иметь разный смысл в зависимости от того, кто и откуда его делает. Запросы к TXT-записям могут быть нормальными для почтового сервера, который проверяет SPF, DKIM и DMARC. Но если сотни TXT-запросов к неизвестному домену делает пользовательская рабочая станция, это уже подозрительно.

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

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

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

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

DNS как источник ранних сигналов для Threat Hunting

Не все угрозы можно заблокировать на основании известных индикаторов. Иногда домен новый, инфраструктура еще не размечена, а активность выглядит неочевидно. В таких случаях DNS-логи становятся материалом для Threat Hunting.

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

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

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

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

В этом смысле DNS-защита — это не только блокировка, но и видимость.

Контроль DNS-туннелирования

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

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

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

При этом важно не сводить обнаружение только к TXT-записям. Некоторые туннели используют A-запросы или другие типы записей, чтобы выглядеть менее подозрительно. Ключевой сигнал — не отдельный тип записи, а поведение: DNS начинает использоваться как транспортный канал.

Для защиты от туннелирования нужно ограничить прямые DNS-запросы наружу, направлять трафик через корпоративные резолверы, анализировать структуру имен, строить baseline по устройствам и проверять подозрительные события через EDR, NGFW и SIEM. Если устройство генерирует туннель, важно не только заблокировать домен, но и понять, какой процесс это делает и как он попал в систему.

Контроль DoH и DoT

DNS over HTTPS и DNS over TLS решают задачу конфиденциальности DNS-запросов, но в корпоративной среде создают отдельный вызов. Если приложение или браузер отправляет DNS-запросы на публичный DoH-сервер в обход корпоративных резолверов, команда ИБ теряет часть видимости.

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

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

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

DNSSEC как отдельный слой доверия

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

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

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

Но DNSSEC требует операционной зрелости. Нужны управление ключами, корректные DS-записи, мониторинг срока действия подписей, регламент миграций и понимание, что ошибка в настройке может привести к недоступности домена для валидирующих резолверов.

В корпоративной модели DNSSEC стоит рассматривать как часть общей DNS-безопасности, но не как замену фильтрации, мониторинга или анализа угроз. Контроль категорий отвечает на вопрос: «Можно ли обращаться к этому домену?», мониторинг отвечает на вопрос: «Кто и почему к нему обращается», а DNSSEC отвечает на вопрос: «Можно ли доверять самому DNS-ответу?». Это разные задачи.

Интеграция DNS с SIEM, EDR, NGFW и Proxy

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

Например, DNS показывает, что устройство обратилось к подозрительному домену. EDR может показать процесс, который инициировал обращение. NGFW — дальнейшую сетевую сессию. Proxy — HTTP-запрос. SIEM — похожую активность на других устройствах, связь с пользователем, временную линию и корреляцию с письмом или запуском файла.

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

Практически полезные сценарии корреляции выглядят так: DNS-запрос к фишинговому домену связывается с переходом по ссылке из письма; обращение к C2-домену — с запуском неизвестного процесса; DGA-паттерн — с множеством NXDOMAIN; DNS-туннель — с длинными поддоменами и запуском PowerShell или скрипта; запрос к недавно зарегистрированному домену — с загрузкой файла; попытка DoH-обхода — с обращением к публичному резолверу.

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

Что важно логировать

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

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

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

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

Уровни зрелости DNS-защиты

DNS-защиту удобно рассматривать как постепенное развитие: от базовой фильтрации к управляемому уровню анализа риска.

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

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

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

Дальше появляется поведенческий анализ. Команда ИБ смотрит не только на категорию домена, но и на аномалии: всплески NXDOMAIN, длинные поддомены, множество уникальных FQDN, обращения к новым или редким доменам, попытки DoH-обхода и нетипичные типы записей. На этом уровне особенно важна корреляция, иначе правила могут давать слишком много шума.

На следующем уровне DNS становится частью SOC-процесса. DNS-события связываются с EDR, NGFW, Proxy, почтовой безопасностью и SIEM. Тогда подозрительный домен превращается не просто в запись журнала, а в точку расследования: можно понять, какое устройство сделало запрос, какой процесс был запущен, были ли сетевые соединения и повторился ли паттерн на других хостах.

Самая зрелая модель — адаптивная. Политики и реакции меняются с учетом риска и поведения актива. Например, устройство с признаками C2-коммуникации или DNS-туннеля не только получает блокировку домена, но и отправляется на проверку, переводится в ограниченный режим или попадает в очередь SOC. Такой подход требует зрелой архитектуры и операционной дисциплины, но именно он превращает DNS из списка блокировок в управляемый источник контекста для ИБ.

Типовые ошибки при построении DNS-защиты

Одна из частых ошибок — считать, что достаточно заблокировать известные вредоносные домены. Такая блокировка нужна, но она не видит новые домены, DGA, туннели и внутренние аномалии.

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

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

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

Наконец, опасно воспринимать блокировку как финал процесса. Если устройство попыталось обратиться к C2-домену или показало признаки туннеля, вопрос не только в том, был ли запрос заблокирован. Важно понять, почему устройство это сделало, какой процесс инициировал обращение и нет ли признаков компрометации.

Как внедрять DNS-защиту поэтапно

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

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

Затем запросы нужно направить через контролируемые резолверы. Это повышает безопасность и создает основу для аналитики. Без централизованной видимости любые дальнейшие правила будут неполными.

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

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

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

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

Финальный этап — адаптивные реакции. Например, устройство, которое обращается к C2-домену или показывает признаки DNS-туннеля, не только получает блокировку домена, но и переводится в ограниченный сетевой режим, отправляется на проверку EDR или попадает в очередь SOC.

Вопросы, которые CISO стоит задать про DNS

Чтобы оценить зрелость DNS-защиты, полезно начать с простых вопросов.

Все ли DNS-запросы проходят через контролируемые резолверы? Видим ли мы DNS-трафик удаленных пользователей, филиалов, серверов, IoT и гостевых сетей? Есть ли политика по DoH, DoT и публичным резолверам? Отличаются ли DNS-политики для рабочих станций, серверов, IoT и критичных сегментов?

Не менее важно понять, попадают ли DNS-события в SIEM и можно ли связать DNS-запрос с устройством, пользователем и процессом. Может ли команда быстро определить, какое устройство первым обратилось к подозрительному домену? Есть ли процесс расследования DGA, DNS-туннелей и NXDOMAIN-аномалий? Хранятся ли DNS-логи достаточно долго для расследований? Что происходит после блокировки: событие расследуется или просто закрывается?

Ответы на эти вопросы часто показывают, является ли DNS управляемым уровнем безопасности или остается техническим сервисом без достаточной видимости для ИБ.

Что важно запомнить

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

Нужны контекст устройств и пользователей, поведенческий анализ, контроль DoH/DoT, мониторинг DNS-туннелей, качественные логи и интеграция с SOC.

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

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

Так DNS превращается из фонового инфраструктурного протокола в управляемый уровень корпоративной защиты — не заменяющий EDR, NGFW, SIEM или Proxy, а усиливающий их за счет ранней видимости, контекста и контроля сетевых намерений.