Sophos Firewall Hardening: best practice per una configurazione sicura
L’hardening di Sophos Firewall significa ridurre consapevolmente la superficie d’attacco non necessaria attorno al firewall stesso e ai servizi pubblicati tramite esso. Non è una singola impostazione magica, ma un processo operativo ripetibile: limitare l’accesso amministrativo, imporre MFA, mantenere aggiornato il firmware, controllare le regole, attivare le funzioni di protezione e analizzare i log.
Questo articolo è il punto di ingresso centrale. Non sostituisce le guide dettagliate, ma ordina le best practice più importanti e collega gli articoli Avanet KB appropriati.
Cosa controllare per primo
Nell’hardening l’ordine conta. Una policy IPS perfettamente regolata serve poco se WebAdmin è raggiungibile da WAN in tutto il mondo o se un vecchio portale VPN resta esposto senza MFA.
I controlli immediati più importanti:
- WebAdmin è raggiungibile dalla zona WAN?
- SSH è consentito solo da reti di management fidate?
- MFA è attivo per amministratori, VPN Portal e Remote Access?
- Firmware, hotfixes e pattern updates sono aggiornati?
- Esistono accessi DNAT, WAF o VPN non più necessari?
- I servizi pubblicati hanno IPS, WAF, Threat Feeds, logging e responsabilità chiara?
- I log rilevanti per la sicurezza sono archiviati centralmente o almeno controllati regolarmente?
- Esiste un backup attuale e testato, incluso il Secure Storage Master Key?
Proteggere l’accesso amministrativo
L’area di hardening più importante è l’accesso al firewall stesso. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal e servizi locali non sono normali regole firewall, ma servizi locali del firewall. Devono essere limitati consapevolmente tramite Device Access e Local Service ACL.
Device Access e Local Service ACL
In Administration > Device access si definisce per ogni zona quali servizi locali sono raggiungibili. Per la zona WAN dovrebbe essere attivo solo ciò che serve davvero. Accesso admin e SSH normalmente non dovrebbero essere esposti ampiamente a Internet.
Se è necessaria amministrazione remota, queste varianti sono più pulite:
- Gestione tramite Sophos Central.
- Accesso tramite una rete di management dedicata.
- Accesso tramite VPN o ZTNA.
- Local Service ACL Exception Rules ristrette a indirizzi IP sorgente admin fissi.
L’implementazione è descritta in Proteggere l’accesso Sophos Firewall: configurare correttamente Device Access. Se serve SSH, aiuta anche Connettere Sophos Firewall via SSH.
MFA, ruoli e login security
MFA dovrebbe essere obbligatorio per amministratori e utenti Remote Access. Sono particolarmente critici account admin locali, VPN Portal, User Portal e Remote Access VPN. MFA però è solo una parte dell’hardening del login. Sono altrettanto importanti account admin nominali, ruoli chiari, password policy forti, tentativi di login limitati e session timeout brevi.
La configurazione pratica si trova in Abilitare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access. Per scenari WAF con login utente è adatto Proteggere Sophos Firewall WAF con MFA.
Firmware, hotfixes e recovery
Un firewall è un sistema edge. Aggiornamenti ritardati non sono quindi un dettaglio estetico, ma una vera finestra d’attacco. Allo stesso tempo gli aggiornamenti non vanno eseguiti alla cieca, perché sedi remote, cluster HA, VPN e regole NAT produttive possono essere coinvolti.
Rendere pianificabili gli aggiornamenti
Gli aggiornamenti firmware dovrebbero essere preparati con backup, finestra di manutenzione, controllo delle release notes, pianificazione HA e criteri di rollback. Nelle versioni SFOS 22 attuali, la pagina WebAdmin Backup & Firmware > Firmware non mostra più una sezione Hotfix separata. La funzione hotfix esiste ancora: Sophos installa gli hotfix automaticamente per impostazione predefinita e consiglia di non modificare questa impostazione. Se occorre verificarne lo stato, usare system hotfix show nella Device Console. Gli hotfix non sostituiscono un processo di update regolare. Il processo è descritto in Sophos Firewall firmware update: preparazione e best practice.
Per salti di versione maggiori, controllare anche percorso di upgrade, licenza, piattaforma e limitazioni note. Controllare Sophos Firewall prima dell’upgrade SFOS 22 è adatto.
Controllare backup e restore
L’hardening non finisce con la prevenzione. Un firewall rafforzato deve anche essere ripristinabile. Servono un backup attuale, la password del backup, il Secure Storage Master Key, un percorso di accesso documentato dopo il restore e un test di accettazione.
I dettagli sono in Creare o ripristinare un backup Sophos Firewall. Un pacchetto di recovery completo è obbligatorio soprattutto prima di firmware update, migrazioni, reimage e sostituzione hardware.
Ridurre la superficie d’attacco nelle regole
Molti rischi non derivano da attacchi esotici, ma da regole troppo ampie, vecchie eccezioni e servizi pubblicati di cui nessuno è più davvero responsabile.
NAT, WAF e servizi pubblicati
Ogni servizio pubblicato tramite DNAT o WAF è un ingresso aperto consapevolmente. Può essere necessario, ma va pianificato in modo stretto: source, destination, service, ordine NAT, regola firewall, policy IPS/WAF, logging, test e owner stanno insieme.
Per server pubblicati aiutano Pubblicare un server con DNAT su Sophos Firewall e Comprendere NAT su Sophos Firewall. Se vengono pubblicati web server, Sophos Firewall WAF: pubblicare web server in sicurezza è la base più adatta.
Regole firewall e segmentazione
Le regole con Any come source, destination o service non sono automaticamente sbagliate, ma devono sempre essere spiegabili. Per l’hardening contano queste domande:
- La regola serve ancora?
- Il logging è attivo?
- Esiste una source o destination più chiara?
- La regola è posizionata correttamente prima di regole più ampie?
- Reti admin, server, client, IoT, guest e backup sono separate in modo pulito?
Le basi sono in Comprendere e configurare in sicurezza le regole Sophos Firewall. Per verificare una regola concreta, Testare correttamente una regola Sophos Firewall è adatto.
Attivare consapevolmente le funzioni di protezione
Le funzioni di protezione aiutano solo se corrispondono a regola, traffico e processo operativo. Attivazioni cieche creano falsi positivi, problemi di performance o casi di supporto. Funzioni disattivate lasciano invece aperta superficie d’attacco inutile.
IPS, Spoof Protection e DoS
IPS dovrebbe essere usato sul traffico in ingresso non fidato e sui passaggi interni rilevanti. Sono importanti policy IPS adatte, logging, processo per falsi positivi e attenzione alle performance. L’implementazione è in Configurare e testare in sicurezza Sophos Firewall IPS.
Spoof Protection e DoS Settings riducono sorgenti non plausibili e semplici pattern di flooding. Devono essere testati con prudenza, soprattutto con VoIP, VPN, carico pacchetti elevato o routing particolare. L’articolo adatto è Controllare Sophos Firewall Spoof Protection e DoS Settings.
Threat Feeds per WAF e DNAT
I Threat Feeds sono un’integrazione molto utile quando servizi sono raggiungibili tramite WAF, DNAT, VPN Portal o altri accessi pubblici. Possono bloccare prima IP, domini o URL malevoli noti, prima che raggiungano l’applicazione o la regola effettiva.
Sono particolarmente utili per:
- web server pubblici dietro WAF o DNAT,
- accessi RDP, SSH o admin non ancora sostituiti completamente da ZTNA,
- accessi VPN e portali con molto rumore Internet,
- ambienti in cui il blocco per paese è troppo grossolano,
- clienti che vogliono usare feed di terze parti curati oltre a Sophos X-Ops.
Il funzionamento operativo è decisivo: qualità del feed, azione Monitor o Block, allowlist, falsi positivi, logging e responsabilità devono essere chiari. La configurazione è descritta in Configurare e gestire in sicurezza Sophos Firewall Threat Feeds. Per feed curati, Cybora può essere un componente utile, soprattutto quando servizi pubblicati devono essere protetti in modo coerente da fonti note come pericolose.
Web, DNS, TLS e Zero-Day Protection
Web Protection, DNS Protection, TLS Inspection e Zero-Day Protection aumentano visibilità e capacità di blocco, ma richiedono pianificazione pulita. TLS Inspection non dovrebbe partire come progetto tutto-o-niente. DNS Protection deve corrispondere ai percorsi DNS usati. Zero-Day Protection aiuta solo se tipi di file e policy rilevanti sono integrati sensatamente.
Gli articoli dettagliati sono Creare Sophos Firewall Web Protection con Web Policies, Configurare Sophos DNS Protection con Sophos Firewall, Introdurre correttamente Sophos Firewall TLS Inspection e Comprendere e gestire Sophos Firewall Zero-Day Protection.
Rilevamento, logging e review
L’hardening non è un’attività una tantum. Regole, utenti, portali, eccezioni NAT e versioni firmware cambiano. Servono quindi review regolari e log disponibili prima di un incidente.
Health Check come punto di partenza
Il Sophos Firewall Health Check è un buon punto di partenza perché rende visibili configurazioni rischiose. I finding non vanno applicati alla cieca, ma valutati per rischio, impatto operativo e architettura locale.
Momenti adatti per un Health Check:
- dopo il setup iniziale,
- dopo migrazioni,
- prima e dopo upgrade firmware,
- dopo grandi modifiche alle regole,
- prima degli audit,
- trimestralmente durante l’esercizio.
Logging, alert e SIEM
Regole firewall senza logging sono spesso inutili per troubleshooting e incident response. Per conservazione più lunga, il Log Viewer locale di solito non basta. A seconda dell’ambiente sono utili Sophos Central Reporting, Syslog, SIEM, MDR, XDR o NDR.
La configurazione Syslog è descritta in Inviare Sophos Firewall Syslog in sicurezza a SIEM. Per report centrali è adatto Attivare e gestire Sophos Firewall Central Reporting. Se NDR e Active Threat Response sono rilevanti, aiuta Gestire Sophos Firewall NDR e Active Threat Response.
Checklist compatta di hardening
Per una prima review usare questo ordine:
- Controllare accesso WAN a WebAdmin, SSH, User Portal e VPN Portal.
- Attivare MFA per admin e Remote Access.
- Ripulire account admin locali, ruoli e password policy.
- Controllare firmware, hotfixes, pattern updates e stato supporto.
- Documentare backup, SSMK, percorso restore e test recovery.
- Verificare la necessità di pubblicazioni DNAT, WAF e VPN.
- Ripulire regole con
Any, logging mancante o owner non chiaro. - Attivare in modo mirato IPS, Spoof Protection, DoS Settings e Threat Feeds.
- Introdurre Web, DNS, TLS e Zero-Day Policies a fasi.
- Stabilire Health Check, Syslog, alert e review regolari come processo operativo.
Errori frequenti
L’accesso WAN resta aperto per comodità
Un accesso WebAdmin o SSH viene aperto per un caso di supporto e poi dimenticato. Proprio queste eccezioni temporanee dovrebbero essere documentate con scadenza, owner e controllo successivo.
I Threat Feeds vengono attivati senza concetto operativo
I Threat Feeds sono forti, ma non privi di manutenzione. Senza monitoring, allowlist e processo per falsi positivi può essere bloccato un partner, fornitore o servizio cloud legittimo. Quindi testare prima con Monitor o scope limitato, poi passare ordinatamente a Block.
Manca logging sulle regole critiche
Se una regola DNAT pubblica, WAF o VPN non logga, in caso di incidente si vede troppo poco. Almeno ingressi rilevanti per la sicurezza, accessi admin, regole deny e passaggi critici tra segmenti dovrebbero essere tracciabili.
Health Check viene trattato come attività una tantum
Un buon punteggio dopo il setup non è uno stato permanente. Nuove regole, nuovi utenti VPN, eccezioni temporanee e modifiche firmware possono cambiare la situazione. L’hardening richiede un ritmo di review.