Firewall Hardening – Deo 1: Osnove i arhitektura

Ovim tekstom počinje nova serija posvećena firewall-u kao samostalnoj temi — mrežnim uređajima koji stoje na granicama poverljivosti unutar infrastrukture, za razliku od host-based firewall-a (Windows Defender Firewall, nftables/UFW/firewalld) koji smo detaljno obradili u ranijim serijama na ovom blogu. Serija ide od osnovnih pojmova i arhitekture, preko dizajna pravila i segmentacije, do naprednih NGFW mogućnosti, i na kraju konkretnih platformi — pfSense/OPNsense, Fortinet i Palo Alto. Prvi deo postavlja terminologiju i osnovne principe bez kojih dalji delovi serije neće imati čvrsto uporište.

Evolucija firewall-a — od porta do aplikacije

Vredi razumeti kratku istoriju pre nego što pređemo na savremeno stanje, jer objašnjava zašto današnji firewall uređaji rade ono što rade. Prva generacija — packet-filtering firewall — donosila je odluku o svakom paketu izolovano, na osnovu izvorne/odredišne IP adrese, porta i protokola, bez ikakvog pamćenja prethodnih paketa u istoj konekciji. Stateful inspection firewall, standard od sredine devedesetih naovamo, dodaje pamćenje — vodi tabelu stanja (state table) aktivnih konekcija, i dozvoljava povratni saobraćaj koji pripada već uspostavljenoj, legitimnoj konekciji, bez potrebe da se za svaki takav paket piše posebno pravilo.

Next-Generation Firewall (NGFW), dominantan standard danas, dodaje sloj koji stateful inspection sam po sebi nema: svesnost o aplikaciji i identitetu korisnika, ne samo o portu i protokolu. Ovo rešava konkretan, ozbiljan problem — stateful firewall koji dozvoljava port 443 (HTTPS) ne može da razlikuje legitiman veb saobraćaj od malvera koji koristi taj isti port za komandnu i kontrolnu (C2) komunikaciju, jer oboje izgledaju identično na nivou porta i protokola. NGFW, kroz Deep Packet Inspection (DPI), gleda dalje od zaglavlja paketa u sam sadržaj, i može doneti odluku na osnovu toga koja aplikacija stvarno generiše taj saobraćaj, bez obzira na to koji port koristi.

Šta treba uraditi

• Razumeti da izbor firewall-a nije pitanje "koji je najbolji" u apstraktnom smislu, već koji nivo vidljivosti je stvarno potreban za konkretno okruženje — jednostavan stateful firewall i dalje ima svoje mesto za osnovnu segmentaciju gde aplikaciona svesnost nije prioritet, dok granica poverljivosti prema internetu gotovo uvek zaslužuje NGFW mogućnosti
• Ne tretirati firewall kao jedinu, dovoljnu meru bezbednosti — isti princip odbrane u dubinu koji se provlači kroz svaku seriju na ovom blogu; firewall je primarna, ali ne i jedina linija odbrane, i mora raditi zajedno sa merama opisanim u prethodnim serijama (endpoint zaštita, audit, segmentacija na nivou samog hosta)
• Postaviti firewall na svaku stvarnu granicu poverljivosti, ne samo na perimetar prema internetu — isti princip mikrosegmentacije (istok-zapad saobraćaj, ne samo sever-jug) koji smo detaljno obradili za Kubernetes NetworkPolicy i Proxmox mrežnu segmentaciju u ranijim serijama, ovde primenjen na nivou fizičke ili virtuelne mrežne infrastrukture

Default deny — princip koji se ponavlja kroz celu ovu seriju

Ovo je isti princip koji se pojavljuje u doslovno svakoj prethodnoj seriji na ovom blogu, ovde u svom najčistijem, izvornom obliku. Implicitno odbijanje (implicit deny) znači da se svaki paket koji ne odgovara nijednom eksplicitnom, dozvoljavajućem pravilu automatski odbacuje — suprotna filozofija, implicitno dozvoljavanje, dozvoljava sve što nije eksplicitno zabranjeno, i predstavlja fundamentalno rizičniji, danas praktično napušten pristup.

Vredi napomenuti praktičnu razliku u ponašanju kod različitih proizvođača, jer je ovo detalj koji zbunjuje administratore koji prelaze sa jedne platforme na drugu: neki sistemi (npr. Cisco ASA) primenjuju implicitno odbijanje automatski, bez vidljivog pravila u konfiguraciji, dok drugi (npr. Palo Alto) prikazuju ga eksplicitno kao vidljivo, auto-generisano pravilo na dnu liste (interzone-default, intrazone-default), a treći (npr. FortiGate) zahtevaju da administrator sam eksplicitno definiše to pravilo umesto da se osloni na skriveno, podrazumevano ponašanje. Ova razlika direktno utiče na to koliko je lako administratoru da vizuelno potvrdi da default-deny zaista postoji u konkretnoj konfiguraciji — detaljnije ćemo ovo obraditi kad u kasnijim delovima serije pređemo na Fortinet i Palo Alto pojedinačno.

Šta treba uraditi

• Potvrditi da je implicitno odbijanje zaista aktivno na svakom firewall-u u infrastrukturi, bez obzira na to da li je vidljivo kao eksplicitno pravilo ili skriveno, ugrađeno ponašanje platforme — ne pretpostaviti da je "podrazumevano" nužno bezbedno bez provere
• Primenjivati default-deny simetrično — i za dolazni (ingress) i za odlazni (egress) saobraćaj — ne samo za saobraćaj koji ulazi u mrežu, po istom principu opisanom kroz seriju o hardeningu Linux i Windows servera; nekontrolisan odlazni saobraćaj je čest, a lako previdiv put kojim kompromitovan sistem komunicira sa napadačem ili izvlači podatke
• Tretirati svaku dozvolu kao eksplicitnu, svesnu odluku sa jasnim poslovnim razlogom, ne kao podrazumevano stanje koje treba naknadno suziti

Zone-based arhitektura — organizovanje po nivou poverljivosti, ne po fizičkoj topologiji

Savremeni firewall uređaji rade sa zonama — imenovanim, logičkim grupacijama interfejsa ili mrežnih segmenata koji dele isti nivo poverljivosti, umesto da se pravila pišu pojedinačno za svaki fizički interfejs. Tipičan, osnovni raspored uključuje najmanje tri zone: nepoverljivu (internet), poverljivu (interna mreža), i demilitarizovanu zonu — DMZ — za sisteme koji moraju biti dostupni iz nepoverljive zone, ali ne treba da imaju direktan pristup najosetljivijim delovima interne mreže.

Pravila se zatim definišu ne po pojedinačnom interfejsu, već po paru zona — šta sme iz zone A da dopre do zone B, i pod kojim uslovima. Ovo uključuje i takozvana intrazone pravila (saobraćaj unutar iste zone) — čest, previdiv detalj, jer podrazumevano ponašanje kod nekih platformi dozvoljava sav saobraćaj unutar iste zone bez ikakvog filtriranja, što poništava svrhu mikrosegmentacije ako se u istu, široku zonu grupišu sistemi različitog stvarnog poverenja.

Šta treba uraditi

• Dizajnirati zone prema stvarnom nivou poverljivosti i poslovnoj funkciji, ne prema fizičkoj topologiji ili istorijskom rasporedu mreže — sistemi koji zahtevaju različit nivo zaštite (npr. IoT uređaji i finansijski serveri) ne treba da dele istu zonu samo zato što su fizički povezani na isti switch
• Postaviti javno dostupne servise (veb aplikacije, mejl serveri) u DMZ, sa strogo ograničenim, eksplicitno definisanim putem komunikacije ka internim, zaštićenijim segmentima — javna aplikacija ne treba direktan pristup internoj bazi podataka bez posredovanja kroz kontrolisan, uzak kanal
• Eksplicitno definisati i intrazone politiku, ne pretpostaviti da je saobraćaj unutar iste zone automatski bezbedan samo zato što deli isti nivo poverenja — čak i unutar jedne zone, mikrosegmentacija (obrađena detaljnije u drugom delu serije) ima svoju vrednost
• Voditi dokumentovanu mapu zona i njihovih međusobnih odnosa, ažuriranu kad god se infrastruktura menja — nedokumentovana zone arhitektura postaje, vremenom, nešto što niko u potpunosti ne razume niti pouzdano održava

Redosled pravila — first match, ne best match

Ovo je tehnički detalj koji zaslužuje eksplicitno objašnjenje, jer njegovo nerazumevanje je čest izvor grešaka u praksi. Firewall pravila se procesiraju odozgo nadole, i primenjuje se prvo pravilo koje odgovara datom paketu — ne najbolje, najspecifičnije pravilo u celoj listi, već prvo koje se poklopi, nakon čega se procesiranje zaustavlja. Ovo znači da široko, permisivno pravilo postavljeno iznad uže, restriktivnijeg pravila potpuno poništava svrhu tog užeg pravila — ono nikad neće biti dosegnuto, jer je saobraćaj već "uhvaćen" ranijim, širim pravilom. Ovaj obrazac se naziva "shadowed rule" (zasenčeno pravilo), i predstavlja jedan od najčešćih uzroka razlike između onoga što administrator misli da je konfigurisao i onoga što firewall zaista radi.

Šta treba uraditi

• Postavljati specifičnija pravila iznad opštijih u listi — pravilo koje precizno navodi izvor, odredište, port i protokol treba da bude iznad šireg pravila koje bi ga inače "presrelo" pre nego što stigne do njega
• Redovno proveravati listu pravila na prisustvo zasenčenih pravila — mnoge platforme nude ugrađen alat za analizu koji automatski identifikuje pravila koja nikad neće biti dosegnuta zbog šireg pravila iznad njih
• Izbegavati "any-any" pravila (dozvoli sve, sa bilo kog izvora ka bilo kom odredištu) osim u retkim, eksplicitno dokumentovanim slučajevima — ovakvo pravilo, čak i postavljeno nisko u listi kao naizgled bezopasan "catch-all", predstavlja rizik ako se slučajno pomeri više ili ako neko naknadno doda usko pravilo ispod njega očekujući da će se primeniti
• Koristiti grupe adresa (address sets/objects) umesto pojedinačnih IP adresa u pravilima gde je to moguće — ovo pojednostavljuje administraciju i smanjuje šansu za grešku kad se infrastruktura menja, jer se izmena vrši na jednom mestu (definiciji grupe) umesto pretraživanja i ažuriranja svakog pravila pojedinačno

Dokumentacija i upravljanje promenama — pravilo bez konteksta je dug koji se plaća kasnije

Isti princip opisan kroz svaku prethodnu seriju za GPO, sudo pravila, RBAC dozvole i backup izuzetke primenjuje se i ovde: firewall pravilo bez jasnog vlasnika, razloga i, gde je primenjivo, datuma isteka, postaje vremenom nešto što niko ne razume dovoljno dobro da bezbedno ukloni — čak i kad se posumnja da više nije potrebno.

Šta treba uraditi

• Za svako pravilo beležiti poslovnu svrhu, vlasnika/traženja stranu, datum kreiranja, i gde je primenjivo, datum planiranog isteka (posebno za privremene, projektno-vezane dozvole)
• Sprovoditi formalan proces upravljanja promenama za svaku izmenu pravila — dokumentovano opravdanje, odobrenje od strane vlasnika zone i bezbednosnog tima, testiranje pre primene u produkciji, i jasna mogućnost povratka na prethodno stanje ako izmena izazove problem
• Sprovoditi periodičnu (kvartalnu ili polugodišnju) reviziju cele liste pravila, uklanjajući ona za koja niko više ne može da potvrdi da su stvarno potrebna — isti princip periodične revizije koji se ponavlja kroz svaku seriju na ovom blogu
• Zabraniti (kroz formalnu politiku, ne samo dobru nameru) obrasce poput "any-any" pravila, širokih izvornih opsega bez opravdanja, i korišćenja nezaštićenih, starijih protokola — sprovesti ovo kroz automatizovanu analizu konfiguracije gde platforma to podržava

Sledeći deo serije ide dublje u konkretan dizajn rulebase-a i mikrosegmentacije — kako praktično strukturirati pravila za realnu infrastrukturu, kako DMZ arhitektura izgleda u praksi sa konkretnim primerom, i kako mikrosegmentacija sprečava lateralno kretanje unutar iste, naizgled "poverljive" mreže.