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.

Device Console o Advanced Shell?

SFOS 22 offre due percorsi chiaramente distinti. Nella Device Console, tcpdump è un comando CLI Sophos documentato. L’Advanced Shell, invece, è una shell Linux con accesso completo ai componenti di sistema. Per una breve cattura in tempo reale, la Device Console è quindi l’opzione predefinita più sicura; l’Advanced Shell serve solo quando occorrono opzioni Linux, un nome file PCAP personalizzato, processi in background o operazioni sui file.

• Device Console: nel menu principale selezionare 4. Device Console. Digitare tcpdump e premere Tab per vedere gli argomenti disponibili oppure ? per visualizzarne la descrizione. SFOS 22 documenta, tra gli altri, count, filedump, hex, interface, llh, no_time e verbose. Un file creato con filedump viene salvato in /tmp.
• Advanced Shell: aprirla da 5. Device Management nel menu principale. Qui si applicano le opzioni Linux standard usate negli esempi Advanced Shell riportati più avanti. Sophos raccomanda espressamente prudenza perché la shell offre accesso completo al sistema. I file in /tmp vengono eliminati al riavvio del firewall.

Non mescolare i comandi delle due console: tcpdump count 100 ... appartiene alla Device Console, mentre tcpdump -c 100 ... appartiene all’Advanced Shell.

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

Percorso rapido nella Device Console

Per una breve cattura che termina automaticamente, accedere alla CLI, selezionare 4. Device Console ed eseguire, ad esempio, questo comando SFOS:

tcpdump count 100 'host 198.51.100.20 and port 443'

count 100 termina l’output dopo 100 pacchetti ricevuti. host 198.51.100.20 and port 443 è il filtro BPF e deve essere adattato alla destinazione o all’origine del proprio test. Per controllare una sola interfaccia, usare il relativo ID SFOS effettivo, ad esempio:

tcpdump interface Port2 count 100 'host 198.51.100.20 and port 443'

Prima dell’esecuzione, verificare sul proprio firewall gli argomenti disponibili e il relativo ordine digitando tcpdump e premendo Tab o ?. Ciò è particolarmente importante per filedump: SFOS salva l’output in /tmp, mentre la guida integrata mostra la sintassi locale esatta e il nome file generato. Se occorrono un nome file PCAP personalizzato e il successivo trasferimento del file, usare invece la procedura Advanced Shell seguente.

Eseguire tcpdump in tempo reale nell’Advanced Shell

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