Использование DoH в корпоративных сетях

Муслим Меджлумов

Введение

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

• резолвинг известных доменов, используемых для Command and Control (С2) серверов злоумышленников;
• резолвинг фишинговых доменов или доменов, используемых для распространения вредоносного программного обеспечения (ВПО);
• работу DGA (Domain Generation Algorithm);
• эксфильтрацию данных (DNS-туннели, DNS-FTP);
• аномалии в DNS (новые домены, нетипичный всплеск обращений к домену с одного или множества хостов внутри сети и т.д.).

В случае работы DNS поверх UDP или TCP для анализа трафика возможно использование следующих методов.

1. Пассивные:

• сбор логов с корпоративного рекурсивного DNS-резолвера и последующий анализ в одном из инструментов LM (Log Management) или SIEM (Security Information and Event Management);
• передача копии (SPAN/PortMirroring) трафика в систему обнаружения вторжений IPS/IDS.

2. Активные:

• Next-Generation Firewall;
• рекурсивный DNS-сервер с функциональностью безопасности (далее Secure DNS).

В 2018 году был принят новый стандарт DNS Queries over HTTPS (DoH, https://datatracker.ietf.org/doc/rfc8484/), который определяет возможность передачи DNS-запросов поверх HTTPS, тем самым обеспечивая их конфиденциальность. С тех пор поддержка DoH появилась:

• у облачных DNS-провайдеров (например, CloudFlare, Google Public DNS, BlahDNS и др.);
• в DNS-серверах BIND, Unbound, PowerDNS;
• в браузерах (Firefox, Chrome, Microsoft Edge на основе Chromium, Opera);
• в ОС (Windows 10, MacOS 11 Big Sur);
• в мобильных OC (Apple iOS 14).

Изначально в основе идеи DoH стоит возможность анонимизации пользовательской активности, чтобы операторы связи, правоохранительные органы или иные государственные службы не могли анализировать DNS-трафик граждан, при этом сотрудники организаций также могут настроить свои браузеры для работы с DoH-серверами и оставаться неподконтрольными для служб информационной безопасности. Злоумышленники также понимают, что DoH позволяет им обходить пассивные инструменты мониторинга DNS и часть активных, поэтому начали использовать его в качестве канала коммуникации для ВПО (например, https://blog.netlab.360.com/an-analysis-of-godlua-backdoor-en/). В итоге, из перечисленных выше методов анализа DNS-трафика в случае с DoH работать в полной мере будет только в Secure DNS, который поддерживает DoH и соответственно терминирует сессию и самостоятельно обрабатывает DNS-запросы.

Далее будет представлен подход, который мы реализовали в ООО «БИЗон» и который позволяет обеспечить работоспособность и безопасность DoH в корпоративной среде.

Ввиду того, что внутри предприятия, как и за его пределами, использовались решения, не предоставляющие функционал DoH, было принято решение в качестве отправной точки взять кеширующий/рекурсивный DNS-резолвер с открытым кодом Unbound https://nlnetlabs.nl/projects/unbound/about/ и реализовать недостающий нам функционал, тем самым получить свою реализацию Secure DNS. Старт реализации необходимого нам функционала был в начале 2020 года; на тот момент DoH в основной ветке еще не был реализован. По результатам проекта был реализован протокол DoH, защита от несанкционированного использования рекурсивного DoH-резолвера в публичных сетях. Помимо функционала, реализующего DoH, были добавлены функции фильтрации доменов на основе известных вредоносных доменов, категорий ограниченного контента, информации о репутации, защиты от эксфильтрации трафика.

Предварительные мероприятия

При внедрении DoH на предприятии необходимо произвести ряд мероприятий, связанных с исключением использования DoH-резолверов, неподконтрольных службе информационной безопасности предприятия, а именно:

1. Ограничить доступ из внутреннего периметра сети предприятия к внешним DoH-резолверам. Для этого на периметровых устройствах сетевой безопасности необходимо создать правила, блокирующие доступ к публичным DoH-резолверам на L4-устройствах, список которых можно почерпнуть по ссылке https://raw.githubusercontent.com/oneoffdallas/dohservers/master/list.txt. На UTM/NGFW- устройствах необходимо включить блокировку DoH-приложений.

2. В случае предоставления сотрудникам предприятия доступа к веб-ресурсам, расположенным в сети Интернет, обеспечить его через HTTP-proxy-серверы. На последних необходимо создать правила фильтрации на основе URI и/или HTTP-заголовка Content-Type.

Давайте рассмотрим вариант фильтрации на примере ACL популярного HTTP-proxy с открытым кодом squid.

acl dns-query-url urlpath_regex ^/dns-query\??
acl dns-req-message req_header Content-Type ^application/dns-(?:message|json)}$
acl doh_request any-of dns-query-url dns-req-message
acl doh_reply rep_header Content-Type ^application/dns-(?:message|json)$

Вышеописанные действия позволят предотвратить скрытые действия злоумышленников через публичные DoH-резолверы.

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

Использование нескольких рекурсивных резолверов для внутренних и внешних преобразований

Для использования DoH на предприятии в разных сегментах сети (внутренний и внешний) развернут сервис Secure DNS, который будет обслуживать мобильных и удаленных пользователей предприятия. Secure DNS будет предоставлять функции DoH-резолвера, а также фильтрацию на основе категорий ограниченного контента, защиту от эксфильтрации трафика, фильтрацию на основе регулярных выражений доменов, фильтрацию доменов и IP-адресов на основе известных вредоносных доменов, информации о репутации, проверки расширений безопасности DNS (Aggressive Use of DNSSEC-Validated Cache, Query Name Minimisation и т.д.).

На DNS-серверах предприятия, обслуживающих зону example.com (здесь и далее этот домен используется лишь в качестве примера), как внутренних, так и внешних, регистрируется домен doh.example.com. Для зарегистрированного доменного имени doh.example.com создается пара ключей для взаимодействия через TLS, сертификат подписывается общеизвестными удостоверяющими центрами (список УЦ можно получить из хранилище SSL-сертификатов операционной системы либо из настроек веб-браузеров). Выпущенные сертификаты размещаются на экземплярах Secure DNS. После этого Secure DNS может принимать запросы на резволвинг от клиентов через протокол DoH.

Через корпоративные политики производится конфигурирование устройств с использованием доменного имени Secure DNS с указанием уникального идентификатора организации – токена безопасности (например, https:// doh.example.com/7300211b-aa0c-457f-9ce7-1ffa2a1dc956). Использование токена позволяет прикрыть Secure DNS от несанкционированного использования кем-либо из сети Интернет.

После проведенных мероприятий пользователи, находясь в локальной сети предприятия, могут использовать внутренний Secure DNS для получения как локальных имен, так и глобальных имен, полученных от авторитативных DNS-серверов, расположенных за пределами сети предприятия.

Мобильные или удаленные сотрудники, находясь за пределами сети предприятия, используя небезопасные подключения к сети (открытые точки доступа Wi-Fi, сети операторов мобильной связи, домашний Интернет), будут использовать корпоративный DoH-резолвер (Secure DNS), расположенный в DMZ предприятия, а не назначенные через DHCP DNS-резолверы, предоставленные к использованию небезопасной сетью. Это позволить уменьшить вероятность утечек приватных доменных имен предприятия.

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

Рассмотрим вариант использования Secure DNS пользователями (мобильными и удаленными сотрудниками), использующими небезопасные подключения к сети (Рис. 1.)

Удаленный сотрудник пользуется публичным Wi-Fi в кафе без подключения к VPN предприятия и начинает использовать ресурсы, расположенные в Интернете. При подключении к публичной Wi-Fi-сети устройство сотрудника через протокол DHCP получает настройки DNS-резолверов, работающих через традиционный транспорт 53 UDP/TCP.  На устройстве пользователя в настройках DoH указан Secure DNS с корректными токеном организации.

Пользователь открывает веб-браузер и подключается к веб-ресурсу. Веб-браузер, имея настройки DoH и не имея в своем кэше информации о домене doh.example.com, пытается с помощью системного DNS-резолвера получить информацию об IP-адресе домена doh.example.com, отправляя запрос к DNS-серверу публичной Wi-Fi-сети (1). DNS-сервер публичной Wi-Fi-сети, не имея в своем кэше информации о домене doh.example.com, отправляет запрос к авторитативному DNS-серверу, отвечающему за DNS-зону example.com (2). В описании данного процесса пропущены шаги, связанные с поиском авторитативного DNS-сервера (example.com). На шаге (3, 4) авторитативный DNS возвращает информацию о публичных IP-адресах Secure DNS. Только описанные шаги 1-4 используют традиционный транспорт UDP/TCP по 53 порту, весь остальной поиск и резолвинг имен будет производиться по защищённому протоколу.

DoH-резолвер веб-браузера, имея информацию об IP-адресах, начинает взаимодействовать с рекурсивным DoH-резолвером предприятия (5).

В процессе взаимодействия веб-браузера и рекурсивного Secure DNS (рассмотрим только такой запрос, который удовлетворяет всем политикам, принятым на предприятии, и информации о домене нет в кэше):

• проверяется корректность токена безопасности в запросе (6);
• проверяются политики предприятия на резолвинг домена (фильтрации доменов на основе известных вредоносных доменов, категорий ограниченного контента, информации о репутации, детектирование от эксфильтрации трафика, DGA и т.п.) (7);
• проверяется наличие информации о домене в кэше экземпляра рекурсивного резолвера (8).

В процессе обработки запроса происходит обогащение событий и журналирование таких событий (9).

После произведенных проверок, связанных с политиками, принятыми на предприятии, Secure DNS производит рекурсивный поиск информации о домене (9), отправляя запросы к авторитативным DNS-серверам, расположенным в сети Интернет (10). Secure DNS, получив ответы (11), прогоняет тесты с применением функционала Aggressive Use of DNSSEC-Validated Cache, Query Name Minimisation и т.п., отправляет информацию о запрошенном доменном имени веб-браузеру удаленного сотрудника (12).

Мы рассмотрели положительный сценарий, когда запрос доменного имени удовлетворяет всем политикам, принятым на предприятии. В случае нарушения политик, принятых на предприятии, Secure DNS может прекратить процесс резолвинга, вернуть ошибку или вернуть IP-адрес страницы заглушки с пояснением причины блокировки инициатору запроса (веб-браузеру).

Далее рассмотрим варианты использования Secure DNS мобильными и стационарными пользователями, использующими подключения к локальной сети предприятия (Рис. 2.)

Мобильный сотрудник, вернувшись на площадку предприятия, подключается в локальную проводную или беспроводную сеть предприятия и начинает использовать ресурсы предприятия, расположенные как в локальной сети, так в сети Интернет. При подключении Wi-Fi-сети предприятия устройство сотрудника через протокол DHCP получает настройки DNS-резолверов, работающих через традиционный транспорт 53 UDP/TCP, также расположенный на кэширующем рекурсивном резолвере Secure DNS.

Совмещение DoH и традиционного рекурсивного резолвера позволяет кэшировть информацию как о приватных, так и о глобальных доменных именах.

Пользователь открывает веб-браузер и подключается к веб-ресурсу. Веб-браузер, имея настройки DoH и не имея в своем кэше информации о домене doh.example.com, пытается с помощью системного DNS-резолвера получить информацию об IP-адресе домена doh.example.com, отправляя запрос через традиционный транспорт (DNS over UDP) к Secure DNS (1). Secure DNS локальной сети, не имея в своем кэше информации о домене doh.example.com, отправляет запрос к приватному авторитативному DNS-серверу (размещенному внутри периметра сети предприятия), отвечающему за DNS-зону example.com. Так как Secure DNS сконфигурирован на пересылку всех запросов к зоне example.com на конкретные приватные IP-адреса внутри локальной сети, политики безопасности к таким запросам применяться не будут. Запросы будут перенаправлены на приватные авторитативные DNS-серверы корпоративного домена example.com (2). Запросы также будут зафиксированы в журнале (9). На шаге (3) авторитативный DNS возвращает информацию о приватных IP-адресах DoH-резолверов на кеширующий DNS-сервер (Secure DNS). Secure DNS возвращает инициатору запроса информацию о приватных IP-адресах в домене doh.example.com.

DoH-резолвер веб-браузера, имея информацию об IP-адресах, начинает взаимодействовать с локальным Secure DNS (5).

Далее процесс (6-12) идентичен описанному ранее.

Мы рассмотрели процессы, которые происходят во время работы протокола DNS, но не затронули процесс конфигурирования DoH-клиентов.

Опишем процесс настройки корпоративной политики Chrome Enterprise.

Настройки политик использования DNS-over-HTTPS в Chrome Enterprise

Опишем имеющиеся параметры конфигурации политики.

При настройке политики будет необходимо сконфигурировать пару параметров, такие как DnsOverHttpsMode и DnsOverHttpsTemplates.

Для управления политиками необходимо выбрать один из предложенных вариантов для параметра DnsOverHttpsMode:

• off: отключите DNS-over-HTTPS (Disable DNS-over-HTTPS) – Chrome никогда не отправляет DoH-запросы на DNS-серверы.
• automatic: включен DNS-over-HTTPS с небезопасным откатом. Если доступен DNS-сервер, поддерживающий DoH, Chrome сначала отправляет запрос DNS-over-HTTPS. Если получена ошибка или сервер, поддерживающий DoH, недоступен, Chrome вместо этого просто отправляет DNS-запрос на сервер, используя системный резолвер. Данная опция может быть полезна при использовании мобильных устройств в сетях с применением Captive Portal (публичные Wi-Fi-сети).
• secure: включен DNS-over-HTTPS без небезопасного отката – Chrome отправляет запросы DoH только на DNS-серверы.
• значение по умолчанию – включен DNS-over-HTTPS с небезопасным откатом.

Включая DoH на предприятии, необходимо добавить в список шаблонов URI резолверов DoH (Secure DNS). Иначе будут использоваться публичные рекурсивные DNS-резолверы Google.

Например, при использовании Secure DNS в параметре DnsOverHttpsTemplates указать URI https://doh.example.com/7300211b-aa0c-457f-9ce7-1ffa2a1dc956.

Данные параметры можно поменять через групповые политики MS AD или через скрипт, вносящий изменения в ветки реестра:


Software\Policies\Google\Chrome\DnsOverHttpsMode тип данных: строка
Software\Policies\Google\Chrome\DnsOverHttpsTemplates тип данных: строка


В итоге

DNS over HTTPS обеспечивает преимущества конфиденциальности для конечных пользователей, но может создавать проблемы для предприятий, желающих добиться защиты и видимости при работе DNS. Предприятия могут внедрить DoH в свои службы DNS для получения как преимуществ DoH, так и передовых методов защиты DNS. Однако предприятия, которые разрешают использование DoH без стратегического и тщательного подхода, в конечном итоге могут лишиться видимости DNS-трафика на средствах сетевого мониторинга, не дав им возможности обнаруживать вредоносную активность внутри сети и позволяя злоумышленникам и вредоносным программам обходить назначенные корпоративные DNS-резолверы. Часть разработок, которые были нами реализованы в собственных целях и описаны в статье, мы планируем опубликовать в корпоративном аккаунте на github.