Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)

Минимизация рисков использования DoH и DoT

Защита от DoH и DoT

Контролируете ли вы свой DNS трафик? Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Однако, одной из областей, которой часто не уделяется должного внимания, является DNS.

Хорошим обзором рисков, которые приносит DNS является презентация Verisign на конференции Infosecurity.

31% обследованных классов программ-вымогателей использовали DNS для обмена ключами.Выводы исследования

31% обследованных классов программ-вымогателей использовали DNS для обмена ключами.

Проблема серьезная. По данным исследовательской лаборатории Palo Alto Networks Unit 42, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW. 

Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.

При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.

Что такое зашифрованный DNS?

Что такое DNS

Система доменных имен (DNS) преобразует удобочитаемые человеку доменные имена (например, адрес www.paloaltonetworks.com ) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.

Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или изменения ответа и перенаправления браузера на вредоносные сервера. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. Шифрование DNS запросов и ответов защищает вас от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом. 

За последние несколько лет были внедрены два протокола шифрования DNS:

1. DNS-over-HTTPS (DoH)

2. DNS-over-TLS (DoT)

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

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

DNS over HTTPS (DoH)

DNS внутри HTTPS

DoH использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы «смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении», «затруднить анализ трафика DNS» и, таким образом, обойти меры корпоративного контроля ( RFC 8484 DoH, раздел 8.1 ). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.

Риски, связанные с DoH

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

И Google, и Mozilla реализовали возможности DoH в последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS. Microsoft также разрабатывает планы по интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи: PsiXBot теперь использует Google DoH , PsiXBot продолжает развиваться с обновленной инфраструктурой DNS и анализ бэкдора Godlua .) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.

Обеспечение видимости и контроля трафика DoH

В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https). 

Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.

Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:

Правило Palo Alto Networks NGFW для блокировки DNS-over-HTTPS

В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см.  Applipedia от Palo Alto Networks   и выполните поиск по фразе «dns-over-https»).

DNS over TLS (DoT)

DNS внутри TLS

В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует специальный порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS ( RFC 7858 , Раздел 3.1 ).

Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 ( RFC 7858, раздел 6 ).  Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.

Риски, связанные с DoT

Google реализовал DoT в своем клиенте Android 9 Pie и более поздних версиях , при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.

Обеспечение видимости и контроля трафика DoT

В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:

• Настройте NGFW для расшифрования всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.

• В качестве альтернативы можно полностью заблокировать движком App-ID трафик ‘dns-over-tls’ через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение ‘dns-over-tls’ или трафик через порт 853).

Источник: habr.com