|
Ministère
de l’Enseignement Supérieur et de la Ecole nationale
Supérieure d’Informatique (ESI)
Mémoire de fin d’études Pour l’obtention du diplôme d’ingénieur d’état en informatique Option : Systèmes Informatiques
Thème :
Conception et implémentation à base d’agents, d’un système de détection d’intrusions inspiré des systèmes immunitaires.
Réalisé
par : Encadré
par :
Face aux nouvelles technologies de l’information et de la communication, apparue avec l’avènement des réseaux et d’internet, la sécurité informatique est devenue un défi majeur, et les travaux dans cet axe de recherche sont de plus en plus nombreux. Divers outils et mécanismes sont développés afin de garantir un niveau de sécurité à la hauteur des exigences de la vie moderne. Parmi eux, les systèmes de détection d’intrusions destinés à repérer des activités ou comportements anormaux suspects de nuire au bon fonctionnement du système. L’objet de ce projet de fin d’études est la conception et la réalisation d’un IDS (Intrusion detection system) inspiré des systèmes immunitaires naturels. L’étude de systèmes biologiques afin de s’en inspirer pour la résolution de problèmes informatiques est un axe de l’intelligence artificielle qui a donné naissance à des méthodes robustes et efficaces (colonies de fourmis, algorithmes génétiques, réseaux de neurones …etc.). De part leur fonction naturel, les systèmes immunitaires ont suscité l’intérêt des chercheurs dans le domaine de la détection d’intrusion, compte tenu des similitudes des objectifs d’un SIN (système immunitaire naturel) et d’un IDS. Dans le cadre de ce travail, nous avons conçu un IDS inspiré des SIN et implémenté en utilisant une approche orientée agents. Une plate forme a été développé et des tests ont été effectués afin d’évaluer les performances de notre système. Mots clés : Système de détection d’intrusions, systèmes immunitaires naturels, systèmes immunitaires artificiels, systèmes multi-agents.
In view of new communication and information technologies that appeared with the emergence of networks and Internet, the computer security became a major challenge, and works in this research axis are increasingly numerous. Various tools and mechanisms are developed in order to guarantee a safety level up to the requirements of modern life. Among them, intrusion detection systems (IDS) intended to locate activities or abnormal behaviors suspect to be detrimental to the correct operation of the system. The purpose of this work is the design and the realization of an IDS inspired from natural immune systems. The study of biological systems to get inspired from them for the resolution of computer science problems is an axis of the artificial intelligence field which gave rise to robust and effective methods (ants colonies, genetic algorithms, neuron networks… etc) By their natural function, the immune systems aroused the interest of researchers in the intrusion detection field, taking into account the similarities of SIN (natural immune system) and IDS objectives. Within the framework of this work, we conceived an IDS inspired from natural immune system and implemented by using a directed agents approach. A platform was developed and tests were carried out in order to assess our system performances.
Keywords:
Intrusion detection system, artificial immune system, natural immune system,
multi-agents systems. Chapitre I : Détection des intrusions 2.1 Types de pirates informatiques 2.2 Différentes phases d’une attaque 2.3.3 Scanners de vulnérabilités 3. Systèmes de détection d’intrusions 3.2.1 Architecture centralisée 3.2.2 Architecture partiellement distribuée 3.2.3 Architecture totalement distribuée 3.3.1 Classification selon l’emplacement de l’IDS 3.3.2 Classification selon l’approche de détection 3.3.3 Classification selon la source d’information 3.3.4 Classification selon la fréquence d’utilisation 3.3.5 Classification selon la réponse après détection 3.6 Standardisation / normalisation Chapitre II : Systèmes immunitaires. 2. Systèmes immunitaires naturels 2.3 Immunité innée et immunité adaptative 2.5 Propriétés du système immunitaire 2.5.1 Discrimination entre soi et non soi 2.5.2 Apprentissage et mémorisation 2.5.3 Communication et diffusion 2.6.1 Théorie de la sélection Négative/Positive 2.6.2 Théorie de la sélection clonale 2.7 Déroulement d’une réponse immunitaire 3. Systèmes immunitaires artificiels 3.3. Modélisation des systèmes immunitaires artificiels 3.4.1. Algorithme de la sélection clonale 3.4.2. Algorithme de la sélection négative/positive 3.5. Les systèmes immunitaires et les systèmes de détection d’intrusions 3.5.1. Caractéristiques d’un IDS 3.5.2. Propriétés des AIS pour la détection d’intrusion 3.5.3. Systèmes immunitaires et algorithmes immunitaires 3.5.4. Génération des détecteurs 3.5.5. Détection d’anomalies et détection par scénario Chapitre III : Systèmes multi-agents 2.6 Standards de communication 3.1 Avantage des systèmes multi-agents 3.3 Types de systèmes multi agents 3. Architecture globale de l’IDS 4.1 La base de données « Profils » 4.2 La base de données « Signatures » 4.3 La base de données «Alertes » 5. HIDS avec approche comportementale 5.4 Théorie de la sélection négative 6. NIDS avec approche par scénario 6.2 Théorie de la sélection clonale Chapitre V : Réalisation et tests expérimentaux 4.2 Base de données «Signatures » 4.3 Base de données «alertes » 6. Langages et environnements de développement 7. Déploiement et lancement de l’IDS 7.2 Déroulement de l’exécution de l’IDS Annexe II : Techniques de piratage informatique
FIG 1.1 Rapport de CSI des pertes causées par le piratage informatique en millier de dollars [CSI08]. FIG 1.2 Pourcentage des différents types de piratage informatique selon les dégâts causés [BSA02]. FIG 1.3 Résumé des différents types d’IDS. FIG 1.4 Emplacement de l’IDS au sein d’un réseau. FIG 1.5 Modèle commun aux IDS [BUR06] FIG 2.1 Structure d’un antigène avec ses épitopes [CAS01]. FIG 2.2Différents types de réponses immunitaires [AIC04]. FIG 2.3 Processus de sélection Négative/Positive [CAS03]. FIG 2.4 Processus de sélection clonale [CAS02a]. FIG 2.5 Déroulement d’une réponse immunitaire [cas99]. FIG 2.6 Framework pour les systèmes immunitaires artificiels [BRO04]. FIG 2.7 Espace des formes [CAS01]. FIG 2.8 Différentes distances pour le calcule d’affinité anticorps-antigène . FIG 2.9 Principe de complémentarité entre antigène et anticorps [BRO04]. FIG 2.10 Algorithme de sélection Négative/Positive en deux phase [CAS00c]. FIG 2.11 Système immunitaire artificiel pour la détection d'intrusions FIG 3.1 Un agent dans un environnement [BOI02]. FIG 3.2 Représentation caractéristique d’un agent à architecture modulaire horizontale [FER95]. FIG 3.3 Un agent réactif [BOI01f] FIG 3.4 Un agent cognitif [BOR05] FIG 3.5 Représentation d’un système multi agents [TAN05]. FIG 4.1 Schéma global de la solution. FIG 4.2 Profil utilisateur - HIDS. FIG 4.3 Architecture du HIDS utilisant l’approche comportementale. FIG 4.4 Phase I de la sélection négative (Génération des détecteurs). FIG 4.5 Phase II de la sélection négative (mise en place des détecteurs pour l’analyse). FIG 4.6 Fonctionnement du HIDS. FIG 4.7 Architecture à base d’agents du NIDS. FIG 4.8 : Format d’une signature. FIG 4.9 : Génération de l’ensemble initial d’anticorps FIG 4.10 : Attribution des poids aux différentes parties de la signature. FIG 4.11 : Mesure du degré d’affinité entre une signature et un détecteur. FIG 4.12 : Processus de maturation d’affinité. FIG 4.13 Fonctionnement du NIDS. FIG 5.1 NIDS utilisé à part. FIG 5.2 HIDS utilisé à part. FIG 5.3 Système multi-agents NIDS. FIG 5.4 Schéma de la base de données « Profils ». FIG 5.5 Schéma de la base de données « Signatures ». FIG 5.6 Modélisation de l’attaque par « injection SQL ». FIG 5.7 Schéma de la base de données « Alertes ». FIG 5.8 Interface du NIDS. FIG 5.9 Administration de l’IDS. FIG 5.10 Aperçu rapide des différentes alertes générées. FIG 5.11 Configuration de l’IDS. FIG 5.12 Gestionnaire des profils. FIG 5.13 Gestionnaire des alertes. FIG 5.14 Alertes NIDS. FIG 5.15 Gestionnaire des signatures. FIG 5.16 Réseau de test pour le HIDS. FIG 5.17 Interface du HIDS superviseur. FIG 5.18 Déploiement des agents du HIDS superviseur et des différents HIDS esclaves. FIG 5.19 Alertes générés par les différents HIDS esclaves. FIG 5.20 Génération des détecteurs à partir des signatures – NIDS.
TAB 3.1 : Comparaison systèmes immunitaires et algorithmes immunitaires. TAB 3.2 : Comparaison entre systèmes immunitaires et systèmes de détection d’intrusions. TAB 4.1 : Comparaison entre les deux solutions. TAB 4.1 : Différentes classes du package « SIG » du NIDS. TAB 4.2 : Différentes classes du package « Manager » du NIDS. TAB 4. 3 : Différentes classes du package « Analyseur » du NIDS. TAB 4. 4 : Différentes classes du package « senseur » du NIDS. TAB 4. 5 : Différentes classes du package « Detectors » du HIDS superviseur. TAB 4. 6 : Différentes classes du package « Profils » du HIDS superviseur. TAB 4. 7 : Différentes classes du package « Profils » du HIDS esclave TAB 4. 8 : Différentes classes du package « Captor » du HIDS esclave. TAB 4. 9 : Différentes classes du package « analyse » du HIDS esclave.
Les attaques informatiques ont été depuis leur apparition une vraie menace. Avec leur grande diversité et spécificité aux systèmes, ces dernières peuvent avoir des conséquences catastrophiques. Différentes contre-mesures permettant d’éviter ces attaques ou de diminuer de leur gravité existent mais aucune solution ne peut être considérée satisfaisante et complète. Les systèmes de détection d’intrusions sont l’une de ces contre-mesures les plus efficaces. Leur rôle est de reconnaitre des intrusions ou des tentatives d’intrusions par des comportements anormaux des utilisateurs ou par la reconnaissance d’attaque à partir du flux des données du réseau. Différentes méthodes et approches ont été adoptées pour la conception de systèmes de détection d’intrusions. Parmi ces méthodes, l’une est inspirée de la nature, notamment des systèmes immunitaires, qui présentent des propriétés et une grande similarité avec les systèmes de détection d’intrusions. Le système immunitaire biologique avec ses propriétés remarquables est une source d’inspiration pour la résolution de problèmes. L’étude des systèmes immunitaires est un nouvel axe de recherche très prometteur, qui a donné naissance à une nouvelle branche de l’intelligence artificielle, à savoir, les systèmes immunitaires artificiels. Ces derniers sont en fait la modélisation, l’implémentation et l’adaptation des concepts et méthodes des systèmes immunitaires biologiques pour la résolution de problèmes. Dans le cadre de notre étude, nous nous intéressons aux systèmes immunitaires pour la détection d’intrusion. Notre objectif est de développer un système immunitaire artificiel pour notre système de détection d’intrusions, en implémentant les principales théories immunitaires. Afin d’évaluer ses performances, nous procéderons à une série de tests dont nous analyserons les résultats afin de mesurer l’apport des systèmes immunitaires pour la détection d’intrusions. Les systèmes de détection d’intrusions ainsi que les systèmes immunitaires sont caractérisés par leur architecture hiérarchique et leur fonctionnement distribué sur un ensemble de sous systèmes. Afin de modéliser au mieux ces notions, nous adopterons une méthode de conception basée sur des agents, et nous nous intéresserons de prêt aux systèmes multi-agents. Ce rapport se divisera en deux parties principales : « Etat de l’art » et « Mise en œuvre ». Le premier chapitre est consacré à l’introduction des intrusions informatiques et des systèmes de détection d’intrusions. Dans le second chapitre, nous présenterons les systèmes immunitaires naturels, systèmes immunitaires artificiels et leurs applications pour la détection d’intrusions. Les systèmes multi-agents feront l’objet du troisième chapitre La seconde partie « Mise en œuvre » sera dédiée à la présentation de notre système de détection d’intrusions développé à base d’agents en s’inspirant des systèmes immunitaires artificiels. Nous présenterons dans le quatrième chapitre toutes les théories et modèles immunitaires utilisés. Nous détaillerons dans le chapitre cinq les différents plates-formes et langages de programmation auxquels nous avons eu recours pour l’implémentation de notre système. Nous finirons par un ensemble de tests permettant d’évaluer l’apport des systèmes immunitaires pour la détection d’intrusions.
Première partie
Etat de l’art.
Chapitre I : Détection des intrusions 1. Introduction. 2. Intrusions informatiques. 3. Systèmes de détection d’intrusions. 4. Conclusion. De nos jours l’outil informatique est omni présent dans notre vie quotidienne. Que ce soit pour l’achat d’articles, faire des transactions bancaires, l’envoi de courrier ou encore la réservation de places de cinéma, nous dépendons énormément de cette technologie et nous ne pouvons plus nous en passer. L’arrivée d’Internet est définie comme l’âge d’or de l’informatique. Avec l’interconnexion des réseaux, la rapidité de diffusion et d’acquisition de l’information, Internet a révolutionné notre vie. Comme toute innovation ou nouvelle technologie, Internet peut avoir des conséquences regrettables en cas de mauvaise utilisation. De nouveaux genres d’espionnage industriel, guerre inter-nations ou abus ont vu le jour. Par conséquent une communauté de gens malveillants s’est fondée et de nouveaux objectifs se sont créés tel que le détournement d’informations, la percée des secrets personnels et cela peut aller jusqu'à la destruction d’informations vitales. Avec l’arrivée d’internet, de nouveaux marchés ont vu le jour et de nouvelles perspectives sont apparues. La plupart des opportunités sont dans le domaine commercial, où les entreprises peuvent exposer leurs produits et services au monde entier grâce à des sites web. Des transactions avec des sommes colossales sont effectuées chaque jour, ce qui expose les entreprises à différentes menaces. Autrefois, on s’était beaucoup plus intéressé aux avantages de cette nouvelle technologie et rares étaient ceux qui pensaient ou mettaient quelques moyens et ressources pour assurer un minimum de sécurité. [Col01] Le plus grave est que plusieurs entreprises courent des risques sans le savoir, et que les administrateurs réseau ou les personnes chargées d’assurer la sécurité informatique ignorent de quoi ils devraient se protéger. On estime aujourd’hui à moins de 4 mn le temps moyen pour qu’un PC non protégé connecté à Internet subisse une tentative d’intrusion ou soit contaminé par un programme malicieux. [Gan00]. Différentes techniques ont été mises en place par des communautés des pirates informatiques. Chacune d’entre elles touche un certain aspect de l’outil informatique. Nous pouvons catégoriser les différentes techniques de piratage informatique en deux classes [Gan00] : i. Attaques réseaux : Cette classe d’attaques, regroupe l’ensemble des techniques mises au point, permettant d’exploiter les faiblesses des réseaux ou bien les attaques qui ciblent des composants réseau. ii. Attaques applicatives : Cette deuxième catégorie contient les techniques basées sur les faiblesses et les bugs des applications, permettant ainsi d’exploiter ces dernières pour des fins malveillantes. Les différents types d’attaques seront détaillés en annexe II. 2.1 Types de pirates informatiques Les pirates informatiques se sont organisés en communautés et selon leur appartenance, leurs objectifs diffèrent ainsi que leurs manières de procéder. Deux grandes catégories se sont distinguées i. Hackers : ce sont d’excellents développeurs, spécialistes des réseaux. Ils existent depuis longtemps. Dés l’apparition de l’informatique et avec les premiers mini-ordinateurs, ils ont contribué à faire de l’informatique ce qu’elle est aujourd’hui. Certains d’entre eux ont participé au développement d’Unix, d’autres ont créé Internet. [Ray01]. Les hackers partagent librement l’information et ne causent jamais la perte ou la destruction d’informations. [Sms00] ii. Crackers : Les crackers quant à eux sont dangereux et peuvent causer des dégâts. Si les hackers s’intéressent à découvrir les failles et les bugs, les crackers les utilisent pour des fins destructives. Ils contournent les protections par mots de passe, utilisent des techniques de brute force, effacent des données, déstabilisent et mettent hors d’usage des systèmes …etc. [CAS00a]. La différence fondamentale entre hackers et crackers est que les hackers construisent les choses, les crackers (pirates) les démolissent. [RAY01] 2.2 Différentes phases d’une attaque Quelque soit les attaques menées, elles ont toutes la même démarche [COL01]. Une attaque est constituée de ce qui est connu sous le nom des « 5 P », ces cinq verbes anglais définissent ce que c’est qu’une attaque : - Prob : C’est la partie d’audit qui sert à collecter des informations relatives à la cible. Cette collecte est facilitée par des outils tel que Whois, DNS Lookup, Un scan des ports ou encore un scanner de vulnérabilités. - Penetrate : C’est la phase de pénétration, en utilisant les informations collectées. - Persist : Une fois l’attaque réussie, et le système pénétré, l’attaquant tente de garder un contrôle sur le système. Il crée ainsi un compte avec des droits d’administrateur, ou installe une porte dérobée (Cheval de trois). - Propagate : L’attaquant vérifie s’il y’a d’éventuelles cibles à partir du réseau local, si l’attaque peu être propagée sur d’autres machines. - Paralyze : A la fin de son attaque, l’attaquant peut utiliser la victime pour mener d’autres attaques ou détruire des informations vitales, ou carrément mettre hors d’usage le système. Les conséquences du piratage informatique peuvent être très graves et les chiffres le montrent clairement : des centaines de systèmes ont été piratés, des quantités énormes d’informations confidentielles et de secrets industriels ont été volés. Ce problème est devenu très sérieux. Les infrastructures informatiques gouvernementales et nationales sont les cibles préférées des pirates. Ensuite, les organisations commerciales, les banques et en derniers lieu les simples utilisateurs [ALL03]. Voici un petit historique des plus grandes attaques connues avant le bug de l’an 2000 - Le 11 mai 1999 : Le site web de la maison blanche a été mis hors service. - Le 21 mai 1999 : le GAO (General Accounting Office) dit : « Nous avons réussi à pénétrer quelques systèmes à missions critiques, dont un responsable du calcul de position terre-orbite pour un vaisseau spatial » - Le 1er juin 1999 : Des pirates chinois ont attaqué une poignée de sites gouvernementaux américains, le site de la maison blanche a été encore mis hors service. - Le 7 octobre 1999 : Des pirates russes réussissent à s’introduire dans le réseau du département de défense américain et ont réussi à dérober une très grande quantité d’informations du département d’armement nucléaire et de recherche. - Le 7 octobre 1999 : Une attaque réussie contre la NASA, une attaque très massive et très discrète, les attaquants ont pris une très grande quantité d’informations (des listes de fichiers, des répertoires personnels...etc.). Les attaquants ont installé des backdoors, pour pouvoir se reconnecter plus tard. les backdoors ont été découvert bien après l’attaque…etc. Nous remarquons que dans un laps de temps très réduit, un grand nombre d’attaques ont eu lieu touchants les plus grandes institutions gouvernementales qui sont supposées être sécurisées. Nous pouvons donc imaginer les dégâts causés sur des systèmes moins importants. Le passage à l’an 2000 a couté très chère aux sociétés de l’information d’après le rapport publié par CSI (Computer Security Institute). La figure suivante FIG 1.1 montre les pertes causées par le piratage informatique. Nous pouvons voir clairement sur la figure que durant les deux années qui ont suivi l’an 2000, une grande activité des pirates a été constatée, et par conséquent, le total des pertes s’est vu augmenter d’une manière très remarquable.
FIG 1.1 Rapport de CSI des pertes causées par le piratage informatique en millier de dollars [CSI08]. Voici un simple rappel de chiffres [Bsa02] :
Différentes attaques sont derrières toutes ces pertes, que ce soit des attaques de virus, des attaques par déni de service ou des détournements de sessions, nous retrouvons sur la figure FIG 1.2 les différentes techniques de piratage citées plus haut présentent avec pour chacune le taux de perte causé.
FIG 1.2 Pourcentage des différents types de piratage informatique selon les dégâts causés [BSA02]. Non seulement les conséquences du piratage sont là pour nous donner une idée du danger couru quotidiennement, mais ce fléau ne fait qu’augmenter, même avec les mesures prises pour le contourner. Bien évidemment, face à de telles menaces, les informaticiens et surtout les développeurs ont réagi, en créant des mécanismes de protection, garantissant ainsi un certain niveau de sécurité. Voici les contres mesures les plus connues : La plus part des entreprises craignent les attaques externes, qui peuvent parvenir d’Internet, et ainsi dérober certains secrets industriels ou informations confidentielles. Le pare feu permet de définir des règles à vérifier pour chaque transmission. Il peut par exemple interdire les connexions venant d’une plage d’adresses IP ou une adresse IP précise, interdire les connexions sur un port défini, ou vers un autre port. Le pare feu peut aussi interdire à une application d’utiliser les services réseaux ou de se mettre en mode écoute sur un port défini. Certains logiciels sont déclarés au cours de leur utilisation comme étant vulnérables, le meilleur moyen pour se protéger de ces logiciels est de modifier les règles du pare feu afin de leurs interdire toutes communications avec l’extérieur en attendant l’installation de correctifs. Le pare-feu empêche un grand nombre d’attaques et présente un important mécanisme au sein d’une stratégie de sécurité [COL01].
Un anti-virus est un logiciel qui se charge de détruire tout virus qu'il détecte. Il existe différentes approches pour l’analyse des virus:
- Certains antivirus possèdent une liste de virus et de leurs dérivés. Ils cherchent pour chaque fichier l’existence de signatures de virus dans leur base, ensuite ils essayent de le désinfecter, de l’effacer ou bien de le mettre en quarantaine. - D’autres antivirus scannent le code source des fichiers afin de trouver des morceaux de code dangereux pour l'intégrité du système. Certaines personnes préconisent d'utiliser les deux types d'anti-virus de front afin de limiter les failles. D'autres conseillent d'utiliser un anti-virus et un pare-feu en même temps[COL01].
2.3.3 Scanners de vulnérabilités Ce sont des programmes permettant de scanner une cible afin de déterminer les éventuelles failles ou vulnérabilités dans son système. Un grand nombre d’applications a été mis en œuvre par les experts en la matière. Ces applications peuvent scanner des ports et déterminer les services exécutés sur ces derniers. Ils ne sont pas aussi fiables, cependant leurs principal avantages est leur rapidité [Col01].
Peu après la détection d’une vulnérabilité, une faille ou un bug, l’éditeur de logiciels fournie un patch (correctif) ou bien une mise à jour pour corriger son produit. C’est une très bonne (ou la meilleur) façon de se protéger de la majorité des failles, bugs et erreurs de programmation connues.
Ce sont des systèmes permettant de ralentir des attaques en générant de fausses réponses, tels que les HoneyPots qui font croire à l’attaquant qu’il a réussi son attaque alors qu’il n’a pénétré qu’un système destiné à sauvegarder toutes les traces de cette intrusion [COL01].
Malgré l’existence de différents mécanismes de protection (pare feu, antivirus, scanner de vulnérabilités), chaque système de protection peut présenter une menace particulière pour les systèmes d’informations, car chacun d’entre eux à ses points faibles. D’autres méthodes et mécanismes existent tels que les systèmes de détections d’intrusions (Intrusion Detection System). Objet de ce mémoire de fin d’études, ce sont des systèmes permettant de détecter des tentatives d’attaques ou des attaques réussies. Ils permettent de retrouver les traces des attaques déjà connues ou de détecter une nouvelle forme d’attaques. Les systèmes de détection d’intrusions servent à contrôler le trafic autorisé par le pare-feu et prennent des décisions si le trafic observé est suspect. Ces derniers peuvent découvrir les attaquants qui parviennent à pénétrer le pare-feu ou le trafic qu’ils jugent suspects et l’annoncent aux administrateurs du système, qui peuvent prendre des mesures pour éviter d’éventuels dégâts.
3. Systèmes de détection d’intrusions Avant d’aborder les systèmes de détection d’intrusions, il convient de définir d’abord ce que c’est qu’une intrusion. Une intrusion peu être définie comme une pénétration du système, une tentative des utilisateurs d’augmenter leurs privilèges, ou une tentative de déjouer des mécanismes de sécurité ou de compromettre la confidentialité, l’intégrité et la disponibilité des informations [Ray01] [BUR06]. Une intrusion peut être provoquée par une personne malveillante ou une personne tierce. En effet, des attaquants peuvent utiliser des machines intermédiaires pour effectuer leurs attaques dans le but de dissimuler leurs traces. L’intrusion peut ne pas être couronnée de succès. On parle dans ce cas de tentatives d’intrusion, ce qui éveillerait les soupçons des administrateurs. C’est pour cette raison que les attaquants doivent d’abord étudier le système en question avant de lancer des attaques. Nous pouvons nous intéresser aux attaques durant ou après leurs apparitions. Le terme intrusion est utilisé pour définir une attaque qui est réussie, or, les IDS sont là pour détecter des attaques (réussies, ou seulement des tentatives). Pour être sémantiquement correct et pour être consistant on devrait dire système de détection d’attaques « Attack Detection System » au lieu de dire système de détection d’intrusion [ALL03], mais on continue de l’utiliser par abus. Un système de détection d’intrusion est un dispositif logiciel et ou matériel permettant de : - Analyser du trafic réseau. - Automatiser la tâche d’analyse des fichiers log (Fichiers contenants les traces des utilisateurs). - Reconnaitre des attaques connues. - Découvrir de nouvelles attaques. - Analyser le comportement des utilisateurs, processus…etc [BAC02]. En résumé, un système de détection d’intrusion (IDS) est un outil qui vient s’ajouter à une panoplie d’utilitaires utilisés pour avoir un certain niveau de sécurité. Nous présentons dans ce chapitre les différentes architectures des IDS, leurs approches de détections, leurs comportements. Nous aborderons également les mesures qui permettent de définir le degré d’efficacité d’un IDS et pour finir les travaux très récents de standardisation et d’homogénéisation des IDS. Les systèmes de détection d’intrusions ont un modèle commun, composé de trois modules : La Source : ou la sonde, permet de récupérer des informations qui seront étudiées par la suite. Plusieurs sondes peuvent être installées à divers points stratégiques de la zone sous surveillance. L’analyseur : L’outil permettant d’analyser les informations en provenance des différentes sources. L’analyseur peut en cas de doutes signaler une tentative d’intrusions, ou ‘actionner’ des mécanismes de contres mesures par des alertes. Différentes méthodes d’analyses existent et seront détaillées par la suite. La réponse : C’est la partie qui prend en charge les contre mesures. Selon la gravité de l’alerte, les contre mesures peuvent être diverses : · Sauvegarde d’informations relatives à l’alerte. · Envoi d’emails à l’administrateur. · Alertes visuelles sur des terminaux. · Refus des connexions …etc. La stratégie de contrôle permet de déterminer la manière de gérer plusieurs sondes du même IDS, ou la façon de gérer plusieurs IDS dans un réseau. Selon la disposition des différents composants de l’IDS, plusieurs architectures peuvent être adoptées : 3.2.1 Architecture centralisée Une certaine disposition permettra de contrôler tous les événements à partir d’une console centrale, analyser, et décider des mesures à entreprendre. Différents modèles d’IDS (qui seront abordés plus loin) peuvent être utilisés dans un même réseau à différents points stratégiques, afin de récolter les informations en provenance des différents IDS et les traiter à un point central. En cas de doutes, des actions peuvent être entreprises à partir du même point d’analyse. 3.2.2 Architecture partiellement distribuée Cette disposition permet de décharger le serveur (le point central d’analyse et de traitement) de l’ensemble des tâches. Une hiérarchie est mise en place. Chaque ‘sous partie’ ou bien sous réseau est géré par un point local. Les ‘conclusions’ et les rapports sont communiqués à un nœud d’ordre supérieur hiérarchiquement qui transmet ses conclusions au nœud suivant et ainsi de suite. Les mesures sont prises par la console de niveau supérieur. 3.2.3 Architecture totalement distribuée Cette disposition est adoptée dans le cas des réseaux de grande taille. Dans ce cas le réseau est décomposé en plusieurs sous-réseaux, chacun d’entre est géré par son propre IDS. Les tâches d’audits et d’analyses sont prises au niveau local. Nous pouvons classer les IDS selon différents critères. Ces derniers peuvent être utilisés afin de choisir l’IDS le plus approprié aux besoins. Certaines classifications sont basées sur le comportement des IDS, d’autres sur leurs sources d’informations, une autre classification selon leurs fréquences d’utilisations …etc. 3.3.1 Classification selon l’emplacement de l’IDS § Les NIDS (Network Based Intrusion Detection System) Ces IDS s’installent sur un réseau. Ils ont pour rôle de surveiller le trafic du réseau, en le comparant à une base de signatures des attaques connues, afin de détecter la présence d’éventuelles signatures. Les NIDS sont généralement appelés IDS on-line puisqu’ils analysent le trafic réseau en temps réel. Un problème se pose : les performances du réseau se voient diminuées à cause de l’IDS. Les NIDS sont généralement confrontés à deux grands problèmes : o Les réseaux sont de plus en plus commutés, et la surveillance de tels réseaux est très difficile. o Les transmissions cryptées rendent l’analyse de ces dernières presque impossible. § Les HIDS (Host Based Intrusion Detection System) Ce type d’IDS s’installent sur un hôte et ont pour rôle de surveiller l’activité de ce dernier, les HIDS ont pour tâche de vérifier les fichiers LOG, analyser les appels superviseur et analyser le comportement. § Les IDS hybrides Comme leur nom l’indique, ces IDS sont une imbrication des deux types définis précédemment. Dans un même réseau, différents IDS peuvent être installés, une stratégie pour faire fonctionner et standardiser les communications et les alertes est à prévoir. 3.3.2 Classification selon l’approche de détection L’approche de détection est un paramètre clé pour un IDS, selon les besoins et selon les machines sur lesquelles l’IDS sera déployé, deux principales approches existent : § Approche par scenario (Knowledge Based detection) Cette méthode de détection s’appuie sur une base de données de toutes les attaques connues. Chaque attaque a sa propre signature, l’IDS cherche à reconnaitre cette signature parmi les paquets qu’il analyse. Cette méthode est simple à mettre en œuvre, des algorithmes tels que le pattern matching, les systèmes experts, les algorithmes génétiques…etc. peuvent être utilisés pour permettre cette reconnaissance. Cependant son point faible réside dans le fait que cette méthode est basée sur les signatures d’attaques connues. Donc la base de données doit être régulièrement mise à jour. De plus les attaques inconnues ne seront jamais détectées ainsi que des variantes de la même attaque. Si dans un processus d’attaque, les actions A-B-C se succèdent et si l’attaquant arrive à changer cet ordre ou à introduire une nouvelle action, la même attaque qui aboutit aux mêmes résultats ne sera pas détectée. Parmi les techniques utilisées dans cette approche par scénario : -
Le pattern matching : Pour
cette méthode, nous avons besoin d’un langage pour modéliser une attaque. On
essaie ensuite de localiser les signatures d’attaques dans les sources
d’informations. Le modèle de reconnaissance constitue le cœur du détecteur. Si
l’on veut optimiser la phase de détection, les modifications majeures seront
apportées à ce modèle. - Les systèmes experts : On garde dans la base de données des implications (Si…Alors…) pour modéliser des attaques (signatures ou classes d’attaques). Le point faible est que les attaques sont spécifiques aux systèmes d’exploitation.
§ Approche comportementale (Anomaly detection) Cette méthode est un peu plus ‘compliquée’ à mettre en œuvre, elle se base sur un modèle de comportement habituel et normal de l’utilisateur. Durant une période d’apprentissage, on récupère des paramètres relatifs aux utilisateurs. Ces paramètres peuvent être : - La bande passante moyenne consommée par l’utilisateur. - La consommation des ressources système (Mémoire, CPU). - Les horaires de connexion et d’ouverture de session. - Le type des fichiers utilisés …etc. En se basant sur ces paramètres, un modèle est construit. Ce modèle définit le comportement habituel et ‘sains de l’utilisateur. L’IDS a la charge de comparer le comportement courant de l’utilisateur au comportement préalablement enregistré (Profil). Le profil utilisateur peut évoluer dynamiquement avec le temps. Le plus important dans cette méthode est la définition des paramètres du profil. Plusieurs approches ont été adoptées selon les critères choisis et l’interprétation des divergences dans ces critères - Modèle de Denning : C’est un modèle quantitatif se basant sur des notions de statistique. Ce modèle s’intéresse beaucoup plus à l’utilisation des ressources système : Occupation mémoire, utilisation des processeurs, accès aux disques, utilisation des services système. Le profil peut évoluer en observant les mesures réelles des paramètres choisis. - Systèmes experts : Ensemble de règles décrites (politique de sécurité) ou générées (comportements) - Réseaux de neurones : On définit un profil par rapport aux : - Outils préférés. - Les activités. - Habitudes. - Vitesse de saisie au clavier…etc. 3.3.3 Classification selon la source d’information La source d’information représente un paramètre clé pour un IDS. Cette source d’information impose généralement l’usage de certain algorithmes et méthodes pour l’analyse des données récoltées. §
Audit : Ce
genre d’IDS est généralement utilisé dans le cas où la vérification se fait de
temps en temps. Il se base sur les fichiers d’enregistrement, les fichiers
journaux. § Paquets : Ce genre d’IDS est très spécifique, il ne s’intéresse qu’au flux des paquets, que ce soit sur un réseau ou sur un hôte. Ce type d’IDS peut être installé avec d’autres types, afin de décentraliser les tâches. En effet, dans un réseau, des IDS utilisant l’approche comportementale peuvent s’intéressés aux comportements des utilisateurs, tandis que ce type d’IDS s’intéresse aux paquets réseaux. 3.3.4 Classification selon la fréquence d’utilisation Deux modèles d’IDS se distinguent selon la fréquence d’utilisation. § Utilisation continue : Ces types d’IDS sont des services qui s’exécutent au lancement des systèmes d’exploitation. Ils sont toujours actifs, et analysent en permanence le trafic réseau et/ou les fichiers journaux. Leur inconvénient est qu’ils consomment beaucoup des ressources système, et les performances des machines peuvent se voir dégradées. § Utilisation différée : Cet IDS est lancé périodiquement (généralement en fin de journée). Dans le cas de l’utilisation différée on ne peut analyser que les fichiers journaux et les traces des utilisateurs. L’utilisation différée est préférée dans le cas où les ressources système sont précieuses (Serveur de messagerie, Serveur Web très solicité).
3.3.5 Classification selon la réponse après détection Les IDS ne font pas que détecter des attaques ou tentatives d’attaques, certains ont la faculté d’agir si nécessaire. Cette habilité est plus connue sous le nom de réponse de l’IDS, elle fait la différence entre deux modèles : § Les IDS passifs : Ce type d’IDS ne fait qu’analyser les données en provenance des sondes et en cas de détection ou d’estimation d’un danger, l’IDS sauvegarde cette trace d’attaque, ou à la limite envoie une alerte visuelle sur la console d’administration. § Les IDS actifs : A l’inverse du précédent, l’IDS actif a les mêmes facultés précédentes, sauf qu’en cas de grands dangers ‘estimés’, l’IDS peut réagir sans attendre l’intervention humaine, il peut par exemple : - Modifier la table de routage d’un routeur. - Demander au pare-feu de modifier ses règles. - Refuser ou arrêter une connexion par un appel. - Arrêter un processus…etc. Un autre type bien particulier d’IDS actif est connu sous le nom de système de prévention ou de protection contre les intrusions (Intrusion Prenvention System). Un IPS ne fait pas que détecter et signaler des menaces ou des intrusions. Un IPS est positionné en coupure sur un réseau c.-à-d. qu’il a la faculté de mettre fin a des connexions et d’agir par ses propres ‘moyens ‘, à l’inverse des IDS actifs, qui en cas de tentative d’attaques ou d’intrusions, demandent à d’autres composants tels que les pares feu, les routeurs, ou le système d’exploitation de réagir [Lar03].Donc plusieurs caractéristiques sont à étudier et à déterminer avant d’installer un IDS. Voici un récapitulatif des différents modèles et caractéristiques des IDS FIG 1.3.
FIG 1.3 Résumé des différents types d’IDS. Le choix de l’IDS est très influencé par son éventuel emplacement au sein du réseau. En effet, la topologie réseau impose quelques règles à respecter si on veut que l’IDS soit efficace. L’emplacement de l’IDS doit également tenir compte du type d’intrusions à détecter (internes, externes, les deux). Si dans un réseau, il existe un seul point de connexion à internet, le meilleur emplacement de l’IDS est qu’il soit juste après le routeur. Si dans un autre réseau, différents points de connexions à internet existent, un IDS est placé pour chaque point de connexion comme nous pouvons le voir dans la figure FIG 1.4. Par contre pour détecter les intrusions internes un IDS doit être placé à chaque segment du réseau [Snr03].
FIG 1.4 Emplacement de l’IDS au sein d’un réseau. Des mesures permettent de comparer et de mesurer l’efficacité des IDS. Les IDS sont des éléments très importants dans une stratégie de sécurité, pour cela le choix de l’IDS est très décisif et doit être basé sur les caractéristiques de ce dernier, les tâches qu’il devra accomplir, son emplacement …etc. mais également selon des mesures qui permettent d’évaluer son efficacité. La technique la plus utilisée pour évaluer un IDS est le scanner de vulnérabilités. Cependant, ce dernier reste peu fiable. Les mesures permettant de mieux choisir son IDS et mesurer son efficacité sont [BUR06] : - Qualité des informations fournies par l’IDS : Le taux de faux positif. - Réponse de l’IDS dans un environnement surchargé. - La possibilité de mettre à jour la base des signatures ou de modifier certaines signatures. - La séparabilité des fonctions d’administration (architecture distribuée).…etc. Les IDS à leurs tours peuvent faire l’objet d’attaques et certaines de leurs faiblesses sont liées au système d’exploitation (saturation de la mémoire ou de la carte réseau) [Gad07]. 3.6 Standardisation / normalisation L’un des problèmes majeurs auquel sont confrontés les développeurs, les décideurs ainsi que les administrateurs est : «Comment peut-on faire coopérer différents IDS dans une même zone ? ». Les deux types d’IDS (NIDS, HIDS) sont souvent utilisés ensemble sur les réseaux. Le NIDS est généralement installé sur des points stratégiques du réseau (derrière le routeur et le pare-feu) tandis que le HIDS est installé généralement sur l’ensemble des machines du parc informatique. Une hétérogénéité est donc inévitable due à la complémentarité des deux types d’IDS [BUR06]. En effet, les différents formats de messages et principes d’audit font du fait de réutiliser des composants dans des environnements différents un vrai défi. Le groupe IDWG (Intrusion Detection Working Group) a participé à la standardisation des IDS en définissant la norme IDMEF (Intrusion Detection Message exchange format) pour le format des messages échangés entres IDS et le protocole IDXP (Intrusion Detection eXchange Protocol) qui définie les procédures de transport entre IDS. Un comité du DARPA a défini quatre briques pour décrire l’architecture d’un IDS, et c’est ce modèle FIG 1.5 qui a été adopté par la suite pour l’ensemble des 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) : Analyse les événements reçus de la boite E et produit des alertes. - Base de données événementielles (boîte D) : Pour stocker tous types d’informations relatifs aux événements, alertes. - Système de réponse (boîte R) : réponse en temps réel face aux attaques. En langage IDMEF un analyseur est connu sous le nom de sonde ; La sonde envoie une alerte (sous forme de message) vers un collecteur, ce modèle permet d’avoir une communication hétérogène hormis l’environnement sur le quel se passent les communications. L’implémentation est en général binaire à fin d’éviter l’insertion d’informations inutiles. Les alertes sont sous format XML, le modèle IDMEF offre également un vocabulaire précis sur les différents composants d’un IDS.[BUR06]
FIG 1.5 Modèle commun aux IDS [BUR06]. Les attaques informatiques ne cessent de croitre et par conséquent les dégâts causés par ces derniers s’accumulent. Différentes stratégies de sécurité doivent être mises en place afin de garantir un certain niveau de confort et de sécurité. Dans ce chapitre nous avons présenté ce que c’est qu’un IDS ainsi que les différents types d’IDS. Les IDS peuvent être classifié selon différents critères tels que : la source d’information, la méthode d’analyse, la réponse après détection …etc. Les différents types d’IDS sont appropriés pour des situations et des usages précis. Il existe deux catégories principales d’IDS : le NIDS pour Network based Intrusion Detection System, qui est un IDS qui a pour rôle de surveiller le trafic sur le réseau, et le HIDS pour Host based Intrusion Detection System qui est un IDS chargé de surveiller les machines et les comportements des utilisateurs. Une hybridation entre les deux est en fait possible donnant un résultat plus satisfaisant. Différentes approches de détections existent. L’approche par scénario (souvent utilisée par les NIDS) est la plus simple, elle se base sur un ensemble de signatures des différentes attaques connues. Quant à l’approche comportementale (utilisée par le HIDS), elle analyse le comportement de l’utilisateur et le compare à un comportement préalablement enregistré est défini comme étant normale. Le choix du type d’IDS est basé sur les tests d’efficacité, les besoins en matière de sécurité et enfin les contraintes imposées par les systèmes et les utilisateurs. Un point très
important dans le cas de l’utilisation de différents IDS au sein d’une même
organisation est de gérer les différents formats et modèles. Cette gestion
étant fastidieuse, des modèles communs ainsi que des Frameworks et des langages
ont été mis en place pour standardiser les différents IDS rendant leur
coopération très aisée.
Chapitre II : Systèmes immunitaires. 1. Introduction. 2. Systèmes immunitaires naturels. 3. Systèmes immunitaires artificiels. 4. Les
systèmes immunitaires et les systèmes de détection d’intrusions. Le corps humain est un ensemble de systèmes complexes et très variés, chacun d’eux accomplit une tâche ou une fonctionnalité bien précise. Cet ensemble de systèmes est géré par le cerveau du corps, garantissant ainsi une parfaite communication et gestion des événements. L’étude du corps humain à toujours suscite une très grande attention pour sa grande complexité. Nous nous intéresserons dans le cadre de notre étude à un système très particulier et très important qui est le système immunitaire humain. La complexité du système immunitaire est parfois comparée à celle du cerveau. Durant une longue période, ce dernier est resté une énigme difficile à résoudre pour les biologistes et les chercheurs, et ce n’est qu’avec l’avancée de la microbiologie et la génétique moléculaire que la compréhension de ce système est devenue possible [CAS02a]. Dans ce chapitre nous présenterons les concepts fondamentaux des systèmes immunitaires naturels et les principales théories sur lesquelles est basé le comportement de ces derniers. Puis
nous nous intéresserons aux systèmes immunitaires artificiels qui sont
l’application des systèmes immunitaires naturels pour la résolution de
problèmes complexes. 2. Systèmes immunitaires naturels Le système immunitaire a tout le temps attiré les plus curieux d’entre nous, avec une complicité des différents organes le constituant, il reste jusqu'à nous jour un grand centre d’intérêt des biologistes et chercheurs. Des découvertes voient encore le jour, d’autres sont revues…etc L’étude
du système immunitaire remonte à des milliers d’années avant jésus christ, en
effet les premiers témoignages remontent à 430 AJ, pendant l’épidémie de
fièvre typhoïde qui sévit à Athènes durant la guerre du Péloponnèse, on nota
que seuls les personnes ayant déjà supporté l’infection avaient assez de forces
pour s’occuper des malades. Vers 1960, la communauté scientifique découvrait, grâce aux travaux de Jacques Miller, d’autres caractéristiques fondamentales des cellules immunitaires. En 1989, Charles Janeway propose un modèle selon lequel ce serait l'immunité innée qui serait la véritable gardienne des clefs du déclenchement d'une réponse immunitaire. Le système immunitaire étant très complexe peut être vu sous différents angles. Nous pouvons le considérer en tant qu’un ensemble d’organes, molécules ou cellules. Si nous nous intéressons aux organes du système immunitaire, ce dernier est constitué principalement de: - Moelle osseuse : Lieu de maturation des lymphocytes B. - Thymus : Dans le bas du cou, constitue le site de maturation des lymphocytes T. - Vaisseaux lymphatiques : Transportent la lymphe, les vaisseaux lymphatiques sont situés dans tout le corps. Ainsi que d’autres organes tels que les amygdales, les ganglions lymphatiques et la rate.
Si par contre nous considérons les cellules du système immunitaire, celles impliquées dans la défense sont les globules blancs appelées leucocytes. Ces dernières se trouvent dans le sang et la lymphe. Il existe différents types de globules blancs (leucocytes), les plus importantes sont les lymphocytes. Chez l’homme les lymphocytes représentent 5 à 15% des lymphocytes sanguin [Gar05a] et se compose de : - Lymphocytes B : Les lymphocytes B tirent leur nom de la moelle osseuse chez les mammifères (Bone marrow en anglais). Ils possèdent deux fonctions essentielles : a) Leur activation par un corps étranger induit leur transformation en cellules sécrétrices d'immunoglobulines. b) Les lymphocytes B ont également la capacité de se comporter en cellule présentant le corps étranger . [GAR05B]. - Lymphocytes T : Il existe différentes variantes des lymphocytes T. Leur rôle est d’attaquer les cellules infectées (réponse cellulaire). Les cellules T aideuses sont essentiellement chargées de l’activation des cellules B ; Les cellules T tueuses quant à elles s’attachent aux anticorps et leurs injectent des produits toxiques pour les tuer ; Une autre variante de cellules T, les suppresseurs, qui servent à éviter les réactions immunitaires non appropriées (maladies auto-immune). - Anticorps (immunoglobuline) : On définit un anticorps comme étant une protéine complexe synthétisée par les cellules du système immunitaire en réponse à la pénétration d’un corps étranger (antigène)[SAL09]. Les
anticorps sont dérivés des lymphocytes B et les plasmocytes, ils sont capables
de détecter et de neutraliser des substances étrangères. Il est important de signaler qu’il y a plus de dix millions d'anticorps
différents dans un organisme, ce qui explique leur spécificité.
Substance étrangère, identifiée comme telle par le système immunitaire qui produit des anticorps dirigés spécifiquement contre cette substance. Les antigènes sont généralement des protéines contenues dans des cellules ou des corps étrangers (globules rouges transfusés, organes greffés, bactéries, virus...), ou présentes dans l'environnement (pollens). La réaction antigène-anticorps est la base de l'immunité. Elle assure notre protection contre les infections. Mais cette réaction peut également être nocive lorsqu'elle est disproportionnée ou inappropriée : réaction allergique [Chr08].
FIG 2.1 Structure d’un antigène avec ses épitopes [CAS01]. Le système immunitaire peut aussi être vu en tant qu’ensemble de couches. En effet, la première barrière devant les envahisseurs du corps humain, celle qui constitue le plus important bouclier est en fait la peau. La sueur et le sébum donnent à la peau une certaine acidité (pH 5) ce qui est désavantageux pour la majorité des microorganismes. 2.3 Immunité innée et immunité adaptative La défense de l'organisme contre le milieu extérieur comporte une immunité dite innée ou naturelle, c'est-à-dire existante en absence de tout contact avec un antigène, et une immunité dite adaptative ou acquise, c'est-à-dire apparaissant après contact de l'organisme avec des molécules étrangères qui sont des antigènes [All06]. 2.3.1 Immunité innée L’immunité innée existe depuis la naissance de l’être humain et elle reste invariable tout au long de sa vie. Elle définit les grandes lignes de défenses. Elle est déclenchée en premier lieu dés la pénétration d’un corps étranger, et elle agit sans se soucier du type de ce dernier. L’immunité innée est constituée de la barrière anatomique (la peau et le système respiratoire), les conditions physiologiques telles que le pH, la température ainsi que les cellules tueuses naturelles (NK) [Mou07]. L’immunité adaptative résulte du contact du système immunitaire avec les antigènes grâce à la caractéristique d’apprentissage et mémorisation du système immunitaire qui sera détaillée plus loin. La première intrusion d’un antigène entraine une réponse lente et une réaction difficile du système immunitaire, cependant elle permet de mémoriser l’antigène grâce à ses marqueurs (épitopes) FIG 2.1. Si le même antigène pénètre une seconde fois le corps, la réponse sera plus rapide et bien spécifique avec production d’anticorps particuliers pour cet antigène. Les lymphocytes T, les lymphocytes B et les immunoglobulines constituent les principaux acteurs de l’immunité adaptative. L’immunité adaptative est dite immunité à mémoire [KHE06]. La réponse de l’immunité adaptative est lancée après la réponse de l’immunité innée, les deux types d’immunités sont liées et se complètent. Les deux grandes lignes de défense du système immunitaire étant l’immunité innée et l’immunité adaptative. Chacune emploie un certain nombre de méthodes et met en œuvre des organes complémentaires. Cependant, la plus efficace et plus précise est sans doute l’immunité adaptative (spécifique) qui réagit selon l’antigène en question. Selon le type d’infection, la réponse spécifique se décompose en : Capable de neutraliser les bactéries et les toxines, elle est assurée par le transfert d’humeurs (vaccin ou sérum) d’un patient à un autre (ou d’un animal expérimental à un autre). Généralement l’immunité humorale est utilisée pour les maladies infectieuses [Mou07].
Nécessite le transfert de cellules. L’immunité cellulaire est transmise par des immunoglobulines synthétisées par des cellules [Mou07]. Voici un résumé des différents types de réponses immunitaires avec les principaux acteurs participants à chaque réponse [Aic04] :
FIG 2.2 Différents types de réponses immunitaires [AIC04]. 2.5 Propriétés du système immunitaire 2.5.1 Discrimination entre soi et non soi La plus importante propriété qui est à la base des réactions immunitaires est l’aptitude du système immunitaire à distinguer entre les cellules du soi et les cellules du non soi (étrangères) ainsi que la possibilité de reconnaitre le type exact de chaque cellule étrangère. Ce qui est connue sous le nom du soi ce sont toutes les cellules apprenant au corps humain. Les cellules ont à leurs surfaces des marqueurs permettant de les reconnaitre en tant que cellules ‘inoffensives’. Les cellules du soi en temps normal sont incapables de déclencher une réaction du système immunitaire. Toutes les autres cellules sont considérées comme étant des cellules du non soi et donc le système immunitaire est appelé à réagir contre ces dernières. Cette propriété a été utilisée dans l’élaboration d’algorithmes de reconnaissance de formes [CAS02a], reconnaissance de chiffres [KHE08] …etc. 2.5.2 Apprentissage et mémorisation Comme nous avons pu le voir précédemment, le système immunitaire est évolutif. A chaque contact d’un nouveau genre d’antigènes, le système immunitaire catégorise ce dernier et le garde en mémoire, ceci grâce au mécanisme de division cellulaire suivi d’un processus de sélection afin de raffiner et d’améliorer la réponse du système immunitaire au prochain contact avec le même antigène. Ceci permet au système immunitaire d’augmenter son efficacité pour la reconnaissance d’antigènes, ce processus est appelé la maturation de l’affinité [Bro04]. Un sous ensemble de cellules parmi les cellules qui ont participé à la réponse immunitaire est souscrit avec une durée de vie augmentée créant les cellules mémoires. Ce processus est appelé maturation de la réponse immunitaire, il est à l’origine de la rapidité et de l’efficacité des réponses suivantes. 2.5.3 Communication et diffusion Les différents acteurs du système immunitaire ont besoin d’échanger des messages sous forme de signaux. Deux types de dialogues existent, des signaux à sens unique (sans feedback) transitant par des composantes immunologiques ou des dialogues continus par un échange de signaux moléculaires [MAN04]. Le système immunitaire a la faculté de générer de nouvelles molécules et cellules par des processus tels que la division cellulaire ou l’hyper mutation somatique ou de se débarrasser des cellules invalides (vielles ou peu utilisées) [KOU07]. L’auto-organisation caractérise un processus au cours duquel une structure émerge au niveau global uniquement à partir d’un grand nombre d’interactions entre ses composants de niveau local du système. De plus, les règles qui spécifient les interactions entre les composants du système immunitaire sont prises en utilisant uniquement des informations locales, sans référence à la structure globale [DRE03]. Le système immunitaire avec toute sa complexité, ne contient pas de point central de contrôle, chaque cellule est stimulée et répond à l’antigène attaquant. 2.6 Théories immunitaires Le comportement et les réactions du système immunitaire sont principalement régit par des théories immunitaires. 2.6.1 Théorie de la sélection Négative/Positive Cette
théorie gère le processus de création des lymphocytes. Plus précisément, cette
théorie gère le processus de création au niveau de la discrimination entre soi
et non soi. Le test en question consiste à vérifier si les nouveaux récepteurs s’attaquent aux cellules du soi, dans ce cas lymphocytes sont détruits et purgés de la population des nouveaux lymphocytes, on parle de sélection négative. Le reste de la population est autorisé à quitter le thymus pour circuler dans le sang et effectuer leurs taches de surveillance.Ce processus est illustré par la figure suivante :
FIG 2.3 Processus de sélection Négative/Positive [CAS03]. 2.6.2 Théorie de la sélection clonale Une autre théorie tout aussi importante que la sélection négative st la théorie de la sélection clonale. Cette théorie a été exposée en 1959 par Burnet [CAS03b]. Elle met en avant la réaction du système immunitaire à une stimulation antigénique [CAS02a]. La théorie de la sélection clonale explique les deux processus de prolifération et de maturation d’affinité. L’idée de cette théorie est la suivante : Des la reconnaissance d’un antigène par les lymphocytes B, ces derniers produisent des anticorps spécifiques (chaque cellule sécrète un seul type d’anticorps). L’anticorps s’associe à l’antigène à l’aide des récepteurs (épitopes-paratopes) puis à l’aide des cellules telles que les T aideuses, les cellules B sont stimulées et un processus de prolifération (division cellulaire) permet aux cellules B de se reproduire en créant des clones d’elles mêmes [CAS02b]. Un second processus permettra de sélectionner parmi les nouvelles cellules celles présentant une grande affinité afin d’en faire des cellules mémoires [Hof04].
FIG 2.4 Processus de sélection clonale [CAS02a]. Les cellules mémoires circulent à travers le sang, la lymphe et les tissus, et à la présence d’un antigène précédemment reconnu, une réaction rapide et efficace est immédiatement lancée [cas99]. Cette théorie est particulièrement utilisée dans les domaines tels que l’optimisation, la reconnaissance de formes et l’apprentissage-machine (intelligence artificielle).
Proposée initialement par Polly Matzinger, cette théorie est une nouvelle vision qui diffère de l’approche classique. La théorie du danger gère le comportement du système et sa réaction selon les nouvelles conditions suivantes : - Le système immunitaire ne doit pas réagir contre le soi, sauf si ce dernier est dangereux. - Le système immunitaire réagit contre le non soi, sauf si ce dernier n’est pas dangereux. Nous constatons que dans la théorie du danger il ya une corrélation entre les signaux d’alarmes. Il ne suffit pas de détecter les cellules étrangères, il faudrait également savoir si ces dernières sont dangereuses ou pas [AIC03]. 2.7 Déroulement d’une réponse immunitaire Dés la pénétration d’une substance étrangère (antigène), elle se fait phagocyter (englober et digérer) par un macrophage qui lui extrait des fragments (peptides antigéniques) et les exposes à sa surface sur sa membrane avec l’aide des molécules de présentation, les molécules HLA du système d’histocompatibilité. Cette présentation sur la membrane permet la reconnaissance de la substance par les lymphocytes T FIG 2.5. Chaque lymphocyte T ne reconnait qu’un seul type d’antigène ce qui identifie une réponse spécifique (immunité innée) qui est lente à se déclencher mais très efficace.
FIG 2.5 Déroulement d’une réponse immunitaire [cas99].
Les lymphocytes T auxiliaires sont activés et sécrètent des cytokines qui se comportent comme des facteurs de croissance permettant la multiplication des lymphocytes T et B ou des facteurs de différentiation permettant de produire des anticorps (réponse humorale) ou des facteurs d’activation permettant d’activer des cellules (réponse immunitaire cellulaire). Certains de ces lymphocytes T auxiliaires constituent des cellules mémoires. 3. Systèmes immunitaires artificiels Les travaux sur les SIA ont [BOR05] dans le milieu des années 80 avec l'article de Farmer, Packard et Perelson sur les réseaux immunitaires (1986). Cependant, c'est seulement dans le milieu des années 90 que les SIA devinrent un sujet à part entière. Les travaux de Forrest sur la sélection négative commencèrent en 1994, tandis que Dasgupta menait des études sur les algorithmes de sélection négative. Hunt et Cooke commencèrent leurs travaux sur les modèles de réseaux immunitaires en 1995. Timmis et Neal continuèrent ces travaux en y apportant des améliorations. Le premier livre sur les Systèmes Immunitaires Artificiels a été ecrit par Dasgupta en 1999. Les travaux de De Castro & Von Zuben et Nicosia & Cutello sur la sélection clonale (CLONALG) furent remarqués en 2002. De nouvelles voies, comme la théorie du danger (observation des dégâts plutôt que celle des agents pathogènes) et des algorithmes inspirés par le système immunitaire inné ont également été explorées. Le fait qu'elles apportent quelque chose de nouveau au delà des algorithmes existants est actuellement le sujet de débats qui animent le développement des AIS. Au départ, les travaux sur les AIS visaient à trouver des abstractions efficientes des phénomènes découverts dans le système immunitaire. Plus récemment, les praticiens des AIS se sont aussi intéressés à la modélisation du système immunitaire et à l'application des résultats issus des SIA aux problèmes d'immunologie (ce qui entre dans le cadre de l'immuno-informatique) [DAS03]. Les systèmes immunitaires artificiels sont une nouvelle branche de l’intelligence artificielle. Destinés à résoudre des problèmes divers, inspiré des propriétés et concepts remarquables du système immunitaire biologique [Cas01]. Les systèmes immunitaires artificiels sont une implémentation mathématique ou informatique du fonctionnement du système immunitaire naturel. Cette implémentation reprend les plus grandes lignes de son fonctionnement. Cependant il reste presque impossible de modéliser le comportement complet des systèmes biologiques. Voici quelques définitions des AIS : - Les AIS sont composés de méthodes dotées ‘d’intelligence’ inspirées des systèmes immunitaires naturels pour la résolution des problèmes réels. Quel qu’il en soit, ce sont toujours les propriétés remarquables du système immunitaire naturel à savoir la robustesse, la diversité, l’auto-organisation, l’autonomie, la discrimination, l’apprentissage …etc. qui ressuscite toute l’attention des chercheurs [Bro04]. Pour la conception des systèmes immunitaires artificiels, les chercheurs essaient au mieux de représenter ce fonctionnement avec les moyens techniques disponibles (outils de modélisation, langages de programmation, méthodes mathématiques …etc.). 3.3. Modélisation des systèmes immunitaires artificiels Les travaux dans ce domaine sont confrontés à quelques inconvénients pour les causes suivantes : - Le nombre de personnes actives dans ce domaine de recherche reste très limité. - Les applications des systèmes immunitaires artificiels sont très variées, il est difficile d’apporter une solution globale ou des algorithmes génériques. Ce n’est que récemment qu’un modèle commun a été mis en place pour la représentation de ces systèmes. Ce modèle a facilité énormément la tâche aux développeurs et aux chercheurs [CAS03]. Le modèle commun connu sous le nom du Framework des systèmes immunitaires artificiels, définit les règles que doit respecter un AIS ainsi que les processus à suivre pour l’élaboration de nouvelles approches. Les conditions nécessaires sont : - La représentation des composants du système. - Un ensemble de mécanismes pour l’évaluation de l’interaction entre les individus et leurs environnements. - Des procédures d’adaptation pour contrôler l’évolution du système. Les trois conditions citées ci-dessus sont impératives pour l’élaboration d’un framework pour définir un système immunitaire artificiel. Le schéma suivant FIG 2.6 représente le modèle abstrait pour créer un framework pour les AIS, mettant en œuvre les organes et molécules du système immunitaire naturel. Un ensemble de fonctions d’affinité et des fonctions quantitatives des interactions entre les différents composants sont également à prévoir.
FIG 2.6 Framework pour les systèmes immunitaires artificiels [BRO04]. Ce sont principalement les cellules et les molécules du système immunitaire biologique qui seront utilisées pour modéliser le comportement du système immunitaire artificiel. Comme nous l’avons vu précédemment, les principales cellules sont les lymphocytes B et T, ces dernières sont connues pour avoir sur leurs surfaces des récepteurs (paratopes) capables de reconnaitre des antigènes par la propriété de complétude avec leurs épitopes [Bro04]. Cette notion de complétude épitopes-paratopes est très importante pour donner une description quantitative de l’interaction antigène-anticorps, proposée par Perelson & Oster en 1979 et connue sous le nom d’espace de formes [Cas01]. On peut voir la forme d’un anticorps comme un ensemble de L paramètres. Ces paramètres peuvent être représentés par un point dans un espace de L dimensions. Un premier constat est que dans ce plan, les anticorps qui ce ressembles sont proches les uns des autres.
FIG 2.7 Espace des formes [CAS01]. Une population ou un répertoire de N individus (récepteurs) est modélisé comme un espace de formes d’un volume fini V contenant N points. Donc un antigène est représenté par un point Ag=<Ag1, Ag2,… , AgL>, un anticorps est à son tour représenté par un point Ab=<Ab1,Ab2,…,AbL> FIG 2.7. Pour mesurer le degré de complétude entre l’antigène et l’anticorps FIG 2.8, plusieurs techniques peuvent être utilisées. Le plus souvent on recourt à l’utilisation des distances. Différentes distances existent dont voici les plus utilisées [GHA06] :
FIG 2.8 Différentes distances pour le calcule d’affinité anticorps-antigène [KOU07]. Donc on remarque bien que l’affinité anticorps-antigène est relative à la distance dans cet espace entre ces derniers. En effet, plus la distance antigène-anticorps est petite, plus l’affinité entre ces derniers est plus grande FIG 2.9.
FIG 2.9 Principe de complémentarité entre antigène et anticorps [BRO04]. Une fois les antigènes et anticorps représentés, la fonction quantitative du degré de complétude (affinité) entre eux définie et l’espace des formes connue, il ne reste plus qu’a implémenter les théories immunitaires vues plus hauts. Les principales théories immunitaires sont la théorie de la sélection clonale, la théorie de la sélection négative/positive et la théorie du danger. La théorie du danger quant à elle est moins utilisée dans le domaine de détection d’anomalies, pour la simple raison qu’elle soit non déterministe. Il existe d’autres théories telles que la théorie des réseaux immunologiques mais qui sont utilisées dans d’autres domaines et contextes que celui de la sécurité informatique. Il existe différentes utilisation des théories immunitaires selon le contexte et le problème à résoudre. 3.4.1. Algorithme de la sélection clonale Comme nous avons pu le voir dans les sections précédentes, cette théorie se base sur le principe que seules les cellules ayant reconnu l’antigène prolifèrent et maturent et deviennent des cellules mémoires. Il existe différentes utilisations de la théorie de la sélection clonale selon les contextes, que ce soit dans l’apprentissage-machine, la reconnaissance de formes, l’optimisation multi modale ou la détection d’anomalies [CAS00b], les implémentations de cette théorie reprennent les principales étapes du déroulement de cette dernière. Les deux algorithmes les plus connues sont CLONALG et CLONCLAS CLONALG initialement appelé CSA (Clonal Selection Algorithm) est basé sur les éléments suivants : - Maintient d’un ensemble de cellules mémoires. - Sélection et clonage des anticorps les plus stimulés. - Re-sélection des clones proportionnellement à l’affinité avec l’antigène. - Suppression des anticorps non stimulés. - Maturation de l’affinité de ces derniers [Bro04]. Cet algorithme s’exécute en trois étapes et qui sont :
Initialisation
-
Sélectionner un antigène a de
l’ensemble des Ags. -
Pour chaque anticorps c de l’ensemble
des anticorps Abs, calculer son affinité avec a. -
Sélectionner les n meilleurs anticorps
selon leurs affinités. -
Cloner les n meilleurs anticorps. -
Appliquer le processus de maturation de
l’affinité sur les clones pour augmenter leur degré de correspondance avec
l’antigène a. -
Exposer les clones de nouveau à l’antigène a
et recalculer leurs affinités. -
Les meilleurs clones seront placés dans m. -
Les r anticorps de N les plus faibles
seront remplacés par d’autres générés aléatoirement.
Fin
3.4.2. Algorithme de la sélection négative/positive Initialement utilisée dans le domaine de la sécurité informatique. L’idée principale sur laquelle se base cette théorie est que seules les cellules T qui ne s’attaquent pas aux cellules du soi sont autorisées à quitter le thymus et auront pour tâche de reconnaitre les cellules du non soi. Cette notion est très intéressante, surtout pour les applications de surveillance des systèmes et la détection d’utilisations anormales ou inhabituelles [CAS03]. Forrest et al (1994) comparent le problème de protection des systèmes informatiques au problème d’apprentissage de la distinction entre soi et non soi. Plus exactement, ils comparent le problème de détection des changements au sein des systèmes au processus de sélection négative ayant lieu au niveau du thymus [CAS00c]. Développée en 1994, une méthode de détection d’anomalies basée sur la sélection négative des cellules T dans le thymus, cette méthode ainsi que toutes les autres méthodes utilisant l’algorithme de sélection négative se déroulent en deux phases Phase 1 : Génération d’un ensemble de détecteurs. Phase 2 : Mise en place des détecteurs, afin de surveiller les données. FIG 2.9. Pour la comparaison, on calcule le nombre de bits en communs entre une donnée et un détecteur, s’il est supérieur à un seuil r on dit qu’il y’a correspondance entre les deux. Voici un résumé de l’algorithme de sélection négative/positive [CAS00c].
FIG 2.9 Algorithme de sélection Négative/Positive en deux phase [CAS00c].
Afin de résumer l’algorithme, De Castro [CAS03b] a proposé le pseudo code suivant
3.5. Les systèmes immunitaires et les systèmes de détection d’intrusions L’étude des systèmes immunitaires pour la sécurité informatique a aboutit à un ensemble de propriétés très intéressantes que peut satisfaire un système immunitaire pour les besoins en sécurité informatique. Ces propriétés ont été utilisées pour la première fois dans des travaux de recherches par Kim et Bentley en 1999. Ces travaux consistaient à définir un système immunitaire artificiel pour les systèmes de détection d’intrusions. Plusieurs tentatives de conception de systèmes immunitaires artificiels ont été fait bien avant, mais ces derniers se résumaient à des tentatives d’implémentation d’un sous ensemble très réduit du système immunitaire humain [KIM02a]. 3.5.1. Caractéristiques d’un IDS Il est important de rappeler les fonctions ou propriétés fondamentales très importantes que doit satisfaire un IDS. Une fois ces propriétés énumérées nous essaierons de voir en parallèle ce qu’offrent les systèmes immunitaires artificiels et faire l’analogie entre les deux. Tout IDS doit être [CAS04]: - Robuste : L’IDS doit avoir différents points de détection et doit être très résistant aux attaques. - Configurable : L’IDS doit s’auto configurer facilement en fonction de chaque machine sur laquelle il sera déployé. Le degré de dépendance envers le système d’exploitation doit être réduit au minimum. - Extensible : L’ajout de nouveaux hôtes dans l’ensemble des machines à surveiller doit être élémentaire et aucune dépendance envers les systèmes d’exploitation ne doit être un obstacle devant cette extension. - Augmentable : Il est nécessaire que l’IDS puisse faire face à une augmentation inattendue du flux des données à surveiller due à une extension de l’ensemble des hôtes constituants l’IDS. - Adaptable : L’IDS doit s’adapter dynamiquement aux changements (matériels ou logiciels) au sein du réseau en question. - Efficace : L’IDS doit être léger et simple à déployer pour ne pas affecter les performances des hôtes et réseau à surveiller. - Distribué : Des attaques particulières ne peuvent être détectées qu’après analyse de différents signaux et alarmes en provenance de différents hôtes [KIM07]. L’IDS doit être en mesure de récupérer différents événements issues de différentes stations du réseau, analyser ces derniers et envoyer les réponses aux différentes stations. Afin de développer un IDS performant nous essaierons de retrouver les propriétés précédemment évoquées dans un système immunitaire artificiel. 3.5.2. Propriétés des AIS pour la détection d’intrusion Le système immunitaire est capable de protéger le corps humain face à des bactéries, virus ou antigènes de tout genre. Ce rôle fondamental est principalement basé sur la discrimination entre soi et non soi. Cette discrimination est le processus clé constituant une réponse immunitaire. Que ce soit des antigènes connus ou non, le système immunitaire naturel peut être comparé à un détecteur d’anomalies avec un nombre très réduit de faux positifs et faux négatifs. Plusieurs études ont été faites sur les systèmes immunitaires dans le but de comprendre les mécanismes fondamentaux de ces derniers et essayer de fournir des processus et des méthodes pour le développement de nouvelles solutions dans différents domaines et particulièrement dans la détection d’intrusions réseaux. Les trois plus importantes propriétés d’un IDS ont été retrouvées dans les systèmes immunitaires. En effet les systèmes immunitaires sont [ZIE00]: - Distribués : Le fonctionnement du système immunitaire est distribué sur un réseau immunitaire et un ensemble d’anticorps uniques, accomplissant chacun des tâches bien précises. -
Auto-organisés :
Le système immunitaire est principalement fondé sur trois éléments : les
librairies des gènes, sélection négative et enfin la sélection clonale. - Légers : Grâce aux fonctions d’approximations dans le cas d’attachement (antigènes-anticorps). En effet, il n’est pas obligatoire que l’anticorps soit le complément exact de l’antigène pour qu’il puisse le reconnaitre. La protection des systèmes informatiques contre les attaques de virus ou d’utilisateurs mal intentionnés a été comparée par Forest et al en 1994 au problème de discrimination entre soi et non soi. Ils ont comparé l’approche comportementale dans les systèmes de détection d’intrusions au processus de sélection négative ayant lieu au niveau du thymus. Cette étude a donné naissance à un algorithme de sélection négative. L’algorithme se déroule en deux phases FIG 2.9. La première consiste à générer un ensemble de détecteurs et la seconde consiste à utiliser ces détecteurs afin de surveiller des données en procédant à une comparaison. La comparaison peut être une comparaison du nombre de bits en communs [CAS00c]. La génération des détecteurs est très importante. Au cours de cette génération, il est impératif de supprimer les détecteurs qui s’attaquent aux cellules du soi (sélection négative). Les auteurs de cet algorithme ont également mis en place une équation pour l’estimation de probabilité que deux chaines aléatoires se ressemblent à un certain degré (r bits continus). Cet algorithme est très intéressant dans le cas d’un IDS utilisant l’approche comportementale en nous basant sur un profil du comportement normal de l’utilisateur préalablement enregistré [QIA07]. 3.5.3. Systèmes immunitaires et algorithmes immunitaires Une fois que nous avons retrouvé les propriétés nécessaires pour notre IDS et le choix de l’utilisation des systèmes immunitaires a été fait. Il est intéressant d’avoir une méthode pour la création des algorithmes constituants notre AIS. Une comparaison entre les composants des systèmes immunitaires et leurs équivalents dans les algorithmes immunitaires, nous permet de concevoir facilement les algorithmes composants notre système immunitaires artificiel.
TAB 3.1 Comparaison systèmes immunitaires et algorithmes immunitaires [QIA07]. En suivant ce processus nous pouvons développer n’importe quel algorithme immunitaire. Cette comparaison s’applique aux différents problèmes, nous ne nous intéresserons qu’à la conception d’un système de détection d’intrusions inspiré des systèmes immunitaires.Kim & Bentley ont proposé en 1999 une comparaison plus adaptée aux IDS qui est la suivante :
TAB 3.2 Comparaison entre systèmes immunitaires et systèmes de détection d’intrusions [QIA07]. Sur la base de cette comparaison, ils ont proposé un système immunitaire artificiel pour la détection d’intrusion
FIG 2.10 Système immunitaire artificiel pour la détection d'intrusions Ce système immunitaire artificiel, consiste en un IDS primaire qui joue le rôle de superviseur et de plusieurs IDS seconds qui seront installés sur chaque hôte du réseau FIG2.10. Le fonctionnement de cet IDS modèle est le suivant : L’IDS primaire qui est comparable au thymus et à la moelle osseuse, il a pour rôle de générer un ensemble de détecteur. Chaque ensemble de détecteurs est capable de reconnaitre un certain type d’intrusions réseau. Ces détecteurs sont ensuite transférés sur chaque IDS second (hôte local) et sont exécutés en tant que services du système d’exploitation. Ces processus sont exécutés en permanence afin de surveiller le flux des événements arrivants à l’hôte et détecter un certain type d’attaques.
3.5.4. Génération des détecteurs Le processus de surveillance utilisant l’approche comportementale essaie en permanence de comparer à l’aide des détecteurs le comportement actuel de l’utilisateur avec un profil déjà enregistré. Il est nécessaire d’avoir un format commun pour les détecteurs, ce format doit être normalisé afin de couvrir la majorité des attaques possibles. Dans la phase d’apprentissage, et en parallèle avec la création du profil, un apprentissage concernant les détecteurs doit être mis en place comme suit : - Définir le nombre d’éléments constituant le détecteur (longueur du détecteur). - Définir le type de chaque élément (Valeur discrète, continue, moyenne …etc). Ces deux points sont primordiaux dans la création d’un détecteur. Une fois que les éléments constituant le détecteur ont été énumérés avec le type de chacun d’entres eux, la dernière étape sera de définir les valeurs de chaque élément du détecteur comme suit : - Si l’élément est de type discret, l’élément sera représenté par une valeur unique. - Si l’élément est de type continu, il sera représenté par un intervalle défini par deux bornes. Une fois les éléments ainsi que leurs valeurs respectives ont été énumérés, le détecteur sera représenté par une structure de données contenant ces éléments [KIM02a]. 3.5.5. Détection d’anomalies et détection par scénario Après la création de l’ensemble des détecteurs, la deuxième étape consiste à mettre en œuvre ces détecteurs afin de surveiller le comportement de l’utilisateur. Cette surveillance se résume à une comparaison du comportement courant de l’utilisateur avec les détecteurs. La comparaison est très simple. Proposée par Forrest pour la première fois, cette dernière n’est en fait que la comparaison du nombre continu de bits en communs comme suit : - Dans le cas d’élément à valeur discrète, on dit que les deux éléments sont égaux, s’ils ont exactement la même valeur. - Dans le cas d’élément à valeur continue, on dit que les deux éléments sont égaux, si la valeur du comportement courant de l’utilisateur est incluse dans l’intervalle du détecteur. Pour conclure qu’un certain comportement correspond à un détecteur, nous comptabilisons le nombre d’éléments communs entres eux et nous le comparons à un certain paramètre donné r. Cette fonction de comparaison est toujours la même depuis la première proposition de Forrest en 1994 [KIM02a]. Nous avons vu que pour la détection comportementale il est favorable d’utiliser la théorie de sélection négative. Cependant pour la seconde approche (détection par scénario) et qui est basée sur un ensemble de signatures, nous utiliserons la théorie de sélection clonale comme suit : Dans l’approche de détection par scénario, nous disposons d’une base de données contenant l’ensemble des signatures d’attaques connues. Sur la base de ces signatures nous générerons des détecteurs permettant, après analyse des paquets de détecter la présence de certaines signatures afin de conclure qu’une intrusion ou une tentative d’intrusion s’est produite. Le choix de la théorie de la sélection clonale pour l’approche par scénario a été fait car dans ce processus, cette théorie permet de générer des anticorps et de les perfectionner pour la détection d’antigènes connus. On peut donc comparer dans la théorie de sélection clonale, les anticorps aux détecteurs et les antigènes connus aux signatures d’attaques [KIM02b]. Donc, pour conclure voici l’usage le plus fréquent des théories immunitaires pour la conception des systèmes de détection d’intrusions : NIDS
avec détection par scénario : Théorie de la
sélection clonale L’immunité a été durant une longue période un mystère, on ignorait le rôle et le fonctionnement exact de ce système. Vers les années soixante, ce domaine complexe est devenu un grand centre d’intérêt pour les biologistes et les chercheures, et les plus grandes questions trouvèrent vite des réponses. Dans ce chapitre nous avons abordés les concepts fondamentaux du système immunitaire naturel à savoir les organes le composant (thymus, moelle osseuse) ou ses cellules (lymphocytes, macrophages). Nous avons vu le rôle de chacun de ces composants, ainsi que l’interaction qui existait entre eux afin de former les deux grandes lignes de défense, connues sous le nom d’immunité innée et adaptative. Pour l’immunité adaptative, les deux méthodes de réponse sont l’immunité humorale basée sur le transfert d’humeur, et l’immunité cellulaire basée sur des cellules. Les différentes lignes de défense ainsi que leurs différents mécanismes opèrent ensemble afin de maintenir un équilibre et une certaine sécurité au corps humain. Ceci grâce aux propriétés très intéressantes du système immunitaire telles que l’auto-organisation, l’apprentissage, la discrimination entre soi et non soi, la distributivité …etc. Le fonctionnement de ce système est basé sur des théories telles que la sélection clonale et la sélection négative, qui après plusieurs études, ont donné naissance aux systèmes immunitaires artificiels. En effet les systèmes immunitaires artificiels sont une implémentation du système immunitaire biologique, essayant de modéliser son fonctionnement afin de trouver des solutions à des problèmes tout aussi variés que complexes. Les propriétés des systèmes immunitaires artificiels sont très intéressantes, surtout pour la détection d’intrusions. D’une part, une très grande ressemblance fonctionnelle existe entre les deux systèmes de détection d’intrusions et les systèmes immunitaires. D’autre part, les principales caractéristiques des systèmes de détection d’intrusions ont été toutes retrouvées parmi l’ensemble des propriétés des systèmes immunitaires. Afin de concevoir un système de détection d’intrusions, basé sur des systèmes immunitaires artificiels, nous avons besoins d’outils informatiques appropriés aux besoins et aux contraintes de ces derniers. Les outils utilisés doivent nous permettre de modéliser l’architecture hiérarchique et faciliter les différentes interactions entres les sous systèmes de notre IDS qui doivent être distribués. Le prochain chapitre sera consacré
à un outil très important qui permet de concevoir ce genre de solutions
distribuées. L’outil en question est un nouvel axe de programmation : les
systèmes multi-agents. Chapitre III : Systèmes multi-agents 4. Les systèmes multi-agents et les systèmes de détection d’intrusions. Pendant une longue période, l’informatique se résumait à des applications s’exécutant sur des machines. Cette façon de voir les choses répondait autrefois à la majorité des attentes des utilisateurs. Connue sous le nom de la première génération de l’informatique, les ordinateurs avaient pour tâches d’exécuter des calculs ou des applications que les êtres humains avaient l’habitude de faire (calculs, gestion de stock, calcul de paie…etc.) [BRI01]. Petit à petit, les machines évoluaient et commençaient à s’identifiaient aux humains, en essayant de réaliser des tâches plus appropriées aux humains. A partir des années 80, des problèmes plus complexes, des contraintes plus grandes apparurent, et l’approche utilisée précédemment ne répondait plus aux besoins. Les problèmes appropriés aux humains, impliquent d’autres règles telles que la coopération, l’apprentissage et le partage des connaissances. Ce savoir peut être distribué sur une communauté de personnes. A titre d’exemple, pour la conception de machines évoluées, les personnes s’organisent de façon à faire appel à différentes compétences (mathématiciens, informaticiens, designers, gestionnaires …etc.). Cette approche de concevoir des systèmes a inspiré une nouvelle branche très récente de l’intelligence artificielle distribuée : Les systèmes multi-agents (SMA), qui sont des systèmes utilisant des entités intelligentes (agents) autonomes qui travaillent en coopération pour atteindre un objectif donné. Cette approche a été enrichie par des métaphores afin d’implémenter au mieux le comportement des sociétés d’humains. Malgré les efforts dans ce domaine, cette technologie reste très compliquée et très difficile à mettre en place. Nous aborderons dans ce chapitre les concepts fondamentaux d’agents, les différentes définitions, caractéristiques, différentes architectures et les principaux types d’agents. Ensuite nous verrons les systèmes multi-agents (SMA), leur émergence de l’intelligence artificielle distribuée et leurs domaines d’applications. Nous aborderons également les concepts d’agents au sein des sociétés, les nouvelles contraintes et les nouvelles fonctionnalités issues d’une coopération entre les différents agents constituant la société. Nous verrons vers la fin l’intérêt des SMA, les points forts de ces systèmes et les nouveautés apportées par ces derniers. Le plus important par la suite est la comparaison entre les systèmes multi-agents et les systèmes de détection d’intrusions ainsi que les raisons pour lesquelles nous avons opté pour le choix de cette solution pour concevoir notre propre IDS basé sur les systèmes immunitaires. Les ‘agents’ sont les principaux composants des SMA. chacun d’entre eux est une entité autonome chargée d’accomplir une tâche bien précise. Les deux grandes branches de l’informatique ‘moderne’ sont sans doute la programmation orientée objets POO et la programmation orientée agents POA. Voici les principales différences entre les deux approches [Ada08]: ü Un agent est un objet qui est adaptatif, rationnel, autonome, capable de communiquer et d’agir. ü Un agent logiciel est de préférence créé sous forme d’un objet ayant les caractéristiques d’un processus. ü Un objet o1 peut appeler une méthode existante d’un objet o2 qui doit l’exécuter. ü Un agent a1 peut demander l’exécution d’une méthode à l’agent a2 qui est libre de l’exécuter ou pas. ü Un agent agit en fonction de son but, de ses contraintes et de ses capacités. Ces points font la différence entre agents et objets, et c’est sur ces bases que se fait le choix de l’approche à utiliser selon la problématique. Plusieurs définitions d’agents existent, les définitions diffèrent selon le domaine d’utilisation et les caractéristiques des systèmes. Le terme « Agent » est utilisé de manière assez vague, cependant quelques définitions précises existent dont voici quelques unes : Ø Un agent est un système informatique situé dans un environnement qu’il peut percevoir et sur lequel il peut agir de manière autonome. FIG 3.1 [BOI02]. Ø Un agent est une entité logicielle ou physique à qui est attribuée une certaine mission qu’elle est capable d’accomplir de manière autonome ou en coopération avec d’autres agents [BRI01]. Ø Un agent est une entité physique ou virtuelle [Fer95]. · capable d’agir dans un environnement, · pouvant communiquer directement avec d’autres agents, · Régie par un ensemble de tendances (sous la forme d’objectifs individuels ou d’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser), · possédant des ressources propres, · capable de percevoir (mais de manière limitée) son environnement · Ne disposant que d’une représentation partielle de cet environnement (et éventuellement aucune) · possédant des compétences et offrant des services · pouvant éventuellement se reproduire · dont le comportement tend à satisfaire ses objectifs, en tenant compte des ressources et des compétences dont il dispose, et en fonction de sa perception, de ses représentations.
Ø Une entité devient un agent aussitôt qu’elle est capable d’exercer un contrôle local sur ses processus de perception, de communication, d’acquisition de connaissances, de raisonnement, de prise de décision ou d’exécution [Pic04].
FIG 3.1 : Un agent dans un environnement [BOI02]. Nous retrouvons parmi les caractéristiques des agents, quelques caractéristiques de base telles que la communication ainsi que d’autres caractéristiques bien particulières aux agents, telles que la sociabilité, la réactivité …etc. La communication est une caractéristique essentielle des agents. Elle est également la base de la coopération entre agents. Un agent peut demander un service auprès d’un autre agent en lui envoyant des messages [Bar03]. Cette caractéristique est la base du comportement social des agents. Cependant, des difficultés majeures existent en termes de standards et langage de communication …etc. Les agents ont la capacité d’apprendre tout au long de leur existence. Cet apprentissage leur permet d’évoluer et même de changer leurs comportements [BOI01b]. L’agent s’exécutant dans un processus à part est toujours actif, et il n’a pas besoin d’une intervention humaine pour l’exécuter [BOI01e]. L’agent doit être autonome, il doit agir seul et seulement en fonction des signaux qu’il reçoit des autres agents ou de l’environnement. Il gère son état interne en fonction de ces informations [Pic04]. Généralement les agents sont organisés en communautés. Une communauté impose des relations entres ses constituants. De ce fait, les agents sont amenés à négocier, coopérer pour la résolution de problèmes. La sociabilité est basée sur des interactions entres agents, qui se font grâce à des standards de communication qui seront détaillés par la suite [BOI01f]. Cette propriété se résume au fait que l’agent réagit en fonction de ce qui se passe dans son environnement. L’agent possède des capteurs (senseurs) lui permettant de recevoir des informations de l’environnement ou des autres agents, et en fonction de ces informations il peut agir via des actionneurs (effecteurs) FIG 3.1. Un agent peut également réagir en fonction de ce qu’il doit accomplir, ce type d’agents est doté d’une certaine intelligence et connu sous le nom d’agents cognitifs et sera détaillé par la suite. La structure d’un agent est parfois complexe. C’est cette structure qui lui permet d’accomplir les buts pour lesquels il a été créé, de réagir en fonction des événements et d’interagir avec les composants de son système (des ressources ou avec d’autres agents). Dans une architecture d’agents, on retrouve les paramètres généraux tels que : le type d’approche, structures de subordination …etc. Différentes architectures existent telles que l’architecture à base de modules horizontaux, de taches compétitives et les architectures connexionnistes [Fer95]. Nous ne nous intéresserons qu’à l’architecture modulaire horizontale. L’Architecture modulaire horizontale est sans doute la plus répondue, que ce soit pour des travaux théoriques ou des applications pratiques. La principale architecture pour définir les agents cognitifs est fondée sur la notion d’ensembles de modules horizontaux liés entres eux. Les architectures modulaires sont conçues comme un assemblage de modules réalisant chacun une fonction horizontale particulière. Voici quelques uns des modules les plus courants Ø Les fonctions perceptives. Ø L’émission et l’interprétation des communications. Ø La base de croyances comprenant la modélisation de l’environnement et des autres agents. Ø La gestion des engagements…etc.
FIG 3.2 : Représentation caractéristique d’un agent à architecture modulaire horizontale [FER95]. Il est important de noter que dans de pareilles architectures, les liaisons sont préalablement définies, (c.à.d. le mode de circulation des informations est prédéfini par le concepteur). Nous remarquons clairement dans la figure FIG 3.2 les connexions existantes entre les différents modules de l’architecture de cet agent. En fonction de ce que perçoit l’agent comme situations, il peut réagir. S’il s’agit d’une situation familière pour l’agent, pour laquelle il connait ‘parfaitement’ l’action à effectuer il s’agit d’un agent réactif. Par contre, si cette situation est familière pour l’agent mais il lui faut un certain ‘raisonnement’ pour la résoudre, il s’agit dans ce cas là d’un agent cognitif [DAS03]. Ce type d’agents se caractérise par le fait qu’il n’on pas de représentation de leur environnement, ni du monde auquel ils appartiennent. Ces agents sont les plus simples à mettre en œuvre du fait qu’ils se comportent selon le stimulus. L’agent sera programmé sous forme de couples « Stimulus/Réponse » [Pic04]. Généralement les agents réactifs sont considérés comme non ou peu intelligents, et nous considérons que l’intelligence émerge de la coopération des différents agents. Ces dernier sont de plus bas niveau et n’ont qu’un protocole et un langage de communication réduit [BRI01].
FIG 3.3 : Un agent réactif [BOI01f]. Selon les défenseurs de cette approche, il n’est pas nécessaire que les agents soient intelligents pour que le système ait un comportement global intelligent. Les meilleurs exemples de ce genre de systèmes constitués d’entité de faible intelligence mais dont la coopération conduit à des systèmes très intelligents, sont les sociétés d’insectes (Fourmies). A l’inverse des agents réactifs, les agents cognitifs sont en général dotés d’une certaine intelligence et une parfaite représentation de l’environnement et du monde auquel ils appartiennent. Les sociétés d’agents cognitifs sont généralement constituées d’un petit nombre d’agents. Ces agents sont semblables à des systèmes experts et sont des agents communicants [DEM93]. Ces
agents ont une représentation très précise de leur environnement. Chaque agent
possède des connaissances comprenant des informations et du savoir faire.
FIG 3.4 : Un agent cognitif [COU05]. Les agents cognitifs sont donc intéressants individuellement et collectivement pour leur intelligence. Par contre l’intérêt des agents réactifs est uniquement l’interaction avec les autres agents, et l’exécution de tâches précises et élémentaires. [Pic04]. 2.6 Standards de communication Vu le grand nombre d’interactions entres les agents, et vue la diversité fonctionnelle des agents, un standard de communication s’impose afin de normaliser les messages et les signaux entre agents. Il ya eu plusieurs propositions pour les langages de communication [Ada08]: ü KIF : Knowledge Interchange Format (Langage formel de dialogue interne) Basé essentiellement sur la logique du premier ordre, ce langage permet d’exprimer les propriétés d’un domaine particulier. KIF possède une notation similaire à LISP avec quelques opérateurs et des quantifieurs. ü KQML : Knowledge Query Meta Language Plus
général, KQML permet de définir le format général d’un message. ü FIPA ACL : extension de KQML ACL a été développé par la FIPA en 1995. ACL est un ensemble de performatifs, et plus d’attributs. L’utilisation d’un agent individuellement ne répond souvent pas aux attentes. En effet, des problèmes plus complexes nécessitent l’utilisation de divers agents, chacun ayant un objectif, et ce n’est qu’en les faisant coopérer qu’on arrive à des solutions plus efficaces. Une autre contrainte est le fait que des problèmes sont de manière inhérente distribués (ex : gestion décentralisée d’un réseau électrique), et donc seule une solution distribuée peut résoudre ce genre de problèmes [Ric01]. Un système multi-agents est assimilable à un système distribué composé d’agents. On appelle système multi-agent (SMA), un système composé des éléments suivants: · Un environnement E, c’est-à-dire un espace disposant généralement d’une métrique. · Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire que, pour tout objet, il est possible, à un moment donné, d’associer une position dans E. Ces objets sont passifs, ils peuvent être perçus, créés, détruits et modifiés par les agents. · Un ensemble A d’agents, qui sont des objets particuliers (A ⊆ O), lesquels représentent les entités actives du système. · Un ensemble de relations R qui unissent des objets entre eux. · Un ensemble d’opérations Op permettant aux agents de A de percevoir, produire, consommer, transformer et manipuler des objets de O. · Des opérateurs chargés de représenter l’application de ces opérations et la réaction de l’ensemble des constituants du SMA à cette tentative de modification, que l’on appellera les lois de l’univers multi agents.
FIG 3.5 : Représentation d’un système multi agents [TAN05].
Cette définition des systèmes multi agents a été donnée par Ferber en 1995, elle n’a pas été remise en cause depuis ce temps [FER95]. L’équipe de recherche MAGMA a donné une approche simple pour la conception des systèmes multi-agents connue sous le nom d’approche voyelles [Tan05]: Ø Agent : Les agents sont les composants les plus élémentaires d’un SMA. Ø Environnement : L’espace regroupant les agents. Ø Interaction : Tout les mécanismes de communications (langages, protocoles et infrastructures) permettant une interaction entres les agents. Ø Organisation : La structure des agents en définissant les liens hiérarchiques et les relations entre agents FIG 3.5. L’approche voyelle est régie par trois principes : · Principe déclaratif : Qui est la décomposition précédente des SMA en quatre briques (SMA = A U E U O U I) · Principe fonctionnel : Qui regroupe les fonctionnalités des agents considérés individuellement, auxquelles on rajoute les fonctionnalités résultantes des interactions entre ces derniers. · Principe de récursion : Les SMA peuvent être considérés dans un niveau d’abstraction supérieur comme des entités multi agents. Cette approche voyelle est la plus utilisée pour sa simplicité et son organisation hiérarchique. 3.1 Avantage des systèmes multi-agents L’utilisation des systèmes multi-agents (SMA) est quelques fois obligatoire. Quand on se retrouve face à des problèmes qui imposent un tel choix. Cependant, nous pouvons choisir d’utiliser des SMA pour les raisons suivantes [DRO05]: · Les SMA reflètent la réalité : la majorité des problèmes sont distribués qui s’adapte facilement aux SMA. · Diversité : Les SMA peuvent avoir parmi les agents les constituants une grande diversité, ce qui donne la possibilité aux concepteurs d’intégrer différents agents (réactifs, cognitifs …etc.) · Coopération : Les systèmes entre eux peuvent coopérer pour la résolution de problèmes plus complexes. · Modularité : Le grand nombre d’agents permet de découper les problèmes en sous problèmes ‘simples’, cette approche est l’extension du découpage modulaire de la POO à la POA. ·
A chaque agent sa façon de résoudre les
problèmes (en fonction de ses acquis). Donc un même problème peut avoir
différentes solutions selon les agents. Malgré leur jeune âge, les systèmes multi-agents sont présents dans plusieurs domaines. Ces systèmes sont complexes, distribués, et ont permis le développement de solutions très performantes et très prometteuses. Des systèmes tels que : les systèmes boursiers, les systèmes de commandes et de contrôle en temps réel …etc. ont été le point de départ pour cette nouvelle technologie. Ensuite le domaine d’application des systèmes multi-agents s’est étendu et nous avons remarqué une présence des SMA dans les systèmes suivants : Réseaux d’échange P2P, les télécommunications, les systèmes coopératifs, les systèmes distribués, l’E-commerce. 3.3 Types de systèmes multi agents Il existe différents types de SMA. Nous pouvons considérer les types de systèmes multi-agents selon les types d’agents les constituants ou bien selon les interactions entre leurs agents …etc. Si nous considérons les SMA selon les interactions entre leurs agents, il existe deux types de SMA : Dans
ce genre de SMA, aucune barrière n’est imposée aux agents (concernant leur
migration). En effet, les agents peuvent entrer, ressortir, changer
d’environnement. Aucun échange n’est autorisé, les agents ne doivent interagir qu’au sein de leur environnement et doivent se contenter de ce qui est présent dans ce dernier. Si par contre, nous considérons les SMA selon le type d’agents les constituants : Différents types d’agents peuvent se trouver au sein du même SMA. Les agents sont créés sur des modèles différents, mais arrivent à coexister ensemble dans le même environnement grâce aux standards de communication. Le système multi agents est composé de plusieurs agents du même type. Beaucoup d’IDS sont composés d’un seul bloc qui se charge de toute l’analyse. Cette approche monolithique impose énormément de contraintes telles que [BOU05]: Ø La consommation de ressources système. Ø Difficulté de mise à jour. Ø Le point central est lui-même le point faible si une attaque est lancée contre l’IDS. Ø Nécessité de beaucoup de données d’audit. Pour
palier à ces faiblesses, de nouvelles tendances pour la conception d’IDS
existent. Les tendances actuelles vont vers la détection d’intrusion
distribuées. Nous avons abordé dans la section 1.3, un modèle standard pour les IDS, qui a été mis en place par un comité du DARPA. Ce modèle est adopté dans le développement de la majorité des nouveaux IDS de nos jours. Ce modèle est composé de quatre briques qui sont : La source d’information, le senseur, l’analyseur et le manager. Pour une détection d’intrusions efficace, il est important de rappeler les caractéristiques que doit satisfaire tout IDS, à savoir : la distributivité, l’autonomie, la communication et la coopération, la réactivité et l’adaptabilité [Bou99]. Après ce que nous avons pu voir comme propriétés des systèmes multi agents, les SMA nous semblent très appropriés pour les raisons suivantes [BOU00]: Ø Architecture robuste : L’architecture hiérarchique est connue pour être plus robuste. Généralement plusieurs lignes de communications sont mises en place, ce qui rend la mise hors service d’une telle architecture un vrai défit. Une telle architecture est parfaitement réalisable à l’aide de systèmes multi-agents. De plus les composants de l’architecture seront des agents qui peuvent être relancés automatiquement par un manager dans le cas ou l’un d’eux ne répond pas ou dépasse un certain délai ‘timeout’. Ø Détection multi points : Certaines attaques sont distribuées et l’analyse au niveau de chaque hôte à part ne détectera jamais ce genre d’attaques. C’est pour cette raison que différentes alertes doivent être lancées par les hôtes affectés et au niveau supérieur un agent de coordination pourra récupérer ces différentes alertes et faire l’analyse à son niveau. Ø Partage de connaissances : Une caractéristique importante des agents est leur habilité à coopérer afin de résoudre un problème donné. Cette coopération peut être exploitée dans le domaine de détection d’intrusions en définissant un annuaire des agents en cours d’exécution et leurs capacités d’analyse. Si un agent a besoin d’une fonction bien précise au cours de son analyse, il consulte l’annuaire des agents et cherche parmi les agents disponibles si l’un d’entre eux est capable de réaliser cette tâche à sa place. La conception de l’architecture d’un IDS à base de SMA se déroule en deux étapes : le modèle macro et le modèle micro. Ces deux modèles définissent respectivement la vue globale de la solution et les détails de chaque composant de cette solution. La modèle macro définit globalement notre architecture, les classes d’agents et les relations qui existent entre ces dernières. Les classes d’agents sont caractérisées par des rôles qui leurs sont affectés et des relations inter agents. Chaque agent est capable d’exécuter certaines tâches (rôles), et la coopération entre ces agents permet au système d’accomplir son but global. Dans le modèle micro nous définissons l’architecture interne de chaque agent, les capacités de ce dernier et les différents modules qui le constituent. Plusieurs plates formes existent permettant de développer et d’exécuter des systèmes multi-agents conformément aux normes précédemment évoquées. Les plates formes offrent des classes d’abstractions pour les agents, ainsi que des classes de communication permettant des interactions entre agents tout en respectant les standards (Fipa-ACL, KQML …etc.). Voici quelques unes des plates formes multi-agents les plus connues : - AgentBuilder (http://www.agentbuilder.com/) AgentBuilder est une suite d’outils intégrés permettant de construire des agents intelligents. Développée par Reticular Systems Inc. Cet outil est remarquable car il allie à la fois un logiciel de grande qualité et un modèle sous-jacent qui a fait ses preuves au niveau académique. La méthodologie globale est documentée dans l’AgentBuilder User’s Guide [Ric01]. - Jack (http://www.agent-software.com.au/) Jack est décrit comme étant un environnement pour construire, exécuter et intégrer des systèmes multi-agents commerciaux, écrits en Java et utilisant une approche orientée composants. Il est développé par la société australienne Agent Oriented Software Pty. Ltd. Jack s’intéresse principalement à l’étape de développement. Les outils logiciels sont le JDE ( Jack Development Environment) : un environnement de programmation graphique, le compilateur du Jack Agent Language (JAL), qui traduit les programmes écrits en JAL en Java pur, et la librairie de classes permettant l’exécution des agents, appelée Jack Agent Kernel. - MadKit (http://www.madkit.org/) MadKit est une plate-forme multi-agents écrite en Java basée sur un modèle organisationnel. Elle est développée par Olivier Gutknecht et Jacques Ferber du LIRMM (Laboratoire d’Informatique, de Robotique et de Micro-électronique de Montpellier). MadKit est avant tout une plate-forme d’exécution de systèmes multi-agents, utilisant un micro-noyau agent. Le modèle organisationnel sous-jacent est le modèle Aalaadin. [Ric01]. - Zeus (http://www.labs.bt.com/projects/agents.htm) Zeus est un environnement intégré pour la construction rapide d’applications à base d’agents collaboratifs. Il est développé par l’Agent Research Program du British Telecom Intelligent System Research Laboratory. La documentation de Zeus est abondante, et insiste particulièrement sur l’importance des aspects méthodologiques de Zeus [Ric01]. - Jade (http://jade.tilab.com) Jade permet le développement et l’exécution de systèmes multi-agent conformes aux normes FIPA, cette plate forme offre : Un service de nommage, un service de pages jaunes, des mécanismes de transport de messages, un service d’analyse et une bibliothèque des protocoles d’interactions de FIPA. Cette plateforme est : Entièrement implémentée en JAVA, conforme aux spécifications FIPA, open Source et distribuée avec licence LGPL, modifiable en cours d’exécution (mobilité des agents) [Tan05]. Cette plate forme sera détaillée d’avantage dans l’annexe II, et sera utilisée pour l’implémentation de notre propre système multi-agents. Les tendances actuelles ainsi que les besoins croissants et les contraintes grandissantes ont conduit à l’émergence d’une nouvelle branche de l’intelligence artificielle qui est vite devenue l’un des axes les plus importants de l’informatique moderne. Les systèmes multi-agents ont apporté une nouvelle vision des choses et une nouvelles façon de concevoir des solutions à des problèmes qui au par-avant était impossible ou extrêmement difficiles à résoudre. Les agents, un nouveau concept de programmation se caractérisent par leur autonomie, activité, réactivité, pro-activité …etc. Nous avons vu qu’il existe deux types d’agents : les agents cognitifs qui tentent d’accomplir un but donné et les agents réactifs qui sont un ensemble de stimulus/réactions (agissent en fonction des événements). Quand les agents sont disposés dans des sociétés, ils sont amenés à coopérer, communiquer et doivent faire face à des contraintes telles que le partage des ressources. Les agents avec les interactions existant entre eux, constituent les systèmes multi-agents qui sont des sociétés intelligentes d’agents collaborant pour atteindre un but donné. Nous avons abordé par la suite, l’approche de conception des SMA, qui se résume à la définition des quatre briques de l’approche voyelle. Ensuite, nous avons abordé les types de SMA existants, en fonction du nombre d’agents, types d’agents, relations existantes …etc. Le choix de l’utilisation des systèmes multi-agents pour l’implémentation de notre système de détection d’intrusions est motivé par plusieurs propriétés très intéressantes retrouvés parmi les nombreuses propriétés des SMA et qui répondent aux exigences et attentes des IDS. Pour finir, nous avons cité quelques unes des principales plates formes de développement de SMA. La seconde partie de ce projet de
fin d’étude sera consacrée à la conception de notre propre IDS à base d’agents,
inspiré des systèmes immunitaires artificiels. Nous présenterons notre
solution, les outils et langages de programmation et nous finirons par une
série de testes qui nous permettent d’évaluer notre IDS et surtout l’apport des
systèmes immunitaires dans la détection d’intrusions.
Deuxième partie
Mise en œuvre.
1. Introduction. 2. Description de la solution. 3. Composants de la solution. 4. Bases de données utilisées. 5. HIDS avec approche comportementales. 6.
NIDS avec approche par scénario. L’étude des systèmes de détection d’intrusions nous a permis de réaliser l’importance du rôle que jouent ces derniers au sein d’une stratégie de sécurité. Différents types d’IDS ont été cités, chacun caractérisé par une certaine architecture et une méthode d’analyse. Les caractéristiques des IDS doivent répondre à certaines exigences, le choix de l’adoption d’un certain type par rapport à un autre doit être fondé essentiellement sur les besoins en matière de sécurité et les contraintes logicielles et matérielles. Nous pouvons déterminer le type d’IDS selon : - L’emplacement de l’IDS (NIDS/HIDS). - La fréquence d’utilisation (Continue/Périodique). - La méthode de détection (Comportementale/Par scénario). - La réponse de l’IDS (Passive/Active). La similarité entre les fonctionnalités des systèmes de détection d’intrusions et celles des systèmes immunitaires ainsi que leurs propriétés communes ont donné lieu à plusieurs travaux visant à réaliser un IDS basé sur un SIA (système immunitaire artificiel) dans le but d’approcher les performances extraordinaires d’un système immunitaire naturel. Dans ce chapitre, nous nous proposons de concevoir un SIA pour la détection d’intrusions basé sur les deux principales théories immunitaires, à savoir, la théorie de la sélection négative utilisée pour la détection d’intrusions avec approche comportementale, et celle de la sélection clonale utilisée dans la détection d’intrusions avec approche par scénario. Notre IDS sera basé sur un système multi-agents. Le choix de cette approche est essentiellement fondé sur le fait que l’IDS est composé de différents modules qui doivent être distribués sur un ensemble de stations du réseau pour effectuer des tâches différentes. Les différents composants de l’IDS doivent être en permanente interaction. D’autant plus que même le comportement du système immunitaire est basé sur des interactions entre les différents sous systèmes qui le composent. Donc le choix d’adoption des systèmes multi-agents nous parait le plus approprié. Plusieurs travaux ont été réalisés permettant de concevoir des systèmes immunitaires artificiels pour la détection d’intrusions. Les plus importants sont sans doute ceux réalisé par Kim & Bentley, dans lesquels ils définissent un certain modèle, qui devient par la suite un standard pour la conception d’IDS [KIM02b]. Le modèle en question est composé d’un IDS primaire qui a pour rôle d’organiser les différentes tâches et gérer les différents IDS seconds, qui eux auront pour tâches la capture d’événements et la transmissions des conclusions. Nous adopterons à notre tour ce modèle pour concevoir notre système immunitaire artificiel pour la détection d’intrusions. En utilisant la théorie de la sélection négative, une première solution peut être envisagée pour définir un HIDS utilisant l’approche comportementale dont le noyau d’analyse sera essentiellement basé sur cette théorie. Le HIDS doit se baser sur des profils utilisateurs décrivant leurs comportements normaux. Cette solution est très intéressante dans la mesure où la seule source d’information nécessaire est le comportement des utilisateurs au sein d’un réseau. Cette source d’information peut être maintenue à jour seulement avec des phases d’apprentissage (audit). Cependant, le point négatif de cette solution est le taux de faux positifs dû aux comportements anormaux ou inhabituels des utilisateurs, qui ne sont pas forcement nocifs. La seconde solution peut être envisagée en utilisant la théorie de la sélection clonale, pour définir un NIDS utilisant l’approche d’analyse par scénario. Le NIDS avec approche par scénario utilise essentiellement une base de données des signatures d’attaques connues. Cette source d’information nous permet de diminuer significativement le taux de faux positifs. Cependant, le point faible de cette solution est la source d’information qui doit être régulièrement mise à jour. Une attaque non répertoriée n’a aucune chance d’être détectée par le NIDS. Afin de tirer profit des deux approches (comportementale et par scénario) qui nous semblent complémentaires, notre choix s’est porté sur la conception d’un IDS hybride à base d’agents, utilisant les deux approches d’analyses basée sur les deux principales théories immunitaires. Nous avons opté pour la conception d’un IDS hybride composé d’un NIDS basé sur l’approche d’analyse par scénario, implémentant la théorie de la sélection clonale et utilisant une base de signature, et d’un HIDS basé sur l’approche comportementale, implémentant la théorie de la sélection négative et utilisant une base de données des profils des utilisateurs. En utilisant les théories immunitaires, le noyau de notre IDS génère des variantes des signatures d’attaques et des profils des utilisateurs de manière pseudo-aléatoire. Cette méthodologie nous permet de perfectionner l’analyseur afin de découvrir éventuellement de nouvelles attaques ou des variantes d’attaques. Cependant, cela nous impose de concevoir l’IDS de manière passif. Notre IDS sera développé en tant que système multi-agents, il est nécessaire de préciser que pour notre solution, les agents constituants notre solution seront des agents réactifs. La raison pour laquelle nous avons adopté ce type d’agents est que dans de pareilles solutions, nous voulons avoir un comportement exact et prévisible de l’agent. 3. Architecture globale de l’IDS Notre IDS est composé de : - NIDS : Ce NIDS utilise la théorie de la sélection clonale afin de générer des détecteurs sur la base des signatures. Ces détecteurs seront utilisés pour analyser le trafic réseau. - HIDS : Sur la base de profils des comportements normaux des utilisateurs, le HIDS utilise la théorie de la sélection négative, afin de générer des détecteurs capables de reconnaitre des comportements inhabituels des utilisateurs. - Console d’administration : A partir de cette console, l’administrateur peut configurer les différents paramètres de l’IDS, visualiser les différentes alertes, lancer la commande d’apprentissage …etc. Les composants de notre solution doivent être déployés de la sorte : Le NIDS sera installé sur la machine qui est le proxy du réseau pour pouvoir analyser l’ensemble des paquets du réseau. Tandis que le HIDS sera déployé sur l’ensemble des machines qui constituent le réseau local. Voici l’architecture globale de notre solution :
FIG 4.1 : Schéma global de la solution. Une grande quantité d’informations est analysée et produite par les différents composants de notre IDS. Que ce soit des profils utilisateurs, des alertes générées par les différents détecteurs ou une liste de signatures d’attaques. L’utilisation des bases de données est très importante dans l’architecture de notre IDS, nous avons opté pour l’utilisation de trois bases de données : 4.1 La base de données « Profils » Cette base de données contient l’ensemble des informations relatives aux profils utilisateurs. Les données contenues dans cette base sont générées par le HIDS durant la phase d’apprentissage. Pour des raisons de sécurité, les profils utilisateurs doivent transiter par le superviseur du HIDS afin de garantir la conformité et la cohérence des données contenues dans le profil.
4.2 La base de données « Signatures » Cette source de données est très importante, elle est la base du NIDS. Elle regroupe l’ensemble des attaques connues en utilisant un certain format. Le format de la signature est important dans la mesure où l’ensemble des détecteurs adoptent ce format. Malheureusement, il n’existe aucun modèle standard pour la codification des signatures. Chaque éditeur de logiciels ayant développé un IDS, utilise son propre modèle pour représenter les signatures d’attaques. La signature doit représenter de manière fiable, non ambigüe et exacte les attributs qui permettent de reconnaitre cette attaque. Il faut rappeler que les signatures seront utilisées pour analyser le trafic réseau. Les attributs à utiliser pour représenter une attaque doivent être basés sur les informations contenues dans les paquets. Nous pouvons analyser le trafic réseau à plusieurs niveaux de granularité. En effet, nous pouvons considérer le trafic d’un point de vue paquets, sessions ou connexions. Il faut définir le jeu d’attributs qui doit être utilisé parmi l’ensemble des attributs existants. Voici à titre d’exemple deux jeux d’attributs : - Jeu d’attributs de Denning [KDD99]: Denning propose un jeu d’attributs composé de trois catégories qui utilisent au total 16 attributs pour modéliser des sessions, processus …etc. § Compteur d’événement : Le nombre d’occurrences d’un événement durant une période donnée (ex : le nombre de tentatives de connexion échouées durant une durée de temps). § Compteur de durée : Le temps écoulé entre deux événements (ex : intervalle de temps entre deux tentatives de connexion). § Compteur de ressources : Quantité des ressources utilisées par une entité (ex : temps CPU alloué à un processus).
-
Jeu d’attribut KDD’99 [KDD99]: Ce
jeu d’attributs a servi à formater la base de données Darpa’98 qui est la
première base de données qui découle d’une série de compagnes destinées à
standardiser les IDS. § Attributs de base : Les connexions au niveau paquets (protocole, service…etc.). § Attributs de contenu : Contenu des paquets. § Attributs temporel : L’aspect temporel du trafic réseau (nombre de connexion sur un service pendant une durée donnée). § Attributs de trafic : Le trafic impliquant une machine données (pourcentage de connexions ayant la même adresse IP source parmi les cent dernières connexions). Le jeu d’attributs KDD’99 a été démontré incohérent, car il ne contenait pas assez d’informations pour modéliser l’ensemble des attaques existantes. Nous
proposons ici un modèle particulier de signatures. Notre modèle de signatures a
été conçu de manière à répondre aux exigences que doit satisfaire une signature
d’attaque. Dans notre cas, les signatures sont codées de manière à être modifiables et permettent de modéliser les nouvelles attaques, par de nouvelles méthodes d’analyses ...etc. L’analyse et la synthèse des différentes attaques réseau a permis de classer ces dernières en trois classes : - Les attaques ‘données’ : Ce sont l’ensemble des attaques reconnues en analysant la partie données des paquets, telles que les attaques par injection SQL. Ces dernières seront reconnues si les chaines suivante ('' --, or 1=1) est retrouvée à l’intérieure des paquets. - Les attaques ‘Entêtes’ : Ce sont l’ensemble des attaques reconnues par l’analyse des entêtes des paquets, telles que les attaques DOS avec usurpation des entêtes. - Les attaques ‘Requêtes’ : Les requêtes regroupent généralement plusieurs paquets. Certaines attaques ne seront reconnues qu’en analysant l’ensemble des paquets qui constituent la requête, telles que les attaques de Validation d'entrées ou les attaques de Buffer Overflow, qui ne peuvent être reconnues, que la longueur ou le nombre de paramètres qui constituent la requête. En faisant attention à modéliser les différentes classes d’attaques existantes, notre signature contient les champs suivants :
Ø Id : identifiant unique de la signature. Ø Type : Entête, données, requêtes. Ø Action : L’action d’analyse (ex : retrouver une sous chaine, compter le nombre d’attributs, longueur d’une requête, service demandé …etc.) Ø Data : Dans le cas d’attributs de type chaines de caractères : la chaine recherchée. Ø Val : Dans le cas d’attributs à valeurs numériques : la valeur de l’attribut. Ø Flags : informations supplémentaires L’identifiant sert d’index dans la base de données des signatures tandis que le type permet de retrouver la table qui contient la signature. L’action définie le traitement à faire, c’est le champ de plus important pour une signature, ce dernier contient un mot clé qui permet de savoir quelle méthode appelée pour l’analyse des données. Différentes actions ont été implémentées telle que : Ø SubStr : Permet de rechercher une sous chaine, ce mot clé est utilisé beaucoup plus sur les attaques de type données et requête. Ø LenStr : Calculer la longueur d’une chaine de caractère, permet de retrouver les attaques telles que les attaques DOS. Ø ValidStr : Cette permet de savoir si les chaines de caractères ne contiennent pas de caractères invalide. Le champ ‘Data’, dans le cas ou on recherche une chaine de caractère (ex : L’action SubStr), contient la sous chaine à rechercher. Le champ ‘Val’, dans le cas ou l’action retourne une valeur numérique (ex : La longueur d’une chaine de caractère), contient la valeur numérique qui permet de dire que c’est une attaque. Le champ ‘Flags’ est un champ optionnel qui sert de paramètres pour la méthode d’analyse. A titre d’exemple, pour les attaques de type débordement de tampon, l’action utilisée est ‘LenStr’ qui permet de calculer la longueur de la partie données des paquets. Le champ ‘data’ ne contient aucune chaine puisque nous n’allons essayer de reconnaitre aucune chaine. Par contre le champ ‘Val’ contient la valeur numérique à partir de laquelle nous pouvons conclure que c’est une attaque de débordement de tampon. le champ ‘Flags’ contient l’opérateur ‘>‘ qui indique à la méthode d’analyse que si la longueur dépasse la valeur indiquée dans ‘Val’, l’analyseur d’éclanche une alerte. Un autre exemple pour modéliser l’attaque d’injection SQL. Cette attaque est détectée si on arrive à reconnaitre grâce au mot clé SubStr du champ Action, la sous chaine ('' --, or 1=1) du champ Data à l’intérieur des paquets capturés. A ce modèle de signature, on attribuera un interpréteur permettant d’exécuter l’action d’analyse de chaque signature. A tout moment si l’on veut augmenter le nombre de signatures en rajoutant de nouvelles, il suffit d’utiliser le modèle précédemment définie, et si on a besoin de nouvelles fonctions d’analyse, on les rajoutes à l’interpréteur. 4.3 La base de données «Alertes » Cette base de données permet de répertorier l’ensemble des alertes générées par les détecteurs des deux composants de l’IDS (NIDS et HIDS). Une alerte doit renseigner l’administrateur sur l’événement suspect, en fournissant suffisamment d’informations : l’heure, la date, l’agent détecteur, la signature ou comportement anormal, l’attaquant, la victime …etc. Cette base de données sera consultée par l’administrateur afin de relever les traces d’attaques ou de comportements anormaux. 5. HIDS avec approche comportementale Comme tout HIDS utilisant l’approche comportementale, une base de données des comportements ‘sains’ des utilisateurs est nécessaire. La première étape du déploiement du HIDS, est sans doute l’étape d’apprentissage, durant laquelle on sauvegarde les traces des comportements normaux des utilisateurs en créant un profil pour chacun.
FIG 4.2 : Profil utilisateur. Les profils utilisateurs sont une source de données qui peut nous renseigner sur le comportement des utilisateurs. Nous avons choisi d’utiliser les informations suivantes pour modéliser un profil utilisateur : - Nom de l’utilisateur. - Répertoire racine. - Consommation moyenne CPU et RAM. - Heure d’ouverture / fermeture des sessions. - Liste des processus les plus fréquemment utilisés. - Liste des interfaces réseaux…etc. D’autres informations auraient pu être utilisés telles que la consommation moyenne de bande passante, les sites web les plus consultés, la vitesse de réponse au messages du système d’exploitation …etc. En suivant le modèle proposé par Kim & Bentley, notre HIDS sera constitué d’un HIDS superviseur et d’un ensemble de HIDS esclaves qui seront déployés sur l’ensemble des machines constituants le réseau.
FIG 4.3 : Architecture du HIDS utilisant l’approche comportementale basée sur la théorie de la sélection négative. La théorie de la sélection négative est le noyau de notre HIDS. Cette théorie s’exécute en deux phases : Génération des détecteurs et analyse du comportement. La première phase s’exécute sur le HIDS superviseur, qui envoie les détecteurs générés aux HIDS esclaves pour exécuter la deuxième phase de la théorie. Celle-ci consiste à analyser le comportement actuel de l’utilisateur sur la base des détecteurs. Le HIDS superviseur a pour rôle de : Ø Extraire les profils des utilisateurs de la base de données. Ø Générer les détecteurs et les envoyer aux HIDS esclaves en exécutant la première phase de la théorie de la sélection négative qui consiste à générer des détecteurs qui regroupent l’ensemble des informations nécessaires pour l’analyse du comportement des utilisateurs par la suite. Ø Analyser les rapports des HIDS esclaves et répertorier les alertes dans une base de données. Ø Envoie des commandes permettant de lancer les phases d’apprentissage, analyse, lancement et arrêt des HIDS esclaves…etc. Le HIDS esclave quant à lui a pour rôle de : Ø Générer les profils des utilisateurs durant la phase d’apprentissage. Ø Utiliser des capteurs d’événements pour extraire le comportement actuel de l’utilisateur. Ø Exécuter la deuxième phase de la théorie de la sélection négative qui consiste à utiliser les détecteurs générés par la première phase afin d’analyser le comportement de l’utilisateur. 5.4 Théorie de la sélection négative C’est sur cette théorie qu’est basé le noyau de notre HIDS, elle permet de générer des détecteurs (anticorps) à partir du profil utilisateur, et les mettre en place à fin de reconnaitre des comportements suspects (Antigènes). Comme nous avons pu le voir précédemment cette théorie se déroule en deux phases Ø Phase I : Génération des détecteurs Cette phase s’exécute sur le HIDS superviseur. Durant cette phase, on extrait les profils des utilisateurs à partir de la base de données. Chaque profil sera considéré comme la chaine de soi, et sera utilisée pour la génération aléatoire de détecteurs. Ensuite, un test est mis en place, afin de purger l’ensemble des détecteurs générés en ne gardant que ceux qui ne reconnaissent pas la chaine de soi (voir Fig. 4.4.)
FIG 4.4 : Phase I de la sélection négative (Génération des détecteurs). Ø Phase II : Analyse Cette phase s’exécute sur les HIDS esclaves. Durant cette phase, on exploite les détecteurs générés par la phase précédente afin de procéder à l’analyse du comportement actuel de l’utilisateur. Le HIDS esclave doit disposer de capteurs pouvant le renseigner sur le comportement actuel de l’utilisateur. Une fonction permettra de mesurer le degré de ressemblance entre ce comportement et les détecteurs générés précédemment et une alerte est générée dans le cas où celle-ci atteint un certain pourcentage. Le degré de ressemblance est un paramètre très important pour la génération d’alertes. A titre d’exemple, pour les informations telles que la consommation moyenne des ressources (CPU et RAM) un certain intervalle doit être défini sur la base de la moyenne. Donc si cette consommation dépasse la moyenne d’une certaine valeur ?, une alerte de surconsommation sera générée.
FIG 4.5 : Phase II de la sélection négative (mise en place des détecteurs pour l’analyse). Il faut rappeler que les composants de l’IDS doivent être distribués et en permanente interaction. Pour cette raison, les composants seront installés sur des agents, et notre HIDS sera en fait un système multi-agents distribué sur l’ensemble des machines constituant le réseau local.
Le déploiement et la mise en marche de notre HIDS se fait en deux phases : Ø La phase d’apprentissage : Le HIDS superviseur envoie la commande du début de la phase d’apprentissage aux différents HIDS esclaves. Durant la phase d’apprentissage, le HIDS esclave extrait périodiquement des informations du comportement de l’utilisateur. Pour les valeurs numériques, le HIDS esclave calcule la moyenne des différentes valeurs extraites. Le profil généré par chaque HIDS esclave sera ensuite envoyé au HIDS superviseur, qui se charge de le répertorier. Ø La phase de surveillance : Durant cette phase, le HIDS superviseur extrait les profils de chaque utilisateur, applique la première phase de la théorie de la sélection négative afin de générer des détecteurs. Les détecteurs seront envoyés à chaque HIDS esclave avec la commande de début de la phase de surveillance. Chaque HIDS lance un agent ‘Analyseur’. Ce dernier nécessite une seconde source d’informations, qui est le comportement actuel de l’utilisateur, qu’il comparera par la suite au détecteur. Pour cela, l’agent ‘Analyseur’ demande à l’agent ‘Capteur’ de lui transmettre les informations nécessaires. Comme nous avons pu le voir précédemment le profil utilisateur contient plusieurs informations, toutes ces informations seront transcrites dans le détecteur suivant un certain format. La fonction de comparaison entre le détecteur et le comportement actuel, procède par comparaison des parties de chacun, permettant de nous renseigner sur le degré de ressemblance entre le détecteur et le comportement actuel.
FIG 4.6 : Fonctionnement du HIDS. 6. NIDS avec approche par scénario Le second composant très important est le NIDS utilisant l’analyse avec approche par scénario, basée sur la théorie de la sélection clonale. Cette approche nécessite une base de données des signatures d’attaques connues (antigènes), sur la base de ces signatures, le noyau du NIDS génère des détecteurs (anticorps), capables de reconnaitre la signature initiale (antigène), mais également des signatures qui dérivent de cette dernière (variantes). Le noyau du NIDS contient principalement la fonction d’analyse qui est basée sur la théorie de la sélection clonale. La fonction d’analyse de notre NIDS contient les deux processus de génération de détecteurs et leur mise en place pour l’analyse du flux de paquets.
Le NIDS est en réalité un système multi-agents, constitué de divers agents, avec pour chacun un rôle bien précis. Au sein du NIDS, il existe trois rôles principaux qu’on attribue à trois classes respectives d’agents. C’est le gestionnaire de la solution. Le manager est chargé de : § Lancer les différents agents. § Affecter les différentes tâches d’analyse aux agents. § Extraire les signatures d’attaques et générer les détecteurs, en exécutant l’algorithme de sélection clonale. § Recevoir les rapports des différents agents et répertorier les alertes. Le senseur est responsable de la capture des paquets réseaux. Différents ‘Senseurs’ peuvent être déployés dans notre solution afin de rendre cette tâche plus légère. Si on opte pour le déploiement de plusieurs ‘Senseurs’, il faut définir pour chacun le sous ensemble du trafic réseau qu’il devra capturer (Ex : TCP, UDP …etc.). L’analyseur est en fait comparable à un anticorps qui a pour tâche de surveiller et de reconnaitre un certain type d’antigènes. Dans notre cas, l’antigène en question est la signature d’attaque à reconnaitre. Donc, l’Analyseur reçoit les signatures du ‘Manager’ et les met en place pour reconnaitre un type d’attaques. Pour cela, l’Analyseur doit recevoir un sous ensemble du trafic réseau afin de procéder à son analyse. Le sous ensemble du trafic réseau sera envoyé par l’agent ‘Senseur’. Nous avons opté pour l’utilisation conjointe des ‘Analyseurs-Senseurs’. Cette utilisation nous garantit une solution plus légère et autonome.
FIG 4.7 : Architecture à base d’agents du NIDS. 6.2 Théorie de la sélection clonale
o Initialisation Le ‘Manager’
extrait une signature d’attaque ‘S’, à partir de laquelle il génère un
ensemble initial de détecteurs ‘AB’ de taille ‘N’. o Génération des
détecteurs Ø
Calculer l’affinité de chaque
détecteur de ‘AB’ avec la signature ‘S’. Ø
Sélectionner les ‘n’
meilleurs détecteurs et les cloner on créant des copies identiques. Ø
Appliquer le processus de maturation
d’affinité sur les clones. Ø
Recalculer le degré d’affinité des
nouveaux détecteurs avec la signature ‘S’. Ø
Les détecteurs qui présentent les
degrés d’affinité les plus faibles seront supprimés. o
Génération
des détecteurs Ø Les
‘m’ meilleurs détecteurs relatifs à la signature ‘S’constituerons
les détecteurs qui seront utilisés plus tard pour l’analyse.
L’utilisation de cette théorie immunitaire implique une certaine adaptation des concepts fondamentaux de cette dernière dans notre cas qui est la détection d’intrusions. En effet, nous allons utiliser des méthodes qui permettent d’approche le fonctionnement extraordinaire de cette théorie. Les principaux processus sur lesquels est basée la théorie de la sélection clonale sont : Ø La génération aléatoire d’un ensemble initial d’anticorps. Ø La fonction de mesure du degré d’affinité entre chaque anticorps et l’antigène en question. Ø Le processus de maturation d’affinité. Ø Le processus de clonage. Ces quatre processus sont la base de la théorie de la sélection clonale, nous présenterons notre adaptation de ces processus pour notre IDS. Ø Génération de l’ensemble initiale d’anticorps Comme nous avons pu le voir, nous avons adopté un certain format de signature. La signature contient des parties spécifiques qui sont : Identifiant, type, action, data, val, flags.
FIG 4.8 : Format d’une signature. Durant cette phase, on prépare un ensemble d’anticorps (détecteurs) à partir de la signature initiale (antigène). Nous allons générer les détecteurs de manière à ce que ces derniers reprennent une partie de la signature. Cette méthode nous permet de générer un ensemble de détecteur de taille ≤ 5 qui ressemblent à la signature initiale.
FIG 4.9 : Génération de l’ensemble initial d’anticorps Ø Fonction de mesure d’affinité La fonction de mesure d’affinité permet de calculer le degré de ressemblance entre la signature et le détecteur, et cela en comparant leurs différentes parties comme suit : Nous attribuons des valeurs numériques (poids) pour les différentes parties de la signature. La fonction de mesure d’affinité retourne un entier qui est calculé de la sorte : Si les mêmes parties sont identiques dans les deux signatures, le résultat est incrémenté par le poids de cette partie. La somme des poids des parties identiques est dans notre cas la valeur que retourne la fonction d’affinité. Pour l’attribution des poids (A,B,C…etc), il faudrait que quelques soient les parties identiques, la sommes des poids de ces parties doit retourner une valeur unique qui peut nous renseigner sans ambigüité des parties identiques et par conséquent, des parties différentes. A titre d’exemple si nous attribuons les valeurs suivantes aux différentes parties de la signature :
FIG 4.10 : Attribution des poids aux différentes parties de la signature. Quelques soient les parties identiques entre la signature et le détecteur, la sommes de ces dernières est une valeur unique.
FIG 4.11 : Mesure du degré d’affinité entre une signature et un détecteur. Ø Maturation de l’affinité Dans ce processus, nous essaierons d’augmenter le degré de ressemblance entre la signature et le détecteur. La valeur retournée par la fonction de mesure d’affinité, nous permet d’identifier les parties qui diffèrent entre la signature et le détecteur. Sur la base de ces différences, nous pouvons améliorer le degré d’affinité entre la signature et le détecteur, en améliorant les parties différentes. Le fait de choisir une partie aléatoirement parmi les parties qui constituent le détecteur, peut donner à la fin un détecteur incohérent. Nous appellerons un détecteur incohérent, si ce dernier contient une action qui ne coïncide pas avec le type, ou bien des paramètres qui ne sont pas faits pour cette action …etc. Afin de diminuer considérablement le taux de faux positifs en évitant de générer des détecteurs incohérents, nous avons rajouté dans notre base de données une table des règles à respecter. Ces regèles définissent pour chaque type les actions possibles, pour chaque action les paramètres possibles …etc.
FIG 4.12 : Processus de maturation d’affinité. Ø Clonage Ce processus permet de faire des copies conformes de la même signature, en faisant attention à reprendre exactement la valeur de chaque partie. Les autres étapes de la théorie de la sélection clonale, se dérouleront de la même manière. Notre NIDS utilise l’analyse avec approche par scénario, basée sur la théorie de la sélection clonale, il utilise comme source de données les paquets réseau. Voici les étapes de son exécution : Ø Capture des paquets : La première étape de l’analyse est la capture des paquets, grâce aux agents ‘Senseurs’ qui capturent et transmettent les paquets réseaux aux agents ‘Analyseurs’ afin de procéder à leur analyse. A ce niveau, on peut également
enregistrer les paquets capturés dans des structures de données, afin de les
analyser plus tard si l’administrateur choisit de faire des analyses différées. Ø Extraction et formatage des attributs : Cette étape permet d’extraire un vecteur d’attributs de haut niveau à partir des paquets capturés afin d’être analysés par la suite. Cette étape est très importante, elle
permet de préparer les paquets pour la phase d’analyse en effectuant
quelques modifications sur ces derniers : i.
Structurer les données :
Les données capturées ne sont pas structurées pour une analyse, ce processus
permet de structurer ces informations et produire des informations de haut
niveau. Les paquets sont capturés dans un format binaire, cette phase permet
d’extraire les différents champs du paquets et leurs attribués des valeurs qui
peuvent être interprétées par l’agent ‘Analyseur’. ii.
Résumer les données :
La quantité d’informations qui circule sur un réseau est de l’ordre de
plusieurs giga-octets, même dans les réseaux de taille moyenne. La pratique a
montré que dans un paquet, quelques parties sont analysées. Une grande quantité
d’information est redondante. Donc, il est impératif afin de garantir un niveau
de performances acceptable de ne garder que les informations pouvant servir à
détecter des attaques. iii. Fournir des attributs efficaces : Il faut garantir que les attributs de haut niveau extraits des paquets soient non ambigus et contiennent suffisamment d’informations capables de nous renseigner de manière claire sur le type d’activité (normale, attaque). Il faut préciser que parmi les attributs, il existe ceux qui sont extraits directement tels quels: adresse IP source, adresse IP de destination, protocole, port …etc. Alors que d’autres doivent être calculés tels que : le nombre de paquets durant les n dernières secondes, la durée d’une connexion …etc. Les informations extraites des paquets subissent
un formatage permettant ainsi d’utiliser le format standard des signatures
adopté. Selon le sous ensemble du trafic réseau (ex : FTP, HTTP …etc) que
doit surveiller l’agent ‘Analyseur’, il peut ne sélectionner que les attributs
dont il a besoin afin de procéder à leur analyse (ex : IP source, IP
destination). Ø Analyse des attributs : Une fois que l’agent ‘Manager’ a généré un ensemble de détecteurs par l’application de la théorie de la sélection clonale, la fonction d’analyse assurée par l’agent ‘Analyseur’ compare selon le type de signature, un ensemble de détecteurs avec les attributs des paquets. Sur la base de cette comparaison des rapports sont générés.
Ø Envoi des rapports : Les rapports d’analyse sont systématiquement envoyés à l’agent ‘Manager’ qui se charge de les répertorier dans la base de données ‘Alertes’.
FIG 4.13 : Fonctionnement du NIDS.
Chapitre V : Réalisation et tests expérimentaux 1. Introduction. 2. Environnement d’exécution. 3. Systèmes multi-agents. 4. Structures et sources de données. 5. Découpage des classes. 6. Langages et environnement des développements. 7. Déploiement et lancement de l’IDS. 8.
Tests et résultats expérimentaux.
Après avoir décrit notre solution, nous aborderons dans cette section la partie implémentation de notre système : les langages de programmation, plates formes, système de gestion des bases de données et outils utilisés pour le développement de notre solution. Nous présenterons l’implémentation des différents modules constituants notre solution, les liens entre ces modules, l’environnement d’exécution…etc. Nous présenterons également les différents tests effectués pour évaluer les performances de notre IDS et surtout l’apport des théories immunitaires utilisées. Les deux composants de notre IDS peuvent être utilisés séparément. En effet, un point très intéressant c’est que les deux IDS qui constituent notre solution utilisent des bases de données différentes (‘Signatures’ et ‘Profils’), et s’intéressent à des sources d’informations différentes (Paquets réseau et comportement des utilisateurs). Le NIDS étant développé entièrement en Java, peut être déployer sur n’importe quel système d’exploitation , il suffit juste de reprendre son architecture et installer les deux bases de données nécessaires pour son fonctionnement, la base « Signatures » et la base « Alertes ».
FIG 5.1 : Architecture du NIDS utilisé à part. Afin d’analyser l’ensemble des paquets du réseau, le NIDS doit être installé sur une machine qui doit jouer le rôle de proxy au sein du réseau afin de faire transiter tout les paquets par cette station. Quant au HIDS, il présente une certaine dépendance vis-à-vis du système d’exploitation. En effet, les profils utilisateurs regroupent des informations sur le comportement de ces derniers, et celles-ci ont une relation directe avec le système d’exploitation. Dans notre cas nous avons utilisé le système d’exploitation Windows, qui est le système d’exploitation le plus utilisé par les utilisateurs, et aussi pour le nombre limité d’IDS développés sous ce système d’exploitation. Nous pouvons également utiliser le HIDS séparément. Le HIDS peut être déployé sur un réseau de stations Windows comme le montre la figure FIG. 5.2.
FIG 5.2 : HIDS utilisé à part. Nous présenterons l’utilisation conjointe des deux composants de la solution. Cette utilisation nous permet d’exploiter les avantages de chacune. Donc, l’environnement d’exécution de notre IDS est comme suit : o NIDS installé sur le Proxy. o HIDS Superviseur installé sur une machine dédiée. o HIDS esclaves, déployés sur les machines constituant le réseau. Celles-ci étant dotées du système d’exploitation Windows. Une troisième
application a été développée pour l’administration de l’IDS. Cette application
sert d’interface entre l’administrateur et les différents composants de la
solution. Ø Visualiser les différentes alertes générées par le NIDS et le HIDS. Ø Définir les paramètres de configuration de l’IDS. Ø Mettre à jour la base des signatures. Ø Lancer la phase d’apprentissage pour le HIDS et consulter les différents profils…etc. L’ensemble des fonctionnalités de notre système de détection d’intrusions ont été implémentées à base des agents. Cette approche nous garantit distributivité, autonomie, coopération …etc. L’ensemble de nos agents sont des agents réactifs. Nous avons opté pour ce type d’agents, afin d’éviter d’avoir des comportements inattendus de nos agents. Nous avons utilisé une plate forme multi-agents très connue, développée entièrement en Java qui est JADE (Java Agent DEveloppement framework) .Cette plate forme dispose de plusieurs classes abstraites nous permettant d’hériter des objets importants tels que : Agents, message, behaviour …etc. Deux systèmes multi-agents ont été développés pour notre IDS : Créé par le NIDS, ce SMA regroupe les agents suivants : § Manager : C’est le superviseur des autres agents, il regroupe toutes les fonctions d’extraction et génération des détecteurs, archivage des alertes, lancement des différents agents. § Senseur : Responsable de capturer des paquets selon un certain filtre et les transmettre à son agent « Analyseur ». § Analyseur :
Reçoit les détecteurs de l’agent « Manager », et les paquets de
l’agent « Senseur », puis procède à la comparaison de ces deux
derniers.
FIG 5.3 : Système multi-agents NIDS. Comme le montre la figure Fig. 5.3, nous avons opté pour le déploiement de trois couples (analyseur-senseur), afin de partager les tâches d’analyse sur les trois agents. Nous utiliserons un agent analyseur pour chaque type d’attaque (Données, entêtes et requête). Ce
système multi-agent destiné à contenir les agents du HIDS est un peu plus
complexe. En effet, le système multi-agents HIDS est distribué sur l’ensemble
des machines du réseau. Les agents qui constituent ce SMA sont : § Manager : c’est le gestionnaire de la solution, l’agent «Manager» représente le HIDS superviseur. Cet agent se connecte aux bases de données, extrait les informations de configuration (phase en cours, paramètres des différentes méthodes …etc.), envoie les différentes commandes aux différents agents Slave-Manager de chaque HIDS esclave. § Slave-Manager : Le gestionnaire de chaque HIDS esclave, ce dernier permet d’interagir avec l’agent « Manager » pour recevoir les commandes concernant la phase en cours, ou l’envoie des résultats de chaque phase (profil utilisateur dans le cas de la phase d’apprentissage, ou alertes générées dans le cas de phase d’analyse). § Analyseur : L’agent responsable d’analyser le comportement actuel de l’utilisateur. Cet agent reçoit les informations à partir de l’agent « Capteur » et le détecteur à partir de l’agent « Slave-Manager », puis procède à l’analyse du comportement de l’utilisateur. § Capteur : Cet agent fait appel à des API et des propriétés système, pour extraire les informations du comportement de l’utilisateur et les envoyés à l’agent « Analyseur ». § ProfilCreator : Dans le cas de la phase d’apprentissage, cet agent s’exécute pendant un certain intervalle, génère le profil du comportement de l’utilisateur qu’il envoie à l’agent Slave-Manager. Ce dernier ce charge de le transmettre à l’agent Manager du HIDS superviseur. Dans notre application, nous avons besoin de trois bases de données principales qui sont : signatures, profils et alertes. Nous avons utilisé le système de gestion de bases de données MYSQL. Ce SGBD est très léger et nous permet d’effectuer les taches de journalisation, consultation et mises à jour des données de manière simple. Le schéma de nos bases de données est le suivant : Cette base de
données contient les informations sur le comportement des utilisateurs.
FIG 5.4 :
Schéma de la base de données « Profils ». § Table ‘users’ : Cette table contient des informations générales concernant l’utilisateur à savoir : o Un identifiant unique uid. o Le nom d’utilisateur uname. o Le répertoire racine de l’utilisateur urep. o Le système d’exploitation os. o La version du système d’exploitation os_ver. o L’architecture du système d’exploitation os_arch. o La langue par défaut de l’utilisateur ulang. o La consommation moyenne des processeurs cpu. o La consommation moyenne mémoire ram. o Les horaires d’ouverture et fermeture de la session ton et toff. o Les droits de l’utilisateur utype. § Table ‘interfaces’ : Cette table contient des informations concernant les interfaces réseaux de l’utilisateur : o L’identifiant de l’utilisateur uid. o Le nom de l’interface nom. o L’adresse mac de l’interface mac. o L’adresse IP de l’interface ip. o Le sous réseau auquel appartient l’interface sousres. o
Commentaires comments. § Table ‘process’ : Cette table contient la liste des processus les plus utilisés par l’utilisateur. o L’identifiant unique de l’utilisateur uid. o Le titre du processus caption. o Le processus père du processus en question createur. o La description du processus desc. o Le nom du processus nom. o L’identifiant unique du processus pid. La base de données « profils », étant utilisée par le HIDS, contient d’autres tables telles que : « Liste_process » ou «config » qui sont respectivement : o Liste des processus malveillants à partir desquelles les détecteurs seront générés. o Paramètres de configuration du HIDS. 4.2 Base de données «Signatures » Cette base de données regroupe les différentes signatures d’attaques en trois tables.
FIG 5.5 : Schéma de la base de données « Signatures ». Les informations contenues dans ces trois tables sont formatées en utilisant le modèle de signature détaillé dans la section 4.4.2. o L’identifiant unique de la signature id. o Le nom de l’attaque représentée par la signature nom. o L’action de recherche permettant de reconnaitre l’attaque action. o La partie donnée sur laquelle s’applique la recherche data. o La valeur numérique concernant la recherche d’attributs numériques val. o Paramètres optionnelles pour certaines méthodes d’analyse Flags A
titre d’exemple, pour une attaque d’injection SQL, cette dernière pourra être
reconnue si on retrouve dans des paquets la chaine ('' --, or 1=1) dans la partie
données du paquet.
FIG 5.6 : Modélisation de l’attaque par injection SQL. D’autres informations peuvent être contenues dans cette base de données, puisque cette dernière est utilisée par le NIDS. Elle peut contenir les paramètres nécessaires pour ce dernier à savoir : les paramètres de la théorie de la sélection clonale (Taux de clonage, nombre d’anticorps à générer, taille de l’ensemble initial d’anticorps) ainsi qu’un ensemble de paramètres définis par l’administrateur de l’IDS (La sauvegarde des paquets suspects…etc.). 4.3 Base de données «alertes » Cette base de données regroupe les différentes alertes générées par le NIDS et le HIDS répertoriées dans deux tables :
FIG 5.7 : Schéma de la base de données « Alertes ».
§ La table « alertes_h » : regroupe l’ensemble des alertes générées par le HIDS. o Un identifiant unique de l’alerte id. o L’agent ayant envoyé le rapport d’alerte agent. o Le nom de l’attaque qui s’est produite titre. o La machine sur laquelle s’est produite l’attaque host. o La date de l’envoie de l’alerte date. o L’ensemble des détails de l’alerte details. § La table « alerte_n » : Contient les alertes du NIDS. o Un identifiant unique de l’alerte id. o L’agent ayant envoyé le rapport d’alerte agent. o Le nom de l’attaque qui s’est produite titre. o La source de l’attaque source. o La destination de l’attaque (l’hôte visé par l’attaque) destination. o La date de l’envoie de l’alerte date. o L’ensemble des détails de l’alerte details. Dans cette partie nous détaillerons les différents packages constituant notre solution, ainsi que les différentes classes de chaque package. Notre NIDS est principalement composé de quatre packages : - Sig : Ce package contient trois classes principales
o Antibody : Cette classe représente un détecteur avec la signature initiale, les différents champs du détecteur, le degré de son affinité avec la signature ainsi que les modifications faites sur ce détecteur.
o Signature : Cette classe définie le format de signature.
o Clonalg : Cette classe implémente la théorie de la sélection clonale.
- Manager : ce package contient une seul classe ‘agent_manager’ qui défini le comportement de cet agent. Voici les différentes méthodes de la classe ‘agent_manager ‘ :
- Analyseur : Ce package contient la classe ’agent_analyseur’, qui définie le comportement de ce dernier.
Voici les différentes méthodes contenues dans la classe ‘agent_analyseur’ :
- Senseur : Ce package contient la classe qui définie le comportement de l’agent ‘senseur’. La classe ‘agent_senseur’ contient les méthodes suivantes :
5.2 HIDS Notre HIDS est composé des packages suivants : Notre HIDS superviseur est principalement composé de deux packages : - Detectors : ce pacquage contient deux classes qui définissent respectivement : le format d’un détecteur et l’implémentation de la théorie de la sélection négative.
- Profils : ce pacquage contient l’ensemble des classes qui définissent le profil utilisateur, ainsi que les opérations à effectuer sur ce profil. -
Le HIDS esclave est composé principalement de trois pacquages : - Profils : Ce pacquage contient une classe très importante, qui est la classe de génération du profil, cette dernière est constituée des méthodes suivantes :
- Captor : ce pacquage contient la classe captors qui sert de générateur d’événements, cette classe sera utilisée par l’analyseur afin de comparer les détecteurs au comportement actuel de l’utilisateur. La classe captors contient les méthodes suivantes :
- Analyse : ce pacquage contient les structures de données destinées à contenir les détecteurs, ainsi que la classe d’analyse ?. La classe captors contient les méthodes uivantes :
6. Langages et environnements de développement Nous avons utilisé plusieurs langages de programmation et environnements intégrés de développement, en fonction des besoins. Pour le développement des composants de l’IDS (NIDS et HIDS), nous avons utilisé le langage JAVA avec l’IDE Eclipse. Ce choix s’est imposé, puisque les différents composants de l’IDS sont implémentés sur des agents Jade. Ceci nous a permis de développer notre NIDS de manière à être portable sur différents systèmes d’exploitation. L’application d’administration quant à elle a été développée avec C#.Net en utilisant l’IDE Visual Studio 2008. Ce choix a été fait parce qu’aucune contrainte ne s’est imposée à ce niveau. Nous avons développé cette application de manière à ce que l’interface d’administration soit simple, conviviale et pratique. Pour la connexion avec les différents SGBD, nous avons utilisé la bibliothèque MYSQL Connector, qui nous permet d’exécuter les différentes requêtes sur le SGBD à partir d’applications Java ou C#.Net. Nous avons également fait appel à la bibliothèque JPCAP afin de capturer les paquets réseau, lister les différentes interfaces réseau …etc. Cette bibliothèque est utilisée par l’agent « Senseur » du NIDS pour la capture des paquets et l’agent « ProfilCreator » du HIDS esclave pour lister et extraire les informations relatives aux interfaces réseau. 7. Déploiement et lancement de l’IDS Les différents composants de notre IDS doivent être déployés selon un certain ordre et en respectant certaines conditions. Notre solution nécessite des composants qui doivent être installés avant le lancement de l’IDS. Les composants en questions sont : Ø Le SGBD MYSQL : doit être installé sur les machines réservées pour contenir les différentes sources d’informations. Ø La plate forme JADE : Cette plate forme sera installée sur la machine allouée au NIDS (Le proxy) et la machine allouée au HIDS superviseur. Ø La librairie JPCAP : Doit être installée sur la même station que le NIDS, afin de permettre aux agents senseurs du NIDS de capturer l’ensemble des paquets réseau. Une fois les prés requis de l’IDS installés, il est nécessaire d’importer les schémas et contenus des bases de données. Trois fichiers (.Sql) contiennent les schémas et informations des bases de données, ces fichiers doivent être importés sur les stations concernées. 7.2 Déroulement de l’exécution de l’IDS Après l’installation de l’ensemble des prés requis de notre IDS, nous pouvons lancer notre IDS. Ø NIDS : Le NIDS sera lancé sur le proxy. Son interface nous renseigne sur l’état de ses composants. Voici les étapes de l’exécution du NIDS : o Création du conteneur « NIDS » pour le système multi-agents. o Lancement de l’Agent « Manager » sur ce conteneur. o L’agent « Manager » se connecte au deux bases de données « Alertes » et « Signatures ». o L’agent « Manager » extrait l’ensemble des signatures d’attaques, applique la théorie de la sélection clonale sur chaque signature et génère un ensemble de détecteurs. o L’agent « Manager » lance les différents agents « Analyseurs » et envoie à chacun un sous ensemble de détecteurs. o Chaque agent « Analyseur » lance son propre agent « Senseur » et lui transmet les filtres de captures des paquets. o L’agent « Manager » envoie aux différents agents la commande de début de surveillance.
FIG 5.8 : Interface du NIDS. L’application d’administration a été développée entièrement en C#.net, elle permet à l’administrateur de contrôler à partir de sa station les différents composants de l’IDS.
FIG 5.9 : Administration de l’IDS. Au lancement de
l’application, l’administrateur se connecte aux différentes sources de données.
Ø L’état des différents SGBD contenant nos trois bases de données. Ø Le nombre de profils utilisateurs et la date de la dernière phase d’apprentissage lancée. Ø Le nombre d’alertes générées par le NIDS et le HIDS. Ø Le nombre de signatures contenues dans chacune des tables de la base de données « Signatures ». L’administrateur peut visualiser rapidement les alertes rapportées sur l’onglet ‘Alertes’ FIG5.10]. Sur l’onglet ‘Configuration’, l’administrateur peut définir les différents paramètres de configuration des deux théories immunitaires (Sélection clonale et sélection négative) FIG5.11]. A partir de cette fenêtre, l’administrateur peut accéder aux trois gestionnaires « Profils », « Signatures », « Alertes » pour plus de détails.
FIG 5.10 : Aperçu rapide des différentes alertes générées. Cet onglet présente un aperçu rapide des différentes alertes avec possibilité de filtrage.
FIG 5.11 : Configuration de l’IDS. Les trois gestionnaires permettent à l’administration un contrôle plus approfondi et lui fournissent plus de détails concernant les différentes sources d’informations de l’IDS. a. Gestionnaires des profils : Cette interface lui permet de visualiser les informations contenues dans chaque profil et de relancer la phase d’apprentissage pour l’ensemble ou une partie des utilisateurs.
FIG 5.12 : Gestionnaire des profils. b. Gestionnaires des alertes : Cette interface permet de visualiser les différentes alertes générées.
FIG 5.13 : Gestionnaire des alertes. Il faut rappeler que le NIDS génère des détecteurs avec la théorie de la sélection clonale à partir d’une signature. Ces détecteurs sont en fait des variantes de la signature. L’avantage de générer des variantes d’une signature est la possibilité de reconnaitre des variantes d’attaque, ou de découvrir de nouvelles attaques. Cependant, ces variantes peuvent augmenter le degré de faux positifs. Donc certaines alertes sont sûres (c.-à-d. avec un degré d’affinité de 100%), tandis que d’autres (reconnues avec des détecteurs ayants un degré d’affinité<100%). Le gestionnaire met en évidence les alertes sûres et fournit un ensemble d’informations permettant d’analyser les autres alertes.
FIG 5.14 : Alertes NIDS. Ø Gestionnaire des signatures : Cette interface permet d’interagir directement avec la base de données des signatures, elle permet de : o Lister les différentes signatures. o Importer / exporter une liste de signatures. o Editer des signatures existantes …etc.
FIG 5.15 : Gestionnaire des signatures. Notre solution étant composée de deux IDS, et étant donnée qu’il n’ya pas de liens directs entre les deux IDS, nous ferons des séries de tests sur chaque composant séparément. Le HIDS a pour tâche de reconnaitre les comportements anormaux des utilisateurs. Sur la base des profils préalablement enregistrés. Notre HIDS génère des détecteurs avec la théorie de la sélection négative, capables de reconnaitre toutes différences entre le profil et le comportement actuel de l’utilisateur. Dans ce but, nous ferons nos tests sur un réseau local composé de trois stations, sur lesquels sera déployé le HIDS esclaves et une machine qui sera dédiée au HIDS superviseur FIG 5.16.
FIG 5.16 : Réseau de test pour le HIDS. La base de données des profils sera hébergée sur la même station que celle réservée au HIDS superviseur et contiendra les profils respectifs de chaque machine. Chaque profil utilisateur contient une liste des processus les plus utilisés, ainsi que la liste des interfaces réseaux que possède l’utilisateur. Sur la base des profils, le HIDS sera capable de détecter les variations suivantes : Ø Informations générales : La variation des informations générales telles que la consommation moyenne des ressources système (CPU, RAM), les horaires d’ouverture et fermeture de session, sera considérée par le HIDS comme étant un comportement anormale. Ø Utilisation de processus : L’utilisation d’un processus qui ne figure pas dans le profil sera considérée comme processus suspect. Ø Information réseau : Pour chaque utilisateur une liste des interfaces réseau ainsi que leurs adresses (MAC et IP) respectives est contenue dans son profil. Ces informations sont généralement attribuées par l’administrateur. Donc si un utilisateur essaie de changer cette configuration, une alerte de tentative d’usurpation d’identité est lancée. Les trois types d’alertes citées ci-dessous seront testés sur les trois stations du réseau. Au lancement FIG 5.17, le HIDS superviseur extrait les paramètres de configuration lui permettant de savoir la phase actuelle (apprentissage / Surveillance) ainsi que d’autres paramètres telles que les seuils définis par l’administrateur. Les seuils représentent un paramètre important à partir duquel le HIDS décidera de générer ou pas des alertes. A titre d’exemple, pour la consommation des ressources systèmes (CPU et RAM), l’administrateur peut décider qu’il y’aura une alerte de surconsommation des ressources, si les valeurs de ces dernières dépassent la valeur moyenne du profil avec un certain ?. Nous nous trouvons dans la phase de surveillance, donc le HIDS superviseur extrait les profils de chaque utilisateur (Med, Samir et Ali), applique la théorie de la sélection négative afin de générer un détecteur pour chaque profil.
FIG 5.17 : Interface du HIDS superviseur. Le HIDS superviseur envoie un message pour informer l’ensemble des stations du réseau qu’à présent nous sommes dans la phase de surveillance. Ces derniers lancent juste après la réception de ce message les deux agents ‘Analyseurs’ et ‘Captor’, qui leurs permettent de surveiller le comportement actuel de l’utilisateur et transmettre les différents rapports au HIDS superviseur.
FIG 5.18 : Déploiement des agents du HIDS superviseur et des différents HIDS esclaves. Ø Sur
la machine 1 (Samir) :
Nous essaierons de faire une surconsommation des ressources en utilisant une
application qui a été développée pour ce test, qui boucle indéfiniment sur la
lecture de différents fichiers à partir du disque dure. Ø Sur la machine 2 (Ali) : Nous essaierons d’utiliser des processus nouveaux qui ne figurent pas dans le profil de l’utilisateur de cette machine. Ø Sur la machine 3 (Med) : On essaiera de changer la configuration réseau de la machine et lancer des commandes Ping vers d’autres machines du réseau. Les agents ‘Analyseurs’ des différents HIDS esclaves, détectent les différentes actions citées ci-dessus comme étant inhabituelles et par conséquents génèrent des alertes qui seront envoyées au HIDS Superviseur, qui se chargera de les répertoriées dans la base de données alertes FIG 5.19.
FIG 5.19 : Alertes générés par les différents HIDS esclaves. Analyse des résultats D’après les tests effectués sur le HIDS, nous constatons que ce dernier détecte tout comportement qui diffère de celui du profil comme étant un comportement anormal et par conséquent génère une alerte. Comme tout HIDS avec analyse par approche comportementale, le point critique ce cette approche est le taux de faux positifs du au fait que le comportement anormal de l’utilisateur n’est pas forcément mal intentionné. D’autant plus qu’il est très difficile de choisir un modèle standard pour le profil à adopté. La théorie de la sélection négative interprète parfaitement le fait que tout comportement différent du comportement type est considéré comme dangereux. L’administrateur du HIDS pourra diminuer du taux de faux positifs en définissant des seuils moins stricts. Notre
NIDS utilise une base de données des signatures d’attaques, sur lesquelles il
applique l’algorithme de sélection clonale afin de générer des détecteurs
capables de reconnaitre cette signature mais également des variantes de cette
dernière. Nous nous intéresserons à deux types d’attaques bien particulières à savoir, l’attaque par injection SQL et l’attaque par débordement de tampon. Ø Les attaques par injection de code SQL sont lancées contre les serveurs de bases de données SQL, elles sont reconnues par la reconnaissance d’une chaine de caractère qui est : '' --, or 1=1. La chaine en question peut être reconnue en analysant le contenu des paquets. Ø L’attaque par débordement de tampon peut être reconnue par le calcul de la longueur des paquets. Avec PacketCreator nous mettrons en place ces deux attaques et nous détaillerons par la suite l’apport des systèmes immunitaires. Au lancement du NIDS, l’agent ‘Manager’ extrait les deux signatures d’attaques. Sur lesquelles il applique l’algorithme de sélection clonale qui permet de générer un ensemble de détecteurs FIG 5.20.
FIG 5.20 : Génération des détecteurs à partir des signatures – NIDS. Les détecteurs générés seront capables de détecter les deux attaques en question, mais également d’autres variantes, qui ont été générées en faisant varier les valeurs des différentes parties de la signature. Cette variation peu donner naissance à des mauvais détecteurs qui augmenterons les taux de faux négatifs. Les principales actions de recherche utilisées sont : ValidStr : Vérifie si les données ne contiennent pas de caractères spéciaux et invalides. LenStr : Longueur de la partie donnée. SubStr : Recherche une sous chaine dans la partie donnée. LenHeader : Longueur de l’entête du paquets. Les différents détecteurs générés par l’agent ‘Manager’ seront utilisés par les agents ‘Analyseurs’ qui permettent de détecter nos simulation d’attaques suivante : Ø 1er test, Mise en place des attaques initiales : A l’aide de PacketCreator nous créerons nos propre paquets avec pour le premier, la partie données qui contient la chaine '' --, or 1=1 et le second avec une très longue chaine de caractères qui dépasse 199 octets.
Ø 2nd test, faux positif généré : Le quatrième détecteur généré à partir de la signature d’injection SQL, sera capable de détecter les sous chaines de la chaine '' --, or 1=1 et qui sont: '' / --, / or / 1=1. Nous avons remarqué que cette décomposition induit forcément à des faux positifs, puisque un paquet qui contient ‘or’ ou qui contient ‘--,’ ne correspond pas à une attaque connue de nos jour.
Ø 3iem test, un faux négatif évité : Le troisième détecteur généré à partir de la signature de débordement de tampon, est un détecteur capable de reconnaitre une attaque, se la longueur de l’entête du paquet dépasse 30 octets. Cette attaque ne figurait pas dans notre base de données, mais après analyse de ce détecteur, nous remarquons qu’il est impossible d’avoir un paquet avec la partie entête qui dépasse les 30 octets, sauf si ce dernier a été édité manuellement, comme nous l’avons fait pour notre test. Analyse des résultats L’application de la théorie de la sélection clonale pour la détection d’intrusion est d’un grand apport, en effet, elle permet de détecter de nouvelles attaques ou des variantes d’attaques existantes. Cependant, du fait qu’elle emploi des mécanismes aléatoires au cours du processus de génération des détecteurs, augmente le taux de faux positifs. Dans le présent chapitre, nous avons proposé notre solution qui consiste en un IDS hybride (NIDS et HIDS) utilisant les deux sources d’informations sur un réseau, à savoir : les paquets réseau et les comportements des utilisateurs. Nous avons utilisé dans notre solution les deux méthodes d’analyses comportementale et par scénario. En s’inspirant des systèmes immunitaires artificiels, nous avons conçu des noyaux pour le NIDS et le HIDS, qui utilisent respectivement l’algorithme de sélection clonale et l’algorithme de sélection négative. Notre solution étant déployée sur un réseau et utilisant des composants physiquement distribués, elle est conçu en utilisant l’approche multi-agents. Dans la partie implémentation nous avons détaillé les outils et langages de programmation utilisés pour développer notre solution. Nous avons utilisé principalement le langage Java pour le développement des deux composants de notre solution : NIDS et HIDS. Nous avons également utilisé le SGBD MYSQL, pour la gestion des différentes bases de données qui constituent notre solution. Enfin pour la partie multi-agents, nous avons utilisé la plate forme Jade. Nous
avons achevé ce chapitre par un ensemble de tests qui nous ont permis de voir
l’efficacité non seulement de notre IDS mais également l’apport des systèmes
immunitaires artificiels pour la détection d’intrusions. Les tests ont été
effectués sur les HIDS et NIDS séparément, sur chaque composant nous avons
effectué trois tests.
L’objectif
de ce projet de fin d’études était de concevoir et implémenter à base d’agents
un système de détection d’intrusions inspiré des systèmes immunitaires. Parmi elles, les systèmes immunitaires artificiels, inspirés des systèmes immunitaires naturels, peuvent s’avérer très intéressant pour le domaine de la détection d’intrusion compte tenu de la similarité des fonctionnalités et des objectifs de ces derniers. Nous nous sommes attardés sur les deux grandes théories qui sont la base de la réponse immunitaire, à savoir la théorie de la sélection clonale et la théorie de la sélection négative. L’étude de ces deux théories immunitaires dans le cas de la détection d’intrusions, a montré que la théorie de la sélection clonale est plus appropriée à l’analyse par scénario, tandis que la théorie de la sélection négative est plus appropriée à l’analyse comportementale. Le choix de l’implémentation d’un IDS est très important, surtout si on prend en considération que l’IDS sera déployé sur un réseau contenant plusieurs machines avec différentes configurations matérielle et logicielle. Le fait que l’IDS soit conçu de manière hiérarchique et soit distribué sur plusieurs machines et nécessitant l’analyse de données en provenance de différentes sources, impose l’utilisation des systèmes multi-agents. Nous avons donc conçu un système de détection d’intrusions hybride (NIDS + HIDS) à base d’agents, analysant les deux sources d’informations (Paquets réseau et comportement des utilisateurs) et utilisant les deux théories immunitaires, à savoir, la sélection clonale et la sélection négative. Les tests effectués sur notre solution avaient pour but de définir l’apport des systèmes immunitaires pour la détection d’intrusions. L’utilisation de la théorie clonale, permet de générer à partir d’une signature d’attaques plusieurs détecteurs capables de reconnaitre non seulement l’attaque en question, mais également des variantes de cette attaque, ou de nouvelles attaques similaires. Par contre, l’utilisation de la théorie de la sélection négative dans le cas d’analyse avec approche comportementale permet de détecter tout comportement anormal et qui soit différent du comportement type de l’utilisateur (Profil). L’analyse des tests a permis de déduire que l’application des théories immunitaires est avantageuse pour la reconnaissance de nouvelles formes d’attaques. En effet, ces méthodes, du fait qu’elles fassent appel à des processus aléatoires dans la phase de génération de détecteurs, génèrent un grand nombre de faux positifs. A partir de ce constat, nous pensons que le développement d’IDS basé sur des AIS peuvent être d’un grand apport dans l’étude de nouvelles attaques et contribuer d’une part à enrichir une base de données des signatures, d’autre part à définir les comportements normaux des utilisateurs d’un système donné. Par ailleurs, compte tenu du nombre important de faux positifs générés, il ne serait pas conseillé de développer ce type d’IDS pour un usage grand public. Afin d’enrichir ce travail, nous nous proposons de donner quelques perspectives : Ø Le maintient des profils : Cette tâche implique une méthode dynamique de mise à jour des profils, qui permet de modifier ces derniers aux fils du temps. Ø La reconnaissance de l’architecture du réseau : Pour une auto-adaptation de l’IDS, ce dernier doit être capable de reconnaitre les différentes machines qui composent le réseau sur lequel il est déployé. Ø Généralisation des profils : Les informations que nous avons prises en considération dans le profil, se limitent à quelques données et qui ont une relation très étroite avec le système d’exploitation. Donc, nous pouvons envisager que l’IDS soit en mesure de reconnaitre le système d’exploitation et utiliser un profil plus adapté à ce dernier. Ø Nous avons supposé dans notre solution qu’il n’existe qu’un seul utilisateur par machine. Cependant, il faut prévoir le fait qu’il yai différentes sessions sur la même machine et par conséquent, différents profils seront enregistrés pour cette machine.
1. Introduction. 2. Packages jade. 3. Outils de la plate forme. 4. Conteneurs. 5. Comportements. 6. Communication
inter-agents.
1. Introduction Nous avons opté dans le cadre du développement de notre IDS et plus précisément la partie qui traite des systèmes multi-agents, d’utiliser une plate forme trés connue, qui a fait ses preuves : JADE. JADE (Java Agent DEvelopement Framework) est une plate forme développée par TILAB en 1999, codée entièrement en JAVA, dans le but de faciliter le développement de systèmes multi-agents et applications conformément au standard FIPA. La plate forme Jade se compose principalement de deux composants : Une plate forme agents compatible FIPA et un package pour le développement d’agents Java. Cette plate forme est fournie avec une License open source LGPL. Le choix du langage de programmation java est essentiellement basé sur le fait que ce langage permet une parfaite programmation orienté objet dans des environnements hétérogènes et distribués. En plus des fonctionnalités telles que l’appelle de méthodes distantes (RMI : Remote Methode Invocation), la sérialisation d’objet…etc. Jade est composé de plusieurs packages, offrants aux développeurs un ensemble de fonctionnalités pré développées. Ces packages prennent en charge la gestion des threads agents, le transport des messages, l’architecture distribuée …etc. 2. Packages jade Jade est composé de plusieurs packages, principalement : Jade.core : Le noyau du système, jade.core implémente la classe agent qui est la classe principale pour l’héritage d’objet de type agent. La classe Behaviour qui est la classe permettant de modéliser le comportement des agents. Jade.lang.acl : ce package inclut les classes de communication d’agents conformément aux standards FIPA. Jade.domain : Contient l’ensemble des classes qui représentent les agents gestionnaires de la plate forme, tels que les agents AMS et DF qui permettent respectivement de gérer le cycle de vie d’un agent, et de fournir un service de pages jaunes. Les pages jaunes répertorient l’ensemble des agents ainsi que les différents services proposés par chaque agent. Jade.gui : l’ensemble de classes permettant de fournir des interfaces graphiques pour la gestion des agents. Jade.mtp : ce package fournie des interfaces que n’importe quel protocole de transport de message est sensé implémenter afin de pouvoir interagir avec la plate forme jade. Jade.proto : Contient l’ensemble des classes qui servent à modéliser les protocoles d’interactions standards. D’autres packages existent tels que jade.wrapper ou FIPA. 3. Outils Jade En plus de l’organisation en packages, jade est fournie avec un ensemble d’outils de gestion, chacun incluant des sous packages de jade.tools et qui sont à leur tour des agents. Ces outils sont : - L’agent RMA (Remote Management Agent) : C’est une console graphique permettant le contrôle et la gestion de différentes plates formes et conteneurs.
Figure A.1 : L’agent RMA de la plate forme Jade L’agent RMA permet de contrôler le cycle de vie de la plate forme et ses agents. - L’agent Dummy : C’est l’outil de débogage et de monitoring, ce dernier est en faite un agent avec une interface graphique permettant l’envoi de message ACL et la surveillance des messages échangés entre agents avec toutes les informations relatives.
Figure A.2 : L’agent dummy de la plate forme Jade. - L’agent Sniffer : Permet de modéliser graphiquement tous les échanges de messages avec une notation très proche de celle utilisée sous UML. Cette modélisation des messages est très pratique pour le débogage des agents en observant l’échange de messages ACL.
Figure A.3 : L’agent Sniffer de la plate forme Jade.
- L’agent Introspector : C’est l’agent permettant de surveiller le cycle de vie des autres agents, les messages échangés et les tâches en exécution. - L’agent DF (Directory Facilitator) : Cet agent permet à l’aide d’interface graphique de gérer des domaines de pages jaunes. L’utilisateur peut même créer un réseau complexe de domaines et de sous domaines de pages jaunes.
Figure A.4 : L’agent DF de la plate forme Jade. - L’aget LogManager : Permet de définir les attributs et les niveaux de journalisation d’événements. - L’agent SocketProxy : Cet agent agit de manière bidirectionnelle entre la plate forme Jade et les connexions TCP IP. A titre d’exemple les messages ACL transmis par la plate forme sont d’abord convertit en messages ASCII puis envoyés à travers des sockets et vice-versa. Cette conversion est à la charge de cet agent. 4. Les conteneurs Une plate forme est composée de plusieurs instances de l’environnement d’exécution Jade. Ces instances sont appelées conteneurs. Chaque conteneur peut contenir plusieurs agents et peut être dans différents états (actifs, suspendu …etc.). L’ensemble des conteneurs actifs constitue la plateforme. Un conteneur particulier doit être toujours actif, c’est le conteneur principal (main-container). L’ensemble des conteneurs peut être distribué sur un réseau permettant ainsi d’avoir une plate forme multi agents distribuée. Cette fonctionnalité est permise grâce au service d’appel de méthodes à distance (Remote Methode Invocation), qui doit être lancé sur les différentes machines sur lesquelles la plate forme est distribuée. Les conteneurs prennent en charge les tâches de gestion des cycles de vie de leurs agents et la communication (envoie et réception de message, gestion des files d’attentes). Le conteneur garde des informations relatifs à tout ses agents lui permettant de les identifier, les invoquer …etc. Une gestion distante est possible grâce à l’interface graphique (GUI). Cette interface permet la gestion complète du conteneur et offre un contrôle complet sur ce dernier, que ce soit en local ou à distance. 5. Les comportements (behaviours) Les agents ont des comportements qui se modélisent par des tâches à accomplir. Chaque tâche est un behaviour qui est une classe contenant principalement deux méthodes - Action() : qui définie les opérations à exécuter. - Done () : qui retourne un booléen indiquant si la tâche est terminée. Différents types de behaviours existent à titre d’exemple : - Cyclic behaviour : C’est une tâche répétitive, qui ne se termine ‘jamais’, sa méthode done() retourne toujours faux. - OneShotBehaviour : Sa méthode action() est exécutée seulement une fois et sa méthode done() retourne vrai. 6. Communication inter-agents La communication entre les agents et un concept clé de la plate forme Jade. Nous avons pu voir dans le chapitre 3, que sans la communication, le rôle des agents se retrouve très réduit. Jade propose un package permettant d’hériter un message qui n’est rien d’autre qu’un objet avec des attributs. - Envoi de messages : La classe agent contient une méthode appelée send() qui prend comme paramètre un objet de type ACL-Message qui a des attributs tels que : Langage, Ontology,Receiver …etc.
ACLMessage message= new
ACLMessage(ACLMessage.REQUEST); message.addReceiver (new
AID("Agent_1",AID.ISLOCALNAME)); message.setOntology("Etat_serveur"); message.setContent("En_Marche"); send(message);
Une fois le message envoyé, il sera mis dans une file d’attente jusqu'à ce que son (ses) destinataire(s) le récupère. - Réception de messages : La réception du message est en fait une lecture de la file d’attente. Cette lecture se fait par un appel de la méthode receive().
MessageTemplate temp = MessageTemplate.and
(MessageTemplate.MatchPerformative(ACLMessage.REQUEST),
MessageTemplate.MatchOntology("Etat_serveur")); ACLMessage msg = myAgent.receive(temp);
Nous pouvons voir qu’avec la plate forme Jade, nous disposons de l’ensemble des outils necessaire à la l’implémentation de notre solution.
Annexe II : Techniques de piratage informatique 1. Attaques réseaux. 2.
Attaques applicatives.
Différentes techniques de piratage informatique existent, telles que les détournements d’informations, piratage de logiciels, déni de services…etc. Quelque soit le domaine ou le genre d’activités, les types d’attaques sont propres à chacun d’eux. Nous citons ci-après les attaques les plus connues [BUR06]. 1. Les attaques réseaux Ce sont des attaques liées à des failles dans des protocoles réseaux ou des failles dans leurs implémentations voici quelques unes des attaques les plus connues : 1.1 Les techniques de scan C’est la première étape de plusieurs attaques. Les techniques de scan ne sont pas considérées comme des attaques, mais le début d’une attaque. Après l’utilisation des techniques de scan, une quantité importante d’informations peut être récoltée (Les ports ouverts, Les services exécutés, les versions des logiciels utilisés, le système d’exploitation, les failles existantes dans le système…etc. Il existe plusieurs variantes de cette technique telles que Le scan connect, le scan SYN, le scan NULL, FIN et XMAS, le scan à l’aveugle et le scan passif. 1.2 L’IP spoofing Le but de cette attaque est de se faire passer pour quelqu’un d’autre dans le but de gagner des privilèges supplémentaires ou avoir accès à des ressources, cette méthode est surtout utilisée dans le cas où il existe des mécanismes d’authentification basés sur l’adresse IP tel que Rlogin et SSH. L’attaquant ne
prendra pas réellement l’adresse voulue, mais il pourra modifier ses paquets
sortants en usurpant son adresse grâce à des utilitaires permettant de créer
des paquets avec les informations désirées tel que Hping2 ou PacketCreator. Le
problème avec cette méthode est que la réponse sera envoyée à l’adresse
spécifiée et donc l’adresse de la machine pour laquelle l’attaquant s’est fait
passé. Il devra alors récupérer le paquet envoyé en réponse. 1.3 L’ARP spoofing Sert à détourner le trafic d’une machine vers une autre. Pour réaliser cette attaque, il faudra compromettre le cache ARP de la machine victime en lui envoyant des trames indiquant que l’adresse IP d’une autre machine est la sienne. Le cache ARP est régulièrement vidé, il faudra veiller à ce que l’usurpation soit maintenue. Une fois le cache
ARP usurpé, le pirate reçoit le trafic initialement destiné à la victime.
L’attaquant pour ne pas éveiller les soupçons peut rediriger le trafic vers la
victime. 1.4 Le DNS spoofing Cette technique
permet de rediriger les internautes vers des sites pirates dans le but de
récupérer des informations. L’attaquant cible les serveurs DNS , pour faire
correspondre une fausse adresse ip à un nom de domaine par exemple (le site
http://www.mabanque.com est hébergé sur le serveur 89.90.129.20). Lors des
requêtes des internautes aux serveurs DNS correspondants, le pirate répond par
une autre adresse IP qui serait préparée pour avoir une page simple semblable à
celle du site originale, mais qui renvoie les informations confidentielles
(login, numéro de sécurité sociale, numéro de carte de crédit …etc.) aux
attaquants. Il existe deux façons connues pour effectuer cette attaque : 1.4.1
DNS cache poisonning : Les serveurs DNS possèdent un cache contenant les adresses
dernièrement trouvées ou les adresses les plus fréquentes. 1.4.2 DNS Id spoofing : Une requête DNS est accompagnée d’un identifiant qui sera associé à la réponse du serveur DNS, si le pirate arrive à retarder le serveur par une attaque de déni de service et utilise le numéro d’identification pour répondre à la victime par une autre adresse IP, il pourra la rediriger vers un autre site. 1.5 Fragments Attacks Cette attaque consiste à contourner les protections des équipements de filtrage IP dans le but d’effectuer des attaques ou de récupérer des informations. Il existe deux variantes de cette attaque 1.5.1 Fragments Overlapping : Cette méthode utilise une faille dans les filtres analysant des paquets. L’attaquant envoi une demande de connexion avec des paquets chevauchés et contenant des offset erronés, les filtres analysent les paquets indépendamment, ne détectent pas l’attaque et lors de la défragmentation, la connexion est établie et l’attaque a lieu. 1.5.2 Tiny fragments : Fragmenter la demande de
connexion en deux paquets. Le premier de taille minimale ne contenant que les
adresses sources et destination. Ce paquet n’est pas bloqué par le filtre,
puisqu’il ne contient aucune information suspecte. 1.6 TCP Session Hijacking Cette attaque est menée dans le but de contourner une protection par mot de passe, en essayant de détourner le trafic TCP. Cette attaque est menée en désynchronisant une session entre un utilisateur et le serveur, après écoute du réseau, en créant un paquet contenant comme adresse source l’IP de l’utilisateur et le numéro d’acquittement attendu par le serveur, et il injecte une commande dans la session préalablement établie. 2. Attaques applicatives Dans ce genre d’attaque, le pirate
utilise des failles dans des logiciels ou des erreurs de configuration [BUR06]. 2.1 Les problèmes de configuration La plupart des logiciels, sont installés avec la configuration par défaut, et rares sont les administrateurs qui prennent le temps de comprendre les paramètres de leurs applications. La majorité d’entre eux vont vite choisir la configuration par défaut, celle qui facilite l’exploitation du logiciel, sauf que celle-ci utilise également des droits d’accès par défauts (login : root, password : root) 2.2 Les bugs Des erreurs de programmation sont parfois fatales. La plupart des erreurs mènent à des attaques de type buffer overflow, par exemple dans une application, dans une ligne de saisie si la valeur attendue est un caractère qui sera copié dans une zone mémoire et si le programmeur ne fait pas la vérification du type et de la longueur de la chaine en entrée, une erreur de débordement de tampon ou d’accès à une zone mémoire non autorisée est signalée. Dans ce cas, on devra attendre les patchs des programmeurs. 2.3 Le buffer overflow Ce genre d’attaques est très fréquent et très particulier, un débordement de pile peut même permettre l’exploitation du Shell à distance. La raison est presque toujours la même : une mauvaise programmation. L’attaquant peut aussi accéder à des zones mémoires importantes. 2.4 Les injections SQL Comme son nom l’indique c’est une injection d’un code SQL dans une requête afin de récupérer des informations. 2.5 Les scripts Certains langages de programmation web ont une particularité très importante : la programmation côté serveur. Cette approche a révolutionné le web elle est connue sous le nom du Web Dynamique (PHP,ASP,JSP,PERL). Cependant, cette approche permet à une personne malveillante d’exécuter du code directement sur le serveur. Si l’attaquant parvient à uploader un fichier contenant des commandes lui permettant d’avoir accès au serveur, l’attaque est réussie. 2.6 Man in the middle Dans ce genre
d’attaques, l’attaquant détourne le trafic initialement entre deux stations en
le faisant passer par sa station, et assure l’acheminement des données aux
deux stations. 2.7 Attaque DOS Ce genre d’attaques vise à mettre la victime hors service. Cette attaque est mise en œuvre par la surcharge du réseau d’informations inutiles. Généralement lancées contre des serveurs d’applications ou des serveurs web. 2.7.1 Syn flooding : Cette attaque consiste à saturer le système distant par des demandes connexions auxquelles le pirate ne répond pas. Le pirate envoie des demandes de connexion avec SYN, la victime répond par SYN-ACK et attend la validation par le hacker, toutes ses demandes de connexion occupent des ressources mémoires, ce qui cause le blocage du système distant. 2.7.2 Udp flooding : Les paquets UPD passent avant les paquets TCP, le pirate essaie de submerger la victime par un nombre important de paquets UDP, ce qui bloquera toutes les connexions TCP. 2.7.3 Packets fragment : Cette méthode utilise une mauvaise défragmentation du protocole TCP. 2.7.4 Smurfing : Le pirate peut lancer une attaque à partir d’une autre machine vers sa cible. Il envoie des requêtes ICMP ECHO en modifiant son adresse et indiquant l’adresse de sa cible, une grande quantité de réponses sera envoyée à la victime, ce qui provoquera son blocage et l’utilisation de toutes ses ressources. 2.7.5 DDOS : Denis de Service distribué, ici on lance une très grande attaque à partir de plusieurs points différents au même moment, ce qui provoquera un crash de la cible. Les plus grandes attaques DDOS ont été lancées à partir de réseaux zombies. Les participants à cette attaque ne se rendent pas compte qu’ils ont fait partie d’une attaque à grande échelle. Après chaque attaque, le pirate tente d’effacer ses traces. Généralement des fichiers de journalisation sont gardés dans les machines et serveurs, indiquant ainsi toutes les connexions et les usages fait de ces dernières. Donc pour se protéger, l’attaquant devra pour finir supprimer les fichiers journaux ou bien ses traces qu’il a laissé dans ces derniers.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
