File Server Hardening – Deo 4: Linux File Server – NFS hardening

Treći deo serije pokrio je Samba — protokol za deljenje fajlova sa Windows klijentima. Četvrti deo se bavi NFS-om (Network File System), starijim, izvorno Unix/Linux protokolom koji se i dalje široko koristi za deljenje fajlova između Linux/Unix sistema, posebno u infrastrukturama sa virtuelizacijom, kontejnerima i naučnim ili tehničkim radnim opterećenjima. NFS ima suštinski drugačiji model bezbednosti od SMB-a, i njegove podrazumevane postavke nose rizike koji zaslužuju posebno, eksplicitno objašnjenje.

Osnovna, fundamentalna razlika u odnosu na SMB — poverenje bazirano na klijentu

Ovo je najbitnija konceptualna razlika koju treba razumeti pre bilo čega drugog. SMB (i Samba, opisana u prethodnom delu) zahteva da se korisnik autentifikuje sa korisničkim imenom i lozinkom (ili Kerberos tiketom) pri svakom pristupu. Starije verzije NFS-a (NFSv2 i NFSv3), u svom podrazumevanom, najčešće korišćenom režimu autentifikacije (sec=sys, poznat i kao AUTH_SYS), rade na potpuno drugačijem principu: server veruje broju korisničkog identifikatora (UID) koji mu klijentska mašina sama prijavi, bez ikakve nezavisne provere da li je ta mašina zaista taj korisnik.

Praktična posledica ovog dizajna je ozbiljna: ako napadač uspe da dobije root pristup bilo kojoj mašini kojoj je dozvoljeno da montira (mount) NFS share, može jednostavno da kreira lokalni nalog sa istim UID-om kao ciljani korisnik na serveru (npr. UID 1000) i NFS server će mu, bez ikakve dalje provere, dozvoliti pristup kao da je zaista taj korisnik. Ovo nije propust u implementaciji koji čeka na zakrpu — ovo je fundamentalan dizajn AUTH_SYS mehanizma, prisutan otkad NFS postoji.

NFSv2/v3 dodatno nemaju enkripciju u prenosu

Dodatno pogoršanje: NFSv2 i NFSv3, u svom standardnom radu, ne enkriptuju saobraćaj u prenosu. Ne samo da UID prijavljen od strane klijenta nije nezavisno proveren, već ni sam sadržaj fajlova koji putuje mrežom nije zaštićen od prisluškivanja — bilo ko sa pristupom istom mrežnom segmentu može čitati sadržaj fajlova u prenosu direktno iz mrežnog saobraćaja, bez potrebe da uopšte pokušava da zaobiđe autentifikaciju.

Šta treba uraditi

• Za nove implementacije, koristiti isključivo NFSv4 ili noviju verziju — NFSv4 unosi obavezan RPCSEC_GSS mehanizam koji omogućava stvarnu Kerberos autentifikaciju, umesto oslanjanja na to da klijent "iskreno" prijavi svoj UID
• Za NFSv4, koristiti sec=krb5 kao minimum za autentifikaciju bez oslanjanja na "iskrenost" klijenta, a sec=krb5p (Kerberos sa punom enkripcijom podataka u prenosu) tamo gde poverljivost sadržaja fajlova ima stvaran značaj — ovo zahteva postojeću Kerberos infrastrukturu (KDC), tipično već prisutnu ako je organizacija integrisana sa Active Directory-jem opisanim kroz AD hardening seriju na ovom blogu
• Ako NFSv3 mora ostati u upotrebi zbog starijih klijenata koji ne podržavaju NFSv4, tretirati taj export kao osetljiviju tačku koja zahteva strožu mrežnu izolaciju (opisanu dalje u tekstu), jer aplikativna zaštita na nivou samog protokola u tom slučaju izostaje
• Ako NFS saobraćaj ikad prelazi preko mreže koja nije u potpunosti poverljiva (bilo koji segment gde bi presretanje saobraćaja bilo realno moguće), koristiti sec=krb5p ili tunelovati saobraćaj kroz VPN — nikad ne oslanjati se na neenkriptovan NFSv3 saobraćaj preko takve mreže

Napomena o riziku: prelazak sa NFSv3 na NFSv4 sa Kerberos autentifikacijom je netrivijalna migracija koja zahteva usklađenu Kerberos infrastrukturu na svim učesnicima (server i svaki klijent), i može privremeno prekinuti pristup starijim klijentima koji ne podržavaju noviju konfiguraciju. Planirati ovo kao poseban projekat sa periodom paralelnog rada oba pristupa i temeljnim testiranjem, ne kao brzu izmenu konfiguracije na aktivnom, produkcionom exportu.

root_squash — podešavanje koje nikad ne treba isključiti bez ozbiljnog razloga

Ovo je pojedinačno najvažnije, konkretno podešavanje u celom NFS exportu, i zaslužuje detaljno objašnjenje mehanizma. Podrazumevano, NFS primenjuje "root squashing" — kad se korisnik sa UID 0 (root) na klijentskoj mašini poveže na NFS export, server automatski mapira taj zahtev na neprivilegovanog korisnika (tipično nazvanog nobody ili nfsnobody), umesto da mu dozvoli da deluje kao root na samom serveru. Ovo je zaštita, po difoltu uključena, upravo protiv scenarija opisanog ranije u tekstu — kompromitovan klijent sa root pristupom ne dobija automatski i root pristup podacima na serveru.

Opcija no_root_squash isključuje ovu zaštitu, dozvoljavajući da root na klijentu zaista deluje kao root na serveru za taj konkretan export. Ovo se povremeno koristi za legitimne, uske potrebe (npr. specifičan backup alat koji zaista treba root pristup), ali predstavlja ozbiljan rizik ako se primeni šire nego što je stvarno potrebno — kompromitacija bilo kog klijenta kome je dozvoljen pristup takvom exportu direktno vodi ka punoj kompromitaciji podataka na serveru, bez ijedne dodatne prepreke.

Šta treba uraditi

• Zadržati podrazumevano ponašanje root_squash na svakom exportu, osim ako postoji vrlo konkretan, dokumentovan, uzak razlog za suprotno
• Ako je no_root_squash zaista neophodan za specifičan, legitiman slučaj, ograničiti ga na tačno određen, uzak opseg klijentskih adresa (nikad na širok opseg ili "sve"), i tretirati taj export kao posebno osetljivu tačku koja zahteva pojačan nadzor
• Za read-only exportove namenjene širem, manje poverljivom krugu klijenata, razmotriti all_squash umesto samo root_squash — all_squash mapira svakog korisnika, ne samo root, na neprivilegovanog nfsnobody naloga, čime se u potpunosti uklanja mogućnost da bilo koji UID prijavljen od strane klijenta ima poseban značaj na serveru
• Periodično (kao deo redovne bezbednosne revizije) proveriti sadržaj /etc/exports fajla na svim NFS serverima i potvrditi da nijedan export nema no_root_squash bez jasnog, i dalje važećeg razloga — ovo je tačno onaj tip podešavanja koje se lako postavi "privremeno" za rešavanje jednog problema i nikad ne ukloni

Eksplicitno ograničavanje exportova — nikad "svima"

Isti "default deny, eksplicitno dozvoli" princip koji se provlači kroz celu ovu seriju blogova primenjuje se i na NFS exportove — /etc/exports fajl treba da eksplicitno navede tačno koji klijenti (po IP adresi, opsegu ili hostname-u) smeju da montiraju svaki konkretan export, nikad wildcard koji dozvoljava pristup sa bilo koje adrese.

Šta treba uraditi

• Zameniti svaki wildcard export (npr. *(rw)) eksplicitnom listom dozvoljenih klijenata ili tačno definisanim mrežnim opsegom (npr. 192.168.10.0/24(rw))
• Koristiti ro (read-only) kao podrazumevani izbor gde god pisanje nije stvarno potrebno, po istom principu najmanjih privilegija koji se provlači kroz celu seriju
• Koristiti sync opciju umesto async — sync garantuje da se izmene stvarno upišu na disk pre nego što server potvrdi klijentu uspešnu operaciju, čime se smanjuje rizik gubitka ili nekonzistentnosti podataka u slučaju iznenadnog prekida rada servera
• Nakon svake izmene /etc/exports fajla, primeniti izmenu kroz `exportfs -ra` i proveriti stvarno aktivno stanje kroz `exportfs -v`, kako bi se potvrdilo da je konfiguracija zaista učitana onako kako je napisana, ne samo sintaksno ispravna

Mount opcije na klijentskoj strani — dodatan sloj koji se lako zaboravi

Zaštita ne mora da bude isključivo na strani servera — klijent koji montira NFS share takođe može dodati ograničenja koja smanjuju štetu u slučaju da server (ili sam export) ipak bude preterano permisivan. Ovo je dodatan, nezavisan sloj, koristan čak i kad je server-strana konfiguracija besprekorna.

Šta treba uraditi

• Montirati NFS share sa opcijom nosuid, koja sprečava da setuid/setgid biti na izvršnim fajlovima sa tog share-a imaju efekat — ovo direktno sprečava čest put eskalacije privilegija kroz zlonamerno postavljen izvršni fajl na deljenom prostoru
• Montirati sa opcijom noexec tamo gde share sadrži isključivo podatke, ne izvršne fajlove koje bilo ko treba direktno da pokreće sa te lokacije — ovo u potpunosti sprečava izvršavanje bilo kog fajla sa tog montiranog prostora, nezavisno od dozvola samog fajla
• Izbegavati insecure opciju (koja dozvoljava klijentu da koristi ne-rezervisane, visoke portove za NFS komunikaciju) osim ako postoji konkretan tehnički razlog — rezervisani portovi (ispod 1024) zahtevaju root privilegije za korišćenje na klijentu, što predstavlja slabu, ali postojeću dodatnu prepreku protiv neprivilegovanog korisnika koji pokušava direktno da komunicira sa NFS serverom

Mrežna izolacija — portovi 2049 i 111

NFS koristi port 2049 za sam fajl transfer, i (kod NFSv3, i delimično kod NFSv4 u zavisnosti od konfiguracije) port 111 za RPC portmapper servis koji klijentima pomaže da pronađu odgovarajuće NFS servise. Oba porta treba tretirati sa istom pažnjom kao i bilo koji drugi osetljiv mrežni servis opisan kroz seriju o hardeningu Linux servera.

Šta treba uraditi

• Ograničiti pristup portovima 2049 i 111 (i dodatnim portovima koje koriste pomoćni NFS servisi poput mountd i statd, ako su eksplicitno konfigurisani na fiksne portove radi lakšeg upravljanja firewall-om) isključivo na poznate, poverljive klijentske mreže, po istom principu default-deny firewall politike opisanom u drugom delu Linux Server hardening serije
• Nikad ne izlagati NFS servis direktno internetu — NFS je dizajniran za rad unutar poverljive, lokalne mreže, ne kao internet-facing servis; ako je udaljen pristup zaista potreban, tunelovati saobraćaj kroz VPN, ne izlagati portove direktno
• Onemogućiti NFSv2 servisnu podršku ako se ne koristi (mnoge distribucije je i dalje nude iz razloga kompatibilnosti unazad), po istom principu smanjenja površine napada kroz gašenje nepotrebnih servisa opisanom u drugom delu Linux Server hardening serije

Napomena o riziku: uvođenje strožih mrežnih pravila na postojećem, aktivnom NFS serveru može prekinuti pristup klijentima koji trenutno nisu eksplicitno uzeti u obzir — popisati sve stvarne klijente koji trenutno montiraju svaki export pre nego što se pravila pooštre, i sprovesti izmenu u kontrolisanom prozoru za održavanje, po istom principu opreza koji se provlači kroz svaku izmenu opisanu u ovoj seriji.

Ovim se zaokružuje pregled Samba i NFS hardeninga, i sa njim glavni, protokol-specifičan deo serije o fajl serverima. Poslednji, zajednički deo serije bavi se temama koje važe nezavisno od toga da li je fajl server Windows ili Linux — osnovama zaštite od gubitka podataka (DLP) i dodatnim, praktičnim merama specifično usmerenim na otpornost prema ransomware napadima na nivou samog fajl servera.