File Server Hardening – Deo 1: Windows File Server – Share i NTFS dozvole

Ovim tekstom počinje nova serija posvećena hardeningu fajl servera — prvo Windows, zatim Linux u nastavku serije, sa zajedničkim temama na kraju. Fajl server zaslužuje sopstvenu, posvećenu seriju jer je specifičan slučaj: za razliku od baze podataka ili aplikativnog servera, ovde je "sadržaj" doslovno svaki fajl koji je iko ikad tamo sačuvao — ugovori, finansijski podaci, lični podaci zaposlenih, sve pomešano u istoj strukturi foldera, često izgrađenoj godinama, bez ikad sprovedene sistematske revizije ko šta stvarno sme da vidi. Prvi deo pokriva osnovu Windows fajl servera — share i NTFS dozvole, i protokol (SMB) preko kojeg se do njih dolazi.

Dva sloja dozvola koja se lako mešaju

Windows fajl server ima dva potpuno odvojena sloja kontrole pristupa, i zabuna između njih je jedan od najčešćih izvora grešaka u praksi. Share dozvole (share permissions) kontrolišu pristup na nivou mrežnog deljenja — da li neko sme uopšte da se poveže na taj share preko mreže, i sa kojim maksimalnim nivoom pristupa. NTFS dozvole kontrolišu pristup na nivou samog fajl sistema — šta neko konkretno sme da radi sa fajlovima i folderima, bilo da im pristupa preko mreže ili direktno na samom serveru.

Kad korisnik pristupa fajlu preko mreže (najčešći slučaj za fajl server), oba sloja se primenjuju istovremeno, i važi pravilo najstrožeg preseka — efektivna dozvola je ono što je zajedničko i share i NTFS dozvolama, ne ono što je šire od njih dvoje. Ako share dozvola dozvoljava "Full Control", ali NTFS dozvola dozvoljava samo "Read", krajnji rezultat je "Read" — i obrnuto. Ovo je bitno razumeti pre bilo kakve odluke o tome koji sloj koristiti za šta.

Šta treba uraditi

• Koristiti NTFS dozvole kao primaran, detaljan mehanizam kontrole pristupa — one važe dosledno bez obzira na to da li se pristupa preko mreže ili lokalno, i nude znatno finiju granularnost (posebna prava poput brisanja, izmene dozvola, preuzimanja vlasništva) od share dozvola
• Na nivou share dozvola, izbegavati podrazumevano ponašanje koje mnogi vodiči i dalje predlažu — "Everyone Full Control" na share sloju "jer NTFS ionako sve ograničava" — i umesto toga postaviti share dozvole na razumno ograničen nivo (npr. Authenticated Users sa Change umesto Full Control), tako da čak i greška na NTFS sloju ne ostane jedina linija odbrane
• Nikad ne dodeljivati dozvole pojedinačnim korisničkim nalozima direktno — koristiti isključivo AD bezbednosne grupe, po istom principu opisanom kroz celu ovu i prethodne serije na ovom blogu; direktno dodeljena dozvola postaje "siroče" u trenutku kad korisnik napusti organizaciju ili promeni ulogu, jer niko sistematski ne prati pojedinačne dozvole van grupa
• Grupisati resurse sa istim zahtevima za pristup u iste foldere — ako jedan odsek zahteva čitanje, a drugi izmenu, to su po definiciji dva različita foldera sa različitim dozvolama, ne isti folder sa pokušajem da se razlike izraze kroz komplikovane izuzetke

Napomena o riziku: promena postojećih share ili NTFS dozvola na aktivnom, produkcionom fajl serveru može trenutno prekinuti pristup aplikacijama ili korisnicima koji su se, možda i nesvesno, oslonili na preširoku, postojeću dozvolu. Pre bilo koje izmene na velikom, već postojećem folderu, popisati stvarne korisnike i grupe koje trenutno pristupaju tom resursu (kroz Effective Access karticu u NTFS svojstvima ili sličan alat), i sprovesti izmenu postepeno, uz jasnu najavu i period praćenja, ne kao jednokratnu, iznenadnu promenu na velikom obimu podataka.

Princip najmanjih privilegija — isti princip, drugi kontekst

Ovo je isti princip koji se provlači kroz celu ovu seriju blogova — od AD delegacije, preko MSSQL rola, do Kubernetes RBAC-a — ovde primenjen na fajlove i foldere. Realnost u praksi je da većina korisnika treba samo da čita podatke, ne da ih menja ili briše, a "Modify" ili "Full Control" dozvola se često dodeljuje "da se ne bi javljale greške", isti obrazac koji smo kritikovali kroz svaku prethodnu seriju kad se pojavio u drugom kontekstu.

Šta treba uraditi

• Za većinu korisnika i grupa, dodeljivati Read ili Read & Execute dozvolu kao podrazumevanu — Modify i Full Control rezervisati za jasno definisan, uzak krug korisnika kojima je izmena ili brisanje fajlova stvarno deo posla
• Nikad ne dodeljivati Full Control običnim korisnicima — ova dozvola uključuje mogućnost izmene dozvola samog foldera i preuzimanja vlasništva, što efektivno znači da korisnik može sam sebi (ili drugima) dodeliti šira prava mimo IT tima, potpuno mimo formalnog procesa
• Ograničiti dubinu ugnježdenih, prilagođenih (custom) dozvola na dva do tri nivoa strukture foldera — duboko ugnježdene, međusobno različite dozvole na svakom pod-nivou brzo postaju nemoguće za pregled i reviziju, i u praksi niko posle izvesnog vremena tačno ne zna zašto je neki pod-folder izuzet od pravila roditeljskog foldera
• Koristiti nasleđivanje (inheritance) dozvola sa roditeljskog foldera kao podrazumevano ponašanje, i prekidati nasleđivanje samo tamo gde postoji jasna, dokumentovana potreba za drugačijim pristupom na tom konkretnom pod-nivou
• Sprovoditi redovnu (bar polugodišnju) reviziju dozvola — isti princip periodičnog pregleda AD grupa, sudo pravila i Kubernetes RoleBinding objekata opisan kroz prethodne serije, ovde primenjen na strukturu foldera fajl servera

File traversal — zaboravljen, ali koristan detalj

Vredi pomenuti manje poznato, ali korisno podešavanje: Windows po difoltu dozvoljava "Bypass traverse checking" pravo grupi Everyone, što znači da korisnik može da pristupi konkretnom fajlu duboko u strukturi foldera, čak i ako nema dozvolu da vidi sadržaj svih nadređenih (roditeljskih) foldera na putu do njega — pod uslovom da tačno zna putanju do tog fajla. Ovo je podešavanje koje retko treba menjati bez potpunog razumevanja posledica, ali korisno je znati da postoji, jer objašnjava scenarije koji na prvi pogled deluju kao greška u dozvolama ("kako korisnik ima pristup ovom fajlu kad nema pristup folderu iznad njega") a zapravo su očekivano ponašanje sistema.

SMB protokol — kanal kroz koji se sve ovo prenosi

Dobro postavljene dozvole ne pomažu mnogo ako je sam protokol kojim se do fajlova dolazi ranjiv ili nezaštićen. SMB (Server Message Block) je protokol koji Windows fajl server koristi za mrežno deljenje, i njegova bezbednost zaslužuje istu pažnju kao i sami podaci koje prenosi.

SMBv1 — najstarija verzija protokola, poznata po iskorišćavanju u WannaCry ransomware napadu kroz EternalBlue ranjivost — nema enkripciju, ima slabu autentifikaciju i sadrži poznate, javno dokumentovane propuste. Microsoft je SMBv1 zvanično označio kao zastareo još 2014. godine i isključio ga po difoltu u novijim verzijama Windows-a, ali protokol i dalje ostaje aktivan na mnogim starijim ili nepažljivo održavanim fajl serverima — obično ne zato što je stvarno potreban, već zato što ga niko nikad nije eksplicitno isključio.

Šta treba uraditi

• Proveriti da li je SMBv1 uključen (`Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol`) i, ako jeste, planirati njegovo isključivanje — prvo kroz period auditinga (uključivanjem SMBv1 audit logovanja i praćenjem Event ID 3000 kroz bar dvadesetak dana) kako bi se identifikovali eventualni stariji uređaji ili aplikacije koji ga i dalje koriste, pre stvarnog isključivanja
• Zahtevati SMB signing (RequireSecuritySignature) i na server i na klijent strani, ne samo na jednoj — ako je zahtev postavljen samo na jednoj strani, a druga strana ga "prihvata ako se traži" ali ga sama ne zahteva, signing se svejedno dešava, ali je ovo krhka konfiguracija koja lako ostane nedosledna kroz veći broj mašina
• Uključiti SMB enkripciju za osetljive share-ove, posebno tamo gde saobraćaj prolazi kroz mrežne segmente van striktno kontrolisane, poverljive interne mreže — noviji Windows Server oslobađa veći deo ranije performansne cene enkripcije kroz poboljšanu podršku za RDMA, čineći enkripciju realniju opciju i za saobraćaj velikog obima
• Postaviti minimalnu dozvoljenu SMB verziju eksplicitno na 3.1.1 gde okruženje to dozvoljava, umesto da se protokol prepusti automatskom pregovaranju (negotiation) koje po difoltu prihvata širi opseg starijih verzija
• Osloniti se na ugrađeni SMB authentication rate limiter (podrazumevano uključen u novijim verzijama, sa kašnjenjem od nekoliko sekundi između neuspešnih pokušaja autentifikacije) kao dodatnu, besplatnu zaštitu od brute-force pokušaja pogađanja lozinke direktno kroz SMB protokol, i proveriti da nije nenamerno isključen

Napomena o riziku: isključivanje SMBv1 je operacija koja može prekinuti pristup starijim uređajima (mrežni skeneri, stariji NAS uređaji, specijalizovana oprema) koji ne podržavaju novije verzije protokola — ovo je tačno scenario upozorenja iz Windows Server hardening serije, ovde ponovljen u konkretnom kontekstu fajl servera. Sprovesti period auditinga pre isključivanja, ne isključivati direktno na produkciji bez prethodne provere, izuzev u slučaju aktivnog incidenta (npr. ransomware koji se aktivno širi kroz SMBv1), gde je prihvatljivo prihvatiti privremen prekid rada starijih uređaja kao manje loš ishod od nastavka širenja napada.

Sledeći deo serije bavi se dodatnim Windows fajl server funkcijama namenjenim specifično za ovu ulogu — File Server Resource Manager (FSRM) za kvote i blokiranje tipova fajlova, Shadow Copies kao brza linija odbrane protiv slučajnog brisanja ili ransomware enkripcije, i auditom pristupa fajlovima — ko je i kada tačno otvorio, izmenio ili obrisao koji fajl.