↓ Skip to main content
u-random
u-random
  1. Comandi/

tcpdump - dump traffic on a network

·6 mins
base
Observability
Alessio Barnini
Author
Alessio Barnini
Table of Contents
tcpdump - dump traffic on a network

Cosa fa
#

Cattura pacchetti di rete sull'interfaccia specificata e li mostra in tempo reale o li salva su file .dfir. Permette di vedere tutto il traffico che passa sulla rete — handshake TCP, query DNS, richieste HTTP, ARP — a livello di singolo pacchetto.

Sintassi
#

sudo tcpdump [opzioni] [filtro]

Richiede sudo — legge direttamente dal kernel.

Comandi essenziali
#

ComandoFlagSignificato flagCosa fa
sudo tcpdump -i enp0s1-iinterfaceAscolta su interfaccia specifica
sudo tcpdump -i enp0s1 -n-nnumericNon risolve IP in nomi DNS — piu' veloce
sudo tcpdump -i enp0s1 -nn-nnnumeric numericNon risolve ne' IP ne' porte (22 invece di ssh)
sudo tcpdump -D-DdevicesLista tutte le interfacce disponibili
sudo tcpdump -w capture.dfir-wwriteSalva su file invece di stampare
sudo tcpdump -r capture.dfir-rreadLegge da file .dfir
sudo tcpdump -c 100-ccountCattura solo N pacchetti poi si ferma
sudo tcpdump -v-vverbosePiu' dettagli su ogni pacchetto
sudo tcpdump -A-AASCIImostra il payload di ogni pacchetto in testo leggibile invece di solo header e flag

Filtri — la parte piu' importante
#

I filtri si mettono alla fine del comando. Senza filtri vedi tutto — con filtri vedi solo quello che serve.

# Filtra per host
sudo tcpdump -i enp0s1 -n host 192.168.64.200

# Filtra per porta
sudo tcpdump -i enp0s1 -n port 22
sudo tcpdump -i enp0s1 -n port 53        # solo DNS

# Filtra per protocollo
sudo tcpdump -i enp0s1 -n tcp
sudo tcpdump -i enp0s1 -n udp
sudo tcpdump -i enp0s1 -n icmp           # solo ping

# Combinazioni con and/or
sudo tcpdump -i enp0s1 -n 'tcp and host 192.168.64.200'
sudo tcpdump -i enp0s1 -n 'port 80 or port 443'

# Filtra per flag TCP — rileva SYN scan o SYN flood
sudo tcpdump -i enp0s1 'tcp[tcpflags] & tcp-syn != 0'

Leggere l'output
#

14:21:56.534761 IP 192.168.64.200.38282 > 192.168.64.3.22: Flags [S], seq 2676348498, win 64240, length 0
#     ^               ^          ^             ^        ^        ^         ^
#  timestamp       IP src     porta src    IP dst  porta dst   flag    seq number

Formato: timestamp IP sorgente.porta > destinazione.porta: Flags [X], length N

I flag piu' comuni in ordine di frequenza:

[S]    SYN      — inizio connessione
[.]    ACK      — conferma
[S.]   SYN+ACK  — risposta al SYN
[P.]   PSH+ACK  — dati in arrivo
[F.]   FIN+ACK  — chiusura elegante
[R]    RST      — reset brusco
[R.]   RST+ACK  — reset con conferma
FlagNome completoTraduzioneSignificato operativo
SYNSynchronizeSincronizzaApre la connessione — "voglio parlare con te"
ACKAcknowledgeConferma"Ho ricevuto quello che mi hai mandato"
PSHPushSpingi"Consuma questi dati subito, non aspettare"
RSTResetReimposta"Chiudo tutto immediatamente, basta"
FINFinishFinisci"Ho finito di mandare dati, chiudo il mio lato"
URGUrgentUrgente"Questi dati sono prioritari — raramente usato"

Combinazioni utili
#

# Vedi tutto il traffico tra due VM (lab Kali-Ubuntu)
sudo tcpdump -i enp0s1 -n host 192.168.64.200

# Cattura e salva per analisi dopo con Wireshark
sudo tcpdump -i enp0s1 -w /tmp/capture.dfir

# Cattura solo i primi 200 pacchetti e salva
sudo tcpdump -i enp0s1 -c 200 -w /tmp/capture.dfir

# Leggi il dfir salvato
sudo tcpdump -r /tmp/capture.dfir -n

# Rileva port scan in corso — molti SYN senza completamento
sudo tcpdump -i enp0s1 -n 'tcp[tcpflags] & tcp-syn != 0 and not tcp[tcpflags] & tcp-ack != 0'

Pattern riconoscibili
#

PING (ICMP)
  IP kali > ubuntu: ICMP echo request
  IP ubuntu > kali: ICMP echo reply

ARP (prima di qualsiasi comunicazione)
  ARP, Request who-has 192.168.64.3 tell 192.168.64.200
  ARP, Reply 192.168.64.3 is-at b6:56:08:90:16:03

CONNESSIONE SSH (handshake completo)
  Flags [S]   → SYN
  Flags [S.]  → SYN+ACK
  Flags [.]   → ACK
  Flags [P.]  → dati SSH

PORT SCAN nmap -sS (SYN scan)
  Porta aperta:  [S] → [S.] → [R]   (nmap manda RST)
    esempio flusso
    19  Kali → Ubuntu:22  [SYN]
	21  Ubuntu → Kali     [SYN, ACK]
	23  Kali → Ubuntu:22  [RST]
	
  Porta chiusa:  [S] → [R.]          (Ubuntu manda RST)
  
  
  RST può mandarlo chiunque. Kali lo manda per chiudere il SYN scan. Ubuntu lo manda quando una porta è chiusa. Due situazioni diverse, stesso flag.

Pattern: chiusura elegante con FIN
#

FIN viene mandato da entrambi i lati — ognuno dichiara che ha finito di mandare dati. La sequenza completa si chiama four-way handshake di chiusura:

# Output reale — netcat Kali verso Ubuntu porta 8080

# Apertura (three-way handshake)
Flags [S]    Kali → Ubuntu    SYN — voglio connettermi
Flags [S.]   Ubuntu → Kali    SYN+ACK — ok
Flags [.]    Kali → Ubuntu    ACK — confermato

# Dati
Flags [P.]   Kali → Ubuntu    PSH+ACK — "ciao" (lunghezza 5)
Flags [.]    Ubuntu → Kali    ACK — ricevuto

# Chiusura elegante (four-way handshake)
Flags [F.]   Kali → Ubuntu    FIN+ACK — ho finito di mandare
Flags [F.]   Ubuntu → Kali    FIN+ACK — anch'io ho finito
Flags [.]    Kali → Ubuntu    ACK — confermato

Entrambi i lati mandano FIN — ognuno chiude il proprio lato della connessione separatamente.

Confronto con chiusura brusca:

FIN  →  four-way handshake — entrambi confermano
         connessione chiusa ordinatamente
         tipico di sessioni normali

RST  →  chiusura immediata senza accordo
         connessione tagliata di netto
         tipico di: porta chiusa, nmap SYN scan,
         errore di connessione

Dal punto di vista Blue Team:

Molti FIN   → traffico normale, sessioni che terminano
Molti RST   → segnale sospetto:
              - port scan in corso
              - servizio che crasha
              - firewall che blocca

Scenario Reale
#

Durante un incident response, un analista deve capire se una macchina interna sta comunicando con un IP sospetto esterno:

# Cattura tutto il traffico verso quell'IP
sudo tcpdump -i enp0s1 -n host 185.220.101.x -w /tmp/sospetto.dfir

# Analizza il dfir
sudo tcpdump -r /tmp/sospetto.dfir -n

# Cerca flag anomali — molti SYN senza ACK = possibile scan o flood
sudo tcpdump -r /tmp/sospetto.dfir 'tcp[tcpflags] & tcp-syn != 0'

Quello che vedi in tcpdump i log applicativi non vedono — un SYN scan non lascia tracce in auth.log. tcpdump e' il livello di verita'.

Dove l'ho usato
#

  • Settimana 5 — lab Kali-Ubuntu, TCP handshake in diretta
  • Settimana 5 — port scan nmap -sS catturato e analizzato

Note personali
#

Tip

Aggiungi sempre -n o -nn — senza, tcpdump perde tempo a risolvere ogni IP in nome DNS e l'output e' piu' lento e rumoroso.

Note

tcpdump e Wireshark leggono lo stesso formato .dfir. Cattura con tcpdump da terminale, analizza con Wireshark in GUI — flusso di lavoro standard in un SOC.

Collegato a
#

  • log — categoria
  • incidents — categoria
  • tcp-handshake — i flag che leggi nell'output
  • nmap — il tool che genera i pattern di scan
  • wireshark — GUI per analizzare i .dfir salvati con -w
  • ss — complementare: ss guarda dentro la macchina, tcpdump guarda il filo

Related