Usare tcpdump in sicurezza su Sophos Firewall

tcpdump è lo strumento giusto quando è necessario vedere più nel dettaglio quali pacchetti arrivano effettivamente sulla Sophos Firewall, attraverso quale interfaccia passano e se un problema si verifica prima, sulla o dietro la firewall. Integra Log Viewer, WebAdmin Packet Capture e Service Logs, ma non li sostituisce.

Per analisi rapide tramite browser, spesso è più comodo utilizzare Sophos Firewall Packet Capture nel WebAdmin. Per catture più lunghe, filtri molto precisi, file PCAP o casi di supporto, tcpdump tramite SSH è generalmente più adatto.

⚠️ Importante: Le catture di pacchetti possono contenere dati sensibili: indirizzi IP interni, nomi host, nomi utente, richieste DNS, dettagli dei certificati o payload non cifrati. Pertanto, dovrebbero essere filtrate strettamente, registrate solo per il tempo necessario, documentate e trasmesse solo tramite canali sicuri. Una cattura non filtrata su any può generare molti dati su firewall in produzione.

Scelta dello strumento e prerequisiti

Quale articolo è adatto?

tcpdump non è il primo passo per ogni analisi. A seconda della domanda, un altro punto di partenza può essere più rapido:

• Vedere rapidamente nel WebAdmin se i pacchetti arrivano, vengono inoltrati o scartati: Sophos Firewall Packet Capture nel WebAdmin.
• Validare una regola firewall con Log Viewer, Policy tester e Packet Capture: Testare correttamente una regola Sophos Firewall.
• Focus su Drop, Violation, Rule ID, NAT ID o motivi di drop: Analizzare i pacchetti scartati dal Sophos Firewall.
• Trovare il log locale corretto per VPN, Web, IPS, GUI o servizi di sistema: Assegnare correttamente i Service Log Sophos Firewall.
• Preparare SSH o Advanced Shell: Connettersi a Sophos Firewall tramite SSH.
• Preparare un caso di supporto con archivio /log, dati IPsec o log di debug: Salvare i log di Sophos Firewall per supporto e analisi.
• Serve un file PCAP, una cattura lunga o filtri CLI molto precisi: questo articolo.

Questa distinzione risparmia tempo e riduce il rischio. tcpdump fornisce dati di pacchetti potenti, ma non decisioni di policy specifiche di Sophos. Rule ID, NAT ID, Drop Reason, Web Policy, IPS o SSL/TLS inspection devono essere verificati parallelamente nel Log Viewer, nel WebAdmin Packet Capture o nei file di log appropriati.

Prerequisiti

Per questa guida sono necessari:

• Accesso amministrativo alla Sophos Firewall.
• Accesso SSH alla firewall o accesso alla Advanced Shell.
• L’IP sorgente, l’IP di destinazione, la porta di destinazione e il protocollo interessato.
• Spazio di archiviazione sufficiente se viene scritto un file PCAP.
• Wireshark o un altro strumento di analisi sul client amministrativo, se un file PCAP deve essere valutato.

Come preparare in modo sicuro SSH è descritto in Connettersi a Sophos Firewall tramite SSH. Per le basi generali della CLI, è adatto anche Sophos Firewall CLI Troubleshooting: comandi importanti.

Quando tcpdump è il passo successivo giusto

tcpdump non dovrebbe essere automaticamente il primo passo. Se si vuole solo sapere quale regola del firewall, regola NAT, Web Policy o regola di ispezione SSL/TLS ha deciso, il Log Viewer è più veloce e più leggibile. Se si vuole vedere nel browser se singoli pacchetti arrivano, vengono inoltrati o scartati, spesso è sufficiente Packet Capture nel WebAdmin.

tcpdump diventa utile soprattutto quando si verifica uno di questi punti:

• La cattura deve essere valutata come file PCAP in Wireshark o tramite supporto.
• Il WebAdmin-Capture è troppo breve, troppo confuso o il buffer si riempie.
• Il test deve durare più a lungo durante una finestra di manutenzione, una telefonata o un errore utente riproducibile.
• Sono necessari filtri CLI precisi, ad esempio per VoIP, DNS, IPsec, più host o intervalli di porte.
• Il traffico rilevante deve essere confrontato prima su any e poi su un’interfaccia specifica.

È importante l’aspettativa: tcpdump mostra i pacchetti, ma non una decisione di Rule ID, NAT ID, Drop Reason o Web-Policy specifica di Sophos. Queste informazioni devono essere verificate parallelamente tramite Log Viewer, WebAdmin Packet Capture o file di log appropriati.

Advanced Shell o Device Console?

tcpdump può comparire in due contesti CLI su Sophos Firewall. La Sophos Device Console include un proprio comando tcpdump con sintassi Sophos e opzioni come filedump. La Advanced Shell offre inoltre il tcpdump più vicino a Linux, spesso più pratico nei casi di supporto perché consente di lavorare con processi, scp, /tmp e altri strumenti shell.

Questa distinzione è importante:

• Device Console: adatta al comando Sophos CLI tcpdump. Prima dell’esecuzione è opportuno verificare la sintassi con Tab o ?. Secondo Sophos, un output creato con filedump viene salvato in /tmp.
• Advanced Shell: adatta a workflow shell classici con tcpdump, ps, df, grep, scp, accesso ai file e arresto mirato dei processi in esecuzione.

Questo articolo usa volutamente la Advanced Shell perché file PCAP, processi in background, scp e pulizia finale risultano più comprensibili in questo contesto. Se si usa tcpdump nella Device Console, valgono le stesse regole di base: filtri stretti, finestra di cattura breve, controllo dello spazio libero e confronto del risultato con Log Viewer o WebAdmin Packet Capture.

Se non è chiaro in quale console ci si trova, aiuta la panoramica Sophos Firewall Troubleshooting: Servizi e Log.

Preparare la cattura

Delimitare prima di iniziare

Prima di una cattura, è opportuno annotare i parametri di analisi:

• Source IP: ad esempio 172.16.10.25.
• Destination IP: ad esempio 198.51.100.20.
• Protocollo: ad esempio TCP.
• Destination Port: ad esempio 443.
• Interfaccia attesa: LAN, WAN o interfaccia VPN.
• Momento del test: ora esatta con fuso orario.
• Risultato atteso: connessione consentita, bloccata, DNAT, SNAT, VPN o Drop.
• Controllo parallelo: Log Viewer, Packet Capture, Service Log o ticket di supporto.

Più stretto è il filtro, migliore è il risultato. Una cattura senza filtro è generalmente utile solo su firewall molto tranquilli.

Il test dovrebbe essere riproducibile. Se più persone modificano le impostazioni contemporaneamente o più client testano, la cattura diventa difficile da interpretare. È meglio un singolo client di test, un intervallo di tempo ristretto e una domanda chiara: il pacchetto arriva? Esce? La risposta torna? Quale regola, regola NAT o policy era visibile in parallelo?

Per i test delle regole, è adatto anche Testare le regole del Sophos Firewall con Log Viewer e Packet Capture. Se l’attenzione è su Drop, Violation, Rule ID o NAT ID, Analizzare i pacchetti scartati dal Sophos Firewall è l’articolo di collegamento migliore.

Eseguire tcpdump

Eseguire tcpdump in tempo reale

Per un primo controllo in tempo reale, spesso è sufficiente un filtro host:

tcpdump -i any -nn host 198.51.100.20

I parametri:

• -i any: cattura su tutte le interfacce.
• -nn: non esegue risoluzione DNS o dei nomi porta.
• host 198.51.100.20: mostra solo pacchetti da o verso questo IP.

Per un test web, è utile un filtro porta aggiuntivo:

tcpdump -i any -nn 'host 198.51.100.20 and port 443'

Le espressioni di filtro con and, or o not dovrebbero essere racchiuse tra virgolette semplici. In questo modo, l’espressione rimane intatta e non viene suddivisa dalla shell.

Esempi di filtri comuni

• Host specifico: tcpdump -i any -nn 'host 198.51.100.20'
• Source IP specifico: tcpdump -i any -nn 'src host 172.16.10.25'
• Destination IP specifico: tcpdump -i any -nn 'dst host 198.51.100.20'
• Rete specifica: tcpdump -i any -nn 'net 172.16.10.0/24'
• Porta specifica: tcpdump -i any -nn 'port 443'
• Host e porta: tcpdump -i any -nn 'host 198.51.100.20 and port 443'
• ICMP / Ping: tcpdump -i any -nn 'proto ICMP'
• DNS: tcpdump -i any -nn 'port 53'
• Tutte le porte tranne SSH: tcpdump -i any -nn 'host 198.51.100.20 and port not 22'

In caso di problemi con VPN, VLAN o routing, può essere utile restringere non su any, ma su un’interfaccia specifica. I nomi delle interfacce devono corrispondere alla firewall in uso. Spesso questa sequenza è pratica:

1. Controllare brevemente su any se l’host o la porta attesi sono visibili.
2. Poi catturare sull’interfaccia di ingresso presunta.
3. Poi catturare sull’interfaccia di uscita presunta.
4. Confrontare le tre osservazioni con Log Viewer, NAT ID, Rule ID o Drop Reason.

Così si capisce più rapidamente se il traffico non raggiunge il firewall, viene fermato sul firewall o se la risposta manca sul percorso di ritorno.

Limitare la cattura

Una cattura dovrebbe essere limitata per non durare inutilmente a lungo.

Con -c, tcpdump si interrompe dopo un numero fisso di pacchetti:

tcpdump -i any -nn -c 100 'host 198.51.100.20 and port 443'

Per test brevi, questo è spesso più pulito di un processo in background. Si avvia la cattura, si riproduce il problema e si ottiene automaticamente l’output.

Scrivere un file PCAP

Se la cattura deve essere analizzata successivamente in Wireshark o tramite supporto, si scrive un file PCAP in /tmp.

tcpdump -i any -nn -s 0 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Parametri importanti:

• -s 0: cattura pacchetti completi.
• -w /tmp/sophos-capture.pcap: scrive l’output in un file PCAP.
• -nn: disabilita la risoluzione dei nomi.

-s 0 è utile quando è necessaria una cattura completa. Allo stesso tempo, aumenta il rischio per la privacy, poiché viene catturato più contenuto del pacchetto. Per domande puramente di flusso o intestazione, spesso è sufficiente una cattura in tempo reale senza file PCAP o una cattura breve con filtro stretto.

Prima di catture più grandi, è opportuno controllare lo spazio di archiviazione disponibile:

df -h /tmp
df -h /var

Se il problema deve essere riprodotto solo brevemente, anche qui può essere aggiunto -c:

tcpdump -i any -nn -s 0 -c 500 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Dopo l’avvio, è opportuno riprodurre immediatamente il test e non lasciare la cattura in esecuzione inutilmente. Un PCAP che contiene cinque minuti di troppo non è solo più grande, ma spesso contiene anche più informazioni sensibili.

Per i casi di supporto, il nome file dovrebbe contenere un contesto neutro, ma nessun nome cliente, nome utente o hostname riservato. Sono migliori nomi come /tmp/ticket-12345-wan-443.pcap o /tmp/vpn-test-20260629.pcap.

Avviare e fermare un processo in background

A volte è necessario che una cattura sia in esecuzione mentre viene eseguito un altro test. In tal caso, tcpdump può essere avviato in background.

tcpdump -i any -nn -s 0 -w /tmp/voip-test.pcap 'host 192.0.2.50 and portrange 5060-5090' &

Visualizzare i job in esecuzione:

jobs

Terminare un job:

kill %1

Se sono in esecuzione più processi tcpdump o il job non è più visibile nella shell corrente, controllare prima i processi:

ps | grep tcpdump

Quindi terminare il processo appropriato. killall tcpdump dovrebbe essere utilizzato solo se è chiaro che non ci sono altre catture importanti in esecuzione.

Dopo aver fermato, è opportuno verificare se il file PCAP è stato scritto e ha una dimensione plausibile:

ls -lh /tmp/*.pcap

Se per un appuntamento di supporto è pianificata una cattura in background, prima deve essere chiaro chi la avvia, chi la ferma e dove finisce il file. Una cattura dimenticata non è un raro problema di troubleshooting, ma un rischio operativo evitabile.

Esempio: Analizzare VoIP o 3CX

In caso di problemi VoIP, la segnalazione SIP e il flusso multimediale RTP devono spesso essere considerati separatamente. Una singola cattura su port 5060 mostra solo una parte del problema.

Per un primo test 3CX, si può catturare l’host PBX:

tcpdump -i any -nn -s 0 -w /tmp/3cx-test.pcap 'host 192.0.2.50'

Se il traffico è troppo ampio, si può restringere più precisamente su SIP:

tcpdump -i any -nn -s 0 -w /tmp/3cx-sip.pcap 'host 192.0.2.50 and portrange 5060-5090'

Per problemi audio, è necessario controllare anche l’intervallo di porte RTP effettivamente utilizzato. Questo dipende dal centralino e dalla sua configurazione.

Per argomenti VoIP su Sophos Firewall, è opportuno controllare anche Ottimizzare le impostazioni VoIP su Sophos Firewall.

Valutazione e pulizia

Scaricare e ripulire il file PCAP

Un file PCAP può essere copiato su un server interno tramite scp:

scp /tmp/sophos-capture.pcap adminuser@192.0.2.10:/tmp/

A seconda dell’ambiente, può essere utilizzato anche un altro metodo di trasferimento sicuro. FTP con credenziali memorizzate dovrebbe essere evitato.

Dopo un trasferimento riuscito, il file dovrebbe essere rimosso dalla firewall:

rm /tmp/sophos-capture.pcap

Per archivi di log completi e casi di supporto, Salvare i log di Sophos Firewall per supporto e analisi è la guida più adatta.

Contesto per supporto o analisi esterna

Un file PCAP senza contesto è difficile da valutare. Per Sophos Support, Avanet o un partner esterno di analisi dovrebbero essere forniti almeno questi dati:

• Finestra temporale: ad esempio 2026-06-29, 14:05-14:08 Europe/Zurich.
• Flow atteso: ad esempio client 172.16.10.25 verso server 198.51.100.20:443.
• Funzione interessata: DNAT, IPsec, SSL VPN, Webfilter, VoIP, DNS o Routing.
• Osservazione: ad esempio SYN visibile, nessun SYN-ACK, drop nel Log Viewer o nessuna risposta dal target.
• Controllato in parallelo: Rule ID, NAT ID, Packet Capture e Service Logs rilevanti.
• Modifica prima dell’errore: firmware, modifica regola, cambio provider, certificato o SD-WAN route.

Prima della trasmissione si dovrebbe verificare se il file contiene nomi interni, indirizzi privati, indirizzi IP pubblici del cliente o contenuti non cifrati. Se il contenuto non può essere anonimizzato, destinatari, canale di trasmissione e conservazione devono essere decisi consapevolmente.

Valutare correttamente tcpdump

Nella valutazione, non si tratta solo di vedere se i pacchetti sono visibili. È cruciale ciò che manca.

• Nessun pacchetto visibile dal client: il problema è prima del firewall. Controllare client, VLAN, gateway, switch o routing verso il firewall.
• I pacchetti entrano, ma non escono: controllare regola firewall, NAT, routing, Security Feature o policy.
• I pacchetti escono, ma nessuna risposta torna: controllare sistema di destinazione, percorso di ritorno, firewall opposto, NAT o provider.
• Solo SYN, nessun SYN-ACK: la destinazione o il percorso di ritorno non risponde.
• ICMP Request visibile, Reply mancante: controllare percorso di ritorno, firewall di destinazione o controparte.
• Richiesta DNS visibile, nessuna risposta: controllare server DNS, percorso, regola o upstream.
• Pacchetto visibile solo su any, ma non sull’interfaccia attesa: controllare ipotesi sull’interfaccia, zona, rotta o associazione tunnel.
• Pacchetto visibile sull’interfaccia di ingresso, ma non su quella di uscita: controllare regola, NAT, rotta, Security Feature o motivo di drop.

tcpdump mostra il flusso dei pacchetti. La decisione di policy stessa deve essere verificata parallelamente nel Log Viewer. Per domande su firewall e NAT, spesso la combinazione di Log Viewer, Packet Capture e tcpdump è la più veloce.

Per errori NAT, è importante capire che NAT traduce il traffico ma non lo consente. La base appropriata è Comprendere NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT. Per tunnel IPsec, aiutano parallelamente Sophos Firewall IPsec VPN Troubleshooting e i log VPN appropriati.

Errori comuni e checklist

Errori tipici

• Cattura senza filtro: troppi dati, difficile da valutare. Restringere sempre con host, rete, porta o protocollo.
• Cattura non fermata: spazio di archiviazione e prestazioni possono soffrire. Usare -c o terminare correttamente il processo in background.
• Valutato solo any: un problema di interfaccia o tunnel resta nascosto. Dopo il primo hit confrontare in modo mirato interfaccia di ingresso e uscita.
• Solo direzione di andata controllata: problema di ritorno trascurato. Considerare entrambe le direzioni.
• Interfaccia sbagliata scelta: pacchetti rilevanti mancanti. Prima any, poi restringere su interfaccia specifica.
• PCAP condiviso non crittografato: dati sensibili possono essere esposti. Usare trasferimento sicuro e gruppo destinatari minimo.
• File lasciato dopo caso di supporto: consumo di spazio inutile e rischio dati. Eliminare il PCAP dopo il trasferimento.

Lista di controllo

• IP sorgente, IP di destinazione, porta e protocollo noti.
• Accesso SSH alla firewall configurato in modo sicuro.
• Deciso in anticipo se Log Viewer o WebAdmin Packet Capture sarebbero sufficienti.
• Filtro scelto il più stretto possibile.
• Cattura limitata con -c o processo di arresto chiaro.
• Per domande su interfacce, confrontato prima any e poi interfaccia di ingresso e uscita.
• File PCAP scritto solo se necessario.
• Problema riprodotto specificamente durante la cattura.
• Ora del test documentata.
• Log Viewer controllato parallelamente.
• Rule ID, NAT ID, Drop Reason o Service Log annotati, se visibili.
• PCAP trasferito in modo sicuro.
• File PCAP temporaneo rimosso dalla firewall.

FAQ