DNS Security Percorso Introduzione al DNS Ordinamento

Percorso
DNS Security
♦ Il DNS
♦ I problemi relativi alla sicurezza
Università degli studi di Salerno
Anno Accademico 2001/2002
Sistemi di Elaborazione:
Sicurezza su Reti
♦ Il Domain Name System (DNS)
– Cos’è il DNS
– Il funzionamento
– Vulnerabilità del DNS
• DNS Spoofing
• Cache poisoning
– Estensioni DNSSEC
♦ L’architettura DNSSEC
Introduzione al DNS
♦ Domain Name System – Un database
gerarchico distribuito, che associa nomi
degli host a indirizzi IP
– Permette ad un utente di trovare un sistema
senza conoscere il suo indirizzo IP
(convenienza)
silicon.cs.umn.edu
128.101.35.181
– Organizza l’interrete in domini
Ordinamento gerarchico
♦ I domini sono organizzati logicamente
Struttura Gerarchica del DNS
come un albero invertito
– capri.dia.unisa.it – specifica completa della
macchina di nome capri
– dia.unisa.it – il dominio dia
– unisa.it – il dominiodell’ Università di Salerno
– it - sottodominiodel dominioroot
♦ Suddivisione in zone, responsabilità
delegate
♦ L’Internet Corporation for Assigned
Names and Numbers (ICANN)
sovraintende agli assegnamenti dei nomi
di dominio
Autorità centrale responsabile
per la delegazione dei top-level
com
edu
org
it
Autorità italiana
per i nomi sotto il
dominio it
mit
Autorità locale responsabile
per i nomi sotto il dominio
unisa.it
Autorità locale responsabile
per i nomi sotto il dominio
dia.unisa.it
unisa
dia
libero
dmi
1
Ogni zona ha un Name Server
(NS)
Resource Record
♦ Mantiene un database delle informazioni sugli
♦ Mantiene tutti i dati DNS
host per la sua zona
♦ Contatta l’ NS autoritativo della zona per
prendere informazioni sull’ host (come l’ IP)
♦ Le informazioni devono essere aggiornate
quando quelle dell’ host cambiano nella zona
♦ Aggiornamenti dinamici cambiano i dati del
DNS senza la necessità di ricostruire ogni altra
parte dell’ albero DNS
Il Problema : “Dirottamento” di un
dominio
♦ Gli indirizzi IP nel database del DNS vengono
cambiati da host non autorizzati
♦ Diversi modi per fare ciò
1. DNS Spoofing – “Ingannare” il server DNS con
informazioni ritenute sicure, ma che in realtà non
lo sono
2. Cache Poisoning – Falsarel’ IP con un alto TTL,
cosicchè il server DNS lo conserveràin cache per
molto tempo
3. Errore umano – L’ Amministratoreinserisce le
informazioni DNS in modo scorretto
♦ DNSSEC può aiutare a contrastare i primi due
♦ Alcuni esempi
– NS – Definisce il Name Server della zona
– A – Mappa un hostname in un indirizzo IP
♦ Gli RR possono essere messi in cache per
motivi di performance
– Il campo TTL di un RR specifica quanto
tempo deve essere memorizzato
DNS Security
♦ DNSSEC Extensions
– Obiettivi
• Protezione trasferimenti DNS
– Servizi
• Key Distribution
• Data Origin Authentication
• Transaction and Request Authentication
attacchi
DNS Security
Cosa DNSSEC non garantisce
♦ DNSSEC Extensions
♦ I dati DNS sono pubblici
– Nessuna differenziazione di risposte in base
a differenti provenienze delle richieste
– Non garantisce confidenzialità
– Chain of trust
– Utilizzo di crittografia a chiave pubblica
♦ Nessuna protezione contro un attacco di
tipo Denial of Service
2
DNSSEC autentica le richieste e
le risposte DNS
♦ Usa la crittografia a chiave pubblica per
implementare le firme digitali
♦ Racchiude i dati relativi alla sicurezza del
DNS in nuovi record di risorse nei server
e negli host
DNS Security
Nella seconda parte vengono descritte e classificate
le debolezze del DNS: sono descritti alcuni attacchi
basati sul Dns.
DNS Security
Verranno ora considerate tre
parti, in maniera più
approfondita
Nella prima parte si citano i concetti generali
introduttivi del DNS. La paronamica rapida intende
familiarizzare il lettore con le nozioni basilari usate
in seguito.
DNS Security
Nella terza parte si procede con le soluzioni che si
riferiscono alla cosidetta architettura DNSSEC, e
all’insieme di documenti che includono le
Request For Comment.
•Ind
•Sp irizzi IP
azio
dei
nom
i
3
Differenza fra indirizzi IP e Nomi
mnemonici
Indirizzo IP:
Esempio
Rappresentazione binaria
:
:
stringa di 32 bit
192 .
41
.
218
.
1
11000000 00101001 11011010 0000001
Facile da manipolare per un computer
• Difficile da ricordare per una persona
Nome mnemonico: stringa di caratteri
Esempio: vogclub.com
(Sito per giocare a dama e scacchi on line)
• Facile da ricordare per una persona
• Difficile da manipolare per un computer
•
Gestione dello Spazio dei Nomi
Si deve garantire che ogni nome mnemonico
identifichi univocamente un host:
• Si fissa una politica di gestione dello spazio dei nomi
• Un’autorità garantisce l’applicazione della politica
Due possibili soluzioni:
• Spazio dei nomi piatto (flat)
• Spazio dei nomi gerarchico
E’ possibile associare nomi a indirizzi IP
• l’associazione deve essere 1 - a - 1 per evitare ambiguità
• serve un’applicazione che effettui le conversioni
Spazio dei Nomi Piatto
Una lista di nomi senza una particolare struttura
• Una funzione associa ogni nome univocamente ad
un indirizzo IP
soluzione
semplice
ma con problemi
router
164.1.1.1
pippo
18.12.222.3
macchina2 192.41.218.2
macchina1 192.41.218.1
Gestione centralizzata
• La tabella di conversione deve essere nota a tutti i
computer della rete
• Difficile da gestire e da consultare quando la rete è
grande
•
Idea della Struttura Gerarchica
Struttura di un’azienda
• Direttore generale
• Vari reparti, ognuno con un capo reparto
Il direttore generale ha piena responsabilità ma
garantisce ad ogni reparto autonomia
• nomina un capo per ogni reparto
• il capo reparto ha la responsabilità del suo reparto e può
prendere decisioni autonome
• le relazioni tra i reparti sono gestite dal direttore
generale
Spazio dei Nomi Gerarchico
Lo spazio dei nomi viene diviso in zone dette domini
• per ogni dominio viene definita un’autorità di dominio
Consente la decentralizzazione della gestione della tabella
• l’autorità centrale si occupa solo di coordinare le autorità
di zona
• ogni autorità di dominio è delegata a gestire
l’assegnazione dei nomi della sua zona ed effettuare le
corrispondenze tra indirizzi e nomi
• ogni dominio può essere diviso in sottodomini affidati ad
autorità di sottodominio
Le autorità di dominio sono autonome
• lo stesso nome può essere usato in domini diversi
Struttura dei Nomi Gerarchici
Un nome gerarchico è formato da vari campi,
detti etichette
• le etichette sono separate da punti
Ogni etichetta è assegnata da un’autorità ed
identifica una zona
• l’autorità garantisce che nella sua zona quel nome è
unico
Es. dia.unisa.it
• it è unico a livello globale
• unisa è unico nel dominio it
• dia è unico nel dominio unisa.it generale
1° Livello
2° Livello
3° Livello
4
DNS
•DN
S
•Dom
ini
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
Ad esempio DeSantis@dia si riferisce a dia.unisa.it
Regole Sintattiche
Esempio
Il nome coppi.dia.unisa.it. identifica l’indirizzo 192.168.203.1
Il “.” rappresenta il livello più alto gestito dall’ICANN
L’intero spazio dei nomi è rappresentato come
una zona senza nome
Le etichette dei vari livelli gerarchici sono
separate con un “.”
• Non c’è differenza fra maiuscole e minuscole
I livelli gerarchici sono ordinati da destra a
sinistra
• il primo livello in genere è omesso
(Es. DIA.UNISA.IT._)
“it” rappresenta tutti i domini italiani
L’autorità centrale delega dei responsabili per la gestione dei
nomi sotto il dominio “it”
“unisa” rappresenta i nomi per l’università di Salerno
L’autorità di it delega dei responsabili per la gestione dei nomi
sotto il dominio unisa.it
“dia” rappresenta i nomi per il dipartimento di
Informatica ed Applicazioni
L’autorità di unisa.it delega dei responsabili per la gestione dei
nomi sotto il dominio dia.unisa.it
“coppi” è il nome di un host fissato dall’autorità di dia.unisa.it
Domini Top Level
L’autorità centrale ha individuato un insieme di domini di
primo livello
• individuati su base geografica o in base alla funzione
COM Organizzazioni commerciali
EDU Istituzioni didattiche
GOV Istituzioni statali (americane)
MIL Gruppi militari (americani)
NET Centri di supporto di Internet
ORG Altre organizzazioni
INT Organizzazioni internazionali
IT, US, UK, DE, RU Codici di nazione (due lettere)
Nuovi Domini Top Level
Recentemente sono stati introdotti nuovi domini
di primo livello
• necessari per soddisfare esigenze commerciali e
risolvere problemi di esaurimento dei nomi
Nuovi domini
BIZ
attività commerciali
INFO siti informativi
COOP siti di cooperative
AERO attività aerospaziali
MUSEUM musei
NAME siti personali
EU
codice dell’Unione Europea
5
Struttura dei Top Level Domain
Ogni dominio di primo livello è gestito secondo regole
proprie
• cambiano le regole ed i costi di registrazione
•Na
me
Serv
er
Alcuni domini geografici sono ripartiti secondo
uno schema simile a quello di primo livello
• ac.uk università inglesi
• ac.il università israeliane
• co.uk organizzazioni commerciali inglesi
Name Server
La risoluzione dei nomi è affidata ad un
sistema distribuito
• I membri del sistema sono detti Name Server
• ogni applicazione deve contattare un Name Server
per risolvere un nome
Ogni autorità deve avere almeno un name server
• gestisce la risoluzione dei nomi per quel dominio
• un’autorità è totalmente responsabile del
funzionamento dei suoi name server
I ROOT NAME SERVER
Struttura gerarchica dei Name Server
I name server possono essere classificati
secondo l’albero dei domini
• due name server collegati nell’albero si conoscono e
si scambiano informazioni
I name server collegati possono comunicare in
vari modi
• possono risiedere sullo stesso host o essere
collegati tramite un’interrete
• le relazioni nell’albero sono logiche e non fisiche
I name server associati alla radice dell’albero
sono detti root name server
• per ogni nome conoscono un name server in grado
di convertire quel nome
I Root Name Server
• L' elenco dei 13 root name servers attaccati l’11 Settembre dall’
organizzazione di Bin Laden può essere ottenuto utilizzando il
comando dig che è un evoluto comando di interrogazione DNS.
•
•
•
•
•
•
•
•
•
•
•
•
•
i.root-servers.net. 5d22h39m28s IN A 192.36.148.17
e.root-servers.net. 5d22h39m28s IN A 192.203.230.10
d.root-servers.net. 5d22h39m28s IN A 128.8.10.90
a.root-servers.net. 5d22h39m28s IN A 198.41.0.4
h.root-servers.net. 5d22h39m28s IN A 128.63.2.53
c.root-servers.net. 5d22h39m28s IN A 192.33.4.12
g.root-servers.net. 5d22h39m28s IN A 192.112.36.4
f.root-servers.net. 5d22h39m28s IN A 192.5.5.241
b.root-servers.net. 5d22h39m28s IN A 128.9.0.107
j.root-servers.net. 5d22h39m28s IN A 192.58.128.30
k.root-servers.net. 5d22h39m28s IN A 193.0.14.129
l.root-servers.net. 5d22h39m28s IN A 198.32.64.12
m.root-servers.net. 5d22h39m28s IN A 202.12.27.33
• Il tempo indicato è la validità della corrispondenza Nome <-> Ind. IP
6
Name Server per .it e .unisa.it
Zone di Autorità
Il sottoalbero di domini gestito da un name
server costituisce la sua zona di autorità
Per ottenere una zona di autorità
un’organizzazione deve soddisfare alcuni vincoli
fissati dall’autorità centrale
• supportare tutti i protocolli standard per le
interrogazioni e le risposte dal DNS
• conoscere almeno un root name server
• conoscere un name server per ciascuno dei suoi
sottodomini
• avere almeno due name server attivi che non hanno
punti di guasto comuni
• un name server primario ed uno di backup
it. 1D IN NS nameserver.cnr.it.
it. 1D IN NS server2.infn.it.
it. 1D IN NS ns2.psi.net.
it. 1D IN NS dns2.iunet.it.
it. 1D IN NS dns2.it.net.
it. 1D IN NS ns.ripe.net.
it. 1D IN NS dns.nic.it.
it. 1D IN NS ns.eu.net.
unisa.it. 2D IN NS capri.dia.unisa.it.
unisa.it. 2D IN NS server2.garr.net.
unisa.it. 2D IN NS ns.unisa.it.
;; ADDITIONAL SECTION:
capri.dia.unisa.it. 2D IN A 192.41.218.10
server2.garr.net. 1h30m26s IN A 131.154.1.11
ns.unisa.it. 2D IN A 193.205.160.3
Tipi di Nomi
•Tip
i
•Ris di nom
oluz
i
ione
di
Il DNS consente di incorporare nello stesso
sistema diverse gerarchie di nomi
nom
i
Ad ogni elemento denominato, memorizzato nel
sistema è associato un tipo
• Host
• Casella postale
• Un utente
Quando si interroga il DNS si deve specificare
che tipo di informazione si sta cercando e la
famiglia di protocolli da utilizzare
• Per default si assume che si stanno cercando i nomi
degli host e che si usano i protocolli TCP/IP
Risoluzione di un Nome
Individuazione del Name Server
La comunicazione con il name server è gestita
dal resolver
• Il Resolve r fa parte dell’applicazione ed è invocato
prima di contattare il livello di trasporto
• TCP e UDP non hanno nessuna relazione con i nomi
di domini
Es. un utente su A lancia
Server FTP
il comando ftp B
Name Server
• A richiede al name server
su S l’indirizzo di B
• S risponde con l’indirizzo
• A invia un messaggio FTP
all’indirizzo di B
S
B
A
Client FTP
Non esiste per gli host un metodo standard per
individuare un name server sulla rete locale
• in genere il nome del name server è memorizzato in
un file di configurazione oppure prelevato da un
server DHCP
• il name server si trova sulla porta 53 (sia UDP che TCP)
In ambiente Linux gli indirizzi dei name server
sono memorizzati in /etc/resolv.conf
• specifica fino a 3 name server in ordine di preferenza
• specifica una lista di suffissi per il completamento degli
indirizzi (consente ad esempio di scrivere
Desantis@nomehost, che verrà completato con
dia.unisa.it)
• Es. nameserver 192.168.203.2 domain dia.unisa.it
7
Modalità di Risoluzione
Completamento degli Indirizzi
Il name server accetta solo richieste per nomi
completamente qualificati
• specificano le etichette di tutti i livelli a partire dal
root level
Il resolver permette all’utente di specificare
nomi parziali
• prova ad estenderli per ottenere nomi
completamente qualificati
• aggiunge al nome i suffissi specificati nel file di
configurazione
• Es. ftp coppi ftp coppi.dia.unisa.it.
Il name server può utilizzare due diverse
modalità per rispondere ad una interrogazione
• modalità ricorsiva: se non conosce la risposta
interroga altri name server e poi passa la risposta al
client
• usata dai name server locali
• modalità iterativa: se non conosce la risposta passa
al client l’indirizzo di un altro name server
• usata dai name server di livello superiore
Il client sceglie la modalità di risposta
• setta un flag nel messaggio di richiesta
Funzionamento del DNS
•Dns
•Cac :Funzio
na
he
mes ,Forma mento
sagg
t
gi D o dei
ns
L’applicazione interroga il name server locale
• se il nome appartiene alla sua zona di autorità il
name server locale risponde direttamente
Altrimenti:
Il name server locale interroga un root name
server
• ottiene in risposta il nome di un name server che ha
l’autorità sul dominio di primo livello del nome richiesto
Il name server locale interroga il name server di
primo livello
• ottiene in risposta il nome di un name server di
secondo livello
Si procede ricorsivamente fino alla risoluzione del nome
Esempio di Risoluzione
Name Server per “.”
Name Server per “it”
Name
Server
locale
Cache
“.”
fr
it
unisa
libero
Name S. per “unisa.it”
Name S. per “dia.unisa.it ”
dia
Resolver
www.dia.unisa.it
dmi
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, unisa.it e dia.unisa.it
• una richiesta per www.dmi.unisa.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
8
Parametri
Formato dei Messaggi
0
16
32
Identification
Number of questions
Parameter
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
Number of answers
Number of Authorities Number of Additional
Question Section
Answer Section
Authority Section
Additional Information Section
Ogni messaggio consente di specificare più richieste
e risposte
Formato della Question Section
0
16
32
Query Domain Name
Query Type
IDENTIFICATION: consente di far corrispondere le
risposte alle richieste
Query Class
QUERY DOMAIN NAME: contiene il nome da
risolvere, rappresentato come sequenza di caratteri di
lunghezza variabile
• Es. dia.unisa.it à 3 d i a 5 u n i s a 2 i t 0
QUERY TYPE: specifica il tipo di informazione richiesta
QUERY CLASS: specifica la classe di indirizzi
Gli altri campi specificano quanti record sono contenuti
nelle quattro sezioni del messaggio
Formato della Answer Section
0
16
32
Resource Domain Name
Type
Class
Time to live
Resource Data Length
Resource Data
I primi tre campi sono uguali alla Question Section
TIME TO LIVE: tempo di validità della risposta
RESOURCE DATA: contiene la risposta del name server
• formata da vari record di risorse (RR)
Stesso formato per le altre due sezioni
Tipi degli Oggetti
•Tip
i
•Int degli og
er
g
inve rogazio etti
ni
rse
Il DNS può essere utilizzato per implementare
un qualsiasi spazio gerarchico dei nomi
Può implementare corrispondenze arbitrarie
• es. corrispondenze tra nomi e indirizzi IP e tra nomi
e caselle di posta
Il tipo di un oggetto definisce il tipo di
corrispondenza a cui si riferisce
• esistono circa 20 tipi di oggetti e ne vengono
introdotti continuamente di nuovi
9
Esempio di Utilizzo dei Tipi
Principali Tipi
A
Indirizzo di un host
PTR
Puntatore
CNAME
Nome canonico
MX
Mail exchanger
• Richiesta di tipo A per rossi.diareti.diaedu.unisa.it
à 193.205.161.171 (indirizzo IP associato al nome)
Indirizzo IP
Nome di un dominio
HINFO
CPU e SO
MINFO
Mailbox info
Nome principale di un dominio
Nome dell’host che agisce come
mail exchanger per il dominio
Nome della CPU e del SO
NS
Name Server
SOA
Start of authority
• Richiesta di tipo PTR per 192.168.203.2
à gimondi.dia.unisa.it (nome associato all’indirizzo)
• Richiesta di tipo MX per <nome host>.dia.unisa.it
à udsab.dia.unisa.it (mail exchanger per dia.unisa.it)
Informazioni su una mailbox
Nome del name server che ha
l’autorità sul dominio
Specifica la zona dell’autorità
• Richiesta di tipo NS per <nome host>.dia.unisa.it
à capri.dia.unisa.it (name server che ha l’autorità su
dia.unisa.it)
• Richiesta di tipo SOA per capri.dia.unisa.it
à dia.unisa.it (zona di autorità di capri.dia.unisa.it)
Formato Compresso dei Nomi
Interrogazioni Inverse
I messaggi di risposta del name server
contengono anche la query originaria
• i messaggi non possono essere più lunghi di 512
byte
• la risposta è troncata e il flag corrispondente è
settato
Utilizzata per recuperare il nome associato ad
un indirizzo IP
• utilizzata da alcuni server per verificare la
correttezza delle informazioni ottenute dal client
Per risparmiare spazio i nomi sono compressi
• la prima occorrenza è scritta normalmente
• le occorrenze successive sono sostituite da un
puntatore alla prima occorrenza
• l’indirizzo del puntatore è scritto nel byte precedente
il nome
• al posto della dimensione dell’etichetta (6 bit
meno significativi)
• il puntatore ha i primi due bit a 1
Implementata come la ricerca di un nome
• tutti gli indirizzi IP sono rappresentati come nomi
nel dominio in-addr.arpa
• Es. 192.168.203.2 2.203.168.192.in-addr.arpa
Riassumendo...
Riassumendo...
I root name server mantengono un database di
tutti gli indirizzi IP validi e dei name server che li
possono risolvere
Il DNS
Il Processo di risoluzione dei nomi
•
Query Ricorsiva Aggiornamento
System call
Programma
Utente
Name
resolver
Name
Server
Risposta Primario
Nome
Cache
IP
• Può utilizzare protocolli TCP oppure UDP
Riferimenti
Risposta del Resolver
• Componenti principali DNS:
Macchina Locale
Query Iterativa
Name
Server
E’ un sistema distribuito, gerarchico che provvede
principalmente all’ associazione
Query Iterativa
Risposta
Name
Server
Risposta
Lo Spazio del Nome di Dominio descritto dal tipo ovvero
dai Resource Record (RR) (per esempio, SOA, NS, A, MX)
• I
Name Server
•
•
I
Resolver
10
Perché la Sicurezza del DNS è importante?
Il DNS è utilizzato radicalmente da applicazioni Internet e
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!
• Nel Giugno del 1997, Eugene Kashpureff (fondatore
dell’Alternic) ha reindirizzato il dominio internic.net
ad alternic.net, mettendo in cache informazioni false,
sul Name Server di Internic
Destinazione errata indotta: Credere
in false informazioni
•DN
S SP
OOF
ING
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.
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.
• Ora la connessione salta, e l'utente ritenta l'intera
procedura questa volta al corretto indirizzo IP dell'host A.
11
•
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.
•Aut
en
Auto ticazio
n
r
basa izzazio i e
n
te s
ui n i
omi
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.
Autenticazioni e Autorizzazioni
basate sui nomi
• Alcune applicazioni, sfortunatamente diffuse su
Internet, fanno uso di un meccanismo estremamente
insicuro:
L' Autenticazione e Autorizzazione basate sui nomi
• E' il caso, ad esempio, dell' "rlogin" di unix, o "rsh",
"rcp" che usano il concetto di equivalenza remota per
permettere l'accesso remoto ad un computer.
•
In queste reti, l'amministratore di sistema, o peggio
ancora, gli utenti, possono dichiarare(rendere nota)
l'equivalenza remota di 2 account su 2 differenti
macchine (ad esempio per mezzo dei file
/etc/hosts.equiv oppure .rhosts)
• Questa equivalenza associa due utenti di 2 differenti
host semplicemente sulla base dei loro nomi.
12
Ad esempio :
otherhost.mydomain.com
•
host.mydomain.com
L'accesso al computer remoto è allora garantito se
l'utente remoto è dichiarato equivalente all'utente
locale e se la richiesta dell'hostname coincide con
quella contenuta nella definizione equivalente.
• Nessun altro tipo di identificazione è usata, e perciò
parliamo di autenticazione (debole)basata su nomi.
si collega come…
Joe
Doe
L'utente “joe” può loggarsi come l'utente
“doe” al computer “host.mydomain.com”,
se il file /etc/hosts.equiv contiene l'equivalenza tra
l'utente locale “doe” e l'utente
“[email protected]”
semplicemente sulla base dei loro nomi.
•
•
I comandi Remoti sono stati progettati quando nacque
Internet, per l'uso di reti locali fidate, dove tutti gli utenti
erano conosciuti dall'amministratore di sistema, e la rete
non era connessa al grande Internet. Sfortunatamente, i
comandi remoti sopravvissero alla crescita di Internet e
essi sono ancora presenti e usati in molte reti.
L'attaccante può monitorare il traffico di rete venendo a
conoscenza dell'equivalenza usata in quella rete, e operare
con l'indirizzo IP di un host equivalente (ad esempio
compiendo un attacco DoS, o semplicemente aspettando lo
shutdown della macchina).
•
Se viene usata l'autenticazione basata sul nome, è
possibile accedere ad una macchina remota
semplicemente truffando il nome di un host.
• Anche se la rete locale è protetta da un firewall, 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.
•At
tac
info co alle
r
sup mazion
plem
i
enta
ri
• A questo punto l'host dell'attaccante è completamente
equivalente all'host attaccato per tutti i computer che
usano l'equivalenza remota.
13
Attacco alle informazioni
supplementari
•
Questo è un altro lato della debolezza del DNS.
Per motivi di efficienza il DNS fu progettato in modo da
avere una sezione addizionale nel suo formato standard
dei messaggi.
• Di conseguenza in alcuni casi quando un’ informazione
supplementare è considerata urgente da spedire, per
velocizzare la risposta per una data query, essa è inclusa
nella sezione addizionale.
•
Per esempio, se interroghiamo il nostro Name Server cioè
ns.mydomain.com, per recuperare la RR mail exchange
per il dominio comp-craiova.ro, il Server risponde con un
RR mail.gate.comp-craiova.ro nella sezione answer del
messaggio del DNS e nella sezione additional viene
incluso il nome e l'IP del name Server autoritativo per il
dominio comp-craiova.ro.
• Questa informazione non era stata esplicitamente chiesta
da noi, piuttosto era stata messa in cache, per evitare una
lunga ricerca per il name server autoritativo per quel
dominio.
CACHE POISONING
•CA
CHE
POI
SON
ING
•
Consideriamo ora l’attacco che evidenzia sempre più
la necessità di un meccanismo di autenticazione più
forte.
Esso viene chiamato :
“Cache poisoning" (Avvelenamento della cache).
DNS cache poisoning attack
Scenario
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
4.anyhost.evil.com=A.B.C.E
Host
Attaccante
A.B.C.D
6. www.bank.com?
ns.broker.com
cache
9. www.bank.com =
A.B.C.D
10.www.bank.com?
any.broker.com
8. www.bank.com=A.B.C.D
11.Risposta
Inondare con false risposte il N.Server
errata della cache
12.Connessione errata all’host attaccante!
bank.com
7. www.bank.com
ns.bank.com
14
Introduzione
Verifica Autenticità e Integrità dei
dati
♦ Ogni insieme di RR mandato come risposta a una DNS
•
Con l'RFC 2065 e dopo con la sua successiva 2535,
l'estensione per la sicurezza del DNS fu ammessa e
standardizzata in modo organizzato con il gruppo di
lavoro DNSSEC IETF .
query sarà accompagnato da una firma digitale generata
insieme alla chiave privata del mandante
♦ Il ricevente può verificarel’autenticità e l’integrità dei
messaggi verificando la firma
1. Richiesta DNS
• Il primo passo è provvedere all'autenticazione dei
dati per gli RR che vanno avanti e indietro in
Internet.
• Con l'autenticazione si ottenne anche integrità dei
dati e l'autenticazione dei dati sorgenti.
Host A
3. L’ Host A verifica la firma
NS for
Host B
♦ DNSSEC specifica un nuovo RR chiamato KEY, la
chiave pubblica di un sistema
– Occorre avere una chiave pubblica autentica
– Il SIG RR è la firma digitale di una risposta/richiesta
• L'autenticazione è ottenuta per via della firma digitale
crittografica.
Definizioni DNSSEC
Le caratteristiche del DNSSEC
– DNS le estensioni per la sicurezza (RFC 2535 - 2537):
•
•
•
2. Risposta DNS || Firma(Risposta DNS)
SIG - memorizza le firme digitali(asymmetric keys)
KEY - memorizza le chiavi pubbliche
NXT - autentica la non-esistenza di nomi o
tipi di RR in un dominio
I KEY RR specificano :
• Il tipo di chiave (zona, host, utente)
• Il protocollo (DNSSEC, IPSEC, TLS, ecc.)
• L’algoritmo (RSA/MD5, DSA, ecc.)
– DNSSEC agisce su insiemi di RR e non su singoli RR
I SIG RR specificano :
• Il tipo nascosto degli RR (SOA, A, NS, MX, ecc.)
• L’algoritmo (RSA/MD5, DSA, ecc.)
• I tempi di inizio e scadenza (della validità )
• La firma
– DNSSEC intende provvedere a:
Autenticare l’origine dei dati e all’integrità di essi
• Fornire la distribuzione delle chiavi
• Autenticare le transizioni e le richieste
Le caratteristiche del DNSSEC
Le caratteristiche del DNSSEC
I NXT RR specificano :
• Il prossimo nome nella zona
• Tutti I tipi di RR coperti dal nome corrente
• La chiave privata non è visibile in linea ed è usata per
firmare gli insiemi di RR del file di zona .
•
Per una zona firmata, c'è una KEY RR e ogni RR nella
zona è firmata con la corrispondente chiave privata
della zona.
• La chiave pubblica è pubblicata nel KEY RR
• Per capire meglio questa affermazione, mostreremo
nelle due figure le differenze di un file di zona fra
DNS standard e DNS sicuro.
• La chiave pubblica della zona è firmata usando la
chiave privata del padre di zona
• Per il DNS standard, abbiamo gli RR nel semplice file
dati di zona (figura 1)...
• La firma del padre di zona sulla chiave pubblica della
zona è aggiunta al file di zona.
15
File di Zona
File di Zona
Abbiamo anche l'IP di un host in mydomain.com,
per il name server e l'IP del mail exchange box
dato dall’ RR di tipo A.
Un semplice file dati di zona nel quale sono
presenti gli RR che specificano l'inizio dei
parametri (SOA), il Name Server(NS), la mail
exchange(MX) per il dominio mydomain.com
(linee 1-9).
Figura 1:Un file di zona nel classico DNS
File di Zona
•
File di Zona
Quando DNSSEC è usato, il file di zona è modificato
come presentato in figura 2 (per ogni RR
di figura 1 abbiamo un SIG RR in figura 2) ...
Figura 2 : Lo stesso file di zona nel DNSSEC
Ogni RR nel vecchio file di zona è firmato
mediante la chiave privata della zona. L’RR SIG lega
crittograficamente un insieme di RR al firmatario e
ad un intervallo di validità.
Nel nostro esempio, l'intervallo di validità
della firma è segnato dai valori
19991023133034
(il tempo di scadenza 13:30:34 del 23
Ottobre 1999) e 19990923133046 (il
tempo in cui venne firmata la zona
13:30:46 del 23 Settembre 1999).
Questo nuovo SIG AXFR permette di assicurare efficientemente
l'integrità e la sicurezza dei trasferimenti della zona.
La firma AXFR deve essere calcolata dopo che tutti gli RR nel file
di zona sono firmati e inseriti.
Infatti esso appartiene a tutta la zona non solo
al nome della zona.
The zone signer
•
Le firme degli RR e dei file di dati di zona, sono
generati da uno speciale programma: The zone signer
(il firmatario di zona).
• Il compito di fare la firma è demandato all'amministratore
di zona.
• Il programma legge tutti i dati nel file di zona, li
organizza in un ordine canonico, sistema i relativi record
in gruppi, li firma e aggiunge gli RR SIG e NXT nei loro
posti appropriati.
• Infine questa informazione è scritta in un file che sarà
usato dopo dal Name Server primario di zona.
16
DNSSEC chain of trust
La chiave pubblica del dominio radice
è ritenuta fidata a priori da tutti i
name server
it.
KEY
.
DNS Transaction security
Root name server
dell’albero DNS
m. ?
per co
m.
of co
RRs
Y, SIG
E
K
ve
Rice
host.foo.com. ?
com.
name server
polito.it.
Local name server
foo.com.
name server
Riceve gli RRs: A, SIG, KEY
host.foo.com
.
131.195.21.25
•
Transaction Signature (TSIG) è un’ altra estensione che
usa le chiavi segrete condivise
• Una soluzione miglioreper avere sicurezza nella
comunicazione fra name server e resolver
• TSIG autentica le query DNS e le risposte
• TKEY è un meta RR contenente la chiave segreta
• TKEY – non è memorizzata nei file di zona e nella
cache
• HMAC-MD5 provvede all’ autenticazione e al controllo
per l’integrità per la transazioni
Osservazioni su DNSSEC
DNS come un PKI
•
Il DNS con queste estensioni di sicurezza può diventare
la prima implementazione mondialedi un PKI disponibile
• DNSSEC “chain of trust” è un modello di certificazione
• Per memorizzarei certificati un nuovo RR è aggiunto
al DNS - il CERT RR definito nell’RFC 2538
• CERT può memorizzare i certificati PGP, X.509, SPKI
• La RFC 2538 raccomanda che la dimensione dei certificati
dovrebbe essereridotta al massimo - se possibile,
nessuna estensione
•
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!
Conclusioni
•
INDICE
Le Estensioni per la sicurezza provvedono:
• Protezione dei trasferimenti su Internet
• I dati sono firmati con chiavi pubbliche
(SIG, KEY)
• L’assenza di dati DNS è notificata (NXT)
• 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)
• Distribuzione di differenti tipi di certificati (CERT)
Introduzione generale
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Parte Prima: DNS
Introduzione
Differenza fra indirizzi IP e Nomi mnemonici
Gestione dello Spazio dei Nomi
DNS
Regole Sintattiche
Struttura Gerarchica del DNS, esempio
Domini Top Level
Name Server, Struttura gerarchica, Root Name Server
Zone di Autorità
Tipi di nomi
Risoluzione dei nomi, Resolver
Individuazione del Name Server
Completamento degli indirizzi
Modalità di risoluzione, Funzionamento del DNS
Cache, Formato dei messaggi
Tipi degli oggetti, Esempio di utilizzo dei tipi
Formato compresso dei nomi, Interrogazioni inverse
17
INDICE
INDICE
Riassumendo i concetti principali da conoscere...
Parte Terza: Estensioni per la Sicurezza del DNS
Parte Seconda: Attacchi e debolezze del DNS
•
•
•
•
•
•
•
•
•
•
•
• Introduzione
• Perché la Sicurezza del DNS è importante?
• Dns Spoofing. Destinazione errata indotta: Credere
in false informazioni
• Attacco Denial of Service
• Autenticazioni e Autorizzazioni basate sui nomi
• Esempio di attacco
• Comandi remoti, Equivalenza dei nomi
• Attacco alle informazioni supplementari
• Cache Poisoning
• Esempio di attacco
Introduzione
Definizioni DNSSEC
Caratteristiche DNSSEC
File di Zona
La firma
Tempo di validità
The Zone Signer
DNSSEC Chain of Trust
DNS Transaction Security
Osservazioni su DNSSEC
Conclusioni
Name Server
Formato della Answer Section
0
16
32
I Name Server sono programmi server che mantengono
informazioni sulla struttura ad albero del DNS e possono
settare tali informazioni.
Un Name server puo’ memorizzare in una cache qualsiasi
informazione del domain tree ma in generale ha
informazioni complete su una specifica parte del DNS.
Questo significa che il Name Server ha autorità per quel
sottodominio dello spazio dei nomi.
Per tale motivo è chiamato authoritative.
Resource Domain Name
Type
Class
Time to live
Resource Domain Name
Resource Data Length
Resource Data
RESOURCE DATA: contiene la risposta del name server
• formata da vari record di risorse (RR)
I Resource Record quindi rappresentano l’associazione fra
la struttura ad albero dello spazio dei nomi e i dati associati
a questi nomi.
DNS cache poisoning attack
Resolver
Scenario
I Resolver sono programmi che estraggono le informazioni
dai Name Server in risposta alle richieste del Client.
Esso può variare dalla semplice System call
(gethostbyname() o gethostbyaddress()) a più complesse
applicazioni con capacità di memorizzare informazioni in
cache (nslookup, dig, host).
Quando un programma utente deve risolvere un nome, esso
richiama il Resolver che esegue la seguente procedura:
Formula una Query e contatta il suo Name Server locale che
è preconfigurato (ad esempio in un file resolve.config).
Questa Query può essere sia Iterativa che Ricorsiva.
evil.com
Dalla sua macchina, l'attaccante chiede al name
server ns.broker.com di risolvere un nome sotto
l'autorità del suo name server, per esempio
broker.com
anyhost.evil.com.
1.anyhost.evil.com?
ns.evil.com
ns.broker.com
cache
Host
Attaccante
A.B.C.D
any.broker.com
bank.com
ns.bank.com
18
DNS cache poisoning attack
Supponiamo di considerare la
seguente situazione descritta
in figura.
Un attaccante che controlla il
name server per il suo
dominio evil.com vuole
avvelenare la cache di un
altro name server chiamato
ns.broker.com usato
da un'agenzia di brokers per
impersonare la macchina
www.bank.com che è spesso
accessibile dagli utenti del
dominio broker.com.
Scenario
evil.com
ns.evil.com
DNS cache poisoning attack
Scenario
broker.com
ns.broker.com
broker.com
evil.com
2. anyhost.evil.com?
1.anyhost.evil.com?
cache
Host
Attaccante
A.B.C.D
ns.evil.com
ns.broker.com
Il name server ns.broker.com
contatterà il name server
dell'attaccante, autoritativo
per quel nome.
Host
Attaccante
A.B.C.D
any.broker.com
bank.com
cache
any.broker.com
bank.com
ns.bank.com
ns.bank.com
DNS cache poisoning attack
Scenario
DNS cache poisoning attack
Scenario
broker.com
evil.com
2. anyhost.evil.com?
1.anyhost.evil.com?
ns.evil.com
3. Memorizza
query ID
ns.broker.com
2. anyhost.evil.com?
1.anyhost.evil.com?
cache
Questo name server risponderà alla query e prenderà
anche la query ID e la memorizza per un uso futuro.
Questa query ID è piazzata nell'header section di
qualsiasi messaggio Dns ed è assegnata dal programma
che ha generato la query (cioè dal Target name Server,
ovvero il name server attaccato )
Questo identificatore è copiato nel corrispondente
messaggio replay e può essere usato dal richiedente per
verificare i messaggi di replay per le query insospese
come menzionato nella RFC 1035.
Host
Attaccante
A.B.C.D
broker.com
evil.com
bank.com
ns.evil.com
cache
3. Memorizza
query ID
4.anyhost.evil.com=A.B.C.E
Host
Attaccante
A.B.C.D
6. www.bank.com?
L'attacco continua con un'altra query dal lato dell'attacante .
Egli sa che l'agenzia è frequentemente contattata da siti di
alcune banche, siti che verranno attacati. Egli chiederà al
ns.broker.com l'indirizzo www.bank.com. Normalmente, il
name server ns.broker.com contatterà il sever Dns autoritativo
per il dominio bank.com (ad esempio ns.bank.com).
bank.com
ns.bank.com
ns.broker.com
5.anyhost.evil.com=A.B.C.E
ns.bank.com
DNS cache poisoning attack
A questo punto, l'attaccante inizierà ad
inondare il server ns.broker.com con msg di
replay nel quale l'indirizzo della macchina
attaccante è mappato con www.bank.com prima
ns.evil.comche la vera risposta possa arrivare dal name
server autoritativo (che è ns.nbank.com).
Egli può anche predire correttamente il query
ID, poichè ha l'ultimo query ID generato da
ns.broker.com e quindi riesce a dedurlo (il
successivo, oppure secondo l'algoritmo spiegato
nelle RFC)
evil.com
Host
Attaccante
A.B.C.D
broker.com
ns.broker.com
cache
broker.com
evil.com
In questo modo il server
ns.broker.com riceve un
informazione che non è giusta e
la memorizza dopo aver risposto
alla query dell‘ attaccante per
www.bank.com.
ns.evil.com
ns.broker.com
cache
9.www.bank.com=
A.B.C.D
Host
Attaccante
A.B.C.D
8. www.bank.com=A.B.C.D
Inondare con false risposte il N.Server
bank.com
ns.bank.com
8. www.bank.com=A.B.C.D
Inondare con false risposte il N.Server
bank.com
ns.bank.com
19
Denial of Service (DoS)
Ora la trappola è scattata e tutto ciò che l'attaccante
evil.com
deve fare è aspettare fino a che una connessione dal
dominio broker.com viene fatta a www.bank.com.
Poichè l'IP della macchina attaccante è mappata
scorrettamente, nella cache del server( ns.broker.com),
ns.evil.com
al nome www.bank.com, tutte le connessioni alla banca
saranno dirette verso la macchina dell'attaccante. Il
name server non tenterà di chiedere dinuovo per il nome
www.bank.com, poichè userà solo l'informazione
memorizzata durante la precedente ricerca.
Questa è un'altra ragione per cui i dati ricevuti dai name
server
Host nel DNS hanno bisogno di un'autenticazione di
origine e di una verifica dell'integrità.
Attaccante
A.B.C.D
broker.com
ns.broker.com
cache
9.www.bank.com=
A.B.C.D
NEGAZIONE DEL SERVIZIO.
Un host viene “inondato” da un numero elevato di richieste
di un certo tipo, in modo da tenerlo occupato per un lasso di
tempo.
In questo modo viene negato il servizio che normalmente
compie l’host, per gli altri
10.www.bank.com?
bank.com
ns.bank.com
20