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
[email protected]
SOMMARIO
 Breve panoramica sul Domain Name System.
 Debolezze del DNS.
 Le soluzioni offerte dal DNSSEC.
 Conclusioni.
Domain Name System (1)
 Database gerachico, distribuito :
 Basato sul modello client-server
 nome  indirizzo-IP (traduzione)
 DNS può utilizzare protocollo TCP o UDP
 Principali componenti:
 domain space name descritto dai Resource Records
RR (ad es. SOA, A, MX, NS….)
 name servers
 resolvers
Processo di risoluzione dei nomi
Refreshes
System call
User
program
Recursive query
Name
resolver
Response
Primary
name
server
Cache
References
Resolver’s response
Local machine
Iterative query
Name
server
Iterative query
Response
Name
server
Referral
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, Eugene Kashpureff (fondatore
dell’Alternic) ha reindirizzato il dominio internic.net as
alternic.net mettendo in cache informazioni false su
Name Server di Internic.(Cache Poisoning)
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.
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.
DNS cache poisoning attack
broker.com
evil.com
2. anyhost.evil.com?
1. anyhost.evil.com?
ns.evil.com
5. anyhost.evil.com=A.B.C.E
3. Memorizza query
ID
ns.broker.com
cache
9.www.bank.com=
A.B.C.D
4. anyhost.evil.com=A.B.C.E
Host
Attaccante
A.B.C.D
6. www.bank.com?
8. www.bank.com=A.B.C.D
Inondare il Name Server con false risposte
10.www.bank.com?
any.broker.com
11.Risposta errata
dalla cache
12. Connessione errata all’host attaccante
bank.com
ns.bank.com
7. www.bank.com
Flusso dei dati DNS
Impersonare il Master
Corruzione Dati
Imitare la cache
Zone administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
Data spoofing
Update non autorizzati
PROTEZIONE SERVER
PROTEZIONE DATI
DNSSEC
coinvolgiamo 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
DNSSEC KEY/SIG/NEXT
autenticazione ed integrità dei dati
Imitare la cache
Zone administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
Data spoofing
PROTEZIONE DATI
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.
 Firma digitale crittografica 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.
DNS
FILE DI ZONA
Semplice file dati di zona nel quale sono
presenti gli RR SOA, NS, MX con i relativi IP.
•KEY
RR
specifica:
NB: La
struttura
del file diventa
•SIG
•NXT
RR
RR
specifica
specifica:
circolare. Se un resolver chiede un
•Il•Iltipo
diRR
chiave
(zone,
host,
nome
che
esiste
nel file
di
tiponon
nome
seguente
contenuto.
nella
user)
zona,
il server DNSSEC autoritativo
zona.
•L’algoritmo
di criptazione.
per•Il
quella
zona
ritornerà
una SOA
protocollo
(DNSSEC,
gli RR
RR che
coperti dal
RR e•Tutti
un NXT
•Inception
&
time.
IPSEC,
TLS…expiration
ecc.)
nome corrente.
autenticheranno
la non-presenza di
quel• •L’”impronta”
nome.
della chiave.
l’algoritmo
(RSA/MD5,
DSA)
DNSSEC
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 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.
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” a fidarsi delle chiavi
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.
DNSSEC chain of trust (2)
La chiave pubblica del dominio
radice è ritenuta fidata a priori
da tutti i name server!!
Root name server
dell’albero DNS
com.
name server
it.
host.foo.com. ?
unich.it.
Local name server
foo.com.
name server
Riceve l’RRs: A, SIG, KEY
host.foo.com.
131.195.21.25
DNSSEC TSIG/SIG(0)
protezione tra server
Impersonare il Master
Corruzione Dati
Zone administrator
Zone file
master
Dynamic
updates
slaves
Update non autorizzati
PROTEZIONE SERVER
resolver
stub resolver
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).
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).
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!!!
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).
 Protezione per 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 pubblica PKI:
 Distribuzione di chiavi pubbliche per altri protocolli di
sicurezza (KEY).
 Distribuzione di diversi tipi di certificati (CERT).