RECHERCHE

Un systme de dtection dintrusions distribu pour rseaux ad hoc

Jean-Marc Percher** Ricardo Puttini* Ludovic M* Olivier Camp** Bernard Jouga* Patrick Albers**
* Suplec, BP 81127, F-Cesson Svign cedex {ludovic.me, ricardo.puttini, bernard.jouga}@supelec.fr ** cole Suprieure dlectronique de lOuest (E.S.E.O) 4, rue Merlet de la Boulaye BP 926, F-49009 Angers cedex 01 {jean-marc.percher, olivier.camp, patrick.albers}@eseo.fr
RSUM.

Nous prsentons dans cet article une architecture modulaire pour un systme de dtection dintrusions (IDS) ddi aux rseaux ad hoc. Cette architecture repose sur limplantation dIDS sur chaque nud du rseau ad hoc. Ces IDS locaux communiquent par le biais dagents mobiles. Les choix de conception ont t valids par un prototype qui est dcrit dans cet article. Diffrentes attaques de niveau rseau et de niveau application ont t mises en uvre. Elles sont dcrites en dtail avec leur mthode de dtection. Les exprimentations conduites montrent que notre approche permet la dtection en temps rel de ces attaques. Nous valuons lapport des agents mobiles dans le fonctionnement de lIDS et nous montrons que larchitecture propose permet aussi dintgrer lIDS SNORT comme source dinformation complmentaire.
ABSTRACT.

In this paper we propose a distributed and modular architecture for an intrusion detection system (IDS) dedicated to mobile ad hoc networks (MANET). Our proposition relies on the use of local IDSs on each node of the MANET and on an agent based intra-IDS communication framework. It has been validated by a proof-of-concept prototype, which is presented in this paper. The article describes in detail, several network and application level attacks and how they can be detected. These attacks have been implemented and were used to validate our approach. Experiments exhibit fairly good results and the attacks are well and rapidly detected by our system. We conclude the paper by demonstrating that existing IDSs, such as SNORT, can be integrated as data sources for our architecture and by evaluating the benefits of mobile agents in the ad hoc context.
MOTS-CLS : KEYWORDS:

IDS, systme de dtection dintrusions distribu, rseaux spontans, rseaux ad hoc, MANET, agents mobiles. IDS, distributed intrusion detection system, spontaneous networks, ad hoc networks, MANET, mobile agents.

RSTI - TSI 23/2004. Scurit informatique, pages 391 420

392

RSTI - TSI 23/2004. Scurit informatique

1. Introduction Les rseaux mobiles ad hoc ou MANET (Mobile Ad hoc NETworks) dfinis par la RFC 2501 (Scott Corson et al., 1999), sont des rseaux sans fil qui ne bnficient ni dune infrastructure prexistante, ni dune administration centralise pour assurer les changes dinformations et les services fournis aux utilisateurs. La topologie de ces rseaux se forme au gr de lapparition et du mouvement des nuds. Ces derniers communiquent avec leurs voisins par des liaisons sans fil point point et assurent eux-mmes la fonction de routage. En consquence, il nexiste aucune hirarchie entre les nuds et aucun service rseau ne peut prtendre tre centralis. Un rseau ad hoc est donc un systme autonome de nuds mobiles. Ce systme peut fonctionner de manire isole ou sinterfacer avec des rseaux fixes au travers de passerelles pour devenir un rseau dextrmit. Compte tenu de lvolution rapide des performances des rseaux sans fil et des besoins grandissants des utilisateurs, lutilisation des MANET, aussi appels rseaux spontans, semble appele se dvelopper. Ainsi, ces rseaux rpondent au besoin dchange dinformations, par exemple, entre les participants dune runion, entre les acteurs dune opration de secours, entre les intervenants dun chantier de construction, ou encore entre les lments engags sur un champ de bataille, etc. Ces rseaux sont par nature plus vulnrables et plus difficiles protger que les rseaux filaires. En effet, dans un rseau sans fil, laccs aux donnes changes est immdiat pour tout nud quip dune interface rseau adapte, alors quil faut disposer dune connexion physique dans un rseau filaire. De plus, la mise en uvre de certains mcanismes de scurit dvelopps pour les rseaux filaires est dlicate, voire impossible dans les MANET. En raison de leur caractre spontan, ces derniers ne peuvent bnficier des mcanismes de scurit sappuyant sur linfrastructure, comme un pare-feu ou un serveur dauthentification. En consquence, chaque nud constitue un point de vulnrabilit qui ne peut compter que sur ses propres ressources et ses services pour se protger. Outre les vulnrabilits dj identifies dans les rseaux filaires et souvent accentues dans le contexte ad hoc, ces rseaux possdent des vulnrabilits qui leur sont propres comme celles spcifiques la couche physique et celles spcifiques la couche rseau (Albers et al., 2002). De plus, lobservation des attaques diriges vers les systmes dinformation nous montre que, quelles que soient les techniques de prvention mises en place, il existe toujours des failles exploitables pour celui qui les traque. Nous proposons de renforcer les mcanismes de scurit prventifs existants en leur adjoignant un Systme de Dtection dIntrusions (IDS, Intrusion Detection System) adapt aux caractristiques des MANET. Dans cet article, nous prsentons un IDS pour les MANET et nous validons ses fonctionnalits face quelques attaques caractristiques. Cet article prsente la dmarche complte, depuis la motivation des concepts retenus pour la conception du

Dtection dintrusions dans les MANET

393

systme, jusquaux rsultats obtenus. Dans une premire tape, nous dcrivons les aspects fonctionnels de larchitecture modulaire propose. Dans une deuxime tape, nous dcrivons trois attaques caractristiques et leur dtection. La dernire tape concerne la validation de larchitecture propose et les mesures de performances. Larticle est organis comme suit : la section 2 donne les caractristiques dun IDS pour MANET. La section 3 justifie le choix dun IDS distribu adapt aux caractristiques des rseaux ad hoc. La section 4 dcrit larchitecture modulaire de cet IDS. La section 5 prsente les attaques mises en uvre pour valider cette architecture. La section 6 dcrit les exprimentations et les mesures ralises. Enfin, nous concluons et proposons des suites possibles ce travail.

2. Spcification des besoins de scurit dans les MANET 2.1. La dtection dintrusions et le contexte de mise en uvre des services de scurit Chaque nud dun MANET doit assurer de faon autonome les services de scurit ncessaires la protection de ses ressources. Dans un contexte ad hoc, nous considrons que les services de scurit, comme la confidentialit, lintgrit dun message ou la disponibilit dune ressource, sont dfinis par rapport des communauts dutilisateurs (Feeney et al., 2001). Une communaut dutilisateurs est alors reprsente par un ensemble de nuds partageant une relation de confiance pendant une priode donne. Cette relation de confiance peut, par exemple, permettre le partage dune cl secrte ncessaire la mise en uvre de mcanismes de scurit. Selon les cas dusages, plusieurs communauts dutilisateurs peuvent aussi coexister pendant une priode donne. Dans le contexte des rseaux ad hoc, une politique de scurit est reprsente par les rgles daccs aux services et aux donnes disponibles sur le nud. Ces dernires sont fixes par ladministrateur du nud et reprsentent les actions autorises et interdites pour les autres nuds selon leur appartenance aux diffrentes communauts. La fonction de lIDS est de dtecter les attaques menes contre les services implicites fournis par un nud, comme le protocole de routage, mais aussi de surveiller le respect des rgles dfinies explicitement par la politique de scurit. Plus gnralement, la fonction de lIDS est de dtecter et de ragir lapparition de certains scnarios prdfinis.

2.2. Apport de la dtection dintrusions pour renforcer les mcanismes de scurit Considrons dans une communaut dutilisateurs un nud corrompu suite une faille de scurit due, par exemple, un contournement des mcanismes de scurit

394

RSTI - TSI 23/2004. Scurit informatique

ou un dfaut de configuration. La relation de confiance tablie entre les nuds de la communaut permettra ce nud corrompu, donc potentiellement malveillant, daccder lgitimement aux ressources des autres nuds. Cette dmarche de prise de contrle dun nud distance est bien connue des hackers sur internet. Elle est souvent la premire tape dune attaque plus importante de type DDOS (Distributed Denial Of Service). Les nuds dun rseau sans fil sont particulirement exposs et vulnrables ce type dattaque. Dans un rseau sans fil, les attaques de type Man in the middle , qui consistent gnrer des messages fallacieux pour tromper les destinataires des messages originaux, prsentent une menace importante pour le protocole de routage dont le fonctionnement est bas sur lchange de messages de contrles. Un IDS capable, par exemple, de dtecter en temps rel les prises de contrles distance ou encore des attaques diriges vers le protocole de routage renforcerait alors efficacement laction des mcanismes de scurit en place. Dans la section suivante nous donnons les caractristiques dun IDS pour MANET, puis nous prsentons diffrentes architectures dIDS distribus.

2.3. Caractristiques dun IDS pour MANET Ces caractristiques sont tablies partir des caractristiques gnrales des IDS prsentes dans (M et al., 1999) et des contraintes imposes par les rseaux ad hoc. Dans un premier temps nous prsentons ci-dessous les caractristiques propres de lIDS. Ensuite, nous donnons les contraintes imposes par le rseau et les nuds sur larchitecture et le fonctionnement de lIDS. les principes de dtection : deux approches principales sont couramment utilises. Lapproche comportementale consiste identifier la dviation dun comportement par rapport un modle de rfrence. Lapproche par scnarios sappuie sur la recherche, dans les donnes collectes, de traces dattaques pralablement spcifies ; les sources de donnes : les donnes peuvent tre collectes au niveau du systme, dans les fichiers de log des applications ou du systme dexploitation, ou au niveau du rseau, par lintermdiaire dun sniffer . On qualifie alors respectivement les IDS de Host Based et de Network Based . Quelques travaux (Cabrera et al., 2001) proposent galement lutilisation des donnes stockes dans les MIB (Management Information Base) ; la frquence dutilisation : la dtection des tentatives dintrusions doit tre ralise en temps rel pour permettre aux utilisateurs de ragir immdiatement ; le comportement aprs dtection : la raction la dtection dune intrusion est gnralement informative, dans certains cas particuliers elle peut aussi tre corrective.

Dtection dintrusions dans les MANET

395

Dans un objectif de portabilit et de performances, nous proposons que larchitecture de lIDS soit indpendante de la source des donnes et de la mthode de dtection. Les tests de dtection, bass notamment sur lvolution des faux positifs, nous permettront ensuite de slectionner la mthode de dtection la plus performante face aux diffrents types dintrusions. Les donnes locales utilises pour la dtection des intrusions sont collectes dans la MIB. Cette source dinformation est prfre ici car elle contribue rendre lIDS indpendant des plates-formes matrielles et logicielles utilises. La rponse la dtection dune intrusion doit toujours se faire sous le contrle de lutilisateur du nud attaqu. Celle-ci doit pouvoir tre ractive localement, par exemple en coupant la liaison avec un nud jug suspect, afin de renforcer le niveau de scurit, et informative vers les autres nuds de la communaut. De plus, cette architecture doit aussi tre adapte aux caractristiques des nuds et du rseau : la distribution des nuds : larchitecture de lIDS doit prendre en compte le caractre spontan des rseaux ad hoc ainsi que labsence de nud central permanent ; les dbits limits des liens inter-nuds : les technologies WLAN offrent encore aujourdhui des dbits infrieurs ceux des LAN. LIDS doit sappuyer sur les technologies les moins consommatrices de ressources rseaux ; la mobilit des nuds : lIDS doit utiliser des technologies adaptes la mobilit des nuds ; les caractristiques des nuds et portabilit de lIDS : lIDS doit tre portable, cest--dire indpendant des systmes dexploitation et des plates-formes matrielles. Ses besoins en ressources (batteries, temps CPU, mmoire) doivent de plus tre minimaux. 3. Vers un IDS distribu pour rseau ad hoc Dans un rseau ad hoc, en labsence de point de concentration permanent, la dtection dintrusions doit tre distribue sur lensemble des nuds du rseau. Chaque nud est autonome, et de ce fait, ne peut sappuyer que sur ses ressources locales pour dtecter les intrusions dont il est la cible. Mais, la dtection de certains types dintrusions peut aussi ncessiter la collecte dinformations complmentaires disponibles uniquement sur dautres nuds. Dans ce cas, les nuds sont amens cooprer pour schanger des donnes. Une telle architecture est donc base sur un modle de systme distribu et coopratif. Dans le tableau 1, nous prsentons les principaux IDS reconnus pour possder la fois une architecture distribue et cooprative. Ces derniers ont atteint un niveau de dveloppement permettant de valider les orientations retenues. Notre objectif est ici danalyser leurs caractristiques afin den valuer la compatibilit avec les exigences des MANET.

396

RSTI - TSI 23/2004. Scurit informatique

Source des donnes analyses Systme Systme/Rseau Systme Systme/Rseau Systme MIB/Rseau Systme Systme/Rseau MIB Analyse en temps rel Oui Oui Oui Non Oui Oui Oui Oui Oui

IDS AAFID 1 DIDS2 DPEM3 GrIDS4 CSM5 JiNao6 IDA7 SPARTA 8 MICAEL9

Approche Scnarios Hybride Comportementale hybride Comportementale Hybride Scnarios Scnarios Scnarios

Prtraitement distance Oui Oui Oui Oui Oui Oui Agents mobiles Agents mobiles Agents mobiles

Dtection centralise Oui Oui Oui Oui Non Oui Oui Non Non

Type de rponse Passive Passive Passive Passive Active Passive Passive Passive Passive

Tableau 1. Principaux IDS distribus et leurs caractristiques

Deux caractristiques, la localisation de la dtection et le pr-traitement distance des donnes, sont considrer pour valuer ladquation de ces architectures aux MANET. Pour la localisation de la dtection, lexception de CSM, MICAEL et SPARTA, le processus de dtection ncessite une organisation hirarchique autour dun nud central permanent. Selon nous, on ne peut dans ce cas parler de vritable IDS distribu. Seule la collecte des informations analyser lest. Ces modles darchitectures, dites distribues, ne rpondent donc pas au besoin de distribution des MANET. Nous considrons que larchitecture CSM (Cooperating Security Managers) est quant elle vritablement distribue. Elle est compose dun ensemble dIDS locaux prsents sur chaque systme. Ces derniers sont dots dune fonction spcifique de suivi des connexions dont lobjectif est de dtecter les tentatives dintrusions inities depuis une machine vers plusieurs autres machines du rseau.

1. (Sundar Balasubraniyan et al., 1998). 2. (Snapp et al., 1992). 3. (Ko et al., 1997). 4. (Staniford-Chen et al., 1996). 5. (White et al., 1996). 6. (Fou et al., 1999). 7. (Asaka et al., 1999). 8. (Krgel et al., 2002). 9. (Duarte de Queiroz et al., 1999).

Dtection dintrusions dans les MANET

397

Cet IDS distribu, conu et optimis spcifiquement pour tracer les connexions travers un rseau filaire, nest pas suffisamment gnraliste pour tre retenu tel quel ici. Micael possde une architecture distribue dans laquelle des IDS locaux installs sur chaque nud sont chargs de dtecter les intrusions localement. Lactivit des ces IDS locaux, appels Sentinel est contrle par un agent spcial, appel Head Quater , hberg sur lun des nuds. Cet agent a pour fonction de rassembler les informations collectes par tous les Sentinels Agents et de les assister dans le processus de dtection. Parmi les architectures cites ci-dessus, SPARTA (Security Policy Adaptation Reinforced Through Agents) est la seule conue spcifiquement pour les environnements sans fil. Larchitecture de ce systme, dveloppe paralllement au ntre, ncessite la prsence dun nud central dont le rle est de maintenir une base de connaissance des nuds prsents dans le rseau. Dans une architecture distribue, la mthode utilise pour effectuer la collecte dinformation sur des nuds distants est une fonctionnalit importante pour assurer la coopration. Pour trois des IDS retenus, (IDA, SPARTA, MICAEL), le prtraitement distance des donnes est effectu par des agents mobiles. Un agent mobile peut tre dfini comme une entit logicielle qui fonctionne de manire autonome et continue dans un environnement particulier, capable de se dplacer et de sadapter aux changements de lenvironnement, de communiquer et de cooprer avec dautres agents. La mise en uvre des agents mobiles, qui permet de dplacer le code vers les donnes analyser, est une alternative aux architectures client/serveur. Cette solution de communication entre les nuds est efficace si le code de lagent est moins volumineux que celui des donnes analyser. Les architectures dIDS distribus ncessitent uniquement une mobilit faible (codes et donnes) des agents pour effectuer le prtraitement distant des donnes. Les travaux prsents dans (Krugel et al., 2002 ; Boukhatem, 1999 ; StanifordChen et al., 1995 ; Duarte de Queiroz et al., 1999) donnent les principaux avantages, rsums ci-dessous, des agents mobiles pour les MANET : lasynchronisme permet de dlguer une tche un agent mobile sans rester en attente du rsultat. Ce mode de traitement est particulirement adapt pour des liaisons rseaux peu stables comme celles des WLAN ; lautonomie et lintelligence permettent aux agents dadapter leur comportement selon les informations collectes localement et ventuellement de poursuivre leurs dplacements au sein du rseau pour terminer leur mission. Cette capacit dadaptation permet ainsi de limiter le trafic gnr sur le rseau ;

398

RSTI - TSI 23/2004. Scurit informatique

le temps de rponse des applications et la charge du rseau peuvent tre rduits par le dplacement du code vers les donnes plutt que le dplacement des donnes vers les applications. Nous proposons donc dutiliser des agents mobiles pour raliser la collecte et les prtraitements des donnes situes sur les nuds distants. Les IDS distribus prsents dans le tableau 1 ne sont pas spcifiques aux rseaux sans fil et donc, a fortiori, aux MANET. Leurs points communs sont un prtraitement des informations analyser ds leur collecte et lexception de CSM, conu et optimis pour un type dattaque, une organisation fonctionnelle hirarchique autour dun nud central permanent. Dans un MANET, un modle dorganisation distribue et hirarchique autour dun nud ne peut tre envisageable, en labsence dun nud permanent, quavec des mcanismes supplmentaires de gestion de cette hirarchie base, par exemple, sur un processus dlection du nud central. La mise en uvre dune telle approche saccompagne dchanges rseaux supplmentaires et fait apparatre un nouveau type de vulnrabilit lie au processus dlection du nud central. En consquence, nous ne souhaitons pas la retenir.

LIDS Agents mobiles et alertes intrusions LIDS

Agents mobiles et alertes intrusions

LIDS

Agents mobiles et alertes intrusions

Agents mobiles et alertes intrusions

Agents mobiles et alertes intrusions

LIDS Agents mobiles et alertes intrusions

LIDS

Agents mobiles et alertes intrusions LIDS Local IDS

Figure 1. Architecture globale de lIDS distribu

Nous proposons une nouvelle architecture dIDS distribue et cooprative, forme dun ensemble dIDS autonomes, appels LIDS (LIDS, Local Intrusion detection System), installs sur chaque nud. Chaque LIDS est dot dune plateforme agents pour collecter les donnes sur des nuds distants. La figure 1

Dtection dintrusions dans les MANET

399

reprsente larchitecture globale de lIDS pour MANET, que nous avons propose dans (Albers et al., 2002). Les messages dalertes gnrs par tous les LIDS prsents dans le rseau sont considrs comme une source dinformation supplmentaire traiter de faon spcifique. Dans la section suivante, nous prsentons larchitecture interne des LIDS.

4. Description de larchitecture modulaire dun LIDS Larchitecture interne que nous proposons pour les LIDS sappuie sur les modules prsents dans le modle dIDS propos par lIDWG (Intrusion Detection Working Group de lIETF)10. Celui-ci identifie les trois composants de base suivants reprsents sur la figure 2 : le senseur, charg de collecter et de mettre en forme les donnes brutes issues du systme ou du rseau ; lanalyseur, charg de traiter les informations gnres par le senseur afin didentifier les intrusions ; le manager, charg de grer les alarmes aprs dtection.

Manager

Alertes

Analyseur
Evnements

Requtes

Senseur

Sources des Donnes

Figure 2. Modle IDS de lIDWG, complt par le message Requte

Notre modle ajoute un nouveau type de message entre lanalyseur et le senseur. Ce message appel requte permet lanalyseur de demander et de collecter des informations complmentaires sil le souhaite. Dans la suite de cette section, nous dcrivons les caractristiques de larchitecture modulaire dun LIDS (voir figure 3) en suivant le processus de

10. Le document officiel de lIDWG est disponible.

http://www.ietf.org/html.charters/idwg-charter.html.

400

RSTI - TSI 23/2004. Scurit informatique

traitement des donnes depuis leur collecte jusqu la gestion des alarmes aprs dtection dune intrusion.

4.1. Les principaux lments dun LIDS Chaque LIDS est conu pour tre autonome et exploiter les informations collectes localement ou sur un nud distant. La figure 3 prsente les blocs fonctionnels qui composent larchitecture du LIDS.
LIDS
IHM Manager
Evnements Alertes

Analyseur Module de dtection

(Machines d'tats) Requtes

Signatures XML

Gestion de la distribution (Traitement des vnements et requtes)

Evnements & AlertesSNORT Alertes Requtes

MIB

Senseurs
Senseur distant Senseur local
Collecteur de donnes locales (MIB Browser)

Alertes Locales SNORT

SNORT (Local)
IDMEF-IDXP

Collecteur de donnes distantes (Plate-forme

AGENTS ) MOBILES

Agent SNMP

Architecture de communications (internes et externes)

Figure 3. Architecture modulaire dun LIDS

Un LIDS dispose de diffrentes sources dinformation pour dtecter les intrusions : lagent SNMP sollicit par le Senseur local pour collecter les informations de la MIB locale ; la plate-forme agents mobiles contrle lactivit des agents mobiles (cration, accueil, scurit, arrt) dont la mission est de collecter les informations sur les nuds distants ; lIDS SNORT install sur le mme nud gnre des alertes exploites par le LIDS. SNORT11 est, dans ce cas, considr comme un senseur local dont lalerte devient un vnement trait par le module gestion de la distribution.

11. //www.snort.org/.

Dtection dintrusions dans les MANET

401

Le module gestion de la distribution est linterface entre lanalyseur et les diffrents senseurs. Il met en forme et traite les vnements et requtes changs avec les diffrentes sources dinformation. Lanalyseur gnre des requtes pour collecter les informations et exploite les messages reus (vnements) pour raliser la dtection des intrusions. Quil soit comportemental ou par scnarios, le type dalgorithme utilis pour la dtection des intrusions na pas de consquence sur larchitecture du LIDS. La conception modulaire du LIDS simplifie la mise en uvre de ces diffrents algorithmes de dtection. Lvaluation de leurs performances dans les MANET nest pas aborde dans cet article. Le manager est charg de traiter les alertes reues du module interne analyseur. Les autres fonctions de ce module sont la rponse une intrusion et la gestion des alertes gnres par des IDS situs sur dautres nuds. Pour les changes dalertes entre les LIDS, nous proposons de retenir les formats dalertes IDMEF (Intrusion Detection Message Exchange Format ) et le protocole de transport associ IDXP (Intrusion Detection eXchange Protocol) proposs par lIDWG. La coopration entre les LIDS installs sur diffrents nuds est donc assure par les services de la plate-forme agents mobiles, le manager et le module IDMEF/IDXP.

4.2. Distribution des traitements entre les LIDS Pour effectuer le processus de dtection, un LIDS utilise les donnes prleves localement par le senseur local. La dtection de certaines attaques peut cependant ncessiter la prise en compte dinformations se trouvant sur des systmes distants. Par exemple, pour dtecter lorigine dune attaque distribue, un LIDS A pourrait demander au LIDS B de lui fournir des informations complmentaires sur des oprations excutes sur la machine de B. Pour rpondre aux exigences imposes par les MANET, notamment la faible bande passante et la stabilit des liaisons, nous proposons dutiliser des agents mobiles pour effectuer la collecte et le prtraitement des informations sur les htes distants. Les plates-formes agents (Lange et al., 1998 ; Cockayne et al., 1997) offrent les services de scurit lis leur activit (lauthentification des serveurs, le contrle de lintgrit du code de lagent et des serveurs, le contrle daccs aux ressources locales). Nous nous appuyons sur ces services de scurit spcifiques aux platesformes agents mobiles pour protger les LIDS. De plus, la plate-forme agents

402

RSTI - TSI 23/2004. Scurit informatique

mobiles (Aglets12) que nous utilisons dans notre prototype est dveloppe en java et bnficie donc des mcanismes de scurit inhrents ce langage. La mise en uvre dagents mobiles, en dplaant le code vers les donnes analyser, peut permettre de diminuer le volume des donnes changes sur le rseau. Le nud metteur dun agent peut aussi poursuivre ses traitements sans attendre le retour des informations. En outre, un agent mobile possde la capacit de se dplacer de nud en nud sans repasser par le nud qui la cr. Ce mode de dplacement contribue encore rduire le trafic entre les nuds. Les agents mobiles apportent aussi une rponse au problme du dimensionnement de lIDS par rapport la taille du rseau, puisqu leur arrive dans le rseau, les nouveaux nuds, grce leur plate-forme agents, cooprent avec larchitecture de lIDS dj en place.

4.3. Description de limplmentation Dans cette section, nous donnons les caractristiques de limplmentation ralise. Lobjectif de cette premire implmentation est de nous permettre de raliser les exprimentations ncessaires la validation de larchitecture dIDS distribue que nous proposons. Loptimisation des performances de lIDS sera ralise lissue de cette validation fonctionnelle. Lanalyseur constitue le cur du systme de dtection dintrusions. Pour cette premire version, nous utilisons une approche par scnarios. Chaque attaque est reprsente par un diagramme dtats dont les transitions sont ralises en fonction dvnements prdfinis, reprsents par des valeurs de variables MIB. Le senseur local gnre des requtes SNMP (GET et GETNext) adresses lagent SNMP charg de grer une MIB II standard tendue avec des variables complmentaires implmentes dans la MIB exprimentale. Les signatures des attaques, reprsentes par des machines tats finis, sont stockes dans un fichier au format XML. Lensemble de limplmentation a t ralise en Java. Les modules ont t implants sous la forme de Threads, pour respecter lexigence de moindre couplage entre modules. Pour les agents mobiles, nous utilisons la plate-forme Aglet. Nous avons utilis la version 3 du protocole OLSR13, seule disponible publiquement au dbut de nos exprimentations. Afin de permettre la collecte dinformation relative OLSR nous avons dvelopp une branche exprimentale de la MIB SNMP propre ce protocole de routage.

12. Aglets : http://aglets.sourceforge.net/. 13. (Clausen et al., 2002).

Dtection dintrusions dans les MANET

403

5. Description des attaques utilises pour les exprimentations Dans cette section, nous donnons trois exemples dattaques avec pour deux dentres elles la spcification des signatures qui en permettront la dtection, lautre est dtecte par lIDS SNORT. La premire attaque est une attaque sur le protocole de routage OLSR, qui se traduit par un dni de service (DoS) ; la deuxime est un balayage de ports, frquemment ralis pour prparer une attaque plus srieuse ; la troisime est constitue dune chane de connexions Telnet, aussi connue sous le nom dattaque Stepstone .

5.1. Attaque sur le protocole de routage OLSR 5.1.1. Fonctionnement du protocole OLSR (Clausen et al., 2002) est lune des propositions retenues par lIETF pour le routage dans les rseaux ad hoc. Cest un protocole proactif qui repose sur lchange rgulier dinformations sur la topologie du rseau. Lalgorithme est optimis par la rduction de la taille et du nombre des messages changs : seuls des nuds particuliers, les MPR, MultiPoint Relay, diffusent des messages de contrle sur la totalit du rseau. Les dfinitions suivantes sont utilises dans la description du protocole : nud : station dun rseau ad hoc implmentant le protocole OLSR ; interface : point daccs au rseau ad hoc. Un nud peut avoir plusieurs interfaces, chacune avec sa propre adresse IP ; voisin immdiat : le nud X est un voisin immdiat du nud Y ( un saut) si Y peut entendre le nud X (une des interfaces de X peut envoyer des messages sur lune des interfaces de Y) ; MPR (Multipoint relay) : nud slectionn par un de ses voisins immdiats (appel MS, MPR Selector) pour retransmettre ses messages de mise jour. Lensemble des MPR dun nud est choisi parmi les voisins immdiats, de manire permettre datteindre tous les nuds situs exactement 2 sauts ; lien : couple dinterfaces capables de communiquer (i.e. recevoir des messages). Ltat dun lien peut tre Sym (symtrique, les 2 interfaces peuvent sentendre), Heard ou Asym (le lien est asymtrique, cause de problmes de propagation radio), MPR (lmetteur a slectionn le nud comme MPR, le lien doit tre symtrique), Lost (le lien est perdu). Tous les nuds envoient priodiquement des messages HELLO leurs voisins immdiats (temporisateur HELLO_INTERVAL) sur chacune de leurs interfaces. Ces messages ne sont pas relays vers dautres nuds. OLSR utilise un seul format de message, transport par le protocole UDP. Lentte prcise si le message doit tre seulement transmis au voisinage immdiat ou bien lensemble du rseau.

404

RSTI - TSI 23/2004. Scurit informatique

Chaque nud maintient un cache de description de son voisinage : interfaces voisines, voisins 2 sauts, MPR et MS. Cette description est mise jour chaque rception dun message HELLO et les informations obsoltes sont effaces. Le routage OLSR est bas sur lacheminement des messages par les nuds qui ont un voisinage symtrique. Un lien ne peut participer une route que sil est symtrique. Le routage vers les stations loignes de plus dun saut (1+Nsaut) se fait grce aux MPR, qui diffusent priodiquement des messages TC (Topology Control) contenant la liste de leurs MS. Un numro de squence permet dliminer les doublons. Ces messages servent maintenir dans chaque station une table de la topologie. La table de routage est construite et mise jour partir des informations contenues dans la table des interfaces voisines et la table de la topologie, en utilisant un algorithme de plus court chemin. La mtrique prise en compte est le nombre de sauts. 5.1.2. Vulnrabilits Il est facile de gnrer des attaques de dni de service ou dcoute passive par compromission dun nud MPR qui mettra des messages TC fallacieux. En outre, il est aussi possible de casser un lien symtrique par des messages HELLO errons. De cette manire, on interrompt les communications avec les voisins immdiats et loigns, le routage utilisant seulement les liens symtriques. Cette vulnrabilit est exploite dans lattaque prsente ci-aprs. Remarque. Ces vulnrabilits, qui reposent sur lmission de messages fallacieux par un nud malveillant insr dans le rseau, sont dans leur principe communes aux autres protocoles de routage ad hoc. 5.1.3. Description de lattaque La figure 4 prsente le scnario de lattaque. Avant lattaque, les nuds A et B ont tabli un lien symtrique. 1) le nud A diffuse un message HELLO contenant ladresse IP (Internet Protocol) du nud B (IPB) dans la liste de ses liens symtriques ; 2) la rception de ce message, lattaquant envoie un message erron semblant issu de A avec ladresse IPB dans la liste des liens marqus perdus. B doit changer ltat du lien avec IPA en Heard et ne peut plus envoyer de messages vers A. A reoit aussi le message erron, mais comme rien nest prvu dans OLSR pour traiter ce problme, un correctif ne sera transmis que par le message HELLO suivant ; 3) B diffuse un message HELLO avec IPA dans la liste des liens asymtriques ; 4) lattaquant devra continuer gnrer un message erron la rception du message de B. Cela aura pour effet de casser la symtrie du lien de A avec B, stoppant ainsi tout trafic de A vers B. B recevra aussi le message erron.

Dtection dintrusions dans les MANET

405

Figure 4. Attaque par dni de service Nsaut

Lattaque est difficile parer : corriger la situation en renvoyant un message HELLO correct conduirait le rseau dans un tat instable si lattaquant persiste renvoyer des messages. Lauthentification peut liminer les attaques gnres par des intrus, mais pas celles opres par des stations lgitimes mais corrompues. 5.1.4. Signature de lattaque Description des tats : Nsaut_S0 : Normal, pas dtat ASYM du lien ; Nsaut_S1 : tat ASYM du lien dclar ; Nsaut_S2 : dtection possible dune attaque de type Dni de Service Nsauts , dcision selon les tats du lien pendant le prochain HELLO_INTERVAL. Description des vnements : NSaut_E0 : le lien na pas t dclar ASYM pendant le dernier HELLO_INTERVAL ; NSaut_E1 : le lien a t dclar ASYM puis SYM ou MPR pendant un ou plusieurs HELLO_INTERVAL ; NSaut_E2 : le lien a t dclar ASYM pendant un ou plusieurs HELLO_INTERVAL ; NSaut_Attaque : dtection de lattaque. Les changements dtats se font sur lapparition dvnements dtects par la lecture de variables dans la MIB. Le test des variables de la MIB est ralis

406

RSTI - TSI 23/2004. Scurit informatique

priodiquement toutes les 2 secondes (Valeur du paramtre Hello_Interval prconis par OLSR).
NSaut_E2

NSaut_S1 NSaut_E0 NSaut_E1 NSaut_S0 NSaut_E2 NSaut_E0 NSaut_E0 NSaut_S2 NSaut_E1

NSaut_E1 /Alerte N_Saut Attaque NSaut_ATTAQUE

Figure 5. Signature de lattaque par dni de service NSaut

5.1.5. Description des variables de la MIB Une extension de la MIB standard a t dfinie. Il sagit dune table dont chaque lment est form des trois variables suivantes : OlsrNeighborState : tat courant du lien avec le voisin (Sym, Asym, MPR, Lost), OlslrPreviousNeighborState : tat prcdent du lien, OlsrNeighborAddress : adresse IP du voisin. Ces variables sont mises jour chaque rception ou mission dun message HELLO. Les vnements rsultent du changement dtat des variables, qui sont testes priodiquement toutes les 2 secondes (HELLO_INTERVAL).

5.2. Dtection des ports actifs par balayage Le balayage de ports, appel ports scanning, a pour objectif didentifier les ports actifs dun nud. Bien que cette opration ne reprsente pas une attaque immdiate contre un service offert par le nud, elle constitue trs frquemment ltape pralable au lancement dattaques plus srieuses. Les nuds dun MANET

Dtection dintrusions dans les MANET

407

directement accessibles par des nuds trangers leur communaut sont particulirement exposs ces actions dinvestigation. Pour la dtection des balayages de ports nous utilisons lIDS SNORT, install sur le mme nud que le LIDS, configur pour enregistrer ses alertes dans une base locale MySQL. Lalerte est prise en compte par le module gestion de la distribution . Si ncessaire la collecte des alertes SNORT sur les autres nuds du rseau est ensuite ralise par des requtes locales ralises par des agents mobiles pralablement dplacs. Si le rsultat dun balayage des ports permet didentifier que le port Telnet est ouvert, une attaque du type Stepstone prsente dans la section suivante peut, par exemple, tre lance.

5.3. Attaque Stepstone Lattaque stepstone (Staniford et al., 1995) correspond la cration dune chane de connexions (telnet par exemple) vers un terminal distant. Une attaque de ce type prcde gnralement des actions plus graves car elle rend plus difficile la localisation de lattaquant. Cette technique est couramment utilise par les hackers pour masquer leur machine. La figure 6 illustre le principe de lattaque stepstone . Lattaquant initie une connexion avec un autre nud du rseau (Nud B). Depuis ce nud lattaquant poursuit son chemin vers un autre nud (Nud C) et ainsi de suite jusqu atteindre lhte cible de lattaque.

Figure 6. Attaque Stepstone (chanage de connexions telnet)

5.3.1. Signature de lattaque La dtection dune attaque de type stepstone se dcompose en deux phases distinctes.

408

RSTI - TSI 23/2004. Scurit informatique

Tout dabord, ds quun nud est la cible dune connexion Telnet entrante (vnement local STEPSTONE_E0), il interroge lhte initiateur de la connexion afin de connatre son origine (requte distante STEPSTONE_Q1). Si lhte interrog ne gre aucune connexion entrante associe au port de sortie (cest donc que le nud est lorigine de la chane), il le signale linitiateur de la requte en lui transmettant lvnement STEPSTONE_E1. Un nud recevant un tel vnement doit mmoriser la chane correspondante. Elle est compose dexactement deux lments : le receveur et lexpditeur de lvnement, ce dernier y figurant en tant que source de la chane. Dans le cas contraire, lhte interrog transmettra linitiateur de la requte, la chane existante (vnement STEPSTONE_2). Sur rception de ce type dvnement, linitiateur de la requte mmorise la chane envoye et y ajoute lmetteur du message en tant que dernier maillon. Une chane est limine quand la connexion correspondante son dernier maillon se ferme. Ceci est signal par lvnement local STEPSTONE_E3. La rception dun vnement STEPSTONE_E2 indique la prsence dune chane de connexions, comprenant au moins trois nuds. La requte STEPSTONE_Q0 (en attente dun des vnements STEPSTONE_E0 ou STEPSTONE_E3) doit tre excute de manire priodique. En revanche, on remarque que la soumission de la requte STEPSTONE_Q1 (en attente dun des vnements STEPSTONE_E1 ou STEPSTONE_E2) est, quant elle, dclenche en raction une transition dtat (apparition ou disparition dune connexion TCP). Lautomate de figure 7 reprsente une signature de lattaque Stepstone (chane de connexions Telnet).
STEPSTONE_S0 STEPSTONE_E0 STEPSTONE_E3 STEPSTONE_S1

STEPSTONE_E3

STEPSTONE_E3

STEPSTONE_E1

STEPSTONE_S3 STEPSTONE_E2 / Alert: STEPSTONE_ATTACK

STEPSTONE_S2

Figure 7. Signature de lattaque Stepstone (chane de connexions Telnet)

La table tcpConnTable de la MIB SNMP standard contient les informations relatives aux connexions TCP actives. Pour chacune delles, elle indique ladresse IP

Dtection dintrusions dans les MANET

409

de la machine locale, le port TCP sur la machine locale, ladresse IP de la machine distante, et le port TCP sur la machine distante. Dans la version actuelle de notre prototype, sur chaque nud, un module spcifique est charg de dtecter les associations entre les connexions entrantes et sortantes. 5.3.2. Dtection de lorigine de la chane de connexions Telnet La dtection de lattaque Stepstone, dcrite ci-dessus, permet dillustrer le rle des agents mobiles dans larchitecture prsente figure 3. Nous considrons ici une connexion Telnet ralise en cascade sur trois nuds quips dun mme LIDS et dun agent SNMP. Cette chane de connexions est reprsente sur la figure 6. Nous nous intressons au comportement du LIDS de C. Premire tape : sur C, lanalyseur est inform de larrive dune nouvelle connexion TCP. Dans notre exemple cette dernire est identifie de manire unique par ses adresse et port sources (@IPB et PsB). Deuxime tape : sur C, lanalyseur doit maintenant dterminer si B est le premier nud de la chane. Cette requte est transmise au gestionnaire de distribution qui envoie alors un agent mobile sur B pour collecter cette information. Troisime tape : sur B, lagent met une requte au module de gestion de la distribution pour obtenir la chane de connexion dont le port de sortie est PsB. Si lIDS de B ne possde pas encore cette information (i.e. si son propre agent charg de la collecter nest pas rentr) lagent attendra quelle soit disponible. Dans notre exemple cest la chane de connexion dont lorigine est @IPA et PsA qui est identifie. Quatrime tape : lagent retourne sur le nud C avec les donnes collectes sur B et les transmet ensuite lanalyseur. Cinquime tape : lIHM affiche la chane des connexions. La rponse la dtection dune attaque Stepstone, i.e. la fermeture de la connexion, peut-tre ralise linitiative de loprateur.

6. Exprimentations et mesures 6.1. Objectifs des exprimentations Nous avons expliqu, dans la section prcdente, comment les agents mobiles permettent aux LIDS de cooprer. Dans cette section, nous valuons les performances des agents mobiles et des changes client/serveur pour raliser la coopration entre les LIDS. Dans la suite de cette section, nous prsentons une validation fonctionnelle sur la base des trois attaques dcrites ci-dessus (section 6.3), puis les aspects qualitatifs (section 6.4) et les aspects quantitatifs (section 6.5) de la comparaison client/serveur vs agents mobiles. Nous terminons cette section par une

410

RSTI - TSI 23/2004. Scurit informatique

conclusion sur lapport des agents mobiles dans la coopration entre les LIDS dun rseau ad hoc.

6.2. Description de la plate-forme de mesures Nous utilisons larchitecture rseau reprsente sur la figure 8. Le nud A possde des filtres Iptables pour bloquer les trames MAC gnres par le nud C. Le nud B est alors lu MPR des nuds A et C quelles que soient leurs positions. De mme, nous simulons linstabilit des liaisons physiques, caractristique des WLAN, par lapplication de filtres IP sur les diffrentes interfaces des nuds.

A
@MAC : @IP : 192.168.1.5

B
@MAC : @IP : 192.168.1.4

C
@MAC : @IP : 192.168.1.3

Zone mission de A Zone mission de B Zone mission de C

Figure 8. Rseau 802.11b en mode ad hoc routage OLSR

Tous les nuds sont configurs avec le systme Linux SuSE 8.2 - Kernel 2.4.20, un Analyseur 14, un agent SNMP15, la plate-forme java 1.4.1, une plate-forme agents16, lIDS SNORT 2, le LIDS (dveloppement propritaire en java). Le tableau 2 prsente les configurations matrielles des diffrents nuds.

14. Ethereal 0.9.10 - Libcap 0.7. 15. ucd-SNMP 4.2.6. 16. IBM Aglet Class Library 2.1.0- Aglet API : 1.2 -IBM Corp.

Dtection dintrusions dans les MANET Plate-forme matrielle NEC Mate Interface 802.11b

411

Nud A

Adresse MAC 00 :0A :8A :A2 :C7:BB 00 :0A :8A :A2 :AB:8E

Adresse IP 192.168.1.4 192.168.1.5

Power CISCO PCI AiroNet 350 CISCO PCMCIA AiroNet 350

NEC Versa B FC140-256M NEC Mate

Power CISCO PCI AiroNet 350

00 :0A :8A :A2 :C9:45

192.168.1.3

Tableau 2. Configuration des nuds

6.3. Validation fonctionnelle Les trois attaques, prsentes dans la section 5 sont correctement dtectes leur excution. La premire attaque (NSaut) est dtecte localement sans quil soit ncessaire de faire appel un agent mobile. La seconde attaque est dtecte par SNORT qui transmet son alerte au LIDS. Nous vrifions aussi que les agents mobiles permettent didentifier parmi les nuds prsents dans le rseau ceux qui ont t soumis des attaques de mme type. La dtection de la troisime attaque (StepStone) fait galement appel la coopration entre LIDS. Des agents mobiles sont crs par les LIDS des nuds dtectant une connexion Telnet entrante. Ces trois formes de dtection montrent la capacit de notre architecture dtecter localement et de manire distribue des attaques de niveau rseau ou application. Pour dtecter la premire et la troisime attaques, les senseurs utilisent les informations de la MIB. LIDS SNORT utilise, quant lui, les donnes collectes sur le rseau.

6.4. valuation qualitative de la coopration entre les LIDS Nous utilisons les donnes stockes dans la base MySQL par SNORT lorsquune attaque du type balayage de ports, dcrite dans la section 5.2, est dtecte. Pour connatre la svrit de lalerte, le LIDS recherche les attaques du mme type ralises sur les autres nuds du rseau. Les exprimentations de cette section ont pour objectif danalyser la collecte de ces alertes ralise par des requtes MySQL distantes en mode client/serveur et par des requtes locales ralises par des agents mobiles pralablement dplacs. Lobjectif est ici de comparer les deux modes de collecte dans un rseau dont les liens physiques sont instables. Les exprimentations sont ralises en suivant les tapes dcrites ci-dessous. Premire tape : comportement des changes client/serveur travers le rseau.

412

RSTI - TSI 23/2004. Scurit informatique

Sur une interface, nous simulons une rupture de la connexion physique lors de ltablissement requtes SQL et nous capturons avec lanalyseur ETHEREAL les trames rseaux gnres. Les traces, reprsentes sur la figure 9, ont t captures lors dune requte MySQL effectue depuis le nud 192.168.1.3 vers la base MySQL_SNORT situe sur le nud 192.168.1.5.

Figure 9. Requtes client/serveur avec des connexions rseau instables

Nous constatons que suite une demande de requte, la couche TCP tente douvrir une connexion pendant 98 secondes par lmission de segments TCP avec le drapeau SYN. Au-del de ce dlai, la demande ouverture de la connexion TCP est abandonne, de mme que linterrogation de la base MySQL distante. Une nouvelle tentative de connexion la base MySQL ne peut tre ralise quen gnrant une nouvelle requte. Deuxime tape : comportement des agents mobiles. Nous utilisons un aglet qui se dplace sur les diffrents nuds du rseau pour interroger les bases MySQL de SNORT et ramener les informations. Le LIDS cre un agent mobile autonome et asynchrone programm pour attendre quune route vers la destination soit tablie avant douvrir une connexion TCP. A lmission de lagent, nous simulons une rupture de la connexion dune dure suprieure celle mesure dans le scnario de la premire tape. Nous constatons,

Dtection dintrusions dans les MANET

413

sur les traces de la figure 10, que lagent mobile utilise la connexion ds que celle-ci est de nouveau disponible sans limite de temps.

Figure 10. Dplacement dun agent avec des connexions physiques instables

Troisime tape : analyse des exprimentations ralises dans les deux tapes prcdentes. Linstabilit des connexions physiques dun rseau perturbe le comportement dune connexion TCP et ne lui permet pas dassurer des changes fiables. Ce comportement de TCP, frquent dans les rseaux ad hoc en raison de linstabilit des connexions sans fil, a t mis en vidence dans (Liu et al., 2001). Nous constatons que le comportement autonome et asynchrone des agents mobiles leur permet de sadapter aux volutions de la topologie dun MANET pour atteindre leur destination. De ce fait, dans un rseau ad hoc, les changes dinformation par le biais dagents mobiles sont plus fiables que des changes client/serveur travers le rseau. Des agents mobiles autonomes programms pour

414

RSTI - TSI 23/2004. Scurit informatique

se dplacer et traiter des donnes sur des systmes distants permettent aux applications communicantes dtre dcharges de la gestion des connexions

6.5. valuations quantitatives lies lusage des agents mobiles Lors de son dplacement, pour sexcuter sur un nud distant, le comportement dun aglet est diffrent selon les ressources logicielles (classes java) disponibles sur ce nud. Ce comportement a une influence importante sur la charge rseau induite et sur les temps de rponse. 6.5.1. Les modes de dplacement dun aglet La plate-forme Aglet transfre les agents en trois phases. Tout dabord, laglet est envoy par une commande DISPATCH. Si la plate-forme destination ne possde pas les dfinitions des classes ncessaires lexcution de laglet, elle en fait la demande, par une commande FETCH, lmetteur de laglet. Un accus de rception (DISPATCH) est transmis pour confirmer la disponibilit de toutes les classes demandes (figure 11).
NOEUD A NOEUD B

DISPATCH

FETCH Fichier_1 Fichier_1 ACK FETCH Fichier_2 Fichier_2

DISPATCH ACK

Figure 11. changes pour le dplacement dun aglet 6.5.2. Mesure du temps daccs un saut aux variables MIB par le dplacement dun aglet Compte tenu du mode de dplacement dun aglet nous ralisons trois scnarios de mesures pour effectuer des requtes MIB sur un nud situ un saut : dplacement dun aglet sans code prinstall, avec retour de toutes les variables SNMP collectes ;

Dtection dintrusions dans les MANET

415

dplacement dun aglet avec code prinstall, avec retour de toutes les variables SNMP collectes ; dplacement dun aglet avec code prinstall, sans retour des variables SNMP collectes.
Nombre de requtes SNMP Requtes directes Sans code prinstall Avec code prinstall Avec code prinstall et sans retour des variables 10 43,5 1697 300 175 25 109 1747 330 200 50 217 1825 390 260 100 435 1990 540 410 200 870 2570 740 580

Tableau 3. Temps de collecte de variables MIB (en milliseconde)

Nous constatons (voir tableau 3) quil faut collecter un grand nombre de variables, entre 100 et 200 selon le type de traitement effectuer sur ces variables, pour que les aglets deviennent plus performants que des requtes directes si nous considrons uniquement le temps de collecte. Dans un processus de dtection dintrusions bas sur la collecte dinformation dans une MIB, ce seuil est trop lev pour pouvoir justifier, lui seul, le choix de la plate-forme Aglet pour collecter les informations situes sur dautres nuds. 6.5.3. valuation de la charge rseau induite par le dplacement dun aglet Nous valuons les charges rseau induites par la collecte dinformation dans la MIB effectue distance par des requtes SNMP et localement par un aglet pralablement dplac. Dans le cas dun premier dplacement de laglet, le code associ ncessite deux commandes DISPATCH et deux commandes FETCH (cf. figure 11). Lors dun dplacement de laglet sans les fichiers associs, deux commandes DISPATCH sont ncessaires. Le nombre doctets changs selon le mode de transfert de laglet est reprsent dans le tableau 4.
Dplacement du code de Sans dplacement du laglet code de laglet changes ATP
17

26 695

19 208

17. ATP : Aglet Transfer Protocol.

416

RSTI - TSI 23/2004. Scurit informatique changes TCP/IP Total 5 476 32 284 3 197 22 405

Tableau 4. Charge rseau induite par le dplacement dun aglet (en octet)

Nous pouvons comparer ces chiffres au nombre de donnes changes sur le rseau lors dune requte SNMP et de sa rponse (figure 14).
802.11b 30 IP 20 UDP 8 SNMP 41 Variables Binding 2N

Figure 12. Format dune requte SNMP (en octet)

Nous constatons la lecture du tableau 4 quil faut effectuer plus de 120 requtes de variables simples SNMP dans une MIB pour gnrer sur le rseau un volume de donnes quivalent celui du dplacement dun aglet sans son code. Lutilisation de la plate-forme agents mobiles Aglet pour collecter des donnes, dans une MIB, situe sur un nud distant, gnre un trafic rseau important compar celui dune requte SNMP simple. 6.5.4. Analyse des mesures ralises Les valuations quantitatives montrent que la collecte dinformation dans la MIB situe sur un nud distant est plus lente et charge plus le rseau quand celle-ci est ralise par un aglet que par une requte de type SNMP travers le rseau. Toutefois, il convient de noter que sur des critres quantitatifs, la performance des agents mobiles dpend du rapport entre le volume du code et le volume des donnes dplacer. Dans nos mesures, le volume des donnes dplaces reprsente quelques octets. De plus, la plate-forme agents mobiles gnrique Aglet utilise des protocoles de contrles complexes (cf. tableau 4). Ce contexte propre nos mesures explique quil faut raliser un nombre lev de requtes SNMP pour commencer tirer profit des agents mobiles si lon ne considre que les critres quantitatifs (cf. tableau 3). Une valuation de performance entre deux plates-formes agents mobiles, dont la plate-forme Aglet, et un modle client/serveur bas sur RMI est prsente dans (Hagimont et al., 2000). On constate que des gains defficacit significatifs peuvent tre obtenus en utilisant des agents mobiles. Entre autres, la plate-forme optimise construite spcialement a permis de rduire par 7 les temps de migration dun agent sur un LAN ETHERNET. Cette diffrence sexplique par la complexit du protocole ATP (Aglet Transfert Protocol) qui ncessite plusieurs envois de messages pour dplacer un agent.

Dtection dintrusions dans les MANET

417

Si nous considrons uniquement les critres quantitatifs, ltude dune plateforme agents mobiles lgre et spcifique est donc ncessaire pour pouvoir justifier de son choix dans un rseau ad hoc. Mais lutilisation des agents mobiles dans les rseaux ad hoc repose prioritairement et principalement sur des critres qualitatifs. En effet, les modifications de la topologie, rsultant de linstabilit des liaisons sans fil et du dplacement des nuds, perturbent le fonctionnement du protocole TCP dont la fonction est de garantir la fiabilit des connexions (cf. section 6.4) (Holland et al., 2001). Lutilisation dun protocole TCP spcifique pour les rseaux ad hoc (Liu et al., 2001) rduit, selon nous, linteroprabilit entre les systmes. Nous montrons ici que les agents mobiles, utiliss la place des connexions client/serveur, peuvent adapter leur comportement aux modifications de la topologie et ainsi collecter des informations sur des nuds distants dune faon fiable. Si un LIDS utilise des requtes SNMP/UDP travers un rseau, ces dernires nont alors aucune garantie de fiabilit en raison du mode datagramme propre UDP.

7. Conclusions et travaux futurs Nous avons prsent dans cet article une architecture dIDS distribu pour les rseaux ad hoc. La conception modulaire dun LIDS permet de le configurer pour ladapter aux caractristiques de chaque nud. Pour les nuds disposant de ressources suffisantes, lintgration de SNORT au LIDS permet, dune part, dtendre la base des signatures dattaques et, dautre part, aux IDS SNORT de sappuyer sur la plate-forme agents mobiles pour cooprer et, par exemple, rechercher ltendue dune attaque lchelle du rseau. Nous montrons que dans les rseaux ad hoc, les agents mobiles peuvent par leur intelligence sadapter aux modifications de la topologie. Leur utilisation se justifie principalement comme un moyen dobtenir des changes fiables dans un rseau dont larchitecture est instable. Les rsultats quantitatifs, concernant principalement les temps de rponse et la charge rseau, sont troitement lis aux caractristiques de la plate-forme agents comme cela est prsent dans (Hagimont et al., 2000). De rcents travaux sur les protocoles de routage ad hoc (Migas et al., 2003) se sont aussi intresss aux agents mobiles. Nous pensons que dans les MANET, diffrentes applications comme le routage, la dtection dintrusions et les services de scurit, pourraient bnficier des services rendus par les agents mobiles. Dautre part, la plate-forme Aglet que nous avons utilise dans notre prototype pour raliser les validations fonctionnelles nest pas adapte lvaluation des performances des agents mobiles dans les rseaux ad hoc. La spcification et la conception dune plate-forme agents mobiles pour les rseaux ad hoc constitue une des prochaines tapes de nos travaux en cours.

418

RSTI - TSI 23/2004. Scurit informatique

Enfin, nous travaillons actuellement la mise en place dune approche comportementale afin dobtenir, par coopration avec lapproche par scnarios dj en place, un IDS ad hoc distribu hybride. A cette fin, nous adaptons lapproche de modlisation de comportement dveloppe au sein de notre quipe et prsente dans (Puttini et al., 2002). Remerciements Les rsultats prsents dans cet article ont t obtenus dans le cadre du projet RNRT prcomptitif RAHMS (Rseau Ad Hoc Multiservice Scuris). Les auteurs tiennent ici remercier le RNRT et le ministre de lIndustrie pour leur soutien. En outre, les auteurs remercient lensemble des participant au projet et tout particulirement Catherine Devic (EdF), Eric Carmes et Jean-Mickael Guerin (6Wind), Nicolas Jordan (Netcentrex).

8. Bibliographie
Albers P., Camp O., Percher J.-M., Jouga B., M L., Puttini R., Security in Ad hoc Networks: a General Intrusion Detection Architecture Enhancing Trust Based Approaches, WIS 2002, Ciudad Real Spain, April 2002. Asaka M., Atsushi Taguchi, Shigeki Goto, IDA-The Implementation of IDA : An Intrusion Detection Agent System, IPA Waseda University, 1999. Boukhatem N., Les agents mobiles et applications , Actes du colloque DNAC, 1999. Cabrera J. B. D., Lewis L., Qin X., Wenke Lee, Ravi Prasanth, Ravichandran B., Raman Mehra, Proactive Dectection of Distributed Denial of Service Attacks Using MIB Traffic Variables-A Feasibility Study, in Proceedings of The Seventh IFIP/IEEE International Symposium on Integrated Network Management, (IM 2001), Seattle, WA, May 2001. Clausen T., Jacquet P., Laouiti A., Minet P., Muhlethaler P., Qayyum A., Viennot L., Optimized Link State Routing Protocol - Internet Draft version 5, INRIA, 30 April 2002. Cockayne W. T., Zyda Michael, Mobile Agents, Editions Manning, 1997. Corson S., Macker J., Mobile ad hoc networking (manet), Routing protocol performance issue and evaluation consideration, Requet for Comments (Informational) 2501, IETF, 1999. Duarte de Queiroz J., Rust da Costa Carmo L. F., Pirmez L., Micael: An Autonomous Mobile Agent System to Protect New Generation Networked Applications, Nucleo de Computacao Eletronica UFRJ, Brazil, in the Proceedings of RAID99. Feeney L. M., Ahlgren B., Assar Westerlund, Spontaneous networking: An apllication oriented approach to ad hoc networking, IEEE Communication Magazine, 39(6), June 2001.

Dtection dintrusions dans les MANET

419

Fou Y. F., Gong F., Sargor C., Wu X., Wu S. F., Chang H. C., Wang F., JINAO-Design and Implementation of a Scalable Intrusion Detection System for the OSPF Routing Protocol , Advanced Networking Research, MCNC Computer Science Dept, NC State University, February 1999. Hagimont D., Ismail L., Agents mobiles et client/serveur : valuation de performances et comparaison , Technique et science informatiques, vol. 19, n 9,2000. Holland G., Vaidya N. H, Analysis of TCP Performance over Mobile Ad Hoc Networks, ACM/Kluwer Journal of Wireless Networks, 8 (2-3), 2002, p. 275-288. Ko C., Ruschitzka M., Levitt K., Execution Monitoring of Security-Critical Programs in Distributed Systems: A Specification-based Approach, Proceedings of the 1997 IEEE Symposium on Security and Privacy. Krugel C., Toth T., Flexible, Mobile Agent Based Intrusion Detection for Dynamic Networks, European Wireless 2002, Florence, Italy 2002. Lange D. B., Oshima Mitsuru, Programming and Deploying Java Mobile Agents with Aglets, Editions Addison-Wesley, 1998. Liu J., Singh S., ATCP: TCP for mobile ad hoc networks, IEEE journal on Selected Areas in Communications, (J-AC),19 (7), July 2001, p. 1300-1315. M L., Michel C., La dtection dintrusions : bref aperu et derniers dveloppements , Actes du congrs EUROSEC99, 1999. Migas N., Buchanan W. J., Mc Arteney K. A., Mobile Agents for Routing, Topology Discovery and Automatic Network Reconfiguration in Ad hoc Networks, 10th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS03), Huntsville, Alabama, April 07, 2003. Puttini R., Marrakchi Z., M L., Bayesian Classification Model for Real-Time Intrusion Detection, 22th International Workshop on Bayesian Inference and Maximum Entropy Methods in Science and Engineering (MAXENT2002), August 2002. Snapp S. R., Brentano J., Dias G. V., Terrance L., Goan L., Heberlein T., Che-Lin Ho, Levitt K. N., Biswanath Mukkherjee, Smaha S. E., Grance T., Teal D. M., Mansur D., DIDSDistributed Intrusion Detection System, Computer Security Laboratory, Department of Computer Science, University of California, Davis, June 1992. Staniford-Chen S., Cheung S., Crawford R., Dilger M., Frank J., Hoagland J., Levitt K., Wee C., Yip R., Zerkle D., GrIDS - A Graph Based Intrusion Detection System for Large Networks, Computer Security Laboratory, Department of Computer Science, University of California, Davis, 1996. Staniford-Chen S., Heberlien T., Holding intruders accountable on the internet, Proceedings of the 1995 IEEE symposium on security and privacy, Oakland, May 1995, p 39-49. Sundar Balasubraniyan J., Garcia-Fernandez Jose Omar, Isacoff David, Spafford Eugene, Zamboni Diego, AAFID - Autonomous Agents For Intrusion Detection, Technical report 98/05, COAST Laboratory Purdue University, June 1998.

420

RSTI - TSI 23/2004. Scurit informatique

White G. B., Fish E. A., Udo Pooch, CSM - Cooperating Security Managers: a peer based intrusion detection system, IEEE Networks, p. 20-23, January/February 1996. Wood M., Erlinger M., Intrusion Detection Message Exchange Requirements, Internet Draft, October 22, 2002, http://www.ietf.org/internet-drafts/draft-ietf-idwg-requirements-10.txt.

Jean-Marc Percher est ingnieur ESEO (cole Suprieure dlectronique de lOuest). Enseignant-chercheur lESEO depuis 1980, il est depuis 1999 responsable du Dpartement Informatique et Mathmatiques. Il est lauteur de plusieurs communications dans le domaine de la scurit des rseaux sans fil. Il prpare une thse sur la dtection dintrusions dans les rseaux ad hoc. Ricardo Puttini est enseignant et doctorant lUniversit de Brasilia. Spcialiste en rseau informatique, son sujet de thse porte sur la protection prventive et corrective des protocoles de routage pour rseaux ad hoc. Ludovic M est ingnieur Suplec et docteur de lUniversit de Rennes 1. Il a soutenu une HDR en 2003. Son domaine de recherche est la dtection des intrusions dans les systmes dinformation. Enseignant-chercheur Suplec depuis 1988, il est depuis 1997 responsable de lquipe de recherche SSIR (Scurit des Systmes dInformation et Rseaux). Membre du comit de pilotage du symposium RAID (Recent Advances in Intrusion Detection), il a coprsid le comit de programme de ce mme symposium en 2001. Il est lauteur dune vingtaine de communications dans des revues et des confrences internationales comit de lecture (voir www.rennes.supelec.fr/rennes/si/equipe/lme). Olivier Camp est docteur de lUniversit Paris 6. Enseignant-chercheur lESEO depuis 2000, il travaille au sein de lquipe Systmes Coopratifs et Distribus. Il a coprsid le comit de programme du congrs ICEIS2003 (International Conference on Enterprise Information Systems). Il a publi plusieurs articles sur la scurit des rseaux sans fil. Bernard Jouga est ingnieur Suplec. Enseignant-chercheur Suplec depuis 1983, il est depuis 1998 responsable du mastre spcialis en rseaux informatiques et tlcommunications. Il est lauteur de plusieurs communications dans le domaine des rseaux et de la scurit des systmes dinformation. (voir www.rennes.supelec.fr/ren/perso/bjouga). Patrick Albers est docteur de lUniversit Toulouse 3. Enseignant-chercheur lESEO depuis 2000, il travaille au sein de lquipe Systmes Coopratifs et Distribus. Il est lauteur de plusieurs communications dans le domaine de la scurit des rseaux sans fil.

Article reu le 18 novembre 2002 Version rvise le 27 novembre 2003 Rdacteur responsable : Michael Rusinowitch