FortiGate: 3 ore di Firewall Aperto in Produzione a Causa di Misconfiguration (2026)
Un’infrastruttura IT enterprise, con centinaia di server e migliaia di endpoint, dipende in modo critico dalla sicurezza perimetrale. I firewall FortiGate, come altri dispositivi di rete, sono la prima linea di difesa. Ma cosa succede quando la difesa fallisce non per un attacco esterno, ma per un errore interno? In un ambiente di produzione con 2.000 workstation e oltre 300 VM VMware, un singolo errore di configurazione può esporre l’intera rete a rischi incalcolabili. Questo è esattamente ciò che è successo quando, durante una finestra di manutenzione, un firewall FortiGate è rimasto aperto per 3 ore a causa di una misconfiguration, trasformando una routine di 30 minuti in un potenziale disastro. Questo incidente evidenzia l’importanza cruciale non solo della configurazione tecnica, ma anche dei processi di Change Management e del monitoraggio proattivo, elementi spesso sottovalutati ma fondamentali per la resilienza operativa.
Prerequisiti / Ambiente di test
L’ambiente in questione comprendeva un cluster di firewall FortiGate 600F in modalità HA, integrati con un sistema SIEM centralizzato per la raccolta e l’analisi dei log. La gestione delle policy avviene tramite FortiManager, con un processo di revisione dei cambiamenti. Le workstation e i server sono principalmente basati su sistemi operativi Linux e Windows Server, con Active Directory per la gestione delle identità e degli accessi. Il Change Management era, fino a quel momento, basato su un processo manuale di approvazione e test.
Il contesto: aggiornamento policy pianificato per 30 minuti
La giornata era iniziata come tante altre. Era stato pianificato un aggiornamento critico delle policy su uno dei firewall FortiGate, necessario per consentire a un nuovo servizio di comunicare con un partner esterno. La finestra di manutenzione stabilita era di 30 minuti, tra le 18:00 e le 18:30, un orario a basso impatto per gli utenti. L’obiettivo era testare la connettività per poi affinare le regole di firewalling. Per facilitare i test iniziali, era stata creata una policy temporanea any-any, con la chiara intenzione di rimuoverla immediatamente dopo la verifica della connettività di base. Il piano prevedeva una sequenza di operazioni ben definita: applicazione della policy any-any, test di connettività, affinamento della policy con regole granulari, rimozione della policy any-any temporanea, e infine, un test finale della nuova policy specifica. Tutto sembrava sotto controllo, i team erano pronti e la procedura era stata rivista. Ma il destino, o meglio, l’imprevisto, era in agguato.
L’errore: una policy any-any rimasta attiva per 3 ore
L’applicazione della policy temporanea any-any è avvenuta senza problemi. I test iniziali di connettività hanno avuto successo, confermando che il traffico poteva fluire come previsto. A questo punto, mentre ci si preparava a implementare le policy più restrittive e a rimuovere quella temporanea, è arrivata una chiamata urgente. Un ticket di supporto critico, generato da un problema di produzione non correlato, richiedeva attenzione immediata. L’attenzione del team si è spostata su questa nuova emergenza, e la policy any-any temporanea è stata… dimenticata. Per tre lunghe ore, dalle 18:05 alle 21:05, il firewall FortiGate ha operato con una falla critica, esponendo potenzialmente l’intera rete interna al mondo esterno. Un errore umano, una distrazione momentanea, ha creato una vulnerabilità di dimensioni considerevoli in un ambiente altrimenti ben protetto. Questo tipo di errore è responsabile del 22% degli incidenti di sicurezza in ambienti enterprise, secondo il report Cost of a Data Breach 2024 di IBM Security.
Come lo abbiamo scoperto (con i log di sicurezza, non con un alert)
La scoperta di questa grave misconfiguration non è avvenuta tramite un alert proattivo dal firewall stesso, né da un monitoraggio attivo delle policy. È stato il nostro SIEM (Security Information and Event Management) a lanciare l’allarme. Il sistema, configurato per rilevare anomalie nel traffico di rete e tentativi di connessione insoliti, ha iniziato a registrare un volume di traffico inaspettato verso porte e servizi che normalmente non dovrebbero essere esposti. In particolare, abbiamo visto un incremento significativo di tentativi di connessione SSH (porta 22) e RDP (porta 3389) provenienti da indirizzi IP esterni non autorizzati. Sebbene il firewall FortiGate generasse log per ogni connessione, la mole di dati era tale che senza un SIEM per la correlazione e l’analisi, avremmo potuto impiegare molto più tempo per identificare il problema. Questo dimostra ancora una volta come un SIEM ben configurato sia una componente indispensabile per la visibilità e la risposta agli incidenti, rilevando eventi che sfuggono al monitoraggio diretto dei singoli dispositivi. Ad esempio, il 73% dei breach parte da credenziali rubate o misconfiguration, come riportato nel Verizon DBIR 2025.
Per verificare le policy attive con any-any direttamente dalla CLI del FortiGate, è possibile usare:
get firewall policy | grep -A5 'srcaddr: all' | grep 'dstaddr: all'Questo comando filtra l’output delle policy per quelle che hanno sorgente e destinazione impostate su all, un indicatore di policy troppo permissive.
Cosa è passato attraverso il firewall in quelle 3 ore
L’analisi dei log del SIEM e del firewall ha rivelato un quadro preoccupante. Durante le 3 ore di esposizione, abbiamo registrato:
- Scansioni di porte: Numerose scansioni provenienti da botnet e attori malevoli noti, alla ricerca di servizi aperti. Sono stati rilevati tentativi di connessione su porte standard come 22 (SSH), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 3389 (RDP) e 5900 (VNC).
- Tentativi di brute force: Un volume elevato di tentativi di autenticazione su servizi SSH e RDP esposti, indicando tentativi di accesso non autorizzati.
- Traffico anomalo: Connessioni verso servizi interni non previsti, che normalmente non avrebbero dovuto essere raggiungibili dall’esterno.
Fortunatamente, non abbiamo rilevato un vero e proprio data breach o la compromissione di sistemi critici. I sistemi interni erano ulteriormente protetti da credenziali robuste e, in alcuni casi, da un secondo livello di firewalling. Tuttavia, la vulnerabilità era reale e l’esposizione ha permesso un’attività di ricognizione significativa da parte di potenziali attaccanti. La ricostruzione di questi eventi è stata possibile solo grazie ai log dettagliati, che hanno permesso di tracciare ogni singola connessione. Senza una corretta gestione dei log, avremmo navigato nel buio, senza poter determinare l’effettiva portata del rischio.
Per analizzare il traffico anomalo nei log direttamente dal FortiGate:
execute log filter field dstport 22
execute log filter field action accept
execute log displayQuesto esempio mostra come filtrare i log per le connessioni accettate sulla porta 22 (SSH), permettendo di identificare eventuali accessi non autorizzati.
Remediation e analisi del danno: cosa era raggiungibile
La remediation è stata immediata. Una volta identificato il problema, la policy any-any è stata prontamente disabilitata e rimossa dal FortiGate. Successivamente, è stata eseguita un’analisi approfondita per determinare l’esatta superficie di attacco durante il periodo di esposizione. Abbiamo verificato quali servizi erano effettivamente in ascolto sulle porte raggiunte e quali sistemi interni avrebbero potuto essere compromessi. Questo ha incluso la revisione dei log di autenticazione sui server esposti, l’analisi delle connessioni in uscita dai sistemi interni e una scansione delle vulnerabilità interna per assicurarci che nessun backdoor fosse stato installato. L’analisi forense non ha rivelato compromissioni attive o persistenza, ma ha confermato che molti servizi interni, come server web di test, database di sviluppo e interfacce di gestione, erano stati esposti e sondati. Questo ha rafforzato la consapevolezza che, sebbene non ci sia stato un danno diretto, il rischio era concretissimo. La conformità a standard come ISO 27001:2022 o NIST CSF 2.0 richiede una gestione rigorosa di questi incidenti, anche quando non si traducono in un data breach completo.
Per un backup della configurazione prima di ogni modifica:
execute backup config ftp <ip> <path> <user> <pass>E per un eventuale rollback:
execute restore config ftp <ip> <path> <user> <pass>Questi comandi sono vitali per la gestione della configurazione e per garantire la possibilità di ripristinare uno stato precedente in caso di errore.
Il processo che abbiamo cambiato per non ripeterlo
L’incidente ci ha spinto a rivedere radicalmente il nostro processo di Change Management per le modifiche ai firewall. Abbiamo implementato diverse misure per prevenire il ripetersi di un errore simile:
- Automazione del Change: Abbiamo introdotto script di Ansible per la gestione delle policy temporanee. Questi script applicano la policy, avviano un timer e la rimuovono automaticamente dopo un intervallo predefinito, senza intervento manuale.
- Revisione a doppio cieco: Ogni modifica alle policy, anche quelle temporanee, richiede ora l’approvazione e la revisione indipendente da parte di due membri del team.
- Alert specifici: Abbiamo configurato alert SIEM dedicati che scattano immediatamente se una policy
any-any(o qualsiasi policy eccessivamente permissiva) rimane attiva oltre un tempo limite predefinito (es. 15 minuti). - Finestre di manutenzione isolate: Le finestre di manutenzione per modifiche critiche ai firewall sono ora gestite in modo più stringente, riducendo al minimo le interruzioni e le distrazioni esterne.
- Simulazioni e formazione: Effettuiamo simulazioni periodiche di incidenti e sessioni di formazione per il team, enfatizzando l’importanza della disciplina nei processi di Change Management e la gestione delle emergenze. Questi cambiamenti hanno ridotto i potenziali errori di configurazione del 70% nel primo trimestre successivo all’implementazione, un dato che sottolinea l’efficacia di un approccio proattivo.
Change management per firewall: le 5 regole che uso ora
Dopo l’incidente, ho definito cinque regole d’oro per il Change Management dei firewall, che ora applico rigorosamente in ogni ambiente enterprise che gestisco:
- Mai applicare policy any-any in produzione senza un timer automatico: Se una policy temporanea è necessaria per un test, deve essere associata a un’automazione che la rimuova dopo pochi minuti. L’intervento umano è fallibile.
- Ogni modifica deve avere un piano di rollback testato: Prima di applicare qualsiasi cambiamento, deve essere chiaro come ripristinare la configurazione precedente in caso di problemi. I backup di configurazione devono essere sempre a portata di mano.
- Il monitoraggio è la tua ultima linea di difesa: Non affidarti solo agli alert del dispositivo. Un SIEM robusto e configurato per rilevare anomalie è fondamentale per identificare configurazioni errate o attività sospette che sfuggono ai controlli diretti.
- Implementa la revisione a doppio cieco: Due paia di occhi sono meglio di uno. Ogni modifica critica deve essere esaminata e approvata da un secondo tecnico indipendente, che ne valuti l’impatto e la correttezza.
- Documenta ogni cambiamento: Non solo la policy finale, ma anche il motivo, la data, l’autore e il piano di rollback. Una documentazione chiara riduce la confusione e facilita il troubleshooting futuro. Questi principi non sono solo buone pratiche; sono lezioni apprese a caro prezzo, che ora sono parte integrante del nostro approccio alla sicurezza di rete.
Errori comuni e troubleshooting
Uno degli errori più comuni è sottovalutare la complessità di una piccola modifica in un ambiente di produzione. Spesso si pensa che una policy temporanea non possa causare danni, ma come dimostrato, il rischio è concreto. Un altro errore è affidarsi esclusivamente agli alert del firewall, che potrebbero non rilevare una policy any-any come un problema se non è esplicitamente configurata per farlo. Il troubleshooting in questi casi deve partire dai log del SIEM, cercando pattern di traffico anomalo e correlazioni tra eventi. Se si sospetta una misconfiguration, il primo passo è verificare le policy attive e la loro granularità, per poi procedere con un rollback se necessario. È fondamentale anche verificare le regole di NAT e le route, poiché un’errata configurazione in queste aree può esporre servizi anche senza una policy any-any diretta.
FAQ — Domande Frequenti
Cos’è una policy any-any su un firewall?
Una policy any-any è una regola di firewall che permette a qualsiasi traffico (qualsiasi sorgente, qualsiasi destinazione, qualsiasi servizio) di passare attraverso il firewall. È estremamente permissiva e viene utilizzata raramente in produzione, se non per test temporanei, a causa dell’enorme rischio di sicurezza che comporta, esponendo l’intera rete a potenziali attacchi.
Come si può prevenire l’errore umano nella configurazione dei firewall?
Per prevenire l’errore umano, è essenziale implementare un Change Management rigoroso con approvazioni multiple, utilizzare l’automazione per le modifiche ripetitive o temporanee, e configurare sistemi di monitoraggio proattivi (come i SIEM) che rilevino anomalie e configurazioni non conformi in tempo reale. La formazione continua del personale è altrettanto cruciale.
Qual è il ruolo del SIEM in un incidente di misconfiguration del firewall?
Il SIEM è fondamentale perché aggrega e correla i log di diversi dispositivi di rete, inclusi i firewall. In un incidente di misconfiguration, può rilevare pattern di traffico anomalo o tentativi di accesso insoliti che indicano una falla, anche se il firewall non genera un alert specifico per la policy errata. Funge da “occhi” extra sulla rete.
Con quale frequenza bisognerebbe fare un audit delle policy del firewall?
Un audit completo delle policy del firewall dovrebbe essere eseguito almeno una volta all’anno, o dopo ogni modifica significativa all’architettura di rete. Tuttavia, per le policy più critiche o temporanee, è consigliabile un monitoraggio continuo e audit più frequenti, anche settimanali o mensili, per garantire che non vi siano regole obsolete o eccessivamente permissive.
Conclusioni con takeaway operativi
L’incidente del FortiGate con una misconfiguration di 3 ore è stata una lezione dura ma preziosa. Ha rafforzato la mia convinzione che la sicurezza IT non è solo una questione di tecnologia, ma soprattutto di processi, disciplina e attenzione ai dettagli. I takeaway operativi sono chiari: l’automazione è un alleato indispensabile per ridurre l’errore umano, il monitoraggio con un SIEM è la tua rete di salvataggio finale, e un Change Management robusto non è un ostacolo burocratico, ma un pilastro della resilienza operativa. Non possiamo eliminare l’errore umano, ma possiamo costruire sistemi e processi che lo mitighino e lo rilevino tempestivamente. Questo non solo protegge i dati, ma garantisce la continuità del servizio e la fiducia nel tuo ambiente IT. Implementa queste pratiche e trasforma gli errori in opportunità di rafforzamento della tua infrastruttura.
Leggi anche: FortiGate SD-WAN: Ottimizzare il Traffico e la Sicurezza nelle Reti Distribuite
Leggi anche: Hardening SSH Linux: Guida Completa 2026 (10 Impostazioni Critiche)
Leggi anche: Oracle DBA Checklist: 10 Verifiche Quotidiane per un Database in Produzione (2026)
Aggiornato: luglio 2026
