Проблемы DNS-трафика: как остановить атаку до соединения

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

Первая точка контроля

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

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

DNS-защита работает на опережение

Когда опасный домен блокируется до соединения, атака теряет скорость: пользователь не открывает фишинг, ВПО не получает команду, а SOC видит приоритетный сигнал, а не сырой шум.

Эксперты Solar DNS RADAR

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

Что происходит без защиты DNS-трафика

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

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

Зрелое решение проблемы DNS — это не разовая смена резолвера и не ручной просмотр логов. Нужна связка мониторинга, фильтрации, Threat Intelligence, поведенческого анализа, SIEM-интеграцииSIEM — система сбора и корреляции событий безопасности, где аналитики видят инциденты, приоритеты и контекст реагирования. и управляемого реагирования. Такой подход помогает ИБ-команде видеть DNS-запросы в контексте, быстрее выявлять подозрительную активность и блокировать угрозы до соединения.

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

Скачать презентацию

Сценарии атак через незащищенный DNS-трафик

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

Проблема первая: DNS-трафик не виден традиционным СЗИ

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

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

Чтобы закрыть этот разрыв, ИБ-команде нужно видеть не только сам факт DNS-запроса, но и его контекст:

• Источник запроса — устройство, пользователь, сегмент сети.
• Домен, к которому идет обращение.
• Категорию риска: фишинг, C2, DGA, proxy, Tor, VPN и другие.
• Репутацию домена и его историю.
• Связь с IoC и данными Threat Intelligence.
• Частоту и регулярность обращений.
• Результат фильтрации: разрешено, заблокировано, передано в SOC.

Только при таком уровне видимости проблемы DNS-трафика перестают быть фоновым шумом и становятся управляемым потоком сигналов для ИБ-команды.

Проблема вторая: фишинг через подмену DNS-записей

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

DNS-защита снижает риск, потому что работает до соединения. Если домен связан с фишингом, вредоносной инфраструктурой или свежим IoCIoC (Indicator of Compromise, индикатор компрометации) — технический признак атаки или заражения: домен, IP-адрес, URL, хеш файла, сигнатура или другой след вредоносной активности., запрос можно заблокировать до загрузки страницы.

Проблема третья: C2-серверы и скрытое управление ботнетами

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

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

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

Проблема четвертая: DGA-домены уходят от черных списков

DGA — это алгоритм генерации доменных имен. Вредоносное ПО создает множество вариантов адресов и проверяет, какой из них зарегистрирован злоумышленником для связи с C2. Сегодня один домен неактивен, завтра другой становится рабочим, а послезавтра схема меняется снова. Для статических черных списков это гонка на износ.

Такие домены часто выглядят случайными: длинные строки, необычные сочетания символов, нетипичные зоны, всплески NXDOMAIN-ответов. Но не каждый странный домен вредоносен, а не каждый DGA-домен выглядит очевидно. Поэтому простого правила «длинное имя — блокировать» недостаточно: оно даст ложные срабатывания и быстро утомит аналитиков.

Нужен поведенческий анализ, который учитывает несколько признаков:

• Энтропию доменного имени — насколько оно похоже на случайный набор символов.
• Частоту DNS-запросов и интервалы между ними.
• Историю регистрации домена и срок его существования.
• Повторяемость паттернов в именах и запросах.
• Связь домена с семействами вредоносного ПО.
• Данные Threat Intelligence и известные индикаторы компрометации.

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

Проблема пятая: DNS-туннелирование и скрытая утечка данных

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

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

Признаки DNS-туннелирования, на которые стоит обратить внимание:

• Длинные доменные метки и необычно длинные поддомены.
• Высокий объем запросов к одной доменной зоне.
• Нетипичное использование TXT-записей.
• Повторяющиеся шаблоны в структуре запросов.
• Большой процент уникальных поддоменов.
• Активность, не похожая на поведение реального пользователя.

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

Проблема шестая: SOC перегружен миллионами DNS-событий

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

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

Правильный подход — предварительная фильтрация, обогащение и приоритизация. Безопасный поток остается в журналах, а в SIEM передаются значимые сработки: источник, домен, категория риска, действие, время, IOC и объяснение, почему событие требует внимания. Это не убирает аналитику из процесса, а освобождает ее от лишнего бега.

Проблема седьмая: APT-атаки через легитимный DNS-трафик

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

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

Для выявления APT важны исторический анализ, Passive DNS, Threat Intelligence и контекст по сети заказчика. Нужно понимать, когда домен появился, кто к нему обращался, как менялись записи, с какими IOC он связан и встречался ли такой паттерн в других атаках. Именно здесь проблемы DNS-трафика становятся задачей не только фильтрации, но и расследования.

Проблема восьмая: VPN и proxy обходят политики безопасности

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

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

DNS-фильтрация позволяет применять политики по категориям риска:

• VPN.
• Proxy.
• «Припаркованные» домены.
• «Состаренные» домены.
• Фишинговые ресурсы.
• Вредоносное ПО.
• C2-инфраструктура.
• Другие классы подозрительных или нежелательных доменов.

При этом ИБ-команда может:

• Задавать исключения для легитимных бизнес-процессов.
• Фиксировать попытки обхода корпоративных политик.
• Передавать события в SOC с понятным контекстом.

Проблема девятая: нет единой точки контроля DNS-трафика

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

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

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

Проверьте DNS-контур на скрытые угрозы

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

Запросить демонстрацию

Как Solar DNS RADAR блокирует угрозы

Solar DNS RADARDNS Radar — сервис анализа и фильтрации DNS-запросов, который помогает блокировать вредоносные домены до установки соединения. работает как ранний защитный рубеж: анализирует DNS-запросы, сопоставляет домены с Threat Intelligence, выявляет фишинг, C2, DGA, APT-активность, VPN, proxy и другие риски. Опасный запрос можно заблокировать до соединения — до открытия страницы, загрузки вредоносного ПО или передачи данных.

По данным Solar 4RAYS, 89% киберугроз связаны с использованием DNS-протокола, а 95% выявленных индикаторов компрометации фиксируются повторно. Это дает защите практическое преимущество: если домен, инфраструктура или паттерн уже встречались в атаках, DNS-фильтрация может распознать риск до установления соединения.

В основе архитектуры решения лежат три ключевых компонента:

• DNS-proxy. Выполняет глубокий анализ DNS-трафика непосредственно внутри инфраструктуры.
• Control Center. Отвечает за централизованное управление событиями и политиками безопасности.
• Zero Trust. Проверяет каждый вновь запрашиваемый домен до того, как к нему будет открыт доступ.

Для специалистов SOC критически важна бесшовная интеграция с SIEM-системами. Решение сокращает массив DNS-событий, поступающих на анализ, на 99,5%. Вместо сырого потока всех запросов в SIEM направляются только готовые уведомления о выявленных угрозах. Такой подход позволяет аналитикам меньше времени тратить на ручную проверку первичных событий и быстрее переходить к полноценному расследованию и реагированию на инцидент.

Практический эффект для бизнеса:

• Меньше ручной проверки однотипных DNS-событий.
• Быстрее расследование по источнику, домену и индикатору компрометации.
• Единые политики для филиалов, сегментов и удаленных пользователей.
• Раннее отсечение фишинга, C2 и DGA-активности.
• Контроль VPN, proxy и других способов обхода политик.
• Прокачка внутренней «мускулатуры» SOC без перегруза команды.

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

Сделайте DNS базовой линией обороны

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

Solar DNS RADAR помогает перевести DNS из служебного механизма в активный инструмент безопасности: с аналитикой, Threat Intelligence, Zero Trust, SIEM-интеграцией и понятной логикой реагирования. Это не отдельный прием, а часть общей командной игры, где важны скорость, дисциплина и готовность к давлению.

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

Часто задаваемые вопросы по проблемам DNS-трафика