Firewall Hardening – Deo 6: Palo Alto Networks hardening

Prethodni deo serije pokrio je Fortinet FortiGate. Ovaj, poslednji deo serije prelazi na Palo Alto Networks — platformu koja je u velikoj meri i definisala kategoriju NGFW-a kroz App-ID i User-ID koncepte pomenute u trećem delu serije. Isti obrazac koji smo videli kod Fortinet-a ponavlja se i ovde: stvaran, dokumentovan incident koji ilustruje zašto osnovni hardening management pristupa nije opciona preporuka, već direktan odgovor na aktivno iskorišćavan rizik.

CISA upozorenje — management interfejs izložen internetu kao ponovljen obrazac napada

CISA je izdala hitno upozorenje nakon što je Palo Alto Networks potvrdio aktivno iskorišćavanje neautentifikovane ranjivosti za izvršavanje udaljenih komandi, usmerene specifično na management interfejse PAN-OS uređaja koji su bili izloženi internetu. Vredi primetiti da ovo nije izolovan slučaj specifičan samo za jednog proizvođača — isti obrazac (management interfejs izložen internetu kao primaran vektor kompromitacije) ponovio se kod FortiGate-a u prethodnom delu serije, i predstavlja opšti, industrijski obrazac, ne slučajnost vezanu za jednu platformu.

Poruka koja proizlazi iz oba slučaja je ista, i vredi je eksplicitno ponoviti na kraju cele ove serije: bez obzira na to koliko je NGFW platforma napredna — App-ID, User-ID, threat intelligence, sve mogućnosti obrađene u trećem delu serije — sam management interfejs uređaja ostaje potencijalna, kritična slaba tačka ako nije pažljivo izolovan. Firewall koji odlično štiti saobraćaj koji kroz njega prolazi, a ima nezaštićen sopstveni upravljački pristup, štiti sve osim sebe samog.

Šta treba uraditi

• Potvrditi da management interfejs nije dostupan iz zona okrenutih internetu (untrust zone) — kroz proveru da nijedno pravilo bezbednosne politike ne dozvoljava pristup sa untrust zone ka IP adresi samog management interfejsa
• Ograničiti dozvoljene IP adrese za management pristup (Device → Setup → Management → Management Interface Settings → Permitted IP Addresses) isključivo na radne stanice administratora ili jump server, po istom principu uskog, eksplicitnog dozvoljavanja koji se provlači kroz svaku seriju na ovom blogu
• Smestiti management interfejs na dedikovan management VLAN ili out-of-band (OOB) mrežu, potpuno odvojenu od produkcionog saobraćaja koji uređaj filtrira — isti princip segmentacije upravljačke mreže opisan kroz svaku prethodnu seriju o infrastrukturi
• Pratiti bezbednosne biltene proizvođača (Palo Alto Security Advisories) i CISA upozorenja redovno, i sprovesti preporučenu proceduru odmah po objavi — ista disciplina brzog reagovanja opisana za CISA KEV katalog u Windows Server hardening seriji

Osnovna higijena naloga — isti obrazac ponovljen kroz treću platformu zaredom

Isti principi opisani za pfSense/OPNsense i FortiGate u prethodna dva dela serije primenjuju se identično ovde, sa PAN-OS specifičnom terminologijom: administratorski profili i grupe za ograničavanje pristupa, sprovedena politika lozinki (password profile), i redovna rotacija lozinki na definisan raspored.

Šta treba uraditi

• Promeniti podrazumevanu admin lozinku pre nego što se uređaj poveže na bilo koju mrežu — isti, sada treći put ponovljen princip kroz ovu seriju, jer je podrazumevana lozinka na bilo kojoj platformi jednako predvidiva meta
• Konfigurisati administratorske profile i grupe da ograniče pristup na osnovu stvarne uloge, umesto rutinske dodele punog administratorskog pristupa svima kojima je potrebna bilo kakva administracija
• Sprovesti politiku lozinki (password profile) koja zahteva dovoljnu dužinu i složenost, uz definisan raspored redovne promene za posebno osetljive naloge
• Konfigurisati MFA kroz RADIUS ili SAML integraciju, umesto oslanjanja isključivo na lokalnu, samo-lozinkom zaštićenu autentifikaciju — isti princip phishing-otporne, obavezne MFA koji se ponavlja kroz svaku seriju o kritičnoj infrastrukturi na ovom blogu
• Postaviti kratak idle timeout za administratorsku sesiju (razuman polazni obrazac je oko deset minuta) — ista mera opisana za Veeam konzolu u Backup Infrastructure seriji, ovde primenjena na firewall administraciju
• Uključiti login banner koji jasno naznačava da je pristup ograničen na ovlašćene korisnike — ovo ima i praktičnu, pravnu vrednost u nekim jurisdikcijama u slučaju istrage neovlašćenog pristupa, ne samo simboličku

Security profili — pretvaranje App-ID vidljivosti u stvarnu, aktivnu zaštitu

Ovo je koncept vredan posebnog objašnjenja, jer je čest izvor nesporazuma: samo postojanje App-ID mogućnosti (opisane u trećem delu serije) ne pruža automatski zaštitu — App-ID identifikuje aplikaciju, ali odluku o tome šta se radi sa tom identifikacijom donose posebno pridodati security profili. Bez njih, pravilo koje dozvoljava, recimo, veb saobraćaj i dalje samo dozvoljava taj saobraćaj da prođe, bez ikakve dublje inspekcije sadržaja.

Puna PAN-OS zaštita zahteva pet komplementarnih profila prikačenih na svako dozvoljavajuće pravilo: Antivirus (skenira poznat malver u prenosu), Anti-Spyware (detektuje command-and-control komunikaciju i spyware obrasce), Vulnerability Protection (blokira poznate obrasce iskorišćavanja ranjivosti), URL Filtering (kontroliše pristup na osnovu kategorije veb sadržaja), i WildFire (prosleđuje nepoznate, sumnjive fajlove u cloud sandbox radi analize ponašanja pre nego što se odluka o njihovoj bezbednosti donese).

Šta treba uraditi

• Prikačiti sve pet security profila (Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, WildFire) na svako dozvoljavajuće pravilo u politici, ne samo na uzak podskup pravila — dozvoljavajuće pravilo bez pridodatih profila propušta saobraćaj sa App-ID vidljivošću, ali bez stvarne dubinske inspekcije sadržaja
• Konfigurisati Vulnerability Protection profil da blokira sve ranjivosti ocenjene kao nisko ozbiljne i više, ne samo kritične — niže ocenjena ranjivost i dalje predstavlja stvaran, iskoristiv rizik
• Postaviti URL Filtering profil da podrazumevano blokira poznato rizične kategorije (malver, phishing, poznati C2 domeni), i eksplicitno odlučiti o graničnim kategorijama na osnovu stvarne poslovne politike organizacije
• Uključiti WildFire sa učestalim rasporedom ažuriranja (do jednom u minuti gde je to podržano) i prosleđivanjem svih tipova fajlova na analizu, ne samo uskog podskupa — nepoznat fajl koji nije prosleđen na analizu ostaje nepoznat rizik

Napomena o riziku: puna dubinska inspekcija (svih pet profila na svakom pravilu) nosi realan trošak po performanse uređaja, posebno u kombinaciji sa SSL dekripcijom opisanom u trećem delu serije. Planirati kapacitet uređaja imajući u vidu ovaj kumulativan trošak, i meriti stvarnu propusnost pod punim opterećenjem sa svim profilima uključenim, ne osloniti se isključivo na teorijske specifikacije proizvođača testirane pod idealizovanim uslovima.

Zone Protection — odbrana od poplave i izviđanja na nivou same zone

Ovo je dodatan, komplementaran mehanizam koji radi na drugom nivou od security profila opisanih ranije — Zone Protection profili se primenjuju na ulaznom (ingress) interfejsu zone i štite od mrežnih i transportnih napada poput poplave paketa (flood) i pokušaja izviđanja mreže (port skeniranje, mapiranje topologije), pre nego što saobraćaj uopšte stigne do faze u kojoj bi App-ID i security profili delovali.

Šta treba uraditi

• Primeniti Zone Protection profil na zonu koja sadrži interfejs okrenut internetu kao apsolutni minimum, i razmotriti proširenje na interne zone za dodatnu, dublju zaštitu
• Utvrditi realne pragove (thresholds) za detekciju poplave na osnovu stvarnog, izmerenog obrasca mrežne aktivnosti tokom perioda najvišeg opterećenja — generički, podrazumevani prag koji ne odgovara stvarnom saobraćaju konkretne organizacije može ili propustiti stvaran napad, ili generisati prekomeran broj lažnih alarma
• Prosleđivati threat logove generisane pri prekoračenju praga ka spoljnom syslog sistemu ili SIEM-u, po istom principu centralizovanog logovanja koji se ponavlja kroz celu ovu seriju

Migracija sa port-baziranih na App-ID bazirana pravila

Vredi na kraju pomenuti praktičan izazov sa kojim se organizacije koje prelaze na Palo Alto sa starije, port-bazirane platforme suočavaju: postojeći rulebase, izgrađen godinama oko portova i protokola, ne iskorišćava App-ID mogućnost sve dok se svesno ne migrira. Palo Alto nudi ugrađene alate i strukturirane radne tokove upravo za ovu migraciju — postepenu zamenu starijih, port-baziranih pravila App-ID baziranim ekvivalentima, uz korišćenje podataka koje sam PAN-OS prikuplja o stvarnoj aplikaciji iza svakog postojećeg pravila.

Šta treba uraditi

• Sprovesti migraciju sa port-baziranih na App-ID bazirana pravila postepeno, koristeći ugrađene alate za analizu koji pokazuju koja stvarna aplikacija generiše saobraćaj obuhvaćen svakim postojećim, starijim pravilom
• Zadržati privremeno i staro i novo pravilo paralelno tokom prelaznog perioda (staro pravilo kao sigurnosna mreža), uklanjajući stara pravila tek nakon što se potvrdi da novo, App-ID bazirano pravilo ispravno pokriva sav legitiman saobraćaj
• Tretovati ovu migraciju kao dugoročan, postepen projekat, ne kao jednokratnu izmenu — isti princip fazne primene koji se ponavlja kroz svaku operativno osetljivu promenu opisanu kroz celu ovu seriju blogova

Ovim se zaokružuje cela serija o hardeningu firewall infrastrukture — od osnovnih pojmova i arhitekture, preko dizajna pravila i mikrosegmentacije, naprednih NGFW mogućnosti, do tri konkretne, najrasprostranjenije platforme: pfSense/OPNsense, Fortinet i Palo Alto. Isti obrazac koji povezuje ovu seriju sa svakom prethodnom serijom na ovom blogu ostaje nepromenjen do samog kraja: default-deny kao polazna tačka, least privilege u dizajnu pravila, fazno uvođenje svake operativno osetljive promene, i, možda najvažnija pouka iz oba stvarna primera opisana u poslednja dva dela — da najnaprednija platforma na svetu ne pomaže ako je sopstveni upravljački pristup ostavljen otvoren.