DNS-файрволы и Protective DNS: как работают и кому нужны

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

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

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

Что такое DNS-файрвол

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

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

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

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

Что такое Protective DNS

Protective DNS, или PDNS, — более широкое понятие. Обычно под ним понимают защищенный DNS-сервис, который не только разрешает доменные имена, но и применяет к DNS-запросам политики безопасности.

Если обычный DNS-резолвер отвечает на вопрос «Какой IP-адрес у этого домена?», то Protective DNS добавляет второй вопрос: «Безопасно ли разрешать это обращение с учетом домена, источника запроса, политики и контекста?».

Protective DNS может включать функции DNS-файрвола, threat intelligence, категоризации доменов, обнаружения новых и подозрительных доменов, выявления DGA, признаков DNS-туннелирования, мониторинга обходов через публичные резолверы или DNS-over-HTTPS.

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

Для CISO важна не терминология сама по себе, а управленческий вопрос: помогает ли DNS-уровень видеть и снижать риски до сетевой сессии.

Как это работает

Типовая цепочка выглядит так. Устройство отправляет DNS-запрос. Запрос проходит через контролируемый резолвер или DNS-сервис. Сервис проверяет домен по нескольким слоям: репутация, категория, threat intelligence, возраст домена, признаки фишинга, связь с C2-инфраструктурой, поведенческие паттерны, политика для конкретного сегмента или группы пользователей.

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

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

Хороший DNS-контроль должен показывать:

какое устройство отправило запрос;

какой пользователь или сегмент с ним связан;

к какому домену было обращение;

почему домен признан рискованным;

какой тип угрозы предполагается;

были ли повторные обращения;

обращались ли к этому домену другие устройства;

нужно ли передавать событие в SIEM, SOC или EDR-процесс.

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

Какие угрозы видны на DNS-уровне

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

Фишинг и похожие домены

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

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

C2-коммуникации

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

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

DGA-домены

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

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

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

Новые и малоизвестные домены

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

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

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

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

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

Для CISO этот риск особенно важен, потому что DNS во многих организациях остается служебным трафиком, который контролируется слабее, чем веб, почта или файловый обмен.

Кому это особенно нужно

Protective DNS полезен не только крупным компаниям с большим SOC. Его ценность зависит не столько от размера организации, сколько от распределенности инфраструктуры, критичности активов и зрелости процессов ИБ.

Организациям с распределенной инфраструктурой

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

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

Компаниям с большим количеством устройств без агентов

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

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

CISO, которые строят Zero Trust

Zero Trust — это не продукт, а архитектурный подход: каждое взаимодействие должно проверяться с учетом идентичности, состояния устройства, контекста и риска.

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

Командам SOC

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

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

Компаниям, где важно подтверждать управляемость политик

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

Такие ситуации создают слепые зоны. Формально средства защиты есть, но часть DNS-активности проходит мимо утвержденных политик.

Где проходят границы возможностей

DNS-файрволы и Protective DNS работают с доменным уровнем. Поэтому они не должны восприниматься как универсальный ответ на все сценарии атаки.

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

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

DNS показывает раннюю попытку обращения к домену;

NGFW и прокси видят сетевую и веб-коммуникацию;

EDR помогает понять процесс и поведение конечной точки;

SIEM связывает события во времени;

система управления активами показывает критичность устройства;

SOC или команда реагирования принимает решение, что делать дальше.

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

Как внедрять Protective DNS

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

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

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

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

Четвертый шаг — встроить DNS-события в процессы ИБ. Значимые события должны попадать в SIEM или SOC-процесс, связываться с устройством, пользователем и критичностью актива. Для C2, DGA, DNS-туннелирования и обхода корпоративного резолвера стоит заранее определить сценарии реагирования.

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

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

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

Все ли корпоративные DNS-запросы проходят через контролируемые резолверы?

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

Можно ли связать DNS-запрос с конкретным активом и пользователем?

Контролируется ли использование публичных DNS-сервисов и DNS-over-HTTPS?

Попадают ли события в SIEM?

Есть ли приоритизация по типу угрозы и критичности актива?

Может ли аналитик быстро увидеть историю обращений устройства?

Есть ли отдельные сценарии для C2, DGA и DNS-туннелирования?

Проверяется ли конечная точка после подозрительного DNS-события?

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

Главное

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

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

Protective DNS особенно нужен организациям с распределенной инфраструктурой, устройствами без агентов, удаленными пользователями, облачными нагрузками и зрелым подходом к Zero Trust. Его ценность раскрывается в эшелонированной защите, где DNS связан с политиками, журналами, SIEM, SOC, EDR, инвентаризацией активов и сценариями реагирования.

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