Hardening di pfSense: la configurazione che metto in produzione

pfSense appena installato fa il suo lavoro di base: instrada il traffico e blocca le connessioni in ingresso non richieste. Ma "non insicuro per default" non significa "configurato bene". Tra l'installazione e un perimetro che regge davvero c'è un lavoro di hardening preciso. Questa è la configurazione che metto in produzione su un firewall di una PMI, spiegata passo per passo.

Segmentazione: tre interfacce, non una

Una rete piatta dietro pfSense vanifica metà del firewall. La configurazione minima sensata prevede tre zone:

• WAN - il collegamento verso internet.
• LAN - le postazioni di lavoro e i sistemi interni.
• DMZ - i servizi esposti verso l'esterno (un reverse proxy, un server di posta, un'applicazione web), su una VLAN dedicata.

La DMZ si crea come interfaccia OPT su una VLAN separata (Interfaces > VLANs, poi Interfaces > Assignments). Il principio è semplice: se un servizio esposto viene compromesso, l'attaccante si trova in DMZ, non in mezzo alle postazioni. La regola che lo rende vero la scriviamo subito dopo.

Regole firewall: deny by default, e commentale

pfSense blocca già tutto il traffico WAN in ingresso non sollecitato. Il punto debole è quasi sempre la LAN: la regola Default allow LAN to any lascia uscire tutto. Va sostituita con regole esplicite.

Un set di partenza ragionevole per la LAN:

Azione	Sorgente	Destinazione	Porta	Note
Pass	LAN net	LAN address	443	Accesso alla GUI
Block	LAN net	DMZ net	*	LAN non entra in DMZ
Pass	LAN net	any	80, 443, 53	Web e DNS in uscita
Pass	LAN net	any	123	NTP
Block	LAN net	any	*	Log: tutto il resto

E la regola che dà senso alla DMZ:

Azione	Sorgente	Destinazione	Porta	Note
Block	DMZ net	LAN net	*	La DMZ non raggiunge mai la LAN
Pass	DMZ net	any	80, 443, 53	Solo uscita controllata

Due abitudini che fanno la differenza in audit: commenta ogni regola (il campo Description non è opzionale, è documentazione) e tieni un'ultima regola Block esplicita con il logging attivo, così vedi cosa stai bloccando.

Blindare l'accesso amministrativo

È l'errore più grave e il più comune: l'interfaccia di gestione raggiungibile da internet. Da System > Advanced > Admin Access:

• Protocol: HTTPS, mai HTTP.
• Cambia la porta della GUI da 443 a una non standard: non è sicurezza, ma riduce il rumore degli scanner.
• WebGUI redirect e anti-lockout: lascia la regola anti-lockout solo sulla LAN.
• Spunta Disable webConfigurator login autocomplete.
• Imposta un timeout di sessione breve (Session timeout, 30 minuti).

La regola d'oro: nessuna regola firewall che permetta WAN verso la porta della GUI o verso SSH. L'amministrazione avviene dalla LAN o, da remoto, solo dopo essersi connessi in VPN. Se ti trovi a dover aprire la GUI verso la WAN, la risposta giusta è una VPN, non una regola.

L'SSH (System > Advanced > Secure Shell) va abilitato solo se serve, con autenticazione a chiave e password disabilitate.

Accesso remoto: VPN con doppio fattore

Per amministrare da fuori si usa una VPN, e la VPN deve imporre più di una semplice password. Con OpenVPN la combinazione minima è certificato client + credenziali utente: chi non ha il certificato installato non arriva nemmeno alla richiesta di login.

Per un vero secondo fattore TOTP si aggiunge il pacchetto FreeRADIUS: si crea l'utente, si abilita il supporto OTP e si genera il QR code per l'app di autenticazione. OpenVPN viene poi puntato al server RADIUS locale. Il risultato: per entrare servono il certificato, la password e il codice a tempo. Una credenziale rubata, da sola, non basta.

WireGuard è un'alternativa più leggera e veloce; l'autenticazione lì si basa sulle chiavi, quindi la gestione delle chiavi e la loro revoca diventano la disciplina da curare.

Da firewall passivo a difesa attiva: Suricata

Un firewall che applica solo regole statiche non vede un attacco applicativo che passa su una porta legittima. Per questo si installa Suricata (System > Package Manager).

Configurazione che uso:

1. Interfacce: Suricata sulla WAN e sulla DMZ. Sulla WAN intercetta i tentativi dall'esterno, sulla DMZ sorveglia ciò che esce da un servizio potenzialmente compromesso.
2. Ruleset: abilita le ET Open (Emerging Threats), gratuite. Pianifica l'aggiornamento automatico delle firme una volta al giorno.
3. Modalità: parti in sola rilevazione (legacy mode, solo alert) per una o due settimane. Solo dopo aver ripulito i falsi positivi passa alla modalità IPS / blocking. Mettere in blocco un IPS non calibrato significa tagliarsi i piedi da soli.
4. Suppress list: ogni falso positivo confermato va nella lista di soppressione, con un commento sul perché. La lista è viva e cresce con la conoscenza della rete.

L'ordine conta: prima osservi, poi blocchi.

Filtraggio GeoIP e reputazione: pfBlockerNG

Il pacchetto pfBlockerNG aggiunge due livelli utili:

• GeoIP: se la tua azienda non ha clienti o fornitori in certe aree geografiche, bloccare in ingresso il traffico da quei paesi elimina una quota enorme di scansioni e tentativi di accesso. Richiede una chiave di licenza MaxMind gratuita (account GeoLite2).
• IP reputation e DNSBL: liste di IP malevoli noti e blocco a livello DNS dei domini di malvertising e tracking.

Una raccomandazione pratica: il GeoIP si applica in ingresso, sulle regole WAN, non in uscita, per non bloccare servizi legittimi ospitati all'estero (un CDN, un fornitore cloud).

Logging, backup e aggiornamenti

Tre cose che separano un firewall gestito da uno abbandonato:

• Log remoti: Status > System Logs > Settings, abilita il Remote Logging verso un server syslog esterno. I log che restano solo sul firewall spariscono se il firewall viene compromesso o sostituito. La conservazione per almeno sei mesi è anche un requisito di adeguamento alla direttiva NIS2.
• Backup della configurazione: Diagnostics > Backup & Restore. Esporta l'XML dopo ogni modifica significativa e conservalo fuori dal firewall. Il pacchetto AutoConfigBackup automatizza la cosa.
• Aggiornamenti: pianifica una finestra mensile per aggiornare pfSense e i pacchetti. Un firewall fermo a una versione di un anno fa è una vulnerabilità con l'uniforme.

La configurazione è anche un'evidenza

Un firewall hardenizzato bene non è solo più sicuro: è anche dimostrabile. Regole commentate, una storia di backup datati, log conservati e una suppress list motivata sono esattamente le evidenze che un auditor chiede quando verifica i controlli di rete della ISO 27001:2022. Configurare con metodo e documentare mentre si configura non è lavoro in più: è lo stesso lavoro, fatto una volta sola e fatto bene.