Active Directory Hardening – Deo 4: Bezbednost domain kontrolera i RODC

Prethodna tri dela serije bavila su se konceptima koji uglavnom žive na nivou konfiguracije — tier model, GPO, Kerberos. Četvrti deo se vraća na nešto opipljivije: samu bezbednost domain kontrolera kao mašina, fizičkih ili virtuelnih, i na Read-Only Domain Controller (RODC) kao rešenje za lokacije koje ne mogu da ponude isti nivo zaštite kao centralni data centar.

Zašto je ovo poseban sloj hardeninga

Sva podešavanja iz prethodnih delova serije mogu biti idealno postavljena, a domen i dalje ranjiv — ako neko ima fizički ili hipervizorski pristup mašini na kojoj domain kontroler radi. Ko god ima konzolni pristup virtuelnoj mašini domain kontrolera, u praksi ima i pristup njenom sadržaju u memoriji, bez obzira na to koliko su Kerberos i GPO podešavanja stroga. Zbog toga je bezbednost same infrastrukture domain kontrolera posebna, samostalna tema.

Fizički domain kontroleri

Domain kontroleri se u praksi nalaze u tri tipa lokacija — centralnom data centru, regionalnoj kancelariji ili udaljenoj lokaciji sa ograničenom fizičkom bezbednošću. Svaka od njih zahteva drugačiji pristup.

Šta treba uraditi

• U centralnom data centru, fizičke domain kontrolere smestiti u dedikovane, zaključane rekove ili kaveze, odvojene od ostatka serverske populacije — ne u isti rek sa aplikativnim ili fajl serverima
• Gde god je moguće, opremiti domain kontrolere TPM (Trusted Platform Module) čipom i uključiti BitLocker enkripciju na svim diskovima — ovo štiti od scenarija u kojem se disk fizički iznese iz mašine
• Na lokacijama koje ne mogu da ponude isti nivo fizičke bezbednosti (regionalne kancelarije, manje udaljene lokacije), umesto punog (writable) domain kontrolera koristiti RODC — o čemu detaljnije u nastavku teksta
• Isključiti web pristup (browsing) sa domain kontrolera u potpunosti — svaka odlazna konekcija sa DC-a ka internetu predstavlja nepotreban i značajan rizik, jer to više nikad ne bi trebalo da bude potrebno za redovan rad

Virtuelizovani domain kontroleri

Većina savremenih AD okruženja danas koristi virtuelizovane domain kontrolere, što donosi novu vrstu rizika: administrator hipervizora efektivno postaje i administrator domain kontrolera, bez obzira na to da li je ikad dobio to ovlašćenje unutar samog AD-a. Snapshot virtuelne mašine domain kontrolera, ako padne u pogrešne ruke, sadrži praktično sve što bi napadač mogao poželeti — uključujući NTDS.dit bazu sa heš vrednostima svih lozinki u domenu.

Šta treba uraditi

• Virtuelizovane domain kontrolere pokretati na fizičkim hostovima odvojenim od ostalih virtuelnih mašina — ne deliti hipervizor sa aplikativnim serverima ili radnim stanicama
• Administratorske naloge za hipervizor na kojem rade domain kontroleri držati potpuno odvojenim od naloga koji administriraju ostatak virtuelizacione infrastrukture
• Ako se koristi centralizovan alat za upravljanje virtuelizacijom (npr. System Center Virtual Machine Manager), delegirati administraciju fizičkih hostova i virtuelnih mašina domain kontrolera samo posebno ovlašćenim administratorima, ne celom timu za virtuelizaciju
• Razmotriti odvajanje skladišta (storage) virtuelnih domain kontrolera od ostatka virtuelne infrastrukture, kako administratori skladišnog sistema ne bi imali direktan pristup fajlovima virtuelne mašine
• Onemogućiti neovlašćeno pravljenje snapshot-ova virtuelnih domain kontrolera — snapshot sadrži kompletno stanje memorije i diska u trenutku snimanja

Patch management disciplina

Domain kontroleri se ažuriraju po istim principima kao i svaki drugi server, uz jednu praktičnu razliku — pošto se radi o kritičnoj infrastrukturi, promena mora biti pažljivije isplanirana, ali odlaganje ne sme da postane pravilo. Ranjivosti koje pogađaju AD DS ili LSASS servis spadaju u najozbiljnije koje jedna organizacija može imati neposredno pred sobom.

Šta treba uraditi

• Uspostaviti redovan ciklus održavanja za primenu ažuriranja, sa jasno definisanim prozorom za testiranje pre primene u produkciji
• Pratiti vendorska obaveštenja (Microsoft Security Response Center) za kritične bezbednosne izmene i primenjivati ih van redovnog ciklusa kada ozbiljnost to zahteva
• Pre primene ažuriranja na domain kontroleru, obavezno imati proverenu i validnu rezervnu kopiju (system state backup)
• Koristiti opciju preuzimanja ažuriranja bez automatskog restarta, kako bi tim mogao da kontroliše tačan trenutak restarta domain kontrolera
• Voditi računa da antivirusna ili EDR zaštita na domain kontroleru ne remeti rad AD DS servisa — izuzeci (exclusions) treba da prate isključivo zvaničnu Microsoft preporuku, ne da se dodaju proizvoljno radi "rešavanja problema"

Read-Only Domain Controller (RODC)

RODC je rešenje dizajnirano specifično za lokacije koje ne mogu da ponude fizičku bezbednost punog domain kontrolera — tipičan primer je manja regionalna kancelarija bez servera sobe pod ključem. RODC drži read-only kopiju AD baze; sve izmene teku isključivo od punog domain kontrolera ka RODC-u, nikad obrnuto, što znači da kompromitacija RODC-a ne može direktno da izmeni ili ošteti glavni forest.

Ono što čini RODC upotrebljivim u svakodnevnom radu, umesto da bude samo "read-only ogledalo" koje ništa korisno ne radi, jeste mogućnost keširanja (caching) lozinki lokalnih korisnika — pod kontrolom takozvane Password Replication Policy (PRP). Podrazumevano, nijedna lozinka se ne kešira na RODC-u dok se to eksplicitno ne dozvoli, a osetljivi nalozi (Domain Admins i slični) su unapred, po difoltu, na listi zabranjenih za keširanje.

Šta treba uraditi

• Na svakoj udaljenoj lokaciji bez adekvatne fizičke zaštite servera, koristiti RODC umesto punog (writable) domain kontrolera
• Konfigurisati Password Replication Policy tako da dozvoljava keširanje isključivo lozinki korisnika i računara koji zaista rade na toj lokaciji — ne primenjivati generičku, širom dozvoljenu politiku
• Nikad ne uklanjati privilegovane naloge (Domain Admins, Enterprise Admins i slične) sa liste zabranjenih (Denied) za keširanje na RODC-u, bez obzira na razlog
• Proveriti atribut managedBy na svakom RODC nalogu — svaki korisnik ili grupa navedena u ovom atributu ima lokalna administratorska prava nad tim RODC-om, pa kompromitacija tog naloga direktno vodi ka lokalnoj administraciji RODC-a
• Koristiti Filtered Attribute Set (FAS) da se dodatno osetljivi atributi (npr. LAPS lozinke) isključe iz replikacije ka RODC-u, čime se smanjuje šteta i u slučaju krađe same mašine
• U slučaju sumnje da je RODC fizički ukraden ili kompromitovan, odmah obrisati njegov računarski nalog iz AD-a — ovo automatski forsira reset lozinki svih naloga čije su lozinke bile keširane na tom RODC-u

Peti deo serije prelazi na monitoring i detekciju — koji Event ID-jevi zaista imaju vrednost za bezbednosni tim, kako izgleda razuman skup alarma za AD okruženje srednje veličine, i zašto sam logging bez definisanih pravila za uzbunjivanje često ostaje samo formalnost koja se nikad ne pogleda.