Minimiziranje rizika korištenja DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)

Minimiziranje rizika korištenja DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)Minimiziranje rizika korištenja DoH i DoT

DoH i DoT zaštita

Kontrolirate li svoj DNS promet? Organizacije ulažu puno vremena, novca i truda u osiguranje svojih mreža. Međutim, jedno područje kojem se često ne posvećuje dovoljno pažnje je DNS.

Dobar pregled rizika koje nosi DNS je Verisign prezentacija na Infosecurity konferenciji.

Minimiziranje rizika korištenja DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)31% ispitanih klasa ransomwarea koristilo je DNS za razmjenu ključeva. Nalazi studije

31% ispitanih klasa ransomwarea koristilo je DNS za razmjenu ključeva.

Problem je ozbiljan. Prema istraživačkom laboratoriju Palo Alto Networks Unit 42, približno 85% zlonamjernog softvera koristi DNS za uspostavu naredbenog i kontrolnog kanala, što napadačima omogućuje jednostavno ubacivanje zlonamjernog softvera u vašu mrežu, kao i krađu podataka. Od svog početka, DNS promet je uglavnom nekriptiran i može se lako analizirati sigurnosnim mehanizmima NGFW. 

Pojavili su se novi protokoli za DNS s ciljem povećanja povjerljivosti DNS veza. Aktivno ih podržavaju vodeći dobavljači preglednika i drugi proizvođači softvera. Šifrirani DNS promet uskoro će početi rasti u korporativnim mrežama. Šifrirani DNS promet koji nije pravilno analiziran i riješen alatima predstavlja sigurnosni rizik za tvrtku. Na primjer, takva prijetnja su cryptolockeri koji koriste DNS za razmjenu ključeva šifriranja. Napadači sada traže otkupninu od nekoliko milijuna dolara kako bi vratili pristup vašim podacima. Garmin je, primjerice, platio 10 milijuna dolara.

Kada su ispravno konfigurirani, NGFW-ovi mogu odbiti ili zaštititi upotrebu DNS-over-TLS (DoT) i mogu se koristiti za odbijanje upotrebe DNS-over-HTTPS (DoH), dopuštajući analizu cjelokupnog DNS prometa na vašoj mreži.

Što je šifrirani DNS?

Što je DNS

Sustav naziva domene (DNS) razrješava nazive domena čitljive ljudima (na primjer, adresu www.paloaltonetworks.com ) na IP adrese (na primjer, 34.107.151.202). Kada korisnik unese naziv domene u web preglednik, preglednik šalje DNS upit DNS poslužitelju, tražeći IP adresu povezanu s tim nazivom domene. Kao odgovor, DNS poslužitelj vraća IP adresu koju će ovaj preglednik koristiti.

DNS upiti i odgovori šalju se mrežom u obliku običnog teksta, nekriptirani, što ga čini ranjivim na špijuniranje ili promjenu odgovora i preusmjeravanje preglednika na zlonamjerne poslužitelje. DNS enkripcija otežava praćenje ili promjenu DNS zahtjeva tijekom prijenosa. Šifriranje DNS zahtjeva i odgovora štiti vas od Man-in-the-Middle napada dok obavlja iste funkcije kao tradicionalni DNS (Domain Name System) protokol otvorenog teksta. 

Tijekom proteklih nekoliko godina uvedena su dva protokola za šifriranje DNS-a:

  1. DNS-over-HTTPS (DoH)

  2. DNS-over-TLS (DoT)

Ovi protokoli imaju jednu zajedničku stvar: oni namjerno skrivaju DNS zahtjeve od bilo kakvog presretanja... kao i od zaštitara organizacije. Protokoli prvenstveno koriste TLS (Transport Layer Security) za uspostavljanje šifrirane veze između klijenta koji postavlja upite i poslužitelja koji rješava DNS upite preko priključka koji se inače ne koristi za DNS promet.

Povjerljivost DNS upita veliki je plus ovih protokola. Međutim, oni predstavljaju probleme za zaštitare koji moraju nadzirati mrežni promet te otkrivati ​​i blokirati zlonamjerne veze. Budući da se protokoli razlikuju u svojoj implementaciji, metode analize će se razlikovati između DoH i DoT.

DNS preko HTTPS-a (DoH)

Minimiziranje rizika korištenja DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)DNS unutar HTTPS-a

DoH koristi dobro poznati port 443 za HTTPS, za koji RFC posebno navodi da je namjera "pomiješati DoH promet s drugim HTTPS prometom na istoj vezi", "otežati analizu DNS prometa" i na taj način zaobići korporativne kontrole ( RFC 8484 DoH odjeljak 8.1 ). Protokol DoH koristi TLS enkripciju i sintaksu zahtjeva koju pružaju uobičajeni HTTPS i HTTP/2 standardi, dodajući DNS zahtjeve i odgovore povrh standardnih HTTP zahtjeva.

Rizici povezani s DoH

Ako ne možete razlikovati uobičajeni HTTPS promet od DoH zahtjeva, tada aplikacije unutar vaše organizacije mogu (i hoće) zaobići lokalne DNS postavke preusmjeravanjem zahtjeva na poslužitelje trećih strana koji odgovaraju na DoH zahtjeve, čime se zaobilazi bilo kakav nadzor, odnosno uništava mogućnost kontrolirati DNS promet. U idealnom slučaju, trebali biste kontrolirati DoH pomoću HTTPS funkcija dešifriranja. 

И Google i Mozilla implementirali su DoH mogućnosti u najnovijoj verziji svojih preglednika, a obje tvrtke rade na korištenju DoH-a prema zadanim postavkama za sve DNS zahtjeve. Microsoft također razvija planove o integraciji DoH-a u njihove operativne sustave. Nedostatak je to što su ne samo ugledne softverske tvrtke, već i napadači počeli koristiti DoH kao sredstvo za zaobilaženje tradicionalnih korporativnih mjera vatrozida. (Na primjer, pregledajte sljedeće članke: PsiXBot sada koristi Google DoH , PsiXBot se nastavlja razvijati s ažuriranom DNS infrastrukturom и Godlua backdoor analiza .) U oba slučaja, i dobar i zlonamjerni promet DoH-a proći će neotkriven, ostavljajući organizaciju slijepom za zlonamjernu upotrebu DoH-a kao kanala za kontrolu zlonamjernog softvera (C2) i krađu osjetljivih podataka.

Osiguravanje vidljivosti i kontrole DoH prometa

Kao najbolje rješenje za DoH kontrolu, preporučujemo konfiguriranje NGFW-a za dekriptiranje HTTPS prometa i blokiranje DoH prometa (naziv aplikacije: dns-over-https). 

Prvo provjerite je li NGFW konfiguriran za dekriptiranje HTTPS-a, prema vodič kroz najbolje tehnike dešifriranja.

Drugo, stvorite pravilo za promet aplikacije "dns-over-https" kao što je prikazano u nastavku:

Minimiziranje rizika korištenja DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)Palo Alto Networks NGFW pravilo za blokiranje DNS-over-HTTPS

Kao privremena alternativa (ako vaša organizacija nije u potpunosti implementirala dešifriranje HTTPS-a), NGFW se može konfigurirati za primjenu radnje "zabrani" na ID aplikacije "dns-over-https", ali učinak će biti ograničen na blokiranje određenih dobro- poznatih DoH poslužitelja prema njihovom nazivu domene, pa kako bez HTTPS dešifriranja, DoH promet ne može biti u potpunosti pregledan (pogledajte  Applipedia tvrtke Palo Alto Networks   i potražite "dns-over-https").

DNS preko TLS-a (DoT)

Minimiziranje rizika korištenja DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH)DNS unutar TLS-a

Dok se DoH protokol ima tendenciju miješati s drugim prometom na istom priključku, DoT umjesto toga prema zadanim postavkama koristi poseban priključak rezerviran za tu jedinu svrhu, čak izričito zabranjujući da isti priključak koristi tradicionalni nekriptirani DNS promet ( RFC 7858, odjeljak 3.1 ).

DoT protokol koristi TLS za pružanje enkripcije koja enkapsulira standardne upite DNS protokola, s prometom koji koristi dobro poznati port 853 ( RFC 7858 odjeljak 6 ). Protokol DoT osmišljen je kako bi organizacijama olakšao blokiranje prometa na portu ili prihvaćanje prometa, ali omogućivanje dešifriranja na tom portu.

Rizici povezani s DoT-om

Google je implementirao DoT u svom klijentu Android 9 Pie i noviji , sa zadanom postavkom da automatski koristi DoT ako je dostupan. Ako ste procijenili rizike i spremni ste koristiti DoT na organizacijskoj razini, tada trebate imati mrežne administratore koji izričito dopuste odlazni promet na portu 853 kroz svoj perimetar za ovaj novi protokol.

Osiguravanje vidljivosti i kontrole DoT prometa

Kao najbolju praksu za kontrolu DoT-a, preporučujemo bilo što od gore navedenog, na temelju zahtjeva vaše organizacije:

  • Konfigurirajte NGFW da dekriptira sav promet za odredišni port 853. Dešifriranjem prometa, DoT će se pojaviti kao DNS aplikacija na koju možete primijeniti bilo koju radnju, kao što je omogućavanje pretplate DNS sigurnost mreže Palo Alto za kontrolu DGA domena ili postojeće DNS Sinkholing i protiv špijunskog softvera.

  • Alternativa je da mehanizam App-ID potpuno blokira promet 'dns-over-tls' na portu 853. To je obično blokirano prema zadanim postavkama, nije potrebna nikakva radnja (osim ako izričito ne dopustite 'dns-over-tls' aplikaciju ili port promet 853).

Izvor: www.habr.com

Dodajte komentar