Windows Server Hardening – Deo 1: Osnovna bezbednosna podešavanja i lokalne politike

Ovim tekstom počinje nova serija posvećena hardeningu Windows Server operativnog sistema — teme koja je do sada u ovoj rubrici pominjana samo usput, kroz Active Directory i MSSQL serije, ali nikad nije bila sama sebi cilj. A trebalo bi da bude: domain kontroler, SQL server ili bilo koja aplikacija na vrhu je samo onoliko bezbedna koliko je bezbedan operativni sistem ispod nje. Prvi deo pokriva osnovu — lokalne administratorske naloge, RDP pristup i uklanjanje zastarelih protokola koji i dalje, iznenađujuće često, ostaju uključeni.

Zašto je OS sloj lako zapostavljen

Uobičajen obrazac u praksi: pažnja ide ka aplikaciji koja radi na serveru — bazi, veb serveru, domain kontroleru — dok sam operativni sistem ostaje na podešavanjima sa dana instalacije. Razlog je razumljiv: aplikacija je ono što se svakodnevno koristi i za šta postoji jasna poslovna potreba, dok OS hardening deluje kao apstraktan, "pozadinski" zadatak bez opipljivog rezultata — sve dok se ne desi incident u kojem se ispostavi da je baš propust na OS nivou (deljena lokalna admin lozinka, otvoren RDP, ugašen SMB signing) bio ulazna tačka.

Security baseline kao polazna tačka

Isti princip koji smo primenili u seriji o Active Directory-ju i Group Policy-ju važi i ovde: hardening ne treba raditi od nule, ručnim pogađanjem podešavanja, već preuzimanjem Microsoft-ovog zvaničnog Security Baseline-a za odgovarajuću verziju Windows Server-a i njegovom prilagodbom. Za Windows Server 2025, najnovija revizija (verzija 2602, februar 2026) donosi nekoliko bezbednosno značajnih promena — među njima gašenje "sudo" komandnog režima na članskim serverima i domain kontrolerima radi smanjenja rizika od zaobilaženja User Account Control-a, i strožu proveru ROCA-ranjivih Windows Hello for Business ključeva.

Za primenu baseline-a, Windows Server 2025 uvodi i noviji alat — OSConfig — koji omogućava primenu unapred pripremljenih scenarija (npr. SecurityBaseline/WindowsServer/2025/MemberServer ili .../DomainController) kroz PowerShell, Windows Admin Center ili Azure Policy, uz mogućnost da se prati i automatski ispravlja odstupanje (configuration drift) od zadatog stanja tokom vremena.

Šta treba uraditi

• Preuzeti najnoviji Microsoft Security Baseline (ili koristiti OSConfig scenario) za tačnu verziju i ulogu servera (Domain Controller, Member Server, Workgroup Member) — baseline za pogrešnu ulogu servera primenjuje nepotrebna ili nedovoljna ograničenja
• Razmotriti i CIS Benchmark za Windows Server kao dodatnu referencu — CIS nudi dva nivoa (Level 1 za praktičan baseline bez značajnog operativnog uticaja, Level 2 za striktnija okruženja koja zahtevaju detaljno testiranje) i mapira se na standarde poput ISO 27001, što je posebno korisno u kontekstu ranije objavljene ISO 27001 serije na ovom blogu
• Baseline primenjivati kroz Group Policy ili OSConfig, nikad ručnim, pojedinačnim podešavanjem svakog servera — ručna primena garantovano vodi u nekonzistentnost između servera vremenom
• Uključiti drift detection (praćenje odstupanja od zadate konfiguracije), gde alat to podržava, kako bi se neplanirane ili neovlašćene izmene automatski uočile

Napomena o riziku: baseline nikad ne treba primenjivati direktno u produkciji bez prethodnog testiranja — pojedina podešavanja (npr. stroža SMB politika ili gašenje starijih protokola) mogu prekinuti rad starijih aplikacija, štampača ili uređaja koji na njih i dalje oslanjaju. Primeniti baseline prvo u test okruženju ili na manjoj grupi servera, pratiti rezultate kroz period auditinga gde je to moguće, i tek onda širiti na celu infrastrukturu.

Lokalni administratorski nalozi

Deljena lokalna administratorska lozinka — ista na svim serverima u organizaciji — ostaje jedan od najčešćih, a najozbiljnijih nalaza na tehničkim proverama. Ako napadač kompromituje jedan server i izvuče heš te lozinke, može istim kredencijalima (pass-the-hash) da se prijavi na svaki drugi server koji deli tu istu lozinku, čime se jedan probijen server pretvara u kompromitaciju cele infrastrukture.

Rešenje je Windows LAPS (Local Administrator Password Solution) — funkcija koja je od 2023. ugrađena direktno u operativni sistem (bez potrebe za starijim MSI instalerom), sa podrškom za enkriptovano čuvanje lozinke i mogućnošću korišćenja Active Directory-ja ili Microsoft Entra ID-a kao pozadinskog skladišta. Svaki server dobija jedinstvenu, redovno rotiranu lokalnu admin lozinku, čime se pass-the-hash lateralno kretanje efektivno onemogućava za ovaj konkretan vektor.

Šta treba uraditi

• Uvesti Windows LAPS na svim serverima, uključujući i domain kontrolere (gde LAPS može dodatno da upravlja i Directory Services Restore Mode lozinkom)
• Ako je u upotrebi starija (legacy) verzija LAPS-a, planirati migraciju na ugrađenu verziju — starija verzija čuva lozinke u AD atributu bez enkripcije, što predstavlja nepotreban rizik
• Postaviti rotaciju lozinke nakon svake autentifikacije (post-authentication rotation), ne samo na fiksnom vremenskom intervalu, kako bi se dodatno otežalo ponovno korišćenje jednom preuzete lozinke
• Strogo ograničiti i auditirati ko sme da preuzme (retrieve) LAPS lozinku iz AD-a ili Entra ID-a — pravo čitanja LAPS lozinke je samo po sebi privilegovan pristup i treba mu pristupiti sa istom pažnjom kao i članstvu u administratorskim grupama, opisanim u AD hardening seriji

RDP — pristup koji se najčešće izlaže greškom

Remote Desktop Protocol ostaje standardni način administracije Windows servera, ali i standardan ulazni vektor kad je loše podešen — direktno izložen internetu, bez ograničenja izvora konekcije, ili sa slabom autentifikacijom. Network Level Authentication (NLA) je osnovna, a često i dalje neuključena zaštita: zahteva da se korisnik autentifikuje pre nego što se uopšte uspostavi puna RDP sesija, čime se sprečavaju napadi koji ciljaju sam proces uspostavljanja sesije, pre bilo kakve autentifikacije.

Šta treba uraditi

• Nikad ne izlagati RDP direktno internetu — pristup obezbediti isključivo preko VPN-a, Remote Desktop Gateway-a sa MFA, ili slične posredničke zaštite
• Uključiti Network Level Authentication (NLA) na svim serverima gde RDP mora ostati aktivan
• Ograničiti RDP pristup na nivou Windows Firewall-a na tačno određene izvorne IP adrese ili mrežne segmente uprave (management network), ne na celu korisničku mrežu
• Ograničiti članstvo u lokalnoj Remote Desktop Users grupi na tačno određene naloge kojima je pristup zaista potreban, po istom principu najmanjih privilegija koji važi i za AD grupe
• Razmotriti Remote Credential Guard za direktne RDP konekcije unutar domena — ova funkcija preusmerava Kerberos zahteve ka klijentu umesto da šalje kredencijale na odredišni server, čime se smanjuje rizik krađe kredencijala sa kompromitovanog odredišta; napomena — ne radi preko RD Gateway-a ili Connection Broker-a, pa kompatibilnost treba proveriti za stvarni put pristupa koji se koristi

Napomena o riziku: ograničavanje RDP pristupa na određene IP adrese ili grupe može, ako se uradi bez prethodne provere, odseći legitimne administratore koji rade sa promenljivih lokacija ili preko VPN-a sa dinamičkim adresama — pre primene, popisati sve stvarne izvore administrativnog pristupa. Uključivanje NLA takođe zahteva da svi klijenti koji se konektuju podržavaju ovu funkciju; vrlo stari RDP klijenti to možda ne podržavaju, pa promenu treba najaviti i testirati pre šire primene.

Gašenje zastarelih protokola

SMBv1 je star, ranjiv protokol (poznat po iskorišćavanju u EternalBlue napadu) koji na mnogim serverima ostaje uključen samo zato što ga niko nije eksplicitno isključio, ne zato što je stvarno potreban. Isto važi za starije verzije TLS/SSL protokola, koje mogu ostati aktivne uporedo sa novijim, bezbednijim verzijama, čime se otvara mogućnost da se konekcija svesno degradira na slabiji protokol.

Šta treba uraditi

• Isključiti SMBv1 na svim serverima gde nije eksplicitno, dokumentovano potreban za rad sa starijim uređajem ili aplikacijom
• Uključiti SMB Server signing i, gde je podržano, Extended Protection for Authentication (EPA) — Microsoft je uveo audit režim za obe funkcije upravo da bi se pre same primene otkrili klijenti koji ne bi preživeli tu promenu
• Onemogućiti starije verzije TLS/SSL protokola (SSL 3.0, TLS 1.0, TLS 1.1) gde poslovni zahtevi to dozvoljavaju, i zadržati isključivo TLS 1.2 i noviji
• Periodično proveravati koji su servisi i portovi zaista aktivni na svakom serveru (npr. kroz netstat ili odgovarajući alat) i isključiti sve što ne odgovara stvarnoj nameni tog servera

Napomena o riziku: gašenje SMBv1 ili starijih TLS verzija može prekinuti komunikaciju sa starijim uređajima (npr. stariji mrežni štampači, NAS uređaji, ili industrijska oprema) koji ne podržavaju novije protokole. Pre isključivanja, koristiti dostupne audit funkcije (SMB compatibility auditing) da se identifikuju svi klijenti koji se oslanjaju na stariji protokol, i tek nakon te provere preći na potpuno isključivanje.

Sledeći deo serije bavi se firewall politikom i segmentacijom na nivou samog servera, kao i Windows Defender/EDR osnovama — šta znači "podrazumevano odbij" (default deny) pristup u praksi, i kako uskladiti tu politiku sa realnim potrebama servera koji mora da komunicira sa desetinama drugih sistema u mreži.