transition (MTU), et consiste à fragmenter ses paquets sur plusieurs unités qui une fois rassemblées au niveau de l’hôte cible causent une attaque. Pour plus de complexité et d’efficacité, cette technique peut être combinée avec la technique de flooding.
Pour que les systèmes de détection puissent détecter l’attaque, ils doivent être en mesure de stocker les unités fragmentées pour pouvoir reconstituer le paquet initial. Cela exige d’importantes capacités mémoire et un temps de traitement très considérable.
3. Le cryptage : Le cryptage des paquets rend anodins les systèmes de détection d’intru-sion. C’es pourquoi les pirates font, le plus souvent appel à des mécanismes de chiffre-ment, tels que SSL ou SSH pour dissimuler leurs attaques.
4. L’obscurcissement : Cette technique est incontestablement, la plus utilisée. Elle consi-ste à utiliser une codification non standard pour représenter les données dans le but de masquer l’attaque. Cela peut être réalisé soit par des insertion des caractères spéciaux tel que le retour chariot, le caractère de tabulation,... ou l’utilisation d’un uni-code différent du code ASCII et indépendant de tout langage, programme ou plate forme. Par exemple l’intrus peut tromper l’ IDS en remplaçant le caractère "/" dans une sollicitation de page web par le caractère uni-code c1.4
4. Le fait de dissimuler une attaque utilisant des caractères Unicode, hexadécimal ou de contrôle pour cacher une attaque contre un système de détection d’intrusion est communément appelé obfuscation
1.4.5 Interopérabilité des systèmes de détection d’intrusion
La détection d’intrusion a suscité ces dernières années une très grande attention et son déploiement au sein des entreprises, se fait d’une manière très rapide. Pour faire face à cette demande grandissante, une pléthore de produits de détection d’intrusion, en version commer-ciale aussi bien qu’en "open source" a été lancée (environ 130 ont été répertoriés dans [71] en janvier 2003). Or le problème crucial de ces produits fermés et incompatibles entre eux, réside dans le fait qu’aucun de ces systèmes détection n’est capable, à lui seul, de faire face à toutes les attaques et qu’on ne disposait pas d’un moyen standard pour les faire communiquer et col-laborer. Dans ce contexte, plusieurs efforts ont été consentis afin de résoudre ces problèmes et de définir ainsi des outils d’interopérabilité entre systèmes de détection d’intrusion. Parmi les aboutissements de ces efforts, on cite :
Le CIDF(Common Intrusion Detection Framework)[316] fut le résultat d’un projet de recherche entamé, en 1997, par DARPA5. L’objectif du CIDF est de permettre, d’une part l’interopérabilité des différents systèmes impliqués dans la surveillance du système informatiques et la ré-utilisation de leurs composants. Cette plate forme est composée de quatre types de composants : Des générateurs d’événements (E-boxes), des analyseurs(A-boxes), une bases de données(D-boxes) et d’un mécanisme de réponse(R-boxes). Les mécanismes de contre-mesures sont également représentés sous forme de C-box(Fig. 1.9).
Figure 1.9 – Architecture de CIDF
— Le générateur d’événement, constitué d’un ensemble de composants dits E-boxes fonc-tionnant en tant que "senseurs terminaux", fournit, au système de détection d’intrusion, des informations pertinentes sur le système surveillé.
— L’analyseur, un ensembles de A-boxes explore les données provenant des E-boxes dans le but de détecter une attaque.
— La base de données(système de stockage), ou "D-box", permet de conserver les trace des événements que le moteur d’analyse a considéré comme étant hostiles.
— Le mécanisme de réponse(R-boxes) constitue l’unité de réactions ayant pour objectif de réagir au nom d’autres composants de CIDF. Une réponse peut être, par exemple, : l’arrêt d’un processus, la ré-initialisation des connexions...
Le module de contre-mesures ("C-Box"), présent dans le cas où la détection se fait en temps réel, vise, si cela est possible, à contrer une attaque en cours.
La communication entre ces composants se fait en utilisant des objets dits (GIDOs) "Gé-néralized Intrusion Detection Objects". Ces objets sont représentés via un format standard commun défini à l’aide de CISL6 un langage appartenant à la famille Lisp. Le projet fut aban-donné en 1999 et ce modèle n’a été implanté par aucun produit. Néanmoins, ses idées on été reprises par l’ Intrusion Detection Working Group (IDWG) un groupe de travail co-dirigé par ses coordinateurs.
L’ IDMEF(Intrusion Detection Message Exchange Format) [99] : a été proposé, en 1999, par le groupe de travail de détection d’intrusion au sein de l’Internet Engineering Task Force (IETF) pour être un format standard d’interopérabilité et d’échange de rapports d’incidents entre les systèmes de détection d’intrusion, de prévention d’intrusion et de collecte d’infor-mations de sécurité et les applications qui doivent interagir avec eux. En effet, grâce à un langage commun, il devenait possible de centraliser les divers messages de détection d’intrusion provenant de multiples sondes en un seul et même module central de traitement des inci-dents(manager). Ce dernier se retrouve au cœur du fonctionnement des systèmes de détection d’intrusion hybrides tel que Prelude-IDS7 et permet d’enregistrer, corréler et/ou présenter les informations issues des sondes. IDMEF définit deux classes(types) de messages : messages d’alerte et messages Heartbeats.
— Les messages d’alertes sont générés, d’une manière asynchrone, par un analyseur lors de la détection d’un évènement présent dans sa configuration. Un message d’alerte peut être relié, selon l’analyseur, à un simple évènement, ou à plusieurs évènements détectés. — Un message Heartbeat permet à un analyseur de signaler son état au manager. La réception d’un tel message par le manager permet de vérifier que l’analyseur est bien dans un état de fonctionnement. Cependant, si à une ou plusieurs reprises (selon la configuration), le manager ne reçoit pas de tels messages, alors l’analyseur est supposé défaillant.
D’une manière évidente, il devrait être implémenté au niveau du canal entre la sonde et le moniteur auquel elle envoie les alertes, toutefois d’autres emplacements sont possibles :
— Au niveau du système de gestion de la base de données devant stocker les résultats emmenant de différents systèmes de détection d’intrusion ce qui permettrait une analyse globale de ces résultats au lieu d’une analyse séparée de chaque jeux.
— Au sein du système de corrélation d’événements devant recevoir des alertes de différents systèmes de détection d’intrusion. Ce la rendrait possible une cross-correlation plus so-phistiquée d’alertes provenant de plusieurs systèmes de détection au lieu de se contenter d’une simple corrélation limitée aux alertes produites par un seul système de détection. — Au niveau de l’interface graphique devant afficher les alertes produites par différents systèmes de détection. Un format standard d’échange de données pourra, non seulement,
6. Common Intrusion Specification Language
7. Prelude-IDS (http ://www.prelude-technologies.com), est un système de détection d’intrusion
hy-bride,Distribué sous licence GPL, conçu pour être modulaire, distribué, souple, et résistant aux attaques. Sa modularité permet notamment de lui rajouter facilement de nouveaux types de détecteurs d’intrusion, d’analy-seurs de logs et d’un mécanisme de corrélation, le tout au format et à la norme IDMEF, bien que de nombreux autres formats de logs sont compatibles.
faciliter considérablement cette tâche d’affichage, mais aussi permettra la communication d’information sur ces alertes.
En fin, il est a noter que le XML a été retenu par IDWG pour implémenter l’IDMEF vu sa popularité et sa flexibilité mais aussi pour les raisons suivantes :
— Donne la possibilité de définir un langage spécifique pour la détection d’intrusion ainsi que celle d’étendre ce langage pour des révisions ultérieures
— XML est un support substantiellement disponible, ainsi que ses outils de traitement — Disponibilité de documents et des APIs pour analyser et valider XML pour plusieurs
langages tel que Java, C/C++. L’accès répondu à ces outils rend l’adoption de l’IDMEF plus facile, rapide et beaucoup plus conviviale.
— XML projette de devenir un standard reconnu mondialement.
— XML peut supporter le filtrage et l’agrégation une fois associer à XSL — XML et libre.
1.4.6 Critères de choix d’un SDI :
Aujourd’hui les systèmes de détection d’intrusion sont réellement devenus indispensables lors de la mise en place d’une infrastructure de sécurité opérationnelle. Ils s’intègrent donc toujours dans un contexte et une architecture qui imposent des contraintes pouvant être très diverses. C’est pourquoi il n’existe pas de grille d’évaluation unique pour ce type d’outil. Pourtant un certain nombre de critères peuvent être dégagés ; ceux ci devront nécessairement être pondérés en fonction du contexte de l’étude.
1. Fiabilité : Un détecteur d’intrusion doit être fiable ; les alertes qu’il génère doivent être justifiées et aucune intrusion ne doit pouvoir lui échapper. Un système de détection d’intrusion générant trop de fausses alertes sera à coup sûr désactivé par l’administrateur et un autre ne détectant rien sera rapidement considéré comme inutile.
2. Réactivité : Un système de détection d’intrusion doit être capable de détecter les nou-veaux types d’attaques le plus rapidement possible. Pour cela il doit rester constamment à jour. Des capacités de mise à jour automatique sont pour ainsi dire indispensables. 3. Facilité de mise en œuvre et adaptabilité : Un système de détection d’intrusion
doit être facile à mettre en œuvre et doit pouvoir surtout s’adapter au contexte dans lequel il doit opérer ; il est inutile d’avoir un système de détection d’intrusion émettant des alertes tous les 10 secondes si les ressources nécessaires à une réaction ne sont pas disponible pour agir dans les mêmes contraintes de temps.
4. Performance : la mise en place d’un système de détection d’intrusion ne doit en aucun cas affecter les performance des systèmes surveillés. De plus, il faut toujours avoir la certitude que le système de détection d’intrusion a la capacité de traiter toute l’information à sa disposition (par exemple un système de détection d’intrusion réseau doit être capable de traiter l’ensemble du flux pouvant se présenter à un instant donné sans jamais dropper de paquets) car dans le cas contraire il devient trivial de masquer les attaques en augmentant la quantité d’information.
5. Multi canal : Un bon système de détection d’intrusion doit pouvoir utiliser plusieurs canaux d’alerte (email, téléphone, fax...) afin de pouvoir garantir que les alertes seront effectivement émises.
6. Information : Le système de détection d’intrusion doit donner un maximum d’infor-mation sur l’attaque détectée afin de préparer la réaction.
7. Classification : il doit être aisé de hiérarchiser la gravité des attaques détectées afin