Langage de description d’attaques pour la détection d’intrusions par corrélation d’événements ou d’alertes en environnement réseau hétérogène

L’approche traditionnelle de la sécurité des systèmes d’information (SSI) consiste à mettre en place des mécanismes de sécurité préventifs pour assurer le respect d’une politique de sécurité visant à garantir la confidentialité, l’intégrité ou la disponibilité de ressources sensibles. Mettre en place des mécanismes préventifs est une condition nécessaire mais pas suffisante. En effet, compromettre un système est essentiellement une question de temps et de moyens mis en œuvre. Malgré tous les efforts déployés pour renforcer la sécurité d’un système ou d’un réseau, tout mécanisme de sécurité a ses limites et peut être contourné. Par exemple :
– un pare-feu, aussi sophistiqué soit-il, ne peut filtrer que les paquets qui le traversent. Il sera donc inopérant si un utilisateur le contourne en utilisant un modem sur une machine du réseau interne ;
– un contrôle d’accès à base de login/mot de passe n’empêche pas la connexion d’une personne non autorisée si elle a obtenu frauduleusement le mot de passe d’un utilisateur légitime ;
– un protocole ou un mécanisme bien pensé et qu’on ne peut théoriquement pas détourner n’est pas à l’abri d’une erreur de programmation lors de sa mise en œuvre. Ainsi de nombreux logiciels que l’on croyait sûrs se révèlent vulnérables à des attaques de type buffer overflow qui permettent généralement à l’attaquant d’exécuter le code de son choix avec des privilèges plus élevés que prévu.

Ainsi, malgré toute la sécurité préventive mise en place, une intrusion peut quand même survenir. Il est alors primordial de savoir que cela s’est produit : pour comprendre comment, pour empêcher que cela recommence et pour réparer les dégâts éventuels. Il faut donc mettre en place une surveillance des activités (sur les systèmes et les réseaux qui les interconnectent) afin d’y rechercher de manière automatique ce qui pourrait constituer une intrusion.

Les caractéristiques du langage 

Nous mettons ici en avant les caractéristiques dont nous avons souhaité doter le langage ADeLe et qui ont guidé sa conception.

Description complète
Le but premier d’ADeLe est de donner la possibilité de représenter chacun des aspects d’une attaque au sein d’une seule description, c’est-à-dire :
– du point de vue de l’attaquant : on peut souvent trouver de l’information brute sur les attaques comme, par exemple, le code source d’un exploit. Afin de savoir comment s’effectue réellement l’attaque, nous pouvons inclure ce code dans la description. Il peut être écrit dans les langages traditionnels utilisés pour les exploits (C, Perl, NASL . . .) ou dans un autre langage de haut niveau que nous proposons dans 2.2.2. Mais disposer du code source ne suffit pas : nous pouvons également décrire les préconditions qui font que l’attaque est possible (OS, version d’application vulnérable, type d’accès initial, services réseaux disponibles . . .) ainsi que les conséquences de l’attaque (informations obtenues, gains de privilèges, ressources utilisées, dénis de service . . .).
– du point de vue du défenseur : nous pouvons préciser quels sont les événements caractéristiques observables qui doivent se produire durant l’attaque. La description contient aussi les relations temporelles et contextuelles entre ces événements qui permettront de détecter l’attaque. Nous pouvons également exprimer ce qui permet de confirmer la détection en vérifiant la présence des conséquences attendues de l’attaque pour préciser si la tentative a abouti. Chaque description contient également un modèle précisant quelles informations devront figurer dans l’instance de l’alerte remontée après la détection. Dans certains cas, une réaction appropriée et automatique à l’attaque détectée est souhaitable et peut être spécifiée dans la description.

Expressivité
Le langage ADeLe a été conçu pour être le moins restrictif possible quant aux possibilités de description d’attaques. Comme l’information de base pour la détection est l’événement, une description doit donc pouvoir utiliser les événements provenant de tous les types de capteurs : système, réseau et applicatif. De même, si l’on souhaite faire de la corrélation entre plusieurs alertes (pour en générer d’autres de plus haut niveau), il faut pouvoir utiliser les alertes provenant des IDS.

Modularité
Une description en ADeLe se doit d’être modulaire afin que l’on puisse réutiliser au mieux les descriptions déjà écrites. Cela vaut à la fois pour la partie attaque et pour la partie détection : on peut donc d’abord définir des briques de base, puis les réutiliser pour composer des descriptions de plus haut niveau de manière hiérarchique.

Généricité
De nouvelles variantes d’attaques connues apparaissent tous les jours. Une modification même mineure peut permettre à l’attaque de passer inaperçue dans un premier temps puisque les IDS utilisant une base de signatures ne la connaitront pas encore. C’est le problème majeur qu’on prête à l’approche par scénarios : être obligé de connaître toutes les variantes d’une attaque afin de pouvoir les détecter . Cela signifierait dans notre contexte être obligé de faire autant de descriptions distinctes qu’il existe de variantes.

Nous apportons une réponse partielle à ce problème dans ADeLe en introduisant des opérateurs pour exprimer et factoriser plusieurs variantes en une seule description. Ainsi, il est fréquent que l’ordre de certaines étapes d’une attaque composée soit indifférent et amène au même résultat. Une autre possibilité est qu’une des étapes est interchangeable avec une autre produisant les mêmes effets. Nos opérateurs permettent justement de représenter non-déterminisme et alternative à la fois dans la partie attaque et dans la partie détection d’une description. L’introduction de la généricité permet donc de réduire la taille de la base de description d’attaques puisqu’une seule description peut représenter plusieurs variantes de la même attaque.

Aptitude à tester des IDS
Comme une description en ADeLe peut contenir le code source de l’attaque, constituer une base de descriptions d’attaques signifie également constituer une base d’attaques exécutables. Moyennant l’utilisation du compilateur (ou de l’interpréteur) approprié, il est possible, dans un réseau de tests confiné, de jouer l’intégralité de cette base d’attaques contre des systèmes surveillés par des IDS.

Cela permet de tester l’efficacité de la détection de ces IDS, notamment en termes de faux négatifs. En effet, puisque l’on sait quelles attaques ont été réellement jouées, il est possible de dire pour chacune d’entre elles si l’IDS considéré l’a effectivement détectée.

Aptitude à configurer des IDS
Une description d’attaque en ADeLe doit permettre de configurer des IDS, c’està-dire des capteurs et les analyseurs associés. Toutefois, une description en ADeLe n’est pas directement opérationnelle. Certes, elle contient de l’information sur une attaque mais cette information a besoin d’être extraite et transformée par des compilateurs pour être utilisable concrètement.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction
1 Etat de l’art
1.1 Une classification des systèmes de détection d’intrusions
1.1.1 Source des données à analyser
1.1.2 Méthodes de détection
1.1.3 Localisation de l’analyse des données
1.1.4 Fréquence de l’analyse
1.1.5 Comportement après détection
1.2 Les langages de description d’attaques
1.2.1 Les langages d’exploit
1.2.2 Les langages d’événements
1.2.3 Les langages de détection
1.2.4 Les langages de corrélation d’alertes
1.2.5 Les langages de description d’alertes
1.2.6 Les langages de réaction
1.2.7 Récapitulatif des langages
1.3 Position d’un IDS configurable en ADeLe dans la classification
2 Syntaxe et sémantique informelle du langage ADeLe
2.1 La description globale <ADELE>
2.2 La partie <EXPLOIT>
2.2.1 La section <PRECOND>
2.2.2 La section <ATTACK>
2.2.3 La section <POSTCOND>
2.3 La partie <DETECTION>
2.3.1 La section <DETECT>
2.3.1.1 La sous-section <EVENTS>
2.3.1.2 La sous-section <ENCHAIN>
2.3.1.3 La sous-section <CONTEXT>
2.3.2 La section <CONFIRM>
2.3.3 La section <REPORT>
2.4 La partie <RESPONSE>
3 Sémantique opérationnelle de la détection
3.1 Choix du formalisme
3.2 Les bases du formalisme
3.2.1 Types abstraits de données utilisés pour les automates
3.2.2 Notations utilisées pour les propriétés temporelles
3.3 Sémantique de la corrélation temporelle
3.3.1 Reconnaissance d’un seul événement
3.3.2 Opérateur de séquence ” ;”
3.3.3 Opérateur de disjonction “One_among”
3.3.4 Opérateur de conjonction “Non_ordered”
3.3.5 Opérateur d’exclusion “Without”
3.3.6 Contrainte temporelle “Timeout”
3.3.7 Contrainte temporelle “MinDelay”
3.3.8 Contrainte temporelle “MaxDelay”
3.4 Sémantique de la corrélation contextuelle
3.4.1 Contraintes intra-événement
3.4.2 Contraintes inter-événements
3.5 Principes de l’algorithme abstrait utilisé pour la détection
3.6 Problème de l’explosion combinatoire
4 Mise en œuvre et expérimentation
4.1 Mise en œuvre de capteurs et de sondes
4.1.1 Capteur système : audit BSM sous Solaris
4.1.2 Capteur système : Libsafe sous Linux
4.1.3 Capteur réseau : sniffer TCP/UDP/ICMP
4.1.4 Sonde applicative : module pour serveur web Apache
4.2 Compilation du langage ADeLe vers le langage des automates d’ADeLaIDS
4.3 L’analyseur ADeLaIDS
4.3.1 Principe de fonctionnement
4.3.2 Mise en œuvre
4.3.3 Interface graphique interactive de test des automates
4.3.4 Expérimentation
4.3.4.1 Test d’un cas réel : analyse d’un log Apache
4.3.4.2 Test d’un cas limite par simulation
Conclusion 

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *