DNS Spoofing Cache Poisoning

Università degli Studi G. d Annunzio Facoltà di Economia Corso di Laurea Specialistica in Economia Informatica SEMINARIO PER IL CORSO DI RETI DI CALCOLATORI DNSS EC: cos è? Auttore: Fabrizio ROSSI Proffessore: Stefano BISTARELLI 1

Introduzione Il Domain Name System (DNS) è un database gerarchico distribuito, che associa nomi degli host a indirizzi IP. Esso permette ad un utente di trovare un sistema senza conoscere il suo indirizzo IP, risolvendo nomi di host in indirizzi IP, e organizzando l'interrete in domini. Ad esempio "pippo.sci.unich.it" è la specifica completa della macchina di nome pippo, "sci.unich.it" è il dominio sci, e "unich.it" è il dominio dell' Università di Chieti-Pescara. Sfortunatamente il DNS non è immune a problemi di sicurezza e l'esattezza delle informazioni contenute nel DNS è vitale per molti aspetti delle comunicazioni basate sul protocollo IP. Uno dei punti deboli per la sicurezza del DNS è il cosiddetto concetto del "dirottamento del dominio". Il problema è che gli indirizzi IP nel database del DNS vengono cambiati da host non autorizzati. Vi sono principalmente due modi per fare ciò: DNS Spoofing - "Ingannare" il server DNS con informazioni ritenute sicure, ma che in realtà non lo sono. Cache Poisoning - Falsare l' IP con un alto TTL, cosicchè il server DNS lo conserverà in cache per molto tempo. Le minacce che insidiano il DNS sono dovute in parte alla mancanza dell'autenticazione e al controllo dell'integrità dei dati mantenuti dal DNS e in parte ad altri protocolli che usano nomi di host come meccanismo di controllo di accesso. Per risolvere questi problemi, l' IETF formò un gruppo di lavoro (DNSSEC Working Group) per inserire nel protocollo esistente delle estensioni per la sicurezza e il nuovo protocollo risultante venne chiamato DNSSEC. L' architettura DNSSEC può aiutare a contrastare i due attacchi appena introdotti. Le estensioni di tale 2

architettura hanno come obiettivo quello di garantire la protezione del trasferimento dei dati del DNS, con l'ausilio della crittografia a chiave pubblica. Per comprendere la strategica rilevanza della sicurezza del DNS riferiamoci ad un ben noto caso di attacco al DNS. Nel Giugno del 1997, il dominio internic.net (il principale dominio per la registrazione dei nomi in Internet) venne rediretto al sito www.alternic.net (Alternic è una associazione che si batte contro il monopolio dei domini in rete). Tutto iniziò dal fatto che molti utenti di Internet sentivano che il controllo dei domini di alto livello era contro lo spirito naturale di Internet. Eugene Kashpureff - il fondatore dell'alternic - dichiarò che era in corso una protesta contro la pretesa di Internic, ad avere il controllo dei domini.com,.org,.net ecc.., quando si supponeva invece che fossero di dominio pubblico. Conseguentemente nell'ottobre del 1997 Kasphureff fu arrestato per frode dalle autorità Canadesi e venne estradato negli Stati Uniti. Egli rappresentava la mente che organizzò l'attacco che provvedeva alla programmazione dei server di Internic ad instradare le informazioni verso il sito Alternic. Sostanzialmente era un tipo di attacco alla cache con informazioni contraffatte. Fino ad allora, nessun cambiamento essenziale era stato fatto per la sicurezza del DNS cosicchè questi tipi di attacchi sono tuttora possibili. Per di più il DNS è usato dalla maggior parte delle applicazioni e dei protocolli coinvolti nella comunicazione sulla rete. Indirizzi IP e Nomi mnemonici La famiglia di protocolli TCP/IP usa interi a 32 bit chiamati indirizzi IP (Internet Protocol) per identificare le macchine. Sebbene tali indirizzi forniscano una rappresentazione compatta e utile per specificare la sorgente e la destinazione nei pacchetti inviati attraverso un' interrete, gli utenti preferiscono assegnare alle macchine nomi facili da ricordare. 3

Lo schema di denominazione è interessante per due motivi: innanzitutto è stato usato per assegnare i nomi delle macchine in tutta l'internet mondiale; secondariamente, poiché usa un insieme geograficamente distribuito di server per tradurre i nomi in indirizzi, l'implementazione del meccanismo di traduzione dei nomi fornisce un esempio su vasta scala del paradigma client-server. I primi sistemi di elaborazione imponevano agli utenti di interpretare gli indirizzi numerici corrispondenti a oggetti come tabelle di sistemi e dispositivi periferici. I sistemi a condivisione di tempo portarono un miglioramento, consentendo di inventare nomi simbolici significativi sia per oggetti fisici (ad esempio, periferiche) sia per oggetti astratti (ad esempio, file). Un modello simile è emerso nel collegamento in rete dei computer. I primi sistemi supportavano le connessioni punto a punto e usavano indirizzi hardware di basso livello per specificare le macchine; il collegamento tra reti diverse ha introdotto l'indirizzamento universale e l'uso del software dei protocolli per tradurre indirizzi universali in indirizzi hardware di basso livello. Poiché la maggior parte degli ambienti di calcolo contiene più macchine, agli utenti servono nomi simbolici significativi per identificarle. La differenza fra indirizzo e nome è interessante. Un nome è semplicemente un identificatore che consiste in una sequenza di caratteri scelti da un alfabeto finito. I nomi sono utili solo se il sistema può tradurli in modo efficace nell'oggetto che rappresentano; per questo si pensa ad un indirizzo IP come a un nome di basso livello e si dice che gli utenti preferiscono i nomi di alto livello per le macchine. 4

Gestione dello Spazio dei Nomi Si deve garantire che ogni nome mnemonico identifichi univocamente un host, per cui si fissa una politica di gestione dello spazio dei nomi con un'autorità che garantisce l'applicazione della politica. Vi sono due possibili soluzioni: - Spazio dei nomi piatto (flat) - Spazio dei nomi gerarchico Spazio dei Nomi Piatto L'insieme originale dei nomi delle macchine usato in Internet formava uno spazio di denominazione piatto in cui ciascun nome consisteva in una sequenza di caratteri senza alcuna ulteriore struttura. Nello schema iniziale, un sito centrale, il NIC (Network Information Center) amministrava lo spazio di denominazione e stabiliva se un nuovo nome era appropiato (cioè proibiva i nomi osceni o nomi nuovi in conflitto con quelli esistenti). Il vantaggio principale di uno spazio di denominazione piatto è che i nomi sono brevi, mentre lo svantaggio è che non si può generalizzare questo schema a molte macchine per motivi sia tecnici che amministrativi. In primo luogo, poichè i nomi sono creati da un unico insieme di identificatori, le potenzialità di conflitti aumentano quando cresce il numero dei siti. In secondo luogo, poichè l'autorità di aggiungere nuovi nomi deve restare in un singolo sito, il carico amministrativo nel 5

sito centrale aumenta con il numero dei siti. Per capire la gravità del problema, si immagini un'interrete che cresce rapidamente con migliaia di siti, ciascuno dei quali è composto da centinaia di personal computer e stazioni di lavoro; ogni volta che qualcuno acquista e connette un uovo personal computer, il suo nome deve essere approvato dall'autorità centrale. Infine, poichè i collegamenti tra nomi e indirizzi cambiano spesso, il costo per mantenere copie corrette dell'elenco intero in ciascun sito è elevato e cresce se aumenta il numero dei siti; se invece il database dei nomi si trova in un singolo sito, è il traffico di rete verso quel sito ad aumentare. Una funzione associa ogni nome univocamente ad un indirizzo IP. Soluzione semplice ma con problemi. E' una gestione centralizzata e la tabella di conversione deve essere nota a tutti i computer della rete. Di conseguenza è difficile da gestire e da consultare quando la rete è grande 6

Spazio dei Nomi Gerarchico Lo spazio dei nomi viene diviso in zone dette domini e per ogni dominio viene definita un'autorità di dominio. Tutto ciò consente la decentralizzazione della gestione della tabella. L'autorità centrale si occupa solo di coordinare le autorità di zona. Ogni autorità di dominio è delegata a gestire l'assegnazione dei nomi della sua zona ed effettuare le corrispondenze tra indirizzi e nomi mentre ogni dominio può essere diviso in sottodomini affidati ad autorità di sottodominio. Le autorità di dominio sono autonome e lo stesso nome può essere usato in domini diversi. Idea della Struttura Gerarchica Per capire come dovrebbe essere diviso lo spazio di denominazione, si prenda in considerazione la struttura interna delle grandi organizzazioni. Al vertice, un direttore generale ha la piena responsabilità, ma poichè egli non può controllare tutto, l'organizzazione può essere divisa in vari reparti con un direttore a capo di ciascuno. Il direttore generale garantisce a ogni reparto un'autonomia all'interno di limiti specificati. Il responsabile di un particolare reparto può assumere o licenziare dipendenti, assegnare incarichi e delegare la sua autorità, senza ottenere l'autorizzazione diretta dal direttore generale. 7

Struttura dei Nomi Gerarchici Il DNS usa uno schema di denominazione gerarchico che rappresenta il nome gerarchico sotto forma di nome di dominio. Un nome gerarchico è formato da vari campi, detti etichette. Esse sono separate da punti e ognuna è assegnata da un'autorità ed identifica una zona. L'autorità garantisce che nella sua zona quel nome è unico. Ad esempio in www.sci.unich.it si ha che: it è unico a livello globale unich è unico nel dominio it sci è unico nel dominio unich.it generale 1 Livello 2 Livello 3 Livello DNS Il Domain Name System implementa uno spazio dei nomi gerarchici per le interreti TCP/IP. Esso è utilizzato su Internet da molte altre applicazioni e protocolli che interagiscono con la comunicazione in un interrete (Web browsing, Ftp, Telnet, utilitiy TCP/IP su internet). E' basato su un database distribuito e provvede a specificare la sintassi dei nomi e le regole per delegare l'autorità sulle zone e ad implementare il sistema di calcolo distribuito per convertire nomi in indirizzi e viceversa. Le etichette dei vari livelli gerarchici sono separate con un "." e non c'è differenza fra maiuscole e minuscole. 8

I livelli gerarchici sono ordinati da destra a sinistra e il primo livello in genere è omesso (Es. sci.unich.it._) Struttura Gerarchica del DNS 9

Domini Top Level L'autorità centrale ha individuato un insieme di domini di primo livello. Essi sono stati individuati su base geografica o in base alla funzione: COM Organizzazioni commerciali EDU GOV MIL NET ORG INT Istituzioni didattiche Istituzioni statali (americane) Gruppi militari (americani) Centri di supporto di Internet Altre organizzazioni Organizzazioni internazionali IT, US, UK, DE, RU Codici di nazione (due lettere) Recentemente sono stati introdotti nuovi domini di primo livello che sono necessari per soddisfare esigenze commerciali e risolvere problemi di esaurimento dei nomi: BIZ INFO COOP attività commerciali siti informativi siti di cooperative 10

AERO attività aerospaziali MUSEUM musei NAME EU siti personali codice dell'unione Europea Name Server Oltre alle regole per la sintassi dei nomi e la delega dell'autorità, lo schema dei nomi di dominio include un sistema distribuito efficace, affidabile e di uso generale per la traduzione dei nomi in indirizzi. Distribuito in senso tecnico, il che significa che un insieme di server che funzionano insieme in più siti risolvono il problema della traduzione. Efficace nel senso che la maggior parte dei nomi può essere tradotta localmente, mentre solo pochi richiedono di generare traffico d'interrete. Di uso generale perchè non è limitato ai nomi delle macchine. Infine, affidabile per il fatto che nessun guasto di nessuna macchina impedirà al sistema di funzionare correttamente. Il meccanismo per la traduzione dei nomi in indirizzi consiste in sistemi cooperativi indipendenti chiamati Name Server. Un Name Server è un programma server che fornisce la traduzione da nome a indirizzo, traducendo da nomi di dominio in indirizzi IP. Spesso il software dei server è eseguito su un processore dedicato e la macchina stessa è chiamata Name Server. Ogni applicazione deve contattare un Name Server per risolvere un nome, e ogni autorità deve avere almeno un Name Server che gestisce la risoluzione dei nomi per 11

quel dominio ed essere totalmente responsabile del funzionamento dei suoi name server. I name server sono programmi server che mantengono informazioni sulla struttura ad albero del DNS e possono settare tali informazioni. Un Name Server puo' memorizzare in una cache qualsiasi informazione dell'albero dei domini ma in generale ha informazioni complete su una specifica parte del DNS. Questo significa che il Name Server ha autorità per quel sottodominio dello spazio dei nomi. Per tale motivo è chiamato authorative. Struttura Gerarchica dei Name Server I name server possono essere classificati secondo l'albero dei domini. Due name server collegati nell'albero si conoscono e si scambiano informazioni. I name server collegati possono comunicare in vari modi: possono risiedere sullo stesso host oppure essere collegati tramite un'interrete. Le relazioni nell'albero sono logiche e non fisiche. I name server associati alla radice dell'albero sono detti root name server. Per ogni nome conoscono un name server in grado di convertire quel nome. 12

I Root Name Server L' elenco dei 13 root name server attaccati l'11 Settembre dall'organizzazione di Bin Laden può essere ottenuto utilizzando il comando dig che è un evoluto comando di interrogazione DNS. L'output è il seguente: i.root-servers.net. 5d22h39m28s IN A 192.36.148.17 e.root-servers.net. 5d22h39m28s IN A 192.203.230.10 d.root-servers.net. 5d22h39m28s IN A 128.8.10.90 a.root-servers.net. 5d22h39m28s IN A 198.41.0.4 h.root-servers.net. 5d22h39m28s IN A 128.63.2.53 c.root-servers.net. 5d22h39m28s IN A 192.33.4.12 g.root-servers.net. 5d22h39m28s IN A 192.112.36.4 f.root-servers.net. 5d22h39m28s IN A 192.5.5.241 b.root-servers.net. 5d22h39m28s IN A 128.9.0.107 j.root-servers.net. 5d22h39m28s IN A 192.58.128.30 k.root-servers.net. 5d22h39m28s IN A 193.0.14.129 l.root-servers.net. 5d22h39m28s IN A 198.32.64.12 m.root-servers.net. 5d22h39m28s IN A 202.12.27.33 Il tempo indicato è la validità della corrispondenza Nome <->Indirizzo IP. 13

Zone di Autorità Il sottoalbero di domini gestito da un name server costituisce la sua zona di autorità. Per ottenere una zona di autorità un'organizzazione deve soddisfare alcuni vincoli fissati dall'autorità centrale. Deve supportare tutti i protocolli standard per le interrogazioni e le risposte dal DNS, supportare tutti i protocolli standard per le interrogazioni e le risposte dal DNS e conoscere almeno un root name server. Inoltre l'organizzazione deve conoscere un name server per ciascuno dei suoi sottodomini e almeno due name server attivi che non hanno punti di guasto comune: un name server primario ed uno di backup. Un file di zona mantiene informazioni (che saranno rappresentate dai cosiddetti Resource Record- RR) per tutti i nomi di dominio associati con la zona. Più avanti vedremo il formato considerando un esempio. 14

Name Server per.unich.it Utilizzando il comando dig www.unich.it, si ha il seguente output: ; <<>> DiG 9.4.2-P1 <<>> www.unich.it ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.unich.it. IN A ;; ANSWER SECTION: www.unich.it. 82146 IN CNAME settebbello.unich.it. settebbello.unich.it. 82146 IN A 192.167.13.195 ;; Query time: 23 msec ;; SERVER: 26.204.101.31#53(26.204.101.31) ;; WHEN: Fri Nov 28 11:57:36 2008 ;; MSG SIZE rcvd: 72 ; <<>> DiG 8.3 <<>> www.unich.it Il tempo indicato è la validità della corrispondenza Nome <->Indirizzo IP. 15

Tipi di Nomi nomi. Il DNS consente di incorporare nello stesso sistema diverse gerarchie di Ad ogni elemento denominato, memorizzato nel sistema è associato un tipo: - Host - Casella postale - Un utente Quando si interroga il DNS si deve specificare che tipo di informazione si sta cercando e la famiglia di protocolli da utilizzare. Per default si assume che si stanno cercando i nomi degli host e che si usano i protocolli TCP/IP. 16

Risoluzione di un Nome La comunicazione con il NS è gestita dal Resolver. I Resolver sono programmi che estraggono le informazioni dai Name Server in risposta alle richieste del Client. Esso puo' variare dalla semplice System call (gethostbyname() gethostbyaddress()) a più complesse applicazioni con capacità di memorizzare informazioni in cache (nslookup, dig, host). Quando un programma utente deve risolvere un nome, esso richiama il Resolver che formula una query e contatta il suo Name Server locale che è preconfigurato (ad esempio in un file resolve.config). Questa query può essere sia Iterativa che Ricorsiva. Il Resolver fa parte dell'applicazione ed è invocato prima di contattare il livello di trasporto. Esempio : Un utente su A lancia il comando ftp B 1. A richiede al name server su S l'indirizzo di B 2. S risponde con l'indirizzo 3. A invia un messaggio FTP all'indirizzo di B 17

Non esiste per gli host un metodo standard per individuare un Name Server sulla rete locale. In genere il nome del name server è memorizzato in un file di configurazione oppure Il Name Server accetta solo richieste per nomi completamente qualificati. Il resolver permette all'utente di specificare nomi parziali provando ad estenderli per ottenere nomi completamente qualificati. Esso aggiunge al nome i suffissi specificati nel file di configurazione. Ad esempio a "ftp pippo" corrisponde "ftp pippo.sci.unich.it". Modalità di Risoluzione Il Name Server può utilizzare due diverse modalità per rispondere ad una interrogazione. - modalità ricorsiva: se non conosce la risposta interroga altri name server e poi passa la risposta al client. E' usata dai name server locali. - modalità iterativa: se non conosce la risposta passa al client l'indirizzo di un altro Name Server. E' usata dai name server di livello superiore. Il client sceglie la modalità di risposta settando un flag nel messaggio di richiesta. 18

Funzionamento del DNS L'applicazione interroga il name server locale: se il nome appartiene alla sua zona di autorità il Name Server locale risponde direttamente, altrimenti il Name Server locale interroga un root Name Server ottenendo in risposta il nome di un Name Server che ha l'autorità sul dominio di primo livello del nome richiesto. A questo punto il Name Server locale interroga il name server di primo livello e se il nome non può essere risolto si ottiene in risposta il nome di un Name Server di secondo livello. Si procede così, ricorsivamente fino alla risoluzione del nome. 19

Cache Ogni Name Server mantiene in una cache tutte le corrispondenze tra nomi e indirizzi di cui viene a conoscenza. Nell'esempio il Name Server locale mette in cache i name server di it, unich.it e sci.unich.it. Ogni corrispondenza viene mantenuta nella cache per un periodo fissato. Il tempo di validità è fissato dal Name Server che ha l'autorità su quel nome nel messaggio inviato agli altri name server. Per default il timeout è 2 giorni. 20

Formato dei messaggi Il formato dei messaggi consente a un client di porre più richieste in un singolo messaggio. Ogni domanda consiste nel nome di dominio per cui il client cerca l'indirizzo IP e il tipo di oggetto desiderato (ad esempio, indirizzo). Il server risponde restituendo un messaggio simile che contiene le risposte alle domande. Se non può soddisfare tutte le richieste, la risposta conterrà informazioni su altri name server che il client può contattare per ottenere le risposte. In un messaggio dei name server, ogni Answer Section, Authority Section e Additional I. Section consiste in un insieme di Resource Record (RR) che descrivono i nomi di dominio e le traduzioni (ogni record descrive un nome). Il formato di queste sezioni sarà mostrato più avanti. 21

I Resource Record quindi rappresentano l'associazione fra la struttura ad albero dello spazio dei nomi e i dati associati a questi nomi. Parametri IDENTIFICATION: consente di far corrispondere le risposte alle richieste. richiesta. PARAMETER: contiene vari flag per specificare il tipo di operazione - Richiesta/Risposta - Corrispondenza indirizzo/nome o viceversa - Messaggio troncato - Risposta proveniente dalla autorità o indiretta - Modalità ricorsiva disponibile - Modalità ricorsiva richiesta Gli altri campi specificano quanti record sono contenuti nelle quattro sezioni del messaggio. 22

Formato della Question Section QUERY DOMAIN NAME: contiene il nome da risolvere, rappresentato come sequenza di caratteri di lunghezza variabile. - Es. sci.unich.it 3 s c i 5 u n i c h 2 i t 0 QUERY TYPE: specifica il tipo di informazione richiesta. QUERY CLASS: specifica la classe di indirizzi. 23

Formato della Answer Section I primi tre campi sono uguali alla Question Section TIME TO LIVE: tempo di validità della risposta RESOURCE DATA: contiene la risposta del Name Server formata da vari record di risorse Stesso formato per le altre due sezioni Authority Section e Additional I. Section. 24

Tipi degli Oggetti Il DNS può essere utilizzato per implementare un qualsiasi spazio gerarchico dei nomi. Può implementare corrispondenze arbitrarie come ad esempio corrispondenze tra nomi e indirizzi IP e tra nomi e caselle di posta. Il tipo di un oggetto definisce il tipo di corrispondenza a cui si riferisce. Perché la Sicurezza del DNS è importante? Il DNS è utilizzato radicalmente da applicazioni Internet e sorgono quindi i problemi di sicurezza del DNS: I name server possono essere "truffati" facilmente e sono vulnerabili a molti tipi di attacchi (DoS, buffer overrun, replay). false. I Resolver possono essere indotti a "credere" in informazioni Misure di sicurezza (per esempio, ACLs) e altri meccanismi, rendono l'inganno, più difficile da compiere, ma non impossibile! Nel Giugno del 1997, Eugene Kashpureff (fondatore dell'alternic) ha reindirizzato il dominio internic.net ad alternic.net, mettendo in cache informazioni false, sul Name Server di Internic. 25

Destinazione errata indotta: Credere in false informazioni Si supponga il seguente scenario: un utente vuole connettersi ad un host A mediante un telnet client. Il telnet client chiede, attraverso un resolver, il Name Server locale per risolvere il nome A in un indirizzo IP. Esso riceve una informazione falsa e inizia una connessione TCP al server telnet sulla macchina A (almeno così crede). L'utente manda la sua login e password all'indirizzo falso. Ora la connessione salta, e l'utente ritenta l'intera procedura questa volta al corretto indirizzo IP dell'host A. Egli puo' ignorare ciò che è appena successo ma l'attaccante malizioso che si e' spacciato con il nome dell'host A, ha ora il controllo della login e della password dell'utente. Ciò è accaduto poichè i router attuali non hanno la capacità di respingere i pacchetti con falsi indirizzi sorgenti. Cosi' se l'attaccante può instradare pacchetti a chiunque, egli può indurre a farli considerare come pacchetti provenienti da un host fidato. Quindi, nel nostro caso, l'attaccante prevede il momento in cui viene mandata una query e inizia ad inondare il resolver con le sue false risposte. Con un firewall per la rete dell'utente, il resolver non sarebbe raggiungibile dal mondo esterno, ma il suo Name Server locale si. Cosi' se il Name Server locale può essere corrotto nel modo come descritto, allora l'attaccante può ridirezionare tali applicazioni con informazioni vitali, verso host sotto il suo controllo e catturare queste informazioni. Attenendosi a queste assunzioni, osserviamo che contemporaneamente a ciò, c'è la possibilità di un attacco Denial of Service (DoS). Nel caso di un tale attacco, se il Name Server può essere ingannato e l'host dell'attaccante può spacciarsi per il vero 26

Name Server, allora puo' maliziosamente imporre che alcuni nomi nel dominio, non esistano. Autenticazioni e Autorizzazioni basate sui nomi Alcune applicazioni diffuse su Internet, sfortunatamente, fanno uso di un meccanismo estremamente insicuro: L' Autenticazione e Autorizzazione basate sui nomi. Ad esempio : L'utente "joe" può loggarsi come l'utente "doe" al computer "host.mydomain.com" dal computer"otherhost.mydomain.com", se il file /etc/hosts.equiv contiene l'equivalenza tra l'utente locale "doe" e l'utente "joe@otherhost.mydomain.com" semplicemente sulla base dei loro nomi. I comandi Remoti sono stati progettati quando nacque Internet, per l'uso di reti locali fidate, dove tutti gli utenti erano conosciuti dall'amministratore di sistema, e la rete non era connessa al grande Internet. Sfortunatamente, i comandi remoti sopravvissero alla crescita di Internet e essi sono ancora presenti e usati in molte reti. 27

Se viene usata l'autenticazione basata sul nome, è possibile accedere ad una macchina remota semplicemente truffando il nome di un host. Anche se la rete locale è protetta da un firewall, tutti gli host che usano l'autenticazione basata sui nomi, rischiano poichè un attaccante può prendere il controllo di una singola macchina della rete protetta dal firewall. L'attaccante può monitorare il traffico di rete venendo a conoscenza dell'equivalenza usata in quella rete, e operare con l'indirizzo IP di un host equivalente (ad esempio compiendo un attacco DoS, o semplicemente aspettando lo shutdown della macchina).a questo punto l'host dell'attaccante è completamente equivalente all'host attaccato per tutti i computer che usano l'equivalenza remota. Attacco alle informazioni supplementari Questo è un altro lato della debolezza del DNS. Per motivi di efficienza il DNS fu progettato in modo da avere una sezione addizionale nel suo formato standard dei messaggi. Di conseguenza in alcuni casi quando un' informazione supplementare è considerata urgente da spedire, per velocizzare la risposta per una data query, essa è inclusa nella sezione addizionale. Per esempio, se viene interrogato il Name Server ns.mydomain.com, per recuperare il mail exchanger per il dominio comp-craiova.ro, il server risponde con un messaggio contenente mail.gate.comp-craiova.ro Nella sezione answer del messaggio e nella sezione additional viene incluso il nome e l'ip del Name Server autoritativo per il dominio comp-craiova.ro. Questa 28

informazione non era stata esplicitamente chiesta, piuttosto era stata messa in cache, per evitare una lunga ricerca per il name server autoritativo per quel dominio. Cosa è il DNSSEC? Cominciamo col vedere che cosa DNSSEC non è. DNSSEC non è la soluzione totale per la sicurezza. Non è una robusta difesa contro tutte le forme di attacco verso server e client. DNSSEC è la specifica di una estensione del DNS attraverso la definizione di Resource Records DNS aggiuntivi che possono essere usati dai client DNS per valicare l autenticità di una risposta del DNS, l integrità dei dati di una risposta DNS e dove la risposta indica che non esiste un tal dominio o una tale risorsa, anche questa informazione negativa può essere autenticata. In altre parole, DNSSEC è inteso proteggere client DNS da dati DNS falsi. Questa protezione non elimina la potenziale immissione di dati contraffatti in una transazione che coinvolge DNS, ma aggiunge informazioni addizionali alle risposte DNS per permettere al client di controllare che la risposta sia autentica. Per ottenere ciò, DNSSEC definisce alcuni nuovi records DNS (RR), ad esempio DNSKEY, RRSIG, NSEC, DS. Con il DNSSEC un amministratore di zona firma digitalmente una Resource Record Set (RRSet), e pubblica questa firma digitale. Per controllare una risposta DNS, un client DNSSEC può recuperare la relativa firma digitale del RRSet e controllare questa firma, usando la chiave pubblica, con il valore hash del RRSet calcolato localmente, quindi convalida la chiave pubblica dell amministratore di zona con un percorso gerarchico di firme che conduce alla fine ad un punto fidato. Se tutti questi controlli hanno successo allora il client ha una qualche convinzione che la risposta del DNS è completa ed autentica. DNSSEC implica differenti azioni per differenti ruoli. Per un amministratore di zona DNS, DNSSEC è essenzialmente il 29

processo di firma del RRSet con una chiave privata, pubblicando queste firme per ogni RRSet nel file di zona e pubblicando la chiave pubblica di zona nel file di zona. Inoltre l amministratore di zona deve avere la chiave pubblica di zona firmata dall amministratore padre di zona. Per un client DNS il DNSSEC è la capacità di eseguire un numero di controlli aggiuntivi sulle risposte DNS (controlli di autenticità e accuratezza). Per il DNS stesso il DNSSEC rappresenta essenzialmente un certo numero di RR addizionali che contengono le firme digitali delle informazioni DNS. DNS Record Resource Il DNSSEC introduce Quattro RRs addizionali allo scopo di assicurare sicurezza delle informazioni. Questi records sono: DNSKEY: Ogni zona DNS assicurata dal DNSSEC ha associata una coppia di chiavi privata e pubblica, così come generate dall amministratore di zona. La chiave privata rimane il segreto dell amministratore di zona. La chiave pubblica associata alla zona viene pubblicata nel file di zona nella forma di un RR DNSKEY. Un esempio di record DNSKEY per la zona example.com è (da RFC 4034): example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31gajiqky+5cptlr3buxa10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U anvv4w== ) 30

Il TTL ha valore 1 giorno (86400 secondi). I flags hanno valore 256, indicando che si tratta di una chiave di zona. Il valore del protocollo è la costante 3. Il campo successivo rappresenta l algoritmo della chiave pubblica, ed il valore 5 indica cha si tratta di RSA/SHA1. Il valore RR è la codifica Base64 del valore della chiave pubblica. RRSIG: Un Resource Record set ((RRSet) è un insieme di RR in una zona DNS che condivide un nome comune, una classe comune e un tipo comune. Nel DNSSEC gli RRSet sono firmati digitalmente dall amministratore di zona. Questa firma è prodotta dalla generazione di un hash del RRSet, e poi criptando la hash usando la chiave privata dell amministratore di zona. Per una zona cha contiene dei resource record SOA, NS, A, MX, DNSKEY esistono almeno 5 distinti RRSet, ed ogni RRSet potrebbe avere il suo resource record RRSIG. Un esempio di record RRSIG per la zona example.com è: (da RFC 4034): 20030322173103 ( host.example.com. 86400 IN RRSIG A 5 3 86400 20030220173103 2642 example.com. ojb1w6wngv+ldvq3wdg0mqkg5iehjrip8wtr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 31

I primi quattro campi specificano il nome del proprietario, TTL, Classe e tipo RR (RRSIG). Il campo successivo è il campo tipo covered ed il valore di A indica che questo è una firma di RRs A per host.example.com. Il campo successivo è l algoritmo di firma, ed il valore 5 indica che questo è firmato usando RSA/SHA1. Il valore 3 è il numero di etichette nel nome del proprietario originario. Il valore 86400 nel RRSIG RDATA è il valore originario del TTL per il RRSet A covered. 20030322173103 and 20030220173103 sono le date di scadenza e iunizio, indicando che la firma RRSet è stata creata alle 17:31:03 del 20/02/2003. Il tag della chiave è 2642 e il nome del firmatario è example.com. Il rimanente del valore RR è l hash criptato del RRSet. NSEC: I records DNSKEY e RRSIG possono essere usati per testare l autenticità di una risposta DNS, dove esiste una risposta DNS, ma dove non ci sono dati autoritativi da ritornare allora l autenticazione richiede informazioni aggiuntive. Il RR NSEC può essere considerato come un record che copre un gap a scopi di autenticazione. L intero file di zona è organizzato in una forma canonica ed allora gli RR NSEC sono aggiunti per coprire questo gap. Se la zona contiene i nomi alpha e beta, allora ci sarà un record RR NSEC per alpha e uno per beta, indicando che non ci sono nomi definiti tra alpha e beta. In aggiunta il record NSEC definisce l insieme di tipi RR per questo nome di dominio. In risposta a una query se il nome non esiste nel file di zona, o il tipo RR non esiste per il nome in questione, allora viene restituito un record NSEC che evidenzia il fatto che il tipo RR non esiste. La ragione di questa forma di dati spanning, diverso da una più generica risposta no such name, è che questa forma di risposta può essere usata in caso di un attacco di tipo replay, affermando in maniera falsa che un nome non esiste, da momento che il record NSEC zinforma esplicitamente il client di questo gap. 32

4034): Un esempio di record NSEC per la zona example.com è il seguente (RFC alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) I primi 4 campi testo specificano il nome, TTL, classe e tipo RR (NSEC). L elemento host.example.com è il successivo nome autoritativo dopo alfa.example.com in ordine canonico. I codici A, MX, RRSG, NSEC e TYPE1234 indicano che ci sono RRSet A, MX, RRSIG, NSEC e TYPE1234 associati con il nome alfa.example.com. I records NSEC possono essere usati per enumerare l intero contenuto di un file di zona. DS: Il punto cruciale nella crittografia delle chiavi pubbliche è quello del mezzo di validazione della chiave pubblica. Il problema della validazione della chiave pubblica di zona rimane aperto con i primi tre tipi di RR appena esaminati. Quindi il problema è: come può un client validare il record DNSKEY? L approcio usato dal DNSSEC è quello di usare una chain of trust all interno della struttura di delegazione gerarchica dello stesso DNS. Esclusa la zona root, ogni zona DNS ha una zona padre. Il RR del firmatario delegato (DS) contiene la hash della chiave pubblica della zona figlio. Questo record è firmato dalla chiave privata del padre di zona con un RR RRSIG. Per validare un DNSKEY di zona, vengono recuperati gli associati record DS, RRSIG e DNSKEY della zona padre. Il record DS è validato usando il DNSKEY per criptare il record RRSIG(DS) e quindi verificando che il risultato combacia con il record DS. Questa è la chiave pubblica di zona. Può essere confrontata con il record DNSKEY della zona in questione. La domanda ora è: come può essere validata questa chiave? Si applica lo stesso processo. Il processo di validazione ha termine nel momento in cui il client incontra una chiave fidata. La chiave fidata ideale dovrebbe essere il DNSKEY della zona root, ma in assenza di un tale punto fidato ogni client 33

DNSSEC deve configurare il suo sistema di validazioni fidate con punti di fiducia noti dove non esiste validazione padre. Un esempio di record DS per la zona example.com è il seguente (RFC 4034). dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) I primi 4 campi specificano il nome, TTL, classe e tipo RR (DS). Il valore 60485 è il tag chiave per il corrispondente RR DNSKEY dskey.example.com e il valore 5 denota l algoritmo usato da questo RR DNSKEY dskey.example.com. il valore 1 è l algoritmo usato per costruire l indice, e il resto del testo RDATA è l indice in esadecimale. Come lavora DNSSEC Quando richiesto dal client, DNSSEC aggiunge ulteriori dati alle risposte del protocollo DNS in modo da fornire dati addizionali per permettere al client DNS di autenticare i RRSet in risposta. Dal punto di vista della transazione tra un agente di query e un nameserver autoritativo, la variazione riguarda l aggiunta di una parte RRSIG ai dati in risposta dove c è una risposta che può essere generata e l uso di un RR NSEC oltre al RRSIG se non esiste un nameserver autoritativo per la risposta alla richiesta. Il client preleva la risposta in RRSet ed usa l algoritmo indicato nel record 34

RRSIG per generare l hash dei dati. Il client deve anche avere il record DNSKEY di zona. Questa operazione permette al client di verificare che l hash dei dati RRSet coincidono con l hash del RRSIG decriptato. Risultati dall utilizzo di DNSSEC Il DNSSEC comporta alcune variazioni sostanziali nell organizzazione del DNS soprattutto a livello di performance. La grandezza media del messaggio di rispota del DNS aumenta, dovuto all aggiunta dei record di firma collegati ai records di risposta. Inoltre quando un messaggio va oltre l ampiezza di un messaggio UDP deve essere troncato, causando quindi perdita della query e rivolgersi pertanto al TCP. Il numero delle transazioni DNS aumenta dovuto al fatto che vengono effettuate ulteriori query per ottenere i records relativi alle chiavi pubbliche di zona per costruire le chain of trust. Il file di zona aumenta in grandezza dovuto all aggiunta di records addizionali DNSSEC. Il maggior contributo a questo fenomeno è dovuto ai records NSEC e RRSIG. Il client spende tempo aggiuntivo per validare i dati firmati e le chiavi pubbliche. Il server deve generare nuove firme relativamente ad ogni variazione di RRSet. RFC 3383 fa notare che il comportamento di una piccola richiesta che genera una risposta corposa è stato usato per apportare un denial of service. 35

In realtà un DNS con DNSSEC può diventare un veicolo ideale per questa forma di attacco. Con l'rfc 2065 e dopo con la sua successiva 2535, l'estensione per la sicurezza del DNS fu ammessa e standardizzata in maniera formale, con il gruppo di lavoro DNSSEC IETF. Il primo passo è provvedere all'autenticazione dei dati per gli RR che vanno avanti e indietro in Internet. Con l'autenticazione si ottenne anche integrità dei dati e l'autenticazione dei dati sorgenti. L'autenticazione è ottenuta per via della firma digitale crittografica. Gli algoritmi a chiave pubblica usati per l'autenticazione nel DNSSEC sono MD5/RSA e DSA. Le firme digitali generate con gli algoritmi a chiave pubblica hanno il vantaggio che chiunque, avendo la chiave pubblica le può verificare. Ogni messaggio di RR nel DNS scambiato può essere firmato digitalmente provvedendo così all' autenticazione dei dati origine e all'integrità del messaggio. In aggiunta, DNSSEC definisce nuovi RR per la memorizzazione delle chiavi pubbliche nel DNS. Questi RR possono essere usati per distribuire le chiavi coinvolte per la sicurezza del DNS stesso e anche per distribuire chiavi associate con nomi per supportare altri protocolli come IPSEC. Negli esempi riportati sono ancora indicati RR KEY (ora utilizzato solo per TKEY), RR NXT ora obsoleto (in pratica sostituito da NSEC) e RR SIG sostituito da RRSIG. Per il DNS standard, abbiamo gli RR nel file dati di zona (figura 1). 36

Abbiamo un semplice file dati di zona nel quale sono presenti gli RR che specificano l'inizio dei parametri (SOA), il Name Server (NS), il mail exchanger (MX) per il dominio mydomain.com (linee 1-9). Abbiamo anche l'ip per il Name Server, l'ip del mail exchanger e l'ip di un host in mydomain.com dato dal RR di tipo A. Quando DNSSEC è usato, il file di zona è modificato come presentato in figura 2. 37

Line 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. host securens servmail IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN SOA SIG SIG NS SIG MX SIG NXT SIG A SIG NXT SIG A SIG KEY SIG NXT SIG A SIG NXT SIG Zone Data File securens.mydomain.com. sysadmin.mydomain.com. ( 938093434 ;serial number 86400 ;refresh time 1800 ;retry time 2592000 ;expire time 86400 ;TTL ) ;Cl = 2 SOA 1 86400 (;RR type, alg. type, TTL 19991023133034 ;SIG expiration time 19990923133041 ;SIG inception time 59104 mydomain.com. ;key tag, signer s name ama12lanfghi/ukl... );the signature AXFR 1 86400 (;zone transfer signature 19991023133034 19990923133046 59104 mydomain.com. rema121anfasdc... );the signature securens.mydomain.com. NS 1 86400 ( 19991023133034 19990923133041 59104 mydomain.com. BmmAR12LenCDFsS... );the signature 10 servmail.mydomain.com. MX 1 86400 ( 19991023133034 19990923133041 59104 mydomain.com. kjldfievdsl... ) host.mydomain.com. NS SOA MX SIG NXT NXT 1 86400 ( 19991023133034 19990923133041 59104 mydomain.com. LfDS5Almcds21... ) 131.87.24.3 A1 86400 ( 19991023133034 19990923133044 59104 mydomain.com. securens.mydomain.com. A SIGNXT NXT 1 86400 19991023133034 19990923133044 59104 mydomain.com. LdSD+/34mCDGfy... ) 131.87.24.1 A1 86400 ( 19991023133034 19990923133046 59104 mydomain.com. HgfT4K08VBDliv... ) KmOP/sd7REvb3Kii... ;the securens public key KEY 1 86400 ( 19991023133034 19990923133046 59104 mydomain.com. OrT2M09/xZE... ) servmail.mydomain.com. A SIG KEY NXT NXT 1 86400 19991023133034 19990923133046 59104 mydomain.com. TmBP/ = s4hrvevbla... 131.87.24.4 A1 86400 ( 19991023133034 19990923133044 59104 mydomain.com. mydomain.com. A SIG NXT NXT 1 86400 ( 19991023133034 19990923133044 59104 mydomain.com. Al0Va/fuT23mRs... ) Figura 2 : Lo stesso file di zona nel DNSSEC RR in figura 2. Prima di tutto possiamo vedere che per ogni RR di figura 1 abbiamo un SIG 38

zona. Ogni RR nel vecchio file di zona è firmato mediante la chiave privata della L' RR SIG lega crittograficamente un insieme di RR al firmatario e ad un intervallo di validità. Nel nostro esempio, l'intervallo di validità della firma è segnato dai valori 19991023133034 (il tempo di scadenza 13:30:34 del 23 Ottobre 1999) e 19990923133046 (il tempo in cui venne firmata la zona 13:30:46 del 23 Settembre 1999). Notiamo anche il differente RR SIG che appare in linea 13 di figura 2. Si riferisce al RR AXFR. Questo record non era presente in figura 1. Questo SIG permette di assicurare efficientemente l'integrità e la sicurezza dei trasferimenti della zona. La firma AXFR deve essere calcolata dopo che tutti gli RR nel file di zona sono firmati e inseriti. Infatti esso appartiene a tutta la zona non solo al nome della zona. La firma AXFR è recuperata come parte di un trasferimento di zona. Le firme degli RR e dei file di dati di zona, sono generati da uno speciale programma: The zone signer (il firmatario di zona). Il compito di fare la firma è demandato all' amministratore di zona. Il programma legge tutti i dati nel file di zona, li organizza in un ordine canonico, sistema i relativi record in gruppi, li firma e aggiunge i RR SIG e NXT nei loro posti appropriati. Infine questa informazione è scritta in un file che sarà usato dopo dal name server primario di zona. L'uso del RR NXT serve per autenticare la non esistenza di un RR. Come si può vedere, la struttura del file diventa circolare, in modo che se qualcuno guarda 39

l'ultimo NXT RR nella zona, vedrà che punta all' RR del nome mydomain.com che è nella parte iniziale del file. E' anche importante osservare che i nomi nella zona sono sistemati in un ordine canonico (con una sola eccezione: il nome di zona). Il NXT RR gioca il ruolo di linkare i nomi successivi nel file di zona. Come si vede in fig.2, per ogni nome nel file di zona abbiamo un NXT RR che punta al prossimo nome nella zona e nell'ultima colonna c'è anche un elenco (un riepilogo) di tipi di RR disponibili per quel nome. Per esempio, il NXT RR per mydomain.com punta a host.mydomain.com (prossimo nome nella zona) e specifica come tipi esistenti di RR per mydomain.com i tipi NS, SOA, MX, SIG e NXT. Questo è necessario per fornire un meccanismo mediante il quale tutti possono verificare la non-esistenza di un nome in una zona o la non-esistenza di un tipo per un nome esistente. Se un Resolver chiede un nome che non esiste nel file di zona, il Server DNSSEC autoritatrivo per quel dominio, ritornerà una SOA RR firmata e anche una NXT RR che autenticherà la non-esistenza di quel nome. Per esempio, se un resolver chiede per il nome newhost.mydomain.com la A RR(indirizzo), il name server autoritativo per il dominio mydomain.com, cioè securens.mydoamin.com, ritornerà una SOA RR firmata, insieme con il NXT RR di host.mydomain.com (cioè host IN NXT securens.mydomain.com A SIG NXT). Cosa significa ciò? L'interpretazione è che tra host.mydomain.com e securens.mydomain.com non ci sono altri nomi nel file di zona e solo A, SIG e NXT RR sono disponibili per quel nome (cioè host.mydomain.com) 40

Quindi il resolver verificando la firma di NXT RR può facilmente dedurre che il nome richiesto non esiste e solo questi tre tipi sono disponibili per quel nome. In breve il NXT RR è usato per indicare in modo sicuro che gli RR con un nome proprietario in un determinato intervallo di nomi non esiste in una zona e per indicare quali RR sono associati ad un'esistente nome nella zona. Il NXT RR deve essere automaticamente elaborato e aggiunto quando si firma la zona e devono essere firmati con la chiave della zona. Integrità dei dati ed autenticazione dell origine L autenticazione è effettuata associando le firme digitali, generate crittograficamente, con insiemi di Recource Record [ RRset ] nel DNS. Una singola chiave privata viene, generalmente, utilizzata per autenticare un intera zona, ma potrebbero esistere chiavi private multiple per differenti algoritmi, differenti firme e così via. Se un resolver sicuro ottiene una chiave pubblica della zona di cui si fida può autenticare i dati autenticati, letti a partire da quella zona, se è autorizzato a farlo. Il metodo più sicuro per garantire che una zona sia sicura è tenere le chiavi private off-line e rifirmare tutti i record della propria zona periodicamente, anche se questa operazione non è sempre possibile. Nel caso, ad esempio, in cui si dovessero fare aggiornamenti dinamici le chiavi private devono essere necessariamente on-line. Ogni informazione è identificata come resource record. Tale risorsa è distinguibile in base ad un campo che ne identifica il tipo associato. Le chiavi per l autenticazione dell origine dei dati sono associate ad una zona e non al server che mantiene le copie dei dati. Questo metodo è necessario perché qualora il server secondario risultasse compromesso o persino quello primario, se le 41

chiavi fossero tenute off-line, il resolver non potrebbe determinare se un dato è genuino. Un resolver può apprendere la chiave pubblica di una zona sia leggendola dal DNS sia avendola configurata staticamente. Per potersi fidare di una chiave pubblica letta dal DNS, la chiave stessa deve essere firmata con una chiave di cui il resolver si fida. Il resolver deve essere configurato con almeno una chiave pubblica che autentica una zona come punto d'inizio. A questo punto può leggere le chiavi pubbliche delle altre zone, se le zone intermedie nell'albero del DNS sono sicure e le loro chiavi (firmate) accessibili. Il fatto di aggiungere l autenticazione dell origine dei dati e l'integrità non richiede cambiamenti al protocollo DNS presente al di là di aggiungere il contrassegno del tipo di risorsa necessario per la distribuzione della chiave. Questo servizio può essere supportato dal resolver esistente e dall'implementazione di un server di caching fatta in modo che possano supportare i tipi di risorsa addizionali. L'unica eccezione è che i CNAME2 riferiti in una zona sicura non possono essere autenticati se provengono da un server non sicuro. Autenticazione sulle transazioni e sulle risposte Il servizio di autenticazione dell'origine dei dati, fornisce garanzia sulla correttezza dei resource record [RR] o, se non dovessero esistere, sulla non esistenza di questi. 42

Se i campi dell'intestazione di una risposta sono falsati da un server non autorizzato, non c'è molto da fare, ma è possibile aggiungere autenticazione alle transazioni. Questa autenticazione garantisce ad un resolver almeno di ricevere il messaggio dal server che ha effettivamente interrogato e che la risposta è relativa alla richiesta che ha effettivamente spedito. La risposta può essere accompagnata da un SIG resource record, aggiunto alla fine della risposta, che è la firma digitale. Questa, firma tutta la catena di risoluzioni e la richiesta del resolver. Anche le richieste possono essere autenticate includendo uno speciale SIG resource record alla fine della stessa. Per quanto riguarda l'autenticazione delle richieste, non essendo ancora implementato ovunque DNSSEC, potrebbero verificarsi degli errori o non funzionare affatto con servizi DNS obsoleti. É comunque presente nel protocollo DNSSEC questa sintassi per poter effettuare richieste di update dinamico sicure oppure per utilizzi futuri che richiederanno una forma di autenticazione. CACHE POISONING Consideriamo ora l' attacco che evidenzia sempre più la necessità di un meccanismo di autenticazione più forte. Esso viene chiamato : "Cache poisoning" (Avvelenamento della cache). 43

44

45

46

47

DNSSEC Chain of Trust Quando un resolver riceve una risposta dal DNSSEC name server, deve iniziare la verifica delle firme associate agli RR ricevuti come risposta. Ma la verifica della firma dice solo che il messaggio è stato correttamente firmato. Non dice nulla circa la falsità dei dati. Così, abbiamo solo l'integrità dei dati, ma non l'autenticazione dell'origine dei dati. Il resolver deve in qualche modo determinare se la chiave KEY con cui sono stati firmati gli RR è sicura e se è autorizzato a firmare questi RR. Per fare questo deve costruire una catena verificata crittograficamente di KEY e SIG RR verso un punto di fiducia. 48

Ogni KEY RR è firmato con la chiave del padre di zona. Quindi per verificare il SIG RR di una KEY, il resolver deve recuperare informazioni sul padre delle zone. Vediamo un esempio. Supponiamo di voler recuperare l'indirizzo RR di host.mydomain.com. Il resolver dovrebbe fare una query al name server per il nome e il tipo richiesto. Quando riceve la risposta, si ha un A RR per il nome host.mydomain.com e anche un SIG RR per l'a RR insieme con un KEY RR contenente la chiave pubblica che verifica la firma. Il problema è: si puo' aver fiducia in quella chiave pubblica? Il processo di autenticazione è basato sul fatto che la chiave pubblica Root è sicura dal momento che è preconfigurata nel resolver. Assumiamo che gli RR di mydomain.com (posti sulla macchina securens.mydomain.com) erano firmati con la chiave privata di mydomain.com. La chiave pubblica (memorizzata in KEY RR recuperata da noi) è anche firmata, ma dal dominio padre, cioè con la chiave privata di com. Per verificarla, si deve recuperare anche la chiave pubblica di "com". Nella stessa maniera, la chiave pubblica di com è firmata dalla chiave privata root. Dopo le verifiche della chiave pubblica di com (con la chiave pubblica root in possesso), si deve raggiungere un punto nell'albero di cui ci si può fidare. Quindi, si può concludere che la pubblic KEY di mydomain.com può essere sicura. In questo modo, un resolver dovrebbe "imparare" a fidarsi delle chiavi verificando le loro firme passando attraverso queste catene di KEY e SIG RR. 49

In secondo luogo è necessario verificare se è possibile fidarsi dei dati messi in cache durante le precedenti valutazioni. Nel caso peggiore, un resolver dovrebbe confermare la firma delle chiavi fino al livello della radice dell' albero DNS. 50

DNS Transaction Security Questa nuova nozione fu introdotta nella terminologia DNSSEC per via di diversi fatti concernenti i resolver. Un resolver è di solito una semplice applicazione, che non è capace di memorizzare in cache e compie piccole elaborazioni. Nello schema generale DNSSEC, se un resolver deve verificare tutte le firme degli RR ricevuti, passando attraverso la catena di KEY e SIG descritta prima, dovrebbe essere migliorato con capacità di memorizzare e di verificare le firme. Questa soluzione e' di gran lunga impraticabile poichè molti resolver lavorano su piccole macchine e interagiscono con un piccolo numero di name server. Una soluzione migliore è lasciare il compito di verificare le firme al name server e introdurre una comunicazione sicura fra il name server e il resolver. Per due soli partecipanti possiamo usare la crittografia segreta della chiave con l'osservazione che essa è più veloce della crittografia della chiave pubblica e richiede meno uso della Cpu, cosicchè il peso sul resolver non sarebbe alto. In questo scenario, il resolver e il name server condividono una chiave segreta. La chiave deve essere generata fuori dal gruppo (zona). Questa chiave -la TKEY meta RR- non è memorizzata o messa in cache nel DNS e non dovrebbe apparire nei file di zona. La chiave può essere generata sia dal server che dal resolver, perciò possiamo avere chiavi assegnate al server o resolver. Per esempio nel primo caso il server DNS produce la chiave fisica. Il resolver manda una query nella quale esso richiede una TKEY RR. 51

Nella sezione addizionale di questa query, il resolver include la sua chiave pubblica, che sarà usata dal name server per criptare la chiave fisica e compilare la risposta per il resolver. Solo il resolver può decodificare la chiave simmetrica poichè esso ha la chiave privata. La chiave fisica avrà lunghezza minore uguale di 256 bit poichè è sufficiente al momento per una forte protezione con i moderni algoritmi simmetrici. Anche il cambiamento manuale della chiave è possibile. condivisa. A questo punto, il resolver e il name server hanno una chiave segreta Da ora in poi ogni messaggio proveniente dal resolver può includere una richiesta di firma e ogni messaggio dal name server al resolver può incorporare nella sezione addizionale, una firma. Queste firme sono create con la chiave simmetrica condivisa e sono autenticate dal ricevente. Per queste speciali firme, è introdotto un nuovo RR - TSIG(Transaction Signature). La differenza fra SIG e TSIG RR consiste nel fatto che le prime sono firme di insiemi di RR mentre le seconde sono firme di messaggio DNS (per gli RR nel messaggio e nell'header section). L'unico algoritmo per i messaggi, codificato per essere usato per le transizioni di firme specificato nel Internet Draft[10], è HMAC-MD5 (come definito nelle RFC 1321, 2104). 52

DNS come un PKI Abbiamo discusso la capacità del DNSSEC di memorizzare chiavi pubbliche in KEY RR. Ma questi RR possono memorizzare molto di più che chiavi pubbliche DNS. I KEY RR sono associati a zone (usati per firmare le zone DNSSEC), agli host o ad entità finali o agli utenti (il DNS può memorizzare gli user name). In più, ogni KEY RR è associato ad un protocollo, per esempio DNSSEC, IPSEC. Con l'onnipresenza del DNS in Internet, questa caratteristica di memorizzare chiavi può essere usata da altre applicazioni e protocolli come la Pubblic Key Infrastructure(PKI). Nel PKI esistente, le chiavi pubbliche sono pubblicate e autenticate per mezzo di certificati. Un certificato è un insieme contenente una chiave pubblica crittografata, un intervallo di validità, identità, e altre informazioni relative tutte legate insieme da una firma digitale. Inoltre, una Lista di revoca di certificati rappresenta una lista dei certificati revocati, tutti firmati dal distributore dei certificati di revoca. Ad esempio i certificati X.509 La cosiddetta "catena sicura " DNSSEC provvede ad una sorta di certificazione dato che la verifica dei KEY e SIG RR è simile al processo di verifica di un certificato in un PKI. Inoltre nell' RFC 2538[7], un nuovo RR è definito per il DNS per provvedere all'immagazzinamento per i certificati e le loro relative liste di revoca di certificati - i CERT RR. Secondo la RFC 2538[7], si raccomanda che i certificati siano memorizzati sotto un nome di dominio relativo all'entità che controlla la chiave privata 53

corrispondente al certificato a chiave pubblica. Anche per i CRL CERTS RR si raccomanda che siano memorizzati sotto un nome di dominio del distributore dei certificati di revoca. Le implementazioni attuali di DNS sono ottimizzate per piccoli trasferimenti, tipicamente non più di 512 byte. Quindi al momento la RFC 2538[7] raccomanda che è consigliabile sforzarsi di minimizzare la dimensione dei certificati memorizzati con il DNS. Sforzi simili sono anche fatti per raggiungere l'efficienza per i grandi trasferimenti nelle prossime generazioni delle implementazioni DNS. Osservazioni Nelle prospettive del DNS, la crittografia è usata solo per l'autenticazione e non per questioni di riservatezza. Ciò e' necessario per i resolver al fine di recuperare corrette informazioni verificabili dai server DNS esterni. Inoltre rispetta l'obiettivo primario del DNS di fornire le stesse pubbliche risposte disponibili per tutte le query senza discriminazione. Il DNSSEC coinvolge le chiavi crittografate e quindi qualche attenzione va data alla generazione delle chiavi, alla dimensione delle chiavi, la memorizzazione delle chiavi e ai problemi sui tempi di validità. In altre parole è chiaro che i KEY e SIG RR hanno una dimensione più grande di ogni altro RR nel DNS. 54

Se noi confrontiamo l'indirizzo di 4 byte di un RR con i 128 byte di un SIG RR generato da una chiave privata RSA a 1024 bit, è chiaro che la prima differenza notevole tra DNS e DNSSEC è rappresentata da un sostanziale incremento della dimensione dei file di zona e conseguentemente dei messaggi DNS scambiati. Come visto nel nostro esempio, ogni nome con un insieme di dimensione piccola di RR proveniente da un file di zona insicuro sarà aggiunto in un file di zona sicuro, con i SIG e NXT RR. Ritornando al trattamento della chiave nel DNSSEC, è utile menzionare alcune cose. Una generazione accurata della chiave è di alto interesse e non dovrebbe essere ignorata. L'algoritmo più potente che si possa immaginare usato con le chiavi piu' lunghe, non serve se un potenziale avversario può indovinare la chiave, riducendo la dimensione dello spazio della chiave, cosicchè una potente macchina può ricercarla esaustivamente. Un altro aspetto considerato è il tempo di vita (di validità) di una coppia di chiavi pubbliche. Più a lungo una chiave è in uso, più grande è la probabilità di essere compromessi attraverso trascuratezze, negligenza, spionaggio, o crittoanalisi. La RFC 2541[9] raccomanda che non dovrebbero esserci tempi maggiori di 4 anni e che un tempo ragionevole sia 13 mesi con l'idea di rimpiazzare le chiavi ogni anno. In altre parole le chiavi pubbliche con un tempo di validità troppo corto, possono condurre in un eccessivo consumo di risorse nel re-firmare la zona dati e nel recupero di informazioni più recenti, poichè le informazioni in cache sono "scadute". 55

Il minimo valore proposto è 3 minuti - la stima ragionevole del ritardo di un pacchetto. Per cio' che concerne il tempo di vita delle chiavi usate per la transaction security, l'intervallo di tempo consigliabile è 36 giorni con l'idea che le chiavi dovrebbero essere cambiate mensilmente. Al crescere della velocità dei computer ogni anno, la crittoanalisi diventa sempre più efficiente nella rottura delle chiavi. Per combattere ciò, sarebbe bene incrementare la dimensione delle chiavi verso un punto in cui, nonostante la grande capacità di elaborazione sarebbe comunque necessario un grande periodo di tempo per rompere la chiave. Il problema e' che più grandi sono le chiavi e più sicurezza si ha, ma anche più lentezza. Inoltre chiavi più grandi implicano la crescita dei KEY e SIG RR, e anche della dimensione dei messaggi DNS. Quindi cio' lascia la possibilità di un overflow per i pacchetti DNS UDP e quindi il protocollo TCP verrebbe usato con un grande overhead. Tutto cio' puo' solo condurre a risoluzioni di nomi piu' lente con tutte le sue conseguenze (RFC 2539[8]) Ugualmente importante è la memorizzazione delle chiavi private. Le raccomandazioni per questo concetto sono che le chiavi private della zona e la copia principale del file di zona siano tenute e usate per firmare off-line, su computer non connessi in rete e computer fisicamente sicuri. Anche i resolver sicuri devono essere configurati con alcune chiavi pubbliche fidate on-line altrimenti essi non potranno verificare gli RR recuperati. 56

Inoltre questa chiave pubblica deve essere ulteriormente protetta, altrimenti è possibile che Per le zone dei domini top-level e per la zona root il problema di rendere sicure le chiavi private deve essere discusso in un modo differente. Un attaccante che potesse prendere la chiave privata di una zona top-level potrebbe diventare autoritativa per tutti i sottodomini di livello inferiore. Allo stesso modo chiunque ottenesse la chiave privata di zona, avrebbe il controllo sull'intero spazio DNS di tutti i resolver configurati per usare la chiave pubblica della zona root. Quindi la sicurezza della chiave della zona root e delle chiavi private delle zone top-level è di grande importanza. La chiave piu' "forte", piu' grande e quella piu' accuratamente trattata dovrebbe essere usata per queste zone e la chiave privata della zona root dovrebbe essere sempre essere tenuta off-line. Il tempo di validità di una tale chiave dovrebbe variare da 10 a 15 anni poichè un aggiornamento di un enorme massa di resolver intorno a Internet sarebbe difficile da realizzare spesso (anche tutte le chiavi pubbliche top-level dovrebbero essere firmate ancora dalla nuova chiave privata della zona root). 57

Conclusioni Le estensioni per la sicurezza provvedono alla: Protezione dei trasferimenti su Internet I dati sono firmati con chiavi pubbliche (RRSIG, DNSKEY) L'assenza di dati DNS è notificata (NSEC) Protezione per i traferimenti DNS locali I messaggi fra name server e resolver sono autenticati (TSIG) Trasferimenti di zona fra name server primari e secondari (TSIG) Infrastruttura a chiave pubblica (KEY) Distribuzione di chiavi pubbliche per altri protocolli di sicurezza Distribuzione di differenti tipi di certificati (CERT) 58

TIPI DI RR A 1 RFC 1035[1] record di indirizzo restituisce un indirizzo IPv4 a 32 bit, normalmente utilizzato per collegare un nome host al suo indirizzo IP. AAAA 28 RFC 3596[2] record di indirizzo IPv6 restituisce un indirizzo IPv6 a 128 bit, normalmente utilizzato per collegare un nome host al suo indirizzo IPv6. AFSDB 18 RFC 1183 record del database AFS puntamento al server di database AFS. Questo record è utilizzato dai client AFS per contattare un server AFS fuori dal proprio dominio. Un sottotipo di questo record era utilizzato dall'obsoleto file system DCE/DFS. AXFR 252 RFC 1035[1] Trasferimento dell'intera zona Richiesta di trasferimento dell'intera zona dal server principale ad un secondario. CERT 37 RFC 4398[3] Record di certificato Trasferisce un certificato di tipo PKIX, SPKI, PGP, ecc. CNAME 5 RFC 1035[1] record di nome canonico DHCID 49 RFC 4701[4] Identificazione DHCP Permette di collegare un nome DNS ad un altro. La risoluzione continuerà con il nuovo nome indicato dal record CNAME. Questa funzione è molto utile quando, ad esempio, sullo stesso server sono disponibili più servizi come FTP, WEB ecc operanti su porte differenti. Ciascun servizio potrà avere il suo riferimento DNS (ad esempio ftp.example.com. e www.example.com.). È molto utile anche quando sullo stesso server ci sono più istanze web con differenti nomi ma utilizzando lo stesso indirizzo. Questa funzione richiede, però, il supporto da parte del server di identità multiple con riconoscimento dell'intestazione http. Utilizzato in congiunzione con un record FQDN restituisce informazioni sul server DHCP DLV 32769 RFC 4431[5] Record per la validazione DNSSEC DNAME 39 RFC 2672[6] nome di delegazione Utilizzato per pubblicare un puntatore a un certificato DNSSEC fuori dalla catena di delegazione. Opera in modo simile al record CNAME ma invece di far riferimento ad un singolo nome fa riferimento ad una porzione di albero DNS sotto un nuovo nome. Analogamente a CNAME la risoluzione continuerà con il nuovo nome. DNSKEY 48 RFC 3755[7] record chiave DNS Il record chiave utilizzato in DNSSEC DS 43 RFC 3658[8] Delegazione del firmatario Utilizzato per identificare la chiave di firma DNSSEC per una zona delegata HIP 55 RFC 5205[9] Host Identity Protocol Un protocollo che consente di aumentare la sicurezza separando gli indirizzi IP degli host. RFC IPSECKEY 45 4025[10] Chiave IPSEC Utilizzato per trasferire informazioni IPSEC IXFR 251 KEY 25 RFC 1995[11] Trasferimento di zona incrementale RFC 4034[12] Record chiave Trasferisce la porzione di zona che è stata cambiata dal server DND principale ad un secondario. Utilizzato solo per TKEY (RFC 2930). Prima che fosse pubblicata l'rfc 3755 era anche utilizzato per DNSSEC, attualmente DNSSEC utilizza DNSKEY. 59

LOC 29 RFC 1876[13] Record di localizzazione Associa una localizzazione geografica ad un nome DNS. MX 15 RFC 1035[1] Server di posta NAPTR 35 RFC 3403[14] Naming Authority Pointer NS 2 RFC 1035[1] Riferimento ai server DNS Collega un nome di dominio ad una lista di server di posta autoritativi per quel dominio. I record indicano anche la preferenza di un server rispetto ad un altro. Un nuovo tipo di record DNS che supporta l'indirizzamento utilizzando espressioni regolari. Delega una zona DNS ad essere gestita da un server DNS autoritativo per quel nome di dominio. NSEC 47 RFC 3755[7] Record Next-Secure Utilizzato da DNSSEC per stabilire se un nome non esiste. NSEC3 50 RFC 5155[15] Record NSEC versione 3 utilizzato da DNSSEC. NSEC3PARAM 51 RFC 5155[7] Parametri NSEC3 Parametri del record NSEC3. RFC OPT 41 2671[16] Option Pseudo record DNS necessario per supportare EDNS PTR 12 RFC 1035[1] Record puntatore Puntatore ad un nome canonico utilizzato per la risoluzione DNS inversa. Inserendo un record PTR per un nome canonico di dominio nella zona in-addr.arpa. fa si che si possa risalire al nome host dal suo indirizzo IP. RRSIG 46 RFC 3755[7] Firma DNSSEC Firma per una serie di record DNSSEC sicuri SIG 24 RFC 2535[17] Firma Record di firma utilizzato in SIG(0) (RFC 2931). Prima che fosse pubblicata l'rfc 3755 era anche utilizzato per DNSSEC, attualmente DNSSEC utilizza RRSIG. SOA 6 RFC 1035[1] Record di start of authority Restituisce informazioni autoritative sulla zona DNS, incluso il server DNS principale, l'e-mail dell'amministratore, il numero seriale del dominio (utile per sapere se i dati della zona sono stati variati) e diversi timer che regolano la frequenza di trasferimento e la durata di validità dei record. SPF 99 SRV 33 RFC 4408[18] Record SPF RFC 2872[19] Localizzatore di servizi Specifica dati relativi al protocollo SPF. In alternativa questi dati posso essere inseriti in un record TXT. Un servizio generalizzato di ricerca di servizi molto utile per nuovi protocolli per non dover aggiungere tipi di record specializzati come ad esempio il record MX. SSHFP 44 RFC 4255[20] Impronta della chiave pubblica SSH Pubblica la chiave pubblica dell'host SSH sul DNS, in modo da aiutare la verifica dell'autenticità dell'host. TA 32768 Nessuna Certificazione DNSSEC Parte della proposta DNSSEC senza una radice DNS firmata.[21] TKEY 249 TSIG 250 RFC 2930[22] Chiave di transazione RFC 2845[23] Firma di transazione Supporta un metodo per rendere sicuro il DNS. Implementa la sicurezza fra il server DNS che risolve la richiesta e il server autoritativo di zona. DNSSEC, al contrario, rende sicuri i singoli record. Supporta un insieme di meccanismi di sicurezza del DNS. Implementa la sicurezza fra il server DNS che risolve la richiesta e il server autoritativo di zona. DNSSEC, al contrario, rende sicuri i singoli record. TXT 16 RFC 1035[1] Record di testo Era stato pensato per aggiungere commenti leggibili ad un record DNS. Dall'inizio degli anni '90, invece, è utilizzato per trasferire informazioni di sicurezza in accordo alla RFC 1464, opportunistic encryption, Sender Policy Framework s DomainKeys. Il systema di DNS dinamico del server dhcp ISC utilizza campi di testo nelle zone dinamiche per identificare i record modificati dal server DHCP. 60

Bibliografia Douglas E. Comer, "Internetworking con TCP/IP", Addison-Wesley, 2002. Internet Draft "Secret Key Transaction Signatures for DNS (TSIG)", Paul Vixie (Ed.) (ISC), Olafur Gudmundsson (NAILabs), Donald Eastlake (IBM), Brian Wellington (NAILabs), July 1999. January 1999. Brian Wellington, "An Introduction to Domain Name System Security", TIS Labs, Paul Albitz, Cricket Liu, "DNS and BIND", Third Edition, O'Reilly, Sebastopol, CA, 1998, ISBN 1-56592-512-2. Le RFC utilizzate, sono di seguito elencate e sono disponibili all'indirizzo http://www.dnssec.net/rfc.php November 1987. RFC 1034 "Domain Name System - Concepts and Facilities", Paul Mockapetris, ISI, RFC 1035 "Domain Name System - Implementation and Specification", Paul Mockapetris, ISI, November 1987. RFC 2065 "Domain Name System Security Extensions", Donald Eastlake, IBM, C. Kaufman, January 1997. 1999. RFC 2535 "Domain Name System Security Extensions", Donald Eastlake, IBM, March IBM, March 1999. RFC 2536 "DSA KEYs and SIGs in the Domain Name System (DNS)", Donald Eastlake, RFC 2537 "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", Donald Eastlake, IBM, March 1999. RFC 2538 "Storing Certificates in the Domain Name System", Donald Eastlake, IBM, Olafur Gudmundsson, TIS Labs, March 1999. 61

RFC 2539 "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", Donald Eastlake, IBM, March 1999. 1999. RFC 2541 "DNS Security Operational Considerations", Donald Eastlake, IBM, March 62