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

Prima di selezionare Add firewall rule, nella pagina delle regole si sceglie esplicitamente IPv4 o IPv6. Gli esempi seguenti non costituiscono un’autorizzazione comune per entrambe le famiglie di protocolli.

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 positivi di una regola corrispondono e nessuna esclusione applicabile ne determina il salto, 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 per il traffico che corrisponde alla regola generica e non ne è escluso.

Una regola può basarsi, tra l’altro, su Source zone, Source network, pianificazione, Destination zone, Destination network, Service e utente. Tutti i criteri positivi configurati devono corrispondere alla connessione. Le Exclusions non sono criteri positivi: se tutti i criteri configurati di un’esclusione corrispondono insieme, SFOS ignora la regola e prosegue con la valutazione delle regole successive.

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.

Per una regola di registrazione approvata, nel corretto insieme di regole IPv4/IPv6 selezionare Add firewall rule > New firewall rule, un nome univoco, Rule position Bottom, Action Drop e Log firewall traffic. Selezionare singolarmente Source zones e Destination zones; impostare Source networks and devices, Destination networks e Services sull’ambito approvato, quindi selezionare Save. Prima dell’operazione, annotare l’ordine esistente e la configurazione di registrazione. Le nuove connessioni di prova consentite e quelle intenzionalmente non consentite devono corrispondere ai Rule ID previsti, senza compromettere i servizi locali. In caso di discrepanze, disattivare la nuova regola e ripristinare lo stato precedente. Il chiarimento sul traffico web nella sezione Action e registrazione rimane un prerequisito, non una verifica completata mediante questi passaggi.

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.

Nella tabella di SFOS-22, mostrare o nascondere i filtri con Enable filter / Disable filter, scegliere campo e valore in Add filter e reimpostarli con Reset filter. Quando è applicato un filtro, è possibile selezionare singole regole, ma non gruppi di regole. È possibile attivare o disattivare regole o gruppi con Enable / Disable; una selezione mista di regole attive e inattive impedisce questa azione. More options offre funzioni di modifica, clonazione, aggiunta, eliminazione, Detach, Reset data transfer count e azioni sui gruppi. Per una regola non ancora assegnata a un gruppo, selezionare Add to group > New group, assegnare il nome del gruppo e definire il tipo di regola e le zone Source/Destination; in alternativa, selezionare un gruppo esistente. È possibile modificare o eliminare i gruppi. La colonna # mostra la posizione; trascinare la regola o il gruppo con il Rule handle, oppure inserire la posizione di destinazione in Move To e confermare con Enter. Prima di ogni spostamento, annotare lo stato precedente e verificare successivamente che i nuovi flussi di prova corrispondano al Rule ID previsto. Un clone non costituisce automaticamente un’autorizzazione sicura: verificarne criteri, stato e posizione prima dell’attivazione.

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.

Le icone sono indicazioni di configurazione, non risultati di test: in SFOS 23 si verifica in Features, in SFOS 22 in Feature and service, se la scansione Web/FTP/Mail e Traffic Logging sono attivati o disattivati, se è selezionato il filtraggio tramite proxy e se sono assegnate delle policy. Un proxy attivato riguarda 80/443; le altre porte HTTP/TLS restano gestite da DPI. Web policy, App control, IPS e Shape traffic possono ciascuno mostrare None; le icone IPS e Shaping indicano una policy assegnata, mentre le icone Web e App ne indicano anche l’azione. Per Heartbeat occorre distinguere lo stato minimo Green o Yellow da No restriction e verificare separatamente lo stato di Block clients with no heartbeat. No restriction da solo non dimostra che questo ulteriore interruttore sia disattivato. Anche le Exclusions attivate devono essere considerate nella verifica della corrispondenza.

Per le nuove installazioni, le guide di SFOS-22/23 indicano una regola LAN-to-WAN e la regola MTA con Linked NAT generata automaticamente quando la modalità MTA è attiva; in questo contesto, MTA è attivo per impostazione predefinita. Ciò non sostituisce la verifica della propria installazione. La regola implicita #0 non può essere modificata, eliminata o spostata e rimane esclusa dai filtri. Occorre distinguere questo caso da un Factory Reset: entrambe le guide descrivono la rimozione di tutte le regole firewall, dopo la quale rimane solo la regola Auto added firewall policy for MTA. Da ciò non si deve dedurre che l’autorizzazione LAN-to-WAN venga ripristinata automaticamente. Un reset non è una procedura per fare pulizia di singole regole; backup, accesso amministrativo indipendente e piano di ripristino rientrano nella procedura separata Ripristinare Sophos Firewall.

La panoramica di avvio Access rules and policies per SFOS 22/23 descrive inoltre gruppi di regole creati per impostazione predefinita con una regola firewall per scartare il traffico verso WAN, DMZ e le zone interne (LAN, Wi-Fi, VPN e DMZ). Si tratta di regole firewall visibili e raggruppate, non della regola implicita #0. Tuttavia, questa panoramica e le impostazioni predefinite dettagliate per l’installazione e il reset menzionate sopra non attestano un insieme iniziale di regole uniforme per tutte le installazioni. Verificare quindi, sulla propria versione, build e installazione specifica di SFOS, in Rules and policies > Firewall rules, quali regole e gruppi siano effettivamente presenti e attivi, quali zone di origine/destinazione e altri criteri di corrispondenza utilizzino e in quale posizione si trovino. La sola presenza di un gruppo non dimostra l’isolamento: un’autorizzazione precedente corrispondente può già consentire il traffico. Verificare la separazione desiderata delle zone mediante nuove connessioni di test espressamente autorizzate e i Rule IDs previsti; per il traffico web resta valido il conflitto nella documentazione relativo a Drop descritto sopra. Non dedurre dalla panoramica di avvio nomi di gruppi garantiti, condizioni di creazione o un effetto di blocco generale.

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: rifiuta la connessione e, per TCP, invia un reset TCP; per UDP e ICMP, la guida indica espressamente un messaggio ICMP di porta non raggiungibile inviato alla sorgente.
• 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.

Selezionando Protect with web server protection, viene visualizzato Preconfigured template. None significa che i dettagli WAF devono essere definiti manualmente. I modelli documentati sono Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 e Microsoft Sharepoint 2010 and 2013. Questi nomi storici non indicano il supporto o la sicurezza attuali delle rispettive versioni server. Prima dell’uso, il modello deve essere adatto al servizio effettivamente in esercizio; la successiva configurazione WAF e la relativa verifica di accettazione rimangono necessarie.

⚠️ 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. Il comportamento della build specifica resta da chiarire a causa di queste descrizioni contraddittorie. 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 sul 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.

Regola basata su MAC: chiarire i limiti prima del tentativo di blocco

Un host MAC può consentire un’ulteriore associazione del dispositivo per i client direttamente visibili, ad esempio quando cambia il loro indirizzo DHCP. Un indirizzo MAC non è tuttavia un’identità forte: può essere modificato o imitato. La guida originale definisce il MAC-Filtering più sicuro e mostra Block_MAC per IPv4 da LAN a WAN con Drop, registrazione, posizione Top, gruppo None, pianificazione All the time, destinazione e Services Any. In questo contesto, tale combinazione non garantisce un blocco completo di Internet: il conflitto HTTP/HTTPS/Web Exceptions documentato sopra rimane irrisolto.

Nella guida, il filtraggio Internet basato su MAC è limitato ai dispositivi collegati direttamente al firewall. Se nel percorso è presente un router, un altro firewall o uno switch Layer 3, il MAC originale del client non è automaticamente visibile. La guida indica a questo scopo il MAC binding per gli utenti locali; senza chiarire l’associazione dell’identità e il percorso effettivo dei pacchetti, ciò non garantisce il MAC-Filtering su percorsi instradati e non sostituisce l’autenticazione. Prima di un tentativo, il MAC visibile all’ingresso del firewall deve appartenere effettivamente al client di prova.

Per un progetto pilota isolato ed esplicitamente approvato, viene bloccato solo un nuovo flusso TCP IPv4 non web verso un server di prova WAN controllato:

1. Confrontare il MAC del client di prova con quello visibile all’ingresso del firewall. In Hosts and services > MAC host > Add, inserire il nome MAC_Host, Type MAC address e il MAC effettivamente verificato, quindi selezionare Save. 37:97:0E:AB:56:46 è il valore di esempio della guida riportato senza modifiche e non deve essere adottato alla cieca.
2. In Rules and policies > Firewall rules, selezionare IPv4 e Add firewall rule > New firewall rule. Per Block_MAC, impostare Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time e Destination zones WAN. Limitare la destinazione al server di prova controllato e Services al servizio TCP non web approvato per la prova, anziché adottare i valori originali Any. Prima dell’operazione, annotare l’ordine e lo stato della configurazione, quindi selezionare Save.
3. Generare un nuovo flusso di prova, ad esempio un flusso TCP iPerf3 approvato, e verificare Block_MAC insieme al Rule ID nel Log Viewer, nonché il flusso di pacchetti scartato. Un altro client di controllo, non bloccato, deve continuare a raggiungere la destinazione di prova. Un timeout da solo non è sufficiente.
4. Dopo il progetto pilota, disattivare o rimuovere la regola di prova, ripristinare l’ordine precedente e dimostrare, tramite il Rule ID previsto, che un nuovo flusso di prova dal client originale è consentito. Rimuovere l’host MAC di prova solo se non è necessario per altre configurazioni.

In assenza di corrispondenza, verificare la visibilità del MAC, la selezione IPv4, Source, Schedule e l’ordine, senza estendere la regola a tutti i dispositivi. In caso di accesso inatteso o di mancata connettività del client di controllo, annullare il tentativo e chiarire le evidenze indicando la versione e il build esatti. HTTP, HTTPS, Web Exceptions, altre zone/destinazioni/servizi e IPv6 non sono coperti da questo progetto pilota. Un blocco completo di Internet basato su MAC può essere garantito solo dopo aver chiarito e verificato separatamente questi casi.

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.

In questo contesto, sconosciuto significa che l’utente ha effettuato l’accesso al dispositivo finale, ma non si è ancora autenticato sul firewall. Configurare AD SSO con Kerberos/NTLM o Captive Portal in Authentication > Web authentication, e l’accesso dalle zone necessarie in Administration > Device access. Per impostazione predefinita, il traffico corrispondente viene conteggiato nel consumo di dati individuale. Exclude this user activity from data accounting lo esclude dal conteggio, ad esempio se per questi utenti non deve essere applicato alcun limite di dati; non costituisce né un’autorizzazione aggiuntiva né un’autenticazione.

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.

L’esempio documentato basato sui paesi consente HTTPS dai paesi africani verso 172.16.16.0 e utilizza una Exclusion con solo Source zone WAN e un oggetto paese selezionato come Source network. La regola viene ignorata solo se entrambi i criteri corrispondono; il traffico può essere consentito da una regola successiva oppure arrivare a #0. L’indirizzo è un esempio riportato senza modifiche, non una definizione completa di rete con prefisso. Per una propria prova, scegliere un oggetto di destinazione effettivamente esistente, documentare l’ordine delle regole e verificare, tramite i Rule ID, un flusso di prova escluso e uno non escluso. Una Exclusion non è un blocco globale.

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.

Per il traffico in uscita dei client, è possibile creare insieme l’autorizzazione firewall e il Source NAT:

1. In Rules and policies > Firewall rules, scegliere la famiglia di protocolli e aprire Add firewall rule > New firewall rule. Definire nome e posizione; nell’esempio, utilizzare Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN e Destination networks Any. Network_LAN deve contenere la propria rete client verificata. La guida mostra Services Any; in produzione, selezionare invece solo i servizi approvati.
2. Selezionare Create linked NAT rule, definire nome e posizione della regola NAT e impostare Translated source (SNAT) su MASQ. Salvare prima la Linked NAT Rule con Save, quindi la regola firewall con Save.
3. Verificare la regola firewall nella tabella firewall e la regola SNAT collegata nella tabella NAT tramite Firewall Rule ID e nome. Viene valutata prima la regola firewall, poi il Source NAT. Per Linked NAT, sono modificabili solo la Source tradotta e la Source Translation specifica dell’interfaccia in uscita; gli altri criteri, inclusi utenti/gruppi, provengono dalla regola firewall.

La rappresentazione della sorgente 10.145.16.10/24 è il valore di esempio della guida riportato senza modifiche, non un valore da copiare come indirizzo di rete senza verificarlo. MASQ utilizza l’indirizzo IP dell’interfaccia in uscita effettivamente selezionata. Prima dell’operazione, controllare la route appropriata, l’interfaccia e le regole NAT posizionate più in alto. Un nuovo flusso di prova deve mostrare il Firewall Rule ID, il NAT Rule ID e la Source tradotta previsti. In caso di traduzione errata, verificare l’ordine e l’interfaccia di uscita; in caso di insuccesso, annullare la nuova configurazione firewall e Linked NAT e ripristinare lo stato precedente, incluso l’ordine, senza modificare altre regole NAT necessarie.

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 esegue la scansione del traffico HTTP e HTTPS già decrittografato alla ricerca di malware, ma non attiva la decrittografia. In modalità DPI è necessaria una regola di ispezione SSL/TLS appropriata in Rules and policies > SSL/TLS inspection rules; in modalità proxy web si utilizza Decrypt HTTPS during web proxy filtering. Prima del rollout, verificare il percorso di elaborazione effettivamente utilizzato e che i client considerino attendibile la CA di decrittografia.

Use Zero-day protection richiede Scan HTTP and decrypted HTTPS e invia i file scaricati tramite HTTP/HTTPS a un’analisi aggiuntiva per rilevare minacce sconosciute o non ancora divulgate. La funzione richiede Zero-Day Protection e può causare un ritardo a seconda del tipo di file e della policy; non attiva autonomamente la decrittografia HTTPS.

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.

Anche quando Use web proxy instead of DPI engine è attivo, il motore DPI continua a filtrare HTTP e SSL/TLS su altre porte; l’opzione riguarda il proxy per 80/443, non tutto il traffico. La guida descrive il Web-Proxy-Filtering su un bridge senza indirizzo IP come un caso in cui il traffico viene scartato; non deve quindi essere attivato senza verifica. Decrypt HTTPS during web proxy filtering esegue la decifratura anche nella modalità Direct-Proxy configurata esplicitamente sul client. In modalità DPI, le Web Policies, incluse le Web Exceptions, si applicano solo se è impostata una Web Policy, se la scansione malware/contenuti è attiva oppure se ATP è attivo. Queste condizioni vanno distinte dal riconoscimento delle micro-app basato sugli URL descritto nella sezione Application Control, IPS e Traffic Shaping.

Elaborare solo determinate destinazioni tramite il Web Proxy

Se SafeSearch, le restrizioni YouTube o gli accessi a Google Workspace devono essere limitati a determinati domini, mentre il resto del traffico utilizza la decifratura DPI, creare una regola dedicata posizionata più in alto. Prima dell’operazione, verificare la licenza Web Protection, le impostazioni web globali appropriate, l’attendibilità della CA di decifratura sui client e la Web Policy desiderata. I gruppi FQDN determinano le destinazioni; non configurano direttamente i domini degli account consentiti o le azioni di filtro.

1. In Rules and policies > Firewall rules, scegliere IPv4 o IPv6, aprire Add firewall rule > New firewall rule e impostare nome e posizione. Selezionare Action Accept, la zona di origine effettivamente necessaria e la rete client approvata. La guida originale utilizza qui Any; questa sorgente ampia non è un requisito necessario per la produzione.
2. Impostare Destination zones WAN, Destination networks con i gruppi predefiniti SafeSearch enforcement, YouTube restrictions enforcement e Google app enforcement, nonché Services HTTP, HTTPS. Selezionare solo i gruppi necessari per il caso d’uso desiderato.
3. Attivare Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering. La Web Policy effettiva deve essere adeguata alla restrizione desiderata. Attivare Log firewall traffic per il progetto pilota e salvare con Save.
4. Posizionare la regola sopra le regole DPI. Con nuove connessioni, verificare la restrizione desiderata di SafeSearch/YouTube/account, il Rule ID e i log web/TLS; provare anche un’altra destinazione, che deve continuare a corrispondere alla regola DPI e alla SSL/TLS inspection rule previste.

Se la restrizione non viene applicata, verificare la posizione della regola, l’associazione FQDN, la Web Policy e QUIC; in caso di errori di certificato, verificare l’attendibilità della CA e la configurazione di decifratura. In caso di comportamento inatteso, disattivare la nuova regola proxy oppure ripristinare i valori e la posizione precedenti, quindi verificare nuovamente il percorso DPI originale. Non disattivare indiscriminatamente la protezione TLS o la verifica dei certificati.

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 e con entrambe le funzioni disattivate: scansione antimalware e ATP. 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.

La selezione DSCP deve essere coerente con la progettazione QoS dell’intero percorso: EF indica Expedited Forwarding per ritardi e perdite ridotti nei servizi in tempo reale; AF indica Assured Forwarding con scarto in caso di sovraccarico; CS serve a garantire la compatibilità con IP-Precedence. Si tratta di concetti di classe, non di una qualità del servizio garantita dalla sola marcatura. I valori documentati sono:

L’esempio ICMP originale utilizza 8.8.8.8, Source zone LAN, Destination zone WAN, sorgente e destinazione Any e AF31. Per una propria verifica, sostituire questi elementi con oggetti client e destinazione specifici e approvati; non sono necessari né questo indirizzo pubblico né un’autorizzazione ampia. Prima della prova, annotare il valore DSCP precedente, ripristinarlo dopo la prova e verificarlo con nuovi pacchetti. Se la prioritizzazione prevista non viene applicata, occorre esaminare separatamente la corrispondenza con la regola, la marcatura effettiva in uscita e il trattamento QoS da parte dei dispositivi a valle.

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.

Preparare le regole firewall tramite XML API

Gli oggetti XML FirewallRule e FirewallRuleGroup sono adatti a modifiche tracciabili delle regole e alla gestione dei gruppi. Non sostituiscono né la pianificazione degli accessi né il collaudo con nuove connessioni di test. L’accesso protetto, l’invio di richieste HTTP POST a APIController, le operazioni XML esplicite, la verifica TLS, la conservazione dei segreti e la valutazione dello stato XML anziché del successo HTTP sono spiegati in Proteggere l’accesso alla API XML. Per prima cosa, dall’host previsto per l’automazione deve funzionare una query di lettura innocua con un account dotato di autorizzazioni strettamente limitate.

Mantenere il tipo di regola, la struttura degli elementi padre e l’ordine

Nella documentazione di riferimento SFOS-22/23, Name, Position e PolicyType sono obbligatori per Add/Edit. Name è una stringa UTF-8 di massimo 60 caratteri, senza virgole. All’interno di FirewallRule, PolicyType seleziona con Network il blocco NetworkPolicy oppure con User il blocco UserPolicy. Non mescolare questi rami e non inviarli entrambi senza averli verificati. HTTPBased e HTTPBasedPolicy rientrano nella configurazione WAF, mentre il collegamento all’autenticazione rientra nell’autenticazione WAF. Le azioni dei percorsi WAF non sono una traduzione numerica delle azioni di rete.

IPFamily ammette IPv4 o IPv6; la tabella indica IPv4 come valore predefinito. Status ammette Enable o Disable, ma indica ON come valore predefinito. Per le regole preparate, impostare consapevolmente lo stato su Disable e verificare la famiglia di protocolli salvata, anziché adottare i valori predefiniti della documentazione come valori sicuri per il payload. Secondo la tabella dei parametri, Position ammette Bottom, Top, After o Before; l’esempio riporta questi valori in minuscolo. Confermare quindi la grafia e l’operazione completa in API help del build installato. After/Name e Before/Name identificano la regola esistente usata come riferimento per il posizionamento; la documentazione limita questi tag alle richieste Set. Section distingue tra Central_TOP, Local e Central_Bottom: chiarire la titolarità e il percorso di gestione prima di tentare una scrittura locale, senza aggirare una restrizione centrale mediante una sezione diversa.

Nel blocco della policy selezionato, origine e destinazione restano separate: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network e Services/Service contengono riferimenti ripetibili. Schedule rimanda a una pianificazione esistente. Le tabelle limitano i riferimenti a reti e servizi a 60 caratteri; non documentano un numero massimo complessivo di tutti i criteri. Gli stessi elementi padre possono trovarsi sotto Exclusions, dove indicano eccezioni a questa regola, non autorizzazioni aggiuntive. Prima della scrittura, leggere le zone, gli host, i servizi e le pianificazioni effettivamente presenti e verificare la corrispondenza desiderata, considerando anche le regole successive.

In UserPolicy, MatchIdentity, ShowCaptivePortal e Identity/Member aggiungono il riferimento agli utenti. Per Member sono documentati più riferimenti a utenti/gruppi, ciascuno di massimo 256 caratteri. L’associazione dell’identità e l’autenticazione web devono funzionare separatamente. DataAccounting è descritto solo quando la corrispondenza dell’identità è attiva ed esclude il traffico degli utenti dal conteggio dei dati; non esegue l’autenticazione. Qui l’esempio e la tabella si contraddicono: l’esempio mostra Include/Exclude, la tabella Enable/Disable. Anche WebCategoryBaseQoSPolicy e ApplicationBaseQoSPolicy mostrano nell’esempio Apply/Revoke, mentre la tabella descrive una stringa. Non tradurre automaticamente questi valori né considerarli intercambiabili. Se il valore concreto per l’oggetto e il build rimane da chiarire, interrompere la richiesta di scrittura e chiedere chiarimenti a Sophos.

Action nel ramo Network/User ammette Accept, Drop o Reject; la tabella indica Drop come valore predefinito. Rimane necessaria un’azione esplicita e il conflitto sulla gestione HTTP/HTTPS di Drop spiegato sopra vale anche per le modifiche tramite API. LogTraffic ammette Enable/Disable, con Disable come valore predefinito documentato; scegliere consapevolmente la registrazione per il collaudo. SkipLocalDestined riguarda il traffico verso l’IP dell’appliance e non sostituisce Device Access. I riferimenti alle policy, come WebFilter, ApplicationControl, IntrusionPrevention e TrafficShapingPolicy, devono essere coerenti con la protezione pianificata in precedenza. Scansione, proxy, decrittografia, Zero-Day e Heartbeat restano controlli distinti, con i prerequisiti spiegati sopra. In particolare, valori predefiniti come OFF, NULL o NoRestriction contraddicono in parte i valori di input indicati; né queste indicazioni né gli elementi vuoti degli esempi dimostrano gli effetti dell’omissione, dello svuotamento o dell’aggiornamento nel build specifico.

Quando si trasferiscono opzioni di protezione esistenti, occorre verificare il dominio dei valori di ciascun campo: ProxyMode indica, oltre a Enable/Disable, anche true/false; NDRActiveThreatIntelligence indica solo true/false. Le soglie MinimumSourceHBPermitted e MinimumDestinationHBPermitted ammettono GREEN, YELLOW e No Restriction, mentre la colonna dei valori predefiniti riporta NoRestriction. Questi valori di input sono distinti da quelli delle opzioni separate di attivazione e disattivazione di Heartbeat e non costituiscono una traduzione automatica delle etichette della GUI. I selettori relativi agli utenti WebFilterInternetScheme e ApplicationControlInternetScheme indicano Enable/Disable, ma un valore predefinito di 0; non vanno confusi con un nome di policy. I commenti XML vincolano WebCategoryBaseQoSPolicy alla selezione di un WebFilter e ApplicationBaseQoSPolicy alla selezione di un Application Filter. Per Traffic Shaping, la tabella riporta TrafficShappingPolicy/TrafficShapingPolicy, mentre l’esempio XML usa TrafficShapingPolicy: non dedurne l’intercambiabilità o l’accettazione di entrambi i tag. DSCPMarking è documentato come stringa; la serializzazione del valore della GUI deve essere compatibile con il build. Confrontare ogni opzione di protezione interessata prima e dopo la modifica; non normalizzare valori di input sconosciuti e non perdere silenziosamente alcuna opzione di protezione.

L’appartenenza a un gruppo non è una decisione di sicurezza

FirewallRuleGroup raggruppa regole esistenti tramite SecurityPolicyList/SecurityPolicy. SourceZones/Zone e DestinationZones/Zone sono elementi padre distinti per l’assegnazione al gruppo, non nuovi criteri di corrispondenza delle singole regole. Il tag Policytype del gruppo, con la t minuscola, è diverso da PolicyType di una regola. I selettori di gruppo documentati sono User/network rule, Network rule, User rule, WAF rule e Any; non dedurre questi valori dal tipo di regola né normalizzarli con grafie diverse.

Il nome del gruppo è obbligatorio, in UTF-8, senza virgole e di massimo 150 caratteri; Description è facoltativo e ammette al massimo 255 caratteri. Per SecurityPolicy, la documentazione indica un massimo di 60 caratteri per nome di regola, nessuna virgola e fino a 200 valori. Si tratta di un limite documentato di appartenenza al gruppo, non di una capacità garantita da test. Per un gruppo Internet Access, leggere prima i nomi delle regole esistenti, selezionare solo i membri approvati e assegnare separatamente origine e destinazione. L’esempio del produttore con due punti e una selezione di tutti i tipi separata da virgole non è un payload eseguibile.

Prima di aggiornare un gruppo, salvare l’appartenenza, le posizioni e lo stato delle regole. Successivamente, verificare nuovamente le stesse regole in WebAdmin e mediante una query di lettura autorizzata. La descrizione «Add/Remove» di SecurityPolicy non definisce una modifica incrementale sicura dell’elenco né una semantica di sostituzione. Se la gestione degli elenchi omessi o vuoti non è chiara, non eseguire scritture. Secondo la guida della GUI, un gruppo non può esistere vuoto; la rimozione dell’ultima regola può rimuovere anche il gruppo. Il raggruppamento migliora la visibilità, ma non crea isolamento né precedenza: restano determinanti i criteri di corrispondenza e l’ordine effettivo di ogni regola.

Distinguere le risposte in base all’operazione e rileggere lo stato

Le associazioni seguenti sono riportate in modo concorde nella documentazione di riferimento SFOS 22/23. Gli identificatori Message.* restano simboli della documentazione non risolti, non messaggi garantiti in fase di esecuzione, traduzioni o cause univoche. Lo stesso codice può indicare qualcosa di diverso a seconda dell’operazione. In particolare, si tratta di codici di stato XML, non di codici di stato HTTP.

Per la creazione e la modifica delle regole Network/User sono rilevanti queste differenze:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: verificare il vecchio e il nuovo nome, i riferimenti e il tipo di regola salvato, senza presumere semplicemente un successo completo.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: confrontare la regola esistente e quella desiderata sulla base dello stato letto, senza sovrascrivere automaticamente.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. Non dedurne una causa di errore comune o un limite numerico di utenti.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: verificare insieme le zone di destinazione e la configurazione di Destination Heartbeat.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: confrontare il nome esistente e il tipo di regola, senza tentare di aggirare il problema con rinomine o cambi di tipo non verificati.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: chiarire la responsabilità di gestione e il percorso di modifica autorizzato.

Le risposte specifiche WAF elencate insieme alle altre rientrano nella guida WAF; non applicare i relativi conflitti di porte, redirect e Protected Server alle regole Network/User.

Anche per i gruppi occorre annotare l’operazione: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. La documentazione di Edit utilizza effettivamente gli stessi simboli di Add. Prima di un nuovo tentativo, leggere il nome del gruppo salvato, l’appartenenza e i due elenchi di zone; non dedurre dai nomi dei simboli che Edit esegua un’operazione di creazione.

Per l’eliminazione valgono Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. La tabella Delete contrassegna Name come facoltativo e lo descrive, in modo contraddittorio, come riferimento per Before/After. Non dedurne la possibilità di un’eliminazione indiscriminata senza nome. Prima di Remove, verificare la destinazione esatta dell’operazione, le dipendenze, l’appartenenza ai gruppi, Linked NAT, la responsabilità di gestione e il payload confermato in API help. Per le vecchie regole poco chiare, la disattivazione controllata con una finestra di osservazione rimane il primo passo più sicuro.

Dopo ogni risposta, e anche dopo un timeout o un’interruzione della connessione, prima di riprovare leggere innanzitutto lo stato effettivamente salvato: nome, tipo, stato, famiglia di protocolli, posizione, criteri, Exclusions, riferimenti di protezione e appartenenza ai gruppi devono corrispondere allo stato desiderato approvato. Per Remove, verificare inoltre che manchi esattamente la regola prevista e che le regole necessarie e NAT rimangano invariati. Un esito sconosciuto può già aver comportato una modifica. Non ripetere alla cieca, non eseguire Upsert automatici né ampliare l’ambito a Any; in caso di discrepanze, interrompere, conservare la risposta depurata dai dati sensibili e l’Audit Trail e utilizzare il percorso di ripristino confermato. Solo successivamente eseguire i nuovi flussi di test consentiti e intenzionalmente non consentiti descritti di seguito.

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.

Gli intervalli temporali possono sovrapporsi: una regola creata alle 10:00 rimane New fino alle 10:00 del giorno successivo. Una modifica alle 11:00 determina lo stato Changed fino alle 11:00 del giorno successivo; tra le 11:00 e le successive 10:00, la regola presenta entrambi gli stati. Uno stato Unused rilevato durante la verifica giornaliera delle 12:00 permane fino alla verifica successiva. Se la regola viene disattivata alle 13:00, può presentare contemporaneamente gli stati Changed e Disabled fino alle 13:00 del giorno successivo, dopodiché solo Disabled. Questi esempi della documentazione non sostituiscono né la verifica dell’utilizzo effettivo né una decisione di eliminazione. Prima di Reset data transfer count, documentare il valore corrente: la reimpostazione non ripristina un valore precedente del contatore e non modifica le autorizzazioni della regola.

Active firewall rules mostra le regole per tipo e stato, nonché il traffico corrispondente in byte nelle ultime 24 ore. Il riquadro distingue tra WAF (Webserver Protection), User (con utenti o gruppi) e Network (senza questi criteri). Scanned indica il numero totale di regole nel grafico, non il numero di regole sottoposte a scansione antimalware. Disabled significa configurata ma disattivata; una regola disattivata può anche essere Changed. Passando il puntatore è possibile verificare il volume di dati; facendo clic sul numero o sullo stato si apre la tabella delle regole 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 corretta. 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.