DNSSEC

1. Università degli studi “G. D’Annunzio” Corso di Laurea Specialistica in Economia Informatica DNSSEC COME GARANTIRE LA PROTEZIONE DEL TRASFERIMENTO DEI DATI DEL DNS CON L’AUSILIO DELLA CRITTOGRAFIA Seminario per il corso di “Reti di calcolatori e sicurezza” Prof. Stefano Bistarelli Realizzato da: Tomassetti Ennio enniotomassetti@hotmail.com

2. SOMMARIO • Breve panoramica sul Domain Name System. • Debolezze del DNS. • Le soluzioni offerte dal DNSSEC. • Conclusioni.

3. Domain Name System (1) • Database gerachico, distribuito : • Basato sul modello client-server • nome  indirizzo-IP (traduzione) • DNS può utilizzare protocollo TCP o UDP • Principalicomponenti: • domainspacename descritto dai ResourceRecords RR (ad es. SOA, A, MX, NS….) • nameservers • resolvers

4. Refreshes System call Recursive query Name resolver Primary name server User program Cache Response References Resolver’sresponse Local machine Iterativequery Name server Name server Iterativequery Referral Response Processo di risoluzione dei nomi

5. Perché la sicurezza del DNS è importante? • I name server possono essere “truffati” facilmente e sono vulnerabili a molti tipi di attacchi (DoS, buffer overrun, replay) • I Resolver possono essere indotti a “credere” in informazioni false. • Misure di sicurezza (ad es. ACLs) e altri inganni rendono più difficile da compiere ma non impossibile! • Nel giugno del 1997, EugeneKashpureff (fondatore dell’Alternic) ha reindirizzato il dominio internic.net as alternic.net mettendo in cache informazioni false su Name Server di Internic.(Cache Poisoning)

6. Destinazione Errata Indotta • Scenario: un utente vuole connettersi ad un host A mediante un telnet client. Il telnet client chiede, attraverso un resolver, il NS locale per risolvere il nome A in un indirizzo IP. Esso riceve un’informazione falsa e inizia una connessione TCP al server telnet sulla macchina A (almeno così crede). • I router attuali non hanno la capacità di respingere i pacchetti con falsi indirizzi sorgenti→ l’attaccante se può instradare pacchetti a chiunque, può indurre a farli considerare come pacchetti provenienti da un host fidato. • NB: con un firewall per la rete dell’utente, il resolver non sarebbe raggiungibile dal mondo esterno, ma il suo NS locale si!!! Quindi se il NS può essere corrotto, l’attaccante può reindirizzare applicazioni con informazioni vitali verso host sotto il suo controllo e catturare queste informazioni.

7. Autenticazioni e Autorizzazioni basate sui nomi • 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 attraverso una monitorizzazione della rete può venire a conoscenza di un’eventuale equivalenza utilizzata in quella rete, e operare con l’indirizzo IP di un host equivalente. • In questo modo l’host dell’attaccante è completamente equivalente all’host attaccato per tutti i computer che usano l’equivalenza remota.

8. 2.anyhost.evil.com? broker.com evil.com 1.anyhost.evil.com? ns.evil.com ns.broker.com 5.anyhost.evil.com=A.B.C.E cache 9.www.bank.com= A.B.C.D 4. anyhost.evil.com=A.B.C.E Host Attaccante A.B.C.D 10.www.bank.com? 6. www.bank.com? any.broker.com 8. www.bank.com=A.B.C.D 11.Risposta errata dalla cache Inondare il Name Server con false risposte 12. Connessione errata all’host attaccante bank.com 7. www.bank.com ns.bank.com DNS cache poisoning attack 3. Memorizza query ID

9. Impersonare il Master Imitare la cache Corruzione Dati Zone file Dynamic updates Data spoofing Update non autorizzati PROTEZIONE SERVER PROTEZIONE DATI Flusso dei dati DNS Zone administrator master resolver slaves stub resolver

10. DNSSECcoinvolgiamo la crittografia • RFC 2065 e successiva RFC 2535 • Estensione per la sicurezza del DNS • Standardizzazione in maniera formale • Utilizzo della crittografia • Gruppo di lavoro DNSSEC IETF

11. Imitare la cache Zone administrator Zone file master resolver slaves Dynamic updates stub resolver Data spoofing PROTEZIONE DATI DNSSEC KEY/SIG/NEXTautenticazione ed integrità dei dati

12. DNSSEC nuovi RRs • Primo passo: provvedere all’autenticazione dei dati per gli RR che vanno avanti e indietro in internet. • Integrità dei dati e autenticazione dei dati sorgenti. • Firmadigitalecrittografica a chiave pubblica. • DNS security extensions (RFC 2535-2537): • SIG: firma dell’RRset mediante chiave privata • KEY: chiave pubblica, necessaria per verificare SIG. • NXT: indica il successivo RRs all’interno di una zona, necessario per verificare la non-esistenza di nomi o tipi di RRs in un dominio.

13. DNSSEC DNS • KEY RR specifica: • Il tipo di chiave (zone, host, user) • Il protocollo (DNSSEC, IPSEC, TLS… ecc.) • l’algoritmo (RSA/MD5, DSA) NB: La struttura del file diventa circolare. Se un resolver chiede un nome che non esiste nel file di zona, il server DNSSEC autoritativo per quella zona ritornerà una SOA RR e un NXT RR che autenticheranno la non-presenza di quel nome. • SIG RR specifica • Il tipo RR contenuto. • L’algoritmo di criptazione. • Inception & expiration time. • L’”impronta” della chiave. • NXT RR specifica: • Il nome seguente nella zona. • Tutti gli RR coperti dal nome corrente. FILE DI ZONA Semplice file dati di zona nel quale sono presenti gli RR SOA, NS, MX con i relativi IP.

14. DNSSEC chain of trust (1) • Ogni KEY RR è firmato con la chiave del padre di zona. • Per verificare il SIG RR di una KEY, il resolver deve recuperare informazioni sul padre delle zone. • Si può avere fiducia nella chiave pubblica? • Il processo di autenticazione è basato sul fatto che lachiavepubblicaRootèsicura dal momento che è preconfiguratanelresolver. • La chiave pubblica (recuperata nel KEY RR) è anche firmata, ma dal dominio padre (ad esempio com) con la sua chiave privata. • Per verificarla bisogna recuperare anche la chiave pubblica di com che sarà firmata dalla chiave privata di root. • Dopo la verifica della chiave pubblica di com (con la chiave pubblica di root in nostro possesso) possiamo essere sicuri della validità della chiave iniziale ottenuta. • Un resolver quindi dovrebbe “imparare” afidarsidellechiavi verificando le loro firme passando attraverso queste catene di KEY e SIG RR fino ad un punto nell’albero in cui ci si può fidare.

15. Root name server dell’albero DNS com. it. KEY percom.? name server Riceve KEY, SIG RRs ofcom. foo.com. host.foo.com. ? name server unich.it. Local name server Riceve l’RRs: A, SIG, KEY host.foo.com. 131.195.21.25 DNSSEC chain of trust (2) La chiave pubblica del dominio radice è ritenuta fidata a priori da tutti i name server!!

16. Impersonare il Master Corruzione Dati Zone administrator Zone file master resolver slaves Dynamic updates stub resolver Update non autorizzati PROTEZIONE SERVER DNSSEC TSIG/SIG(0)protezione tra server

17. DNS Transaction Security • Resolver attualmente troppo semplici per la verifica delle firme. • Sol. La verifica delle firme è lasciata al NS e si introduce una comunicazione sicura tra NS e resolver. • NS e resolver condividono una chiave segreta. • TKEY RR: utilizzato dal resolver per chiedere la chiave pubblica del NS con allegata la prorpia chiave pubblica che verrà utilizzata dal NS per criptare la chiave fisica. • D’ora in poi ogni comunicazione tra NS e resolver avviene attraverso firma. • Per queste speciali firme si utilizza il nuovo TSIG RR. • Algoritmo di criptazione HMAC-MD5 (RFC 1321, 2104).

18. DNS come un PKI • I KEY RR (contengono chiavi pubbliche) sono associati a zone, agli host, ad entità finali e agli utenti. • Omnipresenza del DNS in internet → utilizzo per applicazioni o protocolli come la PKI. • Nel PKI esistente la chiavi pubbliche sono pubblicate e autenticate per mezzo di certificati. • La “Chain of Trust” DNSSEC provvede ad una sorta di autenticazione dato che la verifica di KEY e SIG RR è simile al processo di autenticazione di PKI. • Nell’ RFC 2538 è definito un possibile nuovo CERT RR per l’immagazzinamento dei certificati. • CERT RR può memorizzare certificati PGP, X.509, SPKI. • La RFC 2538 raccomanda che è consigliabile minimizzare la dimensione del certificato visto che le implementazioni attuali del DNS sono ottimizzate per piccoli trasferimenti (<512 byte).

19. Ricapitolando sul DNSSEC • Nel DNS la crittografia è utilizzata per l’autenticazione/integrità e non per questioni di riservatezza. • Bisogna dare attenzione alla generazione delle chiavi, alla dimensione delle chiavi, alla memorizzazione delle chiavi e ai problemi sui tempi di validità. • i resolver sicuri devono essere configurati con alcune chiavi pubbliche sicure on-line altrimenti non potranno verificare la validità degli RR. • La dimensione dei file di zona aumenta vertiginosamente. • Aumentano: dimensione dei dati trasferiti, dimensione dei messaggi (possibili overflow per pacchetti DNS UDP → utilizzo del TCP con un grande overhead), e il numero di cicli di CPU. • La responsabilità degli amministratori incrementa!!!

20. CONCLUSIONI • Le estensioni per la sicurezza provvedono alla: • Protezione dei trasferimenti su Internet: • Dati firmati con chiavi pubbliche (SIG, KEY). • L’assenza di dati DNS è notificata (NXT). • Protezioneper i trasferimenti DNS locali: • I messaggi tra NS e resolver sono autenticati (TSIG). • Trasferimenti di zona tra NS primari e secondari (TSIG). • Infrastruttura a chiave pubblicaPKI: • Distribuzione di chiavi pubbliche per altri protocolli di sicurezza (KEY). • Distribuzione di diversi tipi di certificati (CERT).