Résumé

Les systèmes de détection d'intrusion (IDS) généralement utilisés dans le commerce et dans la recherche posent un certain nombre de problèmes qui limitent leur facilité de configuration, leur élasticité (scability) et leur efficacité. Le défaut principal des architectures existantes est qu'ils sont bâtis autour d'une seule entité monolithique qui effectue la plus grande partie des calculs et de la collecte d’informations. Dans ce document, nous donnons une vision globale de notre architecture : un système de détection d'intrusion distribué, basé sur de multiples entités indépendantes travaillant de manière collective. Nous appelons ces entités Agents Autonomes. Cette approche résout une partie des problèmes mentionnés ci-dessus. Nous présentons une description de cette approche, une partie des résultats issus de prototypes, quelques points relatifs à la conception et à l'implémentation ainsi que les directions prises pour nos futurs travaux.

1. Arrière-plan et motivation

Nous commencerons par introduire certaines notions utilisées tout au long de ce document et nous décrirons les limites que nous voyons dans les systèmes de détection d'intrusion existants. Nous verrons ensuite pourquoi une approche distribuée utilisant des agents autonomes peut aider à outrepasser ces limites.

1.1. Détection d'intrusion

La détection d'intrusion est définie comme "la capacité à identifier les individus utilisant un système informatique sans autorisation (i.e. 'crackers') et identifier ceux qui ont un accès légitime au système mais qui abusent de leur privilèges". Pour notre travail, nous ajoutons à cette définition l'identification des tentatives d'utilisation d'un système informatique sans autorisation et des abus de privilèges. Ainsi, nos définitions correspondent à celles données en [9] où l'intrusion est définie comme "toute tentative visant à compromettre l'intégrité, la confidentialité ou la disponibilité d'une ressource".

Nous avons reçu des commentaires concernant l'utilisation du mot "intrusion" dans la définition précédente [17]. La définition du mot n'inclut pas le concept d'intrus abusant des ressources ou tentant de le faire. Dans ce sens, le terme "Détection des intrusions et des Abus" serait plus approprié. Dans notre définition, le mot intrusion désigne à la fois l'intrusion proprement dite et les abus. Quelques notions :

Modèle de détection des abus : la détection est réalisée en examinant les faiblesses du système ce qui peut être décrit par des schémas spécifiques ou des séquences d’événements et de données (la signature de l'intrusion).

Modèle de détection d'anomalie : la détection est réalisée en recherchant les changements dans le schéma d'utilisation ou dans le comportement du système. Il s'agit du type de détection d'intrusion décrite en [5]. Elle est réalisée en créant un modèle statistique qui contient des données, issues d'opérations du système, qui pointent en tant qu'intrus tout comportement déviant dans une certaine proportion par rapport au modèle statistique.

Un système de détection d'intrusion (IDS) est un programme informatique capable d'effectuer cette fonction par combinaison de différentes techniques. Un IDS sera plus performant en réalisant sa tâche en temps réel [16].

Les IDS sont basés soit sur des machines hôtes (ils sont dans ce cas appelés "host-based") soit sur le réseau complet ("network-based"). Les systèmes dits "host-based" fondent leurs décisions sur des informations obtenues via des hôtes uniquement (habituellement "audit trail") alors que les systèmes dits "network-based" obtiennent leurs informations à partir du réseau sur lequel les stations sont connectées.

On peut noter que la définition d'un IDS n'inclut pas la prévention contre les intrusions, il se contente de les détecter et de les reporter à un opérateur.

1.2. Caractéristiques souhaitées d'un IDS

Les caractéristiques que l'on attend d'un IDS sont répertoriées dans le document [4] :
- Il doit fonctionner de manière continue avec une présence humaine minimum.
- Il doit être tolérant aux fautes c'est-à-dire qu'il doit être capable de retrouver son état initial de fonctionnement après un crash causé soit par une manipulation accidentelle soit par des activités émanant de personnes malintentionnées.
- Il doit résister à la subversion. L'IDS doit être capable de se contrôler lui-même et de détecter s'il a été modifié par un attaquant.
- Il doit imposer une supervision minimale du système sur lequel il tourne afin de ne pas interférer avec ses opérations normales.
- Il doit être configurable d'après les politiques de sécurité du système qu'il supervise.
- Il doit également être capable de s'adapter aux changements du systèmes et des comportements des utilisateurs au cours du temps (par exemple installation de nouvelles applications, transfert des utilisateurs d'une activité vers une autre et du coup transfert des ressources du système).

Lorsque le nombre de systèmes à superviser augmente et donc que les attaques potentielles augmentent également , nous pouvons alors attendre de l'IDS les caractéristiques suivantes :
- Il doit être capable de superviser un nombre important de stations tout en fournissant des résultats de manière rapide et précise.
- Il doit fournir "un service minimum de crise" c'est-à-dire que si certains composants de l'IDS cessent de fonctionner, les autres composants doivent être affectés le moins possible par cet état de dégradation.
- Il doit autoriser des reconfigurations dynamiques. Si un grand nombre de stations est supervisé, il devient pratiquement impossible de redémarrer l'IDS sur tous les hôtes lorsque l'on doit effectuer un changement.

1.3. Limitations des systèmes de détection d'intrusion existants

Beaucoup d’IDS existants ("network-based" et "host-based" [9][10]) réalisent leur collecte de données ainsi que leur analyse en utilisant une architecture monolithique. Par là, nous entendons que la donnée est collectée par une unique station soit à partir d'"audit trails" soit par supervision des paquets du réseau et qu’elle est ensuite analysée par un seul module utilisant différentes techniques. Les autres IDS [11][22] réalisent la collecte des données (ainsi que certains pré-calculs) sur des modules incorporés dans les stations supervisées. Toutefois, la donnée reste envoyée à une entité centrale ou elle est analysée par un moteur monolithique. Une vision globale de la qualité des systèmes utilisant l’une ou l’autre des deux approches est décrite dans l'ouvrage [16].

Il existe un certain nombre de problèmes issus de ces architecture :
- L'analyseur central est un point de faille à lui seul. Si un intrus parvient à le faire tomber (par exemple en crashant ou en ralentissant le terminal où il se trouve), la totalité du réseau se retrouve sans protection.
- L’élasticité du réseau est limitée. Le calcul de toutes les informations sur une seule station implique des limites sur la taille du réseau à observé. Au-delà de cette limite, l'analyseur central devient incapable de gérer le flot d'informations. La collecte de données peut également engendrer des problèmes lors de trafics excessifs sur le réseau.
- Il est difficile de reconfigurer ou d'ajouter des possibilités à un IDS. Les changements et mises à jour sont habituellement effectués en éditant un fichier de configuration et cela en ajoutant une entrée dans une table ou en installant un nouveau module. L'IDS nécessite habituellement d'être redémarré afin de prendre en compte ces changements.
- L'analyse des données du réseau peut être imparfaite. Comme démontré dans le document [20], réaliser la collecte de données d'un réseau ailleurs que sur la station destinée à les recevoir peut offrir à des intrus la possibilité d'attaques dites d'insertion ou d'évasion. Ceux-ci se servent des failles dans les piles de protocoles du réseau de différents centres serveurs pour dissimuler des attaques ou des dénis-de-service.

D’autres IDS ont été conçus pour effectuer la collecte et l'analyse d'informations. Un système hiérarchique est décrit dans [28] et de plus, [29] décrit un mécanisme sans autorité centrale. Ces systèmes résolvent la plupart des problèmes mentionnés ci-dessus excepté la reconfiguration ou l'ajout de fonctionnalités à l'IDS, ce qui n'est décrit dans aucune des deux références.

1.4. Agents autonomes

Un programme informatique de type agent peut être défini comme tel [1] :
"... une entité logicielle qui fonctionne de manière continue et autonome dans un environnement particulier ... capable d'effectuer des activités de manière flexible et intelligente qui réagit bien aux changements d'environnement ... Idéalement, un agent fonctionnant continuellement ... serait capable de s'enrichir de ses expériences. De plus, nous attendons d'un agent qu'il puisse cohabiter avec d'autres dans un même environnement et accomplir ses tâches en communicant et en coopérant avec eux, voir même effectuer cela en se déplaçant sur différents postes."

Dans notre contexte, nous définissons un agent autonome (que nous appellerons désormais agent) comme une entité logicielle qui effectue une certaine fonction de supervision sur une station hôte.

Nous qualifions ces agents d’autonomes car ils correspondent à des entités fonctionnant indépendamment les unes des autres (leur exécution est programmée uniquement par le système sur lequel ils fonctionnent et non par un autre processus). Les agents peuvent éventuellement avoir besoin des données d'autres agents; toutefois, ils sont quand même considérés comme autonomes. Par ailleurs, ils peuvent recevoir des commandes de contrôle de haut niveau comme des instructions visant à démarrer ou arrêter des exécutions ou à changer des paramètres de leur système à partir d'autres entités. Ce haut niveau de contrôle n'interfère pas avec notre définition d'agent autonome.

Un agent peut réaliser une seule fonction très spécifique ou bien au contraire des activités beaucoup plus complexes.

1.4.1. Comment l'utilisation d'agents autonomes peut améliorer les caractéristiques d'un IDS

Parce que les agents sont des entités indépendantes, ils peuvent être ajoutés ou retirés d'un système sans altérer les autres composants et sans besoin de redémarrer l'IDS. De plus, les agents peuvent fournir des mécanismes de reconfiguration pendant leur fonctionnement et cela sans les redémarrer. Par ailleurs, ils peuvent être testés seuls avant d'être introduits dans des environnements plus complexes. Ils peuvent également faire parti d'un groupe et fournir alors des fonctions simples mais qui peuvent être échangées de façon à donner des résultats plus complexes qu'ils ne pourraient pas obtenir seuls.

C'est pourquoi nous pouvons argumenter sur le fait qu'un IDS dans lequel la collecte de données et l'analyse des éléments sont effectuées par agents résout tous les problèmes mentionnés dans la section 1.3. :

Si un agent s'arrête de fonctionner, quelle qu’en soit la raison, un ou plusieurs événement peuvent arriver :
- si l'agent est vraiment indépendant et produit des résultats par lui-même, seules ces données seront perdues et tous les autres agents fonctionneront normalement.
- si l'information produite par un agent est partagée avec d'autres, le groupe peut être gêné et ne plus fonctionner correctement.

Dans tous les cas, les dommages sont restreints à une partie des agents, tous les autres continuant de fonctionner normalement. C'est pourquoi, s’ils sont organisés proprement dans des groupes indépendants les uns des autres, ces problème sont réduits en un seul.

En les organisant en une structure hiérarchique avec plusieurs couches d'agents réduisant les données et les reportant aux couches supérieures, le système peut alors devenir " élastique ". Cette idée est proposée en [3] et est aussi utilisée dans [24]. La faculté de démarrer et d'arrêter des agents indépendamment les uns des autres sur le système qu'ils sont chargés de superviser, ajoute la possibilité de reconfigurer les IDS (ou une partie seulement) sans devoir les redémarrer. Si nous avons besoin de démarrer la collecte d'un nouveau type de données ou bien de superviser un nouveau type d'attaque, les agents en question peuvent être redémarrés sans déranger ceux qui tournent déjà. De même, les agents dont on n'a plus besoin peuvent être arrêtés et ceux qui nécessitent d'être reconfigurés peuvent être redirigés sans avoir besoin de redémarrer la totalité de l'IDS.

Si un agent collecte des informations en relation avec la machine sur lequel il tourne, nous réduisons la possibilité d'être sujet aux attaques d'insertion et d'évasion en réduisant le nombre de failles. D'autre part, utiliser les agents en tant que collecteurs d'information et analyseurs fournit des fonctions supplémentaires :

Parce qu'un agent peut être programmé arbitrairement, il peut obtenir ces données à partir d'un "audit trail" en sondant le système sur lequel il se trouve grâce à la capture des paquets du réseau ou à partir d'autres sources similaires. Ainsi, un IDS basé sur différents agents peut outrepasser les limites entre IDS "host-based" et "network-based".

Parce qu'ils peuvent être arrêtés et redémarrés sans porter préjudice au reste de l'IDS, on peut donc les mettre à jour afin d'accroître leurs fonctionnalités tant que leur interface externe reste inchangée et compatible avec la version précédente. Les autres composants n'ont même pas besoin d'être notifiés de ce changement.

Si les agents sont implémentés en tant que processus séparés sur une station, chacun d'entre eux peut être implémenté dans le langage de programmation qui convient le mieux à la tâche qu'il a à accomplir.

1.5. Travaux de recherche en rapport avec notre étude

L'idée de faire de la détection d'intrusion distribuée n'est pas nouvelle et il en est de même de l'idée d'implémenter différentes fonctions réalisées par des modules distincts sur un IDS. Le projet GrIDS à UC Davis [24] utilise des modules tournant sur chaque machine pour reporter les informations à des moteurs élaborant des représentations sous formes de graphiques, à partir des activités du réseau, et pour détecter des intrusions possibles. D'après le document [24], GrIDS fournit des mécanismes permettant à de nouveaux outils de sécurité nouveaux d'être utilisés comme sources de données mais la façon dont ces informations peuvent être ajoutées, retirées ou mises à jour n'est pas claire.

Le système NADIR [11] effectue la collecte de données de manière distribuée en utilisant les nœuds de service existant du "Los Alamos National Laboratory's Integrated Computer Network" (ICN) pour réaliser des audits d'information qui sont ensuite analysés par un système central expert. Ce travail décrit un IDS qui tourne dans un système du monde réel c'est pourquoi [11] présente des résultats et des considérations intéressantes concernant la collecte, le stockage, la compression et le traitement des données dans un environnement réseau important.

Une autre approche est présentée dans [29] où des "Cooperative Security Managers" (CSM) sont utilisés pour effectuer une détection d'intrusions distribuée qui ne nécessite pas une organisation hiérarchique ou un coordinateur central. Dans ce modèle, chaque CSM fonctionne comme un IDS local pour la station sur lequel il fonctionne mais peut en plus communiquer avec les autres CSM, échanger des informations au sujet des utilisateurs se déplaçant à travers le réseau et détecter des activités suspectes. L'architecture permet également aux CSM de prendre des décisions lorsqu'un intrus est détecté, comme celle de lancer des applications dites "damage-control" ou bien d’arrêter l'intrus dans ses actions. Certains aspects sont moins clairs, comme les mécanismes par lesquels les CSM peuvent être remis à jour ou reconfigurés, et les mécanismes de détection d'intrusion utilisés localement par chaque CSM.

L'idée d'utiliser des éléments largement distribués pour effectuer de la détection d'intrusion en simulant certaines propriétés du système immunitaire biologique et en donnant au système la notion de "lui-même" a également été exploré [8]. Un système de capteurs distribués qui effectue le traitement de manière centralisée, organisé hiérarchiquement est décrit dans [12]. Ce document propose un système quasiment identique au schéma de notre modèle référencé en [3]. Le projet EMERALD [19] propose une architecture distribuée pour la détection d'intrusion qui utilise des entités appelées "service monitors" déployées sur les stations; elles assurent des fonctions de supervision similaires aux fonctionnalités que nous proposons pour nos agents. Le projet définit également différentes couches de contrôle afin de réduire la taille des données par un mode hiérarchique. Les contrôleurs peuvent être programmés pour accomplir toutes ces fonctions. Le projet EMERALD est encore en cours de recherche et nous en attendons des résultats intéressants.

Le fait d’utiliser des agents autonomes dans les détecteurs d'intrusion, fondement de notre travail est proposé dans [3] et [4]. Ces documents introduisent l'idée d'entités indépendantes, allégées opérant de concert pour détecter des activités anormales plus rapidement que la plupart des approches mentionnées précédemment.

2. Architecture du système

Nous proposons une architecture (que nous appelons AAFID pour "Autonomous Agents For Intrusion Detection" - Agents Autonomes pour la détection d'intrusions) pour mettre en place des systèmes de détection d'intrusion utilisant des agents pour la collecte des données et leur analyse et employant une structure hiérarchique permettant une grande souplesse par leur faculté à s'adapter à la dimension du réseau comme décrit dans la section 1.4.1..

2.1. Vue globale

La figure 1(a) montre un exemple simple d'IDS qui adhère à l'architecture AAFID. Cette figure montre les trois composantes essentielles de l'architecture : agents, transmetteurs et moniteurs (ou contrôleurs - "monitors"). Nous nous référons à chacun de ces composants soit comme des entités AAFID soit comme des entités simples; de même, l'entité globale AAFID constituée par ceux-ci sera appelée système AAFID.

Un système AAFID peut être distribué sur un nombre quelconque de stations au sein d'un réseau. Tous les agents d'une station rapportent les résultats de leurs recherches à un unique transmetteur. Ces derniers sont des éléments qui surveillent les opérations effectuées par tous les agents fonctionnant sur leur station et ils ont la capacité de lancer, d'arrêter et d'envoyer des commandes de configuration à ces agents. Ils peuvent également réaliser de la compression de données à partir des informations reçues par les agents. Finalement, ils rapportent leurs résultats à un ou plusieurs moniteurs. Ces derniers surveillent les opérations de plusieurs transmetteurs à la fois. Ils ont accès aux données du réseau de manière étendue et de là sont capables d'effectuer des corrélations de haut niveau et de détecter des intrusions impliquant plusieurs machines. Il peuvent être organisés hiérarchiquement de telle sorte qu'ils réfèrent eux-mêmes leurs activités à un contrôleur supérieur. Aussi, un transmetteur peut reporter ses activités à plus d'un contrôleur pour ainsi fournir des informations redondantes et résister à une faille provenant de l'un d'entre eux. Pour finir, un contrôleur est responsable de fournir des informations et d'obtenir des commandes de contrôle à partir d'une interface utilisateur.

La figure 1(b) montre l'organisation logique qui correspond à la distribution physique représentée sur la figure 1(a). Tous les composants exportent une API pour communiquer les uns avec les autres, ainsi qu’avec l'utilisateur. Dans la section suivante, nous décrivons chaque composant en détail.

(a) Couches physiques des composants d’un système AAFID simple où sont visibles agents, transmetteurs et moniteurs aussi bien que les canaux de communication et de contrôle entre eux.

(b) Organisation logique du même système AAFID les communications sous forme hiérarchique entre les composants. Les flèches bidirectionnelles représentent à la fois des flots de contrôle et de données entre les entités. On peut noter que cette organisation logique est indépendante du lieu où se situent les entités sur les hôtes.

Figure 1 : Représentations physique et logique d’un IDS simple qui suit l’architecture AAFID (appelé système AAFID).

2.2. Composants de l'architecture

2.2.1. Agents

Un agent est une entité fonctionnant de manière indépendante qui contrôle certains aspects de la machine et rapporte les comportements anormaux ou es comportements intéressants (en redéfinissant au préalable la notion "intéressants") du transmetteur approprié. Par exemple, un agent pourrait observer les connections Telnet sur une station protégée et considérer comme suspicieux ce genre d’événement. L’agent générerait alors un rapport envoyé aux transmetteurs appropriés. Les agents n’ont pas l’autorisation nécessaire pour pouvoir émettre une alarme. Habituellement, un transmetteur ou un moniteur va émettre une alarme vers l’utilisateur à partir des informations reçues d’un ou plusieurs agents. En combinant les rapports de différents agents, les transmetteurs construisent une image de l’état de leur station et les moniteurs font l’état de la globalité du réseau qu’ils surveillent.

Les agents ne communiquent pas directement les uns avec les autres au sein de l’architecture AAFID. Au contraire, ils envoient leurs messages aux transmetteurs. Ces derniers décident quoi faire de l’information. On peut noter que l’architecture AAID ne spécifie pas de limitations à l’utilisation des agents. Ainsi, il peut s’agir d’un simple programme chargé d’observer l’état d’une variable du système ou d’un événement (par exemple compter le nombre de connections Telnet au cours des 5 dernières minutes), ou bien d’un programme informatique complexe (par exemple IDIOT [2] chargé de surveiller une série de paramètres liés aux intrusions locales). Produisant des informations dans un format approprié et les envoyant au transmetteur, l’agent fait partie intégrante du système AAFID.

Quelques tâches réalisables par les agents :

- Les agents peuvent évoluer à travers le temps en utilisant par exemple des techniques de programmation dites "génétiques" comme mentionnées en [3].

- Les agents peuvent utiliser des techniques pour conserver leur état entre différentes sessions, leur permettant de détecter des attaques à long terme ou des changements de comportement. Actuellement, l’architecture ne spécifie aucun mécanisme de maintient d’états.

- Les agents peuvent migrer d’un hôte à l’autre en combinant l’architecture AAFID avec des architectures d’agents mobiles existantes.

Ces agents peuvent être implémentés dans n’importe quel langage de programmation. Certaines fonctionnalités (par exemple la génération de rapports, les mécanismes de communication et de synchronisation) sont communes à tous les agents et peuvent être fournies par des librairies partagées ou d’autres mécanismes similaires. Ainsi, une implémentation de base (comme celle décrite en [23]) peut fournir la plupart des outils et des mécanismes nécessaires pour rendre la tâche d’écriture de nouveaux agents simple.

2.2.2. Transmetteurs

Les transmetteurs sont les interfaces externes de communication de chaque station. Ils ont deux rôles : le contrôle et le traitement des données. Pour qu'un terminal puisse être surveillé par un système AAFID, il doit obligatoirement posséder un transmetteur.

Dans son rôle de contrôle, le transmetteur accomplit les fonctions suivantes :
- initialise et arrête l'exécution de l'agent sur sa machine. Ces instructions peuvent venir soit des informations de configuration, soit d'un superviseur humain, soit d'une réponse à un événement spécifique (par exemple le rapport d'un agent peut déclencher l'activation d'autres agents pour un contrôle plus ciblé de la station),
- garde une trace des agents qui tournent sur sa machine,
- répond aux commandes provenant de son "monitoring" en fournissant les informations appropriées ou en en effectuant les actions nécessaires.
En ce qui concerne son rôle de traitement des données, il lui incombe les tâches suivantes:
- recevoir les rapports générés par les agents fonctionnant sur sa station,
- effectuer les actions préconisées (analyse ou réduction) à partir des informations provenant des agents,
- distribuer ces informations, voire l'analyse faite de celles-ci, soit vers les autres agents, soit vers l'entité chargée du "monitoring".

2.2.3. Ecrans de contrôle ("Monitors")

Il s'agit des entités les plus hautes dans l'architecture AAFID. Ils gèrent le contrôle et le traitement de la même manière que les transmetteurs. La grande différence entre ces deux entités est que les écrans de contrôle (que l’on désignera dorénavant par moniteurs) peuvent superviser des agents tournant sur différentes stations alors que les transmetteurs peuvent seulement contrôler les agents locaux.

Dans leur rôle de traitement des données, ces moniteurs reçoivent une information réduite provenant des transmetteurs sous leur contrôle; ils peuvent ainsi faire des corrélations de haut niveau et détecter des événements impliquant plusieurs machines. Ils ont également pour vocation de détecter des événements indécelables au niveau des transmetteurs. Pour le contrôle, ils reçoivent des instructions provenant d'autres moniteurs qu'ils peuvent également contrôler au même titre que les transmetteurs. De plus, ils ont la capacité de pouvoir communiquer grâce à une interface utilisateur et fournir des points d'accès à tout le système AAFID. Ce contrôle de haut niveau est accessible via des API pouvant être utilisées à la fois par les autres moniteurs et par d'autres programmes (comme les interfaces utilisateur). Ces API incluent des mécanismes d'accessibilité aux informations du moniteur afin de lui transmettre ensuite des commandes ou envoyer celles-ci à des entités de niveau plus bas comme les transmetteurs et les agents.

Si deux moniteurs contrôlent le même émetteur, des mécanismes doivent être employés afin d'assurer la concision des informations et des comportements. L'architecture AAFID ne spécifie pas actuellement de mécanismes permettant d'effectuer ces opérations.

2.2.4. Interfaces Utilisateur

Le système de détection d'intrusion le plus complexe et le plus complet devient inutile s'il ne possède pas de bons mécanismes permettant aux utilisateurs d'interagir avec lui et de le contrôler. Nous n’avons pas vu en détail le problème de l'interface utilisateur bien que quelques considérations soient mentionnées en section 4.4.

L'architecture AAFID sépare de manière bien claire l'interface utilisateur, la collecte de données et les éléments de traitement des informations. Une interface utilisateur nécessite de pouvoir interagir avec un moniteur et de pouvoir utiliser les API que celui-ci exporte pour ses demandes de renseignements et pour fournir ses instructions.

Cette séparation autorise différentes implémentations d'interfaces utilisateur (même concurrentes) au sein d'une architecture AAFID. Par exemple l'interface graphique utilisateur ("Graphical User Interface" - GUI) peut-être utilisée pour fournir des accès interactifs à l'IDS pendant qu'une interface basée sur des lignes de commandes tourne avec des scripts afin d'automatiser certaines fonctions de maintenance et de rapport.

2.3. Mécanismes de communication

La transmission de messages entre les différentes entités est un point central dans le fonctionnement d'un système AAFID. Si cette communication devient instable, le système cesse de fonctionner. Bien que l'architecture AAFID ne spécifie pas de mécanismes de communication, il existe un minimum de caractéristiques que l'on considère comme souhaitables. Quelques considérations plus détaillées sur les compromis à faire de même que sur les alternatives d'implémentation sont présentes dans la section 4.1..

Nous considérons les lignes suivantes comme étant des points importants concernant les mécanismes de communication utilisés dans un système AAFID :
- Des techniques appropriées doivent être utilisés pour répondre aux différents besoin en matière de communication. En particulier, les communications au sein d'une station peuvent s'effectuer par d'autres moyens qu'un trafic à travers le réseau.
- Les mécanismes de communication doivent être efficaces et sûrs, dans le sens où il ne faut pas ajouter de flux significatifs en plus des activités courantes des machines, et répondre aux attentes vis-à-vis de l'acheminement des messages qui doit se faire rapidement et sans altération.
- Ces mécanismes doivent prendre en compte des considérations en matière de sécurité c'est-à-dire qu'ils doivent résister aux tentatives (soit par des attaquants extérieurs, soit par des utilisateurs légitimes abusant de leurs droits) le rendant inexploitable (par déni de service par exemple), et doivent fournir des mécanismes d'authentification ET de confidentialité.

Les sujets liés à la sécurité des communications, à la sécurité distribuée et à la sécurité sur les agents autonomes ont déjà été étudiés [6][13] et certains de ces travaux peuvent être utilisés dans les implémentations AAFID afin d'obtenir des canaux de communication qui offrent les caractéristiques attendues.

2.4. Autres idées et composants possibles

Dans notre étude sur l'élaboration de l'architecture de notre système, nous avons exploré quelques composants. Nous allons nous attarder sur deux d’entre eux : le protocole SNMP ("Simple Network Management Protocol") et l'audit ("router audit"). Nous traitons également des atouts et inconvénients de l'utilisation de ces composants dans notre système. Ils ne font pas partie intégrante de notre architecture AAFID.

2.4.1. Le Protocole SNMP

Le "Simple Network Management Protocol" [21] est un protocole élaboré afin de faciliter la gestion des informations entre les différents dispositifs d'un réseau.
Le modèle SNMP comprend deux entités :
- le "Network Management System" - NMS
- et les éléments administrés.

Un agent SNMP fonctionne sur chaque dispositif administré et un gestionnaire SNMP s'exécute sur les machines appartenant au réseau qui va être supervisé. Le logiciel appelé agent SNMP est typiquement élaboré dans le but de minimiser son impact sur les dispositifs impliqués. Les NMS qui font tourner le logiciel de gestion supportent la charge des informations et contiennent des applications permettant de présenter la gestion des données aux utilisateurs (par exemple un GUI). La base de données de gestion des information ("Management Information Base" - MIB) est une base de données qui spécifie les variables exploitées par les agents et que l’administrateur peut interroger ou modifier [26]. Il existe quatre opérations de base : get et getnext pour la récupération des informations, set pour modifier ou fixer les informations et trap pour la manipulation des évènements asynchrones.

Le modèle SNMP peut être utilisé pour l'implémentation de l'architecture AAFID. Les transmetteurs peuvent être implémentés comme des agents SNMP alors que le fonctionnement des moniteurs peut s'effectuer par un SNMP NMS ("Network Management System"). On peut donner un identifiant unique aux agents autonomes (à ne pas confondre avec les agents SNMP) dans une base de données MIB spécialement élaborée pour cette utilisation. Ces objets identifiant peuvent offrir des paramètres au sein de la MIB dont les valeurs représentent l'état de l'agent autonome et peuvent être gérées par un NMS.

Les transmetteurs peuvent communiquer avec le moniteur en envoyant des alarmes SNMP. Les agents autonomes communiquent avec ces transmetteurs en positionnant leurs valeurs correspondantes. Utiliser SNMP pour implémenter l'architecture AAFID peut offrir des possibilités intéressantes. Cependant, il existe un certain nombre de questions importantes qui doivent être explorées, notamment en termes de sécurité, de tolérance aux fautes, de facilité d'extension et de déploiement de cette implémentation.

2.4.2. Routeurs d’audit

Les systèmes d'audit ("System audit trails") sont une source essentielle d'information pour un IDS. Toutefois, des problèmes interviennent lorsque plusieurs enntités différentes (comme des agents dans une architecture AAFID) essaient d'accéder les uns aux autres simultanément. Il peut être utile de posséder un mécanisme aidant à distribuer l'information aux entités qui le nécessitent. Nous décrivons maintenant quelques possibilités ayant pour but d'implémenter un tel mécanisme.

Le premier et le plus simple des cas, est de transmettre tous les enregistrements d'audit à tous les agents et de les laisser sélectionner ceux dont ils ont besoin. Le problème avec ce système est que chaque agent doit traiter la totalité de "l'audit trail" ce qui est probablement un gaspillage des ressources des processeurs.

Une autre possibilité est de mettre à la disposition des agents un serveur permettant d'envoyer les enregistrements d'audit appropriés à chacun d'entre eux. Une version de cette approche a été utilisée avec succès sur un IDS : le IDIOT IDS [2][15]. On rencontre toutefois un problème : ce modèle supporte uniquement les mécanismes dits "push" des interactions client-serveur. Cela signifie que le serveur envoie les événements aux agents dès qu'elles sont disponibles. Si un agent n'est pas prêt à les recevoir, ils sont perdus, à moins que les agents n'implémentent des techniques de synchronisation et de "buffering".

Nous proposons l'utilisation d'un autre mécanisme utilisant un "audit trailer" central. Ce routeur exécute la plupart du travail et fournit aux agents des mécanismes permettant de recevoir seulement les informations qui les intéressent.

Ce routeur d’audit central maintient une base de données d'agents et des classes d'audit dont il a besoin et des routines comme la gestion des buffers (Figure 2). Les agents doivent s'enregistrer auprès du routeur et lui donner des informations au sujet du type de classes indispensables à l'audit. En effectuant cette tâche, ils reçoivent un rapport en retour. Les agents peuvent ensuite simplement lire ce rapport lorsqu'il est prêt à recevoir de nouveaux événements. Quand l'agent stoppe cette opération, le routeur retire les informations le concernant de sa table de routage. Cette technique implémente un modèle de type "pull". La contrepartie est que le routeur d'audit devient plus complexe, à cause de la gestion des buffers et des autres tâches associées. Cette technique peut aussi supporter un modèle "push" en permettant aux agents de spécifier une fonction de retour pouvant être invoquée par le routeur d'audit lorsque certains types de données sont reçus.

Une façon d'implémenter un modèle de routeur d'audit est de séparer l'audit en différents buffers. Le routeur d'audit maintient pour chaque agent une liste de positions dans le buffer approprié. Lorsqu'un enregistrement d'audit est demandé, le routeur retourne l'enregistrement suivant dans l'ordre chronologique à partir du buffer.

figure 2 : Modèle du routeur d’audit. Le routeur d’audit agit comme un intermédiaire entre les fichiers d’audit et les agents.

2.5. Inconvénients de l'architecture AAFID

Nous avons identifié plusieurs défauts dans l'architecture AAFID que nous proposons.
- Dans leur rôle de contrôle, les moniteurs sont des points particuliers de failles. Si l'un d'entre eux s'arrête de fonctionner, tous les émetteurs qu'il contrôle s'arrêtent de produire les informations utiles. Ceci peut être résolu via une structure hiérarchique où la faille d'un moniteur serait annoncée par les moniteurs de plus haut niveau et des mesures pourraient être prises pour lancer un nouveau moniteur et examiner la situation qui est à l'origine de la faille du premier moniteur. Une autre possibilité est d'établir des moniteurs redondants qui s'occupent des mêmes transmetteurs de telle sorte que si l'un d'entre eux n'est plus opérationnel, les autres peuvent reprendre la situation en main sans interrompre les activités en cours.
- Si des moniteurs supplémentaires sont utilisés pour permettre une redondance, intervient alors un problème de concision et de duplication des informations. Des techniques doivent être employées afin de s'assurer que les moniteurs redondants vont garder la même information, obtenir les mêmes résultats et n’interféreront pas avec les opérations classiques de l'IDS.
- L'architecture actuelle d'AAFID ne spécifie pas de mécanismes de contrôle d'accès permettant à différents utilisateurs d'avoir des accès de niveau différent à l'IDS. Ceci est une question qui peut toucher également l'accès aux moniteurs, aux émetteurs, aux agents de même qu'aux interfaces utilisateur.
- La détection d'intrusion au niveau du moniteur est retardée jusqu'à ce que les informations provenant des agents et des émetteurs soient reçues. Cela est un problème commun à tous les IDS distribués.

3. Implémentations

Nous avons développé deux prototypes basés sur une architecture AAFID et nous sommes actuellement dans l’étape de test de ces implémentations, mais aussi de développement de nouvelles possibilités.

3.1. Premier prototype

Le premier prototype que nous avons mis au point a été programmé grâce à une combinaison de Perl [28], de Tcl/Tk [18] et de C [14]. Il était destiné à valider le concept de notre architecture. Dans cette implémentation, que nous avons appelé AAFID1, la plupart des composants ont été codés de manière "hard" et il ne sont pas véritablement configurables. AAFID1 utilisait UDP comme technique de communication inter-hôtes et des messages Solaris pour les communications intra-hôtes. Près de douze agents ont été développés pour ce prototype dans le but de détecter différents types d'activités intéressantes. Ce prototype nous a permis :

- de montrer que l'architecture AAFID pouvait fonctionner pour faire de la détection distribuée afin de détecter des événements anormaux,

- de gagner de l'expérience en développant des agents, nous permettant d'identifier les fonctionnalités de base nécessaires à tous les agents,

- d’identifier les problèmes de conception pouvant être améliorés. Par exemple le premier prototype intègre le moniteur et le GUI dans un seul programme ce qui, nous l'avons constaté est une limitation dans la mesure où il ne permet pas l'organisation hiérarchique des moniteurs.

3.2. Deuxième prototype

Forts de l'expérience acquise lors de l'étude du premier prototype, nous en avons développé un deuxième en repartant de zéro et nous l'avons appelé AAFID2. Ce prototype est exclusivement écrit en Perl, ce qui est un avantage pour sa portabilité sur d'autres architectures, au prix toutefois d'une baisse des performances. L'objectif principal de cette implémentation est de pouvoir faire de nombreux tests de l'architecture, c'est pourquoi des efforts ont été faits dans cette direction (plus de possibilités de configurabilité et d'extensibilité). Parmi les améliorations de cette implémentation, on peut citer :
- l'augmentation de la portabilité due à la programmation uniquement en Perl,
- l'implémentation d'une infrastructure fournissant les services de base nécessaires au développement de nouvelles entités,
- la définition d'une API interne afin de pouvoir développer de nouveaux agents,
- une séparation nette entre les différentes techniques de communication en interne et les autres éléments dépendant de la plate-forme,
- une définition claire de chaque entité en tant qu'objet et des relations entre les différentes classes d'objets,
- différents modes d'exécution des entités (à la fois pour les modules exécutables et pour les programmes tournant de manière continue en fond de tâche) qui facilitent le développement, le test, et le débuggage de nouvelles entités,
- définition d'un format de message extensible pouvant être utilisé pour représenter différents types d'information. De plus, la manipulation des messages internes se fait par encapsulation de telle sorte qu'ils puissent être modifiés ou mis à jour à l'aide de répercutions mineures sur les autres éléments du système.
- séparation du moniteur et de l'interface utilisateur.

Cette implémentation constitue actuellement notre meilleur banc de test pour cette architecture et il s'agit de la seule pour laquelle nous ayons développé de nouveaux agents et exploré de nouvelles techniques de communication et de réduction des données. On pourra trouver une description plus détaillée d'AAFID2 dans le document [23].

3.3. Implémentations de bas niveau

Les deux premiers prototypes nous ont aidés à affiner notre architecture mais aussi à identifier les besoins et les problèmes à résoudre. Cependant, nous n'avons pas insisté sur les performances car les prototypes ont été implémentés avec des scripts écrits dans des langages de haut niveau, comme Perl, qui offre de vastes possibilités de traçabilité de la mémoire et du CPU. Pour cette raison, étant donné que l'architecture commence à se stabiliser, nous avons entamé l'étude d'une architecture portable sur des systèmes peu élaborés. En particulier, nous travaillons actuellement sur l'incorporation de composants de l'architecture AAFID sur des noyaux UNIX mais également sur l'ajout de possibilités d'audit et de "monitoring" sur le noyau Linux. Nous travaillerons probablement aussi avec Solaris, BSD/OS et Windows NT. D'autres avantages et inconvénients de cette approche de bas niveau seront décrits dans la section 4.2.

4. Expériences, commentaires et problèmes de conception

A travers les expériences acquises avec AAFID (voir section 3 et document [23]), nous avons identifié un certain nombre de problèmes pouvant être sujet de travaux futurs.

Ces soucis peuvent être classés dans les différentes catégories suivantes : communication entre les différents composants de l'IDS, impact de l'IDS sur les performances de la station supervisée et design de l'interface utilisateur. Ils seront traités dans cette section.

4.1. Communication et Elasticité

Afin de réduire la charge imposée par l'IDS, les mécanismes de communication utilisés doivent être le plus efficace possible.

Nous pouvons classer les besoins en matière de communication en deux groupes principaux : intra-hôtes (entre les processus d'une même station) et inter-hôtes (entre des processus tournant sur des hôtes différents).

4.1.1. Communication intra-hôtes

Bien que les techniques globales de communication intra-hôtes peuvent être utilisées pour les dialogues entres entités d'une même station, nous pensons qu'une solution optimale serait d'utiliser le fait que les entités impliquées font partie du même hôte. Pour l'architecture de notre IDS, nous avons identifié deux types principaux de communication intra-hôtes :
- l'émission d'un message vers plusieurs agents
- l'émission de plusieurs agents vers un transmetteur.
En gardant ces considérations à l'esprit, nous avons traité plusieurs solutions :

Les piles de messages. Ce mécanisme utilise le système V IPC pour établir des piles de messages. Celles-ci fournissent une méthode de transmission des messages de type asynchrone entre les process et constituent une méthode efficace de transfert de petites quantités de données ou de messages entre ces process. Lorsqu'un process envoie à un autre un message, le noyau copie la donnée dans une pile de mémoire qu'il a alloué à cette utilisation. Lorsque le process récepteur requiert de récupérer un message, le noyau copie alors le message à l'adresse ou se situe l'emplacement alloué au récepteur. Ainsi, chaque transfert de message nécessite deux opérations de copie des données, ce qui peut impliquer une diminution des performances lorsque les messages circulant deviennent imposant.

Le défaut majeur des piles de messages est que l'on est limité à une certaine quantité de mémoire au sein du noyau. Pour cette raison, le nombre maximum de messages à un moment donné est relativement faible. Pour Solaris 2.5 et antérieur, ce nombre est 40 par défaut. La conséquence de cette limitation en termes de ressources est que cette méthode est vulnérable aux attaques par déni de service puisque n'importe quel process tournant sur le même système peut créer une file d'attente de messages et la remplir sans jamais venir la lire. Cet acte anihilerait toute communication entre les agents et l'émetteur. De plus, ces restrictions imposent des limites pratiques sur le nombre d'agents pouvant fonctionner simultanément sur le sytème. Ces problèmes peuvent être partiellement résolus en utilisant des piles de messages jusqu'à atteindre leur limite pour ensuite commuter vers une autre méthode - probablement plus lente - de communication. Cependant, on peut penser que cela ne résoudra pas les problèmes d'adaptation du sytème à la dimension de l'architecture.

Un avantage de cette approche est qu'elle est relativement simple à l'implémentation et qu'elle fournit un mécanisme de priorité des messages assure que les messages des agents seront traités immédiatement. Bien que cette approche ait été utilisée lors des premiers prototypes, elle ne sera très certainement pas utilisée dans les prochaines versions de notre système, principalement à cause du manque d'élasticité et de sa vulnérabilité aux attaques.

La mémoire partagée. Cette technique fournit un moyen efficace de partage des données entre deux process car la donnée n'est pas copiée d'un process à l'autre. Ceci est du au fait que, comme le nom le suggère, de multiples entités partagent les mêmes pages mémoires. Chaque process a une trace du même espace physique et peut référencer cet espace à travers des pointeurs (à l'intérieur du code). Bien que cette méthode présente une nette amélioration du système de gestion des files d'attente de messages pour les agents transmettant des messages longs, les avantages et problèmes restent sensiblement identiques. Comme la technique des files d'attente de messages, celle-ci nécessite qu'un bloc spécifique de la mémoire du noyau soit alloué afin de stocker la totalité des données partagées par les process. Par exemple, dans Solaris 2.5 et les versions antérieures, le noyau tente d'empêcher l'allocation d'un espace mémoire trop important en autorisant seulement 25% de sa mémoire totale disponible. A cause de cette limite physique, ce principe est aussi vulnérable aux attaques par déni de service et les files d'attentes, comme les attaques doivent être de plus en plus sophistiquées. Finalement, cette technique introduit également une limite pratique sur le nombre d'agents pouvant tourner simultanément sur un système.

En se penchant sur nos besoin en termes de communication, la méthode de la mémoire partagée semble adéquate pour les communications de type "émission d'un message vers plusieurs agents" où les transmetteurs viendraient écrire dans la mémoire partagée et où les agents auraient un accès en lecture seule à celle-ci. Ceci étant dit, un nouveau problème apparaît : celui de l'impossibilité pour un émetteur de notifier à un agent qu'il a reçu de nouvelles informations.

Tubes. Dans les implémentations traditionnelles d'UNIX, un tube ("pipe" en anglais) est unidirectionnel, de type FIFO ("First-In First-Out"), présentant des flux de données non structurés mais de taille maximale fixe [27]. La donnée est écrite à la fin du tube et lue à l'entrée du tube. La donnée est retirée du tube après lecture. Chaque process fils hérite des descriptions de lecture et d'écriture des fichiers retournées par le système de tube. Ce dispositif autorise plusieurs process de lecture et d'écriture sur un même tube. Un autre type classique de tube disponible sur un système V UNIX nommé "named pipe" existe. Bien qu'ils se comportent de manière similaire aux tubes traditionnels, ils diffèrent dans la façon dont ils sont conçus et dont ils sont accessibles. SVR4 utilise un mécanisme de flot pour implémenter ce type de tube. Une différence majeure réside dans le fait qu'un tube SVR4 est bidirectionnel. Chaque type de tube peut être utilisé pour les communications entre des entités tournant sur un même hôte. Un désavantage de ce type de tube est qu'il existe une limite interne sur le volume de données pouvant être contenu dans un tube si le process ne le retire pas. Si cette limite est atteinte, le process d'écriture se bloque ou échoue. De même, le process de lecture se trouve dans la même impasse si il tente de lire un tube vide.

Utiliser des tubes pour faire communiquer des dispositifs offre cependant plusieurs atouts. Ils sont relativement simples à implémenter et toutes les versions modernes d'UNIX implémentent les deux types de tube. Parce que les tubes peuvent être accessibles via la manipulation de fichiers, il sont extrêmement flexibles vis à vis de la manière dont les composants d'un sytème distribué peuvent être employés et interconnectés. Cela permet également d'isoler les composants des mécanismes de communication utilisés. D'autres systèmes d'exploitation (comme Windows NT) fournissent également des techniques de tubes bien que les mécanismes spécifiques permettant leur établissement et leur accès soient quelque peu différents et demandent à être étudiés avant de porter des programmes utilisant des tubes sur ces systèmes.

Indépendamment de la technique de communication utilisée, l'IDS nécessite un contrôle d'accès aux canaux de communication. Tous les mécanismes mentionnés ont la capacité de réaliser des contrôles d'accès par les moyens suivants :
- Pour les piles de messages et la mémoire partagée, le process qui gère la pile ou la mémoire partagée établit les modes d'accès dans une structure similaire aux modes d'accès des fichiers système sous UNIX.
- Pour les tubes UNIX classiques, le tube est uniquement accessible par le process qui le crée et par ses fils et il est par définition inaccessible par tout autre process.
- Pour les tubes dits "named pipes", le contrôle d'accès est réalisé par le fichier des permissions d'UNIX car les mécanismes sont uniquement accessibles à partir des entrées du système de fichiers UNIX.

En conclusion, bien que certaines de ces techniques paraissent prometteuses, elles doivent être étudiées avec attention avant de décider de l'intégration de l'une d'entre elles. Il peut être possible d'utiliser plus d'une technique de communication (cela dépend de la situation).

4.1.2. Communications inter-hôtes

Les caractéristiques principales à traiter dans les techniques de communication au sein d'un IDS sont les suivantes : Performance, Fiabilité, Sécurité.

Performance. Pour que l'IDS fonctionne en temps réel, les messages doivent être délivrés le plus rapidement possible d'un endroit du système à un autre, mais sans surcharger le réseau lorsque plusieurs agents tournent en même temps. Ainsi, les techniques de communication employées doivent être capables de fournir de bons temps de transmission sans générer de surcharge.

Fiabilité. Le fait que les messages envoyés d'un hôte à un autre parviennent correctement dans l'ordre et en temps voulu peut éventuellement être une question primordiale pour les IDS. Si on peut estimer la quantité maximum de messages perdus, on doit également être capable d'estimer convenablement la dégradation du service. Malheureusement, la définition du mot "acceptable" dépend de l'endroit où le système est déployé.

Sécurité. Le respect de la vie privée et l'authentification sont des besoins importants pour un IDS parce que certains des messages générés par celui-ci peuvent contenir des données sensibles concernant les hôtes supervisés. Les accesseurs illégitimes ne doivent pas être capable de générer des messages exploitables par les composants de l'IDS.

Habituellement, la cryptographie est la solution à ces deux problèmes. Cependant, elle n'est pas sans coût pour les performances du système. La possibilité d'attaque par déni de service est un autre problème de sécurité où l'attaquant rend l'acheminement des messages difficile voire impossible. Il est important de noter que même si un intrus n'est pas capable de couper totalement les communications, le fait de simplement pouvoir les retarder peut devenir une faille d'une importance extrême.

Voici certaines questions que l'on peut se poser et qui peuvent aider à décider des meilleures approches à suivre en terme de sécurité :
- Est-ce que le respect de la vie privée est ici nécessaire ? Bien que nous ayons mentionné que la plupart des messages pouvaient contenir des informations sensibles, ce ne sera pas le cas si les composants et la sémantique sont élaborés soigneusement.
- Est-ce que l'authentification est nécessaire ? La question ne se pose même pas puisque l'on ne veut pas qu'un imposteur génère de faux messages et les envoie vers les moniteurs.

- Comment les implémenter ? Si une certaine forme de cryptographie est jugée nécessaire, il existe différentes manières de le faire. Suivant le choix fait parmi les algorithmes, il peut en résulter des performances finales différentes. Par exemple, si le chiffrement est effectué seulement entre le moniteur et le transmetteur et que les agents opèrent des rapports uniquement vers les transmetteurs locaux, alors le codage peut s'effectuer dans des scripts dits "batches" en envoyant plusieurs messages de manière périodique au lieu d'encoder et d'envoyer chaque message individuellement. Cette méthode peut produire une amélioration des performances mais présente néanmoins un problème : certains messages peuvent être étiquetés comme 'Urgent' et ne peuvent donc pas attendre. Tous ces problèmes doivent être résolus dans nos prochains travaux d'implémentation.

Une autre possibilité est de faire du chiffrement sélectif. Si seuls certains messages sont considérés comme sensibles, on peut gagner en performances en utilisant un mécanisme permettant de spécifier les messages à chiffrer et ceux qui ne le nécessitent pas. Bien sûr, cela présente des problèmes techniques. Par exemple, toutes les entités impliquées dans une communication doivent être capables de détecter quel type de transmission est réalisée et agir en conséquence. Un point encore plus problématique se situe sur la sélection de ce qui doit être chiffré et ce qui ne doit pas l'être.

Les problèmes mentionnés ci-dessus posent un certain nombre de questions dont les réponses dépendent de l'approche spécifique suivie. Actuellement, nous voyons deux solutions :
- Utiliser un protocole existant (comme UDP ou TCP) en prenant en compte ses faiblesses pour récupérer les fonctionnalités dont nous avons besoin. Cela a pour avantage que le protocole de base existe déjà, nous savons comment l'exploiter et savons également qu'il est bien supporté. Les inconvénients sont sa non fiabilité (dans le cas de UDP), la surcharge (en-tête) nécessaire à la fiabilité (dans le cas de TCP) et le manque de caractéristiques comme l'absence de chiffrement.
- Elaborer un nouveau protocole en ayant les besoins de l'IDS en tête. Un tel protocole doit pouvoir fournir des transmissions fiables, avec peu d'en-tête et plusieurs mécanismes de sécurité. Les avantages, en partant dans cette dernière direction, est que le protocole pourrait être découpé et adapté particulièrement suivant nos besoins spécifiques. L'élaboration du protocole lui-même n'est pas une tâche évidente (implémentation, tests complets et déploiement) ce qui représente un gros inconvénient.

Un des aspects les plus difficiles dans l'élaboration d'un protocole de communication pour la détection d'intrusion est de déterminer un compromis correct entre les différents facteurs (efficacité, sécurité, etc.) de telle sorte que le protocole respecte chacun d'entre eux. Nous percevons cela comme une extension dans nos futurs travaux de recherche.

Après avoir exprimé notre avis sur les communications inter-hôtes, particulièrement celles en rapport avec les performances et l'extensibilité, nous arrivons à une question plus fondamentale : Avons nous vraiment besoin de nous inquiéter ? Plus précisément, atteindrons-nous toujours notre objectif si des milliers d’hôtes communiquent ? Nous pouvons affirmer que si une organisation hiérarchique appropriée est utilisée, cela n'arrivera jamais. Par exemple, si le système est structuré de telle sorte que seul un sous-réseau puisse se reporter à un unique moniteur et que ces moniteurs, à leur tour, ne peuvent que se reporter à d'autres moniteurs de plus haut niveau, le problème ne sera pas aussi important que nous l’avons suggéré précédemment. Dans ce cas, la sécurité et la fiabilité des communications serait une priorité.

Finalement, le niveau d'efficacité que nécessite les protocoles de communication dépend du niveau de réduction que l'on peut atteindre sur les données qui transitent. Si cette réduction est faite de telle sorte que la quantité d'information réellement envoyée à travers le réseau soit limitée alors l'efficacité peut devenir un soucis secondaire.

4.2. Impact sur les performances des hôtes

Dans les premières architectures AAFID, toutes les entités sont implémentées en tant que process séparés. Cependant, la plupart des données collectées et analysées est généré dans le noyau (par exemple, les informations sur les "logins" des utilisateurs, la gestion des process, l’établissement des connections réseau). Cela signifie qu'à chaque fois qu'une action du système doit être notifiée voire analysée, l'information doit être transmise à partir du noyau vers l'espace utilisateur, incluant des commutations et augmentant la charge imposée sur le système par l'IDS. Lorsque le nombre d'agents tournant sur un hôte augmente, la charge des en-têtes commence à influer sur le comportement normal des machines. Ceci est particulièrement vrai si certaines parties de l'IDS sont écrites en langages à base de script comme Perl ou Tcl/Tk qui sont en général consommateurs de ressources.

Une approche visant à réduire la surcharge créée par l'IDS serait d'écrire tous les composants dans un langage compilé comme le C. Cela réduirait probablement l'utilisation qui est faite de la mémoire et du CPU mais ne résoudrait pas le problème lié à la commutation ou bien ceux issus de l'extension du réseau (surcharge provenant de différents process tournant simultanément).

Un autre pas pourrait être franchi en utilisant un langage supportant le multitâche et en implémentant chaque agent en tant que tâche indépendante au lieu d'en faire des process indépendants. Qui plus est, ceci réduirait en plus la charge par agent sans toutefois résoudre les problèmes de commutation.

Le niveau le plus bas que nous pourrions atteindre serait d'intégrer certains composants au noyau UNIX. Par exemple, un moniteur chargé de superviser les connections réseau pourrait lire directement la structure de données de manière pertinente au lieu d'avoir à exécuter la commande netstat continuellement. Il en est de même pour les comptes rendus de process, les accès fichiers, etc.

Intégrer les agents au noyau réduirait beaucoup de problèmes :
- On éviterait un contexte de commutation puisque les agents tourneraient au sein du noyau lui-même.
- L'information serait enregistrée et traitée à l’endroit même où elle est générée (ou au pire juste à côté); ainsi, cela réduit les possibilités d'attaques et de modification par un intrus du fait que l'information ne parviennent pas à l'agent.
- Il devient difficile pour un intrus de "bidouiller" avec les agents parce qu'à ce moment, le noyau lui même doit être modifié.

Les transmetteurs pourraient également être inclus au noyau. De cette façon, les données n'auraient plus besoin d'être transmises hors du noyau à moins que le transmetteur ne décide de les envoyer à un moniteur afin de procéder à des calculs plus poussés ou pour effectuer une notification.

L'approche qui vient d'être décrite présente également les inconvénients suivants :
- Créer des entités en tant que composants d'un noyau anéanti complètement l'aspect portable des agents car ils doivent alors être élaborés et implémentés en gardant à l'esprit un système d'exploitation particulier. Il n'existe pas deux versions UNIX exploitant un noyau interne identique. Le problème est encore pire si l'on porte l'IDS sur un système d'exploitation non UNIX.
- Une entité qui se comporte anormalement (soit intentionnellement soit par des erreurs de programmation ou de configuration) peut faire plus de dégâts s'il tourne au sein du noyau car il dispose alors d'un accès total au système.
- Les entités du noyau peuvent avoir un impact important sur le comportement des hôtes en ralentissant les opérations fondamentales (par exemple les accès disque et mémoire et les accès aux structures de données du noyau) ou en perturbant les repères temporels des opérations critiques de bas niveau. C'est pourquoi les entités intégrées au noyau doivent être élaborées, implémentées, et débuggées avec attention.
- Le problème essentiel est que les ressources à disposition des entités dans le noyau sont très limitées et certainement insuffisantes. Par exemple, un agent chargé de scruter les paquets IP nécessite une grande quantité de mémoire afin de stocker un nombre suffisant d'informations pour pouvoir superviser tous les événements nécessaires à la détection d'attaques de type "SYN-flood". Un travail préliminaire indique qu'il n'est probablement pas possible de développer des agents distincts et indépendants au sein du tout en réalisant des tâches complexes à moins qu'ils ne soient étroitement liés au code du noyau lui-même. Cet effet et particulièrement visible si les agents supervisent les communications d'un réseau.

Bien que les résultats achevés à ce jour semblent indiquer qu'il ne serait pas réalisable de développer des agents au sein du noyau, nous continuerons toutefois d'explorer les potentialités présentes dans cette direction (voir en Section 3).

4.3. Traitement des données et réduction

Pour créer des agents aussi légers que possible, nous devons utiliser plus qu'un simple élément pour transmettre les données aux émetteurs qui à leur tour regroupent les données provenant de tous les agents pour les envoyer vers les moniteurs concernés où tout est traité et où les actions appropriées sont lancées. Ceci fut l'approche utilisée dans le premier prototype. Toutefois, cette technique emploie une quantité importante de trafic qui limite l’élasticité du système.

La solution serait de déplacer la charge des moniteurs vers les transmetteurs et vers les agents de telle sorte que les entités locales à la station commencent un travail de traitement et de réduction sur les données et reportent aux moniteurs uniquement les informations pertinentes. Ceci peut être poussé à l'extrême en faisant de chaque transmetteur un IDS local communiquant avec les moniteurs comme un IDS global plus large. Malheureusement, cela a un impact sur les hôtes surveillés car le traitement local risque de ralentir les autres applications tournant sur celui-ci. Autre problème : décider de l'endroit où sera stocké l'état de l'IDS. Dans l'approche centralisée, tous les paramètres sont stockés au sein d'un écran de contrôle central. C'est pourquoi, si cette machine est mise hors service, compromise ou détruite, l'état de toutes les stations qui dépendent de ce moniteur est perdu. D'un autre côté, si chaque hôte a son propre moteur, l'information est distribuée sur plusieurs hôtes ce qui rend la perte de toutes ces données plus difficile. L'inconvénient est que réaliser une image de l'état global de l'IDS devient plus difficile.

Nous pensons que la meilleur approche est d'essayer de trouver un compromis entre ces deux extrêmes. Une étude plus détaillée des performances peut nous aider à prendre une décision sur la manière dont peuvent être distribués les calculs entre agents, transmetteurs et moniteurs afin de maximiser le débit et l'extensibilité du système sans imposer de charge excessive aux hôtes ou au réseau.

4.4. Interface utilisateur

Comme nous l'avons mentionné précédemment, n'importe quel IDS est inutile s'il n'offre pas aux utilisateurs de bons mécanismes de contrôle et de supervision ("monitoring"). Dans notre cas, l'interface utilisateur doit prendre en compte un problème classique : comment interfacer avec un utilisateur un système très rapide, distribué, tournant en permanence mais qui ne peut analyser rapidement un large volume de données tout en étant sur ses gardes 24h/24h en contrôlant tout.

Les approches traditionnelles où une fenêtre affiche une liste d'hôtes en cours d'observation et où l'utilisateur peut observer chacun d'entre eux en détail fournit uniquement une forme rudimentaire de contrôle sur ce qui se passe sur les éléments distribués de l'IDS et n'est pas très extensible. En soulignant cet inconvénient, on constante qu'un autre problème plus profond apparaît : comment faire en sorte qu'une personne puisse observer et contrôler un système difficilement contrôlable en partie à cause de son élaboration orientée vers lui-même et vers ses propres décisions. Ceci est un problème qui implique à la fois le format des données, l'application GUI, la communication, la sécurité et la consistance.

Nous pensons que les questions principales sont à ce stade :

1. Quelles informations concernant les entités de l'IDS sont nécessaires à l'utilisateur pour avoir une bonne image du système.

2. Comment transmettre efficacement avec fiabilité et consistance les informations à l'utilisateur.

3.Comment présenter les informations de manière utile. L'interface doit être capable de fournir à l'utilisateur plusieurs niveau de détail (d'une vue globale de haut niveau jusqu'aux paramètres des agents) de la manière la plus simple possible.

4. Comment permettre à l'utilisateur de fournir des retours et de contrôler les entités du système. Idéalement, cela doit être fait efficacement (rapidement), avec fiabilité (résistant aux défauts), sûrement (résistant aux tentatives d'accès illégitimes), en permettant l'audit (possibilité d'observer qui fait quoi) et la gestion (compréhensive pour l'utilisateur).

5. Comment rendre l'interface réactive. L'utilisateur peut vouloir visualiser immédiatement les effets des changements effectués et être averti immédiatement lorsque quelque chose d'intéressant se produit.

6. Comment effectuer un compromis permettant de fournir à l'utilisateur suffisamment de rapports intéressant (historiques).

Nous n'avons pas étudié en détail l'interface utilisateur et elle fait partie de nos prochains travaux.

5. Travaux à venir

Dans cette section nous identifions les lignes directrices de nos travaux (actuels et futurs). Nous décrivons à court et à long terme les points que nous avons jugés intéressants.

5.1. Travaux en cours et à cours terme

Des travaux sont actuellement en cours dans les laboratoires COAST sur les domaines suivants :

Développement d'agents. Nous développons actuellement un grand nombre d'agents couvrant des activités d'observation les plus larges possibles. Ceci nous permettra de découvrir les limites et les atouts de notre système au cours de l'élaboration des interfaces internes et des services fournis par les agents.

Implémentations de bas niveau. Bien que le travail préliminaire mentionné en Section 4.2. n'a pas été concluant les bénéfices issus des composants basés sur le noyau méritent plus d'approfondissements. Le développement d'agents permettant de surveiller et d'identifier les comportement anormaux est également un domaine prometteur à explorer. Il a été démontré [7] qu’il est possible de détecter certaines intrusions classiques en opérant des corrélations à courte distance sur des appels à des process du système.

Implémentations de haut niveau. Le dernier prototype de haut niveau mentionné en Section 3. est actuellement en développement et en cours d'implémentation. Nous espérons que l'expérimentation de ce prototype nous aidera à identifier les forces et les faiblesses de notre produit. De plus, les leçons acquises des implémentations de haut niveau pourront nous servir plus tard pour celles de bas niveau (plus performantes).

Mécanismes de communication. Nous avons l'intention d'aller plus loin dans l'exploration des techniques de communication intra et inter hôtes à l'intérieur et à l'extérieur du noyau UNIX. Les interfaces de communication doivent également être définies afin de permettre plus de modifications de ces techniques de communication sans avoir à modifier les programmes qui les utilisent. Par ailleurs, des considérations sur la sécurité seront incorporées à ces mécanismes avant de déployer ce système.

Outils de développement. Une interface graphique utilisateur ("Graphical User Interface" - GUI) a été développée pour le prototype de haut niveau. La version existante de ce GUI fournit un accès et des fonctions de contrôle simples mais il s'agit d'un premier pas dans l'identifications des problèmes qui pourraient être explorés plus tard. Des outils facilitant le développement d'agents sont également en étude. Ces outils fournissent des générateurs semi-automatiques de code dans le but d'aider le débuggage des nouveaux agents.

Développement et tests. Le meilleur moyen de tester notre architecture est de permettre à tous de l'utiliser. Nous avons planifié d'ouvrir notre dernier prototype à des "testeurs" sélectionnés d'abord puis au public ensuite afin de permettre de l'expérimenter, de tester le système et de nous renvoyer des retours afin que nous puissions améliorer notre produit.

Développement de transmetteurs et de moniteurs. Nous aimerions expérimenter différentes approches de réduction des données et de rapports incluant différentes fonctionnalités pour chaque composant dans des recherches orientées vers un compromis entre les calculs centralisés et les calculs locaux.

5.2. Travaux à moyen à terme

Une fois que les travaux en cours seront terminés, il y a certains points que nous aimerions traiter.

Sémantique de la communication. Jusque là, nous nous sommes attardés principalement sur les techniques et les aspects de l'architecture des communications. Toutefois, ce sont les aspects de la sémantique des communications (le contenu des messages) qui permet réellement la détection d'intrusion. Cela sera probablement l'objet de recherches lorsque l'architecture sera mise en place.

Réduction des données. Différentes approches peuvent être choisies pour contrôler la réduction des données aux niveaux agents, transmetteurs et moniteurs. Nous avons pensé à un procédé particulier dans lequel chaque agent "porterait" avec lui les codes de réduction des données nécessaires qu'il transmettrait à l'émetteur et au moniteur une fois déployé. Toutefois, cette approche néglige le fait que des événements provenant d'agents différents doivent être combinés et traités. Ce point doit également être approfondi.

Portage vers d'autres plates-formes. Nous avons l'intention de porter nos prototypes de haut niveau vers d'autres systèmes d'exploitation comme Windows NT. De plus, le développement de composants du noyau va probablement prendre place dans plusieurs systèmes d'exploitation. Parmi ceux-ci : Solaris, Linux et BSD/OS.

Chiffrement. Nous avons prévu d'évaluer avec précision l'utilisation du chiffrement pour la confidentialité et l'authentification des données. Les mécanismes qui seront jugés nécessaires seront implémentés en vue d'avoir un impact minimum sur les performance de l'IDS.

Extensions de l'architecture. En explorant notre prototype d'architecture AAFID, nous allons découvrir des aspects à modifier ou à étendre afin de fournir des fonctionnalités améliorées voir s’ajoutant au produit. Par exemple, permettre aux moniteurs de répondre automatiquement à certains événement en mettant en place des règles en l'absence de contrôleur humain serait une extension possible de notre architecture. Ces aspects seront traités lorsqu'ils seront rencontrés.

5.3 Travaux futurs à long terme

Finalement, nous pensons qu'il existe certains points importants qu'il faudra traiter à un moment donné de l'avancement de nos recherches mais qui ne font pas partie actuellement de nos projets.

Administration globale et configuration. Alors que l'IDS s'améliore et que le nombre d'hôtes capables d'être supervisés simultanément par les moniteurs augmente, configurer et contrôler tout à la main devient impossible. Des mécanismes pour configurer et administrer les entités à distance vont devenir nécessaires. Ils incluent :

- L'administration des moniteurs : les moniteurs exercent un contrôle sur les autres entités mais il doivent également être contrôlés d'une certaine manière. Comment déployer et contrôler ces moniteurs, comment déployer un code de détection, comment réagir face aux événements détectés et à qui les moniteurs doivent les reporter sont autant de questions à traiter dans le futur.

- Configuration des agents et des hôtes. On veut pouvoir ajouter ou retirer des agents dynamiquement. Par exemple, si une situation inhabituelle est détectée sur un hôte, on peut vouloir ajouter des agents supplémentaires en vue de procéder à une observation plus détaillée. Ceci peut être fait manuellement ou automatiquement et ces mécanismes peuvent être sujets à de futurs travaux intéressants.

Compromis sur les charges et contrôle des failles. Lorsqu'un IDS observe un réseau composé de centaines voire de milliers d'hôtes, les questions de charge et de contrôle des erreurs deviennent importantes. Par exemple, utiliser un seul moniteur pour contrôler un nombre important d'hôtes peut devenir improductif à la fois en termes de performances et en termes de sécurité. Les questions auxquelles on doit répondre à ce sujet sont :

- Comment opérer ce compromis sur la charge,

- Comment garder un état global concis. S'il y a plusieurs moniteurs, comment s'assurer qu'ils ont tous la capacité de détecter une intrusion pendant un état global donné de la situation.

- Comment opérer les communications parmi les entités de haut niveau. Dans le but de garder un état global, certaines communications doivent avoir lieu entre les moniteurs et peut-être même entre les transmetteurs.

Analyse des tailles optimales et maximales. Il est important de connaître les limites de l'architecture AAFID. C'est pourquoi il serait intéressant de réaliser des analyses afin de déterminer la taille maximale supportée de manière efficace (en termes d'hôtes, d'agents par hôte et de moniteurs). Connaître la taille optimale, taille pour laquelle l'IDS se comporte le mieux serait également intéressant pour le futur.

Fiabilité. Comment garder un état fiable de l'IDS entre les crashes et les redémarrages. Posséder des mécanismes fiables garantit que l'IDS sera alerté la plupart du temps et fournira donc une meilleure protection.

6. Conclusions

Nous proposons une architecture de système de détection d'intrusion appelé AAFID basé sur des entités appelées agents autonomes pour réaliser la collecte et l'analyse des données distribuées. L'analyse centralisée est effectuée "per-host" ou "per-network" par des entités de haut niveau appelées transmetteurs et moniteurs. L'architecture autorise le traitement des informations directement à l'endroit où elle est disponible, cela peut être au niveau de l'agent, du transmetteur ou du moniteur. Nous avons démontré la faisabilité de cette architecture par l'implémentation de prototypes qui fonctionnent. Le premier de ces prototype est décrit dans ce document alors que le second est décrit en détail dans le document [23].

L'architecture AAFID permet de collecter les données provenant de plusieurs sources différentes ce qui nous permet de combiner les caractéristiques des IDS basés sur les hôtes et des IDS basés sur la totalité du réseau. Cela nous permet également de construire un IDS plus résistants aux attaques par insertion et par évasion [20] que les architectures existantes, bien qu'aucun test n'ait été effectué pour confirmer ces considérations.

De plus, les caractéristiques modulaires de l'architecture la rendent facilement extensible, configurable et modifiable soit pour ajouter de nouveaux composants, soit en remplaçant certains d'entre eux lorsqu'ils nécessitent d'être mis à jour. Par exemple, il serait possible de modifier le système afin de produire des messages au format CIDF [25].

L'architecture AAFID présente toutefois plusieurs points étudiés lors des recherches sur les systèmes distribués classiques comme la capacité à s'adapter à l'extension du réseau, les performances et la sécurité. Des compromis entre efficacité, consommation des ressources et sécurité doivent être évalués et nous utiliserons les résultats obtenus lors de précédentes recherches pour implémenter les mécanismes nécessaires à AAFID (il s'agit de travaux en cours).

L'interface utilisateur fait partie de nos principaux axes de recherche pour les travaux à venir. La plupart du travail effectué dans le domaine de la détection d'intrusion lors de ces dernières années s’est concentré sur la manière de réaliser la détection, mais peu se sont orientés vers la présentation de l'information à l'utilisateur et vers la façon d'autoriser l'utilisateur à spécifier des politiques de sécurité que l'IDS puisse comprendre pour ensuite l’appliquer.

Références

[1] Jeffrey M. Bradshaw. An introduction to soft-ware agents. In Jeffrey M. Bradshaw, editor, Software Agents, chapter 1. AAAI Press/The MIT Press, 1997.

[2] Mark Crosbie, Bryn Dole, Todd Ellis, Ivan Krsul, and Eugene Spafford. IDIOT - Users Guide. COAST Laboratory, Purdue University, 1398 Computer Science Building, West Lafayette, IN 47907 - 1398, September 1996. Available at http://www.cs.purdue. edu/coast/coast-library.html.

[3] Mark Crosbie and Eugene Spafford. Defending a computer system using autonomous agents. In Proceedings of the 18th National Information Systems Security Conference, Oct 1995.

[4] Mark Crosbie and Gene Spafford. Active defense of a computer system using autonomous agents. Technical Report 95-008, COAST Group, Department of Computer Sciences, Purdue University, West Lafayette, IN 47907-1398, Feb 1995.

[5] Dorothy E. Denning. An Intrusion-Detection Model. IEEE Transactions on Software Engineering, 13(2):222{232, February 1987.

[6] William M. Farmer, Joshua D. Guttman, and Vipin Swarup. Security for mobile agents: Issues and requirements. In Proceedings of the 19th National Information Systems Security Conference, volume 2, pages 591-597. National Institute of Standards and Technology, October 1996.

[7] Stephanie Forrest, Steven Hofmeyer, Anil Somayaji, and Thomas Longsta. A sense of self for Unix processes. In Proceedings of the 1996 IEEE Symposium on Security and Privacy. IEEE, IEEE Computer Press, 1996.

[8] Stephanie Forrest, Steven A. Hofmeyr, and Anil Somayaji. Computer Immunology. Communications of the ACM, 40(10):88{96, October 1997.

[9] R. Heady, G. Luger, A. Maccabe, and M. Servilla. The Architecture of a Network Level Intrusion Detection System. Technical report, University of New Mexico, Department of Computer Science, August 1990.

[10] L. Heberlein, G. Dias, K. Levitt, B. Mukherjee, J. Wood, and D. Wolber. A Network Security Monitor. In Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1990.

[11] Judith Hochberg, Kathleen Jackson, Cathy Stallings, J. F. McClary, David DuBois, and Josephine Ford. NADIR: An automated system for detecting network intrusion and misuse. Computers and Security, 12(3):235-248, May 1993.

[12] Willian Hunteman. Automated information system - (ais) alarm system. In Proceedings of the 20th National Information Systems Security Conference. National Institute of Standards and Technology, October 1997.

[13] IEEE Journal on Selected Areas in Communications, May 1989. Special issue on Secure Communications.

[14] Brian W. Kernighan and Dennis M. Ritchie. The C Programming Language. Prentice-Hall, Englewood Clis, NJ 07632, USA, second edition,1988.

[15] Sandeep Kumar. Classication and Detection of Computer Intrusions. PhD thesis, Purdue University, West Lafayette, IN 47907, 1995.

[16] Biswanath Mukherjee, Todd L. Heberlein, and Karl N. Levitt. Network intrusion detection. IEEE Network, 8(3):26-41, May/June 1994.

[17] "intrusion". Merriam-Webster OnLine: WWWebster Dictionary. http://www.m-w.com/dictionary, 1998. Accessed on May 16, 1998.

[18] John K. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, Reading, MA, USA, 1994.

[19] Phillip A. Porras and Peter G. Neumann. EMERALD: Event monitoring enabling responses to anomalous live disturbances. In Proceedings of the 20th National Information Systems Security Conference. National Institute of Standards and Technology, 1997.

[20] Thomas H. Ptacek and Timothy N.Newsham. Insertion, evasion, and denial of service: Eluding network intrusion detection. Technical report, Secure Networks, Inc., January 1998.

[21] Marshall Rose. The Simple Book: an introduction to management of TCP/IP based internets. Prentice Hall, NJ, 1993.

[22] S. R. Snapp, J. Brentano, G. V. Dias, T. L. Goan, L. T. Heberlein, C. Ho, K. N. Levitt, B. Mukherjee, S. E. Smaha, T. Grance, D. M. Teal, and D. Mansur. DIDS (Distributed Intrusion Detection System) - Motivation, Architecture, and an early Prototype. In Proceedings of the 14th National Computer Security Conference, pages 167-176, October 1991.

[23] Eugene Spafford and Diego Zamboni. A framework and prototype for a distributed intrusion detection system. Technical Report 98-06 COAST Laboratory, Purdue University, West Lafayette, IN 47907-1398, May 1998.

[24] S. Staniford-Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, C. Wee, R. Yip, and D. Zerkle. GrIDS: A graphbased intrusion detection system for large networks. In Proceedings of the 19th National Information Systems Security Conference, volume 1, pages 361-370. National Institute of Standards and Technology, October 1996.

[25] Stuart Staniford-Chen. Common intrusion detection framework. WWW page at http://seclab.cs.ucdavis.edu/cidf/.

[26] W. Richard Stevens. TCP/IP Illustrated, volume Volume 1. The Protocols of Professional Computing Series. Addison-Wesley, 1994.

[27] Uresh Vahalia. UNIX Internals: The New Frontiers. Prentice-Hall, Englewood Clis, NJ 07632, USA, 1996.

[28] Larry Wall, Tom Christiansen, and Randal L. Schwartz. Programming Perl. O'Reilly & Associates, Inc., second edition edition, September 1996.

[29] Gregory B. White, Eric A. Fisch, and Udo W. Pooch. Cooperating security managers: A peerbased intrusion detection system. IEEE Network, pages 20-23, January/February 1996.

Traduction : ESEO (Ecole Supérieure d'Electronique de l'Ouest)
4, rue Merlet de la Boulaye - 49000 ANGERS - France
Doceux Erwan - Etudiant de 4ème année de l'ESEO

"An Architecture for Intrusion Detection using Autonomous Agents"
Jai Sundar Balasubramaniyan, Jose Omar Garcia-Fernandez, David Isacoff, Eugene Spafford, Diego Zamboni (auteur principal)
de COAST Laboratory - Purdue University - West Lafayette, IN 47907-1398
{balasujs,jgarcia,isacoff,spaf,zambonig}@cs.purdue.edu
COAST Technical Report 98/05
June 11, 1998