Amplificazione DNS: come un router aperto diventa un megafono (e come chiuderlo)

C’è un modo per trasformare un router innocuo in un megafono per colpire qualcun altro, senza entrarci dentro. Si chiama amplificazione DNS. In questo articolo lo vediamo dal vivo in laboratorio — 21 byte che ne diventano 1017 — guardiamo cosa bussa davvero alla porta del Dojo, e chiudiamo la falla. Nessun codice d’attacco: solo il meccanismo, osservato dalla parte di chi si difende.

Due parole su come funziona il DNS

Il DNS è la rubrica di internet: tu chiedi “che indirizzo ha esempio.it?” e un resolver ti risponde con il numero. La domanda e la risposta sono due pacchetti, quasi sempre su UDP, porta 53: uno va, uno torna, senza stabilire una connessione.

Una zona DNS non contiene solo indirizzi. Ci sono tanti tipi di record: A (IPv4), AAAA (IPv6), MX (posta), TXT (testo libero), NS (i server della zona). E, se la zona è firmata con DNSSEC — il meccanismo che aggiunge una firma crittografica alle risposte, così il client può verificare che non siano state manomesse — compaiono anche record grossi: RRSIG (le firme), DS, e soprattutto DNSKEY, che contiene le chiavi pubbliche con cui si verificano quelle firme.

Ed è qui il punto che ci interessa: una domanda tipo DNSKEY (o la vecchia ANY, “dammi tutto”) è piccola, ma la risposta può essere grossa, perché porta con sé più chiavi o più record. Domanda piccola, risposta grande: tienilo a mente.

Il trucco sta nell’UDP

L’UDP non ha stretta di mano. Quando mandi un pacchetto UDP, scrivi tu l’indirizzo del mittente, e nessuno lungo la strada lo verifica davvero: la rete si fida. Questo si chiama spoofing: falsificare il mittente.

Metti insieme le due cose — domanda piccola con risposta grande, e mittente falsificabile — e hai l’attacco:

• l’attaccante manda al resolver una domanda piccola (una DNSKEY), ma scrive come mittente l’indirizzo della vittima, non il suo;
• il resolver, gentile, risponde… alla vittima, con un pacchetto molto più grande;
• moltiplica per migliaia di domande al secondo, e da più resolver “aperti” contemporaneamente: la vittima annega sotto risposte che non ha mai chiesto.

L’attaccante spende poco (domande piccole), la vittima paga tutto (risposte grandi), e il resolver nel mezzo — magari il tuo router — ci mette la faccia e la banda. Per questo si chiama reflection (riflessione) e amplification (amplificazione).

È una debolezza del protocollo?

Sì e no, ed è la parte interessante. Non c’è un singolo “bug” del DNS da correggere: l’attacco mette insieme tre scelte di progetto, ognuna utile, e le usa storte.

• Il DNS viaggia su UDP per velocità: miliardi di piccole domande al giorno, senza l’onere della stretta di mano del TCP. È efficiente. Il rovescio è che l’UDP non verifica il mittente — ma quello è il carattere dell’UDP, non un errore.
• Le risposte grandi vengono da DNSSEC, cioè da una difesa: le chiavi e le firme (DNSKEY, RRSIG) servono a garantire che le risposte DNS non siano contraffatte. La “benzina” dell’amplificazione è letteralmente una funzione di sicurezza.
• Un resolver che risponde fa il suo mestiere. Il problema nasce solo quando risponde a chiunque da internet: è una configurazione sbagliata, non un difetto del protocollo.

La vera debolezza, quella che tiene in piedi tutto, è un’altra e non è del DNS: è che per internet girano pacchetti con mittente falsificato. Se nessuno potesse mentire sul proprio indirizzo (è la raccomandazione BCP38 di cui parliamo sotto), l’amplificazione non esisterebbe. Ecco perché non si “ripara” il DNS e basta: ci si difende non facendo da megafono, e a monte non lasciando passare i mittenti falsi.

In una riga: è come spedire mille cartoline con scritto il tuo indirizzo come mittente a mille aziende che rispondono con grossi cataloghi. La posta, i cataloghi e le aziende fanno cose normali; l’inganno è il mittente falso.

La prova in laboratorio: 21 byte che ne diventano 1017

In laboratorio ho acceso su un MikroTik il resolver “per tutti” (/ip dns set allow-remote-requests=yes) e gli ho fatto una sola domanda DNSKEY per il dominio org, catturando con lo sniffer. Ecco i due pacchetti veri:

20:44:15.801  172.31.255.254.58865 > 172.31.255.1.53   DNSKEY? org.          (21)    frame 63 B
20:44:15.802  172.31.255.1.53 > 172.31.255.254.58865   5/0/0 DNSKEY×5        (1017)   frame 1059 B

La domanda è 21 byte di DNS, la risposta 1017 (cinque record DNSKEY): quasi 48 volte più grande. Contando le intestazioni, sul filo sono 63 byte contro 1059: comunque quasi 17 volte. Immagina questa risposta moltiplicata e spedita a una vittima che non l’ha chiesta.

Nota tecnica: la vecchia domanda ANY oggi rende meno (i resolver la “minimizzano”, nel mio lab era circa 7×). Per questo gli attacchi moderni usano DNSKEY e le zone firmate con DNSSEC, dove le risposte restano grandi.

Cosa ci bussa davvero alla porta

Non è teoria. Lo sniffer sulla WAN del Dojo, mentre scrivo, vede arrivare questo, in continuazione:

<mittente-mascherato> > <nostro-IP>.53   ANY? dhitc.com   frame 80 B   (qtype 255)
… 111.115 domande come questa in un solo file di cattura

Qualcuno prova a usare il Dojo come megafono verso un dominio-esca (dhitc.com), con domande ANY da 80 byte, a raffica, da un blocco ristretto di indirizzi (li maschero: su UDP potrebbero essere falsificati, cioè essere la vittima e non l’attaccante). Il bersaglio, cioè il nostro indirizzo pubblico, l’ho mascherato anche quello.

La differenza con il laboratorio? Lì il resolver era aperto e rispondeva. Il gateway del Dojo, invece, queste domande le scarta in ingresso e non genera nulla: nessuna risposta parte, nessuna vittima viene colpita, e il router resta a CPU bassa (nell’ultima ora misurata: 128.622 domande scartate, CPU media 1,8%). Non rispondere è la difesa.

Vuoi vederlo dal vivo? Ho messo il router del Dojo in diretta: nella pagina Il Dojo sotto assedio vedi, in tempo reale, cosa sta bussando alla WAN in questo momento — compresa questa amplificazione DNS. E c’è un interruttore: puoi spegnere il firewall “per finta” e vedere con gli occhi cosa accadrebbe se il Dojo rispondesse — i missili che partirebbero verso le vittime — senza che succeda davvero. È il modo più diretto per capire cosa ferma la regola di drop, soprattutto con il DNS amp.

E ogni domenica mattina c’è il Bollettino d’assedio: un’ora di traffico reale raccontata minuto per minuto, con i numeri, i paesi e il verdetto di Suricata.

Come ci si difende

1. Non essere un resolver aperto

È la regola d’oro: il tuo router deve rispondere alle domande DNS solo di chi sta dentro la tua rete, mai a chi arriva da internet. Due mosse, meglio entrambe.

La prima: non offrire il resolver al mondo. Se non ti serve allow-remote-requests, tienilo spento; se ti serve per la LAN, chiudi comunque la porta dalla WAN con il firewall. Occhio all’ordine: in cima alla catena input ci va sempre l’accettazione del traffico di ritorno, poi i drop.

# sempre per prima: lascia rientrare le risposte alle connessioni del router stesso
/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="accept replies to the router's own connections"
add chain=input action=drop   connection-state=invalid comment="drop invalid"
# poi: nessuno dalla WAN può interrogare il resolver del router
add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop comment="DNS: never from the WAN (udp)"
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop comment="DNS: never from the WAN (tcp)"

(Al posto di ether1 metti la tua interfaccia WAN, o una interface-list tipo WAN.) Una domanda che viene spontanea: queste regole non bloccano la risoluzione DNS del router stesso? No, ed è una sottigliezza utile. Quando il router risolve per conto suo, la sua domanda esce verso la 53 di un server a monte; la risposta torna in input con destinazione una porta alta effimera, non la 53. I drop qui sopra matchano la destinazione 53, cioè solo le domande che arrivano al resolver del router: non toccano le risposte alle query del router (che rientrano con la prima regola, established) né i client della LAN (che interrogano il router dall’interfaccia LAN, non da ether1). Sul gateway del Dojo queste regole, nell’ora della cattura, hanno fermato le 128.622 domande di prima: leggi il contatore con /ip firewall filter print stats.

Non è teoria: guardando la connection table del gw mentre risolve per conto suo, le sue query escono così (l’IP pubblico l’ho mascherato):

<IP-WAN>:39613 -> 8.8.8.8:53
<IP-WAN>:45781 -> 8.8.8.8:53
<IP-WAN>:35633 -> 8.8.8.8:53

La porta sorgente è sempre una porta alta casuale (39613, 45781…), mai la 53: la risposta torna quindi su quella porta effimera, lontano dal nostro drop. E quella casualità non è un dettaglio da poco: è una difesa in più contro il cache poisoning. Per avvelenare la cache DNS — iniettare una risposta falsa prima di quella vera — un attaccante deve indovinare, oltre all’ID della transazione (16 bit), anche la porta sorgente: randomizzarla alza enormemente il muro. RouterOS lo fa di default, ed è il motivo per cui qui vedi porte sparse e non la 53 fissa.

2. UDP contro TCP: perché il TCP non si falsifica

Il trucco funziona perché l’UDP non verifica il mittente. Il TCP invece comincia con una stretta di mano a tre: chi apre la connessione deve ricevere la risposta del server per proseguire. Se hai falsificato il mittente, quella risposta va alla vittima, non a te, e la connessione non parte: con il TCP la reflection non funziona. I resolver seri sfruttano questo con il response rate limiting (RRL): quando sospettano un abuso, troncano la risposta UDP e obbligano il client a riprovare in TCP — un attaccante che falsifica il mittente non riesce a completare il TCP e si ferma. È una difesa dei resolver dedicati (BIND, Unbound); sul router la difesa pratica resta chiudere il resolver.

3. DoH e DoT: cosa risolvono (e cosa no)

DNS over HTTPS (DoH, porta 443) e DNS over TLS (DoT, porta 853) incapsulano il DNS dentro TLS: viaggia cifrato e su TCP. Due conseguenze: nessuno per strada può leggere o manomettere le tue domande, e — essendo su TCP — non sono un vettore di amplificazione. RouterOS può usare un server DoH a monte (/ip dns use-doh-server) per le proprie richieste. Attenzione però a non confondere i piani: DoH/DoT proteggono le tue richieste DNS; non impediscono da soli al tuo router di fare da megafono UDP. La difesa contro l’amplificazione resta non rispondere agli estranei sulla 53. (Il controllo opposto, impedire ai client di aggirare il tuo DNS con il DoH, è un altro tema: lo trovi nell’howto Bloccare DNS over HTTPS e DNS over TLS.)

4. A monte: il filtro anti-spoofing (BCP38)

La radice del problema è che l’UDP con mittente falsificato gira per internet. La raccomandazione ufficiale per fermarlo è BCP38 (documento IETF RFC 2827, “Network Ingress Filtering”): ogni operatore dovrebbe scartare i pacchetti in uscita dalla propria rete che hanno un mittente non appartenente a quella rete. Se fosse applicata ovunque, lo spoofing — e quindi l’amplificazione — sparirebbe. È una difesa “altruista” (ne beneficiano le vittime altrove, non chi la applica), per questo è adottata solo in parte; l’estensione per le reti multi-homed è il BCP84 (RFC 3704).

La tua parte la puoi fare: non lasciare che dalla tua rete escano mittenti falsi. Sul MikroTik si attiva il reverse-path filter

/ip settings set rp-filter=strict

che scarta i pacchetti il cui mittente non tornerebbe indietro da quell’interfaccia. La difesa tua resta non amplificare; questa è la parte che tocca a tutti: non far passare mittenti falsi.

La verifica

Dopo aver chiuso il resolver, riprova dall’esterno la stessa domanda: non deve arrivare risposta. In laboratorio, con allow-remote-requests=no, la DNSKEY org è andata in timeout; riaprendolo, tornavano i 1017 byte. E il contatore della regola di drop cresce a ogni tentativo scartato: è lì che vedi, numero alla mano, quante domande non hai amplificato.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable): resolver aperto, misura DNSKEY org 21→1017 byte (~48×) con cattura reale, difesa con allow-remote-requests=no e con le regole di drop in input. Il traffico in arrivo è osservato sulla WAN reale del Dojo (sniffer): indirizzi di terzi e indirizzo pubblico del Dojo mascherati, conteggi aggregati, nessuna risposta è mai stata generata verso vittime reali.

Domande frequenti

Il mio MikroTik è un resolver aperto senza saperlo?

Può esserlo se hai acceso allow-remote-requests=yes e non hai chiuso la porta 53 dalla WAN. Controlla con /ip dns print e con le regole di input del firewall. In dubbio, metti le due regole di drop di sopra.

Perché la risposta è più grande della domanda?

Perché la domanda chiede “tutto” o le chiavi DNSSEC, e la risposta porta più record (qui cinque DNSKEY). Pochi byte di domanda, tanti di risposta: è l’amplificazione.

Se scarto le domande DNS dalla WAN, rompo qualcosa?

No, se sulla WAN non devi fare da DNS pubblico (quasi nessuno deve). I tuoi client in LAN continuano a usare il resolver del router normalmente; blocchi solo gli estranei.

DoH mi protegge dall’amplificazione?

No, sono due cose diverse. DoH cifra e usa TCP, quindi protegge le tue richieste e non è un vettore di amplificazione, ma non impedisce al tuo router di rispondere agli estranei sulla UDP 53: quello lo fa il firewall.