Минимизиране на рисковете при използване на 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.

• Като алтернатива, можете напълно да блокирате трафика ‘dns-over-tls’ през порт 853 с помощта на App-ID. Обикновено той е блокиран по подразбиране, не са необходими действия (освен ако не сте разрешили приложението ‘dns-over-tls’ или трафика през порт 853).

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