Firewall Hardening – Deo 2: Pravila i segmentacija

Prvi deo serije postavio je osnovne pojmove — zone, default-deny, redosled pravila. Drugi deo prelazi na praktičan dizajn: kako izgleda DMZ arhitektura u realnoj primeni, i zašto je mikrosegmentacija unutar interne mreže danas jednako bitna kao i klasičan perimetar prema internetu — možda i bitnija, s obzirom na to gde se većina savremenog napada zapravo odvija nakon početnog upada.

Klasičan three-tier DMZ dizajn

Standardan, dobro proveren obrazac za javno dostupnu aplikaciju deli infrastrukturu na tri sloja: prezentacioni sloj (veb serveri, dostupni iz interneta), aplikativni sloj (poslovna logika, dostupan samo iz prezentacionog sloja), i sloj baze podataka (najosetljiviji, dostupan isključivo iz aplikativnog sloja). Prezentacioni sloj se smešta u DMZ — zonu koja je dostupna iz interneta, ali je istovremeno strogo ograničena u tome šta sme da dosegne dalje unutar mreže. Aplikativni i sloj baze podataka ostaju u internim, zaštićenijim segmentima, nikad direktno dostupni iz interneta.

Logika ovog rasporeda je namerna slojevitost: napadač koji uspe da kompromituje veb server u DMZ-u ne dobija automatski pristup bazi podataka — mora dodatno da probije granicu ka aplikativnom sloju, a zatim ponovo ka bazi, pri čemu svaka od tih granica predstavlja odvojenu priliku za detekciju i zaustavljanje. Ovo je suštinski ista logika slojevite odbrane koju smo detaljno obradili kroz Docker/Kubernetes seriju (seccomp, AppArmor, capabilities kao odvojeni slojevi) — ovde primenjena na nivou mrežne arhitekture umesto na nivou pojedinačnog kontejnera.

Rigorozniji varijanti ovog dizajna koristi dva odvojena firewall-a (spoljni, između interneta i DMZ-a, i unutrašnji, između DMZ-a i internih segmenata), idealno različitih proizvođača ili bar odvojenih instanci — ovo osigurava da ranjivost ili greška u konfiguraciji jednog firewall-a ne ugrozi automatski i drugu granicu.

Šta treba uraditi

• Smestiti svaki javno dostupan servis (veb aplikacije, mejl relej, DNS server dostupan spolja) u DMZ, nikad direktno u internu, poverljivu mrežu
• Dozvoliti komunikaciju iz DMZ-a ka internim segmentima isključivo na tačno određenim, potrebnim portovima ka tačno određenim odredištima — DMZ sistem ne treba širok pristup internoj mreži "za svaki slučaj", samo uzak, dokumentovan put ka onome što mu je stvarno potrebno
• Nikad ne dozvoliti da veza iz DMZ-a ka bazi podataka ili drugim osetljivim internim sistemima bude inicirana sa interne strane ka DMZ-u u suprotnom smeru bez jasne potrebe — smer inicijacije konekcije nosi bezbednosni značaj, ne samo krajnja dostupnost
• Za posebno osetljive scenarije, razmotriti arhitekturu sa dva odvojena firewall-a na granicama DMZ-a, po mogućstvu različitih proizvođača, kako bi se izbegla jedinstvena tačka otkaza na nivou same firewall platforme
• Prekidati enkriptovane sesije na granici (bastion host ili sam firewall sa SSL inspection mogućnošću, detaljnije obrađenom u trećem delu serije) gde je stvarna inspekcija sadržaja potrebna — enkriptovan saobraćaj koji nikad nije dekriptovan ne može biti stvarno pregledan, samo propušten ili blokiran u celini na osnovu metapodataka

Zašto istok-zapad saobraćaj zaslužuje jednaku pažnju kao i sever-jug

Terminologija vredi objašnjenja: sever-jug (north-south) saobraćaj označava komunikaciju koja ulazi ili izlazi iz mreže/data centra (klijent ka internet-facing serveru), dok istok-zapad (east-west) saobraćaj označava komunikaciju između sistema unutar iste mreže ili data centra (server ka serveru, aplikacija ka bazi, VM ka VM-u). Istraživanja dosledno pokazuju da 70 do 80 procenata ukupnog mrežnog saobraćaja u savremenom data centru čini upravo istok-zapad komunikacija — a ipak, istorijski, najveći deo firewall inspekcije i monitoring kapaciteta bio je usmeren isključivo na sever-jug granicu.

Ovo stvara ozbiljnu slepu tačku: tradicionalna "tvrda ljuska, meka sredina" arhitektura — snažan perimetar prema internetu, ali flat, nefiltrirana interna mreža — znači da napadač koji jednom probije perimetar (kroz phishing, kompromitovan endpoint, ili bilo koji drugi ulazni vektor koji ne prolazi kroz sam firewall) dobija gotovo neograničenu slobodu kretanja unutar interne mreže. Isti obrazac koji smo detaljno kritikovali za podrazumevanu Docker bridge mrežu i podrazumevano otvorenu Kubernetes pod-to-pod komunikaciju u ranijim serijama na ovom blogu ponavlja se ovde na nivou cele mrežne infrastrukture.

Šta treba uraditi

• Tretirati internu mrežu kao da sadrži potencijalno kompromitovane sisteme, ne kao homogeno poverljiv prostor — isti princip "zero trust" pretpostavke koji se provlači kroz svaku savremenu bezbednosnu arhitekturu
• Uvesti mikrosegmentaciju — granularnu kontrolu na nivou pojedinačnog radnog opterećenja ili male grupe radnih opterećenja, ne samo na nivou širokih mrežnih zona — za kritične sisteme i osetljive segmente
• Prioritizovati mikrosegmentaciju prema stvarnom riziku i kritičnosti, ne pokušavati odjednom pokriti celu infrastrukturu — počevši od najosetljivijih radnih opterećenja (baze podataka, sistemi sa regulisanim podacima) i šireći postepeno
• Uvesti vidljivost istok-zapad saobraćaja (kroz NDR — Network Detection and Response — alate ili ugrađene mogućnosti modernih NGFW platformi) kao preduslov za mikrosegmentaciju — ne mogu se pisati smislena pravila za saobraćaj čiji obrazac administrator prethodno nikad nije video

Metodologija uvođenja mikrosegmentacije — matrica komunikacije pre nego što se bilo šta blokira

Ovo je praktičan, proveren proces vredan detaljnog opisa, jer direktno rešava najveći praktičan rizik uvođenja mikrosegmentacije — nenamerno prekidanje legitimnog saobraćaja usled nedovoljnog razumevanja stvarnih obrazaca komunikacije pre nego što se restrikcije uvedu.

Prvi korak je izgradnja komunikacione matrice — sistematskog popisa koji beleži koja grupa radnih opterećenja (npr. "web-tier", "app-tier", "db-tier") stvarno komunicira sa kojom drugom grupom, i na kojim portovima. Ovo se gradi kroz period posmatranja (tipično dve do četiri nedelje) u kojem se saobraćaj prati i beleži, ali se ništa još ne blokira — isti princip audit/permissive/complain moda koji smo detaljno objasnili za SELinux, AppArmor, Docker seccomp profile, i Kubernetes Pod Security Standards kroz prethodne serije na ovom blogu, ovde primenjen na nivou mrežne segmentacije.

Šta treba uraditi

• Sprovesti period posmatranja (log-only/audit mod) pre bilo kakvog stvarnog blokiranja, prikupljajući realne podatke o tome ko sa kim zaista komunicira, umesto da se pravila pišu na osnovu pretpostavki o tome kako bi komunikacija trebalo da izgleda
• Organizovati prikupljene podatke u matricu — grupe radnih opterećenja kao redovi i kolone, dozvoljeni portovi kao sadržaj ćelija — koja postaje osnova (specifikacija) za stvarnu segmentacionu politiku
• Tretirati svaku praznu ćeliju u matrici (kombinacija grupa koja nikad nije zabeležena da komunicira) kao podrazumevano odbijenu — direktna primena default-deny principa iz prvog dela serije, sada na nivou grupa radnih opterećenja umesto pojedinačnih pravila
• Pregledati matricu sa vlasnicima aplikacija pre prelaska na stvarno sprovođenje — automatski prikupljeni podaci mogu propustiti retke, periodične tokove (npr. mesečni izveštaj koji se pokreće jednom mesečno) koji se nisu desili tokom kratkog perioda posmatranja
• Uvoditi sprovođenje (enforcement) postepeno, grupu po grupu, ne odjednom za celu infrastrukturu — isti princip fazne primene koji se ponavlja kroz svaku seriju na ovom blogu za operativno osetljive promene

Napomena o riziku: prelazak direktno na sprovođenje bez perioda posmatranja, ili prekratak period posmatranja koji ne pokrije periodične, retke obrasce saobraćaja, gotovo garantovano prekida legitimnu komunikaciju na način koji se ne otkriva odmah, već tek kad se taj redak obrazac sledeći put pojavi — često u najgorem mogućem trenutku (mesečno zatvaranje finansijskih knjiga, godišnji izveštaj). Produžiti period posmatranja za sisteme sa poznato neredovnim obrascima korišćenja, i zadržati mogućnost brzog vraćanja na permisivniji mod ako se nakon sprovođenja otkrije nedostajući, legitiman tok.

Segmentacija po identitetu — otpornost na promenu IP adrese

Vredi pomenuti noviji, sve rasprostranjeniji pristup koji rešava praktičan problem klasične, IP-bazirane segmentacije: pravilo koje kaže "dozvoli port 443 sa 10.0.1.0/24" prestaje da važi čim se radno opterećenje premesti, ponovo zakaže (u kontekstu kontejnera ili cloud auto-scaling-a), ili jednostavno dobije novu IP adresu. Identitet-bazirana mikrosegmentacija umesto toga definiše pravila na osnovu atributa identiteta radnog opterećenja — članstva u bezbednosnoj grupi, oznake (label) u orkestracionom sistemu, ili kriptografskog identiteta (npr. SPIFFE/SPIRE standard) — koji ostaje validan bez obzira na promenu IP adrese ispod njega.

Šta treba uraditi

• Za okruženja sa čestim promenama IP adresa (kontejnerizovane radne opterećenja, cloud auto-scaling grupe), razmotriti identitet-baziranu segmentaciju umesto klasičnih, statičkih IP pravila — isti princip label-baziranog pristupa koji smo detaljno obradili za Kubernetes NetworkPolicy u ranijoj seriji, proširen ovde na širu mrežnu infrastrukturu
• Dizajnirati pravila oko uloge radnog opterećenja (web-tier, app-tier, db-tier), ne oko pojedinačne instance — pravilo "web-tier sme da dosegne db-tier na portu 5432" preživljava restart, reskaliranje ili premeštanje pojedinačnih instanci bez potrebe za ručnim ažuriranjem
• Za tradicionalnu, statičku infrastrukturu (fizički serveri sa stabilnim IP adresama), IP-bazirana segmentacija ostaje sasvim adekvatna — identitet-bazirani pristup rešava problem koji u statičkom okruženju jednostavno ne postoji u istoj meri, i uvođenje dodatne složenosti bez stvarne potrebe nije opravdano

Sledeći deo serije prelazi na napredne NGFW mogućnosti — IPS/IDS funkcionalnost, SSL/TLS inspekciju i njene kompromise, i application-aware filtriranje koje omogućava da firewall donosi odluke na osnovu stvarne aplikacije, ne samo porta i protokola, kako je najavljeno u prvom delu serije.