DNSSEC COME GARANTIRE LA PROTEZIONE DEL TRASFERIMENTO DEI DATI DEL DNS CON LAUSILIO DELLA CRITTOGRAFIA Seminario per il corso di Reti di calcolatori e.

Presentazione sul tema: "DNSSEC COME GARANTIRE LA PROTEZIONE DEL TRASFERIMENTO DEI DATI DEL DNS CON LAUSILIO DELLA CRITTOGRAFIA Seminario per il corso di Reti di calcolatori e."— Transcript della presentazione:

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

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

3 Domain Name System (1) Database gerachico, distribuito : Database gerachico, distribuito : Basato sul modello client-server Basato sul modello client-server nome indirizzo-IP (traduzione) nome indirizzo-IP (traduzione) DNS può utilizzare protocollo TCP o UDP DNS può utilizzare protocollo TCP o UDP Principali componenti: Principali componenti: domain space name descritto dai Resource Records RR (ad es. SOA, A, MX, NS….) domain space name descritto dai Resource Records RR (ad es. SOA, A, MX, NS….) name servers name servers resolvers resolvers

4 Processo di risoluzione dei nomi System call Resolvers response Refreshes Recursive query References Response User program Name resolver Local machine Primary name server Cache Name server Name server Iterative query Response Iterative query Referral

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 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. 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! Misure di sicurezza (ad es. ACLs) e altri inganni rendono più difficile da compiere ma non impossibile! Nel giugno del 1997, Eugene Kashpureff (fondatore dellAlternic) ha reindirizzato il dominio internic.net as alternic.net mettendo in cache informazioni false su Name Server di Internic.(Cache Poisoning) Nel giugno del 1997, Eugene Kashpureff (fondatore dellAlternic) 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 uninformazione falsa e inizia una connessione TCP al server telnet sulla macchina A (almeno così crede). 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 uninformazione 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 lattaccante se può instradare pacchetti a chiunque, può indurre a farli considerare come pacchetti provenienti da un host fidato. I router attuali non hanno la capacità di respingere i pacchetti con falsi indirizzi sorgenti lattaccante 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 dellutente, il resolver non sarebbe raggiungibile dal mondo esterno, ma il suo NS locale si!!! Quindi se il NS può essere corrotto, lattaccante può reindirizzare applicazioni con informazioni vitali verso host sotto il suo controllo e catturare queste informazioni. NB: con un firewall per la rete dellutente, il resolver non sarebbe raggiungibile dal mondo esterno, ma il suo NS locale si!!! Quindi se il NS può essere corrotto, lattaccante 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 lautenticazione basata sui nomi rischiano poiché un attaccante può prendere il controllo di una singola macchina della rete protetta dal firewall. Tutti gli host che usano lautenticazione basata sui nomi rischiano poiché un attaccante può prendere il controllo di una singola macchina della rete protetta dal firewall. Lattaccante attraverso una monitorizzazione della rete può venire a conoscenza di uneventuale equivalenza utilizzata in quella rete, e operare con lindirizzo IP di un host equivalente. Lattaccante attraverso una monitorizzazione della rete può venire a conoscenza di uneventuale equivalenza utilizzata in quella rete, e operare con lindirizzo IP di un host equivalente. In questo modo lhost dellattaccante è completamente equivalente allhost attaccato per tutti i computer che usano lequivalenza remota. In questo modo lhost dellattaccante è completamente equivalente allhost attaccato per tutti i computer che usano lequivalenza remota.

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

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

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

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

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

13 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. FILE DI ZONA DNS DNSSEC Semplice file dati di zona nel quale sono presenti gli RR SOA, NS, MX con i relativi IP. SIG RR specificaSIG RR specifica Il tipo RR contenuto.Il tipo RR contenuto. Lalgoritmo di criptazione.Lalgoritmo di criptazione. Inception & expiration time.Inception & expiration time. Limpronta della chiave.Limpronta della chiave. NXT RR specifica:NXT RR specifica: Il nome seguente nella zona.Il nome seguente nella zona. Tutti gli RR coperti dal nome corrente.Tutti gli RR coperti dal nome corrente. KEY RR specifica:KEY RR specifica: Il tipo di chiave (zone, host, user)Il tipo di chiave (zone, host, user) Il protocollo (DNSSEC, IPSEC, TLS… ecc.)Il protocollo (DNSSEC, IPSEC, TLS… ecc.) lalgoritmo (RSA/MD5, DSA) lalgoritmo (RSA/MD5, DSA)

14 DNSSEC chain of trust (1) Ogni KEY RR è firmato con la chiave del padre di zona. 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. Per verificare il SIG RR di una KEY, il resolver deve recuperare informazioni sul padre delle zone. Si può avere fiducia nella chiave pubblica? Si può avere fiducia nella chiave pubblica? Il processo di autenticazione è basato sul fatto che la chiave pubblica Root è sicura dal momento che è preconfigurata nel resolver. Il processo di autenticazione è basato sul fatto che la chiave pubblica Root è sicura dal momento che è preconfigurata nel resolver. La chiave pubblica (recuperata nel KEY RR) è anche firmata, ma dal dominio padre (ad esempio com) con la sua chiave privata. 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. 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. 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 a fidarsi delle chiavi verificando le loro firme passando attraverso queste catene di KEY e SIG RR fino ad un punto nellalbero in cui ci si può fidare. Un resolver quindi dovrebbe imparare a fidarsi delle chiavi verificando le loro firme passando attraverso queste catene di KEY e SIG RR fino ad un punto nellalbero in cui ci si può fidare.

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

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

17 DNS Transaction Security Resolver attualmente troppo semplici per la verifica delle firme. 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. 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. 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. 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. Dora in poi ogni comunicazione tra NS e resolver avviene attraverso firma. Dora in poi ogni comunicazione tra NS e resolver avviene attraverso firma. Per queste speciali firme si utilizza il nuovo TSIG RR. Per queste speciali firme si utilizza il nuovo TSIG RR. Algoritmo di criptazione HMAC-MD5 (RFC 1321, 2104). 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. 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. 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. 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. 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 limmagazzinamento dei certificati. Nell RFC 2538 è definito un possibile nuovo CERT RR per limmagazzinamento dei certificati. CERT RR può memorizzare certificati PGP, X.509, SPKI. 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). 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 lautenticazione/integrità e non per questioni di riservatezza. Nel DNS la crittografia è utilizzata per lautenticazione/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à. 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. 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. 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. 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!!! La responsabilità degli amministratori incrementa!!!

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