D´
ETECTION D’INTRUSIONS ET ANALYSE
PASSIVE DE R´
ESEAUX
M´emoire pr´esent´e
`a la Facult´e des ´etudes sup´erieures de l’Universit´e Laval dans le cadre du programme de maˆıtrise en informatique
pour l’obtention du grade de Maˆıtre `es sciences
D´EPARTEMENT D’INFORMATIQUE ET DE G´ENIE LOGICIEL FACULT´E DES SCIENCES ET DE G´ENIE
UNIVERSIT´E LAVAL QU´EBEC
juin 2005
c
Dans ce travail, nous proposons un nouveau langage d´edi´e `a la d´etection d’intru-sions. Il s’agit d’un langage purement d´eclaratif, bas´e sur une logique temporelle lin´eaire pass´ee avec pr´edicats du premier ordre. Apr`es avoir effectu´e une revue de treize lan-gages de d´etection d’intrusions existant d´ej`a, nous donnons une liste de dix propri´et´es souhaitables pour un langage de d´etection d’intrusions. Contrairement au langage que nous proposons, aucun des langages ´etudi´es ne pr´esente `a la fois ces dix propri´et´es. En plus d’ˆetre suffisamment expressif pour r´epondre aux besoins identifi´es, il vient avec un algorithme de v´erification qui s’ex´ecute en temps lin´eaire avec la quantit´e d’information analys´ee et utilise une quantit´e born´ee d’espace m´emoire. Ces deux propri´et´es per-mettent de prot´eger le syst`eme de d´etection d’intrusions contre d’´eventuelles attaques d’inondation.
Je d´esire d’abord remercier ma m`ere, qui a su me donner le goˆut des ´etudes, ainsi que mon p`ere, qui m’a appris l’importance de l’int´egrit´e et de la transparence. Je les remercie tous les deux pour le support et les encouragements qu’ils m’ont donn´e tout au long de mon cheminement, autant personnel qu’acad´emique.
Je remercie aussi mon directeur de recherches, le professeur B´echir Ktari, pour avoir accept´e de me diriger dans un domaine aussi stimulant, et pour la confiance qu’il m’a montr´ee tout au long de ces deux ann´ees de travail. J’adresse aussi mes remerciements `a Fr´ed´eric Massicotte, ami et collaborateur au Centre de Recherches sur les Communi-cations, qui a su `a plusieurs occasions me donner des critiques constructives sur mon travail. Je le remercie aussi pour son sens aigu du bien-ˆetre d’autrui, qu’il a su en partie me communiquer. Je tiens aussi `a exprimer ma reconnaissance envers les professeurs Jos´ee Desharnais et Mohamed Mejri qui ont accept´e d’´evaluer ce m´emoire. Je remer-cie le personnel administratif du d´epartement d’informatique, et plus particuli`erement Lynda Goulet, pour sa bonne humeur et les nombreux services qu’elle m’a rendus.
Je remercie le Centre de Recherches sur les Communications, pour son support mat´eriel et financier, le Gouvernement Fran¸cais, pour m’avoir accueilli et avoir financ´e en partie mes recherches, de mˆeme que les professeurs Andr´e-Luc Beylot, Marc Boyer et J´erˆome Ermont, pour leur chaleureux accueil `a l’ENSEEIHT, `a Toulouse. Je remercie le Minist`ere des Relations Internationales du Qu´ebec, pour avoir rendu possible cet ´echange avec l’ENSEEIHT.
Merci `a Catherine et aux colocs du 22A, pour leur pr´esence chaleureuse et les nom-breuses soir´ees que nous avons pass´ees ensemble. Merci `a Alexandre Lacasse, pour son agr´eable compagnie au cours des deux voyages que nous avons faits en France, de mˆeme que pour ses commentaires encourageants et constructifs. Finalement, je remercie toutes celles et ceux de mes amies et amis qui m’ont encourag´e et support´e dans mes projets.
Imagination is more important than knowledge.
R´esum´e ii
Avant-propos iii
Table des mati`eres v
Liste des tableaux viii
Table des figures x
Introduction 1
1 Syst`emes de d´etection d’intrusions 5
1.1 Langages sp´ecifiques au domaine . . . 7
1.1.1 Panoptis . . . 8 1.1.2 Snort . . . 11 1.1.3 NeVO . . . 15 1.2 Langages imp´eratifs . . . 18 1.2.1 ASAX . . . 19 1.2.2 BRO . . . 22 1.3 Syst`emes de transitions . . . 25 1.3.1 STAT . . . 26 1.3.2 IDIOT . . . 30 1.3.3 BSML . . . 32 1.4 Syst`emes experts . . . 35 1.4.1 P-BEST . . . 36 1.4.2 LAMBDA . . . 38 1.5 Logiques temporelles . . . 41 1.5.1 LogWeaver . . . 42 1.5.2 Monid . . . 44 1.5.3 Chronicles . . . 46 1.6 Conclusion . . . 51
2.1 Logiques temporelles . . . 58
2.1.1 Logique temporelle lin´eaire . . . 58
2.1.2 Logique temporelle lin´eaire pass´ee . . . 60
2.1.3 Logique temporelle lin´eaire avec pass´e oubliable . . . 63
2.1.4 µ-calcul lin´eaire . . . . 65
2.2 Logiques temporis´ees . . . 67
2.2.1 Logique temporelle temporis´ee . . . 67
2.2.2 Logique temporelle m´etrique . . . 70
2.2.3 TRIO . . . 71
2.3 Conclusion . . . 72
3 D´etection d’intrusions et analyse passive 74 3.1 Architecture du syst`eme . . . 76
3.2 Langage . . . 77
3.3 Sc´enarios d’attaques complexes . . . 78
3.4 Acquisition passive d’information . . . 80
3.4.1 Ports TCP ouverts et sessions actives . . . 80
3.4.2 Ports TCP ferm´es . . . 82
3.4.3 Sessions ferm´ees et balayage FIN . . . 82
3.4.4 Vuln´erabilit´es et syst`emes d’exploitation . . . 83
3.4.5 Adresses du routeur . . . 84
3.4.6 Inf´erence de nouvelles connaissances . . . 85
3.5 Pr´esentation formelle du langage . . . 86
3.5.1 Mod`ele . . . 86
3.5.2 Syntaxe . . . 87
3.5.3 S´emantique . . . 89
3.5.4 Algorithme . . . 90
3.6 Conclusion . . . 95
4 Logique d’acquisition de connaissances 97 4.1 Un paradigme pass´e . . . 98 4.1.1 Mod`ele . . . 99 4.1.2 Syntaxe . . . 99 4.1.3 S´emantique . . . .100 4.2 Unification . . . 102 4.2.1 Mod`ele . . . .103 4.2.2 Syntaxe . . . .103 4.2.3 S´emantique . . . .106 4.3 R´ecursivit´e . . . 112 4.3.1 Approximants . . . .112
4.3.2 Tableaux . . . .113
4.4 Algorithmes . . . 114
4.4.1 Cas propositionnel . . . .115
4.4.2 Cas du premier ordre . . . .118
4.5 Conclusion . . . 129
5 Travaux futurs 132 5.1 Satisfiabilit´e . . . 132
5.2 Filtrage dynamique et s´emantique de symptˆome . . . 134
5.3 Synth`ese de contrˆoleur . . . 136
Conclusion 142
1.1 Algorithme d’apprentissage et de v´erification de Panoptis. . . 9
1.2 Syntaxe abstraite de RUSSEL. . . 20
1.3 Syntaxe des patrons dans BSML. . . 33
1.4 Syntaxe du calcul d’´ev´enements utilis´e dans LAMBDA. . . 38
1.5 Syntaxe d’un sc´enario d’attaque LAMBDA. . . 39
1.6 Syntaxe de la premi`ere logique de LogWeaver. . . 42
1.7 Syntaxe des sp´ecifications Eagle. . . 45
1.8 Pr´edicats de r´eification de Chronicles. . . 48
1.9 Dix propri´et´es souhaitables d’un IDS. . . 52
1.10 Tableau r´ecapitulatif des IDS. . . 53
2.1 Familles de logiques temporelles et leur mod`ele. . . 57
2.2 Syntaxe de LTL. . . 58
2.3 S´emantique de LTL. . . 59
2.4 Op´erateurs d´efinis de LTL. . . 59
2.5 Syntaxe de P-LTL. . . 60
2.6 S´emantique des op´erateurs particuliers `a P-LTL. . . 61
2.7 Op´erateurs d´efinis de P-LTL. . . 61
2.8 Syntaxe de N-LTL. . . 63
2.9 S´emantique de l’op´erateur particulier `a N-LTL. . . 64
2.10 Syntaxe du µ-calcul lin´eaire. . . . 65
2.11 S´emantique de l’op´erateur particulier au µ-calcul lin´eaire. . . . 65
2.12 Op´erateurs d´efinis du µ-calcul lin´eaire. . . . 66
2.13 Syntaxe de T-LTL. . . 68
2.14 S´emantique des op´erateurs particuliers `a T-LTL. . . 69
2.15 Un op´erateur d´efini de T-LTL. . . 69
2.16 Syntaxe de MTL. . . 70
2.17 S´emantique des op´erateurs particuliers `a MTL. . . 70
2.18 Syntaxe de TRIO. . . 71
2.19 S´emantique de l’op´erateur particulier `a TRIO. . . 71
3.1 Syntaxe du langage de signatures. . . 77
3.2 Syntaxe. . . 88
3.3 S´emantique. . . 89
3.4 Syntaxe du sous-ensemble associ´e au langage de signatures. . . 90
3.5 Algorithme de v´erification. . . 92
4.1 Syntaxe pour le cas propositionnel. . . 99
4.2 S´emantique pour le cas propositionnel. . . 100
4.3 Syntaxe pour le cas du premier ordre. . . 103
4.4 S´emantique op´erationnelle pour le cas du premier ordre. . . 106
4.5 Approximants. . . 113
4.6 Approximants avec intervalles. . . 114
4.7 Algorithme de v´erification pour le cas propositionel. . . 116
4.8 Algorithme de v´erification pour le cas du premier ordre. . . 120
4.9 S´emantique d´enotationnelle pour le cas du premier ordre. . . 121
5.1 Syst`eme de preuves `a base de tableaux. . . 134
5.2 S´emantique de symptˆome. . . 135
5.3 Syntaxe de l’alg`ebre des automates. . . 137
5.4 S´emantique de l’alg`ebre des automates. . . 137
1.1 Exemple de fichier de configuration de Panoptis. . . 8
1.2 Exemple de fichier de planification de tˆaches de Panoptis. . . 9
1.3 Exemple de fichier de sortie de Panoptis. . . 9
1.4 Structure de Snort. . . 12
1.5 Exemple de signature Snort. . . 13
1.6 Exemple d’utilisation du module de r´eaction. . . 14
1.7 Exemple d’utilisation du module flowbits. . . 14
1.8 Exemple de signature NeVO. . . 17
1.9 D´etection d’une p´en´etration externe dans ASAX. . . 21
1.10 Structure de Bro. . . 22
1.11 Exemple de script Bro. . . 23
1.12 Session `a demi ouverte dans NetSTAT. . . 28
1.13 Session `a demi ouverte dans l’outil STATed. . . 29
1.14 Mod´elisation d’un r´eseau avec NetSTAT. . . 29
1.15 Session TCP dans IDIOT. . . 31
1.16 Attaque TCP SYN-Flood dans BSML. . . 34
1.17 Exemple de r`egle d’inf´erence dans P-BEST. . . 37
1.18 Mod´elisation du sc´enario d’acc`es ill´egal `a un fichier avec LAMBDA. . . . 40
1.19 Exemple de sp´ecification Eagle. . . 45
1.20 Exemple de chronique. . . 48
2.1 Exemples de programmes. . . 60
3.1 Architecture du syst`eme d´evelopp´ee (`a droite), et celle de Snort (`a gauche). 76 3.2 Balayage SYN. . . 79
3.3 Poign´ee de main TCP. . . 81
3.4 Ports TCP ferm´es. . . 81
3.5 Fermeture d’une session TCP. . . 81
3.6 D´etection d’un syst`eme d’exploitation FreeBSD 3.0 `a 4.3. . . 83
3.7 R`egle Snort num´ero 343. . . 84
3.8 R´eduction des faux-positifs `a l’aide de la d´etection de vuln´erabilit´es. . . . 84
3.10 Inf´erence de nouvelles connaissances. . . 85
3.11 Exemple de trace. . . 87
3.12 Formule repr´esentant une poign´ee de main TCP. . . 88
3.13 Sp´ecification associ´ee au sc´enario d’une poign´ee de main TCP. . . 91
3.14 Exemple de trace d’ex´ecution de l’algorithme. . . 93
4.1 Attaque dans le contexte d’une session TCP active. . . 99
4.2 Exemple de trace pour le cas propositionnel. . . 101
4.3 Exemple de relations de satisfaction pour le cas propositionnel. . . 101
4.4 Exemple de trace du premier ordre. . . 102
4.5 Suivi des sessions TCP. . . 105
4.6 Exemple de relations de satisfaction pour le cas du premier ordre. . . 107
4.7 Utilisation des approximants. . . 113
4.8 Utilisation des approximants avec intervalles. . . 114
4.9 Balayage de ports TCP. . . 115
5.1 Exemples de contradictions. . . 133
5.2 Exemple de conflit. . . 136
5.3 Automate TCP. . . 138
5.4 Contrˆoleur pour l’automate TCP relativement `a ¬(rst ∧ [synack, ack]). . 138
Contexte
La d´etection d’intrusions est un probl`eme inh´erent `a la nature abstraite d’un r´eseau informatique. Il est plutˆot rare que l’on puisse dire, par un simple coup d’oeil aux ´equipements informatiques, que ceux-ci ont ´et´e ou sont pr´esentement utilis´es d’une fa¸con non-souhaitable. Pour le savoir, il faut ´etudier attentivement des quantit´es la plupart du temps astronomiques de fichiers d’audit et faire preuve d’une patience et d’une capacit´e d’analyse hors du commun. Afin de nous all´eger cette tˆache ardue, les informaticiens se sont mis `a d´evelopper des outils logiciels automatisant une partie du travail. Ils les ont appel´es syst`emes de d´etection d’intrusions.
Les syst`emes de d´etection d’intrusions sont g´en´eralement class´es en deux cat´egories : les d´etecteurs d’anomalies et les syst`emes `a base de sc´enarios. Les d´etecteurs d’anoma-lies fonctionnent g´en´eralement en deux phases : une phase d’apprentissage et une phase de d´etection. Au cours de la phase d’apprentissage, le syst`eme apprend `a reconnaˆıtre ce qu’est un comportement normal, et au cours de la phase de d´etection, il identifie les comportements anormaux. Les syst`emes pour lesquels la phase d’apprentissage continue apr`es le d´ebut de la phase de reconnaissance sont dits adaptatifs. L’objectif des syst`emes adaptatifs est de tenir compte de la nature changeante des r´eseaux informatiques. Les syst`emes `a base de sc´enarios n’ont pas de phase d’apprentissage. Ils viennent avec une base de sc´enarios d’attaque pr´ed´efinis qu’ils doivent reconnaˆıtre. L’avantage des d´etec-teurs d’anomalies est donc de pouvoir d´etecter des sc´enarios d’attaque insoup¸conn´es, au risque de g´en´erer des faux-positifs (fausses alarmes), alors que celui des syst`emes `a base de sc´enarios est de g´en´erer moins de faux-positifs, au risque de laisser passer des attaques encore inconnues. Dans ce cas, on parle de faux-n´egatifs. Le pr´esent travail s’int´eresse surtout aux syst`emes `a base de sc´enarios.
Une autre fa¸con de classer les syst`emes de d´etection d’intrusions est selon le niveau auquel ils interviennent : hˆote ou r´eseau. Au niveau hˆote, les fichiers d’audit analys´es
sont des fichiers syst`emes : utilisation du processeur, du syst`eme de fichiers, du r´eseau, traces d’ex´ecution de programmes, etc., alors qu’au niveau r´eseau, les fichiers d’audit utilis´es sont des traces de trafic. Une trace de trafic est une copie de tout le trafic ayant circul´e `a un endroit donn´e d’un r´eseau informatique. Il s’agit en fin de compte d’un cas particulier de fichier d’audit, et c’est pourquoi certains syst`emes de d´etection pr´esentent une approche g´en´erale permettant de regrouper les deux cas de cette classification.
Plusieurs paradigmes, auxquels nous reviendrons, ont ´et´e propos´es pour les lan-gages de signatures des syst`emes de d´etection d’intrusions `a base de sc´enarios. Parmi ceux-ci, se trouvent ceux bas´es sur des logiques temporelles. Les logiques temporelles, en m´ethodes formelles, ont ´et´e utilis´ees pour s’attaquer `a trois cat´egories de probl`emes :
V´erification Etant donn´e un programme, d´ecider, avant mˆeme de l’ex´ecuter, si toutes´ ses ex´ecutions respecteront une propri´et´e donn´ee.
Synth`ese Etant donn´ee une propri´et´e, g´en´erer un programme tel que toutes ses ex´e-´ cutions respectent cette propri´et´e.
Validation Etant donn´ee une ex´ecution d’un programme, d´ecider si cette ex´ecution´ respecte une propri´et´e donn´ee.
Le pr´esent travail s’inscrit donc dans un contexte de validation. Dans notre cas, le programme `a valider sera le r´eseau, et son ex´ecution sera mat´erialis´ee par les diff´erents fichiers d’audit mis `a notre disposition. Bien que nous nous int´eressions particuli`erement aux traces de trafic, la m´ethode que nous proposons s’adapte aussi bien aux autres fichiers d’audit. Il convient de noter, avant d’aller plus loin, que la d´etection d’intrusions a ceci de particulier que les ex´ecutions auxquelles on s’int´eresse sont de longueur infinie. Les m´ethodes propos´ees pour des ex´ecutions finies de programmes ne sauraient donc s’appliquer ici.
Objectifs et m´
ethodologie
Nous nous sommes donn´e comme mandat de d´evelopper un langage de d´etection d’intrusions qui soit bas´e sur un paradigme purement d´eclaratif. Pour ce faire, nous avons d’abord dˆu effectuer une revue des langages de d´etection d’intrusions existant d´ej`a. Bien que plusieurs d’entre eux aient la pr´etention d’ˆetre d´eclaratifs, il s’est av´er´e que le bien fond´e de cette affirmation ´etait dans la plupart des cas discutable. Ceux ´etant le plus pr`es de r´epondre `a ce crit`ere ´etant ceux bas´es sur un paradigme de logique temporelle, nous avons privil´egi´e cette voie pour la poursuite de nos travaux.
celles-ci pouvaient ˆetre utilis´ees pour r´epondre `a nos besoins. Un de ces besoins ´etait d’acqu´erir passivement de l’information sur un r´eseau informatique, de fa¸con `a faire une d´etection d’intrusions plus accrue. En effet, un reproche ayant souvent ´et´e fait aux sys-t`emes de d´etection d’intrusions est de ne pas tenir compte du contexte avant de signaler des alarmes. Cette sauvegarde du contexte ne saurait cependant ˆetre faite sans un coˆut additionnel, le pire cas, tout `a fait d´eraisonnable, constituant la sauvegarde compl`ete de la trace de trafic. Au mieux, on ne sauvegarde que l’information n´ecessaire, pas un bit de plus. La capacit´e `a traiter un fichier d’audit enregistrement par enregistrement sans revenir en arri`ere est ce que nous appellerons traitement en ligne. Les trois objectifs principaux de notre travail sont donc :
1. Paradigme d´eclaratif,
2. acquisition passive d’information, 3. et traitement en ligne.
Nous proposons deux approches pour s’attaquer `a ces probl`emes. La premi`ere est une approche hybride o`u la s´eparation entre l’information acquise et les sc´enarios `a reconnaˆıtre est claire, tant au niveau du langage que du logiciel d´evelopp´e, et la seconde approche permet d’uniformiser l’acquisition d’information et la d´efinition de sc´enarios `a reconnaˆıtre. Dans le premier cas, le langage utilis´e pour d´ecrire les sc´enarios est bas´e sur une logique temporelle avec op´erateurs futurs, et dans le second cas, il est bas´e sur une logique temporelle avec op´erateurs pass´es.
Organisation
La premi`ere partie de ce m´emoire est une revue de litt´erature en deux volets. Au chapitre1, nous dressons un ´etat de l’art d´etaill´e des langages de signatures utilis´es par treize syst`emes de d´etection d’intrusions. Nous proposons une taxonomie divisant ces langages en cinq cat´egories, selon les paradigmes utilis´es. `A la fin de ce chapitre, nous dressons une liste de dix propri´et´es identifi´ees comme souhaitables pour un langage de d´etection d’intrusions. Au chapitre 2, nous pr´esentons les logiques temporelles ayant le plus influenc´e notre travail.
La seconde partie de ce m´emoire pr´esente le travail effectu´e. Au chapitre 3, nous d´ecrivons un outil d’acquisition passive d’information et de d´etection d’intrusions que nous avons d´evelopp´e. Cet outil utilise un langage de signatures qui permet de
com-biner et d’effectuer les deux tˆaches dans un paradigme uniforme. Au chapitre 4, nous pr´esentons un autre langage, d´evelopp´e en vue de combler les lacunes identifi´ees avec le premier. Entre autres, ce langage a la propri´et´e d’ˆetre purement d´eclaratif. Pour cha-cun de ces deux langages, nous pr´esentons les algorithmes de v´erification `a utiliser et donnons les preuves de compl´etude et de coh´erence.
La troisi`eme partie constitue la conclusion. Au chapitre 5, nous donnons quelques id´ees pour la continuation des travaux de recherche effectu´es dans le cadre de cette maˆıtrise. Nous dressons un bilan des travaux effectu´es au dernier chapitre.
Syst`
emes de d´
etection d’intrusions
Un syst`eme de d´etection d’intrusions (ou IDS pour Intrusion Detection System) est une composante logicielle responsable d’identifier une utilisation non-d´esirable d’une ressource informatique. On peut classer les IDS selon plusieurs crit`eres. Les crit`eres les plus g´en´eralement rencontr´es sont le type de sonde (r´eseau ou hˆote) et le type d’algorithme (statistique ou `a base de signatures).
Les syst`emes bas´es sur des m´ethodes statistiques, aussi appel´es d´etecteurs d’anoma-lies, pr´esentent l’avantage de pouvoir d´ecouvrir des attaques encore non-r´epertori´ees. Ils fonctionnent g´en´eralement en deux phases : une phase d’apprentissage et une phase de d´etection proprement dite. Pendant la phase d’apprentissage, le syst`eme dresse un profil de ce qui sera par la suite consid´er´e comme un comportement normal. La phase de reconnaissance, quand `a elle, consistera `a d´etecter des d´eviations du comportement normal. Normalement, la phase d’apprentissage continue pendant la phase de recon-naissance. Cette strat´egie permet de faire face `a la nature changeante du comportement des utilisateurs et ainsi de s’adapter au changement. L’hypoth`ese derri`ere cette fa¸con de faire est que le comportement normal d’un utilisateur change de fa¸con graduelle et qu’une utilisation non-d´esir´ee du r´eseau entraˆınera un changement brusque dans le comportement. Cette hypoth`ese entraˆıne `a la fois des faux-positifs (fausse alarme) et des faux-n´egatifs (attaque non-d´etect´ee). Les faux positifs surviennent lorsque les uti-lisateurs changent leur comportement de fa¸con brusque, par exemple en installant un nouveau logiciel. Les faux n´egatifs, quand `a eux, surviennent lorsqu’un utilisateur mal-veillant au courant de la strat´egie de d´etection change son comportement petit `a petit de fa¸con `a exploiter la capacit´e d’adaptation du syst`eme.
Les IDS fonctionnant `a base de signatures, quand `a eux, engendrent moins de faux-positifs car on leur sp´ecifie exactement ce qu’ils doivent d´etecter. Cependant, comme
on doit constamment tenir `a jour leur base de signatures, le risque de faux-n´egatifs est plus ´elev´e. Le mod`ele de syst`eme de d´etection d’intrusions `a base de signatures le plus simple que nous puissions imaginer est celui g´en´eralement utilis´e dans le domaine des anti-virus : celui du patron de bits. L’hypoth`ese menant `a cette m´ethode de travail est qu’un comportement non-d´esirable peut ˆetre d´etect´e `a partir d’un petit nombre de bits physiquement situ´es `a proximit´e les uns des autres. Dans le cas des anti-virus, il s’agit g´en´eralement des premiers bits du fichier, alors que dans les IDS r´eseaux tels que Snort [1], il peut s’agir de quelques bits bien cibl´es d’un seul paquet. Bien que na¨ıve en apparence, la strat´egie du patron de bits a men´e jusqu’`a date `a de tr`es bons r´esultats, et ce pour deux raisons : premi`erement, la complexit´e algorithmique li´ee `a la v´erification des signatures est des plus avantageuses (constante en m´emoire et lin´eaire en temps) ; deuxi`emement, la simplicit´e du langage de signature encourage la communaut´e d’utilisateurs `a participer `a l’enrichissement de la base de donn´ees de signatures.
Les IDS fonctionnant `a base de patrons de bits comportent cependant des faiblesses au niveau de l’expressivit´e des signatures qui peuvent mener autant `a des faux-positifs qu’`a des faux-n´egatifs. C’est pourquoi la communaut´e scientifique persiste `a mettre tant d’efforts dans le d´eveloppement d’IDS pouvant d´etecter des patrons d’´ev´enements s´epar´es dans le temps. Les signatures de ces syst`emes permettent de prendre en compte le contexte avant de signaler une alarme. Par exemple, dans le cas d’un IDS r´eseau, ils permettent de sp´ecifier que pour ˆetre valide, une attaque doit survenir dans le contexte d’une session active. Diff´erents mod`eles th´eoriques ont ´et´e utilis´es dans le cadre du d´eveloppement de ces syst`emes, et nous allons consacrer le reste de ce chapitre `a leur ´etude.
Dans [2], C´edric Michel et Ludovic M´e proposent une taxonomie des langages utilis´es en d´etection d’intrusions divisant ceux-ci en six cat´egories : langages d’´ev´enements, d’exploits, de rapports, de d´etection, de corr´elation et de rapports. Dans ce chapitre, nous nous attaquons au cas particulier des langages de d´etection, que nous subdivisons en cinq cat´egories.
Nous commencerons notre ´etude dans la section1.1par les langages les plus simples : les langages sp´ecifiques au domaine. Ces langages ont l’avantage de pr´esenter une grande simplicit´e, mais offrent souvent une faible expressivit´e et peu de souplesse. Par la suite, dans la section 1.2, nous jetterons un oeil aux langages imp´eratifs ayant ´et´e d´evelopp´es sp´ecialement pour la d´etection d’intrusions. Ce sont ceux qui se rapprochent le plus des langages de programmation habituels. Ils pr´esentent l’avantage d’offrir des primitives associ´ees au traitement d’´ev´enements et des syst`emes de types appropri´es `a la d´etection d’intrusions. Les signatures d´evelopp´ees avec ces langages sont cependant souvent diffi-ciles `a maintenir. Les langages bas´es sur les syst`emes de transition, que nous traiterons
les sc´enarios d’attaques. Ces langages comportent cependant une partie imp´erative dont l’objectif est souvent d’emmagasiner une partie du contexte. Les syst`emes experts, dont nous parlerons dans la section1.4, sont sp´ecialis´es dans l’accumulation et, surtout, l’in-f´erence d’information concernant le contexte. Afin d’´eviter les probl`emes de m´emoire, cette information doit cependant ˆetre g´er´ee explicitement, et le niveau d’abstraction d´esir´e n’est pas toujours atteint. Les syst`emes bas´es sur des logiques temporelles, dont nous parlerons finalement dans la section 1.5, sont ceux qui se rapprochent le plus de syst`emes `a base de signatures purement d´eclaratives.
1.1
Langages sp´
ecifiques au domaine
Un langage sp´ecifique au domaine, tel que d´efini dans [3], est un langage de pro-grammation sp´ecialement con¸cu pour capturer la s´emantique propre `a un domaine d’ap-plication particulier. Des exemples de langages sp´ecifiques au domaine sont HTML et SQL, respectivement con¸cus pour l’´edition d’hypertextes et la consultation de bases de donn´ees. Dans le pr´esent chapitre, chacun des syst`emes de d´etection d’intrusions que nous pr´esentons vient avec son propre langage permettant de le configurer et/ou de sp´ecifier des signatures particuli`eres d’attaque. Ces langages, sp´ecialement con¸cus pour la d´etection d’intrusions ou pour la surveillance de syst`emes en g´en´eral, tombent donc tous dans la cat´egorie des langages sp´ecifiques au domaine. Cependant, dans la plupart des cas, ces langages sont con¸cus avec un certain souci d’abstraction permettant des les utiliser pour diff´erents types de fichiers d’audit. Par exemple, le langage STATL peut ˆetre utilis´e autant pour une d´etection d’intrusions au niveau hˆote (dans le cas de WinSTAT et USTAT), qu’au niveau r´eseau (dans le cas de NetSTAT).
Les trois syst`emes que nous pr´esentons dans cette section se distinguent de par le fait que les langages qu’ils utilisent sont li´es d’encore plus pr`es au type de d´etection particulier qu’ils permettent d’effectuer. Ils ne sont pas d´efinis sur une s´emantique abs-traite de fichiers d’audit, mais sur des s´emantiques tr`es concr`etes reli´ees aux fichiers d’audits de processus (dans le cas de Panoptis), au filtrage de paquets (dans le cas de Snort), et `a l’identification passive de failles de s´ecurit´e (dans le cas de NeVO). Nous pr´esentons d`es maintenant ces trois syst`emes.
#
# Configuration file for host pooh #
# $ Id : poo.dsl 1.6 2000/05/30 12 :26 :58 dds Exp $ #
HZ = 100 # "Floating point" value divisor
bigend = FALSE # Set to TRUE for big endian (e.g. Sun), FALSE for # little endian (e.g. VAX, Intel x86)
map = TRUE # Set to TRUE to map uid/tty numbers to names
EPSILON = 150 # New maxima difference threshold (%) report = TRUE # Set to TRUE to report new/updated entries unlink = FALSE # Set to TRUE to start fresh
# Reporting procedure
output = ’| /usr/bin/tee /dev/console | /bin/mail root’ # Databases and parameters to check
dbcheck(tty, minbmin, maxbmin, maxio, maxcount) # Terminals
dbcheck(comm, ALL) # Commands
dbcheck(uid, ALL) # Users
dbcheck(uidtty, maxcount) # Users on a terminal
dbcheck(uidcomm, minbmin, maxbmin, maxutime, # Users of a command maxstime, maxmem, maxrw, maxcount, maxasu)
# Map users and terminals into groups usermap(caduser, john, marry, jill)
usermap(admin, root, bin, uucp, mail, news)
termmap(room202, tty31, tty32, tty33, tty34, tty35)
termmap(ptys, ttyp01, ttyp02, ttyp03, ttyp04, ttyp05, ttyp06)
Fig. 1.1 – Exemple de fichier de configuration de Panoptis.
1.1.1
Panoptis
Panoptis [3] se distingue des autres syst`emes de d´etection d’intrusions pr´esent´es dans ce chapitre par le fait qu’il s’agit du seul syst`eme bas´e sur une d´etection d’anomalies que nous avons choisi de pr´esenter. Comme nos travaux se situent plutˆot dans le cadre de reconnaissance de sc´enarios, nous avons mis le focus sur ces types de syst`emes, mais nous avons tout de mˆeme jug´e utile, par souci de compl´etude, d’inclure au moins un d´etecteur d’anomalies.
Comme nous l’avons d´ej`a dit, Panoptis est configurable `a l’aide d’un langage sp´eci-fique au domaine. Ce domaine est celui des processus d’un syst`eme Unix, et Panoptis prend donc en entr´ee des fichiers d’audits de processus. Les auteurs affirment que le langage a quand mˆeme ´et´e con¸cu de fa¸con assez g´en´erale pour pouvoir fonctionner sur n’importe quel syst`eme fournissant des fichiers d’audits de processus, dont Windows NT. Panoptis maintient des tables contenant les profils d’activit´es pour diff´erents utilisa-teurs, terminaux, processus, ou groupages et/ou couplage de ces entit´es. Par exemple, il peut maintenir une table concernant l’utilisation d’un processus donn´e, pour trois utilisateurs sp´ecifiques utilisant un mˆeme terminal. Les informations maintenues pour
#
# Panoptis crontab file for host pooh #
# The format of this file is :
# Hour Minute Day-of-month Month Day-of-week Command
* 5,25,45 * * * panoptis pooh-quick.cfg pooh.20min 20m
8-18 05 * * * panoptis pooh-hour.cfg pooh.workhour 1h
19-7 05 * * * panoptis pooh-hour.cfg pooh.late 1h
4 50 * * 1-5 panoptis pooh-day.cfg pooh.workday 24h
4 50 * * 6,0 panoptis pooh-day.cfg pooh.weekend 24h
2 20 * * 0 panoptis pooh-full.cfg pooh.weekly 7d
/usr/adm/pacct ? /usr/adm/pacct
Fig. 1.2 – Exemple de fichier de planification de tˆaches de Panoptis.
read and parse the the domain-specific language configuration while there are records in the specified accounting file
read and decode an accounting record synthesise the derived quantities
substitute the name of entities belonging to a group with the group name for every database table specified
look for an database entry matching the key of the record retrieved if a matching entry is found
compare it with the entry read
if the accounting record value exceeds the amount stored in the database produce a new maximum value alert and update the database
else (if no matching entry is found)
produce a new value alert and update the database
Tab. 1.1 – Algorithme d’apprentissage et de v´erification de Panoptis.
Database Users*Commands, key [dds/gcc] : New entry. Command : gcc Terminal : ttyp0 User : dds
Executed from : 2001-01-13 01 :29 :32 to : 2001-01-13 01 :29 :33 (1.36 seconds) Database Users*Commands, key [root/ls] :
New maximum average character input/output (204.8 / 64 ; 220%) Command : ls Terminal : ttyp1 User : root
Executed from : 2001-01-13 01 :32 :13 to : 2001-01-13 01 :32 :13 (0.41 seconds)
chacune des entit´es surveill´ees sont param´etrables `a l’aide d’un fichier de configuration. Un exemple de fichier de configuration utilis´e par Panoptis se trouve `a la figure1.1. Ce fichier se divise en quatre parties. En premier lieu, on trouve un ensemble de d´efinitions de variables qui servent `a d´efinir le fonctionnement g´en´eral du programme. Ensuite, on indique la m´ethode de rapport `a utiliser. La troisi`eme partie est celle o`u on sp´ecifie ce que l’on veut surveiller. Pour chacune des cinq tables tty, comm, uid, uidtty et uidcomm, on sp´ecifie les champs que l’on veut surveiller. Ces champs sont pr´ed´efinis et font partie de la d´efinition du langage. Le mot-cl´e ALL signifie que l’on veut surveiller tous les champs. Finalement, on trouve les options de groupage qui permettent de re-grouper certains utilisateurs ou terminaux en un seul. Par exemple, `a la figure 1.1, les utilisateurs john, marry et jill sont regroup´es sous l’utilisateur abstrait caduser.
Une fois ces options choisies, il reste `a configurer la fr´equence `a laquelle les fichiers d’audits sont lus par le syst`eme. Panoptis peut soit les lire en continu, soit ˆetre ex´ecut´e `a des intervalles pr´ed´efinis. Un exemple de fichier de planification de tˆaches se trouve `a la figure 1.2. On voit que des intervalles diff´erents, de mˆeme que des fichiers de configuration diff´erents, peuvent ˆetre utilis´es selon les p´eriodes de la journ´ee ou de la semaine. Finalement, `a chaque fois que Panoptis est ex´ecut´e sur un fichier d’audit, celui-ci compare les valeurs calcul´ees `a celles se trouvant dans les tables et rapporte les entr´ees qui pr´esentent des diff´erences significatives.
`
A la table1.1, on peut voir l’algorithme d’apprentissage et de v´erification utilis´e par Panoptis. Apr`es avoir synth´etis´e les donn´ees du fichier d’audit, il compare, pour chaque entr´ee, la valeur obtenue avec celle qu’il avait d´ej`a. Si aucune valeur n’´etait pr´esente, un ´ev´enement est g´en´er´e pour signaler une nouvelle entr´ee et la valeur est ins´er´ee dans la table. Si, au contraire, une valeur ´etait d´ej`a pr´esente, les deux valeurs sont compar´ees et si la diff´erence entre celles-ci d´epasse le seuil de tol´erance sp´ecifi´e dans le fichier de configuration, un ´ev´enement est g´en´er´e. Ensuite, la nouvelle valeur obtenue est ins´er´ee `a la place de l’ancienne. Panoptis est donc un syst`eme tol´erant `a des changements de comportements graduels. D’un cˆot´e, cette caract´eristique pr´esente l’avantage de bien refl´eter le fait que les utilisateurs changent petit `a petit leurs habitudes, mais d’un autre cˆot´e, elle pr´esente aussi l’inconv´enient d’offrir ainsi `a un utilisateur malveillant un moyen d’´echapper `a la d´etection de la modification de son comportement.
`
A la figure 1.3, se trouve un exemple de fichier de sortie de Panoptis. Il y a deux sortes d’´ev´enements : ceux correspondant `a une nouvelle entr´ee dans une table et ceux correspondant au d´epassement du seuil de tol´erance. Dans chacun des cas, on donne le nom de la table concern´ee ainsi que la cl´e de l’entr´ee ayant g´en´er´e l’´ev´enement et le moment o`u celui-ci est survenu. Dans le cas o`u il s’agit d’un d´epassement de seuil, on donne aussi la nouvelle valeur. Le premier ´ev´enement de la figure 1.3 signifie donc
seconde signifie que l’utilisateur root, `a l’aide de la commande ls, a list´e le contenu de r´epertoires contenant deux fois plus de fichiers qu’`a l’habitude.
En r´esum´e, Panoptis constitue un cas typique de syst`eme de d´etection d’intrusions effectuant de la d´etection d’anomalies. Il est configurable `a l’aide d’un langage tr`es simple et sp´ecifique `a l’analyse de fichiers d’audits de processus sur un syst`eme Unix. Un tel outil fait partie des composantes essentielles `a une architecture de s´ecurit´e car il permet d’avoir une vision r´esum´ee de fichiers d’audits qui, dˆu `a leur grande taille, seraient inutilisables sinon. Comme la plupart des syst`emes effectuant de la d´etection d’anomalies, Panoptis est sujet `a un grand nombre de faux positifs et sa nature adap-tative le rend vuln´erable aux utilisateurs qui modifieraient tranquillement leur profil afin de ne pas se faire remarquer. Cependant, son mode de fonctionnement g´en´erique le rend capable de d´etecter des attaques qu’un syst`eme fonctionnant `a base de signatures aurait pu laisser passer.
1.1.2
Snort
Le syst`eme de d´etection d’intrusions Snort [1], originellement con¸cu pour ˆetre un renifleur (sniffer ) plus ´evolu´e que tcpdump [4], s’est av´er´e petit `a petit tr`es efficace comme outil de d´etection d’intrusions. En effet, il dispose d’un langage de signatures permettant de d´ecrire avec une grande pr´ecision les caract´eristiques des paquets of-fensifs circulant sur le r´eseau1. L’hypoth`ese derri`ere le choix de Snort comme syst`eme
de d´etection d’intrusions est donc que les attaques sont rep´erables `a l’aide d’un seul paquet. Bien que les efforts investis par la communaut´e pour d´evelopper des langages de signatures permettant de tenir compte de plusieurs paquets - voir tout le reste du pr´esent chapitre - incitent `a penser qu’un langage de signatures concernant un seul paquet n’est pas suffisamment expressif, la pratique d´emontre qu’il est tout de mˆeme possible de d´etecter un grand nombre d’attaques sur la base d’un tel langage (la base de signatures de Snort contient, `a ce jour, plus de 2000 signatures d’attaques).
La structure logicielle de Snort se trouve `a la figure 1.4. Utilisant, tout comme tcpdump, la librairie de capture de paquets LibPcap [5], Snort comporte un module de d´ecodage de paquets permettant de d´ecoder un grand nombre de protocoles de diff´erents niveaux. Au dessus de ce module de d´ecodage se situe un ensemble de pr´eprocesseurs, dont la fonction originale ´etait de r´egulariser le format des paquets afin de faciliter la
1Une autre approche consiste `a d´etecter les paquets r´esultants de l’attaque. Lorsqu’il est possible
Modules d’affichage Réseau Libpcap Module de décodage Préprocesseurs Module de détection
Fig. 1.4 – Structure de Snort. tˆache de la base de r`egles.
Par exemple, si une politique de s´ecurit´e sp´ecifie que personne ne doit se connecter au service Telnet en utilisant l’utilisateur root, on voudrait pouvoir sp´ecifier une r`egle qui surveille les paquets contenant la chaˆıne de caract`eres user : root. Cependant, il est possible d’´echapper `a cette r`egle en utilisant le caract`ere de retour en arri`ere <BS>. En tapant user : roo<BS>ot, un utilisateur peut alors se connecter sous le compte root sans se faire rep´erer. Des astuces similaires s’appliquent au trafic HTTP. Pour ces raisons, Snort comporte des pr´eprocesseurs responsables de r´egulariser le trafic Telnet et HTTP. Il est cependant possible d’´echapper au syst`eme de d´etection d’intrusions autrement qu’en utilisant des astuces de formatage au niveau application. Une astuce bien connue consiste `a fragmenter le paquet offensif en plusieurs petits paquets, de fa¸con `a ce qu’aucun des paquets r´esultants ne soit alarmant. Une autre fa¸con de faire est d’envoyer les paquets dans un ordre ne correspondant pas `a celui dans lequel ils seront interpr´et´es par la machine qui les recevra. Les pr´eprocesseurs frag2 et stream4 ont donc ´et´e ajout´es afin de remettre ensemble les paquets fragment´es et de pr´esenter les paquets au syst`eme de d´etection d’intrusions dans le mˆeme ordre que celui dans lequel le syst`eme les recevant les interpr`etera. Il s’agit encore une fois d’un travail de formatage visant `a ´eviter certaines attaques d’´evasion.
En plus de cette fonctionnalit´e, les pr´eprocesseurs sont aussi utilis´es `a deux autres fins : d´etecter les sc´enarios d’attaques utilisant plusieurs paquets, ainsi que permettre l’acquisition passive d’information. Un exemple simple de cat´egorie d’attaques n´ecessi-tant la d´etection de plusieurs paquets est le balayage (scan). Qu’il s’agisse d’un balayage TCP, UDP, ICMP ou autre, les attaques de balayage ont pour objectif de permettre
stateless ; flags :A,12 ; ack :0 ; reference :arachnids,28 ; classtype :attempted-recon ; sid :628 ; rev :3 ;)
Fig. 1.5 – Exemple de signature Snort.
`a l’attaquant d’acqu´erir de l’information sur le r´eseau ou la machine victime afin de mieux se pr´eparer `a son attaque. Les balayages peuvent s’effectuer en utilisant des fonctionnalit´es tout `a fait normales de la pile TCP/IP, et la seule fa¸con de les d´etec-ter consiste g´en´eralement en la d´etection de l’utilisation abusive de ces fonctionnalit´es. Certains pr´eprocesseurs (par exemple portscan2) ont donc ´et´e ajout´es afin de compter, par exemple, le nombre de connexions TCP demand´ees par un hˆote distant dans une fenˆetre de temps donn´ee.
Effectuer un minimum d’acquisition est plus que souhaitable pour un syst`eme de d´etection d’intrusions : il s’agit d’une fonctionnalit´e vitale. Un exemple de pr´eproces-seur effectuant de l’acquisition passive d’information est le pr´eprocespr´eproces-seur flow, dont la tˆache est de tenir `a jour une table des sessions TCP actives. Avant l’arriv´ee de flow, il ´etait possible d’exploiter le fait que Snort fonctionnait paquet par paquet pour g´en´erer automatiquement des paquets correspondant aux signatures d’attaque [6], engorgeant ainsi le syst`eme de d´etection d’intrusions de faux-positifs.
Au dessus de tous ces pr´eprocesseurs, se trouvent les modules de d´etection. Ces derniers sont responsables de reconnaˆıtre les profils de paquets offensifs. La description des paquets `a reconnaˆıtre se trouve dans un fichier texte qui est lu `a l’amor¸cage du programme. Le langage utilis´e pour d´ecrire ces paquets est relativement simple, ce qui explique en partie la popularit´e et la croissance rapide du nombre d’attaques que Snort est maintenant capable de reconnaˆıtre. Typiquement, une signature Snort est une suite de mots-cl´e suivis de z´ero ou plusieurs arguments. Certains mot-cl´es ne concernent pas la d´etection, mais sont simplement ajout´es afin de documenter l’attaque. Une fois les paquets reconnus, une s´erie de modules d’affichage et d’archivage sont responsables de l’interaction avec l’usager. Lorsque les attaques sont identifi´ees, Snort peut, entre autres, afficher un message `a l’´ecran, ajouter une ligne dans un fichier texte, une entr´ee dans une base de donn´ees, envoyer un message via le protocole SNMP, etc.
`
A la figure1.5, on pr´esente un exemple de signature Snort. L’interpr´etation de cette signature se lit comme suit : si un paquet TCP provenant de l’ext´erieur ($EXTER-NAL_NET) p´en`etre dans notre r´eseau ($HOME_NET), peu importe les ports (any), et que ce paquet a le drapeau ACK activ´e, de mˆeme que les deux bits r´eserv´es (flags :A,12), et que le num´ero d’acquiescement est 0 (ack :0), peu importe l’´etat de la session
(sta-alert tcp any any <> 192.168.1.0/24 80 (content : "sex" ; msg : "Not for children !" ; react : block, msg ;)
Fig. 1.6 – Exemple d’utilisation du module de r´eaction.
alert tcp any 143 -> any any (msg :"IMAP login" ; content :"OK LOGIN" ; flow :established,to_client ; flowbits :set,logged_in ; flowbits :noalert) alert tcp any any -> any 143 (msg :"IMAP list overflow attempt" ;
flow :established,to_server ; flowbits :isset,logged_in ; content :"LIST" ;)
Fig. 1.7 – Exemple d’utilisation du module flowbits.
teless), il faut alors signaler un balayage TCP fait avec nmap [7] (msg :"SCAN nmap TCP"). Le reste de la signature constitue la documentation de l’attaque.
Cette revue de Snort serait incompl`ete si aucune allusion n’´etait faite `a la nature particuli`ere des modules de d´etection react et flowbits. Le module react fait de Snort non plus un simple syst`eme de d´etection d’intrusions, mais un syst`eme de pr´evention d’intrusions. Il permet de r´eagir en interrompant les sessions TCP jug´ees offensives. Il permet, de plus, d’envoyer un message d’avertissement `a l’usager expliquant pourquoi la communication a ´et´e interrompue. `A la figure1.6, on voit comment ce module peut ˆetre utilis´e pour empˆecher les enfants d’aller sur des sites pornographiques. Lorsqu’un usager tente de consulter un site web contenant le mot sex, la session TCP correspondante est interrompue et le message not for children est affich´e dans son navigateur. Cet exemple est tir´e de [1].
Le module flowbits, quant `a lui, a ´et´e mis au point afin de r´epondre au besoin de plus en plus grandissant de permettre `a Snort de tenir compte de l’´etat des sessions au niveau application. Il permet de d´efinir des variables bool´eennes (drapeaux) servant `a suivre l’´etat de la session en changeant la valeur de ces variables (set, unset, reset, toggle) dans certaines r`egles, et en les lisant dans d’autres (isset, isnotset). Comme ce module a ´et´e mis au point pour suivre l’´etat des sessions au dessus de TCP, ces variables sont instanci´ees et initialis´ees `a chaque nouvelle session TCP. Il est `a noter que les r`egles servant `a mettre `a jour les valeurs des drapeaux contiennent g´en´eralement le mot-cl´e noalert, signifiant que mˆeme si la r`egle est activ´ee, aucune alerte ne doit ˆetre g´en´er´ee. `A la figure1.7, on peut voir comment l’utilisation du module de d´etection flowbits permet de diminuer le nombre de faux positifs lors de la d´etection d’une attaque de d´ebordement de tampon d’un serveur IMAP, un protocole s’ex´ecutant g´en´eralement
versions de imapd, s’effectue en utilisant incorrectement la commande LIST, et ne peut r´eussir que si l’usager est correctement connect´e (au niveau application). La premi`ere signature de la figure1.7 sert donc `a m´emoriser le fait que le mot de passe de l’usager a ´et´e accept´e. Ce sera le cas si on voit passer la chaˆıne de caract`eres OK LOGIN. Dans ce cas, on active drapeau logged_in et on sp´ecifie que cette r`egle ne doit pas d´eclencher d’alerte en utilisant le mot-cl´e noalert. L’utilisation du pr´eprocesseur flow nous permet, d’une part, de v´erifier que le paquet survient bel et bien dans le contexte d’une session TCP active, et d’autre part, qu’il provient bien du serveur. La seconde signature permet la d´etection de l’attaque proprement dite. Il s’agit d’une version l´eg`erement modifi´ee de la signature num´ero 2118. Une alerte sera lanc´ee si on voit passer le mot LIST en direction du serveur dans le cadre d’une session TCP active appartenant `a un usager ayant r´eussi `a se connecter.
En r´esum´e, Snort est un syst`eme de d´etection d’intrusions ouvert jouissant d’une grande popularit´e. Il fonctionne au niveau r´eseau et sa base de signatures contient la description d’un nombre consid´erable d’attaques. Il comporte plusieurs pr´eprocesseurs qui permettent de faciliter le travail des modules de d´etection ainsi que de prot´eger le syst`eme d’´evasions communes et d’attaques d’inondation de faux-positifs. Ces modules devraient faire partie int´egrante de tout bon syst`eme de d´etection d’intrusions. Les modules de d´etection, situ´es au-dessus des pr´eprocesseurs, permettent `a l’utilisateur de d´efinir ses propres r`egles dans un langage simple. Certains moyens ont ´et´e mis en oeuvre pour compenser les manques les plus importants reli´es `a la nature un paquet-une signature de ce langage. Cependant, `a mesure que ces moyens sont mis en place, il devient de plus en plus ´evident qu’un langage de sp´ecification id´eal devrait pouvoir tenir compte de plusieurs paquets. Le reste de ce chapitre est donc consacr´e aux langages permettant d’exprimer des signatures s’´etalant sur plusieurs paquets (ou ´ev´enements).
1.1.3
NeVO
NeVO [8] n’est pas un syst`eme de d´etection d’intrusions, mais un identificateur passif de failles de s´ecurit´e. La raison pour laquelle nous le mentionnons ici est que la connaissance des failles de s´ecurit´e du r´eseau fait partie des moyens ´etant souvent mentionn´es pour r´eduire le nombre de faux positifs g´en´er´es par un syst`eme de d´etection d’intrusions [9, 10]. Dans [9], on trouve une courte ´etude des diff´erentes fa¸cons dont les identificateurs de failles de s´ecurit´e pourraient ou devraient, selon les besoins, coop´erer avec les syst`emes de d´etection d’intrusions. Par exemple, la connaissance des failles de s´ecurit´e peut ˆetre utilis´ee pour activer ou d´esactiver certaines r`egles du syst`eme de d´e-tection d’intrusions, diminuant ainsi `a la fois le nombre de faux positifs et la demande
faite au processeur de la machine sur laquelle le syst`eme s’ex´ecute. D’autres pensent plutˆot que toutes les attaques devraient continuer `a ˆetre surveill´ees, sauf que l’outil de visualisation utilis´e pour consulter le journal d’attaques devrait permettre d’identifier celles dont le succ`es est le plus vraisemblable ´etant donn´ees les vuln´erabilit´es identifi´ees. R´eciproquement, un autre mod`ele de coop´eration envisageable serait de lancer l’identi-ficateur de failles seulement au moment o`u les attaques surviennent, all´egeant ainsi le travail de ce dernier plutˆot que celui du syst`eme de d´etection d’intrusions. Finalement, on ne doit pas oublier, lors de l’´etude de ces diff´erents mod`eles, que les identificateurs de failles sont autant sujets aux faux positifs et aux faux n´egatifs que les syst`emes de d´etection d’intrusions.
NeVO, mis au point par la compagnie Tenable, est un identificateur passif de failles de s´ecurit´e, ce qui signifie qu’il effectue son travail sans avoir `a injecter de trafic sur le r´eseau. Il se pr´esente comme un compl´ement ou une alternative `a Nessus [11,12,13], qui est un identificateur actif de failles de s´ecurit´e. Bien que l’identification active puisse en g´en´eral fournir des rapports plus exhaustifs que l’identification passive, elle peut souvent s’av´erer tr`es d´erangeante pour le r´eseau en cours d’audit, voire mˆeme mener `a son instabilit´e. De plus, l’identification passive permet d’avoir acc`es `a une information continuellement mise `a jour. Finalement, l’identification passive permet non-seulement de trouver les failles sur les serveurs, mais aussi sur les clients. Pour toutes ces raisons, l’identification passive s’impose comme un compl´ement essentiel `a l’identification active.
`
A premi`ere vue, un identificateur passif de failles de s´ecurit´e ne devrait pas fonction-ner diff´eremment d’un syst`eme de d´etection d’intrusions. D’un point de vue abstrait, on tente d’identifier un comportement caract´eristique de l’information `a laquelle on s’in-t´eresse. Les auteurs de [8] citent cependant deux diff´erences notables entre le mode de fonctionnement d’un identificateur de failles et celui d’un syst`eme de d´etection d’intru-sions : la tol´erance `a l’´echantillonnage et le mod`ele d’acc`es `a l’information.
Tol´erance `a l’´echantillonnage : Alors que le fait de n’ˆetre pas capable de traiter en temps r´eel tout le trafic circulant sur le r´eseau peut ˆetre consid´er´e, pour un syst`eme de d´etection d’intrusions, comme une faiblesse majeure, cette particularit´e est beaucoup plus tol´erable pour un identificateur passif de failles de s´ecurit´e. L’hypoth`ese permettant de dire qu’un identificateur de failles peut fonctionner aussi bien sur une base ´echantillonnale qu’en observant la totalit´e du trafic est que le comportement caract´eristique de la faille sera observable pratiquement `a chaque fois que le syst`eme d´efaillant entrera en communication. Si on n’identifie pas la faille maintenant, on l’identifiera bien plus tard.
Mod`ele d’acc`es `a l’information : L’information acquise par un identificateur pas-sif de failles de s´ecurit´e ne doit pas, contrairement `a celle acquise par un
sys-nooutput hs_sport=21 name=Anonymous FTP (login : ftp) pmatch=^USER ftp match=^331 NEXT #---id=700019 dependency=700018 timed-dependency=5 hs_sport=21 name=Anonymous FTP enabled
description=The remote FTP server has anonymous access enabled. risk=LOW
pmatch=^PASS match=^230
Fig. 1.8 – Exemple de signature NeVO.
t`eme de d´etection d’intrusions, ˆetre archiv´ee `a chaque fois qu’elle est d´etect´ee. Au contraire, l’identificateur doit plutˆot tenir `a jour un mod`ele du r´eseau et le fournir sur demande. Cette demande sera typiquement faite au moment de la consultation du journal d’attaques du syst`eme de d´etection d’intrusions. L’information n’est donc pas envoy´ee directement `a l’utilisateur, mais conserv´ee jusqu’`a ce qu’elle soit demand´ee.
Ces deux diff´erences concernant l’architecture logicielle d’un identificateur passif de failles ne justifient cependant pas le fait que le langage utilis´e pour d´ecrire les fa¸cons de d´etecter les failles soit diff´erent de celui utilis´e par un syst`eme de d´etection d’intrusions, et c’est pourquoi nous nous attarderons maintenant au langage de NeVO. Ce langage est fortement d´edi´e `a l’acquisition passive d’information sur un r´eseau informatique. De plus, l’acquisition d’information faite `a l’aide de ce langage se limite au niveau appli-cation. Cela signifie que l’inspection faite sur les paquets se limite `a la partie donn´ees de ceux-ci, et non aux diff´erents champs des diff´erents protocoles ni `a l’interaction de ceux-ci. NeVO incorpore cependant un module permettant de d´etecter passivement les syst`emes d’exploitation des machines communiquant sur le r´eseau en inspectant les entˆetes des paquets SYN, mais ce module n’utilise pas le langage de NeVO.
Une signature NeVO concerne g´en´eralement un seul paquet. On sp´ecifie le contenu recherch´e `a l’aide du mot-cl´e match. Cependant, il est possible de sp´ecifier, `a l’aide du mot-cl´e pmatch, le contenu du paquet pr´ec´edent dans la mˆeme session. Par d´efaut, le contenu est recherch´e en mode texte. Il est cependant possible de rechercher un contenu binaire `a l’aide du mot-cl´e bmatch. Le mot-cl´e regex permet de rechercher des expressions r´eguli`eres. Le mot-cl´e dependency permet de sp´ecifier qu’une signature ne doit ˆetre consid´er´ee, pour un flux TCP donn´e, que si une autre signature a ´et´e activ´ee.
Le mot-cl´e time-dependency permet de limiter le d´elai d’attente entre l’activation des deux signatures. Le mot-cl´e description permet de sp´ecifier le message a afficher et le mot-cl´e nooutput signifie qu’il n’y a pas de message `a afficher. On trouve `a la figure1.8 un exemple de signature NeVO (tir´e de [8]) responsable d’identifier les serveurs FTP ayant un compte anonymous actif. Cette signature se divise en deux sous-signatures. La premi`ere est responsable d’identifier les paquets contenant une demande de connexion pour l’utilisateur ftp suivie d’une acceptation du nom d’utilisateur (code 331). La seconde, activ´ee seulement dans les 5 secondes suivant l’activation de la premi`ere, est responsable d’identifier l’envoi d’un mot de passe suivi de l’acceptation de ce mot de passe (code 230).
En r´esum´e, NeVO est un exemple tr`es int´eressant d’identificateur passif de failles de s´ecurit´e. Mˆeme s’il a ´et´e d´evelopp´e `a des fins commerciales (habituellement, la docu-mentation disponible sur les outils commerciaux se limite aux aspects externes), on peut trouver une documentation riche et pr´ecise sur son fonctionnement interne. `A premi`ere vue, son langage d´edi´e `a l’identification de simples paquets au niveau application pour-rait nous porter `a croire que le nombre de comportements observables est plutˆot limit´e, mais la possibilit´e de sp´ecifier une notion de d´ependance entre les r`egles augmente sans aucun doute l’expressivit´e du langage de fa¸con significative. Cependant, cette fa¸con ad hoc de r´egler le probl`eme des sc´enarios complexes ne saurait amener toute l’expressivit´e d´esirable. Entre autres, elle ne permet pas de reconnaˆıtre le fait qu’un paquet donn´e n’arrive pas dans un certain d´elai, ou encore de compter le nombre d’occurrences d’un paquet donn´e. De plus, il est dommage que la s´emantique du langage se limite au niveau application. Le fait de pouvoir sp´ecifier des paquets au niveau des diff´erentes couches de protocoles permettrait sans doute de d´etecter plus de failles et, sans n´ecessairement se limiter aux failles, d’acqu´erir encore plus d’information.
1.2
Langages imp´
eratifs
La distinction entre les langages imp´eratifs et les langages d´eclaratifs, dans la litt´e-rature, n’est pas aussi nette que l’on pourrait le croire. G´en´eralement, on se contente de d´efinir informellement un langage d´eclaratif comme ´etant un langage permettant de d´efinir ce que l’on veut identifier, plutˆot que comment l’identifier. Les autres langages tombent tous sous la cat´egorie des langages imp´eratifs. Sur la base de cette d´efinition, le langage de signatures de Snort, par exemple, est clairement d´eclaratif.
`
A l’exception des langages pr´esent´es dans la pr´esente section, les langages que nous pr´esentons dans ce chapitre ont tous la pr´etention d’ˆetre d´eclaratifs. Plus loin dans
les langages d´eclaratifs des langages imp´eratifs. Pour l’instant, nous pr´esentons deux langages qui, peu importe la d´efinition utilis´ee, appartiennent certainement `a la cat´ego-rie des langages imp´eratifs. RUSSEL, que nous pr´esentons dans un premier lieu, a ´et´e con¸cu dans le but d’analyser s´equentiellement des fichiers d’audit, alors que Bro, que nous pr´esentons par la suite, a ´et´e con¸cu afin de pouvoir exprimer les signatures dans un langage typ´e proche de celui utilis´e pour exprimer les politiques de s´ecurit´e dans un contexte de d´etection d’intrusions au niveau r´eseau.
1.2.1
ASAX
ASAX [14,15,16] a ´et´e d´evelopp´e dans le but d’analyser des traces d’audit. La syn-taxe de RUSSEL, le langage utilis´e pour ´ecrire les signatures, se trouve `a la table 1.2. L’ex´ecution d’un programme RUSSEL implique l’analyse s´equentielle d’un fichier de trace d’audit. Une trace d’audit est d´efinie comme ´etant une s´equence finie d’enregis-trements, qui eux sont d´efinis comme ´etant une fonction partielle associant des valeurs `a un ensemble d’´etiquettes, aussi appel´ees champs. Ces enregistrements sont pass´es `a ASAX dans un format normalis´e (Normalized Audit Data Format), qui permet de faire abstraction du type d’audit.
La notion centrale de ASAX est celle de contexte d’ex´ecution. Un contexte d’ex´e-cution est entre autres caract´eris´e par trois ensembles de r`egles : Cur, Nxt et Cmp. L’ensemble Cur contient les instances de r`egles qui doivent ˆetre ex´ecut´ees sur l’en-registrement courant, l’ensemble Nxt contient les instances de r`egles qui doivent ˆetre ex´ecut´ees sur l’enregistrement suivant, et l’ensemble Cmp contient l’ensemble des r`egles qui doivent ˆetre ex´ecut´ees une fois que tous les enregistrements sont trait´es. L’utilit´e de ce dernier ensemble est de permettre d’effectuer des traitements sur des valeurs ayant ´et´e accumul´ees tout au long du traitement de la trace d’audit. Par exemple, il permet de calculer une moyenne et de la sauvegarder quelque part. Ces trois ensembles doivent ˆetre maintenus `a jour explicitement par celui qui ´ecrit les r`egles via le mot-cl´e Trigger off.
Une autre caract´eristique d’un contexte d’ex´ecution est l’ensemble des valeurs des diff´erentes variables. Ces variables peuvent ˆetre de trois types : locales `a une r`egle, glo-bales, ou correspondre aux champs d’un enregistrement. Comme l’ordre d’ex´ecution des r`egles n’est pas sp´ecifi´e, l’utilisation de variables globales peut amener un certain non-d´eterminisme. Aussi, pour palier aux probl`emes d´ecoulant du fait que certains champs peuvent ˆetre absents de certains enregistrements, on a ajout´e un mot-cl´e present, per-mettant de tester la pr´esence d’un champ. Lorsqu’un champ est absent, il est tout de
R : := rule Q ( . . . ; G ; . . . ) ; . . . ; H ; . . . ; A G : := P : T
H : := V : T
A : := V := E | Y ( . . . , E , . . . )
| trigger off M Q ( . . . , E , . . . ) | begin . . . ; A ;. . . end | do . . . ; C → A ; . . . od | if . . . ; C → A ; . . . fi
C : := true | F present | not C | C B C | E S E E : := L | V | F | P | -E | E O E | X(. . . ,E,. . . ) B : := and | or
O : := + | - | * | div | mod S : := > | < | = | 6= | ≤ | ≥
M : := for current | for next | at completion T : := integer | byte | string
A actions O arithmetic operators
B logical operators P formal parameters
C conditions Q rule names
E expressions R rules
F field names S relational operators
G parameter declarations T types
H variable declarations V local variables
L literals X external function names
M triggering modes Y external procedure names Tab. 1.2 – Syntaxe abstraite de RUSSEL.
mˆeme possible de lire sa valeur. La valeur lue est alors celle qui ´etait pr´esente la der-ni`ere fois que le champ ´etait pr´esent, et les r´esultats obtenus sont susceptibles d’ˆetre tr`es diff´erents de ceux escompt´es.
`
A la figure1.9se trouve un exemple de signature ´ecrit en RUSSEL pour ASAX. Cet exemple a ´et´e copi´e tel quel de [14]. Les variables evt et res sont des champs qui sont suppos´es faire partie de chaque enregistrement. Ensemble, les deux r`egles Failed_login et Count_rule1 servent `a surveiller un utilisateur qui ´echouerait `a se connecter trop souvent. On remarque que la r`egle Failed_login se r´eactive inconditionnellement (ligne 8). La r`egle Count_rule1 d´emontre la s´emantique particuli`ere d’un bloc if. . . fi. Ces blocs renferment une s´erie de conditions, chacune suivie d’un bloc d’actions. D`es qu’une condition est v´erifi´ee, le bloc correspondant est ex´ecut´e et le bloc if. . . fi est termin´e.
01.rule Failed login (maxtimes, duration : integer)
02.# This rule detects a first failed login and triggers off an accounting rule with an 03.# expiration time
04.begin
05.if evt=’login’ and res=’failure’ and is unsecure (terminal)
06. → Trigger off for next Count rule1 (maxtimes-1, timestp+duration) 07.fi ;
08.Trigger off for next Failed login (maxtimes, duration) 09.end
10.
11.rule Count rule1 (countdown, expiration : integer) 12.# This rule counts the subsequent failed logins,
13.# it remains active until its expiration time or until the countdown becomes 0 14.if evt=’login’ and res=’failure’
15. and is unsecure(terminal) and timestp < expiration 16. → if countdown > 1
17. → Trigger off for next Count rule1(countdown-1, expiration) ;
18. countdown =1
19. → SendMessage (”too much failed login’s”) 20. fi ;
21. timestp ≥ expiration 22. → Skip ;
23. true
24. → Trigger off for next Count rule1 (countdown, expiration) 25.fi
Fig. 1.9 – D´etection d’une p´en´etration externe dans ASAX.
L’instruction skip est l’instruction qui ne fait rien. Donc, si le d´elai est ´ecoul´e (ligne 21), la r`egle n’est pas r´eactiv´ee. Sinon, la condition true est v´erifi´ee et la r`egle est r´eactiv´ee pour le prochain enregistrement.
En r´esum´e, RUSSEL est un langage de programmation imp´eratif comportant, en plus des notions les plus communes, celles de contexte d’ex´ecution et de variables d’en-registrement. Ces notions permettent d’automatiser certaines tˆaches communes au trai-tement s´equentiel de fichier d’audit telles que la mise `a jour de la base de r`egles et la mise `a jour des valeurs des champs des enregistrements. Cependant, il n’est pas du tout clair que l’approche consistant `a d´evelopper un nouveau langage ait ´et´e ici la meilleure `a adopter. Les notions particuli`eres au langage RUSSEL auraient tr`es bien pu ˆetre im-plant´ees sans d´evelopper un nouveau langage. Par exemple, on aurait pu envisager une approche orient´ee-objet dans un langage d´ej`a connu de la communaut´e (tel que C++), et arriver `a des r´esultats semblables sinon meilleurs du point de vue de la facilit´e de maintenance et de la courbe d’apprentissage.
Réseau Libpcap Module d ’événements
Interpréteur de scripts
Fig. 1.10 – Structure de Bro.
1.2.2
BRO
Bro [17] est un syst`eme de d´etection d’intrusions con¸cu sp´ecifiquement en vue de d´etecter les attaques survenant au niveau r´eseau. Son architecture logicielle en couches, que l’on peut voir `a la figure1.10, est comparable `a celle de Snort. `A la base, se trouve la mˆeme librairie de capture de paquets (libpcap). Le module d’´ev´enements fait un travail relativement semblable `a celui auquel les pr´eprocesseurs de Snort, conjointement au module de d´ecodage, ´etaient initialement destin´es : faire un premier travail de formatage sur les paquets afin de simplifier la tˆache de l’interpr´eteur de scripts de politiques de s´ecurit´e. Ce dernier est comparable au module de d´etection. Il n’y a pas, pour Bro, d’´equivalent des modules d’affichage. Tout est archiv´e dans des fichiers en format texte. Malgr´e le fait que les deux architectures puissent se ressembler au premier abord, il y a tout de mˆeme deux diff´erences majeures entre les deux syst`emes : l’abstraction cr´e´ee par le module d’´ev´enements et la nature imp´erative du langage de signatures. Alors que les objets fournis par les pr´eprocesseurs de Snort au module de d´etection sont des paquets, ceux fournis par le module d’´ev´enements de Bro `a l’interpr´eteur de scripts sont d’un type plus abstrait : celui d’´ev´enement. Ceci implique qu’un processus de filtrage est fait par le module d’´ev´enements, et que seulement les informations jug´ees pertinentes sont pass´ees `a l’interpr´eteur de scripts. Un des objectifs de cette ´etape de filtrage est de permettre au syst`eme de fonctionner en temps r´eel, malgr´e la grande affluence de trafic pouvant circuler sur le r´eseau. Aussi, les politiques de s´ecurit´e v´erifi´ees avec Bro sont normalement plus haut niveau que celles v´erifi´ees par Snort, voire mˆeme la plupart des autres syst`emes de d´etection d’intrusions. En fait, il s’agit d’un des objectifs poursuivis par les auteurs : permettre une s´eparation claire entre les m´ecanismes et les politiques de s´ecurit´e. Les m´ecanismes, dans ce cas, sont les diff´erents moyens de g´en´erer un ´ev´enement donn´e, alors que les politiques de s´ecurit´e sont les actions `a prendre lorsque les ´ev´enements sont identifi´es. Les m´ecanismes sont donc g´er´es au niveau du
02.global finger_log = open("finger.log") ;
03.event finger_request(c :connection, request : string, full : bool) 04.{ 05. if ( byte_len(request) > 80 ) { 06. request = fmt("%s...", sub_bytes(request, 1, 80)) ; 07. ++c$hot ; 08. } 09. if ( request in hot_names ) 10. ++c$hot ;
11. local req = request == "" ? "ANY" : fmt("\"%s\"", request) ; 12. if ( c$addl != "" )
13. # This is an additional request.
14. req = fmt("(%s)", req) ; 15. if ( full )
16. req = fmt("%s (/W)", req) ;
17. local msg = fmt("%s > %s %s", c$id$orig_h, c$id$resp_h, req) ; 18. if ( c$hot > 0 )
19. log fmt("finger : %s", msg) ;
20. print finger_log, fmt("%.6f %s", c$start_time, msg) ; 21. c$addl = c$addl == "" ? req : fmt("*%s, %s", c$addl, req) ; 22.}
Fig. 1.11 – Exemple de script Bro.
moteur d’´ev´enements, programm´e en C++, alors que les politiques de s´ecurit´e sont mises en oeuvre par l’interpr´eteur de scripts. Ces derni`eres sont ´ecrites dans un langage de signatures propre `a Bro.
Alors que le langage de signatures de Snort est un langage d´eclaratif d´ecrivant certaines caract´eristiques bien cibl´ees des paquets circulant sur le r´eseau, celui de Bro est un langage imp´eratif, quasi aussi expressif que le langage C (sa syntaxe en est d’ailleurs en plusieurs points tr`es semblable), avec d´eclaration de variables (locales ou globales), expressions compos´ees, inf´erence et v´erification de types, etc. Un des objectifs vis´e par le d´eveloppement de ce langage est de permettre, au moment de la compilation, d’effectuer un maximum de v´erification de types, de fa¸con `a ce qu’au moment de l’ex´ecution, le type des variables r´ef´erenc´ees soit coh´erent. Pour ce faire, le langage de Bro dispose de plusieurs types de variables propres `a la r´eseautique : port, adresse IP, nom r´eseau, etc. Le langage dispose aussi de structures de donn´ees abstraites : ensemble, table d’associations, enregistrement ; permettant d’exprimer naturellement des v´erifications dans un langage proche des politiques de s´ecurit´e : si il y a une connexion Telnet sur un des serveurs d’impression, alors. . . . Il est `a noter que bien que le langage de Bro soit imp´eratif, celui-ci ne dispose pas de construction syntaxique it´erative. Cette caract´eristique a ´et´e voulue par les concepteurs afin de minimiser le temps de traitement d’un ´ev´enement. Cependant, comme la r´ecursivit´e est tout de mˆeme permise, l’it´eration est toujours possible. Les concepteurs n’ont toutefois pas relev´e de cas ou son utilisation se faisait ressentir.
`
A la figure 1.11, on peut voir un exemple de script de politique de s´ecurit´e ´ecrit dans le langage de Bro. Cet exemple, tir´e de [17], montre comment on doit r´eagir `a une requˆete finger. L’op´erateur $ sert `a acc´eder aux diff´erents champs des structures. L’op´erateur in (ligne 9) sert `a v´erifier si un ´el´ement fait partie d’un ensemble. Le script v´erifie en premier lieu si la requˆete est excessivement longue (ligne 5). Le cas advenant, celle-ci est tronqu´ee et le champ hot est incr´ement´e. Ensuite, il v´erifie si la requˆete concerne un nom sensible (ligne 9). Si tel est le cas, le champ hot est encore incr´ement´e. La variable locale req est ensuite initialis´ee (lignes 11 `a 16) et, si le champ hot a ´et´e incr´ement´e (ligne 18), une notification en temps r´eel est effectu´ee (ligne 19). Dans tous les cas, la requˆete est archiv´ee (ligne 20). Finalement, la requˆete est enregistr´ee dans le champ addl de la connexion (ligne 21). Advenant le cas o`u une autre requˆete a eu lieu dans le contexte de la mˆeme connexion, ce qui peut ˆetre associ´e `a un comportement malicieux, elle est ajout´ee `a celle s’y trouvant d´ej`a et un ast´erisque est ajout´e pour attirer l’attention lors de l’inspection du fichier d’audit.
L’algorithme de v´erification en temps-r´eel de Bro fonctionne en une seule passe et suivant un seul fil d’ex´ecution (thread). Lorsqu’un paquet est captur´e sur le r´eseau par la librairie libpcap, il est pass´e au moteur d’´ev´enements. Celui-ci peut alors g´en´erer de z´ero `a plusieurs ´ev´enements pour un seul paquet (r´eciproquement, un type d’´ev´enement donn´e peut ˆetre g´en´er´e par plusieurs types de paquets diff´erents). Ces ´ev´enements sont alors plac´es dans une file d’attente et, par la suite, trait´es par l’interpr´eteur de scripts de politiques de s´ecurit´e. Pour un ´ev´enement donn´e, il peut y avoir plusieurs traitements `a faire. Ceux-ci sont effectu´es dans l’ordre o`u ils apparaissent dans le fichier de script. Il est `a noter que ces traitements peuvent, en plus de g´en´erer des alarmes, cr´eer d’autres ´ev´enements qui iront se placer `a la fin de la file et devront ˆetre trait´es avant de retourner au moteur d’´ev´enements et de passer au paquet suivant.
Les travaux entourant Bro sont grandement motiv´es par la pratique et l’article [17] traite de plusieurs probl`emes concrets devant ˆetre pris en compte lors de la concep-tion d’un syst`eme de d´etecconcep-tion d’intrusions en temps r´eel. L’auteur parle entre autres des diff´erentes fa¸cons d’attaquer le syst`eme lui-mˆeme et des moyens de s’en d´efendre, des probl`emes reli´es `a la surveillance de r´eseaux haut-d´ebit (principalement en ce qui concerne la perte de paquets), des diff´erentes fa¸cons de g´erer les chronom`etres, des avantages et des inconv´enients de disposer d’un langage compil´e, des probl`emes reli´es au red´emarrage du syst`eme (souvent n´ecessaire pour faire un nettoyage de la m´emoire), etc. Quiconque s’engage dans des travaux reli´es `a la d´etection d’intrusions en temps r´eel devrait au moins prendre quelques minutes pour jeter un oeil `a cet article.
En r´esum´e, Bro est un syst`eme de d´etection d’intrusions fonctionnant au niveau r´eseau dont la conception a grandement ´et´e influenc´ee par des probl`emes pratiques. Il
