DNS Security Hardening: Zaštita infrastrukture i DNS kao bezbednosni alat

DNS je verovatno najnedovoljno iskorišćena bezbednosna kontrola u tipičnoj infrastrukturi — ne zato što bi bila komplikovana ili skupa za primenu, već zato što se DNS tradicionalno tretira kao "samo" servis koji prevodi imena u IP adrese i retko dobija istu pažnju kao firewall, endpoint zaštita, ili email bezbednost. Ovaj tekst pokriva DNS iz dva ugla koja se retom razdvajaju, a zaslužuju odvojenu pažnju: zaštitu sopstvene DNS infrastrukture (autoritativni serveri, zone transferi, dinamička ažuriranja) i korišćenje DNS-a kao aktivnog bezbednosnog alata (filtriranje, detekcija tunelovanja, enkripcija upita).

Zašto DNS zaslužuje posebnu pažnju — statistika koja menja perspektivu

Vredi otvoriti sa konkretnim brojem koji objašnjava zašto je DNS toliko privlačan napadačima: preko 90 procenata malvera koristi DNS za komandnu i kontrolnu (C2) komunikaciju — ne zato što je DNS protokol posebno pogodan za skrivenu komunikaciju, već zato što je univerzalno dozvoljen. Mrežni firewall koji strogo blokira direktne odlazne konekcije na neuobičajenim portovima gotovo uvek propušta port 53 (DNS) potpuno otvoren, jer je blokiranje DNS-a jednako blokiranju internet pristupa u celini za sve korisnike na mreži. Ova univerzalna dozvoljenost je tačno ono što napadači eksploatišu — DNS upit izgleda kao rutinski, bezopasan saobraćaj, čak i kad nosi ukradene podatke ili komande za već kompromitovan sistem.

Zaštita sopstvene DNS infrastrukture — počevši od osnova servera

Isti princip minimizacije površine napada i osnovne higijene koji se provlači kroz svaku prethodnu seriju na ovom blogu primenjuje se i ovde, sa DNS-specifičnim detaljima. DNS server (bilo BIND, PowerDNS, Windows DNS, ili druga implementacija) treba tretirati sa istom pažnjom kao i svaki drugi kritičan, mrežno izložen servis obrađen kroz Windows i Linux Server hardening serije na ovom blogu.

Šta treba uraditi

• Razdvojiti autoritativne i rekurzivne uloge DNS servera — autoritativni server (koji odgovara za sopstvene, konkretne zone) ne treba da vrši rekurzivnu rezoluciju za proizvoljne, spoljne upite; ova razdvojenost sprečava da kompromitacija ili zloupotreba jedne funkcije automatski ugrozi i drugu
• Onemogućiti otvorenu rekurziju na svakom serveru koji nema stvarnu poslovnu potrebu da je pruža celom internetu — server koji vrši rekurzivnu rezoluciju za bilo koga postaje meta za DNS amplifikacione DDoS napade, gde napadač koristi taj otvoreni server da multiplikuje saobraćaj usmeren ka žrtvi
• Ograničiti ko sme da šalje upite i ko sme da inicira rekurzivne zahteve (allow-query, allow-recursion podešavanja kod BIND-a, ili ekvivalentna podešavanja druge implementacije) isključivo na poznate, poverljive mrežne segmente, po istom default-deny principu koji se provlači kroz celu ovu seriju blogova
• Zahtevati bezbedna dinamička ažuriranja (secure dynamic updates) na Microsoft DNS serverima integrisanim sa Active Directory-jem, nikad ostaviti zone podešene na nesigurna ažuriranja — nesigurno dinamičko ažuriranje dozvoljava bilo kom klijentu da upiše proizvoljan zapis u zonu bez autentifikacije
• Uključiti Response Rate Limiting (RRL) na autoritativnim serverima — ovo ograničava koliko odgovora server šalje istom izvoru u kratkom vremenskom periodu, direktno usporavajući DNS amplifikacione napade koji zloupotrebljavaju server kao pojačalo

Zone transfer — česta, a ozbiljna greška u konfiguraciji

Ovo zaslužuje detaljno objašnjenje jer predstavlja jedan od najčešćih, a najozbiljnijih propusta koji se otkrivaju tokom bezbednosnih provera DNS infrastrukture. Zone transfer (AXFR za pun transfer, IXFR za inkrementalni) je mehanizam kojim sekundarni DNS server preuzima kompletnu kopiju zone sa primarnog — legitiman, neophodan proces za redundansu, ali ako nije strogo ograničen na eksplicitno poznate, poverljive sekundarne servere, otvara vrata katastrofalnom curenju informacija.

Razlog zašto je ovo toliko ozbiljno: uspešan, neovlašćen zone transfer daje napadaču kompletnu mapu unutrašnje mreže u jednom potezu — svaki A/AAAA zapis (imena i IP adrese svih servera), svaki MX zapis (mejl infrastruktura), i, što je posebno rečito, sama imena hostova često direktno otkrivaju njihovu funkciju (sql01, backup-server, dc1, vpn-gateway). Ovo napadaču daje spreman prioritetni spisak meta — koje mašine su verovatno domain kontroleri, koje su baze podataka, koje su backup sistemi — pre nego što je uopšte pokušao ijedan stvaran, tehnički napad. Neovlašćen zone transfer se s razlogom smatra jednim od najrečitijih, "besplatnih" izvora izviđanja koji napadač može dobiti od loše konfigurisane infrastrukture.

Šta treba uraditi

• Eksplicitno ograničiti dozvoljene transfere (allow-transfer kod BIND-a, ili ekvivalentna postavka) na tačno, poimenično navedene IP adrese poznatih sekundarnih servera — nikad ostaviti podešeno na "any" ili ekvivalentno, potpuno otvoreno stanje
• Koristiti TSIG (Transaction Signature) za autentifikaciju samog procesa transfera između primarnog i sekundarnog servera — ovo dodaje kriptografski sloj koji potvrđuje da zahtev za transfer zaista dolazi od legitimnog, autorizovanog sekundarnog servera, ne samo od IP adrese koja se lako lažira
• Redovno testirati sopstvenu izloženost — pokušati AXFR upit sa neovlašćene, spoljne adrese protiv svakog autoritativnog servera koji organizacija održava, i potvrditi da je transfer eksplicitno odbijen; ovo je jednostavna, brza provera koja direktno otkriva najčešći propust u ovoj oblasti
• Pratiti logove servera na neuspešne pokušaje AXFR/IXFR transfera sa neočekivanih izvora — obrazac ponovljenih pokušaja sa iste, nepoznate adrese predstavlja jasan signal izviđanja u toku, vredan istrage čak i kad svaki pojedinačan pokušaj bude uspešno odbijen
• Ograničiti broj istovremenih transfera i primeniti TCP rate limiting na portu 53 kao dodatnu, mrežnu zaštitu iznad same DNS server konfiguracije — ovo sprečava da čak i autorizovan proces transfera bude zloupotrebljen za iscrpljivanje resursa servera

DNSSEC — kriptografska potvrda da odgovor nije falsifikovan

DNSSEC rešava suštinski drugačiji problem od zone transfer zaštite opisane ranije — ne štiti od curenja informacija, već od falsifikovanja odgovora. Standardan DNS, bez DNSSEC-a, funkcioniše na principu slepog poverenja: klijent šalje upit i prihvata prvi odgovor koji stigne kao validan, bez ikakve mogućnosti da proveri da li je taj odgovor zaista poslat od strane autoritativnog servera ili je usput falsifikovan (cache poisoning, man-in-the-middle presretanje). DNSSEC dodaje digitalne potpise DNS podacima, omogućavajući rezolveru da kriptografski proveri da odgovor zaista potiče od legitimnog vlasnika zone i da nije izmenjen u prenosu.

Šta treba uraditi

• Uključiti DNSSEC potpisivanje za sopstvene autoritativne zone, posebno za domene koji hostuju osetljive servise — portale za prijavu, korporativne resurse, e-commerce platforme — gde falsifikovan DNS odgovor može direktno preusmeriti korisnike ka lažnoj, napadačevoj infrastrukturi
• Uključiti DNSSEC validaciju na rekurzivnim resolverima koje organizacija koristi ili kontroliše — potpisivanje sopstvenih zona štiti one koji pitaju za vaše podatke, dok validacija na resolveru štiti vaše korisnike od falsifikovanih odgovora za bilo koji domen koji oni upituju
• Imati na umu istorijski razlog spore adaptacije DNSSEC-a — kompleksnost konfiguracije i loši podrazumevani parametri kod nekih starijih implementacija DNS softvera — i planirati postavljanje uz testiranje, ne kao trivijalnu, jednominutnu izmenu
• Razumeti jasno ograničenje DNSSEC-a: štiti integritet i autentičnost DNS podataka, ali ne pruža nikakvu poverljivost — sam upit i odgovor i dalje putuju u čitljivom obliku, vidljivi svakom ko prisluškuje mrežni saobraćaj; za poverljivost je potreban enkriptovan transport, obrađen dalje u tekstu

Enkriptovan DNS transport — DoT, DoH, i praktičan kompromis korporativne kontrole

DNS over TLS (DoT) i DNS over HTTPS (DoH) rešavaju problem koji DNSSEC ne pokriva — poverljivost samog upita. Bez enkripcije, svaki DNS upit koji korisnik pošalje (koji sajt pokušava da poseti, čak i pre nego što se sama HTTPS konekcija uspostavi) vidljiv je svakome sa pristupom istom mrežnom segmentu — internet provajderu, operateru javnog WiFi-ja, ili napadaču koji prisluškuje lokalnu mrežu. DoT enkriptuje DNS saobraćaj kroz standardnu TLS konekciju na dedikovanom portu, dok DoH ide korak dalje i umotava DNS upite unutar standardnog HTTPS saobraćaja na portu 443 — čineći DNS upit vizuelno nerazlučivim od bilo kog drugog veb saobraćaja.

Upravo ova poslednja osobina DoH-a stvara praktičan, korporativni problem vredan detaljnog objašnjenja: organizacije koje oslanjaju sopstvenu bezbednosnu politiku na DNS filtriranje (blokiranje poznatih zlonamernih domena na nivou samog DNS upita, obrađeno dalje u tekstu) gube tu vidljivost i kontrolu ako aplikacije ili pregledači na krajnjim uređajima samostalno počnu da koriste sopstveni, spoljni DoH resolver, zaobilazeći korporativni DNS server u potpunosti. Moderni pregledači sve češće imaju DoH uključen po difoltu, usmeren ka javnom resolveru (npr. Cloudflare ili Google), potpuno nezavisno od toga šta je administrator organizacije podesio na nivou mreže ili operativnog sistema.

Šta treba uraditi

• Rasporediti interni DoH/DoT resolver i sprovesti njegovo korišćenje kroz upravljanje uređajima (Group Policy, MDM profil) — ovo omogućava enkripciju DNS saobraćaja bez gubljenja korporativne vidljivosti i kontrole, jer svi upiti i dalje prolaze kroz resolver koji organizacija kontroliše
• Eksplicitno blokirati poznate, spoljne DoH resolvere na nivou mrežnog firewall-a (poznate IP adrese i domene javnih DoH servisa) kako bi se sprečilo zaobilaženje korporativnog resolvera od strane aplikacija koje same, nezavisno pokušaju da koriste sopstveni, spoljni DoH — mnogi proizvođači bezbednosnih rešenja eksplicitno navode ovo kao standardnu, očekivanu praksu
• Konfigurisati politiku upravljanih uređaja (browser policy kroz Group Policy ili MDM) da eksplicitno onemogući ili "pin-uje" DoH podešavanje pregledača na organizacioni, interni resolver, umesto da se prepusti podrazumevanom ponašanju aplikacije
• Za saobraćaj koji putuje van organizacione mreže (radne stanice na putu, javni WiFi), i dalje davati prednost enkriptovanom DNS transportu nad plaintext DNS-om — u tom kontekstu, poverljivost postaje prioritetnija od korporativne vidljivosti, i enkriptovan DNS ka poverljivom, spoljnom resolveru je bolji izbor od nešifrovanog DNS-a na nepoznatoj, potencijalno neprijateljskoj mreži

DNS filtering — jeftin, brz, agentless sloj zaštite

Ovo zaslužuje isticanje kao jedna od retkih bezbednosnih mera koja kombinuje nisku cenu implementacije, brzinu postavljanja, i realnu, merljivu vrednost bez potrebe za agentom na svakom pojedinačnom uređaju. Protective DNS (zaštitni DNS) resolver proverava svaki upit protiv liste poznatih zlonamernih domena — phishing sajtova, poznate command-and-control infrastrukture, domena povezanih sa distribucijom malvera — i odbija rezoluciju pre nego što uređaj uopšte uspostavi konekciju ka tom odredištu.

Šta treba uraditi

• Usmeriti sav DNS saobraćaj organizacije kroz filtrirajući resolver (bilo komercijalno rešenje poput Cisco Umbrella, Cloudflare Gateway, ili slično, bilo sopstveni resolver sa integrisanom listom pretnji), umesto direktnog korišćenja generičkih, javnih resolvera bez ikakvog filtriranja
• Kombinovati filtriranje bazirano na listi poznatih pretnji sa bihevioralnom analizom gde je dostupno — obrasci koji ukazuju na tek nastale, još nekatalogizovane pretnje (domeni generisani algoritamski — DGA, tipičan obrazac malvera koji generiše nove domene za komunikaciju svaki dan da izbegne blokiranje) zahtevaju dublju analizu od proste liste poznatih, već identifikovanih domena
• Logovati sve DNS upite centralno, čak i one koji nisu blokirani — pun log DNS aktivnosti je izuzetno vredan izvor za naknadnu istragu incidenta, otkrivajući ka kojim domenima je kompromitovan sistem pokušavao da se poveže pre nego što je incident uopšte otkriven drugim putem
• Tretovati DNS log kao ravnopravan izvor za centralizovan SIEM sistem, po istom principu centralizovanog logovanja koji se provlači kroz svaku seriju na ovom blogu — DNS log često otkriva ranu fazu napada (izviđanje, pokušaj komunikacije ka C2 infrastrukturi) pre nego što se napad razvije do faze koja bi aktivirala druge, tradicionalnije alarme

DNS tunneling — kad se legitiman protokol koristi kao skriveni kanal

Ovo zaslužuje detaljno tehničko objašnjenje jer predstavlja tehniku koja ne "kvari" DNS niti eksploatiše nijednu ranjivost u klasičnom smislu — umesto toga, zloupotrebljava normalno, očekivano ponašanje protokola. DNS tunneling kodira proizvoljne podatke (ukradene fajlove, komande za već kompromitovan sistem) unutar delova DNS upita koji dozvoljavaju proizvoljan sadržaj — tipično unutar samog imena poddomena koji se traži (npr. dugačak, na izgled nasumičan niz karaktera ispred glavnog domena) ili unutar TXT zapisa, koji je po dizajnu namenjen proizvoljnom tekstualnom sadržaju.

Pošto svaki firewall dozvoljava DNS saobraćaj (iz razloga objašnjenog na početku ovog teksta), ovaj kanal prolazi nezapaženo kroz standardnu mrežnu odbranu koja bi inače blokirala direktan pokušaj neautorizovane konekcije. Otkrivanje zahteva analizu obrazaca saobraćaja, ne samo prostu proveru da li je DNS dozvoljen ili ne — pitanje nije "da li DNS saobraćaj postoji" (uvek postoji, i uvek treba da postoji), već "da li ovaj konkretan DNS saobraćaj liči na normalnu rezoluciju imena ili na nešto drugo".

Šta treba uraditi

• Pratiti neuobičajeno visok volumen TXT i NULL tipova upita — ovi tipovi zapisa se koriste znatno ređe u normalnom, svakodnevnom DNS saobraćaju od standardnih A/AAAA upita, pa njihova neuobičajena učestalost predstavlja jasan signal vredan pažnje
• Tražiti neuobičajeno duge, ili na izgled nasumične nizove karaktera u imenima poddomena koji se upituju — legitimni domeni retko imaju poddomene koji liče na base32/base64 kodirane vrednosti; ovakav obrazac je čest, prepoznatljiv potpis tunelovanja podataka kroz DNS upit
• Analizirati vremenski obrazac saobraćaja — stabilan, nizak, ali kontinuiran tok upita ka istom, retko viđenom domenu (tipičan obrazac za sporo, namerno prikriveno curenje podataka) razlikuje se od uobičajenog, isprekidanog obrasca ljudski-generisanog pregledanja interneta
• Koristiti alate specijalizovane za analizu obrazaca DNS saobraćaja (entropija imena, volumen, vremenski razmak između upita), ne osloniti se isključivo na proste blokliste — tunelovanje po definiciji koristi domene koje mogu biti sasvim nove, nepoznate bilo kojoj postojećoj listi pretnji
• Kombinovati DNS tunneling detekciju sa opštom disciplinom logovanja i centralizovanog praćenja opisanom kroz svaku prethodnu seriju na ovom blogu — izolovan, jednokratan pogled na DNS log retko otkriva ovaj obrazac; potrebna je kontinuirana, agregatna analiza tokom vremena

Kontrola pristupa i praćenje izmena zapisa

Isti princip least privilege i audit discipline koji se ponavlja kroz svaku seriju na ovom blogu ima ovde direktnu primenu: neovlašćena izmena DNS zapisa (posebno MX zapisa koji usmerava mejl saobraćaj, ili A/CNAME zapisa za kritične servise) može biti tiha, a razorna tačka napada — preusmeravanje saobraćaja ka napadačevoj infrastrukturi bez potrebe da napadač direktno kompromituje sam ciljani servis.

Šta treba uraditi

• Ograničiti administrativan pristup DNS upravljačkom interfejsu (bilo internom serveru, bilo panelu registrara domena) na uzak, jasno definisan krug ljudi, sa MFA obaveznom bez izuzetka — isti princip opisan kroz svaku seriju o kritičnoj infrastrukturi na ovom blogu
• Uključiti registrar-level zaštitu (registry lock ili ekvivalentna funkcija koju registrar nudi) za kritične, poslovno-vitalne domene — ovo dodaje dodatan korak potvrde (često ručnu intervenciju osoblja registrara) pre nego što se bilo koja izmena na nivou samog domena, uključujući promenu autoritativnih DNS servera, uopšte može izvršiti
• Pratiti izmene DNS zapisa aktivno, kroz automatizovan alat koji redovno proverava trenutno stanje protiv očekivane, dokumentovane konfiguracije, i alarmira na svako neočekivano odstupanje — neovlašćena izmena MX zapisa, na primer, može ostati neprimećena danima ako niko aktivno ne prati stanje, dok napadač u međuvremenu presreće celokupnu dolaznu poštu organizacije
• Dokumentovati očekivano, ispravno stanje svake kritične zone kao referentnu tačku za tu vrstu poređenja, po istom principu dokumentacije koji se provlači kroz svaku seriju na ovom blogu

DNS, uprkos tome što deluje kao jednostavan, "pozadinski" servis, zaslužuje istu pažnju kao i svaki drugi sloj infrastrukture obrađen kroz ovaj blog — i kao alat napada (tunelovanje, C2 komunikacija), i kao meta napada (zone transfer, falsifikovanje odgovora), i, možda najvažnije, kao potcenjen, a moćan alat odbrane kad se svesno iskoristi kroz filtriranje i centralizovano praćenje. Isti obrazac koji povezuje ovu temu sa svakom prethodnom serijom na ovom blogu ostaje tačan i ovde: default-deny, least privilege, i kontinuirano praćenje čine razliku između DNS-a koji tiho radi u pozadini bez ikakve pažnje, i DNS-a koji aktivno doprinosi ukupnoj bezbednosnoj poziciji organizacije.