Dtection dintrusions et diagnostic danomalies

dans un systme diversifi par comparaison de

graphes de flux dinformation
Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane
quipe SSIR, EA 4039
Suplec, BP 81127, 35511 Cesson-Svign Cedex, France
prenom.nom@rennes.supelec.fr
Tel : (+33) 299.84.45.00
Les systmes de dtection dintrusions (IDS) sont des complments indispensables aux mcanismes de scurit
prventifs prsents dans les systmes informatiques et les rseaux. Une manire de dtecter des intrusions consiste
identifier des variations dans le comportement des entits surveilles (approche dite comportementale). Les IDS
utilisant une telle approche proposs jusqu maintenant prsentent certains inconvnients : taux de faux positifs
levs, absence de diagnostic, ncessit de dfinir un modle explicite, etc. Certains travaux ont propos une mthode
de dtection comportementale, base sur la diversification de COTS (Components Off-The-Shelf), qui ne ncessite
pas la construction de modles explicites. Ces travaux prsentent quelques inconvnients comme limpossibilit de
dtecter certains types dintrusions. Dans cet article, nous prsentons une extension dun de ces travaux, fonde
sur la construction de graphes de flux dinformation pour comparer les comportements des diffrents COTS. Cette
mthode permet, de plus, un diagnostic des erreurs dtectes. Nous dcrivons un prototype dIDS pour serveurs web
et exhibons les rsultats de dtection dintrusions obtenus.
Mots-cls: dtection dintrusions, diversification fonctionnelle, diagnostic danomalies.

Introduction

La dtection danomalies repose sur la comparaison du comportement de lentit observe (utilisateur,

application, flux rseaux, . . .) avec un comportement normal , tabli antrieurement. Une alerte est
leve lorsque ces deux comportements diffrent suffisamment. Cette mthode de dtection permet de
dtecter de nouvelles attaques si celles-ci impliquent une utilisation anormale du systme observ, ce qui
est souvent le cas. Les comportements de rfrence sont gnralement modliss de manire explicite.
Ils peuvent tre incomplets ou incorrects : cela peut tre la cause de faux ngatifs (absence dalertes en
prsence dattaques ou dintrusions) ou de faux positifs (alertes en absence dattaques ou dintrusions).
Certains travaux [TMM05, JRC+ 02, VNC03, GRS05] ont introduit une nouvelle mthode de dtection
danomalies pour laquelle il nest pas ncessaire de construire un modle du comportement de lentit
observe de manire explicite. Ces travaux reposent sur une technique du domaine de la sret de fonctionnement : la diversification fonctionnelle. Cependant, ces travaux prconisent lutilisation de COTS
(Components Off-The-Shelf - logiciels disponibles sur tagre) la place de versions dveloppes spcifiquement comme cest le cas en programmation N-versions. Cela permet de rduire le cot de larchitecture et cela apparat comme la seule solution viable dun point de vue conomique. Cet article prsente
une extension des travaux mens dans [TMM05]. Ces travaux utilisent en effet une approche bote noire
Ces travaux sont financs par la rgion Bretagne et font partie de lACI-SI DADDi (Dependable Anomaly Detection with
Diagnosis

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

qui ne permet pas de dtecter tous les types dattaque. Nous prsentons dans cet article une nouvelle
mthode de dtection dintrusions fonde sur la diversification fonctionnelle. Cette mthode repose sur la
construction de graphes de flux dinformation dans chaque systme dexploitation et leur comparaison par
lintermdiaire dun calcul de similarit entre graphes. Cette mthode permet galement dapporter une
aide au diagnostic des anomalies. En effet, la plupart du temps, les IDS comportementaux ne fournissent
aucun diagnostic de lanomalie dtecte. Ladministrateur doit lui-mme vrifier si les alertes leves par
le systme sont des vrais positifs ou non et, dans le cas dune intrusion effective, trouver les fichiers ou
les processus affects par lintrusion. En prsentant les diffrences entre les graphes, la mthode que nous
proposons fournit ladministrateur des informations sur les symptmes de lintrusion.
Dans la suite de larticle, nous prsentons les diffrentes approches qui ont t explores pour la dtection dintrusions par diversification fonctionnelle (Section 3) et exposons la mthode que nous proposons
pour dtecter les diffrences de comportements entre les diffrents COTS de larchitecture (Section 4).
Ensuite, nous prsentons comment cette mthode de dtection permet galement une aide au diagnostic
des anomalies (Section 5). Finalement, nous dcrivons le prototype dvelopp pour montrer la faisabilit
de lapproche et les rsultats obtenus (Section 6).

Diversification fonctionnelle et dtection dintrusions

La diversification fonctionnelle et, plus particulirement, la programmation N-versions permettent de

construire des systmes tolrants aux fautes. Les diffrents logiciels dvelopps sont appels des versions
et sont dvelopps partir de la mme spcification, par diffrentes quipes de dveloppeurs, avec des
outils et des mthodes de dveloppement diffrents. Lobjectif est dassurer, autant que possible, que les
logiciels dvelopps soient indpendants du point de vue des fautes, cest--dire quils ne subissent pas
de dfaillance commune. Cette proprit garantit que la comparaison des sorties des diffrents logiciels
permet de dtecter la majorit des erreurs.
Une architecture classique fonde sur la programmation N-versions (Figure 1) consiste en la comparaison des sorties de diffrents logiciels pour les mmes entres. Le nombre de logiciels utiliss dtermine
le nombre de fautes qui peuvent tre dtectes et le nombre de fautes qui peuvent tre tolres. Une architecture comprenant f diffrents logiciels permet la dtection de f 1 fautes et permet de tolrer f 2
fautes.
Une intrusion est la consquence de lexploitation dune faute logicielle (alors appele vulnrabilit) :
il est ainsi possible dutiliser une telle architecture pour dtecter et tolrer des intrusions.
La production de N versions dun mme logiciel a un cot trs important et nest certainement pas adapte un environnement industriel standard. De plus, de trs nombreux services internet (serveurs HTTP,
serveurs FTP, serveurs POP par exemple) sont disponibles sous la forme de COTS sur de nombreux systmes dexploitation diffrents. Sous certaines conditions (telles que la dcorrlation des vulnrabilits,
la proximit des spcifications), il est possible dutiliser, dans une architecture de type N-versions, des
COTS la place de versions dveloppes spcifiquement. Des travaux ont montr quune telle approche
est justifie, comme par exemple [WWB01] ou [GPSS04], o des tudes de la dcorrlation des vulnrabilits ont t ralises respectivement sur des serveurs Web et des bases de donnes. Dans la suite de cet
article, nous considrons lutilisation de COTS.

Travaux connexes

Les diffrents travaux utilisant la diversification fonctionnelle pour dtecter les intrusions peuvent tre
classs en deux grandes catgories. En effet, soit ces travaux considrent les serveurs comme des botes
noires et ne comparent donc que les sorties des serveurs ; soit ils les considrent comme des botes grises
et comparent la fois les sorties et certains lments internes des serveurs (comme par exemple les appels
systmes).

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

Service 1

Serveur 1
Service Proxy
Parefeu

Service 2

Service IDS
Serveur 2

Service N

Serveur N

F IG . 1: Architecture gnrale

3.1

Dtection dintrusions par diversification : les approches bote noire

Trois projets rcents ont utiliss la diversification pour dtecter les intrusions avec une approche bote
noire : DIT [VNC03, VAC+ 02], HACQIT [JRC+ 02] et DADDi [TMM05].
DIT (Dependable Intrusion Tolerance) [VNC03, VAC+ 02] est un projet proposant une architecture
gnrale de systmes tolrants aux intrusions. Un serveur web tolrant aux intrusions a t dvelopp
comme instance particulire de larchitecture. Larchitecture propose comprend : des serveurs COTS
redondants fonctionnant sur des systmes dexploitation et des plate-formes diversifis, des proxys tolrants aux intrusions qui jouent le rle dintermdiaire entre le client et les serveurs et qui surveillent le
comportement des serveurs et des autres proxys, et des composants de dtection dintrusions bass sur le
framework de dtection dintrusions EMERALD [PN97]. Larchitecture a t ensuite tendue pour grer
le cas dun serveur web au contenu dynamique. La comparaison des sorties est base sur la comparaison
des hash MD5 des pages web mais la dtection dintrusions repose essentiellement sur les systmes de
dtection dintrusions rseaux et htes.
Le projet HACQIT (Hierarchical Adaptive Control for QoS Intrusion Tolerance) [JRC+ 02] propose
une architecture de serveurs web tolrante aux intrusions. Pour fournir cette proprit, le projet propose
une architecture utilisant la redondance et la diversit. Ainsi, larchitecture est compose de deux serveurs
web (un serveur IIS fonctionnant sous Windows et un serveur Apache fonctionnant sous Linux). Un seul
de ces deux serveurs est reli au client ; lautre serveur reoit les requtes par lintermdiaire dun autre
ordinateur qui se charge notamment de la comparaison des rponses. Lalgorithme de comparaison repose
sur la comparaison du code de statut de la rponse HTTP et/ou sur labsence ou non de rponses dun des
deux serveurs. En plus de ce mcanisme de dtection dintrusions, des moniteurs dhtes, des moniteurs
dapplications, un IDS (Snort) et un utilitaire de vrification dintgrit sont galement utiliss.
Le projet DADDi [TMM05] (Dependable Anomaly Detection with Diagnosis) propose un IDS reposant exclusivement sur la diversification de COTS. Aucun autre systme de dtection dintrusions nest
ajout larchitecture contrairement aux deux autres projets prsents ci-dessus. Les sorties rseau des

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

serveurs COTS sont entirement compares. Un IDS pour serveurs web a t dvelopp dans le cadre de
ce projet. Larchitecture propose comprend trois serveurs : un serveur Apache tournant sur Mac-OS X,
un serveur IIS sur Windows 2000 et un serveur thttpd sur Linux. Les auteurs montrent que, suivant lalgorithme de comparaison utilis, la diversification de COTS peut conduire de nombreux faux positifs
dus aux diffrences de spcification et de conception. Pour rsoudre ce problme, ils proposent lintroduction de mcanismes de masquage pour dterminer quelles diffrences en sortie sont la consquence
dune diffrence de spcification ou de conception. Cela constitue un modle des diffrences normales,
qui est plus simple construire quun modle complet des programmes surveills.
Ces trois projets adoptent une approche de type bote noire. Cette approche prsente un inconvnient
majeur : il nest pas possible de dtecter toutes les intrusions car toutes les sorties des services surveills
ne sont pas prises en compte. Une intrusion contre lintgrit dun des serveurs peut, en effet, ne pas tre
dtecte : un attaquant qui russit compromettre lun des serveurs peut crer une rponse identique
celles des autres serveurs. Les projets HACQIT et DIT utilisent des systmes de dtection dintrusions
htes pour dtecter ces types dintrusions mais ces IDS nutilisent pas la diversification. Il est possible
de dtecter ce type dintrusions en utilisant une approche bote grise comme le montre la sous-section
suivante.

3.2

Dtection dintrusions par diversification : les approches bote grise

Deux articles rcents proposent des IDS utilisant la diversification avec une approche de type bote
grise [CEF+ 06, GRS06].
Le projet N-variant [CEF+ 06] utilise une approche diffrente de celle que nous proposons. Au lieu
dutiliser diffrents COTS pour assurer lindpendance des fautes, les auteurs utilisent des techniques
automatiques de diversification (partitionnement de lespace dadressage, tiquetage des instructions par
exemple) pour construire partir dun seul COTS des variantes diversifies de ce COTS. Ces variantes
prsentent les mmes vulnrabilits mais ces vulnrabilits ne peuvent pas tre exploites par exactement
la mme attaque. Chaque variation permet de dtecter de manire certaine un certain type dattaques.
Contrairement aux autres projets prsents, les variantes sont excutes sur la mme plate-forme. Le prototype dvelopp modifie le noyau du systme dexploitation pour sassurer que les diffrentes variantes
excutent les mmes appels systmes dans le mme ordre. Le fait de nutiliser quun seul COTS que lon
diversifie permet de contourner un problme de lapproche de type bote grise. Il nest en effet pas ais
de comparer les appels systmes effectus par des programmes diffrents sur des systmes dexploitation
diffrents car il est difficile de construire une correspondance entre les appels systmes de diffrents systmes dexploitation. Cette approche prsente cependant un inconvnient : il est ncessaire de construire
des variantes pour chaque type dattaques que lon souhaite dtecter.
Gao, Reiter et Song [GRS05, GRS06] proposent une manire de comparer des suites dappels systme effectus par des COTS sur diffrents systmes dexploitation. Ils introduisent la notion de distance
comportementale qui est une mesure de la dviation des comportements de deux processus. Ils proposent
deux manires dvaluer cette distance : en utilisant une distance volutionnaire [GRS05] ou des modles
de Markov cachs [GRS06]. Une intrusion devrait modifier le comportement de lun des deux processus
et devrait donc accrotre la distance comportementale. Si la distance calcule est au-dessus dun certain
seuil, une alerte est mise. Un inconvnient dune telle approche est quelle ne considre que le numro
des appels systmes, alors que lopration effectue par un appel systme dpend souvent des paramtres
qui lui sont passs. Il est ainsi possible dutiliser ce fait pour viter la dtection.

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

Dtection dintrusions par comparaison de graphes de flux dinformation

En programmation N-versions classique, il est ncessaire de spcifier quelles sorties sont compares ;
le systme ne permet alors de dtecter que les erreurs qui se propagent sur ces sorties. Ainsi, des intrusions nayant pas deffets sur les sorties rseau ne seront pas dtectes par des approches bote noire.
Nous proposons dtendre lapproche bote noire prsente dans [TMM05] en prenant en compte les appels systmes effectus par les diffrents services surveills. Pour cela, nous introduisons une nouvelle
approche de type bote grise qui est complmentaire de lapproche de type bote noire de [TMM05]. Cette
approche est fonde sur la comparaison de graphes de flux dinformation. Dans la suite, nous ferons rfrence lIDS prsent dans [TMM05] en le qualifiant dIDS bote noire et lIDS que nous prsentons
dans cet article par IDS bote grise.
Dans le cadre de lapproche bote noire, seules les sorties rseau des diffrents COTS sont compares ;
les autres sorties des services surveills ne sont pas prises en compte. Ces sorties correspondent en fait aux
appels systme excuts par les services sur les diffrents systmes dexploitation (operating systems en
anglais, OS dans la suite) utiliss. Ce sont ces appels systmes que nous allons considrer avec lapproche
bote grise propose. Cependant, il nest pas ais de comparer les appels systmes de diffrents systmes
dexploitation. En effet, il ny a pas de correspondance une une entre les appels systmes de diffrents
OS. Il est possible de construire une correspondance entre plusieurs appels systmes dun OS et plusieurs
appels systmes dun autre OS, mais cette construction nest pas aise. Pour comparer ces appels systme
et par l dtecter des intrusions, nous avons donc choisi une autre approche fonde sur les graphes de flux
dinformation.
Une politique de scurit peut tre dcrite par un ensemble de flux dinformation autoriss et interdits dans le systme. Par rapport cette politique de scurit, une intrusion se caractrise par un ou des
flux dinformation interdits. Dans larchitecture propose, un service compromis excutera donc des appels systmes qui vont crer des flux dinformation interdits alors que, sur les autres serveurs, ces flux
dinformation ne seront pas prsents.
Nous allons dabord dcrire ce quest un graphe de flux dinformation, puis la mthode que nous avons
choisie pour calculer la similarit entre deux graphes. Enfin, nous expliquerons comment nous appliquons
ces concepts la dtection dintrusions.

4.1

Graphes de flux dinformation

Tout dabord, il est ncessaire de dfinir la notion de flux dinformation. Nous considrons quun flux
dinformation dun objet o1 vers un objet o2 a t cr si ltat de lobjet o2 dpend causalement [dA94]
de ltat de lobjet o1 .
Bell et LaPadula [BP76] ont modlis la cration de flux dinformation. Ils ont pour cela considr
deux types dobjets dans le systme : les objets actifs (tels que les processus) et les objets passifs qui
sont les conteneurs dinformations (tels que les fichiers, les sockets, les pipes, . . .). Les flux dinformation
peuvent tre produits par les trois oprations suivantes :
Un objet actif peut lire un objet passif, ce qui produit un flux dinformation de lobjet passif vers
lobjet actif. Un exemple de ce type doprations est la lecture dun fichier par un processus.
Un objet actif peut crire un objet passif, ce qui produit un flux dinformation de lobjet actif vers
lobjet passif. Un exemple de ce type doprations est lcriture dinformations dans un fichier par
un processus.
Un objet actif o1 peut invoquer un objet actif o2 , ce qui produit un flux dinformation de o1 vers o2 .
Un exemple de ce type doprations est la cration dun nouveau processus par un autre processus.
Les appels systme qui manipulent les informations sont varis, diffrents selon les systmes dexploitation et dpendent du type dobjets manipuls. Cependant, ils peuvent toujours tre classs dans une de

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

2954 apache

15 /private/var/log/httpd/error_log

5 socket

17 /private/var/log/httpd/access_log

F IG . 2: Graphe de flux dinformation pour une requte HTTP donne traite par le serveur Apache sur Mac-OS X

ces trois catgories.

Nous appelons graphe de flux dinformation un ensemble de flux dinformation et dobjets impliqus
dans ces flux qui ont t crs lors dun appel au service surveill. Un graphe de flux dinformation
est un graphe orient tiquet cest--dire que les nuds et les arcs sont associs avec des tiquettes (une
chane de caractres, un entier, . . .). Les objets du systme dexploitation (processus, fichiers, sockets, . . .)
sont les nuds du graphe et les flux dinformation les arcs du graphe. Les tiquettes sont des informations
relies aux nuds ou aux arcs du graphe. Dans notre prototype, les tiquettes possibles sont les suivantes :
les nuds sont associs avec un type : PROCESS, SOCKET, FILE, PIPE, MAPPING ;
les arcs sont associs avec un type galement : PROCESS_TO_FILE, FILE_TO_PROCESS, PROCESS_TO_SOCKET, SOCKET_TO_PROCESS, PROCESS_TO_PIPE, PIPE_TO_PROCESS, PROCESS_TO_LOGFILE.
Dautres donnes sont associes avec les nuds et les arcs mais ne sont pas considrs comme des
tiquettes dans le sens o elles ne sont pas utilises dans le calcul de la similarit (voir la sous-section 4.3).
Les nuds du type FILE sont associs un nom, un descripteur de fichier, une date de cration et de
destruction du descripteur de fichier dans lOS. Les processus sont associs avec leur nom, leur pid, le
pid de leur parent et la date de cration et de destruction du processus dans lOS. Les tiquettes sont
associes avec les donnes transfres entre la source et la destination du flux et avec un temps daccs.
En pratique, un processus o qui accde un fichier f en lecture cre un flux dinformation avec deux
nuds o et f , lis par un arc tiquet par un type et associes aux donnes lues par le processus o et le
temps daccs .
La figure 2 prsente un exemple de graphes de flux dinformation. Ce graphe de flux dinformation
reprsente le traitement dune requte HTTP par le serveur web Apache. Les tiquettes et autres donnes associes ne sont pas toutes reprsentes pour viter de surcharger la figure. Le type des objets est
reprsent par la forme des nuds :
Les sockets sont reprsentes par des losanges. Le nombre prsent dans le losange est le descripteur
de fichier assign par le systme dexploitation.
Les processus sont reprsents par des hexagones. Le nombre prsent dans lhexagone est le pid du
processus et la chane de caractres, le nom du processus.
Les fichiers sont reprsents par des ellipses. Le nombre prsent dans lellipse est le descripteur de
fichiers et la chane de caractres, le nom du fichier.
Le graphe de la figure 2 montre que le processus Apache lit une socket, puis crit dans deux fichiers
de log et crit finalement sur la socket (la chronologie des flux dinformation est donne par les temps
daccs associs aux flux ; ces temps daccs ne sont pas reprsents sur la figure).
En pratique, dans notre prototype, seuls les 256 premiers octets du flux dinformation sont utiliss en tant que donnes associes
larc.

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

4.2

Similarit entre graphes de flux dinformation

Il est ncessaire davoir une mthode pour valuer si deux graphes sont similaires ou non. Pour cela,
nous avons dcid dutiliser le modle dvelopp par Champin et Solnon [CS03], qui permet de calculer
la similarit entre deux graphes tiquets. Dans ces travaux, ils proposent un algorithme pour calculer la
similarit entre deux graphes, algorithme que nous avons lgrement optimis pour notre cas particulier.
Nous allons prsenter brivement leur approche et dtailler lalgorithme que nous utilisons pour comparer
des graphes de flux dinformation.
Un graphe tiquet est un graphe orient G = (V, rV , rE ) o :
V est lensemble des nuds ;
rV V LV est une relation entre les nuds du graphe et les tiquettes des nuds (LV est lensemble
des tiquettes des nuds) ;
rE V V LE est une relation entre les arcs et les tiquettes des arcs (LE est lensemble des
tiquettes des arcs).
Le descripteur dun graphe tiquet G = (V, rV , rE ) est dfini par desc(G) = rV rE .
Considrons deux graphes tiquets G1 = (V1 , rV1 , rE1 ) et G1 = (V2 , rV2 , rE2 ) ; nous cherchons mesurer
la similarit entre ces deux graphes. Pour cela, la notion de mapping est introduite : un mapping m est une
relation m V1 V2 . m est un ensemble de couples de nuds. Dans un mapping m, un nud v1 V1 (resp.
v2 V2 ) peut tre associ avec zro, un ou plusieurs nuds de V2 (resp. V1 ). Une notation fonctionnelle
peut tre utilise pour m : m(v) est lensemble des nuds qui sont associs v dans le mapping m.
La similarit entre G1 et G2 en fonction dun mapping m est alors donne par la formule suivante :
simm (G1 , G2 ) =

f (desc(G1 ) um desc(G2 ))
f (desc(G1 ) desc(G2 ))

o f est une fonction positive croissante en fonction de linclusion (le cardinal est une fonction qui
respecte ces critres par exemple) et um , appel intersection en fonction du mapping m, reprsente lensemble des lments des descripteurs des deux graphes pour lesquels les tiquettes correspondent dans le
mapping m :
desc(G1 ) um desc(G2 ) = {(v, l) rV1 |v0 m(v), (v0 , l) rV2 }

{(v, l) rV2 |v0 m(v), (v0 , l) rV1 }

{(vi , v j , l) rE1 |v0i m(vi ), v0j m(v j )(v0i , v0j , l) rE2 }

{(vi , v j , l) rE2 |v0i m(vi ), v0j m(v j )(v0i , v0j , l) rE1 }

Il est ncessaire dintroduire un dernier concept pour calculer la similarit entre deux graphes. Un nud
peut en effet tre mapp avec plusieurs autres nuds. Ce concept est intressant dans notre cas car il
permet dassocier plusieurs processus sur un OS avec un seul processus sur un autre OS par exemple. La
notion de splits peut tre ajout pour prendre en compte lassociation dun nud particulier avec plusieurs
autres nuds. Les splits dun mapping m reprsentent les nuds qui sont associs avec strictement plus
dun nud dans le mapping m :
splits(m) = {(v, sv )|v V1 V2 , sv = m(v), |m(v)| 2}
La dfinition de la similarit en fonction dun mapping m est alors modifie :
simm (G1 , G2 ) =

f (desc(G1 ) um desc(G2 )) g(splits(m))

f (desc(G1 ) desc(G2 ))

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

o g est une fonction positive, croissante en fonction de linclusion. A partir de la dfinition de la similarit
entre deux graphes en fonction dun mapping m, il est possible de dfinir la similarit entre deux graphes :
sim(G1 , G2 ) = max

mV1 V2

f (desc(G1 ) um desc(G2 )) g(splits(m))

f (desc(G1 ) desc(G2 ))

Trouver la similarit entre deux graphes, cest trouver le mapping m qui maximise cette valeur. Des
exemples de meilleurs mappings, cest--dire de mappings pour lesquels la valeur de la similarit est
maximale, sont donns dans la section 5.
Champin et Solnon [CS03] ont propos deux algorithmes pour rsoudre ce problme : un algorithme
de recherche complte avec quelques optimisations pour couper les branches de larbre de recherche
et un algorithme glouton. Dans notre prototype, nous avons choisi dutiliser lalgorithme de recherche
complte. Nous sommes en effet plus intresss par la prcision du calcul de la similarit plutt que par
la rapidit de lalgorithme.
De plus, nous avons introduit certaines optimisations adaptes aux cas des graphes de flux dinformation et plus particulirement des serveurs webs pour lesquels nous avons dvelopp notre prototype :
cela na pas de sens dassocier un processus un fichier ou une socket ; ces mappings sont donc
interdits ;
les communications entre processus par lintermdiaire de fichiers ne sont pas prsentes dans le cas
particulier que nous considrons ; les associations entre une socket et un fichier ne sont pas permises
dans un mapping (nous considrons que les fichiers ne sont pas des moyens de communications
entre processus) ;
un fichier en dehors de lespace web et un fichier lintrieur de lespace web ne peuvent tre
associs dans un mapping. De plus, lintrieur de lespace web, seuls des fichiers possdant le
mme nom peuvent tre associs dans un mapping.
notre prototype tant dvelopp pour les serveurs web, les sockets recevant les requtes sont mapps
ensemble au dbut de lalgorithme, ainsi que les processus lisant ces sockets.
Avec ces optimisations, le temps de calcul des mappings est relativement bon pour des graphes de petite
taille. Puisque lalgorithme est exponentiel en temps en fonction du nombre de nuds, le temps de calcul
peut tre relativement long pour des graphes plus importants : de lordre de 10 minutes pour des graphes
de 15 nuds par exemple. Notre prototype ne peut donc tre utilis en temps rel actuellement. Il est,
pour cela, ncessaire dvaluer dautres algorithmes tels que lalgorithme glouton propos par Champin
et Solnon et optimiser le code de notre prototype.

4.3

Dtection dintrusions fonde sur la notion de similarit entre graphes de flux dinformation

Les serveurs COTS implmentant le mme service, les graphes de flux dinformation doivent tre
sensiblement les mmes sur les diffrents serveurs et donc la similarit doit tre leve dans les cas
normaux (cela a t vrifi exprimentalement sur notre prototype).
Une intrusion au niveau de lOS se caractrise par des flux dinformation illgaux entre des processus
et des fichiers, des sockets, des pipes, etc. Dans un graphe de flux dinformation, une intrusion sera
responsable de la cration ou de la modification de flux dinformation, dobjets actifs et/ou dobjets
passifs. Une intrusion contre la confidentialit sera caractrise par la cration de flux dinformation
dobjets passifs vers des objets actifs et, si ncessaire, par la cration de nouveaux objets. Une intrusion
contre lintgrit sera caractrise par la cration ou la modification de flux dinformation dobjets actifs
vers des objets passifs et, si ncessaire, la cration de nouveaux objets. Ainsi, une intrusion va affecter
la valeur de la similarit entre les graphes de flux dinformation dun serveur compromis et dun serveur
non-compromis.

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

Seuil de similarit Le calcul de la similarit est une fonction prenant en paramtres deux graphes. Une
valeur leve de la similarit signifie que les serveurs se sont comports dune manire identique en ce
qui concerne les flux dinformation. Une valeur peu leve de la similarit signifie que les serveurs se sont
comports de manire relativement diffrente, ce qui peut tre la consquence dune intrusion ou dune
diffrence de conception ou de spcification. Il est ncessaire de dterminer un seuil en-dessous duquel
une alerte est leve. Pour cela, nous avons dcid de procder par apprentissage dans un contexte normal
dutilisation.
Ce seuil doit tre dtermin exprimentalement pour chaque couple de services diversifis : la similarit
dpend du cardinal des descripteurs des graphes considrs et donc dpend de lapplication surveille. Si
les graphes sont grands (cest--dire quils ont beaucoup de nuds et darcs), un ou plusieurs objets ou
flux dinformation non mapps auront moins dinfluence sur le calcul de la similarit que si les graphes
sont petits (cest--dire ont peu de nuds et darcs). Il nest ainsi pas possible davoir un seuil unique
pour toutes les applications.
Pour calculer ce seuil, il faut dterminer statistiquement quelle valeur correspond un comportement
normal, cest--dire une requte qui nest pas une attaque. Ce seuil est forcment infrieur 1 cause
des diffrences de conception. Au-dessus de ce seuil, il y a une forte probabilit que la diffrence dtecte
soit de une diffrence de conception. En-dessous de ce seuil, la probabilit de dtecter une diffrence
de spcification doit tre faible. Ce dernier cas produira une alerte, mme si la diffrence entre les deux
graphes nest pas due une intrusion : dans ce cas, cette alerte sera donc un faux positif.
Algorithme de dtection dintrusions Dans le contexte dune architecture n > 2 serveurs COTS
Si , il faut dterminer un seuil ti, j pour chaque couple de serveurs comme expliqu dans le paragraphe
prcdent. ti, j est le seuil choisi pour les serveurs Si et S j . Dtecter une intrusion requiert alors de calculer
la similarit entre les graphes de chaque couple de serveurs pour une requte au service surveill, ce qui
correspond au calcul de Cn2 = n!(n2)!
similarits entre graphes. Notons si, j la similarit entre le graphe
2!
du serveur Si et celui du serveur S j . Comme la similarit est symtrique, nous avons si, j = s j,i pour tout
i, j
i, j
(i, j) dans {1, n2 }. Notons I1 = [0,ti, j ] et I2 = [ti, j , 1].
Nous avons choisi les rgles suivantes pour dterminer la dcision de lIDS dans le cas de n serveurs :
i, j

(i, j) {1, n}2 , i < j, si, j I1

(i,

j) {1, n}2 , i

<

i, j
j, si, j I2

Alerte
Pas d 0 alerte

cest--dire quune alerte est mise ds quune similarit si, j est faible (en-dessous de ti, j ). Aucune alerte
nest mise seulement lorsque toutes les similarits calcules sont suprieures leur seuil respectif.
Localisation du serveur compromis La localisation du serveur compromis se base sur la rgle suivante :
i, j
i {1, n}, j {1, n}, j 6= i, si, j I1

Si est compromis
k,l
2
(k, l) {1, n} , k 6= i, l 6= i, sk,l I2
Cette rgle signifie que, sous lhypothse de dcorellation des fautes, il ne doit y avoir quun seul serveur
pour lequel les similarits entre ce serveur et les autres sont faibles, toutes les autres similarits calcules entre les autres serveurs devant tre leves. Dans tous les autres cas o lIDS lve une alerte, la
localisation du serveur compromis nest pas possible.
Exemple pour trois serveurs Le tableau 1 rsume, dans le cas de trois serveurs S1 , S2 et S3 , dans
quels cas une alerte doit tre leve et sil est possible de localiser le serveur compromis en fonction des
similarits calcules.
La localisation nest pas possible dans certains cas : par exemple, si s1,2 et s2,3 sont leves et s1,3
faible. Cela signifie que les comportements de S1 et S2 sont proches, ainsi que les comportements de S2

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

s2,3 I12,3
PP s1,3
I11,3
s1,2 PPP
P
I11,2
A/?
I21,2
A/S3

PP

s2,3 I22,3

I21,3

I11,3

I21,3

A/S2
A/?

A/S1
A/?

A/?
NA

TAB . 1: Alertes et localisation du serveur compromis dans le cas N = 3 ; A signifie alerte, NA signifie pas dalerte, ?
signifie que la localisation nest pas possible, Si signifie que le serveur Si est considr comme compromis

et S3 mais que les comportements de S1 et S3 sont diffrents. Il nest pas possible dexhiber partir du
calcul de similarit un serveur dont le comportement est diffrent des deux autres.
hhhh

hhhhIDS bote grise

alerte
hhhh
IDS bote noire
hhh
alerte
alerte
pas dalerte
alerte

pas dalerte
alerte
pas dalerte

TAB . 2: Corrlation entre lapproche bote noire et lapproche bote grise

Corrlation entre lapproche bote noire et lapproche bote grise Nous utilisons les deux approches
conjointement. Le tableau 2 rsume la dcision prise par la combinaison en cas de dsaccord. Si un des
deux IDS lve une alerte, nous avons dcid que la combinaison des deux IDS lvera galement une
alerte. Si aucune des deux mthodes ne lve une alerte, aucune alerte nest leve.

Diagnostic danomalies
2954 apache
1072 abyssws.exe
15 /private/var/log/httpd/error_log

260 log/access.log

300 socket

978 abyssws.exe

a. Graphe de flux dinformation pour le serveur web Abyss

12971 buggy

5 socket

17 /private/var/log/httpd/access_log

b. Graphe de flux dinformation pour le serveur web Apache

12970 buggy

6 /home/daddi/htdocs/log/127.0.0.1_33594

4 socket
5 /home/daddi/htdocs//../../../../../etc/passwd

c. Graphe de flux dinformation pour le serveur web vulnrable

F IG . 3: Trois graphes de flux dinformation lis une mme requte HTTP traite sur diffrents serveurs et lidentification des objets qui ne sont pas mapps

En calculant la similarit entre les graphes, nous obtenons galement les objets actifs (processus),
les objets passifs (fichiers, sockets, pipes, . . .) et les flux dinformation non mapps dans le meilleur

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

Apache
2954 proc.
2954 proc.
5 socket
15 file
17 file
5 2954
2954 15
2954 17

serveur vulnrable
12971 proc.
12970 proc.
4 socket
6 file
6 file
4 12971
12971 6
12971 6

Apache
2954 proc.
2954 proc.
5 socket
15 file
17 file
5 2954
2954 5
2954 15
2954 17

Abyss
1072 proc.
978 proc.
300 socket
260 file
260 file
300 1072
1072 300
1072 260
1072 260

Abyss
1072 proc.
978 proc.
300 socket
260 file
300 1072
1072 260
978 1072

serveur vulnrable
12971 proc.
12970 proc.
4 socket
6 file
4 12971
12971 6
12970 12971

TAB . 3: Meilleurs mappings entre les objets et mappings entre les flux dinformation pour chaque couple de serveurs :
le pid ou le descripteur de fichier est utilis pour faire le lien avec les graphes de la figure 3 (proc. signifie processus) ;
les flux dinformation sont nots : pid fd, fd pid or pid pid. Les objets et les flux dinformation sur la mme
ligne dans un tableau sont mapps ensemble dans le meilleur mapping

mapping, cest--dire celui pour lequel la similarit est maximale. Le meilleur mapping dpend du calcul
de la similarit et donc des fonctions f et g choisies (voir le paragraphe Choix des fonctions f et g
dans la sous-section 6 pour les choix que nous avons faits pour ces fonctions dans notre prototype). En
cas dintrusion, les objets non mapps sont les effets visibles au niveau de lOS de lexploitation dune
vulnrabilit. Lanalyse de ces objets permet dobtenir des informations sur lintrusion : processus crs,
fichiers lus ou crits, sockets cres, etc. Sil nest pas possible de retrouver directement la vulnrabilit
exploite, ces informations peuvent y conduire. Dans le cas dun zero-day, cela peut constituer un bon
point de dpart pour dcouvrir la vulnrabilit inconnue.
Nous proposons de montrer ladministrateur de scurit du systme les graphes des diffrents serveurs
pour la requte suspecte en mettant en valeur les objets et les flux non mapps. La figure 3 montre un
exemple simple dune intrusion contre la confidentialit dun serveur web vulnrable qui a t dvelopp
dans un but pdagogique. Lintrusion consiste en une attaque par remonte dans larborescence pour
aller lire le fichier /etc/passwd. Le serveur vulnrable ne vrifie pas la prsence de ../ dans la chane de
caractres de lurl alors que les deux autres serveurs refusent de traiter une telle requte et renvoient une
erreur au client.
Le meilleur mapping pour chaque couple de serveurs est donn dans le tableau 3. Dans ce tableau, le
pid (pour les processus) ou le descripteur de fichier (pour les sockets et les fichiers) sert de lien avec les
nuds de la figure 3. Les nuds sur la mme ligne dun tableau sont associs ensemble dans le meilleur
mapping. Les flux dinformation sont nots par : pid fd, fd pid et pid fd (fd pour descripteur de
fichier). Les flux dinformation sont considrs comme associs dans le meilleur mapping entre les nuds
(il faut noter quun mapping m est une relation entre les nuds des deux graphes : voir la sous-section
4.2). Comme pour les nuds, les flux dinformation sur la mme ligne dun tableau sont considrs
comme mapps ensemble.
Lobjet fichier reprsentant le fichier /etc/passwd nest associ avec aucun des objets dans les autres
graphes. Cest le cas galement pour le flux dinformation reprsentant laccs en lecture au fichier
/etc/passwd et lcriture sur la socket. Ces objets sont mis en vidence sur la figure 3. Pour le serveur
Apache comme pour le serveur Abyss, les flux dinformation reprsentant lcriture sur la socket ne sont
pas mapps avec leur quivalent dans le graphe du serveur vulnrable mais sont associs ensemble dans
le mapping concernant Abyss et Apache. Ils sont donc mis en valeur mais dune manire moins visible.
Nous pensons que cette approche peut tre rellement bnfique un oprateur de scurit et peut tre
tendue pour automatiquement tablir un rsum des interactions impliquant les objets non mapps.

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

Gnrateur
de graphes

Proxy HTTP
Parefeu

P + es
TT
h
s H rap
te de g
u
q
s
P
Re ute
T
q
T
Re
s H es
se
h
n
p
a
po
Gr
R
+

Wrapper

Gnrateur
de graphes

Moniteur
dappels
systme
Serveur web

Moniteur
dappels
systme

IDS bote noire +

IDS bote grise par

Wrapper

Serveur web

comparaison des graphes

Gnrateur
de graphes

Wrapper

Moniteur
dappels
systme
Serveur web

F IG . 4: Architecture de lIDS par fond sur la similarit entre graphes de flux

Prototype et rsultats

Nous avons dvelopp un prototype dIDS fond sur la similarit entre graphes de flux dinformation
que nous utilisons en conjonction avec lIDS bote noire [TMM05]. Nous allons dabord prsenter les
lments de larchitecture, puis nous voquerons la modlisation des appels systmes et le choix des
fonctions f et g utilises dans le calcul de la similarit. Finalement, nous prsenterons les rsultats des
tests effectus.

6.1

Architecture de lIDS

Dans notre prototype, nous avons utilis trois serveurs web diffrents : un serveur thttpd ou Lighttpd
tournant sur Linux, un serveur Abyss tournant sur Windows 2000 Server et un serveur Apache tournant
sur Mac-OS X. Larchitecture prsent figure 4 est compose de plusieurs lments : un proxy HTTP,
lIDS fond sur la similarit entre graphes de flux dinformation et, sur chaque serveur, un wrapper, un
gnrateur de graphes et un logger dappels systme. Le proxy HTTP a le rle classique utilis dans ce
type darchitectures : il reoit les requtes provenant des clients et les transfre tous les serveurs ; il
attend ensuite leurs rponses et en renvoie une suivant le dcision de lIDS. LIDS calcule la similarit
entre les graphes de flux dinformation et lve une alerte dans les cas explicits dans la section 4.3. Le rle
du wrapper est de lier une requte particulire avec les temps de dbut et de fin de cette requte. Il reoit
une requte HTTP du proxy, stocke le temps de dbut de cette requte et la transfre au serveur. Il renvoie
la rponse du serveur et, la fin de cette rponse, stocke le temps de fin. Il demande ensuite le graphe de
flux dinformation correspondant au temps de dbut et de fin de la requte et envoie ce graphe au proxy.
Il nest pas toujours possible de dterminer la correspondance entre les appels systmes et les requtes,
cest--dire de dterminer quelle requte correspond un appel systme. Pour rsoudre ce problme, les
requtes peuvent tre srialises pour sassurer que le serveur ne traite quune requte la fois. Le rle
du moniteur dappels systme est denregistrer les appels systmes effectus par le serveur web et de
les envoyer au gnrateur de graphes. Ce dernier construit les graphes de flux dinformation partir des
appels systmes et les renvoie sur demande du wrapper.

6.2

Modlisation des appels systme

Nous avons instrument environ 20 appels systmes sur chaque OS utilis. Tous les appels systme
gnrant des flux dinformation except trois que nous prsentons dans la suite correspondent au modle
des flux dinformation prsent dans la sous-section 4.1. Par exemple, un processus excutant un appel
systme read est lobjet actif de lopration de lecture du modle ; le fichier, la socket ou le pipe lu est

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

lobjet passif. Cet appel systme correspond une opration de lecture du modle et cre donc un flux
dinformation de lobjet passif vers lobjet actif, tiquet par les donnes lues.
Cependant certains flux dinformation lintrieur du systme dexploitation sont difficiles modliser.
Les appels systmes qui crent un autre thread tel que clone (sur Linux) permettent aux processus pre
et fils de communiquer ensemble par lintermdiaire de la mmoire. Il est possible de surveiller tous les
flux de communications entre ces processus mais cela ncessite de vrifier tous les accs mmoire des
processus pre et fils, ce qui a un impact important sur les performances. Nous avons donc dcid de
modliser lappel systme clone par deux flux dinformation : un du pre vers le fils et un du fils vers le
pre. Ces flux dinformation ont des tiquettes donne vides.
Les appels systmes crant un nouveau processus tels que fork sur Linux correspondent une opration
execute du modle. Pour la mme raison que prcdemment, le flux dinformation cr par cet appel
systme a une tiquette donne vide.
Les appels systmes tels que mmap peuvent galement tre la source de flux dinformation qui ne
peuvent tre modliss sans observer les accs mmoire des processus. Lappel systme mmap permet
un processus de projeter en mmoire un fichier. Lire ou crire dans le fichier se fait tout simplement par
des lectures ou des critures en mmoire. Suivant les argument de mmap, nous avons dcid de crer des
flux dinformation entre le processus qui excute cet appel systme et le fichier considr. Si la projection
est en lecture seule (resp. criture seule), un flux dinformation du fichier (resp. du processus) vers le
processus (resp. le fichier) est cr. Si la projection est en mode lecture-criture, deux flux dinformation
sont crs du processus vers le fichier et du fichier vers le processus. Ces flux dinformation ont galement
des tiquettes donne vides.
Notre prototype ne prend pas en compte certains mcanismes dIPC tels que les messages et les mmoires partages et les signaux. Les mcanismes dIPC peuvent tre modliss par des objets passifs.
Les signaux crent des flux dinformation entre le processus qui envoie le signal et celui qui le reoit. Il
est donc possible de les modliser par un flux dinformation avec une tiquette donne qui contient le
numro du signal envoy.

6.3

Choix des fonctions f et g

Ces fonctions ont un impact important sur le calcul de la similarit. Il faut les choisir convenablement
pour reflter la signification des mappings effectus lors du calcul de la similarit. Dans notre prototype,
nous avons test deux fonctions diffrentes pour f et une pour g. Dabord, nous avons choisi pour f et
g la cardinalit des ensembles considrs. Ensuite, nous avons modifi f sans changer g. En utilisant les
mmes notations que dans la sous-section 4.2, on considre S V1 V2 E1 E2 et (v, v0 , l) rE1 rE2 .
f est dfini par :
/ = 0
f (0)
f (S v) =
f (S {(v, v0 , l}) =

f (S) + 1
f (S) + 1 i f l 6= PROCESS_T O_FILE

f (S {(v, v0 , l}) =

f (S) + 3 i f l = PROCESS_T O_FILE

Avec cette fonction f , si un flux dinformation de type PROCESS_TO_FILE nest pas mapp, cela
va entraner une baisse plus importante de la similarit entre les deux graphes considrs. Cette fonction
permet de mettre laccent sur la dtection des attaques contre lintgrit du serveur.

6.4

Tests sur un serveur web statique

Dtermination des seuils ti, j Comme expliqu dans la sous-section 4.2, les seuils ti, j doivent tre choisis exprimentalement pour chaque couple de serveurs utiliss. Nous avons dcid de les fixer de telle
manire que, pour la plupart des requtes HTTP, notre prototype ne lve pas dalertes, cest--dire que la
majorit des similarits calcules est suprieure aux seuils ti, j .

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

Dispersion des requtes
100000

similarit entre thttpd et Apache

similarit entre Apache et Abyss
similarit entre thttpd et Abyss

Nombre de requtes

10000

1000

100

10

0.1

0.2

0.3

0.4

0.5
Similarit

0.6

0.7

0.8

0.9

F IG . 5: Rpartition des requtes en fonction de la similarit pour chaque couple de serveurs (le nombre de requtes
est exprim en chelle logarithmique)

Nous avons utilis en tant quensemble de requtes normales, les requtes provenant du fichier de log
du serveur web du campus de Suplec. Cet ensemble de requtes couvre une semaine et est constitu de
71 596 requtes. Pour vrifier que cet ensemble ne contienne pas dintrusions contre lun des serveurs
utiliss, nous avons utilis lIDS bote noire et WebSTAT [VRKK03]. Notre prcdent IDS lve 197
alertes qui se sont rvles tre des faux positifs. WebSTAT lve 33 alertes qui se sont galement rvles
tre des faux positifs.
La figure 5 reprsente la rpartition des requtes pour les trois couples de serveurs utiliss lors de nos
tests. Cette figure nous permet de dterminer les seuils ti, j . Nous avons choisi de fixer les trois seuils
0,7. Dans ce cas, plus de 99,5% des requtes sont considres comme normales par notre IDS (le nombre
de requtes sur la figure est exprim en chelle logarithmique).
Notons S1 le serveur thttpd, S2 le serveur Apache et S3 le serveur Abyss et si, j les similarits correspondantes. Le tableau 4 rsume les alertes leves par notre prototype pour la semaine dapprentissage, tous
les seuils tant fixs 0,7. Notre prototype lve 247 alertes, ce qui reprsente un taux de faux positifs de
0,35%. Loprateur de scurit doit alors analyser environ 35 alertes par jour.
s2,3 I12,3
PP s1,3
I11,3
s1,2 PPP
P
I11,2
0 (A/?)
I21,2
7 (A/S3 )

PP

s2,3 I22,3

I21,3

I11,3

I21,3

0 (A/S2 )
11 (A/?)

212 (A/S1 )
16 (A/?)

1 (A/?)
71 349 (NA)

TAB . 4: Nombre dalertes et identification du serveur considr comme compromis pour la semaine dapprentissage ;
A signifie alerte, NA signifie pas dalerte, ? signifie que la localisation nest pas possible, Si signifie que le serveur Si
est considr comme compromis

Rsultats Pour valuer lIDS propos, nous avons utilis un autre ensemble de requtes HTTP logges
par le serveur web de notre campus pendant une semaine. Cet ensemble est compos de 105 228 requtes.

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

WebSTAT gnre seulement 4 alertes pour cette semaine : 3 alertes correspondent des attaques qui
chouent contre les serveurs de notre architecture et la dernire ne correspond pas une attaque et est
donc un vrai faux positif. Pour cette semaine de test, lIDS bote noire lve 50 alertes et lIDS bote grise
140 alertes (voir tableau 6). Le tableau 5 utilise la mme notation que le paragraphe prcdent et montre
la localisation du serveur compromis lorsque cest possible. Toutes ces alertes sont des faux positifs :
elles ne sont en effet pas des des intrusions. Cela reprsente un taux de faux positifs de 0,13% et 20
alertes par jour.
La combinaison des deux IDS lve 180 alertes : les deux IDS ne sont daccord que sur deux requtes.
Cela reprsente un taux de faux positifs de 0,18% et environ 28 alertes par jour.
s2,3 I12,3
PP s1,3
I11,3
s1,2 PPP
P
I11,2
0 (A/?)
I21,2
2 (A/S3 )

PP

s2,3 I22,3

I21,3

I11,3

I21,3

0 (A/S2 )
1 (A/?)

120 (A/S1 )
16 (A/?)

1 (A/?)
105 088 (NA)

TAB . 5: Nombre dalertes et identification du serveur considr comme compromis pour la semaine de test ; A
signifie alerte, NA signifie pas dalerte, ? signifie que la localisation nest pas possible, Si signifie que le serveur Si
est considr comme compromis

hhhh

hhhhIDS bote grise

alerte
hhhh
IDS bote noire
hhh
alerte
2 (A)
pas dalerte
138 (A)

pas dalerte
48 (A)
105 040 (NA)

TAB . 6: Corrlation entre les deux approches sur la semaine de test

6.5

Tests sur un serveur web dynamique

Dans cette partie, nous valuons, dans le contexte dun serveur web dynamique, les taux de faux positifs
et de faux ngatifs. Nous avons install sur les trois serveurs une application web Bibtex Manager . Cette
application est dveloppe en php et repose sur une base de donne. Nous avons enregistr 86 requtes
correspondant une utilisation normale de lapplication. Nous avons introduit dans une des versions des
vulnrabilits permettant des intrusions classiques dans le domaine des applications web : une injection
SQL dans la page dauthentification qui permet notamment de sauthentifier sans avoir de compte, une
vulnrabilit de type directory traversal permettant dcrire un fichier dans un rpertoire notamment
en dehors de lespace web, une vulnrabilit permettant lupload puis lexcution de code php et une
vulnrabilit de type cross site scripting (XSS). Nous avons dvelopp des attaques permettant dexploiter
ces vulnrabilits et les avons testes avec notre IDS.
Toutes ces intrusions sont immdiatement dtectes par lIDS de type bote noire que nous avons
dvelopp prcdemment lexception du XSS, qui est cependant dtect lorsque quune page contenant
lentre corrompue est demande.
Les similarits entre les diffrents graphes correspondant aux intrusions ( lexception du XSS) sont
infrieures celles des requtes normales. En moyenne, pour les requtes normales, la similarit est
environ de 0,95, alors que, pour les attaques, celle-ci est infrieure 0,8. LIDS bote grise que nous
proposons est incapable, comme lIDS bote noire, de dtecter le XSS. Cependant, contrairement lIDS
www.supelec-rennes.fr/ren/perso/etotel/PhpBibtexDbMng/index.html

Frdric Majorczyk, ric Totel, Ludovic M, Ayda Saidane

hhhh
h

hhhh Intrusions injection

hhhh
Similarit entre
h
h SQL

criture

Lighttpd et Apache
Apache et Abyss
Lighttpd et Abyss

0.725
0.9715
0.7209

0.9655
0.7742
0.7838

excution
dun script
php
0.5882
0.6364
0.6667

XSS
(insertion)
0.9677
0.9677
1

XSS (lecture
de lentre
corrompue)
0.9143
0.9706
0.9189

TAB . 7: Similarits entre les graphes des diffrents serveurs dans le cas des intrusions

bote noire, il ne dtecte pas non plus lintrusion lorsquune requte demande une page contenant lentre
corrompue. En effet, dans ce cas, le comportement des serveurs est proche en terme de flux dinformation :
seules les donnes envoyes diffrent. Le tableau 7 rsume les diffrentes similarits obtenues pour les
intrusions.
La localisation du serveur compromis est immdiatement visible partir des similarits dans les cas
des deux premires intrusions. Dans le cas de linjection SQL, les similarits concernant le serveur Abyss
sont plus faibles et dans le cas de lcriture dun fichier par directory traversal, les similarits concernant
le serveur Lighttpd sont plus faibles. Ce nest pas le cas dans la troisime intrusion teste cause de
diffrences de spcifications entre les serveurs qui entranent une similarit basse entre tous les serveurs.
En plaant le seuil pour chaque couple de serveurs 0,8, notre prototype est capable de dtecter toutes
les intrusions lexception du XSS et lve 6 fausses alertes lorsque lon rejoue les 86 requtes normales
enregistres prcdemment.
Ces tests montrent que notre prototype est capable de dtecter des intrusions, lorsque celles-ci impliquent une diffrence dans le comportement des serveurs. Actuellement, le taux de faux positifs reste
sensiblement lev et des travaux doivent encore tre mens dans lobjectif de le faire diminuer.

Conclusion

Cette approche de dtection dintrusions semble intressante, tant en termes de faux positifs que de
faux ngatifs. Une approche bote noire [TMM05] a t tendue par lutilisation dune approche bote
grise qui permet de rsoudre certains de ses dfauts :
la possibilit de dtecter des attaques lencontre de lintgrit des serveurs qui peuvent ne pas tre
dtectes si lon ne compare que les sorties rseaux des serveurs ;
Lapport dun premier diagnostic et dune aide au diagnostic : ceci est un rsultat important car les
IDS comportementaux ne fournissent en gnral aucune information sur la nature des alertes mises.
Les futurs travaux sorienteront dans plusieurs sens. Il est ncessaire de rduire le nombre de faux positifs. Ces alertes sont des la prsence de diffrence de spcification ou de conception. Il est possible
dintroduire des mcanismes de masquage, pour reconnatre les cas o une alerte est mise sans quune
intrusion ait eu lieu. Ce travail va tre li un approfondissement de la fonction de diagnostic. Un diagnostic plus volu permettra certainement de reconnatre les faux positifs des vrais positifs (cest--dire
les fausses alertes des vraies intrusions).

Rfrences
[BP76]

D. E. Bell and L. J. La Padula. Secure computer system : Unified exposition and multics
interpretation. Technical report, MITRE Co., 1976.
[CEF+ 06] Benjamin Cox, David Evans, Adrian Filipi, Jonathan Rowanhill, Wei Hu, Jack Davidson,
John Knight, Anh Nguyen-Tuong, and Jason Hiser. N-variant systems : A secretless frame-

Dtection dintrusions et diagnostic danomalies dans un systme diversifi

work for security through diversity. In Proceedings of the 15th USENIX Security Symposium,
Vancouver, Canada, August 2006.
[CS03]

Pierre-Antoine Champin and Christine Solnon. Measuring the similarity of labeled graphs.
In in Proceedings of the 5th International Conference on Case-Based Reasoning (ICCBR
2003), pages 8095, Trondheim, Norway, June 2003.

[dA94]

Bruno dAusbourg. Implementing secure dependencies over a network by designing a distributed security subsystem. In Proceedings of the European Sysmposium on Research in
Computer Security (ESORICS94), pages 249266, 1994.

[GPSS04] Ilir Gashi, Peter Popov, Vladimir Stankovic, and Lorenzo Strigini. On Designing Dependable
Services with Diverse Off-The-Shelf SQL Servers, volume 3069 of Lecture Notes in Computer
Science, pages 196220. Springer-Verlag, 2004.
[GRS05]

Debin Gao, Michael K. Reiter, and Dawn Song. Behavioral distance for intrusion detection. In Proceedings of the 8th International Symposium on Recent Advances in Intrusion
Detection (RAID 2005), pages 6381, Seattle, WA, September 2005.

[GRS06]

Debin Gao, Michael K. Reiter, and Dawn Song. Behavioral distance measurement using hidden markov models. In Proceedings of the 9th International Symposium on Recent Advances
in Intrusion Detection (RAID 2006), pages 1940, Hamburg, Germany, September 2006.

[JRC+ 02] James E. Just, James C. Reynolds, Larry A. Clough, Melissa Danforth, Karl N. Levitt, Ryan
Maglich, and Jeff Rowe. Learning unknown attacks - a start. In Andreas Wespi, Giovanni
Vigna, and Luca Deri, editors, Proceedings of the 5th International Symposium on Recent
Advances in Intrusion Detection (RAID 2002), volume 2516 of Lecture Notes in Computer
Science, pages 158176, Zurich, Switzerland, October 2002. Springer.
[PN97]

Phillip A. Porras and Peter G. Neumann. EMERALD : Event monitoring enabling responses
to anomalous live disturbances. In Proc. of the 20th National Information Systems Security
Conference, pages 353365, Baltimore, MD, October 1997.

[TMM05] Eric Totel, Frdric Majorczyk, and Ludovic M. COTS diversity based intrusion detection
and application to web servers. In Proceedings of the 8th International Symposium on Recent
Advances in Intrusion Detection (RAID 2005), pages 4362, Seattle, WA, september 2005.
[VAC+ 02] Alfonso Valdes, Magnus Almgren, Steven Cheung, Yves Deswarte, Bruno Dutertre, Joshua
Levy, Hassen Sadi, Victoria Stravidou, and Tomas E. Uribe. An adaptive intrusion-tolerant
server architecture. In Proceedings of the 10th International Workshop on Security Protocols,
pages 158178, Cambridge, United Kingdom, April 2002.
[VNC03]

Paulo E. Verssimo, Nuno F. Neves, and Miguel P. Correia. Intrusion-tolerant architectures :

Concepts and design. In Architecting Dependable Systems, volume 2677 of Lecture Notes in
Computer Science. Sptringer-Verlag, April 2003.

[VRKK03] Giovanni Vigna, William Robertson, Vishal Kher, and Richard A. Kemmerer. A stateful
intrusion detection system for world-wide web servers. In Proceedings of the Annual Computer Security Applications Conference (ACSAC 2003), pages 3443, Las Vegas, Nevada,
December 2003.
[WWB01] Rong Wang, Feiyi Wang, and Gregory T. Byrd. Design and implementation of acceptance
monitor for building scalable intrusion tolerant system. In Proceedings of the 10th International Conference on Computer Communications and Networks, pages 2005, Phoenix, AZ,
October 2001.