Firewall Hardening – Deo 4: pfSense/OPNsense hardening

Prethodna tri dela serije pokrila su principe nezavisne od proizvođača — osnove, segmentaciju, napredne NGFW mogućnosti. Ovaj deo prelazi na prvu konkretnu platformu: pfSense i OPNsense, dva najrasprostranjenija besplatna, open-source firewall rešenja, oba izgrađena na FreeBSD osnovi (OPNsense konkretno na HardenedBSD ogranku). Principi opisani ranije u seriji ovde dobijaju tačna imena podešavanja i mesta u web interfejsu — a i pfSense i OPNsense dele dovoljno zajedničke arhitekture da veći deo ovog teksta važi podjednako za oba, uz eksplicitnu napomenu gde se razlikuju.

Sveža instalacija nije podešena za produkciju — isti obrazac koji smo videli kroz celu ovu seriju blogova

Fresh pfSense/OPNsense instalacija dolazi sa dobro poznatom, podrazumevanom lozinkom (pfsense za pfSense), i automatizovani botovi skeniraju internet za izložene instance sa tom podrazumevanom lozinkom u roku od minuta od izlaganja bilo kog IP-a. Kompromitovan firewall nije samo jedan kompromitovan uređaj — to je potpuna kontrola nad svim saobraćajem koji kroz njega prolazi, sa mogućnošću da napadač isključi logovanje, otvori tunel ka unutrašnjosti mreže, ili jednostavno preusmeri saobraćaj po volji.

Šta treba uraditi

• Promeniti podrazumevanu admin lozinku odmah, pre bilo kog drugog koraka, na dugu (16+ karaktera), nasumično generisanu lozinku čuvanu u password manageru — ne u pretraživaču, po istom principu opisanom kroz svaku prethodnu seriju o čuvanju kritičnih kredencijala
• Zameniti podrazumevani, samopotpisani (self-signed) sertifikat za web interfejs sertifikatom izdatim od interne CA, kako korisnici koji redovno pristupaju interfejsu ne bi navikli da ignorišu upozorenja o sertifikatu — isti rizik "korisnici koji nauče da ignorišu bezbednosna upozorenja" opisan za SSL inspekciju u trećem delu serije
• Zahtevati isključivo HTTPS pristup web interfejsu, uz onemogućen automatski redirekt sa HTTP na HTTPS — sam redirekt mehanizam zahteva da HTTP port bude bar kratko dostupan da bi izvršio preusmeravanje, što je nepotrebna, izbegava izloženost
• Razmotriti promenu podrazumevanog porta za web interfejs na nestandardni — isti princip smanjenja "pozadinske buke" automatizovanog skeniranja opisan kroz Linux Server hardening seriju, ne stvarna zaštita protiv ciljanog napada, ali koristan dodatni sloj

Anti-lockout pravilo — mehanizam vredan posebnog razumevanja

Ovo je koncept specifičan za pfSense/OPNsense arhitekturu koji zaslužuje detaljno objašnjenje, jer njegovo pogrešno razumevanje je čest uzrok potpunog gubitka pristupa firewall-u. Prilikom instalacije, sistem automatski kreira skriveno, uvek-aktivno pravilo na LAN interfejsu koje garantuje administrativan pristup (HTTPS i SSH ka IP adresi samog interfejsa) bez obzira na to šta ostatak rulebase-a kaže — ovo postoji upravo da administrator ne bi mogao slučajno, kroz grešku u sopstvenim pravilima, da sam sebe zaključa van uređaja.

Problem nastaje kad administrator, iz razloga stroge kontrole (npr. želi da ograniči čak i LAN pristup na uže, specifičnije uslove nego što anti-lockout pravilo dozvoljava), svesno isključi ovo automatsko pravilo. Ako se to uradi bez prethodnog kreiranja eksplicitne, ekvivalentne zamene, i ako sledeća izmena pravila slučajno blokira sopstveni administrativni pristup, jedini preostali put je fizička konzola uređaja — ili, u gorem slučaju, potpuni reset na fabrička podešavanja.

Šta treba uraditi

• Zadržati ugrađeno anti-lockout pravilo aktivno u većini scenarija — ono je dizajnirano upravo da spreči najčešći, najbolniji tip greške u administraciji firewall-a
• Ako se anti-lockout pravilo svesno isključi radi strože kontrole, prvo kreirati eksplicitno, ekvivalentno pravilo koje dozvoljava administrativan pristup sa poznate, poverljive izvorne adrese, i postaviti ga na sam vrh liste pravila (po principu redosleda pravila opisanom u prvom delu serije) — nikad isključivati ugrađenu zaštitu bez unapred pripremljene zamene
• Testirati svaku izmenu pravila koja utiče na LAN interfejs iz odvojene sesije pre zatvaranja postojeće, po istom principu predostrožnosti koji se ponavlja kroz svaku seriju na ovom blogu

Napomena o riziku: pfSense/OPNsense nude vremenski ograničenu primenu izmena pravila kod nekih operacija (izmena se automatski poništi ako administrator ne potvrdi da i dalje ima pristup u određenom roku) — koristiti ovu mogućnost gde je dostupna za posebno rizične izmene pravila koje utiču na administrativni pristup, kao dodatnu, automatizovanu mrežu sigurnosti iznad same predostrožnosti testiranja iz odvojene sesije.

SSH i udaljen pristup — isti princip iz Linux Server serije, primenjen ovde

Isti principi opisani za SSH u ranijoj seriji o hardeningu Linux servera primenjuju se direktno, budući da su i pfSense i OPNsense izgrađeni na FreeBSD osnovi. Vredi, međutim, istaći jednu, možda i najvažniju preporuku specifično za kontekst firewall uređaja: SSH pristup ka samom firewall-u ne treba nikad da bude dostupan sa WAN interfejsa — ne kroz port forward, ne kroz NAT pravilo, ni u kom obliku.

Šta treba uraditi

• Onemogućiti SSH pristup u potpunosti ako se ne koristi redovno — isti princip minimizacije površine napada opisan kroz seriju o hardeningu Linux servera; ako se koristi, uključiti ga isključivo na internom interfejsu
• Zahtevati autentifikaciju SSH ključem, ne lozinkom, za slučajeve gde SSH ostaje aktivan
• Nikad ne izlagati SSH port na WAN interfejsu — za udaljenu administraciju, koristiti VPN (WireGuard, koji pfSense i OPNsense oba nativno podržavaju) kako bi se administratorov uređaj efektivno tretirao kao da je fizički na internoj mreži, nikad direktnim izlaganjem porta ka internetu
• Za root/superuser nalog na OPNsense-u specifično, imati na umu da je podrazumevani login nalog root — kreirati odvojen, imenovan administrativni nalog za rutinsku upotrebu, po istom principu opisanom za root nalog kroz seriju o hardeningu Linux servera i Proxmox hardening seriju

Autentifikacija za web interfejs — MFA kao standard, ne izuzetak

Isti princip phishing-otporne, obavezne MFA opisan kroz svaku prethodnu seriju o kritičnoj infrastrukturi na ovom blogu (AD, VMware, Proxmox, Veeam) primenjuje se identično ovde. Vredi naglasiti razlog specifičan za firewall kontekst — istraživanja dosledno pokazuju da kompromitacija firewall uređaja najčešće dolazi kroz ukradene ili slabe kredencijale, ne kroz softverske ranjivosti same platforme; deljeni administratorski nalozi bez MFA i bez razdvajanja uloga značajno povećavaju verovatnoću uspešnog upada.

Šta treba uraditi

• Uključiti dvofaktorsku autentifikaciju (TOTP, kroz FreeRADIUS paket sa TOTP modulom na pfSense-u, ili ugrađenu podršku na OPNsense-u) za pristup web interfejsu i za VPN pristup
• Integrisati sa centralizovanim autentifikacionim sistemom (LDAP/RADIUS, povezano sa AD-om opisanim kroz raniju seriju na ovom blogu) gde okruženje to podržava, umesto oslanjanja isključivo na lokalne naloge
• Kreirati odvojene, imenovane administratorske naloge za svaku osobu koja upravlja firewall-om, umesto deljenja jednog admin naloga — isti princip individualne odgovornosti i mogućnosti audita opisan kroz svaku seriju na ovom blogu
• Uključiti login protection (ugrađenu zaštitu od brute-force pokušaja, sa razumnim podrazumevanim pragom neuspešnih pokušaja i periodom blokade) kao dodatan sloj iznad same MFA

Rulebase — praktičan raspored primenjen na konkretnu platformu

Isti principi redosleda i strukture pravila opisani u prvom delu serije primenjuju se ovde kroz konkretnu, preporučenu strukturu: eksplicitni blokovi poznatih pretnji (bogon mreže — neispravno dodeljeni ili nedodeljeni IP opsezi, GeoIP liste, poznate zlonamerne adrese) na vrhu, zatim specifična, dozvoljavajuća pravila za legitiman saobraćaj, sa implicitnim odbijanjem na dnu kao krajnjom, podrazumevanom merom.

Šta treba uraditi

• Koristiti URL Table alias tip za liste poznatih pretnji (bogon, GeoIP, malware liste) umesto ručno unetih, statičkih adresa — ovaj tip aliasa se automatski ažurira iz spoljnog izvora, čime lista ostaje ažurna bez ručnog održavanja
• Definisati svako pravilo maksimalno specifično — protokol, odredišni port, izvorna i odredišna adresa — po istom principu preciznosti opisanom u prvom delu serije, izbegavajući široka pravila koja "hvataju" više nego što je stvarno nameravano
• Za organizacije čiji legitiman saobraćaj dolazi isključivo iz određenih zemalja/regiona, razmotriti geografsko blokiranje (kroz pfBlockerNG paket na pfSense-u ili ekvivalentnu OPNsense funkcionalnost) kao dodatan filter — imajući u vidu da ovo nije zaštita protiv ciljanog napadača koji koristi VPN ili proxy da zaobiđe geografsko ograničenje, već koristan filter protiv neselektivnog, masovnog skeniranja

Backup konfiguracije — automatizovan, enkriptovan, testiran

Isti princip discipline backup-a detaljno obrađen kroz celu posvećenu seriju o backup infrastrukturi na ovom blogu primenjuje se i ovde, sa specifičnom, ugrađenom implementacijom: AutoConfigBackup automatski enkriptuje i prenosi svaku izmenu konfiguracije na sigurnu, spoljnu lokaciju, omogućavajući brzu restauraciju na novom uređaju u slučaju otkaza hardvera.

Šta treba uraditi

• Uključiti automatizovan backup konfiguracije (AutoConfigBackup gde je dostupan, ili ekvivalentan, redovno zakazan izvoz konfiguracije za manuelno čuvanje) umesto oslanjanja na to da će se neko setiti da ručno izveze konfiguraciju pre veće izmene
• Potvrditi da je enkripcija backup-a uključena, po istom principu opisanom kroz celu backup seriju na ovom blogu — konfiguracioni backup sadrži osetljive podatke (lozinke, VPN ključeve, IP raspored cele mreže)
• Testirati stvarnu restauraciju iz backup-a periodično, ne pretpostaviti da backup radi samo zato što se redovno izvršava — isti princip verifikacije koji se ponavlja kroz svaku seriju o backup-u na ovom blogu

Sledeći deo serije prelazi na Fortinet FortiGate — komercijalnu NGFW platformu sa sopstvenom terminologijom (FortiGuard, Security Fabric, ASIC akceleracija) i specifičnim hardening koracima koji se razlikuju od otvorene, open-source arhitekture pfSense/OPNsense obrađene u ovom delu.