Complessità del DNSSEC e considerazioni

Il DNS è suddiviso in parti più piccole chiamate zone. Una zona inizia tipicamente con un nome di dominio e contiene tutti i record relativi ai sottodomini. Ogni zona è gestita da un singolo responsabile. Ad esempio, cloudflare.com è una zona che contiene tutti i record DNS per cloudflare.com e i suoi sottodomini (ad esempio, www.cloudflare.com, api.cloudflare.com).

Non esiste un servizio di directory per i sottodomini nel DNS, quindi se vuoi sapere se api.cloudflare.com esiste, dovrai chiedere questa informazione a un server DNS e questo server DNS a sua volta chiederà a cloudflare.com se api.cloudflare.com esiste. Ciò non si verifica con il protocollo DNSSEC. In alcuni casi, l'abilitazione del DNSSEC può rivelare contenuti di zona altrimenti oscurati. Non tutti si preoccupano della segretezza dei sottodomini e il contenuto della zona può già essere facilmente intuibile perché la maggior parte dei siti ha un sottodominio "www"; tuttavia, i sottodomini sono talvolta utilizzati come portali di login o altri servizi che il proprietario del sito vuole mantenere privati. Il proprietario del sito potrebbe non voler rivelare che "secretbackdoor.example.com" esiste per proteggere quel sito dagli autori di attacchi.

Il motivo per cui il DNSSEC può esporre i sottodomini è legato alla modalità di firma delle zone. Storicamente, il protocollo DNSSEC viene utilizzato per firmare le zone statiche. Una zona statica è un insieme completo di record per un determinato dominio. I record di firma DNSSEC vengono creati utilizzando le due chiavi Key Signing Key (KSK) e Zone Signing Key (ZSK) in una posizione centrale e vengono inviati al server autoritativo perché siano pubblicati. Questo insieme di record consente a un server autorevole di rispondere a qualsiasi domanda gli venga posta, comprese quelle relative a sottodomini che non esistono.

Quando un sottodominio non esiste, a differenza del DNS standard in cui il server restituisce una risposta NXDOMAIN (Non-Existent Domain) non firmata, DNSSEC garantisce che ogni risposta sia firmata. Ciò avviene con un record speciale che funge da prova di non esistenza, chiamato record NextSECure (NSEC). Un record NSEC può essere utilizzato per dire: "non ci sono sottodomini tra il sottodominio X e il sottodominio Y". Riempiendo il vuoto tra ogni dominio della zona, NSEC fornisce un modo per rispondere a qualsiasi domanda con un record statico. Il record NSEC elenca anche i tipi di record di risorse esistenti per ciascun nome.

Per le zone firmate staticamente, per definizione esiste un numero fisso di record. Poiché ogni record NSEC punta al successivo, si ottiene un "anello" finito di record NSEC che copre tutti i sottodomini. Chiunque può "camminare" in una zona seguendo un record NSEC all'altro fino a conoscere tutti i sottodomini. Questo metodo può essere usato per rivelare tutti i nomi di quella zona, esponendo eventualmente informazioni interne.

Si supponga che esista una zona abilitata al protocollo DNSSEC chiamata example.com, con i sottodomini public.example.com e secret.example.com. L'aggiunta di record NSEC rivelerà l'esistenza di tutti i sottodomini.

Chiedendo il record NSEC di example.com si ottiene quanto segue:

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

La richiesta di public.example.com fornisce il seguente record NSEC:

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

La richiesta di secret.example.com fornisce il seguente record NSEC:

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

Il primo è per la zona top/apex, e dice che il nome "example.com" esiste e il nome successivo è "public.example.com". Il record public.example.com dice che il nome successivo è "secret.example.com", il che rivela l'esistenza di un sottodominio privato. "secret.example.com" dice che il prossimo record è "example.com". completando la catena di sottodomini. Pertanto, con poche domande chiunque può conoscere l'insieme completo dei record della zona.

Tecnicamente, i record DNS non dovrebbero essere segreti, ma in pratica a volte vengono considerati tali. I sottodomini sono stati utilizzati per mantenere la privacy (ad esempio una pagina di login aziendale) per un certo periodo di tempo, e rivelare improvvisamente il contenuto del file di zona potrebbe essere inaspettato e non apprezzato.

Prima del DNSSEC, l'unico modo per scoprire il contenuto dei nomi in una zona era quello di interrogarla con una query o di provare a trasferire la zona da uno dei server autoritativi. I trasferimenti di zona (AXFR) sono spesso bloccati. L'alternativa di NSEC, NSEC3, è stata introdotta per risolvere i problemi di enumerazione delle zone, ma anche NSEC3 può essere utilizzato per rivelare l'esistenza di sottodomini.

La maggior parte dei domini sotto .ch utilizzano NSEC3

Il record NSEC3 è come un record NSEC, ma invece di un intervallo firmato di nomi di dominio per i quali non esistono risposte alla domanda, NSEC3 fornisce un intervallo firmato di hash di nomi di dominio. L'obiettivo è quello di evitare l'enumerazione delle zone. Così, la catena NSEC3 per una zona contenente "example.com" e "www.example.com" potrebbe essere (ogni record NSEC3 è su 3 righe per chiarezza):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Dove

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

La prima riga del record NSEC3 contiene il "nome" della zona dopo che è stata sottoposta a hash, il numero di giri di hash e il sale utilizzato nell'hash sono gli ultimi due parametri della prima riga "3 ABCDEF". Il valore "1 0" indica l'algoritmo digest (1 significa SHA-1) e se la zona utilizza l'Opt-out (0 significa no). La seconda riga è il "prossimo nome con hash nella zona", la terza riga riporta i tipi del nome. Si può notare che il "nome successivo" del primo record NSEC3 corrisponde al nome del secondo record NSEC3 e il "nome successivo" di quest'ultimo completa la catena.

Per l'enumerazione NSEC, è possibile creare l'elenco completo dei domini iniziando a ipotizzare i possibili nomi del dominio. Se la zona ha circa 100 nomi di dominio, saranno necessarie circa 100 richieste per enumerare l'intera zona. Con NSEC3, quando richiedi un record che non esiste, viene restituito un record NSEC3 firmato con la zona successiva presente ordinata alfabeticamente per hash. Verificando se il nome del prossimo candidato alla query si inserisce in uno degli intervalli noti, è possibile scoprire l'intera catena in circa 100 query. Esistono molti strumenti in grado di effettuare questo calcolo, tra cui un plug-in di nmap

Con gli hash corrispondenti a tutti i nomi validi della zona, è possibile utilizzare un attacco con dizionario per scoprire i nomi reali. I nomi brevi sono facilmente indovinabili e, utilizzando un dizionario, è possibile rivelare l'esistenza di nomi più lunghi senza dover inondare di ipotesi i nameserver autorevoli. Strumenti come HashCat rendono questa operazione facile da eseguire nel software e la popolarità dei bitcoin ha abbassato drasticamente il prezzo dell'hardware specifico per l'hashing. Esiste una fiorente industria di dispositivi costruiti per calcolare hash crittografici. Il cracker per password Tesla (sotto) è solo un esempio di questi dispositivi non disponibili.

Il cracker Telsa

Poiché l'hashing è economico, la privacy della zona è solo leggermente migliorata quando si utilizza NSEC3 come progettato; la quantità di protezione ottenuta da un nome è proporzionale alla sua inosservabilità.

In breve, NSEC è come rivelare password in chiaro e NSEC3 è come rivelare un file di password in stile Unix. Nessuna delle due tecniche è molto sicura. Con NSEC3 un sottodominio è tanto privato quanto difficile da indovinare.

Questa vulnerabilità può essere mitigata da una tecnica introdotta nelle RFC 4470 e 4471 (https://tools.ietf.org/html/rfc4470 e https://tools.ietf.org/html/rfc4471) chiamato "DNSSEC white lies", implementata da Dan Kaminsky a scopo dimostrativo. Quando arriva una richiesta per un dominio non presente, invece di fornire un record NSEC3 del dominio reale successivo, viene presentato un record NSEC3 dell'hash successivo in ordine alfabetico. Questo non infrange la garanzia di NSEC3 che non esistono domini il cui hash si inserisce dal punto di vista lessicografico tra la risposta di NSEC3 e la domanda.

Puoi implementare NSEC3 o NSEC "white lies" solo se le firme possono essere calcolate in tempo reale in risposta alle domande. Tradizionalmente, i record di zona statici per la risoluzione DNS vengono creati offline e tutti i record con le firme vengono memorizzati in un file di zona. Questo file viene quindi letto da un server DNS live che può rispondere alle domande sulla zona.

L'implementazione DNSSEC di Cloudflare sfrutta l'efficiente generazione di firme ECDSA per firmare i record DNSSEC al volo.

DNSSEC è stato progettato per funzionare in varie modalità, ognuna delle quali offre diversi compromessi in termini di sicurezza, prestazioni e convenienza. La firma dal vivo risolve il problema dell'esposizione del contenuto della zona in cambio di una gestione meno sicura della chiave.

La modalità DNSSEC più comune è la firma offline delle zone statiche. Ciò consente al sistema di firma di essere altamente protetto da minacce esterne, mantenendo le chiavi private su un computer non connesso alla rete. Questo modello operativo funziona bene quando le informazioni DNS non cambiano spesso.

Un'altra modalità operativa comune è la firma online centralizzata. Se si firmano i dati in sistemi di firma DNS dedicati e ad accesso limitato, i dati DNS possono essere modificati e pubblicati rapidamente. Alcuni operatori eseguono la firma DNS sui loro server DNS principali. Proprio come la firma offline delle zone statiche, questa modalità segue il modello di firma centrale, ossia un singolo (o replicato) firmatario centrale esegue tutte le operazioni di firma e i dati vengono propagati da esso ai server DNS autoritativi effettivi.

Una modalità più radicale è quella di consentire ai server DNS autoritativi effettivi di firmare i dati al volo quando necessario, il che consente una serie di nuove funzionalità, tra cui le informazioni geograficamente dipendenti firmate dove viene generata la risposta. L'aspetto negativo è che ora il materiale delle chiavi si trova su molte macchine diverse che hanno accesso diretto a Internet. L'esecuzione della firma in diretta sul bordo introduce nuovi problemi, come la distribuzione delle chiavi, e impone ai nodi requisiti di calcolo aggiuntivi.

Recentemente è stato scoperto un bug noto come Heartbleed che ha aperto un'importante falla nella sicurezza delle applicazioni server. Il problema era causato da un errore di codifica in OpenSSL che creava una vulnerabilità di divulgazione della memoria in remoto. Questo bug consentiva agli autori di attacchi remoti di estrarre chiavi crittografiche da server rivolti a Internet. I bug di esposizione della memoria remota sono solo una delle tante minacce alla sicurezza delle chiavi private quando queste vengono utilizzate in un processo attivo come la firma live del DNSSEC. Più una macchina è esposta a Internet, più sono i vettori di attacco. Le macchine con firma offline hanno una finestra di esposizione molto più ridotta a tali minacce.

Un modo per mantenere la sicurezza delle chiavi è quello di utilizzare una soluzione supportata da hardware, come un modulo di sicurezza hardware (HSM). Lo svantaggio principale è il costo: gli HSM sono molto costosi (e lenti). Questo è uno dei punti più spinosi per chi gestisce server DNS distribuiti geograficamente per essere vicini ai propri clienti. L'esecuzione di un HSM in ogni sede del server non solo può essere costosa, ma può anche comportare complicazioni legali .

Un'altra soluzione per proteggere le chiavi dalla divulgazione a distanza è quella di scaricare le operazioni crittografiche su componenti fidati del sistema.È qui che può essere utile avere un server DNS personalizzato in grado di scaricare la crittografia.

La gestione delle chiavi per il DNSSEC è simile alla gestione delle chiavi per il TLS e presenta sfide simili. All'inizio dell'anno abbiamo introdotto Keyless SSL per migliorare la sicurezza delle chiavi per TLS. Stiamo valutando la possibilità di estendere Keyless SSL per offrire i vantaggi dei server di chiavi remote per la firma live del DNSSEC.

Gli operatori che gestiscono un server DNS autorevole sono spesso nervosi per il fatto che il loro server venga utilizzato come canale per attacchi DDoS (Distributed Denial of Service) malevoli. Ciò deriva dal fatto che il DNS utilizza UDP, un protocollo stateless.

In TCP, ogni connessione inizia con un handshake a tre vie. In questo modo si garantisce che l'indirizzo IP di entrambe le parti sia noto e corretto prima di avviare una connessione. In UDP non c'è questa stretta di mano: i messaggi vengono inviati direttamente a un IP con un indirizzo IP "from" non verificato. Se un autore di attacchi è in grado di creare un pacchetto UDP che dice "Ciao, dall'IP X" a un server, quest'ultimo risponderà in genere inviando un pacchetto UDP a X. La scelta di X come indirizzo IP della vittima invece di quello del mittente è chiamata "spoofing" UDP. Facendo lo spoofing di una vittima, un autore di attacchi può far sì che un server che risponde alle richieste UDP inondi la vittima con traffico "riflesso". Questo vale sia per i server autoritativi che per i resolver ricorsivi aperti.

Il DNSSEC funziona anche su UDP e le risposte alle query DNS possono essere molto lunghe e contenere più record DNSKEY e RRSIG. Si tratta di un obiettivo interessante per gli autori di attacchi, in quanto consente loro di "amplificare" gli attacchi di riflessione. Se ai server dei nomi viene inviato un piccolo volume di richieste UDP DNSSEC spoofate, la vittima riceverà un grande volume di traffico riflesso. A volte questo è sufficiente per sovraccaricare il server della vittima e causare un denial of service.

La richiesta di un TLD inesistente da parte di un server root restituisce una risposta di circa 100 byte, mentre la risposta firmata per la stessa domanda è di circa 650 byte, ovvero un fattore di amplificazione pari a 6,5. La radice è firmata utilizzando una chiave RSA a 1.024 bit e utilizza NSEC per le risposte negative. La richiesta di un dominio che non esiste in un TLD utilizzando NSEC3 firmato con una chiave a 1.024 bit produrrà un fattore di amplificazione pari a circa 10. Esistono altre query che possono produrre fattori di amplificazione ancora più elevati; la più efficace è la query "ANY".

Come molti servizi, il DNS può funzionare anche su TCP. Esiste un flag di "troncamento" che può essere inviato a un resolver per indicare che è necessario il TCP. Questo risolverebbe il problema della riflessione DNS al costo di richieste DNS più lente. Questa soluzione non è al momento praticabile poiché il 16% dei resolver non rispetta il flag di troncamento TCP e il 4% non prova con un secondo server.

Un'altra opzione per ridurre le dimensioni delle risposte è quella di utilizzare le chiavi Elliptic Curve Digital Signature Algorithm (ECDSA) invece delle tradizionali chiavi RSA. Le chiavi ECDSA sono molto più piccole delle chiavi RSA di forza equivalente e producono firme più piccole rendendo le risposte DNSSEC molto più piccole, riducendo il fattore di amplificazione. Google Public DNS ha aggiunto il supporto per ECDSA alla fine del 2014 e da allora molti altri hanno seguito l'esempio.

Il supporto per il TCP e l'ECDSA è ancora in ritardo rispetto al supporto generale del DNSSEC, pertanto è possibile utilizzare metodi anti-abuso tradizionali. Questo include Resource Rate Limiting (RRL) e altre euristiche.

Per proteggere dagli attacchi di riflessione, Cloudflare sta lavorando a un approccio su più fronti. In primo luogo, utilizzando l'euristica di identificazione degli attacchi e le tecniche anti-abuso che stiamo attualmente utilizzando nel nostro server DNS, e in secondo luogo riducendo il fattore di amplificazione delle risposte DNSSEC. I modi per ridurre il fattore di amplificazione massimo includono la risposta solo alle richieste "ANY" su TCP, l'uso di chiavi ECDSA più piccole quando possibile e la riduzione della frequenza dei rinnovi delle chiavi.

Cloudflare è consapevole della complessità introdotta dal protocollo DNSSEC per quanto riguarda la privacy delle zone, la gestione delle chiavi e il rischio di riflessione/amplificazione. Con decisioni ingegneristiche intelligenti e controlli operativi, è possibile prevenire i pericoli del DNSSEC.