Как ограничить DNS-запросы при анализе неизвестного приложения

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

Зачем ограничивать DNS, а не просто отключать сеть

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

• Контроль точки выхода. DNS — это шлюз ко всему остальному трафику. Если приложение не может разрешить имена, оно не сможет установить HTTP-, HTTPS- или C2-соединение с новым адресом, даже если вы не блокировали эти протоколы явно.
• Индикаторы компрометации. Список доменов, к которым обращался образец, — один из самых ценных артефактов анализа. Его можно использовать для блок-листов, правил детектирования и поиска по другим системам.
• Управляемый ответ. Подменяя DNS-ответы, вы направляете трафик на собственный сервер-приманку и можете наблюдать, какие запросы приложение отправляет дальше.
• Снижение риска. Даже при ошибке в остальных правилах фильтрации закрытый DNS не даст образцу связаться с реальным инфраструктурным сервером атакующего.

При этом важно понимать ограничение: DNS — не единственный канал. Часть вредоносного ПО использует захардкоженные IP-адреса, DoH (DNS over HTTPS) через известные публичные резолверы или нестандартные протоколы. Поэтому ограничение DNS работает как основной, но не единственный слой контроля.

Подготовка окружения

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

1. Создайте виртуальную машину с чистой гостевой системой и сделайте снапшот до любых манипуляций.
2. Отключите общие папки, буфер обмена и проброс USB между гостевой системой и хостом.
3. Пропишите в настройках сети виртуальной машины единственный DNS-сервер — ваш контролируемый локальный резолвер (например, на отдельной виртуальной машине или хосте).
4. Убедитесь, что гостевая система не имеет доступа к другим DNS: заблокируйте исходящий трафик на порты 53 (TCP и UDP), 853 (DoT) и фильтруйте DoH-домены на уровне резолвера.
5. Подготовьте журнал: резолвер должен писать полный лог запросов с метками времени, именем клиента и типом записи.

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

Варианты организации контролируемого DNS

Выбор инструмента зависит от глубины анализа и доступных ресурсов. Ниже — типовые подходы, от простого к гибкому.

Подход	Как работает	Плюсы	Ограничения
Локальный резолвер с логированием	Все запросы уходят на ваш DNS-сервер, который пишет лог и отвечает из кэша или заглушкой	Просто, виден полный список доменов	Нет гибких правил ответов «из коробки»
DNS-заглушка (sinkhole)	Все или выбранные домены получают заранее заданный IP вашей машины	Трафик остаётся внутри, можно поднять фальшивый сервер	Нужен отдельный HTTP/HTTPS-сервер для осмысленного ответа
Резолвер с политиками (RPZ, списки allow/deny)	Домены из блок-листа получают NXDOMAIN или подменённый ответ, остальные — по правилу	Гибко: можно разрешить «безопасные» домены и блокировать остальное	Требует настройки и понимания, что считать безопасным
Полная блокировка DNS	Порт 53 закрыт, резолвера нет	Максимальная безопасность	Образец часто не проявляет поведение; теряются индикаторы

Для первого запуска неизвестного образца разумна связка «резолвер с логированием + политика по умолчанию deny»: всё запрещено, кроме явно разрешённых вами доменов. Так вы увидите, к чему приложение пытается обратиться, но не дадите ему этого сделать без вашего решения.

Пошаговый порядок работы с DNS при анализе

1. Зафиксируйте исходное состояние. Сделайте снапшот, запишите базовый лог резолвера до запуска образца — фоновые запросы самой системы (обновления, телеметрия ОС) не должны смешиваться с запросами приложения.
2. Запустите образец и наблюдайте за логом DNS. Отмечайте новые домены, их типы записей (A, AAAA, TXT, MX), частоту и регулярность обращений. Повторяющиеся запросы одного домена с коротким интервалом часто указывают на механизм C2 с резервными адресами.
3. Классифицируйте домены. Проверьте каждый через пассивный DNS, репутационные сервисы и анализ возраста домена. Свежезарегистрированные домены и домены с алгоритмически сгенерированными именами (DGA) — сильный признак вредоносной активности.
4. Примите решение по каждому домену. Безопасные служебные домены можно разрешить, подозрительные — направить на sinkhole, заведомо опасные — вернуть NXDOMAIN. Решение фиксируйте в журнале анализа.
5. Наблюдайте реакцию образца. Если после блокировки приложение начинает генерировать новые домены или переходит на прямые IP-соединения, это тоже поведенческий индикатор — зафиксируйте его.
6. Соберите артефакты. Экспортируйте лог DNS, список доменов, скриншоты и сетевые дампы. Верните виртуальную машину к снапшоту после завершения.

Что именно записывать в логе

Лог DNS — главный артефакт этого этапа. Полезный журнал должен содержать:

• точное время каждого запроса — для сопоставления с другими событиями (создание файлов, запуск процессов);
• полное запрашиваемое имя, включая поддомены;
• тип записи: запросы TXT и NULL-записи иногда используются для туннелирования данных;
• размер и содержимое ответа, который вы вернули;
• источник запроса, если в песочнице несколько клиентов.

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

Типичные ошибки и как их избежать

Даже опытные аналитики допускают на этом этапе предсказуемые промахи:

• Полное отключение сети «на всякий случай». Вы теряете поведенческую картину. Лучше управляемый DNS с запретом по умолчанию, чем отсутствие сети.
• Забытые альтернативные каналы разрешения имён. Современные системы и браузеры поддерживают DoH и DoT. Если не заблокировать порты 853 и обращения к известным DoH-серверам, образец обойдёт ваш резолвер.
• Захардкоженные IP-адреса. Ограничение DNS не остановит трафик напрямую на IP. Дополните его ограничением исходящих соединений на уровне файрвола песочницы.
• Разрешение «безобидных» доменов без проверки. Домены CDN, аналитики и обновлений иногда используются как канал доставки полезной нагрузки. Разрешайте только то, что действительно нужно для проявления поведения.
• Смешивание фонового шума с активностью образца. Сама гостевая ОС генерирует множество запросов. Сравнивайте лог «до» и «во время» запуска, чтобы выделить именно новые домены.
• Работа без снапшота. Если образец изменил систему, повторный анализ на «грязной» машине даст искажённые результаты.

Сценарии: что делать в конкретных ситуациях

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

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

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

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

Проверка качества настройки

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

• из гостевой системы запросите заведомо существующий домен — он должен пройти через ваш резолвер и появиться в логе;
• запросите несуществующий домен — убедитесь, что ответ соответствует вашей политике (NXDOMAIN или заглушка);
• проверьте, что прямое обращение по IP и попытка DoH-соединения блокируются файрволом;
• убедитесь, что снапшот создан и виртуальная машина изолирована от хоста и локальной сети.

Что делать после анализа

Результат работы с DNS — не просто лог, а материал для защиты. Список доменов превращается в индикаторы компрометации для мониторинга, выявленные механизмы (DGA, туннелирование, резервные C2) — в правила детектирования, а наблюдаемое поведение — в вывод о классе угрозы и необходимых мерах. Верните виртуальную машину к снапшоту, а артефакты сохраните вне песочницы.

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

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