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. Anche Server Access Assistant crea una regola firewall insieme a DNAT, reflexive SNAT e loopback. 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; la guida al DNAT per server pubblicati spiega Server Access Assistant.

⚠️ Prima di creare la regola Drop con registrazione: Non presumere che mantenga il blocco HTTP/HTTPS esistente: la documentazione su Drop, autenticazione, Web Exceptions e pagine di blocco è contraddittoria. Per qualsiasi traffico web, prima della distribuzione in produzione occorre un chiarimento scritto di Sophos per la versione SFOS, il build e il percorso di elaborazione esatti, oppure una verifica isolata ed espressamente autorizzata. Seguire le indicazioni di verifica, annullamento delle modifiche ed escalation in Action e registrazione, più avanti.

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 e non genera una normale voce nel log del traffico firewall. Per rendere visibili questi scarti in Log Viewer, Central Reporting o syslog, si crea in fondo alla base delle regole una regola Drop con ambito ristretto e Log firewall traffic attivato. A tale scopo si selezionano singolarmente le zone Source e Destination effettivamente necessarie anziché la zona Any; in caso contrario, la regola può intercettare anche il traffico interno verso servizi locali. I dettagli sono descritti in Analizzare i pacchetti scartati su Sophos Firewall.

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. Un gruppo non può rimanere vuoto. La guida SFOS 22 richiede di separare una regola con Detach prima di spostarla fuori dal gruppo; in alternativa, si sposta tutto il gruppo. Eliminare l’ultima regola elimina anche il gruppo.

La guida SFOS 23 descrive un altro procedimento: per una ricerca filtrata, fare clic nel campo di ricerca, selezionare un criterio suggerito e completare la ricerca con gli ulteriori suggerimenti. Premere Enter per filtrare la tabella delle regole. Per cercare una regola per nome, inserirlo direttamente nel campo di ricerca e premere Enter; rimuovere i singoli filtri con x. Con Show/Hide columns si selezionano le colonne visibili, si modifica il loro ordine facendo clic e trascinando e si bloccano fino a tre colonne affinché siano sempre visualizzate per prime. Attivare o disattivare tramite Status oppure in blocco con Turn on / Turn off; una selezione mista di regole attive e disattivate impedisce questa azione in blocco. Le regole disattivate appaiono attenuate con il nome barrato. Trascinare una regola almeno una posizione fuori dal gruppo la rimuove dal gruppo; inserirla tra due regole di un altro gruppo la aggiunge a quest’ultimo. View menu offre Clone rule above/below, Add rule above/below, Move To ed Edit group. Passare il puntatore su Features permette di distinguere tipo User/Network e azione della regola dalle azioni delle policy e dalle soglie Heartbeat. Nella tabella SFOS 23, User significa Match known users selezionato e Network non selezionato; le icone delle policy distinguono None, Accept, Drop e Reject, quelle Heartbeat Green, Yellow e No restriction. La presentazione non dimostra modifiche al motore del traffico.

Per nuove installazioni, le guide SFOS 22/23 elencano una regola LAN-to-WAN e la regola MTA con Linked NAT creata automaticamente all’attivazione di MTA, indicato come attivo per default. Verificare comunque la propria installazione. La regola implicita #0 non può essere modificata, eliminata o spostata ed è esclusa dai filtri. Ripristinare Sophos Firewall spiega lo stato diverso dopo un Factory Reset in SFOS 22.

Action e registrazione

Action definisce come viene gestito il traffico corrispondente:

• Accept: consente la connessione.
• Drop: è documentato come scarto senza notifica per il traffico non web. Il comportamento HTTP/HTTPS non è garantito in modo universale a causa del conflitto documentale descritto di seguito.
• 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.

⚠️ Conflitto documentale irrisolto sul traffico web: La guida al modulo delle regole SFOS 22/23 descrive per Drop l’accettazione e l’esame di HTTP/HTTPS, l’autenticazione degli utenti sconosciuti con Use web authentication for unknown users attivo, l’autorizzazione delle richieste consentite da una Web Exception corrispondente e una pagina di blocco HTML per le altre richieste. La guida alla registrazione del traffico scartato descrive invece lo scarto silenzioso in generale e collega la pagina di blocco web a tale opzione di autenticazione. Queste descrizioni contraddittorie non sono risolte qui come comportamento verificato di uno specifico build SFOS. Non dimostrano lo scarto silenzioso di tutte le connessioni web, una pagina di blocco dipendente solo dall’opzione di autenticazione o il blocco generalizzato di tutti i servizi.

Se occorre un blocco garantito o una risposta specifica, ottenere un chiarimento scritto di Sophos per la versione SFOS, il build e il percorso di elaborazione esatti, oppure verificare in un ambiente di test isolato ed espressamente autorizzato. Testare separatamente traffico non web, HTTP e HTTPS; per il traffico web includere utenti noti/sconosciuti, autenticazione attiva/disattiva e presenza/assenza di una Web Exception corrispondente. Usare solo client, destinazioni e servizi di test definiti, attivare Log firewall traffic e generare nuove connessioni. Documentare build, posizione della regola, Firewall Rule ID, utente, Action, impostazioni web/TLS e risultati di log, Packet Capture e browser. Un timeout, una pagina di blocco o Policy Tester da soli non dimostrano il blocco previsto. In caso di accesso inatteso o risultato incerto, non distribuire in produzione; annullare le modifiche di test e inoltrare le evidenze a Sophos Support. Reject fornisce la risposta di protocollo descritta sopra; qui non è consigliato come sostituto non verificato del controllo web.

Log firewall traffic deve essere attivo nelle regole importanti. I log vengono salvati per default sulla firewall; verificare le impostazioni locali e le destinazioni Syslog in System services > Log settings. L’invio al servizio cloud richiede inoltre di attivare Sophos Central services nella pagina Sophos Central. La guida SFOS 22 chiama la destinazione Sophos Fusion (in precedenza Sophos Central), quella SFOS 23 Sophos Central; il nome non sostituisce questo requisito separato. 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

Scollegare una Linked NAT Rule nella tabella NAT la rende modificabile e ne determina la valutazione in base ai propri criteri, indipendentemente dalla regola firewall originale. Documentare scope e ordine NAT prima dell’operazione, poi verificare un nuovo flusso di test; non è una semplice rinomina.

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.

In molte installazioni è già presente una regola Default SNAT con MASQ. Ciò dipende tuttavia dallo stato della configurazione e della migrazione e deve essere verificato nella specifica tabella delle regole NAT. Prima di aggiungere una Linked NAT Rule, è necessario controllare se una regola esistente 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 Fusion 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 Fusion > 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.

Per entrambe le soglie, Green ammette solo Green; Yellow, Green o Yellow; No restriction ammette anche Red e dispositivi senza Heartbeat. Verificare anche le opzioni separate di blocco senza Heartbeat. La guida agli Heartbeat mancanti distingue tra perso e mai inviato; Synchronized User ID tratta la disconnessione dopo la perdita o sospensione/riattivazione e la verifica di un nuovo accesso.

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.

La scansione di malware e contenuti utilizza Web > General settings. Per selezionare il filtraggio web proxy occorre prima una Web Policy o Scan HTTP and decrypted HTTPS. Una Application Filter Policy per Micro Apps basate su URL resta applicata nel percorso DPI con decrittografia anche con Web policy None, malware scanning e ATP disattivati. Ciò non elimina le condizioni specifiche delle Web Exceptions in DPI. Le guide dettagliate trattano proxy su bridge senza IP e decrittografia HTTPS con Direct Web Proxy.

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. La guida attuale relativa al modulo della regola non descrive la priorità tra una Application Policy e una Rules Policy. Per un design comprensibile si deve utilizzare una sola variante per caso d’uso e testare ogni combinazione necessaria sul build SFOS in uso. Con Match known users attivato, si applica invece la Traffic Shaping Policy dell’utente; se l’utente non dispone di una policy, si applica quella del suo gruppo.

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 solo i pacchetti IPv4 e IPv6 in uscita che corrispondono a questa regola. Sovrascrive un’eventuale marcatura DSCP già presente sul traffico in ingresso. I pacchetti di risposta e il traffico generato dal sistema non vengono contrassegnati dalla regola firewall. La marcatura da sola non assegna priorità né classifica il traffico; tutti gli switch, i router e i dispositivi WAN coinvolti devono gestire in modo coerente i valori DSCP selezionati.

Un test QoS circoscritto usa un client definito, una destinazione di test autorizzata e ICMP con AF31 = 26. Confermare il match della regola, poi controllare la marcatura con Packet Capture all’uscita WAN e la risposta separatamente. CS0 = 0 è la risposta nell’esempio documentato, non una garanzia sulla marcatura di qualsiasi destinazione. Non creare una concessione ampia con Any; rimuovere poi la regola di test. Testare una regola Sophos Firewall spiega la cattura.

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 XGS Appliances e deployment virtuali, software e cloud comuni, ma non XGS 87, 87w, 88 e 88w. XDR o MDR e il trasferimento a Sophos Fusion sono opzionali per un’analisi avanzata.

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.

Per un server SMTP esistente pubblicato tramite DNAT, Configurare Mail Protection in Legacy mode collega le regole in entrata e in uscita con NAT, policy di scansione, TLS e log del proxy Legacy.

Per il recupero della posta, la casella da sola non basta: attendibilità della CA, limiti globali di scansione, policy POP-IMAP opzionale e corrispondenza effettiva della regola devono combaciare. Analizzare e testare POP3 e IMAP su Sophos Firewall fornisce la procedura completa di pilota e verifica.

Testare e gestire la regola

Collaudo dopo il salvataggio

Dopo la configurazione, la regola viene salvata con Save. È 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.

Policy Tester simula la selezione della regola, ma non genera un flusso di pacchetti reale e non conferma né il routing né il percorso di ritorno. Per Policy Test, Log Viewer e Packet Capture è quindi disponibile la procedura completa 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.

Annullare una modifica a una regola

Prima di una modifica, si annotano la posizione attuale e tutti i campi interessati oppure si esporta uno stato di configurazione tracciabile. Una regola esistente non deve essere adattata a uno scopo diverso: una nuova regola, inizialmente disattivata, offre un percorso di ripristino più chiaro e lascia invariata l’autorizzazione esistente.

Se il collaudo non riesce, si disattiva la nuova regola oppure, nel caso di una regola modificata, si ripristinano i valori precedenti e la posizione originaria. Si generano quindi nuovamente sia il flusso di test consentito sia un flusso di test volutamente non consentito e si verifica nel Log Viewer la Firewall Rule ID prevista. Quando si modifica il percorso di amministrazione, un accesso amministrativo indipendente deve rimanere disponibile per l’intera procedura.

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. Nella guida SFOS 22, Sophos documenta Unused in modo diverso in due punti: la guida alla tabella delle regole indica 24 ore senza traffico corrispondente, mentre il widget Active firewall rules del Control Center indica 12 ore e un controllo giornaliero. Lo stato non è quindi un criterio affidabile per l’eliminazione. New e Changed restano visualizzati per 24 ore dalla creazione o dalla modifica, e una regola può avere più stati contemporaneamente. Nella guida SFOS 23, tabella e widget indicano entrambi 12 ore per Unused. È un confronto documentale, non una misurazione provata su un build dell’appliance.

Active firewall rules mostra il numero di regole attive e il traffico corrispondente in byte delle ultime 24 ore. Distingue WAF (Webserver Protection), User (con utenti o gruppi) e Network (senza questi criteri). Scanned è il totale delle regole nel grafico, non il numero di regole con scansione malware. Disabled significa configurata ma disattivata; può essere contemporaneamente Changed. Passare il puntatore mostra il volume; fare clic su un numero o stato apre la tabella con il filtro corrispondente.

Il widget del Control Center è visibile a tutti gli amministratori, indipendentemente dai relativi diritti. La sua visibilità non dimostra quindi l’accesso in scrittura alla pagina delle regole. Queste 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. Se una regola prevista non compare nella tabella, si reimposta innanzitutto il filtro attivo; la guida SFOS 22 limita inoltre le azioni di gruppo nella vista filtrata.

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 Sophos Fusion, 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.