Минимизирање на ризиците од користење на DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)

Минимизирање на ризиците од користење на DoH и DoT

DoH и DoT заштита

Дали го контролирате вашиот DNS сообраќај? Организациите инвестираат многу време, пари и напор во обезбедувањето на нивните мрежи. Сепак, една област која често не добива доволно внимание е DNS.

Добар преглед на ризиците што ги носи DNS е Презентација на Verisign на конференцијата за Инфосигурност.

31% од испитаните класи на откупни софтвер користеле DNS за размена на клучеви.Наоди од студијата

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

Проблемот е сериозен. Според истражувачката лабораторија Palo Alto Networks Unit 42, приближно 85% од малициозниот софтвер користи DNS за да воспостави канал за команда и контрола, дозволувајќи им на напаѓачите лесно да инјектираат малициозен софтвер во вашата мрежа, како и да крадат податоци. Од своето основање, сообраќајот DNS во голема мера е нешифриран и може лесно да се анализира со безбедносните механизми NGFW. 

Се појавија нови протоколи за DNS со цел да се зголеми доверливоста на DNS конекциите. Тие се активно поддржани од водечки продавачи на прелистувачи и други продавачи на софтвер. Шифрираниот DNS сообраќај наскоро ќе почне да расте во корпоративните мрежи. Шифрираниот DNS сообраќај кој не е правилно анализиран и решен со алатки претставува безбедносен ризик за компанијата. На пример, таква закана се криптолокерите кои користат DNS за размена на клучеви за шифрирање. Напаѓачите сега бараат откуп од неколку милиони долари за да го вратат пристапот до вашите податоци. Garmin, на пример, плати 10 милиони долари.

Кога се правилно конфигурирани, NGFWs може да ја негираат или заштитат употребата на 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 (Transport Layer Security) за да воспостават шифрирана врска помеѓу клиентот што поставува прашања и серверот што решава 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. Мајкрософт исто така развива планови за интегрирање на DoH во нивните оперативни системи. Негативната страна е што не само угледните софтверски компании, туку и напаѓачите почнаа да го користат DoH како средство за заобиколување на традиционалните мерки на корпоративниот заштитен ѕид. (На пример, прегледајте ги следните написи: PsiXBot сега користи Google DoH , PsiXBot продолжува да се развива со ажурирана DNS инфраструктура и Анализа на задна врата на Годлуа .) Во секој случај, и добриот и злонамерниот сообраќај на DoH ќе останат неоткриени, оставајќи ја организацијата слепа за злонамерната употреба на DoH како канал за контрола на малициозен софтвер (C2) и кражба на чувствителни податоци.

Обезбедување видливост и контрола на сообраќајот на DoH

Како најдобро решение за контрола на DoH, препорачуваме да го конфигурирате NGFW за дешифрирање на сообраќајот HTTPS и блокирање на сообраќајот DoH (име на апликација: dns-over-https). 

Прво, проверете дали NGFW е конфигуриран да дешифрира HTTPS, според водич за најдобри техники за дешифрирање.

Второ, креирајте правило за сообраќај на апликации „dns-over-https“ како што е прикажано подолу:

Правило NGFW на мрежите на Пало Алто за блокирање на DNS-преку HTTPS

Како привремена алтернатива (ако вашата организација не имплементирала целосно HTTPS дешифрирање), NGFW може да се конфигурира да примени дејство „негира“ на ID на апликацијата „dns-over-https“, но ефектот ќе биде ограничен на блокирање одредени добро- познати DoH сервери по нивното име на домен, па како без HTTPS дешифрирање, сообраќајот DoH не може целосно да се провери (види  Апликација од 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 безбедност за контрола на DGA домени или постоечки DNS Sinkholing и анти-шпионски софтвер.

• Алтернатива е моторот на App-ID целосно да го блокира сообраќајот „dns-over-tls“ на портата 853. Ова обично е стандардно блокирано, не е потребно дејство (освен ако конкретно не дозволите „dns-over-tls“ сообраќајот на апликацијата или пристаништето 853).

Извор: www.habr.com