Rapport stage Dess Isa

2Le projet DIAMS

Dans ce chapitre je présente la plate forme DIAMS et mon intervention dans les différents modules qui la compose. Le but étant le déploiement de DIAMS à partir du code source.

2.1Présentation de DIAMS

MIRADOR est un contrat industriel du projet ARMOR de l’IRISA, géré à l’ENSTB. La finalité de MIRADOR est de dresser un état de l’art sur la détection d’intrusion, puis de construire une plate-forme sous la forme d’un IDS répondant aux besoins du domaine militaire. Les partenaires dans ce projet sont l’ENST Bretagne, Alcatel, le CERT ONERA et Supélec.

Les différentes couches de l’IDS développé sont les sondes, les modules de détection d’intrusion (MDI), la coopération puis la réaction. Pour les sondes et les MDI, le projet utilise des IDS du domaine des logiciels libres. De ce projet une plate forme fut développée en java, elle s’appelle DIAMS.

DIAMS est un outil de détection d’intrusion entièrement développé à l’ENST Bretagne. Basé sur l’écoute passive et l’analyse du trafic réseau, il est considéré comme une source d’audit indépendante et indécelable permettant de protéger le site contre d’éventuelles intrusions.


Figure 1 : Schéma de l’architecture globale de DIAMS
Au centre de l’architecture se trouve le Routeur, qui assure, via un mécanisme d’abonnement, les communications (sécurisées) entre les différents modules. Les formats des alarmes sont syslog⁷ et IDMEF [5]/XML.
DIAMS est composé de différents modules indépendants (voir Figure 1) pouvant fonctionner sur des machines différentes :

• 
  Le routeur (router) transmet les messages qu’il reçoit du convertisseur vers les différents clients suivant les règles de filtrage que chacun lui a soumis.
  
• 
  Les sondes (sensors) sont des agents qui dupliquent le trafic des segments sur lesquels elles sont placées pour analyser, agir, assembler des informations et les envoyer au routeur par contenu. Elles sont basées sur le principe condition/action.
  
• 
  Le convertisseur (translator) reçoit tous les messages, au format syslog, envoyés par les sondes et les convertit au format XML suivant la DTD IDMEF.
  
• 
  Les clients de réception sont des visualiseurs graphiques qui permettent d’analyser en temps réel ou a posteriori les informations générées par les sondes. Chaque client compose un filtre, envoyé au routeur, afin de définir ses besoins d’informations.
  
• 
  Le client DBClient archive dans une base de données les attaques détectées par les sondes.
  
• 
  La corrélation(correlation) : les IDS génèrent, parfois, des faux positifs. La corrélation permettra, en utilisant plusieurs sources de données, de vérifier la pertinence des alarmes et d'affiner le diagnostic par le croisement de plusieurs alarmes ou la recherche d'informations complémentaires.
  
• 
  Le module réaction à partir duquel on pourra lancer, à l’aide d’un serveur SSH, le programme DiamsAction, qui permet d’effectuer une réaction contre une attaque.
  
• 
  Le File Reader permet de simuler la génération d’attaques à partir de données lues dans un fichier.
  

2.2Déploiement de Diams

Tous les modules peuvent fonctionner de façon autonome en mode application ou en mode applet. Il suffit que la configuration de l'adresse IP du routeur soit correcte dans le cas d'une utilisation en application ou que les droits autorisent l'applet à écouter le port UDP 514 (utilisation du policytool de java) dans le cas d'une utilisation en applet.
Le déploiement de la maquette DIAMS se décline donc en une multitude de tâches qui sont :

• 
  Création d’un fichier exécutable à partir du code source (Création de l’applet).
  
• 
  Installation des machines virtuelles (les java run time environement)
  
• 
  Déploiement de l’applet sur les stations.
  
• 
  Configuration des java.policy(via le policytool).
  
• 
  Lancement des attaques et des sondes.
  

Une applet Java n’a par défaut aucun droit sur les ressources du poste de travail qui l’exécute. Il n’est donc, par exemple, pas possible à l’applet de lire un fichier se trouvant sur le disque dur local ou d’accéder à une imprimante. La plate-forme Java permet cependant de définir une politique de sécurité autorisant certaines applets identifiées à utiliser les ressources du client.

Chaque applet est obligatoirement exécutée sous le contrôle d’un gestionnaire de sécurité (Security Manager). Celui-ci s’interpose entre l’applet et les ressources du système afin d’empêcher toute tentative d’accès illégal aux ressources du client. Les permissions d’accès sont définies par la politique de sécurité (Security Policy) installée sur le poste de travail. Lorsque aucune politique de sécurité n’est définie explicitement sur le client, le gestionnaire utilise alors la politique par défaut qui interdit aux applets tout accès (lecture et écriture) aux ressources de la machine locale.
Quand une applet tente d’accéder à une ressource du système, le gestionnaire de sécurité vérifie si le code exécuté a la permission d’accéder à cette ressource en consultant la politique de sécurité. Si la permission est accordée, tout se passe normalement. Dans le cas contraire, une exception est levée. Les fichiers « .policy » servent à paramétrer la politique de sécurité du système local.

2.3Le convertisseur ( translator )

La fonction du convertisseur est de traduire les messages syslogs reçus sur le port 514 de la machine qui l’héberge en messages au format XML IDMEF.

La configuration de l'adresse IP du routeur doit être correcte dans le cas d'une utilisation en application distribuée et les droits (utilisation du policytool de java) doivent autoriser l'applet à écouter le port UDP 514 dans le cas d'une utilisation en applet. Ce port reçoit les informations (messages syslog) émises par des sondes logiciel Snort, Etrust et NetProwler.

Une fois le message traduit, le convertisseur via une interface RMI dont il est le client, envoie le message au routeur. Le convertisseur aura au préalable rempli les champs IDMEF concernant la date de création de l'erreur et l'origine du message.

Pour contrôler son activité, celui-ci dispose d’une interface graphique très simplifiée (voir Figure 2), permettant de visualiser, dans une première zone de texte, les messages syslog reçus, dans une seconde les messages d’erreurs transmis par l’analyseur des messages et enfin, dans une dernière, l’arbre XML du message.

Figure 2 - Vue du convertisseur