Les systèmes de détection

d'intrusions dans un
environnement Linux

Stage effectué par Clément Gauthey

A l'INRA de Jouy-en-Josas
Du 03 avril au 09 juin 2006
Sous la responsabilité de Christophe Caron

Clément Gauthey – IUT informatique René Descartes – 2006

1/50
Remerciements

Je tiens avant tout à remercier les responsables de l'INRA de Jouy-en-Josas pour m'avoir
accueilli au sein de leur entreprise, et plus particulièrement mon maître de stage, Christophe Caron,
pour son soutien et ses bons conseils tout au long de mon séjour à l'unité MIG. Je remercie
également toutes les autres personnes qui m'ont aidé.

Un grand merci aux enseignants de mon université qui m'ont permis, grâce à leurs cours et à
leurs travaux dirigés, d'obtenir les connaissances nécessaires à la réussite de mon stage et à mon
intégration dans le monde du travail.

Clément Gauthey – IUT informatique René Descartes – 2006

2/50
Table des matières

Introduction.......................................................................................................................................... 4
1. Environnement professionnel........................................................................................................... 6
1.1. INRA.........................................................................................................................................6
1.2. Centre de Jouy-en-Josas............................................................................................................9
1.3. Unité MIG et la plateforme Migale........................................................................................ 10
2. Analyse du sujet............................................................................................................................. 11
2.1. Existant................................................................................................................................... 11
2.2. Cahier des charges.................................................................................................................. 13
2.3. Systèmes de détection d'intrusions......................................................................................... 15
2.3.1. Caractéristiques............................................................................................................... 15
2.3.2. Choix du système de détection........................................................................................18
2.4. Snort........................................................................................................................................20
2.4.1. Architecture réseau......................................................................................................... 20
2.4.2. Fonctionnement...............................................................................................................22
3. Mise en oeuvre du système de détection........................................................................................ 25
3.1. Démarche de mise en oeuvre.................................................................................................. 25
3.2. Gestion des intrusions.............................................................................................................27
3.2.1. Réactions immédiates : blocages et alertes..................................................................... 27
3.2.2. Consultations et analyses................................................................................................ 28
3.3. Optimisation du système de détection d'intrusions.................................................................33
3.3.1. Amélioration de la sécurité............................................................................................. 33
3.3.2. Amélioration des performances...................................................................................... 37
3.4. Validations et résultats............................................................................................................40
Conclusion.......................................................................................................................................... 46
A. Lexique.......................................................................................................................................... 48
B. Ressources documentaires............................................................................................................. 51

Clément Gauthey – IUT informatique René Descartes – 2006

3/50
Introduction

La deuxième année d'IUT informatique se conclut par un stage en entreprise nécessaire à

l'obtention du diplôme. Cette pratique permet d'apporter aux étudiants une vision du monde du
travail plus réaliste mais aussi de les orienter sur leur poursuite d'études. C'est dans ce cadre que j'ai
effectué mon stage dans le service informatique de l'unité MIG (Mathématique, Informatique et
Génome) de l'INRA (Institut National de Recherche Agronomique) de Jouy-en-Josas.

L'institut fait partie du milieu de la recherche qui m'a toujours attiré : les sciences et la
découverte de nouveaux éléments me motivent. Ce stage me permettra donc d'en apprendre
davantage sur les activités d'une unité de recherche. Ainsi je disposerai d'informations
supplémentaires qui me permettront d'évaluer mon intérêt pour les métiers de ce milieu.
D'autre part, les domaines du réseau, des systèmes et de la sécurité interviennent dans le stage.
Hors, je trouve que la mise en pratique de ces derniers me permettrait de mieux les comprendre et
de valider les nombreuses connaissances acquises.
Enfin, ma formation universitaire étant orientée vers le développement de logiciels, ce stage me
permettra également d'élargir mes compétences.

De nos jours, l'ouverture des entreprises au monde extérieur devient de plus en plus
nécessaire pour offrir des services adaptés aussi bien aux employés, aux clients ou encore aux
partenaires. Cette ouverture augmente considérablement les risques d'attaques informatiques par des
personnes malveillantes dont le but est souvent un gain financier ou simplement un amusement.
L'objectif du stage consiste à mettre en place, suite à l'apparition de problèmes de sécurité sur des
machines sensibles de l'unité MIG, un système de détection des intrusions apportant des
fonctionnalités de réaction face à une attaque. La difficulté concerne principalement le système de
détection des intrusions lui-même, car l'unité n'a jusqu'à lors aucune donnée précise sur son
fonctionnement, son efficacité et les conséquences de son implantation sur le réseau. L'unité ne
cherche pas à obtenir une sécurité maximale, mais elle souhaite mettre un système fiable de
détection d'intrusions afin de d'améliorer la sécurité.

Clément Gauthey – IUT informatique René Descartes – 2006

4/50
 Dans un premier temps, je vous présenterai l'environnement professionnel de mon stage,
c'est-à-dire l'institut, et ceci au travers de son organisation et de son évolution.
Dans un second temps, je vous expliquerai l'activité dominante de mon stage en montrant la
démarche effectuée pour répondre à la problématique. J'expliciterai l'étude et la mise en place du
système de détection dans la situation actuelle sans oublier les tests et les résultats obtenus.

Clément Gauthey – IUT informatique René Descartes – 2006

5/50
1. Environnement professionnel

1.1. INRA

L'Institut National de la Recherche Agronomique a été créé en 1946 dans le contexte de la

reconstruction nationale d'après guerre et de la modernisation de l'agriculture française. Il fait parti
des établissements publics à caractère scientifique et technologique (EPST).

Au cours des dernières années, son objectif premier a largement été modifié. En effet, à
l'origine l'institut n'avait en charge que la remise en condition de l'agriculture française suite aux
désastres engendrés de la Seconde Guerre Mondiale en s'appuyant sur la science et la technologie.
Fort de ce succès, l'INRA a pu se diriger par la suite vers des objectifs plus large mêlant
l'agriculture à l'environnement et à l'alimentation. On retrouve donc les secteurs d'activité suivants :

− la protection des ressources naturelles,

− l'alimentation humaine et la sécurité des aliments,

− l'informatique et la biologie à haut débit,

− la biologie intégrative : du génome aux populations végétales, animales et microbiennes,

− les sciences sociales pour éclairer les acteurs publics et privés.

Aujourd'hui, l'INRA se préoccupe d'éléments plus complexes afin de favoriser un

développement durable aussi bien en France que sur planète entière. Ainsi l'institut se doit par
exemple d'intégrer à son programme la gestion, l'écologie et la préservation des ressources
naturelles et de la biodiversité ou encore la validité économique et le bien-être social. De plus en
plus, l'institut apporte son expertise et son aide à la société pour répondre aux besoins et aux
nécessités actuelles mais également futures.

Le premier institut de recherche agronomique européen comprend près de 8850 personnes

dont la moitié sont des ingénieurs ou des chercheurs. Il s'appuie sur 14 départements scientifiques et
sur 21 centres répartis sur l'ensemble du territoire français. Chaque unité de recherche est rattachée
à un département scientifique spécialisé dans un domaine d'étude. On se retrouve donc avec deux

Clément Gauthey – IUT informatique René Descartes – 2006

6/50
niveaux d'organisation : une organisation géographique avec les centres et une organisation de
recherche avec les départements. Il faut également savoir que se sont les départements qui pilotent
et coordonnent les activités des unités de recherche.

Organigramme de l'INRA

Répartition des centres de l'INRA sur le territoire français

Clément Gauthey – IUT informatique René Descartes – 2006

7/50
 Au niveau financier, le budget de l'institut n'a fait qu'augmenter au cours des dernières
années. En 2003, il était de 573 millions d'euros, alors que l'année dernière, en 2005, il se situait
autour des 680 millions d'euros.

La principale recette de l'institut (82% des recettes) provient du budget civil de recherche-
développement (6%). Elle correspond aux subventions des ministères de tutelle (ministère délégué à
l'Enseignement et à la Recherche, et ministère de l'Agriculture et de la Pêche).

Clément Gauthey – IUT informatique René Descartes – 2006

8/50
1.2. Centre de Jouy-en-Josas

Le centre INRA de Jouy-en-Josas a été créé en 1950. Sa construction a été lancée seulement
quelques années après la création de l'institut afin de mener des recherches scientifiques sur les
espèces d'élevages telles que les bovins, les volailles ou encore les poissons.

D'une superficie de 70000m2, il abrite 30 laboratoires et près de 1300 personnes soit environ 15%
des effectifs totaux. On rencontre parmi ce personnel une importante diversité de métiers. Ainsi
animaliers, biologistes, biochimistes, informaticiens, nutritionnistes, vétérinaires, généticiens, mais
aussi documentalistes, gestionnaires, et techniciens de maintenance se côtoient pour participer aux
activités de recherche du centre.

Les activités du centre de Jouy-en-Josas sont principalement liées aux productions animales et à
l'agro-alimentaire et plus précisément à la génétique des animaux d'élevage, à la microbiologie, à la
nutrition humaine ou à la biométrie. Il offre des nouveaux axes de développements et de recherches
grâce à la mise en place de la biologie intégrative et de la bioinformatique.

Le site de Jouy-en-Josas dispose par ailleurs d'un budget de 29 millions d'euros dont 62%
proviennent de subventions de l'Etat, le reste des recettes et des contrats. Depuis toujours, l'INRA
mène en effet une étroite collaboration avec les industriels et le monde agricole, ce qui a donné
naissance à de nombreux contrats entre ces différents éléments.

Clément Gauthey – IUT informatique René Descartes – 2006

9/50
1.3. Unité MIG et la plateforme Migale

L'unité Mathématique, Informatique et Génome a été crée en 2000 pour répondre aux
avancées de la bioinformatique. Elle a pour mission de :

− développer des méthodes et des outils d'analyse des génomes in silico,

− mettre en place des systèmes d'information pour la génomique,

− participer à des projets de génomique choisis pour leur intérêt scientifique ou stratégique.

Cette unité est rattachée à trois départements PHASE (Physiologie Animale et Systèmes
d'Elevages), MICA (Microbiologie et Chaîne Alimentaire), et MIA (Mathématique et Informatique
Appliquées).

La plateforme bionformatique hébergée au sein de l'unité MIG regroupe un ensemble de

ressources dédiées à la bioinformatique. Elle appartient au réseau national de bioinformatique
(ReNaBi). Ces ressources regroupent à la fois des outils développés par l'unité MIG et les outils mis
à disposition par la communauté. Un portail web propose également les collections de banques et de
bases de données biologiques génériques ou thématiques.

Cette plateforme possède un ensemble de ressource matérielle allant de machines de

stockage de données destinées aux biologistes (banques et bases de données relationnelles), aux
traitements (graphe de calculs), en passant par les services en ligne (interface web). Les principales
missions de la plateforme sont :

− de mettre à disposition des utilisateurs une infrastructure matérielle performante,

− de proposer des développements informatiques (base de données, automatisation, etc.),

− d'organiser la mise en place de formations en bioinformatique,

− de valoriser les outils développés par l'unité MIG,

− d'offrir aux biologistes les outils et les données nécessaires à une analyse bioinformatique,

− de communiquer sur les différentes actions entreprises sur la plateforme,

− d'interagir avec les autres plateformes sur le centre et de participer à la mutualisation de

ressources de stockage et de calcul.

Clément Gauthey – IUT informatique René Descartes – 2006

10/50
2. Analyse du sujet

2.1. Existant

Le centre de Jouy-en-Josas est organisé au niveau informatique de la même manière que les
aux autres centres de l'INRA. Chaque centre possède une EIC (Equipe Informatique de Centre) en
charge de l'informatique collective. L'EIC s'occupe en autre des communications vers l'extérieur et
des connections réseaux Ethernet entre les laboratoires du centre. Ces liaisons entre laboratoires
sont de types fibres optiques. L'EIC ne gère donc pas l'organisation interne des unités. Les centres
sont reliés à l'Internet via le REseau NATional d'Enseignement et de Recherches (RENATER).

La plateforme bioinformatique Migale est constituée à ce jour de plus de 10 serveurs

(serveur de fichiers, serveur web, etc.) et d'un ensemble de postes de travail tournant en majorité
sous un système d'exploitation Linux. Les agents de l'INRA et plus largement la communauté
scientifique peuvent utilisés les ressources (logicielles ou matérielles) présentes sur cette
plateforme.

Parmi les serveurs, certains, de part leurs fonctions, sont ouverts sur l'Internet. Il est évident que ce
type d'ouverture constitue un risque probable de tentatives de piratage. Bien que les
communications soient en partie filtrées par la présence de systèmes de protection (ex: pare-feu)
situées en amont de l'unité, il existe tout de même de nombreux dangers pouvant nuire à son bon
fonctionnement. Avec l'accroissement des ressources de la plateforme durant ces trois dernières
années, le nombre d'utilisateurs et les échanges de données deviennent de plus en plus importants.
Ces nouveaux usages rendent la plateforme encore plus sensible dans le domaine de la sécurité.

Clément Gauthey – IUT informatique René Descartes – 2006

11/50
 Schéma de l'infrastructure de la plateforme Migale

En même temps que cet accroissement de la structure informatique, les responsables de la

plateforme ont constaté lors des précédents mois, plusieurs opérations visant à compromettre la
sécurité. En effet, l'apparition de plus en plus fréquente de tentatives d'intrusions par mot de passe
faible ainsi que des scans de ports ouverts, inquiète fortement les administrateurs.

Dans l'optique d'améliorer la sécurité de la plateforme, un mécanisme de centralisation des journaux

systèmes des serveurs a récemment été mis en place. On utilise pour cela une machine dédiée, que
j'appellerai dans ce rapport Liris.

Malgré le suivi des mises à jour de sécurité, et l'application d'une gestion des comptes
utilisateurs de plus en plus contraignantes, il apparaît aujourd'hui qu'une action plus en amont
pourrait apporter des améliorations notables en matières de sécurisation du réseau informatique de
la plateforme.

Clément Gauthey – IUT informatique René Descartes – 2006

12/50
2.2. Cahier des charges

Suite aux problèmes de tentatives d'intrusions, il devient de plus en plus pressant de mettre
en place des systèmes de détection automatique afin d'augmenter le niveau de sécurité de l'ensemble
du système informatique de l'unité MIG.

Nous avons décidé d'étudier les systèmes de détection d'intrusions (IDS en anglais) notamment les
applications Prelude et Snort, puis de mettre en place celui qui conviendrait le mieux aux besoins
exprimés. Le système choisi devra respecter les exigences suivantes :

1. La politique de détection et de surveillance devra s'intégrer dans la politique informatique de

l'unité mais également dans celle de l'institut. L'unité MIG ne cherche pas à obtenir un
niveau de sécurité très élevé. Il convient donc de ne pas bloquer entièrement la plateforme
simplement pour être sûr de ne laisser passer aucune intrusion.

2. L'IDS devra s'inscrire dans l'architecture modulaire de la plateforme. Un IDS pouvant dans
certains cas se révéler extrêmement complexe et coûteux, l'étude des cas de détections dans
le cadre de la gestion d'un campus ou d'un réseau d'interconnexion ne doit pas être pris en
compte. Il faudra se concentrer sur le côté local de la plateforme, la sécurité du campus
(ports ouverts) étant gérée par EIC.

3. L'intégration du système de détection ne doit pas porter atteinte aux performances actuelles
des serveurs. Ce point est particulièrement important du fait de la nature des traitements de
type calculs intensifs qui sont opérés sur la plateforme.

4. Les machines à surveiller sont principalement des serveurs ouverts vers l'extérieur. Il y en a
actuellement trois, à savoir Tulipe (serveur fichier), Anémone (serveur web), et Edelweiss
(serveur projet). Les intrusions portant sur l'un d'entre eux sont à détecter en priorité.
Néanmoins, à terme une seule machine sera susceptible d'être directement attaquée. Ainsi, la
plupart des choix pourront être fait pour convenir à la situation actuelle, mais il faut tout de
même envisager les possibilités d'évolution.

5. L'unité MIG travaillent principalement avec des logiciels en technologie open source. Le
choix de l'IDS devra en tenir compte. Une première vieille technologique des
administrateurs a permis d'envisager l'étude des solutions Prelude et Snort répondant à ce
critère.

Clément Gauthey – IUT informatique René Descartes – 2006

13/50
6. L'automatisation des tâches est un point primordial. La détection, mais aussi les diverses
actions à entreprendre pour maintenir le système de détection à jour devront se faire sans
intervention de la part des administrateurs.

7. La tracabilité des attaques et la conservation d'un historique doit faire partie de l'étude. La
possibilité d'étudier à posteriori les intrusions et d'obtenir de manière simple des
informations pratiques (machine la plus touchée, port le plus utilisé, etc.) permettrait à
l'administrateur de concevoir un plan de sécurité plus adapté à la plateforme.

Clément Gauthey – IUT informatique René Descartes – 2006

14/50
2.3. Systèmes de détection d'intrusions

2.3.1. Caractéristiques

Un système de détection d'intrusions (IDS) est un outil, logiciel et/ou matériel, permettant de
découvrir une activité anormale sur une machine ou un réseau informatique. Avant de me lancer
dans la mise en place d'un IDS, j'ai réalisé un état de l'art. La veille technologique m'a permis de
trouver de la documentation sur ces derniers m'offrant ainsi des connaissances supplémentaires.
Grâce à cela, je pourrais déterminer plus tard quel système de détection choisir.

Tout d'abord, les IDS disposent de plusieurs approches d'analyse pour rechercher les
éléments suspects. On en dénombre deux principales : l'approche par scénario et l'approche
comportementale, chacune ayant des avantages et des inconvénients.

L'approche par scénario fonctionne en tout point comme un anti-virus. Cette méthode de détection
s'appuie sur une base de données regroupant les signatures des attaques connues. Une signature
correspond à l'emprunte d'une intrusion : elle est donc unique. Ce procédé est donc très efficace
contre les attaques répertoriées dans la base, mais en contrepartie reste inopérant face à des
intrusions inconnues. C'est pourquoi une mise à jour fréquente des signatures est fortement
conseillée pour garantir une meilleure sécurité.

L'approche comportementale compare les activités d'un système au fonctionnement normal que ce
dernier aurait eu dans un environnement sain (dépourvu d'intrusions). Si cette activité ne correspond
pas au comportement attendu, elle est alors considérée comme suspecte. Avec cette approche il est
possible, contrairement à l'approche par scénario, de découvrir de nouvelles attaques. Néanmoins, il
faut savoir que cette méthode consomme relativement plus de puissance machine et également plus
d'espace disque pour sauvegarder les données, ce qui peut être pénalisant pour des machines de
faibles puissances ou exécutant d'autres applications.

Clément Gauthey – IUT informatique René Descartes – 2006

15/50
 Approche par scénario Approche comportementale
- Efficace contre les intrusions - Analyse complète du système
connues - Détection d'intrusions inconnues
Avantages
- Consommation de ressources peu
élevée
- Pas de détection d'attaques non - Forte consommation en ressources
répertoriées - Machine saine avant utilisation
Inconvénients
- Nécessite de mises à jour - Temps d'apprentissage requis pour
régulières déterminer l'état stable du système

Tableau comparatif des approches de détection

Une autre caractéristique des IDS concerne leurs façons de réagir lorsqu'une alerte est
générée. Il existe deux modes de réaction possible : le mode passif ou le mode actif.

Dans le cas du mode passif, l'IDS ne réalisera aucune action pour empêcher l'attaque de se
déclencher. Son objectif principal est d'informer via divers mécanismes une machine et/ou une
personne humaine. Par exemple, il pourrait envoyer un courriel contenant les données d'une
intrusion à l'administrateur ou encore inscrire dans les fichiers journaux du système les alertes
générées.

En mode actif, un IDS est beaucoup plus intéressant car il va pouvoir exécuter des actions pour
stopper une intrusion. Il est alors possible de manipuler d'autres éléments du réseau, comme un
pare-feu, depuis l'IDS afin de bloquer par exemple une communication non autorisée. Dans le cadre
des objectifs déterminés par le cahier des charges, il est clair que posséder ce type de réaction est
indispensable.

Enfin, il existe plusieurs types d'IDS qui sont plus ou moins efficace selon le contexte.

L'HIDS (de l'anglais, Host based IDS) est un mécanisme de détection placé sur une machine unique
et n'analysant que cette dernière. Son utilisation sur les machines susceptibles d'être attaquées et
contenant des données sensibles comme certains serveurs par exemple est donc recommandé. Dans
le cadre de son activité, il est normal qu'il utilise l'approche comportementale car cette dernière est
très efficace dans la surveillance approfondie d'un seul système. L'HIDS se base donc sur une
analyse du réseau (protocoles, horaires d'activité, etc.), de l'activité de la machine (ressources
consommées, nombre et liste des processus et des utilisateurs, etc.) et de l'activité des utilisateurs

Clément Gauthey – IUT informatique René Descartes – 2006

16/50
(horaires de connexion, durée de session, commandes utilisées, etc.). Néanmoins l'impact sur les
performances des différents serveurs due aux analyses trop pointues de l'approche comportementale
n'est pas souhaitable pour aboutir à une meilleure sécurité. L'HIDS ne correspond donc pas aux
spécifications exprimées dans le cahier des charges.

Le NIDS (de l'anglais, Network IDS) permet de contrôler non plus une seule machine mais les flux
circulant sur le réseau. L'avantage réside dans le fait qu'il est alors possible de détecter le passage
d'une intrusion avant même qu'elle n'atteigne sa cible et ceci pour tout ou partie des machines du
réseau. Néanmoins l'architecture de ce réseau ainsi que le type de données peuvent empêcher la
détection d'une attaque. Par exemple, les circuits virtuels privés (VPN) ou encore les données
cryptées bloquent l'analyse du trafic. Par ailleurs, un trop fort débit risque de submerger le NIDS.
Ce dernier ne pourra alors pas scanner l'ensemble des flux, il devient alors un élément peu fiable et
donc dangereux pour la sécurité de la plateforme. Ce point est particulièrement important et
demande une grande attention lors de l'installation d'un NIDS sur le réseau. Il faut trouver des
moyens d'éviter les pertes de données en configurant et paramétrant correctement le système de
détection. Sachant qu'il est également possible d'implanter cet IDS directement sur une machine
hôte, comme pour un HIDS, on peut grâce à cela garder un système de détection efficace tout en ne
surchargeant pas cette dernière.

Il existe un dernier type d'IDS relativement récent appelé le NNIDS (IDS à noeud de réseau). Il
vient corriger les problèmes de submersion du NIDS en intégrant un système de sélection de flux à
analyser. Cependant cette technologie est émergente. De ce fait, nous disposons de très peu de
documentation, et aucun outil en source ouverte n'implémente cet IDS. Nous avons donc décidé de
ne pas le tester, préférant nous servir de moyens connus et fiables pour mettre en place un système
de détection des intrusions.

HIDS NIDS NNIDS

- Analyse pointue d'une - Analyse des flux - Analyse du réseau de
unique machine réseaux manière ciblée
Avantages
- Approche - Détection d'un attaque - Détection d'un attaque
comportementale avant son déclenchement avant son déclenchement
- Fonctionne que sur une - Limité par la - Limité par la
seule machine architecture du réseau architecture du réseau
Inconvénients
- Dégradation des - Possibilité de perte de - Technologie récente peu
performances données implémentée

Tableau comparatif des types d'IDS

Clément Gauthey – IUT informatique René Descartes – 2006

17/50
2.3.2. Choix du système de détection

Après avoir déterminer au mieux les caractéristiques des systèmes de détection d'intrusions,
nous devons maintenant choisir celui qui s'inscrira correctement dans l'architecture de la plateforme
Migale. Les solutions évoquées par les responsables, à savoir Prelude et Snort, offrent toutes les
deux des éléments divergents qu'il convient d'étudier. D'autres solutions existent telles que
l'application Shadow mais sa popularité face aux deux premiers reste très en retrait. De ce fait, je
me suis concentré sur l'étude de Prelude et de Snort. J'ai donc dans un premier temps pour objectifs:

− la validation des deux IDS conformément au cahier des charges,

− la sélection parmi ces solutions de l'IDS adéquate.

Les deux solutions n'ont pas été sélectionnées au hasard par les administrateurs. Elles font
parties des logiciels en source ouverte (dit open source). Ce premier point répond à une exigence de
la plateforme sur les caractéristiques des applications à installer.

Leur forte communauté génère un nombre conséquent de contributions et de documentations. Il est

alors normal qu'elles aient été trouvées plus facilement lors des recherches pré-stage. Une
importante communauté donne également accès à plus d'information. On a généralement plus
confiance quand on sait qu'il existe quelque part des ressources (personnes, documentations, etc.)
capables de répondre à nos questions ou de trouver des solutions à nos problèmes.

Ces deux IDS ont la particularité de fonctionner en mode passif. Hors ce mode ne permet pas de
réaliser des actions sur l'attaque en elle même. Le cahier des charges stipule pourtant de pouvoir
bloquer une intrusion. A priori Prelude et Snort ne semblent donc pas convenir tels quels pour
répondre à ce point. Cependant comme annoncé précédemment, ils disposent tous les deux d'un
grand nombre de contributions et de logiciels supplémentaires. Et parmi ces éléments certains
offrent des moyens d'interaction et de blocage. Malgré une complexification de la chaîne
d'exécution, nous utiliserons tout de même ces outils pour répondre aux besoins exprimés.

Il est maintenant nécessaire de départager les deux solutions retenues. Les points de
divergences vont donc nous permettre de choisir l'IDS le plus apte à remplir son rôle.

La solution Prelude est une solution hybride qui peut tout aussi bien être un HIDS qu'un NIDS, là

Clément Gauthey – IUT informatique René Descartes – 2006

18/50
où Snort ne fonctionne qu'en NIDS. Prelude a donc un avantage certain grâce à une plus grande
flexibilité dans sa mise en oeuvre.

Prelude se veut être un unificateur des systèmes de détection existants. C'est pourquoi cette solution
a la possibilité de construire une architecture où plusieurs types d'IDS cohabitent, Prelude servant
alors de « centraliseur » pour l'ensemble des informations générées. De ce fait, cette solution
apporte des fonctionnalités beaucoup plus poussées que Snort telles que l'utilisation des règles de
détection des autres IDS en plus de ces propres règles. La complexité de Prelude au niveau de son
installation et de sa gestion est donc aussi plus importante. Sachant que les IDS sont des éléments
nouveaux dans la sécurité pour les administrateurs, il est alors préférable de commencer par des
applications plus aisées à maîtriser. D'autant plus que Snort est considéré par Prelude comme un des
ses sous éléments (Prelude peut utiliser Snort). Il sera plus tard possible de greffer la solution
Prelude dessus sans modifier les IDS déjà mis en place.

Le dernier point énoncé a permis de déterminer le système de détection à utiliser. En effet, il est
préférable de démarrer par le plus simple, pour ensuite remonter graduellement l'échelle de
complexité des IDS. D'autant plus que ce type de système n'est pas fermé, c'est-à-dire qu'il offre la
possibilité d'évoluer sans supprimer les éléments mis en place précédemment. La solution Snort a
donc été choisie pour remplir le travail de détection des intrusions.

Clément Gauthey – IUT informatique René Descartes – 2006

19/50
2.4. Snort

Après avoir choisi ce système de détection d'intrusions pour répondre aux besoins de
l'entreprise, il faut l'analyser de façon plus rigoureuse et méticuleuse. Son fonctionnement interne
mais aussi son positionnement sur le réseau sont des informations utiles à connaître afin de mieux le
comprendre.

2.4.1. Architecture réseau

Le positionnement de Snort sur le réseau est un point important à déterminer avant son
implantation. Plusieurs configurations sont possibles au sein de la plateforme.

La première configuration utilise le mode « mirroring » du commutateur pour recopier les

flux de données le traversant, vers un port spécifique où est connecté l'IDS. Cette configuration
permet de contrôler l'ensemble des informations provenant de l'extérieur mais malheureusement
aussi toutes celles appartenant au réseau interne si tous les ports y sont redirigés. Une seule instance
de Snort est nécessaire, et il vaut mieux utiliser dans ce cas une machine dédiée. Il faut savoir que
cette méthode pose tout de même des problèmes de surcharge sur le commutateur. En effet,
commuter les ports demande des opérations supplémentaires, et risque donc de ralentir le
fonctionnement de la plateforme Migale.

Exemple de positionnement de Snort en « mirroring »

Clément Gauthey – IUT informatique René Descartes – 2006

20/50
 Une autre configuration est néanmoins possible sur la plateforme, il s'agit cette fois de placer
Snort sur chaque élément à surveiller. Cette configuration demande pour être efficace une
centralisation des informations afin de diminuer les conséquences de la répartition des sondes. Par
ailleurs, plusieurs instances de l'IDS doivent être installer, complexifiant la gestion du système de
détection et son installation.

Exemple de positionnement de Snort sur chaque élément

Sachant qu'à terme une seule machine sera susceptible d'être attaquée, il est préférable
d'utiliser pour l'instant la deuxième configuration car l'impact sur les performances est un critère
beaucoup plus important. Au final, il ne devrait rester qu'une seule instance de Snort sur une unique
machine n'analysant que le trafic passant à sa proximité. Ceci est amplement suffisant pour les
besoins de la plateforme en matière de sécurité.

2.4.2. Fonctionnement

Une présentation sommaire du fonctionnement interne de Snort peut aider à la

compréhension des mécanismes mis en jeu lors de la détection des intrusions. Snort se décompose
en un certain nombre de modules, chacune jouant un rôle dans la découverte d'une attaque. Nous
allons expliquer le fonctionnement de Snort en étudiant l'enchaînement de ses différents modules.

Clément Gauthey – IUT informatique René Descartes – 2006

21/50
 Tout d'abord, la récupération des informations sur le réseau se fait grâce à un système appelé
le décodeur. Ce dernier réalise aussi une première mise en forme des données récupérées pour un
traitement plus efficace. Il s'appuie sur une bibliothèque appelée « libpcap », généralement présente
sur les systèmes d'exploitation Linux, qui s'occupe d'extraire des données issues du trafic réseau.

Ensuite, les préprocesseurs, tous modifiables via le fichier de configuration de Snort, se

divisent en deux catégories :

− D'un côté, se trouvent les préprocesseurs de détection qui permettent de détecter certaines
formes intrusions. Dans le cas d'une détection à ce niveau il est inutile de continuer le
déroulement du cycle et le logiciel passe directement aux modules de sorties.

− De l'autre côté, on retrouve des préprocesseurs de formatage des données. Ces derniers sont
très importants dans la détection d'une intrusion car la structure des informations transitant
sur un réseau peut être utilisée au profit d'une attaque. Par exemple, la fragmentation des
données si elle est bien manipulée, permet de découper le code de son attaque en morceau.
Si l'IDS n'était pas capable de reconstituer entièrement la donnée, il ne pourrait alors pas
découvrir l'attaque car les morceaux pris séparément ne constituent pas en eux même une
menace. Et ce n'est que lors de la reconstitution des données (défragmentation) par le
système cible que l'attaque prendra effet.

Après les préprocesseurs, on retrouve les détecteurs qui se servent des signatures des
intrusions pour les identifier. Ces signatures prennent la forme de règles modifiables à souhait par
l'administrateur. Lorsqu'une correspondance est trouvée entre une règle et le contenu d'une donnée
provenant du réseau, cette dernière est considérée comme suspecte mais est tout de même analysée
par les règles restantes. En effet, il aurait été possible de camoufler une très grosse attaque derrière
une de plus petite envergure pouvant amener l'administrateur à une erreur d'interprétation et donc de
moyens à mettre en oeuvre pour bloquer l'attaque. Il faut noter que Snort n'intègre ce système que
depuis sa dernière version (2.4).

Clément Gauthey – IUT informatique René Descartes – 2006

22/50
 Enfin, les modules de sorties constituent le dernier chaînon du cycle de fonctionnement de
l'IDS Snort. Ils offrent un grand nombre de possibilités en terme de génération des alertes. Par
exemple, c'est grâce à eux que l'on peut spécifier l'envoie des informations vers une base de
données ou vers un fichier.

Cycle de fonctionnement de Snort

Après cette première analyse du fonctionnement de Snort, nous allons pouvoir passé à la
mise en oeuvre du système de détection.

Clément Gauthey – IUT informatique René Descartes – 2006

23/50
3. Mise en oeuvre du système de détection

3.1. Démarche de mise en oeuvre

L'installation de nouveaux composants nécessite d'utiliser une méthodologie de mise en

oeuvre. Les systèmes de détection d'intrusions sont pour l'instant des mécanismes récents pour la
plateforme et les administrateurs souhaitent en apprendre d'avantage. D'autant plus que ces derniers
font partis de la sécurité, domaine dans lequel une erreur peut avoir de graves conséquences. On a
donc adopté une démarche de mise en oeuvre itérative pour chaque nouvel élément intervenant dans
les solutions proposés au cahier des charges. Cette démarche est composée en trois phases.

1. La première phase consiste à se documenter sur l'outil. Elle permet de maîtriser les
principales caractéristiques du produit et d'évaluer les éventuels problèmes constatés par
d'autres utilisateurs. J'ai donc commencé par me documenter sur technologie IDS. J'ai par la
suite approfondi les outils Snort et Prelude pour mieux comprendre leur fonctionnement.
Cette première étape permet d'avoir une idée plus précise sur la façon d'installer, de
configurer et de tester l'application.

2. La deuxième phase met en place une maquette (ou prototype). Deux machines de tests (MT1
et MT2) m'ont été allouées pour réaliser cette tâche. Ces deux ordinateurs fonctionnent sous
la distribution CentOS en raison de la prochaine migration de l'ensemble des machines de la
plateforme. Ainsi les tests à effectuer seront également validés pour le futur. D'autre part,
afin d'être autonome, j'ai reçu les droits d'accès maximum, c'est-à-dire que je suis
l'administrateur de ces machines. Étant dans un domaine d'étude principalement orienté
réseau, il est par ailleurs pratique d'avoir plusieurs machines à disposition pour analyser les
interactions entre elles sans devoir manipuler les autres composants en activité.

Le prototypage comprend l'installation et les premiers tests. Il est en effet nécessaire

d'effectuer des tests afin de vérifier la fiabilité, le bon fonctionnement de l'application et
d'évaluer les conséquences immédiates. Ces premières évaluations ne sont certes pas
indicatives de la valeur réelle du logiciel, mais donnent tout de même plusieurs informations
importantes. On peut par exemple s'assurer que le programme démarre correctement et ne

Clément Gauthey – IUT informatique René Descartes – 2006

24/50
 bloque pas la machine. Ce type d'information est primordial avant de passer en production
car des résultats néfastes pourraient se répercuter sur l'ensemble des utilisateurs, et donc
détruire ou endommager le travail des chercheurs qui est principalement de longues séries
de calculs mathématiques.

3. La dernière phase est le passage en production. La mise en place sur les systèmes réels ainsi
que la validation finale des nouvelles applications font donc partis de cette étape. La
première et seconde phase ayant permis de minimiser les risques potentiels, il devient donc
possible de vérifier que le programme s'insère correctement dans le cycle de fonctionnement
des machines hôtes. C'est pourquoi une nouvelle série de tests viennent compléter l'analyse.
Cette fois il s'agit de s'assurer qu'aucun problème lié aux différences entre les machines de
production et les machines de tests n'apparaissent. Il faut valider chaque nouveau composant
pour garantir sa bonne implémentation dans le système réel.

Clément Gauthey – IUT informatique René Descartes – 2006

25/50
3.2. Gestion des intrusions

Un système de détection d'intrusions comme Snort est uniquement spécialisé dans la

recherche d'attaques sur le réseau. Nous souhaitons réagir lorsqu'une intrusion a été détectée. C'est
pourquoi deux types d'actions sont à entreprendre afin de répondre au cahier des charges :

1. Il s'agira dans un premier temps d’envisager une réaction immédiate et coercitive qui
consistera à bloquer immédiatement l’attaquant et à alerter les administrateurs. Pour ce
dernier point, on utilisera le système de centralisation des fichiers journaux mis en place, en
y intégrant les alertes générées par Snort.

2. Dans un second temps, le système d’alerte devra conserver les traces des tentatives
d’intrusions sur une longue durée. L'IDS Snort possède une architecture modulaire ce qui le
rend très facilement extensible. Ces nouvelles fonctionnalités (blocage, alerte et traçabilité)
vont pouvoir être mises en place grâce aux différentes contributions disponibles pour la
communauté Snort ou à des outils plus spécifiques mais s’intégrant parfaitement dans
l'architecture de la plateforme.

3.2.1. Réactions immédiates : blocages et alertes

Lorsqu'une intrusion est détectée la première opération à effectuer est de stopper l’attaque
potentielle pour qu'elle ne puisse pas compromettre les systèmes.
L’ensemble des serveurs de la plateforme redirige leurs journaux systèmes vers le serveur Liris
dédié au stockage et à l’analyse des journaux, via le processus « syslogd ». Snort est capable
d’envoyer les alertes au processus « syslogd » et il sera relativement simple d’intégrer la
centralisation des journaux de Snort vers le serveur dédié. On pourra ainsi externaliser les outils
(scripts, applications) de réactions à une attaque sur le serveur Liris. Cette séparation des tâches
permet de renforcer la sécurité globale de la plateforme. Il va de soi que le serveur centralisant
l’ensemble de ces informations est considéré comme sensible, et pourrait le cas échéant être le point
faible de la chaîne des traitements des informations remontés par Snort. Ainsi un arrêt involontaire
de cette machine empêcherait toute réaction face à une intrusion. Dans ce premier scénario, le

Clément Gauthey – IUT informatique René Descartes – 2006

26/50
serveur qui détecte l’attaque est passif. Ce sont les outils installés sur le serveur Liris qui décideront
de la réaction à entreprendre suite à la détection d'une intrusion.

On peut envisager un second scénario, où le serveur attaqué prend lui-même la décision de la

riposte. Une couche logicielle nommée NetFilter peut faire office de pare-feu sous Linux. Il faut
alors installer et surtout configurer ce pare-feu sur chaque machine à protéger. Par exemple, lors
d’une détection de « scan SSH », Netfilter est capable de bloquer à la volée la machine source.
Netfilter ne fera que bloquer les attaques, mais ne sera pas en charge des alertes ou de la
conservation des traces. Même si il est capable de tracer les alertes cela nous amène à gérer autant
fichiers de traces que de serveurs sur lequel l'IDS fonctionne. La gestion en local de ces deux
fonctionnalités n'est alors pas pratique : les fichiers de traces sont éparpillées et chaque machine a
besoin des scripts. Malgré les contraintes de la seconde solution, il est intéressant de conserver cette
possibilité et également de la valider, car à terme il n’existera qu’une seule machine ouverte sur
l'extérieur.

Le serveur Liris en charge de la centralisation des logs dispose d’une application d'analyse
des fichiers journaux: LogSurfer. L'administrateur indique, avant de lancer cette l'application, des
séries de mots-clés et le fichier journal à analyser. Si une correspondance est trouvée entre un des
mots-clés et une ligne de ce fichier, une action sera alors exécuter Cette action va consister dans
notre cas en deux opérations et être regroupée dans un script shell. Ce script envoie tout d’abord un
mail d’alerte puis enregistre les machines incriminées dans une liste noire. Cette liste permettra de
conserver un historique à partir duquel il est possible de lancer des actions de blocage des adresses
concernées. Le cas d'un blocage non désiré (par exemple à cause d'un faux positif) est à prendre en
considération. On ne peut pas en effet interdire l'accès à un membre de la communauté scientifique
sous prétexte d'une erreur dans l'analyse faite par Snort. C'est pourquoi les adresses contenues dans
la liste noire sont régulières débloquées.

3.2.2. Consultations et analyses

La consultation et l'analyse des alertes doivent s'effectuer après la détection d'une intrusion.
Un administrateur ne peut en effet pas rester continuellement à l'écoute du système de détection. Il

Clément Gauthey – IUT informatique René Descartes – 2006

27/50
faut donc trouver un moyen de conserver les données sur les attaques et également de trouver un
système d'interface permettant un accès simple et convivial.

Les données générées par les différentes instances de Snort sont réparties sur plusieurs
machines. La conservation de ces dernières doit donc être centraliser afin d'obtenir une meilleure
efficacité dans la consultation. D'autre part, il n'est pas envisageable de garder la structuration
d'origine des fichiers d'alertes. Ces derniers ne sont pas adaptés à la lecture par une personne
humaine. Nous devons également faire en sorte que cette structuration soit compatible avec
l'interface graphique. Après un rapide tour d'horizon, il semblerait que la plupart des interfaces
disponibles travaillent à partir d'une base de données. La machine Tulipe en propose justement
plusieurs types dont MySQL. De plus, Snort est livré avec des scripts de création de base de
données, l'installation s'en trouve donc simplifitée.

Encore une fois, c'est du côté des contributions que des outils de gestion graphiques vont
être trouvés. En premier lieu, ACID (de l'anglais, Analysis Console Intrusion Detection) semble
offrir toutes les fonctionnalités pratiques pour analyser et consulter de manière claire et précise les
données. Il est possible de connaître les dernières alertes, les machines les plus touchées, ou encore
les protocoles et les ports les plus utilisés par les attaques. Mais la présence d'un moteur de
recherche ainsi que des fonctionnalités de génération de graphiques, pouvant montrer l'évolution
des alertes dans le temps par exemple, montrent la qualité de cette application écrite en langage
« PHP ». Cependant, le développement d'ACID a été arrêté en 2004 impliquant l'absence de suivi
dans les mises à jour logicielles, conséquence, un changement dans la structuration de la base de
données de Snort ne pourra plus être pris en compte par ACID.

Clément Gauthey – IUT informatique René Descartes – 2006

28/50
 Interface web d'ACID

Afin de pallier à ce problème, une autre interface graphique nommée BASE (en anglais,
Base Analysis & Security Engine) existe et offre les mêmes possibilités que l'application ACID.
BASE est développé par des membres de la communauté de Snort à partir d'ACID. Néanmoins
plusieurs bogues viennent entâcher la bonne qualité de cette application, il est donc conseillé de
conserver pour l'instant les deux outils jusqu'à ce que BASE fonctionne parfaitement. Le mieux
étant d'avertir les développeurs de ces problèmes et d'attendre la prochaine version en espérant une
amélioration.

Clément Gauthey – IUT informatique René Descartes – 2006

29/50
 Interface web de BASE

Grâce à la gestion des alertes dans une base de données et à l'utilisation d'interfaces
graphiques, les administrateurs ont la possibilité d'analyser et de consulter les alertes. L'ergonomie
et les fonctionnalités proposées par BASE et ACID sont des atouts majeurs pour améliorer la
sécurité de la plateforme. Ces éléments permettent aux responsables de suivre l'évolution des
tentatives d'intrusions et d'y apporter des réponses efficaces dans un délai très court.

Clément Gauthey – IUT informatique René Descartes – 2006

30/50
 Pour terminer cette partie sur la gestion des intrusions, un exemple d'attaque « SSH » montre
les différents mécanismes mis en jeu lors de la gestion de cette intrusion. On distingue bien les deux
parties de cette gestion : la réaction immédiate ainsi que la conservation et la consultation des
alertes.

Exemple de gestion d'une intrusion « SSH »

Clément Gauthey – IUT informatique René Descartes – 2006

31/50
3.3. Optimisation du système de détection d'intrusions

Afin de répondre aux cahier des charges, l'optimisation du système de détection d'intrusions
est une étape obligatoire pour s'assurer d'une part de son efficacité à découvrir les attaques, et
d'autre part pour ne pas altérer le fonctionnement de la machine hôte.

3.3.1. Amélioration de la sécurité

L'amélioration de la sécurité consiste à rendre l'IDS plus sensible à la détection des

intrusions. Cette amélioration passe tout d'abord par un paramétrage adapté aux besoins de
plateforme, puis par la mise en place d'outils de mise à jour automatique du logiciel.

Snort ne doit théoriquement se consacrer qu'à la détection, et relayer les autres tâches aux
diverses contributions. Il est impératif que Snort puisse effectuer sa fonction principale sans être
gêner par des interactions. C'est pourquoi des développeurs ont mis au point un utilitaire, Barnyard,
qui transmet les données d'alertes aux différents composants en ayant besoin, comme la base de
données par exemple. Snort ne s'attardera alors plus à communiquer avec ces composants, donc à
attendre leurs réponses, et déléguera cette opération.

Le principe de fonctionnement est le suivant : Snort génère des fichiers en local dans un format
binaire donc plus rapide à écrire. Barnyard vient lire ces fichiers de façon locale, et les envoie aux
éléments indiqués dans ces paramètres de configuration. Dans notre cas il s'agit de la base de
données MySQL et du programme de centralisation des journaux SysLog.

Clément Gauthey – IUT informatique René Descartes – 2006

32/50
 3,75
3,5
3,25
3
Pourcentage de perte 2,75
2,5
2,25
2
1,75 Avec Barnyard
1,5 Sans Barnyard
1,25
1
0,75
0,5
0,25
0
1 2 3 4 5 6 7 8 9 10
Tests par intervalle d'1h

Tests d'analyse de Snort sur MT1

Des mises à jour de sécurité pour les signatures, appelées « règles », sont disponibles sur le
site internet de Snort. Il faut noter que plusieurs versions sont présentes en fonction du statut de
l'internaute. Par exemple, en souscrivant un abonnement payant il est possible d'obtenir les
nouvelles mises à jour dès leur parution, alors qu'en restant un simple visiteur ces dernières ne sont
modifiées qu'à chaque version de Snort. Autant dire tout de suite qu'il faut trouver un moyen d'avoir
le plus rapidement ces nouvelles données de détection. Au vue des tarifs indiqués pour
l'abonnement, nous avons plutôt décidé de nous inscrire gratuitement sur le site, offrant un délai de
cinq jours pour les mises à jour. Cette contrainte de délai est acceptable pour la plateforme Migale.

Par ailleurs, une contribution appelée « OinkMaster » permet de s'assurer que Snort possède les
mises à jour les plus récentes. Si ce n'est pas le cas, l'application va, grâce au compte attribué lors de
l'inscription, ajouter les règles manquantes et remplacer ou supprimer celles qui sont obsolètes. Le
fichier de configuration du logiciel permet d'être plus précis dans les mises à jour à effectuer, et
propose même le téléchargement de la dernière version de Snort. L'automatisation de cette tâche via
un script shell allège la charge de l'administrateur. Il n'a alors pas besoin de contrôler
continuellement la parution de ces nouvelles mises à jour. Le script est utilisé conjointement avec le
programme de lancement périodique de tâches, la crontab. Ce procédé offre un moyen efficace pour
réaliser de manière régulière la mise à jour des règles de détection et de les intégrer immédiatement

Clément Gauthey – IUT informatique René Descartes – 2006

33/50
dans le système de détection.

Toujours dans l'optique de mieux sécuriser le réseau, les communications entre les
différentes sondes et les machines de centralisation (des alertes sur Tulipe et des journaux sur Liris)
peuvent être cryptées. Ce mécanisme met en place « OpenSSL » offrant principalement des
algorithmes de cryptage performants et le protocole « SSL » (Secure Sockets Layer), ou « Stunnel »
un programme permettant d'établir des sessions chiffrées entre un client et un serveur. Certes ces
éléments seraient utiles dans le cadre d'une banque où la sécurité est très élevée. Mais pour la
sécurité de la plateforme Migale, il s'avère que ce moyen de protection est finalement trop
contraignant par rapport au bénéfice qu'on en retirerait. Nous avons donc décidé de ne pas mettre en
place ce mécanisme.

Enfin, la sécurité passe aussi par la résistance de l'IDS face aux attaques. Celui-ci étant sur le
réseau, une adresse ip lui est attribuée afin que l'on puisse communiquer avec lui. Hors si un pirate
connaît cette adresse, il peut alors s'en prendre directement au système de détection des intrusions.
Plusieurs cas de figures se présentent pour améliorer sa sécurité et dépendent des caractéristiques de
la machine hôte. L'IDS, pour analyser les flux, n'a pas besoin d'être identifié sur le réseau, il ne fait
que lire les données depuis l'interface réseau. Par contre, dès lors que vous devez dialoguer avec
celui-ci, vous avez obligatoirement besoin de connaître son adresse ip sauf si le dialogue s'établit
entre la machine hôte et son IDS. La configuration adoptée dans le positionnement de Snort,
nécessite une centralisation des informations et donc demande d'avoir cet identifiant pour chaque
instance de l'IDS.

C'est du côté des interfaces réseaux que l'amélioration peut être réalisée. Si une seule interface est
disponible sur la machine hôte, il n'y a alors aucun moyen pour augmenter la sécurité en utilisant les
interfaces réseaux.

Clément Gauthey – IUT informatique René Descartes – 2006

34/50
 Architecture de Snort avec une seule interface réseau

Par contre, si on dispose de plusieurs interfaces, on peut configurer le système ainsi :

− la première interface ne dispose pas d'adresse ip propre. La sonde récupère les données depuis
cette interface. La sonde est invisible sur le réseau.

− la seconde interface est connecté à un réseau privé sur lequel est également connecté la machine
de centralisation. Bien entendu, le coût en matériel utilisé est plus important avec cette solution
et la gestion devient également plus complexe.

Architecture de Snort avec deux interfaces réseaux

Ce système a été proposé pour une amélioration future mais n'est pour le moment pas mis en place.

Clément Gauthey – IUT informatique René Descartes – 2006

35/50
3.3.2. Amélioration des performances

Un des critères importants pour l'optimisation de Snort concerne l'amélioration de ses

performances. Il est courant de rencontrer des scientifiques réalisant des calculs pouvant durer
plusieurs semaines voir plusieurs mois. L'IDS ne doit donc pas altérer de manière drastique les
performances des machines hôtes. Afin de répondre à ce problème, deux méthodes sont
envisageables : faire en sorte que Snort n'analyse que les informations utiles et qu'il les analyse le
mieux possible.

Le premier moyen d'optimisation des performances met en place un mécanisme de filtrage

appelés « Berkley Packet Filtrer » (Filtre de paquet Berkley) et qui est intégré à Snort. Il permet de
réaliser un premier tri des données traversant le réseau avant même leur passage sous les détecteurs
de l'IDS. La mise en place d'un tel filtre allège la charge machine attribuée à la vérification des
règles d'intrusions. On peut représenter les différents réseaux de la manière suivante :

Niveau de dangerosité des réseaux

Dans notre cas, il est intéressant d'indiquer le réseau de la plateforme Migale comme étant un réseau
de confiance. En effet, il y a peu de chance pour qu'un membre de l'unité aille effectué
volontairement des attaques sur son propre réseau. Par contre, le réseau du centre n'est pas
considéré comme fiable. Chaque laboratoire gérant son propre réseau, rien n'indique qu'il soit
réellement sécurisé. Des ouvertures sur leur réseau pourraient alors servir à attaquer indirectement

Clément Gauthey – IUT informatique René Descartes – 2006

36/50
une autre plateforme. On classera donc le centre de Jouy-en-Josas comme un réseau intermédiaire
dont il faut se méfier. Évidemment, les données provenant de l'Internet sont potentiellement les plus
dangereuses et ne peuvent donc pas être filtrées.

Un test de performance est ici approprié pour démontrer l'intérêt de l'utilisation des filtres. Ainsi
deux instances du logiciel Snort sont lancées simultanément avec pour seule différence la présence
ou l'absence des filtres. La récupération de la charge du processeur utilisé se fait grâce à des
commandes de base intégrées aux distributions Linux et d'une application que j'ai développé en
langage C. Voici un exemple intéressant de l'utilisation de connaissances en programmation dans un
stage pourtant orienté système et réseau. La polyvalence d'un informaticien est donc pratique pour
améliorer l'efficacité de son travail et son autonomie.

Intérêt des filtres sur Tulipe

Clément Gauthey – IUT informatique René Descartes – 2006

37/50
 La seconde méthode pour améliorer les performances consiste à diminuer le nombre
d'erreurs générés par Snort. Ces erreurs sont appelées des faux, et il en existe deux types :

− les faux négatifs qui sont des alertes émises alors qu'il n'y en avait pas,

− et les faux positifs qui correspondent à une absence de détection d'intrusion.

Snort génère nativement un certain nombre de faux négatifs. La diminution de ces faux ne doit pas
passer dans l'excès inverse. En effet, il est toujours préférable d'avoir des faux négatifs que des faux
positifs car un manque d'information est beaucoup plus grave que trop d'information.

Afin de réaliser cette tâche, il est nécessaire de bien déterminer les règles de détection à activer. Par
exemple, les règles concernant les intrusions via le protocole « http » ne sont d'aucune utilité sur
une machine ne possédant pas ce type de protocole. De plus, l'étude plus approfondie du
paramétrage de Snort montre que la configuration adoptée influence grandement la génération de
faux. Un préprocesseur s'occupe par exemple de reconstruire les paquets fragmentés durant leur
transit sur le réseau. Hors l'unité a un serveur de fichiers qui engendre des données parasites pour
l'IDS. Ce serveur créé des données fragmentées qui répondent aux critères de détermination d'une
intrusion par ce préprocesseur. Ce problème peut se résoudre en modifiant les paramètres de Snort.
Mais dans notre cas, l'application des filtres sur les données à traiter permet de ne plus tenir compte
de ces données parasites car elles appartiennent au réseau de confiance.

Clément Gauthey – IUT informatique René Descartes – 2006

38/50
3.4. Validations et résultats

Le prototypage a permis d'obtenir un aperçu global du fonctionnement de la plupart des

nouveaux outils, et de s'assurer qu'aucun problème majeur ne viendrait perturber les serveurs
Tulipe, Anémone et Edelweiss lors de la mise en production. Néanmoins, les ordinateurs de tests
possèdent des différences notables avec ces serveurs.

La principale différence concerne le système d'exploitation. La migration prochaine de l'ensemble

des machines d'une distribution Mandrake vers une distribution CentOS nous a incité à installer ce
nouveau système d'exploitation sur MT1 et MT2. Ainsi, les tests permettront de valider le
fonctionnement de l'IDS sur la nouvelle distribution. En contrepartie, le risque d'incompatibilité
entre les machines de tests et les machines de production est plus élevé.

De plus, les deux prototypes fonctionnent sur une architecture en 32 bits alors que les serveurs à
protéger utilisent une architecture en 64 bits. Cette différence implique de recompiler les
applications pour qu'elles s'adaptent à leur nouvel environnement.

Par ailleurs, les fonctionnalités de conservation des alertes nécessite l'utilisation d'une base de
données opérationnelle. Hors les machines de tests ne présentent pas cette caractéristique. Nous
avons donc décidé de ne pas utiliser MySQL sur les machines de tests car les risques d'effets de
bord sur le serveur en production sont extrêmement faible.

Enfin, les serveurs de production sont des éléments vivants, c'est-à-dire qu'ils ont de nombreuses
interactions aussi bien en local qu'avec l'extérieur. Les machines MT1 et MT2 sont dédiées aux tests
de l'implémentation du système de détection, leurs interactions sont considérablement réduites. Des
tests de performances sur ces machines ne représenteraient donc pas la réalité. Afin de rendre l'IDS
fonctionnel, nous avons besoin de valider par de nouveaux tests sa mise en place sur les serveurs de
production.

Clément Gauthey – IUT informatique René Descartes – 2006

39/50
 Caractéristiques \ Machines Serveurs Prototypes
Système d'exploitation Mandrake CentOS
Architecture 64 bits 32 bits
Activité machine Importante Faible
Base de données Oui Non
Version du noyau 2.6 2.6

Récapitulatif des caractéristiques divergentes entre les différentes machines

Nous décrirons, étape par étape, l'installation de chaque composant sélectionné pour
répondre à la problématique générale, en mettant en évidence les nouvelles difficultés rencontrées.
Chaque étape sera ponctuée par un schéma de l'avancement de la mise en oeuvre dont la légende est
la suivante :

Légende utilisée pour les schémas

Nous utiliserons la machine Tulipe pour une première série de validation. Les deux autres
serveurs à protéger utilisent la même distribution, et devraient dans un avenir proche de disparaître
du groupe à surveiller. Il semble donc plus approprié de démarrer les tests de validité sur cette
machine.

Nous débutons la mise en production par le déploiement de l'IDS Snort. La présence d'un
système d'exploitation différent et d'une architecture en 64 bits nous obligent à recompiler
l'application. Cela nous permet également d'intégrer en même temps le module de sortie pour

Clément Gauthey – IUT informatique René Descartes – 2006

40/50
l'envoi vers la base de données MySQL.

Néanmoins, un premier problème apparaît : les bibliothèques nécessaires au fonctionnement de ce

module ne peuvent être localisées par Snort dans les répertoires par défaut. Lors de la compilation
Snort n'est pas capable de prendre en compte un chemin autre que celui par défaut. La solution
trouvée, qui n'est pas optimale, consiste à créer des liens dans ces répertoires vers les emplacements
réels de ces bibliothèques.

La configuration de l'IDS est modifiée pour qu'elle corresponde aux spécificités de la machine
Tulipe. Par exemple, les règles de détection d'attaques sur le protocole « http » sont activées car le
serveur propose une interface web. Au contraire, celles sur le protocole « snmp » sont supprimées
car la plateforme ne les utilise pas.

Une copie du script de lancement de Snort est enregistrée sur Tulipe. Malheureusement la version
du shell utilisée par la distribution du serveur ne correspond pas à celle des machines de tests. Une
légère adaptation est donc nécessaire pour pallier à ce problème.

Déploiement de l'IDS

L'installation des fonctionnalités de réaction immédiate constitue la deuxième étape de la

mise en production. Le paramétrage des modules de sortie pour qu'ils puissent envoyés des
informations à l'application « Syslog » ne pose aucune difficulté particulière. La même démarche
avait été adoptée lors du prototypage.

Les nouveaux outils à mettre en place se font cette fois du côte du serveur de centralisation des
fichiers journaux. La dernière version de « Logsurfer » avait mis hors service une machine. Nous

Clément Gauthey – IUT informatique René Descartes – 2006

41/50
avions donc tester sur MT1 une version plus ancienne qui avait donnée entière satisfaction. C'est
cette dernière que nous installons donc sur Liris. Les scripts shell, que j'ai déjà développé au
préalable, contenant les actions à réaliser en cas d'attaques « SSH » sont directement transporter
depuis la machine de tests.

Un test rapide nous permet de vérifier que tous les composants communiquent correctement entre
eux. Les alertes sont bien réceptionnées et traitées sur Liris. De plus, la simulation d'une attaque
« SSH » sur Tulipe permet de valider la réaction immédiate obtenue.

Mise en place de module de réaction immédiate

L'étape suivante consiste à implémenter les fonctions d'historique des alertes. Cette étape
comprend donc la mise en place de la base de données MySQL et des interfaces graphiques ACID
et BASE, mais aussi les modifications à apporter au système de détection pour qu'il puisse les
utiliser.

Les scripts livrés avec Snort et BASE ainsi que ceux déjà présents sur Tulipe facilitent grandement
l'installation de la base. La reconfiguration de l'IDS permet d'utiliser le module de sortie vers
MySQL. Aucun problème n'est survenu lors de la validation de ce module en local. Cependant lors
d'un test d'interaction entre MT1 et la base de données de Snort, un problème d'autorisation d'accès
est apparu. L'administrateur a résolu rapidement la situation en modifiant les droits d'accès sur la
base.

Les interfaces graphiques ont besoin de modules « PHP » différents pour la gestion des graphiques.
Nous procédons donc à leur installation. L'utilisation des interfaces semblent fonctionner

Clément Gauthey – IUT informatique René Descartes – 2006

42/50
correctement à l'exception des problèmes cités précédemment. C'est pour cette raison que nous
avons conservé les deux interfaces sur le serveur web.

Mise en place du module de conservation

La dernière étape vise à optimiser l'efficacité de l'IDS en y intégrant l'application Barnyard

et en modifiant Snort pour qu'il utilise le mécanisme des filtres.

Une erreur lors de la compilation de Barnyard est apparue alors qu'aucune problème n'avait été
signalé lors du prototypage. Il s'agit également d'une recherche de bibliothèques dans un répertoire
ne les contenant pas. Pour résoudre ce problème, nous avons tout simplement supprimé la variable
d'environnement LD_LIBRARY_PATH qui pointait sur des emplacements de recherche erronés.

Un fichier fournissant les données à ne pas analyser par l'IDS vient s'ajouter à la configuration de
base de Snort. Le script de lancement ayant était créé dans l'optique d'une utilisation des filtres au
moyen d'un fichier, aucune modification supplémentaire est nécessaire.

Clément Gauthey – IUT informatique René Descartes – 2006

43/50
 Mise en place du mécanisme d'optimisation

Finalement, nous obtenons un système de détection opérationnel répondant aux divers points
du cahier des charges comme l'avertissement des administrateurs en cas d'attaque, la conservation
des données sur les intrusions et une implémentation sans conséquences sur les performances des
systèmes.

Clément Gauthey – IUT informatique René Descartes – 2006

44/50
Conclusion

Le stage effectué proposait l'étude et la mise en oeuvre d'un système de détection

d'intrusions. La choix de l'IDS Snort a répondu aux besoins exprimés par les responsables de la
plateforme Migale en terme de sécurité informatique. Les nombreuses contributions et les
applications déjà présentes sur les machines ont permis d'apporter des fonctionnalités
supplémentaires à Snort en terme de gestion d'une intrusion, de conservation et de consultation des
alertes ainsi que d'optimisation de l'IDS. Les performances globales des machines n'ont pas été
dégradées au profit du fonctionnement de l'IDS, et la qualité de détection reste correcte pour la
politique de sécurité de la plateforme. Au final, bien que certains problèmes mineurs persistent,
nous avons réussi à obtenir un système fonctionnel.

Le stage à l'INRA a été une bonne expérience pour une première approche du monde
professionnel mais également pour découvrir le fonctionnement d'un laboratoire de recherche.
Entrevoir le fonctionnement d'un « cluster de calcul » a aussi été intéressant. Mais le principal
attrait de se stage fut la mise en pratique de connaissances sur des systèmes d'exploitation qui ne
m'étaient pas familiers (linux...), et dans le domaine de la sécurité peu pratiqué à l'université de
Paris5. J'ai également pris conscience des difficultés de la gestion d'un parc informatique.

Néanmoins, le travail d'un stagiaire diverge en plusieurs points de celui d'un salarié. Par exemple,
dans le cadre de mon stage, je n'étais pas tenu à obtenir des résultats sur la mise en place de l'IDS.
D'autre part, le sujet de mon stage ne m'a pas permis de m'intégrer à un groupe de travail. De ce fait,
je n'ai pas pu voir les problèmes liés à la coopération et à l'organisation des membres d'une équipe
dans le cadre d'un projet professionnel.

Ce stage a été une source non négligeable d'informations aussi bien pour mes connaissances
informatiques que dans ma perception du monde du travail et de mon avenir professionnel. Les
domaines d'activités exercés au cours des dix semaines dans l'institut, à savoir les systèmes, les
réseaux et la sécurité, m'ont donné envie de continuer dans cette voie. Mon maître de stage m'a
également motivé pour que je poursuive mes études aussi loin que possible. C'est pourquoi j'espère

Clément Gauthey – IUT informatique René Descartes – 2006

45/50
devenir ingénieur informatique spécialisé dans les domaines cités ci-dessus en intégrant une école
d'ingénieur dès l'année prochaine.

Par ailleurs, grâce à ma bonne entente avec les membres de l'unité MIG et à mes capacités à
effectuer un travail efficace, j'ai pu obtenir une prolongation de mon stage de trois semaines. Bien
que le sujet traité sera différent, il reste tout de même dans les domaines des systèmes et réseaux. Il
portera en particulier sur l'étude de la mise en place d'un système de haute disponibilité pour le
« cluster de calcul ».

Clément Gauthey – IUT informatique René Descartes – 2006

46/50
A. Lexique

Attaque « SSH » : Attaque via le programme de connexion à distance « SSH ». Le Secure SHell
permet de réaliser des actions sur une machine distante avec une communication sécurisée. La
connexion nécessite d'entrer les informations sur le compte utilisateur à utiliser. Les tentatives par
mot de passe faible sont donc courants pour ce type d'attaque.

Bibliothèque : En informatique, une bibliothèque (logicielle) est un ensemble de routines

regroupées pour réaliser un ensemble de tâches du même domaine. Les bibliothèques se distinguent
des exécutables dans la mesure où elles sont utilisées par des programmes plutôt que d'être
exécutées directement elles-même

Bioinformatique : La bioinformatique est le traitement des grandes quantités de données produites

par les techniques à haut débit de la biologie intégrative. Il s'agit :

− de développer de nouveaux outils (bases de données, modèles statistiques...),

− d'analyser des données et modélisation des phénomènes du vivant dans toute leur
complexité.

Biologie intégrative : La biologie intégrative est le développement d'outils d'analyse performants

(imagerie, spectrométrie de masse, etc.), d'approches de biologie animale, cellulaire et moléculaire
et de méthodes d'analyse globales des systèmes complexes (interactions entre gènes, systèmes de
régulation, etc.) qui s'appuient sur le développement des biopuces, de la protéomique, de la
transcriptomique et de la métabolomique.

Black-lister : Action d'enregistrer un élément particulier dans une liste d'éléments indésirables
appelée la liste noire (en opposition à la liste blanche).

Compilation : La compilation est un travail qui consiste à transformer un code source lisible par un
humain en un fichier binaire exécutable par une machine particulière.

Clément Gauthey – IUT informatique René Descartes – 2006

47/50
Distribution : Une distribution est la diffusion d'un système d'exploitation sous la forme d'une
collection de paquetages comprenant un noyau, des couches supérieures et des applications
complémentaires (interface graphique, modules de communication, etc.)

FAQ : La Foire Aux Question répertorie les questions (et leur réponse) les plus fréquemment
posées par les utilisateurs pour un domaine particulier.

Fichiers journaux : Les fichiers journaux ou fichier « log » (de l'anglais) enregistrent les
événements qui se passe sur une machine. Ex: arrêt involontaire d'une application, connexion à la
machine, démarrage d'un service, etc.

IDS : de l'anglais Intrusions Detection System, système de détection d'intrusions. Le sigle français
n'est jamais utilisé.

Port : Tous les systèmes d'exploitation utilisent des ports pour faire transiter des données entre les
machines. Chaque port est numéroté et correspond à un service. Ainsi, si on installe sur sa machine
un serveur Web, ce dernier utilisera le port 80 pour son fonctionnement.

Protocole : Un protocole est une norme ou une série de règles utilisées par les ordinateurs pour
pouvoir communiquer entre eux. Une fois un protocole défini, chaque terminal, client ou serveur,
implémente ce protocole et peut ainsi communiquer avec les autres ordinateurs utilisant ce
protocole.

Scans de ports ouverts : Un scans de ports consiste à tester les ports en activités sur une machine.
Cela correspond souvent à l'étude d'un système par un pirate avant de l'attaquer.

Script : Un script est un programme écrit dans un langage interprété. A la différence des
programmes écrits dans des langages compilés comme le C ou en C++, les scripts sont traduits en
langage machine au fur et à mesure de leur exécution. Ils sont en général plus lents à exécuter, mais

Clément Gauthey – IUT informatique René Descartes – 2006

48/50
aussi plus faciles à écrire. Les langages utilisés pour écrire un script sont par exemple : le bash (qui
est plus précisément un script shell), le perl, le php, etc.

Source ouverte : Le terme Source Ouverte (en anglais, Open Source) définit une licence de logiciel
obéissant à une définition très précise établie par l'Open Source Initiative. Les principaux critères
nécessaires sont :

− la libre redistribution,

− la disponibilité du code source,

− la possibilité de réaliser travaux dérivés.

Attention, le fait de disposer des sources d'un logiciel ne suffit pas à dire qu'il est Open Source.

Tentative par mot de passe faible : Une tentative par mot de passe faible consiste à pirater un
compte utilisateur d'une machine en essayant un couple login-mot de passe. Aucun algorithme
particulier n'est mis en oeuvre pour découvrir le login et son mot de passe associé. Le pirate
utilisera des couples standards, comme le nom de l'utilisateur et sa date de naissance.

Clément Gauthey – IUT informatique René Descartes – 2006

49/50
B. Ressources documentaires

Bibliographie
− Le shell bash 3eme Edition de Cameron Newham et Bill Rosenblatt, traduction de Hervé
Soulard, édition O'REILLY, janvier 2006, titre original: Learning the bash shell 3rd Edition
en avril 2005
− Snort 2 de Jack Koziol, traduction de C. Eberhardt et V. Warion, édition CampusPress, titre
original : Intrusion Detection with Snort en 2003
− Intrusion Detection Systems with Snort de Rafeeq Ur Rehman, Edition Prentice Hall, 2003
− Linux Magazine n°83

Webographie
− Snort : http://www.snort.org
− Prelude :
− http://lehmann.free.fr/
− http://lehmann.free.fr/Prelude.html
− http://www.prelude-ids.org/
− BASE : http://secureideas.sourceforge.net/
− ACID : http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html
− OinkMaster : http://cvs.sourceforge.net/viewcvs.py/oinkmaster/oinkmaster/
− Logsurfer : http://www.samag.com/documents/s=9053/sam0403i/0404i.htm
− Sécurité : http://www.security-labs.org/index.php3
− Script Shell :
− http://linuxfr.org
− http://lea-linux/org

Clément Gauthey – IUT informatique René Descartes – 2006

50/50