Evolution d’un système de détection d’intrusions réseau basé sur l’IDS snort

Résumé du document

Les menaces contre les systèmes informatiques, aujourd'hui encore plus nombreuses, fréquentes, complexes et dangereuses visent plus que jamais à compromettre la disponibilité, la confidentialité et l'intégrité des données et ressources de l'entreprise. Une bonne approche de gestion du risque devrait garantir une confiance totale aux entreprises, aux administrations et consommateurs.

Même les meilleurs systèmes doivent être constamment surveillés pour détecter les tentatives réussies et non réussies d'éventuelles attaques connues ou non. Les NIDS (Network-based Intrusion Detection System) et NIPS (Network-based Intrusion Prevention System) constituent une ligne de défense aujourd'hui très intéressante surtout par la fonction de détection. Dans le cadre de notre projet évolution du système, nous avons pour but de détecter les faux positifs.

L'application est un système multi-agents (SMA) issu de l'analyse de la problématique de gestion des connaissances dans les systèmes de détection/prévention d'intrusions réseau. Le fonctionnement du système existant est dirigé par les agents : Sensor (Snort), Dectector, MsgToHostCarrier, Analysor, et Manager.

C'est le manager qui est l'agent principal de ce système : il crée les detectors et leur donne l'ordre de se déplacer de façon autonome dans le réseau : ceux-ci vérifient les nouvelles alertes qui ont été journalisées par les Sensor depuis leur dernier passage ou depuis le dernier passage d'autres detectors.

En cas de nouvelles alertes, il envoie un signal sous forme de message à l'agent « manager » pour l'informer des nouvelles intrusions détectées sur une machine. Il envoie les identifiants (nom) de la machine sur laquelle il a détecté les intrusions. Cette machine doit être analysée, le manager crée donc un agent analysor et lui donne de se déplacer vers cette machine.

Celui-ci analyse les alertes trouvées sur la machine concernée et envoie les alertes trouvées au manager et l'analysor meurt. En fonction de la gravité de la situation, le manager peut soit envoyer des agents porteurs de courrier MsgToHostCarrier soit en notifiant l'administrateur par SMS ou email.

Extraits

[...] Nous avons donc décidé de rendre le CBR plus pratique par deux exemples simples Rappel sur le fonctionnement du CBR Les prédicats Les concepts 2 Simulation des attaques Il a été question d'étudier certaines attaques déjà connues et de les simuler nous présentons ici les principales attaques étudiées Nous avons écrit les règles snort suivantes pour pouvoir les detecter Mais compte tenu des difficultés avec internet et le téléchargement des règles de snort nous n'avons pas pu avoir des résultats. Du coup nous nous sommes concentrés sur 2 principales alertes à savoir :le scan de port et les ping. [...]

[...] Nous avons ainsi pu catégoriser ces 2 types d'attaques avec notre CBR Implémentation du module de réaction Ce module gère les différentes réactions envisagées, lors d'une attaque pour avertir l'administrateur. Envoi de message électronique à l'adresse e-mail de l'administrateur : Pour envoyer les e-mails à l'administrateur, nous avons utilisé l'API JavaMail qui est une extension du JDK, ainsi qu'un serveur SMTP (KaliMail) pour le routage des messages car ce type d'échanges se font entre les serveurs SMTP. KaliMail est installé en local sur la machine où se trouve l'agent Manager Sur cette image, on a l'interface principale de KaliMail Envoie d'une alarme sur la machine attaquée : Ici il est simplement question de déplacer l'agent notifyer vers le container sur lequel l'attaque a été détectée, et arrivé à destination, l'agent émet des sons pendant un certain temps. [...]

[...] Evolution d'un système de détection d'intrusions réseau basé sur l'IDS snort 1. INTRODUCTION Architecture de l'existant L'Agent Sensor L'Agent Detector L'Agent MsgToHostCarrier L'Agent Analysor L'Agent Manager Fonctionnement du système NOUVEAUX MODULES Module1: Analyse Module2: Réaction Module3: administration NOTRE APPROCHE DE RESOLUTION Implémentation du module d'analyse Implémentation du module de réaction Implémentation du module d'Administration Difficultés rencontrées Conclusion Guide de Déploiement Bibliographie 15 INTRODUCTION Les menaces contre les systèmes informatiques, aujourd'hui encore plus nombreuses, fréquentes, complexes et dangereuses visent plus que jamais à compromettre la disponibilité, la confidentialité et l'intégrité des données et ressources de l'entreprise. [...]

[...] Cet agent est doté d'un CBR (case based reasonning). c'est ici que l'on prend les décisions (alerte, envoi de mail) Redéfinition des schémas d'attaque Nous allons utiliser le grand livre de sécurité informatique pour répertorier les attaques et constituer une base de données consistante qui permettra de catégoriser les attaques. Nous allons aussi revoir l'outil chargé d'inférer sur les schémas d'attaques 2 Module2: Réaction C'est dans ce module que l'on implémente les différentes actions à exécuter lors d'une attaque. Ces actions peuvent être l'envoi de mail à l'administrateur ou l'alerte sur la machine attaquée. [...]

[...] En effet, lorsque le CBR a analysé une alerte et la catégorisé, un agent notifyer est créé pour effectuer l'action décrite dans cette catégorie : ces actions peuvent être : - 3 Module3: administration Fournir une interface d'administration web accessible via l'internet et protéger par un mot de passe. Elle permet de définir les schémas d'attaque, de visualiser les attaques. Le langage utilisé est php pour plus de flexibilité. Pourquoi une interface web ? Il question que l'administrateur puisse contrôler l'application et être au courant de tout ce qui se passe à l'intérieur de l'application à n'importe quel endroit du globe. Donc, cette partie sera un site web hébergé sur un serveur accessible. [...]