La regola di Sophos Firewall non si applica: verifica delle cause

Quando una regola del firewall non si applica, raramente il firewall è “rotto”. Di solito, una condizione non è soddisfatta, una regola più generale è posizionata sopra, il NAT altera la visione del traffico, il matching utente non è soddisfatto o il logging non è correttamente attivato.

Questa checklist aiuta ad affrontare il problema in modo sistematico, invece di modificare le regole a caso.

Orientamento

Partire da un caso di test chiaro prima di cambiare regole o funzioni di sicurezza.

Quale articolo è adatto?

I problemi con le regole si sovrappongono rapidamente a NAT, routing, VPN, Device Access o funzionalità di sicurezza. Per l’analisi, è importante chiarire prima quale livello è coinvolto:

Comprendere una regola del firewall da zero: Comprendere e configurare correttamente le regole di Sophos Firewall
Testare una singola connessione con Log Viewer, Policy Tester e Packet Capture: Testare una regola del firewall con Log Viewer, Policy Test e Packet Capture
Coinvolgimento di NAT, SNAT, DNAT, MASQ o PAT: Comprendere il NAT su Sophos Firewall
Un server è pubblicato su Internet tramite DNAT: Pubblicare un server tramite DNAT
L’accesso riguarda WebAdmin, VPN Portal, SSH, DNS o SNMP del firewall: Configurare correttamente Device Access
Route, SD-WAN o percorso di ritorno non sono chiari: Adattare la priorità di routing su Sophos Firewall
I pacchetti devono essere verificati direttamente sul firewall: Utilizzare Packet Capture in WebAdmin

Questa distinzione è importante perché una regola del firewall non controlla ogni tipo di accesso. I servizi locali del firewall, le decisioni NAT, il routing e le funzionalità di sicurezza hanno i propri punti di controllo.

Rapida delimitazione

All’inizio, non si dovrebbero spostare immediatamente le regole o modificare gli oggetti. Prima si delimita il punto in cui il traffico si perde.

Il contatore della regola rimane 0: La posizione della regola, la zona, l’origine, la destinazione, il servizio o la pianificazione non sono corretti
Log Viewer mostra un’altra regola: Una regola più generale o generata automaticamente è posizionata più in alto
Log Viewer non mostra nulla: Il logging manca o il traffico non raggiunge il firewall
Packet Capture non vede alcun pacchetto: Il problema è prima del firewall: client, VLAN, switch, gateway, provider o Cloud Security Group
Packet Capture vede pacchetti, ma nessun inoltro: La regola del firewall, NAT, routing o funzionalità di sicurezza bloccano
Packet Capture vede l’inoltro, ma nessuna risposta: Verificare il percorso di ritorno, il sistema di destinazione, NAT o firewall esterno

Questa distinzione fa risparmiare tempo. Se il firewall non vede alcun pacchetto, nessuna modifica a una regola del firewall aiuterà. Se Log Viewer mostra un’altra Rule ID, l’ordine è più importante della regola di destinazione interessata. Se il flusso di pacchetti e la Rule ID sono corretti, l’analisi si sposta su NAT, percorso di ritorno o funzionalità di sicurezza.

Definire chiaramente il caso di test

Una regola può essere verificata in modo sensato solo se il caso di test è chiaro. Affermazioni come “Internet non funziona” o “VPN non funziona” sono troppo ampie. Per la ricerca degli errori è necessario un flusso concreto.

Prima del test, dovrebbe essere chiaro:

IP di origine: Client 10.10.20.35
Zona di origine: LAN, VPN, DMZ o zona personalizzata
Utente: Utente autenticato o nessun matching utente
Destinazione: IP del server, FQDN, IP pubblico o oggetto WAN
Servizio: TCP 443, UDP 53, ICMP, servizio personalizzato
Regola attesa: Nome della regola o Rule ID, se noto
Regola NAT attesa: NAT Rule ID o nome della regola, se NAT è coinvolto
Tempo di test: Ora esatta per Log Viewer e file di log successivi

Dopo, si ripete sempre lo stesso test. Se durante l’analisi cambiano IP di origine, destinazione, risoluzione DNS o porta, non si confronta più lo stesso caso.

Combinare correttamente gli strumenti di analisi

Sophos Firewall offre diversi strumenti che rispondono a domande diverse. Nessuno di questi è da solo una prova completa.

Contatore delle regole: Il nuovo traffico di test colpisce la regola in generale? Non mostra perché un’applicazione fallisce comunque
Log Viewer: Quale Rule ID, NAT Rule ID, Action, User o funzione di sicurezza è stata registrata? Dipende dal logging e dalla fine della sessione
Policy Tester: Quale logica di policy si applicherebbe a un flusso definito? Non sostituisce un vero flusso di pacchetti e non rappresenta completamente SD-WAN
Packet Capture: I pacchetti arrivano, vengono inoltrati o scartati? Non spiega ogni livello applicativo e richiede filtri stretti
Service-Logs: Un modulo come Web, IPS, autenticazione o VPN ha un problema proprio? Utile solo quando il servizio interessato è delimitato

Per una diagnosi affidabile, si combinano almeno Log Viewer e un vero test. In caso di risultati contraddittori, Packet Capture è spesso il passo successivo, poiché mostra se i pacchetti arrivano effettivamente e continuano.

Albero decisionale per il primo test

Per la prima analisi, spesso basta un breve albero decisionale. Evita di lavorare immediatamente su regole, NAT e routing contemporaneamente.

Packet Capture non vede alcun pacchetto: Verificare client, VLAN, switch, gateway, provider, Cloud Security Group o firewall preposto
Packet Capture vede il pacchetto, Log Viewer rimane vuoto: Verificare logging, tipo di log, fine della sessione e filtro BPF appropriato
Log Viewer mostra un’altra Rule ID: Confrontare ordine delle regole, zone, origine, destinazione, servizio e pianificazione
La Rule ID del firewall è corretta, la NAT Rule ID non lo è: Verificare ordine NAT e campi Original
Rule ID e NAT ID sono corretti, ma non arriva risposta: Verificare percorso di ritorno, sistema di destinazione, firewall locale sul server o blocco esterno
La regola si applica solo a determinati utenti: Verificare matching utente, gruppo, autenticazione e utenti senza client

In questo modo, l’analisi rimane controllata: prima si dimostra se il traffico raggiunge il firewall. Poi si verifica quale regola e quale regola NAT si applicano effettivamente. Solo quando questi due punti sono corretti, vale la pena cercare nel percorso di ritorno, nelle funzionalità di sicurezza o nel livello applicativo.

Comprendere il rule matching

Sophos Firewall elabora le regole in ordine. Vince la prima regola adatta.

Primo principio: la prima regola corrispondente vince

Sophos Firewall elabora le regole del firewall dall’alto verso il basso. Non appena una regola si applica, le regole successive non vengono più verificate. Lo stesso principio di base vale anche per le regole NAT.

Importante:

La posizione nell’elenco determina la valutazione.
La Rule ID è solo un riferimento e non dice nulla sull’ordine attuale.
I gruppi di regole aiutano nella visualizzazione, ma non sono una logica di matching propria.
Una regola generale sopra può “inglobare” completamente una regola specifica sotto.

Se una regola non si applica, si verifica prima la posizione.

Regole del firewall di Sophos Firewall con ordine delle regole evidenziato — La posizione nell’elenco delle regole del firewall determina la valutazione. La prima regola corrispondente vince, non la Rule ID più bassa.

Resettare il contatore delle regole

In caso di corrispondenze poco chiare, è utile resettare il contatore delle regole.

Aprire Rules and policies > Firewall rules.
Cercare la regola interessata.
Aprire il menu a tre punti.
Selezionare Reset data transfer count.
Riprodurre nuovamente il traffico.
Controllare il contatore dopo il test.

Menu a tre punti di Sophos Firewall con Reset data transfer count — Con Reset data transfer count si resetta il contatore delle regole. Dopo, è facile vedere se il nuovo traffico di test finisce davvero su questa regola.

Se il contatore non aumenta, la regola non si applica. Se aumenta, ma l’applicazione non funziona comunque, il problema è probabilmente nei profili di sicurezza, NAT, routing, percorso di ritorno o sistema di destinazione.

Verificare i campi di matching

Una regola del firewall si applica solo se tutti i criteri rilevanti sono soddisfatti.

Source zones: Zona errata, VLAN si trova in un’altra zona, traffico VPN proviene da VPN
Source networks and devices: Oggetto errato, IP errato, gruppo host incompleto
Destination zones: Zona di destinazione errata, soprattutto con DNAT o VPN
Destination networks: Confusione tra visione pre-NAT e post-NAT
Services: Porta mancante, confusione tra TCP/UDP, applicazione utilizza porte aggiuntive
Users or groups: Utente non autenticato o gruppo errato
Schedule: Pianificazione non corretta al momento
Exclusions: Il traffico è escluso dalla regola e viene elaborato sotto

Regola del firewall di Sophos Firewall con Source, Destination e services — Una regola del firewall si applica solo se Source zone, Source networks and devices, Destination zones, Destination networks, Services e Schedule sono contemporaneamente corretti.

Per il traffico web, si dovrebbe inoltre verificare se QUIC è attivo. Se i browser inviano traffico su UDP 443, alcune aspettative di filtro web e scansione si applicano diversamente rispetto al classico HTTPS su TCP.

Per ulteriori informazioni: Sophos Firewall e il protocollo QUIC.

Non trascurare DNS, FQDN e IPv6

Una regola può sembrare corretta e comunque non applicarsi se il client raggiunge una destinazione diversa da quella prevista. Questo accade spesso con oggetti FQDN, DNS diviso, servizi CDN, IPv6 o applicazioni che utilizzano più destinazioni in parallelo.

Prima di modificare le regole, si dovrebbe verificare:

Quale IP risolve effettivamente il client?: Cache DNS, DNS diviso o un altro resolver possono fornire un indirizzo diverso da quello previsto.
È IPv4 o IPv6?: Le regole IPv4 non si applicano al traffico IPv6. Se i client preferiscono IPv6, il lato IPv6 deve essere verificato separatamente.
Viene utilizzato un host FQDN nel firewall?: Il firewall deve risolvere l’FQDN e conoscere l’IP di destinazione attuale. I servizi CDN o cloud possono fornire più IP variabili.
L’applicazione utilizza destinazioni aggiuntive?: Login, API, aggiornamenti, telemetria o percorsi multimediali possono utilizzare domini e porte diversi rispetto all’applicazione principale.
Un client interno utilizza il nome pubblico di un servizio interno?: In tal caso, DNS diviso, Loopback NAT o una risoluzione pubblica errata possono essere le cause.

Per la ricerca degli errori, è fondamentale non solo annotare il nome host, ma confrontare l’IP di destinazione effettivamente utilizzato nel Log Viewer o Packet Capture. Se una regola punta a un determinato oggetto FQDN o host, ma il client utilizza un altro IP, la regola non si applicherà.

Per le risoluzioni dei nomi interne, aiutano le route di richiesta DNS pulite. La procedura è descritta in Configurare le route di richiesta DNS su Sophos Firewall. Se IPv6 è attivo nell’ambiente, si dovrebbe inoltre verificare se IPv6 è pianificato consapevolmente e se è presente la policy appropriata. Le basi sono descritte in Configurare la delegazione del prefisso IPv6 su Sophos Firewall.

Il traffico verso il firewall stesso è un caso speciale

Non ogni accesso a un Sophos Firewall è controllato tramite le normali regole del firewall. Se il client deve raggiungere il firewall stesso, ad esempio WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS o SNMP, sono decisivi Device Access e Local service ACL.

Esempi tipici:

WebAdmin da LAN o WAN: Device Access, Local service ACL, MFA, autorizzazione admin
VPN Portal o User Portal: Device Access, configurazione del portale, autorizzazione utente
SSH sul firewall: Device Access, Local service ACL, diritti admin, rete di origine
Connessione SSL VPN o IPsec: Device Access per la zona appropriata, configurazione VPN, autenticazione
DNS al firewall: Device Access, configurazione DNS, percorso della richiesta
SNMP al firewall: Device Access, configurazione SNMP, fonte di monitoraggio

Se una regola del firewall non si applica a tale traffico, spesso non è un errore della regola. Il traffico termina sul firewall ed è trattato come servizio locale. Per la protezione di questi servizi, l’articolo centrale è Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access. Per i portali, si adatta anche Panoramica dei portali Sophos.

Verificare NAT, DNAT e ID

Per il traffico DNAT, regole firewall e regole NAT vanno lette insieme.

Leggere correttamente DNAT

Con DNAT, la visione nelle regole del firewall è particolarmente importante. Come regola generale, si può ricordare:

Le regole del firewall per il traffico DNAT utilizzano la zona di destinazione dopo NAT, ma l’IP di destinazione prima di NAT.

Esempio:

Un client esterno si connette all’IP WAN del firewall.
NAT traduce su un server interno nella DMZ.
La regola del firewall utilizza come zona di destinazione la zona del server interno, ad esempio DMZ.
La rete di destinazione rimane però l’IP pubblico o l’oggetto WAN che il client ha contattato.

Se questa combinazione è errata, la regola NAT potrebbe sembrare corretta, ma la regola del firewall non si applica comunque.

Per ulteriori informazioni: Pubblicare un server tramite DNAT su Sophos Firewall.

Verificare le regole NAT

Il NAT non consente il traffico. Il NAT traduce solo. È sempre necessaria anche una regola del firewall appropriata.

Sotto Rules and policies > NAT rules si dovrebbe verificare:

La regola NAT appropriata è posizionata sopra le regole NAT più generali?
La regola è attiva?
Original source, destination e service sono corretti?
Translated source, destination e service sono corretti?
Viene utilizzato MASQ o un IP SNAT fisso?
Esiste una Linked NAT Rule che si applica inaspettatamente?
Esiste una regola SNAT generica che si applica prima di una regola più specifica?

Sophos consiglia per ambienti semplici di solito regole NAT autonome, invece di generare una Linked NAT Rule per ogni regola del firewall.

Per ulteriori informazioni: Comprendere il NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Leggere insieme Firewall Rule ID e NAT Rule ID

Se è coinvolto il NAT, la domanda “Quale regola del firewall si applica?” non è sufficiente. Una connessione può colpire la Firewall Rule ID prevista, ma comunque passare attraverso una NAT Rule ID errata. Al contrario, una regola NAT può sembrare corretta, mentre una regola del firewall più generale sopra elabora già il traffico.

Per il test, si dovrebbe annotare in anticipo:

Firewall Rule ID prevista: Mostra se la regola del firewall corretta consente o blocca il traffico
NAT Rule ID prevista: Mostra se la regola SNAT, DNAT, MASQ o PAT corretta traduce
ID effettive nel Log Viewer: Dimostra se il firewall elabora il flusso come previsto
ID nel Packet Capture: Aiuta se il Log Viewer sembra incompleto o il percorso di ritorno non è chiaro

L’interpretazione è relativamente semplice, ma fa risparmiare molto tempo di ricerca:

Firewall Rule ID è corretta, NAT Rule ID è errata: Verificare ordine NAT, campi Original e regole NAT più generali
NAT Rule ID è corretta, Firewall Rule ID è errata: Verificare ordine delle regole del firewall, zone, origine, destinazione e servizio
Entrambe le ID sono corrette, ma la connessione fallisce comunque: Verificare percorso di ritorno, server di destinazione, funzionalità di sicurezza o applicazione
Nessuna NAT Rule ID visibile, anche se NAT è previsto: Verificare flusso di test, criteri NAT, direzione e logging nuovamente

È importante non modificare immediatamente entrambi i set di regole contemporaneamente. Prima si decide se il problema è nel matching del firewall o nel matching NAT. Solo dopo si dovrebbe modificare una posizione di regola concreta, un oggetto o un campo. L’analisi NAT più dettagliata è descritta nella sezione Leggere correttamente Firewall Rule ID e NAT Rule ID.

Verificare utenti, routing e funzioni di sicurezza

User Matching, routing, NAT, logging e profili di sicurezza possono influenzare l’applicazione della regola.

Verificare User Matching e autenticazione

Le regole con matching utente o gruppo spesso sembrano corrette, ma si applicano solo se il firewall può effettivamente associare l’utente al traffico in quel momento.

Da verificare:

L’utente è visibile nel Log Viewer?
Il traffico proviene dal dispositivo previsto o da un altro client?
L’utente è nel gruppo firewall corretto?
Funziona AD SSO, STAS, Captive Portal, RADIUS o Entra ID SSO?
Una regola senza User Matching si applica sopra la regola utente pianificata?
Ci sono utenti senza client che vengono trattati diversamente?
MFA o accesso al portale sono riusciti, ma la regola del firewall per il traffico effettivo è errata?

Per l’accesso remoto, si dovrebbe separare il problema utente dal problema VPN. Un utente può accedere con successo, ma comunque non raggiungere un’applicazione interna se pool VPN, regola del firewall, NAT o routing non sono corretti. Per le basi di AD, si adatta Aggiungere Active Directory su Sophos Firewall, per scenari di accesso remoto basati su Entra Microsoft Entra ID SSO per Sophos Connect e VPN Portal. Se l’utente si autentica tramite Captive Portal con Entra ID SSO, si adatta Configurare Microsoft Entra ID SSO per Sophos Firewall Captive Portal.

Un login riuscito al VPN Portal, User Portal, Captive Portal o tramite Microsoft Entra ID SSO non prova ancora che la regola utente pianificata corrisponda effettivamente al traffico. Il login conferma solo l’autenticazione. Successivamente, il firewall deve associare correttamente l’utente, l’IP di origine, il gruppo e il flusso di traffico.

Per l’analisi, si dovrebbe quindi verificare separatamente:

L’utente si autentica, il contatore delle regole rimane 0: Verificare pool VPN, zona di origine, rete di origine, condizione di gruppo o posizione della regola
Il campo utente nel Log Viewer è vuoto: Verificare STAS, Captive Portal, AD SSO, Entra ID SSO o utenti senza client
L’utente è visibile, ma si applica la regola sbagliata: Verificare ordine delle regole, filtro di gruppo o regola più generale sopra
Solo gli utenti VPN sono interessati: Verificare zona VPN, pool VPN, configurazione SSL/IPsec e profilo Sophos Connect
Solo alcuni utenti sono interessati: Confrontare UPN, indirizzo email, gruppo importato e gruppo firewall

Per ambienti AD locali, aiutano STAS e Aggiungere Active Directory su Sophos Firewall. Per setup basati su Entra, si dovrebbe verificare a seconda del percorso di login Microsoft Entra ID SSO per Sophos Connect e VPN Portal o Entra ID SSO per Captive Portal. Se sono coinvolti molti utenti o utenti senza client, può diventare rilevante anche il limite di ID utente di Sophos Firewall.

Verificare routing e SD-WAN

Se la regola si applica, ma la connessione non funziona, il problema potrebbe essere il routing.

Si verifica:

Esiste una route predefinita appropriata?
Esiste una route statica?
Si applica una route SD-WAN?
Il gateway è attivo?
Esistono route di ritorno sul sistema di destinazione o nella rete remota?
Il percorso di ritorno è simmetrico?
Il traffico passa attraverso VPN, MPLS o un’altra interfaccia rispetto a quanto previsto?

Importante: Il Policy Tester non rappresenta completamente il routing SD-WAN. È molto utile per decisioni di policy del firewall, SSL/TLS e web, ma non sostituisce un vero test di flusso di pacchetti.

Per ulteriori informazioni: Adattare la priorità di routing su Sophos Firewall.

Attivare il logging

Senza log, il troubleshooting diventa difficile. Si verificano due punti:

Nella regola del firewall deve essere attivato Log firewall traffic.
Sotto System services > Log settings deve essere attivato il tipo di log appropriato localmente, per Sophos Central o per Syslog.

Il Log Viewer mostra tipicamente le sessioni del firewall quando il firewall termina una connessione e riceve un evento Destroy. Se una connessione Internet si interrompe semplicemente, potrebbe non apparire ogni sessione come ci si aspetta.

Si apre il Log Viewer in alto a destra nella console WebAdmin. Filtri utili sono:

IP di origine
IP di destinazione
Porta o servizio
Rule ID
Nome della regola
Azione
Utente
NAT rule ID

Log Viewer di Sophos Firewall con Firewall rule ID e NAT rule ID — Nel Log Viewer si vede quale Firewall Rule ID e NAT Rule ID hanno elaborato il traffico. È spesso più veloce che cercare solo per nome della regola o indirizzo IP.

Per ulteriori informazioni: Sophos Firewall Troubleshooting: Servizi e Log.

Utilizzare Packet Capture

Se Log Viewer e contatore delle regole non sono sufficienti, si utilizza Diagnostics > Packet capture.

La domanda più importante è se il pacchetto arriva, viene inoltrato o rimane già bloccato sul firewall.

Packet Capture di Sophos Firewall con filtro BPF, NAT ID e Rule ID — Packet Capture mostra se i pacchetti arrivano, attraverso quale interfaccia passano e quale NAT ID o Rule ID è visibile. Il filtro BPF mantiene l’output piccolo e leggibile.

Nessun pacchetto arriva: Il problema è prima del firewall: client, switch, VLAN, gateway, provider, Cloud Security Group
Il pacchetto entra, ma non esce: Verificare regola del firewall, NAT, routing o funzionalità di sicurezza
Il pacchetto esce, ma non arriva risposta: Verificare percorso di ritorno, sistema di destinazione, NAT o blocco esterno
Il pacchetto viene mostrato con Violation: Policy o funzionalità di sicurezza bloccano
Il pacchetto mostra NAT ID e Rule ID: Confrontare miratamente corrispondenze di regole e NAT

Per ulteriori informazioni: Utilizzare lo strumento Packet Capture in WebAdmin.

Non cambiare più cose contemporaneamente

In caso di problemi con le regole, è allettante adattare contemporaneamente posizione, servizio, NAT, Web Policy e routing. Questo a volte risolve temporaneamente l’accesso, ma rende difficile comprendere la causa in seguito.

Meglio è un approccio passo-passo:

Annotare lo stato iniziale: Rule ID, NAT ID, origine, destinazione, servizio, orario.
Eseguire esattamente una modifica.
Ripetere il test con la stessa IP di origine e la stessa destinazione.
Confrontare nuovamente Log Viewer e Packet Capture.
Documentare il risultato.
Solo dopo verificare la prossima modifica.

Per le regole produttive, dovrebbe essere chiaro se una modifica è permanente o solo una regola di test. Le regole temporanee dovrebbero avere un proprietario e una data di scadenza, altrimenti spesso rimangono nel set di regole per anni.

Verificare singolarmente le funzionalità di sicurezza

Se la regola si applica, ma l’applicazione non funziona, un profilo di protezione potrebbe intervenire:

Web Policy
Regola di ispezione SSL/TLS
Profilo di decrittazione
IPS Policy
Application Control
Scansione malware
Protezione zero-day
Security Heartbeat
Traffic Shaping

Per i test, non si può disattivare tutto in modo permanente. Meglio è: verificare brevemente in modo mirato, osservare Log Viewer e poi risolvere correttamente la causa. Per l’ispezione TLS, aiuta l’articolo Distribuire gradualmente l’ispezione TLS su Sophos Firewall.

Per le regole produttive, non si dovrebbero considerare le funzionalità di sicurezza come un blocco unico. Meglio è delimitare un modulo dopo l’altro:

Categoria web o URL bloccato: Verificare Web Policy, categoria, eccezione e Log Viewer
Applicazione riconosciuta erroneamente: Verificare Application Control e log IPS
Pagina HTTPS carica solo senza ispezione: Verificare regola di ispezione SSL/TLS, distribuzione CA, profilo di decrittazione ed eccezioni
Connessione si interrompe con grandi dati: Verificare MTU/MSS, percorso VPN, frammentazione e Packet Capture
Riscontro in IPS o protezione zero-day: Valutare firma, policy, sistema di destinazione e rischio di falso positivo
Solo alcuni utenti sono interessati: Verificare User Matching, Security Heartbeat, gruppo e autenticazione

Se per un test viene rimosso un profilo di protezione, la modifica dovrebbe essere strettamente limitata: solo l’origine interessata, solo la destinazione concreta, solo per il periodo di test. Dopo, si ripristina la protezione originale o si documenta un’eccezione mirata.

Controllare la cronologia delle modifiche

Se una regola funzionava ieri e oggi non funziona più, non bisogna controllare solo il contenuto attuale della regola. Spesso poco prima è stato modificato un oggetto, la posizione di una regola, una regola NAT, un gruppo, un servizio o una policy Central.

Controlli pratici:

La regola firewall è stata modificata?: Audit Trail, Config Studio, descrizione della regola
È stato modificato un oggetto utilizzato?: Hosts and services, Audit Trail, Config Studio
La posizione della regola è stata spostata?: Elenco regole firewall, Audit Trail
È stata trasferita una policy Central?: Sophos Central Task Queue e vista locale della firewall
È stata modificata una regola NAT o una route SD-WAN?: Regole NAT, routing, Audit Trail, Packet Capture

Per la tracciabilità sono utili Controllare gli Audit Trail Logs di Sophos Firewall e Usare Sophos Firewall Config Studio. Se la modifica arriva da Sophos Central, controllare anche la Sophos Central Firewall Management Task Queue.

Procedura pratica e cause tipiche

La maggior parte dei problemi di matching si restringe rapidamente con una sequenza di troubleshooting fissa.

Cause comuni

Il contatore delle regole rimane 0: Posizione della regola, zona di origine, zona di destinazione o servizio errati
Il log mostra un’altra regola: Una regola più generale è posizionata sopra
Nessun log visibile: Logging non attivo o traffico non raggiunge il firewall
DNS funziona, web no: Verificare servizio, Web Policy, ispezione TLS o QUIC
Nome host corretto, ma IP di destinazione diverso: Verificare DNS, oggetto FQDN, DNS diviso, CDN o IPv6
HTTPS non viene scansionato: Nessuna regola di ispezione SSL/TLS appropriata o CA non distribuita
DNAT non funziona: La regola del firewall utilizza zona di destinazione errata o rete di destinazione errata
Traffico VPN non si applica: Verificare zona VPN, route, interfaccia tunnel o contesto XFRM
Solo alcuni utenti sono interessati: Verificare User Matching, gruppo, SSO, Captive Portal o Heartbeat

Procedura pratica

Annotare il problema con IP di origine, destinazione, porta, utente e orario.
Verificare la posizione della regola.
Resettare il contatore delle regole.
Riprodurre il test.
Filtrare Log Viewer con IP di origine e IP di destinazione.
Verificare regola NAT e routing.
Avviare Packet Capture con filtro stretto.
Verificare solo miratamente il profilo di sicurezza.
Documentare la modifica.

Per un flusso di test combinato, vedere Testare una regola del firewall con Log Viewer, Policy Test e Packet Capture.

Checklist per il troubleshooting delle regole

Caso di test concreto definito con origine, destinazione, servizio, utente e orario.
Posizione della regola verificata e contatore delle regole resettato per il test.
Log Viewer mostra la Rule ID attesa o un’altra regola comprensibile.
Risoluzione DNS, IP di destinazione effettivo e versione IP sono stati confrontati con il caso di test.
Con DNAT, zona di destinazione dopo NAT e rete di destinazione prima di NAT sono impostate correttamente.
NAT Rule ID è stata verificata, se NAT è coinvolto.
Il traffico verso il firewall stesso è stato separato dal traffico attraverso il firewall.
User Matching è stato valutato solo se l’utente è visibile nel Log Viewer.
Per le regole utente, login, associazione utente e decisione della regola effettiva sono stati valutati separatamente.
Routing, SD-WAN, gateway e percorso di ritorno sono stati verificati.
Packet Capture mostra Incoming, Forwarded, Violation o risposta mancante in modo comprensibile.
Le funzionalità di sicurezza sono state verificate singolarmente e non disattivate permanentemente in modo generale.
Le modifiche di test sono documentate e le regole temporanee hanno un proprietario e una data di scadenza.

FAQ

Perché una regola di Sophos Firewall non si applica?

Di solito, almeno un criterio di matching non è soddisfatto: posizione della regola, zona di origine, zona di destinazione, oggetto di origine, oggetto di destinazione, servizio, pianificazione, User Matching o contesto NAT. Si dovrebbe prima verificare Log Viewer, Rule ID e Packet Capture.

Perché Log Viewer mostra un'altra regola rispetto a quella prevista?

Probabilmente, una regola più generale è posizionata più in alto o il traffico appare diverso al firewall rispetto a quanto previsto. Posizione della regola, zone, NAT e campi di origine/destinazione sono quindi più importanti del nome della regola.

Perché non si vede alcun log?

O Log firewall traffic non è attivo nella regola, il tipo di log appropriato è disattivato o il traffico non raggiunge il firewall. Packet Capture aiuta a distinguere se il pacchetto arriva effettivamente.

Le regole del firewall si applicano anche a WebAdmin, SSH o VPN Portal?

Non come per il traffico di transito normale. Gli accessi ai servizi locali del firewall sono controllati tramite Device Access e Local Service ACL. Le regole del firewall normali sono responsabili del traffico attraverso il firewall.

Perché DNAT non funziona, anche se la regola NAT è corretta?

Spesso, la regola del firewall appropriata è costruita in modo errato. Con DNAT, la regola del firewall utilizza la zona di destinazione dopo NAT, ma la rete di destinazione prima di NAT. Inoltre, devono essere corretti ordine NAT, logging e percorso di ritorno.

Il Policy Tester è una prova per il traffico reale?

No. Il Policy Tester è utile per la logica delle policy, ma non è un vero test di flusso di pacchetti. Routing, SD-WAN, percorso di ritorno, comportamento del provider e sistemi di destinazione devono essere verificati con Log Viewer e Packet Capture.

Perché una regola utente non si applica, anche se il login VPN funziona?

Il login VPN dimostra solo che l’autenticazione funziona. Per la regola del firewall, devono essere corretti anche zona di origine, pool VPN, associazione utente, gruppo, servizio, destinazione e posizione della regola. Nel Log Viewer si dovrebbe verificare se l’utente è effettivamente visibile nel traffico interessato e quale Rule ID elabora il flusso.

Perché una regola con destinazione FQDN non si applica?

Spesso, il client utilizza un IP di destinazione diverso da quello previsto. Le cause sono cache DNS, DNS diviso, indirizzi CDN, un altro resolver o IPv6. Nel Log Viewer o Packet Capture si dovrebbe confrontare l’IP di destinazione effettivamente utilizzato con l’oggetto FQDN o host della regola.