Surveillez votre système pour prévenir et détecter toute action malveillante

Un IDS (Intrusion Detection System) est un programme qui s'appuie sur les points d’instrumentation d’un système d’exploitation afin de détecter d’éventuelles actions malveillantes. Pour un HIDS (Host IDS), un point d’instrumentation est une source d'information générée par le système d'exploitation (tentatives de connexion à la console, arrêt ou démarrage de tel ou tel service, etc.) ou par des logiciels tiers (connexions HTTP à un serveur Apache, authentification sur un serveur MySQL, etc.). Sous Linux, on retrouve toutes ces informations dans le répertoire /var/log. En complément, il existe des NIDS (Network IDS) qui sont placés sur le réseau dans le but de traquer les interactions malveillantes entre machines. Wazuh est donc un HIDS proposant de sélectionner parmi toute cette masse d'informations les événements relevant de la sécurité du système.

1. Banc de test

Notre environnement de test comporte quatre machines. La première est une machine nommée « cible » occupant l'IP 192.168.45.1. Elle embarque l'agent Wazuh. En détection d'intrusion, on appelle agent le programme installé sur la machine et qui la surveille. Cet agent doit être le plus compact possible pour limiter la surface d'attaque. En général, quand l'agent constate un souci de sécurité, il remonte immédiatement l'information à un manager. La seconde machine est donc le manager en question et elle répond au nom de wazuh-manager sur l'IP 192.168.45.2. Cette machine embarque la partie de Wazuh nommée wazuh-manager qui orchestre les agents distribués sur les machines du réseau. On notera que les managers peuvent être organisés en cluster pour travailler de concert. La troisième machine s'appelle elk pour Elasticsearch Logstash Kibana. Cette machine va organiser et présenter les données remontées par wazuh-manager dans le but de les rendre exploitables par l'utilisateur final. Elle est sur l'IP 192.168.45.3. Enfin, la dernière machine nommée attaquant va nous servir à générer des événements de sécurité sur « cible ». Elle est en 192.168.45.4. Toutes les machines sont en Debian Buster.

2. Installation de Wazuh

Toutes les machines embarquant des composants Wazuh doivent suivre des étapes d'installation très similaires. Les manipulations qui suivent sont donc à réaliser sur cible et wazuh-manager. Nous allons ici présenter les manipulations sur wazuh-manager, mais il faudra faire les mêmes sur cible. Avant tout, il faut installer les paquets nécessaires à l'ajout des dépôts Wazuh :

On récupère la clé du dépôt Wazuh et on l'ajoute dans la configuration d'apt :

Ensuite, on ajoute le dépôt Wazuh dans la configuration d'apt :

Lors de l'update, on constate que la base de données d'apt intègre maintenant des paquets provenant de chez Wazuh :

2.1 Installation du manager et de l'agent

Passons maintenant à la partie spécifique à wazuh-manager. Commençons par installer le paquet sur la machine wazuh-manager :

Et vérifions que ça tourne :

Le service wazuh-manager est fonctionnel, passons à l'agent. Installons le paquet sur la machine cible :

L'étape suivante est d'enregistrer l'agent auprès du manager. Ils vont communiquer avec une clé symétrique, c'est-à-dire qu'ils vont se partager un mot de passe connu que d'eux.

2.2 Enregistrement de l'agent

Sur le manager, il nous faut ajouter l'agent de cible dans la base de données des agents déployés. Nous allons utiliser la commande manage_agents qui se trouve dans le répertoire /var/ossec/bin de la machine wazuh-manager.

Cette commande ajoute un agent nommé cible (argument -n) sur une machine possédant l'adresse IP 192.168.45.1. Dans notre exemple, il est en effet plus simple d'avoir un nom d'agent identique à celui de la machine où il est installé. Vérifions que la machine est bien enregistrée :

Notre machine cible s'est vue attribuer l'ID 001. Lors de cette étape, la fameuse clé a été générée. Il faut l'extraire pour la communiquer à l'agent de cible. Cela se fait toujours avec la même commande en utilisant l'argument -e qui extrait la clé d'un agent identifié par l'ID passé en paramètre :

Il faut donc communiquer cette clé à l'agent de cible. Toujours avec la commande manage_agents, nous allons l'enregistrer avec l'argument -i auquel on passe la valeur de la clé :

2.3 Démarrage de l'agent

Une fois l'agent configuré, démarrons-le :

Arrêtons-nous un instant sur l'affichage du statut :

Nous constatons qu'il y a tout un tas de services démarrés notamment ossec-syscheckd et ossec-logcollector. En gros, le premier est chargé de surveiller l'intégrité du système (fichiers modifiés, rootkits) et même de réaliser un audit des configurations du système (avec de très bonnes suggestions de remédiations). Le second analyse en continu le répertoire /var/log à la recherche de remontées d'informations suspectes de la part des applications.

Testons maintenant la bonne communication de l'agent avec le manager. Nous allons utiliser la commande agent_control depuis wazuh-manager pour lister les agents qu'il supervise :

Nous allons maintenant nous placer sur attaquant et faire des connexions sur le serveur SSH de cible avec un compte utilisateur inexistant :

Nous entrons trois fois un mot de passe bidon jusqu’à fermeture de la connexion par le serveur SSH de cible. Voyons si nous avons une trace dans les logs du manager (les logs se trouvent dans le fichier /var/ossec/logs/alerts/alerts.log) :

Nous y trouvons bien une trace de connexion d'un utilisateur inexistant nommé malmsteen. Arrivé ici nous avons validé le bon fonctionnement de l'agent et du manager. La prochaine étape est d'envoyer toutes ces informations dans une plateforme de visualisation.

3. Raccordement à ELK

ELK est une pile composée de trois logiciels : Elasticsearch, Logstash et Kibana. Dans notre article, nous allons laisser de côté Logstash et n'utiliser que Elasticsearch et Kibana. Pour faire très simple, Elasticsearch est une base de données extrêmement rapide pour l'indexation (et donc la recherche). L'idée va être d'envoyer tous les logs du manager dans la base de données Elasticsearch. Le programme situé sur wazuh-manager qui va lire les logs et les envoyer à l'instance d'Elasticsearch installée sur elk se nomme Filebeat.

3.1 Configuration de Filebeat sur « wazuh-manager »

Nous allons l'installer en ajoutant un dépôt apt ainsi que sa clé. D'abord la clé :

Puis le dépôt :

Nous validons que les dépôts d'elastic.co sont bien présents :

Installons Filebeat :

Puis descendons un fichier de configuration de base pour Filebeat. Le seul élément à changer sera l'adresse de la base Elasticsearch. Ce fichier est disponible sur le git de elastic.co :

L'étape suivante est de récupérer un fichier de configuration pour Filebeat. En effet, Filebeat doit avoir connaissance de la structure des logs de Wazuh pour les envoyer à la base Elasticsearch. Ce fichier « template » est disponible sur le git de elastic.co :

Ensuite, ajoutons le module Wazuh pour Filebeat qui va s'appuyer sur ces deux fichiers pour envoyer les logs formatés à la base Elasticsearch :

Enfin, nous n'avons plus qu'à indiquer à Filbeat la localisation de la base Elasticsearch dans son fichier de configuration /etc/filebeat/filebeat.yml :

On redémarre le tout :

Et on vérifie :

Passons à l'installation de la couche ELK.

3.2 Installation de Elasticsearch sur « elk »

À l'instar de wazuh-manager, il faut installer les dépôts de elastic.co. Je passe vite là-dessus :

Passons à l'installation de Elasticsearch :

Activons-le au démarrage de la machine elk :

On ne le démarre pas de suite, car il y a quelques éléments à configurer dans le fichier /etc/elasticsearch/elasticsearch.yml :

Le premier paramètre node.name est le nom de ce nœud Elasticsearch. En effet, Elasticsearch est une base de données fortement distribuée, chaque participant (ou nœud) est identifié par un nom. Ici, il s'agit du nom pleinement qualifié de la machine elk, soit elk.lab.secusys.local. Le second paramètre network.host indique sur quelle(s) interface(s) Elasticsearch doit écouter les requêtes des clients type Filebeat. Ici, nous avons mis 0.0.0.0 pour dire « toutes les interfaces ». S'en suit http.port qui définit le port sur lequel écouter. Enfin, cluster.initial_master_nodes donne la liste des nœuds habilités à être élus maîtres sur l'infrastructure distribuée Elasticsearch. Démarrons le service :

Vérifions son bon fonctionnement :

Vérifions également qu'il écoute bien sur le port 9200 :

Nous constatons que ça communique entre wazuh-manager (192.168.45.2) et elk (192.168.45.3). Repassons sur wazuh-manager pour vérifier que Filebeat arrive bien à s'accrocher à Elasticsearch :

C'est tout bon ! Passons à Kibana.

3.3 Installation de Kibana

Kibana est un service web de visualisation du contenu de la base Elasticsearch. Il lui faut deux choses pour fonctionner : la localisation de la base Elasticsearch et la façon de présenter les données remontées par Wazuh. Installer Kibana sur elk :

Commençons par le plugin Wazuh pour Kibana :

Ensuite configurons Kibana pour que 1) il écoute sur toutes les interfaces réseaux de la machine elk et que 2) il trouve l'instance d'Elasticsearch :

Le premier paramètre server.host définit sur quelle(s) interface(s) Kibana doit écouter. Ici, on écoute sur toutes (0.0.0.0). Le second elasticsearch.hosts donne l’emplacement réseau du service Elasticsearch. Activons et démarrons Kibana :

Vérifions :

Nous pouvons maintenant nous connecter sur l'interface Kibana qui répond sur http://192.168.45.3:5601. Aucun identifiant/mot de passe ne nous est demandé. Nous laissons ça en l'état, car configurer la sécurité de l'accès à Kibana pourrait faire l'objet d'un article entier. Une fois sur l'interface, nous cliquons sur l'élément nommé Discover (Figure 1 en haut à gauche dans le carré rouge). Nous choisissons l'item wazuh-alerts-3.x-* dans le menu déroulant juste à côté. Nous pouvons visualiser les informations brutes remontées par Filebeat (ici une tentative de connexion SSH d'un utilisateur « tipiak » inexistant).

Dans le menu déroulant, un second item wazuh-monitoring-3.x-* est disponible. Nous y trouvons les informations à propos des agents déployés sur le réseau (Figure 2). Le lecteur au regard affûté aura remarqué que l'IP vue pour « cible » est 10.0.2.15, cela est dû au fait que la plateforme de test est en VM et que chaque machine est doublement attachée avec une interface NAT sur le 10.0.2.0/24 (pour sortir sur le net) et une interface sur un réseau interne à l'hyperviseur en 192.168.45.0/24 (sinon les machines ne se verraient pas).

Ces deux sources d'informations sont complètes, mais pas vraiment exploitables. Ce qui nous amène à la dernière partie de l'article, à savoir la configuration de l'API Wazuh. Cette partie nous permettra de tirer le meilleur de l'intégration Wazuh dans ELK.

4. Configuration de l'API Wazuh

L'API Wazuh est une interface de communication permettant à des programmes tiers d'interroger le service wazuh-manager. Kibana va tirer parti de cette API pour nous permettre de piloter l'infrastructure Wazuh facilement.

Retournons sur wazuh-manager pour configurer l'accès à cette API implémentée en Node.js. Ajoutons donc le dépôt Node.js pour Debian :

Et installons le service Node.js ainsi que l'API Wazuh :

Comme toujours, vérifions :

À partir de cet instant, l'API est accessible par tout le monde et de partout. Ce n'est pas très sérieux pour un HIDS. Nous allons ajouter un couple identifiant/mot de passe pour accéder à l'API. Il faut se rendre dans le répertoire /var/ossec/api/configuration/auth/ pour y configurer un htaccess. Le htaccess est un fichier traditionnellement associé au serveur web demandant une authentification lors de l'accès à certaines URL protégées. Ici, l'URL en question est le point d'entrée de l'API. La génération du fichier se fait via le package htpasswd de la commande node :

Nous avons créé un utilisateur « waz » avec comme mot de passe « ossec ». Nous pouvons maintenant redémarrer Elasticsearch et Kibana :

Retournons dans l'interface web Kibana pour cliquer sur la petite frimousse encadrée à gauche dans la Figure 3. Vous allez arriver sur un écran vous demandant de renseigner un accès à l'API Wazuh. Vous pouvez donner les paramètres configurés précédemment à savoir : User « waz », Password « ossec », URL « http://192.168.45.2 » et le port « 55000 ». Une fois ces paramètres rentrés, vous pouvez cliquer sur Overview en haut à gauche et avoir accès à tout un tas de statistiques bien plus exploitables que les données brutes de la section précédente (Figure 3).

Toutefois, si une fois arrivé à cette étape Kibana se plaint d'index défaillants, vous pouvez les réinitialiser avec les commandes suivantes :

Et relancer le couple Elasticsearch/Kibana.

Dernier conseil, le démarrage de ces deux services peut prendre pas mal de temps. Je vous conseille de superviser le démarrage de l'un puis de l'autre avec les commandes suivantes. Pour Elasticsearch :

Et pour Kibana :

Conclusion

Nous avons vu comment mettre en place et surtout exploiter une flotte de HIDS sur les machines composants un réseau. Un axe d'améliorations serait de sécuriser les communications de l'infrastructure ELK en chiffrant et en authentifiant les échanges entre Kibana et Elasticsearch. Un autre point faible est la communication en clair entre l'API Wazuh et Kibana. Enfin, il serait de bon ton d'ajouter une authentification pour l'accès à Kibana (par exemple via un reverse-proxy).