Disclaimer
Questo vuole essere una serie di articoli su un argomento particolarmente articolato che, per non renderlo oltremodo prolisso, vorrei dividere in “puntate”. Questa è la puntata numero uno.
Cos’è
Quando di parla di DNS amplification si fa riferimento a un attacco di tipo DDoS volumetrico dove un aggressore sfrutta una funzionalità dei resolver DNS aperti per sovraccaricare una rete o un server di destinazione con una quantità amplificata di traffico, rendendo il server e l’infrastruttura circostante inaccessibili.
Per iniziare a capirlo un po’ meglio ho trovato un paragone estremamente azzeccato sul sito di Cloudflare
Un singolo bot di un attacco di amplificazione DNS può essere paragonato a una situazione in cui un adolescente in vena di scherzi chiami un ristorante ordinando l’intero menu e chieda poi di ricevere una telefonata di conferma in cui venga ripetuta ogni voce dell’ordine. Quando il ristorante chiede il numero da richiamare, gli viene fornito quello della vittima designata. Così la vittima riceverà una chiamata dal ristorante con una marea di informazioni non richieste.
Cloudflare
In particolar modo è indispensabile capire cosa si intende per “amplification” e cioè che cosa viene amplificato in questo attacco, per farlo bisogna iniziare a capire come funziona.
Come funziona
L’amplificazione consiste nella differenza tra i byte che l’attaccante trasmette alla vittima e quelli che la vittima trasmette indietro. In altre parole è il rapporto tra la banda necessaria per eseguire l’attacco e la banda che viene consumata sul/i server della vittima. Considerando che una query DNS può occupare al minimo 8 byte e la risposta può occupare al massimo 512 byte è possibile calcolare il cosiddetto “fattore di amplificazione” teorico di 64 volte. Effettuando query di dimensione minima si obbliga il server DNS a occupare una larghezza di banda di 64 volte superiore a quella dell’attaccante. Nei casi reali si assume che il fattore di amplificazione del protocollo DNS sia 60.
Inoltre, siccome il protocollo DNS viaggia prevalentemente su UDP, è anche facile contraffare il mittente del pacchetto in quanto l’UDP non richiede un handshake (come nel caso del TCP).
Nella pratica
L’attaccante, mediante una richiesta dove viene modificato l’IP sorgente, inoltra la query DNS verso il server DNS interno. Questo – non avendo in cache la risposta – inoltra al server autoritativo la query. Il server autoritativo risponde al server DNS precedente il quale inoltrerà la risposta alla vittima.
Vien da se che un grande numero di richieste possono generare un traffico molto ingente il quale potrebbe portare ad un fermo del servizio causato dal “flooding” di traffico da dover gestire.
Azioni di mitigazione
Qua iniziano le brutte notizie: sono complesse e non possono essere sempre gestite localmente in quanto la problematica non è legata al servizio in sè quanto alla connettività.
Sicuramente mettere in campo soluzioni Anti-DDoS/CDN è fondamentale per individuare l’attacco il prima possibile.
Se quanto messo in campo non dovesse essere sufficiente (ed in strema ratio) è possibile limitare l’effetto degli attacchi accettando una certa percentuale di disservizio. Nel caso in cui la vittima fosse in grado di richiedere intervento del suo provider è possibile richiedere il blocco del traffico proveniente da una subnet o da un AS accettando, quindi, di fare a meno di tutto il traffico (sia malevolo che lecito) proveniente dal segmento di rete identificato.
Altre azioni di mitigazione, nel caso in cui foste voi a gestire il server DNS attaccato, potrebbero essere:
- limitare il numero di risposte che il server può fornire in un determinato lasso di tempo
- limitare la ricorsività delle query a determinate sottoreti note
- implementare una lista di IP autorizzati ad accedere al servizio
Qua termina la prima puntata, nelle prossime andrò ad effettuare una POC per rendere più chiaro quanto scritto fin’ora.
EOF