Les systmes de dtection d'intrusions

David Burgermeister, Jonathan Krier

Date de publication : 22/07/2006 Date de mise jour : 22/07/2006

Sites :

http://dbprog.developpez.com http://krierjon.developpez.com

Sommaire
I. II. Introduction _____________________________________________________5 Les diffrents types d'attaques _____________________________________6

1) 2)
i. ii. iii. iv. v. vi.

Anatomie dune attaque __________________________________ 6 Les attaques rseaux ____________________________________ 7

Les techniques de scan ________________________________________________ IP Spoofing _________________________________________________________ ARP Spoofing (ou ARP Redirect) _________________________________________ DNS Spoofing________________________________________________________ Fragments attacks ____________________________________________________ TCP Session Hijacking _________________________________________________ Les problmes de configuration _________________________________________ Les bugs___________________________________________________________ Les buffer overflows__________________________________________________ Les scripts _________________________________________________________ Les injections SQL ___________________________________________________ Man in the middle ___________________________________________________ 7 7 8 8 9 9

3)
i. ii. iii. iv. v. vi.

Les attaques applicatives ________________________________ 10

10 10 10 10 11 11

4) 5)
III.

Le Dni de service______________________________________ 11 Actuellement__________________________________________ 12

Dtection d'attaques : les IDS _____________________________________12

1)
i. ii. iii. iv. v. vi. vii. viii.

Les diffrents types d'IDS________________________________ 12

Les Les Les Les Les Les Les Les systmes de dtection dintrusions (IDS) ______________________________ systmes de dtection dintrusions rseaux (NIDS) ___________________ systmes de dtection dintrusions de type hte (HIDS) __________________ systmes de dtection dintrusions hybrides _________________________ systmes de prvention dintrusions (IPS) _____________________________ systmes de prvention dintrusions kernel (KIDS/KIPS) _______________ firewalls ________________________________________________________ technologies complmentaires ______________________________________ 13 13 13 13 14 15 15 15

2)

Les mthodes de dtection _______________________________ 16

i. Lapproche par scnario (misuse detection) _______________________________ 16 ii. Lapproche comportementale (Anomaly Detection)__________________________ 17 iii. Les mthodes rpandues ______________________________________________ 18

3)

Principes gnraux et installation technique _________________ 19

i. Dploiement dun NIDS _______________________________________________ 19 ii. Problmes techniques ________________________________________________ 21 iii. Complmentarit des IDS _____________________________________________ 22

4) 5)
i. ii. iii. iv.

Normalisation _________________________________________ 22 Techniques anti-IDS ____________________________________ 23

Dtecter un IDS _____________________________________________________ Dni de services contre un IDS _________________________________________ Techniques dinsertion ________________________________________________ Techniques dvasion _________________________________________________ 24 24 24 25

6)

Critres de tests d'un IDS ________________________________ 26

IV.

Mise en uvre d'IDS ____________________________________________27

1)
i. ii. iii. iv. v. vi.

NIDS / NIPS : Snort ____________________________________ 27

Description_________________________________________________________ Installation _________________________________________________________ Configuration _______________________________________________________ Excution __________________________________________________________ Cration de nouvelles rgles ___________________________________________ La console BASE ____________________________________________________ Description_________________________________________________________ Installation _________________________________________________________ Configuration _______________________________________________________ Excution __________________________________________________________ Cration de nouvelles rgles ___________________________________________ 27 28 29 29 30 31 33 34 34 34 35

2)
i. ii. iii. iv. v.

NIDS : Bro ____________________________________________ 33

3) 4) 5) 6)
i. ii. iii. iv.

Comparatif Snort & Bro__________________________________ 35 NIPS : SnortSam _______________________________________ 37 NIPS : Snort-Inline _____________________________________ 37 HIDS : OSSEC _________________________________________ 37
Description_________________________________________________________ Installation _________________________________________________________ Configuration _______________________________________________________ Cration de nouvelles rgles ___________________________________________ 37 38 38 38

7)

HIDS : SamHain _______________________________________ 39

i. Description_________________________________________________________ 39 ii. Installation _________________________________________________________ 39 iii. Configuration _______________________________________________________ 40

8)
i. ii.

HIDS : RkHunter _______________________________________ 40

Description_________________________________________________________ 40 Installation _________________________________________________________ 41

9) 10) 11)

Comparatif HIDS _______________________________________ 41 IDS Hybride : Prelude ___________________________________ 42 KIDS : LIDS ___________________________________________ 44

V.

Tests de dtection dattaques _______________________________________44

1) 2) 3) 4) 5) 6) 7) 8)

Exploit phpBB _________________________________________ 44 Scan TCP SYN _________________________________________ 45 Scan TCP Connect ______________________________________ 45 Scan Null _____________________________________________ 45 Remarques sur les scans ________________________________ 46 Exploit : Overflow HTTP dOracle 9i (win32) _________________ 46 Exploit : Overflow FTP dOracle 9i (win32)___________________ 46 Remarques sur les exploits Oracle 9i _______________________ 47

VI.

Algorithmique : le Pattern Matching ________________________________48

1) 2) 3) 4) 5) 6) 7) 8)
VII.

Introduction __________________________________________ 48 Algorithme naf (Brute Force Algorithm) ____________________ 49 L'algorithme de Morris - Pratt_____________________________ 49 L'algorithme de Knuth - Morris - Pratt ______________________ 51 Algorithme de Boyer - Moore _____________________________ 53 Algorithme de Aho - Corasick _____________________________ 55 Snort et le pattern matching______________________________ 57 Conclusion ___________________________________________ 58
Conclusion ____________________________________________________60

Annexe : Rappels essentiels concernant les protocoles _______________________ i

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 dune politique de scurit autour de ces systmes est donc primordiale. Outre la mise en place de pare-feux 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 lheure actuelle.

II.

Les diffrents types d'attaques

Linformatique 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. Cest pourquoi nous allons dans un premier temps analyser ce que nous appellerons lanatomie dune 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.

1)

Anatomie dune 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 dinformations par le biais doutils comme whois, Arin, DNS lookup. La collecte dinformations sur le systme cible peut seffectuer de plusieurs manires, comme par exemple un scan de ports grce au programme Nmap pour dterminer la version des logiciels utiliss, ou encore un scan de vulnrabilits laide 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 dun rseau. 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 alternative pour sinfiltrer dans un systme est dutiliser des failles applicatives que nous verrons ci-aprs. Persist : cration dun 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 dexploitation dans le but de planter le serveur.

Aprs ces cinq tapes, le pirate peut ventuellement tenter deffacer ses traces, bien que cela ne soit rarement utile. En effet, les administrateurs rseaux sont souvent surchargs de logs analyser. De plus, il est trs difficile de supprimer entirement des traces.

2)

Les attaques rseaux

Ce type dattaque se base principalement sur des failles lies aux protocoles ou leur implmentation. Les RFC1 ne sont parfois pas assez spcifiques, et un choix particulier dimplmentation dans les diffrents services ou clients peut entraner un problme de scurit. Observons quelques attaques bien connues.

i.

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 lavons vu, la premire phase des 5Ps dans le droulement dune 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. Sil 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 sagit dune amlioration du scan simple. Ce scan essaie galement de se connecter sur des ports donns, mais il ntablit pas compltement la connexion : pas de commande ACK (acquittement) aprs avoir reu laccord 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 laveugle : seffectue 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 den-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 : lutilitaire incontournable pour raliser des scans de ports se nomme Nmap.

ii.

IP Spoofing

But : usurper ladresse IP dune autre machine.

Les request for comment (RFC, littralement demande de commentaires) sont une srie de documents et normes concernant l'Internet, commence en 1969. Peu de RFC sont des standards, mais tous les standards de l'Internet sont enregistrs en tant que RFC.

Finalit : se faire passer pour une autre machine en truquant les paquets IP. Cette technique peut tre utile dans le cas dauthentifications 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 lon 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 ladresse 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 ladresse spoofe seront ainsi envoys aux routeurs contrls par le pirate et les rponses pourront tre galement reues par celui-ci.

iii.

ARP Spoofing (ou ARP Redirect)

But : rediriger le trafic dune 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 quil reoit vers le vritable destinataire, ainsi lutilisateur usurp ne se rendra compte de rien. La finalit est la mme que lIP 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 quil faut lui envoyer des trames ARP en lui indiquant que ladresse IP dune autre machine est la sienne. Les caches ARP tant rgulirement vids, il faudra veiller maintenir lusurpation.

iv.

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, lutilisateur 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 dune rponse dun serveur DNS contrl par le pirate un autre serveur DNS, lors de la demande de ladresse IP dun 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 dune requte pour obtenir ladresse IP partir dun nom, un numro didentification est plac dans la trame afin que le client et le serveur puissent identifier la requte. Lattaque consiste ici rcuprer ce numro didentification (en sniffant le 8

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.

v.

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 sinfiltrer dans un rseau pour effectuer des attaques ou rcuprer des informations confidentielles. Droulement : deux types dattaque 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 lattaque 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 lattaque. Cependant, lors de la dfragmentation, la demande de connexion est bien valide et lattaque a lieu. Tiny fragments : le but de lattaque 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 ladresse et le port de destination. Le deuxime paquet contient la demande effective de connexion TCP. Le premier paquet est accept par les filtres puisquil 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 lest aussi. Mais lors de la dfragmentation sur le systme dexploitation, la connexion stablit ! De nos jours, une grande majorit des firewalls2 sont capables de dtecter et stopper ce type dattaques.

vi.

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 lorsquil estime que lauthentification a pu se produire (dlai de n secondes par exemple), il dsynchronise la session entre lutilisateur et le serveur. Pour ce faire, il construit un paquet avec, comme adresse IP source, celle de la machine de lutilisateur 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.

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)

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.

i.

Les problmes de configuration

Il est trs rare que les administrateurs rseaux configurent correctement un programme. En gnral, ils se contentent dutiliser les configurations par dfaut. Celles-ci sont souvent non scurises afin de faciliter lexploitation du logiciel (ex : login/mdp par dfaut dun serveur de base de donnes). De plus, des erreurs peuvent apparatre lors de la configuration dun logiciel. Une mauvaise configuration dun serveur peut entraner laccs des fichiers importants, ou mettant en jeu lintgrit du systme dexploitation. Cest pourquoi il est important de bien lire les documentations fournies par les dveloppeurs afin de ne pas crer de failles.

ii.

Les bugs

Lis un problme dans le code source, ils peuvent amener lexploitation de failles. Il nest pas rare de voir lexploitation dune machine suite une simple erreur de programmation. On ne peut toutefois rien faire contre ce type de problmes, si ce nest attendre un correctif de la part du dveloppeur.

iii.

Les buffer overflows

Les buffer overflows, ou dpassement de la pile, sont une catgorie de bug particulire. Issus dune erreur de programmation, ils permettent lexploitation dun shellcode3 distance. Ce shellcode permettra une personne mal intentionne dexcuter des commandes sur le systme distant, pouvant aller jusqu sa destruction. Lerreur de programmation est souvent la mme : la taille dune entre nest pas vrifie et lente est directement copie dans un buffer dont la taille est infrieure la taille de lentre. On se retrouve donc en situation de dbordement, et lexploitant peut ainsi accder la mmoire.

iv.

Les scripts

Principalement web (ex : Perl, PHP, ASP), ils sexcutent sur un serveur et renvoie un rsultat au client. Cependant, lorsquils sont dynamiques (i.e. quils utilisent des entres saisies par un utilisateur), des failles peuvent apparatre si les entres ne sont pas correctement contrles. Lexemple classique est lexploitation de fichier distance, tel que laffichage du fichier mot de passe du systme en remontant larborescence depuis le rpertoire web.

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 par un cracker voulant avoir accs la ligne de commande.

10

v.

Les injections SQL

Tout comme les attaques de scripts, les injections SQL profitent de paramtres dentre non vrifis. Comme leur nom lindique, le but des injections SQL est dinjecter 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.

vi.

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. Il accdera ainsi toutes les communications et pourra en obtenir les informations sans que lutilisateur sen rende compte.

4)

Le Dni de service

Evoqu prcdemment, le dni de service est une attaque visant rendre indisponible un service. Ceci peut seffectuer de plusieurs manires : par le biais dune surcharge rseau, rendant ainsi la machine totalement injoignable ; ou bien de manire applicative en crashant lapplication distance. Lutilisation dun buffer overflow peut permettre de planter lapplication 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, etc) voire un systme complet. Voici quelques attaques rseaux connues permettant de rendre indisponible un service : SYN Flooding : exploite la connexion en 3 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 leffondrement du systme.

UDP Flooding : le trafic UDP est prioritaire sur TCP. Le but est donc denvoyer un grand nombre de paquets UDP, ce qui va occuper toute la bande passante et ainsi rendre indisponible 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 dattaque se basant sur la fragmentation des paquets peuvent aussi tre utilises pour outrepasser un filtre IP.

11

Smurfling : le pirate fait des requtes ICMP ECHO des adresses de broadcast en spoofant l'adresse source (en indiquant ladresse 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 dun nombre important de machines. Grce des failles (buffer overflows, failles RPC4, etc) 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 lordre dattaquer toutes les machines en mme temps, de manire ce que lattaque soit reproduite des milliers dexemplaires. Ainsi, une simple attaque comme un SYN Flooding pourra rendre une machine ou un rseau totalement inaccessible.

5)

Actuellement

La scurit contre les attaques distantes se renforce, notamment par le biais dquipements rseaux plus puissants (comme des firewalls plus intelligents), mais les attaques locales restent toutefois encore fort efficaces : lARP Spoofing, le vol de session, restent souvent possibles. Linformatique 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 savrer dangereux pour des applications largement rpandues. 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 davoir 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 appel IDS (Intrusion Detection Systems), les systmes de dtection dintrusions conviennent parfaitement pour raliser cette tche.

A lorigine, les premiers systmes de dtection dintrusions ont t initis par larme amricaine, puis par des entreprises. Plus tard, des projets open-source ont t lancs et certains furent couronns de succs, comme 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,

1)

Les diffrents types d'IDS

Comme nous lavons vu, les attaques utilises par les pirates sont trs varies. Certaines utilisent des failles rseaux et dautres des failles de programmation. Nous pouvons donc facilement comprendre que la dtection dintrusions doit se faire plusieurs niveaux.
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.

12

Ainsi, il existe diffrents types dIDS dont nous dtaillons ci-dessous les caractristiques principales.

i.

Les systmes de dtection dintrusions (IDS)

Dfinition : ensemble de composants logiciels et matriels dont la fonction principale est de dtecter et analyser toute tentative deffraction (volontaire ou non). Fonctions : dtection des techniques de sondage (balayages de ports, fingerprinting), des tentatives de compromission de systmes, dactivits suspectes internes, des activits virales ou encore audit des fichiers de journaux (logs). Remarque : utopiquement, il sagit dun systme capable de dtecter tout type dattaque.

Certains termes sont souvent employs quand on parle dIDS :

Faux positif : une alerte provenant dun IDS mais qui ne correspond pas une attaque relle. Faux ngatif : une intrusion relle qui na pas t dtecte par lIDS

ii.

Les systmes de dtection dintrusions rseaux (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 lanalyse et gnre des alertes si des paquets semblent dangereux. Les NIDS tant les IDS plus intressants et les plus utiles du fait de lomniprsence des rseaux dans notre vie quotidienne, ce document se concentrera essentiellement sur ce type dIDS.

iii. Les systmes de dtection dintrusions de type hte (HIDS)

Un HIDS se base sur une unique machine, nanalysant cette fois plus le trafic rseau mais lactivit se passant sur cette machine. Il analyse en temps rel les flux relatifs une machine ainsi que les journaux. Un HIDS a besoin dun systme sain pour vrifier lintgrit des donns. 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 Prevention System) qui sont fortement lis au noyau. Ces types dIDS sont dcrits un peu plus loin.

iv.

Les systmes de dtection dintrusions 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 quils sont capables de runir aussi bien des informations provenant dun systme HIDS quun NIDS.

13

Lexemple 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 dautres 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 linstallation de chacun.

v.

Les systmes de prvention dintrusions (IPS)

Dfinition : ensemble de composants logiciels et matriels dont la fonction principale est dempcher toute activit suspecte dtecte au sein dun 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 dintrusions existent : surveille l'excution des processus et host-based memory and process protection 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 quil bloque toute activit qui lui semble suspecte. Or, il est impossible dassurer une fiabilit 100% dans lidentification des attaques. Un IPS peut donc malencontreusement bloquer du trafic inoffensif ! Par exemple, un IPS peut dtecter une tentative de dni de service alors quil sagit simplement dune priode charge en trafic. Les faux positifs sont donc trs dangereux pour les IPS. Le deuxime inconvnient est quun pirate peut utiliser sa fonctionnalit de blocage pour mettre hors service un systme. Prenons lexemple dun individu mal intentionn qui attaque un systme protg par un IPS, tout en spoofant son adresse IP. Si ladresse IP spoofe est celle dun noeud important du rseau (routeur, service Web, ...), les consquences seront catastrophiques. Pour palier ce problme, de nombreux IPS disposent des white lists , cest--dire des listes dadresses rseaux quil ne faut en aucun cas bloquer. Et enfin, le troisime inconvnient et non le moindre : un IPS est peu discret. En effet, chaque blocage dattaque, il montre sa prsence. Cela peut paratre anodin, mais si un pirate remarque la prsence dun IPS, il tentera de trouver une faille dans celui-ci afin de rintgrer son attaque... mais cette fois en passant inaperu. 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 dune fonctionnalit de raction automatique certains types dattaques.

14

vi.

Les systmes de prvention dintrusions kernel (KIDS/KIPS)

Nous lvoquions prcdemment dans le cadre du HIDS, lutilisation dun dtecteur dintrusions au niveau noyau peut savrer parfois ncessaire pour scuriser une station. Prenons lexemple dun serveur web, sur lequel il serait dangereux quun accs en lecture/criture dans dautres rpertoires que celui consultable via http, soit autoris. En effet, cela pourrait nuire lintgrit 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 lexcution du code. Le KIPS peut galement interdire lOS dexcuter un appel systme qui ouvrirait un shell de commandes. Puisquun KIPS analyse les appels systmes, il ralentit lexcution. Cest 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.

vii. 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 laccs des flux. Ils travaillent en gnral au niveau des couches basses du modle OSI (jusquau niveau 4), ce qui est insuffisant pour stopper une intrusion. Par exemple, lors de lexploitation dune faille dun serveur Web, le flux HTTP sera autoris par le firewall puisquil nest pas capable de vrifier ce que contiennent les paquets. Il existe trois types de firewalls :

Les systmes filtrage de paquets sans tat : analyse les paquets les uns aprs les autres, de manire totalement indpendante. Les systmes maintien dtat (stateful) : vrifient que les paquets appartiennent une session rgulire. Ce type de firewall possde une table dtats 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 sintercale dans la session et analyse linformation afin de vrifier que les changes protocolaires sont conformes aux normes.

viii. Les technologies complmentaires

Les scanners de vulnrabilits : systmes dont la fonction est dnumrer les vulnrabilits prsentes sur un systme. Ces programmes utilisent une base de vulnrabilits connues (exemple : Nessus). Les systmes de leurre : le but est de ralentir la progression dun attaquant, en gnrant des fausses rponses telle que renvoyer une fausse bannire du serveur Web utilis. 15

Les systmes de leurre et dtude (Honeypots) : le pirate est galement leurr, mais en plus, toutes ses actions sont enregistres. Elles seront ensuite tudies afin de connatre les mcanismes dintrusion utiliss par le hacker. Il sera ainsi plus facile doffrir 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 dintrusion : linformation sensible est rpartie plusieurs endroits gographiques mais des copies de fragments sont archives sur diffrents sites pour assurer la disponibilit de linformation. Cependant, si un pirate arrive sintroduire sur le systme, il naura quune petite partie de linformation et celle-ci lui sera inutile.

2)

Les mthodes de dtection

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

i.

Lapproche par scnario (misuse detection)

Cette technique sappuie sur la connaissance des techniques utilises par les attaquants pour dduire des scnarios typiques. Elle ne tient pas compte des actions passes de lutilisateur et utilise des signatures dattaques (= ensemble de caractristiques permettant didentifier 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 doctets) au sein du flux de donnes. LIDS comporte une base de signatures o chaque signature contient les protocole et port utiliss par lattaque 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 le base de signatures. Un autre inconvnient est que les motifs sont en gnral fixes. Or une attaque nest pas toujours identique 100%. Le moindre octet diffrent par rapport la signature provoquera la non dtection de lattaque. Pour les IDS utilisant cette mthode, il est ncessaire dadapter 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 16

le nombre de fausses alertes et donc faciliter le travail des administrateurs rseaux qui analyseront les fichiers dalertes. Cette technique est galement utilise dans les anti-virus.

Recherche de motifs dynamiques Le principe de cette mthode est le mme que prcdemment mais les signatures des attaques voluent dynamiquement. LIDS est de ce fait dot de fonctionnalits dadaptation et dapprentissage. Analyse de protocoles Cette mthode se base sur une vrification de la conformit (par rapport aux RFC) des flux, ainsi que sur lobservation 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 nest pas toujours trs performante. Lanalyse protocolaire est souvent implmente par un ensemble de prprocesseurs, o chaque prprocesseur est charg danalyser un protocole particulier (FTP, HTTP, ICMP, ...). Du fait de la prsence de tous ces prprocesseurs, les performances dans un tel systme sen voient fortement dgrades. Lintrt fort de lanalyse protocolaire est quelle permet de dtecter des attaques inconnues, contrairement au pattern matching qui doit connatre lattaque pour pouvoir la dtecter. Analyse heuristique et dtection danomalies 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 dun port donn dpasse un seuil dans un intervalle de temps prdfini.

ii.

Lapproche comportementale (Anomaly Detection)

Cette technique consiste dtecter une intrusion en fonction du comportement pass de lutilisateur. 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 lutilisateur provoque une alerte. ncessite une priode de non fonctionnement pour mettre en uvre les mcanismes dauto-apprentissage : 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. ltablissement du profil doit tre souple afin quil ny ait pas trop de fausses alertes : le pirate peut discrtement intervenir pour modifier le profil de lutilisateur afin dobtenir 17

aprs plusieurs jours ou semaines, un profil qui lui permettra de mettre en place son attaque sans quelle ne soit dtecte.

Plusieurs approches peuvent tre utilises pour la mthode de dtection comportementale : Approche probabiliste Des probabilits sont tablies permettant de reprsenter une utilisation courante dune application ou dun protocole. Toute activit ne respectant pas le modle probabiliste provoquera la gnration dune alerte. Exemple : Avec le protocole HTTP, il y a une probabilit de 0.9 quune 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 lutilisateur : taux doccupation de la mmoire, utilisation des processeurs, valeur de la charge rseau, nombre daccs lIntranet par jour, vitesse de frappe au clavier, sites les plus visits, Cette mthode est trs difficile mettre en place. Elle nest actuellement prsente que dans le domaine de la recherche, o les chercheurs utilisent des rseaux neuronaux et le data mining pour tenter davoir des rsultats convaincants. Autres mthodes Dautres mthodes existent mais ne sont pas encore rpandues. Parmi celles-ci, nous pouvons noter : Lutilisation de limmunologie, cest--dire construire un modle de comportement normal des services. La prsentation dune activit habituelle sous forme de graphe.

iii. Les mthodes rpandues

En gnral, les IDS mlangent les diffrentes techniques de dtection par scnario en proposant du pattern matching, de lanalyse protocolaire et de la dtection danomalies. De nombreuses techniques et algorithmes sont utiliss dans la dtection dintrusions : Pattern Matching algorithmes de recherche de motifs (ex : Boyer-Moore) , algorithmes de comptage algorithmes gntiques conformit aux RFC mthodes heuristiques modles statistiques rseaux baysiens rseaux de neurones, systmes experts + data 18

Analyse Protocolaire Dtection danomalies Analyse statistique Analyse probabiliste

Autre analyse comportementale mining, immunologie, graphes, ...

Il est bien sr impossible de dtailler chacun des algorithmes mis en oeuvre dans les IDS. Nous avons cependant ddi le chapitre 6 aux algorithmes de pattern matching.

3)

Principes gnraux et installation technique

Jusqu' prsent, nous avons vu les types dIDS existants et les mthodes de dtection quils utilisent. Nous allons maintenant dtailler une tape importante dans la mise en place dun IDS : linstallation technique. Lors de la mise en place dun systme de dtection dintrusions au sein dun rseau, il est important de le dployer correctement dune part, mais aussi de comprendre son fonctionnement interne pour pouvoir le configurer efficacement. Toute erreur lors de linstallation dun IDS pourra le rendre inefficace ou inutilisable.

i.

Dploiement dun NIDS

Il faut tout dabord prendre conscience quun NIDS n'est pas suffisant pour assurer la scurit. En plus dinstaller 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 (DMZ5) chaque utilisateur doit tre averti de limportance de la scurit de ses mots de passe les fonctionnalits des services qui ne sont pas utilises doivent tre dsactives.

Lors du dploiement dun 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 senseur6 est trs important :

5 Une zone dmilitarise (DMZ) est un sous-rseau isol par un pare-feu. Ce sous-rseau contient des machines se situant 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 dattraper le trafic circulant sur celui-ci.

19

A 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. 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 dun 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, seul les flux accepts par le firewall sont analyss, ce qui rduit fortement la charge de la sonde IDS. Lors de linstallation dun NIDS, le choix matriel a galement une grande importance. Puisquune sonde NIDS doit tre capable danalyser le trafic rseau quelque soit le destinataire, elle devra recevoir elle-mme tous les paquets. Pour cela, le NIDS devra jouer le rle dun sniffer7, mais le matriel rseau pose parfois problme :

un switch simple (commutateur) : en utilisant un tel quipement, la conversation avec lIDS est impossible du fait de la nature dun switch : il commute les paquets directement au destinataire. Il est ds lors impossible dinstaller une sonde qui analysera le trafic global. un hub (concentrateur) la conversation avec lIDS 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 copie 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, cest le cas pour les VPN8), il est impossible pour lIDS de dcrypter ces flux. Il faut dans ce cas utiliser un proxy SSL comme illustr ci-dessous.

Nous savons donc maintenant que lemplacement 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 quelles gnrent ne sont pas scurises, un pirate pourrait trs bien rendre lIDS compltement inefficace.

7 8

Un sniffer est une machine coutant toutes les donnes circulant sur le rseau. Le Rseau priv virtuel (VPN ou Virtual Private Network, en anglais), est une extension des rseaux locaux qui procure une norme de scurit en tlcommunications.

20

Pour scuriser les sondes et les fichiers dalertes, 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 dexploitation du senseur devra tenu jour Un systme dauthentification 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 dutiliser 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 dinterface est communment appele stealth interface.

ii.

Problmes techniques

Le premier problme est de configurer correctement lIDS afin quil ninonde pas les rapports dalertes avec des faux positifs. La prsence de faux positifs semble inoffensive. Or, sils sont trop nombreux, les rapports dalertes seront longs analyser. Par consquent, les administrateurs passeront beaucoup de temps distinguer un faux positif dune vritable intrusion. Et de plus, en voyant toutes ces fausses alertes, ils auront tendance minimiser le risque dattaque. Bien sr, il faut galement veiller ce que laffinement 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 davoir un quipement rseau performant, lIDS doit utiliser des algorithmes adapts et optimiss. Afin de bien comprendre comment amliorer les performances dun NIDS, il faut comprendre les diffrentes tapes. Chaque paquet de donnes trait par lIDS va subir une suite de traitements :

capture de la trame par linterface 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 dexploitation filtrage ventuel applications de divers prprocesseurs en fonction du type de requte afin de contrer des techniques dvasion dattaques (voir plus loin) passage vers le moteur danalyse (protocole, pattern matching, statistique, )

Pour amliorer les performances de lIDS, 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 lanalyse des flux Web, une autre pour lanalyse des flux FTP et une analyse des requtes SQL.

21

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 fusion : fusionner en supprimant les doublons (mme attaque dtecte par plusieurs sondes) corrlation : dfinir un motif commun, c'est--dire interprter une suite dvnements 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, lutilisation dun scanner de vulnrabilits nest pas parfaite car il est difficile dchanger 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 quil ny a aucune interoprabilit entre les diffrents IDS du march, mis part la possibilit dexporter les informations dans des formats standard. Pourtant, des normes ont t tablies, comme nous allons le voir.

iii.

Complmentarit des IDS

Nous avons vu quil existe plusieurs types dIDS, dont leur rle est compltement diffrent. Plus exactement, leurs rles sont complmentaires. En effet, un NIDS ne fera quanalyser le trafic rseau. Mais complt par un HIDS, des intrusions non dtectes sur le rseau pourront ltre lorsquelles 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. Lidal 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 lexcution des programmes, ils sont souvent dlaisss ou configurs de faon nutiliser 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.

4)

Normalisation

Il y a quelques annes, un comit du DARPA a dfini 4 briques fonctionnelles pour dcrire larchitecture globale dun IDS :

Gnrateur dvnements (bote E) : envoie des vnements la bote A Analyseur dvnements (bote A) : produit des alertes Base de donnes vnementielle (bote D) Systme de rponse (bote R) : rponse en temps rel face aux attaques 22

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 na jamais t utilis mais il a inspir dautres comits. LIDWG (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. protocole IDXP (Intrusion Detection eXchange Protocol) : procdures de transport entre les entits de lIDS.

Selon lIDWG, un IDS est ensemble de plusieurs senseurs, analyseurs et managers :

Cest 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 lID de lanalyseur, le type dalerte, lemplacement (le nud rseau), le jour et lheure, ladresse, la classification de lattaque,

5)

Techniques anti-IDS

Comme tout systme informatique, ou presque, il existe des failles dans les IDS, ou plutt des techniques qui permettent doutrepasser ces systmes sans se faire reprer. Si un pirate dtecte la prsence dun IDS, il peut le dsactiver, ou mieux encore, gnrer de fausses attaques pendant quil commettra son forfait tranquillement. Il existe trois catgories dattaques contre les IDS :

Attaque par dni de service : rendre lIDS inoprant en le saturant. Attaque par insertion : le pirate, pour viter dtre repr, injecte des paquets de leurre qui seront ignors par le systme dexploitation de la cible mais pris en compte par lIDS : lIDS ne dtecte rien danormal, alors que sur le systme cible, lattaque a bien lieu puisque les paquets superflus sont ignors. Attaque par vasion : il sagit de la technique inverse lattaque par insertion. Ici, des donnes superflues sont ignores par lIDS mais prises en compte par le systme dexploitation. Nous dtaillons un peu plus loin quelques techniques dvasion Web. 23

i.

Dtecter un IDS

Comme nous lavons dj signal, il est trs dangereux que la prsence dun IDS soit remarque par un pirate. Car dans ce cas, il tentera dobtenir un maximum dinformations sur lIDS install (ex : la version utilise) pour pouvoir loutrepasser et attaquer sans se faire remarquer. Voici quelques techniques qui permettent de dtecter un IDS : Usurpation dadresse MAC : les NIDS mettent linterface de capture en mode promiscuit (promiscuous mode), il est donc possible de dtecter lIDS en envoyant par exemple un ICMP echo request la machine souponne dtre 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 linterface 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 ladresse tester, puis il mesure et note les temps de rponses. le pirate sature ensuite le rseau en broadcast9 dans le but de ralentir lIDS, qui recevra tous les paquets. Enfin, le pirate rmet la mme srie de pings en mesurant les nouveaux temps de rponse. Sils 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 didentifier le type dIPS. 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 quil y a un IDS.

ii.

Dni de services contre un IDS

Le but est de dsactiver lIDS en saturant ses ressources (ex : SYN Flood ou paquets fragments incomplets). LIDS sera ds lors incapable dexcuter sa fonctionnalit de dtection, et le pirate pourra raliser son attaque.

iii. Techniques dinsertion

Comme nous lavons vu, ces techniques consiste injecter des donnes supplmentaires de telle sorte que :

lIDS les estiment inoffensives la cible ne les dcode pas

Voici quelques mthodes permettant dutiliser des techniques dinsertion : en utilisant la fragmentation IP qui est gre de manire diffrente selon lOS 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 dexploitation utilis favorise les nouveaux.

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.

24

Pour utiliser le recouvrement de fragments (fragmentation overlap), il faut modifier artificiellement les champs longueur et dcalage (offset) des fragments IP. en utilisant lcrasement 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 lIDS tout en ralisant une attaque complte sur le systme dexploitation. 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 quavec la fragmentation IP + possibilit de timeout (Apache Linux : 5min dans tampon, IIS : 10 min). Lun des outils pour raliser ce genre dattaques se nomme fragroute. insrer un faux paquet avec checksum erron : certains IDS ne verront pas lattaque car peu dIDS 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, comme par exemple le TTL.

iv.

Techniques dvasion

Nous prsentons maintenant quelques techniques dvasion. Pour rappel, ces techniques ont pour but dinsrer des donnes qui seront ignores par lIDS mais qui ne gneront nullement lattaque.

Evasions HTTP : le principe est de modifier la syntaxe des URL mais sans changer la smantique. La premire personne avoir prsent ce genre dattaques avait pour pseudonyme Rain Forrest Puppy qui est lauteur du trs clbre outil Whisker, un scanner de vulnrabilits Web. Voici quelques exemples dvasion HTTP qui permettaient une poque doutrepasser les signatures de nombreux NIDS, tout en mettant des requtes HTTP valides. Bien sr, les NIDS prennent maintenant en compte ces techniques. faire une requte HEAD au lieu de GET. encoder les URL en hexadcimal, cette forme dencodage 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 auto-rfrences exemple : www.monsite.com/cgi/./././script

25

simuler la fin dune 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 nanalysaient quune partie de lURL 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, cest--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 dexcuter le shellcode.

De nombreux IDS sont capables de dtecter les tentatives de buffer overflow. La premire mthode est de surveiller la prsence importante dinstructions NOP. La deuxime est de dtecter la chane bin/sh qui est souvent prsente dans les shellcodes pour Unix. La troisime mthode est davoir 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, ) - 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 quil 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 lempcher au dernier moment de lancer un shellcode. Pour cela, seuls les KIPS (Kernel Intrusion Prevention System) se montrent adapts puisquils surveillent les appels systmes.

6)

Critres de tests d'un IDS

Lors de la mise en place dun IDS, il est ncessaire de prendre en considration plusieurs critres qui permettront de choisir au mieux lIDS.

26

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 bords. Ergonomie : on retrouve diffrents types dinterfaces dans les IDS. Tout dabord, 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, linterface 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.

1)
i.

NIDS / NIPS : Snort

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. 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. 27

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.

ii.

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 : o --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.

28

iii.

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 nallons 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.

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. 29

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/cvename.cgi?name=2001-0877][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=20010876][Xref => http://www.securityfocus.com/bid/3723]

v.

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 iptables10 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 ':'

10 Netfilter est le module qui fournit sous Linux depuis la version 2.4 les fonctions de pare-feu, 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.

30

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, ...) 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-application-attack (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.

vi.

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 31

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 nombres 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 dun 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. Exemple : output database: log, mysql, dbname=snort host=localhost user=snortusr password=pwd

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 :

32

2)

NIDS : Bro

i.

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.

33

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 3 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.

ii.

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 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.

iii.

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.

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 34

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

v.

Cration de nouvelles rgles

Tout comme le NIDS Snort, il est possible avec Bro de crer ses propres rgles de dtection ou dadapter 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 dattributs 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 den-tte : elles permettent de spcifier le protocole, les ports et les adresses source et de destination. Conditions de contenu : elles sont exprimes sous forme dexpressions rgulires pour reconnatre le contenu de certains types de requtes. Conditions de dpendance : elles permettent dexprimer des dpendances entre les signatures. Par exemple, une signature ne doit tre dtecte que si une autre signature la t. Conditions de contexte : elles permettent de rajouter lexcution de certaines fonctions, crites avec le langage de script de Bro, qui complmenteront les autres conditions.

Comme nous pouvons le voir, les conditions de dtection de signatures sont trs volues. Cependant, ce nest pas le cas des actions, cest--dire les oprations raliser quand une signature est dtecte. Il nexiste pour linstant quune seule action possible : event. Celle-ci va permettre de dcrire lventuelle attaque qui a t dtecte. Enfin, rappelons lexistence 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.

3)

Comparatif Snort & Bro

Nous venons de voir une description des fonctionnalits des deux NIDS les plus utiliss dans le mode Open-Source. Comme nous lavons remarqu, Snort et Bro ne partagent pas les mmes objectifs : lquipe de Snort veut un IDS performant, volutif et facile utiliser ; alors que lquipe Bro prfre favoriser linnovation et la recherche ainsi que profiter de ce projet pour tester des nouvelles mthodes danalyse.

Voyons cependant un rcapitulatif des grandes fonctionnalits quoffrent ces deux NIDS :

35

Snort : + + + + + + + Bro : + + + + + + + + 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 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 oeuvre 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

En analysant ces tableaux de fonctionnalits, nous pouvons remarquer que Bro est loin dtre 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 laccs lapplication par une documentation complte et des interfaces facilitant la gestion et lanalyse des logs.

36

Quant Snort, il a fait ses preuves. Mais la version Open-Source est encore rserve une certaine lite. Bien videmment, la version commerciale na srement pas les mmes faiblesses.

4)

NIPS : SnortSam

SnortSam est un plugin Open-Source et multi-plateforme 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.

5)

NIPS : Snort-Inline

A 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), SnortInline 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).

6)

HIDS : OSSEC

i.

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.

37

Capable d'analyser diffrents formats de journalisation tels que ceux dApache, 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 rootkit11 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 dtre excute lors de la dtection d'une anomalie.

ii.

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.

iii.

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. 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.

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.

Un rootkit est un programme ou ensemble de programmes permettant un pirate de maintenir - dans le temps un accs frauduleux un systme informatique.

11

38

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 prcdent a dj t leve. La rgle prcdente est spcifie l'aide de la balise if_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, comme par exemple l'url qui rfrence l'exploit connu. Plus d'informations sont disponibles dans la documentation sur le site officiel d'OSSEC.

7)

HIDS : SamHain

i.

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 dintrusions 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.

ii.

Installation

Linstallation 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/. 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 --

39

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 rcuprer 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, puisque 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

iii.

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

8)

HIDS : RkHunter

i.

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).

40

ii.

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 Port 2006: CB Rootkit Port 2128: MRK Port 14856: Optic Kit (Tux) Port 47107: T0rn Rootkit Port 60922: zaRwT.KiT * Interfaces Scanning for promiscuous interfaces

[ [ [ [ [ [

OK OK OK OK OK OK

] ] ] ] ] ]

[ OK ]

Security advisories * Check: Groups and Accounts Searching for /etc/passwd... Checking users with UID '0' (root)... * Check: SSH Searching for sshd_config...

[ Found ] [ OK ]

* 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

9)

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 dun HIDS en environnement de production. 41

Produit OSSEC Fonctionnalits

Architecture Rootkits Fichiers logs Fichiers configuration Interface Alertes
C-S / local Oui Contenu Perm., Taille, Prop., md5 X Log, Mail C-S / local Oui Contenu + Taille Perm., Taille, Prop., md5 Web Log, Mail, Syslog local Oui X X X Log, Mail

Samhain

Rkhunter

Tirons quelques conclusions de ce tableau comparatif. Dune 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 part ses fonctionnalits dalerte qui se rapprochent, voire quivalent, celles dautres HIDS.

Les deux systmes Ossec et Samhain sont fort proches. Ils possdent tous les deux la possibilit dtre mis en place de manire locale ou bien via une architecture client/serveur. Chacun dentre eux analyse le systme pour vrifier la non prsence de rootkits, inspecte les fichiers de logs pour y dtecter des activits anormales, et permet davertir ladministrateur 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, linstallation de Samhain nous a pos quelques problmes, et la configuration na pas t des plus simples. A linverse, le systme OSSEC est dot dun installeur qui prend les choses en main et nous demande uniquement les paramtres de configuration. Ainsi, malgr un nombre de fonctionnalits important, Samhain nest peut-tre pas aussi mature quil le laisse paratre.

10) IDS Hybride : Prelude

Comme nous lavons prcdemment constat, il existe peu doutils permettant dunifier lutilisation conjointe de diffrents IDS. Prelude est n de cette observation, il se veut tre un framework12 de centralisation et dunification des vnements permettant dacclrer lanalyse des diffrentes alertes. Prelude est un IDS Hybride, cest--dire quil combine les vnements dtects par toute sorte dapplications de scurit : NIDS, analyseur de logs (HIDS), anti-virus, etc Dans le but de raliser cette tche, Prelude sappuie 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.

Un Framework, ou cadre dapplications, est un ensemble de bibliothques et doutils permettant de faciliter lutilisation groupe dapplications.

12

42

Le framework se compose dune bibliothque de gnration de messages IDMEF, dun gestionnaire dvnements, dun analyseur de logs et dune console de visualisation des alertes. Linterface 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 lillustration 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. Lillustration suivante est un exemple des possibilits de la console de Prelude.

43

11) KIDS : LIDS

Le systme de dtection dintrusions LIDS est un patch appliquer au noyau Linux. Celui-ci permet daugmenter la scurit du noyau en implmentant un contrle daccs chaque ressource systme. Une fois activ, tout accs fichier, toute opration dadministration rseau, tout usage mmoire et toute lecture/criture sur disque deviennent impossibles mme pour lutilisateur root. Il est possible de spcifier la liste des fichiers accessibles par chaque programme indpendamment. Ce systme offre une scurit optimale, mais peut savrer compliqu mettre en place et configurer. Mal configur, ce systme peut paralyser une machine et la rendre totalement hors dusage. LIDS supporte les noyaux 2.6 et 2.4 lheure actuelle. Il est distribu gratuitement sous licence GPL.

V. Tests de dtection dattaques

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.

1)

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 :

Snort

L'attaque est dtecte. Cependant, l'alerte gnre ne concerne pas exactement l'attaque mais l'accs au fichier viewtopic.php. Or ce fichier est l'un des principaux de phpBB ! La signature de cette alarme va gnrer beaucoup trop de faux positifs, il est conseill de l'enlever. L'attaque n'est pas dtecte par dfaut, sauf si on convertit la mme signature que possde Snort, concernant l'accs au fichier viewtopic.php.

Bro

Conclusion : Aucun des deux IDS ne sest 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.

44

2)

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 : Snort Bro Le scan est dtect. L'alerte gnre signale galement les ports qui taient ouverts lors du scan. Le scan est dtect.

Conclusion : Ce genre de scan passait inaperu il y a quelques annes mais il est facilement dtectable de nos jours.

3)

Scan TCP Connect

Prsentation : 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 : Snort Bro Le scan est dtect. L'alerte gnre signale galement les ports qui taient ouverts lors du scan. Le scan est dtect.

Conclusion : Cette mthode de scan est la plus facile mettre en uvre, mais c'est galement la moins discrte.

4)

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.

45

Rsultats du test : Snort Bro Le scan est dtect. Le scan n'est pas dtect.

Conclusion : Ici, Snort se montre plus performant que Bro, qui ne voit rien d'anormal lors du scan.

5)

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.

6)

Exploit : Overflow HTTP dOracle 9i (win32)

Prsentation : La version 9i du clbre SGBD Oracle est victime dune faille dans son moteur XML, appel XDB. Nous avons test un exploit tirant profit cette faille avec le framework Metasploit. Lexploit consiste provoquer un stack overflow lors de lidentification HTTP au serveur de base de donnes. Rsultats du test :

Snort

Lattaque nest pas dtecte. Un processus peut tre lanc en mode SYSTEM sans que la moindre anomalie ne soit remarque ! Pas de version Windows de ce NIDS

Bro

Conclusion : Par dfaut, Snort nest pas capable de dtecter lattaque. Cependant, un bon administrateur rseaux pourra crer facilement une rgle gnrant une alerte lors de cette attaque. Pour cela, il devra analyser entirement lexploit, disponible sur Internet.

7)

Exploit : Overflow FTP dOracle 9i (win32)

Prsentation : Il sagit dune faille identique la prcdente, lexception que sa mise en uvre est ralise en utilisant le protocole FTP. Ici encore, nous avons utilis le framework Metasploit pour tester cette attaque.

46

Rsultats du test :

Snort Bro

Lattaque est dtecte. Pas de version Windows de ce NIDS

Screenshot de lattaque :

Conclusion : Snort dispose par dfaut de la signature pour cette attaque, permettant de la dtecter trs facilement.

8)

Remarques sur les exploits Oracle 9i

Comme nous lavons vu, une version par dfaut de Snort ne dtecte pas toujours les attaques contre le moteur XML dOracle 9i. Pour se protger de manire efficace, lentreprise Oracle prconise tout simplement de dsactiver les services HTTP et FTP.

47

VI.

Algorithmique : le Pattern Matching

Bien que la dtection dintrusions soit plutt lie aux rseaux et aux systmes dexploitation, lalgorithmique reste trs importante dans ce domaine. Il serait impossible dtre exhaustif pour les algorithmes mis en uvre dans les IDS. De ce fait, nous avons dcid de nous limiter aux techniques de pattern matching.

1)

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 x[i] et y[i] : le ime 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 et 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 : 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. 48

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.

2)

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.

3)

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. 49

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].

Supposons que la premire non correspondance ait lieu lors de la comparaison entre 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.

50

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". i x[i] mpNext[i] 0 A -1 1 C 0 2 A 0 3 B 1 4 A 0 5 C 1 6 A 2 7 3

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 Occurrence de x trouve la position j i i := mpNext[i] finsi fintantque

4)

L'algorithme de Knuth - Morris - Pratt

L'algorithme de Knuth-Morris-Pratt est une version optimise de l'algorithme de MorrisPratt. 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]. 51

Et supposons que la premire diffrence ait lieu lors de la comparaison de x[i] avec 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] 52

fintantque i := i + 1 j := j + 1 si (x[i] = x[j]) alors // Mme caractre : bord non disjoint 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 log (m) o est le nombre d'or : (1 + 51/2) / 2.

5)

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.

53

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.

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]. 54

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 lalphabet. 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 sous-linaire en moyenne.

6)

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. 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. 55

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 : fX(pa) si pa P; BordX(pa) sinon; et de plus, BordX(p) . a si p BordX(pa) = sinon

p.a=

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).

56

7)

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, tel 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. 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 multi-motifs trs rapide, bas sur l'algorithme de Aho-Corasick. Grce cela, Snort russit le test OSEC (http://osec.neohapsis.com) ralis 750Mbits/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 optimale. 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 "Banded-Row", 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". 57

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 implmentation. suivante montre l'espace mmoire ncessaire pour chaque

Nous constatons que le stockage "Banded-Row" ne ncessite qu'1/15me du stockage de la version standard et 1/7me de la version avec matrices compltes. L encore, cette implmentation se montre la plus optimise.

8)

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.

Algorithme

Caractristiques

Naf

- Pas de prtraitement - Fentre toujours dcale d'une position vers la droite - Phase de recherche en complexit temps O(mn)

58

Morris-Pratt

- Prtraitement de complexit temps et espace O(m) - Phase de recherche de complexit temps O(m + n) - Dlai born par m - Prtraitement de complexit temps et espace O(m) - Phase de recherche de complexit temps O(m + n) - Dlai born par log (m) - Comparaisons de droite gauche - Prtraitement de complexit temps et espace O(m + ) - Phase de recherche de complexit temps O(mn) - Recherche multi-motifs - Construction d'un automate dterministe - Phase de recherche de complexit temps O(m + n)

Knuth-Morris-Pratt

Boyer-Moore

Aho-Corasick

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.

59

VII. Conclusion
Bien que rpandus dans les organisations aujourdhui, les systmes de dtection dintrusions ne reprsentent quun maillon dune politique de scurit. En effet, mme si ceuxci permettent la dtection, parfois larrt, des intrusions, ils restent nanmoins vulnrables eux aussi faces aux attaques externes.

Cest pourquoi, pour une scurit optimale, ces outils doivent tre coupls dautres, comme lindispensable pare-feu. Mais ils doivent aussi tre mis jour, aussi bien le cur du logiciel comme la base de signatures, qui constitue la base dune dtection efficace. Il faut galement coupler les systmes de dtection entre eux : cest--dire ne pas hsiter placer des NIDS, HIDS et KIDS dans le mme rseau. Leurs rles sont diffrents, et chacun apporte ses fonctionnalits.

Lefficacit des dtections passe aussi par une bonne implmentation des algorithmes de recherche. Ltude que nous avons mene sur ces algorithmes nous a permis dobserver combien il est indispensable dutiliser des structures de donnes appropries lors dun dveloppement. Mais ce nest 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 lintrieur de lentreprise, et non de lextrieur. Des mots de passe simples, des droits daccs trop levs, des services mal configurs, ou encore des failles dans les logiciels restent la bte noire en matire de scurit.

60

Bibliographie

Exact String Matching Algorithms Christian Charras et Thierry Lecroq http://www-igm.univ-mlv.fr/~lecroq/string/ Elments d'algorithmique - Recherche de motifs D. Beauquier, J. Berstel, Ph. Chrtienne http://www-igm.univ-mlv.fr/~berstel/Elements/Elements.html 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 dintrusions 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 http://www.bro-ids.org LIDS Documentation LIDS Project http://www.lids.org Articles Wikipedia http://www.wikipedia.org

61

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.

Len-tte dun datagramme IP est compos : dune partie fixe de 20 octets dune partie longueur variable : les options

Il est utile de connatre les champs du protocole IP, qui sont utiliss des fins de reconnaissance ou dattaque par dni de services :

Version (4 bits) : version du protocole (IPv4, bientt IPv6) En-tte (4 bits) : spcifie la longueur de len-tte, en mots de 32bits. Minimum 5 car il y a 20 octets au minimum dans len-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 dun mme datagramme Flags (3 bits) : pour contrler la fragmentation IP o o o Bit 0 : rserv doit tre laiss 0 0 si autorise

Bit 1 : Accept Fragmentation (AF) Bit 2 : Dont Fragment (DF)

0 quand il sagit 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 dun 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 den-tte (16 bits) : somme de contrle calcule sur len-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

Len-tte, permettant didentifier le protocole de niveau suprieur nest 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 dtablissement 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 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 dacquittement 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 transmissions, 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 sattend recevoir Header Length (4 bits) : taille de len-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 o o o o o URG : champ pointeur de donnes urgentes significatif ACK : champ accus de rception significatif PSH : fonction Push RST : rinitialisation de la connexion SYN : synchronisation des numros de squence FIN : fin de connexion

Fentre (16 bits) : nombre doctets partir de la position marque dans laccus 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 dune donne urgente (position par rapport au numro de squence) Options (variable) : doit tre un multiple de 8 bits ventuel o remplissage (padding)

Maximum Segment Size (MSS) : taille maximale des segments : envoye dans la requte de connexion initiale Window Scale : permet de dfinir des tailles de fentre suprieurs 64Ko Selective Acknowledgement (SACK) : acquittements slectifs NOP (No OPeration) : sparateur pour aligner le dbut dune option sur le dbut dun mot de 16 bits

o o o

ii

Voici galement un rappel des champs du protocole UDP : Port source (16 bits) Port destinataire (16 bits) Longueur (16 bits) : nombre doctets du datagramme entier (y compris en-tte). Min = 8 Checksum (16 bits)

Le protocole ICMP est souvent utilis des fins malicieuses car cest 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 0 = net unreachable, 1 = host

Type 3 (Destination Unreachable) 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)

iii