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 di sicurezza sono conservati indipendentemente dal firewall e monitorati, con responsabile e periodo di conservazione definiti?
• 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 Fusion (in precedenza 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.

Quando si crea un’eccezione WAN bisogna evitare di perdere l’accesso. Prima accedere e verificare un percorso di recupero indipendente tramite console, LAN di management, VPN amministrativa o Sophos Fusion. Quindi, in Administration > Device access, fare clic su Add sotto Local service ACL exception rule. Un esempio adattabile è WAN-Admin-203.0.113.10 con Rule position Top, IP version IPv4, Source zone WAN, l’IP pubblico fisso dell’amministratore come Source network / host, l’interfaccia WAN del firewall come Destination host, Services HTTPS e SSH solo se necessario, e Action Accept. 203.0.113.10 è un indirizzo di documentazione e va sostituito con l’IP amministrativo fisso reale. Lasciare aperta la sessione esistente, provare l’accesso in una seconda sessione da quella sorgente e solo dopo rimuovere l’autorizzazione WAN più ampia per HTTPS o SSH in Local service ACL. Se il test fallisce, l’accesso precedente rimane invariato; correggere l’eccezione prima di modificare l’autorizzazione di zona.

MFA, ruoli e login security

VPN Portal non serve solo per i download: Client VPN e configurazioni modificate vengono distribuiti tramite VPN Portal. Anche SSO richiede di mantenere la raggiungibilità WAN necessaria: Microsoft Entra ID SSO in SFOS 22 e OpenID Connect SSO in SFOS 23. Non chiudere un percorso SSO ancora necessario dopo i download. User Portal resta disattivato su WAN; l’accesso remoto avviene tramite VPN. Proteggere VPN Portal con ACL adeguate e quanto più restrittive possibile, un certificato valido e monitoraggio degli attacchi brute force. Con OIDC imporre MFA nell’IdP, non tramite OTP aggiuntivo del firewall. I passaggi OTP locali seguenti riguardano l’autenticazione classica, non OIDC. La configurazione è descritta in Entra VPN SSO e Google Workspace OIDC. Dopo modifiche ad ACL o autenticazione, testare un nuovo login e il tunnel VPN reale dalla rete esterna prevista; in caso di errore verificare ACL, certificato e associazione dei redirect anziché aprire ampiamente WAN.

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.

In SFOS 22, la configurazione degli utenti si trova in Authentication > Multi-factor authentication (MFA). In One-time password (OTP) selezionare All users oppure Specific users and groups, attivare Generate OTP token with next sign-in per i token basati su app e selezionare ogni servizio realmente usato in Require MFA for. L’account integrato admin si protegge separatamente in Administration > Device access > MFA for default admin. Prima di imporre MFA, almeno un account amministratore nominativo deve aver registrato il proprio token; verificarne l’emissione in Issued tokens. Provare quindi un nuovo accesso mantenendo aperta una sessione admin esistente come percorso di recupero.

La configurazione pratica si trova in Abilitare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access. Configurare in sicurezza amministratori e profili Sophos Firewall spiega come interagiscono account locali personali, profili Device Access, sorgenti di login e offboarding. Per scenari WAF con login utente è adatto Proteggere Sophos Firewall WAF con MFA.

Verificare le autorizzazioni VPN di accesso remoto

Concedere accesso VPN solo agli utenti e gruppi che ne hanno bisogno e alle sole risorse necessarie. Non selezionare a questo scopo il gruppo di fallback predefinito Open group. Gli utenti senza un gruppo corrispondente possono finirvi, per esempio durante la sincronizzazione AD. Controllare regolarmente i membri e assegnarli ai gruppi corretti. Questo gruppo predefinito non è né una regola firewall di fallback né il gruppo di fallback IdP volutamente ristretto della guida SSO collegata. La configurazione specifica del provider resta descritta lì. Per l’accettazione testare un utente autorizzato, un utente di fallback/non assegnato e una risorsa negata: deve funzionare solo l’accesso previsto. Se un test riesce inaspettatamente, correggere associazione dei gruppi e permessi VPN/firewall, quindi ripetere il test.

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. Controllare regolarmente le maintenance release disponibili e installarle tempestivamente dopo l’approvazione. 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.

La pagina conserva al massimo due versioni firmware. Un rollback avvia la versione precedente con la relativa configurazione anteriore; le modifiche eseguite dopo il cambio di versione vengono perse. Da SFOS 19.0 MR1, dopo tre aggiornamenti gratuiti i cambi di firmware richiedono Enhanced Support o Enhanced Plus; gli hotfix non richiedono questo abbonamento di supporto. Occorre quindi verificare firmware atteso, raggiungibilità amministrativa, VPN e pubblicazioni critiche prima di apportare ulteriori modifiche dopo l’aggiornamento.

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.

Una particolare migrazione di conformità è la modalità FIPS 140-3 su Sophos Firewall: l’attivazione esegue un factory reset e richiede una ricostruzione completamente pianificata con impostazioni VPN e dei certificati conformi a FIPS.

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 integrano la protezione solo per moduli e percorsi di traffico accertati. Da SFOS 22 è documentato il confronto dell’IPv4 sorgente del traffico in ingresso inoltrato DNAT/WAF con MDR, NDR e Third-Party Threat Feeds. Per servizi locali come VPN Portal, la protezione aggiuntiva accertata è il confronto dell’IPv4 sorgente con Third-Party Feeds supportati; questo percorso non passa per una regola firewall di transito. Gli indicatori di dominio/URL riguardano invece confronti appropriati della destinazione in uscita, non l’IP sorgente di un login in ingresso. Devono essere adeguati i percorsi DNS/IPS/Application Classification o web/ispezione TLS; i percorsi URL HTTPS completi richiedono decrittazione. Le sorgenti IPv6 non sono coperte da questa protezione.

Limite X-Ops irrisolto: Il testo ATR e la matrice di traffico SVG si contraddicono su alcune direzioni di confronto X-Ops, in particolare destinazione e sorgente locale del traffico in uscita. Non trasferire le conclusioni MDR, NDR o Third-Party Feeds a Sophos X-Ops, nemmeno per DNAT/WAF o portali locali. Fino a un chiarimento autorevole non dipendere dagli effetti contestati: ACL restrittive, regole firewall/WAF, patch e MFA restano necessari indipendentemente dal feed. Verificare modulo, direzione, log ed effetto reale solo con test autorizzati e controllati. MDR Threat Feeds e la guida NDR collegata più sotto approfondiscono questo limite.

Monitor rileva e registra le corrispondenze ma non blocca; Block deve essere configurato per il percorso verificato. Una corrispondenza da sola non prova né il blocco né una registrazione completa. Verificare il log ATR/firewall/WAF pertinente insieme alla connessione reale; allowlist, gestione dei falsi positivi e responsabilità restano necessari. Gli esempi seguenti valgono solo entro questi limiti di modulo e percorso.

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.

In SFOS 22, aprire il widget Firewall health check nel Control Center oppure andare in Monitor & analyze > Firewall health check. I dati si aggiornano quando cambia una configurazione monitorata. È importante sapere che un finding può essere contrassegnato manualmente come compliant senza correggerne la causa. La validazione deve quindi confermare il requisito della policy, non solo lo stato visualizzato.

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.

Valutare separatamente telemetria e Sophos Assistant

In Administration > Admin and user settings, Sophos Adaptive Learning controlla quali dati di utilizzo e sulle minacce il firewall invia a Sophos. Sono incluse le applicazioni non classificate e informazioni su alert IPS, virus rilevati, spam e rilevamenti di Active Threat Response. Inoltre, l’invio di base dei dati di configurazione e utilizzo è attivo per impostazione predefinita: il dispositivo invia periodicamente tramite HTTPS dati su configurazione, funzionalità, errori e utilizzo delle risorse. Sophos dichiara di non raccogliere informazioni specifiche o personalizzate degli utenti. La decisione va comunque documentata consapevolmente in base ai requisiti di privacy e al modello operativo, senza scambiare l’opzione per una funzione di protezione del traffico locale.

Turn on Sophos Assistant, invece, riguarda solo testi di aiuto, smart tips e guide di configurazione in WebAdmin. Dopo una modifica bisogna disconnettersi ed eseguire nuovamente il login. Disattivare l’assistente non riduce la superficie di attacco della rete e non interrompe automaticamente la telemetria; le due impostazioni vanno valutate separatamente.

Logging, alert e SIEM

Regole firewall senza logging sono spesso inutili per troubleshooting e incident response. La baseline documentata è il reporting centrale in Sophos Fusion (in precedenza Sophos Central) più una soluzione SIEM scelta. Definire classi di eventi, destinatari, responsabile, periodo di conservazione e monitoraggio con procedura di risposta. Documentare esplicitamente ogni eccezione architetturale: deve offrire un percorso equivalente, conservato indipendentemente dal firewall e monitorato; non ogni architettura necessita di destinazioni duplicate. Il solo controllo regolare del Log Viewer locale non basta. MDR, XDR e NDR non sono archivi di log intercambiabili. Con un evento di test autorizzato e innocuo verificare consegna a ogni destinazione prevista, ricerca nel log conservato e percorso di monitoraggio/allarme. Se la consegna fallisce, correggere selezione degli eventi, connettività e destinatari e ripetere il test. Verificare anche conservazione e permessi sulla destinazione.

Inoltre, in System services > Notification list selezionare gli eventi di sistema necessari per e-mail o SNMP. Prima configurare la destinazione e-mail in Administration > Notification settings, oppure l’agente SNMP e la community o l’utente in Administration > SNMP. Dopo Save, un evento controllato e innocuo deve raggiungere il destinatario previsto; in caso contrario verificare prima destinazione e-mail o SNMP, connettività e classe di evento selezionata.

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.

Validare le modifiche e tornare indietro in sicurezza

Applicare l’hardening in passi piccoli e tracciabili. Prima di ogni gruppo di modifiche, annotare valore corrente, owner e percorso di recupero previsto. Modificare quindi una sola area, per esempio Device Access, una regola firewall o l’azione di un Threat Feed. Provare sia il percorso consentito atteso sia un percorso intenzionalmente negato e controllare i log pertinenti. Solo dopo passare all’area successiva.

Per il rollback, riportare soltanto l’ultima impostazione modificata al valore iniziale documentato. Per Device Access mantenere disponibili sia la sessione admin esistente sia un percorso di management indipendente verificato in precedenza. Non eliminare la regola precedente prima che la sua variante più restrittiva sia stata validata. Avviare i Threat Feeds con Monitor, esaminare corrispondenze e possibili falsi positivi e passare a Block solo dopo; se il blocco causa problemi, tornare a Monitor e aggiungere solo eccezioni verificate. Un restore completo del backup non è un pratico pulsante Undo, ma il percorso di recovery per problemi più estesi.

Checklist compatta di hardening

Per una prima review usare questo ordine:

1. Limitare accesso WAN a WebAdmin e SSH, lasciare User Portal disattivato e mantenere e testare VPN Portal per i download e SSO necessari.
2. Attivare MFA per admin e Remote Access.
3. Ripulire account admin locali, ruoli e password policy.
4. Controllare firmware, hotfixes, pattern updates e stato supporto.
5. Documentare backup, SSMK, percorso restore e test recovery.
6. Verificare la necessità di pubblicazioni DNAT, WAF e VPN; limitare gruppi/risorse VPN, non autorizzare Open group e testare accessi consentiti e negati.
7. Ripulire regole con Any, logging mancante o owner non chiaro.
8. Attivare in modo mirato IPS, Spoof Protection, DoS Settings e Threat Feeds.
9. Introdurre Web, DNS, TLS e Zero-Day Policies a fasi.
10. Stabilire Health Check, log conservati indipendentemente e monitorati, test di consegna, alert e review regolari con responsabile e periodo di conservazione.

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.

FAQ