Windows Server Hardening – Deo 2: Firewall, segmentacija i Defender osnove

Prvi deo serije pokrio je osnovna podešavanja — baseline, lokalne administratorske naloge i RDP pristup. Drugi deo se bavi onim što server propušta ili odbija na nivou mreže: Windows Defender Firewall i osnovnim postavkama Microsoft Defender-a kao ugrađenog endpoint zaštitnog rešenja. Oba su besplatna, ugrađena u sam operativni sistem, a u praksi često ostaju na podrazumevanim podešavanjima koja nisu prilagođena stvarnoj ulozi servera.

Zašto host-based firewall ostaje bitan i uz mrežni firewall

Čest argument koji se čuje u praksi je da mrežni (perimetarski) firewall već štiti sve što je iza njega, pa je firewall na samom serveru suvišan. Problem sa ovim rezonovanjem je lateralno kretanje — ako napadač jednom uđe u mrežu (preko phishing mejla, kompromitovane radne stanice ili bilo kog drugog puta), perimetarski firewall više ne igra nikakvu ulogu, jer je napadač već unutar mreže koju taj firewall štiti. Host-based firewall na svakom pojedinačnom serveru je ono što u tom trenutku ograničava koliko daleko napadač može da ode.

Tri profila, jedna disciplina

Windows Defender Firewall radi sa tri odvojena profila — Domain, Private i Public — svaki sa sopstvenim skupom pravila, u zavisnosti od toga kakvoj mreži je server trenutno povezan. Uobičajena greška je usredsrediti se na Domain profil (jer server obično radi unutar domena) i zapostaviti preostala dva profila, pod pretpostavkom da nikad neće biti u upotrebi — dok stvarni rizik dolazi upravo od toga da ta pretpostavka nekad ispadne netačna, na primer kad se server privremeno poveže na drugu mrežu tokom migracije ili održavanja.

Šta treba uraditi

  • Zadržati Windows Defender Firewall uključenim na sva tri profila — Domain, Private i Public — bez izuzetka
  • Za svaki profil, zadržati podrazumevano ponašanje "blokiraj dolazno, dozvoli odlazno" kao polaznu tačku, a zatim ga pooštriti dodavanjem eksplicitnih pravila za ono što server stvarno treba da radi
  • Za Public profil primenjivati najstrože moguće podešavanje — blokirati sav dolazni saobraćaj bez izuzetka, jer server po definiciji ne bi trebalo da bude povezan na nepoverljivu mrežu dok obavlja svoju redovnu ulogu
  • Nikad ne brisati ugrađena (built-in) pravila firewall-a koja dolaze sa operativnim sistemom — ona omogućavaju osnovnu funkcionalnost (Windows Update, DNS klijent i slično), i njihovo brisanje može oštetiti rad samog OS-a; umesto brisanja, dodavati sopstvena, precizna pravila
  • Upravljati firewall pravilima kroz Group Policy, ne pojedinačno na svakom serveru — isti princip konzistentnosti kao i kod primene Security Baseline-a iz prvog dela serije

Dolazna i odlazna pravila — obe strane su bitne

Većina administratora prirodno prioritizuje dolazna (inbound) pravila — logično, jer je to pravac kojim napadač prvo pokušava da uđe. Odlazna (outbound) pravila se često ostavljaju na podrazumevanom "dozvoli sve", što znači da čak i kad napadač uspe da postavi malver na server, taj malver ima slobodan izlaz ka spoljnoj mreži za preuzimanje dodatnih alata (command and control komunikacija) ili za izvlačenje podataka. Stroža odlazna pravila ne sprečavaju prvi upad, ali značajno otežavaju sledeći korak napadača.

Šta treba uraditi

  • Za kritične servere (domain kontrolere, SQL servere, servere sa osetljivim podacima) razmotriti prelazak na "podrazumevano odbij" i za odlazni saobraćaj, uz eksplicitno dozvoljene destinacije koje server zaista koristi
  • Popisati stvarne odlazne zavisnosti servera pre uvođenja restriktivnih odlaznih pravila — Windows Update, NTP sinhronizacija, DNS upiti, i eventualne aplikativne integracije moraju biti unapred identifikovane, ne otkrivene tek kad prestanu da rade
  • Uključiti firewall logovanje (i za odbijene i za uspešne konekcije) i obezbediti dovoljnu veličinu log fajla — podrazumevana veličina je često premala za server sa ozbiljnijim saobraćajem, pa se stariji zapisi brzo prepisuju pre nego što neko stigne da ih pregleda

Napomena o riziku: uvođenje restriktivnih odlaznih pravila je operativno osetljivija promena od dolaznih pravila, jer aplikacije često imaju zavisnosti koje nisu odmah očigledne (npr. provera licence prema spoljnom serveru, telemetrija, automatska ažuriranja treće strane). Uvesti odlazna pravila postepeno, prvo u režimu beleženja i praćenja (bez stvarnog blokiranja), analizirati šta server zaista pokušava da kontaktira, i tek nakon te provere preći na aktivno blokiranje. Ovu promenu nikad ne raditi direktno u produkciji bez prethodnog perioda posmatranja.

Segmentacija na nivou uloge servera

Firewall pravila treba da odražavaju stvarnu ulogu servera, ne generički šablon primenjen na sve mašine podjednako. Domain kontroler ima potpuno drugačije mrežne potrebe od veb servera ili aplikativnog servera, i tretiranje svih servera kao da su isti tip mašine neizbežno vodi ili u preterano permisivna pravila (radi izbegavanja problema) ili u pravila koja stalno remete legitiman rad.

Šta treba uraditi

  • Grupisati servere prema ulozi (domain kontroleri, SQL serveri, veb serveri, fajl serveri) i za svaku grupu definisati zaseban skup GPO firewall pravila usklađen sa stvarnim potrebama te uloge
  • Ograničiti administrativni pristup (RDP, WinRM, upravljačke konzole) na tačno određene izvorne adrese sa upravljačke (management) mreže, nezavisno od uloge servera — ovo pravilo važi univerzalno, bez obzira na to čemu server inače služi
  • Izolovati servere različitih poverljivosti jedne od drugih — server izložen internetu ne bi trebalo da ima slobodnu mrežnu vidljivost ka internim serverima sa osetljivim podacima, čak i ako su formalno u istoj mreži

Microsoft Defender — Attack Surface Reduction pravila

Windows Server dolazi sa ugrađenim Microsoft Defender-om, koji uključuje Attack Surface Reduction (ASR) pravila — skup unapred definisanih zaštita koje blokiraju specifične, često zloupotrebljavane obrasce ponašanja (npr. izvršavanje sadržaja preuzetog putem mejla, pokretanje neobičnih skripti, čitanje LSASS memorije radi krađe kredencijala — direktno relevantno za teme iz AD hardening serije). Ova pravila su besplatna i uključena u sam OS, a u praksi ostaju neaktivna jer zahtevaju svesnu odluku o uključivanju i testiranju.

Šta treba uraditi

  • Uključiti ASR pravila prvo u Audit modu (ne odmah u Block modu) i pratiti rezultate bar 30 dana, kako bi se identifikovale legitimne aplikacije koje bi bile pogođene pravilom pre nego što se ono stvarno primeni
  • Nakon perioda auditinga, preći na Block mod za pravila koja nisu izazvala lažne pozitivne rezultate; za pravila koja jesu, prvo definisati precizne, uske izuzetke, ne isključivati pravilo u celini
  • Prioritetno uključiti pravilo koje blokira pristup LSASS memoriji od strane nepoverljivih procesa — ovo direktno otežava krađu kredencijala na kompromitovanom serveru, isti princip zaštite koji Credential Guard pruža na drugom nivou
  • Izuzetke (exclusions) definisati što uže moguće — tačno određena putanja ili proces, nikad ceo folder ili disk — jer širok izuzetak poništava svrhu pravila za sve što se nalazi u tom opsegu
  • Uključiti Tamper Protection, koja sprečava neovlašćeno gašenje ili izmenu Defender podešavanja — bez nje, kompromitovan administrativni nalog ili malver sa dovoljnim privilegijama može jednostavno ugasiti zaštitu pre nego što izvrši svoj glavni cilj

Napomena o riziku: Tamper Protection može sprečiti da promene ASR pravila ili drugih Defender podešavanja "prime" čak i kad je komanda naizgled uspešno izvršena — ako se podešavanja ne primenjuju kako se očekuje, proveriti status Tamper Protection-a pre nego što se pretpostavi da je sama komanda pogrešna. ASR pravila uključena direktno u Block modu, bez prethodnog audit perioda, mogu prekinuti rad specifičnih poslovnih aplikacija (posebno starijih skripti ili alata koji koriste obrasce slične onima koje pravila ciljaju) — ovo je posebno osetljivo na serverima koji hostuju prilagođen ili stariji softver, gde audit period nije opcioni korak, već neophodan.

Sledeći deo serije bavi se lokalnim bezbednosnim politikama u dubinu — User Rights Assignment na nivou servera, kontrolom instalacije softvera i uređaja, i osnovama BitLocker enkripcije diska za fizičke i virtuelne servere koji nisu domain kontroleri.

Comments

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)