XDR : déploiement de Wazuh pour créer un lab cybersécurité

I. Présentation

Dans cet article, nous allons apprendre à déployer rapidement et facilement la solution XDR open source Wazuh via Docker.

Wazuh est une solution open-source de surveillance des évènements de sécurité basée sur OSSEC. Cette solution permet de jouer le rôle de SIEM (Security Information and Event Management) et de XDR (eXtended Detection and Response) au sein d’une infrastructure.

Notre objectif est ici d’être rapidement opérationnel sur cette solution avec une architecture légère et rapide à déployer. Nous verrons également comment installer l’agent Wazuh sur des systèmes Windows et Linux. Nous finirons par visualiser le statut et la configuration de ces agents dans l’interface Wazuh.

L’idée de l’article n’est pas de décrire l’installation complète de Wazuh dans un environnement d’entreprise, en prenant en compte les bonnes pratiques de déploiement et de sécurité (certificats, mots de passe, redondance, charge). En revanche, suivre cette procédure vous conviendra parfaitement si vous souhaitez le déployer dans un lab cybersécurité, découvrir la solution rapidement ou même vous former aux solutions XDR.

Avant de passer au déploiement, nous allons faire un rapide rappel de ce qu’est un XDR et de ces principales différences avec un antivirus et un EDR.

II. Antivirus, EDR, XDR : quelles différences ?

Le terme antivirus est certainement le plus connu des utilisateurs grand public, même si peu de non-initiés savent réellement quel est leur fonctionnement et rôle. La fonction principale d’un antivirus est de protéger le système des menaces connues. Ils utilisent pour cela l’analyse statique, et notamment les empreintes (hash) pour identifier s’il s’agit de programmes malveillants connus. Les antivirus plus avancés (à l’époque où ils étaient le summum des solutions de sécurité) utilisent également des sandbox pour exécuter dans un environnement contrôlé les programmes lancés par l’utilisateur. Ces environnements limités et surveillés permettent de réaliser une analyse comportementale en vérifiant les actions et communications de chaque programme. 

Les attaquants ont néanmoins appris à contourner ces analyses statiques et dynamiques qui ont donc commencé à montrer leurs limites face aux attaques sophistiquées. À présent, la surveillance efficace d’un système d’information passe par le déploiement d’un EDR (Endpoint Detection & Response) sur chacun des systèmes le composant. Les EDR utilisent des hooks (accroche), des points d'interception au niveau du noyau, pour surveiller les activités des programmes en temps réel. Là où l’antivirus se concentre sur les programmes malveillants, les EDR permettent une surveillance précise du comportement des programmes et des utilisateurs sur le système. En parallèle, ils produisent une télémétrie avancée sur toutes les activités qu’ils jugent suspectes et sont en capacités de bloquer l’exécution d’un programme, l’accès à certaines ressources sensibles ou d’isoler un système compromis du réseau. Cette télémétrie est ensuite centralisée au sein d’une plateforme unique de visualisation, gestion et configuration de l’ensemble des agents déployés. Certains EDR s’appuient notamment sur de l’IA et du machine learning pour repérer des comportements suspects.

Enfin, les XDR (Extended Detection and Response) utilisent l’ensemble de cette télémétrie et des journaux de sécurité pour effectuer de la corrélation des évènements de sécurité. Leur fonction première est d’aider les analyses sécurité via leurs capacités et règles de traitement. 

Prenons l’exemple d’un attaquant qui va effectuer une attaque par brute force répartie sur une centaine de systèmes. La corrélation des évènements de ces systèmes par l’XDR permettra de les regrouper un seul, d’émettre une alerte unique et de la catégoriser en fonction d’un TTP du MITRE ATT&CK. Là où la télémétrie unitaire de chaque système aurait rendu difficile cette mise en relation de différents évènements. De plus, le périmètre de traitement des XDR s’étend en général au-delà des endpoints (systèmes et serveurs) en intégrant, par exemple, les journaux d’évènements, les mails, les alertes réseau, cloud, l’Active Directory, etc.

Les TTP (Tactiques, Techniques and Procedures) du MITRE ATT&CK sont un cadre qui catégorise et documente les méthodes d’attaque utilisées par les attaquants.

Les XDR ont bien sûr de multiples fonctions avancées de surveillance et sécurisation. Mais, l‘idée centrale reste le support de traitement des nombreuses alertes et évènements ainsi que l’automatisation de certaines actions d’audit, de surveillance et de protection.

III. Déployez Wazuh en single mode via Docker

A. Les principaux composants de Wazuh

Wazuh est un XDR qui repose sur plusieurs rôles pouvant être répartis sur plusieurs systèmes (multi-node) ou tous regroupés sur un seul (single-node). Bien entendu, ces deux choix d’architecture dépendent de la charge, des ressources disponibles et du nombre d’agents et d’évènements à monitorer. En général, un déploiement de production dans une entreprise se fera sur du multi-node alors que le déploiement dans un lab ou pour tester la solution se fera sur du single-node.

Voyons à présent les principaux composants d’une installation Wazuh : 

• L’indexer : il stocke et indexe (répertorie) les alertes générées et évènements remontés. C’est également lui qui permet la réalisation de recherche sur les données et les capacités d’analyse et corrélation. L’indexer utilise principalement le format JSON pour le stockage clé-valeur, facilitant ainsi la recherche et l'analyse des données.
• Le Wazuh server (ou manager) : Il traite en temps réel les données reçues des agents, en utilisant des décodeurs et des règles pour détecter les indicateurs de compromission (IoC). Il gère également les communications, configurations et mises à jour des agents.
• Le dashboard : c'est l'interface web qui permet la visualisation en temps réel des données et leur analyse, ainsi que de nombreuses autres fonctionnalités comme les alertes et les rapports.
• Les agents : ce sont les services Wazuh installés et exécutés sur chaque endpoint (postes de travail, serveurs, machines virtuelles). Ils collectent les activités locales et envoient la télémétrie et les alertes au manager pour analyse, corrélation et visualisation.

Voici une vue schématisée et simplifiée de ces différents composants :

Dans cette vue, j’ai représenté chaque composant sur un serveur dédié pour que cela soit plus clair. Cette architecture correspondant à un déploiement multi-node. Cela permet de mieux gérer des charges importantes, notamment via une mise à l’échelle (scaling). On pourra, par exemple, mettre en place deux Wazuh Server (manager) si nous avons énormément d’agents. Dans cet article, nous allons déployer ces trois composants sur un même hôte (single-node).

Vous trouverez une vue plus complète sur la documentation officielle de Wazuh : Wazuh components and data flow

Également, voici les principaux ports qui ont besoin d’être exposés par ces différents composants :

Le déploiement via Docker nécessite la mise en place (automatisée) de quelques volumes. Ces volumes permettent de rendre les données persistantes, ce qui est toujours utile même pour un lab. 

Pour rappel, dans un conteneur Docker, aucune donnée ne persiste une fois qu’il est éteint. Pour palier à cela, un conteneur peut monter un répertoire de l’hôte (comme un répertoire partagé distant) et y stocker des données. Cela s’appelle alors un volume.

Une fois que vous aurez déployé votre infrastructure Wazuh via Docker (chapitre suivant), vous pourrez lister ces volumes via la commande suivante : 

$ docker volume ls 

DRIVER    VOLUME NAME
local     single-node_filebeat_etc
local     single-node_filebeat_var
local     single-node_wazuh-dashboard-config
local     single-node_wazuh-dashboard-custom
local     single-node_wazuh-indexer-data
local     single-node_wazuh_active_response
local     single-node_wazuh_agentless
local     single-node_wazuh_api_configuration
local     single-node_wazuh_etc
local     single-node_wazuh_integrations
local     single-node_wazuh_logs
local     single-node_wazuh_queue
local     single-node_wazuh_var_multigroups
local     single-node_wazuh_wodles

B. Déploiement de Wazuh

Nous allons déployer Wazuh en mode single-node, c'est-à-dire avec les trois rôles sur un même système. Nous utiliserons pour cela la conteneurisation avec Docker, ce qui rendra le déploiement très rapide et très simple, parfait pour faire des tests !

Commençons par aller voir quelle est la dernière version release du dépôt wazuh-docker :

Dans mon cas, il s’agit de la version 4.11.0, il faut spécifier cette version dans l’option -b (--branch) de git (pensez à mettre à jour la version dans la commande suivante) : 

git clone https://github.com/wazuh/wazuh-docker.git -b v4.11.0

Il faut ensuite se rendre dans le dossier wazuh-docker/single-node/, dans lequel vous trouverez plusieurs dossiers et fichiers : 

Le fichier docker-compose.yml est celui qui permet le déploiement des différents composants de Wazuh (indexer, manager, dashboard), chacun dans un conteneur dédié. C’est dans ce fichier que sont stockés les éléments de configuration relatifs à l’exposition des ports, aux relations entre les conteneurs, aux volumes permettant le stockage de fichiers persistants sur le système hôte, etc. Je vous invite à les consulter si vous êtes curieux.

Le fichier generate-indexer-certs.yml contient lui les directives de déploiement d’un petit conteneur basé sur l’image Docker wazuh/wazuh-cert-tool. Son rôle est la génération automatisée des certificats SSL/TLS nécessaires au bon fonctionnement et à la confidentialité des échanges entre les différents composants de Wazuh.

Dans une infrastructure réelle de production, il faut bien sûr passer par des certificats signés avec votre PKI interne, mais nous sommes ici dans le contexte d’un lab/test.

Avant tout déploiement des conteneurs relatifs à Wazuh, il faut donc générer ces certificats, ce que l’on peut faire à l’aide de la commande suivante : 

docker compose -f generate-indexer-certs.yml up

Cette commande a pour effet de créer différents certificats dans le dossier suivant :

$ sudo ls /opt/wazuh-docker/single-node/config/wazuh_indexer_ssl_certs/ -al
total 56
dr-x------ 2 root    root            4096 11 mars  22:06 .
drwxrwxr-x 6 mickael mickael         4096 11 mars  22:06 ..
-r-------- 1 mickael mickael         1708 11 mars  22:06 admin-key.pem
-r-------- 1 mickael mickael         1119 11 mars  22:06 admin.pem
-r-------- 1 mickael mickael         1704 11 mars  22:06 root-ca.key
-r-------- 1 dnsmasq systemd-journal 1704 11 mars  22:06 root-ca-manager.key
-r-------- 1 dnsmasq systemd-journal 1204 11 mars  22:06 root-ca-manager.pem
-r-------- 1 mickael mickael         1204 11 mars  22:06 root-ca.pem
-r-------- 1 mickael mickael         1704 11 mars  22:06 wazuh.dashboard-key.pem
-r-------- 1 mickael mickael         1261 11 mars  22:06 wazuh.dashboard.pem
-r-------- 1 mickael mickael         1704 11 mars  22:06 wazuh.indexer-key.pem
-r-------- 1 mickael mickael         1257 11 mars  22:06 wazuh.indexer.pem
-r-------- 1 dnsmasq systemd-journal 1704 11 mars  22:06 wazuh.manager-key.pem
-r-------- 1 dnsmasq systemd-journal 1257 11 mars  22:06 wazuh.manager.pem

Maintenant que nos certificats SSL/TLS sont prêts, nous pouvons créer et démarrer nos 3 conteneurs Wazuh à l’aide du fichier de configuration principal : 

docker compose -f docker-compose.yml up

Dans les logs qui sont affichés dans votre terminal (si vous n’avez pas utilisé l’option -d), vous pourrez constater l’activité des trois conteneurs différents, exemple :

# Extrait des logs lors du démarrage des conteneurs (terminal)
wazuh.dashboard-1  | {"type":"log","@timestamp":"2025-03-11T21:15:29Z","tags":["info","plugins","wazuh","monitoring"],"pid":54,"message":"Updated the wazuh-agent template"}        
wazuh.indexer-1    | [2025-03-11T21:15:29,238][INFO ][o.o.c.m.MetadataUpdateSettingsService] [wazuh.indexer] updating number_of_replicas to [0] for indices [wazuh-monitoring-2025.11w]                                                                                       
wazuh.dashboard-1  | {"type":"log","@timestamp":"2025-03-11T21:15:29Z","tags" ["info","plugins","wazuh","monitoring"],"pid":54,"message":"Settings added to wazuh-monitoring-2025.11
w index"}                                                                                 
wazuh.manager-1    | 2025-03-11T21:15:34.047Z   INFO    log/harvester.go:302    Harvester started for file: /var/ossec/logs/alerts/alerts.json     
[...]

Si dans ces logs, vous constatez des stack trace Java mentionnant SSL/TLS et des journaux qui apparaissent en boucle, c’est qu’il y a vraisemblablement un problème au niveau des certificats. Vérifier que vous avez bien pris la dernière release du dépôt wazuh-docker que vous n’êtes pas sur la main (option -b).

Quelques secondes après l’exécution de cette commande, vous pourrez saisir (dans un autre terminal) la commande suivante pour vérifier l’état des conteneurs démarrés : 

docker ps -a

Voici la vue et les statuts qui sont attendus :

Nous y retrouvons notamment les ports réseau exposés par chacun des conteneurs. À présent, vous pourrez vous rendre sur l’URL suivante via un navigateur : https://localhost

Après avoir accepté d’utiliser une connexion non sécurisée (certificat auto-signé), vous vous retrouverez avec la page de login de l’XDR Wazuh. Voici les identifiants à utiliser : admin:SecretPassword

Et voilà, notre Wazuh est installé ! Vous pouvez à présent naviguer dans l’interface de gestion et de configuration.

IV. Ajouter des agents Wazuh Windows et Linux

A. Déploiement de l’agent Wazuh sous Windows

Passons à présent au déploiement d’un agent Wazuh sur un système Windows. Cela nous permettra d’avoir nos premières remontées d’information et des données dans le dashboard.

Dans le dashboard, rendez-vous dans Agents Management > Summary, vous aurez alors accès à une page contenant un bouton Deploy new agent :

Sur cette nouvelle page, il vous faudra sélectionner MSI 32/64 bits dans l’encart Windows ainsi que saisir l’adresse IP du Wazuh Server : 

Optionnellement, vous pourrez également saisir le nom que vous souhaitez donner à l’agent lorsqu’il apparaitra dans l’interface. Par défaut, les agents prennent le nom de l’hôte sur lequel ils tournent.

Cette configuration permet de remplir une ligne de commande PowerShell que vous trouverez en bas de page :

Il suffit alors de copier/coller cette ligne de commande PowerShell dans un terminal lancé en tant qu’administrateur. Elle se charge de : 

• Télécharger l’agent Wazuh depuis la source officielle et dans la bonne version ;
• Lancer l’installateur avec en paramètre le serveur Wazuh à contacter.

Pour les cas où votre système n’a pas un accès direct à Internet, vous pouvez bien sûr procéder en trois étapes : 

• Téléchargement manuellement l’installateur .msi sur un système ;
• Le transférer sur l’hôte cible ;
• Exécuter la ligne de commande d’installation.

Par défaut, le binaire d’installation fournit par Wazuh n’est pas signé. Lors de l’utilisation via msiexec.exe, cela entraine une erreur “Impossible d’ouvrir ce package d’installation. Vérifiez qu’il existe et que vous êtes autorisé à y accéder, ou vérifiez auprès de votre revendeur d’applications que ce package de Windows Installer est valide” : 

Et, double attention, l’utilisation de l’option /q (/quiet) de msiexec.exe dans la ligne de commande par défaut masque ce message d’erreur ! 

Pour une installation qui n’est pas regardante sur ce point (cas d’un lab) et unitaire, nous allons réaliser un déploiement à la main. Il nous faut pour cela exécuter directement le .msi en double-cliquant dessus (en tant qu’administrateur). Cliquez ensuite sur Exécuter dans la fenêtre d’avertissement de sécurité (elle aussi due à la non-signature du binaire). La suite de l’installation est assez classique.

Une fois réalisée, il est nécessaire de demander une clé d’enregistrement au serveur à l’aide de la commande suivante (à exécuter via un terminal PowerShell) : 

&"C:\Program Files (x86)\ossec-agent\agent-auth.exe" -m <IP Wazuh Server>

Cette commande permet à l’agent Wazuh de s’enregistrer auprès du serveur Wazuh : 

Une demande d’authentification est envoyée (ici, aucun mot de passe demandé, nous sommes dans un lab). Le serveur renvoi ensuite une clé, propre à l’agent, qui servira à authentifier et chiffrer les échanges. Cette clé peut être trouvée dans le C:\Program Files (x86)\ossec-agent\client.keys.

Nous allons ensuite aller exécuter le programme win32ui qui se situe dans le dossier C:\Program Files (x86)\ossec-agent. Dans la fenêtre qui s’ouvre, la clé d’authentification est déjà saisie. Il nous reste à renseigner l’adresse IP du Wazuh Server et cliquer sur Save : 

Dernière étape, démarrer le serveur Wazuh avec la ligne de commande suivante depuis un terminal PowerShell lancé en tant qu’administrateur : 

PS Z:\> NET START WazuhSvc
Le service Wazuh a démarré.

Pour un déploiement propre, automatisé et silencieux, il sera nécessaire de passer par une signature au préalable du binaire avec votre PKI interne. Une autre option serait de désactiver le filtre SmartScreen qui protège les postes contre l’exécution de binaires non reconnus/signés et venant d’internet, mais ce n’est pas conseillé du tout.

Pour constater que votre agent Wazuh est déployé et actif, voici quelques commandes de debug et le résultat attendu (pensez bien à adapter le PID) : 

# Vérifier le statut du service Wazuh
PS Z:\> get-service -Name WazuhSvc

Status   Name               DisplayName
------   ----               -----------
Running  WazuhSvc           Wazuh

# Vérifier que le processus wazuh-agent.exe est en cours d’exécution (PID : avant dernière colonne)
PS Z:\> ps |findstr "wazuh"
    514      24    23804      38028       9,00   4300   0 wazuh-agent

# Vérifier qu’une communication est établie sur le port 1514 entre l’agent (PID) et le serveur Wazuh
PS Z:\> netstat -ano |findstr "4300"
  TCP    192.168.56.102:61438   192.168.56.105:1514    ESTABLISHED     4300

Pour les plus curieux, vous trouverez les éléments de configuration de l’agent Wazuh dans le dossier C:\Program Files (x86)\ossec-agent. Le fichier ossec.conf contient toutes les informations relatives au Wazuh Server, utile en cas de changement d’IP.

Notre agent Wazuh est maintenant déployé sous Windows, passons au déploiement sur un système Linux avant de visualiser leur activité dans la console Wazuh.

B. Déploiement de l’agent Wazuh sous Linux

Pour le déploiement sous Linux, retournons à nouveau dans Agents Management > Summary > Deploy New Agent.

Nous allons ici cliquer sur Deb amd64 dans l’encart Linux (dans mon lab, je suis sous Debian), remplir l’adresse IP du serveur comme précédemment sous Windows, et récupérer la ligne de commande en bas de page :

Sous Linux, nous ne sommes pas embêtés avec la signature des binaires. La ligne de commande permet l’installation sans problème de l’agent et de ses services. Nous devons tout de même générer une clé qui servira pour l’authentification de notre agent et le chiffrement des échanges (depuis un terminal en tant que root) : 

$ /var/ossec/bin/agent-auth -m 192.168.56.105
2025/03/15 16:23:33 agent-auth: INFO: Started (pid: 91509).
2025/03/15 16:23:33 agent-auth: INFO: Requesting a key from server: 192.168.56.105
2025/03/15 16:23:33 agent-auth: INFO: No authentication password provided
2025/03/15 16:23:33 agent-auth: INFO: Using agent name as: kali-it-connect
2025/03/15 16:23:33 agent-auth: INFO: Waiting for server reply
2025/03/15 16:23:33 agent-auth: INFO: Valid key received

$ cat /var/ossec/etc/client.keys 
003 kali-it-connect any 538d20c3918e0bbf071f711edd67f498bea85ddd1d149a4befdf6995c42adfe2

Une fois cela fait, il nous faut démarrer le service wazuh-agent. Nous allons exécuter ces trois lignes de commandes depuis un terminal privilégié (root) : 

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Comme sous Windows, vous pourrez confirmer que votre agent est bien en cours d’exécution avec les quelques commandes de debug suivantes :

# Vérifier le statut du service wazuh-agent 
$ systemctl status wazuh-agent               
wazuh-agent.service - Wazuh agent
     Loaded: loaded (/usr/lib/systemd/system/wazuh-agent.service; enabled; preset: disabled)
     Active: active (running) since Fri 2025-03-15 16:25:54 CET; 16s ago
 Invocation: 94720a2045cd48a2a3a44aff3141933b
    Process: 92810 ExecStart=/usr/bin/env /var/ossec/bin/wazuh-control start (code=exited, status=0/SUCCESS)
      Tasks: 31 (limit: 9388)
     Memory: 12.9M (peak: 21.3M)
        CPU: 456ms
     CGroup: /system.slice/wazuh-agent.service
             ├─92833 /var/ossec/bin/wazuh-execd
             ├─92852 /var/ossec/bin/wazuh-agentd
             ├─92873 /var/ossec/bin/wazuh-syscheckd
             ├─92883 /var/ossec/bin/wazuh-logcollector
             └─92908 /var/ossec/bin/wazuh-modulesd
[...]
                                                                                                                                                            
# Vérifier la communication réseau entre l’agent et le Wazuh Server
$ ss -petulan |grep wazuh
tcp   ESTAB      0      0      192.168.56.105:57912  192.168.56.105:1514 users:(("wazuh-agentd",pid=98231,fd=8))                                         uid:119 ino:369001 sk:2004 cgroup:/system.slice/wazuh-agent.service <->
                                                                                               
# Vérifier  l’activité du processus wazuh-agentd
$ ps -edf |grep wazuh-agent    
wazuh      92852       1  0 16:25 ?        00:00:00 /var/ossec/bin/wazuh-agentd

Pour les plus curieux, vous trouverez les éléments de configuration de l’agent Wazuh dans le répertoire /var/ossec/etc/ : 

$ ls /var/ossec/etc 
client.keys  internal_options.conf  local_internal_options.conf  localtime  ossec.conf  shared  wpk_root.pem

Le fichier ossec.conf contient toutes les informations relatives au Wazuh Server, utile en cas de changement d’IP.

Notre agent Wazuh est maintenant déployé sous Windows et sous Linux. Nous avons tout ce qu’il faut pour commencer à expérimenter sur une plateforme fonctionnelle. Faisons un rapide tour sur le dashboard pour visualiser nos agents.

C. Visualiser et gérer les agents Wazuh

Comme pour toute solution de centralisation basée sur des agents (EDR, XDR, etc.), nous avons bien sûr une page dédiée à leur gestion au sein du dashboard Wazuh. Il faut retourner dans le menu Agents Management > Summary :

Nous voyons ici nos deux agents et les informations associées (ID, nom d’hôte, IP, OS, statut, etc). Différentes statistiques sur l’état, les OS et les groupes d’agents sont également affichées. Elles sont surtout utiles dans des infrastructures d’entreprise traitant des dizaines ou centaines d’agents. Nous avons notamment la possibilité de répartir nos agents dans des groupes, ce qui permettra de leur appliquer des configurations différentes en fonction des OS ou de leur criticité.

Cette page permet aussi de gérer les agents et leurs configurations à distance. Mais, nous le traiterons probablement dans de futurs articles.

V. Conclusion

Dans cet article, nous avons vu comment devenir rapidement opérationnel sur la solution open-source XDR Wazuh. Après l’avoir déployé via Docker en single-node, nous avons déployé un agent sous Windows et sous Linux.

Wazuh est une solution open-source et comme tout XDR, elle regorge de fonctionnalités très intéressantes. Dans le cadre d’un lab cybersécurité, cette solution permet de voir les effets d’une cyberattaque et de s’entrainer à la gestion, configuration et visualisation des évènements de sécurité.

Je vous encourage à aller plus loin dans votre découverte de Wazuh. En attendant, n’hésitez pas à mettre vos avis et questions dans les commentaires ou à venir en discuter sur notre serveur Discord.