Usare Packet Capture Sophos Firewall in WebAdmin

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

Log Viewer mostra la decisione della firewall. Packet Capture mostra il flusso dei pacchetti. Insieme sono spesso il modo più rapido per trovare la causa.

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

Quando Packet Capture è utile

Packet Capture aiuta soprattutto con domande come:

• Il traffico arriva davvero alla firewall?
• Il traffico esce dall’interfaccia prevista?
• Una Firewall Rule viene applicata?
• Una NAT Rule viene applicata?
• Un pacchetto viene scartato da policy, IPS o routing?
• Arriva una risposta dal sistema di destinazione?
• Viene usato un altro porto o protocollo rispetto a quello previsto?

Se nel Log Viewer non si vede nulla, Packet Capture è spesso il passo successivo. In questo modo si capisce se il problema è prima della firewall o se la firewall sta elaborando il traffico.

Percorso di menu

Lo strumento si trova qui:

Diagnostics > Packet capture

Packet Capture si apre direttamente in WebAdmin. A seconda della versione SFOS e della visualizzazione del browser, appare come una finestra diagnostica separata dentro WebAdmin.

Log Viewer o Packet Capture?

Log Viewer e Packet Capture rispondono a domande diverse.

Un buon esempio è un ping. Nel Log Viewer spesso si vede solo una voce o una decisione riassunta della connessione. In Packet Capture si vedono invece i singoli pacchetti ICMP: Echo Request verso la destinazione ed Echo Reply di ritorno. Windows invia per impostazione predefinita quattro ICMP Echo Requests con ping. In Packet Capture ci si aspetta quindi di vedere più pacchetti in andata e ritorno. Se sono visibili solo le requests ma non tornano replies, il problema è diverso rispetto al caso in cui nessuna request raggiunga la firewall.

In pratica:

• Log Viewer risponde: Quale regola o modulo ha deciso?
• Packet Capture risponde: I pacchetti sono arrivati davvero e quale percorso seguono?
• Per problemi di routing, NAT, VLAN, gateway o percorso di ritorno, Packet Capture è spesso più significativo.
• Per decisioni di Web filter, Application Control, IPS o SSL/TLS inspection serve anche Log Viewer.

Limitare il perimetro prima di iniziare

Packet Capture non dovrebbe essere avviato senza filtro. Nelle reti di produzione si generano rapidamente molti dati e l’output diventa difficile da leggere.

Prima conviene annotare:

• Source IP
• Destination IP o FQDN
• Protocollo
• Source port, se rilevante
• Destination port
• Interfaccia o zona
• Ora del test
• Applicazione interessata

Per un test web, il perimetro potrebbe essere:

Configurare il capture filter

Con Configure si imposta un filtro il più possibile ristretto.

Filtri tipici:

• Source IP del client
• Destination IP del server
• Destination port
• Protocollo TCP, UDP o ICMP
• Interfaccia

Se il server di destinazione non è noto, si può iniziare filtrando solo per Source IP. Se sono visibili troppi pacchetti, si restringe ulteriormente.

Sophos Firewall usa la sintassi Berkeley Packet Filter, abbreviata BPF. Il capture filter decide quali pacchetti vengono scritti nel capture buffer. Dovrebbe quindi essere impostato correttamente prima del test.

Esempi BPF tipici:

Per un test web molto mirato, un filtro può essere:

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

In WebAdmin, dopo il salvataggio, il BPF string attivo viene mostrato sopra la lista dei pacchetti. Il primo screenshot mostra la configurazione del filtro, il secondo la lista dei risultati con il filtro attivo.

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

Avviare la cattura e riprodurre il problema

1. Impostare il filtro.
2. Attivare Packet Capture con l’interruttore.
3. Riprodurre il problema in modo mirato.
4. Fermare di nuovo la cattura.
5. Analizzare i risultati.
6. Svuotare la cattura prima di iniziare un nuovo test.

Sophos Firewall mostra stato e buffer:

Quando il buffer è pieno, la cattura si ferma automaticamente. Dopo bisogna usare Clear prima di poter registrare una nuova cattura utile. Per questo un filtro stretto è importante.

Nelle impostazioni del filtro si può anche definire quanti byte per pacchetto vengono catturati. Per molte prime analisi bastano le informazioni degli header. Se servono più dati payload, bisogna catturare più byte, tenendo però presenti privacy e dimensione del buffer.

Comprendere le colonne importanti

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

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

Con Show additional properties o nella vista dettagliata, a seconda della versione, si vedono altre informazioni come Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username o altri policy IDs. Questi dettagli aiutano quando un pacchetto non viene elaborato solo da una Firewall Rule, ma anche da Web, Application Control, IPS o altri moduli.

Interpretare correttamente lo status

Se si vede solo Incoming e non Forwarded, probabilmente il pacchetto resta bloccato sulla firewall. In questo caso bisogna verificare Firewall Rule, NAT, routing e security features.

Se Forwarded è visibile ma non torna alcuna risposta, il problema spesso è sul sistema di destinazione, sul percorso di ritorno, su NAT o su un peer remoto.

Con un 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 di ritorno. Se mancano i Replies, bisogna controllare route di ritorno, sistema di destinazione, firewall locale del sistema di destinazione, NAT o un peer remoto. Se mancano già i Requests, bisogna controllare client, gateway, VLAN, porta switch o se il traffico raggiunge Sophos Firewall.

Usare Display filter

Il capture filter limita quali pacchetti vengono registrati. Il Display filter invece filtra la vista già registrata. È utile quando la cattura è stata avviata volutamente in modo un po’ più ampio e dopo si vogliono mostrare solo determinati pacchetti.

Nel Display filter si può filtrare, tra l’altro, per:

• Interface name
• Ethernet type, ad esempio IPv4, IPv6 o ARP
• Packet type
• Source IP e Source port
• Destination IP e Destination port
• Reason
• Status
• Rule ID
• User
• Connection ID

Per il troubleshooting sono particolarmente utili Status, Reason, Rule ID, Source IP, Destination IP e Destination port. Se nella cattura ci sono molti pacchetti, permettono di ridurre rapidamente la vista alla parte rilevante senza riavviare subito il test.

Leggere NAT in Packet Capture

Con NAT bisogna ricordare che un pacchetto appare diverso prima e dopo NAT. Packet Capture può mostrare NAT ID, Rule ID e gli indirizzi modificati.

Per problemi NAT, verificare:

• Il pacchetto è visibile con l’indirizzo originale?
• Il pacchetto è visibile dopo la traduzione?
• Viene mostrato il NAT ID previsto?
• Il pacchetto esce dall’Out interface previsto?
• Torna una risposta?

Per DNAT c’è anche questo punto: la Firewall Rule usa la destination zone dopo NAT, ma la Destination IP prima di NAT. All’inizio può sembrare insolito.

Maggiori informazioni: Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Combinare Packet Capture e Log Viewer

Il flusso migliore è:

1. Aprire Log Viewer.
2. Avviare Packet Capture con un filtro stretto.
3. Riprodurre il test.
4. In Packet Capture verificare se i pacchetti arrivano ed escono.
5. In Log Viewer verificare quale regola o modulo ha deciso.
6. Se necessario, passare al log file corrispondente.

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

La combinazione è importante soprattutto con ping o semplici connessioni TCP. Log Viewer può mostrare solo che una connessione è stata consentita o bloccata. Packet Capture mostra inoltre se i pacchetti di risposta tornano, se NAT viene applicato, se viene usato il corretto Out interface e se il percorso di ritorno funziona.

Esempi frequenti

Il client non raggiunge Internet: impostare una cattura 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 Firewall Rule, NAT o routing.

DNAT non funziona: impostare una cattura sull’IP di destinazione pubblico e sulla porta esterna. Se non arriva alcun pacchetto, controllare router del provider, port forwarding, cloud Security Group o WAN. Se il pacchetto arriva ma non va al server interno, controllare la regola DNAT e la Firewall Rule.

Il traffico VPN non funziona: impostare una cattura sull’interfaccia tunnel, XFRM interface o sulle reti sorgente/destinazione rilevanti. Verificare anche strongswan.log, charon.log o xfrmi.log.

Web filter blocca in modo inatteso: in Packet Capture di solito si vede solo il flusso dei pacchetti. La decisione vera si verifica meglio nel Log Viewer sotto Web, Application Control o SSL/TLS inspection.

Quando tcpdump è migliore

WebAdmin Packet Capture è ideale per analisi rapide. Per catture più lunghe, filtri molto precisi o casi di supporto, tcpdump da CLI è spesso migliore.

Maggiori informazioni: Raccogliere log Sophos Firewall con TCPDump per l’analisi.