Minimering af risikoen ved at bruge DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)

Minimering af risikoen ved at bruge DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)Minimering af risikoen ved at bruge DoH og DoT

DoH og DoT beskyttelse

Styrer du din DNS-trafik? Organisationer investerer meget tid, penge og kræfter i at sikre deres netværk. Et område, der ofte ikke får nok opmærksomhed, er DNS.

Et godt overblik over de risici, som DNS medfører, er Verisign præsentation på Infosecurity-konferencen.

Minimering af risikoen ved at bruge DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)31 % af de adspurgte ransomwareklasser brugte DNS til nøgleudveksling. Undersøgelsesresultater

31 % af de adspurgte ransomwareklasser brugte DNS til nøgleudveksling.

Problemet er alvorligt. Ifølge Palo Alto Networks Unit 42 forskningslaboratorium bruger cirka 85 % af malware DNS til at etablere en kommando- og kontrolkanal, hvilket gør det muligt for angribere nemt at injicere malware i dit netværk samt stjæle data. Siden starten har DNS-trafik stort set været ukrypteret og kan nemt analyseres af NGFW-sikkerhedsmekanismer. 

Nye protokoller til DNS er dukket op med det formål at øge DNS-forbindelsernes fortrolighed. De understøttes aktivt af førende browserleverandører og andre softwareleverandører. Krypteret DNS-trafik vil snart begynde at vokse i virksomhedens netværk. Krypteret DNS-trafik, der ikke er korrekt analyseret og løst af værktøjer, udgør en sikkerhedsrisiko for en virksomhed. For eksempel er en sådan trussel kryptologere, der bruger DNS til at udveksle krypteringsnøgler. Angribere kræver nu en løsesum på flere millioner dollars for at genoprette adgangen til dine data. Garmin betalte for eksempel 10 millioner dollars.

Når de er korrekt konfigureret, kan NGFW'er nægte eller beskytte brugen af ​​DNS-over-TLS (DoT) og kan bruges til at nægte brugen af ​​DNS-over-HTTPS (DoH), så al DNS-trafik på dit netværk kan analyseres.

Hvad er krypteret DNS?

Hvad er DNS

Domain Name System (DNS) løser menneskelæselige domænenavne (f.eks. adresse www.paloaltonetworks.com ) til IP-adresser (f.eks. 34.107.151.202). Når en bruger indtaster et domænenavn i en webbrowser, sender browseren en DNS-forespørgsel til DNS-serveren og beder om den IP-adresse, der er knyttet til det pågældende domænenavn. Som svar returnerer DNS-serveren den IP-adresse, som denne browser vil bruge.

DNS-forespørgsler og -svar sendes på tværs af netværket i almindelig tekst, ukrypteret, hvilket gør det sårbart over for spionage eller ændring af svaret og omdirigerer browseren til ondsindede servere. DNS-kryptering gør det vanskeligt for DNS-anmodninger at blive sporet eller ændret under transmission. Kryptering af DNS-anmodninger og -svar beskytter dig mod Man-in-the-Middle-angreb, mens du udfører samme funktionalitet som den traditionelle DNS-protokol (Domain Name System). 

I løbet af de sidste par år er to DNS-krypteringsprotokoller blevet introduceret:

  1. DNS-over-HTTPS (DoH)

  2. DNS-over-TLS (DoT)

Disse protokoller har én ting til fælles: de skjuler bevidst DNS-anmodninger fra enhver aflytning... og også fra organisationens sikkerhedsvagter. Protokollerne bruger primært TLS (Transport Layer Security) til at etablere en krypteret forbindelse mellem en klient, der laver forespørgsler, og en server, der løser DNS-forespørgsler over en port, der normalt ikke bruges til DNS-trafik.

Fortroligheden af ​​DNS-forespørgsler er et stort plus ved disse protokoller. De udgør dog problemer for sikkerhedsvagter, som skal overvåge netværkstrafikken og opdage og blokere ondsindede forbindelser. Fordi protokollerne er forskellige i deres implementering, vil analysemetoderne være forskellige mellem DoH og DoT.

DNS over HTTPS (DoH)

Minimering af risikoen ved at bruge DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)DNS inde i HTTPS

DoH bruger den velkendte port 443 til HTTPS, som RFC specifikt angiver, at hensigten er at "blande DoH-trafik med anden HTTPS-trafik på samme forbindelse", "gøre det vanskeligt at analysere DNS-trafik" og dermed omgå virksomhedens kontroller ( RFC 8484 DoH Afsnit 8.1 ). DoH-protokollen bruger TLS-kryptering og anmodningssyntaksen leveret af de almindelige HTTPS- og HTTP/2-standarder, og tilføjer DNS-anmodninger og -svar oven på standard HTTP-anmodninger.

Risici forbundet med DoH

Hvis du ikke kan skelne almindelig HTTPS-trafik fra DoH-anmodninger, så kan (og vil) applikationer i din organisation omgå lokale DNS-indstillinger ved at omdirigere anmodninger til tredjepartsservere, der reagerer på DoH-anmodninger, hvilket omgår enhver overvågning, dvs. ødelægger evnen til at styre DNS-trafikken. Ideelt set bør du kontrollere DoH ved hjælp af HTTPS-dekrypteringsfunktioner. 

И Google og Mozilla har implementeret DoH-funktioner i den nyeste version af deres browsere, og begge virksomheder arbejder på at bruge DoH som standard til alle DNS-anmodninger. Microsoft er også ved at udvikle planer om at integrere DoH i deres operativsystemer. Ulempen er, at ikke kun velrenommerede softwarevirksomheder, men også angribere er begyndt at bruge DoH som et middel til at omgå traditionelle virksomhedsfirewall-foranstaltninger. (Gennemgå f.eks. følgende artikler: PsiXBot bruger nu Google DoH , PsiXBot fortsætter med at udvikle sig med opdateret DNS-infrastruktur и Godlua bagdørsanalyse .) I begge tilfælde vil både god og ondsindet DoH-trafik blive uopdaget, hvilket efterlader organisationen blind for den ondsindede brug af DoH som en kanal til at kontrollere malware (C2) og stjæle følsomme data.

Sikring af synlighed og kontrol af DoH-trafikken

Som den bedste løsning til DoH-kontrol anbefaler vi at konfigurere NGFW til at dekryptere HTTPS-trafik og blokere DoH-trafik (applikationsnavn: dns-over-https). 

Først skal du sørge for, at NGFW er konfigureret til at dekryptere HTTPS, ifølge en guide til de bedste dekrypteringsteknikker.

For det andet skal du oprette en regel for programtrafik "dns-over-https" som vist nedenfor:

Minimering af risikoen ved at bruge DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)Palo Alto Networks NGFW-regel til at blokere DNS-over-HTTPS

Som et midlertidigt alternativ (hvis din organisation ikke fuldt ud har implementeret HTTPS-dekryptering), kan NGFW konfigureres til at anvende en "afvis"-handling på "dns-over-https"-applikations-id'et, men effekten vil være begrænset til at blokere visse brønd- kendte DoH-servere ved deres domænenavn, så hvordan uden HTTPS-dekryptering kan DoH-trafik ikke inspiceres fuldt ud (se  Applipedia fra Palo Alto Networks   og søg efter "dns-over-https").

DNS over TLS (DoT)

Minimering af risikoen ved at bruge DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)DNS inde i TLS

Mens DoH-protokollen har en tendens til at blande sig med anden trafik på den samme port, bruger DoT i stedet som standard en speciel port, der er reserveret til det eneste formål, og tillader endda specifikt, at den samme port bliver brugt af traditionel ukrypteret DNS-trafik ( RFC 7858, afsnit 3.1 ).

DoT-protokollen bruger TLS til at levere kryptering, der indkapsler standard DNS-protokolforespørgsler, med trafik ved hjælp af den velkendte port 853 ( RFC 7858 afsnit 6 ). DoT-protokollen er designet til at gøre det nemmere for organisationer at blokere trafik på en port eller acceptere trafik, men aktivere dekryptering på den port.

Risici forbundet med DoT

Google har implementeret DoT i sin klient Android 9 Pie og nyere , med standardindstillingen til automatisk at bruge DoT, hvis det er tilgængeligt. Hvis du har vurderet risiciene og er klar til at bruge DoT på organisationsniveau, så skal du have netværksadministratorer til eksplicit at tillade udgående trafik på port 853 gennem deres perimeter for denne nye protokol.

Sikring af synlighed og kontrol af DoT-trafik

Som en bedste praksis for DoT-kontrol anbefaler vi et af ovenstående, baseret på din organisations krav:

  • Konfigurer NGFW til at dekryptere al trafik for destinationsport 853. Ved at dekryptere trafik vil DoT fremstå som en DNS-applikation, hvorpå du kan anvende enhver handling, såsom aktivering af abonnement Palo Alto Networks DNS-sikkerhed til at kontrollere DGA-domæner eller et eksisterende DNS Sinkholing og anti-spyware.

  • Et alternativ er at lade App-ID-motoren fuldstændig blokere 'dns-over-tls'-trafik på port 853. Dette er normalt blokeret som standard, ingen handling er påkrævet (medmindre du specifikt tillader 'dns-over-tls'-applikation eller port trafik 853).

Kilde: www.habr.com

Tilføj en kommentar