DNS over HTTPS и DNS over TLS: безопасность или головная боль для SOC
Автор: Андрей Корепов, младший специалист по информационной безопасности
Предпосылки появления DoH и DoT
Протокол DNS был разработан ещё в далёком 1983 году. В то время интернет насчитывал не более 1000 хостов, преимущественно распределённых между двумя сетями: военной MILNET и научно-исследовательской ARPANET. О безопасности протокола особо не думали, перед ним ставилась одна задача: обеспечить базовую связность, преобразуя доменные имена в IP-адреса.
Всё изменилось с появлением графических браузеров и приходом коммерции в интернет-пространство. Массовое распространение интернета выявило две проблемы протокола: отсутствие конфиденциальности и целостности DNS-трафика. Целостность удалось обеспечить с помощью расширения протокола DNSSEC, которое предусматривает добавление цифровых подписей к DNS-записям, однако проблема с конфиденциальностью оставалась нерешённой. Для её решения были разработаны DNS over HTTPS (DoH) и DNS over TLS (DoT), о которых и пойдёт речь в этой статье.
Что представляет собой DNS over TLS
В ответ на недостаточный уровень конфиденциальности было решено добавить к стандартному DNS шифрование по протоколу TLS. Так и получился DNS over TLS (DoT), способный работать как с DNSSEC, так и без. В отличие от стандартного протокола DNS, использующего 53-й порт, для его «надстройки» специально был зарезервирован 853-й порт.
При использовании DNS over TLS процесс разрешения доменного имени стал более ресурсоёмким. Разберём это на практическом примере: попробуем узнать IP-адрес сайта skydns.ru и отследим интернет-трафик. В ходе разрешения доменного имени была зафиксирована последовательность пакетов, которую можно разделить на четыре этапа:
- Установка TCP-соединения клиента с сервером (пакеты 9–11 из примера): клиент запрашивает соединение с сервером; сервер принимает соединение; клиент подтверждает соединение.
- Процесс TLS-рукопожатия, установка зашифрованного TLS-туннеля (пакеты 12–19 из примера): клиент отправляет пакет с поддерживаемыми версиями TLS и наборами шифров; сервер отвечает пакетом с выбранными параметрами, отправляет свой сертификат и необходимые расширения; обмен клиента и сервера зашифрованными данными для генерации сессионных ключей; подтверждение готовности туннеля к работе.
- Зашифрованный DNS-обмен (пакеты 20–23 из примера): передача DNS-запроса клиента через установленный TLS-туннель; получение зашифрованного DNS-ответа от сервера.
- Завершение соединения (пакеты 24–27 из примера): подтверждение последних полученных данных; закрытие TCP-соединения с обеих сторон.
В результате разрешения доменного имени получилась следующая последовательность символов, которая представляет собой стандартный DNS-ответ в зашифрованном виде:
Описанная в практическом примере последовательность процессов соответствует протоколу TLS 1.2. В версии TLS 1.3 процесс оптимизирован, и DNS-запрос может передаваться за меньшее число пакетов, но базовый принцип инкапсуляции остаётся тем же.
Что представляет собой DNS over HTTPS
Спустя некоторое время после появления DoT на свет вышла технология DNS over HTTPS (DoH). По своей сути она повторяет процесс разрешения доменного имени через DoT с одним важным отличием: в TLS-туннеле передаётся не чистый DNS-запрос, а HTTP-запрос, в теле или параметрах которого инкапсулированы DNS-данные. Отправить такой запрос можно одним из двух методов:
- GET: запрос кодируется в base64url и передаётся в параметре dns (/dns-query?dns=…).
- POST: бинарный DNS-пакет отправляется в теле запроса (Content-Type: application/dns-message).
При попытке отследить такой трафик можно увидеть аналогичную DoT картину c одним отличием в виде HTTP в качестве протокола передачи данных:
Несмотря на схожесть с DoT, у DoH есть ключевая особенность, делающая технологию более приватной. Если DoT использует порт 853, что делает такой трафик заметным при сетевом мониторинге, то DoH работает на стандартном порту HTTPS — 443, маскируясь под обычный веб-трафик.
Светлая сторона DoT и DoH
Как было упомянуто в разделе про предпосылки появления технологий, главная цель создания DoT и DoH — повышение конфиденциальности DNS-запросов. Этого удалось достигнуть с помощью передачи запросов в защищённом, зашифрованном туннеле. Конфиденциальность не позволяет потенциальному злоумышленнику, получившему доступ к сетевому трафику, отслеживать запрашиваемые доменные имена, что минимизирует риск атак с применением социальной инженерии. Ведь, зная, на какие сайты заходит пользователь, мошенник с лёгкостью может составить профиль своей жертвы и, например, использовать это для создания более убедительного фишингового письма. Также известно о случаях, когда интернет-провайдеры собирали данные сетевой активности для показа таргетированной рекламы.
Помимо конфиденциальности, передача DNS-данных в зашифрованном туннеле решает ещё одну проблему — возможность подмены ответов (DNS-спуфинг). В классическом DNS, где отсутствует проверка сертификатов, злоумышленник может реализовать атаку типа MITM (Man-in-the-Middle, «человек посередине»). Она позволяет перехватывать DNS-запросы клиента и подменять ответы, отправляя вредоносный IP-адрес вместо реального. Так пользователь, планировавший зайти, к примеру, на корпоративный сайт, попадает на его визуальную подделку, вводит учётные данные и предоставляет мошеннику новую точку входа в сеть компании.
Тёмная сторона DoT и DoH
Однако у данных технологий есть и обратная сторона. Повышение приватности использования трафика создаёт проблему безопасности в корпоративных сетях. Активное шифрование DNS-трафика формирует слепую зону для SOC-аналитиков, повышая вероятность укрытия вредоносной активности в одном из таких туннелей. Классический DNS всегда был одним из главных источников информации о состоянии сети для аналитиков. По логам резолвера можно было отследить заражение, выявить утечку данных или заблокировать обращение к C2-серверу ещё до установки соединения. Но с появлением DoT и DoH анализировать DNS-трафик стало практически невозможно без специализированных решений.
Зачастую в корпоративных сетях DNS-резолверы выполняют не только функцию разрешения доменных имён, но и играют роль фильтра. С их помощью блокируются не только домены из категорий безопасности, но и ресурсы, не связанные с выполнением рабочих задач (социальные сети, торренты, разнообразные развлекательные порталы и т. д.), а также сайты, доступ к которым должен быть ограничен законодательными требованиями регуляторов. DoT и DoH создают в этой системе брешь. Трафик уходит на DNS-серверы, минуя корпоративные фильтры. В результате организация теряет контроль над тем, к каким ресурсам обращаются её сотрудники, а выстроенные политики безопасности оказываются фактически нерабочими.
Третьим недостатком этих технологий является иллюзия полной приватности. Переход на DoH и DoT создаёт у пользователя ощущение полной защищённости. Да, шифрование действительно скрывает содержимое DNS-запросов от локальной сети, однако часть информации остаётся в открытом виде. SNI (Server Name Indication) раскрывает имя самого резолвера на этапе рукопожатия, а имя запрашиваемого домена становится видно при последующем HTTPS-соединении с целевым сервером. Помимо SNI, в открытом виде остаются IP-адреса конечных серверов и паттерны трафика. В итоге вместо повышения приватности контроль над DNS-запросами смещается с локального DNS-сервера на публичный резолвер.
Влияние на SOC
SOC является одним из основных элементов эшелонированной защиты сети. Каждый хост в сети генерирует тысячи DNS-запросов в сутки, и паттерны этих обращений позволяют выявлять аномалии ещё на ранних стадиях компрометации. Внедрение DoT и DoH лишает SOC этого источника данных, что повышает вероятность успешной реализации следующих угроз:
- DGA-активность — сетевое поведение, при котором зараженный хост массово и быстро опрашивает псевдослучайные доменные имена. Вредоносное ПО перебирает сгенерированные алгоритмом варианты, пока не попадет на домен, заранее зарегистрированный злоумышленником для связи с C2-сервером. Для аналитика это выглядит как аномальный всплеск уникальных DNS-запросов с одного узла и большое количество ответов об отсутствии домена (NXDOMAIN).
- Эксфильтрация через DNS-туннели — техника скрытого вывода информации, при которой злоумышленник использует DNS как нелегитимный канал связи. Конфиденциальные данные кодируются и встраиваются в имена поддоменов запросов, отправляемых на подконтрольный атакующему сервер. Признаками эксфильтрации являются неестественно длинные поддомены с высокой энтропией, резкие всплески запросов к одному домену, аномальный объем DNS-трафика от конкретного хоста и нетипично частое использование TXT-записей.
- C2-коммуникация — процесс, при котором зараженный хост обращается к инфраструктуре управления и контроля злоумышленника через DNS. Вредоносное ПО использует DNS как первичный или резервный канал для получения команд или загрузки дополнительных модулей. Обнаружить это можно через периодические обращения к недавно зарегистрированным доменам (NRD), регулярные запросы к подозрительным TLD-зонам, частую смену IP-адресов, связанных с одним доменом (fast-flux), и аномальную периодичность DNS-запросов от конкретного хоста.
- Тайпсквоттинг и фишинг — метод обмана пользователей, при котором злоумышленник регистрирует доменное имя, визуально имитирующее легитимные корпоративные или партнерские ресурсы с помощью опечаток, замены символов или добавления дефисов (например, g00gle.com, glthub.com и т.д.). Зачастую такие адреса используются для кражи учетных данных или доставки вредоносного ПО. Выявление подобных угроз строится на анализе сходства запрошенных имен с доверенными доменами, однако шифрование DNS полностью скрывает факт обращения хоста к поддельному ресурсу.
- Beaconing-активность — регулярные, периодичные сеансы связи зараженного хоста с управляющим сервером. Вредоносное ПО использует такие запросы для получения новых команд, поддержания персистентности или синхронизации, стараясь максимально сливаться с фоновым сетевым шумом. В открытом трафике выявить подобные «маяки» позволяет строгая математическая периодичность запросов, минимальный разброс интервалов (джиттер) и циклический характер обращений к одним и тем же поддоменам.
И это список только наиболее часто встречающихся угроз, от которых способен защитить SOC, опираясь на одни лишь DNS-логи. Шифрование DNS-трафика в корпоративных сетях системно снижает эффективность обнаружения угроз, и без этого источника телеметрии центр мониторинга теряет возможность предотвращать инциденты на ранних стадиях и вынужден реагировать на компрометацию постфактум, когда ущерб уже нанесен.
Как вернуть контроль над зашифрованным трафиком
Если для того, чтобы запретить весь DoT трафик в сети, необходимо всего лишь заблокировать 853-й порт, то в случае с DoH всё намного сложнее. Блокировка HTTPS может привести к полной недоступности всех сайтов на устройстве с настроенным DoH. Так что же делать в таком случае? Даже несмотря на шифрование, есть способы мониторить DoH и DoT трафик.
Первый из способов — это использовать облачные DNS-сервисы, поддерживающие DoT и DoH. Достаточно указать поставщика в настройках любого современного браузера, и весь DNS-трафик браузера будет направляться через корпоративный аккаунт этого провайдера, что позволяет, помимо DNS-логирования DoH- и DoT-трафика, применять политики фильтрации, блокировать обращения к вредоносным или нежелательным доменам непосредственно на уровне резолвера.
Однако в таком случае не будет логироваться системный трафик от других приложений. Можно настроить DoH на роутере, но в таком случае при просмотре DNS-логов все устройства, подключенные к одному маршрутизатору, будут иметь один IP-адрес, что усложняет проведение расследования. Для решения данной проблемы некоторые сервисы облачной DNS-фильтрации предоставляют агентские приложения, которые устанавливаются на каждый хост в сети. Это позволяет просматривать DNS-логи даже при включенном шифровании трафика.
Второй способ — это мониторинг трафика на конечных устройствах с помощью EDR или XDR. Агенты EDR способны перехватить DNS-запрос на уровне операционной системы до этапа шифрования и отправить в SOC статистику о запрашиваемом доменном имени, процессе, инициировавшем запрос, и о пользователе, с чьего устройства была осуществлена попытка разрешения домена.
Третий способ — это принудительная расшифровка трафика (SSL/TLS-инспекция). Корпоративный прокси-сервер или межсетевой экран/NGFW выступает в роли доверенного посредника. На устройства сотрудников устанавливается корпоративный сертификат, который позволяет оборудованию перехватывать зашифрованные HTTPS-соединения, включая DoH-трафик. Прокси расшифровывает запрос, фиксирует имя домена для отправки в SOC, а затем заново шифрует данные и отправляет их дальше на резолвер.
Также при использовании корпоративного или облачного DNS-сервера рекомендуется принудительно блокировать публичные резолверы. В противном случае сотрудники могут сменить настройки DNS в операционной системе или браузере на публичные адреса (например, 8.8.8.8 или 1.1.1.1). Это позволит им легко обойти корпоративные политики фильтрации и логирования, полностью выведя свой трафик из-под контроля SOC.
Заключение
Как и любая технология, направленная на повышение безопасности, DoH и DoT могут быть обращены во вред. Шифрование запросов отлично защищает от перехвата и подмены, но одновременно предоставляет злоумышленникам готовый инструмент для маскировки своих действий внутри корпоративной сети.
Внедрять эти протоколы в компаниях можно и нужно, но только при условии, что у организации есть технические возможности для их контроля. Без соответствующих мер по инспекции и логированию трафика использование DoH и DoT создает условия, при которых вредоносная активность может оставаться необнаруженной.
