Capire e configurare le regole Sophos Firewall

Le Firewall Rules sono il cuore di Sophos Firewall. Decidono quale traffico tra zone, reti, utenti e servizi viene consentito o bloccato e quali funzioni di protezione vengono applicate.

Questo articolo spiega una Sophos Firewall Rule dall’alto verso il basso: ordine, gruppi, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR e scansione e-mail.

Il percorso di menu è:

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

Navigazione rapida

• Principio di base e ordine
• Esempio pratico
• Area superiore: stato, nome, azione e logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Controllo dopo il salvataggio
• Errori tipici

Principio di base e ordine

Le Firewall Rules controllano il traffico tra zone e reti. Possono consentire, scartare o bloccare traffico e applicare Security Features aggiuntive.

Sophos Firewall controlla le Firewall Rules dall’alto verso il basso. Appena una regola corrisponde, le regole successive non vengono più controllate. Non conta quindi solo cosa contiene una regola, ma anche dove si trova nell’elenco.

Una regola corrisponde solo se tutti i criteri rilevanti corrispondono contemporaneamente:

Vince la prima regola che corrisponde. Se una regola generale LAN_to_WAN_Any si trova sopra una regola più specifica LAN_to_WAN_Restricted, la regola specifica non verrà mai raggiunta.

Esempio pratico

In questo esempio viene creata una regola client pulita:

Obiettivo: i client della LAN interna possono accedere a Internet. Web Filtering, Application Control, IPS e logging devono essere attivi. Server, guest e reti di management ricevono regole proprie e non vengono mescolati con questa regola client.

Questo esempio non è volutamente un lasciapassare Any. Nella pratica, reti client, reti server, Wi-Fi guest, VoIP e management devono essere considerate separatamente.

Area superiore: stato, nome, azione e logging

Rule status

Rule status attiva o disattiva la regola.

Una nuova regola è normalmente attiva. Per regole preparate si può disattivare lo stato e attivarle solo più tardi. Le regole disattivate devono essere controllate regolarmente, così vecchie regole di test o migrazione non restano nella configurazione.

Esempio pratico: una nuova regola per un server viene preparata, ma attivata solo durante la finestra di manutenzione.

Rule name

Il nome deve rendere subito chiaro cosa fa la regola.

Nomi validi:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Nomi come Rule1, Test, Allow o Internet sono meno utili, perché in seguito non si riconosce più lo scopo della regola.

Description

La descrizione è importante per operations, supporto e audit. Dovrebbe indicare:

• perché la regola esiste
• chi ha richiesto la regola
• quali restrizioni sono state impostate consapevolmente
• se esiste un ticket, un progetto o una data di scadenza

Esempio:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

L’articolo Come documentare facilmente una regola Sophos Firewall descrive più in dettaglio come usare bene questo campo e documentare le Firewall Rules in modo tracciabile.

Rule position

Rule position definisce dove viene inserita la nuova regola.

Regola base: specifico prima di generale. Una regola per un singolo server o un’applicazione specifica si trova di solito sopra una regola Internet generale.

Rule group

Rule group è un raggruppamento organizzativo. Il gruppo non è un confine di sicurezza e non è un policy engine separato. La firewall continua a controllare le singole regole dall’alto verso il basso.

Gruppi utili:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

In ambienti piccoli None può bastare. In ambienti più grandi conviene introdurre presto una struttura chiara, perché la base regole diventa rapidamente poco leggibile.

Action

Action determina cosa accade al traffico che corrisponde.

Per normali regole client o server si usa quasi sempre Accept. Per regole di blocco, Drop è più silenzioso; Reject è spesso più comodo durante il troubleshooting.

Log firewall traffic

Log firewall traffic dovrebbe essere attivato su quasi tutte le regole importanti.

Senza logging, in Log viewer mancano informazioni importanti. Molti casi di troubleshooting falliscono non per la regola stessa, ma perché il logging non era attivo e non si vede quale regola ha realmente corrisposto.

Importante: la firewall registra normalmente le sessioni quando una connessione termina e viene generato un evento Destroy. Non ogni connessione appare esattamente nel momento in cui il client la avvia.

Affinché i log siano visibili localmente, in Sophos Central o via syslog, anche System services > Log settings deve essere configurato correttamente. Per una conservazione più lunga sono utili Sophos Central Firewall Reporting o un server syslog. Maggiori informazioni: Attivare Central Firewall Reporting.

Source

La sezione Source definisce da dove arriva il traffico.

Source zones

Source zones è la zona da cui proviene il traffico.

Esempi:

• LAN per reti client interne
• VPN per utenti Remote Access
• DMZ per reti server
• Guest per Wi-Fi guest
• WAN per traffico Internet in ingresso

Esempio pratico: per una regola Internet dai client verso Internet si seleziona LAN. Per una regola DNAT dall’esterno verso un server interno, la Firewall Rule associata usa normalmente WAN come Source zone.

Source networks and devices

Source networks and devices restringe la sorgente.

Oggetti possibili:

• host singoli
• reti
• IP ranges
• gruppi host
• FQDN Hosts
• oggetti paese

All’inizio Any sembra comodo, ma spesso è troppo ampio. Meglio una rete client concreta, un gruppo host o un oggetto rete con nome chiaro.

Esempio pratico: invece di Any come Source si usa net_LAN_Clients. Server, stampanti, guest e dispositivi di management ricevono regole proprie.

During scheduled time

During scheduled time definisce quando la regola è valida.

Valori tipici:

• All the time
• orari di lavoro
• finestre di manutenzione
• accessi temporanei

Gli schedule sono utili quando un accesso deve essere consentito solo in determinati orari. Durante il troubleshooting bisogna sempre verificare che ora della firewall, fuso orario e schedule corrispondano davvero.

Esempio pratico: l’accesso di manutenzione esterno a un server viene consentito solo durante una finestra definita.

Destination and services

La sezione Destination and services definisce dove può andare il traffico e quali porte o protocolli sono consentiti.

Destination zones

Destination zones è la zona di destinazione.

Esempi:

• WAN per accesso Internet
• DMZ per server in DMZ
• LAN per destinazioni interne
• VPN per utenti remoti o tunnel Site-to-Site

Esempio pratico: per traffico Internet client si usa WAN. Per l’accesso dei client a un server interno si può usare Server o DMZ, se queste zone esistono.

Destination networks

Destination networks restringe la destinazione.

Per regole Internet client, Any è spesso un punto di partenza pratico. Per server, reti di management o accessi VPN, le destinazioni devono essere limitate molto di più.

Esempi:

• Any per accesso Internet generale
• FQDN Host come updates.vendor.com
• oggetto host di un server interno
• oggetto rete di una sede remota via VPN
• oggetto paese per regole Geo-IP

Esempio pratico: un server di backup può accedere solo alle destinazioni cloud backup del produttore, non a Any.

Services

Services sono definizioni di protocolli e porte.

Esempi:

• HTTP per TCP 80
• HTTPS per TCP 443
• DNS per TCP/UDP 53
• NTP per UDP 123
• servizi personalizzati come Synology_5555

I Services devono essere scelti nel modo più restrittivo possibile. Any ha senso solo se devono essere consentiti davvero tutti i protocolli o se si lavora consapevolmente con altri controlli.

Esempio pratico: per normali client web spesso basta un gruppo con HTTP, HTTPS, DNS e NTP. Per l’accesso a un server da Internet si consente solo il servizio effettivamente pubblicato.

Match known users

Con Match known users, l’identità utente diventa parte del matching. La regola non vale più solo per indirizzi IP, ma per utenti o gruppi noti.

È utile quando:

• le Web Policies devono applicarsi per gruppo AD
• il reporting deve essere basato sugli utenti
• gruppi diversi devono avere diritti Internet diversi
• MFA, Captive Portal o SSO sono già configurati correttamente

Insidia: se l’autenticazione non funziona bene, la regola potrebbe non corrispondere. Il traffico cade allora su una regola più generale sotto o viene scartato dalla regola drop-all.

Per i primi test è spesso meglio iniziare senza User Matching e aggiungere i criteri utente in seguito.

Add exclusion

Con Add exclusion si può escludere traffico da una regola. La firewall salta questa regola solo se tutti i criteri di esclusione impostati corrispondono, poi controlla la regola successiva.

Le exclusions possono contenere Source zones, Source networks and devices, Destination zones, Destination networks e Services.

Esempio pratico: una regola Internet client generale usa Web Filtering. Un determinato update server deve però passare tramite una regola propria con Security Features diverse. Quel server può quindi essere escluso dalla regola generale.

Le exclusions sono potenti, ma rendono le regole più difficili da leggere. Se una regola contiene molte eccezioni, una regola specifica separata è spesso più comprensibile.

Create linked NAT rule

Con Create linked NAT rule si può creare una regola Source NAT direttamente dalla Firewall Rule. Questa Linked NAT Rule appare poi nella tabella NAT.

Per chi inizia sembra comodo, ma nella pratica le regole NAT autonome sono quasi sempre più chiare. Se una regola NAT generica copre già correttamente lo stesso traffico, non si dovrebbe creare una Linked NAT Rule aggiuntiva.

Per una normale regola client-verso-Internet basta di solito la regola SNAT predefinita con MASQ, purché sia attiva e coerente con la base regole.

Importante: NAT non consente traffico da solo. NAT traduce indirizzi o porte. Se il traffico è consentito lo decide sempre la Firewall Rule corrispondente.

Maggiori informazioni: Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

Nella sezione Web filtering si configurano Web Policy, malware scan e comportamento del filtro web.

Web policy

Web policy controlla gli accessi web tramite categorie, utenti, gruppi, URL groups e regole.

Esempio pratico: per i client si usa una Web Policy che blocca malware, phishing, adult content e categorie rischiose, ma consente applicazioni business.

Se non è impostata alcuna Web Policy, tramite questa opzione non avviene filtraggio web basato su categorie.

Apply web category-based traffic shaping

Questa opzione applica Traffic Shaping in base alle categorie web. È utile solo se vengono usate regole Traffic Shaping o Web Category Policies corrispondenti.

Esempio pratico: le categorie streaming vengono limitate, mentre le applicazioni business restano prioritarie.

Block QUIC protocol

QUIC usa UDP 80 e UDP 443. Molti browser usano QUIC per servizi Google e altre applicazioni web moderne.

Se Web Filtering o Malware Scan sul traffico web è importante, Block QUIC protocol dovrebbe restare attivo in molti ambienti. I browser tornano normalmente a HTTPS su TCP, che si controlla e ispeziona meglio.

Scan HTTP and decrypted HTTPS

Questa opzione scansiona HTTP e HTTPS già decrittato alla ricerca di malware.

Importante: questa opzione non decritta HTTPS automaticamente. Per ispezionare davvero HTTPS servono SSL/TLS inspection rules adatte sotto Rules and policies > SSL/TLS inspection rules.

Esempio pratico: se TLS Inspection è attiva per LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS può controllare file scaricati nel traffico HTTPS decrittato.

Maggiori informazioni: Introdurre TLS Inspection su Sophos Firewall passo per passo.

Use Zero-day protection

Use Zero-day protection invia download sospetti a Sophos Zero-Day Protection per ulteriore analisi. È utile per regole client e server in cui i download da Internet devono essere controllati.

La funzione richiede una licenza adatta e può causare ritardi a seconda del tipo di file e della policy.

Scan FTP for malware

Questa opzione scansiona il traffico FTP alla ricerca di malware. È rilevante solo se FTP viene effettivamente usato e i servizi corretti sono consentiti nella regola.

Negli ambienti moderni FTP è meno comune, ma esiste ancora con sistemi legacy, controlli macchina o vecchi meccanismi di aggiornamento.

Use web proxy instead of DPI engine

Sophos Firewall può ispezionare traffico web tramite DPI engine o tramite Web Proxy.

Per setup moderni, DPI è di solito la scelta standard migliore, perché traffico HTTP e SSL/TLS può essere elaborato su tutte le porte. Il Web Proxy resta utile quando servono funzioni proxy specifiche, per esempio SafeSearch enforcement, restrizioni YouTube, limitazione Google app domain, Pharming Protection, Web Cache o Parent Proxy.

Se Use web proxy instead of DPI engine non è attivo, la regola lavora in modalità DPI.

Decrypt HTTPS during web proxy filtering

Questa opzione appartiene alla modalità Web Proxy. È rilevante solo se Use web proxy instead of DPI engine è attivo e HTTPS deve essere decrittato in modalità proxy.

In modalità DPI, la decryption HTTPS non viene controllata qui, ma tramite SSL/TLS inspection rules.

Synchronized Security Heartbeat

Con Configure Synchronized Security Heartbeat lo stato Sophos Endpoint può essere incluso nella Firewall Rule.

Opzioni tipiche:

• definire uno stato minimo per dispositivi sorgente
• bloccare client senza Heartbeat
• definire uno stato minimo per dispositivi destinazione
• bloccare richieste verso destinazioni senza Heartbeat

È potente, ma utile solo se Sophos Endpoint, Sophos Central e Security Heartbeat sono configurati correttamente.

Esempio pratico: client con Security Heartbeat rosso non possono più accedere ai server o a Internet.

Per una prima regola client non si dovrebbe attivare Heartbeat alla cieca, altrimenti si rischia di bloccare dispositivi che non possono inviare Heartbeat.

Other security features

Identify and control applications (App control)

Con Identify and control applications (App control) si seleziona una Application Filter Policy.

Si possono riconoscere e controllare applicazioni come:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control richiede una licenza adatta. Nella pratica questa funzione è inclusa nei Sophos Firewall Bundles con Web Protection, per esempio Standard Protection, Xstream Protection o Epic Protection.

Per riconoscere applicazioni in traffico cifrato, TLS Inspection è spesso decisiva. Senza decryption, la firewall vede a seconda del servizio solo hostname, SNI, informazioni certificato o IP, ma non il contenuto completo.

Apply application-based traffic shaping policy

Questa opzione applica Traffic Shaping definito nella Application Policy o nell’Application Object.

Esempio pratico: Microsoft Teams deve essere riconosciuto e prioritizzato con una determinata Traffic Shaping Policy. Occorre selezionare la Application Control Policy adatta e applicare la application-based traffic shaping policy.

Se nel campo Shape traffic è già impostata una Traffic Shaping Policy esplicita, deve essere documentato chiaramente quale policy ha priorità e perché.

Detect and prevent exploits (IPS)

In Detect and prevent exploits (IPS) si seleziona una IPS Policy.

IPS controlla il traffico alla ricerca di pattern di attacco ed exploit noti. Per traffico client verso Internet si usa una policy diversa rispetto a traffico server o servizi pubblicati.

Esempi pratici:

• regola client LAN_to_WAN: IPS policy client o LAN-to-WAN
• regola DNAT verso webserver: IPS policy server o webserver
• regola VoIP: testare con cautela, perché profili IPS aggressivi possono disturbare VoIP

IPS non va semplicemente attivato ovunque con la policy più severa. Una IPS Policy troppo ampia o errata può rompere traffico legittimo o generare carico inutile.

Shape traffic

Con Shape traffic si può applicare una Traffic Shaping Policy direttamente alla regola.

È rilevante per:

• VoIP
• videoconferenze
• traffico di backup
• Wi-Fi guest
• linee WAN lente

Esempio pratico: il Wi-Fi guest riceve una limit policy per non sottrarre banda al traffico business.

Maggiori informazioni: Configurare Application Traffic Shaping su Sophos Firewall.

DSCP marking

DSCP marking marca i pacchetti per Quality of Service su dispositivi di rete a valle.

È utile solo se switch, router o dispositivi WAN valutano questi valori DSCP. Sophos Firewall può marcare, ma il resto della rete deve trattare le marcature in modo coerente.

Esempio pratico: il traffico VoIP riceve una marcatura DSCP affinché switch e router WAN lo trattino con priorità.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence usa Sophos NDR Threat Intelligence per una valutazione aggiuntiva del traffico di rete.

Questa opzione è utile solo se l’ambiente usa i componenti Sophos Central e NDR necessari. In molti ambienti non è la prima opzione per una regola base, ma può essere un’aggiunta preziosa in reti monitorate più intensamente.

Scan email content

La sezione Scan email content riguarda i protocolli e-mail.

Opzioni possibili:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Se si attivano protocolli qui, anche le porte standard corrispondenti devono essere presenti nei Services della regola o aggiunte tramite Add ports.

Per normali regole web client, questa sezione spesso non è rilevante. Per mail server o traffico mail client deve essere pianificata consapevolmente.

Esempio pratico: un mail server interno può inviare SMTP verso l’esterno. Si crea una regola server separata, si attiva logging e si verifica l’e-mail scanning in base all’architettura mail.

Controllo dopo il salvataggio

Dopo il salvataggio bisogna testare la regola e non presumere che tutto funzioni correttamente.

Controllare:

1. La regola si trova nella posizione corretta?
2. Log firewall traffic è attivo?
3. La regola corrisponde in Log viewer?
4. Viene mostrata la Firewall Rule ID prevista?
5. Si applica la regola NAT prevista?
6. DNS funziona?
7. Web Filtering, IPS, Application Control e TLS Inspection vengono applicati come previsto?
8. Ci sono drop inattesi o errori SSL/TLS?

Per un controllo pulito: Testare Firewall Rules con Log Viewer, Policy Test e Packet Capture.

Errori tipici

La regola è troppo in basso: una regola più generale sopra corrisponde prima al traffico.

Source è troppo ampia: Any può funzionare, ma rende le regole poco chiare e aumenta la superficie d’attacco.

Destination è troppo ampia: server o reti di management raramente dovrebbero uscire verso Internet con Any.

Services è troppo ampio: Any consente molto più del necessario. Meglio servizi concreti o gruppi di servizi.

Logging non è attivo: nel Log Viewer mancano allora le informazioni più importanti.

HTTPS non viene scansionato: Scan HTTP and decrypted HTTPS è attivo, ma non esiste una SSL/TLS inspection rule adatta o non c’è decryption.

Web Filtering non si applica: nessuna Web Policy impostata, utente errato, Source zone errata o QUIC non bloccato.

User Matching non si applica: autenticazione, AD SSO, Captive Portal o associazione utente non funzionano correttamente.

NAT manca: la Firewall Rule consente il traffico, ma SNAT/MASQ non corrisponde.

Security Feature non adatta al traffico: una IPS Policy errata, un’opzione proxy o un’opzione di scan e-mail può rompere traffico legittimo.