Université de science technologique Houari Boumediene

Prélude-IDS

Un IDS hybride

Belhocine Mhamed Nacereddine & Hariti Badis20/12/2013

Chapitre 1 - Installation

Prelude, ou Prelude-IDS, est un système de détection d’intrusion hybride composé de plusieurs plugins, sondes. Prelude a été conçu dans le but d’être modulaire, souple, et résistant aux attaques. Sa modularité permet notamment de lui rajouter facilement de nouveaux types de détecteurs d’intrusion, d’analyseurs de logs et d’une solution de corrélation, le tout au format et à la norme IDMEF (Intrusion Detection Message Exchange Format), bien que de nombreux autres formats de logs sont compatibles.Le format IDMEF décrit une alerte de façon objet et exhaustive. Une alerte est le message qui est émis depuis un analyseur, qui est une sonde en langage IDMEF, vers un collecteur. Le but d’IDMEF est de proposer un standard permettant d’avoir une communication hétérogène quel que soit l’environnement ou les capacités d’un analyseur donné. Ces alertes sont définies au format XML, offrant une possibilité de validation de chaque message. En général, les implémentations restent binaires, afin d’éviter les problèmes connus d’ajout d’information inutiles en dehors d’XML lorsque l’on envoie un message sur le réseau.

IDMEF offre aussi un vocabulaire précis, qu’il est courant d’utiliser dans le domaine de la détection d’intrusions. Par exemple, une classification correspond au nom d’une alerte, un impact celui d’un niveau d’attaque.

L’intérêt de Prelude est de pouvoir centraliser les alertes dans sa base de données et de les normaliser au format IDMEF, puis visualisable dans une interface web.

Prelude peut intégrer :

un NIDS (Network Intrusion Detection System, par exemple Snort)

un HIDS (Host Intrusion Detection System, par exemple Ossec)

un LML (Log Monitoring Lackey, module Prelude : Prelude-LML)

un corrélateur (module Prelude : Prelude-Correlator)

une interface web (module Prelude : Prelude-Prewikka)L’application Prelude est disponible uniquement sous Linux, bien qu’il ait une offre payante (support, fonctionnalités supplémentaires, …), le logiciel est gratuit.

Composants Prelude

Libprelude

Libprelude est une bibliothèque permettant une communication sécurisée entre différentes sondes et un serveur Prelude (Prelude-Manager). De plus, il fournit une API (Application Programming Interface) afin de permettre la génération d’alertes au format standard IDMEF (par exemple, libprelude “traduit” une alerte Ossec en IDMEF).

La bibliothèque permet également d’automatiser l’enregistrement et la retransmission des alertes en cas de perte d’un des composants.

LibpreludeDB

La librairie LibpreludeDB permet la gestion du type et du format de la base de données utilisée pour stocker les alertes au format IDMEF. Elle offre aussi la possibilité de gérer la base de données sans utiliser du SQL, grâce à l’usage de commandes, spécialement développées pour interagir depuis un terminal Linux.

Prelude-Manager

Prelude-Manager est le composant principal de Prelude, il joue le rôle de serveur. En effet, il réceptionne les alertes IDMEF provenant de ses sondes ou de ses composants (Prelude-Correlator).

Prelude-Correlator

C’est un outil de corrélation multiflux, utilisant des règles écrites en Python pour corréler les alertes IDMEF reçues par Prelude-Manager.

Prelude-LML

Prelude-LML est un analyseur de fichiers de logs. En agissant comme sonde auprès de Prelude-Manager, il collecte et analyse les informations issues de tous types d’applications émettant des évènements sous forme de journaux systèmes, de massages syslog, …etc. Il détecte des activités suspectes lors de ses analyses, puis génère des alertes au format IDMEF et les transmet au serveur Prelude.

Prewikka

Interface web de Prelude. Prewikka permet de visualiser les alertes reçues par Prelude-Manager.

Compatibilités Prelude

AuditD

Snort

SanCP

Nagios (check_prelude)

Ossec

Nepenthes

PAM

NuFW

Samhain

Chapitre 2 - Prise en main

Administration des composants Prelude

Libprelude

Rappel

Libprelude est la librairie de Prelude. Elle permet les inscriptions des sondes, la génération des certificats des composants et leur communication avec un serveur Prelude. De plus la librairie contient les données nécessaires pour la gestion du format IDMEF (génération des alertes en IDMEF par les sondes).

Utilisation

libprelude-config

Commande permettant de préciser des paramètres de base (répertoire d’installation, …etc).

prelude-admin

Cette commande est utilisée pour réaliser les inscriptions des sondes. prelude-admin génère les certificats d’enregistrement selon les profils (ajout,suppression, …etc), puis en mode écoute sur le serveur, elle accepte ou non les certificats envoyées par les sondes.Voici un exemple d’utilisation pour lister les certificats utilisés:

$ sudo prelude-admin list

Afin d’obtenir plus d’informations sur l’usage et les options de cette commande:

$ sudo prelude-admin --help

prelude-adduser

prelude-adduser a le même rôle que prelude-admin, elle est en quelque sorte, l’ancienne commande utilisée pour les inscriptions des sondes. D’ailleurs à l’avenir, cette commande sera normalement supprimée.

LibpreludeDB

Rappel

La librairie LibpreludeDB permet d’ajouter l’utilisation d’une base de données dans une architecture Prelude.

Utilisation

libpreludedb-config

Cette commande permet de préciser des paramètres tel que le chemin où se trouve l’installation de Prelude.

preludedb-admin

Afin de pouvoir agir, modifier la base de données de Prelude, à savoir « prelude » (nommée lors de l’installation), il existe une commande permettant de supprimer des alertes, de les copier sur une autre base de données, …etc. Pour cela, il suffit d’utiliser la commande preludedb-admin.Voici un exemple d’utilisation pour supprimer des alertes antérieures à une date :

# preludedb-admin delete alert --criteria "alert.create_time < "2009-09-24"" "type=mysql name=prelude user=prelude pass=password"

Pour d’obtenir plus d’informations sur l’usage et les options de cette commande:

$ sudo preludedb-admin --help

Prelude-Manager

Rappel

Prelude-Manager est le module principal de Prelude-IDS. En effet, c’est lui qui reçoit et traite les alertes (stockage dans une base de données, dans un fichier, …etc). Il gère également les certificats des différentes sondes (inscriptions des sondes).

Utilisation

prelude-manager

Il s’agit de la commande d’administration de Prelude-Manager. Elle permet dans un premier temps de démarrer le serveur Prelude, et ainsi recevoir les alertes provenant des sondes enregistrées. Dans un second temps, elle peut servir dans de multiples usages pour par exemple, relayer les alertes reçues vers un autre Prelude-Manager (centralisant les alertes provenant de plusieurs serveurs Prelude), ou encore appliquer des filtres sur les critères des alertes IDMEF.

Voici un exemple d’utilisation, démarrant Prelude-manager en mode daemon, et précisant un fichier de configuration:

$ sudo prelude-manager -d --config=/usr/local/etc/prelude-manager/prelude-manager.conf

Afin d’obtenir plus d’informations sur l’usage et les options de cette commande:

$ sudo prelude-manager --help

Prelude-Correlator

Rappel

Prelude-Correlator est le module (optionnel) de Prelude permettant de gérer la corrélation des alertes reçues par Prelude-Manager. Pour cela, il utilise des règles développées en Python. par défaut, le paquet ne contient qu’une dizaine de règles. Donc il faudra en écrire des supplémentaire en fonction de vos besoins.

Utilisation

prelude-correlator

Il n’y a qu’une seule commande à utiliser pour gérer le corrélateur de Prelude, c’est prelude-correlator. Celle-ci permet de démarrer le module, et tout comme une sonde, ce dernier s’authentifie au démarrage auprès du Prelude-Manager avec un certificat (préalablement enregistré).Voici un exemple d’utilisation, avec démarrage du corrélateur en mode deamon, et écriture des alertes IDMEF traitées (par Prelude-Correlator) en entrée et en sortie dans des fichiers de logs:

$ sudo prelude-correlator -d --print-input=/etc/prelude-correlator/logs/input.log --print-output=/etc/prelude-correlator/logs/output.log

Plus d’informations sur l’usage et les options de cette commande:

$ sudo prelude-correlator --help

Prewikka

Rappel

Prewikka est l’interface Web de Prelude. Elle permet d’afficher les alertes reçues par Prelude-Manager.

Interactions

Prelude-ManagerLorsque Prelude, plus précisément Prelude-Manager, reçoit une alerte IDS, il l’ajoute dans la base de données de Prelude. Ainsi, Prewikka, lorsqu’il va réactualiser sa page d’affichage

d’alertes, relancera un SELECT sur les tables de la base de données et affichera alors cette nouvelle alerte.

Prelude-CorrelatorArpès la réception et l’ajout d’une nouvelle alerte par Prelude-Manager, le corrélateur, à savoir Prelude-Correlator va en fonction de ses règles, intercepter certaines alertes pour en générer une nouvelle, corrélée. Cette dernière sera renvoyée au Prelude-Manager, qui la verra comme une nouvelle alerte, mais corrélée. En aucun cas, le corrélateur ne supprime les alertes à partir desquelles il a généré sa corrélation. Ainsi, dans Prewikka, il sera possible de voir les nouvelles alertes reçues directement par le Prelude-Manager, avec aussi la nouvelle alerte corrélée, en général à un niveau de gravité plus élevé.

Description et utilisation de l'interface

Lancement de l'interface

Etant une interface graphique web, Prewikka se lance donc dans un navigateur internet. Pour cela, il suffit d’entrer dans la barre d’adresse url du navigateur (Firefox, IE, Opera, …), cette adresse :

http://adresse_ip/prewikkaIci, “adresse_ip” étant à remplacer par l’adresse réel ou le nom du serveur où est installé Prelude (et Prewikka en toute logique). Selon la configuration du « virtual host » dans Apache, il n’est pas indispensable d’ajouter « prewikka » à la fin de l’adresse web.

En cas de problèmes pour afficher l’interface, ne pas hésiter pas à vérifier, pour commencer les connexions réseaux, puis ensuite à revoir la configuration d’Apache pour Prewikka, ou bien encore en contrôlant le fichier de configuration de Prewikka (/etc/prewikka/prewikka.conf).

Si tout va bien, une interface graphique apparaît dans le navigateur avec un formulaire d’authentification. Il faut entrer le login et le password en fonction de la configuration de Prewikka (définition de l’administrateur par défaut dans le fichier de configuration /etc/prewikka/prewikka.conf, avec les champs initial_admin_user et initial_admin_pass). Si vous n’avez rien changé, par défaut, le login est « admin » et le password « admin ». Il est possible de supprimer cette phase d’authentification dans le fichier de configuration.

Une fois authentifié (ou non), s’affiche alors la page principale de Prewikka, à savoir la visualisation des alertes.

Description de l'interface

L’interface de Prewikka est composée d’une fenêtre principale, centrale où sont affichées les alertes transmises par les sondes de Prelude.

Sur la gauche, on peut trouver le menu avec les différentes parties : Evénements, Agents, Paramètres et A propos.

La partie Evénements correspond donc à la visualisation des alertes IDS. C’est la page principale (par défaut) de Prewikka. Sur cette page, il y a 3 onglets disponibles pour spécifier, voir plutôt filtrer l’affichage des alertes. On a donc le choix entre Alertes, Alertes de Corrélation et Alertes d’outils. Le premier onglet Alertes (par défaut), affiche la totalité des alertes (corrélées, …), le second, comme l’indique son nom, sert à visualiser que les alertes corrélées par Prelude-Correlator. Quant au troisième, il affiche les alertes concernant les outils (sondes).

Quelque soit l’onglet choisi, il est possible (en général) de voir en détail les alertes en cliquant dessus, sur le titre de l’alerte ou bien, en cliquant sur le nombre à côté du titre dans le cas où il y en aurait plusieurs.

Après avoir cliqué sur une alerte, Prewikka affiche alors le contenu de l’alerte, à savoir le format IDMEF avec une mise en forme HTML, plus sympathique à lire que dans un fichier de logs.

Pour revenir sur l’affichage des alertes, elles utilisent des couleurs pour pouvoir en faciliter la recherche sur les niveaux de gravités, de danger de chacune d’entre elles. Ainsi, le code des couleurs est :

Bleu → niveau d’information « info »

Vert → niveau le plus faible « low »

Orange → niveau intermédiaire « medium »

Rouge → niveau d’alerte maximum « high »Les alertes sont affichées sous la forme d’un tableau, avec comme colonnes, la classification (nom de l’alerte, …), la source ayant provoquée l’alerte, puis la destination de l’événement, ensuite le nom de la sonde ayant fait remontée cette alerte à Prelude, et enfin le temps (heure) sur lequel l’alerte à été reçue par le Prelude-Manager. Pour chacun des ses onglets (Evénements), un bouton se trouvant en bas de page (Effacer), permet après sélection des alertes (globale, ou ciblée), de les supprimer.

Sur le menu, à gauche il y a aussi un autre choix, le bouton Agents. Ce dernier permet de visualiser l’ensemble des agents constituant l’architecture réseau de notre projet, à savoir les différentes sondes connectées au serveur Prelude, ainsi que ses composants, comme le Prelude-Manager, le Prelude-Correlator. Il est possible donc de voir l’état des sondes et des composants de Prelude en temps réel, c’est-à-dire si ils sont connectées ou pas (démarrées).

A partir de cette fenêtre, les alertes et les pulsations (2ème onglet) peuvent être supprimées, afin de nettoyer Prewikka, pour repartir avec une interface à neuf.

Lorsqu’une sonde est déconnectée, il est également possible de supprimer son profil à partir de l’interface.

Comme pour le bouton Evénements, la partie Agents contient deux onglets, le premier nommé aussi Agents correspond donc à l’affichage des statuts des sondes comme énoncé précédemment. Pour le deuxième onglet Pulsations, il permet de voir les différentes vérifications de connexions entre les sondes, avec l’heure exacte de chaque test de statuts des agents.

Troisième bouton du menu (à gauche de l’interface), les Paramètres de Prewikka. C’est ici, que l’on peut créer ou éditer des filtres pour l’affichage des alertes, en précisant par exemple de n’afficher que les alertes provenant d’une sonde en particulier, … etc. Principal avantage de cet éditeur de filtre, c’est qu’il repose sur le format IDMEF, ce qui donne une multitude de possibilités, à condition bien sûr de maîtriser un minimum la norme IDMEF, pour pouvoir utiliser les différents champs d’une alerte IDS.

Pour appliquer un filtre, il suffit lorsque l’on est sur la page d’affichage des alertes d’utiliser l’outil disponible tout en bas à gauche (sous le menu), puis de choisir l’un des filtres préalablement créés et l’appliquer.

Cet outil (sorte de menu) dispose en plus de pouvoir appliquer des filtres, des boutons pour faire défiler les pages des alertes classées par période d’une heure. Permettant ainsi de voir un historique des alertes reçues. Il est aussi possible d’appliquer des filtres spécifiques sur chaque colonne d’affichage d’alertes, en cliquant sur le nom d’une des colonnes.

Par rapport au deuxième onglet des Paramètres, c’est-à-dire Mon compte, ainsi que pour le dernier onglet Utilisateurs, ici, peut être créé ou modifié des utilisateurs autorisés à se connecter à Prewikka, en indiquant les droits de chaque utilisateur, et la langue de l’interface.

Et enfin, le dernier bouton du menu A propos donne des informations générales sur la solution Prelude-IDS, la version utilisée de Prewikka, et les différentes adresses pour contacter la société, éditrice de Prelude.

Inscriptions des composants Prelude et des sondes

Prelude pouvant utiliser des sondes et des plugins (composants) répartis sur tout un réseau, doit pour plus de sécurité, mettre en place des échanges cryptés. Ainsi, pour l’ajout d’un plugin comme Prelude-Correlator par exemple, en local comme sur un autre serveur, ce dernier doit être enregistré et authentifié auprès du Prelude-Manager.

Prelude-Manager

Pour cela, Prelude intègre un outil prelude-admin, c’est avec cette commande qu’il va être possible d’enregistrer les composants supplémentaires.

Création du profil Prelude-Manager

Tout d’abord, il faut commencer par créer le profil du Prelude-Manager.

$ sudo prelude-admin add "prelude-manager" --uid 0 --gid 0

Cette commande génère une clé pour le Prelude-Manager afin qu’il puisse mettre en place ses échanges cryptés.

le temps de création de la clé peut être très long, mais vraiment très long ! Pour réduire le délai de génération, il est conseillé de faire travailler le système. Il existe par exemple l’entropie :

$ sudo cat /dev/urandom > /dev/null

Mais cette méthode n’est pas la plus rapide car cela peut prendre tout de même plusieurs heures (maximum 24h en général). Heureusement, il y a une autre solution, qu’est l’installation d’un paquet assez lourd. Exemple :

$ sudo apt-get install gimp

Avec cette méthode le temps de création passe à une vingtaine de minutes (1h maximum). Bien entendu, un autre paquet peut faire l’affaire, à vérifier tout de même selon les paquets. Ensuite, ce paquet téléchargé et installé n’est plus nécessaire, donc désinstallation :

$ sudo apt-get autoremove gimp

Enregistrement

Une fois la clé générée, il faut démarrer le Prelude-Manager :

$ sudo prelude-manager

Et taper cette commande dans un autre terminal pour mettre le serveur Prelude en mode écoute pour enregistrer une sonde ou un plugin :

$ sudo prelude-admin registration-server prelude-manager

La commande génère alors un mot-de-passe à usage unique et reste en écoute. Il ne reste plus qu’à enregistrer un composant.

ce mot-de-passe est à usage unique. C’est-à-dire qu’il ne peut servir que pour l’enregistrement d’un seul composant. Pour l’inscription d’un autre plugin ou d’une sonde, il faudra tout simplement la relancer à chaque fois, pour obtenir un nouveau mot-de-passe et mettre le serveur en écoute.

Prelude-Correlator

En local tout comme sur un serveur différent du Prelude-Manager, il faut effectuer l’enregistrement du Prelude-Correlator avec une commande qui génère également une clé pour le plugin :

$ sudo prelude-admin register prelude-correlator "idmef:rw" localhost --uid 0 --gid 0

Si le plugin n’est pas installé sur le même poste, modifier localhost par l’adresse ip du serveur hébergeant le Prelude-Manager.

Tout comme la génération de la clé du Prelude-Manager, le temps de création est très long, donc il faut également faire travailler le système (voir précédemment).

Lorsque la clé est créée, il est demandé d’entrer un mot-de-passe. Ce dernier est tout simplement celui générer par le Prelude-Manager auparavant.

Rappel : ce mot-de-passe est à usage unique. Prelude-Manager doit être en écoute (voir la section au-dessus).

Une fois le mot-de-passe entré, l’enregistrement est en attente d’une réponse du Prelude-Manager. Donc il faut se rendre sur le terminal de ce dernier, où est lancé la commande prelude-admin registration-server prelude-manager, et accepter (ou pas) la connexion et donc l’inscription du Prelude-Correlator. L’enregistrement du plugin est alors terminé.

Prelude-LML

La démarche est la même que pour le Prelude-Correlator, il y a juste à adapter la commande :

$ sudo prelude-admin register prelude-lml "idmef:w admin:r" localhost --uid 0 --gid 0

Dans le cas où Prelude-LML n’est pas installé sur le même serveur que Prelude-Manager, il faut alors remplacer “localhost” par l’adresse ip du manager. Prelude-LML étant considéré comme une sonde.

Exemples d'enregistrement de sondes NIDS et HIDS

La commande de base :

$ prelude-admin register <profile_name> <requested_permission> <prelude_manager_address> --uid <uid> --gid <gid>

Snort

Pour la sonde Snort, la commande est :

$ sudo prelude-admin register snort "idmef:w admin:r" 192.168.100 --uid 0 --gid 0

Ossec

La commande d’Ossec est similaire à celle de Snort :

$ sudo prelude-admin register ossec "idmef:w admin:r" 192.168.1.100 --uid 0 --gid 0

Démarrage de Prelude

Pour lancer le serveur Prelude, il faut démarrer dans un premier temps Prelude-Manager :

$ sudo prelude-manager

Ensuite Prelude-Correlator, Prelude-LML, et enfin les sondes (Snort et Ossec) :

$ sudo prelude-correlator

$ sudo prelude-lml

Architecture d'une solution Sécurité OSSDans ce qui suit, figure une présentation d’une

architecture de solutions Sécurité OSS.

Rôles de la solution

Ossec

Tout d’abord, afin de s’assurer du bon fonctionnement

des postes informatiques à surveiller, l’installation d’un

logiciel comme Ossec, un HIDS, est très utile. En effet,

Ossec permet de vérifier la modification de fichiers, de

détecter des attaques (rootkits, …) et de générer des

alertes.

Fonctionnement

Topologie Physique

Voici une topologie réseau de base, formée en étoile :

Topologie logique

Explications

L’architecture mise en place doit permettre

l’acheminement d’une alerte, provenant d’un poste

client, jusqu’à son affichage dans la console de

supervision de Nagios. Le schéma ci-dessus, offre une

vision plus claire du trajet parcouru par une alerte. Ce

parcours peut être divisé en plusieurs étapes :

Pour commencer, il y a un poste client (nommé tout

simplement CLIENT), ce dernier est intégré à un

domaine (serveur PDC, nommé LDAP) et dispose d’un

antivirus administré par un serveur (soit nommé

ANTIVIRUS.

1. Un problème x sur CLIENT survient, selon la nature du problème (authentification, virus, …), le contrôleur de domaine LDAP, ou bien le serveur ANTIVIRUS affiche cet évènement dans un fichier log, fichier qui grâce à Ossec est analysé.

2. OSSEC détecte alors le problème selon ses propres règles et fait remonter l’alerte (si besoin) sous forme de message IDMEF au serveur PRELUDE. Le serveur PRELUDE, réceptionnant l’alerte, ajoute alors un évènement dans sa base de données au format IDMEF, respectant ainsi toujours la norme.

3. De son côté, le serveur SNORT, détecte une attaque y sur le réseau, identifiée par ses règles, et transmet alors une alerte IDMEF à PRELUDE. Tout comme pour une alerte provenant d’OSSEC, PRELUDE stocke l’évènement dans la base de données.

4. Le serveur de supervision NAGIOS, afin d’afficher les alertes, check régulièrement le serveur PRELUDE, et dès qu’il détecte une ou des alertes dans la base de données, il affiche un statut CRITICAL ou WARNING pour le service gérant le check de Prelude (soit check_prelude). Ainsi, il détecte les alertes x d’Ossec et y de Snort, qui selon leur priorité, leur niveau d’importance change le statut du service de check_prelude. Les alertes sont alors correctement affichées dans la console du serveur NAGIOS.

Cas pratique

Dans cet exemple, le poste CLIENT tente une

authentification auprès du contrôleur de domaine LDAP.

Le mot-de-passe n’étant pas le bon, après plusieurs

tentatives, que LDAP a pris soin de stocker dans ses

logs, l’application Ossec cliente qui les analyse, par

exemple après trois échecs, transmet alors une alerte

au serveur OSSEC.

OSSEC, réceptionne l’évènement et l’inscrit dans ses

propres logs tout en le transférant au format IDMEF au

serveur PRELUDE.

Prelude-Manager, à la réception de l’alerte, l’ajoute

dans sa base de données.

NAGIOS, comme à son habitude, check la base de

données de PRELUDE toutes les cinq minutes, ainsi, au

bout des cinq minutes, le service configuré utilise la

commande check_prelude pour compter la présence

d’alertes. Si la priorité de cette alerte, à savoir, l’échec

d’authentification ldap, est de type CRITICAL, le statut

du service sous NAGIOS passe alors à l’état CRITICAL.

Pour visualiser les détails des alertes, il faut utiliser

l’interface Web de PRELUDE, c’est-à-dire Prewikka, qui

affiche les alertes de la base de données de Prelude.

Ensuite, il est possible de visualiser plus en détail les

informations :

Comme le montre cette capture d’écran, l’alerte est

beaucoup plus précise, et détaillée en indiquant le

problème rencontré, la sonde qu’il a générée, …etc.

Ainsi, il est possible de trouver l’origine du problème et

donc de le résoudre.