università degli studi “ g. d’annunzio ” chieti-pescara
DESCRIPTION
Università degli Studi “ G. d’Annunzio ” Chieti-Pescara Corso di Laurea Specialistica in Economia Informatica. DNSSEC. Seminario per il corso di “ Reti di calcolatori e sicurezza ” Prof. Stefano Bistarelli Realizzato da: fabrizio rossi. Percorso Il DNS I problemi relativi alla sicurezza - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/1.jpg)
Università degli Studi “Università degli Studi “G. d’AnnunzioG. d’Annunzio” Chieti-Pescara” Chieti-Pescara
Corso di Laurea Specialistica in Economia InformaticaCorso di Laurea Specialistica in Economia Informatica
Seminario per il corso di “Seminario per il corso di “Reti di calcolatori e sicurezzaReti di calcolatori e sicurezza””
Prof. Prof. Stefano BistarelliStefano Bistarelli
Realizzato da: Realizzato da: fabrizio rossifabrizio rossi
![Page 2: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/2.jpg)
Percorso
• Il DNS
•I problemi relativi alla sicurezza
•L’architettura DNSSEC
![Page 3: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/3.jpg)
![Page 4: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/4.jpg)
DNS
Il Domain Name System implementa uno spazio dei nomi gerarchici per le interreti TCP/IP utilizzato su Internet
E’ utilizzato da molte altre applicazioni e protocolli che interagiscono con la comunicazione in un interrete (Web browsing, Ftp, Telnet, utility TCP/IP su internet) basato su un database distribuito.
Il DNS provvede a:• specificare la sintassi dei nomi e le regole per delegare l ’autorità sulle zone• implementare il sistema di calcolo distribuito per convertire nomi in indirizzi e viceversa
![Page 5: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/5.jpg)
![Page 6: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/6.jpg)
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 • una richiesta per www.sci.unich.it viene risolta direttamente dal name server locale
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
![Page 7: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/7.jpg)
![Page 8: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/8.jpg)
PARAMETRI
IDENTIFICATION: consente di far corrispondere le risposte alle richieste
PARAMETER: contiene vari flag per specificare il tipo di operazione richiesta:• 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.
![Page 9: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/9.jpg)
![Page 10: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/10.jpg)
![Page 11: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/11.jpg)
Processo di risoluzione dei nomi
System call
Resolver’s response
RefreshesRecursive query
References
ResponseUser
program
Name resolver
Local machine
Primaryname server
Cache
Name server
Name server
Iterative query
Response
Iterative query
Referral
![Page 12: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/12.jpg)
Perché la Sicurezza del DNS è importante?
Il DNS è utilizzato radicalmente da applicazioni Internet; sorgono quindi i problemi di sicurezza DNS:
•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 (per esempio, ACLs) e altri meccanismi, rendono l’inganno, più difficile da compiere, ma non impossibile!
![Page 13: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/13.jpg)
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.
Di conseguenza:L’utente può ignorare ciò che è appena successo, ma l'attaccante malizioso che si è spacciato con il nome dell'host A, ha ora il controllo della login e della password dell'utente.
![Page 14: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/14.jpg)
• Il problema è che i Router attuali non hanno la capacità di respingere i pacchetti con falsi indirizzi sorgenti.
• L'attaccante può instradare pacchetti a chiunque e può indurre a farli considerare come pacchetti provenienti da un host fidato.
• 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 Local Name Server si.
• Attenendosi a queste assunzioni, osserviamo che parallelamente, c'è la possibilità di compiere 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 name server, allora può maliziosamente imporre che alcuni nomi nel dominio, non esistano.
![Page 15: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/15.jpg)
Perché DNSSEC ?
•DNS NON è sicuro
–Vulnerabilità pubblicamente conosciute –DNS è un servizio di grande importanza
•DNSSEC protegge dallo spoofing e dalla alterazione dei dati del traffico DNS
![Page 16: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/16.jpg)
![Page 17: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/17.jpg)
![Page 18: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/18.jpg)
DNS: Vulnerabilità Protocollo
• I dati Dns trasmessi tra il name-server master, il forwarder ed il resolver possono essere contraffatti (spoofing) e corrotti.
• Il protocollo Dns non consente di controllare la validità dei dati trasmessi dal protocollo stesso
– Bugs nell’implementazione del protocollo sul resolver(ID di transazione prevedibile)
– Cache-Pollution dei forwarders può causare danni per un certo periodo di tempo (TTL)
– Dati Dns corrotti possono finire nella cache e rimanervi a lungo
• Impossibilità per il name-server slave (secondary) di accertare se ha instaurato la comunicazione con il giusto master (primary) server
![Page 19: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/19.jpg)
DNSSEC: Soluzioni
• DNSSec protegge contro il data spoofing ed il data corruption
– TSIG/SIG0: fornisce un meccanismo per autenticare la comunicazione tra server DNS
– DNSKEY/RRSIG/NSEC: fornisce un meccanismo per stabilire l’autenticità e l’integrità dei dati Dns
– DS: fornisce un meccanismo per delegare una relazione di trust a chiavi pubbliche di terze parti
• Il DNS sicuro necessita di un’infrastruttura a chiave pubblica, tuttavia non stiamo parlando di una vera e propria PKI.
![Page 20: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/20.jpg)
DNSSEC: RFC
• RFC 3833– A threat analisys of the Domain Name System
• RFC 4033– DNS Security Introduction and Requirements
• RFC 4034– Resource Records for the DNS Security Extensions
• RFC 4035– Protocol Modifications for the DNS Security Extensions
• RFC 4398– Storing certificates in teh Domain Name System
![Page 21: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/21.jpg)
![Page 22: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/22.jpg)
![Page 23: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/23.jpg)
Autenticità ed Integrità dei Dati
• Autenticità: I dati sono pubblicati dall’entità che si ritiene ne abbia l’autorità???
• Integrità: I dati ricevuti sono i medesimi che sono stati pubblicati???
• La crittografia a chiave asimmetrica risponde alle seguenti esigenze:– Verificare l’integrità e l’autenticità dei dati attraverso le signatures
– Verificare l’autenticità delle signatures
• L’integrità e l’autenticità dei dati ottenuta firmando i RRs con la chiave privata
• La chiave pubblica DNSKEY usata per verificare i RRSIGs
• I nodi ‘figlio’ firmano le proprie zone con la propria chiave privata
– L’autenticità della chiave è stabilita dal parent attraverso la coppia signature/checksum
![Page 24: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/24.jpg)
Resource Records
•3 RRs correlati alla cifratura a chiave asimmetrica
– RRSIG -> signature su RRSet ottenuta usando la chiave privata– DNSKEY -> Chiave pubblica, necessaria per verificare un RRSIG – DS -> Delegation Signer: puntatore per la costruzione di catene di
autenticazione
•1 RR per la consistenza interna
– NSEC -> Indica quale nome sia il successivo nella zona
![Page 25: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/25.jpg)
RRs e RRSets
• Resource Record– Name TTL class type rdata– www.example.net. 7200 IN A 192.168.10.3
• RRSet: RRs con gli stessi name, class e type
– www.example.net. 7200 IN A 192.168.10.3
A 10.0.0.3A 172.25.215.2
• Gli RRSets sono firmati, ma non lo sono i singoli RRs che lo compongono
![Page 26: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/26.jpg)
![Page 27: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/27.jpg)
![Page 28: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/28.jpg)
![Page 29: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/29.jpg)
![Page 30: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/30.jpg)
![Page 31: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/31.jpg)
![Page 32: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/32.jpg)
NSEC RDATA
• Punta al nome del dominio successivo nella zona
– Elenca anche quali sono tutti i RRs esistenti per il nome di dominio in questione – Il record NSEC dell’ultimo nome si riaggancia al primo nome nella
zona (wrapping around)
• N*32 bits
• Esempio:– www.example.net. 3600 IN NSEC example.net.A RRSIG NSEC
![Page 33: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/33.jpg)
Sicurezza di una Zona
1. Generazione di una keypair– Includere la chiave pubblica (DNSKEY) nel file di zona
2. Firma della zona– Inserimento di:
• Records NSEC• Records RRSIG (signature su ogni RRSet)• Records DS (opzionali)
![Page 34: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/34.jpg)
DNSDNSDNSSECDNSSECFILE DI ZONA
![Page 35: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/35.jpg)
![Page 36: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/36.jpg)
DNSSEC chain of trust
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.
![Page 37: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/37.jpg)
![Page 38: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/38.jpg)
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.DInondare 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
cachens.broker.com
bank.com
ns.bank.com
![Page 39: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/39.jpg)
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.
![Page 40: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/40.jpg)
Osservazioni su DNSSEC
• Nel DNS, la crittografia è usata per l’autenticazione e l’integrità dei dati, non per la confidenzialità
• L’attenzione deve essere spostata alla generazione delle chiavi, memorizzazione delle chiavi, e al life time (RFC 2541)
• La dimensione dei file di zona cresce drammaticamente
• Aumento dei dati trasferiti, dei messaggi (quindi tcp e non udp) e del numero di computazioni (cicli cpu)
• La responsabilità degli amministratori aumenta!
![Page 41: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/41.jpg)
SOLUZIONI A BREVE TERMINE
1. Massimizzare il livello di casualità• Molte implementazioni usano già numeri di transazione casuali• La porta 53 è assegnata da IANA (Internet Assigned Numbers Authority) al DNS.• Comunque è solo richiesto che la porta 53 sia quella di destinazione, non la porta
sorgente• Le varie patches rilasciate negli ultimi mesi lavorano in tal senso (randomizzare la
porta sorgente) per i server che adottano una tecnica ricorsiva.
2. Disabilitare i name server ricorsivi aperti• L’attacco non ha effetto se l’attaccante non può inviare pacchetti di richieste al
name server• Se si vuole far girare un name server ricorsivo, limitare l’accesso a soli quei
computer che ne hanno effettivamente bisogno
3. Usare lettere maiuscole/minuscole per aumentare la casualità• E’ ancora in discussione (non ancora implementato).
![Page 42: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/42.jpg)
![Page 43: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/43.jpg)
Conclusioni
• Le Estensioni per la sicurezza provvedono:
• Protezione dei trasferimenti su Internet
• I dati sono firmati con chiavi pubbliche (RRSIG, KEY) • 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
• Infrastruttura a chiave pubblica
• Distribuzione di chiavi pubbliche per altri protocolli di sicurezza (KEY)
![Page 44: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/44.jpg)
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.
Brian Wellington, "An Introduction to Domain Name System Security", TIS Labs, January 1999.
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
RFC 1034 "Domain Name System - Concepts and Facilities", Paul Mockapetris, ISI, November 1987.
RFC 1035 "Domain Name System - Implementation and Specification", Paul Mockapetris, ISI, November 1987.
![Page 45: Università degli Studi “ G. d’Annunzio ” Chieti-Pescara](https://reader036.vdocuments.pub/reader036/viewer/2022062800/5681409e550346895dac4a7e/html5/thumbnails/45.jpg)
RFC 2065 "Domain Name System Security Extensions", Donald Eastlake, IBM, C. Kaufman, January 1997.
RFC 2535 "Domain Name System Security Extensions", Donald Eastlake, IBM, March 1999.
RFC 2536 "DSA KEYs and SIGs in the Domain Name System (DNS)", Donald Eastlake, IBM, March 1999.
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.
RFC 2539 "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", Donald Eastlake, IBM, March 1999.
RFC 2541 "DNS Security Operational Considerations", Donald Eastlake, IBM, March 1999.