415_rapport-bsobesto-ids

Les Systèd’Intr

Rappo

Filière SOption

ystèmes de DétecIntrusions Réseau

port de projet de 3ème année

Pilote Toinard Christian

Auteur Sobesto Bertrand 3ème Année

re Sciences et Technologies de l’Information tion Sécurité des Systèmes d’Information

Année 2007 – 2008

tection eau

Les Systèmes de Détection d’Intrusions Réseau Rapport de projet de 3ème année Page 1 sur 30

SSSSommaireommaireommaireommaire

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


Table des figures Table des figures Table des figures 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


IntroductionIntroductionIntroductionIntroduction

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.


PPPPartie 1artie 1artie 1artie 1 Etat de l’art Etat de l’art Etat de l’art 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="ip v4-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="ip v4-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 (ms g:"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).


PPPPartie 2artie 2artie 2artie 2 Evaluation Evaluation Evaluation 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.

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.

Sonde Prelude-lml

Manager Prelude-lml

Sonde Prelude-lml

Sonde Prelude-lml

Front-end Prewikka

Base de données MySQL

Counter Measure Agnets


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:Po rt Dst IP Addr:Port Flags Tos Packets Bytes Fl ows 2005-08-30 06:53:53.370 63.545 TCP 113.138.32.152:2 5 -> 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:35 75 -> 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

configuration, il existe des outils graphiques

Il faut éditer le fichier de configuration, il existe des outils graphiques

Edition des fichiers de configuration à la main

Utilisation de l’interface web

Maintenance des signatures Il faut mettre à jour les signatures, il existe des outils pour le faire automatiquement. La syntaxe des signatures est facile à utiliser

Il faut récupérer la dernière version de l’IDS ou ajouter des signatures manuellement. Un langage de script permet d’ajouter des politiques de sécurité

-

Analyse des alertes Utilisation de l’interface web (AcidBase)

Utilisation de l’interface web (Prewikka)

Il faut utiliser un SIM pour analyser les alertes

Utilisation de l’interface 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

et par anomalies (seuils) Méthode de détection par abus (signatures)

Méthode de détection par abus orientée évènement

Méthode de détection par anomalie (seuils)

Standards IDMEF Non Oui, dialogue entre les

sondes et le manager Non -

Modèle CIDF E-Box : Préprocesseur D-Box : Plug-ins output

E-Box et A-Box : Sonde D-Box : Manager C-Box : Manager

E-Box : Event engine A-Box D-Box: Policy script interpreter C-Box : Plug-ins

A-Box : Plug-ins C-Box : Plug-ins E-Box : Netflow

Interopérabilité Non Oui Non Non


Snort Prélude-IDS Bro-IDS NFSen Architecture Modularité Oui, notion de

préprocesseur Oui, on peut rajouter des plug-ins pour l’analyse

Non Oui, notion de plug-ins

Architecture logicielle Un seul processus Tout dépend du plugin d’output, on peut stocker les informations sur une autre machine

En trois partie : Les sondes, le manager et l’application Web donc distribuable.

Un seul processus Un processus qui recueille les flux, un processus (nfsend) qui réalise les calculs et une interface web.

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.


ConclusionConclusionConclusionConclusion

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 Bibliographie Bibliographie 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_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


AnnexesAnnexesAnnexesAnnexes

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

[email protected]

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Objectifs 3

2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Buts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Echéances 4

3.1 Les étapes de réalisation . . . . . . . . . . . . . . . . . . . . . 43.1.1 Recherche de documentation . . . . . . . . . . . . . . . 43.1.2 Détermination de critères . . . . . . . . . . . . . . . . 43.1.3 Recherche de solutions logicielles . . . . . . . . . . . . 43.1.4 Plateforme de test . . . . . . . . . . . . . . . . . . . . 53.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 NationaleSupérieure d'Ingénieurs de Bourges. C'est également un travail préparatoireau 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 projet 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 dedétecteurs d'intrusions réseau (ou NIDS1) existants ainsi que leur e�cacité(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 lessystè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�érentesméthodes d'analyse des paquets et de tester l'e�cacité des solutions logiciellesdisponibles actuellement.

1NIDS : 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 uneidée précise de l'état de la recherche dans ce domaine. Ceci va permettre dedéterminer les di�érentes méthodes de détection et les di�érentes analysese�ectuées par les NIDS.

Dans cette étude, on s'orientera plus spéci�quement 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

A�n d'évaluer et de comparer des solutions logicielles, il est nécessairede dé�nir des critères basés sur des caractéristiques et les performances dedétection.

3.1.3 Recherche de solutions logicielles

Cette étape va consister à rechercher quelques solutions logicielles de NIDSqui 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 estnécessaire de mettre en place une architecture de test composée de plusieursmachines virtuelles fonctionnant sous di�érents systèmes d'exploitation telsque Linux ou Windows. Cette architecture sera composée d'une machineattaquante, 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'évaluationet les caractéristiques de la solution déployée, di�érents types d'attaques se-ront e�ectuées. Cette étape permettra d'évaluer et de comparer les di�érentsNIDS 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

[email protected]

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

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)

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 t otal 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 Discovered open port 113/tcp on 172.16.60.132 Discovered open|filtered port 113/tcp on 172.16.60. 132 is actually open Discovered open port 111/tcp on 172.16.60.132 Discovered open|filtered port 111/tcp on 172.16.60. 132 is actually open Discovered open port 80/tcp on 172.16.60.132 Discovered open|filtered port 80/tcp on 172.16.60.1 32 is actually open Discovered open port 22/tcp on 172.16.60.132 Discovered open|filtered port 22/tcp on 172.16.60.1 32 is actually open Completed Service scan at 03:12, 8.20s elapsed (5 s ervices on 1 host) Initiating OS detection (try #1) against 172.16.60. 132 Initiating RPCGrind Scan against 172.16.60.132 at 0 3: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 (prot ocol 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 a ny incorrect results at http://insecure.org/nmap/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.5 06 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: 'n one', 'all', or a value like '/cgi/' -cookies print cookies found -evasion+ ids evasion technique (1-9 , see below) -findonly find http(s) ports only, do n't perform a full scan -Format save file (-o) Format: htm, c sv 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 req uests, 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 v ersions -vhost+ virtual host (for Host heade r) + requires a value These options cannot be abbreviated: -config+ use this config file -debug debug mode -dbcheck syntax check scan_datab ase.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 req uests) 4 Enumerate user names via cgiwrap (/cgi-bin/cgiwr ap/~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 P ython/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 c heck 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-def ault/ , Default EMC Cellera manager server is running. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Appears to be a default Apache Tomcat install. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Appears to be a default Apache Tomcat install. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Appears to be a default Apache install. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Appears to be a default Apache install. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Default Jrun 2 server running. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Default Sybase Jaguar CTS server running. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Default Jrun 3 server running. + / - Redirects to http://172.16.60.132/apache2-def ault/ , 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 d irectory indexing. + /?S=A - Redirects to http://172.16.60.132/apache2 -default/?S=A , Apache allows directory listings by requesting. Upgrade Apache or disable d irectory 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 stri ng. + / - Redirects to http://172.16.60.132/apache2-def ault/ , PeopleSoft appears to be running. + / - Redirects to http://172.16.60.132/apache2-def ault/ , Samba-swat web server. Used to administer Samba. + / - TRACE option appears to allow XSS or credenti al theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePap er_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%65t%79p%65%3dperce%6e%74 - myphpnuke is vulnerable t o 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 t o Cross Site Scripting (XSS). CA-2000-02. (GET) + 2037 items checked - 3 item(s) found on remote ho st(s) + End Time: Mon Feb 4 03:31:41 2008 (7 seco nds) --------------------------------------------------- ------------------------ + 1 host(s) tested

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:

Nessus Scan Report

1/8

http://cgi.nessus.org/nessus_id.php3?id=10330


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

Nessus Scan Report

2/8


http://cgi.nessus.org/cve.php3?cve=CAN-1999-0629




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:

Nessus Scan Report

3/8


http://cgi.nessus.org/cve.php3?cve=CVE-1999-0189

http://cgi.nessus.org/bid.php3?bid=205



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

Nessus Scan Report

4/8


http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf







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




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:

Nessus Scan Report

5/8


http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf








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.

Nessus Scan Report

6/8














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

Nessus Scan Report

7/8




http://www.nessus.org/register/


Nessus ID : 19506

[ return to 172.16.60.132 ]

This file was generated by Nessus, the free security scanner.

Nessus Scan Report

8/8


http://www.nessus.org

415_rapport-bsobesto-ids

Documents

Transcript of 415_rapport-bsobesto-ids