Les systèmes d’information sont aujourd’hui de plus en plus ouverts sur Internet. Cette ouverture, a priori bénéfique, pose néanmoins un problème majeur : il en découle un nombre croissant d’attaques. La mise en place d’une politique de sécurité autour de ces systèmes est donc primordiale. Outre la mise en place de pare-feu et de systèmes d’authentification de plus en plus sécurisés, il est nécessaire, pour compléter cette politique de sécurité, d’avoir des outils de surveillance pour auditer le système d’information et détecter d’éventuelles intrusions. Ce que nous appelons intrusion signifie pénétration des systèmes d’information, mais aussi tentatives des utilisateurs locaux d’accéder à de plus hauts privilèges que ceux qui leur sont attribués, ou tentatives des administrateurs d’abuser de leurs privilèges. Au cours de ce document, nous verrons comment se protéger efficacement face à ces intrusions, mais aussi les problèmes techniques déduits de ces outils, nouvellement apparus dans le monde informatique. Mais avant cela, il est important, pour comprendre le rôle précis de ces systèmes, de faire un rappel des principales attaques existantes à l’heure actuelle.

II. Les différents types d’attaques

L’informatique étant un domaine très vaste, le nombre de vulnérabilités présentes sur un système peut donc être important. Ainsi, les attaques visant ces failles peuvent être à la fois très variées et très dangereuses. C’est pourquoi nous allons dans un premier temps analyser ce que nous appellerons « l’anatomie d’une attaque », puis dans un second temps, nous caractériserons ces attaques et observerons leur déroulement. Un nombre important de termes techniques vont être employés dans cette partie. Ceux-ci ne seront pas toujours détaillés, afin de ne pas surcharger la lecture ; mais une annexe comportant un rappel sur les notions fondamentales liées aux protocoles des réseaux (TCP, UDP et IP) est disponible à la fin de ce document.

II-A. Anatomie d’une attaque

Fréquemment appelés « les 5 P » dans la littérature, ces cinq verbes anglophones constituent le squelette de toute attaque informatique : Probe, Penetrate, Persist, Propagate, Paralyze. Observons le détail de chacune de ces étapes :

  • Probe : consiste en la collecte d’informations par le biais d’outils comme whois, Arin, DNS lookup. La collecte d’informations sur le système cible peut s’effectuer de plusieurs manières, par exemple un scan de ports grâce au programme Nmap pour déterminer la version des logiciels utilisés, ou encore un scan de vulnérabilités à l’aide du programme Nessus.

Pour les serveurs web, il existe un outil nommé Nikto qui permet de rechercher les failles connues ou les problèmes de sécurité. Des outils comme firewalk, hping ou SNMP Walk permettent quant à eux de découvrir la nature d’un réseau ;

  • Penetrate : utilisation des informations récoltées pour pénétrer un réseau. Des techniques comme le brute force ou les attaques par dictionnaires peuvent être utilisées pour outrepasser les protections par mot de passe. Une autre possibilité pour s’infiltrer dans un système est d’utiliser des failles applicatives que nous verrons ci-après ;
  • Persist : création d’un compte avec des droits de super utilisateur pour pouvoir se réinfiltrer ultérieurement. Une autre technique consiste à installer une application de contrôle à distance capable de résister à un reboot (ex. : un cheval de Troie) ;
  • Propagate : cette étape consiste à observer ce qui est accessible et disponible sur le réseau local ;
  • Paralyze : cette étape peut consister en plusieurs actions. Le pirate peut utiliser le serveur pour mener une attaque sur une autre machine, détruire des données ou encore endommager le système d’exploitation dans le but de planter le serveur.

Après ces cinq étapes, le pirate peut éventuellement tenter d’effacer ses traces, bien que cela ne soit rarement utile. En effet, les administrateurs réseau sont souvent surchargés de logs à analyser. De plus, il est très difficile de supprimer entièrement des traces.

II-B. Les attaques réseau

Ce type d’attaque se base principalement sur des failles liées aux protocoles ou à leur implémentation. Les RFC(1) ne sont parfois pas assez spécifiques, et un choix particulier d’implémentation dans les différents services ou clients peut entraîner un problème de sécurité. Observons quelques attaques bien connues.

II-B-1. Les techniques de scan

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.

II-B-2. IP Spoofing

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.

II-B-3. ARP Spoofing (ou ARP Redirect)

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.

II-B-4. DNS Spoofing

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.

II-B-5. Fragments attacks

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.

II-B-6. TCP Session Hijacking

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.

II-C. Les attaques applicatives

Les attaques applicatives se basent sur des failles dans les programmes utilisés, ou encore des erreurs de configuration. Toutefois, comme précédemment, il est possible de classifier ces attaques selon leur provenance.

II-C-1. Les problèmes de configuration

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.

II-C-2. Les bogues

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.

II-C-3. Les buffer overflows

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.

II-C-4. Les scripts

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.

II-C-5. Les injections SQL

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.

II-C-6. Man in the middle

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.

II-D. Le Déni de service

Évoqué précédemment, le déni de service est une attaque visant à rendre indisponible un service. Ceci peut s’effectuer de plusieurs manières : par le biais d’une surcharge réseau, rendant ainsi la machine totalement injoignable ; ou bien de manière applicative en crashant l’application à distance. L’utilisation d’un buffer overflow peut permettre de planter l’application à distance. Grâce à quelques instructions malicieuses et suite à une erreur de programmation, une personne mal intentionnée peut rendre indisponible un service (serveur web, serveur de messagerie…) voire un système complet. Voici quelques attaques réseau connues permettant de rendre indisponible un service :

  • SYN Flooding : exploite la connexion en trois phases de TCP (Three Way Handshake :

SYN/SYN-ACK/ACK). Le principe est de laisser un grand nombre de connexions TCP en attente. Le pirate envoie de nombreuses demandes de connexion (SYN), reçoit les SYN-ACK, mais ne répond jamais avec ACK. Les connexions en cours occupent des ressources mémoire, ce qui va entraîner une saturation et l’effondrement du système ;

  • UDP Flooding : le trafic UDP est prioritaire sur TCP. Le but est donc d’envoyer un grand nombre de paquets UDP, ce qui va occuper toute la bande passante et ainsi rendre indisponibles toutes les connexions TCP.

Exemple : faire une requête chargen (port 19/service de génération de caractères) à une machine en spoofant l’adresse et le port source, pour rediriger vers echo (port 7/service qui répète la chaîne de caractères reçue) d’une autre machine ;

  • Packet Fragment : utilise une mauvaise gestion de la défragmentation au niveau ICMP.

Exemple : ping of death. La quantité de données est supérieure à la taille maximum d’un paquet IP. Remarque : pour rappel, nous avons vu que les techniques d’attaque se basant sur la fragmentation des paquets peuvent aussi être utilisées pour outrepasser un filtre IP ;

  • Smurfling : le pirate fait des requêtes ICMP ECHO à des adresses de broadcast en spoofant l’adresse source (en indiquant l’adresse de la machine cible). Cette machine cible va recevoir un nombre énorme de réponses, car toutes les machines vont lui répondre, et ainsi utiliser toute sa bande passante ;
  • Déni de service distribué : le but est ici de reproduire une attaque normale à grande échelle. Pour ce faire, le pirate va tenter de se rendre maître d’un nombre important de machines. Grâce à des failles (buffer overflows, failles RPC(4)…) il va pouvoir prendre le contrôle de machines à distance et ainsi pouvoir les commander à sa guise.

Une fois ceci effectué, il ne reste plus qu’à donner l’ordre d’attaquer à toutes les machines en même temps, de manière à ce que l’attaque soit reproduite à des milliers d’exemplaires. Ainsi, une simple attaque comme un SYN Flooding pourra rendre une machine ou un réseau totalement inaccessible.

II-E. Actuellement

La sécurité contre les attaques distantes se renforce, notamment par le biais d’équipements réseau plus puissants (comme des firewalls plus intelligents), mais les attaques locales restent toutefois encore fort efficaces : l’ARP Spoofing, le vol de session… restent souvent possibles. L’informatique évolue, les applications sont de plus en plus complexes et les délais laissés aux programmeurs et administrateurs sont souvent très (trop) courts. Les risques de failles applicatives sont, de ce fait, très grands et peuvent s’avérer dangereux pour des applications largement répandues. Les attaques distribuées seront toujours redoutables si la plupart des machines personnelles ne sont pas protégées. Ce qui nous amène à notre seconde partie : comment détecter et empêcher ces attaques ?

III. Détection d’attaques : les IDS

Afin de détecter les attaques que peut subir un système, il est nécessaire d’avoir un logiciel spécialisé dont le rôle serait de surveiller les données qui transitent sur ce système, et qui serait capable de réagir si des données semblent suspectes. Plus communément appelés IDS (Intrusion Detection Systems), les systèmes de détection d’intrusions conviennent parfaitement pour réaliser cette tâche. À l’origine, les premiers systèmes de détection d’intrusions ont été initiés par l’armée américaine, puis par des entreprises. Plus tard, des projets open source ont été lancés et certains furent couronnés de succès, par exemple Snort et Prelude que nous détaillerons par après. Parmi les solutions commerciales, on retrouve les produits des entreprises spécialisées en sécurité informatique telles que Internet Security Systems, Symantec, Cisco Systems…

III-A. Les différents types d’IDS

Comme nous l’avons vu, les attaques utilisées par les pirates sont très variées. Certaines utilisent des failles réseau et d’autres des failles de programmation. Nous pouvons donc facilement comprendre que la détection d’intrusions doit se faire à plusieurs niveaux. Ainsi, il existe différents types d’IDS dont nous détaillons ci-dessous les caractéristiques principales.

III-A-1. Les systèmes de détection d’intrusions (IDS)

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

III-A-2. Les systèmes de détection d’intrusions « réseau » (NIDS)

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.

III-A-3. Les systèmes de détection d’intrusions de type hôte (HIDS)

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.

III-A-4. Les systèmes de détection d’intrusions « hybrides »

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.

III-A-5. Les systèmes de prévention d’intrusions (IPS)

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.

III-A-6. Les systèmes de prévention d’intrusions « kernel » (KIDS/KIPS)

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.

III-A-7. Les firewalls

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.

III-A-8. Les technologies complémentaires

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.

III-B. Les méthodes de détection

Pour bien gérer un système de détection d’intrusions, il est important de comprendre comment celui-ci fonctionne. Une question simple se pose alors : comment une intrusion est-elle détectée par un tel système ? Quel critère différencie un flux contenant une attaque d’un flux normal ? Ces questions nous ont amenés à étudier le fonctionnement interne d’un IDS. De là, nous en avons déduit deux techniques mises en place dans la détection d’attaques. La première consiste à détecter des signatures d’attaques connues dans les paquets circulant sur le réseau. La seconde, consiste quant à elle, à détecter une activité suspecte dans le comportement de l’utilisateur. Ces deux techniques, aussi différentes soient-elles, peuvent être combinées au sein d’un même système afin d’accroître la sécurité.

III-B-1. L’approche par scénario (misuse detection)

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.

III-B-2. L’approche comportementale (Anomaly Detection)

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.

III-B-3. Les méthodes répandues

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.

III-C. Principes généraux et installation technique

Jusqu’à présent, nous avons vu les types d’IDS existants et les méthodes de détection qu’ils utilisent. Nous allons maintenant détailler une étape importante dans la mise en place d’un IDS : l’installation technique. Lors de la mise en place d’un système de détection d’intrusions au sein d’un réseau, il est important de le déployer correctement d’une part, mais aussi de comprendre son fonctionnement interne pour pouvoir le configurer efficacement. Toute erreur lors de l’installation d’un IDS pourra le rendre inefficace ou inutilisable.

III-C-1. Déploiement d’un NIDS

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 :

Image non disponible
  • À 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.

Image non disponible

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.

III-C-2. Problèmes techniques

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.

III-C-3. Complémentarité des IDS

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.

III-D. Normalisation

Il y a quelques années, un comité du DARPA a défini quatre briques fonctionnelles pour décrire l’architecture globale d’un IDS :

  • générateur d’événements (boîte E) : envoie des événements à la boîte A ;
  • analyseur d’événements (boîte A) : produit des alertes ;
  • base de données événementielle (boîte D) ;
  • système de réponse (boîte R) : réponse en temps réel face aux attaques.

Ce comité a aussi défini un langage de description des intrusions (CISL – Common Intrusion Specification Language) qui utilise des expressions verbales (ex. : « ouvrir session », « effacer objet »…). Cependant, ce langage n’a jamais été utilisé, mais il a inspiré d’autres comités. L’IDWG (Intrusion Detection Working Group) a effectué la plupart des travaux dans le domaine de la standardisation des IDS : norme IDMEF (Intrusion Detection Message Exchange Format) : définit le format des messages échangés dans un IDS ; protocole IDXP (Intrusion Detection eXchange Protocol) : procédures de transport entre les entités de l’IDS. Selon l’IDWG, un IDS est ensemble de plusieurs senseurs, analyseurs et managers :

Image non disponible

C’est un schéma théorique, rarement implémenté de cette façon dans les IDS. La norme IDMEF préconise une représentation en XML des messages où dans chaque message, on retrouve l’ID de l’analyseur, le type d’alerte, l’emplacement (le nœud réseau), le jour et l’heure, l’adresse, la classification de l’attaque…

III-E. Techniques antiIDS

Comme tout système informatique, ou presque, il existe des failles dans les IDS, ou plutôt des techniques qui permettent d’outrepasser ces systèmes sans se faire repérer. Si un pirate détecte la présence d’un IDS, il peut le désactiver, ou mieux encore, générer de fausses attaques pendant qu’il commettra son forfait tranquillement. Il existe trois catégories d’attaques contre les IDS :

  • attaque par déni de service : rendre l’IDS inopérant en le saturant ;
  • attaque par insertion : le pirate, pour éviter d’être repéré, injecte des paquets de leurres qui seront ignorés par le système d’exploitation de la cible, mais pris en compte par l’IDS : l’IDS ne détecte rien d’anormal, alors que sur le système cible, l’attaque a bien lieu puisque les paquets superflus sont ignorés ;
  • attaque par évasion : il s’agit de la technique inverse à l’attaque par insertion. Ici, des données superflues sont ignorées par l’IDS, mais prises en compte par le système d’exploitation. Nous détaillons un peu plus loin quelques techniques d’évasion Web.

III-E-1. Détecter un IDS

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.

III-E-2. Déni de services contre 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.

III-E-3. Techniques d’insertion

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.

III-E-4. Techniques d’évasion

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