Attacchi di amplificazione DNS: l'abuso dei resolver aperti

Un flood diretto richiede che l'attaccante possieda la banda che riversa sul bersaglio. Un attacco di riflessione no. L'attaccante invia un flusso modesto di piccole richieste a molti server di terze parti, e quei server inviano le grandi risposte alla vittima. Il DNS è da anni uno dei protocolli preferiti per questo scopo, perché i server DNS rispondono a chiunque e le risposte possono essere molto più grandi delle domande. Questo articolo spiega il meccanismo, mostra quanta amplificazione hanno misurato i ricercatori e illustra le difese documentate dall'IETF.

Il meccanismo in tre passaggi

1. 1

   Falsificare l'indirizzo sorgente

   L'attaccante invia una piccola query DNS via UDP e scrive l'indirizzo della vittima come mittente. UDP non ha un handshake, quindi nulla lungo il percorso verifica quella dichiarazione.

2. 2

   Chiedere qualcosa di grande

   Una query di tipo ANY con EDNS(0) può restituire tutti i record che un nome contiene, fino a 4.096 byte su UDP. Rossow (2014) osserva che un attaccante può perfino configurare un dominio da lui controllato in modo che il suo server autorevole restituisca risposte di esattamente 4.096 byte. I resolver le mettono in cache per la durata del TTL, quindi il server dell'attaccante quasi non nota il carico.

3. 3

   Lasciare che sia il resolver a inviare

   Ogni resolver risponde all'indirizzo falsificato. Migliaia di resolver insieme sommergono la vittima di risposte DNS dall'aspetto valido provenienti da server legittimi, e il vero attaccante resta nascosto.

Quanta amplificazione?

Rossow definisce il fattore di amplificazione della banda (BAF) come i byte di payload UDP che un amplificatore invia alla vittima divisi per i byte di payload UDP che l'attaccante gli ha inviato, escludendo gli header Ethernet, IP e UDP. I normali lookup di record A o MX amplificano poco. Le cifre qui sotto riguardano l'abuso del DNS basato su ANY, accanto ad altri tre protocolli misurati nello stesso studio del 2014. «Primo 10%» è la media calcolata sul decimo di amplificatori che rispondono con le risposte più grandi.

Il DNS non è né il maggior amplificatore né l'unico, ma è il più noto. Rossow ha stimato circa 7,8 milioni di resolver aperti estrapolando da una scansione di un campione casuale di un milione di indirizzi IPv4, e ha identificato almeno 255.819 server autorevoli, un limite inferiore, quindi il bacino di potenziali riflettori era enorme. La cifra dei server autorevoli nella tabella è stata misurata sui 1.404 di quei server che adottano il DNSSEC per almeno un dominio, e la cifra dei resolver aperti l'ha misurata con un dominio da lui controllato. La sua analisi ha riguardato più di 130 attacchi reali, e cita tre grandi incidenti: 167 Gb/s nel maggio 2012, 300 Gb/s contro Spamhaus nel marzo 2013 e 100 Gb/s nell'agosto 2013. In ciascuno, gli attaccanti hanno abusato di resolver DNS aperti con richieste ANY. Sono misurazioni del 2013 e del 2014; i numeri cambiano, il meccanismo no.

L'aritmetica dell'effetto leva

Poiché il fattore divide ciò che la vittima riceve per ciò che l'attaccante invia, la banda di cui un attaccante ha bisogno è l'obiettivo diviso per il fattore. Alla media di 28,7 per i resolver aperti, un flood da 1 Gb/s richiede circa 35 Mb/s di query falsificate. Alla cifra di 98,3 per il decimo di server autorevoli con i valori più alti, ne servono circa 10 Mb/s. Per la cifra più alta di NTP, 4.670, l'abstract di Rossow indica lo 0,02 per cento della banda che l'attaccante vuole far ricevere alla vittima. Il fattore ignora gli header dei pacchetti, quindi il traffico reale differisce in parte, ma il punto è l'effetto leva: un uplink modesto diventa un flood.

Perché la causa di fondo è lo spoofing

Un attacco di riflessione funziona solo se i pacchetti falsificati possono uscire dalla rete dell'attaccante. Kührer e colleghi (2014) hanno studiato direttamente questo aspetto. Il loro test remoto ha rivelato fino a 2.692 sistemi autonomi privi di egress filtering, e Rossow cita il risultato dello Spoofer Project secondo cui il 25 per cento dei sistemi autonomi consentiva lo spoofing degli indirizzi a luglio 2013. Lo stesso studio riporta che, durante una campagna di notifica condotta con la comunità della sicurezza, il numero di server NTP vulnerabili all'amplificazione monlist è calato di oltre il 92 per cento, anche se gli autori dicono di non poter dimostrare che la campagna ne sia stata la causa.

Tre livelli di difesa

• Impedire ai pacchetti falsificati di lasciare la rete. Il BCP 38 (RFC 2827) descrive l'ingress filtering per sconfiggere gli attacchi denial-of-service che usano indirizzi sorgente falsificati, e il BCP 84 (RFC 3704) lo estende alle reti multihomed. È la correzione che rimuove la causa.
• Non gestire un resolver aperto. Il BCP 140 (RFC 5358) raccomanda di offrire la ricorsione solo ai client previsti, usando una access list basata sull'indirizzo sorgente, sull'interfaccia in ingresso o sulle query firmate (TSIG o SIG(0)). L'RFC 5358 osserva che scegliere i client in base all'interfaccia in ingresso si adatta ai router per piccoli uffici e per uso domestico con resolver ricorsivi incorporati, che non dovrebbero rispondere a tutta Internet.
• Rendere le risposte meno utili. L'RFC 8482 fornisce indicazioni per rispondere alle query ANY con risposte minime invece che con tutto ciò che il server contiene. I DNS Cookie (RFC 7873) offrono ai server un modo leggero per verificare i client e limitare gli abusi da parte di attaccanti off-path. L'RFC 7766 osserva che l'handshake TCP in genere impedisce lo spoofing degli indirizzi, il che rende TCP utile contro la riflessione e l'amplificazione, e che TCP è ormai ampiamente usato nel response rate limiting. Rossow avverte che attacchi costruiti con cura possono eludere un rate limiting progettato male, quindi questo integra il filtraggio del traffico falsificato e non lo sostituisce.

Verificare se il tuo resolver è aperto

Esegui il test da una rete che non è quella del resolver stesso, chiedendogli di risolvere un nome che non gestisce. Se ottieni una risposta, risponde anche a chi sta fuori. Un server solo autorevole di norma rifiuterà con REFUSED le query ricorsive su altre zone (i codici di risposta sono in Dentro un messaggio DNS).

dig @192.0.2.53 www.example.com A

Fonti e letture di approfondimento

• Christian Rossow, Amplification Hell: Revisiting Network Protocols for DDoS Abuse, NDSS Symposium, 2014
• Marc Kührer, Thomas Hupperich, Christian Rossow and Thorsten Holz, Exit from Hell? Reducing the Impact of Amplification DDoS Attacks, 23rd USENIX Security Symposium, 2014, pp. 111-125
• RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (Ferguson and Senie, 2000)
• RFC 3704: Ingress Filtering for Multihomed Networks (Baker and Savola, 2004)
• RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks (Damas and Neves, 2008)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• RFC 7873: Domain Name System (DNS) Cookies (Eastlake and Andrews, 2016)
• RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (Abley et al., 2019)