“Логи DNS — это не просто записи о том, куда ходили пользователи. Это расшифровка намерений каждой машины в сети: какие команды она получала, куда пыталась слить данные и какие скрытые каналы использовала злоумышленник. В них нет шума обычных сетевых логов — только чистая семантика атаки.”
Сбор журналов DNS-запросов
Введение в систему DNS
DNS — это распределённый каталог, который транслирует человекочитаемые адреса в машинные идентификаторы. Каждый раз, когда браузер или приложение пытается подключиться к `mail.example.com`, система делает запрос к DNS, чтобы получить точный IP-адрес для соединения. Без этого механизма сеть была бы набором цифр, не предназначенных для запоминания.
За кулисами: Изначально, до появления DNS в 1987 году, работала модель с единым файлом `hosts.txt`, который администраторы вручную рассылали по всем узлам ARPANET. Её несостоятельность стала очевидна, когда файл перестал помещаться на стандартную дискету и обновления занимали сутки. DNS был создан как масштабируемая альтернатива, и сегодня его корневые серверы обрабатывают триллионы запросов ежедневно.
Почему сбор DNS-логов — обязательный, а не рекомендательный пункт
В современных реалиях DNS перестал быть просто справочной службой. Для злоумышленника это — канал управления, разведки и эвакуации данных, который часто остаётся вне поля зрения систем защиты. Запись DNS-запросов превращает этот скрытый трафик в последовательность событий, поддающихся анализу.
Отсутствие таких логов равносильно слепоте в отношении целого класса атак:
- C2-коммуникация: Вредоносное ПО для получения инструкций регулярно «звонит домой», запрашивая IP-адреса управляющих серверов через DNS.
- DNS-туннелирование: Данные кодируются прямо в поддоменах (например, `data.abcdefg.malicious-domain.com`), превращая DNS в скрытый канал связи, обходящий межсетевые экраны.
- Фишинг и типосквоттинг: Анализ запросов к доменам-клонам (`g00gle.com`, `paypai.com`) помогает выявить целенаправленные фишинговые атаки до того, как пользователь введёт учётные данные.
- Картографирование инфраструктуры: Злоумышленник, уже находящийся внутри сети, может использовать DNS-запросы для обнаружения других серверов и служб (`srv01.internal`, `db.prod`).
Многие решения класса DLP (Data Loss Prevention) и NGFW (Next-Generation Firewall) не инспектируют DNS-трафик на предмет утечек данных. Злоумышленник, использующий DNS-туннелирование, может месяцами выводить конфиденциальную информацию, если логи не анализируются на аномальные паттерны запросов.
Интеграция DNS с Active Directory: точка уязвимости
В корпоративных сетях Windows DNS и Active Directory (AD) неразрывно связаны. AD использует DNS для локализации контроллеров домена, серверов каталогов и других служб. Это делает внутренний DNS-сервер критическим активом и одновременно привлекательной мишенью.
Пример атаки: Техника «DCShadow». Злоумышленник, получивший привилегированные права в домене, может зарегистрировать поддельный контроллер домена и через него модифицировать DNS-записи AD. Например, изменить IP-адрес корпоративного шлюза или сервера обновлений на контролируемый злоумышленником, перенаправив на себя весь трафик. Без детальных логов, фиксирующих аномальные изменения DNS-записей (особенно динамических обновлений), такая атака останется незамеченной.
Анализ DNS-запросов для обнаружения угроз: на что смотреть
Доменные имена как индикатор компрометации
Машинно-генерируемые имена — ключевой маркер. Вредоносные программы, использующие алгоритмы генерации доменов (DGA), создают тысячи случайных имён в день (`xbvjklewqjh.ru`, `poldhgfyt.net`), чтобы скрыть настоящий адрес C2-сервера. Один запрос к такому домену — шум, но их повторяющаяся структура и частотность легко вычленяются при анализе логов.
Стоит обращать внимание не только на явно подозрительные имена, но и на легитимные домены с аномальными субдоменами, которые могут использоваться для техники `DNS C2 over HTTPS (DoH)` или как часть туннеля.
Поведенческие аномалии и паттерны запросов
Одно устройство, генерирующее на порядок больше DNS-запросов, чем аналогичные в своей группе, — тревожный сигнал. Это может указывать на сканирование внутренней сети, попытку брутфорса поддоменов или активность майнера.
Особый интерес представляют ответы `NXDOMAIN` (домен не существует). Их резкий рост с одного хоста может означать работу DGA — вредоносное ПО перебирает сгенерированные адреса в поисках «живого» C2.
Критичные типы DNS-записей в контексте безопасности
Не все записи равнозначны с точки зрения угроз. В таблице ниже — ключевые типы и связанные с ними риски.
| Тип записи | Назначение | Вектор атаки / Индикатор |
|---|---|---|
| TXT | Хранение произвольных текстовых данных. | Используется для проверки домена (SPF, DKIM, DMARC). Злоумышленники могут размещать в TXT-записях команды или конфигурации для вредоносного ПО (техника «DNS Text (TXT)»). Резкое появление нестандартных TXT-запросов — сигнал. |
| CNAME | Создание псевдонима для другого домена. | Часто используется в CDN и облачных сервисах. Может быть перенаправлен на вредоносный финальный домен в случае компрометации сервиса. Анализ цепочек CNAME помогает выявить редиректы на недоверенные ресурсы. |
| NS | Указание авторитетных DNS-серверов для домена. | Внезапное изменение NS-записей внутреннего домена — критический инцидент, указывающий на возможный захват управления доменом. |
| MX | Указание почтовых серверов домена. | Изменения могут говорить о подготовке к фишинговой атаке или перехвате корпоративной почты. |
| SRV | Обнаружение сетевых служб (используется в AD, VoIP). | Запросы к SRV-записям от нестандартных хостов могут свидетельствовать о разведке внутренней службы каталогов или телефонии. |
SPF, DKIM, DMARC: защита от спуфинга не в почтовике, а в DNS
Борьба с поддельными письмами ведётся не на почтовом сервере, а в DNS-зоне отправителя. SPF, DKIM и DMARC — это не протоколы, а политики, опубликованные в виде TXT-записей.
- SPF (Sender Policy Framework): Список серверов, которым разрешено отправлять почту от имени домена. Письмо с сервера не из списка будет помечено как подозрительное.
- DKIM (DomainKeys Identified Mail): Цифровая подпись для заголовка письма, проверяемая с помощью публичного ключа из DNS. Гарантирует, что письмо не было изменено после отправки.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Директива для получателя, что делать с письмом, не прошедшим проверки SPF/DKIM (отклонить, поместить в спам). Также указывает, куда отправлять отчёты о таких письмах.
Отсутствие или некорректная настройка этих записей — прямой риск попадания фишинговых писем от имени вашего домена в почтовые ящики партнёров и клиентов.
v=spf1 ip4:192.0.2.0/24 include:_spf.mailprovider.com -all
В примере выше `-all` означает строгую политику (hard fail): письма с любых других серверов должны быть отвергнуты. Частая ошибка — использование `~all` (soft fail), которая лишь помечает такие письма, но не блокирует их.
Практика: с чего начать сбор и анализ
Внедрение мониторинга DNS должно быть поэтапным.
- Включите аудит запросов на всех DNS-резолверах. Это касается как корпоративных DNS-серверов (Windows Server, BIND), так и интернет-шлюзов, которые могут выполнять роль DNS-форвардеров. Настройте логирование в структурированном формате (например, с полями: timestamp, client_ip, запрошенное имя, тип записи, код ответа).
- Направьте логи в SIEM или отдельную платформу для анализа. Хранение на самом DNS-сервере не подходит для безопасности — логи могут быть удалены при компрометации. Централизованное хранение обязательно.
- Сформируйте базовые правила корреляции. Например:
- Оповещение на частые запросы к доменам из публичных блок-листов угроз.
- Обнаружение паттернов DGA через анализ энтропии доменных имён.
- Выявление всплесков NXDOMAIN-ответов для отдельных хостов.
- Мониторинг запросов к новым, ранее не встречавшимся в сети, доменам верхнего уровня (TLD).
- Регулярно проводите охоту за угрозами (threat hunting). Автоматические правила не отлавливают сложные атаки. Периодически задавайте себе вопросы по логам: «Какой хост чаще всего запрашивает домены в зоне `.xyz` за последнюю неделю?» или «Были ли запросы к доменам, похожим на наши внутренние, но с опечатками?»
Заключение
В условиях, когда трафик шифруется, а атаки становятся целенаправленными, DNS-логи остаются одним из немногих источников прозрачной информации о намерениях. Их сбор — не просто формальное требование 152-ФЗ или внутренних политик. Это создание фундамента для проактивного обнаружения угроз, которые обходят традиционные средства защиты. Инвестиции в грамотную настройку, хранение и, что важнее, регулярный экспертный анализ этих данных окупаются предотвращением инцидентов, стоимость ликвидации которых на порядки выше.