Фишинговая атака часто начинается с простого действия: пользователь кликает по ссылке. До загрузки страницы устройство обращается к DNS, чтобы получить IP-адрес домена. Secure DNS использует этот ранний этап, чтобы заблокировать обращение к вредоносному или подозрительному домену еще до открытия сайта.
Это не заменяет обучение пользователей, почтовую защиту и EDR, но добавляет важный слой раннего контроля.
Почему DNS важен для защиты
Почти любое обращение к сайту, API или управляющему серверу начинается с DNS-запроса. Если на этом этапе видно, что домен связан с фишингом, вредоносной инфраструктурой или нежелательной категорией, соединение можно остановить раньше, чем пользователь увидит страницу или вредоносный код получит ответ.
Именно поэтому DNS-защита полезна не только против фишинга, но и против связи зараженных узлов с C2-серверами.
Почему DNS видит фишинг раньше, чем почта и браузер
DNS-резолвер получает запрос на разрешение домена раньше, чем почтовый шлюз успевает довести письмо до анализа содержимого, и раньше, чем браузер начнет загружать страницу, — потому что оба этих слоя вступают в работу позже по цепочке обращения.
Разница — в самом моменте проверки. Почтовый шлюз анализирует письмо в момент доставки: тему, вложения, репутацию отправителя, ссылки внутри текста. Но между доставкой письма и переходом по ссылке может пройти время — минуты, часы, иногда дни, — и за это время домен, который на момент отправки выглядел нейтрально, успевает превратиться в фишинговый ресурс. Часть архитектур защиты почты умеет повторно проверять ссылку в момент клика, но и такая проверка тоже упирается в DNS-разрешение того же домена.
Браузерная защита — это еще один шаг дальше по цепочке: она включается, когда установлено сетевое соединение и начинает загружаться содержимое страницы. Между отправкой DNS-запроса и получением первых байтов страницы проходит установление TCP-соединения — если домен уже заблокирован на этапе разрешения имени, до этого шага дело просто не доходит.
Таким образом DNS — это самая ранняя общая точка контроля независимо от того, откуда пришла ссылка: из письма, из мессенджера, с рекламного баннера или со взломанного легитимного сайта. Это не делает DNS-фильтрацию более важной, чем почтовая защита или EDR, — это делает ее самым ранним звеном одной цепочки, которая должна сработать целиком.
Какие признаки домена дают основание для блокировки
Secure DNS не блокирует домены произвольно: решение опирается на конкретные проверяемые признаки — как давно домен зарегистрирован, насколько его написание похоже на легитимный ресурс, к какой репутационной категории он относится и как выглядит профиль обращений к нему со стороны сети организации.
| Признак | Что усиливает подозрение |
|---|---|
| Свежая регистрация домена | домен создан недавно, история обращений и репутации еще не накоплена |
| Схожее написание | символы или структура домена визуально повторяют бренд компании, сервиса или партнера |
| Редко посещаемая зона | обращение к домену или категории, нетипичной для трафика организации |
| Аномальный профиль запросов | всплеск обращений с одного узла, нетипичное время суток, повторяющийся паттерн запросов |
Ни один признак сам по себе не доказывает вредоносность домена — свежезарегистрированный домен может принадлежать легитимному стартапу, а нетипичная зона — новому партнеру. Поэтому Secure DNS сопоставляет несколько признаков одновременно и опирается на репутационные базы и категории, а не на один изолированный сигнал.
Как Secure DNS блокирует фишинг
Secure DNS сверяет домены с репутационными базами, категориями и политиками организации. Если домен считается опасным, запрос блокируется или перенаправляется на предупреждающую страницу.
Типовые сигналы:
- домен известен как фишинговый;
- домен недавно зарегистрирован и похож на бренд;
- домен относится к запрещенной категории;
- домен используется в вредоносной кампании;
- поведение запросов выглядит аномальным.
Почему одной почтовой защиты мало
Почтовый шлюз может заблокировать письмо со ссылкой, но пользователь получает ссылки не только по почте: в мессенджерах, документах, личной почте, рекламных объявлениях и через скомпрометированные сайты. Secure DNS закрывает часть этих обходных путей, потому что проверяет сам факт обращения к домену.
Где DNS-фильтрация не закрывает угрозу
Secure DNS видит только факт обращения к домену: там, где соединение вообще обходится без DNS-запроса или использует уже доверенный домен, DNS-фильтр эту угрозу не увидит, и разрыв должна закрывать защита следующего слоя.
Три типовых сценария, в которых один DNS-слой не сработает:
- Прямое обращение по IP-адресу. Если вредоносный код обращается к управляющему серверу напрямую по IP, минуя разрешение имени, DNS-резолвер этот запрос вообще не увидит. Такой сценарий закрывает EDR, который наблюдает за сетевой активностью процесса непосредственно на конечной точке, а не только за DNS-запросами.
- Зашифрованный DNS в обход корпоративного резолвера. Если устройство обращается к публичному DoH- или DoT-резолверу напрямую, минуя корпоративные настройки, политики Secure DNS для этого запроса не применяются. Закрывается это на уровне сети — правилами, которые перенаправляют или блокируют обращения к публичным зашифрованным резолверам в обход защищенного DNS-сервиса организации.
- Ссылка на легитимном хостинге. Если фишинговая страница размещена на доверенном облачном сервисе или в легитимном SaaS-продукте, сам домен имеет хорошую репутацию, и DNS-фильтр его не заблокирует. Здесь разрыв закрывают средства, которые анализируют содержимое и контекст самой страницы или письма, а не только репутацию домена, — почтовая защита и статьи о ней разбирают этот сценарий подробнее в материале «Как работает защита почты» и в статье «Защита от фишинга и BEC».
Что видно в журналах
Журнал DNS-запросов помогает расследовать инциденты. По нему можно понять:
- кто обращался к подозрительному домену;
- когда начались обращения;
- повторяются ли запросы с одного узла;
- есть ли похожие запросы у других пользователей;
- какие политики сработали.
Эти данные полезны для SOC и помогают связать DNS-события с телеметрией EDR, почтовой защитой и SIEM.
Как связать сигнал DNS с почтой и конечной точкой в одном разборе
Отдельно взятый DNS-лог показывает только то, что определенный узел обратился к подозрительному домену. Полную картину инцидента дает сопоставление этого события с почтовым логом — кто получил письмо со ссылкой — и телеметрией EDR — что произошло на узле после обращения.
Типовая цепочка разбора инцидента выглядит так: письмо со ссылкой проходит через почтовый шлюз, пользователь переходит по ссылке, узел отправляет DNS-запрос к домену, Secure DNS принимает решение — заблокировать обращение или пропустить его. Если запрос разрешен, а домен позже оказывается вредоносным, именно телеметрия EDR показывает, какой процесс инициировал соединение и что произошло на узле дальше. Сопоставление всех трех источников по узлу, пользователю и временной метке в SIEM превращает разрозненные события в связный разбор одного инцидента, а не в три независимых записи в разных системах. Подробнее о том, как DNS-события экспортируются для такого сопоставления, рассказано в статье «Как Secure DNS защищает сеть от DNS-атак».
Удаленные сотрудники
DNS-защита особенно важна для удаленных сотрудников. Если устройство вне офиса использует защищенный DNS-сервис и политики организации, фишинговые домены можно блокировать независимо от того, находится ли пользователь в корпоративной сети. Конкретная схема подключения зависит от архитектуры организации и поддерживаемых режимов — прежде чем внедрять защиту для удаленных узлов, стоит свериться с документацией продукта.
Как внедрять Secure DNS поэтапно
Внедрение DNS-фильтрации без подготовки почти всегда приводит к вспышке ложных блокировок и потоку жалоб в поддержку. Правильный порядок снижает этот риск и дает видимость до того, как включается блокировка.
- Инвентаризация резолверов. Сначала нужно найти все DNS-резолверы, которые фактически используются в организации: корпоративные, филиальные, резолверы по умолчанию на устройствах удаленных сотрудников. Нельзя защитить то, что не учтено.
- Перевод клиентов на Secure DNS. Устройства переводятся на защищенный резолвер через DHCP, локальный форвардинг или агент — поэтапно, по группам пользователей, а не разом всей организацией.
- Настройка категорий. Администратор выбирает, какие категории блокируются сразу — заведомо вредоносные и фишинговые, — а какие требуют согласования с бизнесом, например контентные ограничения.
- Режим наблюдения перед блокировкой. Прежде чем включать блокировку, Secure DNS работает в режиме логирования: фиксирует, к каким доменам обращаются пользователи, но не блокирует их. Это показывает, какие легитимные сервисы могут случайно попасть под будущие политики.
- Постепенный переход к блокировке. Блокирующий режим включается по категориям и группам пользователей, начиная с самых однозначных случаев — заведомо вредоносных и фишинговых доменов.
- Работа с ложными срабатываниями. Нужен понятный процесс: пользователь сообщает о заблокированном легитимном домене, администратор быстро проверяет и добавляет исключение, а политики регулярно пересматриваются по итогам таких обращений.
Частые ошибки внедрения
- Включение блокировки сразу, без периода наблюдения. Это блокирует легитимные сервисы неожиданно для пользователей, вызывает вал обращений в поддержку и подрывает доверие бизнеса к инструменту.
- Перевод только части устройств. Если ноутбуки сотрудников вне офиса продолжают использовать резолвер по умолчанию, защита не работает именно там, где риск обращения к фишинговым ссылкам выше.
- Журнал DNS собирается, но не анализируется. Логи без регулярного разбора и без связи с другими источниками телеметрии теряют главную ценность — возможность быстро восстановить хронологию инцидента.
- Secure DNS воспринимается как исчерпывающая защита. Прямые обращения по IP, легитимный хостинг фишинговой страницы и обход резолвера через публичный зашифрованный DNS — три конкретных разрыва, которые один DNS-слой не закрывает (см. раздел выше).
- Нет быстрого процесса для white-list. Если разблокировка легитимного домена занимает дни, часть сотрудников начинает самостоятельно обходить корпоративный резолвер — а это открывает разрыв похуже, чем отсутствие DNS-фильтрации вовсе.
Чек-лист перед включением блокировки
- Учтены все резолверы организации, включая устройства удаленных сотрудников и филиалов.
- Пройден период наблюдения достаточной длительности, чтобы увидеть редкие и сезонные обращения.
- Назначен ответственный за разбор обращений о ложных срабатываниях.
- Настроен экспорт DNS-логов в SIEM и проверена корреляция с почтовыми и EDR-событиями по узлу и времени.
- Есть план для блокировки или перенаправления публичных зашифрованных DNS-резолверов в обход корпоративного.
- Категории блокировки согласованы с бизнес-подразделениями, а не выбраны только силами ИБ.
Практика
На курсе «Внедрение и администрирование BI.ZONE Secure DNS» можно отработать настройку политик и разбор DNS-событий на стендах: увидеть, как блокируются домены, как выглядит журнал запросов и как DNS-защита дополняет другие средства ИБ. Если нужно начать с основ, прочитайте «Что такое Secure DNS», а техническую сторону защиты от DNS-атак разбирает статья «Как Secure DNS защищает сеть от DNS-атак».