Langage déclaratif pour la détection d’intrusions
Mémoire
Papa Maleye Niang
Maîtrise en informatique avec mémoire
Maître ès sciences (M.Sc.)
Québec, Canada
Résumé
Ce mémoire présente un langage déclaratif de description de scénarios et de modèles d’at-taques, ainsi qu’un moteur de détection qui lui est associé. Le langage s’inspire fortement de l’état de l’art dans le domaine des IDS (système de détection d’intrusions) et il s’approprie les qualités de plusieurs de ses références telles que LTL, Snort, Lambda, ou Chronicle. Il représente aussi une évolution majeure de la première version introduite dans un précédent travail [46], dans le sens où nous avons introduit de nouveaux opérateurs, nous avons associé une sémantique formelle au langage, ainsi qu’un système de règles de réécriture permettant le calcul d’une forme normale ; nous offrons aussi la possibilité de définir des modèles d’attaques. Les modèles étant différents des scénarios, le comportement du moteur de détection a été enrichi, augmentant l’expressivité du langage par rapport à sa version initiale.
Table des matières
Résumé iii
Table des matières iv
Liste des tableaux vii
Liste des figures ix
Introduction 1
I Anatomie d’un système de détection d’intrusions 5
1 Fonctionnement d’un NIDS 7
1.1 Composants d’un NIDS . . . 7
1.2 Familles d’IDS . . . 24
1.3 Exemples . . . 26
1.4 Conclusion . . . 32
2 Langages de description 35 2.1 Méthodes formelles. . . 36
2.2 Introduction aux logiques temporelles . . . 40
2.3 Exemples de langage de description . . . 47
2.4 Conclusion . . . 59
II Nouveau langage pour les NIDS 61 3 Langage de description de scénarios 63 3.1 Détection de scénarios . . . 64 3.2 Détection d’anomalies . . . 116 3.3 Conclusion . . . 124 4 Implantation 127 4.1 Architecture . . . 128 4.2 Fonctionnement du prototype . . . 132 Conclusion 135
Liste des tableaux
2.1 Syntaxe de la logique propositionnelle. . . 41
2.2 Table de vérité. . . 41
2.3 Syntaxe simplifiée de la logique propositionnelle. . . 41
2.4 Syntaxe de LTL. . . 42 2.5 Sémantique de LTL. . . 43 2.6 Syntaxe de CTL. . . 44 2.7 Sémantique de CTL. . . 45 2.8 Syntaxe de CTL*. . . 45 2.9 Sémantique de CTL*. . . 46 2.10 Syntaxe de Chronicles.. . . 54
2.11 Duplication d’une instance de modèle Chronicle. . . 56
2.12 Table comparatif des langages présentés. . . 58
3.1 Syntaxe du langage AFI.. . . 65
3.2 Complément de la syntaxe. . . 73
3.3 Syntaxe formelle. . . 78
3.4 Sémantique formelle. . . 82
3.5 Complément de la sémantique formelle. . . 85
3.6 Sémantique de l’opérateur ⊕. . . 90
3.7 Règles annexes de normalisation. . . 95
3.8 Règles de propagation de l’opérateur «.». . . 100
3.9 Règles de concaténation de l’opérateur «.». . . 101
3.10 Trace de l’algorithme de détection. . . 109
3.11 Trace de l’algorithme de détection lors de l’usage de l’option nc.. . . 110
3.12 Trace de l’algorithme de détection lors du traitement d’une disjonction. . . 111
3.13 Trace de l’algorithme de détection lors du traitement d’une disjonction avec l’option nc.. . . 112
3.14 Syntaxe formelle. . . 113
3.15 Sémantique formelle. . . 114
3.16 Ajout du mot clé model à la syntaxe du langage. . . 116
Liste des figures
1.1 Réseau avec sonde incluse dans une machine. . . 9
1.2 Réseau avec sonde incluse dans le switch. . . 10
1.3 Module d’analyse. . . 13
1.4 Système de détection d’intrusions dans son ensemble. . . 23
1.5 Arbre de classification.. . . 27
1.6 Organisation des règles de Snort. . . 29
1.7 Exemple de règle Snort. . . 30
1.8 Prelude, un exemple de corrélation d’alarmes. . . 32
2.1 Diagramme de transitions. . . 42
2.2 Arbre de computation.. . . 43
2.3 Règle basique définie avec Snort.. . . 48
2.4 Règle Snort et blocage d’une page. . . 49
2.5 Modèle de description d’une attaque avec Lambda. . . 49
2.6 Attaque NFS abuse. . . 53
2.7 Description de l’attaque NFS abuse avec Lambda. . . 53
2.8 Exemple de règle Chronicle. . . 55
2.9 Second exemple de règle Chronicle. . . 55
3.1 Scénario vide. . . 69
3.2 Scénario de connexion TCP - définition des événements. . . 70
3.3 Liaison entre les événements. . . 70
3.4 Paramètres de scénario. . . 71
3.5 Attaque web-application (version Snort). . . 71
3.6 Attaque web-application (version AFI). . . 72
3.7 Définition des types d’une trace contenant des courriels. . . 76
3.8 Scénario ARP poisoning. . . 76
3.9 Justification de la normalisation. . . 79
3.10 Justification de la normalisation. . . 82
3.11 Vue d’ensemble du processus de normalisation. . . 99
3.12 Diagramme du protocole TCP.. . . 119
3.13 Modèle décrivant le protocole TCP. . . 120
4.1 Architecture du NIDS.. . . 129
Je dédie ce mémoire à mes parents.
Introduction
Il n’est plus à démontrer que l’outil informatique occupe une place de choix dans nos vies, nos industries et nos infrastructures. Le domaine de la communication en est un exemple perti-nent. La numérisation des moyens de communication a permis de faciliter les liaisons longues distances et le partage de l’information. Elle a aussi permis d’en faire profiter un plus large éventail d’acteurs. En reliant plusieurs ordinateurs et périphériques entre eux, grâce à des ré-seaux et à Internet, de nouveaux horizons se sont ouverts à la notion même de communication : partager de l’information, la diffuser etc. À tous les niveaux de la communication s’ouvrent de nouvelles manières de faire et de nouveaux besoins. Cette nouvelle voie qui donne sur ce monde d’information dispose elle aussi de besoins et de défis qui lui sont inhérents.
En effet, le réseau étant un ensemble hétérogène d’équipements reliés entre eux pour échan-ger de l’information, il faut s’assurer d’harmoniser le dialogue entre ces dits éléments. Ceci est la raison d’être des protocoles réseau. Un protocole réseau est un ensemble de règles de communication auxquelles tous les éléments d’un réseau se soumettent pour s’assurer de la bonne transmission de leurs données ; il est évident que sans cette réglementation, personne n’entendrait ni n’écouterait personne. Des protocoles, il en existe plusieurs, chacun étant as-socié à une couche du modèle OSI [40]. À titre d’exemple, on peut citer les protocoles SMTP et Ethernet : le premier, étant utilisé pour le transfert des courriers électroniques, appartient à la couche cinq du modèle OSI, alors que le second appartient à la couche liaison (couche deux) et est utilisé pour le transfert des paquets de données dont il normalise entre autres le format. Ces protocoles apportent des standards qui masquent l’hétérogénéité des équipements qui communiquent.
Un autre besoin inhérent à cette connexion des ordinateurs et au partage de l’information est le contrôle de l’accès aux données. Il est fort probable que quelqu’un, pour diverses raisons, ex-prime le souhait de ne partager certaines données qu’avec un nombre restreint de personnes. Cette volonté de protéger l’accès à une information souligne le besoin de sécuriser les don-nées, et les transmissions ; un domaine large et varié dont une des tentacules est la détection d’intrusions.
comportements suspects ou nuisibles. Cette première définition de la notion d’IDS (Intrusion Detection System) se base sur le rôle que joue cet outil. L’information circule sous forme de pa-quets à l’intérieur d’un réseau. Afin de s’assurer de l’absence de toutes menaces, chaque paquet est inspecté. Cette vérification se fait en comparant le contenu du paquet à la signature du comportement que l’on souhaite identifier. Il est à noter qu’en fonction de la configuration du réseau, les paquets peuvent provenir aussi bien de machines appartenant au réseau (intranet), que de sources externes au réseau (extranet, Internet).
Bien qu’ayant un principe de fonctionnement très simple, le domaine de la détection d’in-trusions ne cesse d’accroître le nombre de défis qu’il soumet à sa communauté scientifique. Beaucoup de questions sont pour le moment sans réponse complète et précise ; de plus les nouvelles avancées imposent d’adapter régulièrement les solutions. Les progrès techniques per-mettent d’atteindre des vitesses de connexion de l’ordre du gigabits à la seconde, grâce à la fibre optique et au Wimax. Avec une telle vitesse de transmission, il est impératif que nos algorithmes de recherche de traces soient performants et que l’architecture du système NIDS soit adéquate, si l’on souhaite surveiller tous les paquets et performer dans l’analyse de toute cette masse de données.
De nombreuses menaces non identifiées exploitent le plus souvent des failles système non découvertes et aucune solution n’offre pour le moment une assurance totale contre ce type d’attaque. De plus, elles sont généralement opérées de manière silencieuse et avec beaucoup de précautions pour ne laisser aucune trace. Les mêmes remarques s’imposent pour le problème de l’identification des variantes de comportements d’attaques. En effet, il n’est pas réaliste de proposer une nouvelle signature à chaque nouvelle variante de comportement identifiée. Une solution générique, capable de reconnaître les variantes comme appartenant à une même famille de comportements, semble plus probable de répondre à cette question. Quelle stratégie devrons nous utiliser pour répertorier les comportements à risques ? Pouvons-nous tous les identifier ? Avec quel outil est-il adéquat de les représenter ? Les comportements à identifier étant nombreux et variés, il est primordial de disposer d’un langage simple et suffisamment expressif pour couvrir l’ensemble de nos besoins.
Même si elle peut paraître triviale, la réponse que doit fournir l’IDS devant une tentative d’in-trusion mérite réflexion. Le plus souvent, une attaque s’exécute dans une fenêtre de temps de l’ordre de quelques secondes. Un délai trop court pour permettre toute intervention humaine, imposant de facto une réaction défensive automatisée de la part de l’IDS. Il existe dans la littérature des pistes de solutions déjà énoncées, mais sont-elles efficaces ?
Enfin, il est utile, vu les progrès techniques actuels, de s’interroger sur notre capacité réelle à analyser la totalité des paquets qui circulent dans nos réseaux et à déterminer leur provenance. Cette traçabilité de l’information est un facteur à prendre en considération dans la lutte contre certaines menaces sophistiquées basées sur l’usurpation d’identité. Cela permet aussi
de disposer de preuves numériques utiles dans le cadre d’une investigation numérique légale (computer forensics) [5] pour prouver une attaque subie.
En résumé, la détection d’intrusions propose des défis, tant du point de vue du langage de spécification des signatures des comportements à identifier, qu’en matière de performance du système et des mesures prises pour réagir devant la menace. Ce constat est à imputer à la jeunesse du domaine et à l’évolution technologique constante dont il subit, bon gré mal gré, les effets. Les systèmes de détection d’intrusions offrent de grands défis pour tous les passionnés de la question ; il demeure aussi un élément de réponse certain devant une menace informatique organisée, véloce et très actuelle. Cette menace s’illustre avec plusieurs hauts faits relatés par les médias : 2010 a vu déferler la vague Wikileaks [48] avec ses milliers de documents classés confidentiels, publiés sur la toile. Plus récemment, l’affaire Snowden [49] nous apprend, entre autres, que la NSA (Agence Nationale de la Sécurité) collecte des données privées des utilisateurs Google et Yahoo !. Ces événements pointent du doigt l’efficacité imparfaite de nos moyens de protection contre les tentatives d’intrusions et accentuent un peu plus la nécessité de proposer des solutions efficaces et réalistes. On tire la même conclusion en ce qui concerne les attaques du ver informatique stuxnet [7] dirigées contre l’Iran et ses centrales nucléaires. Il faut aussi craindre l’apparition de mouvements hacktivistes qui se voient encouragés par le succès de Wikileaks, augmentant du coup le nombre d’attaquants potentiels ; ces mouvements pouvant être très organisés et puissants comme l’a montré le groupe des Anonymous. Ces faits justifient encore une fois l’urgence de la situation, l’ampleur de la menace et le rôle que les IDS sont appelés à jouer en tant qu’élément de l’arsenal mis à disposition des administrateurs réseau en charge de la sécurité.
Objectifs et méthodologie Pour ce travail, notre objectif est de proposer un langage dé-claratif de détection d’intrusions adapté au contexte des réseaux et un prototype d’IDS qui l’exploite. Ce langage est une extension, axée réseau, d’un précédent travail de recherche [46] initié en partenariat avec l’Université Laval, l’Université polytechnique de Montréal, l’Univer-sité Concordia et certains partenaires industriels.
Pour ce faire, nous analysons les composants des systèmes de détection d’intrusions afin de montrer leurs relations et leurs influences dans la classification des IDS. Connaître cet aspect nous permet de mieux catégoriser notre prototype, d’identifier les propriétés que devra sup-porter le langage et les types de données à traiter. Certaines fonctionnalités du langage étant issues des logiques temporelles, nous présentons une introduction des langages utilisés pour la détection d’intrusion en mettant l’accent sur les méthodes formelles. Enfin, les critiques et réflexions soulevées lors de la présentation du langage vont motiver une liste de fonctionnalités à ajouter au langage.
litté-rature. Le chapitre1 sera l’occasion de décrire le fonctionnement des systèmes de détection d’intrusions. Il présente une description de l’anatomie des systèmes de détection d’intrusions en mettant l’accent sur le fonctionnement de leurs composants et leurs interactions. Puis les diverses familles d’IDS et leurs critères de classification sont présentés suivis de deux exemples pour les illustrer.
Le chapitre2montre la place qu’occupe le langage de description dans la structure des IDS. Il présente les arguments qui justifient l’usage des méthodes formelles dans les IDS et se base sur les logiques temporelles pour détailler le concept. Le chapitre se clôture avec la présentation de trois langages de description utilisés par des IDS.
La seconde partie de ce mémoire présente le langage de description de scénarios et se compose de deux chapitres.
Le chapitre3 offre une vision détaillée du langage en décrivant sa syntaxe et sa sémantique. L’accent est aussi mis sur la description de la sémantique formelle associée au langage, ainsi qu’un système de règles de réécriture permettant le calcul d’une forme normale. De plus, le chapitre aborde les améliorations susceptibles d’accroître la performance du langage.
Enfin, le chapitre4présente l’implantation de notre prototype. Il revient sur l’architecture du projet et son fonctionnement.
Première partie
Anatomie d’un système de détection
d’intrusions
Chapitre 1
Fonctionnement d’un NIDS
1.1
Composants d’un NIDS
Un IDS, pour système de détection d’intrusions (Intrusion Detection system), est un ensemble de mécanismes qui a pour fonction d’identifier ou de prévenir des comportements jugés nui-sibles pour un environnement donné. Souvent utilisé pour protéger un réseau informatique, il porte le nom de Network Intrusion Detection System (NIDS) et sert à prévenir les tenta-tives d’attaques et d’assurer le respect de la politique de sécurité du réseau. On parle de Host Intrusion Detection System (HIDS) si l’on cherche à surveiller l’activité des processus d’une machine. Afin d’alléger la présentation du concept, nous traiterons principalement le cas des NIDS.
Pour mener à bien sa mission, le NIDS dispose de quatre composants : le senseur (sensor, probe, sniffer), le moniteur (monitor), le résolveur (resolver) et le contrôleur (controller). Ces composants travaillent de concert afin d’analyser toutes les données qui circulent au sein du réseau ; chacun d’eux jouant un rôle spécifique afin que l’ensemble forme un tout fonctionnel. On utilise le terme sniffer un réseau pour designer le fait d’écouter et de collecter les paquets qui circulent dans un réseau. Pour ce faire, on place dans le réseau un équipement dédié à cette tâche et qui porte le nom de sonde, senseur ou sniffer. Un sniffer de manière générique désigne notre outil de collecte de données qui peut aussi bien être une carte réseau en mode promiscuité, qu’un autre équipement réseau tel un hub, un switch ou tout autre équipement dédié.
Le senseur a pour tâche de collecter les traces provenant du réseau à surveiller. Cette collecte peut se faire entre autres depuis le réseau, ou depuis un fichier PCAP [41]. Puis, l’information collectée est transmise au moniteur qui est le composant principal du système de détection d’intrusions. Ce dernier analyse la trace provenant de la sonde à la recherche de modèles ou
de comportements suspects. Notez qu’il existe plusieurs stratégies pour détecter ces compor-tements. Une fois qu’un comportement suspect est détecté, le moniteur peut mettre à jour sa base de faits et alerter le résolveur. En cas d’attaque, l’information doit être transmise le plus rapidement et de manière précise à l’administrateur du système. Aussi il est important de réagir face à la menace en prenant des mesures adéquates. Ce rôle est pris en charge par le résolveur afin d’appuyer l’administrateur dans cette tâche, qui se charge de signaler l’alerte et de prendre des mesures préventives telles que fermer un port ouvert. Enfin, le contrôleur joue un rôle d’interface pour configurer et gérer les composants du système de détection d’intrusions déployé. Nous détaillons chacun de ces composants dans les sections suivantes. Remarquez que les composants d’un NIDS peuvent être aussi bien disloqués que monolithiques.
1.1.1 Module Senseur
Prenons un exemple trivial : une personne souhaite copier une donnée dans une machine A. Elle ne dispose que de deux moyens pour y arriver : se rendre physiquement devant la machine A et effectuer l’opération, ou bien accéder à distance à la machine A pour effectuer l’opération. Avec le second cas, en surveillant les données échangées à l’aide d’une sonde, on souhaite s’as-surer que l’opération s’est bien déroulée. Ainsi la sonde est le point de départ du processus de détection d’intrusions. Elle joue un rôle important en récupérant pour le système de détection d’intrusions l’information qui circule au sein du réseau. Afin d’identifier les comportements suspects, le système de détection d’intrusions analyse les échanges au sein de la zone à sur-veiller et ce qui l’entoure. Par exemple, pour un NIDS la zone à sursur-veiller peut être le réseau local d’une entreprise et toute autre connexion externe à ce réseau serait l’environnement qui l’entoure. Tous les paquets qui transitent entre ces deux zones sont potentiellement nuisibles et il incombe au système de détection d’intrusions de vérifier si la menace est réelle ou non. Dans un réseau, le flux d’information circule sous la forme de paquets réseau. Chaque paquet est forgé selon le respect des protocoles du modèle OSI. Le plus souvent, un paquet encapsule l’information qu’il véhicule sous une pile de protocoles [40] afin de respecter les normes et permettre la communication entre plusieurs systèmes différents. Comme c’est le cas avec le protocole HTTPS, parfois l’information véhiculée est cryptée, rendant difficile son accès et son interprétation par l’IDS. Pour finir, comme il existe une grande variété de protocoles, en fonction du rôle du paquet, de sa pile de protocoles ou d’un autre facteur, les paquets diffèrent de par leurs structures.
Afin de détecter une attaque, nous devons identifier sa signature. Pour ce faire, il est nécessaire de collecter les paquets qui transitent dans le réseau et d’analyser leurs contenus. Toute attaque exécutée à distance et ciblant un des éléments du réseau devra circuler sous forme de paquets à travers le réseau. Afin de la détecter, tous les paquets doivent être récupérés et transmis au module d’analyse de menaces du système de détection d’intrusions. Pour le NIDS, c’est la seule
source d’information pour identifier les attaques. En effet, il n’y a que via le réseau que les composants du réseau peuvent échanger de l’information. Ainsi, on peut se demander si cette information est suffisante. Le plus souvent, il est très important de disposer d’une information précise sur les équipements qui composent le réseau afin de mieux corréler et interpréter les paquets réseau récupérés par la sonde. De plus, les systèmes pouvant être mis à jour et de nouveaux équipements ajoutés ou retirés du réseau, il est nécessaire de tenir à jour le descriptif des informations en rapport avec la composition du réseau.
Par contre, la position qu’occupe la sonde dans l’architecture du réseau est déterminante vis-à-vis de la qualité et de la quantité de données qu’elle reçoit. En fonction de l’architecture du réseau, il faudra la placer à un carrefour où passent toutes les communications. Souvent, cela n’est pas possible. Alors on place plusieurs sondes à plusieurs points stratégiques du réseau. Ainsi combinées, on arrive à surveiller tous les paquets qui circulent dans le réseau. Les figures 1.1et1.2 montrent quelques exemples de position de la sonde au sein de diverses configurations réseau. Sonde Pare-feu Switch Ordinateur Ordinateur Internet
Figure 1.1: Réseau avec sonde incluse dans une machine.
La figure1.1présente un NIDS local où la sonde est installée dans une des machines du réseau. En mettant la carte réseau de cette machine en mode promiscuité (promiscuous mode), on arrive à récupérer toutes les communications qui passent en broadcast dans le réseau et les paquets destinés à la machine hôte. Ceci ne garantit pas de recevoir tous les paquets qui
cir-Switch + Sonde Pare-feu Ordinateur Ordinateur Internet Ordinateur
Figure 1.2: Réseau avec sonde incluse dans le switch.
culent dans le réseau. En effet, les communications en broadcast ne se font qu’avec l’utilisation d’un concentrateur (hub) pour connecter les machines entre elles. Par contre, avec l’utilisation d’un commutateur réseau (switch), elles se limitent à certains protocoles de la couche liaison du modèle OSI tel que le protocole ARP, et aux paquets forgés pour être transmis en mode broadcast. Cette configuration n’est utile que dans le cas où l’on souhaite surveiller en par-ticulier les communications adressées à la machine hôte. Ceci peut être considéré comme un désavantage, cependant en intégrant la sonde comme élément du système à surveiller, on dis-pose d’une qualité d’information plus précise. La présence de la sonde au sein d’une machine hôte permet d’accéder à une information plus précise en offrant un accès direct aux données encapsulées par la pile de protocoles. Une fois un paquet reçu par l’hôte, ce dernier enlève une à une les couches de protocoles. Ce processus va nous permettre d’accéder aux informations qui étaient cryptées par un des protocoles. Aussi, on connaît la nature de l’équipement à protéger ce qui permet de mieux identifier les menaces pour lesquelles il est vulnérable. Par exemple, l’exploitation d’une faille connue pour les serveurs Apache [18] ne marchera pas forcément sur un serveur IIS [27].
Dans la figure 1.2, le senseur (sniffer) installé utilise une ou plusieurs sondes pour capturer l’ensemble des paquets qui circulent dans le réseau. Dans cet exemple, la sonde devient un équipement indépendant du réseau qui surveille les paquets qui passent par elle et les com-munique au module de détection de l’IDS. Cependant, il faudra souligner quelques critiques : premièrement, il faut remarquer que la présence de certains protocoles cryptés peut rendre difficilement accessible le contenu des paquets concernés. De plus, on perd en précision, car on ne connaît pas exactement la nature des composants et des systèmes appartenant au réseau.
Enfin, vu que la sonde du NIDS n’est pas placée dans une machine hôte, elle récupère les paquets destinés à divers équipements du réseau et ceci au niveau des couches de bas niveau du modèle OSI, comme la couche de liaison [40] par exemple, rendant du coup l’information collectée moins précise.
Comme présenté dans le précédent paragraphe, nous disposons de deux moyens pour collecter l’information qui circule au sein du réseau. La première consiste à mettre en mode promiscuité la carte réseau d’une des machines du réseau. La seconde consiste à ajouter un équipement dédié à la capture des paquets qui circulent, puis de placer ce dernier à un endroit stratégique où passe l’ensemble des données. Une fois les paquets récupérés, le module senseur utilise dif-férentes stratégies afin de les transmettre au module d’analyse pour qu’il effectue sa tâche de détection. Si le NIDS est configuré pour analyser en temps réel les menaces, alors le module senseur aura pour rôle, dès la réception d’un paquet de le communiquer immédiatement au module de détection. Cette manière de faire implique une fréquence élevée de transfert d’infor-mation depuis le senseur vers le module d’analyse. De ce fait, il faudra s’assurer que l’analyse des paquets puisse se faire rapidement pour éviter l’accumulation de paquets non traités au niveau du module d’analyse. Par contre, si le NIDS n’est pas configuré pour détecter les me-naces en temps réel alors le senseur adopte une stratégie de traitement par lot. Il récupère plusieurs paquets et attend un moment précis avant de transmettre au module d’analyse l’in-formation qu’il a collectée. Par exemple, l’envoi de cette inl’in-formation peut se faire chaque soir à un horaire où le NIDS dispose des ressources nécessaires pour traiter l’information. Elle peut aussi se faire chaque fois que le nombre de paquets collectés atteint un certain seuil ou simplement sur demande du module d’analyse. Le choix de la stratégie à adopter est inhérent à la défense souhaitée. En effet, dans une logique de prévention des menaces, un traitement en temps réel est privilégié alors que dans le cas d’un audit ou d’une vérification journalière, la stratégie de traitement par lot est privilégiée. Par exemple, une banque peut décider, à cause du grand nombre de données qu’elle reçoit par jour et pour éviter de ralentir le traitement des transactions, d’effectuer à chaque fermeture de la banque une analyse de toutes les données collectées par le module senseur de son IDS. Cette manière de faire permettra de vérifier si elle a subi des attaques durant la journée et le cas échéant de prendre des mesures avant la prochaine ouverture. On désigne parfois par le terme heartbeat l’envoi de données à analyser, par le senseur vers le module d’analyse.
Parfois, l’information collectée peut nécessiter un traitement avant d’être envoyée au module d’analyse. Le cas le plus fréquent consiste, quand l’information collectée provient de plusieurs sources différentes, à trier les paquets collectés en fonction de la date de réception. Cette opération permet de proposer un flux unique et homogène d’information au module d’analyse. Cette solution s’applique quand le système de détection d’intrusions surveille plusieurs réseaux différents et que l’analyse de toute l’information collectée est centralisée. En plus de cela, on peut traiter les paquets reçus pour qu’ils respectent un certain format. Tel est le cas avec
l’IDS Prelude [10] qui, vu qu’il collecte de l’information aussi bien au niveau des paquets réseaux que des fichiers logs et des informations sur les systèmes, encapsule toutes les données sous le format IDMEF [12]. Cela lui permet d’uniformiser l’information envoyée au système d’analyse et de masquer les différences sur la structure des données communiquées au système d’analyse. Ainsi, au lieu de recevoir des paquets de données, des commandes systèmes et toute autre information collectée, le système d’analyse de Prelude reçoit une série de données sous le format IDMEF, et ce format encapsule les données réelles collectées par chaque senseur.
1.1.2 Module d’analyse
Le senseur communique les données qu’il collecte au module d’analyse afin que la détection d’intrusions se fasse. Le module d’analyse occupe une place centrale dans l’architecture d’un système de détection d’intrusions. C’est lui qui effectue les processus permettant d’identifier les menaces. Afin de mener cette tâche à bien, le module d’analyse doit assumer trois préalables intimement liés : identifier puis décrire les menaces, disposer d’un mécanisme de détection et élaborer une stratégie d’alerte.
Avant de chercher à détecter la présence d’une menace, d’un comportement suspect, ou juste de s’assurer du respect d’une politique, il faut décrire les signes qui nous permettent d’aboutir à l’une de ces conclusions. Identifier et décrire les menaces sont des étapes importantes pour la détection d’intrusions.
Il existe deux approches ou stratégies majeures pour identifier les intrusions : la détection à base de signatures et la détection à base d’anomalies [13]. Ces approches désignent ce que le système de détection d’intrusions cherche à identifier en surveillant le flux de données. De manière intuitive, la première approche propose de décrire à quoi ressemble un comportement suspect ; ainsi, tous les éléments de la trace collectée qui concordent avec la description sont marqués comme suspects. Par exemple, un paquet qui contient la signature d’un virus devrait être identifié et signalé au système. Quant à la seconde approche, elle propose d’identifier le bon modèle de comportement afin de juger suspecte toute activité qui s’en écarte selon un certain degré. Par exemple, pour un bureau ; on peut considérer comme suspect le fait d’avoir une machine qui envoie des données sur le réseau durant les heures de fermeture.
Détection à base de signatures La détection à base de signatures préconise de disposer d’une base de données des modèles d’attaques connues. Cette base de signatures sert de ré-férence pour analyser la trace collectée et rechercher toute correspondance avec une attaque. Il est évident qu’avec cette méthode, une menace dont nous ne disposons pas la signature ne pourra être détectée. En étudiant les attaques subies, on peut trouver la signature des menaces. C’est actuellement la méthode adoptée par les antivirus. Une fois la signature obtenue, elle
Scénario Scénario Instances de Scénario BD de scénarios Trace à analyser
Demander une alarme si une instance
est complétée Processus : vérifier si la trace
correspond à un scénario
Résultat Non
Oui
Mettre à jour instances
Passer au paquet suivant
Figure 1.3: Module d’analyse.
est utilisée pour identifier la menace dans les traces collectées. Cette signature est un élément distinctif de l’attaque comme un bout de code, un début de requête, etc.
Il est probable que toute la signature de la menace se trouve encapsulée dans un seul paquet réseau et l’analyse de ce paquet suspect permettra avec une forte probabilité d’identifier la présence de la menace. Il est aussi possible que la signature se trouve dans plusieurs éléments de la trace. Ces derniers vont se retrouver éparpillés dans plusieurs paquets de la trace collectée. Dans ce cas, il faudra trouver chacun des éléments composant la signature afin de pouvoir déclarer la présence de la menace. Par exemple, pour trouver les services actifs dans un serveur, un pirate envoie plusieurs demandes de connexion vers le serveur cible avec des adresses de ports différentes, puis abandonne la suite de la requête dès qu’il obtient une réponse du serveur. La présence de plusieurs paquets de ce type dans une fenêtre de temps imparti permet d’identifier une tentative de scan des services du serveur. On désigne par scénario, ce type de signatures qui d’une certaine manière décrivent le comportement d’une menace se déroulant sur un ou plusieurs paquets.
Souvent, la variante d’une menace ne possède pas la même signature. Afin de déjouer la sécurité apportée par le système de détection d’intrusions, les attaquants utilisent des méthodes pour modifier la forme de leurs attaques déjà répertoriées par le système. Par exemple, en fragmentant une attaque sur plusieurs paquets, en changeant l’ordre des requêtes, en lançant leurs attaques depuis plusieurs sources différentes, en cryptant et en modifiant l’encodage du contenu des paquets, le pirate arrive à modifier les signatures de ses attaques. Le nombre de variantes d’une attaque pouvant être nombreux, trouver la signature de chaque nouvelle variante n’est pas une solution viable. Ceci est le principal reproche fait envers la stratégie de détection à base de signatures. Une des pistes de solutions les plus privilégiées serait de disposer d’une règle qui puisse s’adapter à un grand nombre de variantes d’une même attaque. On peut aussi traiter les traces collectées afin de masquer, sinon réduire les différences apportées par la variante. Par exemple, dans le cas d’une fragmentation des paquets réseau, on peut regrouper les fragments afin d’envoyer au module d’analyse des paquets non fragmentés qui contiennent l’ensemble de l’information. Toutefois, le fait de disposer de la signature d’une menace nous permet de l’identifier avec une grande précision, réduisant par la même occasion le taux de fausses alertes (faux positifs). Ce dernier critère sert aussi d’indicateur pour mesurer l’efficacité du système.
Remarque : Avec la signature d’une attaque, on peut définir une règle ou un scénario pour identifier la menace. L’application d’une règle se borne au contenu d’un paquet de la trace collectée. Par contre, l’application d’un scénario peut se faire sur un ou plusieurs paquets. On constate ainsi que la différence majeure entre ces deux termes réside fondamentalement sur l’étendue de leurs rayons d’action.
Détection par anomalies Avec la détection à base d’anomalies, l’approche est différente. Elle consiste à signaler tout écart significatif par rapport au comportement ou à l’utilisation normale pris comme référents. Le NIDS est soumis à un apprentissage afin de le conditionner à reconnaître les échantillons fournis comme étant le comportement normal et à les prendre comme référents. Par exemple, on fournit comme échantillon les traces collectées sur le réseau d’une banque durant une période donnée. Cette source sera prise comme référentiel et devra refléter l’activité normale du réseau de la banque. Ainsi, une fois le système de détection mis en place sur ce réseau, toutes les données collectées seront analysées en fonction des échantillons de référence et tout écart significatif sera signalé comme suspect. Cette manière de faire se retrouve dans le domaine de la météo où l’on compare souvent les changements climatiques à ceux des années passées durant la même période afin de savoir si l’on est dans les normales saisonnières ou pas. Ce comparatif avec un référentiel permet de juger si la situation actuelle est normale ou pas. Bien entendu, les comparaisons faites tolèrent l’existence d’écart jusqu’à un certain seuil.
La faiblesse majeure de cette manière de faire est qu’elle peut signaler comme une menace, toute action même bénigne qui s’écarte du modèle de référence ; ce qui lui confère un taux de faux positifs très élevé. En effet, plusieurs facteurs peuvent altérer le diagnostic du sys-tème. Avec l’exemple précédent d’un NIDS qui surveille le réseau d’une banque, l’ajout d’un nouveau périphérique, des changements par rapport aux activités quotidiennes de la banque ou même la mise en place de nouvelles mesures de protection peuvent altérer le diagnostic du système d’analyse. La détection par anomalies est très sensible à toute modification dans l’environnement à protéger. Afin de garder raisonnable le taux de faux positifs, le système est soumis régulièrement à un apprentissage du comportement normal dans le but de l’adapter aux éventuelles évolutions de ce dernier. Le taux de faux positifs élevé de cette approche est compensé par sa capacité à détecter des scénarios d’attaques non connues.
De plus, la place qu’occupe le conditionnement du NIDS avec cette approche peut être vu comme une faiblesse. Pour que le système soit efficace, on est supposé lui fournir des traces d’une utilisation normale du système à protéger. Dans le cas d’un NIDS, il s’agit de trace réseau collectée durant une utilisation normale du réseau et des ressources qui la composent. Cepen-dant, il n’est pas exclu que ces échantillons soient contaminés, c’est-à-dire qu’ils contiennent une attaque non répertoriée. Le cas échéant, le NIDS va considérer cette menace comme un comportement normal, la rendant invisible. Aussi les échantillons se doivent d’être assez re-présentatifs de tous les types de comportements autorisés, susceptibles d’arriver sur le réseau à protéger. Une assurance difficile à obtenir, car la majorité des NIDS sont déployés dans des environnements qui ne sont pas immuables : mise à jour des systèmes, ajout de nouveaux com-posants, modification de la politique de sécurité, etc. Afin de lutter contre ça, l’entraînement du système n’est pas arrêté une fois le NIDS mis en service, mais est régulièrement mis à jour. Toutefois, s’il se trouve que certaines activités sont encore non incluses dans les traces de références, alors elles seront considérées comme suspectes et déclencheront une alarme. Cette forte dépendance par rapport à la fiabilité des données fournies comme références influence grandement l’efficacité de cette stratégie et son usage peut aussi bien être un avantage qu’une source d’inconvénients. Contrairement à la précédente stratégie, une fois un comportement suspect détecté, on n’a pas la certitude que c’est une véritable attaque. La seule certitude que donne cette manière de procéder demeure le caractère inhabituel de l’activité désignée comme suspecte. Cela impose, à cause de la forte probabilité de faux positif, d’ajuster les contres mesures prises notamment en demandant le jugement d’un administrateur humain.
Complémentarité Il est légitime de se demander s’il est possible de répertorier toutes les signatures d’attaques possibles afin de fournir aux IDS les règles dont ils auront besoin pour mener à bien leur mission ? Des nouvelles failles et manières d’attaquer les systèmes sont fréquemment trouvées, ce qui rend très difficile l’atteinte de cet objectif. Cela motive la mise sur pied d’autres approches telles que la détection par anomalies qui permet par exemple de
s’assurer le respect strict des protocoles réseaux. En d’autres termes, au lieu de chercher à connaître la signature d’une attaque puis de formuler des règles qui sauront l’identifier, on se propose de s’assurer que tous les paquets qui circulent dans le réseau respectent toutes les procédures relatives aux réseaux. En prenant le problème sous l’angle du respect des règles de communication qui régissent les réseaux, on souhaite s’affranchir du nombre conséquent et évolutif de menaces à gérer et se focaliser sur la recherche de requêtes forgées pour passer outre les règles des protocoles établis.
Il faudra tout de même souligner qu’il existe des attaques qui peuvent respecter les protocoles réseaux, mais exploiter des failles du système pour arriver à leur fin. C’est le cas avec plusieurs méthodes de collecte d’information tel que le scan des ports d’un serveur, qui ne vont pas à l’encontre des protocoles établis, mais qui recherchent de l’information de leurs échanges avec les composants du réseau.
La détection par anomalies permet d’exhiber des attaques non répertoriées qui tentent d’exploi-ter les failles et irrégularités des protocoles ; de plus, elle permet d’être proactive en imposant une ligne de conduite sécuritaire et en contrôlant le respect de cette dernière par toutes les communications qui se font dans le réseau. Toutefois, c’est dans sa mise en œuvre que résident les inconvénients de cette solution. En effet, les protocoles étant nombreux et disposant de spé-cifications complexes imposent d’automatiser cette méthode. Malheureusement, automatiser la conversion des protocoles réseaux en règles pour le NIDS est difficile pour plusieurs raisons : la spécification est donnée sous forme de texte volumineux et parfois ambigu ce qui impose un soutient humain pour traiter l’information et l’interpréter sous forme de règles. De plus, certaines spécifications disposent d’implantations différentes d’un système à un autre, affec-tant le caractère générique des règles produites. C’est dans ce contexte que nous introduisons ci-dessous la détection à base de politiques de sécurités [51].
Détection à base de politiques La détection d’intrusions à base de politiques de sécurités est une approche qui consiste à définir toutes les opérations interdites dans le système ou seulement celles autorisées, formant ainsi une politique de sécurité. Toute violation de la politique est considérée comme une tentative d’intrusion. Les opérations non décrites sont implicitement autorisées ou interdites respectivement. C’est-à-dire si la politique décrit un ensemble d’opérations interdites, alors l’ensemble des opérations restantes est autorisé, et si les opérations décrites par la politique sont autorisées, alors celles restantes sont interdites. Un exemple de politique de sécurité serait l’interdiction de toutes connexions FTP en dehors des heures de bureau. Un administrateur qui établit une telle politique jugerait utile d’interdire les services sensibles pendant les heures où personne n’est supposé y accéder. De même, il peut restreindre l’accès à certaines ressources, à une catégorie d’utilisateurs.
collec-tée à la base est identique (trace réseau, trace noyau, journal, etc.), mais elle est exploicollec-tée différemment.
En effet, les données collectées depuis la trace sont analysées de manière individuelle afin de déterminer leur conformité avec la politique établie déterminée. L’efficacité de cette stratégie dépend grandement de la qualité des règles qui forment la politique de sécurité. Les systèmes n’ayant pas tous les mêmes besoins, la politique de sécurité diffère d’un environnement à un autre contrairement à une recherche de signatures ou d’anomalies. De ce fait, les règles qui les composent doivent être réécrites à chaque fois. Ceci empêche, l’organisation d’une base de connaissances commune et le partage de règles entre utilisateurs, contrairement à la détection par signatures où les scénarios d’attaques, une fois identifiés, restent valides et réutilisables pour tout le monde. Enfin, la détection par politiques de sécurités reposant fondamentalement sur la détection des accès illégaux est, une méthode qui reste inefficace contre d’autres types d’intrusions comme les dénis de services.
Elle présente néanmoins certains avantages : d’une part, la description explicite de la politique de sécurité est en soit une qualité, car elle permet à l’administrateur d’avoir un contrôle précis sur la protection mise en œuvre sur le système ; et d’autre part, elle permet de détecter des attaques méconnues. Cette dernière propriété est une conséquence directe de la méthode de détection à base de politiques. En se concentrant sur la violation des propriétés, on parvient à déceler toutes attaques ayant au moins pour conséquence la violation d’une des règles de la politique de sécurité.
Prenons le cas où l’ensemble des opérations interdites forment la politique de sécurité, iden-tifier une intrusion revient à surveiller toutes les opérations exécutées par le système et de trouver celles qui sont illégales. Pour ce faire, on associe à chaque opération une ou plusieurs références. On désigne par référence « la possibilité d’effectuer une action atomique sur un objet ». Par exemple, pour une opération de fermeture de fichier close(file.txt), l’opéra-tion close dispose d’une référence qui autorise la fermeture du fichier file.txt. L’opéral’opéra-tion ls(/home/folder) qui liste le contenu d’un répertoire /home/folder dispose d’une référence pour accéder au contenu du répertoire folder, d’une autre référence pour accéder au contenu du répertoire home et d’une autre référence pour accéder au contenu du répertoire /. Les références sont liées aux objets qui eux sont créés pour représenter les ressources du système. Les références sont créées à l’apparition d’un nouvel objet et effacées à sa destruction. Par exemple, l’opération close(file.txt) s’accompagne de la destruction de la référence qui lui était associée. Enfin, lorsqu’une opération est causée par celle qui la précède, elle hérite des références crées ou acquises par cette dernière. C’est le cas lorsque l’opération d’édition du fichier file.txt nano(file.txt) est exécutée. En effet, elle requiert entre autres l’ouverture du fichier (open(file.txt)) et sa lecture (read(file.txt)).
En résumé Chacune de ces approches dispose de propriétés qui se complètent. D’un côté, nous avons la détection à base de signatures très efficace contre les menaces dont elle possède la signature, mais qui est vulnérable à toutes menaces dont elle ignore la signature ; d’un autre côté, nous avons la détection par anomalie qui souffre d’un taux élevé de fausses alertes, mais pouvant détecter de nouvelles attaques non répertoriées ; enfin, nous avons la détection à base de politiques de sécurité qui permet d’appliquer une protection sur mesure. Dans la pratique, ces approches sont combinées pour un résultat optimal, profitant des avantages complémen-taires de chacune d’elles. Chacune de ces stratégies trouve son utilité selon la situation. Par exemple, dans un environnement où l’on ne prévoit pas de changement, adopter une stratégie par détection d’anomalies se justifie vu qu’elle offre la possibilité de déceler les variations de comportement qui en principe ne devraient pas exister. Par contre, pour un environnement qui change souvent il est préférable d’utiliser une stratégie de détection à base de signatures. Enfin, pour la protection de ressources sensibles, de tailles et de complexités raisonnables, une stratégie de détection par politiques de sécurités fera l’affaire. Par exemple, afin de protéger un grand réseau, on peut utiliser une stratégie de détection par anomalies pour la partie du sous-réseau qui a la propriété de ne subir aucune altération sur son modèle de fonctionnement ; pour la protection des serveurs de données, on utilise une stratégie de détection par anomalies afin de repérer toutes violations d’accès puis, pour le reste du réseau utiliser la stratégie de détection à base de signatures.
1.1.3 Module de gestion des alertes
L’utilité première d’un système de détection est d’aider à dévoiler les menaces puis de prendre des mesures défensives. Ce dernier volet est assuré par le module de gestion des alertes. La fonction de ce module est de prévenir l’administrateur lorsque le module d’analyse a détecté une menace et de prendre si nécessaire des mesures pour atténuer les effets de la menace. Devant une menace, le module peut, à des fins d’archivage, enregistrer l’événement avec tous ses détails afin de produire un rapport détaillé. Il peut aussi envoyer un message à l’administra-teur pour l’informer de la menace et lui proposer si possible des solutions. Enfin, il peut aussi être programmé pour réagir automatiquement en cas d’attaque et déclencher des mécanismes de défense pour neutraliser, sinon réduire, la menace.
Les actions que peut prendre le module sont diverses et elles se divisent en deux groupes : les actions passives et les actions réactives. Une action réactive implique une intervention automa-tisée tandis qu’une action passive consiste à informer l’administrateur de l’alerte déclenchée, lui laissant la tâche de décider de la meilleure contre mesure à adopter.
Actions passives Les actions passives regroupent toutes les solutions dont dispose le NIDS pour informer l’administrateur de l’alerte. Le système de détection d’intrusions peut
préve-nir l’administrateur en lui envoyant un courriel ou en déclenchant un pop-up. En signalant l’alerte, il fournit aussi toutes les informations pertinentes qu’il a collecté sur l’attaque. Il peut aussi collecter et stocker toutes les informations relatives à l’attaque afin d’avoir des preuves qui seront utiles dans le cadre d’une enquête (forensics). Ce dernier volet est particulièrement important si l’on souhaite retrouver l’origine de l’attaque et enclencher des procédures judi-ciaires. La récente attaque subie par Sony [34] a conduit ce dernier à promettre de rechercher et à traduire en justice les coupables et pour cela il aura sûrement besoin des preuves collec-tées via les méthodes de type forensics. L’analyse passive des données échangées fournit au module d’analyse plusieurs renseignements utiles. Cependant, il est parfois nécessaire d’inter-agir avec la source si l’on souhaite plus de précision sur certaines données. Pour ce faire, le NIDS peut envoyer des requêtes vers la source d’où provient la menace dans le but de lui soutirer de l’information. Il peut aussi envoyer une demande vers la machine victime afin de valider si elle est vulnérable à cette attaque ou le cas échéant, de vérifier si l’attaque a été un succès. Il est important de faire remarquer qu’en questionnant la machine d’où provient la menace, la réponse qu’elle nous fournit est susceptible d’être fausse. Il est aussi possible que cette machine soit une victime ou une machine zombie (c’est-à-dire une machine infectée par un programme malveillant capable d’être contrôlé à distance) ou qu’elle refuse simplement de répondre. Enfin, les informations relatives aux alertes sont archivées pour un usage futur. Adopter des actions passives comme mesure de protection offre l’intérêt de ne pas effectuer des actions qui risquent de produire des effets de bord (des effets indésirables). C’est ce qui les caractérise par rapport aux actions réactives. Cependant, les mesures passives se limitent à une observation stricte de la nature de la menace et de ses effets, puis de signaler et attendre une intervention humaine. Le fait de laisser cette tâche à un opérateur humain implique de nouvelles conséquences dont la plus évidente est le temps de réaction. Cela s’explique par le temps que doit prendre l’administrateur pour comprendre la menace en cours, réfléchir et décider des mesures nécessaires pour s’en défendre. Les autres conséquences pouvant être la disponibilité de l’administrateur et l’éventuelle erreur humaine.
Actions réactives Les actions dites réactives placent le NIDS comme étant la première ligne de défense. Ainsi, face à une menace il prend l’initiative sans attendre une intervention humaine et adopte des mesures pour contrôler la menace. Cette méthode confère un meilleur temps de réaction et une meilleure vitesse d’exécution de la contre-mesure, ce qui n’est pas négligeable si l’on tient compte de la vitesse d’exécution et de propagation des attaques. L’absence d’une notion de contexte globale affecte le jugement du NIDS, causant des effets de bord non souhaités. En effet, il s’agit du risque que les mesures défensives prises par le NIDS sanctionnent indirectement des victimes innocentes. Par exemple, en décidant de bloquer l’accès à certaines ressources dans le but de protéger le réseau d’une banque des effets d’une attaque, il est probable que cette initiative prise par le NIDS bloque certaines transactions
importantes que devaient effectuer des clients de la banque, les faisant indirectement accuser des pertes ou des dysfonctionnements.
Les actions réactives à disposition du NIDS sont diverses. Par exemple, on peut interdire les communications avec la source de la menace. Cette solution est à utiliser avec précaution puisqu’elle peut entraîner des effets non désirés si la mauvaise source est bloquée. En effet, si la source de la menace est mal identifiée, en appliquant cette solution on risque d’interdire l’accès à d’autres ressources ou clients, ce qui est un effet non désiré. Toutefois, la solution a le mérite d’être facile à implanter et d’être efficace à condition que la source de la menace soit clairement identifiée.
On peut aussi tenter de supprimer localement la menace en arrêtant tous les processus nuisibles enclenchés par l’attaque et en détruisant les paquets de données qui la véhiculent, avant qu’ils ne se propagent dans le réseau. Cette manière de procéder ressemble à la première ; à la différence près qu’avec cette méthode, on ne bloque que les paquets en provenance de la source de l’attaque et ceux qui semblent avoir un contenu nuisible : le reste du trafic, étant jugé inoffensif, est transmis aux destinataires. Cette solution, beaucoup plus souple, permet d’intervenir de manière sélective sur les paquets de données qui ont un contenu nuisible. Cependant, cet avantage est son plus grand défaut : en procédant de la sorte, toute menace méconnue du NIDS pourra atteindre sa cible sans être interceptée.
Lorsqu’une variante d’attaque est décelée, le NIDS peut aussi être proactif en tentant d’adapter et de produire de nouvelles règles. Cette solution est plus difficile à mettre en œuvre à cause de la nécessité de pouvoir déceler la variante d’attaque. Cependant, une fois mise en place, elle permet au NIDS d’être apte à identifier les menaces qui lui étaient inconnues.
Le NIDS peut aussi être jumelé à un module d’intelligence artificielle (IA) [14,20]. Cela lui ajoute la possibilité d’inférer de nouvelles données qui seront utilisées par le module d’analyse et permettra d’accroître son efficacité dans la détection des menaces. Ainsi, une fois une menace détectée ou une donnée collectée, le NIDS réagit en ajoutant l’information à sa base de faits. La combinaison NIDS et IA est une voie prometteuse. Elle permet au module d’analyse de déduire de nouvelles données et de simuler le comportement d’un système expert. Par exemple, après la réception d’une combinaison précise de paquets de données, le NIDS peut conclure à l’ouverture d’une session par un client et ajouter cette information à sa base de faits. Puis, soit en déduire un nouveau comportement à adopter tel que donner la priorité aux règles qui s’appliquent à ce contexte, soit prendre ce fait comme une composante d’un scénario ou d’une règle.
Encore une fois, la tendance observée est la combinaison des deux types d’actions : passives et réactives. De ce fait, l’administrateur est alerté et en même temps le NIDS réagit en adoptant des solutions nécessaires pour réduire les effets de la menace.
Dans la mise en place des actions défensives d’un NIDS, on constate deux tendances majeures. La première consiste à lier à chaque règle ou scénario, une action défensive à mener. La seconde tendance préconise de ne pas les lier. Toutefois, le choix de la méthode à utiliser se fait le plus souvent selon les besoins.
Comme l’illustre la commande react du langage de description de règles SNORT [35], la définition de l’action défensive à exécuter en présence d’une menace se fait au sein de la définition du scénario de détection. En procédant de la sorte, on s’assure d’adopter la meilleure solution pour chaque situation, car on connaît déjà le contexte et le type de menace à traiter. Durant la définition d’une règle, il sera requis d’y associer l’action défensive la plus adéquate, ce qui alourdit le processus de rédaction des règles de détection d’intrusions. Cela nous oblige à connaître à la fois la signature de la menace et l’action défensive la plus adéquate qui lui sera associée. Avec cette manière de proposer des solutions défensives au cas par cas, il est probable que l’on ait à définir la même action défensive pour plusieurs règles. Cette redondance peut être prise comme un défaut inhérent à cette manière de procéder, d’où la nécessité de parfois dissocier l’action défensive de la règle de détection. Avec cette seconde solution, les actions défensives ne sont pas intégrées dans la définition de la règle, ce qui permet d’associer une catégorie ou un ensemble de règles à un ensemble d’actions défensives. Cette méthode allège la description des scénarios d’attaques étant donné qu’elle se concentre exclusivement sur la description de la signature des attaques. Aussi, en regroupant les actions défensives, cela permettra d’élaborer un ou plusieurs scénarios de défense et de les attribuer dynamiquement à des catégories de menaces selon le contexte, la cible, la fréquence et la vélocité de l’attaque. Il est à souligner que définir la stratégie de défense en dehors de la règle de détection nous fait perdre en précision. Les actions mises en place ne seront plus spécifiques à une menace en particulier et la volonté d’associer une famille d’attaques à une solution défensive oblige à adopter des restrictions larges et parfois permissives afin de couvrir le plus de cas possible. On remarque ainsi que trois éléments caractérisent ce module : les données à envoyer à l’admi-nistrateur pour l’avertir de la menace ; les solutions que peut prendre le NIDS pour assurer la défense de l’environnement ; enfin, où placer les instructions qui vont indiquer au NIDS com-ment on souhaite qu’il réagisse. D’une politique à une autre, la combinaison de ces 3 élécom-ments varie suivant les besoins et les priorités.
1.1.4 Module de contrôle
Le module de contrôle a pour rôle principal d’aider à coordonner le comportement des trois modules précédents en permettant de les configurer de manière centralisée. C’est un outil mis à la disposition de l’administrateur pour gérer le fonctionnement du système de détection d’intrusions.
Une vue d’ensemble du modèle de fonctionnement d’un IDS (figure1.4) nous montre un flux de données entre le module sensoriel, le module d’analyse et le module d’alerte. Ces trois modules ont en commun un vecteur de communication identique qui véhicule les ordres de configuration en provenance du module de contrôle. Cette distribution est idéale dans une configuration distribuée du NIDS. Prenons pour exemple un NIDS en configuration distribuée et déployé dans un grand réseau. Il peut avoir plusieurs capteurs jouant le rôle de senseurs disséminés dans plusieurs artères stratégiques du réseau. Puis dans une zone sécurisée on place le module d’analyse afin de ne pas l’exposer à des attaques de type denial of service (DOS) [33]. Afin d’optimiser les ressources du module d’analyse, on peut placer le module de gestion des alertes sur une autre machine. Enfin, sur le poste des administrateurs se trouvera le module de contrôle. Les autres modules vont communiquer au module de contrôle leurs états chaque fois qu’ils sont altérés. Ceci permettra au module de contrôle de renseigner les administrateurs sur l’état des composants du IDS et de déceler tout dysfonctionnement.
En plus de recevoir de l’information sur l’état des composants du IDS, le module de contrôle peut envoyer vers chacun d’eux des requêtes de configuration. Ainsi, on peut indiquer au senseur la fréquence (heartbeat) d’envoi des traces collectées vers le module d’analyse. On peut aussi demander au senseur d’effectuer un filtre en lui indiquant de ne pas collecter les paquets provenant d’une destination particulière. Aussi, on peut transmettre des instructions pour effectuer des traitements sur les données avant qu’elles ne soient envoyées. Du côté du module d’analyse, le module de contrôle sert de point d’entrée pour faire la gestion des règles et des scénarios d’attaques utilisés par l’IDS. Enfin, conformément à la politique de sécurité adoptée, on indique depuis le module de contrôle les actions défensives à mener par le module de gestion des alertes.
Ce composant est le tableau de bord de l’administrateur. Il est entièrement dédié à la co-ordination et à la configuration des éléments du IDS et à la collecte d’information sur leur état. Le cumul des informations fournies par ce module et celles provenant des rapports du module de gestion des alertes permettra à l’administrateur de mieux évaluer la situation, de prendre la solution la plus adéquate et d’ordonner, depuis le module de contrôle, les actions à entreprendre par l’IDS.
Remarque Notre première présentation des composants d’un IDS comportait quatre élé-ments distincts : le module de collecte, le module d’analyse, le module de gestion des alertes et le module de contrôle. Toutefois, cette configuration n’est pas figée et il arrive qu’on fusionne des composants pour en former un tout monolithique, ou bien que de nouveaux composants y soient intégrés pour répondre à des besoins spécifiques. Enfin, le regroupement de composants peut se faire parfois entre deux éléments. Par exemple, le module d’analyse peut intégrer le module de gestion des alertes.
Module senseur
Module d’analyse Module de contrôle
Module gestion des alertes
État du module et consignes de configuration
État du module et consignes de configuration
État du module et consignes de configuration Communique la trace collectée
Communique les résultats de l’analyse
Figure 1.4: Système de détection d’intrusions dans son ensemble.
Comme dans la section1.1.3, il est possible de jumeler des composants avec un module d’intel-ligence artificielle (IA). La présence d’un élément de ce type va permettre d’accroître l’efficacité de l’IDS en combinant la détection à base de règles et de scénarios avec un moteur d’inférence qui, tout en enrichissant sa base de faits, déduit de nouvelles données qui peuvent aider à iden-tifier de nouveaux scénarios d’attaques. Aussi, les traitements que peut effectuer le module de collecte de données (section 1.1.1) peuvent être confiés à un module spécialisé. Plusieurs traitements peuvent être effectués tels que l’agrégation et le formatage des paquets de données collectés afin de masquer leurs origines variées. De plus, on peut manipuler les données col-lectées afin de les crypter et ainsi éviter qu’elles ne soient interceptées et utilisées de manière illégitimes. Ces dernières solutions sont nécessaires surtout dans le cadre des NIDS pour lutter contre la fragmentation des paquets, l’encodage des données véhiculées, et l’interception des communications. Le module d’analyse assume aussi un rôle d’identification des composants de son environnement. Pour ce faire, l’analyse des données qu’il reçoit peut lui permettre d’identi-fier l’empreinte des systèmes et des périphériques qui composent l’environnement du NIDS. Ce procédé, le plus souvent passif, peut aussi se faire de manière réactive en envoyant des requêtes vers les éléments qui entourent le NIDS afin de susciter une réaction de leur part, permettant ainsi de mieux les identifier. En identifiant les composants de son environnement immédiat, le NIDS s’assure de mieux prévenir d’éventuelles menaces en étant capable d’évaluer les effets et l’interprétation qui sera faite des données qu’il laisse filtrer.
La majorité de nos conclusions proposent de combiner les techniques dans le but d’optimiser les résultats. Toutefois, il faut garder un œil sur l’effet négatif que peut avoir cette combinaison croissante de procédés et de techniques sur la performance générale du NIDS. En effet, même s’il est bien de détecter une menace, il est aussi important de pouvoir le faire dans une fenêtre de temps réaliste.
1.2
Familles d’IDS
La famille des systèmes de détection d’intrusions est très variée et elle se catégorise le plus souvent par spécialisation. Ainsi, suivant la position d’un de ses composants ou la tâche qu’il effectue, l’IDS est classé dans une catégorie. Nous identifions les cinq critères suivants :
– position des senseurs ;
– stratégie pour signaler une alerte ; – méthode de détection ;
– outils
– réaction en cas d’alerte.
Position des senseurs L’un des premiers critères pour catégoriser les IDS est la position du module de collecte de données (senseur). La position des senseurs dans l’environnement à protéger détermine si l’on est devant un Network Intrusion Detection System (NIDS) [29], un Host Intrusion Detection System (HIDS) ou devant un hybride (Hybrid Intrusion Detection System). Avec un NIDS, les sondes collectent les paquets réseau qui circulent. Elles peuvent être des cartes réseau ou des périphériques dédiés capables d’intercepter les trames qui passent par elles. Généralement, elles sont placées de manière stratégique dans plusieurs machines et équipements du réseau afin de couvrir l’ensemble du trafic. Depuis leurs positions, les sondes du NIDS ne collectent que des paquets réseau, mais ces deniers se singularisent grandement de par la diversité des protocoles qu’ils peuvent utiliser [40]. De son côté, le HIDS utilise une autre source de données. Contrairement au NIDS qui surveille les échanges de données entre les composants du réseau, le HIDS se contente de surveiller l’activité au sein d’un système. Une sonde est placée au sein d’une machine hôte où toutes les activités sont collectées. Les données collectées sont des appels aux ressources du système (system call), le contenu des fichiers journaux (log files), les processus, etc. En règle générale, toutes informations pertinentes qui résultent de l’activité de l’hôte.
Un IDS est qualifié d’hybride s’il rejoint les deux catégories d’IDS. Il dispose de plusieurs sondes, les unes qui surveillent l’activité réseau et le reste sur un ou plusieurs hôtes. La diversité des sources de données justifie le traitement des paquets avant qu’ils ne soient transmis au module d’analyse. Par exemple, les paquets de l’IDS hybride Prelude sont encapsulés dans le format IDMEF [6,12] pour masquer l’hétérogénéité des sources. Aussi, on ordonne les paquets afin de respecter leur chronologie. La diversité des sources offre la possibilité de trouver des relations de cause à effet entre les données qui circulent et de les lier les unes aux autres, donnant la possibilité de déceler des comportements suspects qui n’auraient pas été visibles sans cette manière de faire. Un exemple simple de cette liaison est l’ouverture d’un navigateur web. Cette action entraîne l’envoi d’un paquet réseau, afin de récupérer les données web de
la page d’accueil. Dans cet exemple, le lien est fait entre le lancement d’une application et l’échange de paquets avec un serveur web. La vérification de la légitimité de cette action peut se faire en comparant la source des paquets reçus et l’adresse de la page d’accueil demandée. Par contre, la réception de ces mêmes données sans la présence d’une action qui la justifie au niveau du système hôte peut nous indiquer la présence d’un comportement suspect, et nous permettre de conclure que c’est une action non désirée par l’utilisateur du système hôte.
Stratégie pour signaler une alerte Les IDS sont aussi catégorisés en fonction de l’attitude qu’ils adoptent devant une menace. De ce fait, on trouve dans la littérature les termes système de détection d’intrusions (IDS) et système de prévention d’intrusions (IPS) [22]. Avec un IDS, l’alerte est déclenchée pour signaler la détection de la menace une fois toute la signature de cette dernière identifiée. Cela revient en d’autres termes à subir l’attaque avant de la signaler. Pour une attaque contenue dans un seul paquet de données, cette manière de faire semble inévitable. De plus, une fois l’alarme enclenchée, le paquet sera isolé et non transmis à la cible. Un autre avantage qu’offre cette méthode est la certitude de l’existence de l’attaque en cas d’alerte, car sa signature au complet a été identifiée. Par contre pour un scénario d’attaque qui s’étale sur plusieurs paquets de données la donne change. Attendre la détection complète de la signature de la menace implique le plus souvent que l’on ait à subir ses effets. Conscient de cela, il est plus prudent d’opter pour la prévention ; les IPS proposent cette alternative. Cette solution n’est effective que si la menace comporte plusieurs sous actions. Ainsi, en inspectant les traces collectées, chaque étape trouvée nous rapproche de la certitude de l’existence de l’attaque. Il faudra définir le pourcentage de certitude acceptable pour déclencher une alerte et ainsi intervenir avant que l’attaque ne soit exécutée au complet. En procédant de la sorte, on justifie l’alerte qu’avec la découverte d’une portion de la signature parmi les traces, ce qui implique une augmentation du taux de faux positifs. Remarquez qu’en tronquant les scénarios d’un IDS, on obtient le comportement d’un IPS. Cette remarque appuie le fait que la cohabitation des deux genres est possible et se fait sans trop de modifications. On peut entrevoir une combinaison de ces deux manières de faire en dotant l’IDS d’une signature à plusieurs niveaux d’alertes. Ainsi, à chaque phase de la détection d’une signature, des alarmes sont envoyées avec un indice de sureté. La valeur maximale étant attribuée quand la signature complète est détectée.
Méthode de détection La méthode utilisée pour identifier les menaces sert aussi de cri-tère pour catégoriser les IDS. Comme mentionné à la section 1.1.2, nous disposons de trois stratégies : la détection à base de signatures, la détection par anomalies et la détection à base de politiques. La différence de procédé entre ces stratégies justifie grandement l’utilisation de ce critère comme moyen de catégorisation.
