Les systèmes de détection d'intrusions

Les scans de ports ne sont pas des attaques à proprement parler. Le but des scans est de déterminer quels sont les ports ouverts, et donc en déduire les services qui sont exécutés sur la machine cible (ex. : port 80/TCP pour un service HTTP). Par conséquent, la plupart des attaques sont précédées par un scan de ports lors de la phase Probe qui est comme nous l'avons vu, la première phase des 5P's dans le déroulement d'une attaque.

Il existe un nombre important de techniques de scan. Idéalement, la meilleure technique de scan est celle qui est la plus furtive afin de ne pas alerter les soupçons de la future victime. Voici une description des techniques de scan les plus répandues :

• le scan simple : aussi appelé le scan connect(), il consiste à établir une connexion TCP complète sur une suite de ports. S'il arrive à se connecter, le port est ouvert ; sinon, il est fermé. Cette méthode de scan est très facilement détectable ;
• le scan furtif : aussi appelé scan SYN, il s'agit d'une amélioration du scan simple. Ce scan essaie également de se connecter sur des ports donnés, mais il n'établit pas complètement la connexion : pas de commande ACK (acquittement) après avoir reçu l'accord de se connecter. Grâce à ceci, la méthode est bien plus furtive que le scan normal ;
• les scans XMAS, NULL et FIN : se basent sur des détails de la RFC du protocole TCP pour déterminer si un port est fermé ou non en fonction de la réaction à certaines requêtes. Ces scans sont moins fiables que le scan SYN, mais ils sont un peu plus furtifs. La différence entre ces trois types de scan se situe au niveau des flags TCP utilisés lors de la requête ;
• le scan à l'aveugle : s'effectue via une machine intermédiaire et avec du spoofing (voir plus bas). Le système attaqué pense que le scan est réalisé par la machine intermédiaire et non par le pirate ;
• le scans passif : est la méthode la plus furtive. Consiste à analyser les champs d'en-tête des paquets (TTL, ToS, MSS…) et à les comparer avec une base de signatures qui pourra déterminer les applications qui ont envoyé ces paquets.

Remarque : l'utilitaire incontournable pour réaliser des scans de ports se nomme Nmap.

But : usurper l'adresse IP d'une autre machine.

Finalité : se faire passer pour une autre machine en truquant les paquets IP. Cette technique peut être utile dans le cas d'authentifications basées sur une adresse IP (services tels que rlogin ou ssh par exemple).

Déroulement : il existe des utilitaires qui permettent de modifier les paquets IP ou de créer ses propres paquets (ex. : hping2). Grâce à ces utilitaires, il est possible de spécifier une adresse IP différente de celle que l'on possède, et ainsi se faire passer pour une autre « machine ».

Cependant, ceci pose un problème : en spécifiant une adresse IP différente de notre machine, nous ne recevrons pas les réponses de la machine distante, puisque celle-ci répondra à l'adresse spoofée. Il existe toutefois deux méthodes permettant de récupérer les réponses :

• Source routing : technique consistant à placer le chemin de routage directement dans le paquet IP. Cette technique ne fonctionne plus de nos jours, les routeurs rejetant cette option.
• Reroutage : cette technique consiste à envoyer des paquets RIP aux routeurs afin de modifier les tables de routage. Les paquets avec l'adresse spoofée seront ainsi envoyés aux routeurs contrôlés par le pirate et les réponses pourront être également reçues par celui-ci.

But : rediriger le trafic d'une machine vers une autre.

Finalité : grâce à cette redirection, une personne mal intentionnée peut se faire passer pour une autre. De plus, le pirate peut rerouter les paquets qu'il reçoit vers le véritable destinataire, ainsi l'utilisateur usurpé ne se rendra compte de rien. La finalité est la même que l'IP spoofing, mais on travaille ici au niveau de la couche liaison de données.

Déroulement : pour effectuer cette usurpation, il faut corrompre le cache ARP de la victime. Ce qui signifie qu'il faut lui envoyer des trames ARP en lui indiquant que l'adresse IP d'une autre machine est la sienne. Les caches ARP étant régulièrement vidés, il faudra veiller à maintenir l'usurpation.

But : fournir de fausses réponses aux requêtes DNS, c'est-à-dire indiquer une fausse adresse IP pour un nom de domaine.

Finalité : rediriger, à leur insu, des internautes vers des sites pirates. Grâce à cette fausse redirection, l'utilisateur peut envoyer ses identifiants en toute confiance par exemple.

Déroulement : il existe deux techniques pour effectuer cette attaque :

• DNS Cache Poisoning : les serveurs DNS possèdent un cache permettant de garder pendant un certain temps la correspondance entre un nom de machine et son adresse IP. Le DNS Cache Poisoning consiste à corrompre ce cache avec de fausses informations. Ces fausses informations sont envoyées lors d'une réponse d'un serveur DNS contrôlé par le pirate à un autre serveur DNS, lors de la demande de l'adresse IP d'un domaine (ex. : www.ledomaine.com). Le cache du serveur ayant demandé les informations est alors corrompu ;
• DNS ID Spoofing : pour communiquer avec une machine, il faut son adresse IP. On peut toutefois avoir son nom, et grâce au protocole DNS, nous pouvons obtenir son adresse IP. Lors d'une requête pour obtenir l'adresse IP à partir d'un nom, un numéro d'identification est placé dans la trame afin que le client et le serveur puissent identifier la requête. L'attaque consiste ici à récupérer ce numéro d'identification (en sniffant le réseau) lors de la communication entre un client et un serveur DNS, puis envoyer des réponses falsifiées au client avant que le serveur DNS lui réponde.

Remarque : une attaque que nous allons voir ci-après, le Déni de Service, peut aider à ralentir le trafic du serveur DNS et ainsi permettre de répondre avant lui.

But : le but de cette attaque est de passer outre les protections des équipements de filtrage IP.

Finalité : en passant outre les protections, un pirate peut par exemple s'infiltrer dans un réseau pour effectuer des attaques ou récupérer des informations confidentielles.

Déroulement : deux types d'attaque sur les fragments IP peuvent être distingués :

• Fragments overlapping : quand un message est émis sur un réseau, il est fragmenté en plusieurs paquets IP. Afin de pouvoir reconstruire le message, chaque paquet possède un offset. Le but de l'attaque est de réaliser une demande de connexion et de faire chevaucher des paquets en spécifiant des offsets incorrects. La plupart des filtres analysant les paquets indépendamment, ils ne détectent pas l'attaque. Cependant, lors de la défragmentation, la demande de connexion est bien valide et l'attaque a lieu ;
• Tiny fragments : le but de l'attaque est de fragmenter une demande de connexion sur deux paquets IP : le premier paquet de taille minimum (68 octets selon la RFC du protocole IP) ne contient que l'adresse et le port de destination. Le deuxième paquet contient la demande effective de connexion TCP. Le premier paquet est accepté par les filtres puisqu'il ne contient rien de suspect. Quand le deuxième paquet arrive, certains filtres ne le vérifient pas, pensant que si le premier paquet est inoffensif, le deuxième l'est aussi. Mais lors de la défragmentation sur le système d'exploitation, la connexion s'établit !

De nos jours, une grande majorité des firewalls(2) sont capables de détecter et stopper ce type d'attaques.

But : le but de cette attaque est de rediriger un flux TCP afin de pouvoir outrepasser une protection par mot de passe.

Finalité : le contrôle d'authentification s'effectuant uniquement à l'ouverture de la session, un pirate réussissant cette attaque parvient à prendre possession de la connexion pendant toute la durée de la session.

Déroulement : dans un premier temps, le pirate doit écouter le réseau, puis lorsqu'il estime que l'authentification a pu se produire (délai de n secondes par exemple), il désynchronise la session entre l'utilisateur et le serveur. Pour ce faire, il construit un paquet avec, comme adresse IP source, celle de la machine de l'utilisateur et le numéro d'acquittement TCP attendu par le serveur. En plus de désynchroniser la connexion TCP, ce paquet permet au pirate d'injecter une commande via la session préalablement établie.

Il est très rare que les administrateurs réseau configurent correctement un programme. En général, ils se contentent d'utiliser les configurations par défaut. Celles-ci sont souvent non sécurisées afin de faciliter l'exploitation du logiciel (ex. : login/mdp par défaut d'un serveur de base de données).

De plus, des erreurs peuvent apparaître lors de la configuration d'un logiciel. Une mauvaise configuration d'un serveur peut entraîner l'accès à des fichiers importants, ou mettant en jeu l'intégrité du système d'exploitation. C'est pourquoi il est important de bien lire les documentations fournies par les développeurs afin de ne pas créer de failles.

Liés à un problème dans le code source, ils peuvent amener à l'exploitation de failles. Il n'est pas rare de voir l'exploitation d'une machine bloquée suite à une simple erreur de programmation. On ne peut toutefois rien faire contre ce type de problèmes, si ce n'est attendre un correctif de la part du développeur.

Les buffer overflows, ou dépassement de la pile, sont une catégorie de bogue particulière.

Issus d'une erreur de programmation, ils permettent l'exploitation d'un shellcode(3) à distance.

Ce shellcode permettra à une personne mal intentionnée d'exécuter des commandes sur le système distant, pouvant aller jusqu'à sa destruction.

L'erreur de programmation est souvent la même : la taille d'une entrée n'est pas vérifiée et l'entrée est directement copiée dans un buffer dont la taille est inférieure à la taille de l'entrée. On se retrouve donc en situation de débordement, et l'exploitant peut ainsi accéder à la mémoire.

Principalement web (ex. : Perl, PHP, ASP), ils s'exécutent sur un serveur et renvoient un résultat au client. Cependant, lorsqu'ils sont dynamiques (i.e. qu'ils utilisent des entrées saisies par un utilisateur), des failles peuvent apparaître si les entrées ne sont pas correctement contrôlées.

L'exemple classique est l'exploitation de fichier à distance, telle que l'affichage du fichier mot de passe du système en remontant l'arborescence depuis le répertoire web.

Tout comme les attaques de scripts, les injections SQL profitent de paramètres d'entrée non vérifiés. Comme leur nom l'indique, le but des injections SQL est d'injecter du code SQL dans une requête de base de données. Ainsi, il est possible de récupérer des informations se trouvant dans la base (exemple : des mots de passe) ou encore de détruire des données.

Moins connue, mais tout aussi efficace, cette attaque permet de détourner le trafic entre deux stations. Imaginons un client C communiquant avec un serveur S. Un pirate peut détourner le trafic du client en faisant passer les requêtes de C vers S par sa machine P, puis transmettre les requêtes de P vers S. Et inversement pour les réponses de S vers C.

Totalement transparente pour le client, la machine P joue le rôle de proxy. Elle accédera ainsi à toutes les communications et pourra en obtenir les informations sans que l'utilisateur s'en rende compte.

Définition : ensemble de composants logiciels et matériels dont la fonction principale est de détecter et analyser toute tentative d'effraction (volontaire ou non).

Fonctions : détection des techniques de sondage (balayages de ports, fingerprinting), des tentatives de compromission de systèmes, d'activités suspectes internes, des activités virales ou encore audit des fichiers de journaux (logs).

Remarque : utopiquement, il s'agit d'un système capable de détecter tout type d'attaque.

Certains termes sont souvent employés quand on parle d'IDS :

• Faux positif : une alerte provenant d'un IDS, mais qui ne correspond pas à une attaque réelle.
• Faux négatif : une intrusion réelle qui n'a pas été détectée par l'IDS

Objectif : analyser de manière passive les flux en transit sur le réseau et détecter les intrusions en temps réel.

Un NIDS écoute donc tout le trafic réseau, puis l'analyse et génère des alertes si des paquets semblent dangereux.

Les NIDS étant les IDS plus intéressants et les plus utiles du fait de l'omniprésence des réseaux dans notre vie quotidienne, ce document se concentrera essentiellement sur ce type d'IDS.

Un HIDS se base sur une unique machine, n'analysant cette fois plus le trafic réseau, mais l'activité se passant sur cette machine. Il analyse en temps réel les flux relatifs à une machine ainsi que les journaux.

Un HIDS a besoin d'un système sain pour vérifier l'intégrité des données. Si le système a été compromis par un pirate, le HIDS ne sera plus efficace. Pour parer à ces attaques, il existe des KIDS (Kernel Intrusion Detection System) et KIPS (Kernel Intrusion PreventionSystem) qui sont fortement liés au noyau. Ces types d'IDS sont décrits un peu plus loin.

Généralement utilisés dans un environnement décentralisé, ils permettent de réunir les informations de diverses sondes placées sur le réseau. Leur appellation « hybride » provient du fait qu'ils sont capables de réunir aussi bien des informations provenant d'un système HIDS qu'un NIDS.

L'exemple le plus connu dans le monde Open-Source est Prelude. Ce framework permet de stocker dans une base de données des alertes provenant de différents systèmes relativement variés. Utilisant Snort comme NIDS, et d'autres logiciels tels que Samhain en tant que HIDS, il permet de combiner des outils puissants tous ensemble pour permettre une visualisation centralisée des attaques.

Remarque : nous parlerons de tous ces produits plus tard dans ce document, en évoquant les spécificités et l'installation de chacun.

Définition : ensemble de composants logiciels et matériels dont la fonction principale est d'empêcher toute activité suspecte détectée au sein d'un système.

Contrairement aux IDS simples, les IPS sont des outils aux fonctions « actives », qui en plus de détecter une intrusion, tentent de la bloquer. Cependant, les IPS ne sont pas la solution parfaite comme on pourrait le penser.

Plusieurs stratégies de prévention d'intrusions existent :

• host-based memory and process protection :surveille l'exécution des processus et les tue s'ils ont l'air dangereux (buffer overflow). Cette technologie est utilisée dans les KIPS (Kernel Intrusion Prevention System) que nous décrivons un peu plus loin ;
• session interception / session sniping : termine une session TCP avec la commande TCP Reset : « RST ». Ceci est utilisé dans les NIPS (Network Intrusion Prevention System) ;
• gateway intrusion detection : si un système NIPS est placé en tant que routeur, il bloque le trafic ; sinon il envoie des messages à d'autres routeurs pour modifier leur liste d'accès.

Un IPS possède de nombreux inconvénients. Le premier est qu'il bloque toute activité qui lui semble suspecte. Or, il est impossible d'assurer une fiabilité à 100 % dans l'identification des attaques. Un IPS peut donc malencontreusement bloquer du trafic inoffensif ! Par exemple, un IPS peut détecter une tentative de déni de service alors qu'il s'agit simplement d'une période chargée en trafic. Les faux positifs sont donc très dangereux pour les IPS.

Le deuxième inconvénient est qu'un pirate peut utiliser sa fonctionnalité de blocage pour mettre hors service un système. Prenons l'exemple d'un individu mal intentionné qui attaque un système protégé par un IPS, tout en spoofant son adresse IP. Si l'adresse IP spoofée est celle d'un nœud important du réseau (routeur, service Web…), les conséquences seront catastrophiques. Pour pallier ce problème, de nombreux IPS disposent des « white lists », c'est-à-dire des listes d'adresses réseau qu'il ne faut en aucun cas bloquer.

Et enfin, le troisième inconvénient et non le moindre : un IPS est peu discret. En effet, à chaque blocage d'attaque, il montre sa présence. Cela peut paraître anodin, mais si un pirate remarque la présence d'un IPS, il tentera de trouver une faille dans celui-ci afin de réitérer son attaque… mais cette fois en passant inaperçu.

Voilà pourquoi les IDS passifs sont souvent préférés aux IPS. Cependant, il est intéressant de noter que plusieurs IDS (ex. : Snort, RealSecure, Dragon…) ont été dotés d'une fonctionnalité de réaction automatique à certains types d'attaques.

Nous l'évoquions précédemment dans le cadre du HIDS, l'utilisation d'un détecteur d'intrusions au niveau noyau peut s'avérer parfois nécessaire pour sécuriser une station.

Prenons l'exemple d'un serveur web, sur lequel il serait dangereux qu'un accès en lecture/écriture dans d'autres répertoires que celui consultable via HTTP, soit autorisé. En effet, cela pourrait nuire à l'intégrité du système. Grâce à un KIPS, tout accès suspect peut être bloqué directement par le noyau, empêchant ainsi toute modification dangereuse pour le système.

Le KIPS peut reconnaître des motifs caractéristiques du débordement de mémoire, et peut ainsi interdire l'exécution du code. Le KIPS peut également interdire l'OS d'exécuter un appel système qui ouvrirait un shell de commandes.

Puisqu'un KIPS analyse les appels systèmes, il ralentit l'exécution. C'est pourquoi ce sont des solutions rarement utilisées sur des serveurs souvent sollicités.

Exemple de KIPS : SecureIIS, qui est une surcouche du serveur IIS de Microsoft.

Les firewalls ne sont pas des IDS à proprement parler, mais ils permettent également de

stopper des attaques. Nous ne pouvions donc pas les ignorer.

Les firewalls sont basés sur des règles statiques afin de contrôler l'accès des flux. Ils travaillent en général au niveau des couches basses du modèle OSI (jusqu'au niveau 4), ce qui est insuffisant pour stopper une intrusion. Par exemple, lors de l'exploitation d'une faille d'un serveur Web, le flux HTTP sera autorisé par le firewall puisqu'il n'est pas capable de vérifier ce que contiennent les paquets.

Il existe trois types de firewalls :

• les systèmes à filtrage de paquets sans état : analysent les paquets les uns après les autres, de manière totalement indépendante ;
• les systèmes à maintien d'état (stateful) : vérifient que les paquets appartiennent à une session régulière. Ce type de firewall possède une table d'états où est stocké un suivi de chaque connexion établie, ce qui permet au firewall de prendre des décisions adaptées à la situation.

Ces firewalls peuvent cependant être outrepassés en faisant croire que les paquets appartiennent à une session déjà établie ;

• les firewalls de type proxy : le firewall s'intercale dans la session et analyse l'information afin de vérifier que les échanges protocolaires sont conformes aux normes.

Les scanners de vulnérabilités : systèmes dont la fonction est d'énumérer les vulnérabilités présentes sur un système. Ces programmes utilisent une base de vulnérabilités connues (exemple : Nessus).

Les systèmes de leurre : le but est de ralentir la progression d'un attaquant, en générant des fausses réponses telles que renvoyer une fausse bannière du serveur Web utilisé.

Les systèmes de leurre et d'étude (Honeypots) : le pirate est également leurré, mais en plus, toutes ses actions sont enregistrées. Elles seront ensuite étudiées afin de connaître les mécanismes d'intrusion utilisés par le hacker. Il sera ainsi plus facile d'offrir des protections par la suite.

Les systèmes de corrélation et de gestion des intrusions (SIM - Security Information Manager) : centralisent et corrèlent les informations de sécurité provenant de plusieurs sources (IDS, firewalls, routeurs, applications…). Les alertes sont ainsi plus faciles à analyser.

Les systèmes distribués à tolérance d'intrusion : l'information sensible est répartie à plusieurs endroits géographiques, mais des copies de fragments sont archivées sur différents sites pour assurer la disponibilité de l'information. Cependant, si un pirate arrive à s'introduire sur le système, il n'aura qu'une petite partie de l'information et celle-ci lui sera inutile.

Cette technique s'appuie sur la connaissance des techniques utilisées par les attaquants pour déduire des scénarios typiques. Elle ne tient pas compte des actions passées de l'utilisateur et utilise des signatures d'attaques (= ensemble de caractéristiques permettant d'identifier une activité intrusive : une chaîne alphanumérique, une taille de paquet inhabituelle, une trame formatée de manière suspecte…).

Recherche de motifs (pattern matching)

La méthode la plus connue et la plus à facile à comprendre. Elle se base sur la recherche de motifs (chaînes de caractères ou suite d'octets) au sein du flux de données. L'IDS comporte une base de signatures où chaque signature contient les protocole et port utilisés par l'attaque ainsi que le motif qui permettra de reconnaître les paquets suspects.

Le principal inconvénient de cette méthode est que seules les attaques reconnues par les signatures seront détectées. Il est donc nécessaire de mettre à jour régulièrement la base de signatures.

Un autre inconvénient est que les motifs sont en général fixes. Or une attaque n'est pas toujours identique à 100 %. Le moindre octet différent par rapport à la signature provoquera la non-détection de l'attaque.

Pour les IDS utilisant cette méthode, il est nécessaire d'adapter la base de signatures en fonction du système à protéger. Cela permet non seulement de diminuer les ressources nécessaires et donc augmenter les performances ; mais également réduire considérablement le nombre de fausses alertes et donc faciliter le travail des administrateurs réseau qui analyseront les fichiers d'alertes.

Cette technique est également utilisée dans les antivirus.

Recherche de motifs dynamiques

Le principe de cette méthode est le même que précédemment, mais les signatures des attaques évoluent dynamiquement. L'IDS est de ce fait doté de fonctionnalités d'adaptation et d'apprentissage.

Analyse de protocoles

Cette méthode se base sur une vérification de la conformité (par rapport aux RFC) des flux, ainsi que sur l'observation des champs et paramètres suspects dans les paquets. Cependant, les éditeurs de logiciels et les constructeurs respectent rarement à la lettre les RFC et cette méthode n'est pas toujours très performante.

L'analyse protocolaire est souvent implémentée par un ensemble de préprocesseurs, où chaque préprocesseur est chargé d'analyser un protocole particulier (FTP, HTTP, ICMP…). Du fait de la présence de tous ces préprocesseurs, les performances dans un tel système s'en voient fortement dégradées.

L'intérêt fort de l'analyse protocolaire est qu'elle permet de détecter des attaques inconnues, contrairement au pattern matching qui doit connaître l'attaque pour pouvoir la détecter.

Analyse heuristique et détection d'anomalies

Le but de cette méthode est, par une analyse intelligente, de détecter une activité suspecte ou

toute autre anomalie.

Par exemple : une analyse heuristique permet de générer une alarme quand le nombre de sessions à destination d'un port donné dépasse un seuil dans un intervalle de temps prédéfini.

Cette technique consiste à détecter une intrusion en fonction du comportement passé de l'utilisateur. Pour cela, il faut préalablement dresser un profil utilisateur à partir de ses habitudes et déclencher une alerte lorsque des événements hors profil se produisent.

Cette technique peut être appliquée non seulement à des utilisateurs, mais aussi à des applications et services. Plusieurs métriques sont possibles : la charge CPU, le volume de données échangées, le temps de connexion sur des ressources, la répartition statistique des protocoles et applications utilisés, les heures de connexion…

Cependant elle possède quelques inconvénients :

• peu fiable : tout changement dans les habitudes de l'utilisateur provoque une alerte ;
• nécessite une période de non-fonctionnement pour mettre en œuvre les mécanismes d'autoapprentissage : si un pirate attaque pendant ce moment, ses actions seront assimilées à un profil utilisateur, et donc passeront inaperçues lorsque le système de détection sera complètement mis en place ;
• l'établissement du profil doit être souple afin qu'il n'y ait pas trop de fausses alertes : le pirate peut discrètement intervenir pour modifier le profil de l'utilisateur afin d'obtenir après plusieurs jours ou semaines, un profil qui lui permettra de mettre en place son attaque sans qu'elle ne soit détectée.

Plusieurs approches peuvent être utilisées pour la méthode de détection comportementale :

Approche probabiliste

Des probabilités sont établies permettant de représenter une utilisation courante d'une application ou d'un protocole. Toute activité ne respectant pas le modèle probabiliste provoquera la génération d'une alerte.

Exemple : Avec le protocole HTTP, il y a une probabilité de 0.9 qu'une commande GET soit faite après une connexion sur le port 80. Il y a ensuite une probabilité de 0.8 que la réponse à cette commande GET soit « HTTP/1.1 200 OK ».

Approche statistique

Le but est de quantifier les paramètres liés à l'utilisateur : taux d'occupation de la mémoire, utilisation des processeurs, valeur de la charge réseau, nombre d'accès à l'Intranet par jour, vitesse de frappe au clavier, sites les plus visités…

Cette méthode est très difficile à mettre en place. Elle n'est actuellement présente que dans le domaine de la recherche, où les chercheurs utilisent des réseaux neuronaux et le data mining pour tenter d'avoir des résultats convaincants.

Autres méthodes

D'autres méthodes existent, mais ne sont pas encore répandues. Parmi celles-ci, nous pouvons noter :

• l'utilisation de l'immunologie, c'est-à-dire construire un modèle de comportement normal des services ;
• la présentation d'une activité habituelle sous forme de graphe.

En général, les IDS mélangent les différentes techniques de détection par scénario en proposant du pattern matching, de l'analyse protocolaire et de la détection d'anomalies.

De nombreuses techniques et algorithmes sont utilisés dans la détection d'intrusions :

• Pattern Matching
  algorithmes de recherche de motifs (ex. : Boyer-Moore),
  algorithmes de comptage,
  algorithmes génétiques ;
• Analyse Protocolaire
  conformité aux RFC ;
• Détection d'anomalies
  méthodes heuristiques ;
• Analyse statistique
  modèles statistiques ;
• Analyse probabiliste
  réseaux bayésiens ;
• Autres analyses comportementales
  réseaux de neurones, systèmes experts + data mining, immunologie, graphes…

Il est bien sûr impossible de détailler chacun des algorithmes mis en œuvre dans les IDS.

Nous avons cependant dédié le chapitre 6 aux algorithmes de pattern matching.

Il faut tout d'abord prendre conscience qu'un NIDS n'est pas suffisant pour assurer la sécurité. En plus d'installer un NIDS, il ne faudra pas oublier les actions habituelles :

• les systèmes et les applications doivent être mises à jour régulièrement (patches de sécurité) ;
• les systèmes utilisant Internet doivent être dans un réseau isolé (DMZ(5)) ;
• chaque utilisateur doit être averti de l'importance de la sécurité de ses mots de passe ;
• les fonctionnalités des services qui ne sont pas utilisées doivent être désactivées.

Lors du déploiement d'un IDS, il faut le configurer correctement : par exemple, si le réseau est sous Windows, les règles destinées à Unix ne sont pas nécessaires. Il faut donc faire une configuration en fonction de l'OS, des applications et du matériel utilisés.

L'emplacement du senseur(6) est très important :

• À l'emplacement B, seul le trafic entre les systèmes de la DMZ et Internet est analysé. Le trafic entre le réseau interne et Internet n'est pas analysé. Pour cela, il faudra également placer un senseur au point A.
• À l'emplacement C, le trafic entre Internet et le réseau interne ou la DMZ est analysé. Par contre, le trafic entre le réseau interne et la DMZ est invisible.

Il est impensable de vouloir analyser tout le trafic d'un réseau. Il faut donc donner la priorité aux systèmes à risque : ceux qui offrent des services accessibles par Internet (HTTP, FTP…).

De plus, il est souvent préférable de placer le senseur après le firewall du côté interne. Ainsi, seuls les flux acceptés par le firewall sont analysés, ce qui réduit fortement la charge de la sonde IDS.

Lors de l'installation d'un NIDS, le choix matériel a également une grande importance.

Puisqu'une sonde NIDS doit être capable d'analyser le trafic réseau quel que soit le destinataire, elle devra recevoir elle-même tous les paquets. Pour cela, le NIDS devra jouer le rôle d'un sniffer(7), mais le matériel réseau pose parfois problème :

• un switch simple (commutateur) : en utilisant un tel équipement, la conversation avec l'IDS est impossible du fait de la nature d'un switch : il commute les paquets directement au destinataire. Il est dès lors impossible d'installer une sonde qui analysera le trafic global ;
• un hub (concentrateur) => la conversation avec l'IDS est possible, car les hubs répètent les paquets en les émettant à toutes les machines connectées. Cependant, les hubs sont peu fiables et sont donc à éviter ;
• il existe des switches professionnels qui copient le trafic et l'envoie sur un port spécifié (où sera placé le NIDS) : SPAN port (Switch Port Analyzer). Attention : pour ce port, il faudra utiliser une connexion rapide (ex. : Gigabits) capable d'analyser entièrement le trafic provenant ou à destination des différents sous réseaux.

Un autre problème doit être pris en considération : lorsque les flux sont cryptés (ex. : par SSL, c'est le cas pour les VPN(8)), il est impossible pour l'IDS de décrypter ces flux. Il faut dans ce cas utiliser un proxy SSL comme illustré ci-dessous.

Nous savons donc maintenant que l'emplacement des sondes et le matériel réseau utilisés sont très importants. Cependant, un autre point ne doit pas être oublié : la sécurisation du senseur et des logs d'alerte. En effet, si la sonde elle-même ou si les alertes qu'elles génèrent ne sont pas sécurisées, un pirate pourrait très bien rendre l'IDS complètement inefficace.

Pour sécuriser les sondes et les fichiers d'alertes, il est par exemple possible de mettre en place un réseau de management très contrôlé, avec son propre firewall. Ce système sera primordial pour la sécurité du réseau et plusieurs mesures devront être prises pour assurer son fonctionnement :

• le système d'exploitation du senseur devra tenu à jour ;
• un système d'authentification robuste (ex. : PKI) pourra être mis en place pour renforcer la sécurité ;
• tous les mots de passe devront être changés régulièrement ;
• il est également possible d'utiliser deux interfaces réseaux pour le senseur : la première pour générer les alertes et contrôler le trafic, et la deuxième, complètement invisible, en tant que point de monitoring. Ce genre d'interface est communément appelée stealth interface.

Le premier problème est de configurer correctement l'IDS afin qu'il n'inonde pas les rapports d'alertes avec des faux positifs. La présence de faux positifs semble inoffensive. Or, s'ils sont trop nombreux, les rapports d'alertes seront longs à analyser. Par conséquent, les administrateurs passeront beaucoup de temps à distinguer un faux positif d'une véritable intrusion. Et de plus, en voyant toutes ces fausses alertes, ils auront tendance à minimiser le risque d'attaque.

Bien sûr, il faut également veiller à ce que l'affinement de la configuration ne génère pas des faux négatifs, car toute intrusion non détectée peut avoir des conséquences dramatiques.

Le deuxième problème provient des débits actuels sur les réseaux : ces débits augmentent de plus en plus, et les IDS ont de plus en plus de paquets à traiter et à analyser.

En plus d'avoir un équipement réseau performant, l'IDS doit utiliser des algorithmes adaptés et

optimisés.

Afin de bien comprendre comment améliorer les performances d'un NIDS, il faut comprendre les différentes étapes. Chaque paquet de données traité par l'IDS va subir une suite de traitements :

• capture de la trame par l'interface en mode promiscuité (promiscous mode) ;
• analyse de la trame et filtrage éventuel en bas niveau ;
• détection de la présence de fragments ou non et passage éventuel à un moteur de reconstruction ;
• transfert de la trame vers le système d'exploitation ;
• filtrage éventuel ;
• applications de divers préprocesseurs en fonction du type de requête afin de contrer des techniques d'évasion d'attaques (voir plus loin) ;
• passage vers le moteur d'analyse (protocole, pattern matching, statistique…).

Pour améliorer les performances de l'IDS, il peut donc être judicieux de répartir les charges. Par exemple, il est envisageable de séparer les flux à analyser en fonction du protocole de niveau 4 : une sonde pour l'analyse des flux Web, une autre pour l'analyse des flux FTP et une analyse des requêtes SQL.

Un autre problème est la corrélation des informations provenant de plusieurs types de

sondes. Voici les actions à réaliser pour regrouper ces informations :

• agrégation : rassembler les informations des différentes sondes ;
• fusion : fusionner en supprimant les doublons (même attaque détectée par plusieurs sondes) ;
• corrélation : définir un motif commun, c'est-à-dire interpréter une suite d'événements et les résumer.

Une corrélation intéressante serait de ne garder que les alertes qui concernent une faille probable du système. Pour cela il faut utiliser un scanner de vulnérabilités par exemple, ou ne pas afficher les alertes concernant IIS si on possède Apache, ce qui entraînera moins de faux positifs.

Néanmoins, l'utilisation d'un scanner de vulnérabilités n'est pas parfaite, car il est difficile d'échanger des informations entre un scanner de vulnérabilités et un IDS. Cependant, depuis peu, des consoles de corrélation entre IDS et scanners de vulnérabilités sont proposées (ex. : Nevo de Tenable Network Security).

Enfin, un dernier problème est qu'il n'y a aucune interopérabilité entre les différents IDS

du marché, mis à part la possibilité d'exporter les informations dans des formats standard.

Pourtant, des normes ont été établies, comme nous allons le voir.

Nous avons vu qu'il existe plusieurs types d'IDS, dont leur rôle est complètement différent. Plus exactement, leurs rôles sont complémentaires. En effet, un NIDS ne fera qu'analyser le trafic réseau. Mais complété par un HIDS, des intrusions non détectées sur le réseau pourront l'être lorsqu'elles atteindront la machine cible.

En général, un seul NIDS par réseau est suffisant. Mais il est possible de placer des sondes à différents endroits du réseau afin de répartir la charge.

L'idéal pour les HIDS serait d'en déployer sur toutes les machines du parc informatique, mais cela n'est rarement fait pour des raisons de coût et d'exploitation. Un compromis souvent choisi est d'installer des agents HIDS sur toutes les machines de la DMZ, ainsi que sur les serveurs importants.

Les KIDS/KIPS ralentissant énormément l'exécution des programmes, ils sont souvent délaissés ou configurés de façon à n'utiliser que les fonctionnalités de base. Pourtant, ils sont les seuls à pouvoir détecter de manière efficace les tentatives de buffer overflows. Ils sont donc très conseillés sur les machines sensibles.

Comme nous l'avons déjà signalé, il est très dangereux que la présence d'un IDS soit remarquée par un pirate. Car dans ce cas, il tentera d'obtenir un maximum d'informations sur l'IDS installé (ex. : la version utilisée) pour pouvoir l'outrepasser et attaquer sans se faire remarquer. Voici quelques techniques qui permettent de détecter un IDS :

usurpation d'adresse MAC : les NIDS mettent l'interface de capture en mode promiscuité (promiscuous mode), il est donc possible de détecter l'IDS en envoyant par exemple un ICMP « echo request » à la machine soupçonnée d'être un NIDS avec une adresses MAC inexistante.

Si la machine répond alors elle est en mode promiscuous et peut donc être un NIDS ;

mesure des temps de latence : puisque l'interface est en mode promiscuous, les temps de

réponse sont plus longs. Voici une méthode pour exploiter ces temps de latence :

• le pirate génère une série de pings vers l'adresse à tester, puis il mesure et note les temps de réponse ;
• le pirate sature ensuite le réseau en broadcast(9) dans le but de ralentir l'IDS, qui recevra tous les paquets. Enfin, le pirate réémet la même série de pings en mesurant les nouveaux temps de réponse. S'ils sont bien plus élevés que les premiers temps obtenus, il est fort possible que la machine soit en mode promiscous ;

exploiter les mécanismes de réponses actives : les IPS réagissent à certaines attaques (fermer session, bloquer port…), mais en faisant cela, ils laissent souvent des empreintes (header des paquets) permettant d'identifier le type d'IPS ;

observation des requêtes DNS : Les IDS génèrent souvent des requêtes DNS lors des alertes.

En observant le DNS primaire lors de fausses attaques, on peut détecter qu'il y a un IDS.

Le but est de désactiver l'IDS en saturant ses ressources (ex. : SYN Flood ou paquets fragmentés incomplets). L'IDS sera dès lors incapable d'exécuter sa fonctionnalité de détection, et le pirate pourra réaliser son attaque.

Comme nous l'avons vu, ces techniques consistent à injecter des données supplémentaires de telle sorte que :

• l'IDS les estime inoffensives ;
• la cible ne les décode pas ;

Voici quelques méthodes permettant d'utiliser des techniques d'insertion :

- en utilisant la fragmentation IP qui est gérée de manière différente selon l'OS lors de cas anormaux (ex. : recouvrement de paquets) : soit les fragments anciens sont favorisés, soit les nouveaux le sont. Par exemple, il est donc possible que les IDS favorisent les anciens paquets alors que le système d'exploitation utilisé favorise les nouveaux.

Pour utiliser le recouvrement de fragments (fragmentation overlap), il faut modifier artificiellement les champs « longueur » et « décalage » (offset) des fragments IP ;

- en utilisant l'écrasement de fragments (fragmentation overwrite) : même principe que précédemment, mais des fragments entiers sont remplacés, et non seulement des parties de paquets ;

- en utilisant le timeout de fragmentation : les systèmes conservent en général les fragments pendant 60 secondes pour le réassemblage ; mais les IDS les gardent souvent moins longtemps. On peut donc espacer les fragments dans le temps pour ne pas se faire repérer par l'IDS tout en réalisant une attaque complète sur le système d'exploitation ;

- découpage de sessions TCP (session splicing) : la requête TCP est divisée en paquets, tout en modifiant le numéro de séquence pour créer des recouvrements : même principe qu'avec la fragmentation IP + possibilité de timeout (Apache Linux : 5 min dans tampon, IIS : 10 min). L'un des outils pour réaliser ce genre d'attaques se nomme fragroute ;

- insérer un faux paquet avec checksum erroné : certains IDS ne verront pas l'attaque, car peu d'IDS vérifient le checksum. Le système, par contre, rejettera le paquet erroné.

Attention : de nos jours, les routeurs rejettent souvent les paquets erronés ; il faut donc utiliser un autre champ que le checksum, par exemple le TTL.

Nous présentons maintenant quelques techniques d'évasion. Pour rappel, ces techniques ont pour but d'insérer des données qui seront ignorées par l'IDS, mais qui ne gêneront nullement l'attaque.

Evasions HTTP : le principe est de modifier la syntaxe des URL, mais sans changer la sémantique. La première personne à avoir présenté ce genre d'attaques avait pour pseudonyme Rain Forrest Puppy qui est l'auteur du très célèbre outil Whisker, un scanner de vulnérabilités Web.

Voici quelques exemples d'évasion HTTP qui permettaient à une époque d'outrepasser les signatures de nombreux NIDS, tout en émettant des requêtes HTTP valides. Bien sûr, les NIDS prennent maintenant en compte ces techniques.

=> faire une requête HEAD au lieu de GET.

=> encoder les URL en hexadécimal, cette forme d'encodage étant tout à fait valide selon la RFC du protocole HTTP.

exemple : www%2Emonsite%2Ecom%2Fcgi%2Fscript

=> utiliser des doubles slashes au lieu de slashes simples

exemple : www.monsite.com//cgi//script

=> traverser des répertoires fantômes

exemple : www.monsite.com/repFantome/../cgi/script

=> utiliser des autoréférences

exemple : www.monsite.com/cgi/./././script

=> simuler la fin d'une requête prématurée avec le caractère de fin de chaîne %00 ou bien avec les caractères de fin de requête HTTP : %0D%0A

=> utiliser des URL longues : certains IDS n'analysaient qu'une partie de l'URL

=> utiliser la syntaxe MS DOS / Windows : remplacer les caractères / par \

exemple : www.monsite.com\cgi\script

=> découper la requête HTTP sur plusieurs paquets

=> remplacer les espaces par des tabulations

Shellcodes polymorphiques : parmi les attaques décrites précédemment, nous avons vu les tentatives de buffer overflow. Celles-ci peuvent être décomposées en trois grandes parties :

- des instructions pour remplir le buffer. Assez souvent, ce sont des instructions assembleurs NOP, dont le code est 0x90 sur architecture IA32.

- le shellcode, c'est-à-dire le code qui sera exécuté sur la machine et qui permettra de donner accès à un shell de commandes.

- une adresse de retour de procédure (qui pointe souvent vers les NOP) qui permettra lors du dépassement de buffer d'exécuter le shellcode.

De nombreux IDS sont capables de détecter les tentatives de buffer overflow. La première méthode est de surveiller la présence importante d'instructions NOP. La deuxième est de détecter la chaîne « bin/sh » qui est souvent présente dans les shellcodes pour Unix. La troisième méthode est d'avoir des signatures complètes de shellcodes répandus sur Internet.

Cependant, il est facilement possible de camoufler une tentative de buffer overflow.

Voici quelques techniques simples, mais efficaces :

- mettre une autre instruction que des NOP pour remplir le buffer (ex. : DAA, AAA, XOR, INC…) ;

- écrire les instructions par des équivalences, comme par exemple réécrire une instruction « MOV EAX, 0 » par « XOR EAX,EAX » ou bien encore « SUB EAX, EAX » qui auront toutes les trois pour effet de mettre le registre EAX à 0 ;

- réaliser un cryptage (XOR) du shellcode et ainsi le rendre polymorphique. Dans ce cas, le décodeur et la clé doivent être présents dans le shellcode pour pouvoir le décrypter lors de son exécution chez la victime.

Nous pouvons remarquer qu'il devient très difficile pour un IDS de détecter un shellcode en utilisant des signatures. Le seul moyen efficace est de détecter le buffer overflow lors de son exécution et l'empêcher au dernier moment de lancer un shellcode. Pour cela, seuls les KIPS (Kernel Intrusion Prevention System) se montrent adaptés puisqu'ils surveillent les appels systèmes.

Snort est un NIDS/NIPS provenant du monde Open Source. Avec plus de 2 millions de téléchargements, il s'est imposé comme le système de détection d'intrusions le plus utilisé. Sa version commerciale, plus complète en fonctions de monitoring, lui a donné bonne réputation auprès des entreprises.

Snort est capable d'effectuer une analyse du trafic réseau en temps réel et est doté de différentes technologies de détection d'intrusions telles que l'analyse protocolaire et le pattern matching. Snort peut détecter de nombreux types d'attaques : buffer overflows, scans de ports furtifs, attaques CGI, sondes SMB, tentatives de fingerprinting de système d'exploitation…

Snort est doté d'un langage de règles permettant de décrire le trafic qui doit être accepté ou collecté. De plus, son moteur de détection utilise une architecture modulaire de plugins.

Notons que Snort dispose de trois modes de fonctionnement : sniffer de paquets, logger de paquets et système de détection/prévention d'intrusions. Nous ne nous intéresserons qu'à ce dernier mode.

1. Télécharger les sources sur www.snort.org. Lors de l'écriture de ce document, la dernière version stable était la 2.4.4.

2. Télécharger et installer les bibliothèques nécessaires pour Snort :

• libpcap (http://www.tcpdump.org) : offre des fonctions de sniffer
• PCRE (http://www.pcre.org) : permet d'utiliser des expressions régulières de type Perl

La compilation de ces bibliothèques se fait très aisément : ./configure, make, make install.

3. Ouvrir un terminal, décompresser ensuite l'archive de Snort et se placer dans le répertoire des sources décompressées.

4. Configurer la compilation de Snort afin d'activer plusieurs fonctionnalités : ./configure [options].

Deux options nous ont semblé intéressantes :

• --with-mysql=DIR : activer le support de MySQL. Ainsi Snort enregistrera les alertes dans une base de données accessible par d'autres applications (ex. : BASE, décrite plus loin). MySQL n'est bien sûr pas l'unique SGBD supporté.

PostgreSQL ou Oracle peuvent également être utilisés avec les options -withpostgresql et --with-oracle.

• --enable-flexresp : activer les réponses flexibles en cas de tentatives de connexion hostile. Pour activer cette option, la bibliothèque libnet (http://www.packetfactory.net/libnet) est nécessaire.

5. Compiler les sources : make.

6. Installer Snort : make install en mode root.

7. Pour que Snort puisse fonctionner en mode détection/prévention d'intrusions, il est nécessaire de lui fournir des fichiers de règles. Le site de Snort propose deux types de règles : les règles officielles et les règles créées par la communauté. Certaines règles officielles ne sont disponibles que pour les utilisateurs enregistrés, tandis que les règles communautaires sont disponibles à tous et mises à jour régulièrement. Il est cependant important de noter que les règles proposées par la communauté n'ont pas été forcément testées par l'équipe officielle de Snort.

Après téléchargement, l'archive des règles doit être décompressée. Il est conseillé de placer le répertoire rules dans le dossier de Snort. Nous pouvons remarquer que les règles consistent en de simples fichiers textes, et qu'un fichier un peu spécial est présent : snort.conf. Ce dernier va nous permettre de configurer Snort.

Afin de configurer correctement Snort pour qu'il puisse fonctionner en mode détection d'intrusions, il faut modifier le fichier snort.conf. L'emplacement par défaut de ce fichier doit normalement être /etc/snort.conf. Cependant, il sera possible de spécifier un autre emplacement lors de l'exécution de Snort, à l'aide de l'option -c.

Le fichier de configuration contient de nombreuses options paramétrables, ainsi que des explications pour pouvoir les modifier correctement. Nous n'allons nous intéresser ici qu'à quelques variables :

• la variable HOME_NET permet de spécifier quels réseaux ou quelles interfaces seront surveillés par Snort. La valeur any signale à Snort de surveiller tout le trafic ;
• si le réseau à surveiller possède des serveurs DNS, SMTP, FTP, etc., il est possible de spécifier les adresses IP de ces serveurs via les variables DNS_SERVERS, SMTP_SERVERS… Si le réseau ne possède pas un type spécifique de serveur, il est conseillé de commenter (avec le caractère #) la ligne concernée, afin d'optimiser le traitement de Snort. En effet, il est inutile d'analyser du trafic HTTP si aucun serveur Web n'est disponible ;
• certains ports de services peuvent être configurés via des variables telles que HTTP_PORTS ou ORACLE_PORTS.
• la variable RULE_PATH est très importante. Elle permet de spécifier le répertoire où sont stockés les fichiers de règles de Snort.
• les directives include permettent d'inclure des fichiers de règles. Ici encore, il est conseillé de n'inclure que les règles nécessaires en fonction des services disponibles sur le réseau.

L'exécution de Snort se fait en lançant l'exécutable snort en mode root et avec différentes options. Voyons les principaux arguments de Snort :

• -A : générer des alertes. Activé par défaut avec l'option -c
• -c <emplacement de snort.conf> : lancer Snort avec des fichiers de règles.
• -l <répertoire de log> : spécifier le répertoire où les logs d'alertes seront stockés (défaut : /var/log/snort)
• -v : mode verbose. Permet d'afficher les paquets capturés
• -T : mode test. Permet de tester la configuration de Snort

Avant de lancer Snort en mode NIDS, il est préférable de tester si le programme arrive à récupérer les paquets qui circulent sur le réseau. Pour cela, nous pouvons par exemple lancer Snort en simple mode Sniffer : snort -v. Si aucun paquet n'est capturé et affiché, il est probable que Snort n'écoute pas sur la bonne interface. L'option -i permet de spécifier une autre interface.

Lançons maintenant Snort en mode NIDS. Pour cela, nous lui précisons l'emplacement du fichier de configuration avec l'option -c : snort -c /opt/snort/rules/snort.conf

Toutes les alertes détectées sont ainsi stockées dans le fichier /var/log/snort/alert. Pour chaque alerte, Snort donne une priorité, une description, les flags des paquets et éventuellement des adresses sur Internet où se trouvent de plus amples informations sur la tentative d'intrusion.

Exemple :

[**] [1:1384:8] MISC UPnP malformed advertisement [**]
[Classification: Misc Attack] [Priority: 2]
03/25-17:34:49.251861 192.168.0.1:1900 ->
239.255.255.250:1900
UDP TTL:1 TOS:0x0 ID:37277 IpLen:20 DgmLen:437
Len: 409
[Xref =>
http://www.microsoft.com/technet/security/bulletin/MS01-
059.mspx][Xref => http://cve.mitre.org/cgibin/
cvename.cgi?name=2001-0877][Xref =>
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-
0876][Xref => http://www.securityfocus.com/bid/3723]

Bien que le site officiel de Snort propose des règles prêtes à l'emploi et régulièrement mises à jour, il peut être intéressant de créer ses propres règles afin d'adapter au mieux Snort au réseau qu'il doit surveiller et protéger. Par convention, les nouvelles règles personnelles sont à placer dans le fichier local.rules.

Une règle Snort est composée de deux parties et possède le format suivant : Header (Options).

Le format de la partie Header est défini de la manière suivante :

Le champ action peut prendre les valeurs suivantes :

• alert : générer une alerte + logger le paquet
• log : logger le paquet
• pass : ignorer le paquet
• activate : activer une règle dynamique
• dynamic : définir une règle dynamique, qui est passive tant qu'elle n'est pas activée par une autre règle
• drop : demander à iptables(10) de bloquer le paquet, puis le logger
• reject : demander à iptables de bloquer le paquet, puis le logger, et envoyer une commande TCP RST (reset) ou une réponse ICMP Host unreachable
• sdrop : demander à iptables de bloquer le paquet. Ce dernier n'est pas loggé.

Le champ protocole spécifie le protocole pour lequel la règle s'applique. Les valeurs possibles sont : tcp, udp, icmp ou ip.

Les champs adresse1 et adresse2 indiquent l'adresse IP source et destination du paquet. Le mot-clé any permet de spécifier une adresse quelconque. Les adresses doivent être numériques, les adresses symboliques ne sont pas acceptées.

Les champs port1 / port2 spécifient les numéros de port utilisés par la source et la destination. Le mot-clé any permet de spécifier un port quelconque. Des noms de services peuvent être utilisés : tcp, telnet… De même des plages de ports peuvent être spécifiées avec le caractère « : ».

Le champ direction spécifie l'orientation du paquet. Cet opérateur peut prendre deux valeurs :

-> : adresse1 vers adresse2

<> : de adresse1 vers adresse2, ou de adresse2 à adresse1

Notons qu'il n'y a pas d'opérateur <- .

La partie Options des règles contient différentes options, séparées par un point-virgule, qui vont permettre de préciser des critères de détection. Pour chaque option, le format est nomOption : valeur1[, valeur2…]

Voici les options importantes :

• msg : spécifier le message qui sera affiché dans le log et dans l'alerte
• reference : faire référence à un site expliquant l'attaque détectée
• classtype : définir la classe de l'attaque (troyen, shellcode…)
• priority : définir la sévérité de l'attaque
• content : spécifier une chaîne de caractères qui doit être présente dans le paquet pour déclencher l'action de la règle
• rawbytes : spécifier une suite d'octets qui doit être présente dans le paquet pour déclencher l'action de la règle
• uricontent : identique à content, mais est adapté au format normalisé des URI (ex. : hexadécimal accepté)
• pcre : utiliser une expression régulière compatible Perl pour spécifier le contenu du paquet
• ttl : spécifier la valeur du TTL du paquet
• flags : spécifier la présence d'un flag TCP dans le paquet (ex. : SYN, FIN…)
• fragbits : vérifier la présence de certains bits IP (more fragments, don't fragment ou bit réservé)
• session : extraire toutes les informations de la session TCP à laquelle le paquet suspect appartient
• resp : activer une réponse flexible (flexresp) afin de bloquer l'attaque. Il est ainsi possible d'envoyer une commande TCP ou ICMP précise. Cette option nécessite l'activation du mode flexresp lors de la compilation de Snort.
• limit : limiter le nombre d'actions pendant un intervalle de temps pour le même événement.

Exemple de règle :

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEBATTACKS
/bin/ls command attempt"; uricontent:"/bin/ls";
nocase; classtype:web-application-attack;)

Cette règle permet de générer une alerte quand un paquet provient d'un couple (adresse:port) quelconque, est à destination des serveurs HTTP définis dans snort.conf, et contient la chaîne « /bin/ls » dans l'URI. Le message de l'alerte sera « WEB-ATTACKS /bin/ls command attempt ». Cette attaque sera classée dans la classe web-application-attack (priorité medium par défaut).

Il est bien sûr impossible d'être exhaustif ici pour décrire le format des règles Snort. Le manuel utilisateur disponible sur le site officiel indique comment utiliser aux mieux le langage des signatures de Snort.

Par défaut, les alertes de Snort sont enregistrées dans un simple fichier texte. L'analyse de ce fichier n'est pas aisée, même en utilisant des outils de filtre et de tri. C'est pour cette raison qu'il est vivement conseillé d'utiliser des outils de monitoring. Parmi ceux-ci, le plus en vogue actuellement est BASE (Basic Analysis and Security Engine), un projet open source basé sur ACID (Analysis Console for Intrusion Databases). La console BASE est une application Web écrite en PHP qui interface la base de données dans laquelle Snort stocke ses alertes.

Pour fonctionner, BASE a besoin d'un certain nombre de dépendances :

• un SGBD installé, par exemple MySQL
• Snort compilé avec le support de ce SGBD
• un serveur HTTP, par exemple Apache
• l'interpréteur PHP avec les supports pour le SGBD choisi, la bibliothèque GD et les sockets.
• La bibliothèque ADODB : http://adodb.sourceforge.net

Nous ne détaillerons pas ici l'installation de chaque dépendance. La documentation livrée avec les sources de BASE (disponibles sur http://secureideas.sourceforge.net) fournit les informations nécessaires.

Notons cependant que l'archive des sources de Snort dispose également d'un dossier schemas contenant le code SQL pour créer la structure de la base de données pour différents SGBD. Le fichier doc/README.database donne toutes les indications pour créer le schéma de la base de données.

Afin que Snort enregistre les alertes dans la base de données, il ne faut pas oublier de modifier le fichier snort.conf et rajouter une ligne output database avec les informations pour se connecter à la base de données.

Exemple :

output database: log, mysql, user=snortusr password=pwd
dbname=snort host=localhost

Après configuration et installation de BASE ainsi que de toutes ses dépendances, nous pouvons y accéder avec un navigateur internet. Si tout se passe bien, un écran similaire à l'illustration suivante est obtenu :

Bro est un NIDS Open Source, développé essentiellement par une équipe du Lawrence Berkeley National Laboratory. Bro se base sur un ensemble de règles décrivant des signatures d'attaques ou des activités inhabituelles.

Le comportement après détection de trafic suspect peut être paramétré : simple log, alerte en temps réel à l'administrateur ou exécuter un programme (par exemple pour reconfigurer un routeur).

Initialement, le projet Bro a été créé dans un but de recherche pour la détection d'intrusions et l'analyse de trafic réseau. De ce fait, ce NIDS n'est pas destiné aux personnes (physiques ou morales) recherchant une solution prête à l'emploi, mais plutôt à des administrateurs Unix chevronnés, désirant configurer au maximum leur système de détection.

Parmi les fonctionnalités intéressantes, on peut noter :

• un langage de script propre à Bro permettant d'écrire les règles de détection et d'action ;
• l'utilisation des expressions régulières pour exprimer les motifs des signatures ;
• la possibilité d'exécuter des programmes tiers après détection d'intrusion permet de réaliser de nombreux types d'actions ;
• une compatibilité avec les règles de Snort, grâce à un convertisseur nommé snort2bro ;
• la possibilité d'utiliser GnuPG (Gnu Privacy Gard) pour crypter et signer les rapports d'alertes. Cela permet d'empêcher l'espionnage ou la falsification des logs par un pirate ;
• l'envoi d'un rapport périodique des alertes par mail.

L'architecture de Bro est définie en trois couches principales :

• le module Packet Capture : chargé d'écouter le trafic en mode sniffer et de transmettre tous les paquets à la couche supérieure ;
• le module Event Engine : classe les flux par protocole, crée une table d'états pour les connexions, contrôle l'intégrité (checksum), réassemble les fragments et analyse les flux. Ce module génère des événements qu'il transmet à la troisième couche ;
• le module Policy Layer : utilise les scripts écrits dans le langage de Bro pour traiter les événements.

1. Télécharger les sources sur http://www.bro-ids.org. Lors de l'écriture de ce document, la dernière version stable était la 0.9.

2. Télécharger et installer les bibliothèques nécessaires pour Bro :

=> libpcap (http://www.tcpdump.org) : offre des fonctions de sniffer

=> termcap (ftp://ftp.gnu.org/gnu/termcap)

La compilation de ces bibliothèques se fait très aisément : ./configure, make, make install.

3. Ouvrir un terminal, décompresser ensuite l'archive de Bro et se placer dans le répertoire des sources décompressées.

4. Générer un makefile adapté au système de destination : ./configure

5. Compiler les sources : make

6. Installer Bro : make install-brolite en mode root. Cette commande va non seulement installer Bro, mais également créer un exécutable qui va faciliter la configuration de Bro.

La configuration générale de Bro se fait très simplement en mode interactif à la fin de l'installation. Il suffit dès lors de répondre aux questions qui sont posées, et l'IDS sera configuré automatiquement. Il est possible de reconfigurer Bro plus tard en exécutant le script bro_config. Notons qu'une configuration manuelle peut être réalisée en éditant le fichier bro.cfg.

Grâce au script de lancement livré avec Bro, le daemon peut être exécuté de manière très simple avec la commande bro.rc start (en mode root). Dès le début de l'exécution, les différentes activités sont loggées dans le répertoire $BROHOME/logs/. Plusieurs fichiers de log y sont présents :

• alarm.XXX : les attaques détectées
• conn.XXX : un résumé des connexions établies
• ftp.XXX : des informations concernant le trafic FTP suspect
• HTTP.XXX : des informations concernant le trafic HTTP suspect
• info.XXX : des informations générales
• notice.XXX : un suivi des événements lancés

Tout comme le NIDS Snort, il est possible avec Bro de créer ses propres règles de détection ou d'adapter les règles existantes en fonction du système utilisé. Pour cela, il faut bien sûr respecter un format très strict, mais puissant.

Chaque signature de Bro a le format suivant : signature id { attribute-set } où id représente un identifiant unique (sous forme de chaîne de caractères) de la signature et où attribute_set est un ensemble d'attributs qui peut contenir des conditions ou des actions.

Quatre types de conditions existent. Celles-ci vont permettre de définir quand la signature sera reconnue :

• conditions d'en-tête : elles permettent de spécifier le protocole, les ports et les adresses source et de destination ;
• conditions de contenu : elles sont exprimées sous forme d'expressions régulières pour reconnaître le contenu de certains types de requêtes ;
• conditions de dépendance : elles permettent d'exprimer des dépendances entre les signatures. Par exemple, une signature ne doit être détectée que si une autre signature l'a été ;
• conditions de contexte : elles permettent de rajouter l'exécution de certaines fonctions, écrites avec le langage de script de Bro, qui complémenteront les autres conditions.

Comme nous pouvons le voir, les conditions de détection de signatures sont très évoluées. Cependant, ce n'est pas le cas des actions, c'est-à-dire les opérations à réaliser quand une signature est détectée. Il n'existe pour l'instant qu'une seule action possible : event. Celle-ci va permettre de décrire l'éventuelle attaque qui a été détectée.

Enfin, rappelons l'existence de snort2bro qui permet de convertir des règles écrites pour Snort dans le format de Bro. Ainsi, un utilisateur préférant la syntaxe de Snort ou utilisant ces deux NIDS, pourra très facilement réutiliser ses règles Snort avec Bro.

OSSEC est un HIDS Open Source. Développé initialement dans le but d'analyser quelques fichiers journaux de différents serveurs, il est devenu aujourd'hui bien plus puissant qu'un simple analyseur de logs.

Capable d'analyser différents formats de journalisation tels que ceux d'Apache, syslog, Snort, et intégrant un analyseur d'intégrité système, il est devenu aujourd'hui un logiciel de détection d'intrusions à part entière.

Ses fonctions lui permettent de détecter des anomalies apparues sur le système. Par exemple, de multiples erreurs 404 dans les logs du serveur web Apache, la présence d'un rootkit(11) caché dans un binaire système, ou encore des essais d'envoi de mail par relay smtp.

En réalité, grâce à un système de règles entièrement paramétrable via des fichiers XML, OSSEC est capable de détecter n'importe quelle anomalie. De plus, il est doté d'un système de « réponse active » qui permet à une commande d'être exécutée lors de la détection d'une anomalie.

L'installation de OSSEC se fait très simplement grâce à un assistant de configuration.

Rendez-vous sur http://www.ossec.net pour télécharger l'IDS. Lors de la rédaction de ce document, la dernière version était 0.7p1.

Décompressez l'archive puis lancez l'installeur à l'aide de la commande ./install.sh une fois dans le répertoire décompressé.

Après quelques questions, l'installeur mettra en place OSSEC et il ne restera plus qu'à compléter le fichier de configuration avec les valeurs souhaitées.

La configuration se situe dans le fichier ossec.conf du dossier $INSTALL_DIR/etc/. La majorité de ce fichier sera rempli par les paramètres spécifiés lors de l'installation. Ce fichier se divise en plusieurs sections :

• Global : contient les paramètres d'alertes par email ;
• Rules : indique les différents fichiers contenant les règles de détection ;
• Syscheck : spécifie les répertoires à scanner et les fichiers à ignorer ;
• Rootcheck : contient les paramètres de détection des rootkits. Les fichiers contenant les signatures doivent être spécifiés ;
• Active-response : active/désactive la réponse active ;
• Alerts : spécifie le niveau d'alerte pour avertir par email l'administrateur ;
• Localfiles : contient tous les fichiers de logs à vérifier (une entrée par fichier).

Grâce à l'externalisation des règles, il est possible de rajouter de nouvelles règles très facilement. Par défaut, les règles concernant un même programme se trouvent toutes dans le même fichier, mais rien n'empêche de créer de nouveaux fichiers.

Voici un exemple de règle :

<group name="syslog,attacks">
...
<rule id="1608" level="14" timeframe="120">
<if_matched_regex>^sshd[\d+]: \.+Corrupted check by bytes
on</if_matched_regex>
<regex>^sshd[\d+]: fatal: Local: crc32 compensation
attack</regex>
<description>SSH CRC-32 Compensation attack</description>
<cve>2001-0144</cve>
<info>http://www.securityfocus.com/bid/2347/info/</info>
</rule>
...
</group>

Cette règle est caractérisée par un identifiant unique (chaque règle possède un identifiant propre), un niveau de sécurité allant de 0 à 16 (ici 14) et une fréquence d'apparition (timeframe). Cette fréquence d'apparition permet de déclencher une règle uniquement si une règle précédente a déjà été levée. La règle précédente est spécifiée à l'aide de la baliseif_matched_regex. Cette dernière option de répétition est bien sur optionnelle.

Plusieurs options de concordance sont possibles. Ici regex spécifie qu'il s'agit d'une expression régulière à trouver dans la chaîne. Toutefois, il existe l'option match qui spécifie une sous-chaîne à trouver dans la chaîne.

La balise description permet de donner une courte description de la règle ; cve la date de découverte de la faille et enfin info permet de spécifier une information supplémentaire sur la règle, par exemple l'URL qui référence l'exploit connu.

Plus d'informations sont disponibles dans la documentation sur le site officiel d'OSSEC.

De la même façon que OSSEC, Samhain est un système de détection d'intrusions Open Source. Il offre néanmoins des fonctions supplémentaires comme le stockage des alertes d'intrusions dans un système de base de données, le chiffrement des communications client/serveur ainsi qu'une console de visualisation des alertes disponible via un navigateur web.

L'installation va s'effectuer en plusieurs étapes. Tout d'abord, il faut installer la partie serveur qui va s'occuper de réunir toutes les alertes envoyées par les différents agents. Les sources sont disponibles sur http://la-samhna.de/samhain/.

Exemple d'installation avec le support d'une base de données MySQL :

./configure --enable-network=server --enable-xml-log --
with-database=mysql --prefix=/usr/local/yule
make
make install

Le serveur (se nommant yule) va ici être installé dans /usr/local/yule. Effectuons à présent l'installation du client :

./configure --prefix=/usr/local/samhain --enable-xml-log -
-enable-network=client \
--with-datafile=
REQ_FROM_SERVER/var/lib/samhain/samhain_file \
--with-config-file=REQ_FROM_SERVER/etc/samhainrc \
--with-logserver=server.yourdomain.com
make

La variable REQ_FROM_SERVER indique que ce fichier doit être récupéré du serveur.

Logserver spécifie l'adresse où se trouve le serveur regroupant toutes les alertes, c'est-à-dire l'adresse à laquelle le client samhain enverra les alertes.

Cette installation n'est toutefois pas terminée, puisqu'avant d'effectuer la dernière phase, il faut configurer le client pour qu'il puisse s'authentifier au niveau du serveur.

Générons une clé aléatoire sur le serveur :

yule -P $SHPW | sed s%HOSTNAME%client.yourdomain.com% >>
/etc/yulerc

Indiquons cette clé à notre client :

./samhain_setpwd samhain new $SHPW

Cette opération a pour but de créer un nouveau binaire se nommant samhain_new, qui nous permettra de nous connecter avec le serveur. Terminons l'installation avec ces lignes :

mv samhain.new samhain
make install && make install-boot
samhain -t init

La configuration par défaut offre un environnement de détection quasi opérationnel. Il suffit de modifier la variable ExportSeverity afin de spécifier le niveau de détection considéré comme « alerte ».

Dans le fichier /etc/samhainrc, modifiez ainsi :

[Log]
ExportSeverity=warn

Rkhunter est un détecteur de rootkits. Il permet de détecter la présence d'un rootkit dissimulé dans un binaire système. Il offre également la possibilité de scanner des fichiers de configuration afin de détecter la présence d'anomalies de configuration (utilisateur avec UID 0 : root), ou encore la présence de ports ouverts suspects (utilisés par certains rootkits).

L'installation de rkhunter se fait automatiquement. Récupérez les sources sur http://www.rootkit.nl/ puis décompressez l'archive. L'installation s'effectue à l'aide de l'assistant installer.sh.

Aucune configuration supplémentaire n'est à effectuer. Il suffit de lancer le binaire pour lancer un scan. Cette ligne de commande permettra d'effectuer un scan non interactif :

/usr/local/bin/rkhunter -c -sk

Voici un exemple de résultat :

Networking
* Check: frequently used backdoors
Port 2001: Scalper Rootkit [ OK ]
Port 2006: CB Rootkit [ OK ]
Port 2128: MRK [ OK ]
Port 14856: Optic Kit (Tux) [ OK ]
Port 47107: T0rn Rootkit [ OK ]
Port 60922: zaRwT.KiT [ OK ]
* Interfaces
Scanning for promiscuous interfaces [ OK ]
Security advisories
* Check: Groups and Accounts
Searching for /etc/passwd... [ Found ]
Checking users with UID '0' (root)... [ OK ]
* Check: SSH
Searching for sshd_config...
* Check: Events and Logging
Search for syslog configuration... [ OK ]
Checking for running syslog slave... [ OK ]
Checking for logging to remote system... [ OK (no remote
logging) ]
------------------ Scan results --------------------
MD5
MD5 compared: 0
Incorrect MD5 checksums: 0
File scan
Scanned files: 342
Possible infected files: 0
Application scan
Vulnerable applications: 0
Scanning took 62 seconds