 Debolezze Debolezze del DNS. del DNS.

DNSSEC DNSSEC

COME GARANTIRE LA PROTEZIONE DEL COME GARANTIRE LA PROTEZIONE DEL TRASFERIMENTO DEI DATI DEL

TRASFERIMENTO DEI DATI DEL DNSDNS CON CON L’AUSILIO DELLA CRITTOGRAFIA

L’AUSILIO DELLA CRITTOGRAFIA

Seminario per il corso di “Reti di calcolatori e sicurezza”

Seminario per il corso di “Reti di calcolatori e sicurezza”

Prof. Stefano Bistarelli Prof. Stefano Bistarelli

Realizzato da: Tomassetti Ennio Realizzato da: Tomassetti Ennio

enniotomassetti@hotmail.com enniotomassetti@hotmail.com Università degli studi “G. D’Annunzio”

Università degli studi “G. D’Annunzio”

Corso di Laurea Specialistica in Economia Informatica Corso di Laurea Specialistica in Economia Informatica

SOMMARIO SOMMARIO

 Breve panoramica sul Breve panoramica sul Domain Name System. Domain Name System.

 Debolezze _Debolezze del DNS. del DNS.

 Le soluzioni offerte dal Le soluzioni offerte dal DNSSEC DNSSEC . .

 Conclusioni. Conclusioni.

Domain Name System (1) Domain Name System (1)

 Database Database gerachico gerachico , , distribuito distribuito : :

 Basato sul modello client-serverBasato sul modello client-server

 nome nome  indirizzo-IP (traduzione) indirizzo-IP (traduzione)

 DNS può utilizzare protocollo DNS può utilizzare protocollo TCP TCP o o UDP UDP

 Principali Principali componenti: componenti:

 domaindomain spacespace namename descritto dai descritto dai ResourceResource RecordsRecords RR (ad es. SOA, A, MX, NS….)

RR (ad es. SOA, A, MX, NS….)

 namename serversservers

 resolversresolvers

Processo di risoluzione dei nomi Processo di risoluzione dei nomi

System call

Resolver’s 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

Perché la sicurezza del DNS è Perché la sicurezza del DNS è

importante?

importante?



I I name servername server possono essere “ possono essere “truffatitruffati” facilmente e ” facilmente e sono vulnerabili a molti tipi di attacchi (DoS, buffer sono vulnerabili a molti tipi di attacchi (DoS, buffer

overrun, replay) overrun, replay)



I I ResolverResolver possono essere indotti a “credere” in possono essere indotti a “credere” in informazioni false.

informazioni false.



Misure di sicurezza (ad es. ACLs) e altri inganni rendono Misure di sicurezza (ad es. ACLs) e altri inganni rendono più difficile da compiere ma non impossibile!

più difficile da compiere ma non impossibile!



Nel giugno del 1997, Nel giugno del 1997, EugeneEugene KashpureffKashpureff (fondatore (fondatore dell’Alternic) ha reindirizzato il dominio

dell’Alternic) ha reindirizzato il dominio internic.netinternic.net as as alternic.net

alternic.net mettendo in cache informazioni false su mettendo in cache informazioni false su Name Server di Internic.(Cache Poisoning)

Name Server di Internic.(Cache Poisoning)

Destinazione Errata Indotta Destinazione Errata Indotta



Scenario: un utente vuole connettersi ad un host A Scenario: un utente vuole connettersi ad un host A

mediante un telnet client. Il telnet client chiede, attraverso mediante un telnet client. Il telnet client chiede, attraverso

un resolver, il NS locale per risolvere il nome A in un un resolver, il NS locale per risolvere il nome A in un

indirizzo IP. Esso riceve un’informazione falsa e inizia indirizzo IP. Esso riceve un’informazione falsa e inizia

una connessione TCP al server telnet sulla macchina A una connessione TCP al server telnet sulla macchina A

(almeno così crede).

(almeno così crede).



I router attuali non hanno la capacità di respingere i I router attuali non hanno la capacità di respingere i pacchetti con falsi indirizzi sorgenti

pacchetti con falsi indirizzi sorgenti → l’attaccante se → l’attaccante se può instradare pacchetti a chiunque, può indurre a farli può instradare pacchetti a chiunque, può indurre a farli

considerare come pacchetti provenienti da un host fidato.

considerare come pacchetti provenienti da un host fidato.



NB: con un firewall per la rete dell’utente, il resolver non NB: con un firewall per la rete dell’utente, il resolver non sarebbe raggiungibile dal mondo esterno, ma il suo NS sarebbe raggiungibile dal mondo esterno, ma il suo NS

locale si!!! Quindi se il NS può essere corrotto, locale si!!! Quindi se il NS può essere corrotto,

l’attaccante può reindirizzare applicazioni con l’attaccante può reindirizzare applicazioni con

informazioni vitali verso host sotto il suo controllo e informazioni vitali verso host sotto il suo controllo e

catturare queste informazioni.

catturare queste informazioni.

Autenticazioni e Autorizzazioni Autenticazioni e Autorizzazioni

basate sui nomi basate sui nomi

 Tutti gli host che usano Tutti gli host che usano l’autenticazione basata l’autenticazione basata sui nomi

sui nomi rischiano poiché un attaccante può rischiano poiché un attaccante può prendere il controllo di una singola macchina prendere il controllo di una singola macchina

della rete protetta dal firewall.

della rete protetta dal firewall.

 L’attaccante attraverso una monitorizzazione L’attaccante attraverso una monitorizzazione della rete può venire a conoscenza di

della rete può venire a conoscenza di

un’eventuale equivalenza utilizzata in quella un’eventuale equivalenza utilizzata in quella

rete, e operare con l’indirizzo IP di un host rete, e operare con l’indirizzo IP di un host

equivalente.

equivalente.

 In questo modo In questo modo l’host dell’attaccante è l’host dell’attaccante è

completamente equivalente all’host attaccato completamente equivalente all’host attaccato

per tutti i computer che usano l’equivalenza per tutti i computer che usano l’equivalenza

remota.

remota.

DNS cache poisoning attack 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 all’host 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

Flusso dei dati DNS 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 PROTEZIONE SERVER

Data spoofing

Imitare la cache

PROTEZIONE DATI PROTEZIONE DATI

DNSSEC DNSSEC

coinvolgiamo la crittografia coinvolgiamo la crittografia

 RFC 2065 RFC 2065 e successiva e successiva RFC 2535 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

DNSSEC KEY/SIG/NEXT DNSSEC KEY/SIG/NEXT

autenticazione ed integrità dei dati autenticazione ed integrità dei dati

master resolver

stub resolver

Zone administrator

slaves Zone file

Dynamic updates

Data spoofing

Imitare la cache

PROTEZIONE DATI PROTEZIONE DATI

DNSSEC nuovi RRs DNSSEC nuovi RRs



Primo passo: provvedere Primo passo: provvedere all’autenticazione dei datiall’autenticazione dei dati per gli RR per gli RR che vanno avanti e indietro in internet.

che vanno avanti e indietro in internet.



IntegritàIntegrità dei dati e dei dati e autenticazioneautenticazione dei dati sorgenti. dei dati sorgenti.



FirmaFirma digitaledigitale crittograficacrittografica a chiave pubblica. a chiave pubblica.



DNS security extensions (RFC 2535-2537):DNS security extensions (RFC 2535-2537):

 SIG: firma dell’RRset mediante chiave privataSIG: firma dell’RRset mediante chiave privata

 KEYKEY: chiave pubblica, necessaria per verificare SIG.: chiave pubblica, necessaria per verificare SIG.

 NXTNXT: indica il successivo RRs all’interno di una zona, necessario per : indica il successivo RRs all’interno di una zona, necessario per verificare la non-esistenza di nomi o tipi di RRs in un dominio.

verificare la non-esistenza di nomi o tipi di RRs in un dominio.

NB: La struttura del file diventa NB: La struttura del file diventa circolare. Se un resolver chiede un circolare. Se un resolver chiede un nome che non esiste nel file di

nome che non esiste nel file di

zona, il server DNSSEC autoritativo zona, il server DNSSEC autoritativo per quella zona ritornerà una SOA per quella zona ritornerà una SOA RR e un NXT RR che

RR e un NXT RR che

autenticheranno la non-presenza di autenticheranno la non-presenza di quel nome.

quel nome.

FILE DI ZONA FILE DI ZONA

DNSDNS DNSSECDNSSEC

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.

•L’algoritmo di criptazione.L’algoritmo di criptazione.

•Inception & expiration Inception & expiration time.

time.

•L’”impronta” della chiave.L’”impronta” della chiave.

•NXT RR specifica:NXT RR specifica:

•Il nome seguente nella Il nome seguente nella zona.

zona.

•Tutti gli RR coperti dal Tutti gli RR coperti dal nome corrente.

nome corrente.

•KEY RR specifica:KEY RR specifica:

•Il tipo di chiave (zone, host, Il tipo di chiave (zone, host, user)

user)

•Il protocollo (DNSSEC, Il protocollo (DNSSEC, IPSEC, TLS… ecc.)

IPSEC, TLS… ecc.)

• l’algoritmo (RSA/MD5, DSA)l’algoritmo (RSA/MD5, DSA)

DNSSEC chain of trust (1) DNSSEC chain of trust (1)

 Ogni Ogni KEY RRKEY RR è firmato con la è firmato con la chiave del padre di zonachiave del padre di zona..

 Per verificare il Per verificare il SIG RRSIG RR di una KEY di una KEY, il resolver deve recuperare , il resolver deve recuperare informazioni sul padre delle zone.

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 Il processo di autenticazione è basato sul fatto che lala chiavechiave pubblica

pubblica Root Root è è sicurasicura dal momento che è preconfigurata dal momento che è preconfigurata nel nel resolver

resolver..

 La chiave pubblica (recuperata nel KEY RR) è anche firmata, ma La chiave pubblica (recuperata nel KEY RR) è anche firmata, ma dal dominio padre (ad esempio com) con la sua chiave privata.

dal dominio padre (ad esempio com) con la sua chiave privata.

 Per verificarla bisogna recuperare anche la chiave pubblica di com Per verificarla bisogna recuperare anche la chiave pubblica di com che sarà firmata dalla chiave privata di root.

che sarà firmata dalla chiave privata di root.

 Dopo la verifica della chiave pubblica di com (con la chiave pubblica Dopo la verifica della chiave pubblica di com (con la chiave pubblica di root in nostro possesso) possiamo essere sicuri della validità

di root in nostro possesso) possiamo essere sicuri della validità della chiave iniziale ottenuta.

della chiave iniziale ottenuta.

 Un Un resolverresolver quindi quindi dovrebbedovrebbe “ “imparareimparare” ” aa fidarsifidarsi delledelle chiavichiavi verificando le loro firme passando attraverso queste

verificando le loro firme passando attraverso queste catenecatene di KEY di KEY e SIG RR fino ad un punto nell’albero in cui ci si può fidare.

e SIG RR fino ad un punto nell’albero in cui ci si può fidare.

DNSSEC chain of trust (2) DNSSEC chain of trust (2)

host.foo.com. ?

Riceve l’RRs: 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 dell’albero DNS

com.

Local name server

foo.com.

name server name server

host.foo.com.

131.195.21.25 it.

unich.it.

DNSSEC TSIG/SIG(0) DNSSEC TSIG/SIG(0)

protezione tra server protezione tra server

master resolver

stub resolver

Zone administrator

slaves Zone file

Dynamic updates

Update non autorizzati

Impersonare il Master Corruzione Dati

PROTEZIONE SERVER PROTEZIONE SERVER

DNS Transaction Security DNS Transaction Security



ResolverResolver attualmente troppo semplici per la verifica delle attualmente troppo semplici per la verifica delle firme.

firme.



Sol. La Sol. La verifica delle firmeverifica delle firme è lasciata al è lasciata al NSNS e si introduce e si introduce una comunicazione sicura tra NS e resolver.

una comunicazione sicura tra NS e resolver.



NS e resolver condividono una chiave segreta.NS e resolver condividono una chiave segreta.



TKEY RRTKEY RR: utilizzato dal resolver per chiedere la chiave : utilizzato dal resolver per chiedere la chiave pubblica del NS con allegata la prorpia chiave pubblica pubblica del NS con allegata la prorpia chiave pubblica

che verrà utilizzata dal NS per criptare la chiave fisica.

che verrà utilizzata dal NS per criptare la chiave fisica.



D’ora in poi ogni comunicazione tra NS e resolver D’ora in poi ogni comunicazione tra NS e resolver avviene attraverso

avviene attraverso firmafirma..



Per queste speciali firme si utilizza il nuovo Per queste speciali firme si utilizza il nuovo TSIG RRTSIG RR..



Algoritmo di criptazione Algoritmo di criptazione HMAC-MD5 (RFC 1321, 2104).HMAC-MD5 (RFC 1321, 2104).

DNS come un PKI DNS come un PKI

 I I KEY RRKEY RR (contengono chiavi pubbliche) sono associati a zone, agli (contengono chiavi pubbliche) sono associati a zone, agli host, ad entità finali e agli utenti.

host, ad entità finali e agli utenti.

 Omnipresenza del DNS in internet Omnipresenza del DNS in internet → utilizzo per applicazioni o → utilizzo per applicazioni o protocolli come la

protocolli come la PKIPKI..

 Nel PKI esistente la chiavi pubbliche sono pubblicate e autenticate Nel PKI esistente la chiavi pubbliche sono pubblicate e autenticate per mezzo di certificati.

per mezzo di certificati.

 La “Chain of TrustLa “Chain of Trust” DNSSEC provvede ad una sorta di ” DNSSEC provvede ad una sorta di autenticazione dato che la verifica di KEY e

autenticazione dato che la verifica di KEY e SIG RRSIG RR è simile al è simile al processo di autenticazione di PKI.

processo di autenticazione di PKI.

 Nell’ RFC 2538 è definito un possibile nuovo Nell’ RFC 2538 è definito un possibile nuovo CERT RRCERT RR per per l’immagazzinamento dei certificati.

l’immagazzinamento dei certificati.

 CERT RRCERT RR può memorizzare certificati può memorizzare certificati PGPPGP, , X.509X.509, , SPKISPKI..

 La RFC 2538 raccomanda che è consigliabile minimizzare la La RFC 2538 raccomanda che è consigliabile minimizzare la

dimensione del certificato visto che le implementazioni attuali del dimensione del certificato visto che le implementazioni attuali del DNS sono ottimizzate per piccoli trasferimenti (<512 byte).

DNS sono ottimizzate per piccoli trasferimenti (<512 byte).

Ricapitolando sul DNSSEC Ricapitolando sul DNSSEC



Nel DNS la crittografia è utilizzata per Nel DNS la crittografia è utilizzata per

l’autenticazione/integrità e non per questioni di riservatezza.

l’autenticazione/integrità e non per questioni di riservatezza.



Bisogna dare attenzione alla generazione delle chiavi, alla Bisogna dare attenzione alla generazione delle chiavi, alla dimensione delle chiavi, alla memorizzazione delle chiavi e dimensione delle chiavi, alla memorizzazione delle chiavi e ai problemi sui tempi di validità.

ai problemi sui tempi di validità.



i resolver sicuri devono essere configurati con alcune chiavi i resolver sicuri devono essere configurati con alcune chiavi pubbliche sicure on-line altrimenti non potranno verificare la pubbliche sicure on-line altrimenti non potranno verificare la validità degli RR.

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 Aumentano: dimensione dei dati trasferiti, dimensione dei messaggi (possibili overflow per pacchetti DNS UDP

messaggi (possibili overflow per pacchetti DNS UDP → → utilizzo del TCP con un grande overhead)

utilizzo del TCP con un grande overhead), e il numero di , e il numero di cicli di CPU.

cicli di CPU.



La responsabilità degli amministratori incrementa!!!La responsabilità degli amministratori incrementa!!!

CONCLUSIONI 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 (Dati firmati con chiavi pubbliche (SIG, SIG, KEYKEY).).

 L’assenza di dati DNS è notificata (L’assenza di dati DNS è notificata (NXTNXT).).

 ProtezioneProtezione per i trasferimenti DNS locali:per i trasferimenti DNS locali:

 I messaggi tra NS e resolver sono autenticati (I messaggi tra NS e resolver sono autenticati (TSIGTSIG).).

 Trasferimenti di zona tra NS primari e secondari (Trasferimenti di zona tra NS primari e secondari (TSIGTSIG).).

 Infrastruttura a chiave pubblicaInfrastruttura a chiave pubblica PKIPKI::

 Distribuzione di chiavi pubbliche per altri protocolli di Distribuzione di chiavi pubbliche per altri protocolli di sicurezza (

sicurezza (KEYKEY).).

 Distribuzione di diversi tipi di certificati (Distribuzione di diversi tipi di certificati (CERTCERT).).