Firewall Hardening – Deo 3: NGFW mogućnosti – IPS/IDS, SSL/TLS inspekcija i application-aware filtriranje

Prva dva dela serije pokrila su osnove i segmentaciju — funkcije koje ima svaki ozbiljan firewall, star ili nov. Treći deo se bavi onim što razdvaja Next-Generation Firewall od klasičnog stateful uređaja: IPS/IDS mogućnošću, SSL/TLS inspekcijom, i application-aware filtriranjem. Ove tri mogućnosti rade zajedno, ali rešavaju različite probleme, i vredi ih razumeti pojedinačno pre nego što se uključe sve odjednom na produkcionom uređaju.

IDS i IPS — ista tehnologija detekcije, različita posledica

Vredi razjasniti razliku na samom početku, jer se termini često koriste nepromišljeno naizmenično. Intrusion Detection System (IDS) analizira saobraćaj i generiše alarm kad prepozna sumnjiv obrazac — pasivan je, saobraćaj nastavlja da prolazi bez obzira na alarm. Intrusion Prevention System (IPS) koristi istu tehnologiju detekcije, ali aktivno blokira saobraćaj za koji proceni da je zlonameran — aktivan je, i greška (lažno pozitivan rezultat) ima stvarnu, neposrednu posledicu: legitiman saobraćaj biva odbačen, ne samo označen za pregled.

Detekcija se oslanja na dva komplementarna pristupa. Signature-bazirana detekcija upoređuje saobraćaj sa bazom poznatih, katalogizovanih obrazaca napada — precizna i pouzdana za poznate pretnje, sa niskim brojem lažno pozitivnih rezultata, ali suštinski slepa za nove, još nekatalogizovane napade (zero-day). Anomaly-bazirana detekcija gradi statističku osnovu (baseline) normalnog ponašanja mreže tokom perioda učenja, i alarmira kad se trenutno ponašanje značajno udalji od te osnove — sposobna da otkrije potpuno nove obrasce napada, ali podložnija lažno pozitivnim rezultatima u dinamičnim okruženjima gde se legitimno ponašanje menja (nova aplikacija, promena obrasca korišćenja).

Šta treba uraditi

• Koristiti obe metode zajedno — signature-baziranu detekciju za pouzdanu, brzu identifikaciju poznatih pretnji, i anomaly-baziranu kao dopunski sloj za obrasce koje signature baza još ne pokriva, po istom principu odbrane u dubinu koji se provlači kroz svaku seriju na ovom blogu
• Za anomaly detekciju, definisati period učenja (tipično 7 do 30 dana) tokom kojeg se gradi baseline normalnog ponašanja, i podesiti pragove (thresholds) posebno za svaki mrežni segment — server u data centru toleriše znatno viši broj konekcija u sekundi od radne stanice u kancelariji, i primena istog praga na oba nije realna
• Redovno ažurirati signature bazu — proizvođači poput Fortinet-a (FortiGuard) i Palo Alto (kroz Unit 42 istraživanje) objavljuju ažuriranja kontinuirano, uključujući hitne signature za aktivno iskorišćavane, tek otkrivene ranjivosti
• Testirati nove signature na manje kritičnom segmentu ili u pasivnom (log-only) modu pre šire primene u blokirajućem modu — signature koja izgleda ispravno u laboratoriji proizvođača može generisati neočekivane lažno pozitivne rezultate u specifičnom okruženju konkretne organizacije

Fazno uvođenje — isti audit-pre-enforce princip, ovde primenjen na IPS

Isti obrazac koji smo detaljno objasnili za mikrosegmentaciju u drugom delu serije (i, pre toga, za SELinux/AppArmor, Docker seccomp, i Kubernetes Pod Security Standards kroz ranije serije) primenjuje se identično na uvođenje IPS-a: prelazak direktno u blokirajući mod, bez prethodnog perioda posmatranja, gotovo garantovano prekida deo legitimnog saobraćaja pre nego što se otkrije i ispravi obrazac koji izaziva lažne pozitivne rezultate.

Šta treba uraditi

• Uvoditi IPS prvo u detekcionom (log-only) modu, na kopiji stvarnog produkcionog saobraćaja gde je to izvodljivo, kako bi se videlo šta bi bilo blokirano pre nego što se stvarno blokira
• Podešavati pragove i pravila po segmentu, ne primenjivati jedinstven, generički profil na celu infrastrukturu — isti princip diferencirane primene opisan za anomaly pragove ranije u tekstu
• Prelaziti na blokirajući mod postepeno, počev od pravila najviše pouzdanosti (signature za poznate, ozbiljne, dobro potvrđene pretnje), a tek zatim šireći na pravila niže pouzdanosti kako se poverenje u tačnost detekcije u konkretnom okruženju povećava
• Pregledati alarme visoke pouzdanosti i lažno pozitivne rezultate nedeljno tokom prvog meseca nakon svake veće izmene (nova verzija, nov segment, nova signature baza) — trošak podešavanja (tuning) je stalan, ne jednokratan zadatak koji se "završi" i zaboravi

Napomena o riziku: IPS u blokirajućem modu koji nije adekvatno podešen za konkretno okruženje nosi realan operativni rizik — legitimna aplikacija čiji obrazac saobraćaja liči na napad (npr. legitiman alat za masovno testiranje koji generiše veliki broj brzih konekcija) može biti neočekivano blokirana, izazivajući nedostupnost servisa koja izgleda kao mrežni problem, ne kao bezbednosna mera koja radi tačno ono što je podešena da radi. Ovo je posebno bitno imati na umu pre uvođenja IPS-a na kritičnim, produkcionim segmentima bez prethodnog, dovoljno dugog perioda posmatranja.

SSL/TLS inspekcija — zašto je neophodna, i tehnički zašto je komplikovana

Preko 90 procenata veb saobraćaja danas je enkriptovano, što znači da firewall bez mogućnosti da pogleda unutar enkriptovanog tunela postaje, za taj ogroman deo saobraćaja, jednostavan prosleđivač paketa — ne može da otkrije malver, phishing sadržaj, ili command-and-control komunikaciju koja putuje unutar naizgled legitimne HTTPS sesije. SSL/TLS inspekcija rešava ovaj problem, ali mehanizam kojim to radi vredi tehnički objasniti, jer direktno objašnjava i njena ograničenja.

Firewall koji vrši SSL inspekciju deluje kao posrednik (man-in-the-middle) na kontrolisan, namerno uveden način: kad klijent unutar mreže pokuša da uspostavi HTTPS konekciju ka spoljnom serveru, firewall presreće tu konekciju, sam uspostavlja pravu HTTPS vezu sa stvarnim odredišnim serverom, i istovremeno klijentu prezentuje sopstveni, na licu mesta generisan sertifikat (potpisan internim, organizacionim CA sertifikatom koji mora unapred biti instaliran kao poverljiv na svakom klijentskom uređaju). Firewall tako vidi nešifrovan sadržaj obe strane konekcije, pregleda ga, i zatim ga ponovo enkriptuje pre prosleđivanja dalje.

Šta treba uraditi

• Distribuirati interni CA sertifikat firewall-a na sve upravljane klijentske uređaje pre uključivanja inspekcije — bez ovog koraka, svaki korisnik će videti upozorenje o nepoverljivom sertifikatu na svakom HTTPS sajtu, što brzo vodi ili u masovne žalbe, ili u korisnike koji nauče da ignorišu bezbednosna upozorenja generalno, što je gori dugoročni ishod
• Odlučiti selektivno šta se inspektuje, ne pokušavati inspektovati apsolutno sav saobraćaj — kombinovati inspekciju visoko-rizičnih kategorija (nepoznati/novoregistrovani sajtovi, sumnjive kategorije) sa izuzimanjem osetljivih, regulisanih kategorija
• Postaviti pravila izuzimanja (bypass) na sam vrh liste pravila za inspekciju, pre bilo kog opšteg pravila koje bi inače presrelo taj saobraćaj — bankarski i finansijski sajtovi, zdravstveni portali, i pravni/vladini sistemi gde regulatorni zahtevi to nalažu treba da budu izuzeti iz inspekcije, tehnički i pravno, ne samo administrativno
• Voditi ažurnu listu poznatih aplikacija sa certificate pinning-om (detaljnije objašnjeno dalje u tekstu) i izuzeti ih iz inspekcije, umesto da se korisnici suočavaju sa neobjašnjivim, nejasnim greškama povezivanja

Certificate pinning — tehnička prepreka koju MITM inspekcija ne može zaobići

Ovo zaslužuje detaljno objašnjenje, jer je čest, konkretan izvor problema u praksi nakon uključivanja SSL inspekcije. Neke aplikacije — tipično mobilno bankarstvo, korporativni VPN klijenti, i pojedini SaaS klijenti — ugrađuju u sam kod aplikacije očekivani otisak (fingerprint) sertifikata servera sa kojim komuniciraju. Kad firewall pokuša da izvrši svoju standardnu MITM proceduru i prezentuje aplikaciji sopstveni, ponovo potpisan sertifikat, aplikacija upoređuje taj sertifikat sa ugrađenim otiskom, otkriva neslaganje, i prekida konekciju — bez obzira na to što je firewall-ov sertifikat inače validan i potpisan poverljivim, internim CA.

Ovo nije propust u konfiguraciji firewall-a koji se može "popraviti" — to je namerna bezbednosna mera same aplikacije, dizajnirana upravo da spreči MITM presretanje čak i od strane naizgled poverljivih posrednika. Jedini praktičan odgovor je izuzimanje takvih aplikacija iz inspekcije, ne pokušaj da se pinning zaobiđe.

Šta treba uraditi

• Identifikovati aplikacije sa certificate pinning-om u organizaciji unapred, pre uključivanja SSL inspekcije na širem obimu — mnogi proizvođači (uključujući Palo Alto i slične platforme) održavaju kuriranu listu poznatih aplikacija koje koriste pinning, korisnu kao polaznu tačku
• Konfigurisati izuzeće na osnovu hostname-a (upoređenog sa SNI poljem u TLS handshake-u) za takve aplikacije, umesto pokušaja globalnog rešenja koje ne postoji
• Kad korisnici prijave da aplikacija "ne radi" nakon uključivanja SSL inspekcije, prvo proveriti da li je uzrok certificate pinning (vidljivo kroz TLS fatal alert u mrežnom snimku saobraćaja) pre nego što se pretpostavi neki drugi, složeniji uzrok

TLS 1.3 — tehnički razlog zašto je inspekcija danas zahtevnija nego ranije

Vredi objasniti i konkretan tehnički razlog zašto SSL inspekcija u 2026. godini nosi veći trošak performansi nego ranije. Stariji TLS handshake mehanizmi omogućavali su, pod određenim uslovima, pasivno dekriptovanje saobraćaja izvozom privatnog RSA ključa servera — bez potrebe da firewall aktivno učestvuje u samom handshake-u. TLS 1.3 je ovaj put u potpunosti zatvorio: koristi isključivo efemerne (privremene, po-sesiji generisane) Diffie-Hellman ključeve, čime je pasivno dekriptovanje postalo tehnički nemoguće. Dodatno, TLS 1.3 enkriptuje veći deo samog handshake procesa (uključujući sertifikat servera), što dodatno onemogućava bilo kakvu pasivnu analizu.

Praktična posledica: firewall koji želi da inspektuje TLS 1.3 saobraćaj mora aktivno da učestvuje u handshake-u kao pravi posrednik (aktivna MITM procedura opisana ranije), ne da pasivno prisluškuje već uspostavljenu konekciju — što nosi veći, neizbežan trošak po latenciju i procesorske resurse u odnosu na stariji, pasivniji pristup.

Šta treba uraditi

• Planirati kapacitet firewall uređaja imajući u vidu da SSL inspekcija na TLS 1.3 saobraćaju zahteva realno veći procesorski resurs nego što su starije procene performansi (bazirane na starijim verzijama protokola) sugerisale
• Za uređaje sa hardverskom akceleracijom inspekcije (npr. Fortinet-ovi namenski ASIC procesori ili Palo Alto-ov prilagođen čip dizajn, koje ćemo detaljnije obraditi u kasnijim delovima serije posvećenim konkretnim platformama), proveriti da je akceleracija stvarno aktivna i pravilno iskorišćena za TLS 1.3 saobraćaj, ne samo za starije protokole
• Meriti stvarnu latenciju i propusnost pod punim opterećenjem sa uključenom inspekcijom, ne osloniti se isključivo na teorijske specifikacije proizvođača — stvaran mix saobraćaja u konkretnoj organizaciji retko odgovara idealizovanim uslovima testiranja proizvođača

Application-aware filtriranje — treći sloj koji zatvara krug

Ovo je mogućnost koja direktno rešava problem opisan u prvom delu serije — razlikovanje legitimnog HTTPS saobraćaja od malvera koji koristi isti port 443. Application-aware filtriranje (App-ID kod Palo Alto, Application Control kod Fortinet-a i drugih proizvođača) identifikuje stvarnu aplikaciju koja generiše saobraćaj na osnovu obrazaca u samom sadržaju (dostupnom nakon SSL dekripcije opisane ranije, gde je primenjena) i ponašanja protokola, nezavisno od porta koji koristi.

Šta treba uraditi

• Definisati politiku na osnovu identifikovane aplikacije, ne samo porta — dozvoliti, na primer, korišćenje odobrenih cloud storage aplikacija dok se blokiraju neodobrene, čak i kad sve koriste isti, standardni HTTPS port
• Kombinovati application-aware filtriranje sa identifikacijom korisnika (user-ID mogućnost dostupna na većini NGFW platformi, integrisana sa AD-om opisanim kroz raniju seriju na ovom blogu) za politiku baziranu na tome ko je korisnik, ne samo koja je aplikacija ili IP adresa u pitanju — pravilo "ovaj tim sme da koristi ovu aplikaciju" postaje izvodljivo na način koji čista IP-bazirana pravila ne dozvoljavaju
• Redovno pregledati kategorizaciju nepoznatih ili novoregistrovanih aplikacija koje se pojave u mrežnom saobraćaju — nova, još nekategorizovana aplikacija zaslužuje svesnu odluku (dozvoliti, blokirati, ili istražiti dalje), ne automatsko propuštanje po difoltu

Ovim se zaokružuje pregled naprednih NGFW mogućnosti koje razdvajaju savremeni firewall od klasičnog stateful uređaja. Sledeći delovi serije prelaze na konkretne platforme — pfSense/OPNsense, Fortinet FortiGate, i Palo Alto — i pokazuju kako se principi opisani kroz prva tri dela ove serije primenjuju u praksi na svakoj od njih, sa specifičnostima, terminologijom i podešavanjima jedinstvenim za svaku platformu.