Minimumigante la riskojn uzi DoH kaj DoT
Protekto DoH kaj DoT
Ĉu vi kontrolas vian DNS-trafikon? Organizoj investas multan tempon, monon kaj penon por sekurigi siajn retojn. Tamen, unu areo, kiu ofte ne ricevas sufiĉe da atento, estas DNS.
Bona superrigardo de la riskoj kiujn DNS alportas estas ĉe la Infosekureco-konferenco.
31% de ransomware-klasoj enketitaj uzis DNS por ŝlosila interŝanĝo
31% de ransomware klasoj enketitaj uzis DNS por ŝlosilo interŝanĝo.
La problemo estas serioza. Laŭ esplorlaboratorio de Palo Alto Networks Unit 42, proksimume 85% de malware uzas DNS por establi komandan kaj kontrolan kanalon, permesante al atakantoj facile injekti malware en vian reton kaj ŝteli datumojn. Ekde ĝia komenco, DNS-trafiko estis plejparte neĉifrita kaj povas esti facile analizita per NGFW-sekurecaj mekanismoj.
Novaj protokoloj por DNS aperis celantaj pliigi la konfidencon de DNS-konektoj. Ili estas aktive subtenataj de ĉefaj foliumilaj vendistoj kaj aliaj softvaraj vendistoj. Ĉifrita DNS-trafiko baldaŭ komencos kreski en kompaniaj retoj. Ĉifrita DNS-trafiko, kiu ne estas konvene analizita kaj solvita per iloj, prezentas sekurecan riskon al kompanio. Ekzemple, tia minaco estas kriptoŝlosiloj, kiuj uzas DNS por interŝanĝi ĉifrajn ŝlosilojn. Atakantoj nun postulas elaĉeton de pluraj milionoj da dolaroj por restarigi aliron al viaj datumoj. Garmin, ekzemple, pagis $10 milionojn.
Kiam ĝuste agordita, NGFWs povas nei aŭ protekti la uzon de DNS-over-TLS (DoT) kaj povas esti uzataj por nei la uzon de DNS-over-HTTPS (DoH), permesante analizi la tutan DNS-trafikon en via reto.
Kio estas ĉifrita DNS?
Kio estas DNS
La Domajna Nomsistemo (DNS) solvas homlegeblajn domajnajn nomojn (ekzemple adreso ) al IP-adresoj (ekzemple, 34.107.151.202). Kiam uzanto enigas domajnan nomon en retumilon, la retumilo sendas DNS-demandon al la DNS-servilo, petante la IP-adreson asociitan kun tiu domajna nomo. Responde, la DNS-servilo resendas la IP-adreson, kiun ĉi tiu retumilo uzos.
DNS-demandoj kaj respondoj estas senditaj tra la reto en simpla teksto, neĉifrita, igante ĝin vundebla al spionado aŭ ŝanĝado de la respondo kaj alidirektado de la retumilo al malicaj serviloj. DNS-ĉifrado malfaciligas DNS-petojn esti spuritaj aŭ ŝanĝitaj dum transdono. Ĉifrado de DNS-petoj kaj respondoj protektas vin kontraŭ atakoj de Man-en-la-Mezo dum ili plenumas la saman funkcion kiel la tradicia protokolo DNS (Domain Name System).
Dum la lastaj jaroj, du DNS-ĉifradaj protokoloj estis lanĉitaj:
-
DNS-super-HTTPS (DoH)
-
DNS-super-TLS (DoT)
Ĉi tiuj protokoloj havas unu aferon en komuna: ili intence kaŝas DNS-petojn de iu ajn interkapto... kaj ankaŭ de la sekurgardistoj de la organizo. La protokoloj ĉefe uzas TLS (Transport Layer Security) por establi ĉifritan ligon inter kliento faranta demandojn kaj servilo solvanta DNS-demandojn super haveno kiu ne estas normale uzita por DNS-trafiko.
La konfidenco de DNS-demandoj estas granda pluso de ĉi tiuj protokoloj. Tamen, ili prezentas problemojn por sekurecgardistoj, kiuj devas monitori retan trafikon kaj detekti kaj bloki malicajn konektojn. Ĉar la protokoloj malsamas en sia efektivigo, la analizmetodoj diferencos inter DoH kaj DoT.
DNS per HTTPS (DoH)
DNS en HTTPS
DoH uzas la konatan havenon 443 por HTTPS, por kiu la RFC specife deklaras ke la intenco estas "miksi DoH-trafikon kun alia HTTPS-trafiko sur la sama konekto", "malfaciligi analizi DNS-trafikon" kaj tiel eviti entreprenajn kontrolojn. ( ). La DoH-protokolo uzas TLS-ĉifradon kaj la petan sintakson provizitan de la komunaj HTTPS kaj HTTP/2-normoj, aldonante DNS-petojn kaj respondojn aldone al normaj HTTP-petoj.
Riskoj asociitaj kun DoH
Se vi ne povas distingi regulan HTTPS-trafikon de DoH-petoj, tiam aplikaĵoj ene de via organizo povas (kaj faros) preteriri lokajn DNS-agordojn redirektante petojn al triaj serviloj respondantaj al DoH-petoj, kio preteriras ajnan monitoradon, tio estas, detruas la kapablon. kontroli la DNS-trafikon. Ideale, vi devus kontroli DoH per HTTPS-malĉifraj funkcioj.
И en la plej nova versio de siaj retumiloj, kaj ambaŭ kompanioj laboras por uzi DoH defaŭlte por ĉiuj DNS-petoj. pri integrigado de DoH en iliajn operaciumojn. La malavantaĝo estas, ke ne nur bonfamaj programaraj kompanioj, sed ankaŭ atakantoj komencis uzi DoH kiel rimedon por preteriri tradiciajn kompaniajn fajroŝirmilojn. (Ekzemple, reviziu la sekvajn artikolojn: , и .) En ambaŭ kazoj, kaj bona kaj malica DoH-trafiko restos nerimarkita, lasante la organizon blinda pri la malica uzo de DoH kiel kanalo por kontroli malware (C2) kaj ŝteli sentemajn datumojn.
Certigante videblecon kaj kontrolon de DoH-trafiko
Kiel la plej bona solvo por DoH-kontrolo, ni rekomendas agordi NGFW por malĉifri HTTPS-trafikon kaj bloki DoH-trafikon (apliknomo: dns-over-https).
Unue, certigu, ke NGFW estas agordita por malĉifri HTTPS, laŭ .
Due, kreu regulon por aplika trafiko "dns-over-https" kiel montrite sube:
Palo Alto Networks NGFW Regulo por Bloki DNS-super-HTTPS
Kiel provizora alternativo (se via organizo ne plene efektivigis HTTPS-malĉifradon), NGFW povas esti agordita por apliki "nei" agon al la "dns-over-https" aplika ID, sed la efiko estos limigita al blokado de certaj bone- konataj DoH-serviloj laŭ sia domajna nomo, do kiel sen HTTPS-malĉifrado, DoH-trafiko ne povas esti plene inspektita (vidu kaj serĉu "dns-over-https").
DNS super TLS (DoT)
DNS ene de TLS
Dum la DoH-protokolo tendencas miksi kun alia trafiko sur la sama haveno, DoT anstataŭe defaŭlte al uzado de speciala haveno rezervita por tiu sola celo, eĉ specife malpermesante la saman havenon esti uzata de tradicia neĉifrita DNS-trafiko ( ).
La DoT-protokolo uzas TLS por disponigi ĉifradon kiu enkapsuligas normajn DNS-protokoldemandojn, kun trafiko uzante la konatan havenon 853 ( ). La DoT-protokolo estis dizajnita por faciligi al organizoj bloki trafikon sur haveno, aŭ akcepti trafikon sed ebligi deĉifradon sur tiu haveno.
Riskoj asociitaj kun DoT
Google efektivigis DoT en sia kliento , kun la defaŭlta agordo por aŭtomate uzi DoT se disponebla. Se vi taksis la riskojn kaj pretas uzi DoT je la organiza nivelo, tiam vi devas havi retajn administrantojn eksplicite permesi eksteren trafikon sur haveno 853 tra sia perimetro por ĉi tiu nova protokolo.
Certigante videblecon kaj kontrolon de DoT-trafiko
Kiel plej bona praktiko por DoT-kontrolo, ni rekomendas iun el la supre, surbaze de la postuloj de via organizo:
-
Agordu NGFW por malĉifri la tutan trafikon por la celhaveno 853. Malĉifrinte trafikon, DoT aperos kiel DNS-aplikaĵo al kiu vi povas apliki ajnan agon, kiel ebligi abonon. kontroli DGA-domajnojn aŭ ekzistantan kaj kontraŭ-spiono.
-
Alternativo estas havi la App-ID-motoron tute bloki 'dns-over-tls' trafikon sur haveno 853. Ĉi tio kutime estas blokita defaŭlte, neniu ago necesa (krom se vi specife permesas 'dns-over-tls' aplikon aŭ haventrafikon 853).
fonto: www.habr.com