Comprendere e configurare in sicurezza le regole Sophos Firewall

Una regola di Sophos Firewall decide quale traffico è consentito o bloccato tra zone, reti, utenti e servizi. Non conta attivare il maggior numero possibile di opzioni, ma scegliere criteri di corrispondenza adatti, il giusto ordine, funzioni di protezione adeguate e un test riproducibile.

Il percorso del menu è:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Questo articolo spiega il modulo della regola dall’alto verso il basso e utilizza sempre l’esempio LAN_to_WAN_Clients. Gli argomenti specifici come NAT, TLS Inspection o IPS sono illustrati nella misura necessaria per la regola firewall; le guide dettagliate sono collegate direttamente nel punto pertinente.

Pianificare prima di creare la regola

Delimitare correttamente la funzione

Le normali regole firewall controllano il traffico inoltrato che attraversa il firewall. Altre attività vengono configurate altrove:

• Servizi locali del firewall: WebAdmin, User Portal, VPN Portal, SSH, DNS e SNMP vengono controllati tramite Administration > Device access, Local Service ACL e la configurazione del relativo servizio. A questo serve Device Access e Local Service ACL.
• Traffico generato dal sistema: le connessioni generate dal firewall stesso non richiedono una normale regola firewall. Sono determinanti la configurazione del servizio, il routing, WAN Link Manager ed eventualmente SD-WAN per System Traffic.
• Traduzione di indirizzi e porte: NAT traduce il traffico, ma non lo autorizza. La regola firewall e quella NAT devono essere entrambe adatte.
• Routing e percorso di ritorno: una regola firewall corrispondente non dimostra che routing, SD-WAN, VPN o il percorso di ritorno siano corretti.
• Logica web: le categorie web, i gruppi URL e le azioni si configurano nella Web Policy. La regola firewall collega questa policy.
• Decrittografia HTTPS: una SSL/TLS inspection rule decrittografa il traffico. Scan HTTP and decrypted HTTPS analizza solo HTTPS già decrittografato.
• Identità dell’utente: AD SSO, STAS, Captive Portal, Entra ID SSO o RADIUS devono prima associare in modo affidabile l’utente al traffico. I dispositivi senza login possono essere configurati come Clientless Users con un IP fisso e univoco; questa associazione non è un’autenticazione.

Gli accessi di amministrazione che passano attraverso il firewall verso server, switch o hypervisor rientrano nelle normali regole firewall. L’accesso al firewall stesso, invece, rientra in Device Access.

Ordine, IPv4 e IPv6

Sophos Firewall controlla le regole dall’alto verso il basso. Non appena tutti i criteri di una regola corrispondono, le regole successive non vengono più valutate. Una regola generica LAN_to_WAN_Any sopra LAN_to_WAN_Restricted rende quindi inefficace la regola specifica.

Una regola può basarsi, tra l’altro, su Source zone, Source network, pianificazione, Destination zone, Destination network, Service, utente ed Exclusions. Tutti i criteri configurati devono corrispondere alla connessione.

Le regole MTA, IPsec o Hotspot create automaticamente possono comparire in cima all’elenco. Dopo procedure guidate, migrazioni o modifiche VPN è quindi necessario ricontrollare l’ordine. Per un hotspot Sophos Firewall, questo controllo fa espressamente parte della procedura di configurazione. Se SFOS non trova una regola corrispondente, in fondo si applica la regola implicita Drop-all con Firewall Rule ID #0. Non mostra alcun Usage Count; il traffico scartato viene registrato come evento.

Le regole IPv4 e IPv6 vengono gestite separatamente. Una regola IPv4 funzionante non protegge automaticamente lo stesso servizio tramite IPv6. Negli ambienti Dual Stack è necessario pianificare e testare consapevolmente entrambi i set di regole.

Separare chiaramente le basi di regole

Prima di creare la regola, devono essere definiti Source, Destination, Services, Owner e caso di test. Rischi diversi non devono essere riuniti in una regola generica:

• Internet per i client: reti client verso la zona WAN, con Web Policy adeguata, Application Control, IPS e registrazione.
• Internet per i server: solo le destinazioni necessarie per aggiornamenti, backup o cloud; in genere senza riferimento agli utenti.
• Wi-Fi per gli ospiti: zona Guest verso Internet, senza destinazioni interne e, se necessario, con limite di banda.
• Amministrazione: reti di amministrazione definite verso server e infrastruttura, separate dal normale traffico client.
• Remote Access VPN: zona VPN verso le destinazioni e i servizi interni effettivamente necessari.
• Site-to-Site: reti locali e remote con routing, NAT e percorso di ritorno adeguati.
• Sistemi pubblicati: WAN verso DMZ o zona server con origine ristretta, DNAT o WAF, IPS, registrazione e patch aggiornate.
• Accessi temporanei: regola dedicata con ticket, Owner, data di scadenza e rimozione pianificata.

Per strutturare la rete è utile Configurare zone e interfacce di Sophos Firewall.

⚠️ Any può essere utile per un breve test, ma raramente è una buona configurazione finale. In seguito la regola deve essere limitata alle Source, Destination e Services realmente necessari oppure rimossa.

Esempio pratico LAN_to_WAN_Clients

Nell’esempio, i client di una LAN definita possono accedere a Internet. Server, ospiti, VoIP e amministrazione ricevono regole dedicate.

• Rule name: LAN_to_WAN_Clients
• Description: Accesso Internet per la rete client. Webfilter, App Control e IPS attivi. Owner IT, Review 2026-12-01.
• Rule position: Bottom, quindi posizionare la regola sotto le specifiche regole di blocco e di eccezione
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: attivato
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS e solo i servizi di base effettivamente utilizzati direttamente su Internet
• Web policy: Default Workplace Policy
• Block QUIC protocol: attivato
• IPS: policy client adeguata
• App control: Application Policy client adeguata
• Shape traffic: solo con un obiettivo concreto di banda
• DSCP marking: solo se i dispositivi a valle elaborano la marcatura

DNS e NTP rientrano in questa regola LAN-to-WAN solo quando i client contattano direttamente resolver o server di riferimento orario esterni. Se utilizzano il firewall come servizio DNS o di riferimento orario, si tratta di traffico locale.

Il collaudo comprende un client definito, una destinazione concreta, la Firewall Rule ID prevista, la NAT Rule ID prevista e un controllo nel Log Viewer. In questo modo non si verifica solo il funzionamento dell’applicazione, ma anche che venga elaborata dalle regole previste.

Configurare la regola firewall

Sezione di intestazione

Rule status, Rule name e Description

Rule status è attivato per impostazione predefinita nelle nuove regole. Le regole preparate possono rimanere disattivate fino alla finestra di manutenzione. Le regole di test o migrazione disattivate in modo permanente devono essere controllate regolarmente.

Il nome deve indicare Source, Destination e scopo, ad esempio:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

La Description documenta scopo, Owner, ticket, limitazioni ed eventualmente la data di scadenza. Rule1, Allow o Internet sono poco utili per la gestione successiva. La procedura dedicata è disponibile in Documentare correttamente le regole Sophos Firewall.

Rule position e Rule group

Durante la creazione, in SFOS 22 Rule position offre Top o Bottom. In seguito la regola può essere spostata nella tabella oppure posizionata in modo preciso con Move To. Top deve essere selezionato solo quando una regola specifica deve volutamente precedere quelle esistenti.

Rule group migliora la visibilità, ma non modifica la logica di corrispondenza. None è l’impostazione predefinita. Con Automatic, SFOS assegna la regola a un gruppo esistente in base al primo tipo di regola corrispondente e alle zone Source/Destination. Il firewall continua a valutare le singole regole dall’alto verso il basso.

Action e registrazione

Action definisce come viene gestito il traffico corrispondente:

• Accept: consente la connessione.
• Drop: normalmente la scarta senza risposta. Se Use web authentication for unknown users è attivo, SFOS può invece mostrare una pagina di blocco per il traffico web.
• Reject: la scarta e invia un Reset per TCP oppure una risposta ICMP appropriata per UDP e ICMP.
• Protect with web server protection: crea una regola WAF. Questa opzione è disponibile solo per IPv4 e richiede Webserver Protection. La configurazione rientra funzionalmente in Sophos Firewall WAF.

Drop è adatto allo scarto silenzioso; Reject fornisce più rapidamente un riscontro riconoscibile nei test interni o durante il troubleshooting.

Log firewall traffic deve essere attivo nelle regole importanti. Inoltre, in System services > Log settings devono essere attivate le destinazioni locali, Sophos Central o Syslog appropriate. Senza un evento Destroy, una sessione può terminare senza un registro conclusivo, ad esempio in caso di interruzione improvvisa della linea.

Per una conservazione più lunga sono adatti Central Firewall Reporting o un server Syslog/SIEM. La registrazione non serve solo al troubleshooting, ma anche alla revisione: quali Source raggiungono la regola, quali Destination vengono utilizzate e l’accesso è ancora adeguato?

La stessa casella di controllo è la fonte dati per NetFlow v5 su Sophos Firewall: senza Log firewall traffic, NetFlow non esporta le connessioni di questa regola.

Source, Destination e Services

Nell’area Source si definisce la provenienza del traffico:

• Source zones: ad esempio LAN, VPN, DMZ, Guest o WAN.
• Source networks and devices: singoli host, reti, intervalli IP, gruppi, FQDN Hosts od oggetti paese.
• During scheduled time: All the time, orario di lavoro o una finestra di manutenzione.

La sola zona è spesso troppo ampia. Nell’esempio client, LAN viene quindi combinata con net_LAN_Clients. Nelle regole basate su un orario, l’ora del firewall, il fuso orario e lo Schedule devono corrispondere.

Configurare pianificazioni per regole e policy in Sophos Firewall mostra come creare e assegnare finestre ricorrenti o una tantum e testarne i limiti di commutazione.

In Destination and services sono disponibili:

• Destination zones: ad esempio WAN, DMZ, LAN o VPN.
• Destination networks: Any, un host, una rete, un gruppo, un oggetto paese o un FQDN Host.
• Services: definizioni di protocollo e porta come HTTP, HTTPS, DNS, NTP o un Service personalizzato.

La guida Utilizzare correttamente host e servizi di Sophos Firewall spiega come creare IP host, reti, intervalli, liste, Services e gruppi e come verificarli prima delle modifiche.

Any può essere accettabile in una regola Internet generale per i client. Le regole per server, amministrazione e VPN devono utilizzare Destination e Services molto più ristretti. Per destinazioni cloud dinamiche possono essere utili FQDN Hosts e Wildcard FQDN.

Utenti, Exclusions e Linked NAT

Match known users

Con Match known users, utenti o gruppi diventano criteri di corrispondenza. A seconda della configurazione, sono quindi disponibili altri campi:

• Use web authentication for unknown users: reindirizza gli utenti web sconosciuti ad AD SSO o Captive Portal. L’autenticazione e l’accesso dalla zona interessata devono essere già configurati. Configurare e testare Captive Portal su Sophos Firewall mostra come interagiscono autenticazione, Device Access, prerequisito DNS e regola utente.
• Users or groups: limita la regola alle identità selezionate.
• Exclude this user activity from data accounting: esclude il traffico di questi utenti dalla registrazione individuale del consumo di dati.

Una regola utente funziona solo con un’associazione affidabile degli utenti. Sotto di essa non deve esserci un’ampia regola di fallback che consenta lo stesso traffico senza riferimento agli utenti. Durante il collaudo, utente, gruppo e Rule ID devono corrispondere nel Log Viewer.

Add exclusion

Add exclusion esclude del traffico dalla regola. SFOS ignora la regola solo se tutti i criteri di Exclusion configurati corrispondono insieme, quindi verifica la regola successiva.

Come criteri sono disponibili Source zones, Source networks and devices, Destination zones, Destination networks e Services.

Un’eccezione utile può essere un server di aggiornamento escluso da una regola client generica e gestito da una regola dedicata sovrastante con altre funzioni di protezione. Se le Exclusions diventano numerose o difficili da comprendere, in genere è preferibile una regola specifica separata.

Create linked NAT rule

Una Linked NAT Rule è una regola Source NAT valida solo per il traffico della regola firewall collegata. Nella regola NAT si possono definire principalmente la Source tradotta e la Source Translation specifica dell’interfaccia.

La configurazione di fabbrica contiene normalmente una regola Default SNAT con MASQ. Prima di aggiungere una Linked NAT Rule, è necessario verificare se questa regola copre già correttamente il traffico. Se corrisponde una regola NAT indipendente posizionata più in alto, questa prevale sulla Linked NAT Rule.

Con DNAT, SFOS determina prima la destinazione tradotta e poi usa la relativa zona per la corrispondenza della regola firewall. Un port forwarding verso un server nella DMZ richiede quindi, di norma, Destination zone DMZ nella regola firewall, anche se il client contatta l’indirizzo WAN pubblico.

In caso di NAT Rule ID inattesa, è quindi necessario verificare anche l’ordine in Rules and policies > NAT rules. Dopo una modifica NAT è necessario creare una nuova connessione, perché le sessioni esistenti non vengono rivalutate. NAT non consente traffico da solo: la regola firewall decide tra Allow e Drop, mentre NAT traduce indirizzi o porte. I dettagli sono illustrati in Comprendere NAT in Sophos Firewall.

Selezionare le funzioni di protezione

Non tutte le opzioni sono disponibili con la Base License. Prima del rollout è necessario controllare in Administration > Licensing:

• Regole firewall normali: Base License
• IPS e Security Heartbeat: Network Protection
• Web Security, Application Control e protezione web antimalware: Web Protection
• Sandboxing e analisi dei file: Zero-Day Protection
• Protezione email: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection e Xstream Protection includono Web Protection. Anche il bundle Avanet Epic Protection include Web Protection. La classificazione completa è disponibile in Confrontare i bundle di licenze Sophos Firewall.

Web Filtering

Web policy collega una Web Policy con categorie, gruppi URL, utenti e azioni. Senza una Web Policy, questo campo non offre un controllo web basato sulle categorie. La policy viene creata e testata in Web Protection.

Apply web category-based traffic shaping utilizza le impostazioni di banda delle categorie web. L’opzione è utile solo se nelle categorie sono stati effettivamente configurati limiti o garanzie.

Block QUIC protocol blocca per la regola il traffico UDP in uscita sulle porte 80 e 443. QUIC non può essere analizzato come il normale traffico HTTP/HTTPS e aggira Web Filtering. SFOS attiva l’opzione per impostazione predefinita quando si seleziona una Web Policy o la scansione antimalware. I dettagli sono disponibili in Bloccare QUIC e HTTP/3.

Scan HTTP and decrypted HTTPS controlla la presenza di malware nel traffico HTTP e HTTPS già decrittografato. L’opzione non attiva la decrittografia. A questo scopo serve una SSL/TLS inspection rule adatta in Rules and policies > SSL/TLS inspection rules.

Use Zero-day protection invia i download sospetti a un’analisi aggiuntiva dopo la scansione antimalware. La funzione richiede Zero-Day Protection e, a seconda del tipo di file e della policy, può causare un ritardo.

Scan FTP for malware è necessario solo se la regola consente FTP. Nei sistemi Legacy, la scansione deve essere testata separatamente.

Use web proxy instead of DPI engine limita il Proxy Filtering alle consuete porte 80 e 443. Web Proxy è necessario, tra l’altro, per SafeSearch, restrizioni di YouTube, limitazioni dei domini Google Workspace, Pharming Protection, Web Cache o Parent Proxy. In modalità DPI, le SSL/TLS inspection rules si applicano a HTTP e TLS su tutte le porte.

Configurare un upstream proxy su Sophos Firewall descrive la catena aggiuntiva di regole e NAT per un parent proxy. Un proxy nella WAN richiede un percorso diverso da uno nella LAN o DMZ.

Un client Direct Web Proxy configurato esplicitamente utilizza invece il listener anche senza questa opzione. Configurare Direct Web Proxy con un file PAC spiega l’intera configurazione con porta, Device Access, file PAC, regola e test.

Decrypt HTTPS during web proxy filtering appartiene alla modalità Web Proxy. In modalità DPI, la Decryption viene gestita tramite SSL/TLS inspection rules. Le Web Exceptions possono ignorare Decryption, scansione antimalware, Zero-Day Protection e Policy Checks e devono quindi essere strettamente limitate e controllate regolarmente.

Synchronized Security Heartbeat

Le regole Heartbeat richiedono:

• un firewall registrato nello stesso account Sophos Central con Security Heartbeat attivo;
• un Sophos Endpoint gestito con licenza Trial o completa;
• Network Protection sul firewall.

Per rilevare gli Heartbeat mancanti, le zone interessate devono essere selezionate in System > Sophos Central > Optional configurations > Missing heartbeat zones.

Con Minimum source HB permitted e Minimum destination HB permitted viene richiesto uno stato di integrità minimo. Destination Heartbeat è adatto solo per destinazioni interne, non per la zona WAN.

Le opzioni Block clients with no heartbeat e Block request to destination with no heartbeat gestiscono i dispositivi senza Heartbeat. Per impostazione predefinita, un dispositivo che non ha mai inviato un Heartbeat rimane consentito e viene bloccato solo quando entrambe le opzioni sono attive. Questo comportamento deve essere testato consapevolmente con dispositivi privi di Sophos Endpoint.

Una Web Exception che ignora i Policy checks può consentire richieste web nonostante Block clients with no heartbeat. La procedura pratica di verifica è disponibile in Analizzare gli avvisi di Security Heartbeat mancante.

Application Control, IPS e Traffic Shaping

Identify and control applications (App control) collega una Application Filter Policy. Application Control richiede Web Protection. Per le Micro Apps basate su URL nel traffico cifrato, ad esempio upload e download di file in Dropbox o Gmail, è necessaria una SSL/TLS inspection rule adeguata che decrittografi il traffico. Filtri, registri e False Positives sono illustrati in Configurare Application Control.

Apply application-based traffic shaping policy utilizza la policy di banda assegnata a un’applicazione o categoria in Applications > Traffic shaping default. Gli Application Objects sono invece destinati alle rotte SD-WAN. Una Rules Policy selezionata tramite Shape traffic modella l’intero traffico della regola firewall. Sophos non documenta in modo uniforme la priorità quando Application Policy e Rules Policy vengono combinate; per un design comprensibile si deve utilizzare una sola variante per caso d’uso e testare ogni combinazione necessaria sul build SFOS in uso.

Detect and prevent exploits (IPS) collega una IPS Policy. IPS richiede Network Protection o una licenza Trial valida e deve essere attivato globalmente in Intrusion prevention > IPS policies. Il traffico client, server, webserver e VoIP richiede policy differenti e testate. Il rollout sicuro è descritto in Configurare e testare IPS.

Shape traffic assegna una Traffic Shaping Policy all’intera regola, ad esempio per VoIP, riunioni, backup od ospiti. Garanzie e limiti devono essere adeguati alla banda WAN disponibile. Maggiori informazioni: Configurare Application Traffic Shaping.

DSCP marking contrassegna i pacchetti per switch, router o dispositivi WAN a valle. La marcatura da sola non assegna alcuna priorità; tutti i dispositivi coinvolti devono gestire in modo coerente i valori DSCP selezionati.

NDR Active threat intelligence

Scan with NDR Active threat intelligence controlla il traffico mediante firme NDR curate. L’azione è fissa su Log threats: la funzione rileva e registra gli eventi, ma non blocca il traffico.

I requisiti sono:

• Xstream Protection Bundle;
• attivazione globale di NDR Active threat intelligence;
• registrazione IPS attiva;
• selezione dell’opzione in ogni regola firewall pertinente.

Sono supportati dispositivi XGS e deployment virtuali, software e cloud comuni, ma non XGS 87, 87w, 88 e 88w. XDR o MDR e il trasferimento a Sophos Central sono opzionali per un’analisi avanzata in Central.

Scan email content

In Scan email content si possono selezionare IMAP, IMAPS, POP3, POP3S, SMTP e SMTPS. La protezione richiede Email Protection. Se le porte standard non sono presenti in Services, è possibile aggiungerle mediante Add ports.

Il traffico email non deve essere nascosto in una regola Internet generica per i client. Una regola email dedicata rende più chiari Source, Destination, protocolli, registrazione e funzioni di protezione.

Testare e gestire la regola

Collaudo dopo il salvataggio

Dopo il salvataggio, la regola è completa solo quando il caso di test definito produce i risultati previsti:

Per ogni test deve essere apportata una sola modifica, in modo da poter associare causa ed effetto.

1. Controllare la posizione della regola e Rule group.
2. Controllare Log firewall traffic e le destinazioni in System services > Log settings.
3. Generare esattamente una connessione di test con un client, una Destination e un Service definiti.
4. Controllare Firewall Rule ID, Rule name, utente e Action nel Log Viewer.
5. Controllare NAT Rule ID e gli indirizzi tradotti.
6. Verificare separatamente DNS e routing.
7. Controllare Web Policy, Application Control, IPS e TLS Inspection in base all’azione prevista.
8. Cercare Drops imprevisti, errori SSL/TLS o problemi di prestazioni.
9. Rimuovere la regola di test o limitarla agli oggetti di produzione.

Per Policy Test, Log Viewer e Packet Capture è disponibile la procedura dedicata Testare una regola Sophos Firewall.

Nuova regola, regola esistente o disattivazione

Una regola esistente può essere ampliata se Source, Destination, scopo, Owner e requisiti di protezione rimangono invariati. È preferibile una regola dedicata quando registrazione, data di scadenza, Security Features, responsabili o ciclo di revisione sono diversi.

Accesso temporaneo per il supporto, server, ospiti, VoIP, IoT e amministrazione non devono scomparire in una regola client generica. Per le vecchie regole poco chiare, una disattivazione controllata è in genere più sicura di un’eliminazione immediata:

1. Chiarire scopo, Owner e dipendenze.
2. Definire registrazione e finestra di test.
3. Informare i team interessati.
4. Disattivare la regola ed eseguire i test definiti.
5. Rimuoverla solo dopo un periodo di osservazione verificabile.

Una regola di emergenza usata raramente può essere importante. Al contrario, una regola generica usata spesso non è automaticamente sicura.

Contatore dati, revisione e registro delle modifiche

Reset data transfer count azzera il contatore dei dati trasferiti di una regola. Non è un contatore di sessioni o corrispondenze. Lo stato Unused indica solo che nelle ultime 24 ore non è stato rilevato traffico corrispondente. Entrambe le indicazioni devono essere valutate insieme a registri, descrizione della regola e caso d’uso. Per analizzare i dati trasferiti si può utilizzare anche Reports > Dashboards > Traffic dashboard > Allowed policies.

Le revisioni periodiche controllano almeno:

• Source, Destination e Services;
• gli oggetti Any ancora presenti;
• Owner, ticket e data di scadenza;
• registrazione e utilizzo effettivo;
• NAT, Web Policy, IPS, TLS Inspection e altre funzioni di protezione;
• regole disattivate, temporanee e create automaticamente.

Prima di modifiche importanti deve essere disponibile un backup. Audit Trail Logs e Config Studio mostrano le modifiche alla configurazione; per i gruppi gestiti da Central, Firewall Management Task Queue conferma se la modifica è arrivata all’appliance corretto. Firewall Health Check completa la revisione periodica della sicurezza.

Errori tipici

• La regola prevista non si applica oppure compare Rule ID #0: controllare l’ordine, IPv4/IPv6 e tutti i criteri Source, Destination, Service, utente ed Exclusion.
• La Firewall Rule ID è corretta, ma NAT Rule ID o il percorso dei pacchetti no: controllare l’ordine NAT, il routing, SD-WAN e il percorso di ritorno.
• La regola si applica, ma la protezione manca o l’applicazione smette di funzionare: controllare separatamente licenza, attivazione globale, registrazione, Web Policy, QUIC, TLS Inspection, IPS e Traffic Shaping Policy.

Se Rule ID, NAT ID o il percorso dei pacchetti sono inattesi, La regola Sophos Firewall non si applica aiuta a individuare la causa in modo strutturato.