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

Минимизиране на рисковете от използването на DoH и DoT

DoH и DoT защита

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

Един добър преглед на рисковете, които DNS носи е Презентация на Verisign на конференцията Infosecurity.

31% от анкетираните класове ransomware използват DNS за обмен на ключове. Констатации от проучването

31% от анкетираните класове ransomware използват 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-над-HTTPS (DoH)

2. DNS-over-TLS (DoT)

Тези протоколи имат едно общо нещо: те умишлено скриват DNS заявките от всяко прихващане... както и от охраната на организацията. Протоколите основно използват TLS (сигурност на транспортния слой), за да установят криптирана връзка между клиент, който прави заявки, и сървър, разрешаващ DNS заявки през порт, който обикновено не се използва за DNS трафик.

Поверителността на DNS заявките е голям плюс на тези протоколи. Те обаче създават проблеми за охранителите, които трябва да наблюдават мрежовия трафик и да откриват и блокират злонамерени връзки. Тъй като протоколите се различават по тяхното изпълнение, методите за анализ ще се различават между DoH и DoT.

DNS над 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", както е показано по-долу:

Правило NGFW на Palo Alto Networks за блокиране на DNS през HTTPS

Като междинна алтернатива (ако вашата организация не е внедрила напълно HTTPS декриптиране), NGFW може да бъде конфигуриран да прилага действие „отказ“ към идентификатора на приложението „dns-over-https“, но ефектът ще бъде ограничен до блокиране на някои добре- известни DoH сървъри по тяхното име на домейн, така че как без HTTPS декриптиране, DoH трафикът не може да бъде напълно проверен (вж.  Applipedia от Palo Alto Networks   и потърсете „dns-over-https“).

DNS през 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 приложение, към което можете да приложите всяко действие, като активиране на абонамент DNS сигурност на Palo Alto Networks за контролиране на DGA домейни или съществуващ такъв DNS Sinkholing и антишпионски софтуер.

• Алтернатива е механизмът на App-ID да блокира напълно трафика „dns-over-tls“ на порт 853. Това обикновено е блокирано по подразбиране, не е необходимо действие (освен ако изрично не разрешите „dns-over-tls“ приложение или порт 853 Серия

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