UNIVERSITA DI PISA
Facolta di Ingegneria
Corso di Laurea in Ingegneria delle Telecomunicazioni
Tesi di Laurea Magistrale
Realizzazione di un Test-Bed per
l’implementazione di protocolli di routing sicuri
in reti MANET
Relatori:
Prof. Michele Pagano
Prof. Stefano Giordano
Ing. Christian Callegari
Candidato:
Giuseppe Cocilovo
Anno Accademico 2012/2013
Alla mia famiglia.
Indice
Introduzione xi
1 Le Reti Manet 1
1.1 Caratteristiche delle MANET . . . . . . . . 4
1.2 I protocolli . . . . . . . . . . . . . . . . . . 5
1.2.1 Modalita Proactive . . . . . . . . . . 6
1.2.2 Modalita Reactive . . . . . . . . . . 14
2 Attacchi alle reti MANET 21
2.1 Byzantine Attack . . . . . . . . . . . . . . . 24
2.1.1 Link Spoofing Attack . . . . . . . . 24
2.1.2 Routing Loop Attack . . . . . . . . 26
i
INDICE
2.1.3 Packet Dropping Attack . . . . . . . 29
2.1.4 Message Modification Attack . . . . 30
2.1.5 Message Fabrication Attack . . . . . 31
2.2 Replay Attack . . . . . . . . . . . . . . . . . 32
2.3 Neighbor Attack . . . . . . . . . . . . . . . 34
2.4 Blackhole Attack . . . . . . . . . . . . . . . 36
2.5 Grayhole Attack . . . . . . . . . . . . . . . 40
2.6 Jellyfish Attack . . . . . . . . . . . . . . . . 41
2.7 Wormhole Attack . . . . . . . . . . . . . . . 43
2.7.1 Wormhole contro protocolli proattivi 45
2.7.2 Wormhole contro protocolli reattivi . 47
2.8 Rushing Attack . . . . . . . . . . . . . . . . 50
2.9 Sybil Attack . . . . . . . . . . . . . . . . . . 53
2.10 Resourse Consumption Attack . . . . . . . 55
2.10.1 Routing Table Overflow . . . . . . . 56
2.10.2 Jamming Attack . . . . . . . . . . . 57
2.10.3 Sleep Deprivation Attack . . . . . . 58
3 Test-bed 60
3.1 La rete MANET . . . . . . . . . . . . . . . 61
ii
INDICE
3.1.1 Realizzare e configurare una rete ad-
hoc . . . . . . . . . . . . . . . . . . . 61
3.1.2 Protocolli di Routing . . . . . . . . . 66
3.1.3 Sniffing del traffico . . . . . . . . . . 75
4 Implementazione 82
4.1 Replay Attack . . . . . . . . . . . . . . . . . 83
4.2 Drop Attack . . . . . . . . . . . . . . . . . . 90
4.3 Neighbor Attack . . . . . . . . . . . . . . . 95
4.4 Sybil Attack . . . . . . . . . . . . . . . . . . 98
4.5 Blackhole, Grayhole e Jellyfish . . . . . . . 101
4.6 Wormhole . . . . . . . . . . . . . . . . . . . 106
4.7 Discussione dei risultati e confronto con lo
stato dell’arte . . . . . . . . . . . . . . . . . 108
5 Sicurezza AODV 112
5.1 Messaggi scambiati . . . . . . . . . . . . . . 113
5.2 Attacchi . . . . . . . . . . . . . . . . . . . . 116
5.2.1 Replay . . . . . . . . . . . . . . . . . 116
5.2.2 Drop . . . . . . . . . . . . . . . . . . 119
5.2.3 Neighbor . . . . . . . . . . . . . . . 121
5.2.4 Sybil . . . . . . . . . . . . . . . . . . 123
iii
INDICE
5.2.5 Blackhole, Grayhole, Jellyfish . . . . 125
5.2.6 Sleep Deprivation . . . . . . . . . . . 128
5.2.7 Considerazioni finali . . . . . . . . . 130
Conclusioni 131
A Manuale 135
A.1 Fase di setup e installazione . . . . . . . . . 135
A.1.1 Configurare scheda di rete . . . . . . 135
A.1.2 Configurare protocollo . . . . . . . . 138
A.2 Parte Attacker . . . . . . . . . . . . . . . . 143
A.2.1 Installare librerie . . . . . . . . . . 143
A.2.2 Modifica di Libnet per aggiungere
header . . . . . . . . . . . . . . . . 145
A.3 Fase di implementazione . . . . . . . . . . . 146
A.3.1 Configurare rete ad hoc . . . . . . . 146
A.3.2 Configurare tunnel . . . . . . . . . . 149
A.4 Attacchi . . . . . . . . . . . . . . . . . . . . 150
A.4.1 Far partire un attacco . . . . . . . . 151
A.4.2 Blackhole . . . . . . . . . . . . . . . 153
A.4.3 Grayhole . . . . . . . . . . . . . . . 154
A.4.4 Jellyfish . . . . . . . . . . . . . . . . 155
iv
INDICE
A.4.5 Neighbor . . . . . . . . . . . . . . . 156
A.4.6 Packet Drop . . . . . . . . . . . . . 157
A.4.7 Replay . . . . . . . . . . . . . . . . . 157
A.4.8 Sleep Deprivation . . . . . . . . . . . 157
A.4.9 Sybil . . . . . . . . . . . . . . . . . . 158
A.4.10 Whormhole . . . . . . . . . . . . . . 158
A.5 Operazioni effettuate sui pacchetti . . . . . 159
A.5.1 Sniffing . . . . . . . . . . . . . . . . 160
A.5.2 Creazione pacchetti . . . . . . . . . 170
A.5.3 Accodamento dei pacchetti . . . . . 187
v
Elenco delle tabelle
5.1 AODV protection . . . . . . . . . . . . . . . 129
vi
Elenco delle figure
1.1 Rete Ad-hoc . . . . . . . . . . . . . . . . . 3
1.2 Invio di pacchetti senza e con l’utilizzo di
MPR . . . . . . . . . . . . . . . . . . . . . 9
1.3 Formato di un pacchetto OLSR generico con-
tenente due messaggi. . . . . . . . . . . . . 11
1.4 Struttura messaggio RREQ . . . . . . . . . 17
1.5 Struttura messaggio RREP . . . . . . . . . 17
1.6 Struttura messaggio RERR . . . . . . . . . 18
1.7 Protocollo AODV . . . . . . . . . . . . . . 20
2.1 Topologia Link Spoofing Attack . . . . . . 25
2.2 Topologia Routing Loop Attack . . . . . . 27
vii
ELENCO DELLE FIGURE
2.3 Topologia rete prima di un Neighbor Attack 36
2.4 Topologia rete dopo un Neighbor Attack . 37
2.5 Topologia Blackhole Attack . . . . . . . . . 39
2.6 Topologia Wormhole Attack con out-of-band
channel . . . . . . . . . . . . . . . . . . . . 46
2.7 Topologia Wormhole Attack con packet en-
capsulation . . . . . . . . . . . . . . . . . . 47
2.8 Topologia Rushing Attack . . . . . . . . . . 52
2.9 Topologia Rushing Attack . . . . . . . . . . 55
3.1 Laptop utilizzato . . . . . . . . . . . . . . . 62
3.2 Esempio di Topologia . . . . . . . . . . . . 65
3.3 Struttura messaggio con firma OLSR . . . 74
4.1 Struttura messaggio con firma OLSR . . . 84
4.2 Struttura messaggio Challenge . . . . . . . 85
4.3 Struttura messaggio Challenge - Response 86
4.4 Struttura messaggio Response - Response . 87
4.5 Output script VsReplayAttack . . . . . . . 90
4.6 Topologia Drop Attack . . . . . . . . . . . 92
4.7 Detection Drop Attack . . . . . . . . . . . 93
4.8 Output Detection Drop Attack . . . . . . . 94
viii
ELENCO DELLE FIGURE
4.9 Output Detection Neighbor Attack . . . . . 98
4.10 Sybil Mode On . . . . . . . . . . . . . . . . 99
4.11 Traffico Sniffato con Wireshark durante un
Sybil Attack . . . . . . . . . . . . . . . . . 100
4.12 Output Detection Sybil Attack . . . . . . . 102
4.13 Output Detection . . . . . . . . . . . . . . 106
4.14 Figura Topologia Wormhole . . . . . . . . 107
4.15 Tabella Riassuntiva . . . . . . . . . . . . . 111
5.1 Topologia Drop Attack . . . . . . . . . . . 119
5.2 Topologia Neighbor Attack . . . . . . . . . 122
5.3 Topologia Sybil Attack . . . . . . . . . . . 124
5.4 Topologia Blackhole/Grayhole/Jellyfish At-
tack . . . . . . . . . . . . . . . . . . . . . . 125
A.1 Verifica installazione scheda di rete . . . . 137
A.2 Generazione Chiave . . . . . . . . . . . . . 141
A.3 Salvataggio Chiave . . . . . . . . . . . . . . 142
A.4 Interfaccia scheda di rete . . . . . . . . . . 147
A.5 Script . . . . . . . . . . . . . . . . . . . . . 148
A.6 Indirizzo Scheda di Rete . . . . . . . . . . 148
A.7 Topologia con Tunnel . . . . . . . . . . . . 149
ix
ELENCO DELLE FIGURE
A.8 Menu . . . . . . . . . . . . . . . . . . . . . 151
A.9 Attacco Mode ON . . . . . . . . . . . . . . 152
A.10 Topologia Blackhole Attack . . . . . . . . . 153
A.11 Topologia Neighbor Attack . . . . . . . . . 156
A.12 Topologia Packet Drop Attack . . . . . . . 157
A.13 Cartella con gli script degli attacchi contro
l’OLSR . . . . . . . . . . . . . . . . . . . . 160
A.14 Cartella con gli script degli attacchi contro
l’AODV . . . . . . . . . . . . . . . . . . . . 161
A.15 Struttura pacchetto OLSR . . . . . . . . . 170
x
Introduzione
Ultimamente la societa si sta evolvendo verso scenari domi-
nati dalla mobilita. Tale mobilita e dettata principalmente
dalla necessita di ogni persona di essere continuamente, in-
dipendentemente dal luogo dove si trova, in comunicazione
con altre persone ad essa legate da interessi di lavoro, cul-
turali, sociali. Ognuno di noi quotidianamente si trova di
fronte alla necessita di dover risolvere dei problemi pur
essendo lontani fisicamente dal sito dove si e verificato il
problema stesso. Per rispondere a tali ed altre esigenze
l’innovazione tecnologica ha prodotto i dispositivi mobili e
nuove tipologie di rete. In particolare, l’attenzione e stata
rivolta alle reti MANET.
xi
INTRODUZIONE
Dal punto di vista delle telecomunicazioni, una Mobile
Ad-hoc NETwork (MANET) e definita come un sistema
autonomo di terminali mobili connessi mediante collega-
menti wireless di tipo ad-hoc. La definizione di rete ad
hoc fornita dall’IETF e:
“Una MANET e un sistema autonomo di router mo-
bili e host associati, connessi con collegamenti di tipo wi-
reless, formando un grafo di forma arbitraria. Tali router
sono liberi di muoversi casualmente e di auto organizzarsi
arbitrariamente, sebbene la topologia wireless vari rapida-
mente ed in modo imprevedibile. Tale rete puo operare in
isolamento oppure essere connessa alla rete Internet” [11].
Tutti i nodi del sistema collaborano con lo scopo di in-
stradare i pacchetti nel modo corretto secondo la modalita
di forwarding di tipo multihop. Una MANET e quindi una
rete wireless dinamica che si puo costruire all’occorren-
za ed utilizzare in ambienti estremamente dinamici senza
un’infrastruttura preesistente o una gestione centralizza-
ta. In queste reti ogni nodo puo comportarsi oltre che da
sorgente o destinazione anche come router, ragion per cui
le MANET sono utilizzate in applicazioni quali comunica-
xii
INTRODUZIONE
zioni sui campi di battaglia, scenari di emergenza o eventi
locali come conferenze e meeting pubblici.
Quando si parla di MANET bisogna tener presente che,
essendo create al momento, non godono di grandi risorse
energetiche e che per loro natura non hanno una chiara li-
nea di difesa. In modo particolare il fatto di non avere una
propria ‘linea di difesa’ fa si che ne possono entrare a far
parte sia utenti legittimi sia attackers, ossia utenti malin-
tenzionati che hanno libero accesso al canale di comunica-
zione. Generalmente ogni nodo annuncia la sua presenza
nella rete ed ascolta la comunicazione tra gli altri nodi, che
dunque diventano conosciuti. Col passare del tempo ogni
nodo acquisisce la conoscenza di tutti i nodi della rete e
di uno o piu modi per comunicare con loro; quindi, non
essendoci router dedicati, ogni nodo, come detto pocanzi,
puo funzionare sia da host che da router e inoltrare quindi
pacchetti ad altri host della rete.
Le politiche di routing presenti ad oggi nelle MANET
suppongono di lavorare in una ambiente basato sulla fidu-
cia ed e proprio questo uno dei punti deboli di tali reti.
Infatti puo accadere, con estrema facilita, che un attac-
xiii
INTRODUZIONE
ker diventi un router e andando contro quelle che sono le
specifiche del protocollo, riesca a compromettere le ope-
razioni della rete. In un contesto del genere ha un suo
peso, quindi, il fatto di rendere la rete configurata ad-hoc
il piu sicura possibile, cercando di proteggerla attraverso
l’analisi dei punti deboli nei vari attacchi. Tipicamente gli
attacchi vengono fatti sfruttando i messaggi previsti dal
protocollo stesso, poiche l’invio di questi permette appun-
to di diffondere informazioni non veritiere, compromettere
le varie route, l’esclusione di alcuni nodi e cosı via. In uno
scenario come quello delle MANET, diventa quindi impor-
tante trovare una soluzione per evitare la presenza di nodi
malevoli e render sicura la rete proteggendola dai vari at-
tacchi; nello stesso tempo pero si suppone che i terminali
non abbiamo elevate risorse, sia in termini di velocita com-
putazionale che di potenza disponibile per le applicazioni
e di durata di batteria, ed e proprio per questo motivo
che queste reti sono perennemente soggette ad attacchi
come il Blackhole, Wormhole, Replay, Jellyfish, Neighbor
piuttosto che attacchi di tipo IP Spoofing o Link Spoofing.
In questo testo vengono studiati e descritti gli attac-
xiv
INTRODUZIONE
chi precedentemente elencati con il fine di cercare di im-
plementare, sfruttando al meglio le risorse, una versione
sicura di due dei possibili protocolli utilizzati nelle reti
MANET.
L’elaborato e strutturato come segue.
Nel capitolo 1, viene fatta una panoramica sulle reti
MANET e sui vari protocolli di routing utilizzati, focaliz-
zando l’attenzione sui protocolli utilizzati per implemen-
tare le operazioni di routing e gli attacchi.
Nel capitolo 2, viene descritto il principio base di cia-
scun attacco e con esso vengono descritte anche le possibili
conseguenze, facendo quindi, attraverso la presentazione
di un’opportuna topologia, considerazioni in merito alla
posizione dell’attacker.
Nel capitolo 3, vengono descritti la realizzazione del
test-bed e gli strumenti utilizzati per cercare di creare una
versione sicura dei protocolli. In particolare viene descritto
il protocollo OLSR e come si puo implementare una prima
linea di difesa.
Nel capitolo 4, vengono analizzati i vari attacchi ed in
particolare le debolezze di ognuno di essi; viene spiegato
xv
INTRODUZIONE
inoltre come partendo appunto da tali debolezze e stata
implementata una versione sicura del protocollo OLSR.
Nel capitolo 5, viene fatto lo studio degli attacchi rivolti
ad un protocollo reattivo quale l’AODV. Successivamente
viene descritto come attraverso uno studio teorico di que-
sti e possibile implementare delle soluzioni che potrebbero
contribuire a garantire la sicurezza nelle reti in questione.
xvi
Capitolo 1
Le Reti Manet
Le MANET [1](Mobile Ad hoc NETwork) sono un tipo di
rete innovativo formato da dispositivi wireless, quindi mo-
bili, capaci di comunicare tra loro svolgendo operazioni di
instradamento, senza alcun bisogno di una infrastruttura,
come avviene invece per la telefonia cellulare che ha biso-
gno per esempio di antenne e ripetitori. Le reti ad-hoc sono
un sistema di comunicazione dati basato su trasmissioni ra-
dio, nelle quali i nodi comunicano esclusivamente su canali
wireless. Le reti MANET si basano sul concetto Peer-to-
1
Peer (P2P), dove i peer non sono altro che normalissimi
dispositivi quali PC, palmari, smartphone, laptop,etc... Il
fulcro di questo tipo di architettura e appunto l’assenza
di un server centrale che amministri le connessioni e le ri-
sorse. Una rete MANET dunque e una rete temporanea,
senza punti di accesso, che non viene preconfigurata, ma
si forma per la sola presenza dei vari dispositivi in un dato
territorio, auto-configurandosi ed auto-organizzandosi. I
nodi nella rete in questione si comportano non solo come
host ma anche come router.
Nella Figura 1.1 viene presentata una possibile topolo-
gia della rete, da cui si evince che i dispositivi che parte-
cipano alla MANET possono comunicare, a seconda delle
loro esigenze, con tutti gli altri nodi.
Ovviamente, come in tutte le altre tipologie di rete an-
che nelle reti configurate ad-hoc quando si vuole trovare un
percorso che permetta di inoltrare pacchetti da sorgente a
destinazione bisogna adottare delle opportune procedure
di routing. Nel caso di MANET bisogna tener presente
che comunque, a differenza delle reti cablate, si hanno link
asimmetrici, interferenze tra le varie comunicazioni e una
2
Figura 1.1: Rete Ad-hoc
topologia in continua evoluzione [2]. Uno dei principali
problemi presenti in queste tipo di rete, data la mobilita
dell’ambiente e la disponibilita limitata di risorse, e ap-
punto quello della scelta delle varie politiche di routing;
infatti si e sempre in conflitto poiche la rete per sua na-
tura richiede uno scambio di informazioni constante, ma
per i motivi precedentemente elencati si ha la necessita di
limitare il traffico il piu possibile.
3
1.1. CARATTERISTICHE DELLE MANET
1.1 Caratteristiche delle MANET
E possibile riassumere le caratteristiche piu salienti di una
rete a d-hoc, quale la MANET, come segue:
• Topologia Dinamica.
I nodi sono liberi di muoversi arbitrariamente, per-
cio la topologia della rete puo cambiare in maniera
imprevedibile in maniera random (nello spazio).
• Vincoli di banda e capacita variabile dei link.
A differenza delle reti ‘infrastrutturate’, in queste i
collegamenti wireless tra nodi non godono di grosse
capacita trasmissive.
• Operazioni vincolate dall’energia.
Tipicamente l’energia dei nodi di una rete ad-hoc di-
pende da batterie o strumenti energetici simili. Per
questi nodi quindi e importante studiare dei crite-
ri di progettazione cosicche si possa ottimizzare il
consumo energetico.
• Sicurezza limitata.
4
1.2. I PROTOCOLLI
Per la loro natura, le reti mobili wireless sono ge-
neralmente piu esposte ad attacchi rispetto alle re-
ti cablate. Pertanto, la sempre piu crescente possi-
bilita di attacchi quali ascolti, spoofing e denial-of-
service deve essere tenuta in conto dai progettisti che
realizzano sistemi per queste reti.
1.2 I protocolli
Come detto pocanzi uno dei problemi principali e la scel-
ta delle opportune politiche di routing. In particolare gli
algoritmi di routing devono:
- creare le tabelle di routing in modo tale da essere piu
piccole possibili;
- aggiornare costantemente le tabelle di routing;
- eventualmente offrire path multipli per una stessa
destinazione;
- valutare i vari percorsi e riuscire a scegliere il migliore
per raggiungere una destinazione.
5
1.2. I PROTOCOLLI
I protocolli possono essere classificati in base alla mo-
dalita di reperimento delle informazioni e di instradamen-
to. Possiamo distinguere protocolli Proattivi (che tra-
smettono informazioni in modalita proactive) e proto-
colli Reattivi (che scambiano informazioni in modalita
reactive).
1.2.1 Modalita Proactive
In modalita Proactive i nodi si scambiano informazioni
di routing a intervalli fissi di tempo; questa caratteristica
permette che ci sia un percorso immediatamente disponi-
bile ad ogni richiesta; purtroppo cio comporta un elevato
traffico di segnalazione.
Negli algoritmi Proactive (o Table-Driven) l’instrada-
mento ad ogni richiesta e disponibile immediatamente gra-
zie al fatto che i vari dispositivi mobili si scambiano perio-
dicamente informazioni di routing. L’idea e di mantenere
costantemente aggiornate le informazioni di instradamento
tra tutti i dispositivi che compongono la rete.
I protocolli che fanno parte di questa classe sono i
seguenti:
6
1.2. I PROTOCOLLI
1. DSDV (Destination Sequenced Distance Vector).
2. WRP (Wireless Routing Protocol).
3. CSGR (Cluster Switch Gatewey Routing).
4. STAR (Source Tree Adaptive Routing).
5. OLSR (Optimized Link State Routing).
I protocolli che fanno parte della famiglia Proactive
sono accomunati dalle seguenti caratteristiche:
- Scambio di pacchetti ad intervalli fissi.
- Uso di tabelle.
- Aggiornamento delle tabelle.
I pacchetti rivelano sia le informazioni di instradamento
sia i relativi cambiamenti topologici della rete. L’uso di
una o piu tabelle che memorizzano tutte le informazio-
ni riguardanti la topologia della rete e una caratteristica
peculiare della classe Proactive. In particolare andiamo a
vedere come funziona l’OLSR, poiche quello che rispecchia
piu le nostre esigenze.
7
1.2. I PROTOCOLLI
OLSR
OLSR [3] e un algoritmo di tipo proattivo, in cui inizial-
mente ogni nodo collabora con i suoi vicini per costruire
una tabella di instradamento contenente i path verso tut-
ti i nodi esistenti. Dopo questa inizializzazione i nodi si
scambiano periodicamente dei messaggi per mantenere ag-
giornati i propri dati topologici. Come suggerisce il nome
dell’algoritmo, OLSR utilizza il broadcast delle informa-
zioni sullo stato di tutti i collegamenti conosciuti ad ogni
nodo per permettere la ricostruzione della topologia di re-
te. Questo broadcast viene pero ottimizzato, per limitare
al massimo lo spreco di banda, utilizzando un sistema chia-
mato MultiPoint Relaying (MPR). La tecnica MPR
nasce dall’osservazione che in una situazione di broadcast
non ottimizzato ogni nodo riceve piu volte le stesse infor-
mazioni causando un notevole spreco di banda e di potenza
di elaborazione. Questa situazione puo essere migliorata
scegliendo un particolare sottoinsieme di nodi che possono
ritrasmettere le informazioni.
In OLSR (vedi Fig. 1.2) ogni nodo sceglie un sottoin-
sieme dei suoi vicini simmetrici tale che ogni secondo vi-
8
1.2. I PROTOCOLLI
Figura 1.2: Invio di pacchetti senza e con l’utilizzo di MPR
cino sia raggiungibile tramite questo sottoinsieme. Il si-
stema MPR viene usato come metodo di default per la
ritrasmissione dei messaggi. Il traffico di controllo che vie-
ne utilizzato per il calcolo dei percorsi e generato dai nodi
scelti come MPR per accettare anche la perdita di qualche
messaggio; inoltre poiche in questo protocollo ogni pac-
chetto ha un proprio sequence number che lo identifica in
maniera univoca, non e richiesta la consegna ordinata. In
una rete possono esistere piu MPR, infatti ogni nodo del-
la MANET seleziona, tra i vicini con i quali ha un link
bidirezionale, un set di multi point relay; questo set e scel-
to con l’unica peculiarita di far arrivare le informazioni di
9
1.2. I PROTOCOLLI
routing a tutti gli host a due hop di distanza passando dal
minor numero di MPR. I neighbors che non appartengono
al set ricevono ed elaborano i messaggi broadcast ma non
li ritrasmettono.
OLSR utilizza pacchetti UDP, con numero di porta
pari a 698, per trasferire le informazioni di controllo, ogni
pacchetto puo contenere piu di un messaggio proveniente
da mittenti differenti, per ottimizzare il tempo di trasmis-
sione. I messaggi richiesti dalla funzionalita base di OLSR
sono:
HELLO: inviati ad intervalli regolari, compiono le funzio-
ni di rilevamento dei vicini, comunicazione dei nodi
MPR e link sensing
TC (Topology Control): servono a comunicare infor-
mazioni topologiche dal punto di vista di ogni nodo
MID (Multiple Interface Declaration): usati dai no-
di con piu interfacce per dichiararne l’esistenza al
resto della rete.
Un generico pacchetto e descritto nella Figura 1.3.
Descriviamo quindi alcuni campi:
10
1.2. I PROTOCOLLI
Figura 1.3: Formato di un pacchetto OLSR generico contenentedue messaggi.
- Packet Length: valore che indica la lunghezza del
pacchetto
- Packet Sequence Number : valore che identifica in
maniera univoca ogni singolo pacchetto
- Message Type: tipo di messaggio (HELLO, TC op-
pure MID)
Andiamo quindi a descrivere brevemente il funziona-
11
1.2. I PROTOCOLLI
mento di OLSR. Ogni nodo ad intervalli regolari, manda
un messaggio di HELLO. Grazie all’utilizzo di questo mes-
saggio i nodi annunciano la lista dei vicini e anche il tipo,
indicando attraverso il campo Link Code se un nodo e un
MPR oppure un semplice host. I messaggi di HELLO a
differenza di tutti gli altri vengono scambiati localmente
senza appunto esser inoltrati, i messaggi TC invece ven-
gono utilizzati per calcolare i vari percorsi e non vengono
inviati in locale. Ogni MPR ha il compito inoltre di inviare
periodicamente TC messages i quali contengono appunto
la lista dei vicini che lo hanno scelto. In questa tipologia di
messaggi assume particolare importanza il parametro AN-
SN (Advertised Neighbor Sequence Number), un numero
associato al set di vicini annunciati che viene incrementato
di uno ogni volta che il nodo rileva un cambiamento nel set
stesso. Da cio che e stato detto sin ora, si evince il fatto
che, come previsto dall’rfc [3], per il calcolo della tabella di
routing, si preferiscono path con il minor numero di hop,
cio implica pero, il fatto che sara preferito un percorso at-
traverso un singolo link, anche se non buono, ad una route
che passa da due link eccellenti, nonostante la seconda scel-
12
1.2. I PROTOCOLLI
ta sia la migliore. Quello descritto pocanzi e appunto un
problema che viene risolto attraverso l’utilizzo dell’esten-
sione ‘Link Quality’ di OLSR che permette di conoscere
la qualita dei link. Ogni nodo non fa altro che valutare la
packet loss per i pacchetti che riceve dai vicini. Attraver-
so l’invio di piu pacchetti di HELLO viene calcolata la LQ
(Link Quality), cioe la probabilita che la trasmissione vada
a buon fine; altro parametro calcolato e la NLQ (Neighbor
Link Quality) che indica la qualita del link nella direzione
opposta. Infine attraverso la combinazione di queste due
viene calcolata la ETX (Expected Trasmission Count) che
indica la qualita del link in entrambe le direzioni.
EXT = 1/(LQ * NLQ)
Se si ha a che fare con una route che passa da piu
link, calcolare l’ETX totale vuol dire semplicemente fare
la somma dei singoli ETX.
Infine, dato che comunque nelle MANET uno dei pro-
blemi principali e sempre quello di ridurre al massimo l’uso
di risorse, si utilizzano altri due tipi di messaggi:
13
1.2. I PROTOCOLLI
LQ-HELLO: per ogni link annunciato, l’originator co-
munica anche il valore di LQ che si e calcolato.
LQ-TC: porta informazioni su quanto sono buoni i link.
Il fine unico e quello dunque di scegliere il percorso con un
ETX totale minore e non piu in base al numero di hop.
1.2.2 Modalita Reactive
In modalita Reactive, viene invocata una procedura per
determinare il corretto instradamento solo se si vuole tra-
smettere un pacchetto. Cio porta ad avere un ritardo nella
trasmissione dei pacchetti dati, riuscendo pero ad abbassa-
re notevolmente il traffico di segnalazione. In un contesto
del genere si dice che i percorsi vengono creati On De-
mand, il concetto che sta alla base di questi protocolli e
appunto quello di evitare di salvare le varie route poiche
queste, a causa della mobilita dei nodi, sono in continuo
mutamento.
I protocolli che fanno parte di questa classe sono i
seguenti:
14
1.2. I PROTOCOLLI
1. AODV (Ad Hoc On-Demand Distance Vector Rou-
ting).
2. DSR (Dynamic Source Routing).
3. TORA (Temporally Ordered Routing Algorithm).
4. PAR (Power-Aware Routing).
5. LAR (Location-Aided Routing).
I protocolli che fanno parte della famiglia Reactive sono
accomunati dalle seguenti caratteristiche:
- Scoperta del percorso tramite Route discovery.
- Mantenimento del percorso tramite Route Mantei-
nence.
- Cancellazione del percorso con Route Deletion.
AODV
AODV [4], in quanto facente parte della classe dei pro-
tocolli reattivi, permette di ottenere un percorso per una
15
1.2. I PROTOCOLLI
nuova destinazione senza richiedere ai nodi di mantene-
re routes per destinazioni che non sono attive. Uno dei
concetti che sta alla base di questo protocollo e quello di
fiducia reciproca ed inoltre, affinche si possano migliora-
re la scalabilita e le performance, si propone di ridurre
overhead e quantita di traffico di controllo presente nella
MANET.
Il protocollo in questione utilizza pacchetti UDP, con
numero di porta 654.
I messaggi richiesti dalla funzionalita base di AODV
sono:
RREQ (Route REQuest): inviati quando un nodo vuo-
le raggiungere una destinazione della quale non ha
alcuna route disponibile (vedi Fig. 1.4).
RREP (Route REPly): utilizzati per rispondere ad una
richiesta arrivata tramite RREQ (vedi Fig. 1.5).
RERR (Route ERRor): inviati in presenza di errori o
nel caso in cui viene a mancare qualche link (vedi
Fig. 1.6).
16
1.2. I PROTOCOLLI
Figura 1.4: Struttura messaggio RREQ
Figura 1.5: Struttura messaggio RREP
Il parametro che caratterizza l’AODV Protocol e il De-
stination Sequence Number. Esso e creato dal nodo di de-
stinazione, per accompagnare le informazioni relative al
percorso a raggiungerlo, evitando cosı la creazione di loop.
Un nodo che desidera offrire informazioni sulla connetti-
vita invia, ogni HELLO INTERVAL, in broadcast HELLO
17
1.2. I PROTOCOLLI
Figura 1.6: Struttura messaggio RERR
messages, possiamo brevemente descrivere la fase di ‘Route
Discovery’ nel seguente modo:
quando il nodo sorgente richiede un percorso, per rag-
giungere il nodo di destinazione inizia una fase di flooding
inviando richieste a tutta la rete. Questa richiesta puo
arrivare sia direttamente a destinazione, sia ad un nodo
intermedio, il quale deve essere in possesso di un’infor-
mazione sufficientemente aggiornata. Una volta che un
qualsiasi nodo, indistintamente dal fatto che possa essere
la destinazione o no, riceve una richiesta, deve immediata-
mente rimandare al nodo sorgente una risposta, la quale
indica l’avvenuta ricezione dell’informazione. Cio puo es-
sere fatto utilizzando il percorso inverso. Per essere certi
di costruire percorsi senza loop e contenenti informazioni
18
1.2. I PROTOCOLLI
aggiornate, ogni nodo mantiene un numero di sequenza.
Tale numero, identifica univocamente ogni percorso ed e
per questa ragione che viene ogni volta incrementato, cosı
che un nodo riesca a capire se ne e gia in possesso o me-
no. Entrando piu nel dettaglio, quando il nodo sorgente
richiede una route, oltre ad effettuare una richiesta di sco-
perta dei vicini, invia un pacchetto RREQ che rappresen-
ta l’instanza di un percorso per giungere a destinazione.
La fase di Route Discovery continua attraverso l’invio dei
pacchetti RREQ anche dai nodi intermedi, che contatta-
no altri nodi a loro adiacenti, finche si raggiunge il nodo
richiesto. Il pacchetto RREQ viene identificato dall’ID e
dall’indirizzo IP del nodo sorgente.
Per concludere nella Figura 1.7 viene mostrata l’ope-
razione di Route Discovery, in cui il nodo N1 inoltra una
richiesta a tutti i suoi vicini (cio viene determinato dal-
l’orientamento delle frecce), che a loro volta spediscono
pacchetti RREQ giungendo a destinazione. Data la bidire-
zionalita dei link, una volta raggiunta la destinazione, que-
st’ultima rimandera tramite un percorso inverso (nel caso
proposto il piu corto, ma non e sempre detto) un pacchet-
19
1.2. I PROTOCOLLI
to RREP (Route Reply) contenente il percorso (insieme di
indirizzi IP dei nodi) che e stato fatto per raggiungerla.
Figura 1.7: Protocollo AODV
20
Capitolo 2
Attacchi alle reti
MANET
Le caratteristiche delle MANET, quali utilizzo di un canale
wireless accessibile a tutti, topologia in continuo cambia-
mento, mancanza di gestione e monitoraggio centralizzato
e assenza di alcun tipo di linea di difesa, fanno si che esse
siano vittime di attackers. Infatti, dato che qualsiasi nodo
puo, liberamente e come meglio crede, unirsi alla rete e
diventare parte integrante di essa, comunicare, inoltrare,
21
ricevere pacchetti e staccarsi dalla rete senza alcun tipo di
opposizione, gli attacchi avvengono con estrema facilita e
senza alcun impedimento. Alla base di tutto cio vi e inol-
tre la mancanza di un vero e proprio organo centrale che
si occupi di gestire la rete, evitando cosı di far accedere
ad essa chiunque. Nel presente capitolo vengono intro-
dotti e descritti i vari attacchi che una rete MANET puo
subire. Come detto pocanzi un ipotetico attacker puo por-
tare a termine vari attacchi, che posso essere raggruppati
secondo due aspetti:
• ATTACCHI ESTERNI e INTERNI
• ATTACCHI ATTIVI e PASSIVI
Come e facile intuire la prima classificazione e basata sulla
provenienza degli attacchi mentre la seconda sul compor-
tamento dell’attacker.
Gli attacchi esterni hanno il fine unico di causare con-
gestione o disturbare i nodi nel fornire servizi e vengono
compiuti da nodi che non fanno parte della rete. Gli at-
tacchi interni invece vengono compiuti da uno o piu nodi
malevoli che riescono ad entrare a fare parte della rete,
22
partecipando quindi alle attivita di routine, oppure rie-
scono a compromettere un nodo gia attivo inducendolo
ad un comportamento scorretto. Ovviamente tutto cio
e possibile proprio perche ogni nodo ripone piena fiducia
negli altri host della rete. Gli attacchi di questa classe
sono estremamente pericolosi, infatti un nodo malevolo
puo compiere operazioni sui pacchetti, quali modificarli,
replicarli e crearne nuovi; inoltre l’attacker puo deviare il
traffico, negare un servizio o peggiorare le prestazioni di
un link. Passando alla seconda classificazione possiamo
dire che gli attackers che compiono attacchi attivi si com-
portano in maniera tale da compromettere i messaggi che
viaggiano in rete, modificandoli o scartandoli, in modo ta-
le da distruggere le funzionalita della rete [5]. Gli attacchi
passivi invece non distruggono le normali operazioni della
rete, ma lo scopo dell’attacker e appunto quello di ricava-
re piu informazioni possibili attraverso lo sniffing dei dati
che viaggiano nella rete. Questi, a differenza di tutti gli
altri attacchi, sono piu difficili da rilevare poiche le normali
attivita della rete non vengono compromesse.
23
2.1. BYZANTINE ATTACK
Passiamo quindi alla descrizione nel dettaglio dei vari
attacchi.
2.1 Byzantine Attack
In questo attacco vi e la presenza di un nodo corrotto che,
senza danneggiare le normali operazioni della rete, riesce
a distruggere o degradare i servizi di routing, creare loop
o far cadere link attraverso appunto l’inoltro di pacchetti
per percorsi non ottimi o attraverso lo scarto selettivo di
alcuni pacchetti. Questa tipologia di attacco e difficile da
scoprire perche dal punto di vista dei nodi la rete sembra
comportarsi in maniera corretta. Il Byzantine Attack puo
essere realizzato secondo le modalita descritte nei seguenti
paragrafi.
2.1.1 Link Spoofing Attack
Lo scopo in questo caso e appunto quello di distruggere le
operazioni di routing e per far cio il nodo malevolo annun-
cia un falso link con un nodo che non e un vicino. Questo
attacco nel caso in cui si utilizza il protocollo OLSR con-
24
2.1. BYZANTINE ATTACK
siste nell’annuncio, da parte del nodo malevolo, di un link
con un nodo vicino a due hop della vittima. Cosı facendo
si provoca l’assegnazione del titolo di MPR all’attacker. A
questo punto l’attacker, essendo un MPR, puo manipolare
o scartare il traffico portando a termine un attacco di tipo
DoS (Denial of Service).
Figura 2.1: Topologia Link Spoofing Attack
25
2.1. BYZANTINE ATTACK
Nel caso di protocollo OLSR (vedi Fig. 2.1). Il nodo A
e l’attacker mentre il nodo T e la vittima. Prima dell’at-
tacco per il nodo T gli MPRs sono i nodi A e B. Durante
l’attacco, il nodo malevolo annuncia un link con il nodo D
che dista due hops dalla vittima, quindi, in accordo con
OLSR, A diventa l’unico MPR perche con soli due hops
riesce a raggiungere tutti i vicini. Fatto cio l’attacker puo
operare sui pacchetti inviati dalla vittima e decidere se
inoltrarli o meno [6].
2.1.2 Routing Loop Attack
Questo attacco e realizzabile solo contro le reti che utiliz-
zano un Reactive Protocol. Un nodo malevolo attraverso
la modifica dei pacchetti che vengono inviati durante la fa-
se di route discovery riesce a creare un loop facendo si che
il traffico giri indefinitivamente tra i nodi intermedi senza
che appunto questo arrivi a destinazione. In particolare
l’attacker riesce a farsi includere nel percorso e a dirigere
il traffico in modo tale da formare un loop se si trova vicino
al percorso tra sorgente e destinazione ed e vicino di due
nodi successivi appartenenti alla route.
26
2.1. BYZANTINE ATTACK
Analizziamo la Figura 2.2 e vediamo un chiaro esem-
pio di Routing Loop Attack nel caso in cui si utilizzi il
protocollo AODV.
Figura 2.2: Topologia Routing Loop Attack
Ipotizzando che S sia la sorgente, D la destinazione e A
il nodo malevolo, possiamo considerare come percorso cor-
retto il seguente S-X-P-N-J-D. Il nodo A per prima cosa
27
2.1. BYZANTINE ATTACK
aggiunge una route statica facendo si che, affinche si possa
raggiungere la destinazione, si debba passare da P. Dopo-
diche invia una RREP, con un Sequence Number maggiore
di quello utilizzato nelle RREPs non corrotte, a N. In tal
modo avviene che, quando il nodo P riceve un pacchetto
da parte di S, lo inoltra correttamente a N, il quale pero
a sua volta lo invia ad A poiche crede che il miglior per-
corso per raggiungere la destinazione sia appunto quello
che passa dall’attacker; in seguito A inoltra nuovamente
il pacchetto in questione a P facendo si che il giro inizi
nuovamente. Alla fine di tutto cio si verifica la creazione
di un loop tra S e D il quale porta allo scarto dei pacchetti
una volta che il TTL di questi raggiunge il valore zero.
Lo stesso attacco puo essere implementato anche in una
topologia in cui l’attacker non e vicino al nodo designato
come bersaglio. Come prima cosa l’attacker cerca un nodo
vittima che si trova nelle vicinanze del path in questione
e lo forza ad aggiornare la sua tabella di routing con la
route statica precedentemente descritta. Anche in questo
caso, affinche N invii alla vittima i pacchetti destinati a D
creando il loop, l’attacker deve inviare una RREP falsa.
28
2.1. BYZANTINE ATTACK
2.1.3 Packet Dropping Attack
Il Packet Dropping Attack consiste nello scartare pacchetti
indistintamente dalla loro tipologia, quindi indistintamen-
te dal fatto che si tratti di pacchetti dati o di routing.
Tipicamente l’attacker, durante la fase di route discove-
ry, inizia col comportarsi onestamente, facendo si che esso
stesso possa esser incluso come nodo intermedio nel per-
corso in questione, per poi successivamente scartare i pac-
chetti che da sorgente dovrebbero arrivare a destinazione.
Lo scarto dei pacchetti puo avvenire:
• Constantemente.
• In maniera Random.
• Periodicamente.
In particolare attraverso lo scarto periodico l’attacker
riesce a tener nascosto il proprio comportamento scorret-
to [5]. Altro modo per raggiungere lo stesso risultato e
quello di non cooperare con gli altri nodi della rete; infat-
ti il nodo malevolo (attraverso la mancata collaborazione,
il non inoltro dei pacchetti, il non invio dei messaggi di
29
2.1. BYZANTINE ATTACK
errore o addirittura attraverso il suo spegnimento) riesce
ad interrompere le normali operazioni delle rete renden-
do inoltre indisponibili alcuni servizi. A volte questo tipo
di attacco puo essere compiuto anche da nodi che scarta-
no pacchetti senza avere cattive intenzioni, ma che hanno
come obiettivo quello di salvaguardare le proprie risorse
[7].
2.1.4 Message Modification Attack
Pur di compromettere l’integrita dei pacchetti in rete, gli
attackers possono anche apportare alcuni cambiamenti ai
messaggi di routing. Come conseguenza del fatto che i no-
di sono liberi di muoversi e di auto-organizzarsi, facendo
si che il nodo malevolo possa essere, in totale tranquillita,
incluso nei collegamenti, si ha che quest’ultimo puo deci-
dere se comportarsi correttamente partecipando quindi ai
processi di packet forwarding oppure, decidere di lanciare
l’attacco modificando alcuni campi del pacchetti. Se per
esempio si prende in considerazione il protocollo AODV
l’attacco puo avvenire attraverso l’incremento dell’id di
una vecchia RREQ rendendola valida, oppure abbassan-
30
2.1. BYZANTINE ATTACK
do il valore del campo hop count per aggiornare la tabelle
di routing degli altri nodi; cosı facendo e possibile anche
ridirigere il traffico dal path originale verso un percorso
piu lungo e quindi non ottimo.[8]
2.1.5 Message Fabrication Attack
In questo caso, piuttosto che modificare o bloccare i pac-
chetti di routing gia esistenti nella rete, l’attacker prefe-
risce costruirne nuovi in modo tale da creare caos nelle
operazioni della rete [5].
Nel caso specifico di protocolli proattivi l’attacker puo
sia annunciare link inesistenti attraverso l’invio di falsi pac-
chetti di HELLO che diffondere informazioni di topologia
sbagliate attraverso la creazione di TC messages non ve-
ri. Nel caso di protocolli reattivi invece i falsi messaggi
possono essere quelli di route error; inviando questi mes-
saggi l’attacker fa credere agli altri nodi della rete che uno
specifico collegamento e down isolando cosı il nodo che lo
usa.
31
2.2. REPLAY ATTACK
2.2 Replay Attack
Il Replay Attack, come dice il nome stesso, consiste nella
trasmissione ripetuta in maniera fraudolenta di dati vali-
di; ovviamente questo attacco e compiuto da un nodo che
fa parte della rete; questo intercetta i pacchetti e li ritra-
smette con l’intenzione o di deviare il traffico, evitando
magari di utilizzare il path migliore, oppure di avviare un
attacco di tipo Denial of Service [5]. In questo caso per
evitare di esser scoperto il nodo puo replicare tutti i pac-
chetti tranne quelli di controllo dell’area stessa in cui li ha
sniffati. Solitamente per deviare questo attacco, identifi-
cando cosı anche le informazioni piu recenti, i protocolli di
routing utilizzano i sequence number. E’ possibile portare
a compimento questo attacco in un’altra area senza essere
scoperti. Infatti in quest’ultima non ci sono comunicazioni
precedenti con l’originator del pacchetto e di conseguenza
non ci sono messaggi con cui poter confrontare il sequence
number. Nel caso di protocolli Proactive, possono esse-
re replicati messaggi di Topology Control per reintrodurre
vecchi link o per rimuoverne uno esistente; pero, affinche
32
2.2. REPLAY ATTACK
cio possa esser fatto, l’attacker deve fare attenzione al fat-
to che i TC messages sono forniti di un sequence number
il quale permette a chi riceve i pacchetti di valutare la
‘freschezza’ dell’informazione. Considerando il fatto che
questo attacco e piu efficace nel momento in cui vengono
usati pacchetti che non sono propagati per piu di un hop,
si puo valutare il caso in cui ad essere replicati sono i mes-
saggi di HELLO; in questo caso l’attacco e limitato nel suo
effetto perche un Hello Packet contiene una lista dei vicini
e il nodo malevolo dovra spostarsi in un’altra MANET per
far si che l’attacco vada a buon fine [9]. Quindi l’attaccante
inoltra una RREQ in un’altra area; se i nodi di questa area
hanno informazioni piu recenti il pacchetto viene scartato,
se invece non le hanno viene preso in considerazione e si
da inizio ad un attacco di tipo Denial of Service poiche i
nuovi pacchetti iniettati provocano traffico non necessario
di route discovery [10]. Il nodo puo comportarsi anche di-
versamente, infatti puo sniffare e salvare, per poi replicarlo
in un secondo momento, un messaggio di RERR, poiche
su questi messaggi non viene fatto alcun controllo sulla
‘freschezza’. Come conseguenza di questo attacco, i no-
33
2.3. NEIGHBOR ATTACK
di credono che una route non sia piu valida e potrebbero
consumare risorse per scoprire un ulteriore percorso che,
con alta probabilita, alla fine si rivela esser uguale a quello
che era stato scelto prima dell’attacco. Nel caso di pro-
tocolli proattivi invece esiste un meccanismo esplicito di
link recovery, limitandosi quindi a non annunciare piu il
nodo vicino; questo permette ai protocolli Proactive di di-
fendersi da questo particolare attacco, anche se rimangono
vulnerabili al replay attack con altri pacchetti [9].
2.3 Neighbor Attack
L’attacker ha come obiettivo quello di sconvolgere il rou-
ting e per fare cio fa credere a due nodi, che in realta
non sono connessi e non sono neanche nel range di co-
municazione, di essere connessi direttamente l’un all’altro.
Conseguenza di questa modifica apportata alla rete e ap-
punto quella di far perdere i pacchetti che teoricamente
dovrebbero arrivare a destinazione. Neighbor attack, co-
me si vedra successivamente, e simile al Blackhole attack
nel senso che impedisce la consegna dei pacchetti a destina-
34
2.3. NEIGHBOR ATTACK
zione; pero in questo caso, una volta che viene modificato
il link, non e obbligatorio che il neighbor partecipi atti-
vamente all’operazione di scarto di pacchetti [5]. Affinche
il nodo malevolo riesca a far credere a due nodi di esser
direttamente connessi, si deve trovare tra le due vittime e
mandare i messaggi ricevuti da uno all’altro e viceversa;
i messaggi vengono consegnati senza modifiche, causando
cosı una cattiva percezione della topologia della rete.
Prendendo per esempio una rete con topologia come
quella in Figura 2.3 le due vittime sono V1 e V2 mentre
A e l’attacker; la topologia che i nodi vittima vedranno
subito dopo l’attacco e quella in Figura 2.4.
Infine si puo ottenere un risultato simile anche facendo
credere solamente ad uno dei due nodi di trovarsi vicino ad
un altro, ma non il viceversa. Ovviamente, affinche tutto
cio sia possibile, anche in questo caso il nodo malevolo deve
trovarsi direttamente connesso alla vittima.
35
2.4. BLACKHOLE ATTACK
Figura 2.3: Topologia rete prima di un Neighbor Attack
2.4 Blackhole Attack
Il Blackhole Attack consta di due fasi, nella prima il nodo
malevolo usa i messaggi del protocollo di routing per fare
link spoofing e annunciare se stesso come nodo che gode del
percorso migliore e piu corto per arrivare alla destinazione
che poi sara anche la vittima. Il tutto avviene attraverso
36
2.4. BLACKHOLE ATTACK
Figura 2.4: Topologia rete dopo un Neighbor Attack
l’inserimento nella tabella di routing di una route valida
e piu recente. Una volta che il nodo ostile si e inserito
tra i due nodi che stanno comunicando, puo dar inizio alla
seconda fase dell’attacco passando quindi dall’inoltro allo
scarto dei pacchetti che lo attraversano. Anche se mol-
to remota, data la scarsa disponibilita di risorse, vi e la
37
2.4. BLACKHOLE ATTACK
possibilita che i neighbors attraverso un’accurata analisi
della rete e un monitoraggio del traffico riescano a scopri-
re l’attacker e a denunciarlo. Per cercare di evitare che
cio si verifichi esiste una forma un po piu ingegnosa dello
stesso attacco; questa non consiste nello scartare tutti i
pacchetti, ma solo alcuni di essi oppure modificare i pac-
chetti provenienti da alcuni nodi evitando cosı di destare
sospetti.
Facciamo un semplice esempio esplicativo.
Ipotizzando che nella rete mostrata in Figura 2.5 i nodi
comunicano seguendo le regole del protocollo AODV, con-
sideriamo il nodo A come l’attacker, mentre S e D siano
rispettivamente i nodi sorgente e destinazione. L’attacker
si pone l’obiettivo di far saltare la comunicazione tra S e D.
Come descritto pocanzi, nella prima parte dell’attacco A
cerca di far passare il traffico da esso; per fare cio, quando
S inizia il processo di route discovery, manda immediata-
mente una RREP fasulla, anche se non ha una route per
D; attraverso questo messaggio il nodo malevolo annuncia
che dista un salto da D, ponendo il campo Hop Count ad
1, e modifica il Destination Sequence Number incremen-
38
2.4. BLACKHOLE ATTACK
Figura 2.5: Topologia Blackhole Attack
tandolo di 1 in modo tale da assicurarsi che la sua risposta
venga considerata la piu recente. Cosı facendo accade che
la RREP reale che arriva al nodo X viene scartata poiche
il Destination Sequence Number e inferiore e il numero di
salti per arrivare a destinazione e maggiore. Anche se A e
X dovessero annunciare la stessa distanza, viene scelta la
39
2.5. GRAYHOLE ATTACK
prima route poiche con sequence number maggiore.
2.5 Grayhole Attack
Anche questo attacco consiste in due fasi, nella prima fa-
se, come per il Blackhole Attack, l’attacker, annunciando
una route migliore passante proprio da lui, cerca di farsi
includere nel path che da sorgente arriva a destinazione;
una volta intercettato il traffico proveniente dalla vittima,
l’attacker da inizio alla seconda fase e quindi decide come
trattare il traffico in questione. L’attacker puo:
• Scartare i pacchetti intercettati con una certa pro-
babilita.
• Scartare i pacchetti per intervalli di tempo random.
• Unire i due comportamente elencati sopra.
Grazie al suo modo di operare, un nodo malevolo che
esegue un Grayhole Attack e meno ‘esposto’ rispetto ad
uno che esegue un Blackhole Attack perche in questo caso
non si opera su tutti i pacchetti, ma solo su alcuni ed in
periodi random.
40
2.6. JELLYFISH ATTACK
2.6 Jellyfish Attack
Jellyfish Attack, come i due attacchi precedenti, consta
di due fasi: nella prima anche in questo caso l’attacker,
annuncia una route migliore, facendo si che il traffico passi
da lui per arrivare a destinazione, nella seconda invece
agisce sui pacchetti. Gli obiettivi dell’attacker nel Jellyfish
sono quelli di:
• Aumentare il ritardo end to end dei pacchetti.
• Portare a zero il Goodput cioe la quantita di dati
utili trasferiti per unita di tempo [11].
Continuando con l’analisi del Jellyfish Attack si puo
notare che i meccanismi utilizzati per portarlo a termine
sono piu di uno, quali:
1. Reorder Buffer Attack.
2. Delay Variance Attack.
3. Periodic Dropping Attack.
41
2.6. JELLYFISH ATTACK
Il primo dei tre meccanismi consiste nell’inoltrare tut-
ti i pacchetti ricevuti, ma con ordine diverso da quello
originale; il tutto avviene sfruttando un buffer nel quale
prima vengono accodati i pacchetti per poi inoltrarli; non
rispettando l’ordine FIFO (First In First Out). Il secondo
invece consiste nel trattenere i pacchetti ricevuti per un
periodo random, per poi processarli e inoltrarli incremen-
tando quindi la varianza del ritardo. Per esempio in una
connessione TCP, questo causa che il traffico sia manda-
to in burst, aumentando cosı la possibilita di collisioni e
perdite; viene aumentato anche il valore di RTO (Retra-
smission Time Out), provocando una stima sbagliata della
banda disponibile nei protocolli che si basano sul ritardo
dei pacchetti per il controllo della congestione. Infine il
Periodic Dropping Attack scarta i pacchetti per un perio-
do breve, ogni RTO secondi. Cio causa perdite multiple e
quindi il flusso vittima entra in timeout; quando sta per
uscire, RTO secondi dopo, l’attacker scarta nuovamente
i pacchetti. Affinche tutto cio sia possibile necessita che
l’attacker conosca quando il flusso entra in timeout per
appunto sapere quando effettuare un nuovo scarto.
42
2.7. WORMHOLE ATTACK
E difficile distinguere un attacco di tipo Jellyfish dalla
congestione o dalle perdite di pacchetti che avvengono nor-
malmente nella rete, per cui e molto complicato rivelarvo
[12].
2.7 Wormhole Attack
Fin ora sono stati descritti ed analizzati attacchi nei quali
il nodo malevolo era uno solo, nel caso di Wormhole, uno
degli attacchi piu complicati possibili contro le reti MA-
NET, gli attackers sono due. Infatti il primo dei due, che
si trova in un determinato punto della rete, riceve pac-
chetti per poi mandarli al secondo il quale li inietta nella
zona della rete alla quale esso stesso appartiene. Il tut-
to e possibile solo se si sfrutta il concetto di tunnel, cioe
un link diretto tra i due nodi malevoli. A render ancora
piu dannoso il Wormhole attack contribuisce il fatto che il
tutto puo avvenire anche in presenza di comunicazioni che
comunque riescono a garantire segretezza e autenticita an-
che se gli attackers non possiedono le chiavi di crittografia
[13]. Le modalita utilizzate per stabilire il tunnel sono:
43
2.7. WORMHOLE ATTACK
• Sfruttare l’incapsulamento dei pacchetti per stabilir-
lo a livello logico.
• Attraverso un link cablato.
• Attraverso un out-of-band long-range wireless link.
Un Wormhole tunnel creato usando l’incapsulamento
dei pacchetti e piu lento, pero e facile da stabilire e non
richiede particolari capacita hardware o particolari proto-
colli di routing. Se invece si parla di link cablato o di
out-of-band long-range wireless link e piu semplice fare in
modo che i pacchetti che attraversano il tunnel arrivino
a destinazione con una metrica migliore, poiche, i due at-
tackers si trovano a distanza maggiore di quella che copre
un normale range di trasmissione di un singolo hop [14].
Inoltre per utilizzare un link, cablato o wireless, privato e
garantire alte velocita e richiesto l’utilizzo di un particolare
hardware che permetta appunto ai due nodi di comunicare
tra loro. Grazie a questo attacco gli attackers possono:
- Sniffare il traffico.
- Scartare alcuni o tutti i pacchetti.
44
2.7. WORMHOLE ATTACK
- Effettuare attacchi di tipo ‘Man-in-the-Middle’.
Vediamo quindi alcune modalita, distinguendo il caso
in cui si utilizza un protocollo di tipo reattivo da quello in
cui si utilizza un protocollo proattivo, per la realizzazione
del Wormhole Attack.
2.7.1 Wormhole contro protocolli proattivi
Nei protocolli di tipo Proactive un attacco del genere puo
mirare a colpire la costruzione della topologia, poiche i no-
di scambiano periodicamente pacchetti per fare neighbors
discovery e per raccogliere informazioni sulla topologia.
Analizziamo la Figura 2.6, ipotizzando che il protocollo
utilizzato e l’OLSR e che S e D siano sorgente e destinazio-
ne, mentre A1 e A2 siano i due nodi malevoli. Quando il
nodo S invia un messaggio di HELLO, A1 lo copia e lo in-
via attraverso il tunnel a A2, che a sua volta lo inietta nella
sua zona di rete di appartenenza. Cosı facendo il nodo W
nel momento in cui riceve il pacchetto di HELLO replicato,
crede che S sia un neighbor. Ovviamente la stessa proce-
dura avviene in senso contrario facendo si che S considera
45
2.7. WORMHOLE ATTACK
Figura 2.6: Topologia Wormhole Attack con out-of-band chan-nel
W come vicino; in tal modo si e riusciti a creare tra i due
nodi un false simmetric link. Inoltre il fatto che questo
path sia quello con il minor numero di hops fa si che sia
preferito a tutti gli altri. Concludendo, i due nodi possono
scegliersi a vicenda come MPRs e scambiarsi anche infor-
mazioni in merito alla topologia sfruttando il Wormhole
46
2.7. WORMHOLE ATTACK
Tunnel, divulgando informazioni sbagliate, distruggendo
il routing e degradando le prestazioni dell’intera rete [14].
2.7.2 Wormhole contro protocolli reattivi
Figura 2.7: Topologia Wormhole Attack con packet encapsula-tion
47
2.7. WORMHOLE ATTACK
Metodo del tunnel logico
Come si vede in Figura 2.7, i compiti di incapsulare i pac-
chetti e falsificare la lunghezza del percorso spettano ad A1
e A2. Quando S (sorgente) vuole raggiungere D (destina-
zione) inizia la fase di route discovery. Nel momento in cui
A1 si vede arrivare una RREQ da parte di S, la incapsula
e la invia verso A2 sfruttando il tunnel. A2, vedendosi ar-
rivare una RREQ dal tunnel, la decapsula e la manda a D
mostrando che questa per arrivare a destinazione e passa-
ta da A1 e A2, poiche l’header non viene aggiornato dagli
attackers. Alla fine a destinazione arrivano due RREQ re-
lative allo stesso processo di route iniziato appunto da S:
una da Z con un numero di hops pari a 4, poiche il percor-
so seguito e S-X-Y-Z-D, mentre l’altra inviata da A2 con
un numero di salti pari a 3 poiche il percorso seguito dal
pacchetto e stato S-A1-A2-D. Ovviamente per D il per-
corso migliore e il secondo, e il nodo di destinazione invia
una RREP ad A2, che lo invia attraverso il tunnel ad A1 il
quale lo inoltrera alla sorgente. L’effetto finale e appunto
quello di far credere a S che il percorso migliore sia quello
che passa per A1 e non quello che passa per X. Sfruttando
48
2.7. WORMHOLE ATTACK
la creazione del tunnel gli attackers sono riusciti ad evita-
re che i nodi intermedi e onesti possano incrementare la
metrica associata alla lunghezza della route [15].
Metodo del packet encapsulation
Prendiamo come riferimento la Figura 2.6 e consideriamo
S e D rispettivamente come i nodi sorgente e destinazione,
mentre A1 e A2 come i nodi malevoli. L’attacco ha inizio
quando il nodo S attraverso l’invio in broadcast di una
RREQ inizia la fase di route discovery. Nel momento in
cui il primo dei due attackers A1 si vede arrivare la RREQ,
la inoltra ad A2 senza apportare alcuna modifica; A2 a sua
volta la consegna inalterata al suo neighbor W, il quale
invia il pacchetto, ancora intatto, a D. Dato che la RREQ
in questione arriva a destinazione attraverso un canale ad
alta velocita e quindi e anche la prima a giungere a D
quest’ultimo sceglie la route S-W-D e risponde in unicast.
Alla fine il nodo sorgente sceglie questo percorso ignorando
il fatto che esso contiene anche i nodi A1 e A2 [6].
49
2.8. RUSHING ATTACK
2.8 Rushing Attack
Come scritto nel primo capitolo, esistono protocolli di ti-
po On Deman e protocolli classificabili come Table-Driven;
l’attacco in questione agisce solo contro i protocolli facenti
parte della prima classe, in particolare quelli che riescono
a sopprimere i duplicati durante la fase di route discove-
ry. Un punto a favore del Rushing Attack e dato dalla
difficolta nell’esser scoperto.
Vediamo come avviene l’attacco: ogni nodo, affinche
si possa limitare l’overhead del flooding, inoltra solo una
RREQ per ogni route discovery. Nel momento in cui l’at-
tacker riceve una RREQ, la inoltra velocemente in rete
ancor prima che gli altri nodi che hanno ricevuto lo stes-
so messaggio possano rispondere. Un nodo che riceve il
pacchetto di RREQ leggittimo lo considera come un du-
plicato di quello precedentemente ricevuto dall’attacker e
lo scarta. In tal modo il nodo malevolo e riuscito a farsi
inserire nella route da sorgente a destinazione; inoltre non
sara possibile da parte della sorgente trovare altre route
che non lo contengano [15]. Un attacco del genere non
50
2.8. RUSHING ATTACK
richiede una grande quantita di risorse. In condizioni nor-
mali ne consegue che il forwarding delle RREQ e ritardato,
infatti se a livello MAC si ha time division, i nodi devo-
no aspettare il proprio time slot per trasmettere; oppure,
nel caso in cui non viene specificato il ritardo di MAC; a
livello di routing quando si hanno dei pacchetti di broa-
dcast vengono imposti dei ritardi random poiche grazie
al settaggio di questi e difficile rilevare le collisioni. Da
parte dell’attacker diventa quindi possibile rimuovere que-
sti attacchi per appunto velocizzare l’instradamento. Il
forwarding puo essere velocizzato, rispetto agli altri no-
di, tenendo le interfacce degli altri partecipanti alla rete
impegnate, per esempio mandando false RREQ cosı da
rallentare il processing e il forwarding della RREQ legit-
tima. Inoltre e possibile trasmettere anche i pacchetti di
RREQ lavorando sulla potenza poiche trasmettere ad un
livello di potenza maggiore implica la riduzione del nume-
ro di hop che i messaggi devono attraversare per arrivare
a destinazione [16].
Vediamo un esempio pratico (Fig. 2.8):
S inizia il processo di route discovery per raggiunge-
51
2.8. RUSHING ATTACK
Figura 2.8: Topologia Rushing Attack
re la destinazione D; se la RREQ inoltrata dall’attacker A
raggiunge per prima tutti i nodi vicini alla vittima D, allo-
ra ciascuna route scoperta includera un salto verso il nodo
malevolo. Quando i neighbors della destinazione (N1 e N2)
ricevono la richiesta corrotta la inoltrano senza inoltrare
alcun’altra RREQ, poiche, come descritto sopra, si desi-
52
2.9. SYBIL ATTACK
dera limitare l’overhead. Quando arrivano in un secondo
momento le altre RREQ inoltrate dai nodi non malevoli,
queste verranno scartate. Come risultato di tutto cio si ha
che la sorgente non riuscira a trovare altre route migliori
che non contengano il nodo malevolo.
2.9 Sybil Attack
Affinche l’attacco vada a buon fine il nodo malevolo im-
persona un nodo:
• Fisicamente presente nella rete.
• Del tutto inesistente.
Nel primo caso l’hacker assume le sembianze di un
nodo che e realmente esistente e che realmente appar-
tiene alla rete; cosı facendo il nodo malevolo riesce
ad intercettare i messaggi che sono diretti al nodo
vittima. Usando questo metodo l’attacker non solo
maschera la propria identita, ma, fingendosi il nodo
attaccato, puo decidere come rispondere ai messaggi
di routing o comportarsi in maniera malevola. Nel
53
2.9. SYBIL ATTACK
secondo caso invece, affinche vengono compromessi
i vari servizi della rete, l’attacker impersona uno o
piu nodi.[5] Con questo atteggiamento non solo ven-
gano a saltare i servizi quando appunto e necessaria
la cooperazione tra i nodi della rete, ma si colpisco-
no anche gli schemi di configurazione che si basano
prettamente su un modello di fiducia.
L’attacco di tipo man-in-the-middle per esempio ve-
de l’attacker assumere l’identita di un nodo appar-
tenente alla rete. Questo ha la capacita di legge-
re e modificare i messaggi scambiati tra due nodi;
S e D stanno comunicando tra loro, l’hacker puo
impersonare S nei confronti di D e viceversa [15].
Volendo fare invece un esempio pratico relativo al
caso in cui l’attacker impersona uno o piu nodi ine-
sistenti, come si puo notare in Figura 2.9 X e con-
nesso sia a Y che a Z ma anche al nodo malevolo A.
Nel momento in cui A decide di rappresentare an-
che A1, A2, A3, fa credere a X di avere sei vicini
piuttosto che tre con la conseguenza di aumentare
la possibilita che i vari percorsi all’interno della rete
54
2.10. RESOURSE CONSUMPTION ATTACK
Figura 2.9: Topologia Rushing Attack
contengano l’attacker [8].
2.10 Resourse Consumption Attack
Il fine unico di questo tipo di attacco e appunto quel-
lo di consumare e sprecare le risorse di uno o piu no-
55
2.10. RESOURSE CONSUMPTION ATTACK
di 1; Il Resourse Consumption Attack puo avvenire
attraverso:
- la formulazione di continue richieste per vari
percorsi non necessari
- frequente creazione di pacchetti di beacon
- inoltro di pacchetti vecchi o obsoleti
Affinche la vittima sia continuamente occupata si
puo lavorare sia a livello MAC che a livello di routing
[15].
2.10.1 Routing Table Overflow
Lo scopo dell’attacker nel momento in cui decide di
portare avanti un Routing Table Overflow e quello
di consumare le risorse della memoria dedicate alla
tabella di routing del nodo vittima. In questo caso
vengono create delle route per nodi inesistenti. Il
1per risorse di un nodo si intendono: carica della batteria, bandadisponibile, capacita computazionali che come noto nei devices chefanno parte delle reti MANET sono abbastanza limitate.
56
2.10. RESOURSE CONSUMPTION ATTACK
fine e quindi quello di crearne una quantita tale da
far si che nella routing table non possa esser inserita
nessun’altra entry corrispondente a una route valida
o anche confondere l’algoritmo di routing. [15]
2.10.2 Jamming Attack
Questa tipologia di attacco avviene a livello MAC e
ha come obiettivo quello di interferire con le comu-
nicazioni wireless legittime. Col termine Jammer si
indicano dei disturbi creati intenzionalmente, infatti
in questo caso l’attacker, affinche i nodi che desi-
derano iniziare una comunicazione non trasmettono
nulla poiche vedono il canale occupato, non fa altro
che emettere un segnale radio che rappresenta dei
bit random o dei pacchetti che magari sono costitui-
ti da un header corretto e un payload inutile e quindi
semi-validi. L’invio di questi pacchetti puo avvenire
secondo tre tipologie:
1. constantemente
2. random
57
2.10. RESOURSE CONSUMPTION ATTACK
3. quando ci sono pacchetti in rete
in particolare la terza tipologia fa si che in rete si ven-
ga a creare rumore che disturbando la comunicazione
costringe i nodi a ritrasmettere [17].
2.10.3 Sleep Deprivation Attack
Affinche si possa raggiungere l’obiettivo di consuma-
re le risorse, l’attacker non fa altro che tenere i no-
di constantemente impegnati a processare pacchetti
del tutto inutili. L’idea base e quella di richiedere
un servizio che il nodo offre piu e piu volte in modo
che questo non possa entrare nello stato idle o di po-
wer preserving, deprivando cosı dal ‘sonno’ [5]. Af-
finche il nodo vittima diventi incapace di partecipare
ai meccanismi di routing e conseguentemente diventi
irrangiungibile dagli altri nodi della MANET l’attac-
ker per esempio puo ‘spammare’ il nodo in questio-
ne con messaggi di RREQ piuttosto che di RREP o
di RERR. Alternativamente l’hacker, affinche venga
utilizzata ulteriore banda e vengano consumate le ri-
58
2.10. RESOURSE CONSUMPTION ATTACK
sorse della batteria, puo sempre replicare pacchetti
vecchi reimmettendoli in rete [15].
59
Capitolo 3
Test-bed
Dopo aver descritto ed analizzato le reti MANET ed
i protocolli implementati per far si che i nodi possa-
no dialogare tra di loro e scambiare dati nel miglior
modo possibile, e giunto il momento di descrivere il
Test-bed. Questo capitolo, come gia detto nell’in-
troduzione, descrive come e stato realizzato il Test-
bed e gli strumenti utilizzati per implementare sia gli
attacchi precedentemente descritti, sia una versione
sicura del protocollo OLSR, verra anche presentato
60
3.1. LA RETE MANET
un modo per implementare una prima linea di difesa
nelle reti in questione.
3.1 La rete MANET
3.1.1 Realizzare e configurare una rete ad-
hoc
Nel caso in questione il Test-bed e stato realizzato
attraverso l’utilizzo di 7 laptop (vedi Fig. 3.1, Fig.
3.2). Su ognuno di essi e stato installato il sistema
operativo LINUX ed in particolare la release 10.4
LTE di Ubuntu. Per realizzare una rete ad-hoc, ne-
cessita avere degli adattatori senza fili; pertanto su
ogni calcolatore e stato necessario installare un’op-
portuna scheda di rete Wifi (per le procedure di in-
stallazione basta seguire le istruzioni presenti nel ma-
nuale presente a fine testo). Dopo l’installazione si
e passato alla configurazione della rete; per far cio e
stato creato un opportuno script chiamato ‘test.sh‘
61
3.1. LA RETE MANET
Figura 3.1: Laptop utilizzato
62
3.1. LA RETE MANET
all’interno del quale sono stati inseriti gli opportuni
comandi:
# ifconfig INTERFACCIA down
# service network-manager stop
# iw INTERFACCIA set type ibss
# ifconfig INTERFACCIA INDIRIZZO IP up
# iw INTERFACCIA ibss join test 2412
Questi comandi vengono utilizzati per disabilitare
(vedi seconda riga) il tool di Network Manager poiche
se attivo rivela tutte le reti disponibili e fa si che il
sistema possa autoconfigurarsi [11]; viene quindi im-
postata la modalita ad-hoc, assegnato un indirizzo
ip all’interfaccia (nel nostro caso si sono sfruttati in-
dirizzi di classe A) e riattivato il tutto. I comandi
presenti nell’ultima riga di codice sono stati utiliz-
zati per sintonizzare la schede di rete alla frequenza
63
3.1. LA RETE MANET
2.412 GHz (Banda ISM solitamente usata dalle reti
wireless [11]). Nel caso reale non tutti i nodi sono
direttamente connessi e quindi a causa delle distan-
ze non tutti si trovano in visibilita diretta tra loro;
nel nostro caso invece, dato che comunque tutti i
laptop si trovano nello stesso laboratorio, affinche si
possa riprodurre una situazione realistica si e utiliz-
zato il tool Iptables. Grazie a quest’ultimo e stato
possibile ricreare la topologia piu opportuna e con-
sona alle nostre esigenze e quindi formare i vari link;
facendolo agire a livello MAC e stato possibile impo-
stare lo scarto dei pacchetti provenienti dai nodi che
non si vogliono avere in visibilita (in accordo con la
topologia desiderata).
Per far cio il comando utilizzato e stato:
# iptables -I INPUT -m mac
--mac-source ADDRESS -j DROP
Analizziamolo:
64
3.1. LA RETE MANET
Figura 3.2: Esempio di Topologia
-I INPUT: questa parte del comando serve per in-
dicare che comunque si stanno prendendo in
considerazione solamente i pacchetti in ingres-
so;
-m mac...ADDRESS: indica che si sta lavoran-
do a livello di MAC ed in modo particolare
all’indirizzo ADDRESS;
-j DROP: dopo aver selezionato il traffico sul qua-
le agire, bisogna indicare come operare: in que-
65
3.1. LA RETE MANET
sto caso, dato che si e deciso di ‘Scartare’ dei
pacchetti il comando che si utilizza e appun-
to quello di DROP; in caso contrario avremmo
utilizzato l’ACCEPT.
3.1.2 Protocolli di Routing
Come accennato i test sono stati effettuati sfruttan-
do due tipologie di protocolli, Reactive e Proacti-
ve; per la prima classe di protocolli si e lavorato
con AODV, mentre per la seconda si e sfruttato il
protocollo OLSR.
AODV
Di AODV, come per tutti gli altri protocolli, esistono
varie release; nel Test-bed in questione e stata uti-
lizzata l’implementazione aodv-uu-0.9.5 sviluppata
da Uppsala University. Per installarla e stato neces-
sario digitare i comandi presenti nel manuale; dopo
l’installazione e stato necessario attivarlo su tutte le
macchine utilizzando il comando
66
3.1. LA RETE MANET
# aodv -l -d -D -r SEC
-l : utilizzato per scrivere l’output di questo coman-
do nel file di log: /var/log/aodv.log;
-d : per far girare il protocollo in background;
-D : per non attivare il tempo di attesa come reboot
delay quando il protocollo fallisce;
-r SEC : per salvare nel file di log la tabella di
routing ogni ‘SEC’ secondi.
OLSR
Anche nel caso del protocollo OLSR prima si
e dovuto scaricare il pacchetto per poi instal-
lare il tutto; successivamente, affinche il pro-
tocollo possa partire senza alcun intoppo, so-
no stati settati i parametri presenti nel file di
configurazione olsrd.conf presente nella cartella
root/.../RELEASESCARICATA/etc; in parti-
colare si sono settati:
67
3.1. LA RETE MANET
– Debug
– Ipversion
– Interface
Quando si lavora con questo protocollo, e pos-
sibile anche, utilizzare le opzioni del comando
che fa partire il demone del protocollo, per so-
vrascrivere il file di configurazione precedente-
mente menzionato; tra le principali possiamo
trovare:
-d : debug level indica quante informazioni di
debug si desidera visualizzare in output.
Esso puo assumene un valore compreso tra
0 e 9, dove 0 significa che il protocollo gi-
ra in background; nel nostro caso, come
vedremo successivamente, si e utilizzato il
2.
-i : interface specifica l’interfaccia della scheda
di rete.
-ipv6 : utilizzato per indicare al protocollo che
si deve utilizzare IPv6 e non, come farebbe
di default, IPv4.
68
3.1. LA RETE MANET
-bcast : broadcast address permette di decide-
re quale indirizzo broadcast utilizzare per i
messaggi di controllo.
-hint : seconds utilizzato per settare il valore
di HELLO INTERVAL.
Un attacker potrebbe operare anche attraverso
la modifica di alcuni parametri presenti nel file
di configurazione; egli potrebbe modificare sia
il Willingness (mettendolo per esempio a 7 per
farsi scegliere come MPR quando normalmen-
te e 3) che il HELLO INTERVAL (e mandare
messaggi di Hello molto piu spesso e impegnare
continuamente la vittima).
OLSR e un primo livello di sucurezza
Come gia evidenziato, OLSR e un protocollo
di tipo ‘Table-Drive’ o proattivo e non e capa-
ce di fornire alcun tipo di sicurezza. Il test-
bed in questione e stato realizzato in un primo
momento per studiare e valutare quelle che so-
69
3.1. LA RETE MANET
no le debolezze, dal punto di vista della sicu-
rezza informatica, delle MANET e dei relativi
protocolli; successivamente invece la rete crea-
ta in laboratorio e stata utilizzata per realizza-
re un sistema che la proteggesse dalle minacce
precedentemente implementate.
Il punto di partenza per questa seconda fase
e stato l’installazione di una ‘OLSR plugin Li-
brary’ ; nel caso di OLSR viene definito come
plugin una dinamic linked library (DLL), cioe
un pezzo di codice eseguibile che contiene fun-
zioni e dati. Le DLLs di solito sono librerie
o funzioni condivise da piu processi e vengono
utilizzate per aggiungere un’interfaccia tra il de-
mone del protocollo e altre applicazioni. Grazie
all’utilizzo dei plugins e possibile ottenere servi-
zi di Network come il DNS, ma questi possono
anche contribuire ad ottimizzare per esempio
le funzionalita dei nodi MPR, riducendo cosı il
carico di rete. E stato utilizzato come punto
di partenza un plugin perche grazie ad esso e
70
3.1. LA RETE MANET
stato possibile aggiungere una nuova funziona-
lita senza alterare quelle gia presenti; inoltre,
essendo scritto in linguaggio ‘C’, utilizzabile e
compatibile con l’ambiente linux, e stato anche
possibile, come si vedra nel capitolo successivo,
apportare delle modifiche utili per rendere il piu
possibile sicuro OLSR.
Il plugin utilizzato e olsrd secure.so.0.5, dove
‘0.5’ indica che e stato implementato per una
specifica versione ‘0.5.6’ del protocollo OLSR
mentre ‘.so’ e l’estensione tipica dei plugins [18].
Prima di installare il plugin e stato necessario
installare la release olsrd-0.5.6; dato che po-
trebbe esser stata installata nelle varie macchi-
ne una versione differente del medesimo proto-
collo, e ragionevole effettuare un’operazione di
cleaner attraverso i comandi
# make clean && make && make install
successivamente si e passati all’installazione del
plugin, per far cio e bastato digitare
71
3.1. LA RETE MANET
# cd /olsrd-0.5.6/lib/secure
# make && make install
A differenza di OLSR (per il quale era possibile
settare i parametri anche attraverso opportuni
comandi), utilizzabili quando si fa partire il de-
mone del protocollo, in questo caso si e dovuto
editare direttamente il file di configurazione ‘ol-
sr.conf’; in particolare, oltre a settare interfac-
cia, level debug ed altri parametri per attivare
e far si che il protocollo potesse riconoscere il
plugin, e stato necessario aggiungere in fondo
al file le seguenti righe:
LoadPlugin ‘olsrd secure.so.0.5’ {PlParam ‘keyfile’ ‘/etc/olsrd.d/olsrd secure key’
}
Leggendo le poche righe da aggiungere al file
e facile imbattersi nella parola ‘Key’: infatti e
richiesto il settaggio di una chiave.
72
3.1. LA RETE MANET
Nei capitoli precedenti, in particolare nel secon-
do dove sono stati descritti i vari attacchi, si e
detto che un attacker solitamente e un nodo
che non ha alcun interesse nel partecipare alla
MANET se non quello di recare danni; detto
cio e facile intuire che una prima linea di dife-
sa puo essere implementata limitando l’accesso
alla rete ad alcuni host; gli sviluppatori del plu-
gin sono riusciti a far cio imponendo l’utilizzo
di una chiave da parte di tutti i nodi che de-
siderano partecipare alle operazioni, di routing
o di scambio dati, tipiche delle MANET. Nel
test-bed ogni nodo e stato dotato di una chiave
preinstallata di 128 bit. Nel momento in cui,
attraverso la digitazione del comando
# olsrd -d 2
viene fatto partire il demone del protocollo OL-
SR, viene verificata la disponibilita da parte del
nodo di una chiave che abbia la lunghezza ri-
chiesta. Inoltre, utilizzando questo plugin che a
sua volta utilizza la crittografia simmetrica, gli
73
3.1. LA RETE MANET
sviluppatori hanno fatto si che nella rete venga
garantita l’integrita dei dati. La conferma di
quanto detto e il fatto che un nodo che non ha
accesso alla chiave condivisa non puo produrre
un ‘digest’ verificabile e non puo quindi entrare
a far parte della rete.
Figura 3.3: Struttura messaggio con firma OLSR
Concludendo possiamo dire che questa ‘Secure
extension to the OLSR protocol’ [19] prevede
l’utilizzo di una chiave condivisa per creare una
prima linea di difesa attraverso la creazione e
la verifica della firma partendo dal presupposto
che solo i nodi onesti possano accedere alla rete.
In Figura 3.3 e possibile osservare la struttura
74
3.1. LA RETE MANET
del messaggio contenente la firma.
3.1.3 Sniffing del traffico
Per effettuare lo sniffing del traffico, per poi
estrarre le informazioni utili per la detection
di alcuni attacchi, e stata utilizzata la libre-
ria Libpcap-1.1.1 anche essa, come il plugin
precedente presentato, scritta in C.
Affinche il suo utilizzo sia stato possibile e stato
necessario come prima cosa specificare per poi
configurare l’interfaccia di rete da usare:
pcap_t *handle;
handle = pcap_open_live
(dev, BUFSIZ, 1, 1000, errbuf);
if (handle == NULL) {
fprintf( stderr,
"Couldn’t open device %s: %s\n",
dev, errbuf);
return(2);}
75
3.1. LA RETE MANET
Attraverso la funzione ‘pcap open live( )’ e
stato possibile quindi:
– settare l’interfaccia per la cattura
– settare il numero massimo di bytes da cat-
turare
– indicare il timeout prima che l’operazione
di lettura finisca
– settare le dimensioni di un buffer che viene
utilizzato in caso di messaggi di errore
Dato che di default vengono catturati tutti i
pacchetti, indistintamente dalla loro provenien-
za o dalla loro tipologia, affinche non si consu-
mino troppe risorse e stato creato un filtro at-
traverso l’utilizzo delle funzioni di ‘pcap compile(
)’ e ‘pcap setfilter( )’
struct bpf_program fp;
char filter_exp[] =
"ip src host ADDR && udp port PORT";
76
3.1. LA RETE MANET
bpf_u_int32 mask;
bpf_u_int32 net;
if (pcap_lookupnet
(dev, &net, &mask, errbuf) == -1) {
fprintf(stderr,
"Can’t get netmask for device %s\n", dev);
net = 0;
mask = 0;}
if (pcap_compile
(handle, &fp, filter_exp, 0, net) == -1) {
fprintf(stderr,
"Couldn’t parse filter %s: %s\n",filter_exp,
pcap_geterr(handle));
return(2);}
if (pcap_setfilter
(handle, &fp) == -1) {
fprintf(stderr,
"Couldn’t install filter %s: %s\n",
77
3.1. LA RETE MANET
filter_exp, pcap_geterr(handle));
return(2);}
Nel codice, ‘bpf’ (berkeley packet filter) indica
appunto il filtro, ADDR indica l’indirizzo del-
la sorgente dei pacchetti, mentre con PORT e
stato identificato l’indirizzo di porta dal quale
arriva il traffico (nel caso OLSR e 698).
La particolarita di Libpcap e appunto quella di
fornire diverse opzioni per la cattura del traffi-
co. Nel test-bed sono state utilizzate anche le
funzioni:
- pcap next();
- pcap loop();
La prima delle due e stata utilizzata, nella fase
di detection del Replay Attack, per catturare i
pacchetti singolarmente, la seconda invece per
analizzare il contenuto dei pacchetti sniffati e
verificare se essi erano unici oppure sono delle
repliche. Il codice che corrisponde alla prima
operazione e il seguente:
78
3.1. LA RETE MANET
packet=pcap_next(handle, &header);
pcap_sendpacket(handle,packet,header.len);
per la seconda operazione e invece questo:
if (pcap_loop(handle,-1,
process_packet,NULL)==-1){
fprintf (stderr,"%s",
pcap_geterr(handle));
exit (1);
}
Affinche la cattura dei pacchetti desiderati ab-
bia buon esito e stato necessario anche definire
le strutture degli header.
/* OLSR header */
struct sniff_olsr {
u_int16_t pkt_len ;
u_int16_t pkt_seqno ;
};
79
3.1. LA RETE MANET
/* OLSR message header */
struct sniff_msg_header {
u_int8_t msg_type ;
u_int8_t vtime ;
u_int16_t msg_size ;
struct in_addr orig_addr ;
u_int8_t ttl;
u_int8_t hcount ;
u_int16_t msg_seqno ;
};
Infine, come si puo vedere piu in dettaglio nel
manuale (Appendice A), per individuare l’ini-
zio del pacchetto e stato utilizzato il seguente
codice:
ethernet = (struct sniff_ethernet*)(packet);
ip = (struct sniff_ip*)(packet + SIZE_ETHERNET);
size_ip = IP_HL(ip)*4;
udp = (struct sniff_udp*)(packet
+ SIZE_ETHERNET + size_ip);
80
3.1. LA RETE MANET
mentre per individuare solamente un parametro
dell’header (nel nostro caso il Sequence Num-
ber del generico pacchetto sniffato) sono state
impiegate le seguenti righe di codice:
olsr = (struct sniff_olsr*)(packet +
SIZE_ETHERNET + size_ip + size_udp);
81
Capitolo 4
Implementazione
Dopo aver descritto, nel capitolo precedente, la
realizzazione del Test-bed e di una prima linea
di difesa usando un opportuno plugin passia-
mo a descrivere come e stata implementata una
versione sicura del PROACTIVE PROTOCOL
OLSR.
In questo capitolo verranno descritti per ogni
tipologia di attacco quelle che sono appunto le
rispettive linee di difesa. Bisogna tener pre-
82
4.1. REPLAY ATTACK
sente che le varie contromisure sono state im-
plementate partendo dall’analisi del comporta-
mento che ha il nodo malevolo in ogni singolo
attacco.
4.1 Replay Attack
In un attacco di tipo Replay l’attacker prima
sniffa il traffico e successivamente decide quali
pacchetti replicare, il tutto viene compiuto gra-
zie all’utilizzo di opportune librerie come per
esempio la Libpcap.
La detection di questo attacco e stata aggiunta
al protocollo grazie all’installazione del plugin
olsr secure.so.0.5. Gli implementatori sono riu-
sciti a far cio attuando una nuova strategia, di
solito tutti i protocolli che fanno le detection
di questo attacco partono dal presupposto che
se ad un nodo arrivano due pacchetti con lo
stesso Sequence Number, allora uno e la replica
dell’altro e quindi sta avvenendo un Replay At-
83
4.1. REPLAY ATTACK
tack. Tuttavia nel protocollo OLSR il numero
di sequenza e un parametro ‘debole’ (solamente
16-bit) e un attacker puo prendere un pacchetto
replicarlo e iniettarlo in una nuova rete portan-
do ugualmente l’attacco a termine. Per evita-
re cio nei pacchetti e stato aggiunto un nuovo
parametro, il Timestamp.
Figura 4.1: Struttura messaggio con firma OLSR
Vediamo quindi come avviene lo scambio del
timestamp e come viene fatta la detection.
Il timestamp viene calcolato in maniera del tut-
to implicita ogni volta che un nodo entra a far
parte delle rete e quindi subito dopo aver su-
84
4.1. REPLAY ATTACK
perato la prima linea di difesa; il tutto avviene
attraverso lo scambio di tre appositi messaggi:
– Challenge.
– Challenge - Response.
– Response - Response.
Le figure 4.2, 4.3, 4.4 rappresentano le rispettive
strutture dei messaggi sovraelencati.
Figura 4.2: Struttura messaggio Challenge
Considerando due nodi A e B, che fanno parte
della stessa rete e che si vedono per la prima
volta, lo scambio avviene come segue:
A → B : Cha D(IPb,M,K)
B → A: Chb Tsb D(IPb,CHa,K)D(M,K)
85
4.1. REPLAY ATTACK
Figura 4.3: Struttura messaggio Challenge - Response
A → B : Tsa D(IPa,CHb,K)D(M,K) .
Quando A riceve, per la prima volta, un mes-
saggio firmato da un vicino B non ha alcun va-
lore temporale registrato, A inizia il processo di
scambio del TIMESTAMP.
- A invia un messaggio di CHALLENGE a
B. Il messaggio contiene l’indirizzo IP di B
e un nonce, Cha, di 32 bit random (numero
usato una volta). Questo e un numero ca-
suale, che viene utilizzato per accodare dati
casuali a dati reali per prevenire un attacco
86
4.1. REPLAY ATTACK
Figura 4.4: Struttura messaggio Response - Response
di replay. A poi ‘firma’ il messaggio con un
digest di tutto il messaggio e usando la key
condivisa D(M, K)
- B risponde a questo messaggio con un mes-
saggio CHALLENGERESPONSE. B pri-
ma genera il digest del suo IP address, del
nonce ricevuto e della chiave condivisa D
(IPB, cha, K), quindi genera un nonce a
32 bit e trasmette ad A, il nonce, il time-
stamp di B, il digest D (IPb, CHa, K) e
un riassunto di tutto il messaggio e la key
condivisa D(M, K).
87
4.1. REPLAY ATTACK
- Quando A riceve il messaggio di CHAL-
LENGERESPONSE da B, cerca prima
di convalidare i dati. Se il digest D(IPb,
CHa, K) e D(M, K) possono essere verifica-
ti, allora il timestamp di B e utilizzato per
creare la differenza di tempo tra A e B. A
allora genera un messaggio di RESPONSE-
RESPONSE e lo trasmette a B. Questo mes-
saggio contiene l’indirizzo IP del ricevito-
re(B), un timestamp, il nonce ricevuto da
B, la chiave condivisa D(M, K) e un digest
del messaggio e l’intera key D(M, K).
- Quando B riceve il messaggio da A, si veri-
fica il digest. Se la convalida avviene allora
B usa il timestamp ricevuto per registrare
la sua differenza di tempo ad A.
E lo scambio del timestamp e completo.
Una volta che i due nodi hanno scambiato le in-
formazioni in merito al timestamp si puo passa-
re alla detection; Considerando Tsender (Ts)
il timestamp, valore univoco, messo dal sender
88
4.1. REPLAY ATTACK
nel messaggio e T il valore del clock del nodo
ricevente, per ogni coppia di nodi si fissa un
valore delta che indica la discrepanza del time-
stamp tra i clock dei due nodi. Se il modulo
della differenza tra Ts e T e maggiore o uguale
di delta vuol dire che il pacchetto e replicato e
viene scartato.
|Ts− T | < δ
La conferma del fatto che il Replay Attack non
va a buon fine si ha anche da un algoritmo appo-
sitamente implementato sfruttando la libreria
Libpcap (vedi Fig. 4.5).
/* Sniffo due pacchetti */
packet1 = pcap_next( handle, &header);
packet2 = pcap_next( handle, &header);
/* Confronto i pacchetti */
89
4.2. DROP ATTACK
if(packet1 == packet2){
printf("‘Pacchetto gia
presente nella rete\n"’);
}
if(packet1 != packet2){
printf("‘Diversi!\n"’);
}
Figura 4.5: Output script VsReplayAttack
4.2 Drop Attack
L’obiettivo di questo attacco e quello di creare
confusione nel Routing e nella rete. Il tutto con-
90
4.2. DROP ATTACK
sta nello scarto di alcuni pacchetti attraverso
comandi come
# iptables -I FORWARD -j DROP -s SOURCE
che a sua volta sfrutta il tool iptables.
Per fare detection e stato modificato il codice
sorgente del protocollo, riadattandolo alle no-
stre esigenze riuscendo quindi ad analizzare i
parametri di nostro interesse dei messaggi che
arrivano a destinazione. Come noto che nel
protocollo OLSR le informazioni sulla topolo-
gia vengono scambiate grazie ai messaggi di TC
(Topology Control); nell’attacco in questione
la detection viene fatta partendo da un’analisi
dei Sequence Number di questi messaggi, con-
siderando una topologia come quella in Figura
4.6:
i TCSeqno che arrivano a destinazione sono al-
ternati tra quelli di A e quelli di S, quindi nel
momento in cui l’attacco va a buon fine e ‘sal-
ta’ il link, a destinazione arrivano solamente i
91
4.2. DROP ATTACK
Figura 4.6: Topologia Drop Attack
pacchetti di A. Come si puo vedere in Figura
4.7, dopo l’attacco si avranno solo i TCSeqno
di A, ovviamente tutti consecutivi. Sfruttando
questo concetto si e riusciti a fare detection e
nel momento in cui il protocollo si rende conto
che qualcosa non va viene stampato un apposito
messaggio (vedi Fig. 4.8).
Volendo analizzare il codice aggiunto possiamo
dire che sono state utilizzate le funzioni
92
4.2. DROP ATTACK
Figura 4.7: Detection Drop Attack
– fopen( );
– fprintf( );
– fscanf( );
– fclose( );
previste dal linguaggio C per la gestione dei file.
fp_mio_file = fopen ("‘/home/tc4200/
Scrivania/TC.txt"’, "‘a+"’);
93
4.2. DROP ATTACK
Figura 4.8: Output Detection Drop Attack
if(fp_mio_file == NULL){
printf("‘File vuoto\n"’);
}
fprintf(fp_mio_file, "‘%d\n"’, seqno);
fclose(fp_mio_file);}
94
4.3. NEIGHBOR ATTACK
static int dropattackdetection(){
int i, j, max, min, differenza;
int valori [100000];
....
....
fp_mio_file = fopen ("‘/home/tc4200/
Scrivania/TC.txt"’, "‘r"’);
if(fp_mio_file == NULL){
perror("‘Errore\n"’);
}
...
4.3 Neighbor Attack
L’obiettivo dell’attacker e quello di ‘sconvolge-
re’ il routing facendo credere a due nodi, che in
realta non sono connessi tra loro, di poter comu-
95
4.3. NEIGHBOR ATTACK
nicare direttamente. In OLSR i nodi conosco-
no la topologia ancor prima di iniziare una co-
municazione, quindi affinche i due nodi vittima
possano credere di poter direttamente comuni-
care bisogna mandare periodicamente messaggi
di HELLO. L’attacco consta di due operazio-
ni, sniffing di pacchetti prima ed invio di Hello
packet opportunamente modificati dopo.
Per la detection si e partiti dal presupposto che
a destinazione arrivano pacchetti falsi e corrotti
quindi e stato prima di tutto necessario valutare
la loro correttezza; al setaccio sono stati passati:
– Message Type
– Message size
– TTL
– HopCnt
Fondamentalmente tutti i nodi durante il ten-
tativo di attacco continuano ad avere salvata
al loro interno la topologia corretta della rete;
la destinazione quindi si vede arrivare pacchet-
ti con parametri tipici di un nodo direttamen-
96
4.3. NEIGHBOR ATTACK
te connesso anche se sa benissimo che non e
cosı. L’attacker genera false packet sia per ‘Si-
ze’, poiche privi di firma, che per ‘HopCnt’. Il
codice utilizzato e stato il seguente:
if((sig -> olsr_msgtype != MESSAGE_TYPE) ||
(sig -> olsr_msg_size != ntohs(sizeof
(struct s_olsrmsg))) || (sig -> ttl !=1) ||
(sig -> hopcnt !=0)){
olsr_printf(1, "‘ATTACCO -->
Packet not sane!\n"’);
return 0;
}
Conferma alla detection si ha dall’output emes-
so a destinazione ogni volta che si verifica un’a-
nomalia (vedi Fig. 4.9).
Inoltre e possibile far si che dopo la detection
vengano riattivate le procedure utilizzate ad ini-
zio connessione o quando un nodo entra a far
parte della rete.
97
4.4. SYBIL ATTACK
Figura 4.9: Output Detection Neighbor Attack
4.4 Sybil Attack
Il nodo malevolo pur di compromettere i servi-
zi della rete impersona un altro nodo del tut-
to inesistente (vedi Fig. 4.10, 4.11); in OLSR
vengono emessi messaggi di HELLO e TC ri-
spettivamente ogni HELLO INTERVAL e ogni
TC INTERVAL costruiti in maniera del tutto
fittizia.
98
4.4. SYBIL ATTACK
Figura 4.10: Sybil Mode On
La detection (vedi Fig. 4.12) per questo attac-
co e stata implementata in un duplice modo;
infatti questa volta oltre ad analizzare i para-
metri dell’header vengono valutate le condizio-
ni sui pacchetti prendendo in considerazione il
relativo subheader; grazie a cio e stato facile
capire se si stanno cercando di apportare mo-
difiche alla topologia attraverso l’annuncio di
vicini inesistenti.
99
4.4. SYBIL ATTACK
Figura 4.11: Traffico Sniffato con Wireshark durante un SybilAttack
switch ( sig -> sig.type){
case (ONE_CHECKSUM);
switch (sig -> sig.algorithm) {
case (SCHEME);
goto one_checksum_SHA;
break;
}
100
4.5. BLACKHOLE, GRAYHOLE E JELLYFISH
break;
default:
olsr_printf(1, "‘TENTATIVO DI
MODIFICA TOPOLOGIA!\n"’);
return 0;
}
Mentre avviene la validazione dei pacchetti ci
si puo accorgere che comunque si e sotto at-
tacco perche questi hanno dimensione diversa
da quella prevista dal protocollo a causa della
mancanza della firma e del timestamp, para-
metri non presenti poiche il nodo e inesistente
e ogni valore di timestamp e univoco per ogni
coppia di nodi.
4.5 Blackhole, Grayhole e Jel-
lyfish
Per la detection (vedi Fig.4.13) in questo caso e
stato necessario valutare il comportamento e le
101
4.5. BLACKHOLE, GRAYHOLE E JELLYFISH
Figura 4.12: Output Detection Sybil Attack
mosse che compie l’attacker affinche il suo obiet-
tivo venga raggiunto. Nel capitolo due e stato
evidenziato che questi tre attacchi constano di
una duplice fase, la prima, praticamente ugua-
le, e quella in cui l’attacker cerca di far si che
il traffico passi da esso, mentre la seconda varia
da attacco ad attacco. Infatti nel BLACKHO-
LE, piuttosto che inoltrare pacchetti, l’attac-
ker li scarta, mentre nel GRAYHOLE il nodo
102
4.5. BLACKHOLE, GRAYHOLE E JELLYFISH
malevolo puo scartare i pacchetti che arrivano
sia con una certa probabilita, sia ad interval-
li random; infine nel JELLYFISH si opera sui
pacchetti per aumentare il ritardo end-to-end o
portare a zero il goodput.
Per questi tre attacchi la detection e stata im-
plementata in un duplice modo. Valutiamo la
prima parte degli attacchi; il nodo malevolo, per
far credere agli altri nodi della rete, che lui ha il
percorso migliore, genera ed invia pacchetti non
sani o corrotti; poiche ogni nodo, come previ-
sto dalle regole del protocollo OLSR, mantiene
salvato al suo interno la routing table corretta,
e bastata l’analisi dell’header dei pacchetti per
rendersi conto che vi e qualche anomalia.
if((sig -> olsr_msgtype != MESSAGE_TYPE)
&& (sig -> olsr_msg_size != ntohs(sizeof
(struct s_olsrmsg))) && (sig ->ttl !=1)){
olsr_printf(1, "‘ATTENZIONE
PROBLEMI DI TIPOLOGIA, DIMENSIONE e
TTL --> BLACKHOLE/GRAYHOLE/JELLYFISH!\n"’);
103
4.5. BLACKHOLE, GRAYHOLE E JELLYFISH
sleep(2);
return 0;
}
E stato implementato anche un secondo con-
trollo, che ha senso nel momento in cui il no-
do malevolo riesce in un modo o in un altro a
generare ed inviare pacchetti sani e validi. Il
tutto nasce come conseguenza del fatto che ini-
zialmente l’attacker, pur di far passare da esso il
traffico, invia pacchetti corrotti con il fine unico
di modificare la topologia della rete. Per cerca-
re di render il piu sicuro possibile il protocollo
OLSR si e implementato un ulteriore controllo
del traffico ed in particolare i controlli sono sta-
ti fatti sui parametri dei pacchetti contenenti i
messaggi di TOPOLOGY CONTROL
switch ( sig -> sig.type){
...
104
4.5. BLACKHOLE, GRAYHOLE E JELLYFISH
switch (sig -> sig.algorithm) {
case (SCHEME);
goto one_checksum_SHA;
break;
}
...
return 0;
}
Analizzando il codice e facile intuire che viene
prima valutata la ‘signature’ e poi lo ‘scheme’
ed e proprio quest’ultimo che viene corrotto nel
momento in cui si desidera modificare la topolo-
gia. Dopo che la detection e andata a buon fine,
la tabella di routing rimane inalterata ma grazie
al ‘return 0;’ vengono rispediti tutti i messaggi
di challenge affinche si instauri nuovamente un
rapporto di fiducia tra i neighbors. Volendo si
poteva utilizzare un ‘exit(0);’ ed isolare il nodo
vittima affinche potessero essere fatti tutti gli
105
4.6. WORMHOLE
accertamenti del caso.
Figura 4.13: Output Detection
4.6 Wormhole
Dato che il principio base di questo attacco e la
collaborazione dei due attackers, i quali attra-
verso l’utilizzo di un tunnel riescono a falsifica-
re la lunghezza del percorso, e stato possibile
implementare una contromisura semplicemen-
106
4.6. WORMHOLE
Figura 4.14: Figura Topologia Wormhole
te installando il plugin e sfruttando, come nel
caso di attacco Replay, il valore di timestamp;
infatti, nel momento in cui un pacchetto viene
portato a destinazione da A2 (vedi Fig 4.14),
non viene modificato alcun valore nell’header
proprio e questo ha contribuito a trovare una
soluzione al problema. Quando due nodi si ve-
dono per la prima volta attraverso lo scambio di
opportuni messaggi viene calcolata la δ, che in-
107
4.7. DISCUSSIONE DEI RISULTATI E CONFRONTOCON LO STATO DELL’ARTE
dica la discrepanza del timestamp tra i clock dei
due nodi; il fatto che a destinazione arriva un
pacchetto da parte di una determinata sorgen-
te ed il valore della δ attuale non corrisponde
con quello salvato in memoria fa si che scatti
la detection facendo entrare il protocollo in uno
stato di allerta. A schermo viene stampato un
opportuno messaggio di ALARM ATTACK.
4.7 Discussione dei risultati e
confronto con lo stato dell’arte
Dopo aver installato su tutte le macchine OLSR
0.5.6 e fatto partire il plugin, si e passati alla
valutazione del livello di sicurezza che quest’ul-
timo riesce a garantire. I risultati sono stati
quelli che gli unici attacchi che non sono an-
dati a buon fine sono stati appunto quelli di
tipo Replay e Wormhole poiche la destinazione
si rendeva conto che, nonostante la ‘correttez-
za’ dei pacchetti, i valori del timestamp erano
108
4.7. DISCUSSIONE DEI RISULTATI E CONFRONTOCON LO STATO DELL’ARTE
in discrepanza rispetto a quelli calcolati e me-
morizzati dai vari nodi nel momento in cui e
avvenuta la prima connessione. Partendo dallo
studio dei vari attacchi e apportando opportu-
ne modifiche ai source code del protocollo e del
plugin, si e riusciti a trovare almeno un modo
per la detection di tutti gli altri attacchi.
Nel Drop Attack il protocollo e stato modifica-
to in maniera tale da poter ricavare e salvare
su file, i Sequence Number dei TC messages;
per quanto riguarda l’attacco di tipo Neighbor
il sistema di detection e stato implementato in
seguito allo studio dei valori che vengono mo-
dificati per creare nuovi pacchetti; infatti, a se-
conda del ‘MESSAGE TYPE’, il pacchetto si
e dimostrato corrotto per particolari valori dei
parametri. Nel caso di Sybil Attack il tutto e
stato implementato in maniera abbastanza sem-
plice perche, dato che l’attacker cerca di imper-
sonare un nodo inesistente, questo non fa altro
che inviare messaggi non criptati ed inoltre cer-
109
4.7. DISCUSSIONE DEI RISULTATI E CONFRONTOCON LO STATO DELL’ARTE
ca di apportare modifiche alla topologia della
rete. Per quanto riguarda invece gli attacchi di
tipo Blackhole, Grayhole e Jellyfish, la linea che
si e seguita e stata quella di sfruttare al massimo
le debolezze che presentano questi tre attacchi
nella prima parte, che e uguale per tutti; infatti
grazie ad un duplice controllo sui parametri del-
l’header e del subhearder dei pacchetti e stato
possibile non solo sventare questi attacchi, ma
nello stesso tempo anche evitare di appesantire
il protocollo mantenendolo il piu snello possibile
poiche utilizzare tre detection differenti impli-
cava un aumento del carico computazionale su
ogni macchina portando quindi ad un eccessivo
spreco di risorse.
La tabella in Figura 4.15 riassume lo stato del-
l’arte e permette di confrontare le precedenti
versioni sicure di OLSR [20][21][22][23] con la
nostra.
110
4.7. DISCUSSIONE DEI RISULTATI E CONFRONTOCON LO STATO DELL’ARTE
Figura 4.15: Tabella Riassuntiva
111
Capitolo 5
Sicurezza AODV
In questo capitolo ci si propone di analizzare
i vari attacchi alle reti MANET che utilizzano
l’AODV protocol, per trovare, attraverso una
serie di valutazioni teoriche, quelle che potreb-
bero essere delle soluzioni da implementare per
garantire come nel caso di OLSR un maggior
livello di sicurezza.
112
5.1. MESSAGGI SCAMBIATI
5.1 Messaggi scambiati
Il protocollo AODV, essendo di tipo reattivo,
non prevede il salvataggio da parte di ogni sin-
golo nodo delle routes esistenti nella rete e, di
conseguenza non e previsto neanche il salvatag-
gio delle routing tables. Ogni volta che un nodo
desidera scambiare informazioni o comunque of-
fre connettivita entrando a far parte, in maniera
attiva della rete, non fa altro che comunicare la
sua presenza in modo tale che gli altri nodi pos-
sano calcolare la route migliore per arrivare ad
esso.
Prima di passare alla descrizione di come sia
possibile implementare una versione del proto-
collo capace di difendersi e fare detection dei va-
ri attacchi, analizziamo velocemente i messag-
gi scambiati; essi sono RREQ, RREP e RRER
vengono scambiati anche messaggi di tipo HEL-
LO. Vediamo quindi la loro utilita e come sono
settati i parametri che li costituiscono:
113
5.1. MESSAGGI SCAMBIATI
RREQ
Questo messaggio viene mandato da un nodo
nel momento in cui questo desidera raggiungere
una determinata destinazione per la quale non
ha alcuna ROUTE.
Il parametri vengono settati nel seguente modo:
DEST. SEQUENCE NUMBER=0; Se non
si conosce quello della destinazione altri-
menti si setta uguale all’ultimo ‘Seqno’ co-
nosciuto per quella destinazione
RREQ ID=x; con ‘x’ numero intero che vie-
ne incrementato ogni volta che viene man-
data una richiesta
HOPCOUNT= 0;
RREP
Questo messaggio viene inviato come risposta
ad una richiesta precedentemente inoltrata. Ov-
viamente e la destinazione che manda questo
tipo di messaggio.
RRER
114
5.1. MESSAGGI SCAMBIATI
Messaggio mandato in caso di errori o anomalie
varie come nel caso in cui dovesse cadere un
link.
HELLO
Pacchetto che viene periodicamente mandato,
da un nodo ai neighbor, per indicare la propria
disponibilita a connettersi. Esso non e altro che
un RREP con i parametri settati nel seguente
modo:
TTL=1;
DESTINATION ADDRESS = id di chi ri-
ceve il messaggio;
ORIGINATOR ADDRESS = id di chi ge-
nera il messaggio;
HOP COUNT=0;
LIFETIME= tempo dopo il quale se non si
riceve un nuovo HELLO il link si considera
perso.
115
5.2. ATTACCHI
5.2 Attacchi
5.2.1 Replay
Questo tipo di attacco consiste nel replicare i
pacchetti che arrivano all’attacker e che sono
destinati a qualsiasi altro nodo della rete. I pac-
chetti di tipo RREQ hanno un parametro che li
rappresenta in maniera univoca, esso e l’ID un
primo controllo lo si puo fare considerando la
coppia di parametri RREQ ID, ORIGINA-
TOR IP ADDRESS; infatti, se a destinazio-
ne ci si rende conto che un nodo con un deter-
minato IP ha emesso due RREQ con lo stesso
ID, vuol dire che il pacchetto e appunto repli-
cato; inoltre si puo fare un controllo anche su
tutti i pacchetti RREP, poiche essendo contrad-
distinti dalla presenza di un sequence number e
facile intuire che se esistono due pacchetti con
lo stesso numero di sequenza uno dei due e una
replica.
In generale, si puo vedere attraverso ‘WIRE-
116
5.2. ATTACCHI
SHARK’ che a destinazione un eventuale pac-
chetto replicato arriva subito dopo il pacchet-
to originale, ragion per cui si puo adottare la
stessa tecnica utilizzata per fare detection nel
protocollo OLSR. Infatti utilizzando la libreria
‘Libpcap’ si puo creare un filtro e sniffare il
traffico in maniera tale da analizzare gli hea-
der dei vari pacchetti e vedere se questi sono
replicati o meno.
char filter_exp[] = "ip src host
10.0.0.8 && udp port 698";
bpf_u_int32 mask;
...
if (pcap_lookupnet(dev, &net,
&mask, errbuf) == -1) {
fprintf(stderr, "Can’t get netmask
for device %s\n", dev);
net = 0;
mask = 0;
117
5.2. ATTACCHI
}
....
....
if (pcap_setfilter(handle, &fp) == -1) {
fprintf(stderr, "Couldn’t
install filter %s: %s\n",
filter_exp, pcap_geterr(handle));
return(2);
}
while(1){
packet1 = pcap_next(handle, &header);
packet2 = pcap_next(handle, &header);
/*Confronto*/
if(packet1==packet2){
printf ("Uguali!\n");
}
118
5.2. ATTACCHI
if(packet1!=packet2){
printf ("Diversi!\n");
}
}
/* Cleaning up */
pcap_freecode(&fp);
pcap_close(handle);
5.2.2 Drop
Figura 5.1: Topologia Drop Attack
Come noto, nel momento in cui avviene la con-
nessione (vedi Fig. 5.1) sia il nodo X che il nodo
119
5.2. ATTACCHI
Y sanno che per dialogare l’uno con l’altro de-
vono comunque inviare i pacchetti ad A che a
sua volta li consegnera al nodo di destinazione.
L’attacco consiste nel far saltare il link che pas-
sa per A (attacker) e che collega sorgente e
destinazione. Dato che se l’attacker applica la
regola
# iptables -I FORWARD -j drop -s 10.0.0.8
questa fa si che i pacchetti di X non arrivano a
destinazione un’ipotetica soluzione per fare de-
tection potrebbe esser appunto quella di inter-
rogare ogni τs sec la destinazione per accertarsi
che comunque il link e attivo. Si puo pensare di
fare questa operazione in vari modi, tra questi:
– Invio di una nuova RREQ
– Pingare la destinazione.
In entrambi i casi la sorgente si aspetta un mes-
saggio di risposta; nel caso in cui il link doves-
se esser danneggiato, la prima delle due opzio-
ni contribuira a ripristinare il tutto, mentre la
120
5.2. ATTACCHI
seconda richiedera l’invio di una nuova RREQ
dopo un certo periodo τr . E inoltre consi-
gliato implementare l’algoritmo in maniera tale
da far si che τs sia random perche altrimen-
ti in caso contrario l’attaccante potrebbe im-
personificare il nodo di destinazione e mandare
periodicamente messaggi di RREP.
5.2.3 Neighbor
L’attacco consiste nel far credere a S di esser
direttamente connesso a D e viceversa. Per far
cio A opera nel seguente modo (vedi Fig.5.2):
se la sorgente invia una RREQ ad A, quest’ulti-
mo prende il pacchetto ricevuto, ne copia tutti
i campi e ne crea uno nuovo da mandare a de-
stinazione. Subito dopo aver fatto questa ope-
razione, l’attacker crea una RREP da inviare a
S. Dato che comunque alla base di tutto vi e un
continuo furto di identita (infatti A impersona
una volta S ed un’altra D), si potrebbe sfrut-
tare la crittografia asimmetrica garantendo cosı
121
5.2. ATTACCHI
Figura 5.2: Topologia Neighbor Attack
che solamente a destinazione il pacchetto possa
essere letto; inoltre si verrebbe a creare anche
un canale sicuro per lo scambio delle chiavi. Se
A invece riceve un HELLO packet da S, tutto
cio non ha piu senso perche l’attacker puo leg-
gere ugualmente il messaggio e ricreare il tutto;
una possibile soluzione potrebbe essere quindi
quella che prevede l’utilizzo del timestamp.
122
5.2. ATTACCHI
Considerando che quando due nodi si vedono
per la prima volta viene calcolata e memorizza-
ta la differenza δ tra i clock, non appena l’attac-
ker processa decifra e reinvia l’HELLO packet,
perdera un tempo maggiore di δ facendo si che,
|Ts− T | < δ
non sia piu verificata.
5.2.4 Sybil
Questo attacco consiste nel prendere le veci di
un nodo che non esiste e far si che questo, essen-
do visto come un nodo benevolo, diventi parte
integrante della rete riuscendo cosı a scambiare
informazioni e pacchetti vari con tutti gli altri
utenti della MANET (vedi Fig. 5.3).
Nel momento in cui si voglia garantire nella re-
te configurata ad-hoc un minimo di sicurezza
necessita non fidarsi piu dei propri vicini, o co-
munque dei nodi che vogliono entrare a fare
123
5.2. ATTACCHI
Figura 5.3: Topologia Sybil Attack
parte della MANET, e richiedere delle infor-
mazioni per avere certezze. Alla base di que-
sto attacco vi e proprio la violazione della fi-
ducia, ragion per cui una possibile soluzione
potrebbe essere appunto quella di creare una
rete nella quale e implementata una crittogra-
fia asimmetrica e basata sulla presenza della
CA CertificationAuthority; quest’ultima, at-
traverso la generazione dei certificati, riesce a
garantire l’autenticita del nodo e nel caso spe-
124
5.2. ATTACCHI
cifico dell’attacco Sybil il nodo nuovo, essendo
inesistente, e non identificabile.
5.2.5 Blackhole, Grayhole, Jellyfish
Figura 5.4: Topologia Blackhole/Grayhole/Jellyfish Attack
Anche alla base di questi tre attacchi vi e una
continua operazione di sniffing di traffico e una
continua falsificazione di pacchetti da parte del-
l’attacker. Utilizzando AODV, nel momento in
cui un nodo desidera raggiungere una destina-
125
5.2. ATTACCHI
zione, per la quale non ha una route, dissemina
una RREQ e quando il nodo di destinazione
si vede arrivare questo messaggio risponde con
una RREP.
Nella prima fase degli attacchi in questione l’at-
tacker si mette in ascolto cercando di captare il
traffico quindi o una RREQ proveniente dalla
sorgente vittima oppure un pacchetto di HEL-
LO proveniente da un neighbor, poiche appun-
to il parametro di interesse e il Destination
Sequence Number; acquisito questo parame-
tro, l’attacker passa alla creazione di una RREP
falsa.
Dopo aver analizzato la procedura precedente-
mente descritta, le riflessioni fatte hanno porta-
to alla conclusione che una crittografia asimme-
trica potrebbe risolvere i problemi riscontrati;
infatti, nel momento in cui un nodo che non e
la destinazione si vede arrivare una RREQ, non
riesce a decifrarla evitando cosı di leggere e mo-
dificare i vari campi; inoltre, grazie all’utilizzo
126
5.2. ATTACCHI
della coppia di chiavi pubblica-privata, la sor-
gente riesce a verificare se la RREP e autentica
e quindi e stata inviata realmente da D.
Supponendo che la prima parte degli attacchi
sia andata a buon fine, possiamo pensare di fare
detection basandoci sul comportamento che ha
l’attacker nel momento in cui desidera portare
a termine il suo lavoro. Nel caso di Blackhole,
una volta che l’attacker e sicuro che il traffico
passi da esso, non fa altro che applicare le rego-
le di routing ed in modo particolare fa si che i
pacchetti non arrivino piu a destinazione come
nel caso di Drop Attack. Per evitare che que-
sto attacco vada a buon fine, si puo pensare di
attuare la stessa strategia di difesa presentata
per il Drop Attack, inviando quindi in maniera
random una RREQ per verificare la presenza o
meno del link.
Per quanto riguarda il Grayhole Attack la se-
conda fase dell’attacco consiste nell’accodamen-
to dei pacchetti e nell’invio di alcuni di essi ga-
127
5.2. ATTACCHI
rantendo cosı che solo una parte dei dati arrivi a
destinazione. Qui non viene presentata una ve-
ra e propria soluzione al problema; da un punto
di vista teorico si puo pensare di implementa-
re un counter e attraverso la valutazione della
percentuale di traffico perso fare delle ipotesi in
merito all’affidabilita dei link (il fatto che molto
traffico venga perso implica che comunque sta
succedendo qualcosa di strano).
Analogalmente nel Jellyfish Attack, previa stu-
dio accurato delle prestazioni della rete, si pos-
sono settare delle soglie e valutare, per esempio,
un delay massimo oltre il quale non si dovrebbe
normalmente andare.
5.2.6 Sleep Deprivation
Lo Sleep Deprivation mira a consumare le risor-
se dei nodi tenendoli constantemente impegnati
a processare pacchetti inutili. L’attacker puo,
per esempio, inviare al nodo vittima una grande
quantita di pacchetti di route request, di route
128
5.2. ATTACCHI
Attack Esito
Replay OK
Drop OK
Neighbor OK
Sybil OK
Blackhole OK
Grayhole OK
Jellyfish OK
Sleep Deprivation OK
Tabella 5.1: AODV protection
replay o di route error. Come risultato finale il
nodo in questione diventa incapace di parteci-
pare ai vari meccanismi di routing poiche peren-
nemente impegnato in altre attivita. Dato che
comunque questo attacco e simile al Replay At-
tack, si puo pensare di attuare le stesse tecniche
di difesa descritte precedentemente.
129
5.2. ATTACCHI
5.2.7 Considerazioni finali
Dopo aver brevemente descritto i vari attacchi
che un nodo malevolo puo compiere in una re-
te MANET nella quale viene usato il protocol-
lo AODV e aver trovato, almeno una possibile
soluzione per ognuno di essi, possiamo conclu-
dere che le tecniche precedente descritte hanno
senso nel momento in cui l’attacker e parte in-
tegrante della rete. Pertanto, risulta necessa-
ria una prima autenticazione da parte dei nodi
ogni qual volta che uno di essi desidera entrare
a far parte della rete. Per far cio si puo pensa-
re di sfruttare, come nel caso in cui si utilizzi
OLSR, una crittografia simmetrica, poiche piu
leggera dal punto di vista del carico computa-
zionale pero dato che comunque per contrastare
molti attacchi e stato proposto di utilizzare una
crittografia asimmetrica e consigliato sfruttare
quest’ultima anche per cercare di autenticare
i vari nodi che desiderano entrare a far parte
della network.
130
Conclusioni
Lo scopo della presente tesi e stato quello di mo-
strare come costruire un test-bed per valutare e
successivamente migliorare il grado di sicurezza
garantito nelle reti MANET.
Si e partiti analizzando lo scenario ed il contesto
in cui nascono e vengono utilizzate queste reti.
Lo sviluppo delle MANET e sempre in continua
evoluzione poiche vi e la tendenza a migliorare
le prestazioni cercando il modo piu efficiente per
far funzionare le reti create ad-hoc. Come detto
pocanzi e stato costruito un test-bed ponendoci
come obiettivo quello di risolvere i problemi di
131
sicurezza poiche il futuro di tali reti dipende
fortemente dalla loro risoluzione.
Dopo l’analisi iniziale si e passati allo studio dei
protocolli di routing presenti nello stato dell’ar-
te; essi si dividono in Proactive e Reactive rou-
ting Protocol e per ciascuna delle due classi si
e scelto un protocollo. Per la classe dei pro-
tocolli proattivi e stato scelto OLSR (Optimi-
zed Link State Routing Protocol), mentre per
la seconda classe AODV (Ad hoc On-Demand
Distance Vector Routing); in entrambi i casi so-
no state analizzate sia le procedure attraverso le
quali vengono inoltrati i pacchetti sia appunto
i messaggi e i pacchetti scambiati.
Successivamente, e stata fatta una ricerca di
tutti quelli che sono i possibili attacchi imple-
mentati dagli hackers per queste reti, giungen-
do alla conclusione che un nodo malevolo puo
recare danni in vari modi; tra questi vi e la
possibilita di scartare, ritardare o inviare fuori
sequenza i pacchetti che passano da esso stesso.
132
Infine dopo una valutazione di quelli che sareb-
bero stati i tool necessari per il raggiungimento
del nostro obiettivo, si e passati all’implementa-
zione, nel caso di OLSR, di una versione sicura
del protocollo; il tutto e stato possibile grazie in
un primo momento ad un’accurata e minuziosa
analisi e alle opportune modifiche in un secondo
momento del source code.
Per testare il nuovo protocollo sono state crea-
te varie topologie e sono stati simulati i vari at-
tacchi precedentemente analizzati. Il risultato e
stato appunto quello che il nuovo protocollo im-
plementato riesce a fare detection di ogni singo-
lo attacco mettendo i nodi coinvolti in uno stato
di ALERT ed evitando cosı che questi vadano
a buon fine.
Inoltre, per quanto riguarda il protocollo AODV,
e stato fatto uno studio teorico alla luce delle
contromisure proposte per OLSR, di quelle che
potrebbero essere le soluzioni, implementabili
in futuro, per cercare di rendere anch’esso sicu-
133
ro, raggiungendo quindi lo stesso risultato del
protocollo proattivo.
134
Appendice A
Manuale
A.1 Fase di setup e installazio-
ne
A.1.1 Configurare scheda di rete
– Installare Ubuntu 10.04 su tutti i pc
– Eseguire i seguenti comandi per aggiorna-
re i pacchetti presenti ed installare quelli
necessari (connesso a Internet)
135
A.1. FASE DI SETUP E INSTALLAZIONE
# sudo su \(Immettere la password \TC4200"\)
# apt-get update
# apt-get upgrade
# reboot
# apt-get update
# apt-get install build-essential
# apt-get install linux-source
# apt-get install linux-headers-generic
# apt-get install linux-libc-dev
# apt-get install iw
– Per installare la scheda di rete da connet-
tere tramite porta USB bisogna salvare il
firmware ar9271.fw e la cartella compact-
wireless-2.6.38.2-2.tar.bz2
– Eseguire i comandi
# cp ar9271.fw /lib/firmware
136
A.1. FASE DI SETUP E INSTALLAZIONE
# tar xvf compact-wireless-2.6.38.2-2.tar.bz2
# cd compact-wireless-2.6.38.2-2
# ./scripts/driver-select ath9k_htc
# make
# make install
– Per controllare se il driver della scheda e
caricato
# lsmod | grep ath9
Figura A.1: Verifica installazione scheda di rete
137
A.1. FASE DI SETUP E INSTALLAZIONE
A.1.2 Configurare protocollo
I seguenti protocolli devono essere installati su
tutte le macchine che fanno parte del Test-bed.
AODV
– Salvare la cartella aodv-uu-0.9.6.tar.gz
– Eseguire i seguenti comandi
# tar xvf aodv-uu-0.9.6.tar.gz
# cd aodv-uu-0.9.6
# make && make install
– Per far partire il protocollo
# aodvd -l -d -D -r 3
(cosı gira in background e per vedere l’output:
# cat /var/log/aodvd.log)
# aodvd -l -D -r 3
(cosı NON in background )
OLSR
138
A.1. FASE DI SETUP E INSTALLAZIONE
– Eseguire i seguenti comandi
# apt-get install olsrd
# cp /etc/olsrd/olsrd.conf/etc
– Per far partire il protocollo
# olsrd -i interfaccia -d valore
valore: indica quante informazioni di debug ven-
gono visualizzate in output, assume i valori da
0 a 9, dove 0 significa che il protocollo gira in
background .
OLSR Versione Sicura
– Eseguire i seguenti comandi
# cd /...../olsrd-Cocilovo
# make clean && make && make install
# cd /olsrd-Cocilovo/lib/secure
# make clean && make && make install
Considerazioni e problemi riscontrati
– Se l’interfaccia della scheda di rete non e
corretta bisogna editare il file “olsrd.conf”
139
A.1. FASE DI SETUP E INSTALLAZIONE
e modificare l’apposito parametro di “In-
terface” .
# gedit /etc/olsrd.conf
– Se non viene caricato il Plugin di sicurez-
za, dopo l’opportuna installazione, bisogna
editare il file “olsrd.conf” e aggiungere le
seguenti linee a fine file:
LoadPlugin “olsrd secure.so.0.5” {PlParam “Keyfile” “/etc/olsrd.d/olsrd secure key”
}
Ovviamente bisogna assicurarsi che esistano tut-
te le directory richieste, in caso contrario segui-
re la seguente procedura:
– Creare la directory opportura attraverso il
comando
# mkdir /etc/olsrd.d
– Creare il file che conterra la chiave
# gedit /etc/olsrd.d/olsrd\_secure\_key
– Creare la chiave a 128-bit
#md5sum package-name
140
A.1. FASE DI SETUP E INSTALLAZIONE
Figura A.2: Generazione Chiave
– Prendere la key restituita dal passaggio pre-
cedente e copiarlo all’interno del file creato
al passaggio 2.
NOTA: La chiave puo essere calcolata in qual-
siasi altro modo pur che sia di 128-bits. Io ho
preferito l’MD5 solo perche sono sicuro che mi
veniva restituita una stringa di quella dimen-
sione. Ricorda che la chiave deve essere uguale
per tutte le macchine. Per esempio al posto di
package-name si puo mettere il seguente path
/etc/olsrd.d/olsrd secure key.
– Per far partire il protocollo
# olsrd -d valore
valore: indica quante informazioni di de-
bug vengono visualizzate in output, i valo-
ri vanno da 0 a 9, dove 0 significa che il
141
A.1. FASE DI SETUP E INSTALLAZIONE
Figura A.3: Salvataggio Chiave
protocollo gira in background mentre 2 e il
valore tipicamente utilizzato per ricevere in
output le info di nostro interesse.
142
A.2. PARTE ATTACKER
A.2 Parte Attacker
A.2.1 Installare librerie
– Salvare le cartelle
∗ libnet-1.1.5.tar.gz
∗ libpcap-1.1.1.tar.gz
∗ iptables-1.4.13.tar.bz2
∗ libnfnetlink-1.0.0.tar.bz2
∗ libnetfilter queue-1.0.1.tar.bz2
– Per installare le varie librerie:
∗ scompattare la cartella
∗ entrare nella cartella
∗ eseguire i comandi
# ./configure
# make && make install
Considerazioni e problemi riscontrati
– Libnet
143
A.2. PARTE ATTACKER
1. Questa libreria e stata modificata per
poter creare i pacchetti dei protocolli usati
(dettagli nella prossima sezione)
2. Se quando si compila non vine visto lib-
net.so.1 necessita creare un link simbolico
eseguendo il seguente comando
# ln -s /usr/local/lib/libnet.so.1
/usr/lib
– Libpcap
∗ Puo capitare che quandi si esegue il co-
mando
# ./configure
si riscontrano degli errori, in tal caso
bisogna digitare
# ./configure --without-flex
--without-bison
(il tutto e specificato nel MANUALE
presente nella cartella della libreria)
∗ Sui tablet (usati come attackers solo
in Wormhole Attack) puo capitare che
144
A.2. PARTE ATTACKER
vengano restituiti errori quindi necessi-
ta installare anche le seguenti librerie
nel seguente ordine:
· m4-1.4.13
· bison-2.4.1
· flex-2.5.35
· libpcap-1.0.0
– Libnetfilter queue
1. Per installare questa libreria bisogna
installare anche le due precedenti
2. Se in fase di compilazione si dovesse pre-
sentare lo stesso errore di Libnet digitare
# ln -s ... .so.1 /usr/local/lib /usr/lib
A.2.2 Modifica di Libnet per aggiun-
gere header
(esempio in libnet-1.1.5/doc/PACKET BUILDING)
– definire la grandezza del nuovo header (in
bytes) e aggiungerla in
...libnet-1.1.5/include/libnet/libnet-headers.h
145
A.3. FASE DI IMPLEMENTAZIONE
– creare la struttura del nuovo header e ag-
giungerla alla fine di libnet-headers.h
– aggiungere il protocol block identifier alla
fine della lista in ...libnet-1.1.5/include/libnet/libnet-
structures.h
– rieseguire i comandi
# cd libnet-1.1.5
# ./configure
# make && make install
Sono stati introdotti gli header dei proto-
colli usati quindi create le strutture mostra-
te nel file strutture-header.
A.3 Fase di implementazione
A.3.1 Configurare rete ad hoc
– Configurare rete ad hoc
# ifconfig
– Creare uno script utilizzando il comando
# gedit test.sh
146
A.3. FASE DI IMPLEMENTAZIONE
Figura A.4: Interfaccia scheda di rete
– Scrivere all’interno dello script precedente
creato i seguenti comandi:
# ifconfig INTERFACCIA down
# service network-manager stop
# iw INTERFACCIA set type ibss
# ifconfig INTERFACCIA INDIRIZZO up
(indirizzo IP che gli vuoi assegnare)
# iw INTERFACCIA ibss join test 2412
– Dare gli opportuni permessi allo script ap-
pena creato
# chmod a + x /root/.../test.sh
– Per configurare la rete ad-hoc basta sem-
plicemente far partire lo script
# ./ test.sh
– Per emulare la topologia fisica dare il se-
guente comando su tutti i pc per OGNI no-
147
A.3. FASE DI IMPLEMENTAZIONE
Figura A.5: Script
do che NON e in visibilita nella topologia
desiderata
# iptables -I INPUT -m mac
--mac-source indirizzo -j DROP
(indirizzo: MAC del nodo che NON vede)
Figura A.6: Indirizzo Scheda di Rete
148
A.3. FASE DI IMPLEMENTAZIONE
– Avviare il protocollo di routing
A.3.2 Configurare tunnel
Estremi del tunnel A1 e A2
Indirizzi dati:
S = 10.0.0.3
D = 10.0.0.7
A1 = 10.0.0.9
A2 = 10.0.0.8
Figura A.7: Topologia con Tunnel
Su A1 dare questi comandi :
149
A.4. ATTACCHI
# iptunnel add tun mode gre remote 10.0.0.8
local 10.0.0.9 ttl 255
# ifconfig tun 10.0.0.19 up
# ifconfig tun pointopoint 10.0.0.18
# route add 10.0.0.7 gw 10.0.0.19 dev tun
(route per mandare traffico nel tunnel)
Su A2 dare questi comandi :
# iptunnel add tun mode gre remote 10.0.0.9
local 10.0.0.8 ttl 255
# ifconfig tun 10.0.0.18 up
# ifconfig tun pointopoint 10.0.0.19
# route add 10.0.0.3 gw 10.0.0.18 dev tun
(route per mandare traffico nel tunnel)
A.4 Attacchi
(fare attenzione alle interfacce che siano corret-
te negli script)
150
A.4. ATTACCHI
A.4.1 Far partire un attacco
Bisogna rifarsi alla cartella “Menu”. Per far
partire qualsiasi tipologia di attacco basta spo-
starsi all’interno della cartella, digitare
# ./selezione
e seguire il menu che si aprira scegliendo l’at-
tacco da far partire.
Figura A.8: Menu
Se dovessero verificarsi problemi di compatibi-
lita tra i vari scripts ed il pc che funge da at-
151
A.4. ATTACCHI
Figura A.9: Attacco Mode ON
tacker basta ricompilare il tutto eseguendo i
seguenti comandi:
# cd .../menu
#gcc -o selezione selezionetotale.c
#gcc -o selezioneOLSR selezioneOLSR.c
#gcc -o selezioneAODV selezioneAODV.c
152
A.4. ATTACCHI
AODV cartella menu/AODV
OLSR cartella menu/OLSR
#cd .../menu/AODV (OLSR)
A.4.2 Blackhole
Figura A.10: Topologia Blackhole Attack
Attacker A
Victims S e D
S = 10.0.0.9
D = 10.0.0.8
153
A.4. ATTACCHI
AODV
Modo 1 (scarto dei pacchetti effettuato da A)
# gcc -o blackhole1ok blackhole1ok.c
-lnet -lpcap
Modo 2 (i pacchetti vengono inviati a un nodo
inesistente)
# gcc -o blackhole2ok blackhole2ok.c
-lnet -lpcap
OLSR
#gcc -o provablackhole provablackhole.c
-lnet -lpcap
A.4.3 Grayhole
(stessa topologia di Blackhole)
AODV
# gcc -o grayhole grayhole.c -lnet -lpcap
-lnetfilter_queue -lpthread
OLSR
154
A.4. ATTACCHI
#gcc -o grayholeOLSR grayholeOLSR.c -lnet
-lpcap -lnetfilter_queue -lpthread
A.4.4 Jellyfish
(stessa topologia di Blackhole)
AODV
Delay Variance
# gcc -o jf_delayvariance jf_delayvariance.c
-lnet -lpcap -lnetfilter_queue -lpthread
Reorder Buffer
# gcc -o jf_reorderbuffer jf_reorderbuffer.c
-lnet -lpcap -lnetfilter_queue -lpthread
OLSR
# gcc -o jf_reorder_OLSR jf_reorder_OLSR.c
-lnet -lpcap -lnetfilter_queue -lpthread
155
A.4. ATTACCHI
Figura A.11: Topologia Neighbor Attack
A.4.5 Neighbor
Attacker A
Victims S e D
S = 10.0.0.8
D = 10.0.0.9
AODV/OLSR
# gcc -o neighbor neighbor.c -lnet
-lpcap -lnetfilter_queue -lpthread
156
A.4. ATTACCHI
A.4.6 Packet Drop
Attacker A
Figura A.12: Topologia Packet Drop Attack
AODV/OLSR
# gcc -o pkt_drop pkt_drop.c
A.4.7 Replay
(non e stata usata nessuna configurazione par-
ticolare, ho solo verificato con Wireshark che
replicasse effettivamente i pacchetti voluti)
AODV/OLSR
# gcc -o replay replay.c -lpcap
A.4.8 Sleep Deprivation
(stesso discorso)
157
A.4. ATTACCHI
AODV
# gcc -o sleepdeprivation sleepdeprivation.c
-lnet
A.4.9 Sybil
(stesso discorso)
AODV
# gcc -o sybil sybil.c -lnet -lpcap
-lnetfilter_queue -lpthread
OLSR
#gcc -o provaSybilOLSR provaSybilOLSR.c
-lnet -lpcap -lnetfilter_queue -lpthread
A.4.10 Whormhole
(topologia descritta quando si e parlato di tun-
nel)
Sulla macchina con indirizzo 10.0.0.8
#gcc -o encaps8 encaps8.c -lnet -lpcap
158
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
-lnetfilter_queue
#./ encaps8
Sulla macchina con indirizzo 10.0.0.9
#gcc -o encaps9 encaps9.c -lnet -lpcap
-lnetfilter_queue
#./ encaps9
Nota: per evitare eventuali malfunzionamenti e
consigliato durante la procedura di compilazio-
ne non modificare i nomi dei file di output ed
digitare i comandi cosı come sono scritti. Nel
momento in cui si vuole far partire un attacco
conviene prima editare il file per vedere se gli in-
dirizzi IP sono corretti dopodiche basta salvare
e ricompilare .
A.5 Operazioni effettuate sui pac-
chetti
Le operazioni principali che sono state fatte sui
pacchetti sono quelle di Sniffing, Creazione e In-
159
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
Figura A.13: Cartella con gli script degli attacchi contro l’OLSR
codamento. Esse sono state implementate come
segue.
A.5.1 Sniffing
La libreria “Libpcap” e stata utilizzata per
appunto sniffare il traffico. Esistono varie re-
lease di questa API (Application Programming
Interface), nel caso specifico e stata utilizzata
la Libpcap-1.1.1 . L’operazione di sniffing e
composta da vari passaggi.
160
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
Figura A.14: Cartella con gli script degli attacchi control’AODV
Prima di tutto bisogna specificare l’interfaccia
di rete da configurare affinche la cattura dei
pacchetti abbia esito positivo.
pcap_t *handle;
handle = pcap_open_live(dev,BUFSIZ,1,
1000,errbuf);
if (handle == NULL) {
fprintf( stderr, "Error Couldn’t
open device %s: %s",dev, errbuf);
return(2);
161
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
}
Da notare la funzione “pcap open live()” la
quale prende in ingresso i seguenti parametri:
device indica l’interfaccia utilizzata dalla rete
ad-hoc per la cattura del traffico.
snaplen indica il numero massimo di bytes da
catturare per pacchetto.
promisc flag che viene configurato per deter-
minare la modalita di settaggio dell’inter-
faccia di rete, “promiscua o no”.
to ms e un timeout che conta i millisecondi che
passano prima che l’operazione di lettura
finisca.
errbuf buffer per i messaggi di errore.
Utilizzando questa libreria e possibile anche crea-
re un filtro “bpf” (berkey packet filter) selezio-
nando quindi solamente i pacchetti a cui si e
interessati. Il bpf viene compilato tramite la
funzione “pcap compile()” e impostato con
la funzione “pcap setfilter()”.
162
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
struct bpf_program fp;
char filter_exp[] = "ip src host address
&& udp port port";
bpf_u_int32 mask;
bpf_u_int32 net;
if (pcap_lookupnet(dev, &net, &mask,
errbuf) == -1) {
fprintf(stderr, "Can’t get netmask %s", dev);
net = 0;
mask = 0;
}
if (pcap_compile(handle, &fp,
filter_exp, 0, net)==-1) {
fprintf(stderr,"Couldn’t parse filter
%s: %s",filter_exp,
pcap_geterr(handle));
return(2);
}
if (pcap_setfilter(handle,&fp)==-1) {
163
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
fprintf(stderr, "Couldn’t install filter
%s: %s", filter_exp, pcap_geterr(handle));
return(2);
}
Libpcap offre diverse opzioni per la cattura e il
processing dei pacchetti. Le due funzioni utiliz-
zate nel test-bed sono “pcap next()” e “pcap
loop()”. La prima viene utilizzata per sniffare
un singolo pacchetto e spesso e utilizzata an-
che per memorizzare il pacchetto da replicare
successivamente (vedi attacco Replay).
packet = pcap_next(handle, &header);
pcap_sendpacket(handle,packet,header.len);
La seconda funzione per eseguire l’analisi, quin-
di capire il tipo di pacchetto ed eventualmente
memorizzare i campi a cui si e interessati, su
ogni messaggio catturato chiama una funzione
di tipo “process packet()”. Uno dei parame-
tri piu significativi della funzione e il puntatore
al pacchetto, “process packet”.
164
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
if (pcap_loop
(handle, -1,process_packet,NULL)==-1){
fprintf (stderr,"%s",pcap_geterr(handle));
exit (1);
}
Si definiscono quindi le strutture degli header:
/* Ethernet header */
struct sniff_ethernet {
u_char ether_dhost [ETHER_ADDR_LEN];
u_char ether_shost [ETHER_ADDR_LEN];
u_short ether_type ;
};
/* IP header */
struct sniff_ip {
u_char ip_vhl ;
u_char ip_tos ;
u_short ip_len ;
u_short ip_id ;
u_short ip_off ;
165
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
# define IP_RF 0 x8000
# define IP_DF 0 x4000
# define IP_MF 0 x2000
# define IP_OFFMASK 0 x1fff
u_char ip_ttl ;
u_char ip_p ;
u_short ip_sum ;
struct in_addr ip_src, ip_dst ;
};
# define IP_HL(ip) (((ip)->ip_vhl)&0x0f)
# define IP_V(ip) (((ip)->ip_vhl)>>4)
/* UDP header */
struct sniff_udp {
u_short uh_sport ;
u_short uh_dport ;
u_short uh_ulen ;
u_short uh_sum ;
};
166
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
/* AODV header */
struct sniff_type {
u_int8_t tipo ;
};
/* RREQ */
struct sniff_rreq {
u_int8_t type ;
u_int8_t flags ;
u_int8_t res2 ;
u_int8_t hcnt ;
u_int32_t rreq_id ;
struct in_addr dest_addr ;
u_int32_t dest_seqno ;
struct in_addr orig_addr ;
u_int32_t orig_seqno ;
};
/* RREP */
struct sniff_rrep {
167
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
u_int8_t type ;
u_int8_t flags ;
u_int8_t res2 :3;
u_int8_t prefix :5;
u_int8_t hcnt ;
struct in_addr dest_addr ;
u_int32_t dest_seqno ;
struct in_addr orig_addr ;
u_int32_t lifetime ;
};
/* OLSR header */
struct sniff_olsr {
u_int16_t pkt_len ;
u_int16_t pkt_seqno ;
};
/* OLSR message header */
struct sniff_msg_header {
u_int8_t msg_type ;
u_int8_t vtime ;
168
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
u_int16_t msg_size ;
struct in_addr orig_addr ;
u_int8_t ttl;
u_int8_t hcount ;
u_int16_t msg_seqno ;
};
Si incrementa il puntatore per individuare l’ini-
zio del pacchetto successivo:
ethernet = (struct sniff_ethernet*)(packet);
ip = (struct sniff_ip*)
(packet+SIZE_ETHERNET);
size_ip = IP_HL(ip)*4;
udp = (struct sniff_udp*)
(packet+SIZE_ETHERNET
+ size_ip);
Una volta che i bits del pacchetto sniffato sono
associati alla struttura che lo definisce si puo
passare alla lettura dei vari campi.
Infine vengono chiamate due apposite funzioni
per effettuare il cleaning delle risorse, esse sono:
169
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
pcap_freecode(&fp);
pcap_close(handle);
Figura A.15: Struttura pacchetto OLSR
A.5.2 Creazione pacchetti
La libreria utilizzata per la creazione di un pac-
chetto e la Libnet-1.1.5. Essa e stata modifi-
cata attraverso l’aggiunta degli headers dei pro-
tocolli AODV e OLSR. Grazie alla Libnet e pos-
170
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
sibile creare pacchetti sia a livello IP che a livel-
lo 2. Sono presenti molti protocolli e funzioni
per assemblare i rispettivi header, ma nel caso
in cui si dovesse costruire un header non defini-
to nella libreria basta aggiungere nuovi packet
builder con header di dimensione fissa. Vedia-
mo quindi la procedura che porta alla creazione
degli headers dei pacchetti utilizzati, in parti-
colar modo RREQ e RREP per il protocollo
AODV, HELLO e TC per OLSR.
Operazioni per creare un nuovo packet builder:
1)Stabilire la dimensione degli header ed editare
il file libnet-headers.h:
#define LIBNET_AODV_RREQ_H 0x18
#define LIBNET_AODV_RREP_H 0x14
#define LIBNET_OLSR_TC 0x2c
#define LIBNET_OLSR_HL 0x34
2) Creare le strutture e aggiungerle in libnet-
headers.h :
/* AODV RREQ */
171
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
struct libnet_aodv_rreq {
/* RREQ Flags : */
# define RREQ_JOIN 0x1
# define RREQ_REPAIR 0x2
# define RREQ_GRATUITOUS 0x4
# define RREQ_DEST_ONLY 0x8
# define RREQ_UNKNOWN_SEQNO 0x10
# define RREQ_GRP_REBUILD 0x20
u_int8_t type ;
u_int8_t j:1;
u_int8_t r:1;
u_int8_t g:1;
u_int8_t d:1;
u_int8_t u:1;
u_int8_t res1 :3;
u_int8_t res2 ;
u_int8_t hcnt ;
u_int32_t rreq_id ;
u_int32_t dest_addr ;
u_int32_t dest_seqno ;
172
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
u_int32_t orig_addr ;
u_int32_t orig_seqno ;
};
/* AODV RREP */
struct libnet_aodv_rrep {
u_int8_t type ;
u_int8_t r:1;
u_int8_t a:1;
u_int8_t res1 :6;
u_int8_t res2 :3;
u_int8_t prefix :5;
u_int8_t hcnt ;
u_int32_t dest_addr ;
u_int32_t dest_seqno ;
u_int32_t orig_addr ;
u_int32_t lifetime ;
};
/* OLSR HELLO */
struct neighbor {
173
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
uint32_t addr ;
uint8_t lq;
uint8_t nlq ;
uint16_t pad;
};
struct lq_hello_info_header {
uint8_t link_code;
uint8_t reserved;
uint16_t size;
struct neighbor neigh1;
struct neighbor neigh2;
struct neighbor neigh3;
};
struct lq_hello_header {
uint16_t reserved;
uint8_t htime;
uint8_t will;
struct lq_hello_info_header info_h;
};
174
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
struct olsr_msg_header {
uint8_t type;
uint8_t vtime;
uint16_t size;
uint32_t orig;
uint8_t ttl;
uint8_t hops;
uint16_t seqno;
struct lq_hello_header hello_h;
};
struct libnet_olsr_hello {
uint16_t olsr_packlen;
uint16_t olsr_seqno;
struct olsr_msg_header msg_h;
};
/* OLSR HELLO con neighbor con
175
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
diversi link type */
struct libnet_olsr_hello_linktype {
u_int16_t pkt_len;
u_int16_t pkt_seqno;
u_int8_t type;
u_int8_t vtime;
u_int16_t msg_size;
u_int32_t orig_addr;
u_int8_t ttl;
u_int8_t hcount;
u_int16_t msg_seqno;
u_int16_t res1;
u_int8_t htime;
u_int8_t will;
u_int8_t link_code1;
u_int8_t res2;
u_int16_t link_msg_size1;
uint32_t neigh_addr1;
uint8_t link_type1;
176
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
uint8_t neigh_type1;
u_int16_t pad1;
u_int8_t link_code2;
u_int8_t res3;
u_int16_t link_msg_size2;
uint32_t neigh_addr2;
uint8_t link_type2;
uint8_t neigh_type2;
u_int16_t pad2;
uint32_t neigh_addr3;
uint8_t link_type3;
uint8_t neigh_type3;
u_int16_t pad3;
};
/* OLSR TC */
struct libnet_olsr_tc {
u_int16_t pkt_len ;
177
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
u_int16_t pkt_seqno ;
u_int8_t type ;
u_int8_t vtime ;
u_int16_t msg_size ;
u_int32_t orig_addr ;
u_int8_t ttl;
u_int8_t hcount ;
u_int16_t msg_seqno ;
u_int16_t ansn ;
u_int16_t reserved ;
struct neighbor neigh1 ;
struct neighbor neigh2 ;
struct neighbor neigh3 ;
};
3) Aggiungere il Pblock identifier alla fine del-
la lista dei vari identificatori presenti nel file
libnet-structures.h prestando attenzione all’u-
nivocita dell’ID number.
#define LIBNET_PBLOCK_AODV_RREQ_H 0x43
178
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
#define LIBNET_PBLOCK_AODV_RREP_H 0x44
#define LIBNET_PBLOCK_OLSR_H 0x45
#define LIBNET_PBLOCK_OLSR_TC 0x46
#define LIBNET_PBLOCK_OLSR_HL 0x47
4) Definire le funzioni.
Tipicamente affinche si possano definire le fun-
zioni utili per la creazione di un pacchetto biso-
gna creare un file in “root/libnet/src” ma nel
caso specifico le varie funzioni sono state defi-
nite e richiamate ogni qualvolta necessitava nei
vari attacchi.
Si porta come esempio quella che crea un mes-
saggio di HELLO del protocollo OLSR.
/* Funzione che costruisce
il messaggio di hello */
libnet_ptag_t libnet_build_olsr_hello
(u_int16_t pkt_seqno, u_int8_t vtime,
u_int32_t orig_addr, u_int16_t msg_seqno,
u_int8_t linkcode, u_int32_t neigh1,
179
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
u_int32_t neigh2, u_int32_t neigh3,
u_int8_t lq,u_int8_t nlq,
const uint8_t *payload,
uint32_t payload_s, libnet_t *l,
libnet_ptag_t ptag){
uint32_t n;
libnet_pblock_t *p;
struct libnet_olsr_hello hello;
if (l == NULL)
{
return (-1);}
n = LIBNET_OLSR_H + payload_s;
p = libnet_pblock_probe(l, ptag, n,
LIBNET_PBLOCK_OLSR_H);
if (p == NULL){
return (-1);}
memset(&hello, 0, sizeof(hello));
180
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
hello.olsr_packlen = htons(0x0030);
hello.olsr_seqno = htons(pkt_seqno);
(hello.msg_h).type = 0xc9 ;
(hello.msg_h).vtime = vtime;
(hello.msg_h).size = htons(0x002c);
(hello.msg_h).orig = orig_addr;
(hello.msg_h).ttl = 1;
(hello.msg_h).hops = 0;
(hello.msg_h).seqno = htons(msg_seqno);
((hello.msg_h).hello_h).reserved = 0;
((hello.msg_h).hello_h).htime = 134;
((hello.msg_h).hello_h).will = 7;
(((hello.msg_h).hello_h).info_h)
.link_code = linkcode;
(((hello.msg_h).hello_h).info_h)
.reserved = 0;
(((hello.msg_h).hello_h).info_h)
.size = htons(0x001c);
((((hello.msg_h).hello_h).info_h)
.neigh1).addr = neigh1;
181
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
((((hello.msg_h).hello_h).info_h)
.neigh1).lq = lq;
((((hello.msg_h).hello_h).info_h)
.neigh1).nlq = nlq;
((((hello.msg_h).hello_h).info_h)
.neigh1).pad = 0x0000;
((((hello.msg_h).hello_h).info_h)
.neigh2).addr = neigh2;
((((hello.msg_h).hello_h).info_h)
.neigh2).lq = 254;
((((hello.msg_h).hello_h).info_h)
.neigh2).nlq = 255;
((((hello.msg_h).hello_h).info_h)
.neigh2).pad = 0x0000;
((((hello.msg_h).hello_h).info_h)
.neigh3).addr = neigh3;
((((hello.msg_h).hello_h).info_h)
.neigh3).lq = 222;
((((hello.msg_h).hello_h).info_h)
182
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
.neigh3).nlq = 215;
((((hello.msg_h).hello_h).info_h)
.neigh3).pad = 0x0000;
n = libnet_pblock_append(l, p,
(uint8_t *)&hello, LIBNET_OLSR_H);
if (n == -1)
{
goto bad;
}
LIBNET_DO_PAYLOAD(l, p);
return (ptag ptag :
libnet_pblock_update
(l, p, 0, LIBNET_PBLOCK_OLSR_H));
bad:
libnet_pblock_delete(l, p);
return (-1);
};
183
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
Inizializzazione della sessione.
Libnet si basa su tre concetti:
Context : e un opaque handle usato per man-
tenere lo stato della sessione durante la co-
struzione del pacchetto completo. Ci si rife-
risce al contex tramite una variabile di tipo
“libnet t”.
Protocol blocks : sono dati interni di libnet
definiti per ogni livello di rete.
Protocol tag : permette di riferirci a un pro-
tocol block tramite una variabile di tipo
“libnet ptag t”.
La prima cosa da fare consiste nel creare un con-
text usando l’apposita funzione “libnet init()”,
essa prende i seguenti parametri:
injection type : puo assumere valori quali,
LIBNET LINK o LIBNET RAW4, i qua-
li indicano il livello di partenza della co-
struzione del pacchetto. Il primo per esem-
pio indica che si sta partendo da un Link
184
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
Layer mentre il secondo indica che il livello
di partenza e quello IPv4.
device : stringa che contiene il nome dell’in-
terfaccia.
error buffer : buffer a cui mandare i messaggi
di errore.
#include <libnet.h>
libnet_t *l;
char *device = "wlan0";
char errbuf[LIBNET_ERRBUF_SIZE];
l = libnet_init (LIBNET_RAW4,device,errbuf);
if (l == NULL){
fprintf (stderr, "Error opening context:
%s", errbuf);
exit (1);
}
Costruzione dei protocol blocks.
Dopo aver creato il libnet context si puo co-
minciare a costruire i vari protocol blocks, ri-
cordando che devono essere costruiti in ordine
185
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
a partire dal livello piu alto. Si susseguono le
seguenti operazioni:
- dichiarazione dei protocol tags
libnet_ptag_t ipv4=0, udp=0, rreq=0;
- si chiamano le funzioni per definire gli headers
libnet_build_aodv_rreq();
libnet_build_udp();
libnet_build_ipv4();
Invio dei pacchetti e chiusura.
Una volta costruiti i vari protocol blocks attra-
verso l’utilizzo della funzione “libnet write()” si
assemblano e si inviare il pacchetto in rete.
if ((libnet_write (l)) == -1){
fprintf (stderr, "Unable to send
packet: %s",libnet_geterror (l));
exit (1);}
Pulitura della memoria.
libnet_destroy (l);
186
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
A.5.3 Accodamento dei pacchetti
I pacchetti accodati vengono trattati attraverso
l’utilizzo della libreria “Libnetfilter queue-
1.0.1”. Nella fase di inizializzazione tramite
la funzione “nfq open()” viene creato un NF-
QUEUE handler, le due funzioni chiamate suc-
cessivamente servono per dire al kernel che la
coda e gestita dal NFQUEUE handler per il
protocollo selezionato.
struct nfq_handle *h;
h = nfq_open();
if (!h) {
printf( "error during nfq_open ");
if (nfq_unbind_pf
(h, PF_INET)< 0){
printf( "error during nfq_unbind_pf");
exit(1);}
if (nfq_bind_pf
(h, PF_INET) < 0){
187
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
printf( "error during nfq_bind_pf");
exit(1);
}
Quindi si lega il programma a una specifica co-
da e si imposta quale parte del pacchetto deve
essere copiata nello userspace.
struct nfq_q_handle *qh;
qh = nfq_create_queue(h,0, &cb, NULL);
if (!qh) {
printf( "error during nfq_create_queue");
exit(1);}
if (nfq_set_mode(qh,NFQNL_COPY_PACKET,
0xffff)< 0){
printf( "can’t set packet_copy mode");
exit(1);
}
L’accodamento dei pacchetti avviene in manie-
ra iterativa:
int rv;
188
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
char buf[4096];
int fd = nfq_fd(h);
while ((rv=recv(fd, buf, sizeof(buf),
0))>= 0) {
printf("pkt received");
nfq_handle_packet(h, buf, rv);}
La funzione “nfq create queue” per ogni pac-
chetto accodato chiama una funzione di “call-
back cb()” nella quale viene presa la decisione
sul pacchetto attraverso l’utilizzo della
“nfq set verdict()”. Quest’ultima prende in
ingresso
ID : valore univoco assegnato da netfilter ad
ogni pacchetto.
Verdict : l’azione (NF DROP, NF ACCEPT
o NF QUEUE) che l’utente decide di effet-
tuare sul pacchetto.
u_int32_t idpkt (struct nfq_data *tb) {
int id = 0;
struct nfqnl_msg_packet_hdr *ph;
189
A.5. OPERAZIONI EFFETTUATE SUI PACCHETTI
struct nfqnl_msg_packet_hw *hwph;
ph = nfq_get_msg_packet_hdr(tb);
if (ph)
id = ntohl(ph->packet_id);
return id;}
int cb(struct nfq_q_handle
*qh,struct nfgenmsg *nfmsg,
struct nfq_data *nfa, void *data) {
u_int32_t id = idpkt(nfa);
return nfq_set_verdict(qh, id,
NF_ACCEPT, 0, NULL);
}
Anche in questo caso bisogna liberare la me-
moria e per far questo di utilizza la “nfq clo-
se(h)”.
190
Bibliografia
[1] F. De Rosa, V. Di Martino, L. Paglione,
and M. Mecella. (2002) Mobile Adaptive In-
formation Systems on MANET: What We
Need as Basic Layer? In Proceedings of the
1st Workshop on Multichannel and Mobi-
le Information Systems (MMIS’03), IEEE,
Rome.
[2] Krishna Gorantala. (2006) Routing proto-
cols in mobile ad-hoc networks. Master’s
thesis Umea University.
[3] rfc 3626 OLSR
http:// www.ietf.org/rfc/rfc3626.txt
191
BIBLIOGRAFIA
[4] rfc 3561 AODV
http:// www.ietf.org/rfc/rfc3561.txt
[5] Pradip M. Jawandhiya, Mangesh M. Ghon-
ge, DR. M.S.Ali, and Prof. J.S. Desh-
pande. (2010) A survey of mobile ad-hoc
network attacks. International Journal of
Engineering Science and Technology
[6] Rashid Hafeez Khokhar, Md AsriNgadi and
Satria Mandala.(2008) A review of current
routing attacks in mobile ad-hoc networks.
International Journal of Computer Science
and Security
[7] S.A.Razak, S.M.Furnell, and
P.J.Brooke.(2004) Attacks against mo-
bile ad-hoc networks routing protocols.
In Proceedings of 5th Annual Postgra-
duate Symposium on the Convergence
of Telecomunications, Networking &
Broadcasting
[8] Ali Ghaffari.(2006) Vulnerability and secu-
rity of mobile ad-hoc networks.Proceedings
192
BIBLIOGRAFIA
of the 6th WSEAS International Conference
on Simulation, Modelling and Optimization
[9] Po-Wash Yau, Shenglan Hu, and Chris J.
Mitchell.(2009) Malicious attacks on ad-
hoc network routing protocols. International
Journal of Computer Research
[10] Jane Zhen and Sampalli Srinivas.(2003)
Preventing replay attacks for secure rou-
ting in ad-hoc networks. Lecture Notes in
Computer Science
[11] Wikipedia. http:// it.wikipedia.org
[12] Imad Aad, Jean-Pierre Hubaux, and Ed-
ward W. Knightly. (2008) Impact of de-
nial of service attacks on ad-hoc net-
works. IEEE/ACM TRANSACTIONS ON
NETWORKING
[13] Yin-Chun Hu, and Adrian Perrig. (2006)
Wormhole attacks in wireless networks.
IEEE JOURNAL ON SELECTED AREAS
IN COMUNICATIONS
193
BIBLIOGRAFIA
[14] Brahim Bensaou, and Tarik Taleb. (2008)
Detecting and avoiding wormhole attacks in
wireless ad hoc networks. Communications
Magazine, IEEE
[15] Abhay Kumar Rai, Rajiv Ranjan Tewari,
and Sauranbh Kant Upadhyay. (2010) Dif-
ferent types of attacks on integrated manet-
internet communication.International Jour-
nal of Computer Science and Security
[16] Yin-Chun Hu, David B.Johnson, and
Adrian Perrig. (2003) Rushing attacks and
defense in wireless ad-hoc network routing
protocols.WiSe ’03 Proceeding of the 2nd
ACM workshop on Wireless security
[17] Jabel Ben-Othman and Ali Hamieh.(2009)
Defending method against attack in wi-
reless ad-hoc networks. The 5th IEEE
International Workshop on Performance
and Management of Wireless and Mobile
Networks
[18] Andreas Tonnesen, Andreas Hafslund,
194
BIBLIOGRAFIA
and Oivind Kure. The Unik-OLSR plugin
library
[19] Andreas Tonnesen, Andreas Hafslund,
Roar Bjorgum Rotvik, Jon Andersson and
Oivind Kure. (2004) Secure Extension to the
OLSR protocol
[20] Cedric Adjih, Thomas Clausen, Philippe
Jacquet, Anis Laouiti, Paul Muhlethaler,
Daniele Raffo. Securing the OLSR protocol
[21] A.M.Hengland, P.Spilling, L. Nilsen and
O.Kure. Hybrid Protection of OLSR
[22] Fan Hong, Lian Hong, Cai Fu. (2005)
Secure OLSR. AINA ’05. IEEE
[23] Bounpadith Kannhavong, Hidehisa Naka-
yama, Yoshiaki Nemoto, Nei Kato, Ab-
bas Jamalipour.(2008) SA-OLSR: Securi-
ty Aware Optized Link State Routing for
Mobile Ad Hoc Networks.IEEE
195
Top Related