Rapport stage Dess Isa

2.7La réaction

La réaction est un client particulier. Elle peut s’abonner à certains messages IDMEF du routeur, grâce à un fichier de configuration, et réagir, de façon automatique ou manuelle aux différentes intrusions (c’est à dire aux différents messages IDMEF reçus).
Lors de la réaction à une attaque, différentes actions (rôles) sont possibles :

• 
  Information : information locale de l’opérateur par exemple.
  
• 
  Dissuasion : information du poste source de l’attaque, que celle-ci a été détectée, par exemple.
  
• 
  Correction : destruction de la connexion du poste source vers le poste cible par exemple.
  
• 
  Compensation : redémarrage d’un ou plusieurs services arrêtés pendant l’attaque par exemple.
  

Pour chaque rôle, il existe des actions automatiques, et des actions manuelles. Ces actions sont définies dans le fichier de configuration de la réaction. Un bouton permet à l’administrateur du système d’envoyer les actions manuelles qu’il souhaite.

La figure 7 permet de visualiser la fenêtre de la réaction. On peut y voir la liste des attaques pour lesquelles on effectue une réaction et les actions que l’on peut entreprendre.


Figure 7 - Vue du client de réaction

2.8Configuration de la liaison entre la réaction et Diams action.

La réaction s’abonne au pré du routeur, en s’abonnant elle transmet un filtre au routeur lui indiquant le type de message qu’elle désire.

A la réception de ce message, la réaction lance un programme « Diams Action⁸ » qui lui se trouve sur un poste éloigné. Pour une plus grande fiabilité de l’opération, la liaison entre la réaction et le poste où se trouve Diams action doit être sécurisée. On choisit donc de configurer la liaison avec l’utilitaire PUTTY[6].

La réaction doit être automatique. Il est donc nécessaire de configurer la liaison pour que cette dernière s’effectue sans intervention humaine. Pour cela nous allons procéder grâce à plusieurs opérations mettant en œuvre le mécanisme de clé publique et de clé privée.

La marche à suivre est la suivante 

• 
  1^ère étape : Lancement du serveur SSH sur le poste où se trouve Diams action.
  
• 
  2^ème étape : grâce à l’utilitaire Puttygen on généré une paire de clé, une clé publique et une clé privé.
  

Figure 8: Le Putty key Generator

• 
  3^ème étape : la clé publique doit être placée dans le répertoire ./ssh2/authorized_keys de la machine ou se trouve la réaction. La clé privée doit être chargée par le pageant sur la machine où se trouve le module graphique de la réaction⁹.
  

Figure 9: Le Pageant

• 
  4^ème étape : Dans le fichier réaction.conf, on place la commande « plink root@nomdelamachine –option ». Le but de cette commande est de lancer DiamsAction à partir du module de réaction.
  

• 
  5^ème étape : Création d’une interface graphique pouvant être lancer manuellement ou automatiquement.
  

Dans le fichier réaction.conf, il est possible de lancer plusieurs applications. Des applications distantes comme DiamsAction ou des applications locales. J’ai donc créé une interface graphique simple qui peut être lancé soit automatiquement soit manuellement à partir du module de réaction, l’avantage est d’obtenir une information visuelle du lancement de la réaction, et au besoin de lancer nous même certaines réactions. Je montre ainsi les évolutions possibles de la réaction car on peut y intégrer d’autres applications.


Figure 10 : interface graphique

J’ai pu déployer DIAMS dans une salle de tests sur plusieurs machines, les tests furent concluants. Une des perspectives à explorer dans les prochaines semaines concerne l’intégration de triggers dans la base de données. Les événements associés concerneront le module de réaction.

La prochaine section porte sur la politique de sécurité. Les deux projets sont distincts, mais ils concernent toujours le domaine de la sécurité des systèmes d’information.

J’introduis donc dans la première partie le modèle de politique de sécurité développé à l’ENST « Or-Bac ».

3Politique de sécurité réseau

U

...
ne politique de sécurité réseau est exprimée dans un premier temps de façon informelle (sous forme de texte le plus couramment), ce qui ne prête généralement pas à une administration directe via une application en charge de la sécurité réseau. La dérivation de cette politique de sécurité réseau au niveau des éléments de sécurité nécessite donc, dans un premier temps, son expression sous la forme d'un langage de haut niveau, de préférence en suivant un modèle, puis une traduction en règles de bas niveau pour les éléments intégrant des règles de filtrage, c'est à dire les pare-feu. Un modèle permettant cette formulation a été développé à l’ENST, c’est le modèle Or-Bac. Une étude sur la traduction a été menée, elle s’effectue en 2 étapes à l’aide de transformations en XSLT.
Le but final de l’approche étant de pouvoir ainsi dériver à partir du modèle Or-Bac les règles permettant de configurer automatiquement les composants de sécurité (les firewalls).

La suite du rapport est décomposée ainsi : après une présentation du modèle Or-Bac, la prochaine section introduit des pare feu usuels, certains de leurs mécanismes et leur intérêts pour Or-Bac. J’explique dans un exemple, le processus de génération des règles basé sur l’approche évoquée ci-dessus.

J’expose ensuite l’évolution souhaitée, et la nouvelle approche avec Firewall Builder.