~/docs/DNS_amplification.pcap

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 inoltra le query DNS verso il server DNS autoritativo del servizio target, di conseguenza, il servizio risponderà con un ugual numero di DNS answer.

Un attaccante in grado di generare un traffico pari a 1/61 della banda a disposizione del server DNS (immaginiamo una rete botnet composta da centinaia di client zombie) può quindi inibire l’accesso al servizio DNS del sistema target rendendo di fatto non accessibile il servizio in quanto impossibilitati a risolvere il nome di dominio.

Come abbiamo detto poco fa, potendo contraffare l’IP di sorgente, gli attacchi potrebbero apparire distribuiti pur provenendo dalla stessa sorgente fisica rendendo di fatto le azioni di mitigazione complesse. Di fatto, ogni AS potrebbe essere di per sé connesso all’AS in cui si trova il servizio target o comunque potrebbe raggiungerlo tramite diverse “strade”, pertanto la presenza di più nodi fisici su più AS moltiplica i possibili punti di accesso al servizio.

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:

  1. limitare il numero di risposte che il server può fornire in un determinato lasso di tempo
  2. limitare la ricorsività delle query a determinate sottoreti note
  3. 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

Rispondi