Windows Server Hardening – Deo 5: PowerShell bezbednost i logovanje

Prethodni delovi serije pokrili su konfiguraciju, pristup, firewall i disciplinu ažuriranja. Peti deo se bavi alatom koji je istovremeno nezamenljiv za svakodnevnu administraciju i jedan od najčešće zloupotrebljavanih od strane napadača koji se već nalaze unutar mreže — PowerShell-om. Cilj ovog dela nije da obeshrabri korišćenje PowerShell-a (ukidanje ili blokiranje PowerShell-a u celini je pogrešan, kontraproduktivan pristup), već da pokaže kako se on koristi bezbedno, i kako se prati kad neko drugi pokuša da ga zloupotrebi.

Zašto je PowerShell omiljen alat i za administratore i za napadače

PowerShell dolazi ugrađen u svaki Windows Server, ima dubok pristup operativnom sistemu, i može da izvršava kod direktno u memoriji bez ikad zapisivanja izvršne datoteke na disk — sve osobine koje ga čine izuzetno korisnim za legitiman rad administratora, i podjednako korisnim za napadača koji želi da izbegne tradicionalnu antivirusnu detekciju zasnovanu na fajlovima. Nakon što napadač jednom dobije početan pristup mreži, PowerShell je često sledeći alat koji koristi za izviđanje, lateralno kretanje i uspostavljanje trajnog pristupa — ne zato što je "hakerski" alat, već zato što je već tu, na svakom serveru, i retko izaziva sumnju sam po sebi.

Logovanje — bez njega, PowerShell aktivnost je nevidljiva

Podrazumevano, Windows beleži veoma malo o tome šta se u PowerShell-u zapravo izvršava. Postoje tri glavna, dodatna nivoa logovanja koje treba eksplicitno uključiti: Script Block Logging (beleži stvarni sadržaj izvršenog koda, uključujući i dinamički generisan ili namerno zamagljen — obfuskovan — kod), Module Logging (beleži detalje izvršavanja za određene module) i Transcription (beleži kompletnu sesiju — unete komande i njihov izlaz, slično snimku ekrana u tekstualnom obliku).

Ovo je direktno analogno principu iz petog dela AD hardening serije o monitoringu — "uključen audit log" nije isto što i monitoring, i isti princip ovde znači da bez svesno uključenog Script Block Logging-a, mnogi napadi izvedeni kroz PowerShell jednostavno ne ostavljaju trag koji bi se mogao naknadno analizirati.

Šta treba uraditi

• Uključiti Script Block Logging (Event ID 4104) kroz Group Policy na svim serverima — ovo je pojedinačno najvažniji nivo logovanja, jer otkriva stvarni sadržaj koda, čak i kad je namerno zamagljen radi izbegavanja detekcije
• Uključiti Module Logging (Event ID 4103) i Transcription logging kao dodatne, komplementarne slojeve vidljivosti
• Uključiti Process Creation Auditing (Event ID 4688) sa beleženjem argumenata komandne linije, kako bi se videlo i kad se PowerShell pokreće iz drugog procesa, ne samo kad se koristi direktno
• Prosleđivati sve ove logove na centralnu lokaciju (SIEM ili namenski log server), ne oslanjati se na lokalno čuvanje na svakom pojedinačnom serveru — lokalni log na kompromitovanom serveru je prva stvar koju napadač sa dovoljno privilegija može izbrisati
• Zaštititi integritet log podataka (write-once skladište ili strogo ograničen pristup logging serveru), tako da čak ni administrator kompromitovanog servera ne može retroaktivno izmeniti ili obrisati već poslate zapise

Napomena o riziku: uključivanje detaljnog logovanja (posebno Script Block Logging i Transcription) povećava rizik da se osetljivi podaci — lozinke, tokeni, ključevi — koji se pojave unutar izvršenog skripta ili komande, zapišu u log u čitljivom obliku. Ovo znači da sam log postaje osetljiv resurs koji zahteva isti nivo zaštite pristupa kao i podaci koje štiti; strogo ograničiti ko sme da čita ove logove, i uputiti razvojni i administrativni tim da izbegavaju direktno unošenje kredencijala u komandnu liniju ili skriptu, koristeći umesto toga sigurne mehanizme za čuvanje tajni (secrets management) gde god je to moguće.

PowerShell Remoting i WinRM — kontrolisan pristup, ne slobodno kretanje

PowerShell Remoting (kroz WinRM protokol) omogućava administraciju servera sa udaljene mašine, ali otvara i mogućnost lateralnog kretanja — ako je WinRM dostupan sa svake radne stanice ka svakom serveru bez ograničenja, kompromitovana radna stanica jednog zaposlenog postaje potencijalna odskočna daska ka celoj serverskoj infrastrukturi. Isti obrazac koji smo videli kod RDP-a u prvom delu serije ponavlja se i ovde — moćan, legitiman alat za administraciju, čija bezbednost zavisi isključivo od toga koliko je pristup ograničen.

Šta treba uraditi

• Nikad ne dozvoliti neograničeno kretanje sa radne stanice na radnu stanicu ili sa radne stanice direktno na kritične servere — WinRM pristup usmeriti isključivo kroz dedikovane, ojačane upravljačke mašine (jump host / bastion host)
• Ograničiti WinRM na nivou firewall-a (port 5985/5986) tako da prihvata konekcije isključivo sa upravljačke mreže, po istom principu segmentacije opisanom u drugom delu serije
• Koristiti HTTPS (port 5986) za WinRM komunikaciju umesto nešifrovanog HTTP-a, gde god je to izvodljivo
• Na nivou same WinRM konfiguracije, dodatno ograničiti dozvoljene izvorne IP adrese (IPv4Filter/IPv6Filter) kao dopunski sloj, nezavisan od firewall pravila — greška na jednom nivou ne ostavlja sistem potpuno otvorenim ako drugi nivo i dalje radi

Just Enough Administration (JEA) — ograničavanje šta se sme, ne samo ko sme

Standardan pristup delegiranju administracije je davanje punog administratorskog pristupa nekom timu ili osobi "da bi mogli da rade svoj posao" — isti obrazac koji smo kritikovali u AD hardening seriji kod OU delegacije i built-in grupa. JEA (Just Enough Administration) rešava ovaj problem na nivou PowerShell sesije: korisnik se prijavljuje sopstvenim kredencijalima, ali unutar JEA sesije dobija pristup samo tačno određenom, unapred definisanom skupu komandi — sistem ga interno mapira na virtuelni, privremeni administratorski identitet samo za trajanje te sesije i samo za te operacije.

Konkretan primer: inženjer tehničke podrške koji treba da resetuje lozinke i restartuje određene servise ne mora da bude Domain Admin niti lokalni administrator servera — JEA endpoint mu omogućava tačno te dve operacije, bez mogućnosti pokretanja proizvoljnih skripti, kretanja kroz fajl sistem, ili bilo čega van tačno definisanog opsega.

Šta treba uraditi

• Za rutinske, ponavljajuće administrativne zadatke koje obavlja tehnička podrška ili junior osoblje, razmotriti uvođenje JEA endpoint-a umesto dodele punog administratorskog pristupa
• Definisati JEA role capability fajlove tako da dozvoljavaju tačno određene cmdlet-e i parametre potrebne za konkretan zadatak, po istom principu najmanjih privilegija primenjenom kroz celu ovu i prethodne serije
• Koristiti JEA transcript logging (posebna funkcija unutar same JEA konfiguracije) kako bi svaka JEA sesija ostavila potpun trag korišćenih komandi, nezavisno od opšteg PowerShell logovanja
• Uvoditi JEA postepeno, počevši od najčešćih, najrutinskijih zadataka podrške, umesto pokušaja da se odjednom pokrije svaki mogući administrativni scenario

Napomena o riziku: uvođenje JEA-a zahteva precizno unapred definisanje svih operacija koje su korisniku zaista potrebne — prestrog JEA endpoint koji ne pokriva stvaran obim posla će jednostavno naterati korisnike da traže alternativni, širi pristup "da bi mogli da rade", čime se svrha uvođenja JEA-a poništava. Definisati opseg dozvoljenih komandi u bliskoj saradnji sa timom koji će JEA endpoint zaista koristiti, testirati kroz realne, svakodnevne scenarije pre šireg uvođenja, i biti spreman da opseg proširi ako se pokaže da nedostaje neka legitimno potrebna operacija.

Ovim se zaokružuje peti deo Windows Server hardening serije. Serija je do sada pokrila osnovna podešavanja, firewall i Defender, lokalne politike, patch disciplinu i PowerShell bezbednost — zajedno čineći praktičnu osnovu za hardening operativnog sistema koji nosi Active Directory i MSSQL infrastrukturu obrađenu u prethodnim serijama na ovom blogu. Dalji nastavak može ići u dubinu na specifične teme poput bezbednosti Hyper-V virtuelizacione infrastrukture ili detaljnijeg pregleda Windows Event log-a i onoga što sistem inženjer i auditor treba tamo da traže, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.