È sempre colpa del firewall: il guardiano frainteso della rete

«Non passa? Sarà il firewall.» È la frase che parte automatica in ogni war room. Il firewall è il gemello del DNS: fondamentale, ovunque, e primo capro espiatorio di ogni problema di rete. Con una differenza crudele: il DNS, quando lo si accusa, spesso è davvero colpevole; il firewall viene incolpato sia quando ha ragione sia quando ha torto — ed è quasi sempre l’ultimo a potersi difendere, perché nessuno legge davvero le sue regole.

Nel mio lavoro parto sempre dal presupposto opposto: prima di incolpare il firewall, va provato. Un «drop» misterioso può essere routing asimmetrico, una sessione scaduta, un MTU sbagliato — e correlazione non è causazione. Il firewall, in realtà, non mente quasi mai: dice con precisione cosa blocca e perché. Il problema è saperlo leggere con metodo. Vale la pena capire come ragiona davvero, perché è uno dei pochi apparati in cui ogni altro errore della rete finisce per diventare visibile.

Da filtro di pacchetti a guardiano applicativo

Alla fine degli anni ’80 nascono i primi packet filter: regole statiche su indirizzi IP e porte, senza memoria. Ogni pacchetto viene giudicato da solo, come se fosse il primo e l’ultimo — semplice, ma cieco al contesto.

Il salto arriva nel 1994, quando Check Point introduce la stateful inspection: il firewall inizia a ricordare le connessioni. Capisce che un pacchetto di ritorno appartiene a una sessione già autorizzata, e non serve più aprire buchi simmetrici per far funzionare una semplice risposta. È il modello che usiamo ancora oggi. Poi vengono i proxy e i firewall applicativi, capaci di capire i protocolli — HTTP, FTP — e non solo le porte.

Intorno al 2007–2010 compaiono i Next-Generation Firewall: riconoscono l’applicazione a prescindere dalla porta usata, integrano un IPS e — svolta importante — legano le regole all’identità dell’utente, non più al solo indirizzo IP. Infine il perimetro comincia a dissolversi: con il cloud e il lavoro remoto, la logica si sposta su microsegmentazione, ZTNA e SASE. Il firewall non è più soltanto una scatola al confine: è diventato una funzione distribuita, presente ovunque ci sia traffico da governare.

Nel frattempo la scatola si è gonfiata di funzioni: antivirus di rete, VPN, filtro dei contenuti, sandboxing. Sono le appliance UTM (Unified Threat Management) che hanno reso il firewall un coltellino svizzero della sicurezza — comodo per chi gestisce reti piccole, ma anche il primo passo verso un apparato che fa troppe cose insieme e che, quando fa i capricci, se ne trascina dietro parecchie. Come vedremo, è un nodo che torna.

Come ragiona, in breve

Una policy è un elenco ordinato di regole. Si valuta dall’alto verso il basso e vince la prima corrispondenza: l’ordine conta quanto il contenuto. Spostare una regola di due righe può cambiare completamente il comportamento, ed è una delle cause più subdole di «ieri funzionava».

Il principio sano è il default-deny: ciò che non è esplicitamente permesso è vietato. In fondo a ogni ruleset ben fatto c’è un deny implicito che blocca tutto il resto. Sopra ci sono le eccezioni consapevoli — non il contrario.

Sembra ovvio, eppure moltissime reti reali funzionano al contrario: nate con un default-allow «tanto per far partire le cose» e mai davvero chiuse. La differenza non è filosofica. Con il default-deny devi dichiarare esplicitamente ciò che consenti, e quella lista diventa la documentazione vivente di cosa dovrebbe accadere sulla rete; con il default-allow insegui all’infinito ciò che vuoi vietare, sempre un passo indietro rispetto a chi cerca una via d’uscita.

Poi c’è lo stato: il firewall tiene una tabella delle connessioni, consente il traffico di ritorno delle sessioni già stabilite e chiude quelle inattive dopo un timeout. E c’è una distinzione che genera metà dei malintesi: il NAT non è il filtraggio. Sono due funzioni diverse che convivono nello stesso apparato; un problema di NAT sembra un problema di firewall, ma non lo è. Il tutto ragiona per zone — interno, DMZ, esterno — e non per soli indirizzi.

Un’ultima cosa che quasi tutti trascurano: un firewall serve anche a vedere. I contatori di hit dicono quali regole sono vive e quali sono morte da anni; registrare i pacchetti scartati dal deny implicito trasforma l’apparato in un sensore prezioso per il rilevamento delle minacce. Una regola senza log è una regola di cui non saprai mai nulla — né durante un troubleshooting, né il giorno dopo un incidente.

Perché finisce sempre sotto accusa

Il firewall è il punto in cui ogni altro errore della rete diventa improvvisamente visibile. Ecco i colpevoli reali che si travestono da «problema di firewall».

Il rule sprawl: migliaia di regole stratificate in anni, che nessuno audita più. Regole ombra mai raggiunte, ridondanti, contraddittorie — un archeologia che pochi hanno il coraggio di scavare. La regola any-any «temporanea» aperta per sbloccare un progetto e mai richiusa: il buco che nessuno ricorda di aver fatto. Lo stateful che scade una sessione lunga — una query pesante, una connessione keepalive — e l’applicazione «ogni tanto» cade, senza un pattern apparente.

E ancora: il routing asimmetrico, in cui il pacchetto va da una parte e torna da un’altra; il firewall vede metà conversazione e la scarta, e sembra un blocco malevolo quando è pura topologia. L’MTU e la frammentazione, il NAT hairpin, e il grande classico: «ieri funzionava», che significa quasi sempre qualcuno ha cambiato una regola. Il filo conduttore è il metodo: il firewall va interrogato — log, contatori di hit per regola, packet capture — non accusato per riflesso.

Un esempio dal campo, reso anonimo. Una notte ho passato ore a «difendere» un firewall accusato di bloccare a intermittenza un gestionale critico. Nessuna regola era sbagliata: il traffico entrava da un’interfaccia e, per via di una rotta ridondante, tornava da un’altra. Il firewall, stateful, vedeva solo metà conversazione e la scartava — esattamente come previsto. A mentire era la topologia, non la policy. Sistemato l’instradamento, il «bug del firewall» è semplicemente svanito.

Necessario, non sufficiente

Il firewall è indispensabile, ma da solo dà una falsa sicurezza. Una regola troppo larga protegge sulla carta e non nei fatti, e un ruleset che nessuno sa spiegare è già una vulnerabilità. Il perimetro, poi, non esiste più come una volta: con cloud, lavoro remoto e traffico est-ovest tra i server, un firewall perimetrale non ferma il movimento laterale una volta che l’attaccante è dentro. Da qui la microsegmentazione e lo Zero Trust: portare il controllo vicino al carico di lavoro, non solo al confine.

Va detto anche il rovescio della medaglia dell’evoluzione recente. Consolidare tutto nel firewall — VPN, ispezione, filtraggio, SD-WAN — è comodo, ma trasforma quell’apparato nel classico punto singolo di guasto: quando rallenta lui, rallenta tutto, e ogni disservizio torna a essere «colpa del firewall». È una delle ragioni per cui i modelli SASE e Zero Trust distribuiscono l’applicazione delle regole invece di concentrarla in un unico collo di bottiglia. In fase di architettura la domanda giusta non è «quanto è potente il firewall», ma «cosa succede il giorno in cui non c’è».

La cifratura è un’arma a doppio taglio: la gran parte del traffico oggi è TLS, e un firewall che non decifra è cieco al livello applicativo. Decifrare abilita l’ispezione ma introduce rischio e complessità — privacy, prestazioni, gestione dei certificati — ed è una scelta di architettura, non una casella da spuntare. Allo stesso modo, le funzioni «next-gen» (IPS, application control, filtraggio) valgono quanto la loro messa a punto: attivate e mai curate, sono placebo. La vera sicurezza di un firewall è l’igiene delle regole: documentazione, revisione periodica, rimozione del morto, change management disciplinato.

Nella pratica significa poche cose, fatte bene: ogni regola ha un proprietario e una motivazione scritta; le aperture «temporanee» hanno una data di scadenza vera, non teorica; e almeno una volta l’anno il ruleset viene passato al setaccio per togliere il morto e restringere ciò che è troppo largo. È lavoro noioso e poco glamour — ed è esattamente ciò che distingue un perimetro difendibile da uno che regge solo finché nessuno lo mette alla prova.

Perché capirlo fa la differenza

Il firewall premia il rigore: regole difendibili, ordine chiaro, NAT documentato, stato compreso. In un ambiente critico un firewall vale quanto il suo ruleset è verificabile — non quanto è costoso l’apparato. I tecnici bravi lo trattano come una scatola nera finché tiene; poi, sotto pressione, si scopre che nessuno conosce davvero quelle regole, e la war room si trasforma in una seduta spiritica.

Per questo, la prossima volta che «è colpa del firewall», non accusarlo per primo: chiediti cosa è cambiato, guarda i log e i contatori, ricostruisci il percorso del pacchetto. Il firewall raramente mente — ma raramente qualcuno si prende la briga di ascoltarlo.

Fa parte della serie «È sempre…» sulle fondamenta invisibili dell’infrastruttura. Leggi anche È sempre il DNS.