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

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

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

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

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

Как работает DNS-фильтрация

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

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

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

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

Такой подход помогает остановить многие распространенные угрозы на раннем этапе. Однако он преимущественно отвечает на один вопрос: известен ли домен как опасный или запрещенный?

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

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

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

Недавно зарегистрированные и редкие домены

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

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

DGA-домены

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

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

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

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

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

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

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

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

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

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

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

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

Контроль DoH, DoT и публичных резолверов

DNS over HTTPS и DNS over TLS шифруют DNS-запросы и повышают их конфиденциальность. Однако в корпоративной среде неконтролируемое использование этих технологий может снизить видимость сетевой активности.

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

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

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

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

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

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

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

Поведенческий анализ

Репутация домена показывает, что известно о ресурсе. Поведенческий анализ помогает понять, что происходит с конкретным устройством.

ИБ-отдел может отслеживать:

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

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

DNS как источник данных для Threat Hunting

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

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

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

Качественное журналирование

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

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

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

DNSSEC

DNSSEC решает отдельную задачу — позволяет проверять подлинность DNS-ответов и защищает от их подмены.

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

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

Как выстроить DNS-защиту поэтапно

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

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

Следующий шаг — централизация запросов. Корпоративные устройства должны использовать контролируемые резолверы. Это позволяет применять единые правила, получать журналы и видеть активность различных сегментов инфраструктуры.

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

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

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

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

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

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

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

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

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

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