TCPdump: installazione e utilizzo pratico su Linux

tcpdump: quando serve davvero e cosa non fa

tcpdump è lo strumento giusto quando devi vedere il traffico così com’è sul filo, senza passare da interpretazioni del browser, del proxy o dell’applicazione. Su Linux lo usi per capire se un problema è di DNS, di handshake TCP, di TLS, di routing, di MTU, di applicazione o di firewall. La sua forza non è la comodità: è il fatto che ti fa osservare il livello rete con precisione chirurgica.

Non risolve da solo un guasto, ma ti evita di andare a tentativi. Se un sito risponde lento, se un backend non parla con il database, se un client riceve reset improvvisi o se un servizio sembra “morto” ma i log non dicono nulla, tcpdump ti dà un riferimento oggettivo. Il punto è usarlo con criterio: cattura troppo ampia = rumore; cattura troppo stretta = falsi indizi.

Installazione su Linux: pacchetto minimo, zero fronzoli

Su quasi tutte le distribuzioni tcpdump è nei repository standard. Il pacchetto si chiama quasi sempre tcpdump, mentre la libreria di cattura è libpcap. In genere non devi compilare nulla a mano.

Debian, Ubuntu e derivate:

sudo apt update
sudo apt install tcpdump

RHEL, Rocky, AlmaLinux, CentOS Stream:

sudo dnf install tcpdump

Alpine:

sudo apk add tcpdump

Verifica subito che il binario sia presente e che la versione supporti le opzioni che ti servono:

tcpdump --version

Output atteso: versione del programma e della libreria pcap. Se il comando non esiste, il problema è banale: pacchetto non installato o path non aggiornato. Se invece parte ma cattura nulla, il tema è quasi sempre permessi, interfaccia sbagliata o filtro errato.

Permessi: perché tcpdump spesso richiede root e come ridurre il rischio

tcpdump ha bisogno di accedere alle interfacce di rete in modalità promiscua o comunque con privilegi sufficienti a leggere i pacchetti. Il modo più semplice è eseguirlo come root, ma su sistemi gestiti bene conviene limitare l’esposizione.

Prima di fare modifiche invasive, controlla se il tuo ambiente supporta la cattura con capability o con un gruppo dedicato. Su molte distro moderne puoi assegnare capacità al binario, ma questa è una scelta da fare con attenzione perché amplia il potere del processo. Se non hai un motivo preciso per cambiare i permessi, resta sul modello più semplice: esecuzione temporanea come root solo durante la diagnosi.

Per capire se l’utente corrente può catturare, prova:

tcpdump -D

Se ottieni l’elenco delle interfacce, l’accesso base c’è. Se ricevi errori di permission denied, non forzare workaround alla cieca: prima identifica il modello di autorizzazione del server. In ambienti multiutente o su host condivisi, la cattura di traffico è un dato sensibile quanto i log applicativi.

Le due domande da farsi prima di catturare

Prima di lanciare tcpdump, chiarisci due cose: quale interfaccia e quale flusso. Senza questa disciplina rischi di salvare gigabyte inutili o, peggio, di non vedere proprio il traffico che ti interessa.

Per scoprire le interfacce disponibili usa:

tcpdump -D

Su una macchina con bridge, VLAN, VPN o container, l’interfaccia giusta non è sempre quella “ovvia”. A volte il traffico passa su eth0, altre su ens192, su un veth, su docker0 o su un’interfaccia VLAN come eth0.100. Il nome corretto fa la differenza tra diagnosi e fumo.

Se non sai dove guardare, parti dal percorso del traffico: client esterno, edge, origin, backend. La cattura va fatta nel punto in cui vuoi provare o smentire un’ipotesi. Per esempio: se sospetti che il server non riceva le richieste, cattura sull’interfaccia pubblica; se il problema è tra web server e database, cattura sull’interfaccia interna o sul loopback, non sul link esterno.

Filtri: la parte che fa la differenza tra utilità e rumore

tcpdump usa filtri BPF, cioè filtri applicati prima di consegnarti i pacchetti. Questo è il motivo per cui puoi essere molto preciso senza ammazzare la macchina. Un filtro buono riduce CPU, I/O e tempo di analisi.

Le basi da ricordare sono semplici:

1. host: traffico da o verso un IP specifico
2. port: traffico su una porta
3. net: traffico su una subnet
4. and / or / not: logica booleana

Esempi pratici:

tcpdump -i eth0 host 203.0.113.10
tcpdump -i eth0 port 443
tcpdump -i eth0 net 192.0.2.0/24
tcpdump -i eth0 host 203.0.113.10 and port 443

Se devi vedere solo il traffico verso un backend MySQL:

tcpdump -i eth0 host 10.0.0.20 and port 3306

Se vuoi escludere il traffico locale o di management:

tcpdump -i eth0 not host 10.0.0.5

Un dettaglio che molti ignorano: il filtro tra apici va protetto dalla shell. Non è un vezzo, è prevenzione. Quando il filtro diventa complesso, usa sempre virgolette singole o doppie in modo coerente, altrimenti la shell ti interpreta operatori e parentesi prima di tcpdump.

Primi comandi utili: vedere subito se passa qualcosa

Per una verifica rapida, avvia una cattura minimale e leggibile. Non scrivere subito su file se non serve: prima capisci se il traffico c’è.

sudo tcpdump -i eth0 -n

L’opzione -n evita la risoluzione DNS. È importante: senza -n potresti confondere il tempo di analisi con il tempo necessario a risolvere nomi. In troubleshooting, la risoluzione automatica è rumore.

Per vedere anche i numeri di porta senza convertire in servizi:

sudo tcpdump -i eth0 -n -nn

-nn è la scelta più onesta quando vuoi leggere esattamente IP e porte. Se compare traffico, hai già una risposta: il layer di rete sta passando. Se non compare nulla, il problema può essere l’interfaccia, il filtro o la direzione del traffico.

Per ridurre il rumore e vedere solo un host:

sudo tcpdump -i eth0 -n host 198.51.100.25

Per una porta specifica:

sudo tcpdump -i eth0 -n port 22

Per una finestra temporale manuale breve, lancia il comando e fermalo con Ctrl+C. Il riepilogo finale ti dà pacchetti catturati, ricevuti dal kernel e persi. Se i pacchetti persi iniziano a salire, la cattura è troppo pesante o il server è già sotto stress.

Analisi leggera: cosa guardare nell’output live

L’output live di tcpdump non è pensato per essere “bello”, ma per farti riconoscere pattern. Alcuni elementi sono più importanti di altri:

1. timestamp: ordine e frequenza degli eventi
2. IP sorgente e destinazione: direzione del flusso
3. flags TCP: SYN, ACK, RST, FIN
4. porta sorgente e porta destinazione: ruolo client/server
5. lunghezza del pacchetto: utile per capire se c’è payload o solo handshake

Un esempio classico: se vedi SYN in uscita e nessun SYN/ACK in risposta, il problema è a valle della richiesta: routing, firewall, servizio non in ascolto o filtro upstream. Se vedi invece RST immediato dal server, il servizio è raggiungibile ma non accetta quella connessione o quella porta.

Per osservare solo il traffico TCP verso un endpoint:

sudo tcpdump -i eth0 -n tcp and host 10.0.0.20

Se vuoi vedere i flag con dettaglio maggiore:

sudo tcpdump -i eth0 -nnvvv tcp and host 10.0.0.20

L’opzione -v aumenta il dettaglio, -vv e -vvv lo spingono oltre. Non abusarne: più verbosità non significa più chiarezza. Usala quando stai cercando campi specifici, come TTL, window size, opzioni TCP o frammentazione.

Cattura su file: quando devi fermare il tempo e analizzare dopo

Se il problema è intermittente o devi condividere l’evidenza con un collega, salva su file pcap. È il formato giusto per riaprire la cattura con Wireshark o per fare analisi successive senza tenere un terminale aperto.

sudo tcpdump -i eth0 -n -w /tmp/capture.pcap

Questo non produce output leggibile a schermo perché scrive il flusso grezzo su file. Per una cattura più controllata, limita il numero di pacchetti o la durata con strumenti esterni. Un approccio pratico è fermare manualmente dopo aver raccolto il campione necessario.

Per leggere un file catturato senza aprire GUI:

tcpdump -nn -r /tmp/capture.pcap

Se il file è grande, puoi filtrarlo in lettura con gli stessi criteri usati in cattura:

tcpdump -nn -r /tmp/capture.pcap host 10.0.0.20 and port 443

Una nota operativa: il file pcap può contenere dati sensibili, comprese credenziali in chiaro se il protocollo lo consente o metadati utili a ricostruire sessioni. Trattalo come artefatto sensibile, mettilo in una directory protetta e cancellalo quando non serve più.

Tre scenari reali dove tcpdump ti fa risparmiare ore

1. DNS che sembra lento ma non lo è

Un’applicazione sembra impiegare troppo a connettersi a un host remoto. Prima ipotesi: DNS. Prima di toccare resolver e cache, verifica se la richiesta esce davvero e quanto tempo impiega la risposta a rientrare.

sudo tcpdump -i eth0 -n port 53

Se vedi query ma nessuna risposta, il problema è nel percorso verso il resolver o nel resolver stesso. Se vedi risposte immediate ma l’app resta lenta, il collo di bottiglia è altrove. In pratica, tcpdump ti separa il tempo di rete dal tempo di applicazione.

2. HTTPS che fallisce prima ancora del login

Quando il browser mostra errore di connessione o handshake TLS fallito, la tentazione è guardare subito il certificato. Ma la sequenza corretta è più ampia: TCP, poi TLS, poi applicazione.

sudo tcpdump -i eth0 -n host 203.0.113.10 and port 443

Se vedi SYN, SYN/ACK, ACK e poi niente, il problema è probabilmente nel TLS o nel layer applicativo. Se il client manda RST o il server risponde con alert TLS, hai una pista concreta. In molti casi il certificato non è il vero problema: è la catena, il SNI, la configurazione del virtual host o un proxy che interrompe la sessione.

3. Backend e database che “si vedono” ma non lavorano

Se il web server parla con il database ma le query sembrano bloccate, cattura sul canale interno. Qui tcpdump serve a misurare se la connessione resta viva, se ci sono retransmit, se i pacchetti vengono tagliati o se il DB chiude la sessione.

sudo tcpdump -i eth0 -n host 10.0.0.30 and port 3306

Se noti ritrasmissioni frequenti, il problema può essere latenza, perdita di pacchetti o saturazione. Se vedi connessioni aperte e chiuse di continuo, magari l’app non usa pooling o sta esaurendo le connessioni disponibili. Il traffico racconta la storia che i soli log applicativi spesso non mostrano.

Opzioni che vale la pena conoscere davvero

Ci sono alcune opzioni che tornano utili in quasi ogni sessione di troubleshooting:

1. -i per scegliere l’interfaccia
2. -n e -nn per evitare risoluzioni inutili
3. -w per scrivere su file
4. -r per leggere un file pcap
5. -c per fermarsi dopo N pacchetti
6. -s per impostare la snap length

La snap length merita attenzione. Se catturi solo i primi byte di ogni pacchetto, puoi perdere payload e rendere l’analisi parziale. D’altra parte, catturare tutto su un link molto trafficato può costare risorse inutili. In troubleshooting ordinario, lascia il default o imposta un valore adeguato quando sai esattamente cosa ti serve.

sudo tcpdump -i eth0 -n -c 50

Questo esempio cattura solo 50 pacchetti: utile per una verifica veloce, un test di reachability o una fotografia rapida del traffico. Non usarlo per eventi intermittenti rari: in quel caso meglio scrivere su file e monitorare fino a intercettare il problema.

Buone pratiche operative: non trasformare tcpdump in un problema

tcpdump è leggero, ma una cattura fatta male può comunque creare disturbo. Su sistemi sotto carico conviene seguire alcune regole semplici.

1. Filtra il più possibile già in cattura.
2. Evita di lasciare sessioni aperte più del necessario.
3. Salva i file pcap in una directory protetta e tracciane il ciclo di vita.
4. Non catturare traffico sensibile senza un motivo preciso e un perimetro chiaro.
5. Se devi condividere un pcap, valuta di redigere dati personali o segreti prima di distribuirlo.

In ambienti con compliance o dati regolamentati, la cattura di rete è osservabilità, non curiosità. Va trattata come un elemento di audit: chi l’ha fatta, quando, su quale host, con quale scopo, e dove sono finiti i file.

Un flusso di lavoro pratico per troubleshooting serio

Quando devi diagnosticare un problema vero, usa una sequenza ripetibile invece di improvvisare. Una procedura solida è questa:

1. Definisci il layer sospetto: DNS, edge, origin, app, DB o storage.
2. Identifica l’interfaccia dove il traffico dovrebbe comparire.
3. Applica un filtro minimo ma utile.
4. Verifica se il traffico esce, rientra o si interrompe.
5. Solo dopo, amplia il perimetro o cambia punto di cattura.

Per esempio, se un servizio web non risponde, non partire da una cattura globale di tutto il server. Parti da HTTP/HTTPS sul link corretto, poi passa al traffico verso il backend o al loopback se il proxy è locale. Il valore di tcpdump non è “vedere tutto”: è vedere il pezzo giusto nel momento giusto.

Conclusione operativa: cosa tenere a mente

tcpdump resta uno degli strumenti più utili su Linux perché ti dà una vista diretta del traffico, senza filtri applicativi e senza ipotesi comode ma sbagliate. Installarlo è semplice, usarlo bene richiede disciplina: interfaccia corretta, filtro preciso, attenzione ai permessi e una lettura ragionata dei pacchetti.

Se lo usi come “registratore di bordo” per la rete, ti aiuta a distinguere tra sintomo e causa. Ed è proprio lì che si risparmia tempo: non nel catturare più pacchetti possibile, ma nel catturare quelli che contano.