415 - Rapport Bsobesto Ids

Les Systè
ystèmes de Détec
tection
d’Intr
Intrusions Réseau
eau
port de projet de 3ème année

Rappo
Pilote
Toinard Christian
Auteur
Sobesto Bertrand
3ème Année
Filière
re Sciences
S et Technologies de l’Information
Option
tion Sécurité des Systèmes d’Information
Année 2007 – 2008
Sommaire
TABLE DES FIGURES .......................................................................................................................................... 2
INTRODUCTION ................................................................................................................................................ 3
PARTIE 1 - ETAT DE L’ART ................................................................................................................................. 4

I. POURQUOI LES SYSTEMES DE DETECTION D’INTRUSIONS ? .................................................................... 4
A. L’EMERGENCE DES NOUVELLES TECHNOLOGIES..................................................................................................... 4
B. VULNERABILITE.............................................................................................................................................. 4
C. PROFILE DES ATTAQUANTS ............................................................................................................................... 5
D. DEBUT DES SYSTEMES DE DETECTION D’INTRUSIONS ............................................................................................. 6
II. METHODOLOGIE D’UNE INTRUSION........................................................................................................ 6
A. RECONNAISSANCE .......................................................................................................................................... 6
B. DECOUVERTE DU SYSTEME ............................................................................................................................... 6
C. EXPLOITATION DE FAILLES DE SECURITE ............................................................................................................... 7
D. LES DIFFERENTS TYPES D’ATTAQUES ................................................................................................................... 7
III. LES DIFFERENTS TYPES D’IDS ................................................................................................................... 8
A. HOST-BASED INTRUSIONS DETECTION SYSTEMS ................................................................................................... 8
B. NETWORK INTRUSIONS DETECTION SYSTEMS ...................................................................................................... 8
C. INTRUSIONS PREVENTION SYSTEMS ................................................................................................................... 8
IV. MODELE ET NORMALISATION ................................................................................................................. 9
A. LE MODELE CIDF ........................................................................................................................................... 9
B. IDXP......................................................................................................................................................... 10
C. IDMEF...................................................................................................................................................... 10
V. LES SYSTEMES DE DETECTION D’INTRUSIONS RESEAU .......................................................................... 11
A. METHODES DE DETECTION ............................................................................................................................. 11
B. LIMITATIONS ............................................................................................................................................... 12
PARTIE 2 - EVALUATION ................................................................................................................................. 14

I. METHODOLOGIE ................................................................................................................................... 14
A. PLATEFORME DE TEST ................................................................................................................................... 14
B. LES OUTILS TESTES........................................................................................................................................ 15
C. LES OUTILS DE MISE A L’EPREUVE..................................................................................................................... 22
D. D’AUTRES OUTILS DE MISE A L’EPREUVE (NON MIS EN ŒUVRE) .............................................................................. 23
II. EVALUATION ......................................................................................................................................... 24
A. LES CRITERES ............................................................................................................................................... 24
B. RESULTATS ................................................................................................................................................. 25
CONCLUSION .................................................................................................................................................. 27
BIBLIOGRAPHIE .............................................................................................................................................. 28
ANNEXES ........................................................................................................................................................ 30
Les Systèmes de Détection d’Intrusions Réseau

Rapport de projet de 3ème année Page 1 sur 30
Table des figures
Figure 1 - Modèle CIDF ............................................................................................................................ 9
Figure 2 – Insertion (source insecure.org) ............................................................................................ 13
Figure 3 - Plateforme d'évaluation d'origine......................................................................................... 14
Figure 4 - Plateforme d'évaluation ........................................................................................................ 15
Figure 5 - AcidBASE................................................................................................................................ 16
Figure 6 - Architecture de Bro-IDS (Source bro-ids.org)........................................................................ 17
Figure 7 - Architecture de Prélude-IDS utilisée pendant l’évaluation ................................................... 18
Figure 8 - Architecture de Prélude-NIDS (source prelude-ids.org) ....................................................... 19
Figure 9 - Prewikka ................................................................................................................................ 19
Figure 10 - NFSen (source nfsen.sourceforge.net) ................................................................................ 20
Figure 11 - Création d'une Alerte .......................................................................................................... 21
Figure 12 - Client Nessus ....................................................................................................................... 22
Figure 13 – NMAP .................................................................................................................................. 23

Introduction
Les systèmes d’information sont omniprésents dans notre société. Les

données qu’ils contiennent et les services qu’ils rendent leur donnent une valeur
importante. De ce fait ils attirent de plus en plus de personnes malintentionnées
qui tentent de compromettre leur intégrité ou de voler des données. C’est pourquoi
il y a un besoin en termes de sécurité informatique toujours croissant. Ce besoin
s’exprime par l’apparition de nouveaux outils de sécurité précis et très réactifs mais
beaucoup aussi plus complexes.
Cette étude a été réalisée dans le cadre des projets techniques de 3ème année.
L’objectif est de réaliser un état de l’art dans le domaine des systèmes de détection
d’intrusions réseau et de réaliser une évaluation de quelques solutions existantes
sur le marché de la détection d’intrusion.
Dans un premier temps nous verrons pourquoi un système de détection

d’intrusions est nécessaire et quelle est sa valeur ajoutée. Ensuite nous détaillerons
les différents types d’IDS et nous nous intéresserons plus particulièrement aux IDS
réseau. Pour finir, nous ferons des tests comparatifs de quelques solutions.

Partie 1
Etat de l’art
I. Pourquoi les Systèmes de Détection d’Intrusions ?
A. L’émergence des nouvelles technologies
De nos jours, les systèmes d’information ont pris une place prépondérante dans notre
société. Les nouvelles technologies sont omniprésentes que ce soit sur le lieu de travail, dans les
moyens de transports ou bien dans les maisons. Ces systèmes sont devenus de plus en plus
communicants et se sont ouverts vers l’extérieur pour permettre un accès et un contrôle à
distance d’une application ou d’un appareil.
On note également un très fort essor ces dernières années d’Internet. Le nombre de
foyers et d’entreprises connectés à ce réseau croit de plus en plus tout comme les vitesses des
liaisons. Beaucoup d’opérations s’effectuent via Internet. De nouvelles technologies comme les
réseaux privés virtuels permettent d’utiliser ce réseau grand public comme moyen
d’interconnexion de réseaux.
Cette expansion d’Internet a été possible grâce à l’émergence d’un protocole de

communication réseau TCP/IP. Au niveau « Réseau » du modèle OSI (Open Systems
Interconnexion), l’Internet Protocol (IP), permet de gérer l’adressage des machines et le routage.
Au niveau « Transport », TCP/IP offre deux protocoles qui permettent l’acheminement point à
point des données : UDP (User Datagram Protocol) et TCP (Transmission Control Protocol),
l’un est orienté sans connexion et l’autre avec.
L’émergence de ces nouvelles technologies n’est pas sans conséquence. Tout d’abord
nous conservons désormais sous forme numérique des données sensibles et donc de grande
valeur. De plus, la place prise par l’informatique dans les entreprises ou la vie de tous les jours est
d’une importance telle, qu’une panne de réseau peut neutraliser une société et peut coûter une
somme d’argent très élevée. Ces deux états de fait amènent des personnes malintentionnées à
tenter de compromettre les systèmes d’information ou de voler des données en exploitant les
failles de sécurité. L’ouverture des systèmes sur Internet permet à l’attaquant d’avoir un accès plus
facile au réseau qu’il souhaite viser.
La dimension universelle d’Internet et des technologies du Web permettent le partage et

la vulgarisation des connaissances. Ceci permet une propagation rapide des nouvelles
vulnérabilités et de rendre accessible au plus grand nombre l’exploitation de celle-ci.
B. Vulnérabilité
Une vulnérabilité est une erreur dans le code d’une application qui permet à un pirate
d’exécuter une commande ou un morceau de code sur une machine cible. Les logiciels sont
devenus de plus en plus présents et sont de plus en plus complexe, leurs codes contiennent de
plus en plus de lignes. On estime que parmi 1000 lignes de code, 10 contiennent des erreurs et
donc des vulnérabilités potentielles.

Les vulnérabilités sont également introduites par les besoins et l’utilisation faite des
nouvelles technologies par les utilisateurs. Par exemple, en entreprise, de plus en plus d’employés
sont demandeurs de mobilité, c'est-à-dire de pouvoir accéder aux ressources du système
d’information de la société à distance (depuis son domicile ou un client). Dans ce cas on utilise les
réseaux privés virtuels qui nécessitent de laisser un accès depuis l’extérieur et l’utilisation d’une
application permettant d’établir la connexion. Dans ce cas, on introduit deux nouvelles
vulnérabilités. Au niveau du grand public, les réseaux peer-to-peer connaissent une grande
expansion cependant ils sont facteurs de propagation de vers, virus, chevaux de Troie, …
C. Profile des attaquants
On distingue différents types de pirate, on les classe suivant leurs objectifs, leurs connaissances et
leurs moyens.
1. Les script-kiddies
Ce sont généralement des adolescents (d’où le nom de script kiddies) qui utilisent des
scripts mis au point par de véritables pirates pour exploiter des vulnérabilités. Leur objectif
principal est la reconnaissance, ils n’ont pas de réelles connaissances et leur activité privilégiées est
le « web defacement » (défiguration de site web). Ils représentent une grande majorité des pirates.
2. Les hackers
Leur niveau de connaissances en système est beaucoup plus élevé que les script-kiddies.
Ils recherchent et exploitent les failles dans tous types de systèmes. Leur but n’est pas de voler
des données ou de compromettre un système. Ils ont pour principe d’informer les gens des
vulnérabilités qui sont présentes dans une application ou un serveur.
3. La menace interne
De manière générale, les employés disposent d’un accès au système d’information de la

société et selon les cas il peut connaître l’architecture du système. On distingue plusieurs types de
menaces au sein de l’entreprise :
• La corruption : L’employé revend les informations d’une base de données
• Social Engineering : Une personne tente de manipuler une personne du
service informatique ou de l’administrateur pour obtenir des informations qui
lui permettront d’accéder au système d’information
• Mise en commun : Plusieurs employés mettent en commun leurs droits
d’accès pour récupérer des données.
4. Les organisations
Certaines organisations étatiques ou terroristes possèdent d’énormes moyens matériels et

humains pour écouter les réseaux de communication à l’échelle mondiale. Les motivations sont
très souvent économiques.

D. Début des Systèmes de détection d’intrusions
Depuis 2000, le nombre d’attaques et de vulnérabilités ne cessent de croître, il faut

protéger les systèmes. Jusqu'à présent pour protéger les systèmes des attaques, on utilisait des
pare-feux.
Placés en bordure de réseaux, les firewalls sont efficaces pour autoriser ou pas l’accès à
une machine d’un réseau depuis l’extérieur, mais ils ne sont pas capables de vérifier le contenu
des paquets des flux autorisés. De plus une attaque contre un serveur peut être lancée depuis une
machine interne au réseau… Cette attaque ne pourra pas être détectée par le pare-feu.
Pour palier à ce problème et sécuriser le réseau en tout point, on peut mettre en place des
systèmes de détection d’intrusions (ou IDS). Les IDS sont des outils qui permettent de mettre en
évidence les activités inappropriées, incorrectes ou anormales sur un système ou un réseau
informatique. Ils permettent de mettre en évidence d’éventuelles intrusions en surveillant l’activité
d’un système pour recueillir différents évènements et en les analysants.
Les I.D.S. ont des rôles multiples. Leur principal objectif est la détection d’intrusions. Ils
peuvent être également utilisés pour contrôler la politique de sécurité des pare-feux, dans ce cas là
l’IDS vérifie que le trafic observé correspond bien à la politique de sécurité. On peut aussi
détecter les comportements polluants de certains éléments actifs du réseau.
II. Méthodologie d’une intrusion

« L'intrusion est le fait pour une personne ou un objet de pénétrer, dans un espace (physique, logique, relationnel)
défini où sa présence n'est pas souhaitée. » Une intrusion se réalise en plusieurs étapes.
A. Reconnaissance
Cette étape, aussi appelée prise d’empreinte permet d’obtenir des informations sur le réseau visé :
• Adresses IP
• Serveurs
• Services disponibles…
Ces renseignements peuvent être obtenus par le pirate en faisant du « social engineering », c'est-à-
dire obtenir les informations en manipulant une personne qui a la connaissance du système.
B. Découverte du système
1. Topologie
A l’aide d’outils comme traceroute, on détermine les voies d’accès au réseau (les routeurs
qui séparent l’attaquant du réseau visé).
2. Scanning et énumération
Une fois que la topologie est connue, on analyse les adresses IP du réseau avec un
scanneur de ports pour détecter les ports ouverts, les différents services disponibles et les
versions des systèmes d’exploitation.

C. Exploitation de failles de sécurité
Une fois les versions des différents serveurs et systèmes d’exploitation obtenues, il est
possible d’utiliser des scanneurs de failles telles que Nessus ou SAINT pour détecter les
vulnérabilités. Ensuite le pirate peut exploiter les failles trouvées pour s’introduire dans le
système :
• Obtenir des privilèges d’administrateur.
• Compromettre le système.
• Mettre en place une porte dérobée, pour que le pirate puisse continuer à infiltrer
le réseau de l’entreprise.
D. Les différents types d’attaques
1. Les Dénis de Services : les attaques réseau
Ce type d’attaque consiste à saturer les ressources d’un système de façon à l’empêcher de
fonctionner correctement.
Inondation : attaque de dénis de service la plus courante, elle consiste à envoyer un grand nombre
de paquets (exemple : SYN flood qui provoque l’ouverture des connexions sur le serveur et qui
provoque sa saturation).
Land et Latierra : La cible, la source et la destination du paquet sont identiques, ce qui provoque
une boucle infinie.
Attaques par fragmentation : Comme par exemple le teardrop qui consiste à utiliser des fragments de
paquets qui se recouvrent.
Ping de la mort : Paquet ICMP echo request de grosse taille.
2. Exploitation de vulnérabilités sur les services
Consiste à utiliser les vulnérabilités d’une application pour acquérir des privilèges sur le
système visé dans le but de le compromettre ou de détourner de l’information.
Exploitation contre des services web :

• Attaque de site web ou de serveur web (comme par exemple l’attaque unicode)
• Exploitation de scripts CGI
• Détournement de session
• Cross site scripting : permet l’exécution de code malicieux au sein de pages web
Attaques de niveau 2 : Empoisonnement du cache ARP d’une machine.
Buffer overflow : Il permet l’écrasement de données et peut provoquer une erreur de segmentation.
Dans ce cas il s’agit d’une forme de déni de service. Cependant il est possible d’injecter un « shell
code » qui va permettre au pirate d’obtenir une invite de commande de type shell sur la machine
cible.
Injection SQL : Possibilité de faire exécuter des instructions SQL par le biais de formulaires web.

3. Les attaques par portes dérobées et les canaux de communications cachés
Cette technique consiste à cacher un canal d’information parmi les flux de données
« normaux ».
III. Les différents types d’IDS

Il existe différents types d’IDS. On les classe suivant leur capacité de détection (les types
d’attaques qu’ils sont capable de détecter) et leur furtivité.
A. Host-based Intrusions Detection Systems
Les systèmes de détection d’intrusions système sont en charge de détecter les anomalies
sur un système précis. Ils permettent de surveiller l’activité du processeur, la mémoire, l’espace
disque disponible, l’intégrité des fichiers ou les tentatives de connexion. Ils peuvent également
réaliser une analyse des journaux du système ou des applications présents sur la machine.
Les IDS systèmes sont très peu furtifs, ils se présentent sous forme d’un processus et
utilisent des ressources systèmes. De plus il est nécessaire d’installer une sonde HIDS par
machine à monitorer. Ils sont également assez vulnérables, une personne ayant des droits
suffisants peut arrêter le processus. Cependant ils permettent de déterminer si une intrusion a
réussi. Les HIDS recueillent et analysent généralement les données de manière différée.
B. Network Intrusions Detection Systems
Les systèmes de détection d’intrusions réseau sont des sondes qui contrôlent l’activité du
réseau. Ils analysent les paquets et leur contenu à l’aide de techniques variées qui permettent de
détecter du trafic anormal ou une tentative d’intrusion. Ils sont furtifs, leur présence n’est pas
détectable. Placés en des points stratégiques sur le réseau, les NIDS ont une vue globale, une
sonde peut surveiller un réseau entier. Contrairement au HIDS, l’analyse du trafic réseau se fait
en temps réels.
C. Intrusions Prevention Systems
Les systèmes de prévention des intrusions est un système de détection d’intrusions réactif.
Lorsqu’une intrusion est détectée, l’IPS prend une contre-mesure pour bloquer l’attaque.
Généralement il indique au pare-feu d’interrompre une connexion ou de mettre en liste noire une
source d’attaque.
Dans ce cas, l’IDS devient un élément actif du réseau, il perd sa propriété de furtivité, il
est donc détectable par l’attaquant : Certaines attaques peuvent faire bloquer tout le réseau par
l’IPS… De plus l’IPS peut générer des faux positifs et ainsi bloquer des connexions légitimes.
Comme pour les IDS, il y a deux types d’IPS :
• Les NIPS : Network-based Intrusions Prevention Systems ou Inline Prevention

Systems.
• Les HIPS : Host-based Intrusions Prevention Systems

IV. Modèle et Normalisation
Le DARPA (Defense Advanced Research Projects Agency) a défini un modèle d’architecture qui
précise les composants d’un IDS : Le modèle CIDF. Pour assurer une interopérabilité entre les
différents composants, on utilise des normes qui définissent les règles de communication.
A. Le modèle CIDF
Ce modèle définit l’architecture d’un IDS. On distingue 4 entités appelées « Box » :

• E-box : Générateur d’évènements
• A-box : Analyseur d’évènements
• D-box : Stockage d’information
• C-box : Contre-mesure
1. Générateur d’évènements
Le but de la E-box et de fournir des évènements au système, c’est le protocole de bas niveau qui
permet de récupérer des informations pour les autres composants de l’IDS.
2. Analyseur d’évènements
L’analyseur d’évènements analyse les informations qui proviennent du générateur d’évènements.
Cette « box » va extraire les informations pertinentes grâce à des techniques basées sur les
signatures ou la détection d’anomalies.
3. Stockage d’information
Le générateur et l’analyseur d’évènements peuvent produire une grosse quantité d’informations
qu’il est important de stocker pour permettre une consultation par l’administrateur.
4. Contre-mesure
La plupart des IDS sont faits pour détecter uniquement, mais il est possible de rajouter un
module qui permet de contrer l’attaque.
Figure 1 - Modèle CIDF

B. IDXP
L’Intrusion Detection Exchange Protocol est un protocole de communication normalisé

qui permet d’échanger des informations au format IDMEF entre deux détecteurs d’intrusions. Ce
protocole supporte l’authentification mutuelle des entités communicantes, l’intégrité et la
confidentialité des messages. Ce protocole est décrit dans la RFC 4767, il a été créé par l’Intrusion
Detection Working Group de l’Internet Engineering Task Force (IETF).
C. IDMEF
L’Intrusions Detection Message Exchange Format est une norme qui définit le format
des données échangées et les procédures pour partager des informations entre deux éléments
d’un système de détection et de prévention d’intrusions. Ce langage peut être utilisé par un
gestionnaire des informations de sécurité (SIM) pour interagir avec un IDS. IDMEF se base sur
XML, une DTD a été définie par l’IETF.
Exemple : Message IDMEF d’un NIDS sur une attaque de type « phf » :
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFC XXXX IDMEF v1.0//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.0">
<Alert ident="abc123456789">
<Analyzer analyzerid="bc-sensor01">
<Node category="dns">
<name>sensor.example.com</name>
</Node>
</Analyzer>
<CreateTime ntpstamp="0xbc71e980.0x00000000">
2000-03-09T08:12:32-01:00
</CreateTime>
<Source ident="abc123">
<Node ident="abc123-001">
<Address ident="abc123-002" category="ipv4-addr">
<address>192.0.2.200</address>
</Address>
</Node>
<Service ident="abc123-003">
<port>21534</port>
</Service>
</Source>
<Target ident="xyz789">
<Node ident="xyz789-001" category="dns">
<name>www.example.com</name>
<Address ident="xyz789-002" category="ipv4-addr">
<address>192.0.2.100</address>
</Address>
</Node>
<Service>
<port>8080</port>
<WebService>
<url>
http://www.example.com/cgi-bin/phf?/etc/group
</url>
<cgi>/cgi-bin/phf</cgi>
<http-method>GET</http-method>
</WebService>
</Service>
</Target>
<Classification origin="bugtraqid">
<name>629</name>
<url>http://www.securityfocus.com</url>
</Classification>
</Alert>
</IDMEF-Message>

V. Les systèmes de détection d’intrusions réseau
Les IDS réseau ou NIDS analyse les paquets et leur contenu qui circulent sur le réseau.
A. Méthodes de détection
Il y a deux grandes catégories dans les méthodes de détection :
1. Détection par abus
Les méthodes de détection par abus utilisent une base de connaissance appelée base de
signatures qui décrit une attaque. Ces techniques impliquent que l’attaque doit être connue au
préalable. Les méthodes basées sur les signatures sont très efficaces, elles génèrent très peu de
faux-positifs. Cependant pour qu’un IDS soit performant, il faut que sa base de signature soit
mise à jour régulièrement pour détecter les nouvelles menaces.
Pattern matching : Les méthodes de détection par abus utilisent le « pattern matching ». L’IDS
analyse les paquets réseau et compare le contenu avec les signatures. S’il y a correspondance alors
il y a intrusion. On recherche dans les données des chaînes de caractères suspectes,
correspondant à des attaques connues.
Analyse protocolaire : L’IDS va vérifier que le paquet respecte bien les différentes RFC des
différents protocoles mis en jeu lors d’une communication.
Cependant cette méthode ne permet pas de détecter les variantes d’une attaque, pour
pallier à ce problème, des algorithmes heuristiques et génétiques sont utilisés. Ils permettent de
détecter les variantes en effectuant des approximations en un temps raisonnable.
Exemple de signature :
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-MISC /etc/passwd";flags: A+;

content:"/etc/passwd"; nocase; classtype:attempted-recon; sid:1122; rev:1;)
2. Détection d’anomalies
Les IDS utilisant la détection d’anomalies sont appelés IDS comportementaux. Ces outils
comparent le comportement observé par un comportement dit « normal ». La déviation entre le
profile normal et le comportement observé est calculé. Au-delà d’une certaine limite (notion de
seuil), le trafic est considéré comme étant anormal.
Ce type d’IDS nécessite une période d’apprentissage pour définir le comportement

normal du système. Bien que générant de nombreux faux-positifs, cette méthode de détection a
l’avantage de détecter des attaques inconnues. Cependant il est parfois difficile de définir un
profile « normal » et ces outils peuvent être difficiles à mettre en place.
La détection d’anomalies fait appel à différentes notions de statistique, de probabilité et

d’intelligence artificielle :
Méthodes statistiques : On construit le comportement normal en quantifiant certains paramètres liés

à un évènement (occupation mémoire, durée de connexion…). Ensuite on calcule la déviation de
ses paramètres entre le comportement normal et celui qui est observé.

Seuils : Il s’agit d’utiliser des compteurs (nombre de connexion, …) lorsqu’une valeur dépasse un
certain seuil (threshold), on en déduit qu’il y a intrusion.
Méthodes probabilistes : Cette approche définit la probabilité de chaque évènement susceptible de se

produire à la suite d’un autre.
Réseaux de neurones : C’est un modèle de calcul inspiré du fonctionnement de vrais neurones. Le

but est de faire apprendre au réseau de neurones le comportement normal du réseau. Lors d’un
évènement il pourra ensuite calculer la suite du comportement. Si ce dernier dévie, alors il y a
intrusion.
Classifieur de Bayes : Après une période d’apprentissage sur des caractéristiques d’un flux ou d’une
connexion, le classifieur pourra déterminer si le comportement courant est une attaque ou pas.
Machines à support de vecteurs : ou séparateur à vaste marge est une technique d’apprentissage
supervisé capable de comparer deux objets (comportement normal et observé) et de les classer.
B. Limitations
1. Le placement des IDS
Le trafic observé par le NIDS dépend de son positionnement sur le réseau. Intercalé entre
le pare-feu et le réseau, le NIDS aura une vue sur le trafic entrant et sortant du réseau mais il ne
verra pas les échanges entre les machines du réseau. Il existe différentes méthodes pour récupérer
les informations sur le réseau :
• Les boitiers TAP qui permettent de placer un NIDS sur un lien spécifique du réseau.
• Le port mirroring, le commutateur réplique toutes les données reçues sur un port.
2. Pollution/surcharge
L’IDS peut être victime d’une attaque par surcharge ou pollution pour cacher une attaque
de plus grosse envergure. Ce type d’attaque a pour effet de le saturer et donc de ne plus assurer sa
fonction correctement.
Il faut savoir dimension les capacités de l’IDS en fonction de la taille du réseau et la

quantité de flux qu’il faut analyser. Pour pouvoir être efficace, un NIDS doit analyser le
maximum de paquets. Pour les réseaux à hauts débits, il est possible mettre en place des clusters
d’IDS et ainsi de distribuer sur plusieurs machines l’analyse et le stockage des évènements.
3. Contournement/évasion
Il existe des méthodes pour leurrer un NIDS. Dans le cas d’une attaque par évasion, le
NIDS va rejeter le paquet parce qu’il ne sera pas conforme alors que la cible va l’accepter.
Fragmentation : Des attaques comme le teardrop qui consiste à envoyer deux fragments qui se
recouvrent peuvent leurrer le pattern matching. On peut cacher une attaque au niveau applicatif
en fragmentant un paquet.

Insertion : L’IDS peut accepter un paquet qui la cible peut rejeter. Si ce paquet vient s’intercaler au
milieu d’une attaque, il va perturber le fonctionnement de l’IDS qui de ce fait ne verra pas
l’attaque.
Figure 2 – Insertion (source insecure.org)
Substitution : On peut remplacer une chaîne de caractère par son équivalent en hexadécimal :
GET %65%74%63/%70%61%73%73%77%64
L’IDS ne sait pas que cette requête sera interprétée par le serveur web qui fournira en réponse la
liste des mots de passe du système.
Elimination : Consiste à rendre l’IDS inutile en l’inondant d’information par exemple.
4. Temps de détection
Le temps de détection dépend de l’utilisation que l’on souhaite faire de l’IDS. Si l’on
souhaite contrer une attaque, il est évident que le temps de détection doit être le plus petit
possible. L’IDS doit donc réaliser une analyse en temps réel, il doit être suffisamment
dimensionné pour pouvoir traiter l’ensemble du trafic en un temps raisonnable.
Certains IDS stockent le trafic réseau et ne réalisent des analyses des données
régulièrement (toutes les trente minutes par exemple).

Partie 2
Evaluation
I. Méthodologie
A. Plateforme de test
1. Plateforme d’origine
Figure 3 - Plateforme d'évaluation d'origine
La plateforme de test d’origine était composée :

• D’une machine réelle sous Debian Linux (Pentium M 1,7Ghz - 512 Mo de RAM)
• De trois machines virtuelles :
o Une machine réservée pour les NIDS et leurs outils d’administration
o Une machine sous Windows XP qui servait de cible
o Une machine sous Debian Linux Etch qui servait de cible
L’attaque était lancée depuis la machine réelle à destination de la machine virtuelle sous Windows
XP et à destination de la machine virtuelle sous Linux. Cette configuration demandait beaucoup
de mémoire à la machine hôte qui n’en avait que 512 Mo, de plus bien que normalement Vmware
doit agir comme un hub, les données de l’attaque n’étaient pas transmises sur la machine
hébergeant l’IDS.

2. Nouvelle plateforme
Figure 4 - Plateforme d'évaluation
Pour pallier au problème de mémoire et à l’effet Switch des interfaces réseau de Vmware,
la plateforme a été modifiée. Elle est composée d’une machine réelle, à partir de laquelle on lance
les attaques et d’une machine virtuelle qui est la cible et qui héberge l’IDS. Sur cette machine ont
également été installés quelques services comme un serveur Web, un serveur de base de
données…
B. Les outils testés
1. Snort
Snort est un système de détection et de prévention d’intrusions réseau open source. Il se

base sur des méthodes de la détection d’abus et d’anomalies. Snort a quatre modes de
fonctionnement :
• Le mode sniffeur, Snort affiche les paquets réseau
• Le mode packet logger, Snort journalise le trafic réseau dans un fichier
• Le mode NIDS
• Le mode IPS
Snort possède une architecture modulaire, il est composé :

• d’un noyau de base qui charge les règles en mémoire,
• d’un moteur de décodage et de détection qui permet de vérifier qu’un paquet
réseau a été construit suivant les normes et qui se charge de détecter les intrusions
à partir des signatures,
• d’une série de préprocesseurs qui apportent des améliorations en matière d’analyse
• et d’une série de plugins de sortie (output) pour journaliser les intrusions.

Les préprocesseurs reçoivent le trafic réseau, analysent, recomposent les paquets et les
donnent au moteur de décodage et de détection. Voici quelques exemples de préprocesseurs :
• flow : Ce préprocesseur observe tout le trafic et garde une trace de toutes les
connexions TCP
• frag2 : Ce préprocesseur permet de recomposer les paquets réseau fragmentés.
• http_inspect : Ce préprocesseur permet de mettre en forme le trafic http dans un
format qui donne aux règles les meilleures chances d’y faire correspondre des
signatures.
Les plugins de sortie permettent de configurer la destination des résultats :

• Syslog : Les alertes sont envoyées à Syslog
• Log_tcpdump : Les paquets qui ont causé l’alerte sont stockés sous forme de fichier
TCPDUMP
• Base de données : Les alertes sont stockées dans une base de données. Snort est
capable de gérer les SGBD MySQL, PostgreSQL et Oracle.
• Unified : Snort enregistre les alertes et les journaux dans un fichier binaire lisible
par Barnyard. Ce format de fichier est très rapide.
Snort se base sur des fichiers de règles pour détecter les intrusions. Il est donc important
de les mettre à jour régulièrement. Voici un exemple de règle snort :
alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111 (content: "|00 01 86 a5|"; msg:
"external mountd access";)
Snort fonctionne essentiellement en ligne de commande. Il existe de nombreux outils

pour administrer la configuration et visualiser les alertes. Pour la plateforme de test, Base (Basic
Analysis and Security Engine) a été installé pour visualiser les alarmes levées par Snort. Cette
application fournit une interface web pour interroger et analyser les alertes.
Figure 5 - AcidBASE

2. Bro
Bro-IDS est un système de détection d’intrusion réseau. Il est destiné aux environnements
de type Unix comme Linux ou OpenBSD. Il observe le trafic réseau de manière passive à la
recherche d’activités suspicieuses.
Bro détecte les intrusions en analysant le trafic réseau, il vérifie les données du niveau
applicatif et exécute son analyseur orienté évènement pour comparer l’activité avec une base de
signatures d’attaques.
Cet IDS est architecturé autour de trois composants majeurs :

• Libpcap : Bro utilise la libpcap pour récupérer le trafic réseau.
• Event engine : Ce composant génère des évènements à partir du trafic réseau
capturé.
• Policy script interpreter : Ce module procède à l’analyse des évènements, il fait appel à
des scripts qui appliquent la politique de sécurité. Ce composant peut également
lancer la réponse à l’intrusion (lancement de scripts…)
Exemples d’évènements générés par l’ « Event engine » :
new_connection(c: connection)
new_packet(c: connection, p: pkt_hdr)
connection_established(c: connection)
Figure 6 - Architecture de Bro-IDS (Source bro-ids.org)
Lors de la phase d’évaluation, aucun outil d’administration et de visualisation des

journaux n’a été trouvé pour Bro-IDS. Il envoi simplement un mail résumant les intrusions
détectées. Les fichiers de journalisation peuvent être exploitables par un SIM.

3. Prelude
Prélude est un système de détection d’intrusion hybride, c’est-à-dire qu’il est à la fois un
Host-based IDS et un Network-based IDS.
La détection d’intrusion se réalise à partir de deux sources différentes :

• L’analyse du trafic réseau (NIDS)
• L’analyse en continue de fichiers de journalisation
L’architecture de Prelude-IDS se compose :

• de sondes qui effectuent des opérations de surveillance et de génération d’alerte
• de managers qui sont chargés de gérer les différentes sondes et de journaliser les
alertes.
• d’une application web qui permet de visualiser les alertes.
On peut donc dire que cet outil est modulaire et est distribué. On peut également noter
que les communications entre la sonde et le manager sont chiffrées et qu’une procédure
d’association sécurisée permet à une sonde de joindre un manager.
Prelude est aussi capable de mettre en œuvre une contre-mesure qui permet de définir
une réaction à une attaque. La communication entre les sondes et le manager utilisent IDMEF.
Counter
Measure Agnets
Sonde
Prelude-lml Base de données
MySQL
Sonde Manager
Prelude-lml Prelude-lml
Front-end
Prewikka
Sonde
Prelude-lml
Figure 7 - Architecture de Prélude-IDS utilisée pendant l’évaluation
Architecture de Prélude-NIDS
Le trafic réseau est capturé grâce à la libpcap. Quand un paquet est reçu, Prélude effectue
à une vérification de sa structure et ensuite il procède au réassemblage des connexions TCP et
défragmente les paquets IP. A partir de là, le paquet est transmis au « protocol plug-ins ». Ce
moteur permet de décoder les protocoles de plus haut niveau (RPC, http, …). Ensuite le paquet
est transmis au « signature engine » pour vérifier si le contenu correspond à une signature. Les
signatures sont extensibles, il est possible de rajouter des modules qui permettent de parcourir
des paquets spécifiques à une application.

Figure 8 - Architecture de Prélude-NIDS (source prelude-ids.org)
Sur la plateforme d’évaluation, l’application web Prewikka permet de visualiser les alertes
de Prélude.
Figure 9 - Prewikka
Cette interface permet de voir que Prélude est capable de gérer deux types d’alertes : Les
alertes provenant du moteur de détection de Prélude et celles qui proviennent de l’analyse en
continue des fichiers de journalisation. On peut également voir qu’il est possible de créer des
règles de corrélation entre les alertes et d’en générer de nouvelles.

4. NFSen pour Netflow
Netflow est un protocole réseau ouvert mais propriétaire développé par Cisco. Il sert à
collecter des informations sur le trafic IP d’un réseau.
Certains routeurs (surtout Cisco) sont capables de générer des enregistrements Netflow
(netflow record) contenant, suivant les versions, un certain nombre d’informations concernant un
flux. Un flux est défini comme étant une séquence de paquets partageant les propriétés suivantes :
• Adresse IP source
• Adresse IP destination
• Protocole Transport
• Port source
• Port destination
• Protocole IP
Exemple d’enregistrement Netflow
Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes Flows
2005-08-30 06:53:53.370 63.545 TCP 113.138.32.152:25 -> 222.33.70.124:3575 .AP.SF 0 62 3512 1
2005-08-30 06:53:53.370 63.545 TCP 222.33.70.124:3575 -> 113.138.32.152:25 .AP.SF 0 58 3300 1
NFSen, NetFlow Sensor, est une manière graphique de représenter les flots.
Figure 10 - NFSen (source nfsen.sourceforge.net)

NFSen permet de définir des profiles, c'est-à-dire de créer des filtres et d’afficher des
graphiques selon une ou plusieurs caractéristiques. Par exemple on peut choisir de représenter
graphiquement que les flux d’un port particulier. Le profil ‘live’ représente tous les flux, sans
filtrage.
A partir d’un profile particulier ou du profile ‘live’, il est possible de définir des alarmes,
généralement basée sur des seuils. Dès qu’une condition est atteinte, une alarme est levée ; Les
conditions peuvent être définies à partir de l’observation des flux dans leur totalité, à partir d’une
caractéristique mesurée par NFSen (nombre de paquets) ou à partir de données renvoyées par un
plug-in.
Figure 11 - Création d'une Alerte
NFSen est modulaire, il est possible d’y ajouter des plug-ins qui réalisent des calculs à
partir des flux. D’autres plug-ins permettent d’exécuter une action (exécution de script,
journalisation dans une base de données de l’alerte…) lorsqu’une alerte est levée.
NFSen n’est pas à proprement dit un NIDS, il s’agit d’un visualisateur graphique de flots
réseau, mais on peut s’en servir en tant que tel. Les fonctionnalités d’historisation des flux, de
définition de profiles et d’alertes par seuils peuvent permettre de dire qu’il s’agit d’un détecteur
d’anomalies orienté flux.

C. Les outils de mise à l’épreuve
1. Nessus
Nessus est un scanneur de vulnérabilités pour réseau. Il détecte les machines présentes
sur le réseau, effectue une énumération des ports ouverts, détermine les services avec leur version
et tente d’attaquer les services disponibles.
Ce programme se décompose en deux parties, il est composé d’un daemon qui exécute le
scan de vulnérabilités et d’un client qui récupère et met en forme les informations recueillies par
le daemon. Nessus est modulaire, il est possible de rajouter des plug-ins pour tester de nouvelles
vulnérabilités.
La version de Nessus installée pour l’évaluation contient 3814 plug-ins. Le but est de voir
si les NIDS détectent le scan de ports réalisé par Nessus ainsi que toutes les tentatives
d’exploitation des vulnérabilités.
Figure 12 - Client Nessus

2. NMAP
Nmap est un scanneur de ports, il détecte sur une machine distante les ports ouverts, les
services et des informations sur le système d’exploitation.
Le but est de voir si les NIDS détectent un scan XMAS. Le scan XMas Tree utilise des
flags TCP incorrects (URG, PSH et FIN). Si le port est fermé, l’attaquant recevra un paquet RST
sinon le paquet est détruit.
Figure 13 – NMAP
3. Nikto
Ce programme est un scanneur de vulnérabilités de serveurs web. Il utilise Whisker, un

scanneur de vulnérabilités de scripts CGI.
D. D’autres outils de mise à l’épreuve (non mis en œuvre)
1. IDSWakeup
IDSWakeup est un générateur de faux positif, il a pour but de tester les NIDS. La
dernière version datant de 2000, il ne paraît pas très opportun de l’utiliser pour l’évaluation.
2. Snot et Stick
Stick est un outil de stress pour IDS, il permet de déterminer le point de saturation.
Snot permet de générer des fausses attaques à partir d’un fichier de règles snort.
3. Fragroute
Cet outil permet de tester les techniques d’évasion des NIDS en utilisant la fragmentation
des paquets IP.

II. Evaluation
A. Les critères
Cette évaluation prend en compte des critères de différentes natures.
1. Administration
Configuration : Existe-t-il des outils facilitant la configuration de l’outil ?
Ajout de règles : Localisation des règles, utilisation d’une syntaxe simple, ajout possible ?
Analyse des alertes : Existe-t-il des applications qui permettent une visualisation des alertes ?
2. Type d’IDS
Type : Quel est le type d’IDS ? IDS réseau, IDS système ou IDS hybride
Méthodes d’analyses : L’IDS utilise-t-il un moteur de détection d’anomalies ou d’abus ou les deux ?
3. Respects des standards
IDMEF : Dans le cas d’IDS distribués, est-ce que l’IDS respect le standard IDMEF ?
CIDF : Est-ce que l’IDS est conforme au modèle CIDF ?
Interopérabilité : Est-il possible de faire fonctionner cet IDS avec un autre ?
4. Architecture
Architecture du moteur de détection : Est-il possible de rajouter des plug-ins au moteur de détection ?
Architecture logicielle : L’IDS est-il sous forme d’un seul programme ? Est-il possible de répartir des
sondes (IDS distribué) ?
5. Performance temporelle
Type d’analyse : L’IDS effectue-t-il une analyse en continue ou par batch ? Est-ce que l’analyse est
en temps réelle ?
6. Performance de détection
Combien d’alarmes ont été levées par l’IDS au cours des différents tests ?

B. Résultats
Snort Prélude-IDS Bro-IDS NFSen
Administration
Configuration Il faut éditer le fichier de Il faut éditer le fichier de Edition des fichiers de Utilisation de l’interface
configuration, il existe des configuration, il existe des configuration à la main web
outils graphiques outils graphiques
Maintenance des signatures Il faut mettre à jour les Il faut récupérer la dernière -
signatures, il existe des version de l’IDS ou ajouter
outils pour le faire des signatures
automatiquement. manuellement.
La syntaxe des signatures Un langage de script permet

est facile à utiliser d’ajouter des politiques de
sécurité
Analyse des alertes Utilisation de l’interface Utilisation de l’interface Il faut utiliser un SIM pour Utilisation de l’interface
web (AcidBase) web (Prewikka) analyser les alertes web
Type
Envergure d’analyse Réseau uniquement Hybride Réseau uniquement Réseau uniquement (Flux)
Contre mesure Oui (module interne) Oui Oui Oui (plug-ins)
Méthode d’analyse Méthode de détect.par abus Méthode de détection par Méthode de détection par Méthode de détection par
et par anomalies (seuils) abus (signatures) abus orientée évènement anomalie (seuils)
Standards
IDMEF Non Oui, dialogue entre les Non -
sondes et le manager
Modèle CIDF E-Box : Préprocesseur E-Box et A-Box : Sonde E-Box : Event engine A-Box : Plug-ins
D-Box : Plug-ins output D-Box : Manager A-Box D-Box: Policy script C-Box : Plug-ins
C-Box : Manager interpreter E-Box : Netflow
C-Box : Plug-ins
Interopérabilité Non Oui Non Non

Snort Prélude-IDS Bro-IDS NFSen
Architecture
Modularité Oui, notion de Oui, on peut rajouter des Non Oui, notion de plug-ins
préprocesseur plug-ins pour l’analyse
Architecture logicielle Un seul processus En trois partie : Les sondes, Un seul processus Un processus qui recueille
Tout dépend du plugin le manager et l’application les flux, un processus
d’output, on peut stocker Web donc distribuable. (nfsend) qui réalise les
les informations sur une calculs et une interface web.
autre machine
Performance temporelle
Méthode d’analyse Temps réels Temps réels Temps réels Différé
Remontée des informations En continu Pulsation (Batch) En continu Batch
Performance de détection
NMAP Agressif 0 1 2 -
NMAP XMAS Scan 0 1 2 -
Nessus 1031 85 1107 -
Nikto 25 0 500 -
Nikto IDS Evasion 29 0 306 -
1er constat : Bro-IDS génère beaucoup d’alarmes.

Snort ne détecte pas les scans de ports qui sont pourtant un moyen de reconnaissance du système avant attaque. Prélude-IDS fournit trop peu de
résultats, une erreur de configuration en est peut-être à l’origine.

Conclusion
Cette étude a permis de montrer qu’il existait trois types de systèmes de

détection d’intrusions : Les systèmes basés réseau, les systèmes basés hôtes et les
systèmes hybrides.
Les systèmes de détection d’intrusions réseau utilisent deux méthodes

d’analyse, la détection par abus et la détection par anomalies. La détection par abus
se base sur des règles, des signatures qui décrivent un contenu malicieux ou un
scénario d’attaque. Cette méthode est jugée fiable, elle génère très peu de faux-
positifs. En contre partie, on peut détecter que des attaques connues.
La détection d’anomalies se base sur des notions de seuils, sur des modèles
statistiques ou probabilistes ou sur des notions d’intelligence artificielle. Elle
présente l’avantage de détecter des attaques inconnues, cependant cela nécessite
une période d’apprentissage pour générer ce que l’on appelle « le comportement
normal ». Ces méthodes calculent la déviation entre le comportement observé et le
comportement dit normal. Si cette déviation est trop importante, une alarme est
levée.
L’évaluation des solutions proposées dans cette étude montre que ces outils
utilisent majoritairement des méthodes de détection basées sur l’abus, cela
s’explique par le fait que les méthodes de détection par anomalies sont encore au
stade expérimental et qu’il est difficile de les mettre en œuvre.
On peut également observer que toutes les solutions proposent, soit sous
forme de plug-ins ou alors nativement, la possibilité de lancer une contre mesure
dès qu’une alerte se déclenche.
Cependant on peut constater qu’il y a des différences sur les performances

de détection. Elles peuvent venir du fait que les IDS n’ont pas la même base de
signatures et peut-être que la configuration des moteurs de détection n’était pas
optimale.
Cette étude pourrait être approfondie en s’intéressant aux NIDS utilisant

des méthodes de détection d’anomalies. Pour cela il est nécessaire d’avoir un
réseau réel de taille suffisante pour obtenir une grosse quantité de données
concernant le trafic. Ces informations permettraient de définir un comportement
par défaut significatif et de pouvoir sur la définition de seuils ou les réseaux
neurones.

Bibliographie
Livres
Thierry Evangelista. Les IDS, Les Systèmes de détection d’intrusions informatiques. Dunod, 2004.
Kerry Cox & Christopher Gerg. Snort et les IDS. O’Reilly, 2004.
Rafeeq Ur Rehman. Intrusion Detection Systems with Snort: Advanced IDS Techniques with Snort, Apache,
MySQL, PHP, and ACID. Prentice Hall PTR, 2003.
Publications
Gaia Maselli, Luca Deri et Stefano Suin. Design and Implementation of an Anomaly Detection System : an
Empirical Approach. In Proceedings of Terena TNC, 2003.
Kumar, Sandeep. Classification and detection of computer intrusions. PhD thesis, Purdue University,
1995.
Sankalp Singh et Srikanth Kandula. Argus : A distributed network-intrusion detection system.

Undergraduate Thesis, Indian Institute of Technology, mai 2001.
Douglas J. Brown, Bill Suckow, and Tianqiu Wang. A Survey of Intrusion Detection Systems.
Department of Computer Science, University of California, San Diego, Spring 2003.
Stefan Axelsson. Intrusion Detection Systems : A Survey and Taxonomy. Department of Computer
Engineering, Chalmers University of Technology, Göteborg, Sweden, mars 2004.
Aleksandar Lazarevic, Levent Ertoz, Vipin Kumar, Aysel Ozgur and Jaideep Srivastava. A
Comparative Study of Anomaly Detection Schemes in Network Intrusion Detection. Computer Science
Department, University of Minnesota.
Thomas H. Ptacek and Timothy N. Newsham. Insertion, Evasion, and Denial of Service: Eluding
Network Intrusion Detection. Secure Networks, Inc., Janvier 1998.
Dagorn, Nathalie. Détection et prévention d’intrusion : présentation et limites. INRIA Lorraine – LORIA,
2006

Sites Web
Généralités sur les IDS
http://www.webopedia.com/DidYouKnow/Computer_Science/2005/intrusion_detection_prev
ention.asp
http://lehmann.free.fr/RapportMain/RapportMain.html
Scan de vulnérabilité
http://www.hsc.fr/ressources/outils/idswakeup/
http://www.nessus.org/nessus/
http://en.wikipedia.org/wiki/Vulnerability_scanner
http://sectools.org/web-scanners.html
Outils IDS
http://www.bro-ids.org/
http://www.prelude-ids.com/
http://www.snort.org/
http://nfsen.sourceforge.net/
http://en.wikipedia.org/wiki/Netflow

Annexes
Cahier des charges

Cahier des charges du Projet NIDS : Etat de l’art et évaluation
Etat Avancement
Etat d’avancement du projet au 25 Janvier 2008
Résultats NMAP
Résultat du scan NMAP avec l’option XMas Tree Scan
Aide de Nikto
Aide en ligne de Nikto
Résultat Nikto
Résultat du scan de vulnérabilités de Nikto
Résultat Nessus
Résultat du scan de vulnérabilités de Nessus

Les Systèmes de Détection d'Intrusions
Réseau
Cahier des charges

Bertrand Sobesto
bertrand.sobesto@ensi-bourges.fr
Janvier 2008
Résumé
Ce document est un cahier des charges. Il a pour objectif de dénir :
1. Le contexte de ce projet
2. Le but
3. Les grandes étapes de réalisation
Table des matières
1 Introduction 2
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Objectifs 3
2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Buts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Echéances 4
3.1 Les étapes de réalisation . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Recherche de documentation . . . . . . . . . . . . . . . 4
3.1.2 Détermination de critères . . . . . . . . . . . . . . . . 4
3.1.3 Recherche de solutions logicielles . . . . . . . . . . . . 4
3.1.4 Plateforme de test . . . . . . . . . . . . . . . . . . . . 5
3.1.5 Déploiment des NIDS . . . . . . . . . . . . . . . . . . . 5
3.2 Calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1
Chapitre 1
Introduction
1.1 Contexte
Ce projet est réalisé dans le cadre de la troisième année à l'Ecole Nationale
Supérieure d'Ingénieurs de Bourges. C'est également un travail préparatoire
au stage de 6 mois à l'Université du Maryland, USA.
Encadrant Monsieur Christian TOINARD
Etudiant Bertrand Sobesto, option Sécurité des Systèmes d'Information
1.2 Sujet
Ce pro jet s'intitule : Etat de l'art des systèmes de détection d'intrusions

réseau .
2
Chapitre 2
Objectifs
2.1 Problématique
La problématique de ce projet est de déterminer les diérents types de

détecteurs d'intrusions réseau (ou NIDS1 ) existants ainsi que leur ecacité
(avantages/inconvénients).
2.2 Buts
Après une courte présentation pour déterminer pourquoi il est utile d'uti-
liser un détecteur d'intrusion, on verra les diérents types d'outils de détec-
tion d'intrusion (système et réseau). Par la suite, l'étude se focalisera sur les
systèmes de détection d'intrusion réseau.
Le but de cet état de l'art est de dénir de manière exhaustive les diérentes
méthodes d'analyse des paquets et de tester l'ecacité des solutions logicielles
disponibles actuellement.
1 NIDS : Network Intrusion Detection System
3
Chapitre 3
Echéances
3.1 Les étapes de réalisation
Ce projet va se découper en plusieurs étapes :
3.1.1 Recherche de documentation
Une première étape de ce projet va consister à rechercher des informa-

tions sur le sujet et donc de lire les diérentes publications pour avoir une
idée précise de l'état de la recherche dans ce domaine. Ceci va permettre de
déterminer les diérentes méthodes de détection et les diérentes analyses
eectuées par les NIDS.
Dans cette étude, on s'orientera plus spéciquement vers :

1. Les NIDS basés sur les signatures,
2. Les détecteurs d'anomalies, plus particulièrement sur les ux.
3.1.2 Détermination de critères
An d'évaluer et de comparer des solutions logicielles, il est nécessaire

de dénir des critères basés sur des caractéristiques et les performances de
détection.
3.1.3 Recherche de solutions logicielles
Cette étape va consister à rechercher quelques solutions logicielles de NIDS

qui utilisent des méthodes d'analyse et de détection diérentes.
4
3.1.4 Plateforme de test
Pour évaluer les performances des solutions logicielles sélectionnées, il est

nécessaire de mettre en place une architecture de test composée de plusieurs
machines virtuelles fonctionnant sous diérents systèmes d'exploitation tels
que Linux ou Windows. Cette architecture sera composée d'une machine
attaquante, d'un NIDS et d'une cible.
3.1.5 Déploiment des NIDS
Cette phase permettra de tester les NIDS. Suivant les critères d'évaluation
et les caractéristiques de la solution déployée, diérents types d'attaques se-
ront eectuées. Cette étape permettra d'évaluer et de comparer les diérents
NIDS choisis.
3.2 Calendrier
Jeudi 20 Décembre
Dénition du sujet
Semaine 1 (24/12 au 30/12)

Recherche de documentation sur les NIDS
Semaine 2 (31/12 au 6/01)

Recherche de documentation sur les NIDS
Semaine 3 (7/01 au 13/01)

Recherche de documentation sur les NIDS basés sur la détection d'anoma-
lies/ux
Semaine 4 (14/01 au 20/01)

Recherche de solutions logicielles, dénition des critères
Semaine 5 (21/01 au 27/01)

Mise en place de la plateforme de test, évaluation des NIDS
Semaine 6 (28/01 au 03/01)

Dénition du plan du dossier, rédaction et préparation orale
5
Les Systèmes de Détection d’Intrusions
Réseau
Avancement du projet
Bertrand Sobesto
bertrand.sobesto@ensi-bourges.fr
25 Janvier 2008
Partie 1 – Bibliographie
Livres
Thierry Evangelista. Les IDS, Les Systèmes de détection d’intrusions informatiques. Dunod, 2004.
Kerry Cox & Christopher Gerg. Snort et les IDS. O’Reilly, 2004.
Rafeeq Ur Rehman. Intrusion Detection Systems with Snort: Advanced IDS Techniques with Snort,
Apache, MySQL, PHP, and ACID. Prentice Hall PTR, 2003.
Publications
Laura Oller. Etude des Systèmes de détection d’intrusions réseau comportementaux. ENSI Bourges,
Juin 2006.
Gaia Maselli, Luca Deri et Stefano Suin. Design and Implementation of an Anomaly Detection System :
an Empirical Approach. In Proceedings of Terena TNC, 2003.
Kumar, Sandeep. Classification and detection of computer intrusions. PhD thesis, Purdue University,
1995.
Sankalp Singh et Srikanth Kandula. Argus : A distributed network-intrusion detection system.

Undergraduate Thesis, Indian Institute of Technology, mai 2001.
Douglas J. Brown, Bill Suckow, and Tianqiu Wang. A Survey of Intrusion Detection Systems.
Department of Computer Science, University of California, San Diego, Spring 2003.
Stefan Axelsson. Intrusion Detection Systems : A Survey and Taxonomy. Department of Computer
Engineering, Chalmers University of Technology, Göteborg, Sweden, mars 2004.
Aleksandar Lazarevic, Levent Ertoz, Vipin Kumar, Aysel Ozgur and Jaideep Srivastava. A Comparative
Study of Anomaly Detection Schemes in Network Intrusion Detection. Computer Science Department,
University of Minnesota.
Thomas H. Ptacek and Timothy N. Newsham. Insertion, Evasion, and Denial of Service: Eluding
Network Intrusion Detection. Secure Networks, Inc., Janvier 1998.
Dagorn, Nathalie. Détection et prévention d’intrusion : présentation et limites. INRIA Lorraine –

LORIA, 2006
Sites Web
Généralités sur les IDS
http://www.webopedia.com/DidYouKnow/Computer_Science/2005/intrusion_detection_prevention
.asp
http://lehmann.free.fr/RapportMain/RapportMain.html
Scan de vulnérabilité
http://www.hsc.fr/ressources/outils/idswakeup/
http://www.nessus.org/nessus/
http://en.wikipedia.org/wiki/Vulnerability_scanner
http://sectools.org/web-scanners.html
Outils IDS
http://www.bro-ids.org/
http://www.prelude-ids.com/
http://www.snort.org/
http://nfsen.sourceforge.net/
http://en.wikipedia.org/wiki/Netflow
Partie 2 – Evaluation des IDS
I - Plateforme de test
Simulation d’attaques :
• NESSUS (Scanner de vulnérabilités OS et applications)

• NMAP (Scanner de ports)
• Nikto (Scanner de vulnérabilité http)
• Whisker (Scanner de vulnérabilité CGI)
• IDSWakeup
• NIDSBench (Fragroute + Tcpreplay )
II - Critères d’évaluation
Administration :
• Configuration
• Ajout de règles
• Analyse des alertes
Type d’IDS :
• Signatures/Comportemental
Architecture logicielle :
• Boîte noire/Modulaire
Respect des standards :
• CIDF
• IDXP
• IDMEF
Performance :
• Nombre d’alertes au différents testes

• Temps
o Lancement du teste
o Date 1ère alerte
o Date dernière alerte
• Limites
o Testes de contournement des I.D.S.
III - Les solutions logicielles
• Prelude IDS
• Snort
• Bro
• NFSen
Partie 3 – Plan du Rapport
Sommaire
Table des figures
Introduction
• Contexte du projet
o Projet technique de 3A
• Définition IDS
o L’art de détecter les activités inappropriées, incorrectes ou anormales sur un
système ou un réseau informatique.
o Etude qui s’oriente vers les NIDS
Partie 1 – Systèmes de détection d’intrusions réseau : Etat de l’art
Pourquoi les IDS ?
• Expansion d’Internet, ouverture des systèmes

• Augmentation du nombre d’incidents
• Le protocole IP qui s’impose comme un standard, développement des technologies du web
• En entreprise :
o Ouverture des systèmes vers les différents partenaires (clients, fournisseurs…)
o Mobilité des usagers (VPN, population d’utilisateurs détachés physiquement de leur
entreprise).
• Grand public :
o Développement des réseaux peer-to-peer, vecteurs de propagation des vers, virus,
chevaux de Troie…
Le début des IDS
• On a tendance à protéger les réseaux des attaques provenant de l’extérieur, les systèmes de
protection sont placés généralement en bordure de réseau.
• Limitation des Firewalls
o Incapables de vérifier le contenu des paquets
o N’ont pas une vue globale du réseau, analysent le trafic en un point précis du réseau.
Les différents types d’IDS
• HIDS
o Application qui contrôle l’activité du système (Surveillance des ressources, fichiers,
logs…)
o Présence détectable (non furtif), une sonde par machine.
• NIDS
o Sonde réseau qui analyse le trafic réseau (volume et contenu des paquets)
o Furtivité, vision globale du système (surveille plusieurs machines)
• IPS
o Non furtif, réponse à une attaque
Modèle CIDF
• Common Intrusion Detection Framework

• Décrit les différents composants d’un IDS
o E-Box
o A-Box
o D-Box
o C-Box
IDXP
• Standard qui fournit un moyen de communication entre éléments d’un IDS (communication).
Permet une interopérabilité entre IDS, se base sur IDMEF.
IDMEF
• Standard qui permet la normalisation des messages générés par un IDS.
Les NIDS
Ecoute du réseau
• Boitiers TAP
• Port mirroring
• Positionnement des sondes
Méthodes de détection
• Signature
o Pattern matching
o Analyse des protocoles (respect des RFC)
• Comportemental
o Probabiliste (modèles statistiques)
o Statistiques (réseaux bayésiens)
o Systèmes experts et datamining, réseaux de neurones, immunologie, graphes.
Limitations
• Insertion, évasion, saturation

• Ressources, grands réseaux : vers les IDS distribués
Partie 2 – Evaluation des IDS
I - Méthodologie
I.1 – Environnement
• Schéma
I.2 – Outils testés
• Snort
• Bro
• Prelude
• (NFSen)
I.3 – Outils de mise à l’épreuve
• Nessus
• NMAP
• Nikto, Whisker
• (IDSWakeup)
II - Résultats
II.1 – Les Critères
• Ceux énoncés plus haut…
II.2 – Les Résultats
• Sous forme de tableau…
III – Conclusion sur les résultats
Conclusion
Bibliographie
Annexes
Partie 3 – Plan de la présentation Orale
Slide 1 : Sommaire
Slide 2 : Introduction
• Contexte du projet
o Projet technique de 3A
• Définition IDS
o L’art de détecter les activités inappropriées, incorrectes ou anormales sur un
système ou un réseau informatique.
o Etude qui s’oriente vers les NIDS
Slide 3 : Systèmes de détection d’intrusions réseau : Etat de l’art / Pourquoi les IDS ?
• Expansion d’Internet, ouverture des systèmes

• Augmentation du nombre d’incidents
• Le protocole IP qui s’impose comme un standard, développement des technologies du web
• En entreprise :
o Ouverture des systèmes vers les différents partenaires (clients, fournisseurs…)
o Mobilité des usagers (VPN, population d’utilisateurs détachés physiquement de leur
entreprise).
• Grand public :
o Développement des réseaux peer-to-peer, vecteurs de propagation des vers, virus,
chevaux de Troie…
Slide 4 : Systèmes de détection d’intrusions réseau : Etat de l’art / Le début des IDS
• On a tendance à protéger les réseaux des attaques provenant de l’extérieur, les systèmes de
protection sont placés généralement en bordure de réseau.
• Limitation des Firewalls
o Incapables de vérifier le contenu des paquets
o N’ont pas une vue globale du réseau, analysent le trafic en un point précis du réseau.
Slide 5 : Systèmes de détection d’intrusions réseau : Etat de l’art / Les différents types d’IDS
• HIDS
o Application qui contrôle l’activité du système (Surveillance des ressources, fichiers,
logs…)
o Présence détectable (non furtif), une sonde par machine.
• NIDS
o Sonde réseau qui analyse le trafic réseau (volume et contenu des paquets)
o Furtivité, vision globale du système (surveille plusieurs machines)
• IPS
o Non furtif, réponse à une attaque
Slide 6 : Systèmes de détection d’intrusions réseau : Etat de l’art / Standardisation
• Common Intrusion Detection Framework : Décrit les différents composants d’un IDS
• IDXP : Standard qui fournit un moyen de communication entre éléments d’un IDS
(communication). Permet une interopérabilité entre IDS, se base sur IDMEF.
• IDMEF : Standard qui permet la normalisation des messages générés par un IDS.
Slide 7 : Systèmes de détection d’intrusions réseau : Etat de l’art / Les NIDS
Méthodes de détection
• Signature
o Pattern matching
o Analyse des protocoles (respect des RFC)
• Comportementale
o Probabiliste (modèles statistiques)
o Statistiques (réseaux bayésiens)
o Systèmes experts et datamining, réseaux de neurones, immunologie, graphes.
Limitations
• Insertion, évasion, saturation

• Ressources, grands réseaux : vers les IDS distribués
Slide 8 : Evaluation des NIDS / Méthodologie
Environnement de teste
Slide 9 : Evaluation des NIDS / Outils testés
• Snort
• Bro
• Prelude
• (NFSen)
Slide 10 : Evaluation des NIDS / Outils de mise à l’épreuve
• Nessus
• NMAP
• Nikto, Whisker
• (IDSWakeup)
Slide 11 : Evaluation des NIDS / Critères I
Administration :
• Configuration
• Ajout de règles
• Analyse des alertes
Type d’IDS :
• Signatures/Comportemental
Architecture logicielle :
• Boîte noire/Modulaire
Slide 12 : Evaluation des NIDS / Critères II
Respect des standards :
• CIDF
• IDXP
• IDMEF
Performance :
• Nombre d’alertes au différents testes

• Temps
o Lancement du teste
o Date 1ère alerte
o Date dernière alerte
• Limites
o Testes de contournement des I.D.S.
Slide 12 : Evaluation des NIDS / Résultats
Dernier slide : Conclusion

Résultat NMAP
Avec l’option XMas Tree Scan
Starting Nmap 4.53 ( http://insecure.org ) at 2008-02-04 03:12 CET

Initiating ARP Ping Scan at 03:12
Scanning 172.16.60.132 [1 port]
Completed ARP Ping Scan at 03:12, 0.04s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 03:12
Completed Parallel DNS resolution of 1 host. at 03:12, 0.00s elapsed
Initiating XMAS Scan at 03:12
Scanning 172.16.60.132 [1714 ports]
Completed XMAS Scan at 03:12, 1.51s elapsed (1714 total ports)
Initiating Service scan at 03:12
Scanning 5 services on 172.16.60.132
Discovered open port 8080/tcp on 172.16.60.132
Discovered open|filtered port 8080/tcp on 172.16.60.132 is actually open
Completed Service scan at 03:12, 8.20s elapsed (5 services on 1 host)
Initiating OS detection (try #1) against 172.16.60.132
Initiating RPCGrind Scan against 172.16.60.132 at 03:12
Completed RPCGrind Scan against 172.16.60.132 at 03:12, 0.00s elapsed (1 port)
SCRIPT ENGINE: Initiating script scanning.
Host 172.16.60.132 appears to be up ... good.
Interesting ports on 172.16.60.132:
Not shown: 1709 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.3p2 Debian 9 (protocol 2.0)
80/tcp open http Apache httpd 2.2.3 ((Debian) mod_python/3.2.10 Python/2.4.4
PHP/5.2.0-8+etch10 mod_perl/2.0.2 Perl/v5.8.8)
111/tcp open rpcbind 2 (rpc #100000)
113/tcp open ident
8080/tcp open http Apache httpd 2.2.3 ((Debian) mod_python/3.2.10 Python/2.4.4
PHP/5.2.0-8+etch10 mod_perl/2.0.2 Perl/v5.8.8)
MAC Address: 00:0C:29:B9:42:35 (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.18 (Debian 4.0, x86)
Uptime: 0.202 days (since Sun Feb 3 22:21:44 2008)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=202 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux
Read data files from: /usr/share/nmap

OS and Service detection performed. Please report any incorrect results at
http://insecure.org/nmap/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.506 seconds
Raw packets sent: 1739 (70.400KB) | Rcvd: 1725 (69.712KB)
Aide Nikto
---------------------------------------------------------------------------
- Nikto 1.35/1.35 - www.cirt.net
Options:
-Cgidirs+ Scan these CGI dirs: 'none', 'all', or a value like
'/cgi/'
-cookies print cookies found
-evasion+ ids evasion technique (1-9, see below)
-findonly find http(s) ports only, don't perform a full scan
-Format save file (-o) Format: htm, csv or txt (assumed)
-generic force full (generic) scan
-host+ target host
-id+ host authentication to use, format is
userid:password
-mutate+ mutate checks (see below)
-nolookup skip name lookup
-output+ write output to this file
-port+ port to use (default 80)
-root+ prepend root value to all requests, format is
/directory
-ssl force ssl mode on port
-timeout timeout (default 10 seconds)
-useproxy use the proxy defined in config.txt
-Version print plugin and database versions
-vhost+ virtual host (for Host header)
+ requires a value
These options cannot be abbreviated:

-config+ use this config file
-debug debug mode
-dbcheck syntax check scan_database.db and
user_scan_database.db
-update update databases and plugins from cirt.net
-verbose verbose mode
IDS Evasion Techniques:

1 Random URI encoding (non-UTF8)
2 Directory self-reference (/./)
3 Premature URL ending
4 Prepend long random string
5 Fake parameter
6 TAB as request spacer
7 Random case sensitivity
8 Use Windows directory separator (\)
9 Session splicing
Mutation Techniques:
1 Test all files with all root directories
2 Guess for password file names
3 Enumerate user names via Apache (/~user type requests)
4 Enumerate user names via cgiwrap (/cgi-bin/cgiwrap/~user type
requests)
Résultat Nikto
Test avec technique d’évasion d’IDS
---------------------------------------------------------------------------
- Nikto 1.35/1.35 - www.cirt.net
+ Target IP: 172.16.60.132
+ Target Hostname: 172.16.60.132
+ Target Port: 80
+ Using IDS Evasion: Random URI encoding (non-UTF8)
+ Start Time: Mon Feb 4 03:31:34 2008
---------------------------------------------------------------------------
- Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch10
mod_perl/2.0.2 Perl/v5.8.8
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ mod_perl/2.0.2 appears to be outdated (current is at least 5.8)
+ / - Redirects to http://172.16.60.132/apache2-default/ , Default EMC Cellera manager server
is running.
+ / - Redirects to http://172.16.60.132/apache2-default/ , Appears to be a default Apache
Tomcat install.
Tomcat install.
install.
install.
+ / - Redirects to http://172.16.60.132/apache2-default/ , Default Jrun 2 server running.
+ / - Redirects to http://172.16.60.132/apache2-default/ , Default Sybase Jaguar CTS server
running.
+ / - Redirects to http://172.16.60.132/apache2-default/ , Default Jrun 3 server running.
+ / - Redirects to http://172.16.60.132/apache2-default/ , Default Lantronix printer found.
+ /?M=A - Redirects to http://172.16.60.132/apache2-default/?%4d=A , Apache allows directory
listings by requesting. Upgrade Apache or disable directory indexing.
+ /?S=A - Redirects to http://172.16.60.132/apache2-default/?S=A , Apache allows directory
listings by requesting. Upgrade Apache or disable directory indexing.
+ /?sql_debug=1 - Redirects to http://172.16.60.132/apache2-default/?%73%71l_de%62u%67%3d1 ,
The PHP-Nuke install may allow attackers to enable debug mode and disclose sensitive
information by adding sql_debug=1 to the query string.
+ / - Redirects to http://172.16.60.132/apache2-default/ , PeopleSoft appears to be running.
+ / - Redirects to http://172.16.60.132/apache2-default/ , Samba-swat web server. Used to
administer Samba.
+ / - TRACE option appears to allow XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE)
+
/m%79p%68%70nuke%2f%6c%69%6e%6b%73%2ep%68%70%3f%6fp%3dMo%73%74%50%6fp%75%6car%26%72at%65%6eum=
[%73crip%74%5d%61%6c%65rt%28d%6fc%75%6d%65%6e%74.c%6foki%65%29;[/%73%63%72i%70t]%26%72%61%74%6
5t%79p%65%3dperce%6e%74 - myphpnuke is vulnerable to Cross Site Scripting (XSS). CA-2000-02.
(GET)
+
%2f%70hpi%6dagevie%77%2e%70%68%70%3f%70%69%63=j%61v%61%73%63ri%70t:a%6c%65%72%74('%56ul%6ee%72
%61bl%65%27%29 - PHP Image View 1.0 is vulnerable to Cross Site Scripting (XSS). CA-2000-02.
(GET)
+ 2037 items checked - 3 item(s) found on remote host(s)
+ End Time: Mon Feb 4 03:31:41 2008 (7 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Nessus Scan Report
Summary
This report gives details on hosts that were tested and issues that were found.Please follow the recommended steps and
procedures to eradicate these threats.
Scan started at: Mon Feb 4 03:36:02 2008

Scan finished at: Mon Feb 4 04:20:45 2008
Host Possible Issues Holes Warnings Notes

172.16.60.132 Security hole(s) found 2 5 16
Total: 1 2 5 16
Reports per Host

172.16.60.132
Scan of this host started at: Mon Feb 4 03:36:07 2008

Scan of this host finished at: Mon Feb 4 04:20:45 2008
Service (Port) Issue regarding port

ssh (22/tcp) Security notes found
ident (113/tcp) Security warning(s) found
sysorb (3241/tcp) Security notes found
sunrpc (111/tcp) Security notes found
http (80/tcp) Security warning(s) found
http-alt (8080/tcp) Security warning(s) found
sunrpc (111/udp) Security notes found
exosee (1027/udp) Security hole found
general/icmp Security warning(s) found
general/udp Security notes found
general/tcp Security hole found
[ return to summary ]
Security Issues and Fixes - Host 172.16.60.132
172.16.60.132 - ssh (22/tcp)
Informational:
An ssh server is running on this port
Nessus ID : 10330
Informational:
Remote SSH version : SSH-2.0-OpenSSH_4.3p2 Debian-9
Nessus ID : 10267
Informational:
1/8
Nessus Scan Report
The remote SSH daemon supports the following versions of the

SSH protocol :
. 1.99
. 2.0
SSHv2 host key fingerprint : 13:e4:79:ef:60:13:f5:1b:95:cd:84:ea:ea:14:4f:12
Nessus ID : 10881
[ return to 172.16.60.132 ]
172.16.60.132 - ident (113/tcp)
Warning:
The remote host is running an ident (also known as 'auth') daemon.
The 'ident' service provides sensitive information to potential

attackers. It mainly says which accounts are running which services.
This helps attackers to focus on valuable services (those
owned by root). If you do not use this service, disable it.
Solution : Under Unix systems, comment out the 'auth' or 'ident'

line in /etc/inetd.conf and restart inetd
Risk factor : Low

CVE : CAN-1999-0629
Nessus ID : 10021
Informational:
An identd server is running on this port
Nessus ID : 10330
[ return to 172.16.60.132 ]
172.16.60.132 - sysorb (3241/tcp)
Informational:
RPC program #100024 version 1 'status' is running on this port
Nessus ID : 11111
[ return to 172.16.60.132 ]
172.16.60.132 - sunrpc (111/tcp)
Informational:
The RPC portmapper is running on this port.
An attacker may use it to enumerate your list

of RPC services. We recommend you filter traffic
2/8
Nessus Scan Report
going to this port.
Risk factor : Low

CVE : CAN-1999-0632, CVE-1999-0189
BID : 205
Nessus ID : 10223
Informational:
RPC program #100000 version 2 'portmapper' (portmap sunrpc rpcbind) is running on this port
Nessus ID : 11111
[ return to 172.16.60.132 ]
172.16.60.132 - http (80/tcp)
Warning:
Your webserver supports the TRACE and/or TRACK methods. TRACE and TRACK
are HTTP methods which are used to debug web server connections.
It has been shown that servers supporting this method are subject
to cross-site-scripting attacks, dubbed XST for
"Cross-Site-Tracing", when used in conjunction with
various weaknesses in browsers.
An attacker may use this flaw to trick your

legitimate web users to give him their
credentials.
Solution: Disable these methods.
If you are using Apache, add the following lines for each virtual
host in your configuration file :
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
If you are using Microsoft IIS, use the URLScan tool to deny HTTP TRACE
requests or to permit only the methods needed to meet site requirements
and policy.
If you are using Sun ONE Web Server releases 6.0 SP2 and later, add the
following to the default object section in obj.conf:
<Client method="TRACE">
AuthTrans fn="set-variable"
remove-headers="transfer-encoding"
set-headers="content-length: -1"
error="501"
</Client>
If you are using Sun ONE Web Server releases 6.0 SP2 or below, compile
the NSAPI plugin located at:
3/8
Nessus Scan Report
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F50603
See http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf
http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html
http://www.kb.cert.org/vuls/id/867593
Risk factor : Medium

Nessus ID : 11213
Informational:
A web server is running on this port
Nessus ID : 10330
Informational:
The remote web server type is :
Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch10 mod_perl/2.0.2 Perl/v5.8.8
Solution : You can set the directive 'ServerTokens Prod' to limit

the information emanating from the server in its response headers.
Nessus ID : 10107
[ return to 172.16.60.132 ]
172.16.60.132 - http-alt (8080/tcp)
Warning:
Your webserver supports the TRACE and/or TRACK methods. TRACE and TRACK
are HTTP methods which are used to debug web server connections.
It has been shown that servers supporting this method are subject
to cross-site-scripting attacks, dubbed XST for
"Cross-Site-Tracing", when used in conjunction with
various weaknesses in browsers.
An attacker may use this flaw to trick your

legitimate web users to give him their
credentials.
Solution: Disable these methods.
If you are using Apache, add the following lines for each virtual
host in your configuration file :
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
If you are using Microsoft IIS, use the URLScan tool to deny HTTP TRACE
requests or to permit only the methods needed to meet site requirements
4/8
Nessus Scan Report
and policy.
If you are using Sun ONE Web Server releases 6.0 SP2 and later, add the
following to the default object section in obj.conf:
<Client method="TRACE">
AuthTrans fn="set-variable"
remove-headers="transfer-encoding"
set-headers="content-length: -1"
error="501"
</Client>
If you are using Sun ONE Web Server releases 6.0 SP2 or below, compile
the NSAPI plugin located at:
See http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf
http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html
http://www.kb.cert.org/vuls/id/867593
Risk factor : Medium

Nessus ID : 11213
Informational:
A web server is running on this port
Nessus ID : 10330
Informational:
This web server is [mis]configured in that it

does not return '404 Not Found' error codes when
a non-existent file is requested, perhaps returning
a site map, search page or authentication page instead.
Nessus enabled some counter measures for that, however

they might be insufficient. If a great number of security
holes are produced for this port, they might not all be accurate
Nessus ID : 10386
Informational:
The remote web server type is :
Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch10 mod_perl/2.0.2 Perl/v5.8.8
Solution : You can set the directive 'ServerTokens Prod' to limit

the information emanating from the server in its response headers.
Nessus ID : 10107
[ return to 172.16.60.132 ]
172.16.60.132 - sunrpc (111/udp)
Informational:
5/8
Nessus Scan Report
RPC program #100000 version 2 'portmapper' (portmap sunrpc rpcbind) is running on this port
Nessus ID : 11111
[ return to 172.16.60.132 ]
172.16.60.132 - exosee (1027/udp)
Vulnerability:
The remote statd service may be vulnerable to a format string attack.
This means that an attacker may execute arbitrary code thanks to a bug in
this daemon.
Only older versions of statd under Linux are affected by this problem.
*** Nessus reports this vulnerability using only information that was gathered.
*** Use caution when testing without safe checks enabled.
Solution : upgrade to the latest version of rpc.statd

Risk factor : High
CVE : CVE-2000-0666, CAN-2000-0800
BID : 1480
Nessus ID : 10544
Warning:
The statd RPC service is running. This service has a long history of
security holes, so you should really know what you are doing if you decide
to let it run.
*** No security hole regarding this program have been tested, so

*** this might be a false positive.
Solution : We suggest that you disable this service.

Risk factor : High
CVE : CVE-1999-0018, CVE-1999-0019, CVE-1999-0493
BID : 127, 450, 6831
Nessus ID : 10235
Informational:
RPC program #100024 version 1 'status' is running on this port
Nessus ID : 11111
[ return to 172.16.60.132 ]
172.16.60.132 - general/icmp
Warning:
The remote host answers to an ICMP timestamp request. This allows an attacker
to know the date which is set on your machine.
6/8
Nessus Scan Report
This may help him to defeat all your time based authentication protocols.
Solution : filter out the ICMP timestamp requests (13), and the outgoing ICMP
timestamp replies (14).
Risk factor : Low

CVE : CAN-1999-0524
Nessus ID : 10114
[ return to 172.16.60.132 ]
172.16.60.132 - general/udp
Informational:
For your information, here is the traceroute to 172.16.60.132 :
172.16.60.1
172.16.60.132
Nessus ID : 10287
[ return to 172.16.60.132 ]
172.16.60.132 - general/tcp
Vulnerability:
You are running a version of Nessus which is not configured to receive

a full plugin feed. As a result, the security audit of the remote host produced
incomplete results.
To obtain a complete plugin feed, you need to register your Nessus scanner
at http://www.nessus.org/register/ then run nessus-update-plugins to get
the full list of Nessus plugins.
Nessus ID : 9999
Informational:
Information about this scan :
Nessus version : 2.2.10

Plugin feed version : 200704181215
Type of plugin feed : GPL only
Scanner IP : 172.16.60.1
Port scanner(s) : nessus_tcp_scanner
Port range : default
Thorough tests : no
Experimental tests : no
Paranoia level : 1
Report Verbosity : 1
Safe checks : yes
Max hosts : 20
Max checks : 4
Scan duration : unknown (ping_host.nasl not launched?)
7/8
Nessus Scan Report
Nessus ID : 19506
[ return to 172.16.60.132 ]
This file was generated by Nessus, the free security scanner.
8/8

415 - Rapport Bsobesto Ids

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

415 - Rapport Bsobesto Ids

Uploaded by

Copyright:

Available Formats

Les Systè

port de projet de 3ème année

PARTIE 1 - ETAT DE L’ART ................................................................................................................................. 4

PARTIE 2 - EVALUATION ................................................................................................................................. 14

Les Systèmes de Détection d’Intrusions Réseau

Les Systèmes de Détection d’Intrusions Réseau

Les systèmes d’information sont omniprésents dans notre société. Les

Dans un premier temps nous verrons pourquoi un système de détection

Les Systèmes de Détection d’Intrusions Réseau

Cette expansion d’Internet a été possible grâce à l’émergence d’un protocole de

La dimension universelle d’Internet et des technologies du Web permettent le partage et

Les Systèmes de Détection d’Intrusions Réseau

C. Profile des attaquants

De manière générale, les employés disposent d’un accès au système d’information de la

Certaines organisations étatiques ou terroristes possèdent d’énormes moyens matériels et

Les Systèmes de Détection d’Intrusions Réseau

Depuis 2000, le nombre d’attaques et de vulnérabilités ne cessent de croître, il faut

II. Méthodologie d’une intrusion

Les Systèmes de Détection d’Intrusions Réseau

D. Les différents types d’attaques

1. Les Dénis de Services : les attaques réseau

Ping de la mort : Paquet ICMP echo request de grosse taille.

2. Exploitation de vulnérabilités sur les services

Exploitation contre des services web :

Attaques de niveau 2 : Empoisonnement du cache ARP d’une machine.

Les Systèmes de Détection d’Intrusions Réseau

III. Les différents types d’IDS

A. Host-based Intrusions Detection Systems

B. Network Intrusions Detection Systems

C. Intrusions Prevention Systems

• Les NIPS : Network-based Intrusions Prevention Systems ou Inline Prevention

Les Systèmes de Détection d’Intrusions Réseau

Ce modèle définit l’architecture d’un IDS. On distingue 4 entités appelées « Box » :

Figure 1 - Modèle CIDF

Les Systèmes de Détection d’Intrusions Réseau

L’Intrusion Detection Exchange Protocol est un protocole de communication normalisé

<?xml version="1.0" encoding="UTF-8"?>

Les Systèmes de Détection d’Intrusions Réseau

Il y a deux grandes catégories dans les méthodes de détection :

1. Détection par abus

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-MISC /etc/passwd";flags: A+;

Ce type d’IDS nécessite une période d’apprentissage pour définir le comportement

La détection d’anomalies fait appel à différentes notions de statistique, de probabilité et

Méthodes statistiques : On construit le comportement normal en quantifiant certains paramètres liés

Les Systèmes de Détection d’Intrusions Réseau

Méthodes probabilistes : Cette approche définit la probabilité de chaque évènement susceptible de se

Réseaux de neurones : C’est un modèle de calcul inspiré du fonctionnement de vrais neurones. Le

1. Le placement des IDS

Il faut savoir dimension les capacités de l’IDS en fonction de la taille du réseau et la

Les Systèmes de Détection d’Intrusions Réseau

Figure 2 – Insertion (source insecure.org)

Elimination : Consiste à rendre l’IDS inutile en l’inondant d’information par exemple.

Les Systèmes de Détection d’Intrusions Réseau

Figure 3 - Plateforme d'évaluation d'origine

La plateforme de test d’origine était composée :

Les Systèmes de Détection d’Intrusions Réseau

Figure 4 - Plateforme d'évaluation

B. Les outils testés

Snort est un système de détection et de prévention d’intrusions réseau open source. Il se

Snort possède une architecture modulaire, il est composé :

Les Systèmes de Détection d’Intrusions Réseau

Les plugins de sortie permettent de configurer la destination des résultats :

Snort fonctionne essentiellement en ligne de commande. Il existe de nombreux outils

Ce pro jet s'intitule : Etat de l'art des systèmes de détection d'intrusions

La problématique de ce projet est de déterminer les diérents types de

Dans cette étude, on s'orientera plus spéciquement vers :

An d'évaluer et de comparer des solutions logicielles, il est nécessaire