Application aux Réseaux Pair-à-Pair

Transcription

Thèse de Doctorat de l’université d’Evry Val d’Essonne
Spécialité
Réseaux et Informatique
présentée par
Nassima KHIAT
pour obtenir le grade de
Docteur de l’université d’Evry Val d’Essonne
Détection et Mitigation de Vers dans le Cœur de Réseau :
Application aux Réseaux Pair-à-Pair
Soutenance prévue le Mercredi 13 Janvier 2010 devant le jury composé de
Mme Maryline LAURENT
Mr Abdelmalek BENZEKRI
Mr Olivier PAUL
Mr Nazim AGOULMINE
Mr Yvon GOURHANT
TELECOM SudParis
Université Paul Sabatier - Toulouse
TELECOM SudParis
Université d’Evry Val d’Essonne
Orange Labs – Lannion
Rapporteur
Rapporteur
Examinateur
Encadrant
Encadrant
Résumé
L’Internet et ses utilisateurs font quotidiennement l’objet d’attaques à
l’aide de logiciels malveillants. Les vers, qui font partie de ces logiciels, se
distinguent des autres moyens d’attaque par leur propagation automatique,
qui les rend potentiellement dangereux.
Pour faciliter leur propagation et la rendre plus rapide, les vers peuvent,
entre autres, s’attaquer aux applications les plus prisées par les utilisateurs.
La généralisation de l’utilisation des réseaux Pair-à-Pair par les internautes fait de ces réseaux une cible parfaite pour des vers appelés ”vers
Pair-à-Pair”.
Ces vers, et en particulier ceux d’entre eux qui sont passifs, sont caractérisés par leur furtivité. En effet, ils ne génèrent aucun trafic suspect, ce
qui rend leur détection dans le réseau difficile.
Le but de cette thèse est de proposer une solution efficace contre les
vers Pair-à-Pair passifs, afin de sécuriser les réseaux Pair-à-Pair, qui commencent à être utilisés pour distribuer du contenu légal, comme la vidéo
à la demande. Ainsi, nous proposons une architecture et des algorithmes
pour détecter les vers Pair-à-Pair passifs dans le réseau. Nous évaluons nos
algorithmes dans un simulateur que nous avons développé, ainsi qu’à l’aide
d’une étude analytique. Nous nous intéressons ensuite à la mitigation des
vers détectés dans le réseau.
Mots-clés : vers, sécurité, détection d’intrusions, mitigation, Pair-à-Pair
i
Abstract
The Internet and its users are daily the object of attacks of malware.
Among them, we can find the worms, which distinguish themselves from
the other attacks by their automatic way of propagation. This makes them
potentially very dangerous.
To make their propagation easier and faster, the worms can attack popular applications.
The generalization of the use of Peer-to-Peer networks makes them a
perfect target of worms called ”Peer-to-Peer worms”.
These worms, and in particular the passive ones, are characterized by
their stealthy. Indeed, they generate no suspect traffic, and are so difficult
to detect in the network.
The purpose of this thesis is to propose an effective solution against the
passive Peer-to-Peer worms, to make Peer-to-Peer networks, which begin to
be used to distribute some legal contents such as the VoD (Video on Demand) ones, more secure. We propose several algorithms and an architecture
to detect the passive Peer-to-Peer worms in the network. We evaluate our
algorithms in a simulator which we have developed, as well as with an analytical study. We then study the mitigation issue of the detected worms.
Key words : worm, security, intrusion detection, mitigation, Peer-toPeer.
iii
Table des matières
Résumé
i
Abstract
iii
Introduction
1
1 État de l’art
1.1 Vers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Menaces dans le réseau (malware) . . . . . . . . . . .
1.1.2 Composants d’un ver . . . . . . . . . . . . . . . . . . .
1.1.3 Taxonomie des vers . . . . . . . . . . . . . . . . . . .
1.1.4 Solutions contre les vers . . . . . . . . . . . . . . . . .
1.2 Réseaux Pair-à-Pair . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Types de réseaux Pair-à-Pair . . . . . . . . . . . . . .
1.2.3 Applications du Pair-à-Pair . . . . . . . . . . . . . . .
1.2.4 Réseaux Pair-à-Pair les plus connus . . . . . . . . . .
1.2.5 Sécurité dans les réseaux Pair-à-Pair . . . . . . . . . .
1.3 Vers Pair-à-Pair . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Stratégies de propagation des vers Pair-à-Pair . . . . .
1.3.3 Modélisation épidémiologique des vers Pair-à-Pair . .
1.3.4 Détection des vers Pair-à-Pair : les solutions existantes
et leurs limitations . . . . . . . . . . . . . . . . . . . .
2 Proposition d’un mécanisme
Pair passifs
2.1 Algorithme de détection . .
2.1.1 Première approche .
2.1.2 Deuxième approche
5
5
5
8
8
10
16
16
17
19
20
22
22
22
23
23
25
de détection de vers Pair-à. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
v
29
30
30
35
2.2
2.1.3 Troisième approche . . . . . . . . . . . . . . . . . . . .
Architecture de détection . . . . . . . . . . . . . . . . . . . .
42
47
3 Evaluation de la solution de détection
51
3.1 Evaluation par étude analytique . . . . . . . . . . . . . . . . 52
3.1.1 Faux positifs générés par l’algorithme de détection . . 52
3.1.2 Effet des méthodes de contournement éventuelles sur
les résultats de détection . . . . . . . . . . . . . . . . . 55
3.1.3 Architecture de détection . . . . . . . . . . . . . . . . 59
3.2 Evaluation par simulations . . . . . . . . . . . . . . . . . . . . 62
3.2.1 Simulateur . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 64
4 D’une solution de détection vers une solution de lutte contre
les vers Pair-à-Pair passifs
4.1 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Mise en place de la solution dans le réseau . . . . . . . . . . .
4.3 Adaptation de la solution aux systèmes Pair-à-Pair non centralisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion et perspectives
73
74
77
79
83
vi
Table des figures
1.1
1.2
1.3
1.4
Pot de miel. . . . . . . . . . . .
Réseau Pair-à-Pair décentralisé.
Réseau Pair-à-Pair centralisé. .
Réseau Pair-à-Pair hybride. . .
2.1
Arborescence de téléchargement du pair P (SX est le pair
source du pair X, DX est le pair downloader du pair X ). . . .
Pairs impliqués dans l’algorithme L3. . . . . . . . . . . . . . .
Pairs impliqués dans l’algorithme L2D. . . . . . . . . . . . . .
Pairs impliqués dans l’algorithme L4. . . . . . . . . . . . . . .
Pairs impliqués dans l’algorithme L3D. . . . . . . . . . . . . .
Les algorithmes L2, L3, L2D, L4 et L3D dans l’espace ROC,
avec nbFich = 0. . . . . . . . . . . . . . . . . . . . . . . . . .
Evolution du nombre de pairs infectés et pairs détectés avec
L2 et nbFich ∈ {1, 2, 5} . . . . . . . . . . . . . . . . . . . . .
Les algorithmes L2, L3, L2D, L4 et L3D dans l’espace ROC,
avec nbFich ∈ {2, 5} . . . . . . . . . . . . . . . . . . . . . . .
Architecture de détection. . . . . . . . . . . . . . . . . . . . .
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
17
18
19
32
36
38
38
39
41
44
46
49
3.2
3.3
3.4
3.5
3.6
Evolution du nombre de pairs infectés dans le réseau pour c
∈ {1, 5, 10} . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Composants fonctionnels du simulateur. . . . . . . . . . . . . 64
Evolution du nombre de pairs infectés pour c∈ {5, 10, 20, 30, 40}. 66
Evolution du nombre de pairs détectés pour c∈ {5, 10, 20, 30, 40}. 67
Délai entre l’infection d’un pair et sa détection. . . . . . . . . 68
Evolution du nombre de pairs infectés et détectés lorsque le
nombre de pairs pour lesquels il n’y a pas d’information sur
le partage de 10%, 20% et 50% des pairs. . . . . . . . . . . . 70
4.1
Effet de la mitigation sur la propagation du ver.
vii
. . . . . . .
75
Liste des tableaux
1.1
1.2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3.1
3.2
3.3
Tableau récapitulatif
larité. . . . . . . . .
Tableau récapitulatif
mitations. . . . . . .
des différents malware et leur particu. . . . . . . . . . . . . . . . . . . . . . .
des solutions contre les vers et leurs li. . . . . . . . . . . . . . . . . . . . . . .
Algorithme L2. . . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithme L3. . . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithme L2D. . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithme L4. . . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithme L3D. . . . . . . . . . . . . . . . . . . . . . . . . .
Résultats de simulation avec les algorithmes L3, L2D, L4 et
L3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distance entre les algorithmes L2, L3, L2D, L4 et L3D et la
ligne de non-discrimination, avec nbFich = 0. . . . . . . . . .
Résultat de simulation pour L3, L2D, L4 et L3D avec nbFich
∈ {2, 5} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distances entre les algorithmes L2, L3, L2D, L4 et L3D et la
ligne de non-discrimination, avec nbFich ∈ {2, 5} . . . . . . .
Valeurs des paramètres du simulateur. . . . . . . . . . . . . .
Résultat de l’algorithme L2 avec nbFich = 2 pour différentes
valeurs de c. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Effet de la non disponibilité du partage de tous les pairs sur
les résultats de l’algorithme de détection . . . . . . . . . . . .
ix
8
16
33
37
37
39
40
40
41
46
47
65
65
69
Introduction
De nos jours, les logiciels malveillants (ou malware) constituent une menace omniprésente pour les utilisateurs de l’Internet, comme souligné dans le
rapport de l’ENISA (European Network and Information Security Agency)
[22], publié en novembre 2007, qui indiquait que plus de six millions d’ordinateurs dans le réseau Internet étaient corrompus par des malware.
Les malware peuvent être de différents types, selon leur méthode de propagation ou d’activation par exemple, mais leur dénominateur commun est
leur capacité à réaliser des actions malveillantes. Le résultat de ces actions
peut être le vol d’informations confidentielles des machines infectées, ou le
lancement d’attaques de déni de service contre des machines du réseau, notamment.
La multiplication des attaques de malware dans le réseau Internet peut
engendrer des pertes d’argent colossales aux entreprises, entre l’utilisation de
leurs informations confidentielles, la perturbation de leur fonctionnement et
les coûts de rétablissement des machines infectées au sein de ces entreprises,
entre autre. D’après le Computer Economics [25], ces pertes ont atteint, à
l’échelle mondiale, 13,3 milliards de dollars en 2006. Autre fait important à
noter : le ver ≪ SQL Slammer ≫ [7], lancé en janvier 2003, qui a attaqué les
serveurs Microsoft SQL Server 2000, et qui a provoqué une grande consommation de la bande passante et perturbé l’accès à certains sites Web, a
provoqué à lui seul plus de 750 millions de dollars de dommages à l’échelle
mondiale [25].
L’ampleur des dégâts que peuvent provoquer les vers trouve son explication dans leur capacité à se propager automatiquement, et de transporter,
en plus de leur action malveillante, d’autres types de malware comme les
virus. Cet aspect critique de la menace des vers pour les clients des ISP
(Internet Service Providers), autant les particuliers que les entreprises, et
1
les ISP eux-mêmes, a bien été montré dans [46].
Les attaques de vers ont commencé en 1988 avec l’apparition malencontreuse du ver Morris [63], lancé par un étudiant américain dans le réseau
ARPANET [31] (ancêtre du réseau Internet), et elles continuent jusqu’à aujourd’hui avec des vers comme ”Ikee” [12] qui a attaqué les téléphones 3G
iPhone au mois de novembre dernier. Ce ver s’est manifesté en remplaçant
le fond d’écran du téléphone attaqué par la photo de ”Rick Astley”, un
chanteur des années 1980 et un message texte.
Afin de faciliter et accélérer leur propagation, les vers tentent d’attaquer
des applications très utilisées. Cela leur permet d’avoir le plus de victimes
potentielles possibles. Parmi les applications qui ont connu un grand essor
pendant les années 2000, il y a les applications Pair-à-Pair (P2P), et ce grâce
aux possibilités d’échange qu’elles offrent.
Les attaquants n’ont pas tardé à utiliser les réseaux P2P pour faire propager des vers, ce qui a donné naissance aux ”vers Pair-à-Pair”. Ceux-ci
utilisent, selon leur type, la topologie ou le fonctionnement du réseau P2P
pour contaminer de nouvelles victimes. Ils peuvent être actifs et utiliser l’information sur la topologie du réseau Pait-à-Pair, pour trouver de nouvelles
victimes. Ils peuvent aussi être passifs, prendre les noms de fichiers les plus
populaires et attendre que des pairs du réseau les téléchargent.
Le fait que les vers P2P profitent du fonctionnement ou de la topologie
des réseaux P2P pour se propager leur permet de se fondre dans le trafic de
ces derniers et être indétectables. Et les passifs d’entre eux sont les plus difficiles à détecter car, si les actifs ont besoin de contacter par eux-mêmes les
pairs et profiter de failles de sécurité pour les contaminer, ce qui peut trahir
leur présence, les passifs n’ont besoin de réaliser aucune action et restent
discrets, ce qui rend leur détection une tâche difficile à réaliser. Ceci a attiré
notre attention et nous a poussés à nous intéresser à ce type particulier de
vers P2P.
Un autre élément qui a motivé notre intérêt pour ces vers est l’utilisation future des réseaux P2P. Certes, les applications P2P font partie des
applications les plus incontournables de l’Internet, et elles ont beaucoup
contribué à l’augmentation du nombre d’abonnés à l’Internet haut débit.
Mais, à cause des coûts que génère la quantité de trafic qu’elles produisent
aux opérateurs de réseau, ces derniers ont tenté de contrôler ce trafic avec
2
du filtrage ou des limitations de débit. Cette tendance commence à s’inverser grâce à des initiatives telles que le consortium P4P (Proactive network
Provider Participation for P2P ) [30], créé en 2007. Le but de ce consortium
est d’améliorer les performances des applications P2P, en intégrant la localisation géographique, afin d’utiliser les réseaux P2P pour diffuser du contenu
légal. Il englobe des opérateurs de réseau, des acteurs d’applications P2P,
des constructeurs et des fournisseurs de contenu. Les premiers résultats obtenus par le P4P ont permis de constater une accélération des transferts de
fichiers de 30% à 100%, et diminution des coûts en bande passante. Ainsi,
si l’opérateur de réseau coopère avec le réseau P2P, d’importants gains en
performance pourront être obtenus.
Suite aux éléments évoqués jusqu’ici, le besoin de protection des réseaux
P2P contre les vers P2P, en particulier les passifs, du fait de leur furtivité,
paraı̂t évident. Notre but dans le cadre de cette thèse est de répondre à ce
besoin, en proposant une solution efficace pour détecter les vers P2P passifs
et arrêter leur propagation dans le réseau.
Ce document se présente comme suit : dans le chapitre 2, nous dressons
un état de l’art des vers, leurs différents types et les solutions existantes
pour les détecter. Nous présentons ensuite les réseaux P2P et les différentes
applications dans lesquelles ils peuvent être utilisés, puis, dans la continuité, nous abordons les vers P2P, leurs méthodes de propagation, les solutions existantes contre ces vers et leurs limitations. Dans le chapitre 3, nous
détaillons d’abord les algorithmes que nous avons conçus pour détecter les
vers P2P, nous présentons une comparaison entre eux ce qui nous permet de
choisir l’algorithme le plus efficace. Nous décrivons ensuite une architecture
que nous avons conçue et qui nous permet d’appliquer notre algorithme de
détection. Le chapitre 4 comprend l’évaluation de cette solution, qui passe
par une étude analytique et des simulations, réalisées avec un simulateur que
nous avons conçu et implémenté. Dans le chapitre 5, nous complétons notre
parade contre les vers avec une solution de mitigation, permettant d’arrêter
la propagation du ver après sa détection. Nous étudions aussi la possibilité
d’utiliser notre solution dans les différents types de réseaux P2P. Ceci est
fait dans le but d’avoir la solution la plus complète possible pour faire face
aux vers P2P. Nous donnons enfin les conclusions tirées de ce travail et les
perspectives qui nous sont apparues à son issue.
3
Chapitre 1
État de l’art
Résumé
Dans cette partie, nous donnons la définition d’un ver en général, et nous
citons ses composants, ses différents types et les solutions proposées pour
le détecter. Nous abordons ensuite les réseaux P2P en les définissant, ainsi
que leurs différents types et leurs diverses applications. Nous présentons
quelques réseaux P2P parmi les plus connus et nous parlons de la sécurité y
afférente. La dernière partie de ce chapitre porte sur les vers Pair-à-Pair et
les différentes stratégies qu’ils peuvent utiliser, les modélisations données à
leur propagation et les solutions existantes pour les détecter.
Introduction
Avant de donner la définition des vers Pairs-à-Pair, sujet central de cette
thèse, nous allons parler des vers, classe de laquelle ils découlent, et des
réseaux Pair-à-Pair, environnement dans lequel ils évoluent.
1.1
1.1.1
Vers
Menaces dans le réseau (malware)
L’Internet est constamment l’objet d’attaques initiées par des logiciels
malveillants, appelés aussi ”Malware”.
Un logiciel malveillant est un logiciel dont le but est d’effectuer une action
nuisible à la machine qu’il attaque (panne hardware, arrêt d’un service) ou
5
à son utilisateur (accès, modification, envoi d’informations confidentielles).
Nous allons présenter dans ce qui suit les malware les plus répandus, en
commençant par les virus, qui sont les plus connus d’entre eux.
Un virus est défini comme étant un code offensif qui s’introduit dans un
fichier sain pour y vivre. Il se reproduit ensuite en infectant le maximum de
fichiers.
Le terme de ”virus” est actuellement utilisé pour désigner tout type de
malware infectant un ordinateur (ceci est peut-être une conséquence de l’utilisation du terme ”logiciel anti-virus” pour parler d’un logiciel permettant
de détecter tout type de malware).
Dans la suite de ce rapport, le terme ”virus” ne sera utilisé que pour
désigner un logiciel malveillant tel que défini ci-dessus, et non pas pour parler de malware au sens large.
Un autre type de malware est le ”bot” (contraction du mot ”roBot”),
qui peut être commandé à distance. Par opposition, les vers (définis plus
loin dans ce rapport) et les virus ont un fonctionnement autonome préprogrammé : une fois lancé, un ”ver” ou un ”virus” n’est plus contrôlable.
Le plus souvent les bots récupèrent les ordres qui leur sont adressés en se
connectant sur des serveurs IRC (Internet Relay Chat) spéciaux, conçus
à cet effet. Les bots qui dépendent du même serveur, et qui peuvent être
des milliers, constituent un réseau d’attaque appelé ”Botnet”, qui obéit aux
ordres de l’attaquant qui contrôle ce serveur. Les services qu’il peut rendre
à l’attaquant peuvent être par exemple la propagation de spam, ou l’espionnage des utilisateurs des machines victimes.
Le cheval de Troie (”Trojan” en anglais) est un programme qui a l’air
inoffensif, mais qui contient une fonction malveillante cachée. Le terme ”Cheval de Troie” est assez ancien et vague. Il désigne en général, et par opposition aux virus et vers, tout type de malware qui est installé sur un ordinateur
et tente d’y rester de manière furtive le plus longtemps possible, sans chercher à se reproduire ni à se propager. Ce terme n’est plus vraiment utilisé,
et il est préférable de le remplacer par un terme plus précis décrivant la
fonction du malware, comme ”bot” par exemple.
Le ”spyware” est un logiciel espion. Une fois installé sur une machine, il
6
observe son utilisateur et enregistre son comportement.
L’ ”adware” est un cousin du spyware, mais il n’est pas malveillant (il
ne s’agit pas d’un malware). Il a pour fonction d’afficher des messages publicitaires sur le poste de l’utilisateur et est souvent installé en contrepartie
d’une utilisation gratuite d’un logiciel commercial.
Le ”keylogger” est une forme particulière de ”spyware” qui enregistre
tous les évènements clavier de l’utilisateur afin de capturer des données
intéressantes (typiquement des mots de passe). Des keyloggers plus évolués
se spécialisent dans la capture d’informations particulières : par exemple, ils
écoutent toutes les frappes du clavier, mais n’enregistrent que les séquences
correspondant à des phases de saisie de mot de passe.
Le ver est un autre type de malware et il est particulièrement dangereux.
Un ver (”worm” en anglais) est un programme qui tente de se propager
d’ordinateur en ordinateur de manière entièrement automatique. Typiquement, un ver s’introduit dans un ordinateur en utilisant une faille dans un
service réseau de ce dernier. Il s’y installe et cherche ensuite à se propager
sur les ordinateurs voisins. Le ver ”Morris” est considéré comme étant le
premier ver de l’histoire. Il a été lancé le 2 novembre 1988 par
Robert Tappan Morris, un étudiant de l’Université de Cornell. Ce ver
n’était pas destiné à effectuer des actions malveillantes. Il devait juste compter le nombre de machines connectées au réseau ARPANET, mais il y a eu
un bug dans le code, ce qui a provoqué l’infection de 6000 machines.
Le terme anglais ”worm” est souvent traduit en français en utilisant le
mot ”virus” et non pas ”ver”, probablement parce que la différence entre les
deux n’est pas facilement perçue.
En effet, ces deux malware sont bien différents. Le ver n’a pas besoin
de programme ”hôte” pour se propager. Il arrive sur l’ordinateur via des
faiblesses dans le système de ce dernier et se propage en utilisant les flux
réseau. Le virus, quant à lui, doit s’attacher à un fichier. Les deux peuvent
avoir une action malveillante.
Cette capacité du ver à se propager de façon automatique le distingue
de tous les autres types de malware, et augmente sa dangerosité. De plus,
il peut servir de véhicule aux autres types de malware, comme les virus.
Ainsi, pour combattre les malware efficacement, il est primordial de trouver
7
des solutions contre les vers.
Le tableau 1.1 synthétise les différents malware présentés ici.
Malware
Virus
Bot
Cheval de troie
Spyware
Keylogger
Ver
Particularité
Le plus connu des malware. Tente continuellement de se reproduire
Peut être commandé à distance
Ne cherche pas à se reproduire mais à rester invisible
Enregistre le comportement de l’utilisateur
Un type de spyware qui enregistre les
évènements clavier
Le seul type de malware à pouvoir se propager
automatiquement
Table 1.1 – Tableau récapitulatif des différents malware et leur particularité.
1.1.2
Composants d’un ver
Un ver se compose des parties suivantes :
– Le code d’infection qui permet au ver de s’introduire dans la machine victime, en exploitant une faille de sécurité donnée. Une faille
de sécurité (ou vulnérabilité) est une faiblesse (dysfonctionnement ou
défaut de protection) dans un système, qui peut être exploitée par un
attaquant pour s’introduire sur un ordinateur distant.
– Le code de propagation qui permet au ver d’aller d’une machine à une
autre d’une façon automatique.
– Le code d’action (ou payload) qui est la partie représentant le but
pour lequel le ver a été créé.
1.1.3
Taxonomie des vers
Nous allons maintenant présenter une taxonomie des vers qui a été
donnée dans [47] selon différents critères. Nous allons commencer par celui de
la découverte de cibles, autrement dit, les différentes stratégies utilisées par
8
un ver pour trouver de nouvelles victimes et ainsi poursuivre sa propagation.
La première de ces stratégies est celle qui est basée sur le scan. Elle
consiste à balayer des adresses successives ou aléatoires du réseau à la recherche de machines vulnérables à infecter. Des améliorations ont pu être
apportées à cette technique pour la rendre plus efficace, en effectuant par
exemple des scans en local, où il s’agit de balayer des adresses d’un même
sous-réseau, en se basant sur le fait que, si une machine vulnérable existe
dans un sous-réseau, il y a de fortes chances que d’autres machines ayant
la même vulnérabilité existent dans le même sous-réseau. Ces techniques
basées sur le scan sont les plus simples, mais elles sont en même temps faciles à détecter par les systèmes de sécurité existants.
Une autre stratégie utilisée par les vers pour se propager est celle basée
sur des hit-listes, qui sont des listes prédéfinies de cibles potentielles. Elles
permettent d’augmenter la vitesse de propagation initiale du ver. Ceci permet au ver d’être plus virulent, mais la constitution de la liste demande un
effort préalable important. Le ver appelé ”‘Flash”’ est défini comme étant un
ver possédant une hit-liste complète, recensant les adresses IP de toutes les
machines vulnérables de l’Internet. Ceci lui permettrait d’infecter plus d’un
million de machines en moins d’une seconde. Heureusement, ce ver n’existe
pas encore, car une telle liste n’est pas facile à constituer.
Une autre stratégie pouvant être utilisée par les vers est celle basée sur la
topologie, et consistant à utiliser les informations contenues dans chaque machine infectée pour découvrir de nouvelles cibles. Ces informations peuvent
être des adresses mails ou des serveurs par exemple. L’efficacité de cette
technique dépend de la quantité d’informations récoltée au niveau des machines infectées. Dans le cas où cette dernière est grande, le ver peut avoir
une propagation très rapide, lui permettant d’être très dangereux.
Une dernière stratégie, appelée ”‘passive”’, dans laquelle le ver
ne fait pas de recherche pour trouver ses victimes, il attend plutôt que
ces dernières le contactent. En effet, lorsqu’une machine vulnérable entre en
contact avec une machine infectée, le ver en profite pour infecter cette nouvelle machine. Les vers utilisant cette technique sont d’autant plus dangereux
qu’ils peuvent passer inaperçus dans le réseau. En effet, leur comportement
peut paraı̂tre comme une communication normale entre la machine infectée
et la nouvelle victime.
9
Un autre critère de cette taxonomie est l’activation du ver. Cette action
peut avoir lieu juste après l’ajout du ver sur la machine victime, ou bien après
un certain délai. L’activation humaine est considérée comme la méthode la
plus lente car elle requiert l’intervention de l’utilisateur. Et pour piéger les
utilisateurs méfiants, des techniques d’ingénierie sociale sont utilisées. L’activation du ver peut aussi être basée sur l’activité humaine, comme le fait de
démarrer la machine. Le ver peut être activé par un processus programmé,
comme la mise à jour d’une application. La connexion est alors redirigée
pour mettre le ver en action au lieu de faire la mise à jour. Une authentification exigée lors de la mise à jour complique la réalisation de ce type
d’activation. Le ver peut aussi s’auto activer, en exploitant des failles dans
les logiciels.
Les vers peuvent aussi être classés d’après leur charge utile (payload ),
qui représente l’action malveillante. Il existe différents types de payloads, qui
dépendent de l’objectif recherché par l’attaquant. Il peut n’y avoir aucune
payload, à cause d’un bug dans le code du ver ou bien lorsque le but du ver
est juste de se propager et d’inonder le réseau. Les actions effectuées par un
ver sont variées : cela peut être, entre autres, de lancer une attaque de déni
de service (DoS), de récolter des informations qui peuvent être confidentielles
(mots de passe, codes de carte bleue, etc.), d’endommager le matériel des
utilisateurs (carte mère, disque dur, etc.), de maintenir un ver déjà existant.
Les vers peuvent aussi être catégorisés d’après les motivations des attaquants qui les ont créés. Celles-ci peuvent être très variées. Il y a des attaquants qui sont poussés par leur curiosité, et qui veulent faire des expériences,
comme dans le cas du ver Morris, ou qui veulent montrer leurs connaissances
dans ce domaine. Il y a aussi ceux qui veulent infliger des pertes financières
à des structures commerciales, ou bien qui veulent gagner de l’argent en
piratant des codes de carte de crédit. Des raisons politiques peuvent pousser
d’autres attaquants à prendre pour cible les ordinateurs d’institutions gouvernementales, etc.
1.1.4
Solutions contre les vers
Des solutions sont proposées pour chaque type de malware,et ceci, dès
sa découverte. Il n’y a pas de solution standard, efficace contre tous les
types de malware, car chacun de ces derniers a ses spécificités, en particulier
dans sa façon de se propager. Ceci rend la conception d’une solution ”passe10
partout” ardue. Comme notre étude est concentrée sur les attaques de vers,
nous allons présenter les solutions qui ont été proposées pour contrer ce type
de malware.
1.1.4.1
Anti-virus
Les anti-virus constituent un moyen de détection pouvant être utilisé
pour contrer les vers. Comme les anti-virus recherchent des signatures caractéristiques de codes malveillants dans les fichiers, ils peuvent ne pas
détecter les vers qui ne font pas encore partie de leur base de données,
ou les vers polymorphiques (vers modifiant leur code binaire à chaque infection). Storm Worm [8] est l’un de ces vers, contre lequel les anti-virus ont
été inefficaces.
1.1.4.2
Veille de sécurité
Faire de la veille de sécurité consiste à se documenter sur les failles de
sécurité existantes pouvant être exploitées par des vers et sur les correctifs
de ces failles. Certains organismes s’occupent de collecter ce type d’informations et de les diffuser, parmi lesquels nous pouvons citer FIRST (Forum
of Incident Response and Security Teams) [10], Cert-IST (Computer Emergency Response Team - Industrie, Services et Tertiaire) [1], FrSIRT (French
Security Incident Response Team) [11]
et HSC (Hervé Schauer Consultants)[14].
1.1.4.3
Patch
Un patch est un programme permettant de mettre à jour un logiciel pour
éliminer les failles qu’il comporte, empêchant ainsi des attaques pouvant
utiliser ces dernières. Pour que cette solution soit efficace, un patch écrit
pour un logiciel donné doit être appliqué par chaque utilisateur de ce logiciel,
ce qui est difficile à réaliser.
1.1.4.4
Audit de code
Il s’agit de l’analyse du code source d’applications (commerciales ou
propriétaires), pour corriger des erreurs d’implémentation qui pourraient
créer des brèches qu’un attaquant pourrait utiliser. Plus particulièrement, il
s’agit de vérifier les commandes permettant l’accès aux zones critiques, telles
que les requêtes SQL, en particulier pour les bases de données propriétaires.
11
1.1.4.5
Test d’intrusion
C’est un test complémentaire de l’audit de code, permettant de découvrir
les vulnérabilités qu’il n’a pas pu repérer, et celles des applications dont le
code source n’est pas disponible. Il s’agit en fait de lancer de vraies attaques contre une application, non malveillantes dans ce cas, afin de tester
si elles peuvent atteindre cette application. Ceci permet de faire sortir les
vulnérabilités de ces applications et de les corriger, en prévention d’attaques
malveillantes pouvant les utiliser [44].
1.1.4.6
Test de vulnérabilité
Les tests de vulnérabilité sont des vérifications récurrentes d’applications, pour s’assurer que les correctifs de sécurité ont bien été appliqués
[44]. Il existe des plates-formes pour effectuer cela en ligne, ainsi que des
CD-ROM et des boı̂tiers pour le faire localement.
Ces tests sont complémentaires des tests d’intrusion.
1.1.4.7
IDS/IPS
Un système de détection d’intrusion (IDS, Intrusion Detection System)
est défini comme étant un ensemble de composants logiciels et/ou matériels
qui servent à détecter et analyser toute tentative d’effraction volontaire
ou non et/ou de maintien dans un système d’informations ainsi que toute
altération éventuelle de ces données [27].
Il peut être ”basé sur la connaissance” ou ”basé sur le comportement”.
Dans le premier cas, l’IDS possède une base de données des attaques déjà
vues et les éléments les caractérisant.
Une attaque est détectée lorsque ces éléments sont observés dans le
réseau. Ce type d’IDS ne peut ainsi pas détecter les nouvelles attaques,
générant ainsi beaucoup de faux négatifs, ce qui peut le rendre peu efficace.
Dans le second cas, l’IDS a une description du fonctionnement normal
du système qu’il protège, et lorsqu’il y a un changement par rapport à ce
comportement, il considère que le système est la cible d’une attaque. Ceci
peut générer beaucoup de faux positifs, ce qui le rend peu fiable.
L’IDS peut aussi être ”basé sur l’hôte” ou ”basé sur le réseau”, selon la
source des informations qu’il utilise pour détecter la présence d’attaques.
12
Après avoir repéré une attaque, l’IDS déclenche une alerte, et c’est ensuite au gestionnaire de sécurité d’effectuer les actions requises pour y faire
face. Un délai peut s’écouler entre ces deux évènements, ce qui est mauvais
pour le système, car il sera pendant ce temps-là sous l’emprise de cette attaque.
D’où l’apparition de l’IPS (Intrusion Prevention System). Il s’agit du
résultat de l’intégration d’actions automatiques à l’IDS, afin qu’il puisse
réagir directement lors de la détection d’attaques, en déconnectant, par
exemple, la machine source de l’attaque. Mais ceci peut poser un problème de
privation : dans le cas d’un faux positif (fausse alerte), un utilisateur légitime
est déconnecté. Une taxonomie plus complète des IDS/IPS est décrite dans
[29]. Snort [18] et l’un des IDS/IPS les plus connus.
1.1.4.8
Firewalls
Le firewall est un système qui autorise ou pas certains flux en se basant
sur des règles statistiques.
Un firewall peut être couplé avec un IDS : après la détection d’une
attaque, une règle est automatiquement ajoutée au firewall pour bloquer
l’adresse qui en était la source. Mais rien ne garantit que cela soit efficace
car cette adresse peut avoir été usurpée.
De plus, des attaquants ont pu prendre le contrôle d’un firewall en utilisant des mécanismes de reconfiguration automatique. En effet, ils ont pu
forcer l’IDS à reconfigurer le firewall en permanence jusqu’à saturer les tables
de ce dernier, le rendant ainsi inexistant et la combinaison risquée.
En revanche, un firewall ne peut pas filtrer les flux cryptés, ni les attaques
applicatives.
1.1.4.9
Honeypots
Un honeypot (pot de miel) (figure 1.1) est un système d’information qui
sert à appâter les attaquants.
Il est inconnu des autres machines du réseau, et, en principe, il n’y a aucune
connexion vers ou depuis un honeypot dans le réseau. Lorsque cela arrive,
il s’agit d’une attaque [24].
13
Un honeypot sert à étudier les mécanismes qu’utilisent les attaquants
pour trouver des solutions efficaces contre leurs attaques.
Figure 1.1 – Pot de miel.
Il existe des honeypots à ”forte interaction” et des honeypots à ”faible
interaction”.
Les premiers implémentent de vrais services, et peuvent par conséquent
subir les actions malveillantes des attaquants. Ils sont ainsi généralement
installés sur des machines virtuelles comme VMware [20]. Ceci facilite le
contrôle et le rétablissement du honeypot après une attaque [9].
Les seconds sont des systèmes qui n’offrent pas de services autres que
ceux nécessaires pour répondre aux tentatives d’identification du système
par les attaquants (le scan par exemple)[9]. Un exemple de logiciel libre est
14
Honeyd [13]. Ce type de honeypots garantit une plus grande sécurité mais il
ne peut pas donner d’information sur les attaques autres que les tentatives
d’intrusion. Ils peuvent aussi être détectés dans le réseau par les attaquants,
du fait du manque de services sur ces machines, ce qui permet à ces derniers de les éviter ou de changer leur comportement pour fournir de fausses
informations [9].
Un bon exemple d’utilisation des honeypots est le projet ”Leurré.com”
[16], qui a été lancé en janvier 2003 par l’institut Eurécom, et qui a pour but
de collecter du trafic anormal sur Internet et d’en étudier les propriétés et les
causes, à des fins de recherche et de développement [9]. Dans le cadre de ce
projet, des honeypots placés dans différents pays, sur différents continents,
sont utilisés.
L’inconvénient principal des honeypots est qu’ils ne peuvent détecter que
ce qui passe par eux, et donc, ils ont une vue assez restreinte de ce qui se
passe dans le réseau.
Le tableau 1.2 résume les solutions que nous venons de présenter, ainsi
que leurs limitations.
1.1.4.10
Autres solutions
Il existe des solutions académiques contre les vers, parmi lesquelles nous
pouvons citer les systèmes proposés dans [26] et [54] qui analysent les paquets transmis dans le réseau, afin de détecter des signatures indiquant qu’un
paquet a été envoyé par un ver. Les solutions proposées dans [58], [57], [43]
et [66] sont aussi basées sur les paquets, et elles tentent de déterminer si
le trafic est anormal et donc potentiellement causé par les activités du ver.
D’autres approches ([37], [35], [40], [62], [41] et [65]) analysent les tentatives
de connexion de machines et déterminent si ces tentatives sont normales ou
bien causées par des vers qui tentent de se propager. Ces systèmes se basent
sur l’observation du trafic et déclenchent des alarmes lorsque des évènements
suspects ont lieu, comme une signature de ver dans un paquet ou une anomalie dans le trafic.
Après avoir décrit les vers, leur taxonomie et les solutions existantes pour
les contrer, nous allons dans ce qui suit présenter les réseaux Pair-à-Pair, car
cela est nécessaire pour comprendre la problématique que nous étudions.
15
Solution
Antivirus
Veille de sécurité
Patch
Audit de code
Test d’intrusion
Test de vulnérabilité
IDS
IPS
Firewall
Honeypot
Description/Limitations
Ne permettent pas de détecter les vers polymorphiques
Vise à devancer les attaquants dans la
découverte de failles et corriger ces dernières.
Solution de prévention et non de détection
N’est efficace que si tous les utilisateurs l’appliquent
Solution de prévention
Solution complémentaire de l’audit de code. Solution de prévention et non de détection
Solution complémentaire des tests d’intrusion
Déclenche une alerte lors de la découverte d’attaque, mais n’applique aucune contre-mesure
automatiquement, ce qui retarde l’arrêt de l’attaque
Intègre l’application automatique de contremesures suite à la détection d’un ver. En cas de
fausse alerte, des utilisateurs légitimes peuvent
être bloqués
Ne permet pas de bloquer les flux cryptés ou les
attaques applicatives
Leurre. Ne permet de détecter que les attaques
qui passent par lui
Table 1.2 – Tableau récapitulatif des solutions contre les vers et leurs limitations.
1.2
1.2.1
Réseaux Pair-à-Pair
Définition
Les réseaux Pair-à-Pair (P2P) sont des systèmes distribués composés de
nœuds interconnectés capables de s’auto organiser pour former des topologies réseau. Leur but est de partager des ressources telles que du contenu,
des cycles CPU ou des capacités de stockage [21].
16
1.2.2
Types de réseaux Pair-à-Pair
Les réseaux P2P peuvent être de plusieurs types. Nous allons les présenter
dans ce qui suit.
1.2.2.1
Réseaux Pair-à-Pair décentralisés
Ce sont des réseaux dans lesquels il n’y a pas de nœud central et où tous
les nœuds ont la même fonction (figure 1.2). Ces réseaux peuvent être de
deux types :
Figure 1.2 – Réseau Pair-à-Pair décentralisé.
– Réseaux Pair-à-Pair décentralisés structurés : C’est dans le cas où la
topologie du réseau P2P est bien contrôlée et où le contenu n’est pas
stocké d’une façon aléatoire mais à des emplacements bien spécifiques,
ce qui aide à avoir une recherche plus efficace. Ceci est réalisé grâce à
des tables distribuées appelées ”tables de hachage”, (DHT (Distributed
Hash Table)), qui contiennent l’information sur les emplacements des
objets (appelés aussi valeurs) de données. Chaque pair a un identifiant
unique dans l’ensemble composé des pairs du réseau, et chaque objet
de données possède un identifiant unique dans l’ensemble des objets
17
du réseau, appelé clé. Les pairs et les objets se partagent le même espace d’adressage. Chaque pair stocke l’information sur l’emplacement
des objets ayant un identifiant proche du sien. Il maintient aussi une
petite table de routage contenant les identificateurs et les adresses IP
de ses voisins, afin de transférer les requêtes aux pairs ayant l’identifiant le plus proche de celui de l’objet recherché. Un exemple de ce
type de réseaux est ”kad” [45].
– Réseaux Pair-à-Pair décentralisés non-structurés : Ce sont des réseaux
que de nouveaux pairs peuvent rejoindre sans en connaı̂tre la topologie.
Le mécanisme utilisé pour envoyer les requêtes à travers ces réseaux
est l’inondation, c’est à dire l’envoi de la requête à plusieurs pairs du
réseau. Chaque pair qui reçoit une requête envoie une liste des objets
correspondant à cette requête au pair qui l’a lancée. Un exemple est
Gnutella [32].
1.2.2.2
Réseaux Pair-à-Pair centralisés
Les réseaux centralisés (figure 1.3) sont des réseaux P2P dans lesquels
il y a une entité centrale qui maintient un index du contenu partagé par
les pairs du réseau. Les requêtes sont envoyées à cette entité, qui envoie
en réponse, en se basant sur cet index, la liste des pairs possédant l’objet
recherché. Le pair demandeur récupère ensuite l’objet recherché directement
à partir du pair le possédant. eDonkey [33] est un exemple de ces réseaux.
Figure 1.3 – Réseau Pair-à-Pair centralisé.
18
1.2.2.3
Réseaux Pair-à-Pair hybrides
Ce sont des réseaux où il existe des pairs, appelés ”super-pairs” ayant des
capacités plus grandes que celles des autres pairs du réseau, et qui ont comme
fonction d’indexer le contenu d’un sous-ensemble de pairs du réseau (figure
1.4). Les requêtes sont envoyées à ces super-pairs qui s’occupent de trouver
des réponses et de les envoyer aux pairs demandeurs. La différence entre
ces réseaux et les réseaux centralisés réside dans le fait que les super-pairs
sont des pairs du réseau, et non des entités dédiées à indexer le contenu de
ces derniers, comme dans le cas centralisé. En effet, chaque pair du réseau
peut être candidat à devenir super-pair, à condition d’avoir les capacités
requises pour occuper cette fonction. Ces réseaux diffèrent aussi des réseaux
décentralisés, où tous les pairs participent à la recherche de contenu. Un
exemple de réseau hybride est KaZaA [36], qui sera présenté dans la section
suivante.
Figure 1.4 – Réseau Pair-à-Pair hybride.
1.2.3
Applications du Pair-à-Pair
Les réseaux P2P peuvent être utilisés dans différents domaines, pour
accomplir différentes tâches. Un premier exemple est la communication et
19
la collaboration. Le but des réseaux P2P dans ce cas est de permettre la
communication et la collaboration entre différentes machines, généralement
en temps réel, comme dans le cas de la téléphonie (exemple : Skype [60]).
Les réseaux P2P peuvent aussi être utilisés pour effectuer du calcul distribué. Ils permettent dans ce cas de tirer profit de la puissance de calcul
des pairs pour réaliser des tâches complexes, en les divisant en différentes
parties et en distribuant ces dernières aux différents pairs. Nous pouvons
citer comme exemple dans ce domaine des projets comme Seti@home [6] et
genome@home [2].
Mais l’application pour laquelle les réseaux P2P sont les plus connus
est la distribution de contenu. Le but des réseaux P2P dans ce cas est de
créer un moyen de stockage qui permet la publication, la localisation et la
récupération de contenu par les pairs du réseau, facilitant ainsi l’échange de
contenu entre pairs.
Toutes ces applications montrent l’utilité que peuvent avoir les réseaux,
et toutes les facilités qu’ils offrent.
1.2.4
Réseaux Pair-à-Pair les plus connus
Nous allons présenter dans ce qui suit quelques réseaux P2P parmi les
plus connus.
1.2.4.1
Gnutella
Gnutella est un système décentralisé non-structuré, qui distribue les capacités de recherche et de téléchargement en établissant un réseau superposé
de pairs. C’est le premier système à avoir utilisé le réseau overlay non structuré.
Les pairs dans Gnutella sont appelés ”servents” (vient des mots ”serveur” et ”client”, car les pairs jouent les deux rôles) [59]. Lorsqu’un nouveau servent veut rejoindre le réseau, il se connecte à un servent de ce dernier
dont l’adresse peut être obtenue à partir de services présents sur l’Internet
et dédiés à cela.
20
1.2.4.2
KaZaA
KaZaA est un réseau hybride dans lequel les pairs peuvent être des nœuds
ordinaires (Ordinary Nodes) ou des super-nœuds (Super Nodes). Chaque
nœud ordinaire est rattaché à un super-nœud, qui indexe son partage. Un
nœud ordinaire envoie sa requête à son super-nœud. C’est ce dernier qui
s’occupe de trouver les réponses à cette requête. Il peut aussi adresser la
requête à d’autres super-nœuds pour qu’ils lui transfèrent leurs résultats.
1.2.4.3
eDonkey
eDonkey est le réseau les plus utilisé en France et en Europe. C’est un
réseau centralisé dans lequel les pairs envoient leur requête à un serveur central qui comporte un index du partage des pairs du réseau. Pour rejoindre ce
réseau, un pair doit se connecter au serveur. Une liste des serveurs existants
est disponible sur l’Internet.
Lors de sa connexion, le pair envoie la liste de son partage au serveur,
puis il l’informe de tout nouveau téléchargement pendant sa présence dans
le réseau. La liste de partage d’un pair présente sur le serveur est mise à
jour après chaque déconnexion et reconnexion du pair au serveur.
Les requêtes des pairs sont envoyées au serveur qui, en se basant sur l’index qu’il gère, donne en résultat les pairs possédant le contenu recherché. Le
pair demandeur télécharge par la suite ce contenu à partir des pairs donnés
en résultat.
Il n’existe pas de communication entre les pairs du réseau eDonkey en
dehors de celle nécessaire pour le transfert de fichiers.
1.2.4.4
BitTorrent
Dans BitTorrent [48], les fichiers partagés sont divisés en ”pièces” identifiées à l’aide de hashs. Un fichier de métadonnées (.torrent) est distribué
à tous les pairs, en utilisant le protocole HTTP en général. Il contient les
hash de toutes les pièces, une correspondance entre les pièces et les fichiers
et un ”tracker” de référence. Le tracker est un serveur central qui gère la
liste de tous les pairs participant à un ”swarm”, qui est un ensemble de
pairs qui participent à distribuer le même fichier. Le tracker ne partage pas
de fichiers. Un pair rejoint un swarm en demandant au tracker une liste de
pairs auxquels il va se connecter. Lorsqu’un pair veut trouver un fichier, il
21
envoie sa requête à un tracker, qui l’informe des pairs possédant des parties
de ce fichier.
1.2.5
Sécurité dans les réseaux Pair-à-Pair
Concernant la sécurité dans les réseaux P2P, il existe quelques mesures
dans certains d’entre eux, comme le cryptage (exemple : KaZaA), ce qui
peut réduire les chances des attaquants de s’introduire dans le flux de communication, la vérification des fichiers avant de les mettre en partage dans
BitTorrent, ou les systèmes de réputation, présentés dans la partie 1.3.4 de
ce rapport, qui permettent aux pairs de donner des notes aux fichiers qu’ils
ont pu télécharger dans le réseau, pour informer les autres pairs si le contenu
de ces fichiers correspond bien à ce qui était attendu ou pas, leur évitant
ainsi de télécharger des fichiers qui peuvent être malveillants. Mais tout cela
reste insuffisant pour protéger les réseaux P2P contre des attaques comme
celles des vers P2P, que nous allons présenter dans ce qui suit.
1.3
1.3.1
Vers Pair-à-Pair
Définition
Un ver P2P est un ver qui se propage à travers un réseau P2P. Les
réseaux P2P permettent à ce nouveau type de vers d’utiliser les vulnérabilités
communes sur les hôtes de ces réseaux.
Les vers P2P ont des caractéristiques qui devraient les placer parmi les
vers les plus répandus dans l’Internet. En effet, ils ont la capacité de se propager rapidement, car ils ne perdent pas de temps à sonder des adresses IP
inutilisées. Leur détection est ardue car ils ne génèrent pas un taux important d’échec de connexion. De plus, ils peuvent se mélanger au trafic normal
du réseau P2P. Le manque de comportement réseau anormal rend les vers
P2P une menace potentiellement plus dangereuse que les autres car la plupart des mécanismes de défense existants contre d’autres vers, comme les
vers à scan, ne sont pas efficaces. Compromettre des systèmes P2P avec un
grand nombre d’hôtes actifs peut facilement accélérer la propagation du ver,
puisque les hôtes dans les systèmes P2P sont réels et actifs. Quelques hôtes
dans les systèmes P2P peuvent avoir des environnements réseau et système
vulnérables, c’est-à-dire des réseaux domestiques et d’entreprise. Comme les
hôtes dans les systèmes P2P maintiennent un certain nombre de voisins pour
des besoins de routage P2P, les hôtes infectés par des vers dans un système
22
P2P peuvent facilement les propager chez leurs voisins P2P, qui, à leur tour,
continuent ensuite cette propagation chez d’autres hôtes du système.
1.3.2
Stratégies de propagation des vers Pair-à-Pair
Un ver P2P peut utiliser l’une des deux stratégies suivantes pour se
propager :
1.3.2.1
La stratégie topologique (ou active)
Dans ce cas, le ver utilise l’information sur les voisins, disponible au
niveau de chaque nœud qu’il infecte, pour trouver de nouvelles victimes. Ceci
permet au ver de se propager assez rapidement, car il ne perd pas beaucoup
de temps à chercher ses victimes. Une hit-liste de victimes potentielles peut
être utilisée pour augmenter la vitesse du ver au début de sa propagation.
1.3.2.2
La stratégie passive
Le ver P2P utilisant cette méthode ne va pas à la recherche de nouvelles
victimes, mais il attend qu’elles viennent vers lui. En effet, dans ce cas, le
ver se trouve parmi les fichiers partagés de la machine infectée, en plusieurs
copies, avec des noms attrayants (comme des noms de films ou de chansons
populaires par exemple). Lorsqu’un nouveau pair télécharge l’un de ces fichiers, en réalité, c’est le ver qu’il télécharge.
Les vers P2P qui ont été lancés jusqu’à maintenant sont des vers passifs.
Un exemple est le ver ”Benjamin”, qui a été lancé en mai 2002, et qui
s’est propagé à travers le réseau KaZaA. Il avait comme action d’ouvrir une
page web pour afficher une publicité. Une liste de vers P2P déjà vus dans
l’Internet est décrite dans [19].
Les vers P2P passifs sont les plus furtifs des vers P2P, car, dans le réseau,
on ne peut pas faire la différence entre le téléchargement d’un fichier sain et
la propagation d’un ver.
1.3.3
Modélisation épidémiologique des vers Pair-à-Pair
Une étape importante dans la lutte contre les vers P2P est de les étudier
pour comprendre leur fonctionnement, et de trouver les solutions les plus
adaptées pour les contrer. Elle permet d’accomplir cela. Elle découle de la
biologie et plus particulièrement la propagation des maladies biologiques.
23
Les modèles définis permettent de comprendre l’évolution du nombre de
pairs infectés dans le réseau et les éléments qui affectent cette évolution. Ceci
aide à comprendre le comportement des vers et de développer des solutions
pour les détecter et/ou ralentir la propagation parmi les pairs. Dans [67], les
auteurs ont présenté différents modèles de la propagation des vers à scan.
Cependant, comme les vers P2P n’ont pas la même méthode de propagation
que les vers à scan, ces modèles ne sont pas adéquats.
Des modèles spécifiques aux vers P2P ont été donnés dans [64], [55] et
[61]. Dans [64], les vers P2P actifs ont été modélisés. Dans [55] et [61], des
modèles ont été proposés pour les vers P2P passifs. Le modèle présenté dans
[55] se focalise sur les réseaux P2P décentralisés. Par contre, celui mis au
point dans [61] est plus complet et décrit un modèle de propagation valable
pour un réseau P2P centralisé et décentralisé. C’est celui que nous allons
étudier en détail, car nous l’utilisons pour reproduire le comportement d’un
ver P2P dans un simulateur de réseau P2P que nous avons conçu, et que
nous allons présenter dans la partie 3.2.1 de ce rapport.
Dans ce modèle, un pair du réseau P2P est considéré comme étant, à
chaque instant, dans l’un des trois états suivants : le pair est dans l’état
”susceptible” (S ) lorsqu’il n’est pas infecté et ne partage aucun fichier infecté. Le pair est dans l’état ”exposé” (E ) lorsqu’il a téléchargé un fichier
infecté mais ne l’a pas encore exécuté. Enfin, le pair est dans l’état ”infecté”
(I ) lorsqu’il a exécuté un fichier infecté. Son répertoire de fichiers partagés
comporte dans ce cas les copies ajoutées par le ver.
Le pair évolue entre ces trois états comme suit :
– De ”susceptible” à ”exposé” lorsqu’il télécharge un fichier infecté.
– D’ ”exposé” à ”infecté” lorsqu’il exécute ce fichier.
– D’ ”infecté” à ”susceptible” lorsqu’il se rétablit (i.e. le ver et toutes
ses copies sont enlevés manuellement de ce pair).
Les équations (1.1), (1.2) et (1.3) ci-après donnent la variation du nombre
de pairs dans chaque état en fonction du temps t, permettant ainsi de simuler la propagation du ver dans le simulateur du réseau P2P.
dI (t)
= −λR I (t) + λE E (t)
dt
24
(1.1)
dE (t)
= −λE E (t) + λS S (t) h (t)
dt
dS (t)
= −λS S (t) h (t) + λR I (t)
dt
(1.2)
(1.3)
Où :
λS est le nombre moyen de fichiers téléchargés par minute par un pair.
λE est le nombre moyen de fichiers exécutés par minute par un pair. λR
est le nombre moyen de pairs qui se rétablissent par minute. h (t) est la
probabilité pour un pair de télécharger un fichier infecté. h (t) = αq (t) avec
α une constante, ainsi la probabilité de télécharger un ver est proportionnelle à la présence du ver dans le réseau. q (t) représente la proportion de
K(t)
où M est le nombre de fichiers non infectés
fichiers infectés : q (t) = K(t)+M
présents dans le réseau, et K(t) est le nombre de fichiers infectés, donné par
l’équation (1.4). Le nombre de copies du ver partagées par un pair infecté
est c.
dK (t)
(1.4)
= S (t) λS h (t) + E (t) λE (c − 1) − I (t) λR c
dt
1.3.4
Détection des vers Pair-à-Pair : les solutions existantes
et leurs limitations
Les vers P2P n’ayant fait leur apparition que pendant la décennie actuelle
(avec l’apparition des réseaux P2P), peu de solutions ont été proposées pour
les contrer. De plus, comme la stratégie de propagation de ces vers diffère
de celles des autres types de vers, les solutions proposées pour ces derniers
ne peuvent s’appliquer aux vers P2P.
Nous allons, dans ce qui suit, présenter les solutions pouvant être utilisées
pour détecter les vers P2P. Nous les classons en deux catégories : basées sur
le pair et basées sur le réseau.
1.3.4.1
Solutions basées sur le pair
Antivirus
Les antivirus peuvent être utilisés pour la détection des vers P2P passifs, mais cette solution reste inefficace car elle ne peut pas permettre la
détection des vers polymorphiques. Comme pour tout autre type de ver, une
fois qu’une signature existe pour celui-ci, cette dernière peut être ajoutée aux
25
différents anti-virus qui peuvent alors détecter la présence du ver en question sur une machine. Il est clair qu’avant la définition d’une telle signature
pour le ver, ce dernier n’est pas repéré, ce qui représente un inconvénient de
taille. De plus, pour que cette détection soit efficace, tous les pairs du réseau
P2P doivent utiliser un anti-virus, ce qui n’est pas toujours le cas.
Noeuds gardiens (Gardian nodes)
Cette solution se base sur des ”nœuds gardiens”, qui sont définis par les
auteurs [39] comme étant des nœuds ayant des capacités de détection de vers.
Lorsque ces nœuds détectent la présence d’un ver, ils déclenchent une alarme
pour avertir les autres pairs du réseau, afin que ces derniers exécutent les actions leur permettant d’éviter l’infection (comme par exemple arrêter l’application défaillante dont use le ver pour intégrer les machines). Ces alertes sont
soumises à un système d’authentification afin d’éviter leur détournement par
d’éventuels attaquants.
La méthode de détection utilisée par les nœuds gardiens se base sur le
contrôle de flux, en exploitant le fait que ce dernier est modifié par le ver
pour exécuter le code malicieux. En la présence de super-pairs dans le réseau,
ces derniers peuvent être utilisés comme nœuds gardiens afin de profiter de
leur grande connectivité, qui peut rendre la détection plus efficace.
Systèmes de réputation
Les systèmes de réputation tels que [14] reposent sur le jugement des
pairs pour identifier les fichiers corrompus. Dans ces systèmes, les pairs attribuent des notes aux fichiers qu’ils ont téléchargés, ce qui constitue la
réputation de ces fichiers. Si un fichier a une mauvaise réputation, il est
alors possible qu’il soit malveillant ou qu’il ne corresponde pas à sa description dans le réseau P2P (fake). Cette solution est plutôt une solution de
prévention et non de détection. En effet, si les pairs du réseau ne téléchargent
pas les fichiers à faible réputation, la propagation des vers pourrait être limitée. Cependant, cette solution ne permet pas de déterminer avec certitude lesquels de ces fichiers sont des logiciels malveillants. Les systèmes de
réputation ne sont donc pas adaptés à la détection des vers P2P.
Un inconvénient commun à toutes ces solutions est le fait qu’elles se
basent sur le pair, ce qui présente le risque que ce dernier n’envoie des
informations erronées pour éviter d’être détecté. De plus, certaines d’entre
26
elles demandent la modification du client.
1.3.4.2
Solutions basées sur le réseau
Les solutions basées sur le réseau, proposées pour détecter les autres
types de vers, et présentées dans la première partie de ce chapitre, pourraient éventuellement être utilisées pour détecter les vers P2P actifs, en
essayant de repérer les pairs qui tentent de chercher à contacter un grand
nombre de pairs du réseau. Mais nous nous attendons à ce que cela génère
beaucoup de faux positifs, car le trafic du ver se mélange très bien avec celui
du réseau P2P. En effet, dans ce type de réseaux, il est tout à fait normal
que des pairs communiquent entre eux et s’échangent des fichiers. Quant
aux vers P2P passifs, il est impossible de les détecter avec ces solutions, car
ils ne génèrent aucun trafic malicieux. En effet, ce sont les pairs victimes qui
vont télécharger le fichier malveillant à partir des pairs infectés. Le comportement de la machine infectée ne présente aucune anomalie.
Les vers P2P passifs sont les plus dangereux, et comme les solutions
basées sur le pair ne sont pas fiables ni facilement applicables, et que les
solutions basées sur le réseau ne permettent pas de détecter les vers passifs,
nous allons nous pencher sur ce problème dans la partie suivante de ce
rapport.
Conclusion
Comme expliqué dans ce chapitre, les vers représentent une menace
sérieuse pour le réseau, et les vers P2P sont parmi les plus virulents d’entre
eux à cause de leur furtivité. Les solutions pour détecter les vers P2P passifs ne sont pas efficaces comme nous avons pu le voir, d’où la nécessité de
proposer des moyens plus efficaces, d’autant plus que les réseaux P2P sont
de plus en plus utilisés pour diffuser du contenu légal, d’où l’importance
d’assurer leur sécurité.
27
Chapitre 2
Proposition d’un mécanisme
de détection de vers
Pair-à-Pair passifs
Résumé
Dans ce chapitre, nous allons présenter un algorithme de détection de
vers P2P passifs ainsi qu’une architecture permettant de l’utiliser. Nous
avons conçu et testé différents algorithmes, jusqu’à obtenir celui qui nous a
donné des résultats satisfaisants, dont un taux de détection élevé et un taux
de faux positifs négligeable.
Introduction
La détection des vers P2P est essentielle pour garantir la sécurité non
seulement des machines du réseau P2P, mais des machines connectées à
l’Internet en entier. En effet, les pairs d’un réseau P2P étant connectés
à l’Internet aussi, ils peuvent contaminer d’autres machines de ce réseau.
Aussi, l’action malveillante de ce type de vers peut toucher les machines
autres que celles faisant partie du réseau P2P. Par exemple, si cette action
consiste à lancer une attaque de déni de service, la cible de cette attaque peut
être n’importe quelle machine connectée à l’Internet. Il est donc important
d’avoir un moyen efficace pour détecter les vers P2P passifs. Comme nous
l’avons présenté dans le chapitre précédent, les solutions proposées dans ce
domaine ne sont pas nombreuses, et elles manquent d’efficacité.
29
Nous allons dans cette partie présenter la solution que nous proposons
pour détecter les vers P2P passifs. Nous nous sommes basés sur notre étude
des vers P2P passifs et des solutions existantes pour définir des critères que
doit remplir notre solution pour être efficace. Tout d’abord, elle doit pouvoir détecter les vers passifs, qui sont les plus furtifs et les plus difficiles à
détecter. Elle ne doit pas nécessiter la participation des pairs du réseau pour
différentes raisons, dont les suivantes : les utilisateurs du réseau P2P peuvent
ne pas avoir assez de compétences techniques ou bien ne pas vouloir activer
et configurer le système de sécurité. Donc, nous ne pouvons pas compter
sur eux pour assurer cette tâche. De plus, dans une solution basée sur les
pairs, il y a le risque que des pairs malveillants perturbent le mécanisme de
détection en fournissant des informations erronées. Aussi, intégrer les pairs
dans une solution de détection requiert des modifications à leur niveau, ce
qui, en pratique, peut présenter certaines difficultés. La solution ne doit pas
non plus se baser sur des signatures du contenu des fichiers qu’utilise le ver
pour se propager, car ce dernier peut modifier ce contenu rendant ainsi la
détection du ver impossible.
La solution ne doit pas générer de faux positifs, ou très peu, car un grand
nombre de fausses détections peut, en cas de la mise en place d’une action
contre les vers détectés, engendrer des problèmes de déni de service (suppression de fichiers sains, blocage de pairs légitimes, ...), et ainsi affecter
la confiance dans la solution. En même temps, elle ne doit naturellement
pas générer de faux négatifs, ou très peu, afin de permettre une éradication
totale et rapide du ver du réseau. Ces deux derniers points sont, de notre
point de vue, les plus importants pour déterminer l’efficacité d’une solution
de détection.
Notre objectif est de proposer une solution qui répond à ces exigences. Ce
chapitre est organisé comme suit : la section 2.1 aborde le cheminement que
nous avons suivi jusqu’à l’obtention d’un algorithme de détection efficace.
La section 2.2 quant à elle décrit l’architecture que nous avons conçue et qui
nous permet d’appliquer notre algorithme de détection.
2.1
2.1.1
Algorithme de détection
Première approche
Les vers P2P passifs ne génèrent aucune anomalie au niveau du trafic
réseau en termes de quantité de trafic ou de connexions, contrairement à
30
d’autres vers, comme les vers basés sur le scan aléatoire par exemple, et qui
peuvent être détectés grâce à ces anomalies. Et comme nous l’avons expliqué
dans l’introduction, la solution ne doit pas se baser sur les pairs.
Nous proposons ainsi de détecter les vers P2P passifs en surveillant
leur comportement dans le réseau, que nous avons décrit dans le chapitre
précédent, qui consiste à ajouter des fichiers dans le partage de chaque pair
infecté. Ce comportement est loin d’être celui d’un pair ordinaire du réseau
P2P. Ainsi, nous allons surveiller la réplication des fichiers dans le réseau
P2P et repérer celles spécifiques aux vers P2P passifs.
Nous allons décrire l’algorithme que nous avons conçu, nommé ”L2 ”, qui
nous permet cela, en utilisant les notations suivantes :
– Si un pair A a téléchargé un fichier (ou une partie de fichier) à partir
d’un autre pair B, B est appelé ”source” du pair A pour ce fichier et
A ”downloader” de B.
– Si un pair a mis en partage un fichier qu’il n’a pas téléchargé du
réseau P2P mais pris, par exemple, de son disque local ou d’un autre
emplacement de stockage de données, ce fichier est dit ”ajouté localement”. Ainsi, l’ensemble des fichiers partagés d’un pair est l’union de
l’ensemble des fichiers qu’il a téléchargés et celui des fichiers qu’il a
ajoutés localement.
– La liste des fichiers ajoutés localement par un pair est notée ”AL”.
Nous considérons par ailleurs que, comme dans le modèle analytique
[61], un pair du réseau P2P est à chaque instant dans l’un des trois états
suivants : susceptible, exposé ou infecté.
Comme expliqué précédemment, un ver passif se propage dans un réseau
P2P à travers les échanges ordinaires de fichiers entre les pairs de ce réseau.
Le ver arrive à s’introduire dans un nouveau pair lorsque ce dernier le
télécharge (sans savoir qu’il s’agit d’un fichier malveillant) à partir d’un
autre pair sur lequel ce ver est déjà présent.
D’autre part, lorsqu’un ver P2P passif se propage à un pair, et qu’il est
ensuite exécuté (rendant ainsi ce pair infecté), il crée de nouvelles copies de
lui et les ajoute au répertoire de fichiers partagés de ce pair. Ces fichiers
sont donc considérés comme ajoutés localement au partage de ce pair.
Par conséquent, nous proposons de détecter les pairs infectés en compa31
rant entre la liste AL d’un pair et les listes AL de ses sources afin de repérer
d’éventuels fichiers en commun, ayant été ajoutés par un ver. Nous allons
illustrer cela par l’exemple suivant : dans la figure 2.1, pour détecter si le
pair P est infecté par un ver P2P passif en utilisant cette technique, il faut
comparer entre sa liste AL et la liste AL de sa source S. Si un ensemble
d’au moins un fichier est détecté comme appartenant aux deux listes, nous
considérons que cet ensemble de fichiers a été ajouté par un ver, et que
les pairs P et S sont infectés. Ceci découle du fait que, selon nous, s’il est
fréquent que différents pairs du réseau P2P téléchargent les mêmes fichiers
(les fichiers populaires par exemple), la probabilité que différents pairs du
réseau ajoutent localement exactement les mêmes fichiers est très faible.
En conclusion, notre critère de détection est le suivant : si deux pairs
P1 et P2 partagent les mêmes fichiers ajoutés localement, et si le pair P1
a préalablement téléchargé un fichier F du pair P2, la probabilité que le
fichier F soit un ver et qu’il ait ajouté localement les fichiers communs aux
deux pairs est très grande.
Figure 2.1 – Arborescence de téléchargement du pair P (SX est le pair
source du pair X, DX est le pair downloader du pair X ).
La table 2.1 décrit (en pseudo-code) l’algorithme L2 que nous avons
conçu, et qui détecte les vers P2P passifs suivant ce critère. La comparaison
entre les AL est faite sur les noms de fichiers d’un côté, et leurs identifiants
de l’autre. Cela permet de détecter, grâce à leurs identifiants, les vers qui,
pour éviter d’être détectés, changent de nom à chaque infection.
32
Table 2.1 – Algorithme L2.
2.1.1.1
Résultats d’évaluation de l’algorithme L2
L’évaluation de l’algorithme L2 consiste à le tester dans un simulateur
de réseau P2P que nous avons conçu et que nous allons présenter dans le
chapitre 3 de ce rapport. Cela nous permet de calculer le taux de détection
(permettant d’avoir le taux de faux négatifs) et le taux de faux positifs.
Nous allons réaliser des simulations avec 21000 pairs dans le réseau. Le
nombre de copies du ver présentes sur une machine infectée est de 10 (le
ver crée à chaque infection 9 nouvelles copies) et le paramètre nbFich de
l’algorithme L2 (table 2.1) est égal à 1.
A la fin de la simulation, qui a duré 33 heures, l’algorithme L2 a détecté
67,19% des pairs infectés (taux de faux négatifs égal à 33,81%) et généré un
33
taux de faux positifs de 36,08%.
Nous allons essayer de comprendre ces résultats. Avant de nous intéresser
aux taux de détection, qui, dépassant les 50%, reste acceptable, nous allons
analyser celui des faux positifs qui est élevé. La présence d’un tel nombre
d’erreurs compromet l’utilisation de cette solution pour détecter les vers
P2P passifs.
Après analyse, nous pouvons donner les deux explications suivantes à
la présence de ces faux positifs : la première est l’ajout, dû au hasard, des
mêmes fichiers non malveillants en local par différents pairs, parmi lesquels
certains sont les sources d’autres pour d’autres fichiers que ceux ayant été
ajoutés localement. Nous nous retrouvons donc dans une situation où la
condition de notre algorithme est remplie, ce qui va provoquer une fausse
détection.
La deuxième explication que nous avons pu trouver est la présence de
pairs exposés initialement (par lesquels l’infection est arrivée, et qui n’ont
pas téléchargé le ver du réseau), ayant une copie du ver qu’ils n’ont pas
encore exécutée, et ne comportant donc pas les autres copies du ver (voir le
modèle analytique de la propagation des vers P2P passifs, dans le chapitre
1 de ce rapport). Ces pairs peuvent être détectés comme infectés alors qu’ils
ne le sont pas encore, car ils possèdent une copie du ver ajoutée localement,
alors qu’ils ne le sont pas encore, car cette copie du ver n’a pas encore été
exécutée.
Le taux de faux négatifs généré est élevé aussi, mais cela est la conséquence
du taux élevé de faux positifs : lors de notre calcul du taux de détection,
nous enlevons le nombre de fausses détections du nombre total de détections,
et divisons le résultat par le nombre total de pairs infectés.
Dans nos tests, nous pouvons reconnaı̂tre les faux positifs en calculant
le délai entre leur infection (dans le simulateur) et leur détection par notre
algorithme. Si le délai de détection d’un pair est négatif, cela signifie qu’il
a été détecté avant d’être infecté, ce pair est considéré comme un faux positif.
Mais un pair peut avoir été détecté comme étant infecté par erreur une
première fois, puis, détecté une deuxième fois, mais, cette fois-ci, il est vraiment infecté. Cependant, pendant l’exécution du processus de détection,
comme ce pair a déjà été détecté comme étant infecté, il ne sera pas ajouté
une seconde fois à la liste de pairs infectés. Donc, lors du calcul du délai de
34
sa détection, il sera considéré comme étant un faux positif. Nous constatons
ainsi que le taux de détection peut baisser à cause de la présence de faux
positifs.
Ainsi, pour améliorer les résultats de notre algorithme, nous allons commencer par tenter de diminuer le nombre élevé de faux positifs, en améliorant
notre méthode de détection.
Nous allons essayer, dans la deuxième approche que nous allons présenter,
d’éliminer la première cause de la présence de faux positifs que nous avons
pu identifier, à savoir les pairs et leurs sources ayant ajouté les mêmes fichiers localement et complètement par hasard.
2.1.2
Deuxième approche
Pour éliminer ce cas, nous proposons d’étendre la comparaison entre les
AL, effectuée dans l’algorithme L2, aux AL des pairs ayant eu des échanges
de fichiers avec les pairs impliqués dans cet algorithme (donc les sources et
downloaders de ces pairs, qui sont potentiellement infectés aussi), car c’est
à travers ces échanges que les vers P2P passifs se propagent. L’objectif est
de diminuer les chances de trouver des fichiers communs à ces AL, et qui
ont été ajoutés localement par les pairs et non pas par un ver.
Nous présentons dans ce qui suit quatre algorithmes, nommés L3, L2D,
L4 et L3D. Nous utiliserons la figure 2.1 pour donner des exemples explicatifs de ces algorithmes, où, à chaque fois, il s’agira de vérifier si le pair P
est infecté. Nous allons ensuite tester ces algorithmes, afin de déterminer le
meilleur d’entre eux, celui qui ne génère pas beaucoup de faux positifs et
détecte le maximum de pairs réellement infectés. Nous utilisons les mêmes
notations que celles de la table 2.1 pour décrire ces algorithmes.
Dans l’algorithme L3, la comparaison est faite entre les AL du pair, ses
sources et les sources de ses sources. Si un même ensemble de fichiers existe
dans la liste AL du pair, celle de l’une de ses sources et celle de l’une des
sources de cette dernière, nous considérons que cela est dû à la présence
d’un ver. Nous nous basons toujours sur le principe suivant : si le pair S est
infecté, il a sûrement téléchargé le ver à partir de l’une de ses sources (sauf
dans le cas où S est un pair exposé initialement, dont la première copie du
ver a été ajoutée localement). Par exemple, dans la figure 2.1, pour vérifier
35
si le pair P est infecté, l’algorithme L3 compare entre P, S et SS (pairs
colorés dans la figure 2.2).
Figure 2.2 – Pairs impliqués dans l’algorithme L3.
L’algorithme L3 est décrit par la table 2.2.
Dans l’algorithme L2D, un ver est détecté si un même ensemble de fichiers existe dans les AL du pair, l’une de ses sources et l’un des downloaders
de cette dernière autre que ce pair (P, S et DS dans la figure 2.3). Si le pair
S est infecté et a infecté le pair P, il a peut-être infecté d’autres pairs parmi
ses autres downloaders.
L’algorithme L2D est décrit par la table 2.3.
Dans l’algorithme L4, un ver est détecté si un même ensemble de fichiers
est présent dans les AL du pair, l’une de ses sources, l’une des sources de
cette source, et l’une des sources de cette dernière. Donc, dans la figure 2.4,
il s’agit des pairs P, S, SS et SSS. Cet algorithme est décrit par la table 2.4.
Dans l’algorithme L3D, un ver est détecté si un même ensemble de fichiers est présent dans les AL du pair, l’une de ses sources et l’une des
sources et l’un des downloaders de cette dernière (le pairs P, S, SS et DS
de la figure 2.5). Cet algorithme L3D est décrit par la table 2.5.
36
Table 2.3 – Algorithme L2D.
2.1.2.1
Evaluation des algorithmes L3, L2D, L4 et L3D
Nous avons implémenté les algorithmes L3, L2D, L4 et L3D dans notre
simulateur, et nous avons évalué leur capacité à détecter les vers P2P passifs. Comme lors de l’évaluation de l’algorithme L2, le réseau P2P simulé
37
Figure 2.3 – Pairs impliqués dans l’algorithme L2D.
Figure 2.4 – Pairs impliqués dans l’algorithme L4.
comporte 21000 pairs, le nombre de copies du ver est égal à 10 et nbFich
est égal à 1. Les résultats de détection et de faux positifs obtenus après 33
heures de simulation sont présentés dans la Table 2.6.
Comme nous pouvons le remarquer à partir de la table 2.6, le taux de
faux positifs diminue avec les nouvelles versions de L2. Mais les résultats
de détection restent équivalents. Ceci peut être expliqué comme suit : plus
nous rajoutons de pairs dans la comparaison, moins les pairs ont de chance
38
Figure 2.5 – Pairs impliqués dans l’algorithme L3D.
d’avoir rajouté les mêmes fichiers localement. Par contre, lorsque cela se
produit, nous n’avons plus 2 pairs comme faux positifs mais plus.
Nous allons maintenant comparer entre les différents algorithmes en utilisant l’espace ROC (Receiver Operation Characteristic) des algorithmes,
39
Table 2.5 – Algorithme L3D.
Algorithme
L2
L3
L2D
L4
L3D
Détection
67,19%
62,52%
74,34%
64,06%
76,05%
Faux positifs
36,08%
11,54%
25,07%
17,90%
18,53%
Table 2.6 – Résultats de simulation avec les algorithmes L3, L2D, L4 et
L3D
dans lequel le taux de faux positifs est en abscisse et le taux de vrais positifs (détection de pairs réellement infectés) est en ordonnée. Donc, chaque
algorithme de détection est représenté par un point dans cet espace, et un
algorithme qui détermine aléatoirement si un pair est infecté ou non (i.e.
taux de faux positifs égal au taux de vrais positifs) sera situé sur la droite
d’équation x=y (ligne de non-discrimination). Plus un point situé sur la
gauche de la droite de non-discrimination est éloigné d’elle, meilleure est la
performance de l’algorithme qu’il représente. Ainsi, afin de comparer entre
les différents algorithmes, nous avons calculé la distance entre la ligne de
non-discrimination et chacun des points les représentant. Les résultats sont
donnés dans la table 2.7.
40
Figure 2.6 – Les algorithmes L2, L3, L2D, L4 et L3D dans l’espace ROC,
avec nbFich = 0.
Algorithme
L2
L3
L2D
L4
L3D
Distance
21,99
36,04
34,83
32,64
40,67
Table 2.7 – Distance entre les algorithmes L2, L3, L2D, L4 et L3D et la
ligne de non-discrimination, avec nbFich = 0.
Comme nous pouvons le constater dans cette table, les points représentant
les algorithmes L3, L2D, L4 et L3D sont plus éloignés de la ligne de nondiscrimination que le point représentant l’algorithme L2. Le point le plus
éloigné est celui qui représente l’algorithme L3D, ce qui fait de lui l’algo41
rithme le plus performant.
Le taux de détection est supérieur à 62% pour tous les algorithmes, ce
qui représente un bon résultat, par contre, le taux de faux positifs reste assez
élevé pour tous les algorithmes (supérieur à 10%), ce qui est inacceptable.
Ce résultat exclut la possibilité que les faux positifs soient générés par la
présence de pairs et leurs sources ayant ajouté les mêmes fichiers localement
par hasard.
Nous allons maintenant étudier notre deuxième piste de source des faux
positifs, la présence de pairs exposés initialement, et essayer de l’éliminer
afin de diminuer le taux de faux positifs.
2.1.3
Troisième approche
Dans l’algorithme L2, un ver est détecté lorsqu’au moins un fichier est
découvert comme appartenant à la AL du pair contrôlé et la liste AL de
l’une de ses sources (paramètre nbFich égal à 1).
Nous proposons maintenant d’augmenter la valeur de nbFich, c’est-à-dire
changer le test de façon à ce que la décision soit basée sur la présence de plusieurs fichiers en commun entre les AL comparées. Cela permettra d’éliminer
le cas où des pairs exposés initialement (n’ayant donc qu’une seule copie du
ver ajoutée localement) sont détectés.
La nouvelle solution a été implémentée en utilisant les deux valeurs suivantes de nbFich : nbFich = 2, afin d’éliminer le cas où l’un des deux pairs
dont les listes sont comparées (le pair ou sa source) a été exposé initialement
(et a sa copie du ver qui a été ajoutée localement), et l’autre l’a été est initialement aussi ou à partir d’un autre pair. La deuxième valeur est nbFich
= 5. Ce choix est basé sur le fait que, si le ver crée moins de 5 copies de lui
sur les pairs infectés, et selon le modèle de propagation [61], il ne peut pas se
propager et finira par disparaitre rapidement sans aucune action de sécurité
externe (cela sera démontré dans la partie 3 de ce rapport). Nous voulons
par cela voir si le taux de détection est affecté par cette modification de la
valeur du paramètre nbFich.
42
2.1.3.1
Evaluation
Nous avons testé l’algorithme L2 dans notre simulateur (présenté dans
la section 3.2 de ce rapport). Le nombre de pairs est toujours de 21000, le
nombre de copies du ver est de 10, et nbFich est égal à 2 puis 5, comme
expliqué précédemment.
Nous avons obtenu un taux de détection de 83,82% (taux de faux négatifs
égal à 16,18%) avec nbFich=2 et 83,66% (taux de faux négatifs égal à
16,34%) avec nbFich= 5, et aucun faux positif dans les deux cas.
Ces résultats sont en accord avec notre deuxième hypothèse, et prouvent
que, dans la version précédente de l’algorithme L2 (avec nbFich = 1), les
faux positifs étaient causés par les pairs exposés initialement.
Le taux de faux négatifs est plus bas qu’avec la version précédente de l’algorithme L2. Il est certes de l’ordre de 16%, mais il faut noter que ce résultat
a été obtenu pendant les 33 premières heures suivant le début de l’infection.
Nous pouvons nous attendre à un taux de faux négatifs moins élevé dans
les heures suivantes. Aussi, en mettant en place des actions pour arrêter la
propagation du ver après sa détection, le taux de détection est assez important pour permettre l’arrêt de la propagation du ver et le rétablissement de
tous les pairs infectés très rapidement. Ce point sera étudié dans le chapitre
4 de ce rapport.
Dans la figure 2.7, nous avons tracé la courbe représentant l’évolution du
nombre de pairs infectés et celui des pairs détectés en utilisant l’algorithme
L2 avec nbFich = 2, nbFich = 5 et nbFich = 1.
Nous pouvons remarquer qu’après quelques heures (environ 6 heures
avec nbFich = 2 et 7 heures avec nbFich = 5), l’algorithme L2 commence
à détecter les pairs infectés, et après 33 heures, il détecte près de 84% des
pairs infectés. Nous pouvons considérer que cette détection est rapide, car,
en la comparant à la durée de vie du ver dans la figure 2.7, nous pouvons
remarquer que le ver commence à être détecté alors qu’il n’a pas atteint
l’état stable.
Nous pouvons aussi remarquer qu’il y a un délai entre le début de l’infection et la première détection de pair infecté, lorsque nbFich est égal à 2
et 5. En effet, la détection ne commence pas en même temps que l’infection.
Nous expliquons ce délai par les valeurs données à nbFich. Dans le cas où
43
Figure 2.7 – Evolution du nombre de pairs infectés et pairs détectés avec
L2 et nbFich ∈ {1, 2, 5}
.
ce paramètre est égal à 2 (respectivement 5), en comparant l’AL d’un pair
S et celle de sa source SS, si l’un des deux pairs est juste exposé, même si
le deuxième est infecté, il ne sera pas détecté, car le nombre de fichiers en
commun ajoutés localement par S et SS sera au plus égal à 1 et n’aura pas
atteint la valeur de nbFich. Mais lorsque l’infection prend de l’ampleur, la
condition de nbFich = 2 (respectivement nbFich = 5) pourra plus souvent
être vérifiée, et ainsi la détection pourra être effectuée.
Sur la figure 2.7, si nous étudions la courbe avec nbFich égal à 1, nous
pouvons remarquer qu’il n’y a pas de délai, et que la détection commence
plus rapidement qu’avec nbFich ayant les valeurs de 2 et 5, car dans ce cas,
dès le début de l’infection, la présence d’une seule copie du ver ajoutée localement par un pair et l’une de ses sources suffit à la détection du ver et
des pairs infectés. Mais, comme nous l’avons vu, cela engendre la détection
44
de pairs initialement exposés, qui représentent des faux positifs.
De notre point de vue, il est plus efficace d’avoir une solution fiable avec
un petit délai avant le début de la détection, qu’une solution qui commence
sans délai et qui donne des erreurs. L’algorithme L2 avec nbFich égal à 2 et
5 ne donne pas de faux positifs. De plus, le délai avant la première détection
n’est pas important. C’est pour cette raison que nous n’utiliserons pas le
paramètre nbFich avec la valeur 1.
Nous pouvons aussi remarquer que la détection avec nbFich = 2 commence avant celle avec nbFich = 5. Ainsi, nous avons choisi d’attribuer la
valeur 2 à nbFich dans L2, que nous utiliserons pour détecter les vers P2P
passifs.
Nous désirons maintenant voir l’effet qu’a la modification de la valeur du
paramètre nbFich sur les algorithmes proposés dans la seconde approche, et
si cela donne de meilleurs résultats qu’avec L2. Ainsi, nous avons effectué la
détection avec les algorithmes L3, L2D, L4 et L3D, avec nbFich = 2 puis
nbFich = 5. Les taux de détection et de faux positifs que nous avons obtenus
sont donnés dans la table 2.8.
Comme nous pouvons le remarquer à partir de cette table, il n’y a pas
de faux positifs, quel que soit l’algorithme utilisé, ce qui confirme le fait que
ces fausses détections sont dues aux pairs exposés initialement. Quant au
taux de détection, il est plus élevé avec L2 qu’avec les autres algorithmes.
Nous expliquons cela par le fait que, dans les algorithmes L3, L2D, L4 et
L3D, il y a plus de pairs impliqués dans le processus de détection que dans
L2. Ainsi, la probabilité de détecter deux ou cinq fichiers ajoutés localement
par chacun de ces pairs ne peut être qu’inférieure à celle avec L2 et, par
conséquent, le taux de détection est aussi moins élevé qu’avec L2.
Comme nous pouvons le remarquer, les résultats de détection avec L3 et
L2D, qui font appel à trois pairs à chaque comparaison, donnent de meilleurs
résultats qu’avec L4 et L3D, qui en impliquent quatre à chaque comparaison.
La figure 2.8 représente l’espace ROC des cinq algorithmes. Nous avons
calculé la distance entre la ligne de non-discrimination et chacun des points
les représentant. Les résultats sont donnés dans la table 2.9.
Comme nous pouvons le constater dans cette table, le point représentant
l’algorithme L2 (avec nbFich = 2 et nbFich = 5) est celui qui est le plus
45
Algorithme
L2
L3
L2D
L4
L3D
nbFich = 2
Détection Faux positifs
83,82%
0%
66,19%
0%
75,05%
0%
64,77%
0%
73,04%
0%
nbFich = 5
Détection Faux positifs
83,52%
0%
66,66%
0%
74,7%
0%
56,37%
0%
69,08%
0%
Table 2.8 – Résultat de simulation pour L3, L2D, L4 et L3D avec nbFich
∈ {2, 5}
Figure 2.8 – Les algorithmes L2, L3, L2D, L4 et L3D dans l’espace ROC,
avec nbFich ∈ {2, 5}
.
éloigné de la ligne de non-discrimination.
Ainsi, d’un côté, nous avons des résultats de détection meilleurs avec L2
qu’avec les autres algorithmes proposés, et d’un autre côté, L2 est l’un des
46
Algorithme
L2
L3
L2D
L4
L3D
Distance
nbFich = 2 nbFich = 5
0,59
0,59
0,46
0,47
0,53
0,52
0,47
0,39
0,51
0,48
Table 2.9 – Distances entre les algorithmes L2, L3, L2D, L4 et L3D et la
ligne de non-discrimination, avec nbFich ∈ {2, 5}
algorithmes les moins complexes. En effet, nous avons calculé la complexité
des algorithmes. L2, L3 et L4 ont une même complexité de l’ordre de O(N)
(N représentant le nombre de pairs du réseau P2P). La complexité des algorithmes L2D et L3D est de O(N 2 ), car ces algorithmes utilisent dans leur
mécanisme de détection les downloaders, qui sont retrouvés via un calcul à
partir de l’information sur les sources.
Compte-tenu de tous ces éléments, le meilleur algorithme à utiliser dans
notre solution de détection est l’algorithme L2 avec le paramètre nbFich
égal à 2 (qui a donné des résultats de détection un peu plus élevés qu’avec
nbFich égal à 5).
Ainsi, nous avons pu concevoir un algorithme peu complexe, qui permet
de détecter les vers P2P passifs sans erreurs.
Maintenant l’algorithme défini, il nous faut décrire une architecture permettant de l’utiliser.
2.2
Architecture de détection
La solution de détection de vers P2P passifs que nous proposons est
conçue pour être mise en œuvre par un opérateur de réseau. Comme expliqué
dans la partie précédente, l’algorithme de détection, qui se base sur le comportement des vers P2P passifs pendant leur propagation, a besoin d’avoir
accès à des informations sur les listes de fichiers partagés et les sources
des pairs du réseau. Nous allons présenter une architecture, que nous avons
conçue, et qui nous permet d’avoir ces informations.
47
L’algorithme de détection est exécuté dans le centre de détection (le
cercle rouge sur la droite de la figure 2.9) toutes les m minutes (m étant un
paramètre prédéfini), et il contrôle tous les pairs ayant téléchargé des fichiers
entre les instants t et t+m, et donc qui sont susceptibles d’avoir téléchargé
un ver.
L’opérateur doit mettre en place des sondes dans le réseau pour superviser le trafic P2P émis et reçu par les pairs. Ces sondes envoient des notifications au centre de détection quand elles observent des messages d’envoi
ou de mise à jour (après le téléchargement d’un nouveau fichier) de la liste
de fichiers partagés d’un pair, provenant de ce dernier et adressés au serveur d’indexation, ou de messages d’échange de fichiers entre deux pairs.
Elles peuvent être situées dans les boxes ou les passerelles domestiques des
pairs, mais aussi dans le réseau d’accès de l’opérateur où elles sont destinées
à superviser le trafic de plusieurs pairs en même temps. Afin de limiter
le nombre de messages envoyés au centre de détection par les sondes, ces
dernières peuvent mettre dans un cache leurs notifications et en envoyer,
périodiquement, plusieurs dans un seul message.
Les notifications envoyées par les sondes permettent au centre de détection
de mettre à jour ses données, qui comportent :
– la liste des fichiers partagés (identifiant et nom) qui ont été téléchargés
par chaque pair.
– la liste des fichiers partagés qui n’ont pas été téléchargés (c’est-à-dire la
liste AL) pour chaque pair. Cette liste n’est pas obtenue directement
des notifications des sondes, mais en soustrayant la liste de fichiers
téléchargés d’un pair de sa liste totale de fichiers partagés.
– les sources de chaque pair pour chacun de ses fichiers partagés (téléchargés
bien sûr).
En effet, dans un réseau P2P centralisé, nous pouvons avoir les listes de
partage des pairs à partir du réseau. Elles peuvent être reconstituées grâce
aux différents messages envoyés par les pairs au serveur. Par exemple, dans
un réseau eDonkey, lors de sa connexion à un serveur, le pair envoie la liste
complète de son partage à ce dernier. Puis, après la fin d’un téléchargement,
le pair qui a téléchargé un nouveau fichier envoie un message contenant des
informations sur le fichier téléchargé au serveur, et grâce auxquelles ce dernier met à jour son index.
48
Figure 2.9 – Architecture de détection.
Cette architecture nous permet d’obtenir toutes les informations nécessaires
à l’application de notre algorithme de détection.
Ainsi, nous avons pu proposer une solution composée d’un algorithme de
détection de vers P2P passifs pertinent et une architecture permettant de
l’utiliser. Nous allons démontrer l’efficacité et la faisabilité de cette solution
par étude analytique et des simulations dans le chapitre suivant.
Conclusion
Dans ce chapitre, nous avons proposé plusieurs algorithmes que nous
avons étudiés et testés dans le simulateur que nous avons conçu et développé,
et qui sera présenté dans la section 3.2. Grâce aux simulations que nous avons
réalisées, nous avons sélectionné le meilleur (grand taux de détection, faible
taux de faux positifs), et qui de plus remplit les exigences que nous avons pu
définir à travers notre étude bibliographique du chapitre 1, dont celle de la
détection des vers non connus. Nous avons aussi pu définir une architecture
de détection qui permet de détecter le ver dans le réseau, malgré l’absence
de trafic suspect de ce type de vers dans le réseau. Ceci a pu être réalisé
grâce à un algorithme de détection qui se base sur le comportement du ver
dans sa propagation et non sur le trafic qu’il génère.
49
Chapitre 3
Evaluation de la solution de
détection
Résumé
Dans le chapitre précédent, nous avons pu tester l’efficacité de notre algorithme de détection en termes de taux de détection et taux de faux positifs,
à l’aide de simulations. Dans ce chapitre, nous allons prouver l’efficacité de
notre algorithme, tout d’abord, en prouvant que le taux de faux positifs qu’il
génère est négligeable par une étude analytique. Nous allons ensuite nous
intéresser aux méthodes de contournement pouvant être utilisées par les vers
et prouver que notre algorithme reste efficace face à elles.
Nous étendons notre étude analytique pour prouver la faisabilité de l’architecture de détection que nous proposons, en calculant son coût, la puissance de calcul et la taille mémoire qu’elle requiert, et la possibilité de son
passage à l’échelle.
La dernière partie de ce chapitre est consacrée à quelques tests supplémentaires
réalisés dans le simulateur que nous avons conçu et implémenté et que nous
allons présenter dans ce chapitre.
Introduction
L’efficacité d’une solution de détection passe par un taux faible de faux
positifs et une grande proportion de pairs infectés détectés. Elle ne doit pas
avoir de failles pouvant être utilisées par des attaquants potentiels pour la
51
contourner, et elle doit aussi être réalisable. Nous allons dans ce qui suit
vérifier si notre solution passe bien tous ces points de contrôle.
3.1
Evaluation par étude analytique
Nous allons, dans ce qui suit, évaluer analytiquement notre solution de
détection. Tout d’abord, nous allons évaluer l’algorithme de détection L2,
en nous intéressant plus particulièrement au nombre de faux positifs qu’il
génère et à l’effet des techniques de contournement, que peuvent utiliser des
vers P2P passifs, sur le nombre de faux négatifs qu’il donne. Nous allons
ensuite évaluer notre architecture en calculant les coûts qu’elle génère en
termes de bande passante, mémoire et puissance de calcul.
3.1.1
Faux positifs générés par l’algorithme de détection
Dans cette partie, nous voulons calculer le taux théorique de faux positifs
de l’algorithme L2. Un faux positif est obtenu lorsque deux pairs ajoutent
localement, par hasard, les mêmes fichiers non infectés, et que l’un des deux
pairs est source de l’autre pour un autre fichier qui n’est pas infecté. Dans
ce qui suit, la valeur attribuée à nbFich est 2, le même raisonnement reste
valable pour les autres valeurs de nbFich.
Tout d’abord, nous définissons les notations suivantes :
– p est un pair ayant n sources appelées S1 , S2 ,. . ., Sn .
– le pair p a m fichiers dans sa liste de fichiers partagés, nommés f1 ,
f2 ,. . ., fm .
– Ap,f est l’évènement suivant : ”le pair p a ajouté localement un fichier
non infecté f à sa liste de fichiers partagés”.
– Lp,f est l’évènement suivant : ”le fichier non infecté f a été ajouté
localement par le pair p ainsi que par au moins l’une des sources de
p, par hasard”.
– F Pp est l’évènement suivant : ”le pair p a été à l’origine d’un faux
positif”.
– P r(E) est la probabilité de l’évènement E.
A partir de ces définitions, nous obtenons d’une façon directe, pour
chaque fichier f de la liste des fichiers partagés d’un pair p, l’équation (3.1).
52
Lp,f =
n
[
(Ap,f ∩ ASi ,f )
(3.1)
i=1
Ainsi, un faux positif peut être généré par L2 si deux fichiers de la liste de
fichiers partagés du pair p sont ajoutés localement par au moins l’une des
sources de p. Les deux fichiers peuvent être le résultat de n’importe quelle
combinaison de deux fichiers de la liste f1 , f2 ,. . ., fm . Le nombre de ces
combinaisons est ainsi le nombre de façons de choisir 2 éléments à partir
de l’ensemble de taille m. A partir de la définition de Lp,f et la définition
donnée d’un faux positif, nous pouvons écrire l’équation (3.2)
F Pp =
m
[
(Lp,fi ∩ Lp,fj )
(3.2)
i,j=1; i6=j
m
termes.
Il est à noter que l’équation (3.2) est l’union de
2
L’algorithme L2 est appliqué à chaque pair qui a effectué un téléchargement,
car, comme expliqué précédemment, cela représente un moment critique où
un ver peut se propager à ces pairs. Bien évidemment, chacun de ces pairs
est susceptible d’être à l’origine d’un faux positif (évènement F Pp ). La probabilité de l’évènement F Pp peut être calculée à partir des probabilités des
évènements Ap,f que nous allons évaluer dans ce qui suit.
Nous définissons d’abord les notations supplémentaires suivantes :
– P opf est le nombre de pairs qui partagent le fichier f (c’est-à-dire la
popularité du fichier f ).
– N est le nombre total de pairs dans le réseau superposé.
– α est la proportion de fichiers partagés qui ont été ajoutés localement.
A partir de ces notations, nous pouvons exprimer P r (Ap,f ) avec l’équation (3.3).
P r (Ap,f ) = α
53
P opf
N
(3.3)
Le niveau de popularité des fichiers dans un réseau P2P a déjà été étudié
dans [56]. Nous pouvons observer que la valeur de P opf est limitée par
N
α
100 , donc Pr(Ap,f ) est limitée par 100 . Les évènements Ap,f et Lp,f sont
indépendants les uns des autres, et nous savons que lorsque nous avons deux
évènements indépendants A et B, la probabilité de leur union est celle décrite
par l’équation (3.4).
P r (A ∪ B) = P r (A) + P r (B) − P r (A) P r (B)
(3.4)
Ainsi, en combinant les équations (3.1), (3.2) et (3.4), nous pouvons calculer la probabilité P r(F Pp ) de l’évènement F Pp en fonction des probabilités P r(Ap,f ). Ceci a été calculé récursivement à l’aide d’un programme que
nous avons développé. Comme l’algorithme L2 est exécuté une fois toutes
les x minutes (x étant un paramètre prédéfini), et selon le modèle analytique
présenté dans [61], le nombre de pairs qui auront terminé un téléchargement
pendant cet intervalle de temps est x ∗ λS ∗ N (pour rappel, λS est le nombre
moyen de fichiers téléchargés par minute et par pair). Donc, le nombre de
faux positifs générés durant cette période est égal à x ∗ λS ∗ N ∗ P r(F Pp ).
Avec les valeurs P r(Ap,f ) = 10−3 pour tout p et f, n = 20, m = 200, x =
10 minutes, λS = 3, 47 ∗ 10−4 téléchargements par minute, nous obtenons
6 ∗ 10−5 faux positifs par minute.
Avec des valeurs plus élevées de nbFich, nous obtenons bien évidemment
un nombre de faux positifs plus réduit.
Pour nbFich = 1, (le cas où la présence d’un seul fichier ajouté localement par un pair et l’une de ses sources suffit pour qu’une détection soit
effectuée), et en utilisant les mêmes valeurs que pour le cas nbFich = 2, nous
obtenons 0,03 faux positifs par minute, ce qui donne approximativement 60
faux positifs après 2000 minutes de détection.
Si nous considérons que le nombre de pairs infectés à ce moment est 832
(suivant les simulations effectuées dans le chapitre 2), et que 85% d’entre
eux sont détectés, le taux de faux positifs atteint 8,48%.
En conclusion, si nbFich est égal à 1, quelques faux positifs sont générés,
comme nous l’avons vu dans le chapitre précédent, par les pairs exposés
54
initialement. Mais lorsque nbFich est strictement supérieur à 1, la probabilité de présence de faux positifs devient tellement petite qu’elle est
négligeable (6 ∗ 10−5 faux positifs par minute ou moins). Ceci confirme
les résultats de faux positifs obtenus par les simulations que nous avons
effectuées précédemment.
3.1.2
Effet des méthodes de contournement éventuelles sur
les résultats de détection
Lorsqu’un réseau est protégé par un système de détection d’intrusions, les
attaquants tentent de trouver des solutions pour le contourner en étudiant
son fonctionnement et essayant de lui trouver des brèches. Un système de
sécurité est efficace lorsqu’il ne peut pas être contourné. Nous allons dans
ce qui suit étudier les possibilités que pourraient avoir les attaquants pour
passer à travers notre solution de détection.
En analysant le fonctionnement de notre algorithme de détection L2,
nous avons pu identifier quelques cas. Le premier est si le ver n’utilise pas
la même liste de fichiers à chaque fois qu’il infecte un pair. En effet, comme
notre algorithme se base sur la présence de fichiers identiques ajoutés localement entre un pair et l’une de ses sources, le ver pourrait agir comme
expliqué ici afin que la comparaison entre les listes de partage donne dans
ce cas un résultat nul.
Le second cas est celui où le ver ajoute un nombre de copies inférieur
à la valeur du paramètre nbFich sur le pair qu’il infecte, afin d’éviter la
détection.
Le troisième et dernier cas que nous avons pu identifier est celui où le pair
ne crée pas de copies de lui sur toutes les pairs qu’il infecte, en alternant de
sorte à ne pas permettre d’avoir des fichiers malveillants ajoutés localement
sur un pair et ses sources, afin de gêner sa détection. Nous allons maintenant
étudier l’effet de chacun de ces cas sur notre algorithme de détection.
3.1.2.1
Vers n’utilisant pas la même liste de noms de fichier à
chaque infection
Comme les attaques de vers évoluent constamment, les vers P2P passifs pourraient ne pas utiliser la même liste de noms de fichiers à chaque
infection. Au lieu de cela, ils pourraient choisir, d’une façon aléatoire, des
noms de fichiers à partir d’une liste pré-générée de noms attractifs pour les
55
utilisateurs, dans le but de rendre leur détection difficile.
Nous pouvons nous attendre à une augmentation du grand nombre de
faux négatifs générés par notre algorithme de détection, car il pourrait ne
pas trouver assez de noms de fichiers en commun entre un pair infecté et sa
source, même si cette dernière l’est aussi.
Dans ce qui suit, nous voulons estimer le nombre de faux négatifs dans
ce cas. Nous nous intéressons plus particulièrement à la probabilité P (δ)
que deux pairs infectés aient δ noms de fichiers en commun, s’ils ont tous
les deux choisi aléatoirement α noms parmi une liste de β noms possibles.
Soient p1 et p2 deux pairs infectés. Nous supposons que sur le pair p1 ,
le ver s’est répliqué en α fichiers avec des noms choisis parmi une liste de β
noms. Calculons le nombre de possibilités pour p2 de choisir α noms parmi
la liste de β alors qu’il a exactement i noms en commun avec p1 (i est un
entier compris entre δ et α). Le pair p2 doit d’abord choisir i noms parmi les
α noms choisis par p1 et ensuite les (α - i ) restants parmi les (β - α) noms
non choisis par p1 , car les deux pairs ont exactement i noms en commun.
Le nombre de possibilités pour p2 de choisir des noms est donc exprimé par
(3.5) :
β−α
α
α−i
i
(3.5)
Afin d’obtenir le nombre de possibilités pour p2 de choisir des noms
pour avoir au moins δ noms en commun avec p1 , nous devons ajouter les
possibilités pour p2 d’avoir exactement δ noms en commun, plus les possibilités d’avoir exactement (δ + 1) noms en commun, plus les choix d’avoir
exactement (δ + 2) noms en commun, et ainsi de suite. Le nombre total de
possibilités d’avoir au moins δ noms en commun peut être écrit comme suit :
α X
β−α
α
i=δ
α−i
i
56
(3.6)
Si nous divisons le nombre calculé dans (3.6) par le nombre total de possibilités qu’a p2 de choisir α noms parmi une liste de β, nous obtenons la
probabilité que nous recherchons, exprimée par l’équation (3.7).
P (δ) =
β−α
α
i=δ
α−i
i
β
α
Pα
(3.7)
En nous basant sur des vers typiques observés dans les réseaux P2P tels
que KaZaA ou eDonkey (cf [50], [51], [52], [34]), nous choisissons α = 15 et
β = 80. Avec ces valeurs, nous obtenons P (1) = 0, 97 et P (2) = 0, 83. Ceci
implique que la probabilité que deux pairs infectés aient au moins un nom de
fichier en commun est de 97%, et qu’ils aient au moins deux noms en commun
est de 83%. Dans le second cas, l’algorithme exécuté avec nbFich = 2 génère
une augmentation de faux négatifs de 17% seulement. Donc, la détection des
vers P2P passifs dans ce cas de tentative de contournement reste possible,
et avec une bonne solution de mitigation, l’arrêt de la propagation du ver
est possible, l’augmentation des faux négatifs n’étant pas grande.
3.1.2.2
Nombre de copies du ver inférieur au paramètre nbFich
de l’algorithme L2
Le ver pourrait ne pas ajouter de copies sur les machines qu’il infecte,
ou bien n’en ajouter qu’une seule, afin que le nombre de fichiers malveillants
pouvant être trouvés en commun entre un pair et sa source soit inférieur au
seuil de deux fichiers (paramètre nbFich égal à deux) fixé dans l’algorithme
L2 et permettant de détecter la présence du ver.
Cela permet certes au ver d’être furtif, mais à première vue, cela ne
lui permet pas de se propager efficacement. Selon nous, le ver ne va pas
créer assez de copies dans le réseau P2P, diminuant ainsi ses chances d’être
téléchargé par d’autres pairs. Il est donc amené à disparaı̂tre rapidement
sans l’aide d’une quelconque action de sécurité. Ceci est appuyé par la figure 3.1, qui représente l’évolution du nombre de pairs infectés avec c égal à
1, 2 et 5 suivant le modèle analytique présenté dans [61]. Nous pouvons remarquer à partir de cette courbe que lorsque le nombre de copies du ver est
égal à 1, la courbe décroit rapidement jusqu’à atteindre l’axe des abscisses.
57
Nous avons calculé le nombre minimum de copies que doit créer le ver
sur les machines qu’il infecte afin d’avoir la possibilité de se propager efficacement. Ce nombre est donné par l’équation (3.8), que nous avons obtenue
à partir de l’équation (14) dans [61] (les variables sont celles décrites dans
le modèle analytique présenté dans la partie 3 du chapitre 1).
Figure 3.1 – Evolution du nombre de pairs infectés dans le réseau pour c
∈ {1, 5, 10}
.
µmin =
λR (M − (N τ ))
N λE
(3.8)
En utilisant les valeurs de simulation de la table 3.1, nous obtenons µmin
= 4,7 copies. Ceci implique que si le ver crée moins de 5 copies de lui à chaque
infection, il disparaitra complètement du réseau grâce aux rétablissements effectués par les utilisateurs (paramètre λR du modèle [61]), et sans la nécessité
58
d’avoir l’appui d’une solution de détection.
3.1.2.3
Création non systématique de copies par le ver
Un autre moyen que peut avoir le ver pour perturber le fonctionnement
de l’algorithme de détection est de ne pas créer de copies de lui à chaque
infection, mais d’en créer sur un pair et pas sur ses downloaders, ou inversement. Ceci ne permet pas de trouver de fichiers appartenant à la liste de
fichiers ajoutés localement du pair contrôlé ainsi qu’à celle de sa source, et
la détection du ver n’est donc pas possible dans ce cas.
Nous considérons qu’il n’est pas facile de créer ce type de vers, car il faudrait que le ver puisse suivre l’évolution de l’infection, et avoir connaissance,
lors de chaque infection, des pairs qu’il a déjà infectés, et s’il y a eu ajout
de copies ou pas sur ces derniers, afin de savoir s’il doit ajouter des copies
ou pas lors de l’infection en cours. Cette tâche peut être compliquée par des
systèmes comme eDonkey qui permettent de télécharger un fichier à partir
de plusieurs sources. Dans ce cas, il est probable que certaines des sources
du ver contiennent des copies de celui-là ajoutées localement, et d’autres
pas. Comment doit agir le ver dans ce cas ? S’il n’ajoute pas de copies, cela
diminue ses chances de se propager. S’il en ajoute, cela permettra à notre
algorithme de détection de le détecter.
Après discussion des différentes méthodes de contournement possibles,
nous avons pu prouver que notre algorithme de détection peut faire face à
toutes les tentatives de contournement dont il pourrait faire l’objet.
3.1.3
Architecture de détection
Nous voulons maintenant vérifier si notre solution de détection est réaliste
et si elle peut être déployée dans le réseau. Ceci dépend des coûts de l’architecture de détection en termes de bande passante, ainsi que de ses exigences
en termes de puissance de calcul et de mémoire.
3.1.3.1
Coût de l’architecture
Les coûts de l’architecture de détection comprennent les coûts d’installation et ceux d’exploitation. L’opération du système de détection consomme
de la bande passante dans le réseau cœur pour les communications entre les
sondes et le centre de détection. En effet, une notification est envoyée par
59
une sonde à chaque fois qu’un téléchargement est effectué dans le réseau et
à chaque fois qu’un pair envoie sa liste de fichiers partagés à un super-pair,
comme décrit dans la présentation de l’architecture (section 5.2). La bande
passante (BP ) consommée est ainsi exprimée par l’équation (3.9).
BP = N (λD SD + λU SU )
(3.9)
Avec N représentant le nombre de pairs surveillés, λD le taux de téléchargements
accomplis par pair par seconde, et SU la taille de la notification pour une
mise à jour. Typiquement, λD est, en moyenne, au maximum égal à 5
téléchargements par pair par jour d’après [61], et λU est égal à une mise
à jour par pair par jour. La notification pour un téléchargement accompli
contient le nom et l’identifiant du fichier téléchargé et les sources du pair
pour ce fichier. Ainsi, SD est limité par 400 octets. Si nous limitons le nombre
de fichiers dans une liste de fichiers partagés par 200, nous observons que SU
est limité par 125 Ko. Si N est égal à un million de pairs, la bande passante
consommée est ainsi limitée par 88 Mo/s.
3.1.3.2
Puissance de calcul
Afin d’estimer la puissance de calcul requise par notre solution de détection,
essentiellement pour la comparaison entre les listes de partage, nous commençons par donner une estimation du nombre de ces comparaisons. Dans
le cas de l’algorithme L2, la liste de fichiers d’un pair est comparée avec
chacune des listes de ses sources. Le nombre de comparaisons NCOM P est
ainsi donné par l’équation (3.10).
NCOM P = NDL ∗ NSRC
(3.10)
avec NDL représentant le nombre de pairs qui ont effectué un téléchargement,
et NSRC , le nombre de sources d’un pair. NSRC est limité par 20 et NDL
est égal à N ∗ λD . Ainsi, avec N égal à un million de pairs, le nombre de
comparaisons par seconde pour L2 est limité par 1 160.
Pour les algorithmes L3 et L2D, NSRC est limité par 20 + 202 car le
nombre de sources de sources est limité par 202 . Pour les algorithmes L4 et
60
L3D, NSRC est limité par 20 + 202 + 203 (donc 8 420). Par conséquent, L3 et
L2D ont une complexité de 24 300 comparaisons par seconde et L4 et L3D
de 487 000 comparaisons par seconde. En conclusion, la bande passante et
la puissance de calcul requises par le centre de détection sont réalistes, du
moins pour l’algorithme L2.
Les autres algorithmes peuvent être plus coûteux, selon le nombre de
sources de sources et de downloaders. Cependant, comme l’algorithme L2
avec nbFich = 2 a montré son efficacité pour détecter les vers P2P passifs,
et après le calcul de son coût, nous pouvons affirmer que notre solution de
détection est réalisable.
3.1.3.3
Taille mémoire
Nous tentons maintenant de déterminer la taille mémoire requise par le
centre de détection. Ce dernier doit sauvegarder la liste de fichiers partagés
de chaque pair, ainsi que le nom, l’identifiant, et la liste des sources de chacun
de ces fichiers. La taille mémoire requise pour le nom de fichier, l’identifiant
et la liste de fichiers est limitée par 400 octets. Si la taille moyenne d’une
liste est inférieure à 200 fichiers, et avec 1 million de pairs, nous obtenons
moins de 80 Go de taille mémoire.
Ainsi, même si elle peut être plus coûteuse que les autres besoins étudiés ici,
la taille mémoire nécessaire à notre solution de détection reste réaliste.
3.1.3.4
Passage à l’échelle
Notre solution de détection permet le passage à l’échelle, car, d’après
les calculs que nous avons effectués précédemment, les coûts augmentent
linéairement suivant le paramètre N, qui représente le nombre de pairs.
Dans les cas les plus élevés du paramètre N, nous proposons une amélioration
qui est de distribuer la collecte d’informations sur les différentes sondes du
réseau de détection (figure 2.9), de sorte qu’à chaque sonde soient assignés
des pairs (c’est-à-dire que cette sonde doit collecter les listes de fichiers partagés et les sources des fichiers de ces pairs).
En conclusion, la solution que nous avons conçue peut bien être implémentée.
61
3.2
Evaluation par simulations
Après avoir testé notre solution avec une étude analytique, et prouvé
son efficacité en termes de faux positifs, résistance aux attaques de contournement et faisabilité, nous allons compléter notre évaluation de la solution
en étudiant, avec des simulations, des points que nous n’avons pas pu englober dans l’étude analytique du fait de la complexité des calculs qui leur
sont dû. Pour cela, nous allons utiliser un simulateur que nous avons conçu
et implémenté, et que nous allons présenter dans ce qui suit. L’utilisation
de simulateur pour tester notre solution au lieu d’un réseau réel ou de test
(testbed ) est motivé par le fait que manipuler des vers dans un réseau réel
peut s’avérer dangereux et le nombre de pairs dans un réseau de test est
limité et ne permet pas d’avoir une représentation réaliste du réseau P2P.
3.2.1
Simulateur
Il existe bien des simulateurs de réseaux P2P structurés (P2PSim [53],
Overlay Weaver [3]), non-structurés (Query-Cycle Simulator [4]), et les deux
en même temps (NS-2 [15], PeerSim [5], GPS [28], OMNet++ [49], OverSim
[17]).
Cependant, nous avons choisi de développer notre propre simulateur pour
les raisons suivantes : tous ces simulateurs n’intègrent pas la représentation
de la propagation des vers P2P passifs, dont nous avons besoin pour tester notre solution. De plus, dans le cadre de cette évaluation, nous devons
récupérer des statistiques spécifiques comme le taux de faux positifs, et nous
devons faire varier des paramètres de l’algorithme de détection comme le
nombre de copies du ver pour tester l’efficacité de cet algorithme. Réaliser
ces actions peut s’avérer complexe dans un simulateur qui n’intègre même
pas la propagation d’un ver P2P passif par exemple. Il est à noter que les
travaux sur les réseaux P2P sont majoritairement évalués en utilisant des
simulateurs propriétaires.
Nous avons conçu un simulateur que nous avons implémenté en Java. Il
reproduit le fonctionnement normal d’un réseau P2P centralisé, c’est à dire
sans la présence de vers, ainsi que la propagation d’un ver P2P passif dans
ce réseau. Il est illustré par la figure 3.2.
62
Simulation du fonctionnement normal du réseau P2P
Cela passe par la simulation des échanges de fichiers dans un réseau P2P,
qui englobe les actions de recherche et de téléchargement, et qui est réalisée
par le module ”Simulateur du réseau P2P” de la figure 3.2.
Afin d’initialiser les données de notre simulateur, nous avons utilisé une
capture du réseau eDonkey effectuée entre le 9 décembre 2003 et le 2 février
2004, dans le cadre des travaux présentés dans [56] où les auteurs ont réalisé
et utilisé cette capture pour étudier le comportement des pairs dans ce
réseau en fonction de la popularité des fichiers, la distribution du partage et
la présence de clustering géographique et sémantique entre les pairs, entre
autres.
Les données contenues dans cette capture sont les listes quotidiennes de
fichiers des différents pairs mises à disposition dans le réseau. Mais pour
simuler les échanges de fichiers, nous avons aussi besoin d’informations sur
les sources des pairs pour les fichiers qu’ils ont téléchargés, ce qui n’est pas
fourni par cette trace.
N’ayant pas ces informations, et afin de simuler le réseau P2P dans
son fonctionnement normal, nous initialisons au début de la simulation les
listes de fichiers partagés des pairs avec les données du premier jour de
leur connexion au réseau. Ces fichiers sont ainsi considérés comme ayant été
ajoutés localement par les pairs. Nous simulons ensuite des téléchargements
de fichiers entre les pairs de façon aléatoire, avec une moyenne de 5 fichiers téléchargés par pair par jour (comme indiqué dans [56]). Pour chaque
téléchargement, un pair est choisi aléatoirement pour être downloader, ainsi
qu’un fichier à télécharger. Nous effectuons ensuite une recherche dans notre
réseau pour trouver des sources à ce downloader pour ce fichier.
Simulation de la propagation d’un ver P2P passif dans le réseau
Le module ”Simulateur du ver” de la figure 3.2 est dédié à la simulation de la propagation de vers P2P passifs. Il est basé sur le modèle
épidémiologique proposé dans [61] et présenté dans la partie 1.3 de ce rapport. Pour rappel, ce modèle permet de savoir à quel moment un pair du
réseau a téléchargé un fichier infecté (diminution du nombre de pairs susceptibles et augmentation du nombre de pairs exposés), à quel moment il a
exécuté un fichier infecté (diminution du nombre de pairs exposés et aug-
63
mentation du nombre de pairs infectés), et à quel moment il s’est rétabli
(diminution du nombre de pairs infectés et augmentation du nombre de
pairs susceptibles).
Ces informations permettent ainsi de reproduire la propagation du ver
dans le réseau P2P. Nous supposons par ailleurs que le ver ajoute les mêmes
fichiers au partage de chaque pair qu’il infecte.
Figure 3.2 – Composants fonctionnels du simulateur.
3.2.2
Evaluation
Nous allons maintenant présenter les résultats des simulations que nous
avons effectuées et le but de ces dernières.
Comme expliqué précédemment, nous considérons que tous les fichiers
partagés par un pair lors de sa première connexion ont été ajoutés localement.
Dans ce qui suit, et sauf indication contraire, les valeurs des paramètres
du simulateur utilisées sont celles données dans la table 3.1.
3.2.2.1
Effet de la variation du nombre de copies du ver c
Désirant étudier l’effet de la variation du nombre de copies du ver présentes
sur une machine infectée (paramètre c) sur les résultats de détection, nous
avons effectué des simulations avec différentes valeurs de c. Les résultats obtenus sont donnés par la figure 3.3 qui représente l’évolution du nombre de
64
Paramètre
λR
λE
λS
α
N
M
c
E
nbF ich
Valeur
6, 94 ∗
(un rétablissement par jour, en moyenne)
3, 47 ∗ 10−3 (5 fichiers exécutés par jour, en moyenne)
3, 47 ∗ 10−3 (5 fichiers téléchargés par jour, en moyenne)
0, 5
21000 pairs
512276 fichiers sains
10 copies du ver
1000 pairs exposés initialement
2
10−4
Table 3.1 – Valeurs des paramètres du simulateur.
pairs infectés et la figure 3.4 qui représente celui des pairs détectés dans le
réseau. Les taux de faux positifs et de détection correspondants sont donnés
dans la table 3.2.
c
10
20
30
Détection
85,52%
93,99%
94,28%
Faux positifs
0%
0%
0%
Table 3.2 – Résultat de l’algorithme L2 avec nbFich = 2 pour différentes
valeurs de c.
Les figures 3.3 et 3.4 montrent que plus c est élevé (avec c au moins égal
à 1), plus l’infection est rapide, et plus la détection est rapide et meilleure
aussi (supérieure à 90% lorsque c est supérieur ou égal à 20). Ceci prouve que
l’utilisation de valeurs élevées de c pour augmenter les chances du ver de se
propager ne perturbe pas le fonctionnement de notre solution de détection,
qui reste ainsi très efficace.
Lorsque c est inférieur à 2, comme expliqué précédemment dans ce chapitre, l’algorithme ne peut détecter aucun pair infecté, mais, dans ce cas, et
comme expliqué précédemment et montré par la figure 3.1, le ver ne pourra
pas être efficace, et sera amené à disparaı̂tre par lui même quelques jours
après le début de l’infection.
65
Figure 3.3 – Evolution du nombre de pairs infectés pour c∈
{5, 10, 20, 30, 40}.
3.2.2.2
Effet du cryptage dans le réseau
Comme notre solution est basée sur le réseau, il est important d’étudier
l’effet du cryptage dans ce dernier sur les résultats de détection.
Tout d’abord, nous pouvons constater que dans ce cas, la détection doit être
effectuée au niveau du serveur car nous ne pouvons pas avoir d’informations du réseau. Ceci implique l’impossibilité d’avoir les informations sur les
sources d’un pair pour les fichiers qu’il a téléchargé, car le serveur n’en a pas
connaissance. En effet, le serveur connaı̂t les fichiers partagés par chaque pair
du réseau, et lorsqu’une requête lui est envoyée, il répond en envoyant au
pair demandeur la liste des pairs pouvant lui fournir le fichier demandé, mais
il ne sait pas à partir de quelle(s) source(s) ce pair va réellement télécharger
ce fichier. Cette information est collectée à partir du réseau dans notre architecture de détection (figure 2.9), en suivant les téléchargements entre pairs,
lorsqu’il n’y a pas de cryptage dans le réseau.
66
Figure 3.4 – Evolution du nombre de pairs détectés pour c∈
{5, 10, 20, 30, 40}.
Sans l’information sur les sources des pairs, notre algorithme de détection
ne peut pas être exécuté. Pour cela, nous proposons une solution intermédiaire,
qui est de supposer que les pairs donnés par le serveur comme réponse à la
requête de recherche de fichier d’un pair sont des sources de ce pair pour ce
fichier, même si ce dernier n’a pas réellement téléchargé le fichier à partir de
tous ces pairs.
Une conséquence évidente de cette façon de faire est l’augmentation du
nombre de faux positifs. Nous avons pu vérifier cela à travers des simulations
qui ont donné un pourcentage de 2,17% de faux positifs alors qu’il est nul
dans un réseau sans cryptage. Malgré cette augmentation, nous considérons
le résultat en faux positifs satisfaisant car il reste faible. Le taux de détection
est quant à lui de 96,85%, ce qui représente une augmentation par rapport
au cas non crypté où il était égal à 83,82%.
Ainsi, nous pouvons dire que notre solution de détection reste efficace
67
même dans le cas de cryptage des messages envoyés dans le réseau.
3.2.2.3
Temps pris pour détecter les pairs infectés
Nous allons à présent nous intéresser à la durée qui sépare le moment où
un pair est infecté de celui où il est détecté. Les résultats des simulations
que nous avons effectuées sont donnés par la figure 3.5, où l’axe des abscisses représente le délai recherché et l’axe des ordonnées le nombre de pairs
concernés par ce délai. D’emblée, la figure 3.5 montre que certains pairs sont
détectés immédiatement après leur infection (délai proche de zéro). Le calcul
de la moyenne de ce délai donne un résultat de 11 heures. Ceci prouve encore
une fois l’efficacité de notre solution, car ce délai ne laisse pas beaucoup de
temps au ver pour exécuter son action malveillante.
Figure 3.5 – Délai entre l’infection d’un pair et sa détection.
Nous allons maintenant analyser les résultats obtenus de plus près. Le
nombre obtenu de pairs détectés est de 687, parmi lesquels 91 (13,24%) ont
68
été détectés dans les 95 minutes qui ont suivi leur infection. 223 pairs infectés ont été détectés en moins de 287 minutes (moins de 5 heures), ce qui
représente 32,45% des pairs détectés. 435 des pairs infectés ont été détectés
dans les 667 minutes (11 heures) ayant suivi leur infection, et ils représentent
63,31% des pairs détectés. 655 pairs infectés ont été détectés dans les 24
heures qui suivent leur infection, et représentent 95,34% des pairs détectés.
Ces résultats prouvent encore une fois l’efficacité de notre solution de
détection, car grâce à elle, le ver a dans 95% des cas d’infection, moins de 24
heures pour exécuter son action malveillante, ce qui diminue considérablement
ses chances d’y arriver.
3.2.2.4
Effet de la non disponibilité du partage de tous les pairs
Après avoir étudié l’effet de la non disponibilité d’informations complètes
sur les sources des pairs sur notre solution, nous allons maintenant étudier
l’effet de la non disponibilité d’informations sur le partage de tous les pairs.
Les résultats que nous avons obtenus après 33 heures de simulation sont
présentés dans la table 3.3.
Inconnus
10%
20%
50%
Détection
66,84%
51,89%
21,27%
Faux positifs
0%
0%
0%
Table 3.3 – Effet de la non disponibilité du partage de tous les pairs sur
les résultats de l’algorithme de détection
La figure 3.6 présente l’évolution du nombre de pairs infectés et celui de
pairs détectés dans le réseau pour les différents pourcentages du paramètre
Inconnus, qui représente le nombre de pairs pour lesquels nous n’avons pas
d’information sur le partage. Comme nous pouvons le remarquer, plus la valeur de cette variable est grande, plus le taux de détection est petit, et plus le
délai avant la première détection est long. Ce délai est égal à 6 heures quand
Inconnus = 10%, 7 heures quand Inconnus = 20% et 21 heures lorsque Inconnus = 50%.
Les résultats montrent donc que la détection de la présence du ver est
possible même lorsqu’on ne dispose pas de données complètes sur le partage
des pairs. Et nous allons voir dans le chapitre suivant que, malgré la baisse
du pourcentage de détection, la solution de mitigation nous permet d’arrêter
69
la propagation du ver juste après la détection des premiers pairs infectés.
Ainsi, même si nous n’avons accès qu’au partage de la moitié des pairs, nous
pourrons arrêter sa propagation au plus tard dans les 24 heures qui suivent
son lancement.
Figure 3.6 – Evolution du nombre de pairs infectés et détectés lorsque le
nombre de pairs pour lesquels il n’y a pas d’information sur le partage de
10%, 20% et 50% des pairs.
Conclusion
Dans ce chapitre, nous avons pu démontrer l’efficacité de notre solution de détection du point de vue faux positifs (nombre très faible), taux
de détection (nombre élevé) et résistance aux tentatives de contournement.
La solution de détection que nous avons proposée est transparente pour les
utilisateurs du réseau P2P. Ainsi, ils ne peuvent pas la désactiver ou perturber son fonctionnement. Elle est par conception capable de détecter les
70
vers passifs qui ne génèrent pas de trafic anormal. Elle n’est pas basée sur
des signatures, mais sur la détection du comportement du ver lors de sa
propagation.
Ainsi, notre solution remplit toutes les exigences dont nous avons discuté
au début du chapitre 2, et que nous avons fixées comme étant indispensables
pour garantir une bonne solution de détection.
71
Chapitre 4
D’une solution de détection
vers une solution de lutte
contre les vers Pair-à-Pair
passifs
Résumé
Dans ce chapitre, nous allons étudier des aspects importants qui, combinés à notre solution de détection, nous donnent une solution de lutte contre
les vers P2P passifs complète et efficace. Tout d’abord, nous allons proposer
une solution de mitigation, dont le but est d’arrêter la propagation du ver
le plus tôt possible après sa détection, évitant ainsi l’infection de nouveaux
pairs. Puis, notre architecture de détection ayant été conçue au départ pour
un réseau P2P centralisé (eDonkey étant le réseau le plus utilisé en France),
nous allons étudier la possibilité d’appliquer cette architecture sur les autres
types de réseaux P2P. Enfin, nous allons discuter de la mise en place de
notre solution dans un vrai réseau.
Introduction
Dans les chapitres 2 et 3, nous avons pu démontrer l’efficacité de notre
algorithme de détection, mais cela reste insuffisant pour pouvoir parler d’une
solution de lutte contre les vers P2P passifs, car il ne suffit pas de détecter
ces attaques, il faut aussi agir suite à cela et ≪ désinfecter ≫ le réseau de ces
73
intrus. Nous parlons dans ce cas de
≪
mitigation ≫.
Nous allons présenter dans ce chapitre une solution de mitigation et l’appliquer dans notre simulateur pour la tester. Nous allons ensuite étudier la
possibilité d’appliquer notre solution aux systèmes P2P autres que centralisés. En effet, le mécanisme de récupération des informations nécessaires
à l’application de notre algorithme correspond à un réseau P2P centralisé.
Aussi, pour être réellement utile, toute solution à un problème doit être
réalisable et ne pas rester cantonnée dans un simulateur, donc nous allons
étudier la façon avec laquelle notre solution peut être mise en place dans un
réseau réel.
4.1
Mitigation
La détection de vers est généralement suivie d’une phase de mitigation,
dont le but est d’arrêter la propagation des vers détectés. Donc l’efficacité
de la mitigation dépend de celle de la détection, car elle se base sur les
résultats de cette dernière. Si la détection est pertinente et ne génère pas de
faux positifs, les vrais fichiers malveillants sont traqués pas la mitigation.
Si le nombre de fausse détections est élevé, la mitigation ciblera des fichiers
sains, ce qui peut causer des problèmes d’accès à ces fichiers, et donc de déni
de service.
Comme nous avons pu le prouver lors de l’évaluation de notre algorithme de détection, le nombre de faux positifs générés par notre solution
de détection est négligeable. Nous pouvons ainsi proposer une solution de
mitigation pouvant tirer profit de la pertinence des résultats de détection
pour sécuriser encore plus le réseau.
Résultats de la mitigation
Le but de la mitigation (containment ou virus throttling) est d’arrêter
la propagation du ver après sa détection. Ceci est réalisé en effectuant des
actions définies préalablement dans le système afin d’éviter que des machines infectées transmettent le ver à d’autres pairs du réseau. Ces actions
consistent généralement à bloquer les machines infectées comme dans [42] et
[23], mais, comme expliqué précédemment, ceci peut provoquer un déni de
service aux utilisateurs légitimes si la solution de détection n’est pas fiable.
74
Dans notre système, nous proposons une solution de mitigation qui
consiste à supprimer les fichiers malveillants des machines infectées repérées
par notre solution de détection. Comme cette dernière ne génère pas de faux
positifs, nous ne risquons pas d’avoir de problème de déni de service.
Nous avons appliqué cette solution dans notre simulateur. Nous avons
obtenu les résultats présentés dans la figure 4.1. Les simulations ont été effectuées en utilisant les paramètres de la table 3.1 et nbFich = 2.
Figure 4.1 – Effet de la mitigation sur la propagation du ver.
Nous pouvons observer, à partir de la figure 4.1, que le nombre de pairs
infectés augmente jusqu’à atteindre 654 après 365 minutes d’infection (6
heures). Il commence ensuite à décroı̂tre au moment de la détection des premiers pairs infectés. Après 2000 minutes (33 heures), le système détecte et
rétablit 60,35% des pairs infectés, et le nombre de pairs infectés restants est
d’environ 331, alors qu’il est égal à 832 lorsqu’il n’y a pas de solution de mitigation dans le système. Donc, la mitigation a permis de réduire le nombre de
75
pairs infectés en 60,21% en seulement 33 heures. Au même moment, le taux
de détection obtenu est d’environ 60% alors qu’il est d’environ 85% lorsque
la détection est effectuée sans mitigation. Nous pouvons expliquer cela par le
fait que, lorsque les fichiers infectés sont enlevés du répertoire partagé d’un
pair infecté pour le rétablissement de ce dernier, il ne reste plus de fichiers
infectés en commun entre ce pair et ses downloaders infectés. D’autre part,
après 48 heures, nous détectons 70,17% des pairs infectés, 75,08% après 72
heures, 85,5% après environ 7 jours et 89,70% après 15 jours, ce qui correspond à seulement 86 pairs infectés restants dans le réseau, et représente une
baisse de 87,85% en comparaison au cas où la mitigation n’est pas appliquée.
Ainsi, la solution de mitigation que nous avons proposée a eu un grand
impact sur la propagation du ver, en diminuant d’une façon significative le
nombre de pairs infectés dans le réseau. Mais malheureusement, son application reste difficile, nous ne pouvons pas effectuer de modifications sur les
ordinateurs des utilisateurs à notre guise. En effet, pour pouvoir supprimer
les fichiers infectés, il faut prendre la main sur les machines infectées du
réseau P2P. L’un des rares cas où cela est possible est celui de réseaux P2P
privés.
Dans les autres cas, il faut informer les utilisateurs des machines infectées de la présence de fichiers malveillants sur leurs machines, et leur
demander de les supprimer. Ceci nécessite un mécanisme permettant cette
communication. Mais dans ce cas, nous ne pouvons pas garantir l’arrêt de
la propagation du ver, car nous ne pouvons pas être sûrs que les utilisateurs
concernés vont bien enlever les fichiers infectés comme demandé.
Afin d’éviter tout cela, nous avons réfléchi à une autre solution pour
arrêter la propagation du ver sans avoir besoin de supprimer les fichiers
malveillants des pairs infectés. Ainsi, lorsqu’un ver P2P passif est détecté,
nous proposons de ne plus le donner (ni ses copies) en réponse aux requêtes
de recherche des pairs du réseau. Pour cela, le serveur peut enlever les fichiers infectés de son index (qui comporte les listes de fichiers partagés des
pairs qui lui sont connectés). Evidemment, l’absence de faux positifs est une
condition sine qua non pour pouvoir appliquer cette solution sans avoir de
problèmes de déni de service.
En procédant ainsi, il est clair que la propagation du ver peut être arrêtée
immédiatement après la détection de la première copie du ver sur un pair
du réseau, et sans devoir effectuer de modifications au niveau des pairs du
76
réseau.
Dans notre simulateur, en utilisant les paramètres de la table 3.1, et la
valeur 2 pour le paramètre nbFich, la première détection du ver est effectuée
6 heures après le début de l’infection. Ainsi, la propagation du ver peut être
arrêtée juste après. Ceci fait de cette solution une méthode efficace pour
arrêter la propagation du ver rapidement.
Cependant, s’ils ne peuvent plus se propager, les fichiers malveillants
restent présents sur les pairs infectés, avec les risques qu’ils présentent (notamment l’exécution des éventuelles actions malveillantes pour lesquelles ils
ont été lancés).
Afin de permettre un rétablissement rapide de ces pairs, les utilisateurs
P2P doivent être informés de l’infection de leur machine, ainsi que des dispositions à prendre pour la rétablir. Pour cela, un message d’alerte peut être
publié sur les sites de sécurité réseau ou bien d’information sur le réseau P2P
dans lequel a été détectée l’attaque. Contrairement à la première solution
de mitigation, cette solution nous donne l’assurance qu’aucun nouveau pair
du réseau ne peut être infecté par le ver détecté.
Ainsi, nous avons pu proposer une solution qui permet d’arrêter la propagation du ver dès sa détection dans le réseau.
4.2
Mise en place de la solution dans le réseau
Nous allons, dans cette partie, étudier l’intégration de notre architecture de détection dans un vrai réseau. Cette architecture telle que présentée
dans le chapitre 2 correspond au cas où l’entité qui réalise la détection avec
notre algorithme a accès aux données de toutes les sondes ayant des informations sur tous les pairs du réseau P2P surveillé. Ce cas peut se présenter
si le réseau P2P surveillé est un réseau privé, utilisé par une entreprise par
exemple pour organiser la sauvegarde et l’accès aux fichiers à l’intérieur de
cette dernière.
Cependant, dans le réseau Internet, les pairs d’un réseau P2P ne font pas
forcément partie du même réseau. Ils peuvent provenir de réseaux d’opérateurs
différents, avec la possibilité d’avoir un pair et l’une de ses sources pour un fichier donné qui sont dans deux parties du réseau surveillées par deux sondes
77
différentes n’appartenant pas à la même entité. Dans ce cas, comment le
centre de détection du pair downloader peut-il avoir accès aux données du
pair source qui ne fait pas partie de son périmètre ?
Nous avons pu étudier dans le chapitre 3 l’effet d’avoir des informations
partielles sur le partage des pairs. Ainsi, comme nous avons pu le voir, même
si les informations sur la moitié des pairs du réseau ne sont pas disponibles,
nous pouvons détecter la présence d’un ver P2P passif. Par contre, le délai de
détection est plus long que lorsque toutes les informations sont disponibles.
Ainsi, nous pouvons placer notre algorithme de détection sur un équipement
du réseau que nous voulons surveiller, et n’utiliser que les informations des
sondes de ce réseau.
Mais, pour gagner du temps et pour avoir un réseau Internet sécurisé,
il faut qu’il y ait une coopération entre les différents réseaux d’opérateurs,
permettant un échange des informations nécessaires pour la détection des
vers P2P passifs.
La solution complète à mettre en place dans le réseau Internet serait celle
où toutes les sondes des différents réseaux envoient les informations sur les
partages et sources des pairs à un point central, qui s’occupera d’appliquer
l’algorithme de détection. Mais cette solution a un point faible, c’est le point
central de détection, qui, s’il est attaqué, mettra en péril la sécurité dans le
réseau Internet en entier.
L’autre solution, qui nous paraı̂t plus sûre, serait celle où il y a un point
de détection par réseau. Dans ce cas, il suffit de mettre en place un système
de communication entre les sondes des différents réseau. Lorsque les sondes
d’un réseau donné n’ont pas l’information sur le partage de la source d’un
pair de leur réseau, elles peuvent interroger les sondes du réseau auquel
appartient ce pair. Nous pourrions même réfléchir à la construction d’un
système P2P ayant comme pairs les sondes de tout le réseau Internet, facilitant ainsi la recherche des informations sur les pairs via le lancement de
requêtes dans ce réseau.
78
4.3
Adaptation de la solution aux systèmes Pairà-Pair non centralisés
L’algorithme de détection que nous avons proposé fonctionne pour tous
les réseaux P2P, car il se base sur le comportement du ver, qui est identique
quelque soit le type de réseau P2P. En effet, le ver P2P utilise la même
méthode de propagation, quelque soit le type de réseau P2P dans lequel il
se trouve, et le fait que notre algorithme de détection soit basé sur cette
dernière le rend ”multi-réseaux”.
Contrairement à l’algorithme de détection, la collecte des informations
nécessaires à cette solution de détection, qui sont le partage de chaque pair
(les fichiers téléchargés et les fichiers ajoutés localement) change d’un type
de réseaux P2P à l’autre.
La technique de récupération des informations sur le partage présentée dans
ce rapport est celle utilisée dans des réseaux P2P centralisés (typiquement
eDonkey) ou hybrides, dans lesquels les fichiers partagés par les pairs sont
indexés au niveau d’un ou plusieurs points (un serveur ou des super-pairs),
c’est-à-dire dans le cas où les pairs du réseau envoient des informations sur
leur partage à une ou plusieurs entités chargées d’indexer les fichiers du
réseau pour les besoins des recherches ultérieures.
Il peut arriver que, lorsque des fichiers sont ajoutés localement par un
pair du réseau (comme dans eDonkey), le serveur d’indexation n’en soit pas
informé automatiquement. Mais cela arrive sûrement lors de la déconnexion
puis reconnexion du pair au réseau, où la liste complète de partage du pair
est envoyée au serveur d’indexation. Cette liste comporte sûrement les fichiers ajoutés localement par le pair à son partage. Ces derniers peuvent
ainsi être déduits à partir de cette nouvelle liste.
La liste des pairs sources est quant à elle récupérée à partir des échanges
entre ces dernières et le pair ayant demandé le fichier au moment du lancement du téléchargement.
Dans le cas de réseaux P2P décentralisés (structurés ou pas), où, comme
présenté dans le chapitre 1, les fichiers composant le partage d’un pair ne
sont pas indexés dans un système central. Les listes de partage des pairs
peuvent être retrouvées à travers la recherche de fichiers dans le réseau. En
effet, en lançant des requêtes sur une suite de chaines de caractères, en es-
79
sayant de couvrir toutes les possibilités (par exemple : aaa, aab, aac, aad,
. . .), et, à partir des résultats obtenus, nous pouvons reconstituer le partage
des pairs.
Concernant les fichiers ajoutés localement, nous pouvons les deviner à
travers les échanges réalisés dans le réseau. En effet, à travers ces échanges,
nous pouvons voir les fichiers téléchargés par un pair, et donc deviner ceux
qu’il a ajoutés localement à partir du partage total.
Les sources des pairs peuvent aussi être retrouvées à partir des connexions
établies entre les pairs suite à une recherche de fichiers.
Les procédures que nous avons présentées jusqu’ici fonctionnent quand
les communications dans le réseau ne sont pas toutes cryptées.
Dans le cas où les communications sont cryptées, la seule solution de
récupérer les informations demandées par l’algorithme de détection serait
d’intégrer des fonctionnalités permettant de les avoir au niveau des pairs
(au niveau du client P2P ou au niveau des set top boxes par exemple). L’algorithme de détection pourra quant à lui, être exécuté dans le réseau.
Comme nous pouvons le constater, à condition de pouvoir récupérer les
informations requises comme expliqué ci-dessus, notre solution de détection
agit sur tout le réseau. En effet, comme la solution de détection est indépendante
du type de réseau, notre solution peut couvrir la totalité des pairs du réseau
Internet.
Conclusion
Nous avons voulu de ce chapitre celui des discussions sur l’extension de
notre solution de détection pour être la plus complète possible. Nous avions
déjà prouvé dans le chapitre 3 que notre algorithme de détection était complet. En effet notre algorithme permet de détecter une grande partie des
pairs infectés en peu de temps, et il est robuste contre les tentatives de
contournement.
Dans ce chapitre, nous avons introduit une solution de mitigation efficace, qui permet de désinfecter 90% des pairs du réseau en moins de 24
heures. Ceci est décourageant pour les futurs attaquants, car notre solution
80
ne laisse pas assez de temps aux vers pour exécuter leur action malveillante.
Nous avons pu montrer que notre solution (détection et mitigation) pouvait être généralisée à tous les types de réseaux P2P, ce qui nous donnerait
une solution contre les vers P2P couvrant tous le réseau. Ceci nous permettrait de contrer les vers pouvant attaquer plusieurs réseaux P2P très
rapidement.
Nous avons aussi pu étudier comment installer notre architecture de
détection dans un réseau réel, et présenter toutes les possibilités pour cela.
81
Conclusion et perspectives
Tout comme dans la vie réelle, la lutte contre les infections est primordiale dans le réseau Internet. Ces infections, ou attaques, sont très variées,
et la difficulté de les détecter diffère d’un type à l’autre.
Comme nous avons pu le voir dans le premier chapitre de ce rapport,
la détection des vers P2P passifs est une tâche difficile. Le caractère furtif
de ces derniers est dû au fait qu’ils utilisent le mode d’échange de fichiers
des réseaux P2P pour se propager, sans aucune autre action supplémentaire
pouvant trahir cette propagation dans le réseau.
Néanmoins, nous avons réussi à proposer une architecture et des algorithmes efficaces pour la détection dans le réseau de ce type de vers. Nous
avons étudié leur méthode de propagation, et utilisé un élément entrant
dans ce processus, qui est l’ajout de copies du ver en local dans le partage
des pairs infectés, tout en gardant notre solution de détection dans le réseau.
L’une des forces de notre solution de détection est le fait qu’elle soit basée
sur le réseau, ce qui garantit son exécution systématique et continue, contrairement aux solutions basées sur le pair, comme les antivirus, qui peuvent
être désactivées par les attaquants ou les utilisateurs eux-mêmes. Ceci garantit aussi que la détection touche tous les pairs du réseau, contrairement
aux solutions basées sur les pairs, qui nécessitent d’effectuer des modifications de ces derniers, ce qui est loin d’être évident à réaliser sur leur totalité.
Nous avons proposé plusieurs algorithmes et nous les avons testés dans
un simulateur de réseau P2P que nous avons conçu et développé, jusqu’à obtenir les résultats attendus d’une bonne solution de détection d’intrusions,
c’est à dire un nombre de faux positifs quasi nul et une détection rapide et
en grand nombre.
83
Les résultats obtenus dans notre simulateur ont été confirmés par l’étude
analytique que nous avons réalisée. Cette dernière nous a aussi permis de
prouver la robustesse de notre solution en démontrant sa résistance aux
différentes techniques de contournement que nous avons pu identifier.
Nous avons complété notre solution de détection de vers P2P par une
solution de mitigation, afin d’arrêter la propagation du ver le plus tôt possible après sa détection, et de nettoyer les pairs des copies du ver avant que
l’action malveillante de ce dernier ne soit exécutée. Comme notre algorithme
de détection permet de repérer la présence d’un ver en moyenne 6 heures
après son infection d’un pair, notre solution de mitigation peut agir très
rapidement.
La solution proposée a d’autres avantages comme la détection, en plus
des vers déjà connus, ceux jamais vus dans le réseau, ainsi que des vers
polymorphiques. Ainsi, le fait de permettre la détection du ver pendant sa
propagation et non en se basant sur l’action qu’il exécute permet d’éviter
de subir les dommages prévus par cette dernière, ce qui est non négligeable
dans la lutte contre les intrusions.
L’efficacité de notre système de détection étant prouvée dans un simulateur et mathématiquement, la prochaine étape est de le déployer dans un
vrai réseau. Ce dernier peut être celui de l’opérateur, un réseau de streaming
vidéo ou, à moindre échelle, un réseau de partage de fichiers d’une entreprise
basé sur un réseau P2P.
Une autre perspective de ce travail serait d’intégrer une solution de
détection de vers P2P actifs dans le système de détection d’intrusion. Le
système étant mis en place dans le réseau, il pourrait être réutilisé pour
détecter les possibles anomalies causées par les vers P2P actifs car il inclut
une analyse réseau et contient déjà les informations sur les sources des pairs
du réseau.
Ce qui est certain, c’est que la solution que nous avons proposée représente
une grande avancée dans la détection d’intrusions de vers très difficiles à
repérer et pour lesquelles aucune solution de détection efficace n’existait.
L’innovation de notre algorithme de détection a été prouvée par l’acceptation de notre brevet [38] à l’international, et nous sommes d’autant plus
sûrs de l’utilité que peut avoir notre contribution, compte-tenu de l’utilisation actuelle et future des réseaux P2P, avec l’avènement du P4P et sans
84
doute d’autres applications inhérentes ou annexes à ces réseaux.
85
Bibliographie
[1] cert-ist : www.cert-ist.com.
[2] genomeathome.stanford.edu.
[3] overlayweaver.sourceforge.net.
[4] p2p.stanford.edu/www/projects.htm.
[5] peersim.sourceforge.net.
[6] setiathome.berkeley.edu.
[7] Sql slammer,
www.secuser.com/alertes/2003/sqlslammer.htm.
[8] Storm worm.
[9] www.eurecom.fr/resources/documents//0 institut/media kit/revuepresse/2006-01-061̃[email protected].
[10] www.first.org.
[11] www.frsirt.com.
[12] www.futura-sciences.com/fr/news/t/internet/d/ikee-un-ver-dans-lapomme-de-liphone 21360/.
[13] www.honeyd.org.
[14] www.hsc.fr.
[15] www.isi.edu/nsnam/ns.
[16] www.leurrecom.org.
[17] www.oversim.org.
[18] www.snort.org.
[19] www.viruslist.com/en/virusesdescribed ?chapter=153311928.
[20] www.vmware.com/fr/.
[21] S. Androutsellis-Theotokis and D. Spinellis. A survey of peer-to-peer
content distribution technologies.
87
[22] David Barroso. Botnets the silent threat.
[23] H. Binsalleh and A. Youssef. An implementation for worm detection
and mitigation system.
[24] Y.Deswarte M.Kaaniche-K.Kortchinsky V.Nicomette V.H.Pham
E.Alata, M.Dacier and F.Pouget. Leurrée.com : retour d’expérience
sur plusieurs mois d’utilisation d’un pot de miel distribuée mondialement. Actes du symposium SSTIC05, 2005.
[25] Computer Economics. www.computereconomics.com.
[26] S. Staniford et al. Grids - a graph based intrusion detection system
for large networks. In Proceedings of the 19th National Information
Systems Security Conference, volume 1, pages 361–370, October 1996.
[27] T. Evangelista. Les ids. les systèmes de détection d’intrusions informatiques. Ed. DUNOD, 2004.
[28] GPS. cs.binghamton.edu/ wyang/gps.
[29] M. Dacier H. Debar and A. Wespi.
A revised taxonomy for
intrusion-detection systems. Annales des télécommunications (Ann.
télécommun.), 2000.
[30] A. Silberschatz H. Xie, A. Krishnamurthy and Y. R. Yang. P4p : Explicit communications for cooperative control between p2p and network
providers. DCIA P2P Market Conference, New-York, March 2008.
[31] F. et al Heart. The interface message processor for the arpa computer
network. Proceedings of spring joint computer conference, 1970.
[32] O. Heckmann and A. Bock. The gnutella 2000 protocol. 2002.
[33] O. Heckmann and A. Bock. the edonkey2000 protocol.
[34] IM-Worm.Win32.Bropia.ad. www.viruslist.com/en/viruses/encyclopedia ?virusid=81593.
[35] A.W. Berger J. Jung, V. Paxson and H. Balakrishnan. Fast portscan
detection using sequential hypothesis testing. In Proceedings of the
IEEE Symposium on Security and Privacy, May 9– 12, 2004.
[36] R. Kumar J. Liang and K. W. Ross. Understanding kazaa.
[37] L. Gao J. Wu, S. Vangala and K. Kwiat. An effective architecture
and algorithm for detecting worms with various scan techniques. In :
Proceeding of the 11th Annual Network and Distributed System Security
Symposium (NDSS’04), 2004.
[38] N. Khiat and Y. Carlinet. Detection de vers passifs dans un réseau
pair-à-pair. Patent, 0851961, 2008.
88
[39] F. McSherry N. Immorlica M. Costa L. Zhou, L. Zhang and S. Chien. A
first look at peer-to-peer worms : Threats and defenses. Proceedings of
Peer-to-Peer Systems IV, 4th International Workshop (IPTPS), pages
24–35, 2005.
[40] K.N. Levitt B. Mukherjee J. Wood L.T. Heberlein, G.V. Dias and
D. Wolber. A network security monitor. In Proc. IEEE Symp. Research in Security and Privacy, pages 296–304, May 1990.
[41] I. Murase M. Ishiguro, H. Suzuki and H. Ohno. Internet threat detection
system using bayesian estimation. FIRST 16th Annual Conference,
Budapest, June 2004.
[42] G. Ananthanarayanan M. Mowbray and A. Joseph. A randomized defence of virus throttling. Technical report, Workshop on Adaptive Resilient Computing Security (ARCS), London, September 30, 2008.
[43] B. Madhusudan and J. Lockwood. Design of a system for real-time
worm detection. In : Hot Interconnects, Stanford, CA, pages 77–83,
2004.
[44] S. Marechal. Création d’un web worm. exploitation automatisée des
failles web. Symposium sur la Sécurité des Technologies de l’Information et des Communications (SSTIC), 2005.
[45] P. Maymounkov and D. Mazières. Kademlia : A peer-to-peer information system based on the xor metric.
[46] Y. Carlinet N. Khiat and N. Agoulmine. The emerging threat of peerto-peer worms.
[47] V. Paxson N. Weaver and S. Staniford et al. A taxonomy of computer
worms.
[48] A. Norbeg. Introduction to bittorrent. 2006.
[49] OMNET++. www.omnetpp.org.
[50] P2P-worm.win32.krepper.c. www.viruslist.com/en/viruses/encyclopedia ?virusid=60616.
[51] P2P-Worm.Win32.SdDrop.a. www.viruslist.com/en/viruses/encyclopedia ?virusid=24282.
[52] P2P-Worm.Win32.Tanked.a. www.viruslist.com/en/viruses/encyclopedia ?virusid=24511.
[53] P2PSim. pdos.csail.mit.edu/p2psim.
[54] V. Paxson. Bro : A system for detecting network intruders in real-time.
In Proceedings of the 7th USENIX Security Symposium, San Antonio,
TX, January 1998.
89
[55] K. Ramachandran and B. Sikdar. Modeling malware propagation in
gnutella type peer-to-peer networks. The Third International Workshop on Hot Topics in Peer-to-Peer Systems (Hot-P2P), Rhodes Island,
Greece, 2006.
[56] F. Le Fessant L. Massoulié S. B. Handurukande, A.-M. Kermarrec and
S. Patarin. Peer sharing behaviour in the edonkey network, and implications for the design of server-less file sharing systems.
[57] G. Varghese S. Singh, C. Estan and S. Savage. The earlybird system for
the real-time detection of unknown worms. Technical Report CS20030761, August 2003.
[58] J. Hoagland S. Staniford and J-M McAlerney. Practical automated
detection of stealthy portscans. Journal of Computer Security Volume
10, Issue 1-2, pages 105 – 136, 2002.
[59] Clip2 Distributed Search Services. The gnutella protocol specification
v0.4. www.stanford.edu/class/cs244b/gnutella protocol 0.4.pdf.
[60] Skype. www.skype.com/intl/fr.
[61] R. Thommes and M. Coates. Epidemiological modeling of peer-to-peer
viruses and pollution. In Proceedings of IEEE INFOCOM, 2006.
[62] T. Toth and C. Kruegel. Connection-history based anomaly detection.
In Proceedings of the IEEE Workshop on Information Assurance and
Security, West Point, NY, June 2002.
[63] Le ver Morris.
news.cnet.com/16-candles-for-first-Internetworm/2100-7349 3-5438291.html.
[64] S. Chellappan W. Yu, C. Boyer and D. Xuan. Peer-to-peer system-based
active worm attacks : Modeling and analysis. 2005 IEEE International
Conference, pages 295–300, 2005.
[65] A. Wagner and B. Plattner. Entropy based worm and anomaly detection in fast ip networks. In proceedings of the 14th IEEE International
Workshops on Enabling Technologies : Infrastructure for Collaborative
Enterprise, pages 172 – 177, 2005.
[66] S. Ke Wang and J. Stolfo. Anomalous payload-based network intrusion
detection. Techical report, September 2004.
[67] L. Gao Z. Chen and K. Kwiat. Modeling the spread of active worms.
IEEE INFOCOM, 2003.
90

Application aux Réseaux Pair-à-Pair

Transcription

Documents pareils

Lire la suite - Ville de Pont à Marcq

Fiche Produit

Format en couleur

fiche technique

dES FiLMS, oU TU VEUX QUAnd TU VEUX

Attaques Informatique

Grès Etiré non verni

IN VIA Nürnberg e.V/Au-pair

Vacances d`Avril du 27/04/15 au 30/04/15

Notice du GiPro TRE pour Suzuki

Peut-on voyager - Culture et Sens