Millised on DNSi krüpteerimise tagajärjed ettevõtetele

Üleminek HTTP ajastult DNSi ajastule paneb ettevõtte turvalisuse ja SOC-meeskonnad proovile

Ühelt poolt on domeeninimeteenuste (DNS) rünnakute levik  kogu maailmas aidanud tõsta teadlikkust interneti “torustiku” laiaulatuslikust probleemist. DNSi moodustav infrastruktuur vaevleb, kuna sel puudub sisseehitatud turvalisus, mis omakorda ohustab internetikasutajaid.

Domeeninimede süsteemi turvalaienduste (Decades of work on the Domain Name System Security Extensions/DNSSEC) spetsifikatsioonide väljatöötamisega on tegeletud aastakümneid, et leida parim viis DNSi turbeks, hoides seda samas piisavalt paindlikuna, et skaleerida seda ettevõtte ning veelgi suurematesse võrkudesse.  DNSSECi kasutuselevõttu on olnud enamikes riikides siiski loid. Selle põhjuseks võib olla kannatamatus. DNSSECi kasutajad on võtnud DNSi liikluse turvamiseks kasutusele teisi meetodeid, näiteks DNS TLS  (DoT) kaudu, DNSCrypt, DNSCurve ja viimati DNS HTTPS  (DoH) kaudu.

Näeme hetkel lahingut saavutamaks kontrolli DNSi üle, kus tehakse jõupingutusi DNSi turvamiseks HTTPSi kaudu. Kuna tavapäraselt saadetakse DNSi päringuid ja vastuseid lihttekstina, on ettevõtte võrkude üle järelvalvet teostava turvaoperatsioonide keskuse (SOC) meeskonnad võimelised jälgima päringutega domeene ja blokeerima kasutajatele juurdepääsu pahatahtlikele domeenidele. Lihttekstiga DNS-päringud on kindlasti vähem privaatsed, ent DNSi taseme luure on alati olnud võrgu turvalisuse kontrollimisel kriitiliseks andmeallikaks.

DoHi kasutuselevõtuga krüpteeritakse DNSi päringud HTTPS-protokolliga, takistades seega võrgukaitsjate kerget juurdepääsu. Jätte kõrvale muid DoHi aspekte, nagu näiteks privaatsus ja internetiülese kontrolli tsentraliseerimine, kirjutame sellest, kuidas on era- ja avalike võrkude turvalisus mõjutatud.

Nähtavuse kadumine ohustab ettevõtete turvalisust

SOC-meeskondadele avaldab DoH negatiivset mõju, kuna see ei võimalda suhtlust pahavaraga, mille tagajärjel võib viimane end hõlpsamini maskeerida. DNSi teerajaja dr Paul Vixie arutles intervjuus ESETi turvalisuse evangelisti Tony Anscombe’iga:

Võrguoperaatorina… pean ma nägema kasutajate, rakenduste ja seadmete tegevust DNSis, et tuvastada sissetungija, pahavara, botivõrgu kasutaja, mürgitatud tarneahel…Võrgu turvalisuse nimel pean ma seda nägema ja seepärast ei mõista inimene, kes kasutab projekti DNS HTTPSi kaudu ning ütleb “Jah, meie soov on võimaldada võrguoperaatoril sekkuda DNSi toimingutesse” minu elu absoluutselt.

Pahavara suhtleb sageli käsu- ja juhtimisserveritega  läbi HTTP ja HTTPSi – MITER ATT & CK teadmistebaas tuvastab neid kui standarse rakenduskihi protokolli tehnikana.  Näiteks täheldas ESET Research PolyglotDuke’i puhul – tolleaegset äsja avastatud allalaadijat, mida rakendas Dukes (APT29) Operation Ghost is – et too hangib C&C URLe sotsiaalmeedia teenustelt, nagu Twitter ja Reddit ning ühendub seejärel C&C serveritega, et laadida tagaukse kaudu ohvri arvutisse MiniDuke.

Antud suhtluse pahatahtliku olemuse varjamiseks kodeeris Dukes C&C URLid, kasutades selleks eri keeltest, eriti jaapani, tšeroki ja hiina keelest koosnevaid märgikomplekte – ESET nimetas seetõttu allalaadija “PolyglotDuke”iks.

Mis juhtuks, kui pahavara suudaks peita oma suhtlust DoHi taha? Õigupoolest leidsid Proofpointi teadlased PsiXBoti ründevara seksuaalse ahistamise mooduli uuenduse, mis kasutab C&C IP-aadresside hankimiseks Google’i DoH teenust, mis võimaldab varjata DNSi päringut HTTPSi taha. Dukes ja muud ohustajad võivad DoHi kasutamiseks laiendada oma vahendeid, mis aitaks ilmselt tulevikus varjata C&C kommunikatsiooni IT-administraatorite eest.

Ehkki DNSi krüpteerimisega kaasneb ka midagi head, võimaldab see ka tõkestada osa sinu kaitsemehhanismidest. See mõjutab peamiselt võrgupõhiseid turvalahendusi, rõhutades kvaliteetse, mitmekihilise tööjaama kaitse lahenduste olemasolu olulisust.

Pahavara nähtavuse suurendamine läbi krüpteeritud DNSi

SOC-meeskondadel on soovitatav olla kursis Mozilla, Google’i ja teiste DoHi pakkujate viimaste jõupingutustega. Sel viisil saavad IT-administraatorid uuendada võrguliikluse kontrollimise seadmete tarkvara ja konfiguratsioone, et blokeerida juurdepääsu uutele DoH teenustele. Näiteks pakub Google DoHi ainult läbi teatud stabiilsete aadresside, mida on võimalik tulemüüri tasemel ka blokeerida.

Tuntud DoH-teenuste blokeerimine või keelamine on aga alles esimene samm krüpteeritud DNSi pahatahtlike päringute määramisel. Enamarenenud SOC-meeskonnad peaksid kasutama tööjaama kaitse tuvastamise ja reageerimise (EDR) tööriista, mis võimaldab neil muuhulgas tuvastada ja tabada pahatahtlikke tunnustega DNS-päringuid ning uurida ühendusi pahatahtlike  C&C-serveritega.

Firefoxi ja Chrome’i brauserite DoH liikluse jälgimise osas on SOC-meeskonna nähtavause säilimiseks võimalik kasutada kohandatud turvasertifikaatide installimist tööjaama kaitsesse ja brauseri liikluse suunamist puhverserveritesse. See võimaldaks luua DoHist arusaava võrguliikluse kontrollimise lahenduse, mis suudaks teostada HTTPSi kontrolli dekrüpteerimise, kontrolli, logimise jne üle ning edastada kõiki sündmusi EDRi tööriistale edasiseks analüüsiks.

Pane tähele, et kuigi mõned brauserid kontrollivad kinnitatud sertifikaate, võib lokaalselt installitud turvasertifikaat tavalisest kontrollist mööduda. Sellegipoolest ei kontrolli Firefox ega Chrome’i brauserid selle artikli kirjutamise ajal kinnitatud sertifikaate.

DoHiga tegelemiseks on ka teisi võimalusi. Sarnaselt sisemiste DNS-serverite seadistamisega saavad ettevõtted seadistada ka sisemisi DoH-servereid, mis võimaldavad monitoorida kõiki päringuid. Teise võimalusena saab DoHi lihtsalt välja lülitada, nagu pakub ka Mozilla  nende Firefox brauserite korral.

Tehnilised lahendused DoH protokolli turvaprobleemide lahendamiseks on mitmekesised. Mistahes SOC-meeskonna edu jaoks on ülioluline õppida hindama uue protokolli suurenenud võimalusi, millest võivad osa saada pahatahtlikud ründajad ning mõistma selle mõju võrgu turvalisusele. Sel moel saab sinu ettevõtte jaoks panna paika DoHi kasutamisega seotud asjakohase turvapoliitika, mida täidab SOC-meeskond.