Analisi delle Botnet di nuova generazione basate su peer to peer e implementazione in ambiente emulato

Pag. 1 – Capitolo 1: Introduzione 
1 Introduzione 
Nell’ambito dei malware, che comprendono minacce alla sicurezza informatica tra cui 
virus, worm, trojan horse, spyware ed altri ancora, sta assumendo sempre maggiore 
importanza negli ultimi anni anche un’altra tipologia di attacco, che sfrutta le 
potenzialità delle Botnet, reti di host compromessi che, una volta connessi ad Internet, 
tentano di instaurare un canale di “Command & Control” con un nodo centrale 
attaccante (detto botmaster). Questo canale di C&C può essere costituito da un 
insieme di server nel caso di Botnet centralizzate, o da una rete Peer-To-Peer (P2P) 
nel caso di Botnet distribuite: le Botnet P2P utilizzano reti strutturate (ad esempio 
basate su un overlay DHT) poiché le operazioni di controllo sono più leggere e veloci 
rispetto alle reti non strutturate. Il motivo della creazione di queste Botnet risiede 
nell’anonimato di cui gode l’attacker (il botmaster) che, tramite queste reti create ad-
hoc, può lanciare per esempio attacchi DoS, distribuire mail spam, o comunque trarne 
profitto in modo illecito. 
Le Botnet P2P rendono più difficile la rilevazione e il tracking di tali reti da 
parte degli analisti di sicurezza, perché lo scambio dei file di aggiornamento dei bot e 
dei comandi impartiti dal botmaster avviene in modo del tutto mascherato grazie al 
fatto che il botmaster effettua il join alla rete come un normale peer, riuscendo a 
propagare in cascata i comandi a tutti gli altri host. Negli ultimissimi anni, inoltre, per 
il controllo vengono usate reti P2P esistenti (utilizzate ad esempio per il file-sharing) 
anziché reti ad-hoc e questo ne rende ancora più difficoltosa la detection. 
L’obiettivo di questo lavoro di tesi consiste da un lato nell’analisi delle caratteristiche 
delle Botnet esistenti, con particolare riferimento ad una di esse, denominata Storm (o 
Trojan.Peacomm), dall’altro nell’implementazione di un emulatore di una rete di tipo 
Botnet, basata su un protocollo P2P che utilizza Kademlia come algoritmo DHT per la 
gestione delle routing table e delle ricerche dei contenuti. 
Pag. 2 – Capitolo 1: Introduzione 
Il Botnet Emulator che è stato realizzato è configurabile sia per quanto 
riguarda i tempi di interarrivo dei peer (che possono ad esempio avere una 
distribuzione uniforme o esponenziale negativa o anche altre), sia per quelli che 
riguardano le operazioni da essi eseguite, come “get”, “put” e “leave”. E’ inoltre 
possibile decidere quali e quante risorse (ad esempio file) saranno gestiti dai peer (che, 
effettuando l’operazione di “join”, emulano l’ingresso di un host infetto nella rete che 
comprende, tra gli altri host, anche uno o più botmaster), ed è stato anche previsto che, 
dopo la prima join di un peer, questo effettui la ricerca (o la pubblicazione, qualora sia 
il primo host della rete) di un update rilasciato da un botmaster, operazione ricorrente 
in queste reti basate su un C&C distribuito. 
Per quanto riguarda l’organizzazione del lavoro svolto, vengono inizialmente studiati i 
sistemi Peer-To-Peer, e particolarmente le caratteristiche di routing e le vulnerabilità 
dei sistemi basati su DHT (Distributed Hash Table): una attenta analisi di esse 
permette infatti di esplorare quali possano essere le modalità di attacco ad una rete 
Botnet P2P, che nella fattispecie sono state individuate essere il Sybil Attack, 
l’Eclipse Attack, la Pollution delle tabelle di routing e l’Index Poisoning. Sono stati 
anche analizzati i livelli di protezione delle varie release di KAD (la più estesa rete 
P2P di tipo strutturato) in termini di Flood Protection, IP Limitation e IP Verification 
nei confronti degli attacchi Sybil ed Eclipse. 
Si passa poi all’analisi dei malware di nuova generazione, alla loro 
classificazione per campioni o cluster, per giungere alla struttura di una Botnet e alle 
operazioni che avvengono all’interno e all’esterno del singolo host, con particolare 
riferimento allo Storm Worm che, nonostante rappresenti solo una delle prime Botnet 
diffuse a livello mondiale, racchiude al suo interno molti dei componenti che, presenti 
anche nelle più recenti Botnet (quali Conficker), le rendono particolarmente resistenti 
a tecniche di detection e infiltrazione: l’utilizzo di un packer polimorfico, di una lista 
dei peer da contattare che sia in parte fissa e in parte variabile, il funzionamento prima 
su una rete esistente (Overnet) di peer regolari, poi su una creata ad-hoc (Stormnet) e 
Pag. 3 – Capitolo 1: Introduzione 
quindi formata dai soli peer infetti, e l’encryption (con RSA o successivi algoritmi) 
delle stringhe di ricerca in modo da complicare l’opera degli analisti. 
Vengono poi esaminate le caratteristiche di OceanStore, un’infrastruttura di 
rete distribuita a livello globale che offre un accesso controllato a generici dati 
persistenti. Se tale piattaforma venisse anche dotata di tecniche di “accountability” dei 
peer (in particolare attraverso “micropagamenti” o tecniche di reputazione), si 
riuscirebbero a prevenire gli attacchi allo storage, realizzando quindi le premesse per 
la creazione di una futura Botnet P2P che sia efficiente al suo interno e “sicura” nei 
confronti di quei peer che hanno il compito di disgregare la Botnet. 
Infine si descrive il Botnet Emulator che è stato implementato in linguaggio 
Java: dopo un breve tutorial di installazione del progetto nell’ambiente di sviluppo 
Eclipse, e prima di esporre il funzionamento dell’emulatore, si descrive il framework 
DLS (Distributed Location Service) che è stato impiegato, e che permette ad un 
insieme di nodi cooperanti di mantenere al loro interno determinate associazioni tra 
diverse URI (che identificano le risorse) e le liste di contatti da cui è possibile ottenere 
tali risorse. Configurando i parametri di ingresso (distribuzioni, tempi medi, risorse, 
durata emulazione, …) è possibile conoscere la dinamica della rete grazie 
all’aggiornamento real-time della console che mostra le operazioni eseguite ad ogni 
istante e grazie ai file di Log generati che, a fine emulazione, permettono di conoscere 
il numero di join/leave/get/put totali e quelle eseguite con successo, le operazioni 
eseguite da ogni singolo peer, il numero di peer attivi e totali ad ogni istante e anche, 
suddivisi per singola risorsa e per tipo di operazione, i tempi in cui ogni singolo peer 
completa con successo un’operazione sulla risorsa. 
Queste informazioni permettono ad esempio di rappresentare nel tempo 
l’evoluzione del numero dei peer attivi/totali e la percentuale di nodi che hanno 
ottenuto una determinata risorsa: si tratta di indicatori che da un lato permettono di 
stimare la velocità con cui si propagano gli aggiornamenti maligni nella Botnet, 
dall’altro consentono di valutare l’efficienza di eventuali tecniche di infiltrazione 
intraprese per disgregare la comunicazione tra peer infetti o per fornire ai peer dei falsi 
update allo scopo di rimuovere l’infezione anziché aggiornarne il codice. 
Pag. 4 – Capitolo 2: SISTEMI PEER-TO-PEER 
2 SISTEMI PEER-TO-PEER 
2.1 Introduzione 
Un sistema centralizzato di gestione dati [1] ha lo svantaggio notevole di avere un 
singolo point of failure, oltre al fatto che è un sistema dagli elevati costi di 
mantenimento, soggetto facilmente ad attacchi, poco scalabile nonché potenzialmente 
causa di una riduzione delle prestazioni per i terminali remoti che vi accedono (in 
termini di banda e di tempo di accesso alle risorse) qualora molti client 
simultaneamente si connettano al sistema centrale. Ecco perchè un sistema di 
memorizzazione dati basato su una architettura di rete decentralizzata e distribuita, che 
sfrutta le risorse collettive di tutti i terminali della rete, ha il vantaggio di ottenere una 
rete più resistente agli attacchi esterni e a malfunzionamenti interni. 
Tra le tecniche di condivisione dati che caratterizzano i sistemi peer-to-peer, si 
distinguono reti a directory centralizzata oppure decentralizzata. I peer e le loro 
relazioni di comunicazione formano una rete logica astratta, detta rete sovrapposta 
(overlay network). Una overlay network è una rete virtuale formata da nodi (ovvero 
desktop workstation) che si appoggiano alla rete IP esistente, e si può pensare che tali 
nodi siano tra loro connessi da link logici o virtuali, ciascuno dei quali corrisponde ad 
un cammino che può attraversare anche molteplici link fisici nella rete sottostante. Per 
esempio, molte reti P2P sono delle overlay network poiché sono costruite sulla base 
della rete Internet. Il vantaggio offerto dalle overlay network consiste nel rendere 
possibile il routing di messaggi verso destinatari il cui indirizzo IP non è conosciuto a 
priori. Tali overlay network supportano dei protocolli di ricerca [2] che permettono di 
identificare la posizione di un file (ovvero l’indirizzo IP del nodo che lo ospita) a 
partire dal suo nome. Si possono ottenere funzionalità aggiuntive e soluzioni 
alternative a quelle offerte dalle reti esistenti attraverso la modifica dei protocolli di 
Pag. 5 – Capitolo 2: SISTEMI PEER-TO-PEER 
livello overlay, grazie al fatto che le reti overlay sono “sovrapposte” al Network Layer 
IP. 
Vi sono principalmente due tipi di protocolli di ricerca, ognuno adatto a una specifica 
overlay network, la quale può essere: 
· unstructured: tale rete non è vincolata da una organizzazione logica 
deterministica dei nodi, e utilizza un protocollo di ricerca inefficiente basato 
sul broadcast; 
· structured: basata su DHT (Distributed Hash Table), e caratterizzata da una 
organizzazione deterministica delle connessioni tra i nodi. Quindi l’algoritmo 
di routing dei messaggi è strettamente legato a tale organizzazione, e indirizza 
i messaggi di ricerca in modo che raggiungano il nodo di destinazione con un 
limitato numero di rilanci intermedi. Tale rete, assieme ad uno specifico 
algoritmo di routing, costituisce il Document Routing Model (DRM). 
Un modello P2P è costituito da una specifica architettura e da algoritmo di routing ad 
essa dedicato: ciò premesso, una soluzione P2P è scalabile se l’architettura 
contribuisce a rendere efficiente l’algoritmo di routing. Quest’ultimo, in fase di ricerca 
dei file, deve instradare i messaggi nella direzione più opportuna, coprendo il percorso 
più breve possibile, e minimizzando l’overhead computazionale nei nodi e la 
duplicazione dei messaggi. 
2.2 Distributed Hash Table 
Le Distributed Hash Table (DHT), o tabelle di hash distribuite [12], sono una classe di 
sistemi distribuiti decentralizzati che partizionano l’appartenenza di un set di chiavi 
tra i nodi partecipanti, e possono inoltrare in modo efficiente i messaggi all’unico 
proprietario di una determinata chiave. Le DHT sono progettate tipicamente per reti 
con un grande numero di nodi, in cui possono essere frequenti gli ingressi di nuovi 
nodi e gli improvvisi guasti di quelli già presenti. Questo tipo di infrastruttura può 
essere usata per implementare servizi più complessi, come sistemi di file sharing di 
tipo P2P, file system distribuiti e web caching cooperativo. Le DHT utilizzano un tipo 
Pag. 6 – Capitolo 2: SISTEMI PEER-TO-PEER 
di routing basato sulle chiavi che ha lo scopo di ottenere sia la decentralizzazione 
tipica delle architetture non strutturate, sia l’efficienza e l’affidabilità nelle ricerche 
offerte da architetture con directory centralizzata. Le DHT offrono una ricerca solo 
per titoli esatti e non per parole chiave, sebbene questo tipo di funzionalità possa 
essere inserita in uno strato superiore della rete. 
I primi quattro esempi di DHT, ovvero CAN, Chord, Pastry e Tapestry, vennero 
presentati tutti nello stesso periodo, nel 2001, e da allora aprirono la strada alle 
ricerche in questo settore. Kademlia è invece successivo a questi. 
Le proprietà essenziali delle Distributed Hash Table sono: 
· decentralizzazione: i nodi formano collettivamente il sistema senza alcun 
coordinamento centrale; 
· scalabilità: il sistema può funzionare efficientemente anche in presenza di 
molti nodi; 
· efficienti prestazioni in termini di routing, il quale prevede l’utilizzo di nodi 
intermedi a bassa latenza e consente di raggiungere in pochi passi uno dei nodi 
che ospita la risorsa cercata; 
· tolleranza ai guasti o agli attacchi intenzionali: l’affidabilità deve essere 
garantita anche in presenza di nodi che, con elevata frequenza, entrano ed 
escono dalla rete o sono soggetti a malfunzionamenti; 
· semplicità dell’interfaccia fornita dal sistema (denominata Application 
Programming Interface, o API) per permettere agli utenti di ottenere e 
scambiare risorse con altri nodi. 
La tecnica chiave per raggiungere questi scopi è costituita dal fatto che ciascun nodo 
ha bisogno di rimanere in contatto solo con un piccolo numero di altri nodi della rete, 
in modo che questa sia sottoposta alla minima quantità di lavoro per ogni modifica che 
avviene sul set di nodi che la costituiscono. 
Pag. 7 – Capitolo 2: SISTEMI PEER-TO-PEER 
2.3 Struttura delle DHT 
Una DHT è costruita attorno ad un keyspace astratto, per esempio un set di stringhe di 
160 bit. L’appartenenza al keyspace è divisa tra i nodi partecipanti in base ad un ben 
definito schema per il partizionamento. L’overlay network connette i nodi e consente 
loro di trovare il proprietario di una determinata chiave nel keyspace. Si suppone che 
il keyspace sia un set di stringhe di 160 bit. 
Per immagazzinare nella DHT un file caratterizzato dai parametri filename e data, 
viene inizialmente calcolato l’hash del filename, producendo così una chiave k di 160 
bit. In seguito, un messaggio put(k,data) può essere inviato ad un qualunque nodo 
della rete, e tale messaggio sarà inoltrato attraverso la overlay network fino a 
raggiungere il singolo nodo responsabile per la chiave k in accordo alle regole di 
partizionamento del keyspace. Tale nodo immagazzina quindi la coppia (k,data). E’ 
importante osservare [13] che il parametro data può rappresentare sia il file vero e 
proprio (file block), sia un puntatore al nodo in cui il file vero e proprio è 
immagazzinato. Qualsiasi altro nodo può in seguito recuperare il parametro data 
calcolando a sua volta l’hash del filename per ottenere k, e chiedere ad un qualsiasi 
nodo della rete DHT di trovare il dato associato a k tramite un messaggio get(k). Il 
messaggio raggiungerà il nodo responsabile per k, che risponderà fornendo il 
contenuto di data. 
Per partizionare il keyspace si può utilizzare una funzione d( , )k kche definisce la 
12
nozione astratta di distanza tra la chiave k e k. A ciascun nodo è assegnata una 
12
chiave che è detta identificativo (ID), e ad un nodo con ID i appartengono tutte le 
chiavi per cui i è l’ID più vicino, misurando in base a d. Ogni nodo che riceve una 
richiesta per una chiave k, qualora non ne sia il detentore, deve essere capace di 
indirizzare tale richiesta a un nodo il cui ID sia più “vicino” a k. Questa capacità 
assicura che la richiesta arrivi prima o poi al nodo responsabile di k. La nozione di 
distanza assume diversi significati a seconda dello schema impiegato, ad esempio: in 
Chord è la differenza numerica tra due ID di nodo, in Pastry e Tapestry è il numero di 
bit di prefisso in comune tra due ID, in Kademlia è l’OR esclusivo (XOR) tra due ID. 
Pag. 8 – Capitolo 2: SISTEMI PEER-TO-PEER 
Se nel calcolo della funzione di hash applicata al nome di un file si utilizza il 
cosiddetto consistent hashing, la rimozione o l’inserimento di un nodo modifica solo il 
set di chiavi possedute dai nodi con ID adiacenti, senza coinvolgere tutti gli altri nodi, 
in modo da limitare il traffico nella rete. In una hash table tradizionale, invece, 
l’aggiunta o la rimozione di un bucket causa un rimappaggio di quasi tutto l’intero 
keyspace. 
2.4 Key Based Routing 
Si è già detto che ciascun nodo deve mantenere un set di link agli altri nodi suoi vicini. 
Tutte le topologie di DHT condividono qualche variante di questa proprietà 
fondamentale: per ciascuna chiave k, o un nodo possiede k, oppure ha un link ad un 
altro nodo che è più vicino a k in termini di distanza nel keyspace. In quest’ultimo 
caso per contattare il proprietario della chiave k, il nodo inoltra un messaggio di 
richiesta al suo vicino il cui ID ha distanza minima da k. Quando non esiste un vicino 
con questa caratteristica, allora si è giunti effettivamente al nodo più vicino a k, il 
quale sarà proprietario della chiave. Questo tipo di routing viene talvolta definito 
come key based routing. 
A prescindere dalla correttezza di fondo di questo routing, vi sono due vincoli da 
rispettare affinché sia anche efficiente: 
il numero massimo di passi successivi in un qualsiasi percorso (dilazione) deve essere 
basso, in modo che la richiesta sia soddisfatta velocemente. Questo comporta la 
conoscenza di un numero elevato di nodi vicini; 
il numero massimo di vicini di ciascun nodo (ovvero il grado del nodo) deve essere 
basso, al fine di limitare l’overhead di mantenimento. Questo comporta un elevato 
numero di passi successivi. 
I principali algoritmi basati sui meccanismi di DHT sono di tipo strutturato. Questa 
caratteristica offre loro garanzie di successo nelle ricerche dati e invulnerabilità ai 
fallimenti dei singoli nodi. Chord per esempio mantiene una struttura dati che 
assomiglia ad una skiplist, invece Kademlia, Pastry e Tapestry hanno una struttura 
Pag. 9 – Capitolo 2: SISTEMI PEER-TO-PEER 
dati ad albero. CAN differisce ulteriormente dai precedenti per il suo routing 
multidimensionale. La differenza chiave [14] negli algoritmi consiste nella struttura 
dati che essi utilizzano come routing table per effettuare ricerche con complessità 
O(logN), dove N è il numero complessivo dei nodi della rete. Si può notare come la 
complessità delle ricerche sia maggiore qualora si intenda utilizzare, anziché le DHT, 
un’architettura centralizzata (in tal caso il database centrale avrebbe complessità 
O(N)), oppure il query flooding (che nel caso peggiore prevede l’invio di O(N) 
messaggi per singola ricerca). 
2.5 Vulnerabilità di sistemi P2P basati su DHT 
Il protocollo P2P DHT-based [3] consiste in un servizio di ricerca basato su tabelle di 
routing, il quale mappa una data chiave ad un nodo che sarà responsabile per quella 
chiave (ad esempio l’indirizzo IP del nodo). Le ricerche sono implementate 
interrogando le tabelle di routing dei peer: ogni nodo utilizza la propria tabella per 
inoltrare le richieste al nodo responsabile per la chiave cercata. 
I sistemi basati su questo protocollo assumono che i nodi invocati possano essere 
affidabili: mentre in una rete isolata la fiducia dei nodi è giustificata, in una rete 
aperta, come ad esempio la rete internet, è possibile escludere i nodi non sicuri con 
l’aiuto di certificati, come proposto da Pastry. In ogni modo la restrizione del sistema 
P2P non è consigliata nella maggior parte dei casi, nei quali la rete deve poter 
funzionare anche in presenza di partecipanti malevoli. 
2.6 Attacchi a DHT 
Una classe di attacchi alle tabelle di hash distribuite (DHT) [4] causa una 
distribuzione di dati non corretti o manipolati: fortunatamente la correttezza e 
l’autenticazione dei dati condivisi può essere garantita dall’utilizzo di tecniche 
crittografiche, individuando ed ignorando i dati non autentici. 
Pag. 10 – Capitolo 2: SISTEMI PEER-TO-PEER 
La maggior parte dei sistemi P2P basati su DHT implementa uno schema 
deterministico per quanto riguarda il collocamento dei dati e la traccia degli ID dei 
nodi e dei file. Questa caratteristica da una parte assicura la conoscenza della 
posizione dei dati, se essi esistono, e dall’altra permette a nodi malevoli di attaccare 
l’intera rete. 
Un attacco possibile consiste in anomalie di routing (Routing Anomalies) causate dai 
peer malevoli, i quali rispondono alle richieste con instradamenti incorretti; un altro 
attacco mira allo schema di collocamento dei dati (Information Decay); un terzo 
attacco coinvolge la pianificazione e la creazione degli ID dei nodi e dei file (ID 
Mapping). 
I nodi malevoli partecipano al sistema di lookup distribuito, ma non seguono 
correttamente il protocollo. Tali nodi cercano di ingannare i nodi legittimi producendo 
false informazioni. 
2.6.1 Routing Anomalies 
Il protocollo di lookup prevede il mantenimento di tabelle di routing e l’instradamento 
delle richieste attraverso tali tabelle, per cui è importante che le tabelle siano corrette. 
2.6.2 Incorrect Lookup Routing 
Un nodo malevolo potrebbe inoltrare le richieste ad un nodo inesistente: dato che il 
nodo partecipa normalmente all’aggiornamento di routing, appare attivo e per questo 
non viene eliminato dalle tabelle degli altri nodi. Fortunatamente questo tipo d’inoltro 
fasullo può essere individuato, controllando ad esempio che ad ogni passo (peer) la 
richiesta si avvicini sempre di più alla chiave cercata: in caso di un attacco di questo 
tipo la ricerca recupera l’instradamento ritornando sui propri passi fino all’ultimo 
nodo attendibile e cercando un percorso alternativo. Per fare un controllo di questo 
genere, il peer che avvia la ricerca deve poter vedere ogni passo della ricerca: CAN 
propone, ad esempio, un’ottimizzazione in cui ogni nodo tiene traccia dei RTT ai nodi 
Pag. 11 – Capitolo 2: SISTEMI PEER-TO-PEER 
vicini e inoltra la richiesta al vicino con miglior rapporto RTT, senza interagire con il 
peer che ha effettuato la richiesta. 
Un nodo malevolo potrebbe inoltre dichiarare che un nodo a caso è responsabile della 
chiave cercata: in questo caso il nodo che ha effettuato la richiesta potrebbe essere 
lontano dallo spazio di hash della chiave e quindi non sapere che in realtà il nodo 
dichiarato non è quello più vicino alla chiave stessa, registrando la chiave in un nodo 
non corretto e quindi impedendo che tale chiave sia successivamente trovata. Tale 
attacco può essere sconfitto in due passi. 
Prima di tutto il nodo che effettua la ricerca dovrebbe assicurarsi che il nodo di 
destinazione sia vicino alla chiave cercata: in Chord il predecessore ritorna l’indirizzo 
del punto finale della query invece del successore stesso, rendendo possibile un 
attacco in cui il nodo malevolo reindirizza la richiesta ad un altro successore; in ogni 
caso, se il nodo riferito è attendibile, nota di non essere responsabile della chiave 
cercata e provoca un errore. 
In secondo luogo, il sistema dovrebbe assegnare le chiavi ai nodi in modo verificabile: 
dato che in molti sistemi le chiavi sono assegnate ai nodi con ID più vicino alle chiavi 
stesse, sarebbe sufficiente assegnare in modo verificabile ID ai nodi. Chord imposta 
l’ID del nodo sull’indirizzo IP e sulla porta del nodo stesso, mentre CAN permette ad 
ogni nodo di specificare la sua identità, il che rende impossibile verificare la 
responsabilità delle chiavi. Un’alternativa sarebbe utilizzare una crittografia a chiave 
pubblica e privata, anche se comporterebbe penalità sulle prestazioni, ma riuscirebbe a 
stabilire un rapporto di fiducia tra i peer. 
2.6.3 Incorrect Routing Updates 
Un nodo malevolo può manipolare le tabelle di routing inviando ad altri nodi 
aggiornamenti errati. A causa di questi aggiornamenti di routing un nodo innocente 
potrebbe inoltrare una richiesta a nodi malevoli o non esistenti. Tuttavia, se il sistema 
sa che gli update di routing devono avere certi requisiti, tali update possono essere 
Pag. 12 – Capitolo 2: SISTEMI PEER-TO-PEER 
verificati: gli update di Pastry, ad esempio, richiedono un prefisso corretto per ogni 
tabella di routing, cosicché gli update fasulli possono essere identificati e scartati. 
Per un attacco più delicato si dovrebbe approfittare di quei sistemi che permettono ai 
nodi di scegliere percorsi corretti multipli: l’ottimizzazione RTT di CAN è un perfetto 
esempio di questo tipo di sistemi. Un nodo malevolo può abusare di questa flessibilità, 
scegliendo un nodo non attendibile, con grande latenza oppure un altro nodo 
malevolo. 
2.6.4 Partition 
Per eseguire il bootstrap, un nuovo nodo che partecipa al sistema di lookup deve 
contattare un nodo esistente; in questo modo il nuovo nodo è vulnerabile ad essere 
partizionato in una rete malevola, parallela alla rete P2P, che utilizza gli stessi 
protocolli. Il nuovo nodo potrebbe quindi entrare accidentalmente a far parte di questa 
rete, non funzionando correttamente. Un nodo malevolo potrebbe inoltre essere 
registrato anche nella rete legittima, cercando di connettere nuovi nodi alla rete 
parallela (recruit). Oltretutto, le partizioni possono essere utilizzate dai nodi malevoli 
per bloccare il servizio o per studiare il comportamento dei client nella rete. 
Per impedire che un nuovo nodo possa essere reclutato nella rete parallela, esso deve 
effettuare il bootstrap attraverso una qualche sorgente fidata, al di fuori della rete 
stessa: un nodo che eventualmente abbandona e successivamente si registra nella rete 
potrà utilizzare come bootstrap le sorgenti fidate o uno dei nodi contattati 
precedentemente. 
In ogni modo, la costruzione di metriche di fiducia può essere rischioso in presenza di 
reti in cui l’identità dei nodi non è prefissata: se un nodo assume un indirizzo IP 
attraverso DHCP può essere legittimo un giorno e malevolo un altro. 
Se un nodo crede di aver effettuato il bootstrap con successo nel passato, può 
individuare nuove partizioni maliziose con un controllo incrociato dei risultati: 
controlla le tabelle di routing con delle random queries, le quali vengono propagate in 
maniera random. 
Pag. 13 – Capitolo 2: SISTEMI PEER-TO-PEER 
2.6.5 Storage and Retrieval Attack 
Un nodo malevolo può partecipare al protocollo di lookup in modo corretto, ma 
potrebbe negare l’esistenza dei dati per i quali è responsabile oppure sostenere di 
essere in possesso di dati in presenza di una richiesta ma rifiutarsi di servire il client. 
Per contrastare questo attacco, i peer devono implementare la replica dei dati 
condivisi, evitando un processo di replica centralizzato (se il peer malevolo replica 
una risorsa compromessa anche le sue repliche saranno compromesse). 
In questo modo i peer devono indipendentemente determinare i nodi corretti da 
contattare per le repliche: questo permette inoltre di verificare tutte le repliche al 
momento di una possibile ricerca e di assicurare che esistano un numero fisso di 
repliche in ogni momento. I peer che ricercano una data risorsa devono essere 
preparati ad un eventuale nodo malevolo e per questo devono contattare almeno due 
nodi responsabili delle repliche per verificare l’integrità della risorsa e delle sue 
repliche. 
Le repliche con funzioni di hash multiple, come proposto in CAN, sono una tecnica di 
prevenzione di questo tipo di attacco, mentre le reti in cui vengono assegnati ID ai 
nodi in maniera non verificabile sono vulnerabili sotto questo punto di vista. 
L’utilizzo di repliche per la sicurezza dei dati, tuttavia, porta alla luce un problema per 
cui se le variabili che determinano l’attendibilità di una risorsa sono immagazzinate 
come plain-text in modo non sicuro, un peer malevolo può facilmente manipolarle 
facendo credere che i peer attendibili siano malevoli e viceversa. 
Tale problema si può risolvere utilizzando tecniche di crittografia e firma digitale, 
anche se questo comporta un incremento di traffico nella rete dovuto a tutte le 
autenticazioni, soprattutto nei sistemi distribuiti su larga scala. 
2.6.6 ID Mapping Attack 
Quasi tutti i sistemi DHT utilizzano una funzione hash unilaterale (MD5 o SHA1) per 
derivare l’identificazione di un nodo dal suo EID (ad esempio il proprio indirizzo IP). 
Pag. 14 – Capitolo 2: SISTEMI PEER-TO-PEER 
Un nodo p ha accesso al dato d se e solo se dÎResp( )p. Dunque se il nodo malevolo 
n ha come obiettivo la chiave d, dovrà selezionare un EID tale che n effettui il join con 
ID(d)=hash(n.EID). Inoltre il costo di un attacco a una specifica chiave è molto 
inferiore a quello che occorre per invertire la funzione di hash dell’ID mapping. 
Quindi un nodo malevolo può localizzare il nodo in cui è memorizzato un dato che 
vuole ottenere, utilizzando il protocollo di lookup. 
Un nodo che si registra alla rete contatta tipicamente un server di bootstrap pubblico 
per ottenere un entry point per eseguire il bootstrap. Per contrastare un attacco di ID 
Mapping, si potrebbe derivare l’ID del nodo non dal suo EID, ma da una chiave 
random: il nodo malevolo non può, così, determinare offline l’EID utilizzato per 
controllare il dato. 
2.6.7 Inconsistent Behaviour 
Gli attacchi finora descritti sono molto più difficili da rilevare se un nodo maligno 
presenta buoni comportamenti verso una parte della rete, in particolare verso i nodi 
vicini ad esso nell’ID space. Questi nodi vicini non hanno motivo di eliminare il 
maligno dalle loro routing table, nonostante invece i nodi lontani sperimentino un 
comportamento anomalo da parte di esso. Questo non sarebbe un problema se le 
richieste venissero indirizzate sempre a dei nodi vicini prima di raggiungere il target, 
ma molti sistemi utilizzano metodi di routing che prevedono il “salto” nell’ID space 
verso nodi lontani per velocizzare la richiesta. Senza l’utilizzo di chiavi pubbliche e 
firme digitali non è possibile valutare se siano attendibili report che descrivono come 
maligno un nodo vicino apparentemente corretto, poiché tali report potrebbero anche 
essere generati allo scopo di voler eliminare un nodo buono. Invece con chiavi 
pubbliche questo sarebbe possibile, richiedendo ai nodi di firmare ogni loro risposta, 
così da poter successivamente valutare le incongruenze. In assenza di questo, i singoli 
nodi decideranno autonomamente se ritenere maligni determinati nodi che presentano 
un comportamento anomalo.