Testare correttamente una regola Sophos Firewall

Una regola del firewall non dovrebbe essere solo salvata, ma testata in modo mirato. Soprattutto con Webfilter, TLS Inspection, NAT, IPS o User Matching, una regola può sembrare corretta visivamente ma non funzionare come previsto.

Per il test sono utili diversi strumenti:

• Log viewer per eventi reali e decisioni sulle regole
• Policy tester per la logica delle policy Web, Firewall e SSL/TLS
• Packet capture per il flusso effettivo dei pacchetti
• tcpdump per registrazioni più lunghe, file PCAP e casi di supporto

È importante la giusta sequenza: prima si verifica che il test sia definito correttamente e che la regola generi log. Successivamente, il Log Viewer mostra quale decisione la firewall ha effettivamente registrato. Il Policy tester aiuta con la logica delle policy previste, ma non dimostra un flusso di pacchetti reale. Packet Capture è la migliore prova quando potrebbero essere coinvolti routing, NAT, VLAN, VPN, provider o un sistema di destinazione. Se il test deve durare più a lungo, è necessario un file PCAP o il supporto Sophos deve valutare la registrazione, tcpdump su Sophos Firewall è lo strumento migliore.

Un buon test di regola quindi non risponde solo alla domanda se una regola “funziona”. Mostra quale Rule ID ha effettivamente matchato, quale NAT ID era coinvolto, se sono intervenute funzionalità di sicurezza e se direzione di andata e ritorno seguono lo stesso percorso atteso.

Quale articolo è adatto?

Questo articolo è il punto di partenza giusto se si desidera testare un tentativo di connessione specifico con IP di origine, destinazione, servizio e orario. In caso di problemi correlati, un articolo più specifico è spesso più veloce:

• Una regola non matcha affatto o vince un’altra regola: Verificare le cause per cui una regola del Sophos Firewall non corrisponde.
• DNAT, SNAT, MASQ o ordine NAT sono coinvolti: Comprendere il NAT su Sophos Firewall.
• Un server interno viene pubblicato su Internet: Pubblicare un server tramite DNAT.
• Packet Capture mostra drop, Violation o motivi di drop inattesi: Analizzare i pacchetti scartati dal Sophos Firewall.
• SSL VPN è connesso, ma le destinazioni interne non funzionano: Configurare l’accesso remoto SSL VPN su Sophos Firewall.
• Site-to-Site-IPsec o Remote-Access-IPsec ha problemi: Risoluzione dei problemi IPsec VPN su Sophos Firewall.
• Gli strumenti WebAdmin non bastano e servono log locali: Risoluzione dei problemi di Sophos Firewall: Servizi e Log.
• Un caso di supporto richiede archivio log, dati IPsec o file PCAP: Salvare i log di Sophos Firewall per supporto e analisi.

Questa distinzione evita di esaminare troppo ampiamente un problema specifico di NAT, VPN, routing o servizio con un test generale delle regole.

Classificare correttamente gli strumenti

• Log viewer: mostra Rule ID, NAT ID, Action, utente e decisioni delle funzionalità di sicurezza. Non prova però i pacchetti che non raggiungono affatto il firewall.
• Policy tester: mostra la policy Firewall, Web e SSL/TLS attesa per input definiti. Non prova un vero percorso di ritorno, SD-WAN, perdita di pacchetti o problemi provider.
• Packet capture: mostra se i pacchetti arrivano, vengono inoltrati e se le risposte tornano. Non spiega automaticamente l’intento tecnico dietro una regola o una Web Policy.
• tcpdump: adatto per catture più lunghe, filtri BPF molto precisi, file PCAP e analisi Wireshark. Rule ID, NAT ID o decisioni Web Policy non sono visibili direttamente nel WebAdmin.
• Central Reporting o Syslog: aiuta per cronologia, report, correlazione SIEM e analisi successiva. Per flusso pacchetti live e dettagli dei servizi locali, gli strumenti locali restano di solito più veloci.

Se una regola apparentemente “non funziona”, non si dovrebbe subito modificare la regola stessa. Spesso la causa risiede in NAT, routing, una regola superiore, logging mancante o una funzionalità di sicurezza. Per una ricerca sistematica dei problemi, è utile anche Verificare le cause per cui una regola del Sophos Firewall non corrisponde.

Per il troubleshooting live, il Log Viewer locale resta quasi sempre più veloce di Central Reporting o di un SIEM. I log centrali sono importanti quando gli eventi devono essere ricostruiti, correlati o conservati a lungo. Per l’impostazione sono adatti Central Firewall Reporting e Inviare Syslog a SIEM.

Procedura breve per il test delle regole

Per la maggior parte dei casi di supporto è sufficiente una procedura chiara:

1. Definire il caso di test con IP di origine, destinazione, servizio, utente e orario.
2. Attivare Log firewall traffic nella regola interessata.
3. Verificare la posizione della regola e il contatore di utilizzo.
4. Riprodurre il test esattamente una volta.
5. Filtrare il Log Viewer per IP di origine, IP di destinazione e servizio.
6. Annotare Rule ID e NAT ID dal log reale.
7. Utilizzare il Policy tester solo per la logica delle policy.
8. Avviare Packet Capture se Log Viewer e Policy tester non corrispondono.
9. Documentare il risultato prima di spostare o modificare una regola.

È importante modificare un solo caso di test per ciclo. Se posizione regola, NAT, DNS, routing e client vengono cambiati contemporaneamente, il successo successivo non può più essere attribuito con precisione.

Questa procedura evita di modificare inutilmente una regola funzionante, quando il problema reale risiede in NAT, routing, DNS, TLS Inspection o un sistema di destinazione.

Prima del test

Prima di tutto, si dovrebbe annotare esattamente cosa si intende testare:

• Source IP: 172.16.10.25
• Utente: user@domain.local
• Source zone: LAN
• Destination: https://www.example.com
• Service: HTTPS
• Regola prevista: LAN_to_WAN_Clients
• Azione prevista: consentito, bloccato, decrypted, non decrypted

Successivamente, attivare Log firewall traffic nella regola del firewall interessata. Senza logging, il Log Viewer è solo di utilità limitata.

Passo 1: Verificare la posizione della regola

Aprire Rules and policies > Firewall rules e verificare:

• La regola è sopra regole più generali?
• È attiva?
• È selezionata la vista corretta IPv4 o IPv6?
• È in un gruppo di regole sensato?
• Ci sono esclusioni?
• C’è una regola creata automaticamente sopra?

Quando si testa una nuova regola, si dovrebbe resettare il contatore di utilizzo della regola. In questo modo è più facile vedere se la regola è stata effettivamente colpita durante il test.

Passo 2: Aprire il Log Viewer

Aprire il Log viewer in alto a destra nella console WebAdmin.

Filtri utili:

• Modulo: Firewall
• Source IP
• Destination IP
• Destination port
• Rule ID
• Rule name
• Action
• User

Per il traffico web, controllare anche:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

Il Log Viewer si aggiorna automaticamente. Per un’analisi tranquilla, è possibile mettere in pausa la vista live, filtrare e poi riprendere.

Passo 3: Riprodurre il test

Il test dovrebbe essere eseguito da un client definito:

• Aprire un sito web
• Inviare un ping
• Testare una porta
• Avviare un’applicazione
• Stabilire una connessione VPN
• Scaricare un file

Se possibile, dovrebbe essere eseguito un solo test alla volta. Altrimenti, i log e i contatori delle regole si mescolano.

Successivamente, verificare:

• Il contatore delle regole aumenta?
• Si vede un log nel Log Viewer?
• Quale Rule ID viene mostrato?
• Quale NAT Rule ID viene mostrato?
• Il traffico è consentito o bloccato?
• Una funzionalità di sicurezza interviene?

Se il Log Viewer resta vuoto, questo non è ancora una prova contro la regola. Prima controllare logging, filtro temporale, filtro modulo e vero flusso pacchetti. Spesso il traffico non raggiunge affatto il firewall, la regola non logga, è disattivato il tipo di log sbagliato o il test usa un IP di destinazione diverso dal previsto.

Passo 4: Utilizzare il Policy tester

Il Policy tester è utile se si desidera verificare quale regola del firewall, regola di ispezione SSL/TLS o Web Policy si applicherebbe teoricamente al traffico web.

Percorso del menu:

Diagnostics > Tools > Policy tester

Input tipici:

• URL
• Utente
• Ora e giorno
• Source IP
• Source zone
• Metodo di test

Come metodo di test, si sceglie ad esempio Firewall, SSL/TLS, and web, se si desidera verificare la combinazione di regola del firewall, regola di ispezione SSL/TLS e Web Policy.

Il Policy tester non mostra solo Accepted o Blocked, ma anche la regola del firewall corrispondente, la destinazione riconosciuta, la source zone e, a seconda del metodo di test, ulteriori informazioni Web o SSL/TLS. In questo modo si vede rapidamente se il traffico finisce fondamentalmente nella regola prevista.

Importante:

⚠️ Il Policy tester non sostituisce un vero test di flusso di pacchetti. I risultati del test delle policy non rappresentano in modo affidabile le rotte SD-WAN. Pertanto, il comportamento effettivo può differire se sono coinvolti SD-WAN, routing o gateway.

SFOS 22: Il Policy tester può mostrare risultati errati

Con SFOS 22.0 GA e SFOS 22.0 MR1, i risultati del test delle policy devono essere valutati con particolare cautela. Policy Test e Policy Route Test possono mostrare il traffico come bloccato o assegnarlo a una regola errata in determinati casi, anche se il traffico produttivo passa correttamente attraverso il firewall.

Per gli amministratori è importante la conseguenza: se il Policy tester mostra un risultato inaspettato, ma Log Viewer, contatore delle regole e Packet Capture confermano il vero flusso di pacchetti, non si dovrebbero subito modificare le regole del firewall o le regole NAT. Prima si verifica se riguarda solo la visualizzazione diagnostica.

Procedura pratica in caso di risultati contraddittori:

1. Documentare accuratamente il test con IP di origine, destinazione, servizio e utente.
2. Filtrare il Log Viewer per IP di origine, IP di destinazione e servizio.
3. Verificare Rule ID e NAT Rule ID dal log reale.
4. Avviare Packet Capture con un filtro stretto.
5. Confrontare traffico in entrata, inoltrato e di ritorno.
6. Trattare il risultato del Policy tester solo come indicazione, non come prova unica.
7. Verificare la versione del firmware e i problemi noti di Sophos prima di modificare le regole produttive.

Questa cautela vale soprattutto nelle finestre di manutenzione. Un risultato diagnostico errato non dovrebbe portare a riordinare regole produttive funzionanti o ad adattare regole NAT senza prova.

Il Policy tester è particolarmente utile per:

• Web Policy
• Categorizzazione URL
• Contesto utente
• Schedule
• Regola di ispezione SSL/TLS
• Corrispondenza delle regole del firewall per il traffico web

È meno utile per:

• vere decisioni di routing
• ritorno NAT
• perdite di pacchetti
• problemi di provider o switch
• applicazioni con più connessioni e porte

Passo 5: Utilizzare Packet Capture

Se Log Viewer e Policy tester non sono sufficienti, si utilizza Diagnostics > Packet capture.

Il filtro dovrebbe essere impostato in modo stretto, ad esempio:

• Source IP del client
• Destination IP del server
• Porta di destinazione
• Protocollo

Quindi:

1. Avviare Packet Capture.
2. Riprodurre il test.
3. Fermare Packet Capture.
4. Confrontare eventi in entrata e inoltrati.
5. Confrontare Rule ID e NAT ID con Log Viewer.

Interpretazione:

• Nessun pacchetto arriva: controllare client, VLAN, switch, gateway, provider o Cloud Security Group.
• Il pacchetto arriva ma non esce: controllare regola firewall, NAT, routing o Security Feature.
• Il pacchetto esce, ma manca la risposta: controllare rotta di ritorno, sistema di destinazione, NAT o firewall esterno.
• Il pacchetto ha stato Violation: controllare Policy, IPS, Webfilter o Application Control.
• NAT ID inatteso: controllare ordine NAT e regole NAT generiche.

Per ulteriori informazioni: Utilizzare lo strumento Packet Capture in WebAdmin. Se i pacchetti vengono scartati, è utile anche Analizzare i pacchetti scartati dal Sophos Firewall.

Leggere insieme Log Viewer e Packet Capture

Il Log Viewer mostra la decisione, Packet Capture mostra il flusso pacchetti. Nella pratica servono spesso entrambe le prospettive.

• Log Viewer mostra la Rule ID attesa, Packet Capture mostra Forwarded: il test della regola è plausibile per il firewall. Percorso di ritorno e sistema di destinazione restano da verificare separatamente.
• Log Viewer mostra la Rule ID attesa, Packet Capture non mostra risposta: controllare sistema di destinazione, rotta di ritorno, NAT o firewall esterno.
• Packet Capture mostra Incoming, ma nessun log corrispondente: controllare logging, filtro modulo, regola default, Device Access o analisi drop.
• Packet Capture mostra Consumed: il traffico termina sul firewall stesso. Controllare Device Access e Local Service ACL.
• Packet Capture mostra Violation: confrontare Reason, Rule ID, NAT ID e modulo di sicurezza con Log Viewer.

Se i due strumenti sembrano contraddirsi, prima restringere il caso di test. Un solo client, una destinazione, una porta e un breve istante di test sono meglio di una cattura ampia con molto traffico di fondo.

Utilizzare filtri stretti per Packet Capture

Packet Capture è utile solo se il filtro è sufficientemente stretto. Una registrazione troppo ampia mostra rapidamente troppo traffico di fondo, specialmente su firewall produttivi con traffico Web, DNS, VPN o server. Il filtro dovrebbe quindi essere derivato dal caso di test definito.

Esempi pratici di BPF:

• Singolo client verso una destinazione: host 172.16.10.25 and host 203.0.113.10, quando Source e Destination sono noti.
• Client verso destinazione HTTPS: host 172.16.10.25 and port 443, quando la destinazione può cambiare tramite DNS o CDN.
• Solo traffico in uscita di un client: src host 172.16.10.25, quando si verifica prima se il client invia effettivamente.
• Solo traffico di risposta verso il client: dst host 172.16.10.25, quando mancano percorso di ritorno o pacchetti di risposta.
• Test DNS: host 172.16.10.25 and port 53, quando risoluzione dei nomi e test regola devono essere verificati separatamente.
• Test ICMP: icmp and host 172.16.10.25, quando un ping serve come semplice test di raggiungibilità.

Nei test DNAT o VPN, si dovrebbe prestare particolare attenzione alla direzione di visualizzazione. Un filtro sull’IP del server interno non mostra necessariamente l’accesso originale all’IP pubblico. Al contrario, un filtro sull’IP pubblico non mostra automaticamente se il traffico arriva al server interno dopo il NAT. In tali casi, spesso due brevi catture sono più pulite: prima sul lato pubblico, poi sulla destinazione interna.

Dopo il test, si dovrebbe fermare immediatamente la cattura. Registrazioni lunghe aumentano il rischio di catturare dati inutili, nomi host interni o connessioni di terzi.

Quando passare a tcpdump

Il Packet Capture di WebAdmin è ideale per test rapidi. Tuttavia, non è sufficiente per ogni caso. Si dovrebbe passare a tcpdump quando si verifica uno di questi punti:

• La registrazione deve essere valutata come file PCAP in Wireshark o dal supporto.
• Il test dura più a lungo di un breve test di riproduzione manuale.
• Sono necessari filtri BPF molto precisi, ad esempio per VoIP, VPN, DNS o più host.
• Il buffer di WebAdmin si riempie o mostra solo un estratto.
• Il traffico rilevante deve essere osservato su un’interfaccia specifica per un periodo più lungo.

Anche con tcpdump vale: impostare filtri stretti, annotare il tempo di test, mantenere la registrazione breve e rimuovere il file dopo il trasferimento. La guida pratica alla CLI è disponibile in Sophos Firewall tcpdump: Registrare pacchetti tramite CLI.

Passo 6: Validare singolarmente le funzionalità di sicurezza

Se la regola corretta corrisponde, ma il traffico non funziona, le funzionalità attivate dovrebbero essere verificate singolarmente.

• Web policy: controllare categoria, utente, schedule e ordine delle policy.
• Scan HTTP and decrypted HTTPS: HTTPS viene scansionato solo se è già decrypted.
• SSL/TLS inspection: controllare regola adatta, Decryption Profile e certificato CA sui client.
• IPS: controllare firma, policy e possibili False Positives.
• Application Control: controllare applicazione riconosciuta, categoria e Cloud-App-Erkennung.
• Security Heartbeat: controllare se l’endpoint invia Heartbeat e se lo stato è verde, giallo o rosso.
• Traffic Shaping: controllare se la policy è attiva e adatta all’applicazione o alla regola corretta.
• NAT: controllare regola SNAT, DNAT o PAT corretta e ordine delle regole.

Per HTTPS vale: una regola del firewall con Webfiltering non è sufficiente per esaminare i contenuti HTTPS. È necessaria anche una SSL/TLS inspection rule corrispondente con decriptazione e certificato CA distribuito.

Per ulteriori informazioni: Distribuire gradualmente TLS Inspection su Sophos Firewall. Per errori NAT, è utile Comprendere il NAT su Sophos Firewall, poiché una regola NAT non consente il traffico, ma traduce solo indirizzi o porte.

Passo 7: Verificare i file di log

Se gli strumenti WebAdmin non sono sufficienti, si dovrebbero verificare i file di log appropriati.

File tipici:

• Regola firewall: firewall_rule.log
• NAT: nat_rule.log
• Connessioni firewall: fwlog.log
• IPS e DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Quale file di log appartiene a quale modulo è riassunto in Risoluzione dei problemi di Sophos Firewall: Servizi e Log.

Nei casi di supporto, un archivio log o CTR è davvero utile solo se sono documentati il momento del test e gli ID attesi. Un grande pacchetto log senza Source, Destination, porta, utente, Rule ID e NAT ID porta spesso solo a ulteriori richieste.

Esempio: Test della regola Web da LAN a WAN

1. Creare la regola del firewall LAN_to_WAN_Clients.
2. Attivare il logging.
3. Impostare i servizi su HTTP e HTTPS.
4. Selezionare la Web Policy.
5. Lasciare attivato Block QUIC protocol.
6. Attivare Scan HTTP and decrypted HTTPS.
7. Creare una regola di ispezione SSL/TLS per il gruppo di test.
8. Installare il certificato CA sul client di test.
9. Resettare il contatore delle regole.
10. Aprire il sito web.
11. Filtrare il Log Viewer per IP di origine.
12. Eseguire il Policy tester per lo stesso URL.
13. In caso di discrepanza, avviare Packet Capture.

In questo modo si vede se la regola corrisponde, se HTTPS viene effettivamente decriptato e se Webfilter, IPS o Application Control intervengono.

Documentare il risultato del test

Dopo un test delle regole, il risultato dovrebbe essere brevemente documentato. Questo è particolarmente importante se ne deriva un caso di supporto, una finestra di manutenzione o una successiva pulizia delle regole.

Sono utili:

• Data e ora del test
• Source IP, utente, destinazione, servizio e URL o applicazione testata
• Rule ID prevista e effettivamente corrispondente
• NAT Rule ID, se NAT è coinvolto
• Azione nel Log Viewer
• Screenshot o esportazione da Packet Capture, se il flusso di pacchetti era rilevante
• Regola modificata, Web Policy, regola di ispezione SSL/TLS o regola NAT
• Punto aperto, se il comportamento non è ancora completamente spiegato

Per modifiche produttive, si dovrebbe anche annotare se la regola è pensata solo per un pilota, in modo permanente o come soluzione temporanea. Le regole di test temporanee dovrebbero avere una data di scadenza o un proprietario chiaro, in modo che non rimangano come carichi inutili nel set di regole.

Se dal test della regola nasce un caso di supporto, si dovrebbero documentare anche archivio log, Packet Capture o tcpdump-PCAP, periodo interessato e cause già escluse. Per questa parte è adatto Salvare i log di Sophos Firewall per supporto e analisi.

FAQ