Utilisation Des IDS

Les systmes de dtection d'intrusions
Par Jonathan Krier

Date de publication : 21 juillet 2006
Si la scurit devient aujourd'hui un domaine trs en vogue, il reste nanmoins trs vaste
et souvent complexe prendre en main. Ce document a pour but de vous aider distinguer
les diffrents types d'attaques informatiques existantes, mais il vise galement expliquer
le fonctionnement et la mise en place de diffrents systmes de dtection d'intrusions.
Ce document a t ralis dans le cadre d'un sujet d'initiation la recherche en Master
Informatique. Il regroupe de nombreuses heures de recherches, sur les diffrents types
d'attaques, les systmes de dtection d'intrusions, la mise en uvre et comparaison de
diffrents systmes, ainsi qu'une explication des diffrents algorithmes de Pattern Matching.
Les systmes de dtection d'intrusions par Jonathan Krier
I - Introduction..............................................................................................................................................................4
II - Les diffrents types d'attaques.............................................................................................................................. 4
II-A - Anatomie d'une attaque................................................................................................................................ 4
II-B - Les attaques rseau..................................................................................................................................... 5
II-B-1 - Les techniques de scan....................................................................................................................... 5
II-B-2 - IP Spoofing........................................................................................................................................... 6
II-B-3 - ARP Spoofing (ou ARP Redirect)........................................................................................................ 6
II-B-4 - DNS Spoofing.......................................................................................................................................6
II-B-5 - Fragments attacks................................................................................................................................ 7
II-B-6 - TCP Session Hijacking.........................................................................................................................7
II-C - Les attaques applicatives............................................................................................................................. 7
II-C-1 - Les problmes de configuration...........................................................................................................7
II-C-2 - Les bogues...........................................................................................................................................8
II-C-3 - Les buffer overflows............................................................................................................................. 8
II-C-4 - Les scripts............................................................................................................................................ 8
II-C-5 - Les injections SQL............................................................................................................................... 8
II-C-6 - Man in the middle................................................................................................................................ 8
II-D - Le Dni de service....................................................................................................................................... 9
II-E - Actuellement..................................................................................................................................................9
III - Dtection d'attaques : les IDS............................................................................................................................ 10
III-A - Les diffrents types d'IDS..........................................................................................................................10
III-A-1 - Les systmes de dtection d'intrusions (IDS)................................................................................... 10
III-A-2 - Les systmes de dtection d'intrusions rseau (NIDS)...............................................................10
III-A-3 - Les systmes de dtection d'intrusions de type hte (HIDS)........................................................... 10
III-A-4 - Les systmes de dtection d'intrusions hybrides ........................................................................ 11
III-A-5 - Les systmes de prvention d'intrusions (IPS)................................................................................. 11
III-A-6 - Les systmes de prvention d'intrusions kernel (KIDS/KIPS)..................................................... 12
III-A-7 - Les firewalls.......................................................................................................................................12
III-A-8 - Les technologies complmentaires................................................................................................... 12
III-B - Les mthodes de dtection....................................................................................................................... 13
III-B-1 - L'approche par scnario (misuse detection)..................................................................................... 13
III-B-2 - L'approche comportementale (Anomaly Detection).......................................................................... 14
III-B-3 - Les mthodes rpandues..................................................................................................................15
III-C - Principes gnraux et installation technique............................................................................................. 15
III-C-1 - Dploiement d'un NIDS.....................................................................................................................16
III-C-2 - Problmes techniques....................................................................................................................... 17
III-C-3 - Complmentarit des IDS................................................................................................................. 18
III-D - Normalisation............................................................................................................................................. 18
III-E - Techniques antiIDS.................................................................................................................................... 19
III-E-1 - Dtecter un IDS.................................................................................................................................19
III-E-2 - Dni de services contre un IDS........................................................................................................ 20
III-E-3 - Techniques d'insertion....................................................................................................................... 20
III-E-4 - Techniques d'vasion........................................................................................................................ 20
III-F - Critres de tests d'un IDS..........................................................................................................................22
IV - Mise en uvre d'IDS......................................................................................................................................... 22
IV-A - NIDS / NIPS : Snort................................................................................................................................... 22
IV-A-1 - Description.........................................................................................................................................22
IV-A-2 - Installation......................................................................................................................................... 23
IV-A-3 - Configuration..................................................................................................................................... 24
IV-A-4 - Excution...........................................................................................................................................24
IV-A-5 - Cration de nouvelles rgles............................................................................................................ 25
IV-A-6 - La console BASE.............................................................................................................................. 26
IV-B - NIDS : Bro..................................................................................................................................................27
IV-B-1 - Description.........................................................................................................................................27
IV-B-2 - Installation......................................................................................................................................... 27
IV-B-3 - Configuration..................................................................................................................................... 28
IV-B-4 - Excution...........................................................................................................................................28
IV-B-5 - Cration de nouvelles rgles............................................................................................................ 28
-2-
Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de
prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Jonathan Krier. Aucune reproduction,
mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation
expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.
IV-C - Comparatif Snort & Bro.............................................................................................................................29

IV-D - NIPS : SnortSam....................................................................................................................................... 30
IV-E - NIPS : Snort-Inline..................................................................................................................................... 31
IV-F - HIDS : OSSEC...........................................................................................................................................31
IV-F-1 - Description.........................................................................................................................................31
IV-F-2 - Installation..........................................................................................................................................31
IV-F-3 - Configuration..................................................................................................................................... 31
IV-F-4 - Cration de nouvelles rgles............................................................................................................ 32
IV-G - HIDS : SamHain........................................................................................................................................ 32
IV-G-1 - Description........................................................................................................................................ 32
IV-G-2 - Installation......................................................................................................................................... 32
IV-G-3 - Configuration.....................................................................................................................................33
IV-H - HIDS : RkHunter........................................................................................................................................ 34
IV-H-1 - Description........................................................................................................................................ 34
IV-H-2 - Installation......................................................................................................................................... 34
IV-I - Comparatif HIDS......................................................................................................................................... 34
IV-J - IDS Hybride : Prelude................................................................................................................................ 35
IV-K - KIDS : LIDS............................................................................................................................................... 35
V - Tests de dtection d'attaques..............................................................................................................................36
V-A - Exploit phpBB............................................................................................................................................. 36
V-B - Scan TCP SYN...........................................................................................................................................36
V-C - Scan TCP Connect.....................................................................................................................................36
V-D - Scan Null.................................................................................................................................................... 37
V-E - Remarques sur les scans...........................................................................................................................37
V-F - Exploit : Overflow HTTP d'Oracle 9i (win32).............................................................................................. 37
V-G - Remarques sur les exploits Oracle 9i........................................................................................................38
VI - Algorithmique : le Pattern Matching................................................................................................................... 38
VI-A - Introduction................................................................................................................................................ 38
VI-B - Algorithme naf (Brute Force Algorithm)....................................................................................................39
VI-C - L'algorithme de Morris - Pratt....................................................................................................................39
VI-D - L'algorithme de Knuth - Morris - Pratt.......................................................................................................41
VI-E - Algorithme de Boyer - Moore.................................................................................................................... 42
VI-F - Algorithme de Aho - Corasick................................................................................................................... 43
VI-G - Snort et le pattern matching..................................................................................................................... 44
VI-H - Conclusion................................................................................................................................................. 46
VII - Conclusion......................................................................................................................................................... 46
VIII - Bibliographie..................................................................................................................................................... 46
IX - Annexe : Rappels essentiels concernant les protocoles.................................................................................... 48
-3-
I - Introduction
Les systmes d'information sont aujourd'hui de plus en plus ouverts sur Internet. Cette ouverture, a priori bnfique,
pose nanmoins un problme majeur : il en dcoule un nombre croissant d'attaques. La mise en place d'une politique
de scurit autour de ces systmes est donc primordiale.
Outre la mise en place de pare-feu et de systmes d'authentification de plus en plus scuriss, il est ncessaire,
pour complter cette politique de scurit, d'avoir des outils de surveillance pour auditer le systme d'information et
dtecter d'ventuelles intrusions.
Ce que nous appelons intrusion signifie pntration des systmes d'information, mais aussi tentatives des utilisateurs
locaux d'accder de plus hauts privilges que ceux qui leur sont attribus, ou tentatives des administrateurs d'abuser
de leurs privilges.
Au cours de ce document, nous verrons comment se protger efficacement face ces intrusions, mais aussi les
problmes techniques dduits de ces outils, nouvellement apparus dans le monde informatique.
Mais avant cela, il est important, pour comprendre le rle prcis de ces systmes, de faire un rappel des principales
attaques existantes l'heure actuelle.
II - Les diffrents types d'attaques

L'informatique tant un domaine trs vaste, le nombre de vulnrabilits prsentes sur un systme peut donc tre
important. Ainsi, les attaques visant ces failles peuvent tre la fois trs varies et trs dangereuses. C'est pourquoi
nous allons dans un premier temps analyser ce que nous appellerons l'anatomie d'une attaque , puis dans un
second temps, nous caractriserons ces attaques et observerons leur droulement.
Un nombre important de termes techniques vont tre employs dans cette partie.
Ceux-ci ne seront pas toujours dtaills, afin de ne pas surcharger la lecture ; mais une annexe comportant un
rappel sur les notions fondamentales lies aux protocoles des rseaux (TCP, UDP et IP) est disponible la fin de
ce document.
II-A - Anatomie d'une attaque

Frquemment appels les 5 P dans la littrature, ces cinq verbes anglophones constituent le squelette de toute
attaque informatique : Probe, Penetrate, Persist, Propagate, Paralyze.
Observons le dtail de chacune de ces tapes :
Probe : consiste en la collecte d'informations par le biais d'outils comme whois, Arin, DNS lookup. La
collecte d'informations sur le systme cible peut s'effectuer de plusieurs manires, par exemple un scan
de ports grce au programme Nmap pour dterminer la version des logiciels utiliss, ou encore un scan de
vulnrabilits l'aide du programme Nessus.
Pour les serveurs web, il existe un outil nomm Nikto qui permet de rechercher les failles connues ou les problmes
de scurit.
Des outils comme firewalk, hping ou SNMP Walk permettent quant eux de dcouvrir la
nature d'un rseau ;
-4-
Penetrate : utilisation des informations rcoltes pour pntrer un rseau. Des techniques comme le brute
force ou les attaques par dictionnaires peuvent tre utilises pour outrepasser les protections par mot de
passe. Une autre possibilit pour s'infiltrer dans un systme est d'utiliser des failles applicatives que nous
verrons ci-aprs ;
Persist : cration d'un compte avec des droits de super utilisateur pour pouvoir se rinfiltrer ultrieurement.
Une autre technique consiste installer une application de contrle distance capable de rsister un reboot
(ex. : un cheval de Troie) ;
Propagate : cette tape consiste observer ce qui est accessible et disponible sur le rseau local ;
Paralyze : cette tape peut consister en plusieurs actions. Le pirate peut utiliser le serveur pour mener une
attaque sur une autre machine, dtruire des donnes ou encore endommager le systme d'exploitation dans
le but de planter le serveur.
Aprs ces cinq tapes, le pirate peut ventuellement tenter d'effacer ses traces, bien que cela ne soit rarement
utile. En effet, les administrateurs rseau sont souvent surchargs de logs analyser. De plus, il est trs difficile de
supprimer entirement des traces.
II-B - Les attaques rseau

Ce type d'attaque se base principalement sur des failles lies aux protocoles ou leur implmentation. Les RFC (1)
ne sont parfois pas assez spcifiques, et un choix particulier d'implmentation dans les diffrents services ou clients
peut entraner un problme de scurit.
Observons quelques attaques bien connues.
II-B-1 - Les techniques de scan

Les scans de ports ne sont pas des attaques proprement parler. Le but des scans est de dterminer quels sont
les ports ouverts, et donc en dduire les services qui sont excuts sur la machine cible (ex. : port 80/TCP pour un
service HTTP). Par consquent, la plupart des attaques sont prcdes par un scan de ports lors de la phase Probe
qui est comme nous l'avons vu, la premire phase des 5P's dans le droulement d'une attaque.
Il existe un nombre important de techniques de scan. Idalement, la meilleure technique de scan est celle qui est
la plus furtive afin de ne pas alerter les soupons de la future victime. Voici une description des techniques de scan
les plus rpandues :
le scan simple : aussi appel le scan connect(), il consiste tablir une connexion TCP complte sur une
suite de ports. S'il arrive se connecter, le port est ouvert ; sinon, il est ferm. Cette mthode de scan est trs
facilement dtectable ;
le scan furtif : aussi appel scan SYN, il s'agit d'une amlioration du scan simple. Ce scan essaie galement
de se connecter sur des ports donns, mais il n'tablit pas compltement la connexion : pas de commande
ACK (acquittement) aprs avoir reu l'accord de se connecter. Grce ceci, la mthode est bien plus furtive
que le scan normal ;
les scans XMAS, NULL et FIN : se basent sur des dtails de la RFC du protocole TCP pour dterminer si
un port est ferm ou non en fonction de la raction certaines requtes. Ces scans sont moins fiables que le
scan SYN, mais ils sont un peu plus furtifs. La diffrence entre ces trois types de scan se situe au niveau des
flags TCP utiliss lors de la requte ;
le scan l'aveugle : s'effectue via une machine intermdiaire et avec du spoofing (voir plus bas). Le systme
attaqu pense que le scan est ralis par la machine intermdiaire et non par le pirate ;
le scans passif : est la mthode la plus furtive. Consiste analyser les champs d'en-tte des paquets (TTL,
ToS, MSS) et les comparer avec une base de signatures qui pourra dterminer les applications qui ont
envoy ces paquets.
Remarque : l'utilitaire incontournable pour raliser des scans de ports se nomme Nmap.
-5-
II-B-2 - IP Spoofing
But : usurper l'adresse IP d'une autre machine.
Finalit : se faire passer pour une autre machine en truquant les paquets IP. Cette technique peut tre utile dans le
cas d'authentifications bases sur une adresse IP (services tels que rlogin ou ssh par exemple).
Droulement : il existe des utilitaires qui permettent de modifier les paquets IP ou de crer ses propres paquets
(ex. : hping2). Grce ces utilitaires, il est possible de spcifier une adresse IP diffrente de celle que l'on possde,
et ainsi se faire passer pour une autre machine .
Cependant, ceci pose un problme : en spcifiant une adresse IP diffrente de notre machine, nous ne recevrons pas
les rponses de la machine distante, puisque celle-ci rpondra l'adresse spoofe. Il existe toutefois deux mthodes
permettant de rcuprer les rponses :
Source routing : technique consistant placer le chemin de routage directement dans le paquet IP. Cette
technique ne fonctionne plus de nos jours, les routeurs rejetant cette option.
Reroutage : cette technique consiste envoyer des paquets RIP aux routeurs afin de modifier les tables de
routage. Les paquets avec l'adresse spoofe seront ainsi envoys aux routeurs contrls par le pirate et les
rponses pourront tre galement reues par celui-ci.
II-B-3 - ARP Spoofing (ou ARP Redirect)

But : rediriger le trafic d'une machine vers une autre.
Finalit : grce cette redirection, une personne mal intentionne peut se faire passer pour une autre. De plus, le
pirate peut rerouter les paquets qu'il reoit vers le vritable destinataire, ainsi l'utilisateur usurp ne se rendra compte
de rien. La finalit est la mme que l'IP spoofing, mais on travaille ici au niveau de la couche liaison de donnes.
Droulement : pour effectuer cette usurpation, il faut corrompre le cache ARP de la victime. Ce qui signifie qu'il faut
lui envoyer des trames ARP en lui indiquant que l'adresse IP d'une autre machine est la sienne. Les caches ARP
tant rgulirement vids, il faudra veiller maintenir l'usurpation.
II-B-4 - DNS Spoofing

But : fournir de fausses rponses aux requtes DNS, c'est--dire indiquer une fausse adresse IP pour un nom de
domaine.
Finalit : rediriger, leur insu, des internautes vers des sites pirates. Grce cette fausse redirection, l'utilisateur
peut envoyer ses identifiants en toute confiance par exemple.
Droulement : il existe deux techniques pour effectuer cette attaque :
DNS Cache Poisoning : les serveurs DNS possdent un cache permettant de garder pendant un certain
temps la correspondance entre un nom de machine et son adresse IP. Le DNS Cache Poisoning consiste
corrompre ce cache avec de fausses informations. Ces fausses informations sont envoyes lors d'une
rponse d'un serveur DNS contrl par le pirate un autre serveur DNS, lors de la demande de l'adresse
IP d'un domaine (ex. : www.ledomaine.com). Le cache du serveur ayant demand les informations est alors
corrompu ;
DNS ID Spoofing : pour communiquer avec une machine, il faut son adresse IP. On peut toutefois avoir
son nom, et grce au protocole DNS, nous pouvons obtenir son adresse IP. Lors d'une requte pour obtenir
l'adresse IP partir d'un nom, un numro d'identification est plac dans la trame afin que le client et le
serveur puissent identifier la requte. L'attaque consiste ici rcuprer ce numro d'identification (en sniffant
-6-
le rseau) lors de la communication entre un client et un serveur DNS, puis envoyer des rponses falsifies
au client avant que le serveur DNS lui rponde.
Remarque : une attaque que nous allons voir ci-aprs, le Dni de Service, peut aider ralentir le trafic du serveur
DNS et ainsi permettre de rpondre avant lui.
II-B-5 - Fragments attacks

But : le but de cette attaque est de passer outre les protections des quipements de filtrage IP.
Finalit : en passant outre les protections, un pirate peut par exemple s'infiltrer dans un rseau pour effectuer des
attaques ou rcuprer des informations confidentielles.
Droulement : deux types d'attaque sur les fragments IP peuvent tre distingus :
Fragments overlapping : quand un message est mis sur un rseau, il est fragment en plusieurs paquets
IP. Afin de pouvoir reconstruire le message, chaque paquet possde un offset. Le but de l'attaque est de
raliser une demande de connexion et de faire chevaucher des paquets en spcifiant des offsets incorrects.
La plupart des filtres analysant les paquets indpendamment, ils ne dtectent pas l'attaque. Cependant, lors
de la dfragmentation, la demande de connexion est bien valide et l'attaque a lieu ;
Tiny fragments : le but de l'attaque est de fragmenter une demande de connexion sur deux paquets IP : le
premier paquet de taille minimum (68 octets selon la RFC du protocole IP) ne contient que l'adresse et le port
de destination. Le deuxime paquet contient la demande effective de connexion TCP. Le premier paquet est
accept par les filtres puisqu'il ne contient rien de suspect. Quand le deuxime paquet arrive, certains filtres
ne le vrifient pas, pensant que si le premier paquet est inoffensif, le deuxime l'est aussi. Mais lors de la
dfragmentation sur le systme d'exploitation, la connexion s'tablit !
De nos jours, une grande majorit des firewalls (2) sont capables de dtecter et stopper ce type d'attaques.
II-B-6 - TCP Session Hijacking

But : le but de cette attaque est de rediriger un flux TCP afin de pouvoir outrepasser une protection par mot de passe.
Finalit : le contrle d'authentification s'effectuant uniquement l'ouverture de la session, un pirate russissant cette
attaque parvient prendre possession de la connexion pendant toute la dure de la session.
Droulement : dans un premier temps, le pirate doit couter le rseau, puis lorsqu'il estime que l'authentification a
pu se produire (dlai de n secondes par exemple), il dsynchronise la session entre l'utilisateur et le serveur. Pour
ce faire, il construit un paquet avec, comme adresse IP source, celle de la machine de l'utilisateur et le numro
d'acquittement TCP attendu par le serveur. En plus de dsynchroniser la connexion TCP, ce paquet permet au pirate
d'injecter une commande via la session pralablement tablie.
II-C - Les attaques applicatives

Les attaques applicatives se basent sur des failles dans les programmes utiliss, ou encore des erreurs de
configuration. Toutefois, comme prcdemment, il est possible de classifier ces attaques selon leur provenance.
II-C-1 - Les problmes de configuration

Il est trs rare que les administrateurs rseau configurent correctement un programme. En gnral, ils se contentent
d'utiliser les configurations par dfaut. Celles-ci sont souvent non scurises afin de faciliter l'exploitation du logiciel
(ex. : login/mdp par dfaut d'un serveur de base de donnes).
-7-
De plus, des erreurs peuvent apparatre lors de la configuration d'un logiciel. Une mauvaise configuration d'un serveur
peut entraner l'accs des fichiers importants, ou mettant en jeu l'intgrit du systme d'exploitation. C'est pourquoi
il est important de bien lire les documentations fournies par les dveloppeurs afin de ne pas crer de failles.
II-C-2 - Les bogues

Lis un problme dans le code source, ils peuvent amener l'exploitation de failles. Il n'est pas rare de voir
l'exploitation d'une machine bloque suite une simple erreur de programmation. On ne peut toutefois rien faire
contre ce type de problmes, si ce n'est attendre un correctif de la part du dveloppeur.
II-C-3 - Les buffer overflows

Les buffer overflows, ou dpassement de la pile, sont une catgorie de bogue particulire.
Issus d'une erreur de programmation, ils permettent l'exploitation d'un shellcode (3) distance.
Ce shellcode permettra une personne mal intentionne d'excuter des commandes sur le systme distant, pouvant
aller jusqu' sa destruction.
L'erreur de programmation est souvent la mme : la taille d'une entre n'est pas vrifie et l'entre est directement
copie dans un buffer dont la taille est infrieure la taille de l'entre. On se retrouve donc en situation de
dbordement, et l'exploitant peut ainsi accder la mmoire.
II-C-4 - Les scripts

Principalement web (ex. : Perl, PHP, ASP), ils s'excutent sur un serveur et renvoient un rsultat au client. Cependant,
lorsqu'ils sont dynamiques (i.e. qu'ils utilisent des entres saisies par un utilisateur), des failles peuvent apparatre
si les entres ne sont pas correctement contrles.
L'exemple classique est l'exploitation de fichier distance, telle que l'affichage du fichier mot de passe du systme
en remontant l'arborescence depuis le rpertoire web.
II-C-5 - Les injections SQL

Tout comme les attaques de scripts, les injections SQL profitent de paramtres d'entre non vrifis. Comme leur
nom l'indique, le but des injections SQL est d'injecter du code SQL dans une requte de base de donnes. Ainsi, il
est possible de rcuprer des informations se trouvant dans la base (exemple : des mots de passe) ou encore de
dtruire des donnes.
II-C-6 - Man in the middle

Moins connue, mais tout aussi efficace, cette attaque permet de dtourner le trafic entre deux stations. Imaginons un
client C communiquant avec un serveur S. Un pirate peut dtourner le trafic du client en faisant passer les requtes de
C vers S par sa machine P, puis transmettre les requtes de P vers S. Et inversement pour les rponses de S vers C.
Totalement transparente pour le client, la machine P joue le rle de proxy. Elle accdera ainsi toutes les
communications et pourra en obtenir les informations sans que l'utilisateur s'en rende compte.
-8-
II-D - Le Dni de service

voqu prcdemment, le dni de service est une attaque visant rendre indisponible un service. Ceci peut
s'effectuer de plusieurs manires : par le biais d'une surcharge rseau, rendant ainsi la machine totalement
injoignable ; ou bien de manire applicative en crashant l'application distance.
L'utilisation d'un buffer overflow peut permettre de planter l'application distance.
Grce quelques instructions malicieuses et suite une erreur de programmation, une personne mal intentionne
peut rendre indisponible un service (serveur web, serveur de messagerie) voire un systme complet.
Voici quelques attaques rseau connues permettant de rendre indisponible un service :
SYN Flooding : exploite la connexion en trois phases de TCP (Three Way Handshake :
SYN/SYN-ACK/ACK). Le principe est de laisser un grand nombre de connexions TCP en attente. Le pirate envoie de
nombreuses demandes de connexion (SYN), reoit les SYN-ACK, mais ne rpond jamais avec ACK. Les connexions
en cours occupent des ressources mmoire, ce qui va entraner une saturation et l'effondrement du systme ;
UDP Flooding : le trafic UDP est prioritaire sur TCP. Le but est donc d'envoyer un grand nombre de paquets
UDP, ce qui va occuper toute la bande passante et ainsi rendre indisponibles toutes les connexions TCP.
Exemple : faire une requte chargen (port 19/service de gnration de caractres) une machine en spoofant
l'adresse et le port source, pour rediriger vers echo (port 7/service qui rpte la chane de caractres reue) d'une
autre machine ;
Packet Fragment : utilise une mauvaise gestion de la dfragmentation au niveau ICMP.
Exemple : ping of death. La quantit de donnes est suprieure la taille maximum d'un paquet IP.
Remarque : pour rappel, nous avons vu que les techniques d'attaque se basant sur la fragmentation des paquets
peuvent aussi tre utilises pour outrepasser un filtre IP ;
Smurfling : le pirate fait des requtes ICMP ECHO des adresses de broadcast en spoofant l'adresse
source (en indiquant l'adresse de la machine cible). Cette machine cible va recevoir un nombre norme de
rponses, car toutes les machines vont lui rpondre, et ainsi utiliser toute sa bande passante ;
Dni de service distribu : le but est ici de reproduire une attaque normale grande chelle. Pour ce
faire, le pirate va tenter de se rendre matre d'un nombre important de machines. Grce des failles (buffer
overflows, failles RPC (4) ) il va pouvoir prendre le contrle de machines distance et ainsi pouvoir les
commander sa guise.
Une fois ceci effectu, il ne reste plus qu' donner l'ordre d'attaquer toutes les machines en mme temps, de
manire ce que l'attaque soit reproduite des milliers d'exemplaires. Ainsi, une simple attaque comme un SYN
Flooding pourra rendre une machine ou un rseau totalement inaccessible.
II-E - Actuellement
La scurit contre les attaques distantes se renforce, notamment par le biais d'quipements rseau plus puissants
(comme des firewalls plus intelligents), mais les attaques locales restent toutefois encore fort efficaces : l'ARP
Spoofing, le vol de session restent souvent possibles.
L'informatique volue, les applications sont de plus en plus complexes et les dlais laisss aux programmeurs et
administrateurs sont souvent trs (trop) courts. Les risques de failles applicatives sont, de ce fait, trs grands et
peuvent s'avrer dangereux pour des applications largement rpandues.
-9-
Les attaques distribues seront toujours redoutables si la plupart des machines personnelles ne sont pas protges.
Ce qui nous amne notre seconde partie : comment dtecter et empcher ces attaques ?
III - Dtection d'attaques : les IDS

Afin de dtecter les attaques que peut subir un systme, il est ncessaire d'avoir un logiciel spcialis dont le rle
serait de surveiller les donnes qui transitent sur ce systme, et qui serait capable de ragir si des donnes semblent
suspectes. Plus communment appels IDS (Intrusion Detection Systems), les systmes de dtection d'intrusions
conviennent parfaitement pour raliser cette tche.
l'origine, les premiers systmes de dtection d'intrusions ont t initis par l'arme amricaine, puis par des
entreprises. Plus tard, des projets open source ont t lancs et certains furent couronns de succs, par exemple
Snort et Prelude que nous dtaillerons par aprs. Parmi les solutions commerciales, on retrouve les produits des
entreprises spcialises en scurit informatique telles que Internet Security Systems, Symantec, Cisco Systems
III-A - Les diffrents types d'IDS

Comme nous l'avons vu, les attaques utilises par les pirates sont trs varies. Certaines utilisent des failles rseau
et d'autres des failles de programmation. Nous pouvons donc facilement comprendre que la dtection d'intrusions
doit se faire plusieurs niveaux.
Ainsi, il existe diffrents types d'IDS dont nous dtaillons ci-dessous les caractristiques principales.
III-A-1 - Les systmes de dtection d'intrusions (IDS)

Dfinition : ensemble de composants logiciels et matriels dont la fonction principale est de dtecter et analyser
toute tentative d'effraction (volontaire ou non).
Fonctions : dtection des techniques de sondage (balayages de ports, fingerprinting), des tentatives de
compromission de systmes, d'activits suspectes internes, des activits virales ou encore audit des fichiers de
journaux (logs).
Remarque : utopiquement, il s'agit d'un systme capable de dtecter tout type d'attaque.
Certains termes sont souvent employs quand on parle d'IDS :
Faux positif : une alerte provenant d'un IDS, mais qui ne correspond pas une attaque relle.
Faux ngatif : une intrusion relle qui n'a pas t dtecte par l'IDS
III-A-2 - Les systmes de dtection d'intrusions rseau (NIDS)

Objectif : analyser de manire passive les flux en transit sur le rseau et dtecter les intrusions en temps rel.
Un NIDS coute donc tout le trafic rseau, puis l'analyse et gnre des alertes si des paquets semblent dangereux.
Les NIDS tant les IDS plus intressants et les plus utiles du fait de l'omniprsence des rseaux dans notre vie
quotidienne, ce document se concentrera essentiellement sur ce type d'IDS.
III-A-3 - Les systmes de dtection d'intrusions de type hte (HIDS)

Un HIDS se base sur une unique machine, n'analysant cette fois plus le trafic rseau, mais l'activit se passant sur
cette machine. Il analyse en temps rel les flux relatifs une machine ainsi que les journaux.
- 10 -
Un HIDS a besoin d'un systme sain pour vrifier l'intgrit des donnes. Si le systme a t compromis par un pirate,
le HIDS ne sera plus efficace. Pour parer ces attaques, il existe des KIDS (Kernel Intrusion Detection System)
et KIPS (Kernel Intrusion PreventionSystem) qui sont fortement lis au noyau. Ces types d'IDS sont dcrits un peu
plus loin.
III-A-4 - Les systmes de dtection d'intrusions hybrides

Gnralement utiliss dans un environnement dcentralis, ils permettent de runir les informations de diverses
sondes places sur le rseau. Leur appellation hybride provient du fait qu'ils sont capables de runir aussi bien
des informations provenant d'un systme HIDS qu'un NIDS.
L'exemple le plus connu dans le monde Open-Source est Prelude. Ce framework permet de stocker dans une base de
donnes des alertes provenant de diffrents systmes relativement varis. Utilisant Snort comme NIDS, et d'autres
logiciels tels que Samhain en tant que HIDS, il permet de combiner des outils puissants tous ensemble pour permettre
une visualisation centralise des attaques.
Remarque : nous parlerons de tous ces produits plus tard dans ce document, en voquant les spcificits et
l'installation de chacun.
III-A-5 - Les systmes de prvention d'intrusions (IPS)

Dfinition : ensemble de composants logiciels et matriels dont la fonction principale est d'empcher toute activit
suspecte dtecte au sein d'un systme.
Contrairement aux IDS simples, les IPS sont des outils aux fonctions actives , qui en plus de dtecter une intrusion,
tentent de la bloquer. Cependant, les IPS ne sont pas la solution parfaite comme on pourrait le penser.
Plusieurs stratgies de prvention d'intrusions existent :
host-based memory and process protection :surveille l'excution des processus et les tue s'ils ont l'air
dangereux (buffer overflow). Cette technologie est utilise dans les KIPS (Kernel Intrusion Prevention
System) que nous dcrivons un peu plus loin ;
session interception / session sniping : termine une session TCP avec la commande TCP Reset :
RST . Ceci est utilis dans les NIPS (Network Intrusion Prevention System) ;
gateway intrusion detection : si un systme NIPS est plac en tant que routeur, il bloque le trafic ; sinon il
envoie des messages d'autres routeurs pour modifier leur liste d'accs.
Un IPS possde de nombreux inconvnients. Le premier est qu'il bloque toute activit qui lui semble suspecte. Or, il est
impossible d'assurer une fiabilit 100 % dans l'identification des attaques. Un IPS peut donc malencontreusement
bloquer du trafic inoffensif ! Par exemple, un IPS peut dtecter une tentative de dni de service alors qu'il s'agit
simplement d'une priode charge en trafic. Les faux positifs sont donc trs dangereux pour les IPS.
Le deuxime inconvnient est qu'un pirate peut utiliser sa fonctionnalit de blocage pour mettre hors service un
systme. Prenons l'exemple d'un individu mal intentionn qui attaque un systme protg par un IPS, tout en spoofant
son adresse IP. Si l'adresse IP spoofe est celle d'un nud important du rseau (routeur, service Web), les
consquences seront catastrophiques. Pour pallier ce problme, de nombreux IPS disposent des white lists ,
c'est--dire des listes d'adresses rseau qu'il ne faut en aucun cas bloquer.
Et enfin, le troisime inconvnient et non le moindre : un IPS est peu discret. En effet, chaque blocage d'attaque, il
montre sa prsence. Cela peut paratre anodin, mais si un pirate remarque la prsence d'un IPS, il tentera de trouver
une faille dans celui-ci afin de ritrer son attaque mais cette fois en passant inaperu.
- 11 -
Voil pourquoi les IDS passifs sont souvent prfrs aux IPS. Cependant, il est intressant de noter que plusieurs
IDS (ex. : Snort, RealSecure, Dragon) ont t dots d'une fonctionnalit de raction automatique certains types
d'attaques.
III-A-6 - Les systmes de prvention d'intrusions kernel (KIDS/KIPS)

Nous l'voquions prcdemment dans le cadre du HIDS, l'utilisation d'un dtecteur d'intrusions au niveau noyau peut
s'avrer parfois ncessaire pour scuriser une station.
Prenons l'exemple d'un serveur web, sur lequel il serait dangereux qu'un accs en lecture/criture dans d'autres
rpertoires que celui consultable via HTTP, soit autoris. En effet, cela pourrait nuire l'intgrit du systme. Grce
un KIPS, tout accs suspect peut tre bloqu directement par le noyau, empchant ainsi toute modification
dangereuse pour le systme.
Le KIPS peut reconnatre des motifs caractristiques du dbordement de mmoire, et peut ainsi interdire l'excution
du code. Le KIPS peut galement interdire l'OS d'excuter un appel systme qui ouvrirait un shell de commandes.
Puisqu'un KIPS analyse les appels systmes, il ralentit l'excution. C'est pourquoi ce sont des solutions rarement
utilises sur des serveurs souvent sollicits.
Exemple de KIPS : SecureIIS, qui est une surcouche du serveur IIS de Microsoft.
III-A-7 - Les firewalls

Les firewalls ne sont pas des IDS proprement parler, mais ils permettent galement de
stopper des attaques. Nous ne pouvions donc pas les ignorer.
Les firewalls sont bass sur des rgles statiques afin de contrler l'accs des flux. Ils travaillent en gnral au niveau
des couches basses du modle OSI (jusqu'au niveau 4), ce qui est insuffisant pour stopper une intrusion. Par exemple,
lors de l'exploitation d'une faille d'un serveur Web, le flux HTTP sera autoris par le firewall puisqu'il n'est pas capable
de vrifier ce que contiennent les paquets.
Il existe trois types de firewalls :
les systmes filtrage de paquets sans tat : analysent les paquets les uns aprs les autres, de manire
totalement indpendante ;
les systmes maintien d'tat (stateful) : vrifient que les paquets appartiennent une session rgulire.
Ce type de firewall possde une table d'tats o est stock un suivi de chaque connexion tablie, ce qui
permet au firewall de prendre des dcisions adaptes la situation.
Ces firewalls peuvent cependant tre outrepasss en faisant croire que les paquets appartiennent une session
dj tablie ;
les firewalls de type proxy : le firewall s'intercale dans la session et analyse l'information afin de vrifier que
les changes protocolaires sont conformes aux normes.
III-A-8 - Les technologies complmentaires

Les scanners de vulnrabilits : systmes dont la fonction est d'numrer les vulnrabilits prsentes sur un
systme. Ces programmes utilisent une base de vulnrabilits connues (exemple : Nessus).
- 12 -
Les systmes de leurre : le but est de ralentir la progression d'un attaquant, en gnrant des fausses rponses telles
que renvoyer une fausse bannire du serveur Web utilis.
Les systmes de leurre et d'tude (Honeypots) : le pirate est galement leurr, mais en plus, toutes ses actions sont
enregistres. Elles seront ensuite tudies afin de connatre les mcanismes d'intrusion utiliss par le hacker. Il sera
ainsi plus facile d'offrir des protections par la suite.
Les systmes de corrlation et de gestion des intrusions (SIM - Security Information Manager) : centralisent et
corrlent les informations de scurit provenant de plusieurs sources (IDS, firewalls, routeurs, applications). Les
alertes sont ainsi plus faciles analyser.
Les systmes distribus tolrance d'intrusion : l'information sensible est rpartie plusieurs endroits gographiques,
mais des copies de fragments sont archives sur diffrents sites pour assurer la disponibilit de l'information.
Cependant, si un pirate arrive s'introduire sur le systme, il n'aura qu'une petite partie de l'information et celle-ci
lui sera inutile.
III-B - Les mthodes de dtection

Pour bien grer un systme de dtection d'intrusions, il est important de comprendre comment celui-ci fonctionne. Une
question simple se pose alors : comment une intrusion est-elle dtecte par un tel systme ? Quel critre diffrencie
un flux contenant une attaque d'un flux normal ?
Ces questions nous ont amens tudier le fonctionnement interne d'un IDS. De l, nous en avons dduit deux
techniques mises en place dans la dtection d'attaques. La premire consiste dtecter des signatures d'attaques
connues dans les paquets circulant sur le rseau. La seconde, consiste quant elle, dtecter une activit suspecte
dans le comportement de l'utilisateur.
Ces deux techniques, aussi diffrentes soient-elles, peuvent tre combines au sein d'un mme systme afin
d'accrotre la scurit.
III-B-1 - L'approche par scnario (misuse detection)

Cette technique s'appuie sur la connaissance des techniques utilises par les attaquants pour dduire des scnarios
typiques. Elle ne tient pas compte des actions passes de l'utilisateur et utilise des signatures d'attaques (= ensemble
de caractristiques permettant d'identifier une activit intrusive : une chane alphanumrique, une taille de paquet
inhabituelle, une trame formate de manire suspecte).
Recherche de motifs (pattern matching)
La mthode la plus connue et la plus facile comprendre. Elle se base sur la recherche de motifs (chanes de
caractres ou suite d'octets) au sein du flux de donnes. L'IDS comporte une base de signatures o chaque signature
contient les protocole et port utiliss par l'attaque ainsi que le motif qui permettra de reconnatre les paquets suspects.
Le principal inconvnient de cette mthode est que seules les attaques reconnues par les signatures seront dtectes.
Il est donc ncessaire de mettre jour rgulirement la base de signatures.
Un autre inconvnient est que les motifs sont en gnral fixes. Or une attaque n'est pas toujours identique 100 %.
Le moindre octet diffrent par rapport la signature provoquera la non-dtection de l'attaque.
Pour les IDS utilisant cette mthode, il est ncessaire d'adapter la base de signatures en fonction du systme
protger. Cela permet non seulement de diminuer les ressources ncessaires et donc augmenter les performances ;
mais galement rduire considrablement le nombre de fausses alertes et donc faciliter le travail des administrateurs
rseau qui analyseront les fichiers d'alertes.
- 13 -
Cette technique est galement utilise dans les antivirus.

Recherche de motifs dynamiques
Le principe de cette mthode est le mme que prcdemment, mais les signatures des attaques voluent
dynamiquement. L'IDS est de ce fait dot de fonctionnalits d'adaptation et d'apprentissage.
Analyse de protocoles
Cette mthode se base sur une vrification de la conformit (par rapport aux RFC) des flux, ainsi que sur l'observation
des champs et paramtres suspects dans les paquets. Cependant, les diteurs de logiciels et les constructeurs
respectent rarement la lettre les RFC et cette mthode n'est pas toujours trs performante.
L'analyse protocolaire est souvent implmente par un ensemble de prprocesseurs, o chaque prprocesseur est
charg d'analyser un protocole particulier (FTP, HTTP, ICMP). Du fait de la prsence de tous ces prprocesseurs,
les performances dans un tel systme s'en voient fortement dgrades.
L'intrt fort de l'analyse protocolaire est qu'elle permet de dtecter des attaques inconnues, contrairement au pattern
matching qui doit connatre l'attaque pour pouvoir la dtecter.
Analyse heuristique et dtection d'anomalies
Le but de cette mthode est, par une analyse intelligente, de dtecter une activit suspecte ou
toute autre anomalie.
Par exemple : une analyse heuristique permet de gnrer une alarme quand le nombre de sessions destination
d'un port donn dpasse un seuil dans un intervalle de temps prdfini.
III-B-2 - L'approche comportementale (Anomaly Detection)

Cette technique consiste dtecter une intrusion en fonction du comportement pass de l'utilisateur. Pour cela, il faut
pralablement dresser un profil utilisateur partir de ses habitudes et dclencher une alerte lorsque des vnements
hors profil se produisent.
Cette technique peut tre applique non seulement des utilisateurs, mais aussi des applications et services.
Plusieurs mtriques sont possibles : la charge CPU, le volume de donnes changes, le temps de connexion sur
des ressources, la rpartition statistique des protocoles et applications utiliss, les heures de connexion
Cependant elle possde quelques inconvnients :
peu fiable : tout changement dans les habitudes de l'utilisateur provoque une alerte ;
ncessite une priode de non-fonctionnement pour mettre en uvre les mcanismes
d'autoapprentissage : si un pirate attaque pendant ce moment, ses actions seront assimiles un profil
utilisateur, et donc passeront inaperues lorsque le systme de dtection sera compltement mis en place ;
l'tablissement du profil doit tre souple afin qu'il n'y ait pas trop de fausses alertes : le pirate peut
discrtement intervenir pour modifier le profil de l'utilisateur afin d'obtenir aprs plusieurs jours ou semaines,
un profil qui lui permettra de mettre en place son attaque sans qu'elle ne soit dtecte.
Plusieurs approches peuvent tre utilises pour la mthode de dtection comportementale :

Approche probabiliste
- 14 -
Des probabilits sont tablies permettant de reprsenter une utilisation courante d'une application ou d'un protocole.
Toute activit ne respectant pas le modle probabiliste provoquera la gnration d'une alerte.
Exemple : Avec le protocole HTTP, il y a une probabilit de 0.9 qu'une commande GET soit faite aprs une connexion
sur le port 80. Il y a ensuite une probabilit de 0.8 que la rponse cette commande GET soit HTTP/1.1 200 OK .
Approche statistique
Le but est de quantifier les paramtres lis l'utilisateur : taux d'occupation de la mmoire, utilisation des processeurs,
valeur de la charge rseau, nombre d'accs l'Intranet par jour, vitesse de frappe au clavier, sites les plus visits
Cette mthode est trs difficile mettre en place. Elle n'est actuellement prsente que dans le domaine de la
recherche, o les chercheurs utilisent des rseaux neuronaux et le data mining pour tenter d'avoir des rsultats
convaincants.
Autres mthodes
D'autres mthodes existent, mais ne sont pas encore rpandues. Parmi celles-ci, nous pouvons noter :
l'utilisation de l'immunologie, c'est--dire construire un modle de comportement normal des services ;

la prsentation d'une activit habituelle sous forme de graphe.
III-B-3 - Les mthodes rpandues

En gnral, les IDS mlangent les diffrentes techniques de dtection par scnario en proposant du pattern matching,
de l'analyse protocolaire et de la dtection d'anomalies.
De nombreuses techniques et algorithmes sont utiliss dans la dtection d'intrusions :
Pattern Matching
algorithmes de recherche de motifs (ex. : Boyer-Moore),
algorithmes de comptage,
algorithmes gntiques ;
Analyse Protocolaire
conformit aux RFC ;
Dtection d'anomalies
mthodes heuristiques ;
Analyse statistique
modles statistiques ;
Analyse probabiliste
rseaux baysiens ;
Autres analyses comportementales
rseaux de neurones, systmes experts + data mining, immunologie, graphes
Il est bien sr impossible de dtailler chacun des algorithmes mis en uvre dans les IDS.
Nous avons cependant ddi le chapitre 6 aux algorithmes de pattern matching.
III-C - Principes gnraux et installation technique

Jusqu' prsent, nous avons vu les types d'IDS existants et les mthodes de dtection qu'ils utilisent. Nous allons
maintenant dtailler une tape importante dans la mise en place d'un IDS : l'installation technique.
- 15 -
Lors de la mise en place d'un systme de dtection d'intrusions au sein d'un rseau, il est important de le
dployer correctement d'une part, mais aussi de comprendre son fonctionnement interne pour pouvoir le configurer
efficacement. Toute erreur lors de l'installation d'un IDS pourra le rendre inefficace ou inutilisable.
III-C-1 - Dploiement d'un NIDS

Il faut tout d'abord prendre conscience qu'un NIDS n'est pas suffisant pour assurer la scurit. En plus d'installer un
NIDS, il ne faudra pas oublier les actions habituelles :
les systmes et les applications doivent tre mises jour rgulirement (patches de scurit) ;
les systmes utilisant Internet doivent tre dans un rseau isol (DMZ (5) ) ;
chaque utilisateur doit tre averti de l'importance de la scurit de ses mots de passe ;
les fonctionnalits des services qui ne sont pas utilises doivent tre dsactives.
Lors du dploiement d'un IDS, il faut le configurer correctement : par exemple, si le rseau est sous Windows,
les rgles destines Unix ne sont pas ncessaires. Il faut donc faire une configuration en fonction de l'OS, des
applications et du matriel utiliss.
L'emplacement du senseur (6) est trs important :
l'emplacement B, seul le trafic entre les systmes de la DMZ et Internet est analys. Le trafic entre le
rseau interne et Internet n'est pas analys. Pour cela, il faudra galement placer un senseur au point A.
l'emplacement C, le trafic entre Internet et le rseau interne ou la DMZ est analys. Par contre, le trafic
entre le rseau interne et la DMZ est invisible.
Il est impensable de vouloir analyser tout le trafic d'un rseau. Il faut donc donner la priorit aux systmes risque :
ceux qui offrent des services accessibles par Internet (HTTP, FTP).
De plus, il est souvent prfrable de placer le senseur aprs le firewall du ct interne. Ainsi, seuls les flux accepts
par le firewall sont analyss, ce qui rduit fortement la charge de la sonde IDS.
Lors de l'installation d'un NIDS, le choix matriel a galement une grande importance.
Puisqu'une sonde NIDS doit tre capable d'analyser le trafic rseau quel que soit le destinataire, elle devra recevoir
elle-mme tous les paquets. Pour cela, le NIDS devra jouer le rle d'un sniffer (7) , mais le matriel rseau pose
parfois problme :
un switch simple (commutateur) : en utilisant un tel quipement, la conversation avec l'IDS est impossible du
fait de la nature d'un switch : il commute les paquets directement au destinataire. Il est ds lors impossible
d'installer une sonde qui analysera le trafic global ;
un hub (concentrateur) => la conversation avec l'IDS est possible, car les hubs rptent les paquets en les
mettant toutes les machines connectes. Cependant, les hubs sont peu fiables et sont donc viter ;
il existe des switches professionnels qui copient le trafic et l'envoie sur un port spcifi (o sera plac le
NIDS) : SPAN port (Switch Port Analyzer). Attention : pour ce port, il faudra utiliser une connexion rapide
(ex. : Gigabits) capable d'analyser entirement le trafic provenant ou destination des diffrents sous
rseaux.
Un autre problme doit tre pris en considration : lorsque les flux sont crypts (ex. : par SSL, c'est le cas pour les
VPN (8) ), il est impossible pour l'IDS de dcrypter ces flux. Il faut dans ce cas utiliser un proxy SSL comme illustr
ci-dessous.
- 16 -
Nous savons donc maintenant que l'emplacement des sondes et le matriel rseau utiliss sont trs importants.
Cependant, un autre point ne doit pas tre oubli : la scurisation du senseur et des logs d'alerte. En effet, si la
sonde elle-mme ou si les alertes qu'elles gnrent ne sont pas scurises, un pirate pourrait trs bien rendre l'IDS
compltement inefficace.
Pour scuriser les sondes et les fichiers d'alertes, il est par exemple possible de mettre en place un rseau de
management trs contrl, avec son propre firewall. Ce systme sera primordial pour la scurit du rseau et
plusieurs mesures devront tre prises pour assurer son fonctionnement :
le systme d'exploitation du senseur devra tenu jour ;

un systme d'authentification robuste (ex. : PKI) pourra tre mis en place pour renforcer la scurit ;
tous les mots de passe devront tre changs rgulirement ;
il est galement possible d'utiliser deux interfaces rseaux pour le senseur : la premire pour gnrer les
alertes et contrler le trafic, et la deuxime, compltement invisible, en tant que point de monitoring. Ce genre
d'interface est communment appele stealth interface.
III-C-2 - Problmes techniques

Le premier problme est de configurer correctement l'IDS afin qu'il n'inonde pas les rapports d'alertes avec des faux
positifs. La prsence de faux positifs semble inoffensive. Or, s'ils sont trop nombreux, les rapports d'alertes seront
longs analyser. Par consquent, les administrateurs passeront beaucoup de temps distinguer un faux positif
d'une vritable intrusion. Et de plus, en voyant toutes ces fausses alertes, ils auront tendance minimiser le risque
d'attaque.
Bien sr, il faut galement veiller ce que l'affinement de la configuration ne gnre pas des faux ngatifs, car toute
intrusion non dtecte peut avoir des consquences dramatiques.
Le deuxime problme provient des dbits actuels sur les rseaux : ces dbits augmentent de plus en plus, et les
IDS ont de plus en plus de paquets traiter et analyser.
En plus d'avoir un quipement rseau performant, l'IDS doit utiliser des algorithmes adapts et
optimiss.
Afin de bien comprendre comment amliorer les performances d'un NIDS, il faut comprendre les diffrentes tapes.
Chaque paquet de donnes trait par l'IDS va subir une suite de traitements :
capture de la trame par l'interface en mode promiscuit (promiscous mode) ;

analyse de la trame et filtrage ventuel en bas niveau ;
dtection de la prsence de fragments ou non et passage ventuel un moteur de reconstruction ;
transfert de la trame vers le systme d'exploitation ;
filtrage ventuel ;
applications de divers prprocesseurs en fonction du type de requte afin de contrer des techniques
d'vasion d'attaques (voir plus loin) ;
passage vers le moteur d'analyse (protocole, pattern matching, statistique).
Pour amliorer les performances de l'IDS, il peut donc tre judicieux de rpartir les charges. Par exemple, il est
envisageable de sparer les flux analyser en fonction du protocole de niveau 4 : une sonde pour l'analyse des flux
Web, une autre pour l'analyse des flux FTP et une analyse des requtes SQL.
Un autre problme est la corrlation des informations provenant de plusieurs types de
sondes. Voici les actions raliser pour regrouper ces informations :
agrgation : rassembler les informations des diffrentes sondes ;

- 17 -
fusion : fusionner en supprimant les doublons (mme attaque dtecte par plusieurs sondes) ;
corrlation : dfinir un motif commun, c'est--dire interprter une suite d'vnements et les rsumer.
Une corrlation intressante serait de ne garder que les alertes qui concernent une faille probable du systme. Pour
cela il faut utiliser un scanner de vulnrabilits par exemple, ou ne pas afficher les alertes concernant IIS si on possde
Apache, ce qui entranera moins de faux positifs.
Nanmoins, l'utilisation d'un scanner de vulnrabilits n'est pas parfaite, car il est difficile d'changer des informations
entre un scanner de vulnrabilits et un IDS. Cependant, depuis peu, des consoles de corrlation entre IDS et
scanners de vulnrabilits sont proposes (ex. : Nevo de Tenable Network Security).
Enfin, un dernier problme est qu'il n'y a aucune interoprabilit entre les diffrents IDS
du march, mis part la possibilit d'exporter les informations dans des formats standard.
Pourtant, des normes ont t tablies, comme nous allons le voir.
III-C-3 - Complmentarit des IDS

Nous avons vu qu'il existe plusieurs types d'IDS, dont leur rle est compltement diffrent. Plus exactement, leurs
rles sont complmentaires. En effet, un NIDS ne fera qu'analyser le trafic rseau. Mais complt par un HIDS, des
intrusions non dtectes sur le rseau pourront l'tre lorsqu'elles atteindront la machine cible.
En gnral, un seul NIDS par rseau est suffisant. Mais il est possible de placer des sondes diffrents endroits
du rseau afin de rpartir la charge.
L'idal pour les HIDS serait d'en dployer sur toutes les machines du parc informatique, mais cela n'est rarement fait
pour des raisons de cot et d'exploitation. Un compromis souvent choisi est d'installer des agents HIDS sur toutes
les machines de la DMZ, ainsi que sur les serveurs importants.
Les KIDS/KIPS ralentissant normment l'excution des programmes, ils sont souvent dlaisss ou configurs de
faon n'utiliser que les fonctionnalits de base. Pourtant, ils sont les seuls pouvoir dtecter de manire efficace
les tentatives de buffer overflows. Ils sont donc trs conseills sur les machines sensibles.
III-D - Normalisation
Il y a quelques annes, un comit du DARPA a dfini quatre briques fonctionnelles pour dcrire
l'architecture globale d'un IDS :
gnrateur d'vnements (bote E) : envoie des vnements la bote A ;

analyseur d'vnements (bote A) : produit des alertes ;
base de donnes vnementielle (bote D) ;
systme de rponse (bote R) : rponse en temps rel face aux attaques.
Ce comit a aussi dfini un langage de description des intrusions (CISL - Common Intrusion Specification Language)
qui utilise des expressions verbales (ex. : ouvrir session , effacer objet ). Cependant, ce langage n'a jamais
t utilis, mais il a inspir d'autres comits.
L'IDWG (Intrusion Detection Working Group) a effectu la plupart des travaux dans le domaine de la standardisation
des IDS :
norme IDMEF (Intrusion Detection Message Exchange Format) : dfinit le format des messages changs dans un
IDS ;
- 18 -
protocole IDXP (Intrusion Detection eXchange Protocol) : procdures de transport entre les entits de l'IDS.
Selon l'IDWG, un IDS est ensemble de plusieurs senseurs, analyseurs et managers :
C'est un schma thorique, rarement implment de cette faon dans les IDS. La norme IDMEF prconise une
reprsentation en XML des messages o dans chaque message, on retrouve l'ID de l'analyseur, le type d'alerte,
l'emplacement (le nud rseau), le jour et l'heure, l'adresse, la classification de l'attaque
III-E - Techniques antiIDS

Comme tout systme informatique, ou presque, il existe des failles dans les IDS, ou plutt des techniques qui
permettent d'outrepasser ces systmes sans se faire reprer. Si un pirate dtecte la prsence d'un IDS, il peut le
dsactiver, ou mieux encore, gnrer de fausses attaques pendant qu'il commettra son forfait tranquillement.
Il existe trois catgories d'attaques contre les IDS :
attaque par dni de service : rendre l'IDS inoprant en le saturant ;

attaque par insertion : le pirate, pour viter d'tre repr, injecte des paquets de leurres qui seront ignors par
le systme d'exploitation de la cible, mais pris en compte par l'IDS : l'IDS ne dtecte rien d'anormal, alors que
sur le systme cible, l'attaque a bien lieu puisque les paquets superflus sont ignors ;
attaque par vasion : il s'agit de la technique inverse l'attaque par insertion. Ici, des donnes superflues
sont ignores par l'IDS, mais prises en compte par le systme d'exploitation. Nous dtaillons un peu plus loin
quelques techniques d'vasion Web.
III-E-1 - Dtecter un IDS

Comme nous l'avons dj signal, il est trs dangereux que la prsence d'un IDS soit remarque par un pirate. Car
dans ce cas, il tentera d'obtenir un maximum d'informations sur l'IDS install (ex. : la version utilise) pour pouvoir
l'outrepasser et attaquer sans se faire remarquer. Voici quelques techniques qui permettent de dtecter un IDS :
usurpation d'adresse MAC : les NIDS mettent l'interface de capture en mode promiscuit (promiscuous mode), il
est donc possible de dtecter l'IDS en envoyant par exemple un ICMP echo request la machine souponne
d'tre un NIDS avec une adresses MAC inexistante.
Si la machine rpond alors elle est en mode promiscuous et peut donc tre un NIDS ;
mesure des temps de latence : puisque l'interface est en mode promiscuous, les temps de
rponse sont plus longs. Voici une mthode pour exploiter ces temps de latence :
le pirate gnre une srie de pings vers l'adresse tester, puis il mesure et note les temps de rponse ;
le pirate sature ensuite le rseau en broadcast (9) dans le but de ralentir l'IDS, qui recevra tous les paquets.
Enfin, le pirate rmet la mme srie de pings en mesurant les nouveaux temps de rponse. S'ils sont bien
plus levs que les premiers temps obtenus, il est fort possible que la machine soit en mode promiscous ;
exploiter les mcanismes de rponses actives : les IPS ragissent certaines attaques (fermer session, bloquer
port), mais en faisant cela, ils laissent souvent des empreintes (header des paquets) permettant d'identifier le type
d'IPS ;
observation des requtes DNS : Les IDS gnrent souvent des requtes DNS lors des alertes.
En observant le DNS primaire lors de fausses attaques, on peut dtecter qu'il y a un IDS.
- 19 -
III-E-2 - Dni de services contre un IDS

Le but est de dsactiver l'IDS en saturant ses ressources (ex. : SYN Flood ou paquets fragments incomplets). L'IDS
sera ds lors incapable d'excuter sa fonctionnalit de dtection, et le pirate pourra raliser son attaque.
III-E-3 - Techniques d'insertion

Comme nous l'avons vu, ces techniques consistent injecter des donnes supplmentaires de telle sorte que :
l'IDS les estime inoffensives ;

la cible ne les dcode pas ;
Voici quelques mthodes permettant d'utiliser des techniques d'insertion :

- en utilisant la fragmentation IP qui est gre de manire diffrente selon l'OS lors de cas anormaux (ex. :
recouvrement de paquets) : soit les fragments anciens sont favoriss, soit les nouveaux le sont. Par exemple, il
est donc possible que les IDS favorisent les anciens paquets alors que le systme d'exploitation utilis favorise les
nouveaux.
Pour utiliser le recouvrement de fragments (fragmentation overlap), il faut modifier artificiellement les champs
longueur et dcalage (offset) des fragments IP ;
- en utilisant l'crasement de fragments (fragmentation overwrite) : mme principe que prcdemment, mais des
fragments entiers sont remplacs, et non seulement des parties de paquets ;
- en utilisant le timeout de fragmentation : les systmes conservent en gnral les fragments pendant 60 secondes
pour le rassemblage ; mais les IDS les gardent souvent moins longtemps. On peut donc espacer les fragments dans
le temps pour ne pas se faire reprer par l'IDS tout en ralisant une attaque complte sur le systme d'exploitation ;
- dcoupage de sessions TCP (session splicing) : la requte TCP est divise en paquets, tout en modifiant le numro
de squence pour crer des recouvrements : mme principe qu'avec la fragmentation IP + possibilit de timeout
(Apache Linux : 5 min dans tampon, IIS : 10 min). L'un des outils pour raliser ce genre d'attaques se nomme
fragroute ;
- insrer un faux paquet avec checksum erron : certains IDS ne verront pas l'attaque, car peu d'IDS vrifient le
checksum. Le systme, par contre, rejettera le paquet erron.
Attention : de nos jours, les routeurs rejettent souvent les paquets errons ; il faut donc utiliser un autre champ que
le checksum, par exemple le TTL.
III-E-4 - Techniques d'vasion

Nous prsentons maintenant quelques techniques d'vasion. Pour rappel, ces techniques ont pour but d'insrer des
donnes qui seront ignores par l'IDS, mais qui ne gneront nullement l'attaque.
Evasions HTTP : le principe est de modifier la syntaxe des URL, mais sans changer la smantique. La premire
personne avoir prsent ce genre d'attaques avait pour pseudonyme Rain Forrest Puppy qui est l'auteur du trs
clbre outil Whisker, un scanner de vulnrabilits Web.
Voici quelques exemples d'vasion HTTP qui permettaient une poque d'outrepasser les signatures de nombreux
NIDS, tout en mettant des requtes HTTP valides. Bien sr, les NIDS prennent maintenant en compte ces
techniques.
- 20 -
=> faire une requte HEAD au lieu de GET.

=> encoder les URL en hexadcimal, cette forme d'encodage tant tout fait valide selon la RFC du protocole HTTP.
exemple : www%2Emonsite%2Ecom%2Fcgi%2Fscript
=> utiliser des doubles slashes au lieu de slashes simples
exemple : www.monsite.com//cgi//script
=> traverser des rpertoires fantmes
exemple : www.monsite.com/repFantome/../cgi/script
=> utiliser des autorfrences
exemple : www.monsite.com/cgi/./././script
=> simuler la fin d'une requte prmature avec le caractre de fin de chane %00 ou bien avec les caractres de
fin de requte HTTP : %0D%0A
=> utiliser des URL longues : certains IDS n'analysaient qu'une partie de l'URL
=> utiliser la syntaxe MS DOS / Windows : remplacer les caractres / par \
exemple : www.monsite.com\cgi\script
=> dcouper la requte HTTP sur plusieurs paquets
=> remplacer les espaces par des tabulations
Shellcodes polymorphiques : parmi les attaques dcrites prcdemment, nous avons vu les tentatives de buffer
overflow. Celles-ci peuvent tre dcomposes en trois grandes parties :
- des instructions pour remplir le buffer. Assez souvent, ce sont des instructions assembleurs NOP, dont le code est
0x90 sur architecture IA32.
- le shellcode, c'est--dire le code qui sera excut sur la machine et qui permettra de donner accs un shell de
commandes.
- une adresse de retour de procdure (qui pointe souvent vers les NOP) qui permettra lors du dpassement de buffer
d'excuter le shellcode.
De nombreux IDS sont capables de dtecter les tentatives de buffer overflow. La premire mthode est de surveiller
la prsence importante d'instructions NOP. La deuxime est de dtecter la chane bin/sh qui est souvent prsente
dans les shellcodes pour Unix. La troisime mthode est d'avoir des signatures compltes de shellcodes rpandus
sur Internet.
Cependant, il est facilement possible de camoufler une tentative de buffer overflow.
Voici quelques techniques simples, mais efficaces :
- mettre une autre instruction que des NOP pour remplir le buffer (ex. : DAA, AAA, XOR, INC) ;
- 21 -
- crire les instructions par des quivalences, comme par exemple rcrire une instruction MOV EAX, 0 par XOR
EAX,EAX ou bien encore SUB EAX, EAX qui auront toutes les trois pour effet de mettre le registre EAX 0 ;
- raliser un cryptage (XOR) du shellcode et ainsi le rendre polymorphique. Dans ce cas, le dcodeur et la cl doivent
tre prsents dans le shellcode pour pouvoir le dcrypter lors de son excution chez la victime.
Nous pouvons remarquer qu'il devient trs difficile pour un IDS de dtecter un shellcode en utilisant des signatures.
Le seul moyen efficace est de dtecter le buffer overflow lors de son excution et l'empcher au dernier moment de
lancer un shellcode. Pour cela, seuls les KIPS (Kernel Intrusion Prevention System) se montrent adapts puisqu'ils
surveillent les appels systmes.
III-F - Critres de tests d'un IDS

Lors de la mise en place d'un IDS, il est ncessaire de prendre en considration plusieurs critres qui permettront
de choisir au mieux l'IDS.
Tester un IDS avec des scanners de vulnrabilit est une mesure ncessaire pour valuer un IDS, mais est loin d'tre
suffisante. D'autres critres doivent tre pris en compte :
Mthodes et capacits de dtection : estimer le taux de faux positifs et la qualit d'information fournie par
l'IDS ;
Rapidit : tester l'IDS en condition de charge leve. Il est important de tester cela de manire raliste, et
non pas en utilisant des gnrateurs de paquets ;
Ouverture : il faut que l'IDS permette de modifier les signatures afin d'viter certains faux positifs, mais aussi
d'ajouter de nouvelles signatures spcifiques l'environnement ;
Rsistance aux techniques d'vasion : utiliser des outils tels que Whisker, Nikto, Babelweb, Fragroute ou
Mendax pour observer le comportement de l'IDS ;
Architecture logicielle : pour les grandes entreprises, il est intressant de pouvoir sparer les fonctions
d'administration ;
Exploitabilit des donnes : il faut disposer d'outils permettant de retrouver et analyser facilement les
vnements suspects, car le volume gnr par les IDS est important. Afin de centraliser les donnes, il peut
tre intressant de disposer de consoles de reporting ou de tableaux de bord.
Ergonomie : on retrouve diffrents types d'interfaces dans les IDS. Tout d'abord, les interfaces graphiques
qui sont adaptes aux particuliers ou aux PME. Ensuite, les interfaces de type Web ou encore les interfaces
en ligne de commandes rserves aux spcialistes. Dans tous les cas, l'interface doit offrir de nombreuses
fonctionnalits.
D'autres critres, comme la ractivit de l'diteur (mises jour des signatures, correctifs), ou le prix (solution libre
ou non) rentrent en jeu. Pour valuer un IDS, il est intressant de pondrer chacun de ces critres selon l'importance
qu'on leur attribue, et donner une note l'IDS pour chaque critre.
IV - Mise en uvre d'IDS

Maintenant que nous connaissons le but, le fonctionnement, mais aussi les faiblesses des IDS, nous pouvons
dcouvrir plusieurs solutions logicielles existantes.
IV-A - NIDS / NIPS : Snort

IV-A-1 - Description
Snort est un NIDS/NIPS provenant du monde Open Source. Avec plus de 2 millions de tlchargements, il s'est
impos comme le systme de dtection d'intrusions le plus utilis. Sa version commerciale, plus complte en fonctions
de monitoring, lui a donn bonne rputation auprs des entreprises.
- 22 -
Snort est capable d'effectuer une analyse du trafic rseau en temps rel et est dot de diffrentes technologies
de dtection d'intrusions telles que l'analyse protocolaire et le pattern matching. Snort peut dtecter de nombreux
types d'attaques : buffer overflows, scans de ports furtifs, attaques CGI, sondes SMB, tentatives de fingerprinting
de systme d'exploitation
Snort est dot d'un langage de rgles permettant de dcrire le trafic qui doit tre accept ou collect. De plus, son
moteur de dtection utilise une architecture modulaire de plugins.
Notons que Snort dispose de trois modes de fonctionnement : sniffer de paquets, logger de paquets et systme de
dtection/prvention d'intrusions. Nous ne nous intresserons qu' ce dernier mode.
IV-A-2 - Installation
1. Tlcharger les sources sur www.snort.org. Lors de l'criture de ce document, la dernire version stable tait la
2.4.4.
2. Tlcharger et installer les bibliothques ncessaires pour Snort :
libpcap (http://www.tcpdump.org) : offre des fonctions de sniffer

PCRE (http://www.pcre.org) : permet d'utiliser des expressions rgulires de type Perl
La compilation de ces bibliothques se fait trs aisment : ./configure, make, make install.
3. Ouvrir un terminal, dcompresser ensuite l'archive de Snort et se placer dans le rpertoire des sources
dcompresses.
4. Configurer la compilation de Snort afin d'activer plusieurs fonctionnalits : ./configure [options].
Deux options nous ont sembl intressantes :
--with-mysql=DIR : activer le support de MySQL. Ainsi Snort enregistrera les alertes dans une base de
donnes accessible par d'autres applications (ex. : BASE, dcrite plus loin). MySQL n'est bien sr pas
l'unique SGBD support.
PostgreSQL ou Oracle peuvent galement tre utiliss avec les options -withpostgresql et --with-oracle.
--enable-flexresp : activer les rponses flexibles en cas de tentatives de connexion hostile. Pour activer cette
option, la bibliothque libnet (http://www.packetfactory.net/libnet) est ncessaire.
5. Compiler les sources : make.

6. Installer Snort : make install en mode root.
7. Pour que Snort puisse fonctionner en mode dtection/prvention d'intrusions, il est ncessaire de lui fournir des
fichiers de rgles. Le site de Snort propose deux types de rgles : les rgles officielles et les rgles cres par la
communaut. Certaines rgles officielles ne sont disponibles que pour les utilisateurs enregistrs, tandis que les
rgles communautaires sont disponibles tous et mises jour rgulirement. Il est cependant important de noter
que les rgles proposes par la communaut n'ont pas t forcment testes par l'quipe officielle de Snort.
Aprs tlchargement, l'archive des rgles doit tre dcompresse. Il est conseill de placer le rpertoire rules dans
le dossier de Snort. Nous pouvons remarquer que les rgles consistent en de simples fichiers textes, et qu'un fichier
un peu spcial est prsent : snort.conf. Ce dernier va nous permettre de configurer Snort.
- 23 -
IV-A-3 - Configuration
Afin de configurer correctement Snort pour qu'il puisse fonctionner en mode dtection d'intrusions, il faut modifier le
fichier snort.conf. L'emplacement par dfaut de ce fichier doit normalement tre /etc/snort.conf. Cependant, il sera
possible de spcifier un autre emplacement lors de l'excution de Snort, l'aide de l'option -c.
Le fichier de configuration contient de nombreuses options paramtrables, ainsi que des explications pour pouvoir
les modifier correctement. Nous n'allons nous intresser ici qu' quelques variables :
la variable HOME_NET permet de spcifier quels rseaux ou quelles interfaces seront surveills par Snort.
La valeur any signale Snort de surveiller tout le trafic ;
si le rseau surveiller possde des serveurs DNS, SMTP, FTP, etc., il est possible de spcifier les adresses
IP de ces serveurs via les variables DNS_SERVERS, SMTP_SERVERS Si le rseau ne possde pas
un type spcifique de serveur, il est conseill de commenter (avec le caractre #) la ligne concerne, afin
d'optimiser le traitement de Snort. En effet, il est inutile d'analyser du trafic HTTP si aucun serveur Web n'est
disponible ;
certains ports de services peuvent tre configurs via des variables telles que HTTP_PORTS ou
ORACLE_PORTS.
la variable RULE_PATH est trs importante. Elle permet de spcifier le rpertoire o sont stocks les fichiers
de rgles de Snort.
les directives include permettent d'inclure des fichiers de rgles. Ici encore, il est conseill de n'inclure que les
rgles ncessaires en fonction des services disponibles sur le rseau.
IV-A-4 - Excution
L'excution de Snort se fait en lanant l'excutable snort en mode root et avec diffrentes options. Voyons les
principaux arguments de Snort :
-A : gnrer des alertes. Activ par dfaut avec l'option -c

-c <emplacement de snort.conf> : lancer Snort avec des fichiers de rgles.
-l <rpertoire de log> : spcifier le rpertoire o les logs d'alertes seront stocks (dfaut : /var/log/snort)
-v : mode verbose. Permet d'afficher les paquets capturs
-T : mode test. Permet de tester la configuration de Snort
Avant de lancer Snort en mode NIDS, il est prfrable de tester si le programme arrive rcuprer les paquets qui
circulent sur le rseau. Pour cela, nous pouvons par exemple lancer Snort en simple mode Sniffer : snort -v. Si aucun
paquet n'est captur et affich, il est probable que Snort n'coute pas sur la bonne interface. L'option -i permet de
spcifier une autre interface.
Lanons maintenant Snort en mode NIDS. Pour cela, nous lui prcisons l'emplacement du fichier de configuration
avec l'option -c : snort -c /opt/snort/rules/snort.conf
Toutes les alertes dtectes sont ainsi stockes dans le fichier /var/log/snort/alert. Pour chaque alerte, Snort donne
une priorit, une description, les flags des paquets et ventuellement des adresses sur Internet o se trouvent de
plus amples informations sur la tentative d'intrusion.
Exemple :
[**] [1:1384:8] MISC UPnP malformed advertisement [**]
[Classification: Misc Attack] [Priority: 2]
03/25-17:34:49.251861 192.168.0.1:1900 ->
239.255.255.250:1900
UDP TTL:1 TOS:0x0 ID:37277 IpLen:20 DgmLen:437
Len: 409
[Xref =>
http://www.microsoft.com/technet/security/bulletin/MS01059.mspx][Xref => http://cve.mitre.org/cgibin/
- 24 -
cvename.cgi?name=2001-0877][Xref =>
http://cve.mitre.org/cgi-bin/cvename.cgi?name=20010876][Xref => http://www.securityfocus.com/bid/3723]
IV-A-5 - Cration de nouvelles rgles

Bien que le site officiel de Snort propose des rgles prtes l'emploi et rgulirement mises jour, il peut tre
intressant de crer ses propres rgles afin d'adapter au mieux Snort au rseau qu'il doit surveiller et protger. Par
convention, les nouvelles rgles personnelles sont placer dans le fichier local.rules.
Une rgle Snort est compose de deux parties et possde le format suivant : Header (Options).
Le format de la partie Header est dfini de la manire suivante :
action protocole adresse1 port1 direction adresse2 port2
Le champ action peut prendre les valeurs suivantes :
alert : gnrer une alerte + logger le paquet

log : logger le paquet
pass : ignorer le paquet
activate : activer une rgle dynamique
dynamic : dfinir une rgle dynamique, qui est passive tant qu'elle n'est pas active par une autre rgle
drop : demander iptables (10) de bloquer le paquet, puis le logger
reject : demander iptables de bloquer le paquet, puis le logger, et envoyer une commande TCP RST (reset)
ou une rponse ICMP Host unreachable
sdrop : demander iptables de bloquer le paquet. Ce dernier n'est pas logg.
Le champ protocole spcifie le protocole pour lequel la rgle s'applique. Les valeurs possibles sont : tcp, udp, icmp
ou ip.
Les champs adresse1 et adresse2 indiquent l'adresse IP source et destination du paquet. Le mot-cl any permet
de spcifier une adresse quelconque. Les adresses doivent tre numriques, les adresses symboliques ne sont pas
acceptes.
Les champs port1 / port2 spcifient les numros de port utiliss par la source et la destination. Le mot-cl any permet
de spcifier un port quelconque. Des noms de services peuvent tre utiliss : tcp, telnet De mme des plages de
ports peuvent tre spcifies avec le caractre : .
Le champ direction spcifie l'orientation du paquet. Cet oprateur peut prendre deux valeurs :
-> : adresse1 vers adresse2
<> : de adresse1 vers adresse2, ou de adresse2 adresse1
Notons qu'il n'y a pas d'oprateur <- .
La partie Options des rgles contient diffrentes options, spares par un point-virgule, qui vont permettre de prciser
des critres de dtection. Pour chaque option, le format est nomOption : valeur1[, valeur2]
Voici les options importantes :
msg : spcifier le message qui sera affich dans le log et dans l'alerte
reference : faire rfrence un site expliquant l'attaque dtecte
classtype : dfinir la classe de l'attaque (troyen, shellcode)
- 25 -
priority : dfinir la svrit de l'attaque

content : spcifier une chane de caractres qui doit tre prsente dans le paquet pour dclencher l'action de
la rgle
rawbytes : spcifier une suite d'octets qui doit tre prsente dans le paquet pour dclencher l'action de la
rgle
uricontent : identique content, mais est adapt au format normalis des URI (ex. : hexadcimal accept)
pcre : utiliser une expression rgulire compatible Perl pour spcifier le contenu du paquet
ttl : spcifier la valeur du TTL du paquet
flags : spcifier la prsence d'un flag TCP dans le paquet (ex. : SYN, FIN)
fragbits : vrifier la prsence de certains bits IP (more fragments, don't fragment ou bit rserv)
session : extraire toutes les informations de la session TCP laquelle le paquet suspect appartient
resp : activer une rponse flexible (flexresp) afin de bloquer l'attaque. Il est ainsi possible d'envoyer une
commande TCP ou ICMP prcise. Cette option ncessite l'activation du mode flexresp lors de la compilation
de Snort.
limit : limiter le nombre d'actions pendant un intervalle de temps pour le mme vnement.
Exemple de rgle :
alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEBATTACKS
/bin/ls command attempt"; uricontent:"/bin/ls";
nocase; classtype:web-application-attack;)
Cette rgle permet de gnrer une alerte quand un paquet provient d'un couple (adresse:port) quelconque, est
destination des serveurs HTTP dfinis dans snort.conf, et contient la chane /bin/ls dans l'URI. Le message de
l'alerte sera WEB-ATTACKS /bin/ls command attempt . Cette attaque sera classe dans la classe web-applicationattack (priorit medium par dfaut).
Il est bien sr impossible d'tre exhaustif ici pour dcrire le format des rgles Snort. Le manuel utilisateur disponible
sur le site officiel indique comment utiliser aux mieux le langage des signatures de Snort.
IV-A-6 - La console BASE

Par dfaut, les alertes de Snort sont enregistres dans un simple fichier texte. L'analyse de ce fichier n'est pas aise,
mme en utilisant des outils de filtre et de tri. C'est pour cette raison qu'il est vivement conseill d'utiliser des outils de
monitoring. Parmi ceux-ci, le plus en vogue actuellement est BASE (Basic Analysis and Security Engine), un projet
open source bas sur ACID (Analysis Console for Intrusion Databases). La console BASE est une application Web
crite en PHP qui interface la base de donnes dans laquelle Snort stocke ses alertes.
Pour fonctionner, BASE a besoin d'un certain nombre de dpendances :
un SGBD install, par exemple MySQL

Snort compil avec le support de ce SGBD
un serveur HTTP, par exemple Apache
l'interprteur PHP avec les supports pour le SGBD choisi, la bibliothque GD et les sockets.
La bibliothque ADODB : http://adodb.sourceforge.net
Nous ne dtaillerons pas ici l'installation de chaque dpendance. La documentation livre avec les sources de BASE
(disponibles sur http://secureideas.sourceforge.net) fournit les informations ncessaires.
Notons cependant que l'archive des sources de Snort dispose galement d'un dossier schemas contenant le code
SQL pour crer la structure de la base de donnes pour diffrents SGBD. Le fichier doc/README.database donne
toutes les indications pour crer le schma de la base de donnes.
Afin que Snort enregistre les alertes dans la base de donnes, il ne faut pas oublier de modifier le fichier snort.conf
et rajouter une ligne output database avec les informations pour se connecter la base de donnes.
- 26 -
Exemple :
output database: log, mysql, user=snortusr password=pwd
dbname=snort host=localhost
Aprs configuration et installation de BASE ainsi que de toutes ses dpendances, nous pouvons y accder avec un
navigateur internet. Si tout se passe bien, un cran similaire l'illustration suivante est obtenu :
IV-B - NIDS : Bro

IV-B-1 - Description
Bro est un NIDS Open Source, dvelopp essentiellement par une quipe du Lawrence Berkeley National Laboratory.
Bro se base sur un ensemble de rgles dcrivant des signatures d'attaques ou des activits inhabituelles.
Le comportement aprs dtection de trafic suspect peut tre paramtr : simple log, alerte en temps rel
l'administrateur ou excuter un programme (par exemple pour reconfigurer un routeur).
Initialement, le projet Bro a t cr dans un but de recherche pour la dtection d'intrusions et l'analyse de trafic
rseau. De ce fait, ce NIDS n'est pas destin aux personnes (physiques ou morales) recherchant une solution prte
l'emploi, mais plutt des administrateurs Unix chevronns, dsirant configurer au maximum leur systme de
dtection.
Parmi les fonctionnalits intressantes, on peut noter :
un langage de script propre Bro permettant d'crire les rgles de dtection et d'action ;
l'utilisation des expressions rgulires pour exprimer les motifs des signatures ;
la possibilit d'excuter des programmes tiers aprs dtection d'intrusion permet de raliser de nombreux
types d'actions ;
une compatibilit avec les rgles de Snort, grce un convertisseur nomm snort2bro ;
la possibilit d'utiliser GnuPG (Gnu Privacy Gard) pour crypter et signer les rapports d'alertes. Cela permet
d'empcher l'espionnage ou la falsification des logs par un pirate ;
l'envoi d'un rapport priodique des alertes par mail.
L'architecture de Bro est dfinie en trois couches principales :
le module Packet Capture : charg d'couter le trafic en mode sniffer et de transmettre tous les paquets la
couche suprieure ;
le module Event Engine : classe les flux par protocole, cre une table d'tats pour les connexions, contrle
l'intgrit (checksum), rassemble les fragments et analyse les flux. Ce module gnre des vnements qu'il
transmet la troisime couche ;
le module Policy Layer : utilise les scripts crits dans le langage de Bro pour traiter les vnements.
IV-B-2 - Installation
1. Tlcharger les sources sur http://www.bro-ids.org. Lors de l'criture de ce document, la dernire version stable
tait la 0.9.
2. Tlcharger et installer les bibliothques ncessaires pour Bro :
=> libpcap (http://www.tcpdump.org) : offre des fonctions de sniffer
- 27 -
=> termcap (ftp://ftp.gnu.org/gnu/termcap)

La compilation de ces bibliothques se fait trs aisment : ./configure, make, make install.
3. Ouvrir un terminal, dcompresser ensuite l'archive de Bro et se placer dans le rpertoire des sources
dcompresses.
4. Gnrer un makefile adapt au systme de destination : ./configure
5. Compiler les sources : make
6. Installer Bro : make install-brolite en mode root. Cette commande va non seulement installer Bro, mais galement
crer un excutable qui va faciliter la configuration de Bro.
IV-B-3 - Configuration
La configuration gnrale de Bro se fait trs simplement en mode interactif la fin de l'installation. Il suffit ds lors
de rpondre aux questions qui sont poses, et l'IDS sera configur automatiquement. Il est possible de reconfigurer
Bro plus tard en excutant le script bro_config. Notons qu'une configuration manuelle peut tre ralise en ditant
le fichier bro.cfg.
IV-B-4 - Excution
Grce au script de lancement livr avec Bro, le daemon peut tre excut de manire trs simple avec la commande
bro.rc start (en mode root). Ds le dbut de l'excution, les diffrentes activits sont logges dans le rpertoire
$BROHOME/logs/. Plusieurs fichiers de log y sont prsents :
alarm.XXX : les attaques dtectes

conn.XXX : un rsum des connexions tablies
ftp.XXX : des informations concernant le trafic FTP suspect
HTTP.XXX : des informations concernant le trafic HTTP suspect
info.XXX : des informations gnrales
notice.XXX : un suivi des vnements lancs
IV-B-5 - Cration de nouvelles rgles

Tout comme le NIDS Snort, il est possible avec Bro de crer ses propres rgles de dtection ou d'adapter les rgles
existantes en fonction du systme utilis. Pour cela, il faut bien sr respecter un format trs strict, mais puissant.
Chaque signature de Bro a le format suivant : signature id { attribute-set } o id reprsente un identifiant unique (sous
forme de chane de caractres) de la signature et o attribute_set est un ensemble d'attributs qui peut contenir des
conditions ou des actions.
Quatre types de conditions existent. Celles-ci vont permettre de dfinir quand la signature sera reconnue :
conditions d'en-tte : elles permettent de spcifier le protocole, les ports et les adresses source et de
destination ;
conditions de contenu : elles sont exprimes sous forme d'expressions rgulires pour reconnatre le contenu
de certains types de requtes ;
conditions de dpendance : elles permettent d'exprimer des dpendances entre les signatures. Par exemple,
une signature ne doit tre dtecte que si une autre signature l'a t ;
conditions de contexte : elles permettent de rajouter l'excution de certaines fonctions, crites avec le
langage de script de Bro, qui complmenteront les autres conditions.
- 28 -
Comme nous pouvons le voir, les conditions de dtection de signatures sont trs volues. Cependant, ce n'est pas
le cas des actions, c'est--dire les oprations raliser quand une signature est dtecte. Il n'existe pour l'instant
qu'une seule action possible : event. Celle-ci va permettre de dcrire l'ventuelle attaque qui a t dtecte.
Enfin, rappelons l'existence de snort2bro qui permet de convertir des rgles crites pour Snort dans le format de
Bro. Ainsi, un utilisateur prfrant la syntaxe de Snort ou utilisant ces deux NIDS, pourra trs facilement rutiliser
ses rgles Snort avec Bro.
IV-C - Comparatif Snort & Bro

Nous venons de voir une description des fonctionnalits des deux NIDS les plus utiliss dans le mode Open-Source.
Comme nous l'avons remarqu, Snort et Bro ne partagent pas les mmes objectifs : l'quipe de Snort veut un IDS
performant, volutif et facile utiliser ; alors que l'quipe Bro prfre favoriser l'innovation et la recherche ainsi que
profiter de ce projet pour tester des nouvelles mthodes d'analyse.
Voyons cependant un rcapitulatif des grandes fonctionnalits qu'offrent ces deux NIDS :
Snort :
+ grande communaut => de nouvelles rgles sont trs rgulirement proposes par
le CERT, SANS ou l'quipe de Snort
+ grande communaut => de nombreux plugins, frontends, consoles de management
+ mise en uvre basique rapide
+ projet maintenu par une socit : trs bonne ractivit et produit adapt aux entreprises
+ de nombreux livres et documentations existants
+ fichiers d'alertes facilement analysables par un humain
+ fichiers d'alertes trs complets (header des paquets, lien vers description de
l'attaque)
- fichiers d'alertes difficiles parser de manire automatise
- configuration essentiellement par dition de fichiers texte
- de nombreuses fonctionnalits sont payantes
Bro :
- 29 -
+ possibilit d'utiliser des rgles Snort en les convertissant avec l'utilitaire snort2bro
+ forte customisation, qui rend l'IDS trs difficile dtecter par un pirate
+ langage de script puissant et adapt la dtection d'intrusion
+ de nombreuses fonctionnalits prvues pour la version 1.0
+ cryptage et signature lectronique des rapports
+ rapport priodique rsumant les alertes
+ configuration trs simple grce un script interactif
+ fichiers d'alertes trs faciles parser de manire automatise
- projet maintenu par des chercheurs : ractivit moyenne et produit peu adapt aux
entreprises
- fichiers d'alertes difficilement analysables par un humain en format brut
- peu d'informations dans les rapports d'alertes
- documentation incomplte empchant d'utiliser pleinement les nombreuses
fonctionnalits
- aucune GUI actuellement disponible
- pas de support natif pour enregistrer les alertes dans une base de donnes
En analysant ces tableaux de fonctionnalits, nous pouvons remarquer que Bro est loin d'tre un projet amateur,
car il possde des options trs intressantes. Mais pour devenir un grand NIDS respect par les entreprises, il
devra favoriser le dveloppement de ses mthodes de dtection ainsi que simplifier l'accs l'application par une
documentation complte et des interfaces facilitant la gestion et l'analyse des logs.
Quant Snort, il a fait ses preuves. Mais la version Open-Source est encore rserve une certaine lite. Bien
videmment, la version commerciale n'a srement pas les mmes faiblesses.
IV-D - NIPS : SnortSam

SnortSam est un plugin Open-Source et multiplateforme pour Snort. Il permet de bloquer automatiquement des
adresses IP lorsqu'il dtecte une tentative d'intrusion. Le blocage se fait en communiquant avec un firewall matriel
(ex. : Cisco Pix) ou logiciel (ex. : PacketFilter, IPtables).
SnortSam est construit autour d'une architecture client / serveur (Snort / SnortSam) permettant de mettre en place le
NIPS de manire distribue. De plus, pour des raisons de scurit, toutes les communications ralises entre Snort
et l'agent de SnortSam sont cryptes l'aide de l'algorithme TwoFish.
Parmi les fonctionnalits intressantes, on notera la prsence d'une White-List, c'est--dire une liste d'adresses IP
qui ne peuvent pas tre bloques. Cela reprsente une scurit pour viter un blocage d'adresses sensibles (routeur,
serveur Intranet) en cas de spoofing de la part du pirate.
Le plugin SnortSam est galement dot d'un systme de log et de notification par email des vnements.
La mise en place d'actions de blocage est trs simple. Il suffit de modifier les rgles Snort pour signaler que la
dtection de certaines signatures doit provoquer un blocage. Pour cela, le mot-cl fwsam a t rajout. Il permet
notamment de spcifier une dure de blocage.
Cette option de dure peut-tre intressante lors d'un blocage aprs des tentatives rptes d'authentification avec
un mot de passe erron.
- 30 -
IV-E - NIPS : Snort-Inline

l'instar de SnortSam, Snort-Inline est un NIPS bas sur Snort. Cependant, il ne s'agit pas d'un plugin mais d'une
version modifie de Snort.
Son mode de capture est totalement diffrent de celui de Snort : les paquets ne sont plus capturs grce la clbre
bibliothque libpcap, mais via libipq, qui permet d'accepter des paquets provenant du firewall iptables.
Contrairement SnortSam qui communique avec les firewalls (distants ou non), Snort- Inline est un complment au
firewall : il doit tre install sur la mme machine. Les paquets accepts seront ensuite transmis sur le rseau.
Snort-Inline est trs peu utilis, surtout depuis l'introduction des actions de blocage directement dans Snort. Il est
nanmoins trs connu en raison de son importance dans le projet Honeynet (www.honeynet.org).
IV-F - HIDS : OSSEC

IV-F-1 - Description
OSSEC est un HIDS Open Source. Dvelopp initialement dans le but d'analyser quelques fichiers journaux de
diffrents serveurs, il est devenu aujourd'hui bien plus puissant qu'un simple analyseur de logs.
Capable d'analyser diffrents formats de journalisation tels que ceux d'Apache, syslog, Snort, et intgrant un
analyseur d'intgrit systme, il est devenu aujourd'hui un logiciel de dtection d'intrusions part entire.
Ses fonctions lui permettent de dtecter des anomalies apparues sur le systme. Par exemple, de multiples erreurs
404 dans les logs du serveur web Apache, la prsence d'un rootkit (11) cach dans un binaire systme, ou encore
des essais d'envoi de mail par relay smtp.
En ralit, grce un systme de rgles entirement paramtrable via des fichiers XML, OSSEC est capable de
dtecter n'importe quelle anomalie. De plus, il est dot d'un systme de rponse active qui permet une
commande d'tre excute lors de la dtection d'une anomalie.
IV-F-2 - Installation
L'installation de OSSEC se fait trs simplement grce un assistant de configuration.
Rendez-vous sur http://www.ossec.net pour tlcharger l'IDS. Lors de la rdaction de ce document, la dernire version
tait 0.7p1.
Dcompressez l'archive puis lancez l'installeur l'aide de la commande ./install.sh une fois dans le rpertoire
dcompress.
Aprs quelques questions, l'installeur mettra en place OSSEC et il ne restera plus qu' complter le fichier de
configuration avec les valeurs souhaites.
IV-F-3 - Configuration
La configuration se situe dans le fichier ossec.conf du dossier $INSTALL_DIR/etc/. La majorit de ce fichier sera
rempli par les paramtres spcifis lors de l'installation. Ce fichier se divise en plusieurs sections :
Global : contient les paramtres d'alertes par email ;

Rules : indique les diffrents fichiers contenant les rgles de dtection ;
- 31 -
Syscheck : spcifie les rpertoires scanner et les fichiers ignorer ;

Rootcheck : contient les paramtres de dtection des rootkits. Les fichiers contenant les signatures doivent
tre spcifis ;
Active-response : active/dsactive la rponse active ;
Alerts : spcifie le niveau d'alerte pour avertir par email l'administrateur ;
Localfiles : contient tous les fichiers de logs vrifier (une entre par fichier).
IV-F-4 - Cration de nouvelles rgles

Grce l'externalisation des rgles, il est possible de rajouter de nouvelles rgles trs facilement. Par dfaut, les
rgles concernant un mme programme se trouvent toutes dans le mme fichier, mais rien n'empche de crer de
nouveaux fichiers.
Voici un exemple de rgle :
<group name="syslog,attacks">
...
<rule id="1608" level="14" timeframe="120">
<if_matched_regex>^sshd[\d+]: \.+Corrupted check by bytes
on</if_matched_regex>
<regex>^sshd[\d+]: fatal: Local: crc32 compensation
attack</regex>
<description>SSH CRC-32 Compensation attack</description>
<cve>2001-0144</cve>
<info>http://www.securityfocus.com/bid/2347/info/</info>
</rule>
...
</group>
Cette rgle est caractrise par un identifiant unique (chaque rgle possde un identifiant propre), un niveau de
scurit allant de 0 16 (ici 14) et une frquence d'apparition (timeframe). Cette frquence d'apparition permet de
dclencher une rgle uniquement si une rgle prcdente a dj t leve. La rgle prcdente est spcifie l'aide
de la baliseif_matched_regex. Cette dernire option de rptition est bien sur optionnelle.
Plusieurs options de concordance sont possibles. Ici regex spcifie qu'il s'agit d'une expression rgulire trouver
dans la chane. Toutefois, il existe l'option match qui spcifie une sous-chane trouver dans la chane.
La balise description permet de donner une courte description de la rgle ; cve la date de dcouverte de la faille et
enfin info permet de spcifier une information supplmentaire sur la rgle, par exemple l'URL qui rfrence l'exploit
connu.
Plus d'informations sont disponibles dans la documentation sur le site officiel d'OSSEC.
IV-G - HIDS : SamHain

IV-G-1 - Description
De la mme faon que OSSEC, Samhain est un systme de dtection d'intrusions Open Source. Il offre nanmoins
des fonctions supplmentaires comme le stockage des alertes d'intrusions dans un systme de base de donnes,
le chiffrement des communications client/serveur ainsi qu'une console de visualisation des alertes disponible via un
navigateur web.
IV-G-2 - Installation
L'installation va s'effectuer en plusieurs tapes. Tout d'abord, il faut installer la partie serveur qui va s'occuper de runir
toutes les alertes envoyes par les diffrents agents. Les sources sont disponibles sur http://la-samhna.de/samhain/.
- 32 -
Exemple d'installation avec le support d'une base de donnes MySQL :

./configure --enable-network=server --enable-xml-log -with-database=mysql --prefix=/usr/local/yule
make
make install
Le serveur (se nommant yule) va ici tre install dans /usr/local/yule. Effectuons prsent l'installation du client :
./configure --prefix=/usr/local/samhain --enable-xml-log -enable-network=client \
--with-datafile=
REQ_FROM_SERVER/var/lib/samhain/samhain_file \
--with-config-file=REQ_FROM_SERVER/etc/samhainrc \
--with-logserver=server.yourdomain.com
make
La variable REQ_FROM_SERVER indique que ce fichier doit tre rcupr du serveur.

Logserver spcifie l'adresse o se trouve le serveur regroupant toutes les alertes, c'est--dire l'adresse laquelle
le client samhain enverra les alertes.
Cette installation n'est toutefois pas termine, puisqu'avant d'effectuer la dernire phase, il faut configurer le client
pour qu'il puisse s'authentifier au niveau du serveur.
Gnrons une cl alatoire sur le serveur :
yule -P $SHPW | sed s%HOSTNAME%client.yourdomain.com% >>
/etc/yulerc
Indiquons cette cl notre client :

./samhain_setpwd samhain new $SHPW
Cette opration a pour but de crer un nouveau binaire se nommant samhain_new, qui nous permettra de nous
connecter avec le serveur. Terminons l'installation avec ces lignes :
mv samhain.new samhain
make install && make install-boot
samhain -t init
IV-G-3 - Configuration
La configuration par dfaut offre un environnement de dtection quasi oprationnel. Il suffit de modifier la variable
ExportSeverity afin de spcifier le niveau de dtection considr comme alerte .
Dans le fichier /etc/samhainrc, modifiez ainsi :
[Log]
ExportSeverity=warn
- 33 -
IV-H - HIDS : RkHunter

IV-H-1 - Description
Rkhunter est un dtecteur de rootkits. Il permet de dtecter la prsence d'un rootkit dissimul dans un binaire systme.
Il offre galement la possibilit de scanner des fichiers de configuration afin de dtecter la prsence d'anomalies de
configuration (utilisateur avec UID 0 : root), ou encore la prsence de ports ouverts suspects (utiliss par certains
rootkits).
IV-H-2 - Installation
L'installation de rkhunter se fait automatiquement. Rcuprez les sources sur http://www.rootkit.nl/ puis
dcompressez l'archive. L'installation s'effectue l'aide de l'assistant installer.sh.
Aucune configuration supplmentaire n'est effectuer. Il suffit de lancer le binaire pour lancer un scan. Cette ligne
de commande permettra d'effectuer un scan non interactif :
/usr/local/bin/rkhunter -c -sk
Voici un exemple de rsultat :

Networking
* Check: frequently used backdoors
Port 2001: Scalper Rootkit [ OK ]
Port 2006: CB Rootkit [ OK ]
Port 2128: MRK [ OK ]
Port 14856: Optic Kit (Tux) [ OK ]
Port 47107: T0rn Rootkit [ OK ]
Port 60922: zaRwT.KiT [ OK ]
* Interfaces
Scanning for promiscuous interfaces [ OK ]
Security advisories
* Check: Groups and Accounts
Searching for /etc/passwd... [ Found ]
Checking users with UID '0' (root)... [ OK ]
* Check: SSH
Searching for sshd_config...
* Check: Events and Logging
Search for syslog configuration... [ OK ]
Checking for running syslog slave... [ OK ]
Checking for logging to remote system... [ OK (no remote
logging) ]
------------------ Scan results -------------------MD5
MD5 compared: 0
Incorrect MD5 checksums: 0
File scan
Scanned files: 342
Possible infected files: 0
Application scan
Vulnerable applications: 0
Scanning took 62 seconds
IV-I - Comparatif HIDS

Le tableau suivant montre les diffrences entre les trois HIDS que nous venons de prsenter. Ce tableau les compare
sur les principaux critres exigs d'un HIDS en environnement de production.
- 34 -
Tirons quelques conclusions de ce tableau comparatif. D'une part, nous remarquons immdiatement la dficience
du logiciel Rkhunter. Ceci est normal, Rkhunter est uniquement un analyseur systme pour vrifier la prsence de
rootkits. Mais nous avons jug important de le placer dans ce comparatif de par ses fonctionnalits d'alerte qui se
rapprochent, voire quivalent, celles d'autres HIDS.
Les deux systmes Ossec et Samhain sont fort proches. Ils possdent tous les deux la possibilit d'tre mis en place
de manire locale ou bien via une architecture client/serveur.
Chacun d'entre eux analyse le systme pour vrifier la non-prsence de rootkits, inspecte les fichiers de logs pour y
dtecter des activits anormales, et permet d'avertir l'administrateur via des emails ou en journalisant les alertes.
En dehors de cela, nous remarquerons la maigre supriorit de Samhain sur OSSEC.
Toutefois, cette supriorit est temprer. En effet, durant nos tests, l'installation de Samhain nous a pos quelques
problmes, et la configuration n'a pas t des plus simples. l'inverse, le systme OSSEC est dot d'un installeur qui
prend les choses en main et nous demande uniquement les paramtres de configuration. Ainsi, malgr un nombre
de fonctionnalits important, Samhain n'est peut-tre pas aussi mature qu'il le laisse paratre.
IV-J - IDS Hybride : Prelude

Comme nous l'avons prcdemment constat, il existe peu d'outils permettant d'unifier l'utilisation conjointe de
diffrents IDS. Prelude est n de cette observation, il se veut tre un framework (12) de centralisation et d'unification
des vnements permettant d'acclrer l'analyse des diffrentes alertes.
Prelude est un IDS Hybride, c'est--dire qu'il combine les vnements dtects par toute sorte d'applications de
scurit : NIDS, analyseur de logs (HIDS), antivirus, etc. Dans le but de raliser cette tche, Prelude s'appuie sur
le standard IDMEF (Intrusion Detection Message Exchange Format), dont nous avons dj parl dans la partie
Normalisation .
Parmi les applications de scurit supportes par Prelude, on retrouve le NIDS Snort, le scanner de vulnrabilits
Nessus, le HIDS Samhain, et plus de 30 analyseurs de logs.
Le framework se compose d'une bibliothque de gnration de messages IDMEF, d'un gestionnaire d'vnements,
d'un analyseur de logs et d'une console de visualisation des alertes.
L'interface de visualisation des alertes est une application web dveloppe en tant que script CGI. Elle permet de
mettre en vidence les alertes importantes, comme le montre l'illustration ci-dessous.
De plus, cette console permet de gnrer des graphiques statistiques rassemblant des informations importantes sur
les cibles vises et permettant de voir rapidement quelles sont les alertes les plus frquentes. L'illustration suivante
est un exemple des possibilits de la console de Prelude.
IV-K - KIDS : LIDS

Le systme de dtection d'intrusions LIDS est un patch appliquer au noyau Linux.
Celui-ci permet d'augmenter la scurit du noyau en implmentant un contrle d'accs chaque ressource systme.
Une fois activs, tout accs fichier, toute opration d'administration rseau, tout usage mmoire et toute lecture/
criture sur disque deviennent impossibles mme pour l'utilisateur root.
- 35 -
Il est possible de spcifier la liste des fichiers accessibles par chaque programme indpendamment. Ce systme
offre une scurit optimale, mais peut s'avrer compliqu mettre en place et configurer. Mal configur, ce systme
peut paralyser une machine et la rendre totalement hors d'usage.
LIDS supporte les noyaux 2.6 et 2.4 l'heure actuelle. Il est distribu gratuitement sous licence GPL.
V - Tests de dtection d'attaques

Afin de tester les performances de dtection des NIDS prsents dans ce rapport, nous avons ralis quelques
simulations d'attaques. Celles-ci sont cependant trs basiques, et les rsultats prsents ici ne refltent pas la
capacit de dtection d'intrusions face aux techniques utilises par des professionnels.
V-A - Exploit phpBB

Prsentation :
Cette attaque utilise une faille prsente dans certaines versions du trs clbre moteur de forum phpBB. Pour exploiter
cette faille, nous avons utilis le framework Metasploit.
L'exploit consiste utiliser le paramtre highlight de la page viewtopic.php dont le contenu n'est pas vrifi
correctement, permettant ainsi d'injecter du code arbitraire.
Rsultats du test :
Aucun des deux IDS ne s'est montr capable de dtecter correctement cet exploit. En effet, les signatures par dfaut
de Snort ne dtectent pas l'attaque en elle-mme, mais l'accs au fichier concern. Nanmoins, il est impensable de
gnrer une alerte pour chaque accs au fichier viewtopic.php sur un serveur disposant d'un forum phpBB.
V-B - Scan TCP SYN

Prsentation :
Il s'agit d'un scan de ports TCP qui consiste ne pas tablir compltement de connexion.
Lorsqu'un port ouvert est dtect, la poigne de main est rinitialise.
L'utilitaire nmap peut raliser un tel scan grce l'argument -sS.
Rsultats du test :
Conclusion :
Ce genre de scan passait inaperu il y a quelques annes, mais il est facilement dtectable de nos jours.
V-C - Scan TCP Connect

Prsentation :
- 36 -
Il s'agit d'un scan de ports TCP qui dtecte les ports ouverts en tablissant une connexion complte ceux-ci.
L'utilitaire nmap peut raliser un tel scan grce l'argument -sT.
Rsultats du test :
Conclusion :
Cette mthode de scan est la plus facile mettre en uvre, mais c'est galement la moins discrte.
V-D - Scan Null

Prsentation :
Il s'agit d'un scan de ports TCP qui dtecte les ports ouverts en envoyant un paquet TCP avec tous les champs du
header 0. Si le port est ferm, le serveur rpond normalement par une commande RST. Si le port est ouvert, le
serveur ne rpond pas.
L'utilitaire nmap peut raliser un tel scan grce l'argument -sN.
Rsultats du test :
Conclusion :
Ici, Snort se montre plus performant que Bro, qui ne voit rien d'anormal lors du scan.
V-E - Remarques sur les scans

Les rsultats des scans prsents ci-dessus concernent les scans par dfaut. Il est important de noter que tout
scan passe inaperu si chaque test de port est suffisamment espac. L'option Paranoid Trottling de nmap permet
notamment d'attendre 5 minutes entre chaque test de port. Le scan devient ds lors trs lent (plusieurs heures pour
un scan complet), mais est difficilement dtectable.
V-F - Exploit : Overflow HTTP d'Oracle 9i (win32)

Prsentation :
La version 9i du clbre SGBD Oracle est victime d'une faille dans son moteur XML, appel XDB. Nous avons test
un exploit tirant profit de cette faille avec le framework Metasploit.
L'exploit consiste provoquer un stack overflow lors de l'identification HTTP au serveur de base de donnes.
Rsultats du test :
Screenshot de l'attaque :
- 37 -
Conclusion :
Snort dispose par dfaut de la signature pour cette attaque, permettant de la dtecter trs facilement.
V-G - Remarques sur les exploits Oracle 9i

Comme nous l'avons vu, une version par dfaut de Snort ne dtecte pas toujours les attaques contre le moteur XML
d'Oracle 9i. Pour se protger de manire efficace, l'entreprise Oracle prconise tout simplement de dsactiver les
services HTTP et FTP.
VI - Algorithmique : le Pattern Matching

Bien que la dtection d'intrusions soit plutt lie aux rseaux et aux systmes d'exploitation, l'algorithmique reste trs
importante dans ce domaine. Il serait impossible d'tre exhaustif pour les algorithmes mis en uvre dans les IDS.
De ce fait, nous avons dcid de nous limiter aux techniques de pattern matching.
VI-A - Introduction
La recherche de motif (pattern matching) est un sujet important dans le domaine du traitement de donnes. Son but
est de localiser une occurrence d'un mot (= le motif) dans une chane de caractres (= le texte).
Le pattern matching joue un rle crucial dans les NIDS qui utilisent des signatures pour dtecter les attaques ou
intrusions. Un bon NIDS doit pouvoir analyser les paquets qu'il reoit en temps rel. Avec les vitesses leves des
rseaux actuels, il est vident que les algorithmes de pattern matching ne doivent pas tre ngligs, car il en va de
la scurit des systmes surveills.
Plusieurs algorithmes de recherche de motif vont tre expliqus dans ce chapitre. Pour la suite, les notations suivantes
seront utilises :
x = x0x1xm-1 : le motif rechercher, de longueur m

y = y0y1yn-1: le texte sur lequel aura lieu la recherche, de longueur n
me
x[i] et y[i] : le i
caractre de x ou y, quivalent xi et yi
La plupart des algorithmes de pattern matching utilisent une fentre glissante de taille m. Cette fentre reprsente
la position de l'ventuelle occurrence du motif. En d'autres termes, elle englobe les caractres du texte qui vont
tre compars avec le motif pour la tentative en cours. Cette fentre est dcale chaque non-correspondance
(mismatch) et la procdure de comparaison reprend au dbut de la fentre.
Deux catgories de pattern matching peuvent tre distingues :
avec motifs fixes et texte variant : c'est le cas des NIDS avec texte fixe ;
motifs variants : correspond une recherche dans un dictionnaire
Dans tous les cas, l'efficacit d'un algorithme de pattern matching dpend du nombre de comparaisons de caractres
ncessaires pour rechercher le motif.
Lors du choix et de l'implmentation d'un algorithme de pattern matching, plusieurs considrations doivent tre prises
en compte :
- 38 -
a) Le type de pattern matching : recherche multi ou simple motif, motifs statiques ou dynamiques b) Sensibilit
la casse : dans le cas d'une recherche insensible la casse, les caractres du motif et du texte seront par exemple
convertis en majuscules.
c) La taille des motifs : certains algorithmes ont des performances rduites pour les motifs de grande taille.
d) La taille de l'alphabet : la plupart des algorithmes fonctionnent facilement si les caractres sont stocks sur un
octet, mais dans le cas du codage Unicode, certaines adaptations devront tre apportes.
e) Le risque d'attaques de l'algorithme : des pirates peuvent ventuellement utiliser les proprits et le comportement
de l'algorithme pour rduire les performances du programme. Il est donc ncessaire, surtout dans le cas des IDS,
d'valuer les consquences de telles attaques.
f) La frquence des recherches et la taille des textes de recherche : ces deux aspects peuvent influencer les
performances, et l'algorithme devra tre adapt aux types de recherches raliss.
VI-B - Algorithme naf (Brute Force Algorithm)

Cet algorithme consiste vrifier pour chaque position dans le texte si une occurrence du motif commence l ou non.
Il compare donc le motif x chaque facteur du texte y de longueur m. Si une occurrence est rencontre, on le signale ;
sinon, on recommence avec le facteur suivant de y en dcalant la fentre d'exactement une position vers la droite.
Procdure Recherche_Nave (x, y):
i := 0
j := 0
tantque i < m et j < n faire
si y[j] = x[i] alors // Caractre identique :
i := i +1 // on continue dans la mme fentre
j := j+1 //
sinon
j := j - i +1 // Dcalage de la fentre
i := 0 // Le motif est reparcouru
finsi
fintantque
si i = m alors
Occurrence de x trouve la position j - m
sinon
Pas d'occurrence
finsi
Dans le pire des cas, cet algorithme fait (n - m + 1) m comparaisons, ce qui correspond une complexit temps de
O(mn). Ce cas correspond par exemple la recherche de am-1b dans an puisque chaque tentative, l'algorithme
parcourt tout le motif, pour se rendre compte que le dernier caractre (b) n'est pas identique.
VI-C - L'algorithme de Morris - Pratt

L'algorithme naf a un gros inconvnient : en cas d'chec, il recommence entirement la comparaison du motif x avec
le facteur suivant de y, sans exploiter l'information contenue dans la russite partielle de la tentative. L'algorithme de
Morris-Pratt reprend l'algorithme naf tout en profitant de l'analyse du texte pour collecter des informations.
Grce un prtraitement sur le motif, il est possible d'obtenir un gain de temps considrable en vitant de rpter
des comparaisons.
Considrons une tentative de recherche du motif x dans le texte y, commenant la position j dans y. Cela correspond
donc au cas o la fentre est positionne sur y[j .. j + m - 1].
- 39 -
x[i] et y[j+i], avec 0<i<m. Ds lors :
x[0..i-1] = y[j..j+i-1] : les i-1 caractres prcdemment compars sont identiques.Notons u cette sous-chane.
x[i] y[j+i]
Lorsqu'un dcalage de la fentre de comparaison a lieu, il ne faut pas oublier qu'un prfixe v du motif peut
correspondre un suffixe de la portion u du texte. Ce prfixe v est appel un bord de u.
Dfinition :
Soit u un mot quelconque non vide, un bord de u est un mot distinct de u qui est la fois prfixe et suffixe de u.
Notation :
Soit mpNext[i] la longueur du plus long bord de x[0..i-1], pour 0 < i m.
mpNext[0] = -1
mpNext[i] = | Bord maximal (x[0..i-1]) |
Aprs un dcalage, les comparaisons peuvent reprendre entre x[mpNext[i]] et y[j+i] sans risquer d'oublier une
occurrence de x dans y, et tout en vitant de faire un retour en arrire dans le texte.
La table mpNext peut tre construite en espace et temps O(m). Cette table doit tre construite avant la phase de
recherche.
Procdure PrtraitementMP (x, m, mpNext[] )
i := 0
j := mpNext[0] := -1
tantque (i < m) faire // Parcours du motif
tantque ((j > -1) et (x[i] x[j])) faire
j := mpNext[j];
fintantque
j := j + 1
i := i + 1
mpNext[i] = j
fintantque
Voyons un exemple de la table des longueurs des bords maximaux pour le motif ACABACA .
Nous remarquons que mpNext[7] = 3, c'est--dire que le bord maximal de x[0..6], et donc du motif entier, est de
longueur 3. En effet, ce bord est ACA qui est prfixe et suffixe de ACABACA.
Aprs la cration des longueurs des bords, la phase de recherche peut tre faite en temps O(m+n). Au pire des cas,
l'algorithme de Morris-Pratt fait 2n-1 comparaisons.
Procdure RechercheMP (x, m, y, n)
PrtraitementMP (x, m, mpNext)
i := j := 0 // Initialisation des indices
tantque (j <= n) faire // Parcours du texte
tantque ( (i > -1) et (x[i] y[i]) ) faire
i := mpNext[i] // Dcalage en fin de bord
fintantque
i := i + 1
j := j + 1
si (i m) alors
- 40 -
Occurrence de x trouve la position j - i

i := mpNext[i]
finsi
fintantque
VI-D - L'algorithme de Knuth - Morris - Pratt

L'algorithme de Knuth-Morris-Pratt est une version optimise de l'algorithme de Morris- Pratt. En effet, l'algorithme
Morris-Pratt peut tre optimis en amliorant la longueur des dcalages.
Supposons une recherche du motif x partir de la position j dans le texte y, c'est--dire que la fentre est positionne
sur y[j..j+m+1].
y[j+i], avec 0 < i < m. Ds lors :
x[0..i-1] = y[j..j+i-1] : les i-1 caractres prcdemment compars sont identiques.

Notons u cette sous-chane.
x[i] y[j+i]
Lorsqu'un dcalage de la fentre de comparaison a lieu, il ne faut pas oublier qu'un prfixe v du motif peut
correspondre un suffixe de la portion u du texte.
De plus, pour viter une autre non-correspondance immdiate, le premier caractre aprs le prfixe v doit tre diffrent
de l'ancien x[i] puisque nous savons dj que y[j+i] x[i].
Un tel prfixe v est appel bord disjoint (tagged border) de u.
Notation :
Soit kmpNext[i] la longueur du plus long bord de x[0..i-1], pour 0 < i m, suivi d'un caractre diffrent de x[i] ; ou
-1 si aucun bord disjoint n'existe.
mpNext[0] = -1
mpNext[i] = | Bord maximal disjoint (x[0..i-1]) |
Aprs un dcalage, les comparaisons peuvent reprendre entre x[kmpNext[i]] et y[j+i] sans rater d'occurrence de x
dans y, et tout en vitant un retour en arrire dans le texte.
La table kmpNext peut tre calcule en temps et espace O(m). Ce calcul est ralis avant la phase de recherche.
Procdure PrtraitementKMP (x, m, kmpNext)
i := 0
j := kmpNext[0] := -1
tantque (i < m) faire // Parcours du motif
tantque ( (j > -1) et (x[i] x[j]) ) faire
j := kmpNext[j]
fintantque
i := i + 1
j := j + 1
si (x[i] = x[j]) alors // Mme caractre : bord non
disjoint
- 41 -
kmpNext[i] := kmpNext[j]
sinon
jmpNext[i] := j // Position du bord disjoint
fsi
fintantque
Aprs le calcul de la table kmpNext, la phase de recherche peut tre ralise en temps O(m+n), avec au plus 2n-1
comparaisons.
Procdure KMP (x, m, y, n)
PrtraitementKMP (x, m, kmpNext)
i := j := 0
tantque (j < n) faire // Parcours du texte
tantque ( (i > -1) et (x[i] != y[j]) ) faire
i := kmpNext[i]
fintantque
i := i + 1
j := j + 1
si (i > m) alors
Occurrence de x trouve la position j - i
i := kmpNext[i]
finsi
fintantque
Nous remarquons que l'algorithme de Knuth-Morris-Pratt a exactement la mme complexit pour le cas le plus
dfavorable que l'algorithme de Morris-Pratt. Cependant, il y a une diffrence importante au niveau du dlai, c'est-dire le nombre de comparaisons faites sur un mme caractre dans le pire des cas.
Le dlai pour l'algorithme de Morris-Pratt est born par m, alors qu'il est born par logf (m) o f est le nombre d'or :
(1 + 51/2) / 2.
VI-E - Algorithme de Boyer - Moore

L'algorithme Boyer-Moore est un algorithme qui utilise galement le principe de la fentre de dcalage. Mais
contrairement l'algorithme naf et l'algorithme Knuth-Morris-Pratt, les comparaisons sont faites de la droite vers la
gauche. Cette modification apparemment anodine est trs rentable : en pratique, l'algorithme de Boyer-Moore est
le plus rapide des algorithmes connus ! Il est notamment utilis dans des diteurs de texte pour les commandes
rechercher et remplacer .
En cas de non-correspondance (mismatch), il utilise deux fonctions pour choisir le dcalage vers la droite de la
fentre. Ces deux fonctions sont appeles dcalage du bon suffixe et dcalage du mauvais caractre.
Supposons qu'une non-correspondance ait lieu lors de la comparaison de x[i] avec y[j+i].
Ds lors :
x[i+1 .. m-1] = y [i+j+1 .. j+m-1], notons u cette portion

pour rappel : le parcours des comparaisons se fait de gauche droite,donc de j+m-1 j.
x[i] y[j+i]
La fonction de dcalage du bon suffixe consiste aligner le segment u avec son occurrence la plus droite dans x,
qui est prcde par un caractre diffrent de x[i].
S'il n'y a pas de tel segment, le dcalage consiste aligner le plus long suffixe v de y[j+i+1 .. j+m+1] avec un prfixe
de x qui correspond.
- 42 -
La fonction de dcalage du mauvais caractre consiste aligner y[j+i] avec son occurrence la plus droite dans
x[0 .. m-2].
Exemple :
Si aucun caractre gal y[j+i] n'existe dans le motif x, aucune occurrence de x dans y ne peut inclure y[j+i]. Dans
ce cas, le dbut de la fentre est aligne avec le caractre qui suit immdiatement y[j+i], c'est--dire y[j+i+1].
L'algorithme Boyer-Moore choisit le dcalage maximum retourn par la fonction de bon suffixe et la fonction de
mauvais caractre.
Les rsultats de cette fonction sont stocks respectivement dans une table bmGS et bmBC. Celles-ci peuvent tre
calcules en temps O(m + ) avant la phase de recherche, et ncessitent un espace mmoire de O(m + ), o
est la taille de l'alphabet.
Procdure BoyerMoore (x, m, y, n)
calculBmGS (x, m, bmGS) // Fonctions non dtailles ici
calculBmBC (x, m, bmBC)
j := 0
tantque (j <= n - m) faire
i := m - 1
tantque ((i >= 0) et (x[i] = y[j+i])) faire
si (i < 0) alors
MOTIF TROUVE en position j
j := j + bmGS[0]
sinon
j := j + MAX(bmGS[i], bmBC[y[j+i]] - m + 1 + i)
finsi
i := i - 1
fintantque
fintantque
Sur des alphabets trs grands, l'algorithme de Boyer-Moore est extrmement rapide. La recherche de am-1b dans
bn ne ncessite que O(n / m) comparaisons, ce qui est le minimum absolu pour tout algorithme de pattern matching
o seul le motif est prtrait.
L'algorithme au pire des cas est en temps O(mn). Cependant, en pratique, on constate que le nombre total de
comparaisons est trs souvent infrieur la longueur du texte. En fait, il a t prouv que cet algorithme est souslinaire en moyenne.
VI-F - Algorithme de Aho - Corasick

Jusqu' prsent, nous avons vu des algorithmes qui permettent de rechercher un et un seul motif dans un texte la
fois. Or, les systmes de dtection d'intrusions doivent parfois vrifier la prsence de plusieurs centaines de motifs
dans chaque paquet qui arrive. Il est ds lors impensable de lancer squentiellement autant de recherches que de
motifs chercher.
Pour raliser une telle opration, il est ncessaire d'utiliser un algorithme qui effectue la recherche paralllement pour
chaque motif. C'est essentiellement le fonctionnement de l'algorithme de Aho-Corasick, qui est une gnralisation
de l'algorithme de Knuth, Morris et Pratt au cas de plusieurs motifs rechercher.
- 43 -
La premire tape de l'algorithme est de construire un automate dterministe reconnaissant l'ensemble A*X, o A
est l'alphabet et X un ensemble fini de mots rechercher.
Soit donc X un ensemble fini de mots sur un alphabet A, et soit P l'ensemble des prfixes des mots de X. On construit
un automate : A = (P, , P A*X) reconnaissant A*X, dont P est l'ensemble d'tats, est l'tat initial et P A*X
l'ensemble d'tats terminaux.
La fonction de transition est dfinie, pour p # P et a # A, par p.a = fX(pa). La fonction fX est dfinie par : fX(u) = le
plus long suffixe de u qui est dans P.
Cette fonction de transition de l'automate s'exprime l'aide des bords. En effet :
Nous pouvons ainsi exprimer la fonction de transition comme suit :

Fonction TRANSITION(p,a):
tantque pa P et p faire
p := BordX(p)
fintantque
si pa p alors retourner (pa) sinon retourner ()
La recherche des occurrences des mots de X dans un texte t = t1tn se fait par
l'algorithme suivant, qui incorpore l'valuation des transitions :
Procdure AHO_CORASICK(X, t):
q := // tat initial
pour i de 1 n faire // parcours du texte
tantque qti P et q faire
q := BordX[q]
fintantque
si qti P alors
q := qti // on avance dans l'automate
sinon
q := // motif introuvable : on retourne au dbut
finsi
si q est un tat final alors
MOTIF q TROUVE en position i
finsi
finpour
Nous pouvons remarquer que l'algorithme de recherche des occurrences des mots de X dans t s'effectue en temps
O(n + m) et en place O(m).
p . a =
fX(pa) si pa P;
BordX(pa) sinon;
BordX(pa) =
BordX(p) . a si p
sinon
VI-G - Snort et le pattern matching

Comme il l'a t voqu prcdemment, le pattern matching joue un rle important dans les performances de
NIDS bass sur des signatures, telles que Snort. Le choix d'un algorithme efficace et adapt aux besoins est donc
ncessaire. Mais comme nous allons le voir, cela n'est pas suffisant.
Commenons par un petit historique de Snort. Les versions initiales de ce NIDS utilisaient un algorithme brute force
de pattern matching. Celui-ci tait bien sr trs lent et a vite montr ses limites.
- 44 -
La premire amlioration apporte fut l'implmentation de l'algorithme de Boyer-Moore qui apporta de meilleures
performances. Bien que trs efficace pour de nombreuses applications, cet algorithme n'tait pas assez performant
dans le cas d'un NIDS dot de milliers de signatures.
En 2002, la version 2.0 de Snort est dote d'un moteur de recherche multimotif trs rapide, bas sur l'algorithme
de Aho-Corasick. Grce cela, Snort russit le test OSEC (http://osec.neohapsis.com) ralis 750M bits/sec.
Cependant, la qute aux performances tait loin d'tre finie.
Pour amliorer les performances, l'quipe de recherche de Snort savait qu'il n'tait plus ncessaire de changer
d'algorithme. Elle dcida ainsi de modifier principalement l'implmentation de l'algorithme Aho-Corasick. En effet, le
choix de structures de donnes adaptes n'est pas ngligeable pour amliorer la vitesse d'excution.
La reprsentation mmoire de la machine tats de l'algorithme Aho-Corasick est en gnral une matrice o les
lignes reprsentent les tats, et les colonnes reprsentent les vnements. Les lments de la matrice fournissent
l'tat suivant correct en fonction de l'vnement d'entre.
Par le choix de la reprsentation de cette table d'tats, un compromis mmoire - performance est dtermin. De
nombreuses applications utilisent des mthodes de reprsentation trs compresse, ce qui a pour consquence de
diminuer les performances de recherche.
Il n'tait pas pensable que Snort utilise ces mthodes de compression optimales.
Cependant, il tait important de minimiser au mieux la taille mmoire de l'automate. Une bonne reprsentation
des signatures apporte non seulement un gain d'espace mmoire, mais peut aussi apporter un norme gain de
performance grce une zone mmoire accs trs rapide : le cache.
L'optimum serait bien sr de pouvoir stocker toutes les signatures dans le cache, afin d'y accder trs rapidement.
Cependant, cela est difficilement ralisable du fait de la faible capacit des caches et aussi du nombre important (et
croissant) des signatures de Snort.
L'quipe de Snort dcida de reprsenter l'automate tats finis de l'algorithme par une matrice creuse (sparse matrix).
Dans le domaine de l'algbre linaire, il existe des mthodes et des formats de stockage trs performants pour de
telles matrices. Cependant, il n'est pas suffisant de stocker les donnes creuses de manire efficace, il faut surtout
tre capable d'y raliser un accs alatoire rapide.
Aprs avoir compar plusieurs formats de stockage, les chercheurs de Snort choisirent le format BandedRow , constitus de deux vecteurs et de deux index. L'implmentation de l'algorithme de Aho-Corasick fut ensuite
lgrement modifie pour s'adapter la nouvelle structure de donnes.
De nombreux benchmarks ont t raliss afin de s'assurer du gain de performance.
Ces benchmarks testaient trois versions : Aho-Corasick standard, Aho-Corasick optimis avec matrices compltes
et Aho-Corasick optimis avec le format Banded-Row .
L'illustration suivante montre les performances des trois implmentations, normalises par rapport l'algorithme
standard.
Nous pouvons remarquer que l'implmentation avec matrices compltes est 2 2,5 fois plus rapide que
l'implmentation standard. L'implmentation avec le format Banded-Row est plus rapide que la version standard,
mais son intrt par rapport la version matrices compltes n'apparat qu' partir de 1000 motifs. Snort possde
plus de 1000 signatures et par consquent, cette version se montre la plus performante.
L'illustration suivante montre l'espace mmoire ncessaire pour chaque implmentation.
- 45 -
e
e
Nous constatons que le stockage Banded-Row ne ncessite qu'1/15 du stockage de la version standard et 1/7
de la version avec matrices compltes. L encore, cette implmentation se montre la plus optimise.
VI-H - Conclusion
Plusieurs algorithmes de pattern-matching ont t prsents, et nous avons vu qu'il n'tait pas ais d'avoir un
algorithme efficace dans le cadre d'un NIDS, du fait des contraintes de vitesse des rseaux. Le tableau suivant
reprend les caractristiques majeures des algorithmes analyss prcdemment.
Enfin, nous avons vu que le choix d'un bon algorithme n'tait pas suffisant :
l'implmentation et les structures de donnes choisies jouent un rle trs important dans les performances d'un
algorithme.
VII - Conclusion
Bien que rpandus dans les organisations aujourd'hui, les systmes de dtection d'intrusions ne reprsentent qu'un
maillon d'une politique de scurit. En effet, mme si ceux-ci permettent la dtection, parfois l'arrt, des intrusions,
ils restent nanmoins vulnrables eux aussi face aux attaques externes.
C'est pourquoi, pour une scurit optimale, ces outils doivent tre coupls d'autres, comme l'indispensable parefeu. Mais ils doivent aussi tre mis jour, aussi bien le cur du logiciel comme la base de signatures, qui constitue
la base d'une dtection efficace. Il faut galement coupler les systmes de dtection entre eux : c'est--dire ne pas
hsiter placer des NIDS, HIDS et KIDS dans le mme rseau. Leurs rles sont diffrents, et chacun apporte ses
fonctionnalits.
L'efficacit des dtections passe aussi par une bonne implmentation des algorithmes de recherche. L'tude que nous
avons mene sur ces algorithmes nous a permis d'observer combien il est indispensable d'utiliser des structures
de donnes appropries lors d'un dveloppement. Mais ce n'est pas tout, au-del de ces structures, doit rsider un
savoir-faire important de la part du (des) concepteur(s).
Toutefois, et nous terminerons par ceci, mme si une certaine maturit dans ce domaine commence se sentir, le
plus important reste de savoir de quoi il faut se protger.
Les failles les plus rpandues proviennent gnralement de l'intrieur de l'entreprise, et non de l'extrieur. Des mots
de passe simples, des droits d'accs trop levs, des services mal configurs, ou encore des failles dans les logiciels
restent la bte noire en matire de scurit.
VIII - Bibliographie
Exact String Matching Algorithms
Christian Charras et Thierry Lecroq
http://www-igm.univ-mlv.fr/~lecroq/string/
lments d'algorithmique - Recherche de motifs
D. Beauquier, J. Berstel, Ph. Chrtienne
http://www-igm.univ-mlv.fr/~berstel/Elements/Elements.html
- 46 -
Optimizing Pattern Matching for Intrusion Detection

Marc Norton
Increasing Performance in High Speed NIDS, A look at Snort's internals
Neil Desei
Managing Security with Snort and IDS Tools
Kerry J. Cox, Christopher Gerg
O'Reilly - ISBN : 0-596-00661-6
Les IDS - Les systmes de dtection d'intrusions informatiques
Thierry Evangelista
Dunod - ISBN 2 10 007257 9
Les attaques externes
Eric Detoisien
Dtection et tolrance d'intrusions
Samuel Dralet
Les tests d'intrusions
Eric Detoisien et Frdric Raynal
Bro: Un autre IDS Open-Source
Jean-Philippe Luiggi
Misc Magazine n14
Snort User Manual
The Snort Project
http://www.snort.org
Prelude HandBook
Prelude Hybrid IDS project
http://www.prelude-ids.org/
Bro Reference Manual
Lawrence Berkeley National Laboratory
- 47 -
http://www.bro-ids.org
LIDS Documentation
LIDS Project
http://www.lids.org
Articles Wikipdia
http://www.wikipedia.org
IX - Annexe : Rappels essentiels concernant les protocoles

La plupart des attaques se font au niveau des couches hautes du modle OSI (Session, Prsentation & Application).
Cependant, il est important de connatre le fonctionnement des couches basses 3 et 4 (Rseaux et Transport) pour
comprendre certaines attaques.
L'en-tte d'un datagramme IP est compos :
d'une partie fixe de 20 octets

d'une partie longueur variable : les options
Il est utile de connatre les champs du protocole IP, qui sont utiliss des fins de reconnaissance ou d'attaque par
dni de services :
Version (4 bits) : version du protocole (IPv4, bientt IPv6)

En-tte (4 bits) : spcifie la longueur de l'en-tte, en mots de 32bits. Minimum 5, car il y a 20 octets au
minimum dans l'en-tte
Type de service (8 bits) : notion de qualit de service
Longueur totale (16 bits) : longueur du datagramme complet (en-ttes + donnes) : max 65 535 octets
Identification (16 bits) : valeur pour identifier les fragments d'un mme datagramme
Flags (3 bits) : pour contrler la fragmentation IP
o Bit 0 : rserv =>doit tre laiss 0
o Bit 1 : Accept Fragmentation (AF) =>0 si autorise
o Bit 2 : Don't Fragment (DF)=>0 quand il s'agit du dernier fragment
Offset de fragmentation (13 bits) : spcifie le dcalage du premier octet par rapport au datagramme complet.
Le dcalage du premier fragment vaut 0. Le maximum pour un datagramme est de 8192 fragments
Dure de vie / TTL (8 bits) : permet de limiter la dure de vie d'un paquet sur le rseau. Est dcrmente par
chaque nud de transit.
Protocole (8 bits) : indique le protocole de niveau suprieur qui est utilis (ex. : ICMP/IGMP/TCP/UDP)
Checksum d'en-tte (16 bits) : somme de contrle calcule sur l'en-tte uniquement. Doit tre recalcul
chaque modification du TTL ou du ToS
Adresse source (32 bits)
Adresse destination (32 bits)
Options (longueur variable) : rarement utilis L'en-tte, permettant d'identifier le protocole de niveau suprieur
n'est inclus que dans le premier fragment.
Pour tablir une connexion TCP, il y a un protocole de ngociation appel poigne de main TCP (handshake).
Celle-ci se droule en 3 phases :
1) La source met une requte d'tablissement de connexion : bit SYN 1 + numro de squence alatoire (ISN) ;
2) Si la destination accepte : bits SYN et ACK 1 + numro de squence propre + numro de squence de la source
augment de 1 ;
- 48 -
3) La source acquitte la rponse de la destination en positionnant le bit ACK 1, en incrmentant son numro de
squence originel et un numro d'acquittement gal au numro de squence de la destination augment de 1.
Les champs de TCP, comme ceux de IP, sont souvent utiliss par des pirates des fins intrusives. Voici un rappel
de ces champs :
Port source & port destination (16 bits) : dterminent le service requis
Numro de squence (32 bits) : numro du premier octet de donnes par rapport au dbut de la transmission,
sauf si SYN est marqu. Dans ce cas, numro de squence = ISN.
Accus de rception (32 bits) : Si ACK est marqu, ce champ contient le numro de squence du prochain
octet que le rcepteur s'attend recevoir
Header Length (4 bits) : taille de l'en-tte TCP en nombre de mots de 32 bits
Rserv (6 bits) : usage futur #toujours 0
Flags (6 bits) : utiliss pour contrle et gestion des connexions TCP
o URG : champ pointeur de donnes urgentes significatif
o ACK : champ accus de rception significatif
o PSH : fonction Push
o RST : rinitialisation de la connexion
o SYN : synchronisation des numros de squence
o FIN : fin de connexion
Fentre (16 bits) : nombre d'octets partir de la position marque dans l'accus de
rception que le rcepteur est capable de recevoir
Checksum (16 bits) : somme de contrle calcule sur le datagramme
Pointeur de donnes urgentes (16 bits) : spcifie la position d'une donne urgente (position par rapport au
numro de squence)
Options (variable) : doit tre un multiple de 8 bits =>remplissage (padding) ventuel
o Maximum Segment Size (MSS) : taille maximale des segments : envoye dans la requte de connexion
initiale
o Window Scale : permet de dfinir des tailles de fentre suprieures 64Ko
o Selective Acknowledgement (SACK) : acquittements slectifs
o NOP (No OPeration) : sparateur pour aligner le dbut d'une option sur le dbut d'un mot de 16 bits
Voici galement un rappel des champs du protocole UDP :
Port source (16 bits)
Port destinataire (16 bits)
Longueur (16 bits) : nombre d'octets du datagramme entier (y compris en-tte). Min = 8
Checksum (16 bits)
Le protocole ICMP est souvent utilis des fins malicieuses, car c'est un protocole utile pour des messages flash,
et il ne ncessite pas de connexion ni de port.
Les paquets ICMP sont encapsuls dans les paquets IP pour des raisons historiques.
Les champs ICMP sont les suivants :
Type (8 bits) : type de message

Code (8 bits) : prcise le message identifi, par rapport au type de message
- Type 0 (Echo reply) =>pas de code
- Type 3 (Destination Unreachable) =>0 = net unreachable, 1 = host unreachable, 2 = protocole
- Type 4 (Source Quench) : contrle de flux
- Type 5 (Redirect) =>Code 0 = network, 1 = host
- Type 8 (Echo request)
- Type 11 (Time exceeded) : dure de vie coule
- Type 13 (Timestamp) : marqueur temporel
- Type 14 (Timestamp reply ) : rponse au marqueur temporel
- Type 30 (Traceroute)
- 49 -
1 : Les request for comment (RFC, littralement demande de commentaires) sont une srie
de documents et normesconcernant l'Internet, commence en 1969. Peu de RFC sont des
standards, mais tous les standards de l'Internet sontenregistrs en tant que RFC.
2 : Un firewall, ou pare-feu est un dispositif logiciel ou matriel qui filtre le flux de donnes sur
un rseau informatique.Il est parfois appel coupe-feu.
3 : Un shellcode est une chane de caractres qui reprsente un code binaire excutable
capable de lancer un shell('/bin/sh' sous Unix ou command.com sous DOS et Microsoft
Windows par exemple). Un shellcode peut tre utilis parun cracker voulant avoir accs la
ligne de commande.
4 : RPC (Remote Procedure Call) est un protocole permettant de faire des appels de
procdures sur un ordinateur distant l'aide d'un serveur d'application. Ce protocole est utilis
dans le modle client-serveur et permet de grer les diffrents messages entre ces entits.
5 : Une zone dmilitarise (DMZ) est un sous-rseau isol par un pare-feu. Ce sousrseau contient des machines sesituant entre un rseau interne (LAN) et un rseau externe
(typiquement, Internet).
6 : Un senseur est une sonde, place sur le rseau, dont le rle est d'attraper le trafic circulant
sur celui-ci.
7 : Un sniffer est une machine coutant toutes les donnes circulant sur le rseau.
8 : Le Rseau priv virtuel (VPN ou Virtual Private Network, en anglais), est une extension des
rseaux locaux quiprocure une norme de scurit en tlcommunications.
9 : Le broadcast est un terme anglais (en franais on utilise le terme diffusion) dfinissant une
diffusion de donnes un ensemble d'ordinateurs connects un rseau informatique.
10 : Netfilter est le module qui fournit sous Linux depuis la version 2.4 les fonctions de parefeu, de partage de connexions internet (NAT) et d'historisation du trafic rseau. Iptables est la
commande Linux qui permet un administrateur de configurer Netfilter en mode Utilisateur.
11 : Un rootkit est un programme ou ensemble de programmes permettant un pirate de
maintenir - dans le temps -un accs frauduleux un systme informatique.
12 : Un Framework, ou cadre d'applications, est un ensemble de bibliothques et d'outils
permettant de faciliterl'utilisation groupe d'applications.
- 50 -

Utilisation Des IDS

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Utilisation Des IDS

Cargado por

Copyright:

Formatos disponibles

Les systmes de dtection d'intrusions

Par Jonathan Krier

Les systmes de dtection d'intrusions par Jonathan Krier

Les systmes de dtection d'intrusions par Jonathan Krier

IV-C - Comparatif Snort & Bro.............................................................................................................................29

Les systmes de dtection d'intrusions par Jonathan Krier

II - Les diffrents types d'attaques

II-A - Anatomie d'une attaque

Les systmes de dtection d'intrusions par Jonathan Krier

II-B - Les attaques rseau

II-B-1 - Les techniques de scan

Les systmes de dtection d'intrusions par Jonathan Krier

II-B-3 - ARP Spoofing (ou ARP Redirect)

II-B-4 - DNS Spoofing

Les systmes de dtection d'intrusions par Jonathan Krier

II-B-5 - Fragments attacks

II-B-6 - TCP Session Hijacking

II-C - Les attaques applicatives

II-C-1 - Les problmes de configuration

Les systmes de dtection d'intrusions par Jonathan Krier

II-C-2 - Les bogues

II-C-3 - Les buffer overflows

II-C-4 - Les scripts

II-C-5 - Les injections SQL

II-C-6 - Man in the middle

Les systmes de dtection d'intrusions par Jonathan Krier

II-D - Le Dni de service

Packet Fragment : utilise une mauvaise gestion de la dfragmentation au niveau ICMP.

Les systmes de dtection d'intrusions par Jonathan Krier

III - Dtection d'attaques : les IDS

III-A - Les diffrents types d'IDS

III-A-1 - Les systmes de dtection d'intrusions (IDS)

III-A-2 - Les systmes de dtection d'intrusions rseau (NIDS)

III-A-3 - Les systmes de dtection d'intrusions de type hte (HIDS)

Les systmes de dtection d'intrusions par Jonathan Krier

III-A-4 - Les systmes de dtection d'intrusions hybrides

III-A-5 - Les systmes de prvention d'intrusions (IPS)

Les systmes de dtection d'intrusions par Jonathan Krier

III-A-6 - Les systmes de prvention d'intrusions kernel (KIDS/KIPS)

III-A-7 - Les firewalls

III-A-8 - Les technologies complmentaires

Les systmes de dtection d'intrusions par Jonathan Krier

III-B - Les mthodes de dtection

III-B-1 - L'approche par scnario (misuse detection)

Les systmes de dtection d'intrusions par Jonathan Krier

Cette technique est galement utilise dans les antivirus.

III-B-2 - L'approche comportementale (Anomaly Detection)

Plusieurs approches peuvent tre utilises pour la mthode de dtection comportementale :

Les systmes de dtection d'intrusions par Jonathan Krier

l'utilisation de l'immunologie, c'est--dire construire un modle de comportement normal des services ;

III-B-3 - Les mthodes rpandues

III-C - Principes gnraux et installation technique

Les systmes de dtection d'intrusions par Jonathan Krier

III-C-1 - Dploiement d'un NIDS

Les systmes de dtection d'intrusions par Jonathan Krier

le systme d'exploitation du senseur devra tenu jour ;

III-C-2 - Problmes techniques

capture de la trame par l'interface en mode promiscuit (promiscous mode) ;

agrgation : rassembler les informations des diffrentes sondes ;

Les systmes de dtection d'intrusions par Jonathan Krier

III-C-3 - Complmentarit des IDS

gnrateur d'vnements (bote E) : envoie des vnements la bote A ;

Les systmes de dtection d'intrusions par Jonathan Krier