Utilizzare il Packet Capture di Sophos Firewall in WebAdmin

Packet Capture è uno degli strumenti di troubleshooting più importanti nel WebAdmin di Sophos Firewall. Mostra se i pacchetti arrivano a un’interfaccia, se vengono inoltrati, quale regola o ID NAT è coinvolto e se un pacchetto viene scartato.

Il Log Viewer mostra la decisione del firewall. Packet Capture mostra il flusso dei pacchetti. Entrambi insieme sono spesso il modo più rapido per individuare la causa. Se si desidera testare specificamente una regola del firewall, il flusso aggiuntivo è descritto in Testare una regola di Sophos Firewall con Log Viewer, Policy tester e Packet Capture.

È importante la contestualizzazione: questo articolo descrive la versione WebAdmin di Packet Capture. È ideale per un primo controllo, poiché si vede direttamente nel browser se i pacchetti arrivano, vengono inoltrati o scartati. Per registrazioni più lunghe, filtri molto precisi, esportazione PCAP o casi di supporto, spesso è più adatto un tcpdump tramite SSH.

Scelta dello strumento

Quale articolo è adatto?

Packet Capture è particolarmente utile quando il vero flusso dei pacchetti non è chiaro. Per domande correlate, a volte un altro punto di partenza è più rapido:

Questa distinzione è importante: Packet Capture mostra pacchetti e stato a livello di pacchetto. Tuttavia, non sostituisce il Log Viewer per le decisioni di policy, non l’articolo NAT per la logica di traduzione e non tcpdump quando è necessario un file PCAP analizzabile.

Quando Packet Capture è utile

Packet Capture è particolarmente utile per domande come:

• Il traffico arriva effettivamente al firewall?
• Il traffico esce dall’interfaccia prevista?
• Una regola del firewall è applicata?
• Una regola NAT è applicata?
• Un pacchetto viene scartato da una policy, IPS o routing?
• Una risposta arriva dal sistema di destinazione?
• Viene utilizzata una porta o un protocollo diverso da quello previsto?

Se nel Log Viewer non è visibile nulla, Packet Capture è spesso il passo successivo. Si può vedere se il problema è prima del firewall o se il firewall elabora il traffico.

Se il focus è su drop, Violation, ID regola, ID NAT o pacchetti scartati, è utile anche Analizzare i pacchetti scartati da Sophos Firewall.

Percorso del menu

Lo strumento si trova sotto:

Diagnostics > Packet capture

Packet Capture si apre direttamente in WebAdmin. A seconda della versione SFOS e della visualizzazione del browser, appare come una finestra di diagnostica all’interno della vista WebAdmin.

Prima di aprirlo, il caso di test dovrebbe essere già definito. Lo strumento è più efficace quando si riproduce un singolo flusso e non si decide cosa cercare durante la registrazione.

Dopo l’apertura, si dovrebbe prima utilizzare Configure e impostare il filtro di cattura prima di avviare il test. Se la destinazione, l’obiettivo CDN o la vista NAT non sono ancora chiari, un primo filtro sull’IP di origine è spesso migliore di un filtro troppo stretto con un indirizzo di destinazione errato. Dopo il test riprodotto, la registrazione dovrebbe essere fermata per evitare che la vista si riempia di traffico di fondo.

Log Viewer, Packet Capture o tcpdump?

Log Viewer, Packet Capture in WebAdmin e tcpdump rispondono a domande diverse. Chi sceglie lo strumento sbagliato all’inizio spesso cerca nel posto sbagliato.

Un buon esempio è un ping. Nel Log Viewer si vede spesso solo una voce o una decisione riassunta sulla connessione. In Packet Capture si vedono invece i singoli pacchetti ICMP: Echo Request verso la destinazione ed Echo Reply indietro. Windows invia con ping di default quattro ICMP Echo Requests. In Packet Capture ci si aspetta quindi più pacchetti di andata e ritorno. Se sono visibili solo le richieste ma non arrivano risposte, è un problema diverso rispetto a quando nessuna richiesta arriva al firewall.

In pratica, questo significa:

• Log Viewer risponde: Quale regola o modulo ha deciso?
• Packet Capture risponde: I pacchetti sono davvero arrivati e quale percorso seguono?
• Per problemi di routing, NAT, VLAN, gateway o ritorno, Packet Capture è spesso più significativo.
• Per decisioni di Webfilter, Application Control, IPS o ispezione SSL/TLS, è necessario anche il Log Viewer.
• Per registrazioni da inviare al supporto Sophos o a partner di analisi esterni, tcpdump è generalmente migliore di uno screenshot da WebAdmin.

Preparare la cattura

Delimitare chiaramente prima di iniziare

Packet Capture non dovrebbe essere avviato senza filtri. In reti produttive, altrimenti, si generano molti dati e l’output diventa confuso.

⚠️ Packet Capture non dovrebbe mai essere eseguito come registrazione continua ampia su firewall produttivi. Un filtro stretto, un test breve e un momento chiaro riducono la quantità di dati, il rischio per la privacy e le interpretazioni errate.

Prima si dovrebbe annotare:

• Source IP
• Destination IP o FQDN
• Protocollo
• Porta di origine, se rilevante
• Porta di destinazione
• Interfaccia o zona
• Ora del test
• Applicazione interessata
• Regola del firewall o regola NAT prevista, se nota
• Risultato previsto: consentito, bloccato, DNAT, SNAT, VPN, Web Policy o IPS

Per un test web, la delimitazione potrebbe apparire così:

In pratica, si dovrebbe sempre riprodurre un solo caso di test alla volta. Più modifiche parallele a regole del firewall, NAT, routing e configurazione del client rendono difficile l’interpretazione dell’output del Capture. Se il test riguarda un problema utente, si dovrebbe anche annotare l’utente connesso, il dispositivo interessato e l’ora esatta.

Configurare il filtro di cattura

Tramite Configure si imposta un filtro il più stretto possibile.

Filtri tipici:

• Source IP del client
• Destination IP del server
• Porta di destinazione
• Protocollo TCP, UDP o ICMP
• Interfaccia

Se non si conosce il server di destinazione, si può iniziare filtrando solo l’IP di origine. Se poi sono visibili troppi pacchetti, restringere ulteriormente.

Sophos Firewall utilizza la sintassi Berkeley Packet Filter, abbreviata BPF. Il filtro di cattura decide quali pacchetti vengono scritti nel buffer di cattura. Dovrebbe quindi essere impostato correttamente prima del test.

Esempi tipici di BPF:

Per un test web molto mirato, un filtro potrebbe apparire così:

host 172.16.10.25 and host 93.184.216.34 and port 443

Per un test Ping spesso basta:

host 172.16.10.25 and proto ICMP

Se il filtro è troppo stretto

Un filtro di cattura stretto è importante, ma non deve nascondere l’errore. Soprattutto con DNS, NAT, CDN e ritorni, si dovrebbe decidere consapevolmente se filtrare prima abbastanza ampiamente o subito in modo molto preciso.

Ostacoli tipici:

Per il primo passaggio, un filtro sull’IP di origine è spesso più utile di un filtro troppo preciso con un IP di destinazione errato. Quando il flusso rilevante è visibile, si può filtrare più strettamente nel secondo passaggio. In caso di errori NAT, si dovrebbe anche verificare se si sta osservando la vista prima o dopo la traduzione.

Nella vista WebAdmin, dopo il salvataggio, si vede la stringa BPF attiva sopra l’elenco dei pacchetti. Il primo screenshot mostra la configurazione del filtro, il secondo screenshot l’elenco dei risultati con il filtro attivo.

⚠️ I dati PCAP possono contenere indirizzi IP, nomi host, dettagli del protocollo e, a seconda del protocollo, anche dati utente. Le catture dovrebbero essere condivise solo con persone o partner autorizzati a vedere questi dati.

Eseguire la cattura

Avviare e riprodurre la cattura

1. Impostare il filtro.
2. Attivare Packet Capture tramite il cursore.
3. Riprodurre il problema in modo mirato.
4. Fermare nuovamente la cattura.
5. Analizzare i risultati.
6. Svuotare la cattura quando si avvia un nuovo test.

Sophos Firewall mostra lo stato e il buffer:

Quando il buffer è pieno, la registrazione si ferma automaticamente. Successivamente, è necessario svuotare con Clear prima di registrare nuovamente in modo utile. Per questo motivo, un filtro stretto è importante.

Nelle impostazioni del filtro, è possibile anche specificare quanti byte per pacchetto vengono catturati. Per molte prime analisi, le informazioni di intestazione sono sufficienti. Se si necessitano più dati utente, è necessario catturare più byte, ma si dovrebbe tenere d’occhio la privacy e la dimensione del buffer.

Interpretare l’output

Comprendere le colonne importanti

Packet Capture mostra molti campi. Per la pratica, questi sono particolarmente importanti:

Questi campi sono preziosi perché colmano il divario tra “la regola sembra corretta” e “il traffico scorre davvero così”.

Tramite Show additional properties o la vista dettagliata, a seconda della versione, si vedono ulteriori informazioni come Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username o ulteriori ID di policy. Questi dettagli aiutano quando un pacchetto non viene elaborato solo da una regola del firewall, ma anche da Web, Application Control, IPS o altri moduli.

Interpretare correttamente lo stato

Se si vede solo Incoming e non Forwarded, il pacchetto probabilmente rimane bloccato sul firewall. In tal caso, si dovrebbe controllare la regola del firewall, NAT, routing e funzionalità di sicurezza.

Se Forwarded è visibile ma non arriva alcuna risposta, il problema è spesso nel sistema di destinazione, nel ritorno, nel NAT o in una controparte.

In caso di ping riuscito, si vedono tipicamente pacchetti in entrambe le direzioni. Se Windows invia quattro ping, si vedono più ICMP Echo Requests dal client alla destinazione e più Echo Replies indietro. Se mancano le risposte, si controlla il percorso di ritorno, il sistema di destinazione, il firewall locale del sistema di destinazione, il NAT o una controparte. Se mancano già le richieste, si controlla il client, il gateway, il VLAN, la porta dello switch o se il traffico raggiunge effettivamente il Sophos Firewall.

Leggere correttamente Consumed e Generated

Consumed e Generated sono facilmente fraintesi. Questi stati non significano automaticamente che manca una normale regola del firewall.

Esempi di Consumed sono accessi a WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP, IPsec o SSL VPN del firewall stesso. Tale traffico non viene trattato come normale traffico di transito tramite una regola LAN-to-WAN o WAN-to-DMZ. Se un pacchetto nel Capture mostra Consumed, si dovrebbe prima chiarire se il client voleva davvero raggiungere il firewall stesso.

Per questi casi, Administration > Device access e Local Service ACL sono più importanti di una normale regola del firewall. Il rafforzamento di questi accessi è descritto in Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Utilizzare il Display Filter

Il filtro di cattura limita quali pacchetti vengono registrati. Il Display filter filtra invece la vista già registrata. È utile quando si è avviato intenzionalmente il Capture un po’ più ampio e poi si vogliono visualizzare solo determinati pacchetti.

Nel Display Filter si può filtrare, tra l’altro, per questi campi:

• Nome dell’interfaccia
• Tipo Ethernet, ad esempio IPv4, IPv6 o ARP
• Tipo di pacchetto
• Source IP e Source port
• Destination IP e Destination port
• Reason
• Status
• Rule ID
• User
• Connection ID

Per la ricerca degli errori, sono particolarmente utili Status, Reason, Rule ID, Source IP, Destination IP e Destination port. Se ci sono molti pacchetti nel Capture, si può ridurre rapidamente alla parte rilevante senza dover riavviare immediatamente il test.

Leggere il NAT in Packet Capture

Con il NAT, si deve considerare che un pacchetto appare diverso prima e dopo il NAT. Packet Capture può rendere visibili l’ID NAT, l’ID regola e gli indirizzi modificati.

In caso di problemi NAT, si dovrebbe controllare:

• Si vede il pacchetto con l’indirizzo originale?
• Si vede il pacchetto dopo la traduzione?
• Viene visualizzato l’ID NAT previsto?
• Il pacchetto passa attraverso l’interfaccia di uscita prevista?
• Arriva una risposta?

Per DNAT, inoltre: la regola del firewall utilizza la zona di destinazione dopo il NAT, ma l’IP di destinazione prima del NAT. Questo può sembrare insolito a prima vista.

Maggiori dettagli: Comprendere il NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Combinare Packet Capture e Log Viewer

Il miglior flusso è:

1. Aprire Log Viewer.
2. Avviare Packet Capture con un filtro stretto.
3. Riprodurre il test.
4. Verificare in Packet Capture se i pacchetti arrivano e vengono inoltrati.
5. Verificare in Log Viewer quale regola o modulo ha deciso.
6. Se necessario, passare al file di log appropriato.

Il Log Viewer mostra, ad esempio, eventi di firewall, Web, ispezione SSL/TLS, IPS o Application Control. Packet Capture mostra invece il flusso dei pacchetti a livello di interfaccia.

Soprattutto con ping o semplici connessioni TCP, la combinazione è importante. Il Log Viewer può solo mostrare che una connessione è consentita o bloccata. Packet Capture mostra inoltre se i pacchetti di risposta tornano, se il NAT è applicato, se viene utilizzata l’interfaccia di uscita corretta e se il percorso di ritorno è corretto.

Casi di analisi tipici

Il client non raggiunge Internet: Impostare il Capture su Source IP e TCP 443. Se non arriva alcun pacchetto, controllare client, VLAN, gateway o switch. Se il pacchetto arriva ma non esce, controllare regola del firewall, NAT o routing.

DNAT non funziona: Impostare il Capture su IP di destinazione pubblico e porta esterna. Se non arriva alcun pacchetto, controllare router del provider, inoltro delle porte, gruppo di sicurezza cloud o WAN. Se il pacchetto arriva ma non va al server interno, controllare regola DNAT e regola del firewall.

Il traffico VPN non funziona: Impostare il Capture su interfaccia del tunnel, interfaccia XFRM o reti sorgente/destinazione rilevanti. Inoltre, controllare strongswan.log, charon.log o xfrmi.log.

Webfilter blocca inaspettatamente: In Packet Capture si vede spesso solo il flusso dei pacchetti. La decisione stessa è meglio controllata in Log Viewer sotto Web, Application Control o ispezione SSL/TLS.

Piccoli test funzionano, grandi trasferimenti si bloccano: Impostare il Capture sul client interessato e sulla destinazione e prestare attenzione a ritrasmissioni, risposte mancanti o dimensioni dei pacchetti insolite. Se ping, login o piccole richieste HTTP funzionano, ma download più grandi, RDP, VoIP o applicazioni VPN si bloccano, si dovrebbe anche controllare MTU, MSS, PPPoE, overhead VPN e frammentazione. Il flusso è descritto in Verificare MTU e MSS su Sophos Firewall in caso di problemi VPN.

Interpretazioni errate comuni

Packet Capture mostra molto, ma non sempre ciò che ci si aspetta inizialmente. Alcune interpretazioni errate sono particolarmente comuni nei casi di supporto.

Se Packet Capture mostra un ID regola inaspettato, non si dovrebbero modificare immediatamente più regole. È meglio prima confrontare con il Log Viewer e la posizione della regola. Per un matching sistematico, si adatta Verificare le cause per cui una regola di Sophos Firewall non corrisponde.

Limiti, protezione dei dati e condivisione

Privacy e condivisione delle catture

I dati di Packet Capture sono dati operativi. Anche se spesso sono visibili solo intestazioni, possono rivelare indirizzi IP interni, destinazioni pubbliche, nomi utente, nomi host, porte, protocolli e relazioni di comunicazione. Con protocolli non crittografati, possono essere visibili anche dati utente.

Prima di condividere, si dovrebbe controllare:

• La registrazione contiene nomi di clienti, nomi host interni o indirizzi IP pubblici?
• Sono riconoscibili utenti, sistemi o applicazioni?
• Il destinatario è autorizzato a vedere queste informazioni?
• Basta uno screenshot delle righe rilevanti o serve davvero un file PCAP?
• La registrazione deve essere accorciata o anonimizzata prima?

Per i casi di supporto, spesso una registrazione tcpdump mirata con filtro pulito è migliore di una cattura ampia da WebAdmin. Se sono necessari anche file di log, aiuta Salvare i log di Sophos Firewall per supporto e analisi.

Quando tcpdump è migliore

Il Packet Capture di WebAdmin è ideale per analisi rapide direttamente nel browser. Si vede rapidamente se i pacchetti arrivano, vengono inoltrati, consumati, generati o scartati. Per una prima delimitazione, è spesso il punto di partenza giusto.

tcpdump è migliore quando la registrazione non è solo necessaria come vista a schermo, ma come file analizzabile o come traccia tecnica più lunga.

La differenza principale: tcpdump mostra pacchetti, ma nessuna decisione specifica di Sophos. Se si deve sapere quale regola del firewall, regola NAT, Web Policy, IPS Policy o regola di ispezione SSL/TLS è stata coinvolta, si ha ancora bisogno di Log Viewer, Packet Capture di WebAdmin o del file di log appropriato.

Prima di tcpdump, SSH o Advanced Shell dovrebbero essere consapevolmente abilitati. La registrazione dovrebbe essere strettamente filtrata, limitata nel tempo e rimossa dopo l’analisi. Un PCAP ampio su un firewall produttivo può rapidamente contenere dati sensibili e molto traffico inutile.

Maggiori dettagli: Sophos Firewall tcpdump: registrare pacchetti tramite CLI.

Checklist

• Annotare il caso di test con Source, Destination, Port, Protocol e ora.
• Conoscere la regola del firewall e la regola NAT previste, se possibile.
• Impostare il filtro di cattura stretto.
• Con DNS, NAT o obiettivi CDN, verificare se il filtro cattura davvero sia la direzione di andata che quella di ritorno.
• Riprodurre solo un caso di test alla volta.
• Fermare nuovamente Packet Capture dopo il test.
• Distinguere consapevolmente tra Incoming, Forwarded, Consumed, Generated e Violation.
• Confrontare ID regola e ID NAT con Log Viewer.
• In caso di risposta mancante, controllare percorso di ritorno, NAT, sistema di destinazione e controparte.
• In caso di trasferimenti grandi bloccati, controllare MTU/MSS, frammentazione e overhead VPN.
• Controllare i dati sensibili nei Captures prima di condividerli.
• Per registrazioni più lunghe o file PCAP, utilizzare tcpdump.

FAQ