La détection d’intrusions par corrélation d’événements ou d’alertes

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. Pour atteindre ce double objectif, la représentation de ces événements et alertes doit être relativement homogène : c’est pourquoi nous préconisons l’utilisation de formats utilisant le langage XML[Wor00]. Nous recommandons pour les alertes le format IDMEF (qui est en passe de devenir un standard) et pour les événements un format proche de l’IDMEF (mais adapté à chaque source de données) que nous définissons en annexe E. Ainsi, parler d’une valeur contenue dans une occurence d’événement ou d’alerte revient simplement à désigner un champ du document XML correspondant. Une description en ADeLe doit également pouvoir modéliser la détection d’attaques complexes, c’est à dire composées de plusieurs étapes. Cela signifie mettre en relation plusieurs événements ou alertes pour en déduire la présence d’une attaque. Nous avons donc défini dans la syntaxe d’ADeLe des opérateurs de corrélation temporelle et contextuelle entre les événements/alertes, qui permettent respectivement de donner des contraintes sur leur enchaînement et sur les valeurs qu’ils contiennent.

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.
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 Based Intrusion Detection Systems (HIDS). 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 applications peuvent également constituer une source d’information pour les IDS [Sie99]. Les capteurs applicatifs sont de deux natures :
– capteur interne : le filtrage sur les activités de l’application est alors exécuté par le code de l’application [AL01]
– capteur externe : le filtrage se fait à l’extérieur de l’application. Plusieurs méthodes sont utilisées : un processus externe peut filtrer les logs produits par l’application [ADD00] ou bien l’éxécution de l’application peut être interceptée (au niveau de ses appels de librairies [LJ01] ou d’un proxy applicatif (ex : Netsecure Web [Cal03])).
Prendre ses informations directement au niveau de l’application présente plusieurs avantages. Premièrement, les données interceptées ont réellement été reçues par l’application. Il est donc difficile d’introduire une désynchronisation entre ce que voit passer le capteur applicatif et ce que reçoit l’application contrairement à ce qu’il peut se passer avec les capteurs réseau [PN98]. Ensuite, cette source d’information est généralement de plus haut niveau que les sources système et réseau. Cela permet donc de filtrer des événements qui ont une sémantique plus riche. Finalement, si l’on prend l’exemple d’une connection web chiffrée par SSL,1 les agents SNMP (Simple Network Management Protocol) envoient des notifications d’événements, appelées trappes, à un système de gestion. Cette source de données reste aujourd’hui encore assez peu utilisée par les outils commerciaux et les prototypes de recherche.
Source d’information basée IDS : Une autre source d’information, souvent de plus haut niveau que les précédentes, peut être exploitée. Il s’agit des alertes remontées par des analyseurs provenant d’un IDS. Chaque alerte synthétise déjà un ou plusieurs événements intéressants du point de vue de la sécurité. Elles peuvent être utilisées par un IDS pour déclencher une analyse plus fine à la suite d’une indication d’attaque potentielle. De surcroît, en corrélant plusieurs alertes, on peut parfois détecter une intrusion complexe de plus haut niveau. Il y aura alors génération d’une nouvelle alerte plus synthétique que l’on qualifie de méta-alerte. La frontière entre un événement et une alerte est parfois floue car tout dépend à quel niveau d’abstraction on se place. C’est le cas notamment chez les IDS où le capteur et l’analyseur sont indissociables. Ces IDS détectent généralement des attaques simples qui ne requièrent qu’un seul événement. Nous les appelons IDS mono-événement (ex : diagnostic de remontée d’alerte à partir d’un seul paquet réseau). Le filtrage sur les données brutes et la détection se font alors en une seule phase. Il n’y a pas par contre pas d’ambiguïté dans le cas des IDS qui détectent des attaques plus complexes, à partir de plusieurs événements (nous les appellons IDS multi-événements). Parmi les rares IDS multi-événements qui opèrent une détection à partir d’alertes, on peut citer Emerald [VS01], AlertSTAT [RSG02] ainsi que les trois IDS du projet Mirador3 (les modules CRIM [CM02], CRS et la dernière version de Ga sSATA). Cette source de données commence à être exploitée depuis peu (les premières publications datent de l’année 2000).

Comportement après détection

             Une autre façon de classer les systèmes de détection d’intrusions consiste à les classer par type de réaction lorsqu’une attaque est détectée :
– passive : la plupart des systèmes de détection d’intrusions n’apportent qu’une réponse passive à l’intrusion. Lorsqu’une attaque est détectée, ils génèrent une alarme et notifient l’administrateur système par e-mail, message dans une console, voire même par beeper. C’est alors lui qui devra prendre les mesures qui s’imposent.
– active : d’autres systèmes de détection d’intrusions peuvent, en plus de la notification à l’opérateur, prendre automatiquement des mesures pour stopper l’attaque en cours. Par exemple, ils peuvent couper les connexions suspectes ou même, pour une attaque externe, reconfigurer le pare-feu pour qu’il refuse tout ce qui vient du site incriminé. Des outils tels que RealSecure [Sys98] ou NetProwler6 proposent ce type de réaction. Toutefois, il apparait que ce type de fonctionnalité automatique est potentiellement dangereux car il peut mener à des dénis de service provoqués par l’IDS. Un attaquant déterminé peut, par exemple, tromper l’IDS en usurpant des adresses du réseau local qui seront alors considérées comme la source de l’attaque par l’IDS. Il est préférable de proposer une réaction facultative à un opérateur humain (qui prend la décision finale).

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.

Automates à états finis à «exécution parallèle»

                    Finalement, nous avons choisi comme base de la sémantique de la signature dans ADeLe une solution inspirée des RdP mais utilisant des automates à états finis supportant des «exécutions parallèles». La signature est traduite par compilation en un automate à états finis permettant d’en assurer la détection, représenté par un graphe dirigé acyclique. Cet automate sert de modèle à la détection et nous permet de représenter l’état de reconnaissance de la signature. Il garantit, par construction des états, des transitions et des conditions associées aux transitions, qu’une hypothèse qui progresse vers l’état d’acceptation respecte les enchaînements temporels et les contraintes contextuelles définis en ADeLe. Comme les jetons des réseaux de Petri colorés, chaque hypothèse (contenue dans un état) transporte avec elle un ensemble d’informations qui représentent une reconnaissance partielle de la signature. Les hypothèses progressent en parallèle au sein de l’automate. Comme pour les RdP synchronisés, les transitions ne sont franchies que sur l’apparition d’événements particuliers (issus du filtrage/typage des événements concrets remontés par les capteurs ou les sondes). Chaque événement traité par notre automate est fourni simultanément à toutes les transitions concernées (c’està-dire qui attendent ce type d’événement). Les contraintes contextuelles du langage sont traduites en gardes (portées par les transitions) qui assurent qu’un événement remplit toutes les conditions requises avant de pouvoir faire progresser une hypothèse. Lorsqu’une hypothèse franchit une transition, son historique est augmenté avec l’événement courant. On garde également une copie de l’ancienne hypothèse dans l’état d’origine afin de conserver toutes les hypothèses intermédiaires. Cela nous permet d’opérer une recherche exhaustive de toutes les occurences de reconnaissance de la signature en analysant le flux d’événements en une seule passe. Toute hypothèse qui atteint l’état d’acceptation de l’automate correspond à une occurence distincte de reconnaissance de la signature. On émet alors une alerte basée sur le n-uplet des événements qui ont fait progresser cette hypothèse. On note que la construction et l’initialisation de l’automate doivent être réalisées avant de pouvoir analyser le flux d’événements.

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

Télécharger le rapport complet