Minimaliseer die risiko's van die gebruik van DoH en DoT
DoH en DoT beskerming
Beheer jy jou DNS-verkeer? Organisasies belê baie tyd, geld en moeite om hul netwerke te beveilig. Een gebied wat egter dikwels nie genoeg aandag kry nie, is DNS.
'N Goeie oorsig van die risiko's wat DNS inhou, is by die Infosecurity-konferensie.
31% van lospryswareklasse wat ondervra is, het DNS vir sleuteluitruiling gebruik. Studiebevindinge
31% van losprysware-klasse wat ondervra is, het DNS vir sleuteluitruiling gebruik.
Die probleem is ernstig. Volgens Palo Alto Networks Unit 42-navorsingslaboratorium gebruik ongeveer 85% van wanware DNS om 'n bevel- en beheerkanaal te vestig, wat aanvallers in staat stel om maklik wanware in jou netwerk in te spuit en data te steel. Sedert die ontstaan daarvan is DNS-verkeer grotendeels ongeënkripteer en kan dit maklik deur NGFW-sekuriteitsmeganismes ontleed word.
Nuwe protokolle vir DNS het na vore gekom wat daarop gemik is om die vertroulikheid van DNS-verbindings te verhoog. Hulle word aktief ondersteun deur toonaangewende blaaierverskaffers en ander sagtewareverskaffers. Geënkripteerde DNS-verkeer sal binnekort in korporatiewe netwerke begin groei. Geënkripteerde DNS-verkeer wat nie behoorlik deur gereedskap ontleed en opgelos word nie, hou 'n sekuriteitsrisiko vir 'n maatskappy in. So 'n bedreiging is byvoorbeeld cryptolockers wat DNS gebruik om enkripsiesleutels uit te ruil. Aanvallers eis nou 'n losprys van etlike miljoene dollars om toegang tot jou data te herstel. Garmin het byvoorbeeld $10 miljoen betaal.
Wanneer dit behoorlik gekonfigureer is, kan NGFW's die gebruik van DNS-oor-TLS (DoT) ontken of beskerm en kan gebruik word om die gebruik van DNS-oor-HTTPS (DoH) te weier, sodat alle DNS-verkeer op jou netwerk ontleed kan word.
Wat is geïnkripteer DNS?
Wat is DNS
Die domeinnaamstelsel (DNS) los mensleesbare domeinname op (byvoorbeeld adres ) na IP-adresse (byvoorbeeld, 34.107.151.202). Wanneer 'n gebruiker 'n domeinnaam in 'n webblaaier invoer, stuur die blaaier 'n DNS-navraag na die DNS-bediener en vra vir die IP-adres wat met daardie domeinnaam geassosieer word. In reaksie gee die DNS-bediener die IP-adres terug wat hierdie blaaier sal gebruik.
DNS-navrae en -antwoorde word oor die netwerk gestuur in gewone teks, ongeënkripteer, wat dit kwesbaar maak vir spioenasie of die verandering van die reaksie en die herlei van die blaaier na kwaadwillige bedieners. DNS-enkripsie maak dit moeilik vir DNS-versoeke om opgespoor of verander te word tydens transmissie. Deur DNS-versoeke en -antwoorde te enkripteer, beskerm jy teen Man-in-the-Middle-aanvalle terwyl jy dieselfde funksionaliteit uitvoer as die tradisionele gewone teks DNS (Domain Name System) protokol.
Oor die afgelope paar jaar is twee DNS-enkripsieprotokolle ingestel:
-
DNS-oor-HTTPS (DoH)
-
DNS-oor-TLS (DoT)
Hierdie protokolle het een ding in gemeen: dit verberg doelbewus DNS-versoeke vir enige onderskepping ... en ook van die organisasie se sekuriteitswagte. Die protokolle gebruik hoofsaaklik TLS (Transport Layer Security) om 'n geënkripteerde verbinding te vestig tussen 'n kliënt wat navrae maak en 'n bediener wat DNS-navrae oplos oor 'n poort wat nie normaalweg vir DNS-verkeer gebruik word nie.
Die vertroulikheid van DNS-navrae is 'n groot pluspunt van hierdie protokolle. Dit hou egter probleme in vir sekuriteitswagte wat netwerkverkeer moet monitor en kwaadwillige verbindings moet opspoor en blokkeer. Omdat die protokolle verskil in hul implementering, sal die ontledingsmetodes verskil tussen DoH en DoT.
DNS via HTTPS (DoH)
DNS binne HTTPS
DoH gebruik die bekende poort 443 vir HTTPS, waarvoor die RFC spesifiek stel dat die bedoeling is om "DoH-verkeer met ander HTTPS-verkeer op dieselfde verbinding te meng", "dit moeilik maak om DNS-verkeer te ontleed" en sodoende korporatiewe kontroles te omseil ( ). Die DoH-protokol gebruik TLS-enkripsie en die versoeksintaksis wat deur die algemene HTTPS- en HTTP/2-standaarde verskaf word, en voeg DNS-versoeke en -antwoorde bo-op standaard HTTP-versoeke by.
Risiko's verbonde aan DoH
As jy nie gereelde HTTPS-verkeer van DoH-versoeke kan onderskei nie, kan (en sal) toepassings binne jou organisasie plaaslike DNS-instellings omseil deur versoeke te herlei na derdeparty-bedieners wat reageer op DoH-versoeke, wat enige monitering omseil, dit wil sê, vernietig die vermoë om beheer die DNS-verkeer. Ideaal gesproke moet u DoH beheer met behulp van HTTPS-dekripsiefunksies.
И in die nuutste weergawe van hul blaaiers, en beide maatskappye werk daaraan om DoH by verstek vir alle DNS-versoeke te gebruik. oor die integrasie van DoH in hul bedryfstelsels. Die nadeel is dat nie net betroubare sagtewaremaatskappye nie, maar ook aanvallers DoH begin gebruik het as 'n manier om tradisionele korporatiewe firewall-maatreëls te omseil. (Byvoorbeeld, hersien die volgende artikels: , и .) In beide gevalle sal beide goeie en kwaadwillige DoH-verkeer onopgemerk word, wat die organisasie blind laat vir die kwaadwillige gebruik van DoH as 'n kanaal om wanware (C2) te beheer en sensitiewe data te steel.
Verseker sigbaarheid en beheer van DoH-verkeer
As die beste oplossing vir DoH-beheer, beveel ons aan dat NGFW konfigureer om HTTPS-verkeer te dekripteer en DoH-verkeer te blokkeer (toepassingsnaam: dns-over-https).
Maak eers seker dat NGFW gekonfigureer is om HTTPS te dekripteer, volgens .
Skep tweedens 'n reël vir toepassingsverkeer "dns-over-https" soos hieronder getoon:
Palo Alto Networks NGFW-reël om DNS-oor-HTTPS te blokkeer
As 'n tussentydse alternatief (as jou organisasie nie ten volle HTTPS-dekripsie geïmplementeer het nie), kan NGFW gekonfigureer word om 'n "weier"-aksie op die "dns-over-https"-toepassing-ID toe te pas, maar die effek sal beperk word tot die blokkering van sekere goed- bekende DoH-bedieners deur hul domeinnaam, so hoe sonder HTTPS-dekripsie kan DoH-verkeer nie ten volle geïnspekteer word nie (sien en soek vir "dns-over-https").
DNS oor TLS (DoT)
DNS binne TLS
Terwyl die DoH-protokol geneig is om met ander verkeer op dieselfde poort te meng, gebruik DoT eerder 'n spesiale poort wat vir daardie uitsluitlike doel gereserveer is, en laat selfs spesifiek toe dat dieselfde poort nie deur tradisionele ongeënkripteerde DNS-verkeer gebruik word nie ( ).
Die DoT-protokol gebruik TLS om enkripsie te verskaf wat standaard DNS-protokolnavrae inkapsuleer, met verkeer wat die bekende poort 853 ( ). Die DoT-protokol is ontwerp om dit vir organisasies makliker te maak om verkeer op 'n poort te blokkeer, of verkeer te aanvaar, maar dekripsie op daardie poort moontlik te maak.
Risiko's wat verband hou met DoT
Google het DoT in sy kliënt geïmplementeer , met die verstekinstelling om DoT outomaties te gebruik indien beskikbaar. As jy die risiko's beoordeel het en gereed is om DoT op organisatoriese vlak te gebruik, moet jy netwerkadministrateurs uitdruklik uitgaande verkeer op poort 853 deur hul omtrek laat toelaat vir hierdie nuwe protokol.
Verseker sigbaarheid en beheer van DoT-verkeer
As 'n beste praktyk vir DoT-beheer, beveel ons enige van die bogenoemde aan, gebaseer op jou organisasie se vereistes:
-
Stel NGFW op om alle verkeer vir bestemmingpoort 853 te dekripteer. Deur verkeer te dekripteer, sal DoT verskyn as 'n DNS-toepassing waarop jy enige aksie kan toepas, soos aktiveer intekening om DGA-domeine of 'n bestaande een te beheer en anti-spioenware.
-
'n Alternatief is om die App-ID-enjin 'dns-over-tls'-verkeer op poort 853 heeltemal te laat blokkeer. Dit word gewoonlik by verstek geblokkeer, geen aksie word vereis nie (tensy jy spesifiek 'dns-over-tls'-toepassing of poortverkeer toelaat nie 853).
Bron: will.com