В защиту сети вкладывают деньги, время и людей, а DNS остаётся сбоку. Он работает, имена разрешаются, вопросов нет. Вопрос возникает ровно один раз — когда выясняется, что канал управления вредоносом жил в DNS-запросах несколько месяцев, и в журналах его нет, потому что DNS никто не смотрел.
DNS удобен атакующему именно потому, что скучен. Его выпускают наружу без разговоров, он мелкий, его много, и он давно используется как канал управления и как способ вынести данные. В публикации Palo Alto Networks 2020 года со ссылкой на Unit 42 приводилась оценка около 85% для вредоносного ПО, использующего DNS при установлении связи с управляющим сервером. Методики подсчёта там нет, и переносить её на 2026 год я бы не стал; важно другое — это про разрешение имени управляющего сервера, а не про долю DNS-туннелей.
Пока DNS был открытым текстом, разбирать его умел любой межсетевой экран с разбором приложений. Потом появился зашифрованный DNS, и разбирать стало нечего.
Два протокола, и они устроены по-разному
Это важнее всего остального в статье: DoH и DoT решают одну задачу, но прячутся по-разному, поэтому и меры против них разные. Статья про эти два; DNS поверх QUIC (RFC 9250, UDP/853 по умолчанию) и DoH поверх HTTP/3 в неё не входят, но в проверки своей сети их добавьте.
DNS-over-HTTPS (DoH) заворачивает запросы DNS в обычный HTTPS на 443-й порт. Это не побочный эффект, а заявленное свойство: RFC 8484 в разделе 8.1 называет плюсом то, что DoH идёт по стандартному порту и может смешиваться с остальным HTTPS в одном соединении — это, по формулировке документа, способно затруднить вмешательство непривилегированных устройств на пути и анализ DNS-трафика. Стандарт не уточняет, чьё это устройство. Для вас оно своё — межсетевой экран на периметре.
DNS-over-TLS (DoT) поступает наоборот: занимает отдельный порт 853 по умолчанию, закреплённый за ним в разделе 6 RFC 7858, а раздел 3.1 прямо запрещает передавать по нему незашифрованный DNS — в том числе после неудачного рукопожатия TLS. Оговорка важна: тот же раздел допускает согласовать другой порт, поэтому блокировка одного номера закрывает распространённый случай, а не все возможные. Такой протокол легко заблокировать по порту целиком или, наоборот, сознательно разрешить и расшифровывать именно на нём.
Разница практическая. DoT — вопрос решения: разрешаем или нет. DoH — вопрос расшифрования: без него вы не отличите запрос DNS от загрузки картинки.
Схема: где прячется каждый из двух
Чем это опасно в корпоративной сети
Приложение внутри периметра само выбирает, куда отправлять запросы DNS. Если оно умеет DoH, то ваши настройки ему не указ: оно ходит к стороннему DNS-резолверу мимо корпоративного, и мониторинг DNS остаётся без данных — не ломается, а просто перестаёт что-либо видеть.
Браузеры и операционные системы зашифрованный DNS поддерживают, и включение его по умолчанию зависит от версии, платформы и региона — то есть меняется без вашего участия, с очередным обновлением. Вредоносное ПО использует DoH ровно за тем же: канал управления и вынос данных, скрытые внутри обычного HTTPS.
Отдельный случай, из-за которого это перестаёт быть теорией, — семейства, использующие DNS для связи перед шифрованием. Потеря видимости DNS означает потерю одной из возможностей заметить подготовку и вмешаться; других она не отменяет.
Что делать на NGFW
Четыре правила, по убыванию пользы.
1. Разделить управляемые приложения и всё остальное. На управляемых браузерах DoH выключается политикой предприятия — это надёжнее любой сетевой меры и не требует расшифрования. Сетевой контроль нужен для остального: неизвестных назначений и программ, которым ваши настройки не указ. Там работает расшифрование TLS плюс правило по приложению, а не по порту: порт здесь всегда 443 и ничего не говорит. Против вредоноса, игнорирующего любые настройки, ни то ни другое не даёт гарантии — только видимость и шанс заметить.
2. Если расшифрование ещё не внедрено — блокировать DoH по идентификатору приложения. Мера промежуточная и честно ограниченная: сработает она в основном на известных публичных серверах DoH, которые опознаются по имени домена. Свой сервер атакующего она не остановит. Это временная ступень на пути к первому пункту, а не замена ему.
3. Решить по DoT осознанно. Либо блокировать приложение dns-over-tls и порт 853 — чаще всего он и так закрыт, и достаточно убедиться, что его никто не открыл, — либо расшифровывать трафик на нём. Вопрос к поставщику и к пилоту: применяются ли после расшифрования обычные проверки DNS — репутация доменов, алгоритмически сгенерированные имена, перенаправление на подставной адрес. У части продуктов это описано в документации, у части нет; на слово не берите.
4. Оставить ровно один путь наружу. Ограничьте исходящий DNS по UDP и TCP на 53-й порт своими серверами. Это отдельная дыра, а не следствие первых трёх: разрешённый внешний DNS даёт обход корпоративного резолвера даже там, где DoH и DoT закрыты.
Как проверить, что правила сработали
Правило, написанное в политике, и правило, работающее на трафике, — разные вещи. Три проверки:
- Проверять не «откроется ли сайт». Браузер в автоматическом режиме молча вернётся к обычному DNS, а имя может оказаться в кэше — страница откроется, и это ничего не докажет. Нужен режим без отката, заведомо некэшированное имя и сверка трёх вещей: какой резолвер выбран, что видно в сетевом обмене и появилось ли срабатывание в журнале.
- Попробовать соединение на порт 853 наружу и убедиться, что оно не устанавливается или расшифровывается — в зависимости от принятого решения.
- Посмотреть отчёт по DNS за неделю и найти станции, которые обращаются мимо корпоративного распознавателя. Если таких нет вовсе — сначала проверьте, что отчёт вообще собирается: пустой отчёт выглядит одинаково и при полном порядке, и при полной слепоте.
Что спросить у поставщика до покупки
Три вопроса, которые разводят продукты быстрее любой презентации: опознаёт ли продукт DoH как отдельное приложение внутри HTTPS без расшифрования, и с каким ограничением; что происходит с производительностью при включённом расшифровании на реальном профиле трафика; какие проверки применяются к DNS после расшифрования — репутация доменов, алгоритмически сгенерированные имена, туннелирование.
Как проверить это на испытаниях — в программе пилота NGFW. Полный список критериев выбора с вопросами поставщику — на странице как выбрать NGFW.
Материал переписан из моей статьи 2020 года в блоге «Реальная безопасность»: протоколы и разделы RFC с тех пор те же, а рынок, продукты и настройки по умолчанию изменились, поэтому текст собран заново.