Quali tipi di vulnerabilità di sicurezza espone fornendo DNSSEC?

Avevo intenzione di firmare la mia zona DNS con DNSSEC. La mia zona, il registrar e il mio server DNS (BIND9) supportano tutti DNSSEC. L'unico che non supporta DNSSEC è il mio provider di nameserver secondario (ovvero buddyns.com ).

Sul loro sito web , lo affermano riguardo a DNSSEC:

BuddyNS non supporta DNSSEC perché espone ad alcune vulnerabilità non adatte a un servizio DNS ad alto volume.

Bene, ho pensato che l'uso di DNSSEC sia attualmente in qualche modo discutibile poiché la maggior parte dei resolver non controlla se i record sono firmati correttamente. Quello che non sapevo era che - secondo la loro dichiarazione - sembra che se avesse esposto le vulnerabilità di sicurezza di qualche tipo.

Quali sono quelle "vulnerabilità"?

DNSSEC presenta alcuni rischi, ma non sono direttamente correlati alla riflessione o all'amplificazione. L'espansione della dimensione del messaggio EDNS0 è un'aringa rossa in questo caso. Lasciatemi spiegare.

Qualsiasi scambio di pacchetti che non dipende da una precedente prova di identità è soggetto ad abuso da parte degli aggressori DDoS che possono utilizzare tale scambio di pacchetti non autenticato come riflettore e forse anche come amplificatore. Ad esempio, ICMP (il protocollo dietro "ping") può essere abusato in questo modo. Così come il pacchetto TCP SYN, che sollecita fino a 40 pacchetti SYN-ACK anche se il SYN è stato falsificato per provenire da una vittima che non desidera quei pacchetti SYN-ACK. E, naturalmente, tutti i servizi UDP sono vulnerabili a questo attacco, inclusi NTP, SSDP, uPNP e, come notato da altre risposte qui, incluso anche DNS.

La maggior parte degli apparecchi di rilevamento delle intrusioni, prevenzione delle intrusioni e bilanciamento del carico sono colli di bottiglia, incapaci di tenere il passo con il traffico "line rate". Inoltre, molti router non possono funzionare alla velocità della linea e alcuni switch. Questi colli di bottiglia, essendo la cosa più piccola "nel percorso" e più piccoli dei collegamenti stessi, sono il vero bersaglio di attacchi DDoS basati sulla congestione. Se riesci a tenere occupato il firewall di qualcuno con il traffico di attacco, allora il buon traffico non passerà, anche se i collegamenti non sono pieni. E ciò che rallenta un firewall non è il numero totale di bit al secondo (che può essere aumentato utilizzando messaggi più grandi, ed EDNS0 e DNSSEC lo faranno), ma piuttosto il numero totale di pacchetti al secondo.

Esistono molte leggende urbane sul modo in cui DNSSEC peggiora DDoS a causa delle dimensioni più grandi del messaggio di DNSSEC, e mentre ciò ha un senso intuitivo e "suona bene", è semplicemente falso. Ma se ci fosse un briciolo di verità in questa leggenda, la vera risposta sarebbe ancora altrove-- [perché DNSSEC utilizza sempre EDNS0, ma EDNS0 può essere utilizzato senza DNSSEC] e molte risposte normali non DNSSEC sono grandi quanto un DNSSEC la risposta sarebbe. Considerare i record TXT utilizzati per rappresentare i criteri SPF o le chiavi DKIM. O semplicemente qualsiasi grande set di indirizzi o record MX. In breve, nessun attacco richiede DNSSEC, e quindi qualsiasi attenzione a DNSSEC come rischio DDoS è energia non corretta.

DNSSEC ha dei rischi! È difficile da usare e più difficile da usare correttamente. Spesso richiede un nuovo flusso di lavoro per le modifiche dei dati di zona, la gestione dei registrar, l'installazione di nuove istanze del server. Tutto ciò deve essere testato e documentato e ogni volta che qualcosa si rompe in relazione al DNS, la tecnologia DNSSEC deve essere studiata come possibile causa. E il risultato finale se fai tutto nel modo giusto sarà che, come firmatario di una zona, i tuoi contenuti e sistemi online saranno più fragili per i tuoi clienti. In qualità di operatore di server remoto, il risultato sarà che i contenuti e i sistemi di tutti gli altri saranno più fragili per te. Questi rischi sono spesso considerati superiori ai benefici, poiché l'unico vantaggio è proteggere i dati DNS da modifiche o sostituzioni in volo. Quell'attacco è così raro da non valere tutto questo sforzo. Speriamo tutti che DNSSEC diventi onnipresente un giorno, grazie alle nuove applicazioni che consentirà. Ma la verità è che oggi, DNSSEC è tutto a costo, nessun vantaggio e con rischi elevati.

Quindi se non vuoi usare DNSSEC, questa è la tua prerogativa, ma non lasciare che nessuno ti confonda che il problema di DNSSEC è il suo ruolo di amplificatore DDoS. DNSSEC non ha alcun ruolo necessario come amplificatore DDoS; ci sono altri modi più economici di usare DNS come amplificatore DDoS. Se non vuoi usare DNSSEC, lascia che sia perché non hai ancora bevuto il Kool Aid e vuoi essere un ultimo mittente (in seguito) e non un primo in movimento (ora).

I server di contenuti DNS, a volte chiamati "server di autorità", devono essere prevenuti dall'essere abusati come amplificatori che riflettono il DNS, poiché DNS utilizza UDP e UDP è abusabile da pacchetti di origine falsificata. Il modo per proteggere il tuo server di contenuti DNS da questo tipo di abuso non è bloccare UDP, né forzare TCP (usando il trucco TC = 1), né bloccare QUALSIASI query, né rinunciare a DNSSEC. Nessuna di queste cose ti aiuterà. È necessario limitare il tasso di risposta DNS(DNS RRL), una tecnologia completamente gratuita che è ora presente in diversi server di nomi open source tra cui BIND, Knot e NSD. Non è possibile risolvere il problema di riflessione DNS con il firewall, poiché solo una middlebox sensibile al contenuto come il server DNS stesso (con l'aggiunta di RRL) conosce abbastanza la richiesta per essere in grado di indovinare con precisione cos'è un attacco e cosa no. Voglio sottolineare ancora una volta: DNS RRL è gratuito e tutti i server delle autorità dovrebbero eseguirlo.

In conclusione, voglio esporre i miei pregiudizi. Ho scritto la maggior parte di BIND8, ho inventato EDNS0 e ho co-inventato DNS RRL. Ho lavorato su DNS dal 1988 come 20 e qualcosa e ora sono scontroso 50 e qualcosa, con sempre meno pazienza per soluzioni cotte per problemi fraintesi. Ti prego di accettare le mie scuse se questo messaggio suona troppo come "hey ragazzi, scendete dal mio prato!"

Conosco due vulnerabilità specifiche. C'è la riflessione / amplificazione menzionata da Håkan. E c'è la possibilità di elencare le zone.

Riflessione / amplificazione

Reflection indica attacchi in cui le richieste con un IP di origine contraffatto vengono inviate a un server DNS. L'host che viene falsificato è la principale vittima dell'attacco. Il server DNS invierà inconsapevolmente la risposta a un host che non l'ha mai richiesta.

L'amplificazione si riferisce a qualsiasi attacco di riflessione in cui la risposta riflessa è costituita da più byte o più pacchetti rispetto alla richiesta originale. Prima dell'amplificazione DNSSEC + EDNS0 in questo modo si potevano inviare solo fino a 512 byte. Con DNSSEC + EDNS0 è possibile inviare 4096 byte, che in genere comprende 3-4 pacchetti.

Esistono possibili mitigazioni per questi attacchi, ma non conosco alcun server DNS che li implementa.

Quando l'IP client non è stato confermato, il server DNS può inviare una risposta troncata per forzare il client a passare a TCP. La risposta troncata può essere breve quanto la richiesta (o più breve se il client utilizza EDNS0 e la risposta no) che elimina l'amplificazione.

Qualsiasi IP client che completa un handshake TCP e invia una richiesta DNS sulla connessione può essere temporaneamente autorizzato. Una volta autorizzato, l'IP può inviare query UDP e ricevere risposte UDP fino a 512 byte (4096 byte se si utilizza EDNS0). Se una risposta UDP attiva un messaggio di errore ICMP, l'IP viene nuovamente rimosso dalla whitelist.

Il metodo può anche essere invertito usando una lista nera, il che significa che gli IP client possono eseguire query su UDP per impostazione predefinita, ma qualsiasi messaggio di errore ICMP fa sì che l'IP venga inserito nella lista nera che richiede una query TCP per uscire dalla lista nera.

Una bitmap che copre tutti gli indirizzi IPv4 rilevanti potrebbe essere memorizzata in 444 MB di memoria. Gli indirizzi IPv6 dovrebbero essere memorizzati in qualche altro modo.

Conteggio delle zone

In primo luogo, se l'enumerazione di zone sia una vulnerabilità è oggetto di dibattito. Ma se non vuoi che tutti i nomi nella tua zona siano di dominio pubblico, probabilmente lo considereresti una vulnerabilità. L'enumerazione delle zone può essere mitigata principalmente mediante l'uso dei record NSEC3.

Il problema che persiste anche quando si utilizza NSEC3 è che un utente malintenzionato può trovare l'hash di ciascuna etichetta semplicemente richiedendo nomi casuali. Una volta che l'attaccante ha tutti gli hash, un attacco di forza bruta off-line può essere eseguito su quegli hash.

Una difesa adeguata contro l'enumerazione della zona richiederebbe a un utente malintenzionato di eseguire una query sul server autorevole per ogni ipotesi. Tuttavia, tale difesa non esiste in DNSSEC.

La cosa che viene in mente non è in realtà specifica DNSSEC ma piuttosto sull'estensione EDNS0, su cui si basa DNSSEC.

EDNS0 consente payload UDP più grandi e payload UDP più grandi possono consentire attacchi di riflessione / amplificazione del traffico peggiori.

Non so quale sia la percentuale di validatori di validazione, ma il software di nameserver popolare sembra essere spedito con la validazione di default e si troveranno facilmente alcuni importanti fornitori di servizi che sono aperti sul fatto che stanno facendo la validazione, come Comcast e i resolver pubblici di Google.

Sulla base di questo, penso che la percentuale di validatori risolutori sia probabilmente in una forma significativamente migliore rispetto alla percentuale di zone firmate.