Corrélation d événements et d alarmes pour la détection d intrusions dans les systèmes répartis.

Transcription

1 Laboratoire d Informatique Fondamentale d Orléans U.F.R. Sciences - Université d Orléans Master IPVGCA: Informatique : Parallélisme, Vérification, Graphes, Contraintes et Apprentissage Corrélation d événements et d alarmes pour la détection d intrusions dans les systèmes répartis. Etude présenté par : Jonathan ROUZAUD-CORNABAS Effectué au laboratoire: Laboratoire d Informatique Fondamentale d Orléans Projet SDS: Sécurité et Distribution des Systèmes. Localisé à l ENSI-Bourges.

2 Contents 1 Remerciements 4 2 Introduction 5 3 Etat de l art: Détection d Intrusions par Corrélation Introduction Scénario d attaque Vocabulaire Agrégation Probabiliste Pre/Post Condition LAMBDA: A Langage to Model A Database for Detection of Attacks Ning Approach Model Checker Queue Graph Corrélation IDS/Vulnerability Analysis Data Mining Stockage des évènements IDS: Database Versus Memory Correlation et Réseau Neuronal Framework de corrélation Corrélation décentralisée Discussion Motivations 27 5 Framework de Corrélation Distribuée Introduction Contexte pratique des travaux IDS Contrôle d accès Méta-Politique SELinux PIGA Proposition d un framework de corrélation distribuée Introduction Preprocessing Alert Fusion

3 5.3.4 Alert Verification Attack Thread Reconstruction Attack Session Reconstruction Attack Focus Recognition MultiStep Correlation Impact Analysis Alert Prioritizing Alert Sanitization Algorithmique du framework de corrélation Introduction Preprocessing: élimination des malformations Identification et normalisation d alarme Relativisation temporelle Identification de session Alert Fusion Attack Thread Reconstruction Attack Session Reconstruction Attack Focus Recognition Pattern Recognition Alert Prioritizing MultiStep Correlation LinkToSession LinkBackToSession Island Hopping Exemple d un scénario avancé Apprentissage Implantation de l architecture de corrélation Framework de Corrélation Distributivité Stockage des évènements Expérimentation sur les bases de données: Résumé Calcul distribué PIGA: Les nouvelles fonctionnalités Les timestamps Les traces réseaux Les numéros de session L injection dans une base de donnée Optimisation de l architecture de corrélation Expérimentation sur les bases de données MySQL: Introduction MySQL: Stockage en mémoire MySQL: Cluster MySQL Cluster: retour sur expérience Un successeur à MySQL Expérimentation sur les calculs parallèles Introduction Thread

4 8.2.3 Architecture Distribuée Mise en place d une grille Java Programmation Java sur une grille Benchmark de la grille Java Un cache distribué: Oracle Coherence Expérimentations HoneyPot Etude manuelle Framework Preprocessing Alert Fusion Numéro de session Attack Thread Reconstruction Attack Session Reconstruction Attack Focus Recognition Pattern Recognition Alert Prioritizing MultiStep Correlation Apprentissage Synthèse Perspectives Conclusion 92 A Automate 93 A.1 Introduction A.2 Noeud A.3 Transition A.4 Automate A.5 Comparaison B Classification manuelle 97 3

5 Chapter 1 Remerciements Je tiens à remercier l ensemble de l équipe du projet SDS du LIFO pour m avoir acueilli pendant ce stage et tout particulièrement Patrice Clemente et Jeremy Briffaut pour leur aide et encadrement. Je remercie également le LIFO et l ENSIB pour m avoir permis de participer à la conférence CTS 07. 4

6 Chapter 2 Introduction La sécurité des systèmes d informations est un enjeu crucial du 21ème siècle. L interconnexion massive des systèmes informatiques les rend de fait plus vulnérables. Aussi de nombreux travaux s intéressent à la protection des systèmes, la prévention des attaques, la réduction des risques, et la réparation des dégats. Nos travaux s inscrivent dans une démarche développée au sein de l équipe-projet Sécurité et Distribution des Systèmes (SDS), du LIFO. Cette démarche essaie de concilier au mieux d une part, les aspects concernant la protection des système, notamment en termes de contrôle d accès et d autre part, les aspects de surveillance (monitoring) et surtout de détection d intrusions. En particulier, nous visons par ces travaux à augmenter le pouvoir de détection d intrusions des systèmes actuels, et notamment de PIGA IDS [BBLT06a] (Intrusion Detection System based on Policy Interaction Graph Analysis), développé au sein du projet SDS du LIFO. PIGA-IDS est un IDS 1 basé sur des politiques de sécurité. PIGA vérifie en effet qu il n y a pas d opérations enfreignant la politique de sécurité définie sur le système. PIGA est de plus capable de vérifier que les séquences d opérations sont elles aussi en conformité avec la politique de sécurité concernant les séquences. PIGA se fonde pour son fonctionnement sur des politiques de contrôle d accès mandataire [BBLT06b, BCH05]. Notre travail de Master part du postulat que la plupart des systèmes de détection existants sont performants mais très spécialisés et fonctionnent de façon cloisonnée (indépendamment des autres). En terme de contribution scientifique, notre positionnement est le suivant : plutôt que de chercher à définir et implanter un système de détection d intrusion ou IDS (pour Intrusion Detection System) nous souhaitons faire collaborer (au sens des informations qu ils fournissent) les différents outils existants. Cela signifie concrètement de corréler les diverses informations concernant les événements systèmes et réseaux, informations retournées par l analyse constante et dynamique du réseau et du système par les différents outils, IDS réseaux (ou NIDS) et systèmes (ou HIDS) Il existe déjà des travaux de détection d intrusion par corrélation mais à l heure actuelle, ces travaux se basent sur les outils classiques tels que NIDS pour lesquelles les informations de sessiosn restent assez limitées. En particulier, une fois que l attaquant a pénétré le système les outils HIDS sont incapables de de fournir les informations nécessaires au traçage des actions de l attaquant sur la machine pénétrée. Ces informations sont disponibles dorénanvant par l intemédiaire de PIGA ce qui permet ainsi d espérer 1 Intrusion Detection System: Système permettant de surveiller l ensemble d un système informatique. 5

7 la reconstruction de séquences complètes d alarmes, depuis la toute première alerte réseau, jusqu à l opération ultime de l ensemble des actions effectuées par l attaquant sur le système. Un premier aspect du travail consistera donc en la constitution d un ensemble de schémas représentant les événements effectués pour mener à bien une attaques donnée. Ce premier travail consistera donc à analyser les intrusions rencontrées sur un honeypot 2 et essayer manuellement de tracer les attaques complètes, c est-à-dire de suivre la séquence des opérations effectuées sur le système une fois l intrusion (entrée sur le système) réussie, afin de représenter à l aide d un formalisme donné (et les stocker concrètement dans une base de données). Cela correspondra à une premier phase manuelle de corrélation chronologique et temporelle des événements hétérogènes, liés pourtant à une même session 3. Le but de cette première phase est de parvenir à connaître un peu mieux les attaques locales (sur une seule et même machine) mais aussi des attaques migrantes (l attaquant se déplace de machine en machine durant l attaque globale) ou distribuées (l attaquant utilise plusieurs machines pour mener à bien son attaque, ou destinées à plusieurs machines qui en sont la cible). Ensuite, en fonction de la base de connaissances acquise sur les attaques, et en nous appuyant sur la littérature du domaine, nous chercherons à identifier les corrélations les plus appropriées à effectuer pour construire les connaissances les plus pertinentes et complètes possibles sur les données brutes dont nous disposerons (alarmes reportées par les IDS). L un des objectifs à ce stade est de parvenir à reconstituer automatiquement des sessions complètes d attaques. Nous essaierons de formaliser ces traitements sous la forme d un ensemble d algorithmes spécifiques de corrélation. Cela se traduira par la proposition d un framework conceptuel et son implémentation sous la forme la plus souple possible. Vu le grand nombre d alarmes générées par les outils actuels, les alarmes devant a priori toutes être traitées, il est probable que les techniques de répartition des bases de données et/ou de traitement des données devront être étudiées, comme c est d ailleurs déjà le cas dans la littérature 4. Nous chercherons à définir les moyens nécessaires à la mise en oeuvre d un système de détection par corrélation capable, d une part de détecter et classifier des intrusions et plus globalement, de fournir à l administrateur des sessions complètes d attaques, et d autre part, d être capable d apprendre automatiquement de nouveaux schémas (ou patterns) d attaques. Le document est structuré comme suit. Le chapitre 3 présente un état de l art sur les travaux de détection d intrusions par corrélation et termine par une discussion sur les forces et faiblesses des solutions existantes. Cette discussion nous permet, au chapitre suivant d exposer nos motivations précises pour ce travail. Au chapitre 5, nous introduisons un framework de corrélation issu de certains travaux de la littérature, auquel nous ajoutons quelques éléments marquants. Ce framework regroupe un ensemble de fonctionnalités permettant d effectuer différents types de corrélation. Au chapitre 6, nous formalisons ce cadre et définissons explicitement l ensemble des algorithmes nécessaires aux différents types de corrélation proposées. Nous y introduisons quelques 2 Un honeypot (en français pot de miel) est un ordinateur ou un programme volontairement vulnérable destiné à attirer et à piéger les pirates informatiques. 3 Une session est un ensemble d alarmes générées par un IDS représentant le comportement d un attaquant lors d une tentative d intrusion. 4 De nombreux travaux s intéressent aux aspects techniques de la corrélation, du point de vue des ressources CPU et mémoires à utiliser, car cet aspects est couvent bloquant pour une corrélation pertinente, c -est-à-dire travaillant sur des ensembles de données brutes importants. 6

8 exemples de signatures corrélatives d attaques. Le chapitre 7 présente l implantation du framework. Le chapitre 8 fait place à notre étude et nos réalisations permettant d optimiser la gestion mémoire et la répartition des requêtes de corrélation. Le chapitre 9 fait place aux expérimentations et les premiers résultats encourageants obtenus. Le chapitre 10 établit une synthèse de l ensemble des travaux. Le chapitre 11 dresse une liste de perspectives détaillées à donner à ces travaux. Le chapitre suivant constitué la conclusion générale à ce document. L annexe A présente les automates représentant les attaques, et précisément les algorithmes de manipulation de ces automates. Enfin l annexe B présente un certain nombre de résultats concernant l étape de classification manuelle des attaques. 7

9 Chapter 3 Etat de l art: Détection d Intrusions par Corrélation 3.1 Introduction Nous proposons ici un aperçu assez large du domaine de la détection d intrusion (DI) par corrélation. Nous synthétisons donc les travaux les plus marquants dans ce domaine ainsi que le vocabulaire nécessaire à la compréhension du document. Cet état de l art n a pas prétention à être exhaustif mais pose les bases des référents théoriques et pratiques sur lesquels nous nous sommes appuyés pour nos travaux. Le principe général de la corrélation est d assembler/agréger/regrouper des informations provenant de sources différentes et indépendantes, de façon supervisée (guidée) ou totalement automatique pour faire apparaitre de nouvelles informations. Dans le cadre de la DI, il s agit de dépasser les limites des systèmes existants pour fournir, à partir d informations brutes, parcellaires et dispersées, (...) ou des informations plus précices, ou de nouvelles informations, à savoir : soit confirmer ou infirmer des intrusions déjà détectées par des outils classiques, soit être capable de détecter des attaques/intrusions non détectées jusque là. Sous le terme d attaque, nous regroupons la notion d attaque simple (par exemple, une tentative de connexion à une machine), mais aussi la notion d attaque plus complexe, telle qu une tentative de connexion réussie (intrusion) et la suite des actions malveillantes effectuée par l intrus. 3.2 Scénario d attaque Les auteurs [SHM02] ont pu constater qu une alarme 1 est rarement isolée, elle fait en général partie d un scénario plus vaste. Partant de ce constat, ils se sont fixé comme principal objectif de la corrélation, la capacité a reconstituer des scénarios d attaque. Les auteurs [KVV05] ont, quant à eux, proposé comme autre objectif la possibilité de générer un rapport d intrusion complet à partir d alarmes. Le processus de corrélation va consister en une méthode permettant de pratiquer une liaison logique entre N alarmes provenant d une ou plusieurs sources d information. La corrélation va donc 1 Une alarme correspond à une possibilité d intrusion telle que, vue par un IDS, c est-à-dire, une action (ou suite d actions) malveillante unique et isolée détectée par l IDS. 8

10 permettre, à partir d alarmes IDS ou systèmes bas niveau, de construire un scénario d attaque plus ou moins générique et de détecter des attaques incluses dans le surensemble défini par le scénario. L un des prerequis est que les alarmes IDS ne soient pas corrompues entre l instant où elles sont générées et celui où elles sont utilisées pour le processus de corrélation. Au fur et à mesure qu un scénario [DC05] est construit à partir de différentes alarmes, son niveau de priorité va augmenter. Ces scénarios peuvent servir aussi bien à la détection, la défense ou/et le forensics 2. Trois types de corrélation existent: basée sur les similitudes entre 2 alarmes (ie même source, etc): méthode de regroupement sous forme de cluster par comparaison des valeurs (clustering correlation method), i.e., la comparaison des champs et des valeurs entre deux alarmes. basée sur les prérequis et les conséquences d une attaque: méthode de corrélation causal 3 (causal correlation method), i.e., la définition de prérequis et de conséquences à chaque alarme afin de pouvoir reconstituer le scénario. basée sur la connaissance: signature, i.e., en définissant des comportements d intrusion et en comparant ceux ci aux alarmes reçues. Le but du processus de corrélation est d utiliser ces 3 types pour maximiser les possibilités de détection. Pour calculer l efficacité d un système de corrélation, les auteurs [NX02] introduisent deux mesures qui permettront de classer les différents systèmes de corrélation les un par rapport aux autres. Complétude (Completness) ie si les alarmes ont bien été corrélées entre elles. R c = #correctlycorrelatedalerts #relatedalerts Validité (Soundness) ie si les alarmes ont bien été corrélées comme il le fallait. R s = #correctlycorrelatedalerts #correlatedalerts Le probleme du scénario de corrélation est qu il ne refléte pas totalement la stratégie d attaque (i.e. il détermine un flux d alarme qui représente une stratégie d attaque et pas la stratégie elle-même) et donc des petits changements peuvent provoquer une non-détection de celui-ci e.g.: une répetition inutile d un événement, l utilisation de la même méthode par une autre personne/outil, etc. Les auteurs [CO00] introduisent par conséquent une méthode efficace pour les comparer qui devra être précise tout en acceptant l abstraction. Elle va prioritairement chercher les couples attributs/valeurs (i.e. les attributs sont l ensemble des champs instanciés pour chaque alarme e.g. username et les valeurs sont le ou les contenus de ces attributs e.g. username= foobar ) qui ne changent pas d une utilisation à une autre pour le même scénario d attaque. Cinq types de variation de session d attaque peuvent survenir: Mutation: la plus simple et correspond à des changements dans les valeurs de certains attributs (eg. IP, port, username). Resequencing: modification de l ordre temporel des alarmes. 2 Le forensics correspond au domaine de la récupération de système après une intrusion et regroupe des méthodes permettant de relever des indices sur le déroulement, la source et les répercussions de cette intrusion. 3 Le causal est un cas exprimant la raison ou le motif de l alarme exprimée. 9

11 Substitution: remplacement d une ou plusieurs étapes (et donc des alarmes correspondantes) de l attaque par d autres. Distribution: utilisation de plusieurs valeurs pour le même attribut (eg. plusieurs adresses source IP). Looping: répétition inutile de certaines parties du scénario. Pour éviter le problème du temps et du classement temporel entre les alarmes, [WLJ05] abstraient légérement en déclarant que si deux alarmes sont espacées d un temps inférieur à t alors ils sont considérés comme parallèles. Les graphes (ou les autres représentation des scénarios d attaques) sont utilisés de deux façons: en détection passive à postériori (backward), en remontant ce qui va permettre de corréler uniquement les sessions d attaques étant allé jusqu à un certain but et en prévention en anticipant (foward) ce qui permet de prévoir la suite des évènements. En plus de la corrélation entre alarmes IDS, les auteurs [NRJ04] proposent d utiliser des informations provenant des scans de vulnérabilité (voir section 3.9) mais aussi provenant de sondes de monitoring ou d informations tierces sur le réseau. Dans de nombreux cas, ces scénarios d attaque sont construits à la main ce qui provoque beaucoup d erreurs, ils sont souvent trop grands et inutilisables, les auteurs expriment le besoin de définir des méthodes pour apprendre ces scénarios. Devant la complexité de certains graphes d attaques, ils recommandent de prévoir un mécanisme permettant de réduire ces derniers afin qu ils puissent être étudié et visualisés par l Homme. Les intérêts principaux de la corrélation sont un haut niveau de représentation des alarmes. une reconstitution du scénario complet. une réduction des faux positifs. la capacité de détecter des attaques complètes. la possibilité de détecter des variantes d attaques connues. la possibilité de découvrir de nouvelles attaques. la capacité d éliminer une partie des faux positifs (car ils sont aléatoires) ou tout du moins, augmenter la priorité des alarmes corrélées et donc qui ont plus de chances d être de réelles attaques. Les problèmes principalement sont: qu elle se base sur des alarmes provenant d IDS ou d autres évènements de plus haut niveau (logs,...) donc des riques de faux-positif et faux-négatif mais aussi que ces derniers prennent par à la corrélation. que les sessions d attaque peuvent muter d une instanciation à une autre du même scénario d attaque. qu elle ne permet pas de détecter des profils d attaque n ayant pas encore eu lieu. que la qualité est toujours influencée par les faux-positifs et faux-négatifs. que la surcharge de la demande de puissance de calcul d un senseur peut mener à une perte d alarmes. 10

12 que trouver des filtres proprent à chaque IDS demande un travail de parsing relativement long. que cela se base sur une très bonne connaissance des différents types d attaques. qu en utilisant les alarmes IDS, pour l apprentissage, le risque d apprendre des scénarios qui utilisent partiellement ou totalement des faux-positifs est important mais également de ne pas reconnaitre des scénarios dans leur ensemble car certains aspects ne sont pas détectés (faux-negatif). que si une alarme n est pas corrélé avec un scénario d attaque alors ce n est pas forcément est un faux-positif. 3.3 Vocabulaire Nous introduisons ici le vocabulaire courant du domaine, provenant de différentes publications, nécessaire à la compréhension du document. Un glossaire complet se trouve à la fin du document. Action Malicieuse (Malicious action): une action qui ne respecte pas la politique de sécurité. Action Suspicieuse (Suspicious action): une action qui peut mener vers un scénario de malicious action. Attaque Silencieuse (Stealth attack): elle ne va pas génerer d alarme(s) IDS (faux-negatif). Attaque Détectable (Detectable attack): elle va génerer des alarmes IDS (vraipositif). Session Corrélée: un groupe d alarmes qui font partie de la même attaque, il peut y avoir des duplicats pour chaque alarme. Le but est de chercher les conséquences (ou prévenir les conséquences) de cette attaque. Aggregation: regroupement d alarmes suivant certains critères. Duplicat (Duplicate): un événement peut correspondre à plusieurs alarmes. Generalisation: Le but est d abstraire plus ou moins certaines valeurs d attributs qui composent une alarme afin de regrouper un plus ou moins grand nombre d alarmes ayant les mêmes prédicats en commun (e.g. remplacer l IP source d une alarme par l ensemble du réseau source). Cette abstraction implique en retour une perte de précision des informations composant l alarme. Ce taux de généralisation doit être réglé suivant les besoins et peut changer suivant le scénario et entre les étapes d un même scénario. La difficulté de la généralisation étant de regrouper suffisament d alarmes sans perdre trop d informations. Session d attaque: rassemblement d alarmes liés entre elles par des contraintes tel que les adresses IP et la temporalité. Thread: reconstitution d un ensemble d alarmes généré depuis un senseur par une seule et unique session. 11

13 Incident de Sécurité (Security Incident): corrélation d un accident depuis les alarmes de plusieurs senseurs. Cluster d alarmes (Alert Clustering): Regroupement d alarmes qui forment des groupes (méta-alarmes) suivant un certain nombre de prédicat commun (e.g. username == foobar ) pouvant provenir de plusieurs senseurs différents. Mesure de similarité (Similarity Measure): Comparaison uniquement entre les attributs qui sont présents dans les 2 alarmes (feature overlap) et généralisation de certains attributs. Par exemple, une IP en un réseau, un port en une serie de port e.g devient *.*. Niveau de similarité attendu (Similarity Expectation): le niveau de similarité attendu pour chaque argument. Niveau de similarité minimum accepté (Minimum Similarity): le minimum de similarité accepté mais n implique pas que cela soit suffisant pour la classification d une session comme intrusive (ou faisant partie d une classe d intrusion). Hypothétisation: le but est de partir de l hypothèse que les IDS peuvent n avoir pas détecté certaines attaques provoquant une rupture dans le scénario et l impossibilité de finir de détecter ce scénario. Alarme fusionée (Alert Fusion): combine les alarmes qui correspondent à la même étape dans un scénario et provenant de plusieurs senseurs. Vérification des alarmes (Alert Verification): élimination des faux positifs et des attaques n ayant pas abouti pour ne pas géner la corrélation. Cette vérification peut être passive en utilisant une base de connaissance ou active en vérifiant via du monitoring la disponibilité des machines et des services mais également via des scans de vulnérabilité, des scripts, etc (applicable plus particulièrement aux NIDS, e.g. via l utilisation de filtres, suppression de l ensemble des alarmes réseaux destinées à une machine ou un service qui n est pas présent sur le réseau au moment de la génération de l alarme). Reconstruction de thread (Thread Reconstruction): le but est de regrouper les alarmes lancées depuis un attaquant vers un host c est-à-dire les alarmes ayant la même source et la même destination dans une fenêtre de temps. Reconstruction d une session d attaque (Attack Session Reconstruction): cette méthode a pour but de lier les alarmes provenant de différents IDS pour reconstituer la session, e.g., pouvoir lier les alarmes NIDS avec celles de HIDS correspondantes. Reconnaissance par focus (Focus recognition): permet d identifier les hosts qui sont la source ou la destination de nombreuses attaques et fusionner ces dernières en une seule e.g. scanning, DDOS 4. En pratique, utilisation d une méthode de focus se basant sur un certain nombre de prédicat pour détecter si une fusion d alarme regroupent plus d alarmes qu une constante. 4 L attaque par déni de service ou Denial of Service (DoS) vise à rendre une application informatique incapable de répondre aux requêtes de ses utilisateurs. Celle-ci devient DDoS - Distributed Deny of Service - quand l attaque provient de plusieurs sources simultanément. 12

14 Scénario distribué: scénario se déroulant sur plusieurs machines en série et/ou en paralléle. Niveau ajustable de réduction (Adjustable reduction): niveau de généralisation de la phase d agrégation pour regrouper un nombre plus ou moins grand d alarmes suivant la précision ou non des prédicats utilisés. Augmentation de la priorité (Focused Analysis): permet de se focaliser sur une partie des alarmes en utilisant des comparateurs logiques entre les attributs et leurs valeurs (ex: Source_IP = ) permettant d augmenter (ou de diminuer) la priorité de celles-ci. 3.4 Agrégation Le but de l agrégation est de rassembler en une seule méta-alarme un ensemble d alarmes qui partagent une série de valeurs d attributs en commun. Les auteurs [DW01] ont introduit cette méthode afin de pouvoir détecter des attaques de type scan et/ou DDOS facilement et rapidement, de plus, l ajout d une fenêtre de temps permet de réduire la complexité du processus d agrégation e.g. si les auteurs détectent plus de X alarmes relevant d une attaque précise (comme une tentative DoS) mais provenant de plusieurs sources, ils vont pouvoir rassembler ces alarmes en utilisant un taux de similarité fixe entre chaque attribut et cela dans un intervalle de temps Y. Ce taux de similarité est fixé pour chaque attribut avec une valeur variant entre 0 et 100. Par exemple, dans une tentative de DDOS, une majorité des attributs des alarmes est identique, comme la destination IP, et aura donc un taux de similarité proche des 100% et une minorité des attributs sera totalement variable d une alarme à une autre, comme la source IP, et aura un taux de similarité proche des 0%. 3.5 Probabiliste Les auteurs [VS01, VS04] proposent une approche probabiliste afin de pouvoir corréler des alarmes entre elles en acceptant un taux d erreurs pour les valeurs des attributs qui composent les alarmes et assimiler une alarme à une autre alors qu elles ne le sont pas exactement (les valeurs de leurs attributs ne sont pas strictement égales deux à deux), afin de pouvoir y arriver, seuls les attributs qui sont commun aux deux alarmes sont pris en compte. Les auteurs précisent le besoin de faire définir par l utilisateur le degré minimal de similitude entre les deux alarmes. En pratique, leur but est de comparer les nouvelles alarmes avec les anciennes pour essayer de trouver des similitudes. Pour les auteurs [VS02], il faut corréler les nouvelles alarmes avec des méta alarmes (qui sont composées de différentes alarmes provenant de différents senseurs), pour cela il faut chercher ce qu elles ont en commun - feature overlap (par exemple: la source IP, les ports) mais également les similitudes (par exemple: est ce que les IP sources appartiennent au même réseau). Pour optimiser le processus de corrélation probabiliste, ils ajoutent l utilisation de matrices d attaque qui vont comporter le taux de similitude entre 2 classes d alarmes. Pour cela, les auteurs calculent la similarité attendue (expectation of similarity) entre les deux classes d alarmes concernées par rapport à ce qui a pu être observé dans le passé. Par exemple: le degré de similarité entre une alarme de type DENIAL_OF_SERVICE et PRIVILEGE_VIOLATION. Leur but étant de pouvoir assigner des importances plus ou 13

15 moins grandes à certains attributs suivant le type d attaque (par exemple: il est connu que la source IP a des risques d être falsifié pour certains types d attaques). [VS02] proposent également un degré minimal de similarité entre deux attributs, ce degré minimal n est pas suffisant pour pouvoir corréler deux alarmes entre elles mais c est le minimum requis. Sans ce degré minimal atteint, la suite du processus de corrélation ne sera pas lancée. Leur but est de recréer les threads par senseurs puis de regrouper les threads correspondant à la même attaque et provenant des différents senseurs enfin de créer le circuit totale de l attaque. [VS02] proposent de mesurer la similitude de façon suivante: SIM(X, Y ) = j E jsim(x j, Y j ) j E j où: X = la méta alarme de référence. Y = une nouvelle alarme j = l index de l attribut à prendre en compte E j = la similarité attendu entre les 2 attributs X j, Y j = la valeur de l attribut j pour les alarmes X et Y (la valeur peut être une liste). La niveau de similarité entre X et Y correspond à la somme des multiplications entre la similarité attendu et la similarité effective des attributs des deux alarmes qui est ensuite divisé par la somme des similarités attendues des attributs des deux alarmes. La similarité attendue pour chaque attribut entre deux alarmes de type DoS (qui a été fixé précédemment par l utilisateur) est mise en comparaison avec les valeurs réelles des attributs des alarmes X et Y ce qui nous permet de connaitre le taux effectif de similarité entre ces deux alarmes. 3.6 Pre/Post Condition Il y a 3 grandes familles de corrélation par pre/post condition: celle développée par Ning, MIRADOR (et le langage LAMBDA) et le langage JIGSAW. Dans cette approche, les auteurs utilisent les termes de prérequis comme une vulnérabilité d un service et de conséquence comme une intrusion dans la machine. Par exemple, un scan de port est corrélé avec un scénario et va correspondre à la découverte par un attaquant d une vulnérabilité. Les auteurs expriment de plus le fait qu il peut ne pas y avoir de prérequis pour certaines alarmes: celle qui sont au début (temporellement) d attaques. Les trois possibilités générales de transition entre les alarmes sont: Consequences: les conséquences de la réussite d une attaque. Prepare-For: une alarme prépare pour une prochaine si elle contribue au prerequis de celle-ci. Elle doit également avoir lieu avant dans le temps. Prérequis: les conditions nécessaire pour qu une alarme puisse avoir lieu. Cette technique utilise des graphes orientés et acycliques où un noeud représente une alarme et les transitions correspondent à une des possibilités de transitions entre 14

16 deux alarmes, le problème étant que leur taille croit exponentiellement avec la complexité de l attaque. Tout d abord, les auteurs expliquent qu il faut construire des hyper alarmes à partir des alarmes arrivant, une hyper alarme étant constituée de trois attributs: l alarme en elle-même, les prerequis et les conséquences. En général, une hyper alarme représente une alarme mais ils expriment également la possibilité de généraliser un ensemble d alarme en une hyper alarme (agrégation). L intérêt d inclure des fenêtres de temps est qu elles permettent de faire des calculs sur des ensembles plus petits donc plus rapide mais l inconvénient est qu une attaque peut passer outre la corrélation en s étallant sur le temps. Cette vulnérabilité peut être contrée en utilisant des fenêtres de temps plus grand. Mais comme exprimé par les auteurs, elle implique une augmentation exponentielle du temps de corrélation pour chaque nouvelle alarme. Le problème de toutes ces techniques de pre/post condition est qu elles se basent sur un modeling précis des pre et post conditions ce qui impose d avoir une très bonne qualité de représentation pour avoir une corrélation efficace. Les différences entre les divers langages et approches de la détections par pre/post conditions sont relativement faibles. JIGSAW a clairement le plus de défaut (et est également le plus ancien) car peu adapté aux nouvelles réalités du monde des IDS et ne sera pas présenté ici (il a été introduit par ces auteurs dans l article [TL00]). LAMBDA et l approche de Ning sont relativement similaires et de qualité proche. La différence récurente est la phase d agrégation qui est libre pour l approche de Ning et qui se passe forcément avant la corrélation avec LAMBDA LAMBDA: A Langage to Model A Database for Detection of Attacks Ce langage a été développé au cours du projet européen MIRADOR [CM02, MD03]. [CO00] permet de décrire une attaque avec le point de vue d un attaquant et va permettre une corrélation en utilisant des scénarios explicites (ie les auteurs définissent en dur les arguments et les alarmes de la corrélation) mais également de la corrélation implicites où LAMBDA apprend à partir d un groupe d alarmes des régles de corrélation (cette méthode est basé sur l apprentissage et peut utiliser des techniques tel que la classification, le data mining, les réseaux de neurones, etc). Les auteurs proposent d utiliser des graphes où les noeuds représentent des alarmes et les transitions se comportent en pre/post condition. Les transitions sont exprimés sous la forme A = action, actor, date avec action qui correspond au type d action de l attaque, actor (le ou les utilisateurs prenant part à l attaque) et date (l intervalle de temps de l action). La définition des scénarios d attaque se fait en utilisant la grammaire définie (cf publication [CO00]). Par exemple, knows(a,use_service(s,telnetd)) permet d indiquer que A sait que S a un service actif telnetd. Tout d abord, les auteurs proposent de réduire le nombre d alarmes en utilisant l agrégation qui permet de regrouper toutes les variations d une alarme dans une seule hyper-alarme. La corrélation était rarement parfaite (direct correlation ie A B) soit post(a) = pre(b)), ils proposent de faire place à un peu d abstration (ie A AND X B soit post(a) + X = pre(b)). 15

17 3.6.2 Ning Approach L équipe de Ning [NX04, NCR02, NCR01] propose de reconstruire un scénario d attaque en se basant sur un graphe représentant les liaisons entre les différentes alarmes générées. Cette méthode se base sur l utilisation de contraintes sur les attributs de l attaque et sur l ordre temporel des diverses étapes de celle-ci. P. Ning apporte de nombreuses applications de traitement de graphe appliquées aux scénarios d attaques, mais aussi des méthodes d apprentissage de ces derniers et d optimisation de la rapidité du calcul de corrélation. Les traitements de graphe spécialement développés pour la corrélation sont [NCR05] réduction ajustable de graphe (adjustable graph reduction), reconnaissance par focus et découpage de graphe qui permettent de réduire la complexité d un graphe en abstrayant certaines valeurs et de focaliser le graphe sur un sous ensemble. Ning définit trois niveaux de classe de corrélation [NXHA04]: 1. Similitude entre les différents attributs d une alarme (par exemple, même source et destination). 2. Scénario d attaque défini par des humains ou appris depuis d autres scénarios. 3. Basé sur les pre/post conditions d une attaque individuel (une alarme IDS), les auteurs proposent de corréler celle-ci avec d autres alarmes passées qui vont présenter les prérequis de celle-ci et attendre en regardant les alarmes futures, pour obtenir la post condition. Le but est de combiner ces méthodes afin de détecter le maximum de sessions mais l équipe de Ning se focalise sur les recherches dans le domaine des pre/post conditions. En effet, les 2 premières classes de corrélation restreignent leur détection à des attaques déjà connues alors que grâce à la généralisation, la 3ème méthode est moins limitée à ce niveau. Les Hyper-Alarmes Pour P. Ning, une hyper alarme est un triplet qui regroupe: 1. le fait (l alarme) qui est une serie d attributs associés à une ou plusieurs valeurs. 2. le prérequis et la conséquence qui sont des combinaisons logiques de prédicats. Au lieu, de voir si une hyper alarme correspond au prérequis d une autre, il vérifie qu une hyper alarme contribue ou pas au prérequis d une suivante. En pratique, il propose le découpage des prédicats d une hyper alarme et voir si des hyper alarmes précédentes vérifient certains de ces prédicats puis corréler ces hyper alarmes entre elles, e.g. UDPVulnerableToBOF(VictimIP,VictimPort) représente la découverte par un attaquant que la machine qui a pour IP VictimIP fait tourner un service sur le port UDP VictimPort et que ce service est vulnérable a une attaque par buffer overflow. Selon cette méthode, l agrégation n est pas obligatoire mais permet de limiter le nombre d alarmes et de créer des alarmes aggrégées enrichies. Similarité de scénarios d attaque L approche introduite par P. Ning va utiliser une méthode permettant de mesurer la similarité entre 2 stratégies d attaques, permettant d apporter de la tolérance aux fautes mais également de détecter des similarités de sous attaques entre deux attaques. Pour 16

18 répondre à cette dernière exigence, il propose d utiliser la généralisation à partir d un graphe d attaque pour en détecter les variances. L isomorphisme des graphes (et/ou sous graphes) tolérant aux erreurs permet de détecter la signature d une attaque même si c est une variante. Tout d abord, sa méthode est d aggréger les alarmes qui correspondent à la même étape de l attaque pour éviter les répetitions puis extraire les contraintes entre les différentes étapes de l attaque et les représenter dans un graphe d attaque. Généralisation de graphes de scénarios Pour pouvoir construire des graphes d attaques performants, P. Ning inclut des fonctions de mapping de généralisation qui va permettre de généraliser les attributs d une hyper alarme. Bien entendu, cette fonction ne peut pas être faite à la main, c est pourquoi, il introduit le besoin de techniques de clustering pour identifier les types d hyper alarmes, puis les généraliser en un seul (bottom-up hierarchical clustering), sa méthode de clustering se base sur les similarités entre les hyper-alarmes puis va les dériver pour construire les conditions pre et post. L utilisation de la méthode Jaccard Similarity Coefficient 5 lui permet de calculer la similitudes entre 2 ensembles de predicats S1 et S2 [NX03]: Son but est de pouvoir en déduire la similarité entre deux scénarios d attaque mais également de savoir si un scénario fait partie d un autre. Afin de permettre de détecter le bruit et la distortion entre 2 graphes, P. Ning propose d utiliser l isomorphisme. Il introduit deux techniques d approche: le graph edit distance et le graphe commun maximal (maximal common graph). La technique qu il a retenu est graph edit distance. L auteur introduit la liaison May entre 2 alarmes pour pouvoir passer outre la non détection de certaines alarms. Cela lui permet de pouvoir détecter les variations d une attaque sans avoir à posséder les signatures pour chaque variation. La méthode précédente était orienté à corréler des alarmes homogénes, celle-ci [ZNIR04] permet une corrélation d alarmes hétérogénes par les auteurs, elle ne se limite pas à corréler des alarmes IDS, elle les corréle également avec des rapports de vulnérabilité pour renforcer la qualité de l analyse. Cette technique et l utilisation de graphes d attaque permet de ne pas se limiter à détecter des attaques qui ont eu lieu, mais de les détecter quand elles arrivent et donc prendre les décisions correspondantes. P. Ning introduit également l utilisation de trigger event [XN04] qui sont des évènements de bas niveaux qui vont déclencher des alarmes. En regroupant les alarmes qui ont les même triggering event, un ensemble d alarme peut être partitionné en plusieurs clusters dont chacun correspond à une attaque. Pour identifier les triggering events, il introduit le besoin de chercher pour une alarme l ensemble de type d événement qui peuvent déclencher ce type d alarme et les valeurs d attributs correspondant. Dans cette approche, la connaissance des domaines des valeurs des attributs est essentielle. L auteur exprime également le faite qu il ne faille pas se limiter à l égalité des valeurs des attributs, en effet, une alarme peut implicitement en exprimer une autre (par exemple: si il y a suppression du fichier doc/files.txt ou du répertoire doc/, les 2 alarmes vont supprimer le fichier files.txt, il faut donc prendre en compte que la première alarme va être contenue dans la seconde). 5 Le coefficient de similarité Jaccard est une méthode statique utilisé pour comparer les similitudes et la diversité d un ensemble. 17

19 3.7 Model Checker Les auteurs [JSW02, SHJ + 02] amènent une autre approche pour la corrélation via l utilisation de model checker 6 et l implémentent avec ORCHIDS 7. Leur approche est de simplifier la construction et la comparaison de scénarios d attaque entre eux (et également avec des alarmes) en utilisant des arbres de stockage type BDD 8 et une logique temporelle comme LTL ou CTL. Les auteurs veulent prouver l utilité des model checkers pour construire automatiquement des graphes d attaques. En effet, d après leurs recherches, trouver un scénario d attaque possible dans un graphe équivaut au problème du minimum hitting set. Ils introduisent également la possibilité d utiliser des chaines de Markov pour calculer la chance de réussite d une attaque. Un model checker symbolique est introduit utilisant une méthode en marche arrière (backward) en partant de l état d arrivé (goal state). L intérêt de la méthode backward est qu elle ne va pas chercher à reconstruire un graphe pour une attaque qui n a pas été jusqu au point voulu (goal state). L un des avantages du model checker est qu il va être capable à partir d un état final (goal state) de reconstruire à partir des différents alarmes tous les chemins qui peuvent mener à une telle attaque. Leur but est donc de construire un graphe qui va être composé de tous les chemins qui ménent à la rupture de la régle de sécurité. Ce graphe doit être succin et exhaustif. Par la suite, la méthode prévoit de reconstruire le graphe inverse (en utilisant la méthode de procédure transversal - traversal procedure), c està-dire de le reconstruire en partant des noeuds initiaux pour trouver tous les chemins accessibles qui ménent vers la rupture de régle de sécurité. Leur graphe d attaque correspond à l union de tous ces chemins depuis le noeud initial jusqu à celui de rupture de politique. Ils motivent leur utilisation de model checker par la possibilité à réutiliser les recherches effectuées dans le domaine du model checking. 3.8 Queue Graph Le but des auteurs [TA05, WLJ05] de cette approche est de pouvoir supporter les floods 9 d alarmes provoqués par un attaquant souhaitant cacher son intrusion. L utilisation d un token bucket filter (ou TBF) 10 va permettre de contrôler la quantité de flux de données (aussi utilisé en QoS 11 ). Ce token bucket filter a 2 paramètres: la taille du panier et la rapidité de diffusion. Il ne va donc pas y avoir de problèmes de flood puisque les alarmes sont délivrées à la vitesse voulue. Les nouvelles alarmes arrivant sont stockées, avant d être livrées, dans un buffer appellé panier (bucket). Quand ce dernier est 6 Le Model Checking désigne une famille de techniques de vérification automatique des systèmes dynamiques (souvent d origine informatique où électronique). Il s agit de vérifier algorithmiquement si un modèle donné, le système lui-même ou une abstraction du système, satisfait une spécification, souvent formulée en termes de logique temporelle. 7 IDS se basant sur un model checker [OGL05]. 8 Un diagramme de décision binaire (BDD, binary decision diagram en anglais), comme une forme normale niée ou un graphe orienté acyclique propositionnel, est une structure de données utilisée pour représenter des fonctions booléennes. 9 Flood: Envoi massif de données dans le but d empécher un système de fonctionner correctement. 10 L implémentation TBF consiste en un tampon, ou seau, constamment rempli par des éléments virtuels d informations appelés jetons, avec un débit spécifique, dit débit de jeton. Le paramètre le plus important du tampon est sa taille, soit le nombre de jetons qu il peut stocker. Dans l implémentation réelle, les jetons correspondent à des octets et non à des paquets. 11 QoS est un sigle qui signifie Quality of Service en anglais, que l on traduit par qualité de service en français. La Qualité de Service (QoS) est la capacité à véhiculer dans de bonnes conditions un type de trafic donné, en termes de disponibilité, débit, délais de transit, taux de perte de paquets... 18

20 plein, il déborde et les alarmes sont perdues. Pour éviter ce genre d incident, les auteurs introduisent la possibilité d augmenter temporairement la vitesse de traitement en utilisant plus de ressources disponibles (ie un bust dans le domaine de la QoS). De par le problème de risque de perte d alarme dû à un panier plein, les auteurs souhaiteraient pouvoir vérifier que ces alarmes perdues ne sont pas d une importance crutiale. Leur graphe d attaque est représenté via un graphe dirigé et acyclique. Il est composé d alarmes NIDS et de rapports Nessus. Grâce à l utilisation des queue graphs, au lieu de chercher à travers toutes les alarmes déjà reçues celles qui peuvent préparer pour une nouvelle alarme, les auteurs expliquent le besoin de chercher en incluant uniquement la dernière alarme de chaque type. Cela implique donc implicitement une corrélation avec un ordre temporel. En intégrant des fonctions de généralisation des alarmes et des graphes d attaque, les auteurs tentent de réduire la possibilité de non détection et de perte de certaines alarmes mais également de tenter de prédire la suite de l attaque. D après les auteurs, l intérêt de cette technique par rapport aux graphes d attaques classiques est qu elle ne va pas augmenter en complexité avec le temps. Leur approche introduit également comme les graphes d attaque classiques (voir section 3.6) la nested loop approach avec ou sans fenêtres de temps. Grâce à la méthode décrite par les auteurs, la corrélation est capable de détecter les attaques lentes grâce à la conservation de la dernière alarme pour chaque type jusqu à temps qu elle soit corrélée. Comme d autres méthodes, l introduction du processus d hypothétisation de la perte de certaines alarmes IDS va permettre de pouvoir continuer la corrélation même si certaines alarmes sont ratées par un IDS. Du point de vue des graphes, cela revient à combler des parties intermédiaires entre le début et la fin d un graphe d attaque. 3.9 Corrélation IDS/Vulnerability Analysis L approche proposée par les auteurs [Gul07] est de corréler les alarmes IDS avec les informations données par un scan de vulnérabilité. D après eux, cette méthode est très efficace pour éliminer les faux positifs qui sont produits par les NIDS. Leur but est d augmenter le niveau de confiance envers certaines alarmes IDS. Ils introduisent également la possibilité d utiliser des sources d informations autres comme la topologie du réseau. Le but des auteurs est de pouvoir se focaliser sur l étude des attaques impliquant des failles réelles dans le réseau. Grâce au scan de vulnérabilité, il est possible de savoir où sont les risques et créer les régles de sécurité et de l IDS correspondantes, mais les auteurs évoquent également le fait qu il est intéressant de monitorer les endroits où il n y a pas de vulnérabilité. Leur principal problème est de corréler les informations venant du scan de vulnérabilité avec des informations valides venant des IDS et pas avec des faux positifs qui pourrait mener à augmenter la priorité d une attaque qui n a pas lieu. Au niveau de la mise en place, leur problème est de trouver un formalisme pour pouvoir comparer les informations provenant des scans de vulnérabilité tout comme les informations venant des IDS. Ils distinguent trois types de corrélation entre IDS et VA: Persistent VA/IDS Correlation: le but est de maintenir une base de données des vulnérabilités du SI et dès qu une alarme est corrélée avec cette base d augmenter son niveau d importance. Near-Time VA/IDS Correlation: Sensiblement la même chose que Persistent sauf que les recherches de vulnérabilités sont effectué en fonction des alarmes IDS 19

21 reçues. Real-Time VA/IDS Correlation: Cette méthode est la méthode parfaite pour les VA/IDS Correlation, elle va permettre aux IDS de connaitre en temps réel les vulnérabilités touchant le SI de manière magique, i.e. cette méthode est impossible à mettre en place car elle sous entend d être capable de prévoir ce que le processus de corrélation va avoir besoin comme informations sur les vulnérabilités avant même qu il sache qu il en a besoin. Le principal problème de cette méthode est la perte de beaucoup d informations intéressantes comme les étapes de préparation du scénario d attaque qui ne vont pas être détectées. Par contre, elle permet d augmenter la confiance envers certaines alarmes mais ne permet pas la reconstitution de scénario d attaque complet Data Mining Les auteurs [MCZH00, LSC04] amènent une approche de la corrélation via Data Mining où le but est d apprendre à partir des alarmes antérieures les signatures des scénarios d attaque et les contre-mesures à mettre en place. [JD02] proposent deux méthodes de Data Mining pour la corrélation: namely episode rules et conceptual clustering technique. Leur idée est que les techniques de Data Mining seront particulièrement efficace pour réduire les problèmes de mutation des scénarios. Comme la plupart des méthodes de corrélation, cette technique perd des informations car elle rassemble plusieurs alarmes en une seule. La recherche est faite sous 2 axes: tout d abord une recherche d alarme se déroulant de façon séquentielle (ou serielle) (une suite récurrente d alarmes qui peut être potentiellement la signature d une attaque) et une recherche d alarme parallèle, e.g., un scan réseau ou un DDOS. D après les auteurs, seul 1% des attaques est détectée en utilisant l apprentissage sur les attaques précédentes. Pour améliorer la détection, ils ajoutent une couche de généralisation qui va, par exemple généraliser une IP en un réseau, mais ils expriment également le problème qu il ne faut pas tomber dans trop de généralisation qui finirait par provoquer trop de corrélation positive (et potentiellement faux positive). Finalement, ils proposent d utiliser les informations apprises de la généralisation pour créer des procédures d agrégation plus précises mais sans donner de résultats plus précis sur l amélioration du nombre d attaques détectées Stockage des évènements IDS: Database Versus Memory Comme P. Ning l a exprimé, l utilisation de base de données dans le processus de corrélation le ralentit énormément. En effet, les BDD ne sont pas faite pour une étude intéractive comme la corrélation le demande. Le but des auteurs [NX02] est d optimiser les recherches dans la base de données et de faire les études intéractives en stockant en mémoire certaines données utilisées par le processus de corrélation. D après les auteurs, dans un processus de corrélation classique avec 65,000 alarmes, il faut 4 minutes pour pouvoir les traiter en utilisant une base de données, en utilisant des données en mémoire, il est possible de réduire ce temps à moins d une seconde. Il existe plusieurs méthodes de stockage en mémoire [NR02] 20

22 Tableau de recherche binaire (Array Binary Search): cette méthode va stocker les données dans un tableau et va effectuer les recherches en utilisant une technique de type recherche binaire (binary search). Elle est efficace sur les données statiques mais peu sur les données dynamiques. En effet, le tableau doit avoir assez de place pour pouvoir ajouter des nouvelles données sinon il faut réallouer un emplacement mémoire plus grand puis recopier entièrement le tableau à ce nouvel endroit. Mais également, si il y a assez de place dans le tableau, l insertion implique une complexité de O(N) en nombre de déplacement de données. AVL Tree: se base sur des arbres de recherche binaires équilibrés (balanced). Avec ce système, chaque noeud contient des données, des informations de contrôle, un pointeur gauche qui va pointer vers le sous arbre qui contient les éléments plus petit et le droit qui va pointer sur les éléments plus grand. La recherche est très rapide dans ce système mais l insertion dans l arbre demande l ajout d une feuille qui peut impliquer de gros changements dans l arbre comme un rebalancement de ce dernier. B-Tree: est également un arbre de recherche équilibré mais contrairement à ceux en AVL, il peut avoir plusieurs données et pointeur pour chaque noeud. Les données sont ordonnés à l intérieur de chaque noeud et chaque pointeur pointe sur un sous arbre qui contient les données qui sont compries dans le panel identifié par les 2 données adjacentes. Ses intérêts sont: 1. moins d accès au noeud par rapport à AVL. 2. l insertion est plus rapide et ne remet en cause qu un seul noeud. T-Tree: ce sont des arbres binaires avec un ensemble d éléments dans chaque noeud. C est une évolution des AVL et B Tree. Ils combinent la bonne capacité de recherche des AVL avec la rapidité de stockage des mise à jour des B-Tree. La recherche dans les T-Tree correspond à la recherche dans un arbre binaire suivi d une recherche sur un noeud. L insertion implique des mouvements de données uniquement dans un noeud mais également des rotations dans la structure de l arbre pour le rebalancer. Chained Bucket Hashing: cette méthode utilise une table statique de hash et une chaine de panier pour chaque hash. Elle est très efficace dans un environements statiques où il est possible de prévoir à l avance le nombre d éléments qui vont être présent. Mais quand ce nombre n est pas connu, les performances deviennent rapidement mauvaises, en effet, si la table de hash est trop petite alors trop de panier risque d être chainer pour un seul et même hash et si la table est trop grande alors on risque de perdre de la place à cause d entrée vide. Linear Hashing: va également utiliser une table de hash mais dynamique ici qui va couper les hash des paniers dans un ordre linéaire prédéfini. A chaque fois qu un panier déborde, l algorithme va le couper en 2 et la taille de la table de hash va augmenter. Les paniers sont ordonné séquentiellement ce qui permet à une adresse d un panier d être calculer à partir d une adresse de base. Pour utiliser efficacement ces stockages en mémoire, un algorithme appellé Nested Loop Correlation a été créé par l équipe de P. Ning qui permet d utiliser des structures Linear Hashing et T-Tree pour rechercher les relations entre les alarmes (relation de type prepare-for ). 21

23 Contrairement aux bases de données, le stockage en mémoire de l ensemble des alarmes est impossible, la RAM arrivant rapidement à saturation. Pour minimiser le problème, les auteurs proposent d utiliser le concept de fenêtre de temps pour conserver en mémoire seulement certaines alarmes. Le nombre t d alarme disponible en mémoire est calculé par rapport à la taille de la mémoire disponible. En pratique, quand une alarme est ajoutée, la plus ancienne est supprimée. Les structures de données, présentées ci-dessus, ne sont pas optimisées pour la suppression car elles demandent un parcours de l arbre en entier avant de pouvoir trouver et supprimer une alerte. Il faut donc ajouter une deuxième structure de données pour la localisation des alarmes dans la structure de donnée en utilisant une file. Pour minimiser le problème de l allocution de mémoire, les auteurs ont proposé que chaque tableau soit initialisé à une taille fixe, si il n y a plus assez de place dans celui-ci, un nouveau avec une taille double soit créé puis les données précédentes recopiés dedans Correlation et Réseau Neuronal Cette méthode introduit un autoassociateur [SJD05] qui est un Feed-Forward 12 sur les réseaux neuronaux qui prend le même nombre d entrées que de sorties. D après les auteurs, malgré leur simplicité, ils ont prouvé leur efficacité dans le milieu civil et militaire. Un autoassociateur peut corréler des réseaux similaires (scénarios d attaque) et il est extrêmement rapide une fois entrainé. De plus, contrairement aux autres méthodes de corrélation, celle-ci ne perd aucune d informations au fur et à mesure de la corrélation. En pratique, le réseau neuronal est entrainé en utilisant l algorithme de error-backpropagation avec pour objectif de reconstruire l espace d entrée à la sortie Framework de corrélation Ces travaux [VVKK04, Qin05] ont favorisé l utilisation de méta-alarmes. Ce sont des alarmes enrichies par le processus de corrélation. Le processus de corrélation proposé peut être découpé en plusieurs étapes: 1. la normalisation qui permet de comparer facilement les alarmes entre elles, peu importe le senseur qui l a généré. 2. le preprocessing qui vérifie que tous les arguments sont initialisés avec des valeurs cohérentes. 3. la fusion qui regroupe la même alarme venant de plusieurs sondes en une seule. 4. la verification qui, à partir d une alarme simple, définit son niveau de danger (le risque de réussite). 5. le thread reconstruction qui combine une serie d alarme référant à un attaquant lançant plusieurs attaques sur un seul et même host. 6. l attack session reconstruction: association des alarmes NIDS et HIDS pour une session d attaque. 12 Feed-Forward est un terme decrivant une sorte de système qui réagit au changement de son environnement, normalement pour obtenir certains états dans ce système. Un système qui utilise un feed-foward répond aux turbulances d une manière prédéfinie. 22

24 7. le focus recognition: concentration sur une partie des résultats. 8. la multi step correlation: reconstruction du scénario global. 9. l impact analysis: calcul de l impact sur le système, des contre-mesures, etc. [VVKK04, Qin05] précisent que des étapes supplémentaires peuvent être ajoutées comme la corrélation avec un dépot d informations (qui peut contenir la typologie réseau, divers informations de monitoring, le résultat de scan de vulnérabilité, etc), un backend permettant de trouver l identité de l attaque dans des bases de données tel que CVE, Bugtraq et arachnids pour aider à la construction de contre mesures et de rapport d incident [Cal02, Buv03] mais également des interfaces [CBB + 04] permettant à l humain de régler des valeurs qu il souhaite (comme le niveau d agrégation ou de réduction des graphes). Les auteurs introduisent également deux algorithmes permettant de formaliser l étape de multistep correlation 13 : reconnaissance-intrusion-escalade de privilége (recon-breakin-escalate): 1. scan network/host à la recherche de vulnérabilité 2. utilisation de la vulnérabilité pour pénétrer la cible. 3. utilisation d une escalade de privilége et passage en root sur la cible. island-hopping: permet de détecter une attaque où la destination devient la source de la seconde attaque (attaque migrante) Corrélation décentralisée Dans l architecture introduite par les auteurs [KTK05], la corrélation n a pas lieu en un point central mais à de multiples endroits contrairement à la plupart des architectures de corrélation déjà présentées ici qui sont distribuées mais où les données et les calculs sont centralisées ce qui pose un problème pour le passage à l échelle et la tolérance aux pannes. Le passage à une architecture décentralisée ne régle pas tout, il y a toujours le cas où une machine n a pas assez de puissance pour effectuer sa part du travail de corrélation. Le cas présenté [KTK05] utilise une corrélation par signature. Les auteurs expliquent qu un tel système oblige à avoir un langage pour déclarer les signatures mais également un mode de transfert qui sera basé sur un algoritme réseau de type P2P pour partager les alertes et les signatures entre les machines. Grâce à cette méthode, il est possible de détecter un scan de port sur l ensemble d un réseau en faisant transiter l information entre les HIDS. Ils expliquent également que leur méthode permet de mettre en place des contre mesures adaptées pour chaque étape d un scénario d attaque et pas uniquement quand celui-ci est totalement détecté. Les systèmes décentralisés ne l étant jamais totalement, il faut un (ou plusieurs) centre(s) de management qui vont stocker la configuration de chaque IDS. Dans cette approche, les alarmes sont traitées en local (sur chaque senseur IDS) en utilisant du prefiltrage avant d envoyer l information au système de stockage. Ensuite, leur but est de créer un modèle réseau de type publisher/subscriber pour disséminer 13 MultiStep Correlation: étape de la corrélation permettant de détecter des attaques composées de plusieurs sous attaques e.g. un scénario composé d une attaque par brute force et une session locale illégale. 23

25 l information sur les machines. La communication se fait sur un mécanisme fonctionnant au dessus d une connexion SSL entre senseurs permettant le transfert d alarmes et de descriptions de signature. Un canal de management (également protégé) est utilisé pour la reconfiguration et la construction de block. La grammaire utilisée pour décrire les attaques doit pouvoir écrire des relations entre différents évènements sur différents hosts en utilisant ou des expressions régulières ou des grammaires d arbres. Un des problèmes majeurs de la corrélation distribuée est qu il faut pouvoir définir un temps universel afin de pouvoir classer correctement les évènements temporellement les uns par rapport aux autres. Le modèle P2P amène également le probléme de l utilisation réseau, en effet, si les signatures deviennent trop compliquées, le nombre d alarmes échangées va rapidement augmenter. Le pire des cas pour ce principe de corrélation décentralisée est de se retrouver dans le cas où chaque événement est envoyé sur chaque machine. La distribution du système permet de détecter des scénarios d attaques se passant sur l ensemble du réseau. Au niveau du système de corrélation, les auteurs [KTK05] proposent de mettre en place des domaines afin d alléger le processus puis de rassembler les informations provenant des différents domaines et déjà prétraiter. Suivant les différentes études, que la procédure de preprocessing peut être faite au niveau local de chaque senseur mais ne donne souvent rien par manque d informations en local et le besoin d informations provenant de l extérieur. Les auteurs expriment également le besoin de prendre en compte qu un système décentralisé doit pouvoir gérer des signatures ou autres représentations des scénarios en utilisant une grammaire supportant ce processus décentralisé. La décentralisation permet de se passer du modéle manager où un point central est le point de rendez-vous en utilisant un modéle publisher/subscriber mais elle ne régle pas totalement le problème d un ou plusieurs points critiques dans la structure du réseau de corrélation. Leur but étant de permettre que chaque machine fasse une part de la corrélation afin de répartir la charge. Mais le problème est que la corrélation peut être corrompue si une des machines effectuant celle-ci est corrompue (on passe donc d un point critique à plusieurs). Il y a 2 types d architecture décentralisée qui ont déjà été étudié: Cooperating Security Manager (CSM) et Security Policy Adaptation Reinforced Trough Agents (SPARTA). [KTK05] énumèrent plusieurs méthodes de décentralisation: seules les machines impliquées dans le scénario vont participer à la corrélation. utilisation de code mobile qui vont parcourir le réseau à la recherche d alarme utile pour le processus de corrélation qu ils sont entrain d effectuer. utilisation d architecture type peer to peer Discussion Plusieurs méthodes de corrélation d alarmes IDS ont déjà été avancées. Tout d abord, la méthode probabiliste qui permet de détecter facilement des variantes d un scénario. Mais pour permettre cela, il faut disposer de scénario déjà construits et faire définir à l utilisateur le degré de similitude souhaité entre 2 variables. De plus, cette méthode requiert de comparer les nouvelles attaques avec d anciens scénarios, il faut donc une base d attaque validée, il n est pas possible de détecter les nouvelles attaques. De plus, cet algorithme a été presque uniquement utilisé pour les NIDS (particulièrement 24

26 EMERALD ebayes 14 ) est jamais généralisé à l ensemble des sondes. Mais l algorithme est simple et permet des généralisations intéressantes malgré une perte d informations importantes, en effet, les données qui ne sont pas en commun entre deux alarmes comparées sont perdues. La méthode Pre/Post Condition est celle qui a pour le moment été la plus étudiée, de nombreux articles ont été publiés sur ce sujet qui ont permis d introduire une méthode se basant sur des scénarios très détaillés et précis via l utilisation de graphes orientés et acycliques. Le problème principal de cette approche est le modeling des scénarios qui va directement influencer la qualité de la détection. Cette méthode a été principalement reprise dans les travaux suivant: JIGSAW, qui était un intéressant point de départ. LAMBDA, qui amène un point de vue intéressant en décrivant des scénarios du point de vue de l attaquant. Malheuresement, la grammaire est très spécialisée et difficile à implémenter pour un apprentissage, elle est plus destiné à la description par l utilisateur d attaques de haut niveau. De plus, elle a été implémentée avec en vue les NIDS et n est pas adaptée à d autres sources. Enfin, pour augmenter l efficacité, il faut utiliser une couche d abstraction qui fait perdre des informations. l approche de Ning, qui se base sur l utilisation de graphe permettant de réutiliser les nombreuses recherches effectuées dans ce domaine. Ces graphes peuvent être facilement généralisés pour détecter des variations de scénario d intrusion. Mais cette technique se limite à la détection d attaque déjà vu ou de leurs variantes et ne sait pas détecter de nouveaux scénarios. De plus pour chaque étape d un scénario, on doit connaitre précisement les pre requis et les conséquences pour pouvoir les lier dans le graphe. Comme les autres approches, la généralisation est obligatoire pour augmenter la détection mais elle introduit une perte d information. La capacité de ces graphes a pouvoir s étendre sur plusieurs machines permet de pouvoir détecter des attaques distribués. De plus, grâce à une grammaire extensible, on peut ajouter d autres sources d informations bien que pour le moment, cette méthode ait uniquement été validée en utilisant comme source IDS des NIDS. Finalement, les scénarios sont de très haut niveau: précis, difficile à apprendre et très spécialisés. D autres approches utilisent les model checker en se basant sur la reconstruction de graphe d attaque à partir des alarmes connues. Par conséquent, il est uniquement possible de détecter un scénario qui a déjà reconstruit. Cette méthode n est pas réellement innovante mais apporte l approche de résolution de graphe par modelchecker; de plus, les études ont uniquement menées sur des alarmes NIDS. Les queues graphs ont le même défaut que les model checker, ce n est pas réellement une nouvelle approche, mais plutôt l adaptation d une étape de la corrélation en utilisant les recherches effectuées dans un autre domaine. Cette méthode permet à la corrélation d être plus efficace au niveau du flood d alarmes en utilisant des principes provenant de la QOS permettant de réguler le flux d alarmes via l utilisation d un tampon mais peut aussi introduire de la perte d information en cas du débordement de ce dernier. L utilisation de DAG 15 est un plus mais la spécialisation de cette méthode aux alertes provenant de Snort et Nessus uniquement, limite considérablement les intérêts 14 C est un NIDS. Il est capable de faire de la reconstruction de session. 15 Directed Acyclic Graph: Graphe orienté acyclique 25

27 de celle ci. Les réseaux neuronaux sont, quant à eux, une autre méthode de détection qui se base sur un apprentissage automatique. La conception même des réseaux neuronaux posent le problème du contrôle de l apprentissage dû au fonctionnement en boite noire. De plus, comme dans tout réseau neuronal, le risque de sur-apprentissage menant à une détection trop importante (i.e. un grand nombre de faux-postifs) est très présent. Le data-mining peut permettre l apprentissage automatique des scénarios d attaques mais les approches étudiées se basent sur l utilisation des méthodes de data mining pour trouver des similitudes entre d anciens scénarios détectés et de nouveaux en faisant abstraction des mutations. Ces méthodes causent une perte importante de données mais nécessitent une généralisation pour augmenter leur efficacité. Même dans le meilleur des cas, ces méthodes ne détectent que 1% des attaques en se basant sur les attaques antérieures. On peut donc s interroger sur leur apport. Afin d enrichir les scénarios et ne pas se limiter aux sources IDS, des méthodes ont été développées pour ajouter d autres sources et particulièrement les rapports de vulnérabilités (VA). Mais ces VA peuvent être corrélés efficacement uniquement avec les alarmes de type NIDS et elle ne fait qu augmenter la confiance en une alarme. De plus elle n est utilisable qu à un nombre très faible d étapes des attaques. En plus de l importance, d une bonne méthode de corrélation, il faut également faire reposer le processus sur des techniques optimales afin de maximiser la qualité de détection mais aussi la rapidité de celle-ci. C est pourquoi le stockage des alarmes est un point critique. Il y a deux grandes méthodes de stockage de ces alarmes, ou en mémoire où elles sont rapidement accessibles mais ou la pérennité des informations n est pas garantie, ou en base de données où la rapidité est réduite mais la pérennité est garantie et l optimisation de la recherche permet de meilleur résultat. Le framework présenté permet l intéropérabilité de plusieurs étapes de la corrélation permettant de maximiser celle-ci mais également la capacité d ajouter de nouvelles étapes mais est très spécialisé, ne disposant pas de grammaire ou d autres représentation efficaces et les scénarios détectés sont relativement limités. Pour finir, des architectures décentralisées ont été proposées qui permettre de répartir sur plusieurs machines la corrélation. Ce qui facilite un passage à l échelle mais provoque une demande accrue de sécurité des espaces de corrélation afin d assurer que ces derniers restent pérénnes, e.g. dans le cas, où une de ces machine est capturée. Mais la décentralisation amène aussi le besoin d avoir une représentation des scénarios d attaque décentralisée permettant de supporter le distribué. De plus, les techniques présentées disposent toujours d un point de centralisation critique et le stockage et le partage des alarmes est un problème flagrant. Les nombreuses communications réseaux entre les machines et les senseurs doivent être sécurisé pour éviter d introduire un nouveau vecteur d intrusion ce qui améne l ajout de structures d authentification lourdes. Finalement, il a été observé que le pire des cas pour le transfert des alarmes entre les machines est souvent atteint i.e. le cas où toutes les alarmes sont transfèrées sur toutes les machines dans le cas où le stockage est réparti entre les machines en fonction les alarmes dont elles ont besoin. Nous allons dans le chapitre suivant introduire clairement l ensemble des motivations de notre étude. 26

28 Chapter 4 Motivations Dans les grands réseaux, les machines distribuées, les clusters et tous les rassemblement d un nombre important de machines, la surveillance du réseau et des machines devient de plus en plus compliquée, lourde et couteuse. Malgré les avancées dans le domaine de la détection d intrusion et des sources d informations relatives à la surveillance du système d information, les possibilités d utilisation réelles sont restées très limités à cause du nombre trop important d alarmes générés par ces dispositifs mais aussi le nombre de faux positifs et la faible qualité des informations délivrées. L idée est d utiliser au mieux les différents outils existant en supposant que chacun d entre eux, parmi les alarmes ou rapports qu il fournit, fournit une partie exacte de la réalité. La corrélation sera un moyen technique de faire coopérer toutes ces informations hétérogénes, tantôt concordante, tantôt contradictoire, tantôt apparament indépendate (non corréleé). La difficulté du processus de corrélation est de parvenir à générer de nouvelles informations justes, i.e. des vérités plus complètes que celles fournies partiellement par les données sources de la corrélation. Concrétement, ce que nous chercons à faire est non seulement de détecter des attaques isolées mais aussi et surtout des sessions complètes d attaques i.e., depuis une intrusion jusqu à l exploitation grave d une faille sur le système pénétré. La corrélation va permettre tout d abord de reconstruire un scénario complet d attaque à partir de plusieurs alarmes pouvant provenir de plusieurs sources mais également avec un nombre important d alarmes d augmenter la qualité du scénario. La corrélation va permettre également de réduire l importance des faux positifs, de regrouper pour une meilleure détection des sources d informations diverses allant des rapports de vulnérabilités à la typologie du réseau. De plus, cette méthode va permettre d avoir une meilleure vue d ensemble des scénarios d attaque en amenant la possibilité de générer des rapports d intrusion complets et de qualité. Les objectifs principaux de ces travaux sont d être capable de détecter les dérivés d un scénario (ou signature) connu d attaque pour ne pas se retrouver avec un algorithme ultra spécialisé ne détectant que des scénarios déjà détectés comme c est souvent le cas avec les approches existantes. Nous voulons aussi que nos algorithmes soient résistants aux diveres possibilités de mutation d un scénario. Afin de bénéficier des différentes étapes de la corrélation à la demande et de pouvoir facilement répartir ces étapes et les étendre, nous allons proposer un framework composé d agents indépendants. Le moyen de stockage des alarmes est essentiel, en effet, il doit être suffisam- 27

29 ment rapide pour pouvoir corréler rapidement un nombre important d alarmes mais il doit également être optimisé pour lier ces alarmes entre elles tout en garantissant la pérénité de ces dernières. Afin de pouvoir efficacement utiliser ce système, nous devons disposer d une grammaire ou d une representation permettant facilement de représenter un scénario car les limitations dues à la connaissance à priori des scénarios d attaque est trop contraignante. Nous souhaitons donc pouvoir proposer des techniques d apprentissage/détection automatique de nouvelles alarmes. L une des particularités essentielles pour une corrélation efficace et optimale est la possibilité de double lecture de la représentation. C est-à-dire qu à partir d une alarme critique, il est possible de remonter l ensemble du scénario mais également, dans le sens inverse, construire petit à petit la représentation de la session et la couper à la première étape révélant un risque de compromission. L algorithme doit être également capable d être extensible à d autres sources que les alarmes IDS telles que les rapports de vulnérabilites. En plus de cet algorithme, une méthode d apprentissage efficace doit être possible sur cette représentation afin de pouvoir apprendre les scénarios avec une intervention humaine réduite que ce soit pour des nouveaux scénarios ou des mutations de ceux déjà reconnus. De plus, afin de supporter le passage à l échelle, nous avons décidé d utiliser une méthode de calcul distribuée. Nous conservons la centralisation de certains composants mais en permettant de la haute disponibilité sur ceux-ci (via l utilisation de base de données de grande qualité) et nous proposons une méthode capable de répartir les calculs de corrélation sur un ensemble de machines dédiées à cet effet afin de limiter les risques de concurrence entre les utilisateurs et le fonctionnement de l IDS. Ce concept implique également la mise en place d un algorithme supportant la distribution et/ou de techniques de distribution. En fin, nous pensons que la grande limite des systèmes de corrélation actuels est qu ils sont de facto limité par les IDS eux-mêmes. C est pourquoi, la plupart des travaux de corrélation actuels ne corrélent que des données NIDS car une fois l intrusion réussie sur un host, il est relativement difficile, même en exploitant les données des HIDS de déterminer ce que l attaquant a pu faire. Notre situation est différente, car nous pouvons utiliser un Host IDS, PIGA, qui ne détecte pas simplement de simple intrusions unitaires mais des séquences d intéractions interdites même si les intéractions, prises indépendamment, sont autorisées. Cela va nous permettre de corréler des évènements HIDS et NIDS et surtout de proposer et détecter des sessions complexes d attaques. L étude sera donc axée plutôt orientée vers une utilisation avec PIGA mais sera généralisable à l ensemble des sources d informations existantes. 28

30 Chapter 5 Framework de Corrélation Distribuée 5.1 Introduction Plutôt que de chercher à construire un nouvel outil qui serait capable de détecter toute intrusion (chose impossible dans l absolu), nous préférons avoir une approche complémentaire à ce qui existe, et plus précisément, nous appuyer sur ce qui existe (les différents outils et informations dont on dispose) pour nous permettre d avoir des scénarios d attaques de plus haut niveau. Ces scénarios apportent plus de connaissances sur les différentes étapes de déroulement des attaques. Bien entendu, certaines attaques consistent en une unique étape et nous devons également être capable de la détecter mais parfois, enrichir l alarme (la connaissance de l attaque) avec des sources externes (telles que des scans de vulnérabilité) permet aussi de mieux la détecter. 5.2 Contexte pratique des travaux IDS Pour pouvoir surveiller tout comportement depuis, vers ou sur un système d information, il a été introduit les systèmes de détection d intrusions (IDS) qui vont générer une alarme pour chaque intrusion supposée. Il y a deux grandes familles de IDS: les Host Based IDS (HIDS) et les Network Based IDS (NIDS). Les HIDS sont dédiés à la surveillance des activité sur un système alors que les NIDS sont dédiés à la surveillance du réseau. On peut calculer la qualité d un IDS en regardant le nombre de faux négatif 1 et de faux postif 2. Il existe 3 approches de détection d intrusion: la détection d anomalie: se base sur le fait qu une intrusion implique une modification du fonctionnement d une partie du système d information. Il compare un scénario valide et le déroulement actuel et lève des alarmes s il y a des différences. 1 Une intrusion qui est non détectée. 2 Une action valide considéré comme une intrusion. 29

31 la détection par scénario: se base sur l utilisation de signatures de scénario d attaque pour détecter un comportement offensif en regardant un flux d évènements i.e. les alarmes générées par l IDS. la détection basée sur une politique de sécurité: se base sur le respect d une politique de sécurité comme comportement normal. Contrairement aux 2 autres approches, les alarmes générées sont des violations d une politique qui permettent de détecter des attaques inconnues Contrôle d accès Le contrôle d accès permet de garantir la confidentialité et l intégrité sur un système d information qui l implémente en se basant sur une politique de sécurité qui réglemente les relations entre les différents ressources et intervenants. Il existe 3 grands types de contrôle d accès: Contrôle d accès discrétionnaire: il se base sur le fait que les utilisateurs définissent la politique de sécurité sur les fichiers (et ressources) qui leur appartiennent (fonctionnement classique des systèmes d exploitation actuels). mécanisme basé sur une identité et l appartenance d un fichier à une identité. chaque utilisateur est responsable des droits qu il met sur ces objets (pas de sécurité globale possible). tous les programmes lancés par un utilisateur héritent de ces droits et permissions (aucune protection contre les logiciel malicieux). uniquement 2 types d utilisateur: les administrateurs et les utilisateurs. Contrôle d accès obligatoire: Les droits sont décrits par une politique de sécurité et imposés par une entité globale (MAC). La politique est défini par un administrateur et imposée à l ensemble des sujets (processus) et objets (eg. files, socket, network interface). Contrôle d accès basé sur les rôles: Ce modéle ajoute un niveau d abstraction: les rôles. On assigne à ces derniers un certain nombre de permissions, ensuite, on en assigne des rôles à chaque utilisateur Méta-Politique Avec les systèmes répartis (e.g., les clusters), il faut être capable d avoir une politique de sécurité globale pour l ensemble du réseau comportant des systèmes hétérogènes. Plus particulièrement, nous utilisons les méta-politiques permettent de définir une politique globale (meta-politique) qui va s adapter automatiquement à chaque système (politique locale), contrairement à une politique multi-domaine qui doit être écrite pour chaque système SELinux Partant du constat que le système de droits d accès, actuellement utilisé dans les systèmes pour permettre la confidentialité et l intégrité, n est plus adapté, il faut s orienter vers MAC mais sans la vision traditionnelle qui est trop rigide pour une utilisation dans 30

32 un environement réel. C est dans cette optique qu a été introduit SELinux (voir article [LS01a, LS01b]). Voici les deux grands principes fondamentaux concernant le fonctionnement d SELinux: les politiques vont imposer des restrictions sur les données, établir des rôles bien définis pour les utilisateurs et restreindre l accès aux données classifiées. les politiques de confinement sont utiles pour resteindre les accès d un programme à seulement ce qu il est nécessaire. Cela minimise les dommages en cas d intrusion. SELinux combine un système RBAC (Role Based Access Control) et TE (Type Enforcement 3 ). Les identités SELinux sont orthogonales à celle de Linux (UID). Cela renforce la sécurité du système car il inclut deux systèmes de contrôle d accès, empêchant de nombreuses intrusions. Contrairement à une politique RBAC classique où les permissions vont être définies en fonction des rôles, SELinux va utiliser des domaines qui peuvent être utilisés par des rôles et permettre de mettre en place la configuration du TE. Chaque objet dans le système a un type; une matrice d accès est définie pour connaitre les droits d accès entre 2 types. SELinux introduit la notion de contexte de sécurité 4 (CS). Un contexte de sécurité de SELinux contient l identité de l utilisateur, un rôle, un type et optionnellement un niveau MLS. Les rôles ne sont valables que pour les processus, les objets ont donc un rôle générique (object_r). Un nouveau fichier hérite du même type que le répertoire où il est créé. Les pipes, descripteurs de fichiers et les sockets héritent du SID du processus qui les a créé. Les messages de sortie héritent du SID du socket qui les a envoyé. SELinux se base sur un langage qui va permettre de déclarer ce que chaque sujet à le droit de faire, tout le reste étant interdit par défault. Sous SELinux: toute entité sur le système est rattachée à un CS : <user, role, type>. Exemple de régles SELinux: allow type_1 type_2 : class perm_1... perm_n; (5.1) type_transition type_1 type_2 : f ile def ault_f ile_type; (5.2) type_transition type_1 type_2 : process default_process_domain; (5.3) role rolename type type_1... type_n; (5.4) role_transition current_role program_type new_role; (5.5) user username roles role_1... role_n; (5.6) La première ligne permet d autoriser le type_1 et le type_2 à avoir les permissions d accés perm_1 à perm_n sur les objets de classe class. La deuxième ligne permet d autoriser la transition du type_1 au type_2 aux objets de classe fichier et de type default_file_type. La troisième ligne est également une autorisation de transition de type mais pour un processus dans le domaine default_process_domain. La quatrième ligne permet d assigner les type_1 à type_n au role rolename. La cinquième ligne autorise au type de programme program_type de changer de rôle en allant du rôle current_role vers new_role. La sixième ligne affecte les rôles role_1 à role_n à l utilisateur user. 3 Type Enforcement permet de donner la priorité au système MAC par rapport au système DAC dans un environement où les deux types de contrôle d accés cohabitent. 4 ou security context (SC) en anglais 31

33 Figure 5.1: Déroulement du processus de corrélation PIGA Cet IDS utilise une nouvelle approche des IDS basée sur les politiques de sécurité. Il va permettre de contrôler une politique locale de type MAC généré depuis une métapolitique mais également de pratiquer des contrôles supplémentaires tel que le contrôle des séquences qui n est pas possible avec les autres approches de système d intrusion basé sur les politiques. Une séquence illégale est un ensemble d actions légales qui, ensemble, forment une action interdite. Ces séquences sont partagées en plusieurs groupes: entity deviation, violation of sequence, violation of information flow, violation of a trusted computed base and violation of separation of duties. Il est basé sur le calcul de graphes d intéractions calculés à l aide de la politique locale. En plus d étendre les propriétés de sécurité offertes par le contrôle d accés, PIGA peut également auditer les accès. 5.3 Proposition d un framework de corrélation distribuée Introduction Nous présentons dans ce chapitre le framework conceptuel que nous proposons et que nous avons implanté. Ce framework reprend les travaux de [VVKK04, Qin05] pour les différentes étapes de la corrélation (qui tend à devenir un standard) et sur des idées de [KTK05] pour la distribution des calculs, notamment le concept d agent migrant. Comme le proposent [VVKK04, Qin05], notre framework est découpé en plusieurs blocs fonctionnels, dont l exécution est plutôt ordonnée temporellement. Dans la plupart des cas, les alarmes suivront un cycle de traitement particulier, c est-à-dire l ordre classique des étapes du processus de corrélation. Dans certains cas, le processus peut être modifié afin d optimiser certains scénarios, et certaines étapes peuvent être ajoutées/supprimées/déplacées. La figure 5.1 présente ce framework global, dans lequel le point d entrée est le prétraitement (preprocessing) des données brutes. Une partie de ces services de corrélation sont totalement indépendants et d autres sont directement intégrés aux IDS mais tous sont reliés à la même base de données. 32

34 Nous présentons très brièvement ces étapes avant de les détailler dans les soussections suivantes : Preprocessing : préparation des données pour les calculs de corrélation ; Alert Fusion : aggrégation des alarmes ayant un ensemble de critères en communs ; Alert Verification : réduction du nombre de faux positifs (alertes générées à tord) ; Attack Thread Reconstruction : reconstruction (détection) d une session d attaque sur une seule machine lancée par un seul attaquant ; Attack Focus Recognition : détection d attaques massives ; Attack Session Reconstruction : reconstruction de sessions multi-senseurs à partir d alarmes HIDS et NIDS ; MultiStep Correlation : identification (détection) d une session d attaque globale composée de plusieurs sessions multi-senseurs. On utilise plusieurs méthodes pour cela : LinkToSession, LinkBackToSession, IslandHopping, Recon-Breakin- Escalate qui seront détaillées plus bas ; Pattern Recognition : Classification (reconnaissance) des sessions d attaques ; Impact Analysis : analyse de l impact final de l attaque sur le système, i.e., a-telle eu des conséquences sur son fonctionnement ; Alert Prioritizing : attribution de différents niveaux d importance à une attaque en fonction de sa (ses) cible(s) ; Alert Sanitization : suppression de données nominatives or hors-contexte dans la alarmes recueillies. La sous-section suivante détaille les différentes étapes du framework ci-dessus Preprocessing Cette étape est la première du système de corrélation proposée par [VVKK04]. Elle prépare les données pour la corrélation. Son but est de vérifier que tous les attributs d une alarme sont correctement remplis. Pour cela, nous nous assurons que les dates sont valides (si un timestamp se trouve dans le futur par rapport à l heure de réception de l alarme dans le système de détection, nous supposons que le service qui a généré cette dernière est désynchronisé) et nous la transformons en intervalle ( e.g. le timestamp start est bien avant le timestamp end). Nous complétons également les informations qui pourraient manquer pour éviter des erreurs dans la suite du processus de corrélation. Notons que dans notre implantation, afin d optimiser cette étape, nous l avons intégrée directement dans l IDS PIGA, sur lequel nous travaillons. Les alarmes sont donc analysées au fur et à mesure qu elles sont générées par SELinux et traitées par PIGA, ce qui évité de faire des traitements complexes au niveau de la Base de Données. Par contre, cela n impacte quasiement pas les performances de PIGA. 33

35 5.3.3 Alert Fusion [VVKK04, Qin05] proposent cette étape afin de rassembler les différentes instances d un événement qui a généré plusieurs alarmes sur un ou plusieurs systèmes de détection. L objectif de ce regroupement est de créer une méta-alarme rassemblant les informations relative à cet événement. Grâce à cette étape, nous allons donc pouvoir supprimer un certain nombre de doublons qui auraient ralenti le processus de corrélation et cela sans perdre d information en remplaçant N alarmes par une méta-alarme enrichie i.e. certains attributs n étant plus uniquement une valeur mais un ensemble de valeurs. Nous proposons, pour créer ces méta-alarmes, de nous baser sur les timestamps mais également les différents attributs des alarmes. En pratique, pour comparer deux alarmes et voir si nous pouvons les fusionner en une méta-alarme, nous extrayons tous les attributs qu elles ont en commun et nous regardons si ils sont égaux, si c est le cas, nous les fusionnons. Afin de gérer les problèmes de légère désynchronisation, nous autorisons un décalage de plus ou moins t entre les timestamps (t étant un temps en milliseconde). La méta-alarme générée aura comme timestamp les bornes inférieures et supérieures des timestamp des alarmes qu elle fusionne et ces attributs seront l union des attributs des deux alarmes (c.a.d. les attributs égaux et ceux qui ne sont présents que dans l un). Enfin nous ne nous limitons pas à la fusion de deux alarmes en une méta-alarme, en effet, pour pouvoir gérer le fait qu un événement ait provoqué la création de plus de deux alarmes, nous pouvons également fusionner une méta-alarme avec une alarme. Afin de limiter l intéraction entre les IDS et la base de donnée, cette étape a été découpée en deux sous étapes. Nous regroupons un maximum d alarmes directement dans le processus de l IDS, mais en limitant tout de même cette étape, pour éviter une explosion de la complexité de l IDS. Puis l IDS envoie ces alarmes regroupées à la base de données. Grâce à cette première fusion, nous limitons les échanges et les risques d erreurs tout en minimisant l explosion de complexité du coté IDS. Finalement, dans un deuxième temps, un agent du framework de corrélation se connecte à la base et compléte cette étape Alert Verification Comme la qualité de la corrélation décroît fortement avec le nombre faux-positifs, on cherche à les écarter le plus tôt possible durant le processus de corrélation. Le but de cette étape est donc d identifier les attaques réelles qui ont réussies des attaques non réussies ou de simples événements mal interprétés. Pour finir, un point important de cette étape est qu elle ne doit pas provoquer l utilisation de trop de ressources en recherchant les informations voulues, et doit être faîte le plus rapidement possible avant que l attaquant éventuel n ait eu le temps d effacer les traces de ses actions. Dans notre cas d étude avec l utilisation de PIGA, cette étape est transparente car le système d exploitation SELinux effectue déjà ce contrôle. En effet, les alarmes générées sont par définition déjà valides. Pour ce faire, [VVKK04, Qin05] proposent deux familles de méthodes : passives ou actives, qui visent le même objectifs : corréler les alarmes reçues avec la connaissance que l on a du système, obtenue par exemple par des rapports de vulnérabilités ou définie manuellement a priori, à l aide d un formalisme donné. Les auteurs proposent d utiliser l une ou l autre des deux types de méthodes. 34

36 Nous proposons de combiner les approches passives et actives. Concrètement, cela revient, d une part, à comparer les alarmes reçues avec la configuration de la machine victime (ex: OS, service, version) et, d autre part, de rechercher les traces que l alarme aurait dû laisser si elle avait réussi Attack Thread Reconstruction [VVKK04, Qin05] introduisent cette étape pour reconstruire une session d attaque sur une machine donnée, en regroupant les alarmes et/ou méta-alarmes survenues sur cette machine (les alarmes pouvant provenir de différent senseurs) et provenant d un seul attaquant. La difficulté est alors de combiner toutes les alarmes relatives à une même session d attaque. Cette approche diffère du processus de fusion car 1) elle opère sur des données d alarmes non brutes (voire des méta-alarmes), et 2) l aggrégation est relative aux données de session : adresses IP et nř de session, quand ils sont disponibles, ou à défaut l utilisation des dates de génération. Concrètement, nous utilisons un processus d aggrégation qui se base sur des IP sources et destinations identiques dans une fenêtre de temps réduite (et modulable). Les méta-alarmes générées ont alors comme bornes le min et le max de l ensemble des timestamps des (méta-)alarmes qu elles regroupent. Enfin comme précédemment, nous utilisons une variable t (qui permet de corriger les légers décalages temporels qui peuvent exister entre les différents senseurs) pour pondérer les timestamps. Cette étape est développée sous la forme d agent où chaque instance est chargée de reconstruire une session compléte en se basant sur un algorithme défini Attack Session Reconstruction Cette étape, proposée par [VVKK04] permet d identifier les relations entre les alarmes provenant des HIDS et celles provenant des NIDS afin de construire des sessions multisenseurs. Concrètement, nous utilisons une égalité entre les attributs réseaux de deux alarmes provenant de deux senseurs différents afin de créer une session multi-senseurs e.g. les attributs correspondant à l IP source, l IP destination, le port source et le port destination doivent être égaux. Dans les approches existantes, à cette étape de la corrélation, les sessions reconstituées lient uniquement des alarmes NIDS et HIDS. Contrairement aux travaux existants, nous proposons dans cette étape de ne pas lier uniquement des alarmes NIDS et HIDS entre elles mais également des sessions d attaques HIDS avec d autres sessions d attaques HIDS et des sessions d attaques NIDS avec d autres sessions d attaques NIDS. Notre framework est le seul à rendre cela possible. Pour la liaison des attaques HIDS entre elles, nous proposons de tirer avantage du mécanisme de contrôle d accès DTE de SELinux, sur lequel s appuie PIGA pour avoir des alarmes HIDS assez riches et variées et pouvoir ainsi les lier entre elles. Ainsi, notre framework est par exemple le seul à pouvoir détecter des fuites par des fluxs réseaux (e.g. Inet Socket) ou systèmes (e.g. Unix Socket). 35

37 5.3.7 Attack Focus Recognition Le but de cette étape, proposée par [VVKK04] va être d aggréger l ensemble des (méta-)alarmes provenant ou à destination d une machine comme, afin d identifier les attaques massives. Par exemple, on peut avoir un scénario de type one2many (comme un scan) ou many2one (DDOS). Les auteurs proposent d utiliser une fenêtre de temps évolutive pour détecter les attaques de type slow-attack MultiStep Correlation Avec cette étape, proposée par [VVKK04], le processus de corrélation permet d identifier des sessions globales à partir de sessions multi-senseurs. Le principe est de corréler des scénarios d attaques génériques entre eux en utilisant une représentation de haut niveau pour détecter des attaques avancées. Au sein de cette étape, nous proposons un certain nombre de méthodes pour des attaques particulières. LinkToSession : Cette méthode que nous introduisons permet de lier une attaque massive (cf ) avec une session multi-senseurs pour reconstruire une session plus globale. Par exemple, associer une attaque de type Brute-Force 6 avec une session de type connexion ssh, crée suite à la réussité de l attaque par Brute- Force. LinkBackToSession : Cette méthode permet de lier une session multi-senseurs ayant lancé une attaque massive et l attaque massive elle-même. Island-hopping : Cette méthode permet de détecter l intrusion sur une machine qui devient elle-même la source d une nouvelle intrusion sur une autre machine, ce processus étant transitif. Recon-Breakin-Escalate : Cette méthode permet de détecter une attaque combinant de manière séquentielle : un scan de vulnérabilités (Recon), une intrusion résultant à l exploitation de l une des vulnérabilités identifiées (Breakin) et ensuite une escalade de privilèges (Escalate lui permettant de passer du premier compte utilisé (e.g., compte utilisateur standard) jusqu à un compte aux privilèges plus élevés (e.g., compte root) Impact Analysis Avec cette étape, proposée par [VVKK04], le but va être de récolter et d utiliser des informations externes au système de détection afin de calculer l impact qu a eu, a et va avoir l alerte. Pour cela, nous créons et maintenons une base de données contenant les informations réseaux et machines de l ensemble du système d information et les relations qui les lient (par exemple, le serveur mail a besoin du serveur DNS pour fonctionner). Ces informations peuvent provenir de sondes de monitoring. Enfin, nous informons les personnes voulus par divers systèmes (par exemple: mail, messagerie instantanée, SMS) 5 e.g., un scan très lent (1 paquet/min) 6 Attaque de cassage de mot de passe par force brute, i.e., essais successifs nombreux de différents mots de passe contenus dans des dictionnaires d attaquants. 36

38 ou nous mettons en place une réaction automatique (mais dans ce cas, il faut faire attention au risque que l attaquant puisse retourner le système contre nous e.g. si le système de réaction automatique banni les adresses IP des attaquants, un attaquant peut falsifier son adresse afin de prendre celle d un serveur critique pour le réseau et ainsi faire bannir par le système de réaction automatique, une machine qui est essentielle au réseau et le faire ainsi s écrouler). Cette étape sera peu étudiée car elle relève plus de l administration et uniquement des rapports d intrusion relativement simple seront implémentées afin de vérifier le bon fonctionnement et de mieux étudier les scénarios d instrusions par l oeil humain Alert Prioritizing Cette étape, proposée par [VVKK04, Qin05], va permettre d augmenter le niveau de priorité d une alarme suivant les répercussions qu elle a eu dans le système mais également de la classifier (par exemple, on va réduire le niveau d importance des alertes provenant d un scan). Le niveau d alerte attribué est fonction de la criticité définie a priori de la source et de la cible Alert Sanitization Le but de cette étape, introduite par [JBHT04] est de supprimer les sessions qui ne sont pas intéressantes selon le point de vue de notre réseau (par exemple, attaques sur un réseau en dehors de notre juridiction). Cette étape permet également d anonymiser les alarmes (il devient impossible par la suite de retrouver les informations anonymisées) ou pseudonymiser (il devient possible de retrouver les informations par la suite) afin de pouvoir les transmettre entre les systèmes sans risquer de donner des informations critiques. Cette étape est particulièrement utile pour partitionner une entreprise en secteurs et éviter au maximum la fuite d information si l ensemble d un secteur est corrompu i.e. cela permet de prévenir l utilisation des données de corrélation de l ensemble du réseau par l attaquant. En effet ce dernier pourrait s en servir afin d apprendre un maximum sur la structure du réseau et d essayer d y repérer les failles. Cela peut également servir dans le cas de collaborations avec d autres organismes tiers i.e. éviter pour des raisons de sécurité mais également judiciaire d envoyer des informations sensibles ou privées à des collaborateurs. Bien qu utile en entreprise, cette étape n apporte pas de fonctionnalité réelle dans le processus d identification des sessions. 37

39 Chapter 6 Algorithmique du framework de corrélation 6.1 Introduction Ce chapitre détaille les aspects algorithmiques et formels du framework introduit au chapitre précédent. Chacun des blocs fonctionnels du framework est donc revu de façon plus formelle dans ce chapitre, et les premiers algorithmes de corrélation établis y sont présentés. Afin de pouvoir corréler les différentes alarmes générées par les sondes (et plus particulièrement celles provenant de PIGA et se basant sur SELinux), nous décrivons comment exploiter ces différents ensembles d alarmes 1. Nous introduisons donc la notion d alarme, pouvant provenir d outils de monitoring, de NIDS, HIDS, etc. Nous proposons de caractériser les alarmes à l aide des attributs proposés dans SELinux (cf ) pour décrire chaque alarme qu il génère. Nous les avons raffiné et étendus pour maximiser les possibilités et les capacités de corrélation. Une alarme A est la donnée d un ensemble d attributs d alarme AT T (A AT T N ), dont chaque élément attr est étiquetté par une étiquette e, où e E. AT T = {attr e ; e E} L ensemble E des étiquettes d attributs est défini en extension par : E = {scontext, tcontext, hostname, security_perms, security_class, pid, ppid, id, dpid, dppid, date, comm, name, dev, inode, priority, idsession, source_ip, dest_ip, source_port, dest_port, netif, count}. Le tableau 6.1 détaille la nature de ces différents étiquetages possibles d attributs d alarme. Chaque attribut attr AT T peut prendre une valeur parmi un ensemble défini en fonction de son étiquette. Formellement, une alarme A est donc définie par : A = (attr e1 ;... ; attr en ), n N, i [1; n], attr ei AT T (i, j) [1; n] 2, e i e j On notera par A attre, la valeur de l attribut attr étiquetté par e, appartenant à A. On notera par A l ensemble de toutes les alarmes ( i N, A = A i ). 1 Nous parlerons d ensembles au sens de collection d individus de l univers considéré 38

40 Etiquette Description classification classification de l alarme, i.e. l attaque à laquelle elle correspond scontext contexte de sécurité (cf. SELinux, 5.2.4) source tcontext contexte de sécurité (cf. SELinux, 5.2.4) destination hostname nom (ou IP) de la machine où a été détectée la rupture de sécurité security_perms nom de la permission de sécurité (cf. SELinux, 5.2.4) security_class nom de la classe de sécurité (cf. SELinux, 5.2.4) pid numéro du processus source de la rupture de sécurité ppid numéro du processus père de celui source de la rupture de sécurité id numéro unique de chaque alarme date date (en milliseconde) à laquelle a été détectée la rupture de sécurité name nom des fichiers impliqués dans la rupture de sécurité com liste des commandes impliquées dans la rupture de sécurité dev contexte de sécurité (cf. SELinux, 5.2.4) destination hostname nom de l interface impliqué dans la rupture de sécurité, e.g. /dev/hda3 inode numéro de l inode où a été détecté la rupture de sécurité priority niveau de priorité de l alarme idsession numéro de la session dans laquelle se trouve cette alarme source_ip IP source de la rupture de sécurité dest_ip port source de la rupture de sécurité source_port IP destination de la rupture de sécurité dest_port port destination de la rupture de sécurité netif interface réseau impliquée dans la rupture de sécurite e.g. eth0 count dans le cas d une méta-alarme, le nombre d alarmes rassemblées Table 6.1: attributs d alarme 39

41 Nous avons défini et utilisé six grands types d alarmes (ensemble à étendre dans le futur), issus des différentes étapes du framework. Nous présenterons formellement ces six ensembles de d alarmes ou de méta-alarmes au fur et à mesure de leur apparition à travers les étapes du processus de corrélation. 6.2 Preprocessing: élimination des malformations. Le premier but de cette étape est d éliminer les alarmes malformées. Dans notre situation, ce premier niveau d alarmes provient du système (kernel puis syslog). Le traitement de ces alarmes sera fait par PIGA. Avant de poursuivre nous introduisons deux types d alarmes issues de cette étape, qui dans notre cas seront donc fournies par PIGA. Mais la démarche est générale, et peut-être adaptée à n importe quel outil. Nous différencions deux types d alarmes car PIGA traite à la fois des logs liées au réseau (connexion ssh par exemple) et des données liées uniquement à la machine locale. 1. Soit A piga l ensemble des alarmes générées par PIGA (A piga A), ne contenant pas d information réseau : A piga = {attr scontext ; attr tcontext ; attr hostname ; attr security_perms ; attr security_class ; attr pid ; attr ppid ; attr id ; attr date ; attr com ; attr name ; attr dev ; attr inode ; attr priority ; attr idsession } 2. Soit A piga net l ensemble des alarmes générées par PIGA (A piga net A), contenant des informations réseau : A piga net = {attr scontext ; attr tcontext ; attr hostname ; attr security_perms ; attr security_class ; attr pid ; attr ppid ; attr id ; attr date ; attr name ; attr dev ; attr inode ; attr priority ; attr idsession ; attr priority ; attr source_ip ; attr dest_ip ; attr source_port ; attr dest_port ; attr netif } Identification et normalisation d alarme Pour normaliser les alarmes, nous utilisons des schémas ou patterns qui permettent d éliminer certaines fausses alertes (faux positifs) mais également permet d ignorer des informations non pertinentes, ou insuffisamment rensiegnées. Concrètement, ils sont représentés à l aide d expressions régulières, exprimant des informations sur des attributs de l alarme. Dans le cadre de nos travaux, l utilisation de PIGA implique que toute alarme doit avoir ses attributs liés aux contextes de sécurité (i.e., scontext, tcontext) valués. Si ce n est pas le cas, l alarme sera ignorée lors des étapes suivantes de la corrélation. Par contre, certains attributs peuvent ne pas être instanciés ou inconnus sans pour autant impliquer la destruction de l alarme (e.g. dans certains cas, source_ip n est pas indispensable). Pour chaque outil ou IDS utilisé est défini un pattern de normalisation. Nous disposons donc d un ensemble de patterns de normalisation. Nous donnons une description algorithmique de ce processus. L algorithme de preprocessing que nous proposons ci-dessous prend en entrée une ensemble de patterns généraux et obligatoires main_pattern_set, un ensemble de sous patterns spécialisés et optionels sub_pattern_set et une alarme à traiter raw_alarm. L algorithme retourne une alarme traitée preproc_alarm. 40

42 L algorithme commence par déterminer si l alarme ou l événement correspond à l un ou/et l autre des patterns de haut-niveau correspondant à l alarme. Si l alarme correspond à l un des patterns, elle subit un premier traitement via l application de proc_alarm = f ield(raw_alarm, pattern). L alarme devient ainsi plus précise, car certains attributs sont instanciés et l alarme passe de sa forme brute, e.g. audit( ): scontext=system, tcontext=... Cette première étape permet de déterminer la nature de l alarme : alertes HIDS générée par osiris (vérificateur d intégrité) ou PIGA par exemple, alertes NIDS provenant de snort. Si l alarme n a pu être identifié, elle est rejetée. Ensuite, une deuxième étape de l algorithme va essayer l ensemble de faire correspondre des sous patterns réguliers spécialisés sur l alarme traitée. Concrètement, dans notre cas, à ce stade de notre travail, les sous patterns ne concernent que les informations de type réseau. Mais encore une fois, le principe reste général. Si l alarme respecte un des sous patterns spécialisés, les attributs spécialisés correspondant sont instanciés à l aide des valeurs présentes dans le sous pattern. Si l un des attributs obligatoires pour cette spécialisation ne peuvent être instanciés, l alarme est rejetée. Require: main_pattern_set, sub_pattern_set, raw_alarm Ensure: preproc_alarm pattern_find for all pattern in main_pattern_set do if check(raw_alarm, pattern) then proc_alarm f ield(raw_alarm, pattern) pattern_find for all sub_pattern in sub_pattern_set[pattern] do if check(pre_alarm, sub_pattern) then preproc_alarm f ield(pre_alarm, sub_pattern) else if sub_pattern_set[pattern].optional then return end if end for end if end for if pattern_f ind then return else return preproc_alarm end if Relativisation temporelle L objectif de ce deuxième aspect de préparation des données (preprocessing phase) vise à faciliter l exploitation des alarmes générées. En ce qui nous concerne, des problèmes se posent au niveau des dates des alarmes. Dès lors que des événements sensés se passer au même moment semble avoir des dates différentes, il est difficile de les relier du point du synchronisme. Aussi, cette étape permet d abstraire les dates ou timestamps sous la forme d intervalles temporels remplaçant la date initiale. Formellement, un intervalle est un couple de dates : date begin et date end. L algorithme que nous proposons ci-dessous va prendre en entrée une alarme traitée 41

43 Figure 6.1: Arbre de processus avec numéro de session vu par PIGA par l algorithme précedent et va retourner une alarme traitée dont la date a été légérement abstraite. La valeur de l attribut date de l alarme va être remplacé par une double valeur correspondant à la date de génération de l alarme plus ou moins une constante T. Cette constante T correspond à la fenêtre d abstraction de la date de l alarme. Finalement, l algorithme retourne l alarme. Require: preproc_alarm, T : duration Ensure: cleanpreproc_alarm cleanpreproc_alarm datebegin preproc_alarm date T cleanpreproc_alarm dateend preproc_alarm date + T return cleanpreproc_alarm 6.3 Identification de session Cette dernière étape de préparation (preprocessing) des données a pour objectif d affecter un numéro de session utilisateur à chaque alarme normalisée, ce qui permettra notamment par la suite de relier entre elles, toutes les opérations malveillantes effectuées au cours de la même session, et ainsi d avoir des informations sur les sessions d attaque. Le principe de cette étape est simple. Nous commençons par essayer de reconstruire le graphe des processus (en utilisant les numéros pid et ppid), à partir de l ouverture d une session sur une machine par exemple (processus init). Chaque noeud représente à la fois un processus mais aussi et surtout une des alarmes normalisée issues de l étape précédente. En général, à ce stade certains noeuds ont déjà un numéro de session. Nous utilisons ce numéro pour l affecter à tous ceux du graphe représentant la même session (voir figure 6.1). Ensuite, au fur et à mesure que les noeuds sont ajoutés au graphe des processus (construction dynamique du graphe), les numéros sont soit copiés pour la même session, soit incrémentés pour chaque nouvelle (tentative d ) ouverture de session. Sur la figure cela correspond à la tentative d ouverture d une nouvelle sesion ssh, en essayant un autre password. L algorithme suivant permet d effectuer ces opérations. L ensemble entry_point_set contenant les transitions de contextes de sécurité, représentant les points d entrées pos- 42

44 sibles sur une machine (e.g. le passage du context sshd ou f tpd à celui utilisateur). Concrètement, entry_point_set contient un ensemble de couples A attrscontext, A attrtcontext considérés comme des transitions possibles de contexte de sécurité. Le compteur cpt_idsession, spécifique à chaque machine, est initialisé à 0 au lancement de l algorithme. L algorithme va d abord vérifier que l alarme fait partie de entry_point_set dans le système, i.e. que le contexte source et le contexte destination correspondent à un couple dans l ensemble des transitions considérées comme points d entrée possibles (e.g. sshd vers user). Si c est le cas, un numéro de session est assigné à l alarme (et de manière automatique) dans l arbre des processus puis l algorithme incrémente la variable cpt_idsession (i.e. cpt_idsession = le prochain numéro session disponible. Si l alarme ne fait pas partie des points d entrée alors l algorithme va chercher dans l arbre des processus vu par PIGA si le père du processus qui a généré l alarme a un numéro de session. Si c est le cas, le numéro de session du père est assignée à l alarme. Require: Une alerte A 1 A, avec numéro de session non initialisé Ensure: L alerte A 1 avec son numéro de session initialisé if (A attrscontext, A attrtcontext ) entry_point_set then A 1 attr idsession cpt_idsession cpt_idsession cpt_idsession + 1 else if A 2, A 2 A A 2 attr idsession 0 A 2 attr pid = A 2 attr ppid then A 1 attr idsession end if return A 1 A 2 attr idsession 6.4 Alert Fusion Comme expliqué dans la section 5.3.3, cette étape permet de rassembler un groupe d alarmes selon leurs similitudes entre elles. Ce degré de similitude est variable. Il consiste en un nombre minimal m d attributs communs et une durée t de validité temporelle. Pour regrouper certaines alarmes, certains attributs communs (i.e., ceux ayant la même étiquette d une alarme à l autre) devront avoir la même valeur. Nous introduisons informellement la notion de méta-alarme M A, qui est un ensemble d alarmes regroupées en fonction de leur similitude et leur proximité temporelle. On écrire MA p m,t une méta-alarme de nature p, avec un nombre exact d attributs communs égaux m et une durée de validité temporelle t. Si les alarmes doivent avoir eu lieu au même instant, t = 0. Si la durée n importe pas, t =. Formellement, il existe une relation d équivalence entre deux alarmes d une métaalarme MA. MA définit ainsi une classe d équivalence entre les alarmes similaires au rang m et à validité t. A partir de cette définition génériqe des méta-alarmes, nous pouvons proposer, par exemple une définition particulière de méta-alarmes, adaptées à PIGA, dans laquelle nous regroupons l ensemble des alarmes ayant les mêmes attributs étiquetés par scontext, tcontext, name, idsession, security_class, security_perms et se déroulant dans un intervalle de temps t = 2z. 43

45 MA piga 6,2z = {A k ; k N / (k, k ) N 2, A k A piga, A k A piga A k attr scontext = A k attr scontext A k attr tcontext = A k attr tcontext A k attr name = A k attr name A k attr idsession = A k attr idsession A k attr security_class = A k attr security_class A k attr security_perms = A k attr security_perms ((A k attrdate z A k attr date A k attr date + z) ) } (A k attr date z A k attr date A k attr date + z) Selon le même principe, nous définissons une méta-alarme pour les alarmes contenant les attributs réseaux i.e. dest_ip, dest_port. MA piga net 8,2z = { A k ; k N / (k, k ) N 2, A k A piga net, A k A piga net A k attr scontext = A k attr scontext A k attr tcontext = A k attr tcontext A k attr name = A k attr name A k attr idsession = A k attr idsession A k attr security_class = A k attr security_class A k attr dest_ip = A k attr dest_ip A k attr security_perms = A k attr security_perms A k attr dest_port = A k ((A k attrdate z A k attr date A k attr date + z) ) } (A k attr date z A k attr date A k attr date + z) attr dest_port 6.5 Attack Thread Reconstruction Comme expliqué dans la section 5.3.5, le but de cette étape de la corrélation est de reconstruire une session locale à une machine. Cela consiste à rassembler toutes les alarmes générées depuis les ruptures de sécurité provenant d une machine et reliées à une seule et même session utilisateur. Nous introduisons un nouvel ensemble d alarmes MT s,h (pour Méta-T hread) qui va contenir la totalité des alarmes (incluant méta-alarmes, et les alarmes DTG 2 ) reliées à une session donnée s sur une machine h. Formellement, MT s,h = {A /A attridsession = s A attrhostname = h}. Les alarmes de DTG, dont nous n avons par parlé jusqu ici sont un pattern particulier pour les alarmes, alertant sur des transitions (changements) de contexte de sécurité interdites par la politique de sécurité déployée sur le système. Par exemple, le passage d un contexte de sécurité utilisateur à un contexte système (e.g. root). Dans la suite, nous noterons les alarmes de type DTG sous la forme suivante : A dtg. 2 Data Transition Graph : graphe de transition de contexte, cf. [BBLT06a] 44

46 6.6 Attack Session Reconstruction L étape précédente permet de reconstruire des sessions locales à une machine lancées par un attaquant. Comme expliqué dans la section 5.3.6, le but de cette étape de la corrélation est de reconstruire une session enrichie globale, c est-à-réunissant des informations provenant de divers senseurs à la fois réseaux et systèmes. Contrairement aux travaux existants, qui ne permettent que d ajouter des alarmes NIDS à des alarmes de type MT s,h, nous proposons de lier tout type de session, y compris plusieurs sessions ayant eu lieu sur une même machine (donc sans tenir compte des aspects réseau). Cela nous permet de détecter des flux interdits entre sessions d une même machine. Nous définissons un ensemble d alarmes globales GA τ contenant les alarmes de type sessions locales (MT s,h ) ou réseaux (A piga net ) respectant un certain nombre de conditions représentées par τ. Ces conditions τ portent à nouveau sur l égalité de certains attributs, en l occurrence réseaux : source_ip, source_port, dest_ip, dest_port, netif et se déroulant à la même date et des sessions réseau. GA τ = { A k ; k N / (k, k ) N 2, A k MT s,h A k A piga net τ } avec τ = ( A k attr source_ip = A k attr source_ip A k attr source_port = A k attr source_ port A k attr dest_ip = A k attr dest_ip A k attr dest_port = A k attr dest_port A k attr netif = A k attr netif {A k ) attr date ± t} = A k attr date 6.7 Attack Focus Recognition Comme expliqué dans la section 5.3.7, le but de cette étape est de détecter des attaques de masse, comme par exemple des attaques de déni de service distribuées (Distributed Denied of Service (DDoS), des attaques de cassage de mot de passe par force brute, etc. Nous définissons une variable entière af r, permettant de dénombrer le nombre d occurrences d attaques de type DTG, puisque ce sont elles dont il est question en cas d attaque massive. af r est simplement égale au cardinal de l ensemble des attaques A dtg dont la source ou la cible sont égales, survenant sur un hôte donné et dans un intervalle de temps également défini a priori, compris entre t et t + d. Cela se traduit d une façon générale par : { afr Ω A dtgk ; k N /A dtgk attr scontext = context 1 A dtgk attr tcontext = context2 t < A dtgk attr date < t + d A dtgk attr hostname = host1 } Un algorithme compare ensuite afr avec une constante c donnée en fonction de ce que l on cherche à détecter. Si afr est supérieur à c, une alarme de type attaque massive par transition du contexte context1 vers le contexte context2 dans l intervalle de temps [t..(t + d)] sur la machine host1. 45

47 Par exemple, pour détecter les tentatives de brute force sur le serveur SSH i.e la transition du contexte system_u : system_r : sshd_t vers le contexte system_u : system_r : system_chkpwd_t, on va compter à l aide d une variable afr bfssh : afr bfssh { Ω A dtgk ; k N /A dtgk attr scontext = system_u : system_r : sshd_t A dtgk attr tcontext = system_u : system_r : system_chkpwd_t t < A dtgk attr date < t + d A dtgk attr hostname = host1 } De même, pour détecter le brute force sur leur serveur ftp ce qui correspond à la transition de contexte system_u : system_r : f tpd_t vers system_u : system_r : system_chkpwd_t, on va compter dans une variable afr bfftp : afr bfftp { Ω A dtgk ; k N /A dtgk attr scontext = system_u : system_r : ftpd_t A dtgk attr tcontext = system_u : system_r : system_chkpwd_t t < A dtgk attr date < t + d A dtgk attr hostname = host1 } Cette méthode est extensible à l ensemble des massives attaques tel que les scans, les brute forces et les DOS. Nous pouvons également l étendre à la détection des attaques distribuées sur l ensemble des machines du système audité en supprimant l attribut A dtgk hostname. afr datk { Ω A dtgk ; k N /A dtgk attr scontext = context 1 A dtgk attr tcontext = context2 } t < A dtgk attr date < t + d Enfin nous pouvons limiter la recherche à un certain nombre de machines en vérifiant que l attribut A dtgk hostname est élément d un ensemble de valeurs possibles, que nous noterons HST, et qui correspond au sous-groupe du réseau que nous voulons considérer : { afr Ω A dtgk ; k N /A dtgk attr scontext = context 1 A dtgk attr tcontext = context2 } t < A dtgk attr date < t + d A dtgk attr hostname HST 46

48 idsession = IntIdSess A connect_depuis_ssh(idsession) Sync = X(A,B) B files = download_files() Sync = X(B,C) C.files = B.files C exec(files) Sync = X(C,D) D.files = C.files D connect_vers_port(files,irc_port) Figure 6.2: Automate d une pattern 6.8 Pattern Recognition Cette étape permet de détecter, en utilisant des patterns, le risque de compromission d une session locale à une machine. Les patterns que l on cherche à détecter ici concernent un ensemble d alarmes de niveau système rencontrées successivement et/ou parallèlement. Ces alarmes sont générées lors du non respect de politique de contrôle d accès sur un système se basant sur les MAC i.e. PIGA. Nous avons choisi de représenter ces patterns complexes à l aide d automates, dont les noeuds sont des alarmes et les transitions des conditions sur les noeuds situés avant et après la transition. Chaque transition est de plus conditionnée par une durée de validité après laquelle, la transition n est plus faisable. Ce formalisme par automate se base sur les automates introduits dans [RCV07]. On dispose d un ensemble de patterns défini a priori caractérisant un ensemble d attaques déjà classifiées manuellement. A titre d exemple, l automate représenté par la figure 6.2 décrit le scénario durant lequel un attaquant se connecte via SSH sur une machine, télécharge un fichier, l exécute. L exécution de ce fichier (de type cyber-bot) a pour effet d ouvrir une connexion sortante à internet via le port IRC. Cette automate prend en arguments un numéro de session idsession et un nom ou adresse de machine hostname. Précisément, dans cet exemple : le noeud (A) représente une connexion SSH i.e. un ensemble d alarmes corre- 47

49 spondant à une transition entre le contexte SSH et celui utilisateur relatif à une session sur une machine. le noeud (B) représente l ensemble des alarmes relatives au téléchargement de fichiers (i.e. des transitions de contexte vers les contextes http clients tel que user_http_port ayant le même numéro de session et hostname que ceux spécifiés comme arguments d entrée dans l automate). le noeud (C) représente l execution de ces fichiers (i.e. l ajout de la permission d exécution aux fichiers représentée par une transition vers le contexte chmod_x) puis l execution des fichiers représentée par une transition vers le contexte exec avec comme attribut name des alarmes le nom des fichiers. le noeud (D) représente la création d une connexion IRC par le processus qui résulte des l exécution des fichiers i.e. une transition vers le contexte port_irc avec l attribut pid des alarmes égale au pid du processus. La transition de A à B n a pas de condition autre que la contrainte de temporalité (i.e. le noeud A apparaît chronologiquement avant le noeud B et ils ne sont pas espacés de plus de X(A,B) millisecondes). La transition de B vers C respecte également la contrainte de temporalité mais également la condition C.files = B.files c est-à-dire que l ensemble des fichiers impliqués dans le noeud B doit être égal à l ensemble des fichiers impliqués dans le noeud C. Finalement, la transition de C à D respecte la condition temporelle et une condition semblable à celle de la transition de B à C. Nous donnons ci-après l algorithme général de classification (ou pattern recognition) dynamique d attaques. Il va permettre de comparer une session locale reconstruite durant l étape d attack thread reconstruction avec un ensemble des patterns hids_pattern_set. En les comparant avec la méta-alarme, on peut dire à quelle classe d attaque cette dernière appartient. La boucle pour (for) permet d identifier toutes les classifications possibles pour une méta-alarme. Ainsi, on peut avoir plusieurs niveaux de classification pour une même session. L algorithme de pattern recognition va prendre comme arguments hids_patterns_set et MT s,h et va retourner une alarme report_alarm relative à la classification de MT s,h grâce à la comporaisons avec un ensemble de patterns classifiés. L algorithme commence par initialiser à faux la variable booléenne pattern_f ind. L algotihme ensuite initialise la priorité de report_alarm avec la plus haute priorité possible, c est-à-dire celle de l alarme faisant partie de MT s,h ayant la priorité la plus élevée. La classification est initalisée à. Puis le respect de chaque pattern de l ensemble hids_pattern_set est vérifié. Si c est le cas, le booléen pattern_find est assigné à vrai et la variable priority est multipliée par la priorité du pattern de classication utilisé cette fois-ci (à ce tour de la boucle for). Le numéro d identification de la pattern est ajouté à l ensemble classification des patterns qui sont respecté par MT s,h. Finalement, si au moins une pattern est respectée par la session, alors l algorithme va créer une alarme report_alarm puis va modifier la priorité de report_alarm en lui affectant la valeur de la variable priority et de même pour l attribut classif ication et la variable classification. Si aucune parttern est respectée par la session alors l algorithme retourne. Require: hids_pattern_set, MT s,h Ensure: report_alarm pattern_find priority Max{A k attr priority ; k N /A k MT s,h } 48

50 classif ication for all pattern in hids_pattern_set do if check(mt s,h, pattern) then pattern_find priority priority pattern priority classification classification U pattern id end if end for if pattern_f ind then return else report_alarm attrpriority priority report_alarm attrclassification classification MT s,h MT s,h report_alarm report_alarm attrpriority priority report_alarm attrclassification classification report_alarm attridsession s report_alarm attrhostname h for all e i E {priority; classification; idsession; hostname} do report_alarm attrei end for return report_alarm end if Cette étape permet facilement d ajouter des patterns qui ne sont pas limitées à des scénarios locaux à base de SELinux mais peuvent prendre en compte d autres sources. 6.9 Alert Prioritizing Cette étape présenté dans la section permet de modifier la priorité d une alarme/métaalarme dès son arrivée dans la base de donnée pour réguler sa priorité selon un ensemble de règles statique prédéfinie. Par exemple, une expression régulière peut décrire le fait qu une alarme ait comme condition sur ses attributs source_ip soit égale à et source_port à Les patterns de prioritisation sont établis à la main (pour l instant) e.g. source_ip = = Si les attributs d une alarme respectent les conditions énoncés dans l un des patterns, alors on multiplie la priorité de l alarme avec celle de la pattern et on affecte cette nouvelle priorité à l alarme. En pratique, ca permet d augmenter la priorité de certaines parties du réseau. Par exemple, on souhaite mettre en valeur l ensemble des attaques provenant de, à destination de, ou sur le serveur web dest_ip = OR source_ip = OR hostname = Nous ne nous limitons pas aux nouvelles alarmes mais nous généralisons à l ensemble des données, i.e. une session peut aussi correspondre à une pattern de prioritization et voir sa priorité augmentée par cette étape. L algoritme va prendre un ensemble de pattern prio_pattern_set et une alarme alarm et va retourner une alarme dont la priorité aura pu être modifiée prio_alarm. Nous allons vérifier pour chaque pattern, si l alarme la respecte et si c est le cas, nous multiplions la priorité de prio_alarm par celle de la pattern. Finalement, l algorithme retourne l alarme prio_alarm. 49

51 Require: prio_pattern_set, alarm Ensure: prio_alarm prio_alarm alarm for all pattern in list_main_pattern do if check(alarm, pattern) then prio_alarm attrpriority end if end for return alarm 6.10 MultiStep Correlation prio_alarm attrpriority pattern prio L étape MultiStep Correlation permet d identifier une sessions globale multi-senseurs, à l aide de plusieurs méthodes : LinkToSession, LinkBackToSession, IslandHopping, Recon-Breakin-Escalate LinkToSession L étape linktosession permet de retrouver une session qui a été créée après qu une attaque massive ait eu lieu, e.g. un brute force, ayant abouti à la création d une nouvelle session dans le système. On cherche donc à lier une attaque massive à une session. Nous introduisons l ensemble AF R LtoS regroupant les alarmes de séquences DTG A dtg impliquées dans une attaque de masse provoquant une transition du contexte context1 au contexte context2 sur une machine host1 et dans un intervalle de temps compris entre t et t + d. Cette ensemble AF R LtoS est un sous ensemble de A dtg qui respecte les même conditions que celles utilisées pour calculer afr (cf. 6.7). { AF R LtoS Ω A dtgk ; k N /A dtgk attr scontext = context 1 A dtgk attr tcontext = context2 t < A dtgk attr date < t + d A dtgk attr hostname = host1 } Si afr (présenté dans la section 6.7) est supérieur à la constante MAX_AF R alors l algorithme suivant vérifie si une (ou plusieurs) session(s) résultante(s) de cette attaque a (ont) été créée(s) avec succés. L algorithme ci-dessous prend en entrée un ensemble de séquences AF R LtoS et va retourner un ensemble raf R de numéros de session. Cet algorithme va parcourir chaque séquence DTG de AF R LtoS et si l attribut idsession d une séquence DTG est différent de 0, il est ajouté à l ensemble de numéros de sessions raf R LtoS. Require: AF R LtoS Ensure: raf R LtoS raf R LtoS = for all A in AF R LtoS do if A attridsession 0 then raf R LtoS raf R LtoS + A attridsession end if end for 50

52 return raf R LtoS LinkBackToSession linkbacktosession a un fonctionnement inverse de LinkToSession. Si une attaque massive a pour source le réseau surveillé alors nous recherchons la (ou les) session(s) émettrice(s). La différence avec LinkToSession est que le réseau surveillé passe de destination à source de l attaque et que la transition n implique pas les mêmes contextes. Nous introduisons l ensemble AF R LBtoS, pendant de AF R LBtoS à l étape Link- ToSession. Cette ensemble AF R LtoS est un sous ensemble de A dtg qui respecte les même conditions que celles utilisées pour calculer afr (cf. 6.7). La forme générale de AF R LBtoS et de l algorithme associé sont les même que pour AF R LtoS et l algorithme ci-dessus. Seuls les attributs considérés changent Island Hopping L Island Hopping est un type de scénario d attaque où un attaquant va compromettre une machine puis va se servir de celle-ci pour en compromettre une seconde. Nous cherchons à détecter si une session locale a essayé d interagir avec des machines présentes sur le réseau surveillé et, si c est le cas, chercher à retracer les possibles sessions résultantes créées. L algorithme prend en entrée un métathread MTs,h 1 et un ensemble de metathread MTs,h 2 et va retourner un ensemble lrs de numéros de session sur une ou plusieurs machines. Ensuite si une des valeurs de l attribut destination IP dest_ip du metathread MTs,h 1 est compris dans l ensemble des IP du réseau surveillé LAN_IP, l algorithme créée un ensemble P RED 1 de metathread MT2 qui a l attribut hostname égale à l attribut dest_ip de MTs,h 1 mais qui respecte également les conditions suivante l attribut hostname de MTs,h 1 est égale à l attribut source_ip de MT s,h 2, l attribut dest_port de MTs,h 1 est égale à l attribut source_port de MT s,h 2, l attribut source_port de MT s,h 1 est égal à l attribut dest_port de MTs,h 2 et que MT s,h 2 se déroule après MT s,h 1 et dans un intervalle de temps d. Ensuite, l algorithme ajoute les numéros de session correspondant à P RED 1 dans lrs. Finalement, il retourne l ensemble lrs. Require: MTs,h 1, MT s 2,h, LAN_IP Ensure: lrs if A k MTs,h 1 ; k N /A k attr dest_ip LAN_IP then P RED 1 {A k ; k N / (k, k ) N 2, A k MTs,h 1 MT 2 Ak s,h A k attr dest_ip = A k attr hostname A k attr hostname = A k attr source_ip A k attr dest_port = A k attr source_port A k attr source_port = A k attr dest_port (A k attr date Min(A k attr date ) A k attr date + d)} /* Avec s s h = A k attr source_ip h = A k attr dest_ip */ lrs {A k attr idsession ; k N /A k P RED 1 } end if return lrs 51

53 Figure 6.3: Graphe d un scénario complexe 6.11 Exemple d un scénario avancé Le but de cet exemple est de montrer que ce que a été introduit jusqu ici nous permet de détecter des scénarios d attaques avancés. Voici l exemple d un scénario particulier permettant de détecter un attaquant effectuant un scan puis une attaque de type brute force sur le serveur sshd. Par la suite, il va télécharger un fichier depuis l extérieur (potentiellement nuisible) puis lance un second scan sur le réseau interne (le réseau audité) et effectue une autre brute force sur une seconde machine du réseau. Cette fois-ci, il s attaque au serveur f tpd. Enfin il télécharge un dernier fichier à l extérieur et lance une attaque de type DDOS via le protocole http. Nous représentons ce scénario sous forme d un automate (voir figure 6.3). 1. correspond à la (ou les) machines à vérifier: HST. 2. est une attaque de type scan sur l ensemble HST provenant d une IP source IP S. 3. est une session ouverte suite au scan (1) et l attaque par brute force (4) sur l ensemble HST provenant de IP S. 52

54 4. est une attaque de type brute force provenant de IP S à destination de HST. 5. correspond au téléchargement d un fichier provenant de l extérieur depuis la session créé en correspond à un scan sur le réseau privé provenant de HST et de la session IP S. 7. correspond à un brute force suite au scan (6) provenant de HST et de la session IP S sur une machine HST correspond au noeud 7 sur une machine HST correspond à une ouverture de session suite à la brute force vérifier au noeud 7 sur la machine HST est l équivalent du noeud 9 pour la machine HST est un téléchargement d une fichier provenant de l extérieur depuis la session créé en correspond au noeud 11 sur une machine HST est un lancement de DoS sur le port http depuis la session créé en 9 et provenant de HST comportement identique à 13 sur la machine HST 3. Comme on peut le voir, chaque partie de l automate correspond à un algorithme défini dans le framework. L utilisation en commun de ces algorithmes nous permet de détecter des scénarios avancés comme celui présenté ici Apprentissage Le but d apprentissage est l un des objectifs de ces travaux. On vise en effet à partir de classifications d attaques, établies au départ de façon manuelle, d être capable d en construire de nouvelles de façon automatique, avec peu ou pas d intervention humaine. Nous introduisons un algorithme d apprentissage, qui va comparer les automates de session déjà reconstruits. Si l algorithme détecte plus de N automates identiques en faisant abstraction d attribut spécifique à l instance de chaque scénario, alors ce scénario est appris comme une intrusion classifiée. À cette intrusion est assignée une priorité, manuellement automatiquement en se basant sur le calcul de la priorité de chaque alarme composant la session. Par exemples : On ne prendra par en compte l adresse IP source pour l apprentissage. Le passage d une machine A à B i.e. changement de la valeur de l attribut hostname entre A et B, sera équivalent au passage d une machine D à C) Afin de pouvoir comparer nos automates, nous devions introduire un ensemble d outils algorithmiques permettant de les décrire et les manipuler, comme par exemple le fait de comparer des automates afin de pouvoir en déduire leur taux de similarité. Ces outils algorithmiques sont détaillés en annexe A. 53

55 L algorithme suivant apprend de nouveaux automates représentant des attaques, à partir d une base d automates génériques. Cela va permettre par exemple d apprendre toutes les variantes d une attaque connue mais aussi dans certains cas, des attaques totalement nouvelles, suite à une connexion ssh par exemple, ou par la détection dans une session apparemment normale d une opération interdite. L utilisation de PIGA (et SELinux) permet potentiellement d apprendre une grande quantité d attaques encore inconnues. Dans l algorithme qui suit, la fonction de comparaison est représentée par check. Cet algorithme prend en entrée un ensemble d automate automate_set, un automate automate et un ensemble d automate appris ap_automate_set et va retourner un ensemble d automate appris ap_automate_set. Nous commençons par initialiser à 0 la variable count qui va compter le nombre de fois que la fonction de comparaison entre l automate et un des éléments de l ensemble automate_set est valide. Si count dépasse un niveau N alors l automate automate est généralisé et ajouté à l ensemble ap_automate_set. Il représentera le scénario d une intrusion classifiée. Require: automate_set, automate, ap_automate_set Ensure: ap_automate_set count 0 for all auto in automate_set do if check(auto, automate) then count count + 1 end if end for if count > N then ap_automate_set ap_automate_set generalized(automate) end if Une méthode se basant sur le même algorithme et ayant pour but d apprendre les pattern relatives au session locale détecté par PIGA est également utilisé. Nous disposons ainsi d un double niveau de généralisation. D abord, l algorithme va générer des patterns généric qu il peut localiser dans l ensemble des sessions PIGA pour le système d information. Toutes les valeurs spécifiques a l instance vont être supprimées. Cette algorithme est exactement le même que le précédent mais la liste des automates est remplacer par la liste des patterns et l automate de référence est remplacer par une pattern de référence.dans un deuxième temps, l algorithme va effectuer le même résonnement en utilisant le même algorithme mais en réduisant les ensembles d entrées à une machine et/ou un groupe de machine afin de pouvoir détecter de manière plus précise des attaques spécifiques à tel ou tel services et/ou architectures. Nous disposons, de plus, d un algorithme permettant de classifier un automate par rapport à un ensemble d automate généralisé appris. Cet algorithme prend en entrée un ensemble d automata généralisé appris ap_automate_set et un automate à classifier automate. Nous comparons cet automate avec chaque automate ap_automate de l ensemble ap_automate_set, si la comparaison check est valide, alors l automate est classifié par ap_automate. Pour finir, nous retournons une alarme report_alarm_automate contenant le numéro d identification de l automate automate, la priorité de celui-ci et l ensemble des classifications qu il respecte. Require: ap_automate_set, automate Ensure: report_alarm_automate ap_automata_f ind 54

56 priority automate priority classif ication for all ap_automate in ap_automate_set do if check(automate, ap_automate) then ap_automata_f ind priority priority ap_automata priority classification classification U ap_automata id end if end for if ap_automata_f ind then return else report_alarm_automate attrpriority priority report_alarm_automate attrclassification classification report_alarm_automate attrid automata id return report_alarm_automate end if Nous pourrons donc avoir plusieurs classifications pour le même automate, ce qui nous permet de disposer de plusieurs niveaux de classification allant d une classification basique à une classification très spécialisée e.g. un automate de session peut être classifié comme étant une session SSH mais également comme étant une attaque ayant résulter sur la compromission de l accés administrateur root. Pour le moment, l algorithme est basique mais des évolutions futures sont prévues (voir Chapitre 11). 55

57 Chapter 7 Implantation de l architecture de corrélation 7.1 Framework de Corrélation Afin de pouvoir utiliser notre algorithmique de corrélation d une manière optimale, nous avons décidé d exprimer ces algorithmes au sein d agents autonomes Chaque agent (voir figure 5.1) prendra comme valeur d initialisation les variables d entrée nécessaire à la résolution de l algorithme i.e. pour la phase de attack session reconstruction, l agent prendra comme valeur d initialisation le numéro de session (idsession) et le nom de la machine (hostname). Nous réutilisons de manière adaptée au fonctionnement par agent les algorithmes définis au chapitre précédent, en travaillant sur une représentation en automate des attaques. Le formalisme sous forme d automate a été introduit dans l article [RCV07] en n utilisant pas des description de comportement valide mais seulement d intrusion. Ce fonctionnement par agent nous permet de créer un nouveau type d automate décrivant les dépendances entre les agents. Dans cet automate, un noeud représentera un agent et un arc, une dépendance entre deux agents. De plus, un arc prend comme attribut (Sync) une variable permettant de définir le décalage temporel entre les deux ensemble d alarmes retournés par les agents. Un décalage temporel égale a 0 signifie que les deux ensembles d alarmes ont été générées en paralléle i.e. dans le même interval temporel. Ce nouveau type d automate permet d avoir une complexité réduite par rapport à l automate général d attaque tel qu introduit dans la section 6. Ce nouveau type d automate permet également de faciliter la distribution du framework de corrélation. En effet, les dépendances entre les agents sont limitées i.e. uniquement les valeurs d initialisation et de part le fonctionnement même des agents i.e. des programmes indépendants et pouvant facilement se déplacer d une machine à une autre, la distribution est également facilitée. Grâce à cet automate, nous disposons de scénarios de plus haut niveau sans avoir à repenser les bases algorithmiques du framework de corrélation. La comparaison entre les automates s en voit également facilitée grâce à la diminution de la complexité de ces automates. Par conséquent, la procédure d apprentissage s en voit également facilitée. Nous disposons d un certain nombre d agents relatifs à chaque phase de la corrélation, certains sont statiques et incorporés directement dans l IDS et ne seront pas 56

58 représenté sur l automate de dépendances entre les agents : Preprocessing. Creation et assignement du numéro de session. Alert fusion step 1. D autres sont dynamiques et peuvent être appellés un nombre infini de fois de manière sérialisée ou paralléle afin de prendre en compte l ensemble des possibilités de scénarios : Alert fusion step 2 (alertfusion(ma, A)). Thread reconstruction (threadreconstruction(m A, SEQ, idsession, hostname)). Session reconstruction (sessionreconstruction(m T 1, M T 2)). Focus Recognition (focusrecognition(seq)). Link To Session (linkt osession(f ocusrecognition)). Link Back To Session (linkbackt osession(f ocusrecognition)). Island Hopping (island h opping(h1, idsession1, H2)). Alert prioritizing (alertprio(a)). Pattern Recognition (patternrec(m T )). Chaque automate permet d exprimer un scénario d attaque complexe qui pourra être détecté par la combinaison d agents exprimé dans l automate. Sur l automate (voir figure 7.1), nous représentons une attaque se basant sur une combinaison Scan+Brute Force sur une machine puis la création d une session sur celle-ci. Par la suite l attaquant envoi une nouvelle combinaison de Scan+Brute Force sur une deuxième machine du réseau à partir de la première capturée et arrive à créer une nouvelle session sur la deuxième machine. Finalement, la session sur la deuxième machine respecte la pattern de détection locale PHIDS1. Dans cet exemple, chaque intervalle temporel sera supérieur à 0. Le noeud A représente un ensemble d alarmes reliés à une attaque scan sur une machine Hostname. Le noeud B représente un ensemble d alarmes reliés à une attaque brute force sur la machine Hostname. Le noeud C représente un ensemble de numéro de session extrait de l ensemble retourné par le noeud B. Le noeud D représente un ensemble d alarmes représentant une session locale et dont le numéro de session est égal à un des éléments de l ensemble retourné par le noeud C. Le noeud E représente un ensemble d alarmes reliés à une attaque scan sur une machine du réseau surveillé. 57

59 Le noeud F représente un ensemble d alarmes reliés à une attaque brute force sur la même machine que celle de E. Le noeud G représente un ensemble de numéros de session extrait de l ensemble retourné par le noeud F. Le noeud H représente un ensemble d alarmes représentant une session locale et dont le numéro de session est égal à un des éléments de l ensemble retourné par le noeud G. Le noeud I représente le fait que la session locale retournée par H a été classifiée comme faisant partie de la classe PHIDS. L arc A-B représente la condition que l ensemble représenté par le noeud A et B doivent avoir leur attribut source_ip égale et un décalage temporel de X(A,B). L arc B-C représente une condition temporelle de X(B,C). L arc C-D représente une condition temporelle de X(C,D). L arc D-E représente une condition temporelle de X(D,E). L arc E-F représente une condition temporelle de X(E,F). L arc F-G représente une condition temporelle de X(F,G). L arc D-G-H représente une condition temporelle X(D,G,H) et une condition décrivant l égalité du champ id_session entre les noeud G et E. L automate (voir figure 7.2, en fin de chapitre) décrit le parcours du scénario, représenté par l automate 7.1, dans l architecture de corrélation en utilisant plusieurs agents (parfois plusieurs instances du même agent) i.e. l automate présenté au début de cette section. Une partie des tâches des agents peut se dérouler en paralléle alors que d autres sont bloquantes i.e. comme indiqué par les arcs sur l automate. Dans cette automate, un noeud représente une instance d un agent et un arc entre deux noeuds A et B représente une dépendance de B envers A i.e. l agent représenté par le noeud B a besoin de données retourner par l agent A. 7.2 Distributivité Comme expliqué dans les motivations, afin de passer le facteur d échelle et disposer d une puissance de calcul suffisante, il est essentiel de pouvoir bénéficier d un algorithme et d une architecture distribuées. Le modéle de décentralisation, bien que très intéressant et puissant amène des problèmes de séparations de tâches qui sont fortement liées à la sureté du protocole de corrélation et pourrait amener un vecteur d attaque supplémentaire. Nous avons donc voulu conserver cette capacité de distribution mais en l adaptant aux contraintes liées au cluster de calcul disposant de haute sécurité en créant un système distribué dédié à la corrélation et facilement extensible. Nous conservons le point de centralisation de la base de données comme expliqué ci-dessous mais la corrélation est séparée en étapes qui sont réparties via l utilisation d agents sur un 58

60 ensemble de machines en utilisant une architecture distribuée comme expliqué dans l étude ci dessous. Cela nous permet donc d éviter les problémes de concurrence et de bénéficier d une puissance facilement extensible. Bien entendu, le coût est supérieur à celui d un modéle totalement décentralisé où la puissance des machines est réutilisée mais dans le cas de clusters de haute qualité, cette approche est préférable pour éviter tout déterioration des performances. 7.3 Stockage des évènements Afin de maximiser la rapidité, la qualité de corrélation et la pérénnité, nous avons décidé d utiliser une base de données centralisée supportant la répartition de charge et la haute disponibilité et stockant les alarmes récentes et celles impliquées dans le processus de corrélation actuel en mémoire. Cette partie étant critique, nous avons effectué un certain nombre d expérimentations afin de bénéficier de la meilleurs base de donnée disponible pour nos besoins qui nous permette de partir sur les meilleures bases sans avoir à gérer plus finement la partie stockage de la corrélation. 7.4 Expérimentation sur les bases de données: Résumé La solution de corrélation développée se base sur un stockage des alarmes et la recherche sur celles-ci dans une base de données. Afin d avoir la meilleure solution et pouvoir abstraire cette couche dans notre travail, nous devions faire une série d expérimentation. Pour cela, nous avons comparés deux types de stockage i.e. en mémoire et sur le disque dur sur plusieurs solutions de bases de données (MySQL, MySQL-Cluster, DB2, Oracle). MySQL a rapidement montré ses limites sur des gros volumes de données en ne pouvant tout simplement pas gérer des volumes importants avec des requêtes de faible niveau de complexité et cela malgré un stockage en mémoire - ou non - des tables. De plus, le stockage en mémoire est spécifique à chaque table et nous devons créer une deuxième table identique synchronisée sur le disque dur pour pouvoir garder la pérénnité des informations. MySQL-Cluster a comme but de répartir la charge de calcul et de stockage de la base de donnée sur un grand nombre de machines. Mais nos expérimentations nous ont permis de nous rendre compte que MySQL-Cluster pouvait seulement stocker des tables en mémoire et donc nous nous retrouvions avec le même problème que MySQL en plus complexe pour le stockage pérénne. En effet, il faudrait une copie synchronisée locale à chaque machine pour atteindre la pérénnité des données. De plus, l implémentation ne semble pas encore compléte et à cause de flux de données transférées trop importante entre les machines, MySQL-Cluster est plus lent que MySQL. Oracle DataBase semble avoir de bonnes performances et être optimisée pour des gros volumes de données mais son installation et configuration mais aussi une administration trop complexe nous ont conduit à le retirer du processus d expérimentation. Finalement, DB2 lui supporte facilement des gros volumes de données avec des requêtes de forte complexité en s aidant d un stockage en mémoire dynamique, une meilleur optimisation de l utilisation du processeur (et des multiprocesseurs) et de la mémoire mais aussi des options de haute disponibilité et de répartition de charges. De 59

61 plus, il est facilement intégrable (comme l ensemble des autres bases de données) à l implémentation du formalisme grâce à l API de connexion JDBC/ODBC. Le choix s est donc tourné vers DB2 qui nous permet d abstraire totalement la couche de stockage et de requêtage des alarmes en se basant sur un produit efficace et mature. 7.5 Calcul distribué Tout d abord, pourquoi utiliser et programmer des applications qui seront capable de travailler en paralléle. En effet, il est beaucoup plus simple de programmer un logiciel sans parallélisme car il n y a pas de synchronisation entre les différentes parties du code a effectuer ni de problème de partage de données entre les différentes instances. Mais dans le cas où le logiciel demande une forte puissance de calcul et pour améliorer la rapidité du résultat, le but est de tendre le plus possible vers le temps réel pour pouvoir réagir aux attaques le plus rapidement possible. Dans la phase de test, nous avons pu remarquer que la puissance d une machine suffit amplement à calculer une étape de la corrélation mais en utilisant uniquement les alarmes provenant d une machine. Afin de pouvoir facilement passer le facteur d échelle et donc être utilisable sur des grands réseaux avec un nombre de machines importants, il fallait que ce programme soit parallélisé. Nous pouvons paralléliser sur une machine qui supporte la gestion simultanée de plusieurs threads mais la limite de la puissance totale de la machine est rapidement atteinte. Cela permet tout de même déjà de pouvoir bénéficier de la puissance des machines multiprocesseur (SMP). Nous avons donc commencé par adapter notre programme vers une architecture supportant les threads. Dans un second temps, nous avons pu nous rendre compte que la puissance d une seule machine ne serait jamais suffisante et qu il fallait utiliser plusieurs machines en simultané. Pour cela, nous avons comparé un certain nombre de produits le permettant (voir section 8.2). Nos expérimentations nous ont permis de nous diriger vers une grille de calcul permettant de créer des agents représentant les différentes étapes de la corrélation (voir figure 7.3, en fin de chapitre). Ces agents vont être lancés à la demande et répartis sur une grille de calcul (voir figure 7.4, en fin de chapitre), le tout depuis un contrôleur centralisé. La répartition des agents se fait sur la grille en se basant sur des algorithmes proches de ceux de load balancing afin de maximiser l utilisation des machines. Cela permet d optimiser la reconstruction du graphe en se basant sur l algorithmique de corrélation propre à chaque agent (chaque agent a à sa charge une étape de corrélation). De plus, pour certaines étapes demandant de grandes quantités de puissances, l algorithme doit être capable de redécouper le graphe pour partager le calcul d une étape, sur plusieurs machines tout en minimisant les problèmes de concurrence entre les deux sous-arbres. Grâce à la puissance du framework de grille utilisé, nous sommes capable de charger dynamiquement, depuis des clients, les agents sans besoin de les copier physiquement sur chaque machine de la grille. 7.6 PIGA: Les nouvelles fonctionnalités Afin de permettre et de faciliter la corrélation en utilisant les alarmes issues de PIGA, il a fallu faire un certain nombre de modification que voici. 60

62 7.6.1 Les timestamps Dans sa version non modifiée, les timestamps de PIGA se limitaient au jour du mois, le mois, l heure, la minute et la seconde à laquelle avait été levée l alarme. Nous avons donc ajouté le support de l année en dynamique permettant de ne pas avoir d aberration de calcul lorsqu on passe d une année à l autre. De plus, dans le cadre de la corrélation, la seconde n est pas une unité de temps suffisament représentative. En effet, dans certains cas, e.g. les DoS, plusieurs centaines d alarmes peuvent être levées en moins d une seconde. Il fallait donc une unité plus précise. Hors le timestamp utilisé par PIGA est issu de celui fournit par syslog (syslog-ng) qui ne gére pas non plus les millisecondes. Mais un numéro de série attribué à chaque entrée dans le syslog est fourni par le kernel, ce dernier est en partie composé d un timestamp qui nous a permis d extraire l année et la milliseconde de chaque alarme et de les utiliser dans PIGA Les traces réseaux La première version de PIGA ne prenait pas en compte les traces SELinux comportant des informations réseaux. Dans notre cas, il fallait ajouter ce support afin de pouvoir lier des alarmes IDS réseaux avec celles provenant d IDS système mais également pouvoir lier les alarmes systèmes d une machine à une autre (par exemple, pour détecter un scénario de island-hopping). Grâce à la modularité de PIGA et la puissance Java, il a été possible, en étendant certaines classes et en ajoutant des modéles d expressions régulières de parsing des fichiers de logs spécifiques aux traces réseaux SELinux, de supporter l ensemble des évènements réseaux et de les lier à l arbre des processus du système représenté dans PIGA Les numéros de session PIGA permet en utilisant les alarmes SELinux de recréer la totalité de l arbre de processus (voir figure 7.5, en fin de chapitre). Pour tracer une session d attaque, il suffit donc de trouver l événement delictueux d entrée et marquer toute la partie de l arbre l ayant comme racine. En étendant certaines classes de PIGA, nous avons pu ajouter le support des sessions directement dans l IDS afin d avoir une précision maximum. La relative simplicitée de la partie de code traitant des sessions permet de ne pas influer dans la rapidité d éxecution de PIGA L injection dans une base de donnée Afin de pouvoir corréler les alarmes traitées par PIGA, sans avoir à le modifier profondément ni trop pénaliser efficacité, il était plus judicieux d insérer ces alarmes, une fois pre-traitées, dans une base de donnée. Il nous est apparu rapidement que le nombre d alarmes générées par PIGA pouvait monter à plusieurs centaines en une seconde et qu avant d insérer ces derniers dans une base de donnée, il était préférable, pour ne pas augmenter les latences dûes aux réseaux et aux temps de traitement de requête SQL, de faire une première phase d agrégation interne à PIGA. En utilisant une régle d agrégation (voir section 6), nous pouvons rassembler un nombre conséquent d alarmes, afin de les insérer en une seule requête SQL. Ce pre-traitement est relativement faible en complexité mais demande une place mémoire assez importante. Afin de limiter cette utilisation, nous avons restraint la taille des meta-alarmes. De plus, 61

63 nous avons intégré des bornes de temps pour ces méta-alarmes qui contrairement aux alarmes simples ne se déroulent pas à une date précise mais sur un interval de temps. 62

64 Hostname = ScHost B FR(SEQ,"SCAN") A Sync = X(A,B) A.source_IP = B.source_IP FR(SEQ,"BruteForce") Sync = X(B,C) C linktosession(b.idsession) Sync = X(C,D) D E Sync = X(D,E) TR(MA,SEQ,C.idsession) FR(SEQ,"SCAN") Sync = X(E,F) F FR(SEQ,"BruteForce") Sync = X(F,G) G linkbacktosession(b.idsession) G.id_session E D.id_session Sync = X(G,D,H) TR(MA,SEQ,G.idsession) H Sync = X(H,I) Pattern(MT,PHIDS1) I Figure 7.1: Automate d un scénario complexe 63

65 AlertPrioritizing AlertFusion FocusRecognition FocusRecognition linktosession ThreadReconstruction FocusRecognition FocusRecognition IslandHopping ThreadReconstruction PatternRecognition AlertFusion linkbacktosession Figure 7.2: Déroulement du processus de corrélation ThreadReconstruction AlertFusion linkbacktosession IslandHopping Database AlertPrioritizing FocusRecognition PatternRecognition linktosession SessionReconstruction Figure 7.3: Ensemble des agents. 64

66 Node Node IslandHopping linkbacktosession ThreadReconstruction AlertPrioritizing PatternRecognition AlertFusion Database Node Node FocusRecognition PatternRecognition linktosession SessionReconstruction SessionReconstruction Figure 7.4: Exemple de fonctionnement de la grille et des agents. Figure 7.5: PIGA et la gestion des sessions 65

67 Chapter 8 Optimisation de l architecture de corrélation Les auteurs, comme Ning ( [NX02]) ayant produit les travaux parmi les plus avancés en corrélation se sont heurtés aux limitations de la gestion mémoire des données pendant la corrélation, notamment lorsque la corrélation opère sur des données brutes (forcément nombreuses) provenant de plusieurs outils générant des alertes ou des rapports, ou opérant sur de longues plages temporelles par exemple. Ce problème a été évoqué en Ce problème n est pas anodin, car en pratique, il peut tout simplement empêcher d effectuer des requêtes de corrélation, parfois dont le résultat semble simple, mais dont le nombre de données nécessaires pour le produire est important. Dans ce chapitre nous nous proposons d y apporter de réelles solutions, tirant parti des avancées technologiques dans les domaines de Bases de Données et des langages de programmation. Dans ce cadre, notre propos a d abord été très pragmatique : utiliser l existant, à savoir utiliser l outil de gestion de sécurité OSSIM, qui lui-même se fonde sur MySQL. Nous avons donc étudié comment optimiser le fonctionnement de MySQL car rapidement nous nous confronté à ses limites : les requêtes de reconstruction de session par corrélation ne terminaient pas. Nous nous sommes penché sur des solutions de SGBD plus avancées, telles que DB2 et avons constaté de nettes améliorations en terme de performance de calcul et de gestion mémoire. Mais rapidement, la taille des données brutes, particulièrement utilisées toujours dans le cadre des reconstructions de sessions, s est avérée être un facteur bloquant. Disposant d un cluster de machines, nous avons alors étudié les différentes solutions permettant d exploiter au mieux ces différentes machines, et avons finalement convergé par la mise en place d une grille de calcul en java permettant de répartir la charge et de partager la mémoire des machines de façon dynamique et très souple (grâce à la fonction PXE) avant d aboutir à une solution utilisant des technologies récentes dans le domaine de la mémoire distribuée avancées par Oracle par exemple. L architecture que nous proposons au final permet de faire nettement avancer la technologie classiquement utilisée dans les approches de détection d intrusion par corrélation puisqu elle permet d étendre à l infini puissance de calcul, de stockage et de mémoire des techniques de corrélation utilisant des Bases de Données. Dans la section qui suit, nous commençons par introduire nos premières expérimen- 66

68 tations sur les Bases de Données qui nous ont ensuite conduit à creuser le problème de la parallélisation et de la distribution des ressources, que nous abordons dans la section suivante. 8.1 Expérimentation sur les bases de données MySQL: Introduction La solution de corrélation qui a été développée se base sur un stockage des alarmes et la recherche de celles-ci dans une base de données SQL. L architecture existante se basant sur divers produits reliés à MySQL, il a été décidé dans un premier temps de continuer à utiliser celui-ci malgré certains problèmes de stabilités. Puis devant le nombre de problème, de nouveaux produits ont été essayés et comparés pour notre utilisation MySQL: Stockage en mémoire Afin d optimiser la rapidité des recherches mais également des insertions, nous avons décidé d utiliser une table temporaire qui va stocker les nouvelles alarmes pas encore traiter ou en cours de traitement. Cette table qui va être beaucoup soliciter est placée en mémoire vive (RAM) afin de bénéficier de temps accès amélioré mais cela implique également de disposer de suffisamenent de RAM libre afin de pouvoir stocker tous les évènements qui arrivent. En effet, quand une table en mémoire utilise toute la mémoire disponible de nouvelles insertions vont échouées et les alarmes seront donc perdues. On peut donc imaginer un pirate qui va flooder les IDS (en faisant des scans par exemple) afin de perturber le système de détection et lancer sa véritable attaque dans le but de la cacher. Il faut donc pouvoir faire un compromis entre rapidité et sécurité du système afin d avoir une base la plus rapide possible mais qui ne perd aucunes alarmes MySQL: Cluster Le stockage en RAM nous apporte de la rapidité mais nous sommes toujours limités à la puissance et la place mémoire disponible d une machine qui ne permet pas de passer le facteur d échelle. Il nous fallait donc une méthode qui permettait de prendre en compte un plus grand volume de données qu une seule machine peut gérer. Nous nous sommes donc dirigés vers les bases de données répartis et plus particulièrement MySQL Cluster. MySQL cluster est composé de 3 services: Manager qui va gérer la communication entre les autres services, va gérer la répartition des insertions, des requêtes, etc et qui va synchroniser les différents serveurs entre eux. C est le point central du cluster. Stockage qui est chargé de stocker les tables. On peut en avoir un ou plusieurs qui permet de répartir les tables mais également de mettre en place un système redondant résistant aux pannes. Les bases de stockage sont synchronisées entre elles. SQL qui va effectuer les requêtes SQL et renvoyer les résultats. Bien entendu, chaque service peut être présent entre 1 et n fois dans le cluster et la charge sera réparti entre les différentes instances de chaque service. 67

69 Local Cluster real 0m0.082s 0m1.737s user 0m0.032s 0m0.044s sys 0m0.024s 0m0.004s Figure 8.1: Création d une nouvelle table Local Cluster real 0m1.646s 0m14.534s user 0m0.228s 0m0.236s sys 0m0.024s 0m0.024s Figure 8.2: Insertion de 5000 lignes dans la table Le principal problème vient du faite que les tables qui sont gérées par MySQL Cluster sont uniquement stockées en mémoire et on ne peut donc pas stocker l intégralité de la base dans MySQL Cluster, on ne va utiliser la puissance du cluster uniquement sur des tables qui sont stocker en mémoire sur lesquels on fait beaucoup de requêtes (que ce soit de la recherche ou des insertions). En conclusion, on peut dire que MySQL cluster est intéressant pour avoir une forte puissance et un système résistant aux pannes pour gérer l arrivée et le traitement des nouvelles alarmes mais le stockage ne doit pas être effectué par une telle solution mais dans des tables classiques stockées sur le disque dur (et donc beaucoup plus lentes) MySQL Cluster: retour sur expérience Tout d abord, l installation et la configuration de MySQL Cluster est facile, en effet, il suffit de recompiler depuis les sources MySQL avec le flag cluster afin de permettre la création des binaires nécessaires. Ensuite, il ne faut ajouter que quelques lignes dans le fichier de configuration de MySQL afin que chaque machine agissent en tant que membre du cluster MySQL. Ensuite l interface d administration (ndb_mgm) est relativement intuitive et permet d avoir un bon aperçu du cluster à tout moment. Nous avons effectués nos tests avec 4 machines à base de Pentium II 400Mhz avec 256Mo de RAM. Une machine étant utilisé en tant que manager, 1 en stockage, 1 en SQL et 1 en SQL et stockage. Afin d effectuer nos tests, nous avons fait un certain nombre d essai en se basant sur la rapidité a effectué des requêtes relativement simple tel que INSERT, CREATE et SELECT et de voir le temps de réaction et d éxecution de celles-ci. Afin que la rapidité d affichage ne soit pas pris en compte et que uniquement le temps de traitement et de communication le soit, nous rediriger les résultats vers /dev/null. En conclusion, on peut donc dire que malgré une architecture promettante les gains de performance (voir figures 8.1, 8.2, 8.3 sont encore loin et il faudra attendre que le produit arrive à maturation pour espèrer de réel gain de performance. 68

70 Local Cluster real 0m10.490s 1m21.455s user 0m4.808s 0m4.668s sys 0m0.348s 0m0.304s Figure 8.3: 104 recherches en utilisant 2 bornes sur l ensemble des colonnes Un successeur à MySQL Après avoir commencer les tests d utilisation d une base de donnée pour la corrélation, je me suis vite rendu compte que MySQL n allait pas pouvoir supporter le nombre d alerte de PIGA mais également des requêtes un peu compliquées. De plus, comme expliqué ci-dessus, MySQL ne permet pas d être utilisé sur un cluster (ou sans réel intérêt). Oracle 10g J ai d abord voulu essayer Oracle qui semblait être un produit très complet et particulièrement bien fini. Mais mon système tournant sous GNU/Linux Gentoo et malgré une compabilité GNU/Linux, il a été très difficile voir impossible d installer Oracle sur une distribution qui n est pas certifiée par Oracle et seules des distributions payantes ont ce support. Malgré donc un nombre de fonction et des performances sur papier très intéressante, il a été décidé d abandonner Oracle. DB2 Le deuxième grand concurrent dans le monde des bases de données est DB2 développé par IBM. Il est également compatible sous GNU/Linux mais ne propose pas un support uniquement sur certaines distributions. Contrairement à Oracle, son installation a été très aisé sur la machine de test malgré la demande de l installation de la JVM de IBM. La configuration ainsi que le lancement sont relativement simple et les interfaces de contrôle et d administration en Java sont clairs et completes (il faut utiliser la JVM IBM et ne pas utiliser Beryl pour que cela marche). Par contre, leur utilitaire de migration de base de données (MTK) n est pas très efficace, la conversion n est pas aisée et demande pour être compléte de finir en allant chercher des informations ressorti dans les fichiers de log de ce programme. Malgré ce petit problème de migration, l installation/configuration de DB2 est aisée presque autant de MySQL mais support en plus un nombre impressionnant de fonctionnalité permettant l utilisation sur cluster mais également la haute disponibilité. DB2 vs MySQL Tout d abord, malgré les outils de migration, la conversion des tables marche relativement mal et demande un nombre conséquent de modification dans le fichier SQL de MySQL avant qu il soit compatible avec l outil de migration qui va lui même génerer le fichier SQL compatible DB2. Il est donc conseiller de faire la migration des tables à la main. Au niveau des INSERT, le programme de migration marche relativement bien 69

71 MySQL DB2 real 161m11.421s 185m34.195s user 167m48.757s 158m19.854s sys 2m19.185s 2m9.124s Figure 8.4: environ INSERT dont certains contenant des champs de type TEXT/CLOB. MySQL DB2 real 1m11.047s 3m42.442s user 0m37.262s 0m13.045s sys 0m2.936s 0m16.437s Figure 8.5: select de l ensemble des champs d une table de lignes contenant 1Go de données. mais demande un lancement à la main en dehors du programme pour que la migration soit compléte. Afin de partir sur une base relativement égale, aucune optimisation n a été faite que ce soit sous MySQL ou DB2 et uniquement des fonctions basiques ont été utilisés. Les requêtes avancées portant principalement sur des champs integer, l utilisation d index n était pas utile. Le but étant de comparer les performances de MySQL et DB2 pour l utilisation dans le cadre de mon stage, j ai décidé d implémenter les méthodes permettant à PIGA d utiliser MySQL ou DB2 comme backend pour stocker les alertes (PIGA tournant en Java, l utilisation de JDBC a permis cette compatibilité sans avoir à réécrire des parties de code mais demande quelques changements tout de même comme le délimiteur ; qui ne doit pas être présent à la fin d une ligne seule en DB2 mais qui doit l être en MySQL). Le lancement de PIGA sur 3 mois (Janvier / Février / Mars 2007) de logs d une machine (www) génére une table contenant plus de INSERT et une autre en contenant Comme le montre le tableau 8.4, on peut voir que MySQL est légèrement plus rapide dans l absolu que DB2 sur les INSERT. Mais en regardant de plus prêt, on peut voir que cette différence de temps est sûrement dû à un lag supplémentaire dans la couche réseau de DB2 (ou dans l intéraction DB2/Java via la JDBC) car l utilisation réel du processeur est plus faible avec DB2. De plus, ce dernier utilise des OID pour chaque nouvelle ligne insérée dans la table, il va falloir les génerer la première fois ce qui prend plus de temps. Ici aussi 8.5, MySQL est plus rapide mais en regardant le temps d utilisation processeur, on peut se rendre compte que la différence est relativement faible. MySQL prouve ici qu il est clairement optimiser pour la lecture de données brute. Comme on peut le remarquer dans le tableau 8.6 utilisant la requête 3, dès qu on utilise une requête un peu plus avancé (ici une requête permettant de lié les hyper- 1 TEXT est le type correspondant à un champ de texte de grande taille non sensible à la case 2 CLOB est l équivalent de TEXT en DB2 3 SELECT DIST INCT nha.idsession F ROM new_hyperalert AS nha, new_sequence AS ns W HERE nha.idsession = ns.idsession ORDER BY idsession 70

72 MySQL DB2 real N/A 3m42.442s user N/A 0m13.045s sys N/A 0m16.437s Figure 8.6: select sur 2 tables ( x ) alarmes et les séquences provenant des mêmes sessions tout en éliminant des doublons et en classant les résultats) MySQL s effondre totalement alors que DB2 s en sort avec brio grâce à son optimiseur de requête. Je ne donne pas de résultat pour MySQL en effet après 1h en utilisant 100% du CPU et une grande partie de la RAM, je n ai pas eu le résultat. MySQL semble en effet à ne pas réussir à effectuer des requêtes relativement simple sur une grosse masse de données particulièrement au niveau des jointures entre 2 grosses tables hors c est typiquement le genre de requête qui sont particulièrement utilisé en corrélation. En arrivant à ce constat mais également devant le retour sur expérience du serveur MySQL tournant sur le honeypot (ce dernier perd énormément de données mais également s arrête régulièrement), il a été décidé d abandonner MySQL pour passer à DB2. De plus, le support au niveau des langages de programmation (Java et Python dans mon cas) est relativement équivalent et même si la communauté derrière DB2 est beaucoup plus faible, la qualité de finission mais également de white paper disponible via le site d IBM compense. 8.2 Expérimentation sur les calculs parallèles Introduction Tout d abord, pourquoi utiliser et programmer des applications qui seront capable de travailler en parralléle, en effet, il est beaucoup plus simple de programmer un logiciel sans parallélisme car il n y a pas de synchronisation entre les différentes parties du code a effectué ni de problème de partage de données entre les différentes instances. Mais dans le cas où le logiciel demande une forte puissance de calcul mais également pour améliorer la rapidité du résultat (en effet, le but est de tendre le plus possible vers le temps réel pour pouvoir réagir aux attaques le plus rapidement possible). Dans la phase de test, j ai pu remarquer que la puissance d une machine suffit emplement à calculer une étape de la corrélation mais en utilisant uniquement les alertes provenant d une machine. Afin de pouvoir facilement passer le facteur d échelle et donc être utilisable sur des grands réseaux avec un nombre de machines importants, il fallait que ce programme soit parallélisé. On peut parallélisé sur une machine qui supporte la gestion simultanée de plusieurs threads mais la limite de la puissance totale de la machine est relativement rapidement arrivé mais cela permet déjà de pouvoir bénéficier de la puissance des machines multiprocesseur (SMP). J ai donc commencé par adapter mon programme vers une architecture supportant les threads. Dans un second temps, j ai pu me rendre compte que la puissance d une seule machine ne serait jamais suffisante et qu il fallait utiliser plusieurs machines en simultané. Pour cela, j ai comparé un certain nombre de produits le permettant. 71

73 Pour finir, j ai choisi un système à base de grille de calcul et développé une version du logiciel de corrélation supportant ce type d architecture Thread La première étape a permis de facilement supporter les machines de type SMP. Pour cela, j ai implémenter le support des threads dans le logiciel de corrélation. Cela permet de lancer simultanément plusieurs taches qui vont tourner en paralléle sur la machine. Par exemple, pour l étape Thread Reconstruction de la corrélation, on peut disserner 2 tâches: connaître le numéro de la dernière session (le plus grand) et reconstruire les sessions. La tâche de mise à jour du numéro max de session doit tourner régulièrement, ne demande pas beaucoup de puissance mais est très importante pour pouvoir calculer au fur et à mesure les nouvelles sessions découvertes. La tâche de reconstruction des sessions est elle beaucoup plus lourd et demande un temps de calcul plus élevé. Grâce à l utilisation des threads, le logiciel est capable de reconstruire plusieurs sessions en même temps afin d améliorer la rapidité. Bien entendu, l utilisation des Threads améne de nouvelles contraintes comme la synchronisation entre ceux-ci et les possibles collisions dans la modification des variables communes. Il a donc fallu créer des threads avec des parties de codes uniquement accessible par un seul à la fois en écriture (en se basant sur une technique similaire au sémaphore) pour éviter des modifications sauvages des variables communes. Cela permet donc à plusieurs threads de reconstruction de session de travailler ensemble afin d optimiser la rapidité en fonction du nombre de thread executables en paralléle par le processeur. Mais l utilisation de thread touche sa limite avec la puissance de la machine sur lequel le programme tourne, pour pouvoir passer le facteur d échelle, il fallait donc pouvoir répartir le calcul sur plusieurs machines Architecture Distribuée Introduction Comme expliqué ci-dessus, afin de pouvoir passer le facteur d échelle, il était obligatoire de passer à une architecture distribuée. Il existe plusieurs techniques permettant la distribution, la section suivante explique le fonctionnement, les tests effectués, les points forts et faibles de chacune d entre elles. openmosix De nombreuses publications ont été écrite sur openmosix (cf. [Ba]). Le fonctionnement de cette architecture est de pouvoir migrer un processus lancé sur une machine vers une autre machine qui dispose de plus de puissances disponible. Le kernel va donc se charger de migrer le processus et son espace mémoire vers une autre machine où l éxecution continuera. openmosix est une solution opensource et gratuite mais malheuresement elle manque d un support conséquent pour les buts qu elle s est fixée. Le passage récent vers les kernel 2.6.x a très fortement ralenti le développement et des morceaux entiers du programme ont du être réécris. Même en utilisant les dernières versions, les migrations de processus ne sont toujours pas automatique et on doit forcer la migration en injectant des valeurs directement dans certains fichiers du /proc correspondant au processus. De 72

74 plus, la migration marche uniquement pour des petites tâches et la liaison avec la machine qui a lancé est rompu, le processus fini donc en zombie sur la machine distante et la machine qui avait lancé le processus est bloqué en attente. Malgré des fonctions très intéressantes, openmosix n est pas prêt pour un fonctionnement dans un univers réel pour le moment. Kerrighed Kerrighed se base sur le même type d architecture de openmosix. Il est développé en collaboration avec l INRIA. Mais il souffre des même problèmes de maturité que openmosix et même si il est très prometteur, il n est pas fonctionnel pour le moment. MPI-Like MPI est une technique de parralélisation très reconnu et implémenter dans de nombreux langages ([ANL]). Des librairies MPI existent en Java comme: JCluster qui se base sur les principes de MPI. JParss qui se base également sur MPI mais avec une sécurité accrue au niveau de l échange d information entre les machines et une auto-optimisation des tailles de fenêtres TCP afin d améliorer la rapidité de transition des informations entre les machines. De nombreuses autres implémentations existent (malheuresement elles sont souvent des proofs of concept et pas réellement fonctionnel dans une utilisation de tous les jours). Le problème majeur de ce genre d implémentation est la répartition à la volée du code sur l ensemble des machines mais également le besoin de synchronisation très forte et précise entre les différents processus. Mais la robusté et la qualité des librairies MPI n est plus à prouvée. Grid Le principe d une grille de calcul est d utiliser la puissance non utilisée sur les machines afin d effectuer des gros calculs. Il existe un certain nombre d implémentation de grille en Java qui en sont souvent au commencement ou ne sont que des proof of concept ([LMGF05]). L implémentation JPPF (Java Parallel Processing Framework) permet de mettre en place relativement facilement une architecture de grille pour des programmes Java (voir la figure 8.7). De plus cette architecture peut être redondante et se base sur un réseau peer to peer avec un ou plusieurs maitres (driver) liés à un ou plusieurs noeuds (node) permettant donc de limiter les points de fautes comme monté dans la figure 8.8. JPPF est une grid en Java qui va permettre de bénéficier des intérêts d une grille en y alliant la puissance de Java (indépendant du système d exploitation et de la machine utilisée), de plus, il est sous license opensource LGPL. JPPF a été construit en intégrant des capacités de fail-over et de récupération dans chaque composant permettant de minimiser les problèmes de fautes. De plus, grâce à des capacités de transfère dynamique des classes, il n y a pas besoin de déployer chaque logiciel sur chaque noeud de la grille, ils sont automatiquement transférer à la demande (voir la figure 8.9). Des outils sont disponible pour la surveillance et l administration 73

75 Figure 8.7: Le Framework JPPF de la grille. De plus, l utilisation du Java permet de bénéficier des restrictions de sécurité implémenté dans ses librairies. Grâce à des fonctions de load balancing et une optimisation de l utilisation de la bande passante, JPPF peut s adapter à chaque réseau (voir la figure 8.10). Conclusion J ai donc tourné mon choix vers JPPF que ce soit pour sa puissance, sa flexibilité ou sa simplicité d utilisation par rapport aux autres solutions exposés dans cette section Mise en place d une grille Java Afin de pouvoir utiliser le système de grille Java, il fallait une architecture permettant facilement d ajouter à la demande de nouveaux noeuds afin de répondre aux besoins de puissances de calculs. C est dans cette axe que j ai décidé de mettre en place un système permettant de démarrer une machine totalement configurer pour la grille sans avoir besoin d une quelconque installation mais également en pouvant facilement mettre à jour l ensemble des noeuds de la grille et donc pouvoir limiter l administration. Il a donc été mis en place un serveur permettant à n importe quel machine disposant d une carte réseau bénéficiant de la technologie PXE (qui permet de démarrer un système d exploitation en utilisant un bootloader réseau) de démarrer sans aucune installation (et également sans le besoin d un disque dur). En effet, avec l aide de PXE et d un serveur tftp (permettant de récupèrer le bootloader mais également le noyau), on est capable de lancer un système d exploitation complet. En y additionnant les fonctions d autoconfiguration sur IP du noyau Linux et un serveur DHCP, on a été capable de mettre en place, un système démarrant sans aucune configuration locale et chargant 74

76 Figure 8.8: Architecture de JPPF le système depuis le réseau en se basant sur les informations qu ils lui sont fourni par le serveur DHCP. Afin de limiter l administration mais aussi le besoin de transfèrer le système d exploitation sur chaque machine, nous avons mis en place un serveur NFS et chaque noeud est configuré pour utiliser comme système de fichier racine une partition NFS en lecture seule. Bien entendu, certaines parties du systèmes de fichiers sont assessibles en écriture comme le home directory via le NFS mais également des systèmes de fichiers temporaires (chargés en RAM) pour les répertoires /tmp et certaines parties du répertoire /var. Grâce à ce système et un script de lancement automatique de JPPF, nous avons été capable de mettre en place une architecture où il suffit de démarrer une machine via PXE pour que celle ci joint automatiquement la grille de calcul Programmation Java sur une grille L un des problèmes principals de la programmation sur une grille de calcul est de pouvoir partager des valeurs mais également d interdire tous les problèmes liés à la concurrence. Dans mon cas, le but premier était de pouvoir répartir la reconstruction des sessions sur plusieurs machines afin de pouvoir passer le facteur d échelle et permettre un calcul se rapprochant au maximum du temps réel. On peut voir dans le tableau 8.11 que le temps d exécution diminue bien avec le nombre de noeud ajouté même si la complexité et le nombre de données transférer sur le réseau augmente (le programme de multiplication n étant pas très complexe, la rapidité est quelque peu biaisée dans cette exemple) Benchmark de la grille Java La grille de calcul n est pas utile dans le cas où on va se limiter à un seul noeud, en effet, la latence apportée par les transferts réseaux vont faire perdre de la rapidité d execution 75

77 Figure 8.9: Fonctionnement du chargement dynamique des classes dans JPPF par rapport à une version tournant sur un seul poste. Le tableau suivant montre la montée de la puissance de calcul avec la montée du nombre de node disponible dans la grille de calcul mais également la comparaison avec le fonctionnement avec une machine seule. Ce benchmark a été fait en utilisant un programme de multiplication de matrice Un cache distribué: Oracle Coherence Nous avons étudier Oracle Coherence, qui est une implémentation en Java de ce type de cache distribué. En plus des fonctions de base, Oracle Coherence amène des capacités de prédiction permettant de charger des informations reliées à celle en mémoire avant même qu elles soient demandées. Grâce à une redondance des données, ce cache supporte des fonctions de fail-over et de haute disponibilité mais également de load balancing pour répartir la charge au sein même de ce cache [Whi07]. Oracle Coherence permet de garder à jour ce cache vis à vis de la base de donnée, en utilisant un observateur qui va surveillé la base de donnée et qui va effectuer des modifications sur le cache ou sur la BD en utilisant une méthode PUSH (i.e. la mise à jour est poussée et ce n est pas au système de la demander). Nous nous retrouvons avec le problème d occupation mémoire, en effet, ce cache va être stocké en mémoire et il faut donc penser à optimiser cette occupation RAM afin de ne pas en dépasser la capacité. L utilisation du cache amène de plus des problèmes supplémentaires de risque de latence réseau (synchronisation, répartition, accés au cache) et surtout, le temps que prend la transformation de données contenu dans la BD vers une représentation qui est stockable dans le cache. Afin de ne pas surcharger les applications (i.e. les agents de corrélation) avec les 76

78 Figure 8.10: Communication entre les composants de JPPF temps de traitement et autres provoqués par l utilisation de cache, Oracle Coherence permet d utiliser des agents dédiés à la manipulation du cache. Ce qui amène des fonctions de cache through i.e. une application demande une donnée dans le cache, si elle y est l agent va lui donner sinon l agent va charger la donnée depuis la BD dans le cache. Cet agent va également essayer d optimiser les intéractions entre le cache et la base de donnée en ne réplicant qu une partie des changements e.g. si une donnée change 5 fois de valeurs dans un interval de temps faible, uniquement la 5ème valeur sera appliqué à la variable dans la base de donnée. Total Execution Transport 1D 1N 1C 1min 1sec D 1N 2C 1min 1sec D 2N 3C 51sec D 3N 4C 49sec D 4N 5C 48sec D 5N 6C 48sec D 6N 7C 48sec D 7N 7C 48sec Figure 8.11: Benchmark sur JPPF en utilisant une multiplication de matrice (D = Driver, N = Node, C = Computer). 77

79 Chapter 9 Expérimentations 9.1 HoneyPot Toutes les expérimentations ont été effectuées en se basant sur les alarmes générées par un honeypot à haute interaction. Comme la figure 9.1 le représente, le honeypot est composé d un honeywall qui est chargé de limiter la taille et le nombre de flux provenant du honeypot (et donc éviter que des attaques réelles ne soient effectuées depuis celui-ci) et dispose d une interface permettant de faire une copie de l ensemble du traffic qui circulent entre le honeypot et Internet (en utilisant un NIDS dans notre cas Snort). Le honeypot comporte également un serveur composé de quatre machines virtuelles. Ces quatres machines sont le coeur du HoneyPot. C est sur ces dernières que se déroulent les intrusions. Deux machines fonctionnent avec un SELinux en mode permissif (les politiques de sécurité sont activés, mais aucune interaction n est bloquée) ce qui nous permet d autoriser plus de scénarios d intrusion. Les deux autres machines virtuelles fonctionnent avec SELinux de manière complète (enforced) où l ensemble du système doit respecter la politique de sécurité. Chaque machine virtuelle dispose d agents OSSIM 1 et de HIDS (OSIRIS et PIGA). L ensemble des logs des machines sont rassemblés sur la machine hôte (VMWare Server). Ce sont ces logs (et spécifiquement ceux des alarmes SELinux) qui sont utilisés par PIGA. Le Honeypot comporte un logger qui est la machine qui reçoit l ensemble des alarmes générées par le honeypot et qui les regroupent dans une base de donnée. Finalement, nous diposons également d une console d administration nous permettant aussi bien de surveiller les interfaces de monitoring graphique comme OSSIM que d administrer les machines virtuelles via VMWare Server. Actuellement, nous avons reçu uniquement des attaques très standart et nous manquons d attaques distribuées réelles. En effet, afin de pouvoir expérimenter nos algorithmes, nous avons du génerer nous même des sessions d attaques distribuées sur le honeypot. 1 OSSIM est un framework de centralisation d alarmes: 78

80 Renater HoneyWall VMWare Server Console d administration Gentoo SELinux Debian SELinux Gentoo Debian Logger (OSSIM) Database Figure 9.1: Architecture du HoneyPot 9.2 Etude manuelle Cette phase d expérimentation a commencé dès le début de l étude. Nous avons commencé par observer le flux d alarmes générées par PIGA et reconstruire à la main des sessions. Cette reconstruction nous a permis de nous faire une première idée sur les sessions d intrusions qui ont été effectuées sur le honeypot mais également le type et les particularité de celles-ci. Ces observations ont été essentielles par la suite et particulièrement pour l écriture du formalisme qui est basé sur ces observations manuelles que nous avons fait sur des intrusions relevées par le honeypot. Le honeypot est en fonctionnement depuis plusieurs mois, ce qui nous permet d avoir une base d alarmes PIGA assez importante et de pouvoir détecter plusieurs scénarios d attaques. PIGA supporte des flux d alarmes important sans ralentissement notable de la machine et une perte d alarmes proche de 0. Nous perdons un certain nombre d alarmes à cause de fonction bas niveau d écriture de fichier interne au kernel Linux et plus particulièrement le module SELinux qui méne Syslog à génerer des alarmes corrompus. 79

81 9.3 Framework Concernant le framework, nous avons pu expérimenter de manière indépendante puis lié les agents le composant Preprocessing L étape de preprocessing nous a permis d éliminer effectivement les alarmes mal formées par syslog. En effet, nous avons remarqué que la fonction d écriture de log de SELinux a une tendance à générer des alarmes mal formées en cas d augmentation de la charge sur la machine. A la fin de cette étape, nous avons uniquement des alarmes dont l ensemble des attributs est correctement assigné Alert Fusion L étape d Alert fusion réalise un travail extrêmement conséquent en regroupant un grand nombre d alarme en méta-alarme. Nous avons dû limiter le nombre d alarmes agrégées ensemble pour éviter la surcharge de PIGA et le manque de mémoire (il dépasse la taille mémoire qui lui est alloué en voulant y stocker un trop grand nombre d alarmes). Mais en limitant cette étape à des ensembles d une certaine taille (en relation avec la place mémoire allouée à PIGA (e.g. avec 60Mo de RAM) nous pouvons reconstruire des méta-alarmes qui peuvent être composées de jusqu à 1500 alarmes), nous avons pu réduire énormément le volume des alarmes (et donc le nombre d interaction avec la base de donnée), en effet, nous passons de plus de alarmes uniques à environ méta-alarmes Numéro de session L étape de création et d assignement du numéro de session nous permet effectivement d affecter des numéros de session aux alarmes. Dans notre cas, nous détectons environ 1500 sessions par mois et par machine venant principalement du point d entrée relatif au serveur SSH mais également FTP. Les numéros de sessions sont correctement appliqués à l ensemble des alarmes résultant d une session Attack Thread Reconstruction Attack Thread Reconstruction nous permet effectivement de reconstruire l ensemble des sessions locales détectées par PIGA. En moyenne, nous détectons sessions locales par mois et par machine sur le honeypot mais seulement 200 de ces sessions ont réellement fonctionnées i.e. sont allées plus loin qu une tentative de connexion. La figure 9.2 représentent le temps qu a pris le processus de reconstruction de la dernière session avec en ordonnée le temps moyen nécessaire à reconstruire une session en millisecondes et en abscisse le numéro de la session correspondant à ce temps). Nous pouvons voir que ce temps de reconstruction est long i.e. il prend entre 800 et 3000 millisecondes par session. Il est proportionnel au nombre d alarmes qui composent la session. Nous avons pu remarquer dans nos expérimentations que si la taille d occupation mémoire des alarmes d une session dépasse l espace mémoire alloué à l agent de reconstruction de session alors il se produit une explosion du temps de calcul, relatif à la reconstruction de cette session, passant de quelques secondes à plusieurs minutes. 80

82 Figure 9.2: Temps d éxecution nécessaire pour reconstruire la dernière session. Nous devrons donc trouver une méthode nous permettant de réduire l utilisation mémoire de cette étape Attack Session Reconstruction Nous n avons pas pu expérimenter notre algorithme d Attack Session Reconstruction qui doit nous permettre de relier les alarmes HIDS et NIDS. En effet, les alarmes NIDS sont stockées dans une base MySQL et celles HIDS dans une base DB2. De plus, nous ne disposons pas actuellement de serveur DB2 sur le honeypot Attack Focus Recognition L étape d Attack Focus Recognition nous a permis de détecter une attaque de type brute force sur le service ftp d une machine et en parcourant de manière manuelle les alarmes générées par PIGA, nous n en avons pas repérer d autres. Nous n avons pas pu détecter des attaques de ce type sur le serveur SSH car la politique de sécurité du honeypot considère qu il ne faut pas lever d alarme pour la transition que de contexte que provoque une tentative de brute force sur le service SSH. Mais en modifiant cette politique nous seront capable de les détecter. En effet, d après nos études se basant sur les alarmes générées par les NIDS, le nombre de brute force sur le service SSH est très important (i.e. plus de 10 par jour) Pattern Recognition Nous n avons pas encore l ensemble des résultats relatif à l étape de pattern recognition. Mais nous sommes déjà capable de reconstruire l ensemble des sessions locales sous forme d automates (voir l exemple d automate figure 9.3). Cet automate (voir figure 9.3) représente une tentative de connexion au service SSH, i.e. des tentatives de création d une console virtuel utilisateur (/dev/pts). Le premier noeud représente une méta-alarme se déroulant le 10 Avril à 18h04min49sec 2007 avec une transition de contexte depuis system_u:system_r:sshd_t i.e. le contexte du service SSH vers user_u:object_r:user_devpts_t i.e. le contexte de l objet utilisateur /dev/pts avec la classe chr_file i.e. un fichier contenant des chaines de caractères et la permission ioctl i.e. lecture et écriture du fichier. 81