Soutenance mémoire
Source des données à analyser
Les sources possibles de données à analyser sont une caractéristique essentielle des systèmes de détection d’intrusions puisque ces données constituent la matière première du processus de détection. Les données proviennent soit de logs générés par le système d’exploitation, soit de logs applicatifs, soit d’informations provenant du réseau, soit encore d’alertes générées par d’autres IDS.
Source d’information système Un système d’exploitation fournit généralement plusieurs sources d’information :
– commandes systèmes : presque tous les systèmes d’exploitation fournissent des commandes pour avoir un «instantané» de ce qui se passe. Ainsi, sous UNIX, des commandes telles que ps ou vmstat fournissent des informations précises sur les activités courantes du système.
– accounting : l’accounting fournit de l’information sur l’usage des ressources partagées par les utilisateurs (temps processeur, mémoire, espace disque, débit réseau, applications lancées, …). Les modules statistiques et neuronaux d’Hyperview [DBS92] ont utilisé cette source d’information.
– audit de sécurité : tous les systèmes d’exploitation modernes proposent ce service pour fournir des événements système, les associer à des utilisateurs et assurer leur collecte dans un fichier d’audit. On peut donc potentiellement disposer d’informations sur tout ce que font (ou ont fait) les utilisateurs : accès en lecture à un fichier, exécution d’une application, etc. Par exemple, l’audit BSM[Sun] représente les appels systèmes produits par les programmes qui s’exécutent sur un système Solaris. Les outils utilisant cette source de données sont appelés Host réseau. Cette source d’information est particulièrement adaptée lorsqu’il s’agit de rechercher les attaques en déni de service qui se passent au niveau réseau ou les tentatives de pénétration à distance. Le processus d’interception des paquets peut être rendu quasiment invisible pour l’attaquant car on peut utiliser une machine dédiée juste reliée à un brin du réseau, configurée pour ne répondre à aucune sollicitation extérieure et dont personne ne soupçonnera l’existence. Néanmoins, il est difficile de garantir l’origine réelle de l’attaque que l’on a détectée car il est facile de masquer son identité en modifiant les paquets réseau. De plus, l’utilisation du chiffrement peut rendre impossible la détection si elle basée sur le contenu utile des paquets (les données brutes sans les entêtes). Les trappes SNMP1 constituent également une source d’information réseau. Elle est particulièrement adaptée à la collecte des informations provenant des équipements matériels (routeurs, switches, . . .) car ils supportent presque toujours le protocole SNMP. Presque tous les outils commerciaux récents utilisent les informations issues du réseau. Les outils utilisant cette source de données sont appelés Network-based Intrusion Detection Systems (NIDS).
Les langages de description d’attaques
L’approche par scénarios est fondée sur la connaissance du mode opératoire de l’attaque et, par conséquent, sur la connaissance des activités caractéristiques de cette attaque (observables dans les systèmes ou les réseaux surveillés). Pour décrire complètement une attaque, il faut décrire de nombreux aspects de l’attaque qui sont par nature complètement différents. Par conséquent, si l’on veut décrire une attaque sous toutes ses faces, il faut utiliser plusieurs langages adaptés. Dans [VEK00, EVK00], Vigna, Kemmerer et Eckmann donnent une très bonne classification de ces langages. Six classes distinctes sont définies :
– les langages d’exploit servent à décrire le mode opératoire utilisé pour effectuer une intrusion ;
– les langages d’événements décrivent le format utilisé pour représenter les événements;
– les langages de détection sont utilisés pour décrire les manifestations d’une attaque dans les activités des systèmes ou des réseaux ;
– les langages de corrélation d’alertes sont destinés à permettre l’analyse des alertes fournies par les IDS afin de générer des méta-alertes;
– les langages de description d’alertes décrivent le format utilisé pour construire l’alerte qui sera remontée après détection ;
– les langages de réaction sont utilisés pour exprimer les éventuelles contremesures à prendre après détection.
Les langages de détection
Les langages de détection permettent d’exprimer comment on peut reconnaître les manifestations d’une attaque. C’est dans ces langages que l’on va codifier la connaissance que l’on a de l’attaque, c’est-à-dire sa signature. De nombreux langages ont été proposés, avec presque autant de mécanismes différents pour implémenter la détection. Presque tous ces langages sont dédiés à un IDS unique. Le langage de l’IDS réseau Bro [Pax98] est un vrai langage de programmation proche du C (où les signatures sont des fonctions que l’on doit programmer). Le langage RUSSEL est le langage propriétaire utilisé par l’IDS système ASAX [Mou97] dont les signatures sont exprimées sous forme de règles. Le langage STATL [EVK00] utilisé par les IDS de la suite logicielle STAT (USTAT, NetSTAT. . .) permet d’écrire des signatures sous formes d’automates en donnant explicitement la liste des états et des transitions ainsi que les traitements associés à chaque état. Le langage des signatures de l’IDS réseau Snort [Roe99] permet d’exprimer des règles. Chaque règle est associée à une attaque connue et décrit les caractéristiques que doit posséder un paquet réseau pour détecter la signature. Les signatures exprimées dans le langage Sutekh [PD00] sont des expressions combinant des filtres d’événements à l’aide d’opérateurs de séquence et d’ordre partiel. Chaque filtre contient des contraintes sur les valeurs des champs des événements. La sémantique de Sutekh est basée sur des règles de réécriture. Les signatures exprimées dans le langage de Logweaver [?] sont des expressions combinant des filtres d’événements à l’aide d’opérateurs de séquence, d’ordre partiel et de disjonction. La sémantique de Logweaver est basée sur des automates à états finis dont les transitions sont étiquetées par les filtres
Position d’un IDS configurable en ADeLe dans la classification
Une partie du langage ADeLe est dédiée à la détection de l’attaque. Par la conception même du langage, on peut tirer quelques conclusions sur la position dans la classification d’un IDS qui serait configurable en ADeLe. Sources de données : lors de la définition d’une signature, le langage ADeLe permet de désigner de façon homogène les données provenant de toutes les sources (système, réseau, application et alertes). Il n’y a donc pas de restriction sur les sources de données utilisées par un IDS configurable en ADeLe, si ce n’est qu’il faut déployer les capteurs ou sondes appropriés au sein du réseau à surveiller.
Méthode de détection : le langage ADeLe permet de donner une description complète pour chaque attaque connue. Il est donc clairement conçu pour des IDS basés sur l’approche par scénarios. D’ailleurs, si l’on considère un ensemble d’attaques que l’on aura décrites en ADeLe, il consitue (entre autres informations) une base de signatures.
Localisation de l’analyse : l’utilisation du langage ADeLe tend à privilégier des IDS qui effectuent une analyse centralisée puisque nous souhaitons corréler plusieurs événements (ou alertes) pouvant provenir de capteurs (ou sondes) différents. Toutefois, il y a des cas, au sein d’un système ou d’un réseau local, où la signature peut être vérifiée localement (même si les alertes résultantes seront centralisées afin d’avoir une vue globale sur l’ensemble du réseau). Effectuer l’analyse le plus tôt possible, c’est-à-dire lorsque l’on a accès à toutes les informations utiles pour réaliser le diagnostic, permet de réduire efficacement le flot des données au sein du système de détection d’intrusions.
Fréquence de l’analyse : dans une signature ADeLe, on ne présume pas de la fréquence d’analyse qui sera appliquée par l’analyseur (même si l’on peut exprimer des contraintes temporelles dans les signatures). ADeLe a été conçu pour décrire ce qui constitue l’attaque en faisant le moins d’hypothèses possible sur la façon de la détecter. Les opérateurs temporels des signatures ADeLe s’appliquent aussi bien dans le cas de l’analyse offline de fichiers de logs que dans le cas d’une analyse en continu des événements (ou alertes).
Comportement après détection : le langage ADeLe permet, pour chaque attaque décrite, d’exprimer une éventuelle réaction automatique en cas de détection. Un IDS configurable en ADeLe émet systématiquement une alerte et notifie l’opérateur. Par contre, il n’est pas obligé de réagir activement à la détection. Le risque de provoquer un déni de service sur son propre réseau (en cas de fausse alerte suivie d’une réaction automatique) est relativement élevé. Il est plutôt souhaitable de proposer une réaction à un opérateur humain (qui prend la décision finale).
La section
C’est dans cette section que l’on énumère les différents pré-requis pour que l’attaque réussisse. Il est important de pouvoir exprimer précisément les conditions qui font qu’une configuration est vulnérable . En effet, comme les systèmes doivent être continuellement patchés avec des correctifs fournis par les éditeurs de logiciels et de systèmes d’exploitation, il est difficile de recréer dans un réseau de tests une configuration effectivement vulnérable (pour tester une attaque face à des IDS) si l’on ne dispose pas d’informations suffisamment détaillées. Historiquement, cette section était présente pour représenter les niveaux de privilèges (issus de [Ken99]) nécessaires pour mener à bien l’attaque. Ensuite, elle a été enrichie par d’autres informations, dont certaines sont inspirées du langage LAMBDA [CO00]. Pour coder ces informations, nous proposons d’utiliser une liste de mot-clé == « valeur ». Si plusieurs valeurs sont possibles pour un des mots-clés, on marque l’alternative en les séparant avec le symbole ’|’. Un mot-clé peut apparaître plusieurs fois si l’on veut marquer la conjonction (par exemple, deux logiciels qui doivent être installés en même temps).
Un lien entre attaque et détection
La partie d’une description ADeLe (cf 2.3.1, p.42) contient les informations permettant de détecter l’attaque à partir des activités surveillées au sein du système. Comme les événements (issus des capteurs) et les alertes (issues des sondes) correspondent à des étapes observables de l’attaque, il est intéressant d’établir un lien entre les actions et leur détection. Si l’on dispose de l’information nécessaire, il est possible de mettre en relation une action (ou un groupe d’actions) observable avec les événements/alertes qu’elle doit générer. Plus concrètement, cela consiste à délimiter la portion de code correspondant à l’événement/alerte et de lui donner le même nom que celui qui sera utilisé plus loin dans la signature (partie ).
|
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
2.2 La partie
2.2.1 La section
2.2.2 La section
2.2.3 La section
2.3 La partie
2.3.1 La section
2.3.1.1 La sous-section
2.3.1.2 La sous-section
2.3.1.3 La sous-section
2.3.2 La section
2.3.3 La section
2.4 La partie
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 et perspectives
A Lexique
B DTD du squelette d’une description d’attaque
C Grammaire complète du langage ADeLe
D Grammaire pour le format interne d’un événement de type paquet réseau
E DTD pour le format des événements (EVMEF)
F Détails de l’algorithme abstrait utilisé pour la détection
F.1 Notations du pseudo-langage utilisé par l’algorithme
F.2 Détails de l’algorithme
G Deux exemples d’attaques décrites en ADeLe
G.1 Attaque NFS_Mount
G.2 Attaque ARP_Spoofing
H Exemples d’événements et d’alertes
Bibliographie
Télécharger le rapport complet
