Installer et configurer Wazuh XDR sur Rocky Linux 9 : serveur, agents Linux et Windows

pourquoi Wazuh ?

Face à la multiplication des vecteurs d’attaque et à l’évolution permanente des techniques offensives, les équipes de sécurité ont besoin d’outils capables de centraliser la détection, l’analyse et la réponse aux incidents sur l’ensemble de leur parc. Wazuh est une plateforme open source qui combine les fonctions d’un SIEM (Security Information and Event Management) et d’un XDR (Extended Detection and Response) au sein d’une solution unifiée, gratuite et maintenue par une communauté active.

Initialement né comme un fork du projet OSSEC en 2015, Wazuh a considérablement évolué pour devenir une solution de sécurité à part entière. La plateforme collecte et analyse les journaux d’événements, surveille l’intégrité des fichiers (FIM), évalue la conformité des configurations (SCA), détecte les vulnérabilités connues (CVE) sur les terminaux, et permet de déclencher des actions de remédiation automatiques (Active Response). Son architecture repose sur des agents légers déployés sur les postes de travail et serveurs supervisés, qui transmettent leurs données à un ensemble de composants centraux.

1. Architecture et composants de Wazuh

Avant toute installation, il est important de comprendre l’architecture de la plateforme. Wazuh repose sur trois composants centraux qui collaborent pour collecter, indexer et restituer les données de sécurité. A ces briques serveur s’ajoute l’agent, un processus léger installé sur chaque terminal supervisé.

1.1 Les trois briques centrales

Le Wazuh Server (manager) constitue le cœur de la plateforme. Il reçoit les événements envoyés par les agents, les décode grâce à un moteur d’analyse basé sur des règles (plus de 4 000 règles prédéfinies), corrèle les alertes, et expose une API REST pour l’administration programmatique. Le manager gère également l’enregistrement des agents et peut leur pousser des configurations à distance. Depuis la version 4.14.0 publiée en octobre 2025, les agents supportent le rechargement à chaud de leur configuration, ce qui réduit les interruptions lors des modifications.

Le Wazuh Indexer est un moteur de recherche et d’indexation basé sur OpenSearch. Il stocke l’ensemble des alertes générées par le manager et les rend interrogeables via des requêtes structurées. Dans un déploiement all-in-one (tous les composants sur une seule machine), l’indexer est le composant le plus gourmand en ressources, notamment en mémoire vive, car il utilise une JVM (Java Virtual Machine) pour ses opérations.

Le Wazuh Dashboard est l’interface web de la plateforme. Basé sur OpenSearch Dashboards, il permet de visualiser les alertes, d’explorer les événements, de consulter les rapports de conformité, de gérer les agents et de configurer certains paramètres. Par défaut, il écoute en HTTPS sur le port 443 avec un certificat auto-signé.

1.2 L’agent Wazuh

L’agent est un processus léger, multiplateforme (Linux, Windows, macOS, Solaris, AIX), qui consomme en moyenne 35 Mo de mémoire vive. Il remplit plusieurs fonctions essentielles : collecte de journaux, surveillance de l’intégrité des fichiers, inventaire logiciel, évaluation de la configuration, détection de rootkits et communication chiffrée avec le manager. L’agent est compatible avec la plupart des systèmes d’exploitation.

1.3 Ports réseau à prévoir

La communication entre les composants repose sur plusieurs ports TCP. Voici les ports par défaut:

1.4 Modes de déploiement

Wazuh propose deux modes de déploiement principaux. Le mode all-in-one installe les trois composants centraux sur un seul hôte. Ce mode convient aux laboratoires, aux environnements de test, et aux déploiements en production supervisant jusqu’à 100 agents environ, avec une rétention de 90 jours de données indexées. Le mode distribué sépare les composants sur des machines distinctes et permet de constituer des clusters (multi-noeud) pour le manager et l’indexer, apportant haute disponibilité et répartition de charge. Pour les environnements dépassant 100 agents ou nécessitant une forte résilience, le mode distribué est recommandé.

Pour notre homelab, nous utilisons le mode all-in-one, le plus rapide à mettre en œuvre et suffisant pour la plupart des cas d’usage initiaux.

2. Fonctionnalités principales de Wazuh

Avant d’entrer dans l’installation, il est utile de connaître les modules de sécurité disponibles dans Wazuh. Chacun d’entre eux peut être activé ou désactivé indépendamment, ce qui permet d’adapter la supervision aux besoins spécifiques de l’environnement.

2.1 File Integrity Monitoring (FIM)

Le module FIM surveille en temps réel les modifications apportées aux fichiers et répertoires critiques du système. Il détecte les changements de contenu, de permissions, de propriétaire et d’attributs. Chaque modification est enregistrée avec l’identité de l’utilisateur ou du processus responsable. Ce module est indispensable pour répondre aux exigences de normes comme PCI-DSS (requirement 11.5) ou NIST 800-53.

2.2 Security Configuration Assessment (SCA)

Le module SCA analyse la configuration des terminaux en la comparant à des politiques de référence, notamment les benchmarks du CIS (Center for Internet Security). Il identifie les écarts par rapport aux bonnes pratiques de durcissement et propose des actions correctives. Wazuh fournit des politiques SCA prêtes à l’emploi pour de nombreux systèmes, dont Rocky Linux 9 et Windows Server 2022. A noter : la version 4.14.3 a corrigé plusieurs règles SCA spécifiques à Rocky Linux 9 et à Windows Server 2022.

2.3 Détection de vulnérabilités

Le module de détection de vulnérabilités croise l’inventaire logiciel collecté par les agents avec la base de données CVE maintenue par Wazuh CTI (Centralized Threat Intelligence). Lorsqu’un paquet installé correspond à une vulnérabilité connue, une alerte est générée avec le niveau de sévérité, la référence CVE et le statut (Active ou Solved). Ce mécanisme fonctionne sur Linux (paquets RPM et DEB) et sur Windows (correctifs KB).

2.4 Active Response

L’Active Response permet d’exécuter automatiquement des actions de remédiation lorsqu’une alerte correspond à des critères prédéfinis. Les actions disponibles incluent le blocage d’une adresse IP via le pare-feu, l’arrêt d’un processus suspect, ou l’exécution d’un script personnalisé. Cette fonctionnalité doit être configurée avec prudence : un faux positif déclenchant un blocage réseau peut interrompre un service légitime.

2.5 Conformité réglementaire

Wazuh intègre des tableaux de bord et des règles mappées sur les référentiels réglementaires courants : PCI-DSS, HIPAA, NIST 800-53, GDPR et TSC (SOC 2). Ces correspondances permettent d’identifier rapidement les écarts et de produire des rapports exploitables lors des audits.

3. Prérequis côté serveur Rocky Linux 9

3.1 Dimensionnement matériel

Le dimensionnement dépend directement du nombre d’agents supervisés et du volume d’alertes générées par seconde (APS). Pour un déploiement all-in-one, Wazuh publie les recommandations suivantes dans sa documentation officielle :

Source : Wazuh Quickstart – Requirements

Ces valeurs constituent des repères pour un environnement type. En production, le stockage réel dépend de la volumétrie de journaux (nombre d’événements par seconde), des modules activés (la détection de vulnérabilités et le FIM augmentent le volume d’alertes), et de la politique de rétention appliquée. Pour un environnement de test ou de laboratoire avec une dizaine d’agents, 4 vCPU, 8 Go de RAM et 50 Go de disque SSD suffisent.

Parmi les composants, c’est l’indexer (OpenSearch) qui consomme le plus de ressources, en particulier en mémoire. Le moteur d’analyse du manager (wazuh-analysisd) est quant à lui fortement sollicité en CPU, car il traite les événements de manière séquentielle.

3.2 Systèmes d’exploitation supportés (composants centraux)

Les composants centraux de Wazuh 4.14 sont compatibles avec les distributions Linux 64 bits suivantes : Red Hat Enterprise Linux 7, 8 et 9, CentOS 7 et 8, Amazon Linux 2, et Ubuntu 16.04, 18.04, 20.04 et 22.04. Rocky Linux 9, en tant que distribution compatible binaire avec RHEL 9, est pleinement supporté.

3.3 Préparation du système

Les étapes suivantes préparent Rocky Linux 9 à recevoir l’installation Wazuh. Elles couvrent la mise à jour du système, l’installation d’outils nécessaires, la configuration du service de synchronisation horaire et l’ouverture des ports dans le pare-feu. Un décalage horaire entre le serveur et les agents peut entraîner des erreurs de validation des certificats TLS et perturber la corrélation temporelle des alertes.

# -------------------------------------------------------------------
# PRÉPARATION DE ROCKY LINUX 9 (SERVEUR WAZUH)
# -------------------------------------------------------------------# 1. Mettre à jour le système
sudo dnf -y update
# 2. Installer les outils nécessaires
sudo dnf -y install curl tar unzip policycoreutils-python-utils firewalld
# 3. Configurer la synchronisation horaire (NTP via chrony)
sudo dnf -y install chrony
sudo systemctl enable --now chronyd
timedatectl status
# Vérifier que "NTP synchronized: yes" apparaît dans la sortie
# 4. Activer le pare-feu si ce n'est pas encore fait
sudo systemctl enable --now firewalld
# 5. Ouvrir les ports requis par Wazuh (all-in-one)
sudo firewall-cmd --permanent --add-port=1514/tcp
sudo firewall-cmd --permanent --add-port=1515/tcp
sudo firewall-cmd --permanent --add-port=55000/tcp
sudo firewall-cmd --permanent --add-port=9200/tcp
sudo firewall-cmd --permanent --add-service=https # port 443
sudo firewall-cmd --reload
# 6. Vérifier que les règles sont bien appliquées
sudo firewall-cmd --list-all
# 7. Contrôler l'état de SELinux
getenforce
# SELinux en mode "Enforcing" est supporté par Wazuh.
# En cas de blocage durant l'installation, diagnostiquer avec :
# sudo ausearch -m avc -ts recent

4. Installation Wazuh all-in-one sur Rocky Linux 9

L’installation utilise le script officiel wazuh-install.sh, fourni par Wazuh sous le nom « installation assistant ». Ce script automatise l’ensemble du processus : téléchargement et installation de l’indexer, du manager et du dashboard, génération des certificats TLS, création des mots de passe initiaux et démarrage des services. L’option -a indique un déploiement all-in-one.

# -------------------------------------------------------------------
# INSTALLATION WAZUH ALL-IN-ONE (ROCKY LINUX 9)
# -------------------------------------------------------------------# Télécharger le script d'installation (branche 4.14)
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
# Lancer l'installation all-in-one
# L'option -a installe indexer + manager + dashboard sur la machine locale
sudo bash ./wazuh-install.sh -a

L’exécution du script prend généralement entre 5 et 15 minutes selon les performances de la machine et la bande passante réseau. A l’issue de l’installation, le script affiche un résumé contenant :

L’URL d’accès au dashboard, au format https://<adresse_IP>, le nom d’utilisateur par défaut (admin), et le mot de passe généré aléatoirement. Nous devons noter soigneusement ce mot de passe dans un vault ou le récupérer depuis l’archive de sauvegarde comme décrit ci-dessous.

4.1 Récupérer les mots de passe générés

Le script d’installation crée une archive wazuh-install-files.tar dans le répertoire courant. Cette archive contient les certificats TLS et un fichier wazuh-passwords.txt listant les mots de passe de tous les comptes créés (indexer, API, dashboard).

# -------------------------------------------------------------------
# RÉCUPÉRER LES MOTS DE PASSE DEPUIS L'ARCHIVE
# -------------------------------------------------------------------# Afficher le contenu du fichier de mots de passe sans extraire l'archive
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

4.2 Vérifier l’état des services

Une fois l’installation terminée, on vérifira que les trois services sont actifs et que les ports sont en écoute :

# -------------------------------------------------------------------
# VÉRIFICATION DES SERVICES ET DES PORTS
# -------------------------------------------------------------------# État des services
sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard
# Vérifier l'écoute réseau sur les ports Wazuh
sudo ss -lntp | grep -E ':(1514|1515|55000|9200|443)\b'
# Tester l'API du manager (doit retourner un JSON avec le numéro de version)
curl -k -u admin:<MOT_DE_PASSE> https://:55000/?pretty

Si l’un des services ne démarre pas, consultez les journaux correspondants :

# Journaux du manager
sudo tail -100 /var/ossec/logs/ossec.log
# Journaux de l'indexer
sudo journalctl -u wazuh-indexer --no-pager -n 50
# Journaux du dashboard
sudo journalctl -u wazuh-dashboard --no-pager -n 50

4.3 Premier accès au dashboard

On ouvre un navigateur pour accéder à https://<adresse_IP_du_serveur>. Le navigateur affichera un avertissement de certificat, ce qui est normal avec un certificat auto-signé. L’écran d’accueil du dashboard présente une vue d’ensemble de l’état de la plateforme : nombre d’agents connectés, alertes récentes, et accès aux différents modules de sécurité.

5. Configuration post-installation (durcissement et exploitation)

5.1 Sécuriser l’enrôlement des agents

Par défaut, tout agent disposant de l’adresse IP du manager peut s’enregistrer librement. Dans un environnement de production, cette situation n’est pas acceptable : un attaquant ayant accès au réseau pourrait enregistrer un agent illégitime et polluer les données de supervision. Pour éviter cela, Wazuh permet d’imposer un mot de passe lors de l’enrôlement.

# -------------------------------------------------------------------
# ACTIVER L'AUTHENTIFICATION PAR MOT DE PASSE POUR L’ENRÔLEMENT
# -------------------------------------------------------------------# 1. Éditer la configuration du manager
sudo vi /var/ossec/etc/ossec.conf
# Rechercher la section <auth> et ajouter ou modifier :
# <auth>
# <use_password>yes</use_password>
# </auth>
# 2. Créer le fichier contenant le mot de passe d'enrollment
# Remplacez <MOT_DE_PASSE_ENROLLMENT> par une valeur forte
echo "<MOT_DE_PASSE_ENROLLMENT>" | sudo tee /var/ossec/etc/authd.pass > /dev/null
sudo chmod 640 /var/ossec/etc/authd.pass
sudo chown root:wazuh /var/ossec/etc/authd.pass
# 3. Redémarrer le manager pour appliquer le changement
sudo systemctl restart wazuh-manager
# 4. Vérifier que le service authd est actif
sudo /var/ossec/bin/wazuh-control status | grep authd

On conserve ce mot de passe d’enrôlement dans un gestionnaire de secrets. Il sera nécessaire à chaque enregistrement d’un nouvel agent.

5.2 Désactiver les mises à jour automatiques des paquets Wazuh

Une mise à jour non contrôlée du manager ou de l’indexer peut introduire des incompatibilités ou interrompre le service. Wazuh recommande de désactiver les dépôts Wazuh sur le serveur après l’installation, puis de procéder aux montées de version de manière planifiée, en suivant la documentation de migration officielle. Fun Fac, personnel, j’ai cassé l’instance wazuh du homelab, pour ma défense, l’équipe l’éditeur de wazuh n’avait pas mentionnée cette recommandation.😅

# -------------------------------------------------------------------
# VERROUILLER LA VERSION WAZUH SUR LE SERVEUR
# -------------------------------------------------------------------# Désactiver le dépôt Wazuh pour éviter les mises à jour via dnf update
sudo sed -i 's/^enabled=1/enabled=0/' /etc/yum.repos.d/wazuh.repo
# Vérifier que le dépôt est bien désactivé
sudo dnf repolist | grep wazuh
# la ligne ne doit plus apparaître, ou afficher "disabled"

5.3 Remplacer le certificat auto-signé (recommandé en production)

Le certificat auto-signé généré à l’installation permet de démarrer rapidement, mais il n’offre pas de garantie d’identité. Trois options possibles :

La première est d’utiliser un certificat Let’s Encrypt, si le dashboard est accessible depuis Internet et que nous disposons d’un nom de domaine. La deuxième consiste à déployer un certificat émis par la PKI interne (autorité de certification d’entreprise). La troisième option passe par l’utilisation d’un reverse proxy (NGINX, HAProxy) en frontal du dashboard, avec terminaison TLS au niveau du proxy. Cette approche est courante car elle permet de mutualiser la gestion des certificats et d’ajouter une couche de filtrage (WAF, authentification MFA).

La documentation Wazuh détaille la procédure de remplacement des certificats dans la section « Configuring SSL certificates« . Cette opération nécessite un redémarrage des services indexer et dashboard après le remplacement des fichiers PEM.

5.4 Créer des comptes nominatifs et appliquer le RBAC

Le compte admin créé par défaut possède tous les privilèges. En exploitation quotidienne, on devra créer des comptes nominatifs, avec des rôles adaptés (analyste SOC en lecture seule, administrateur avec droits de configuration, auditeur avec accès aux rapports de conformité). La gestion des rôles s’effectue depuis le menu Security du dashboard ou via l’API de l’indexer.

6. Déploiement des agents

Le déploiement d’un agent Wazuh suit un schéma identique quel que soit le système d’exploitation : installation du paquet, configuration de l’adresse du manager, enregistrement (enrollment), puis démarrage du service. Deux méthodes sont disponibles :

Via le dashboard : le menu « Agents management » puis « Deploy new agent » génère une commande prête à l’emploi, adaptée au système cible. Cette approche est pratique pour des déploiements unitaires.

Via des outils d’automatisation : Ansible, GPO, SCCM, Intune ou des scripts d’initialisation cloud (user-data) permettent de déployer l’agent sur un grand nombre de machines de manière reproductible.

Dans les exemples ci-dessous, les variables suivantes sont utilisées :

6.1 Agent sur Rocky Linux 9 (RPM / dnf)

L’installation de l’agent sur Rocky Linux 9 passe par le dépôt RPM officiel Wazuh. Les variables d’environnement passées lors de l’installation configurent automatiquement l’agent avec l’adresse du manager et les paramètres d’enrôlement.

# -------------------------------------------------------------------
# AGENT WAZUH - ROCKY LINUX 9 (DNF)
# -------------------------------------------------------------------# 1. Importer la clé GPG du dépôt Wazuh
sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
# 2. Créer le fichier de dépôt
# Note : "priority=1" est nécessaire pour RHEL 9 et dérivés
sudo tee /etc/yum.repos.d/wazuh.repo > /dev/null << 'EOF'
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
priority=1
EOF
# 3. Installer l'agent avec les variables de provisionnement
sudo WAZUH_MANAGER="<WAZUH_MANAGER_IP>" \
WAZUH_REGISTRATION_SERVER="<WAZUH_MANAGER_IP>" \
WAZUH_REGISTRATION_PASSWORD="<ENROLL_PASSWORD>" \
WAZUH_AGENT_GROUP="linux-servers" \
dnf -y install wazuh-agent
# 4. Activer et démarrer le service agent
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent
# 5. Vérifier le statut de l'agent
sudo systemctl status wazuh-agent
# 6. Consulter les journaux pour confirmer la connexion au manager
sudo tail -n 30 /var/ossec/logs/ossec.log
# Chercher une ligne contenant "Connected to the server"

Une fois le service démarré, l’agent tente de s’enregistrer auprès du manager sur le port 1515, puis bascule sur le port 1514 pour la transmission des événements. Si l’enregistrement échoue, on vérifie que le port 1515 est bien ouvert, que le mot de passe d’enrôlement est correct, et que le FQDN ou l’adresse IP du manager est joignable.

Après l’installation, on désactive le dépôt Wazuh sur l’agent pour éviter toute mise à jour accidentelle :

# -------------------------------------------------------------------
# VERROUILLER LA VERSION WAZUH SUR L'AGENT ROCKY LINUX
# -------------------------------------------------------------------
sudo sed -i 's/^enabled=1/enabled=0/' /etc/yum.repos.d/wazuh.repo

6.2 Agent sur Windows 11 et Windows Server 2022 (MSI)

L’agent Windows est distribué sous forme de paquet MSI, téléchargeable depuis la page Packages list de la documentation Wazuh. L’installation silencieuse via la ligne de commande accepte les mêmes variables de provisionnement que sur Linux, ce qui permet une intégration aisée avec les outils de déploiement en entreprise (GPO, SCCM, Microsoft Intune).

Avant de commencer, On télécharge le fichier MSI correspondant à la version de votre serveur Wazuh (ici 4.14.3). On ouvre ensuite une invite de commandes ou un terminal PowerShell avec des privilèges administrateur.

Installation via CMD (invite de commandes)

REM -------------------------------------------------------------------
REM AGENT WAZUH - WINDOWS (CMD Administrateur)
REM -------------------------------------------------------------------REM Exécuter depuis le dossier contenant le MSI téléchargé
wazuh-agent-4.14.3-1.msi /q ^
WAZUH_MANAGER="<WAZUH_MANAGER_IP>" ^
WAZUH_REGISTRATION_SERVER="<WAZUH_MANAGER_IP>" ^
WAZUH_REGISTRATION_PASSWORD="<ENROLL_PASSWORD>" ^
WAZUH_AGENT_NAME="%COMPUTERNAME%" ^
WAZUH_AGENT_GROUP="windows-workstations"
REM Démarrer le service
NET START WazuhSvc
REM Vérifier l'état du service
SC QUERY WazuhSvc

Installation via PowerShell

# -------------------------------------------------------------------
# AGENT WAZUH - WINDOWS (PowerShell Administrateur)
# -------------------------------------------------------------------# Se positionner dans le dossier contenant le MSI
.\wazuh-agent-4.14.3-1.msi /q `
WAZUH_MANAGER="<WAZUH_MANAGER_IP>" `
WAZUH_REGISTRATION_SERVER="<WAZUH_MANAGER_IP>" `
WAZUH_REGISTRATION_PASSWORD="<ENROLL_PASSWORD>" `
WAZUH_AGENT_NAME="$env:COMPUTERNAME" `
WAZUH_AGENT_GROUP="windows-workstations"
# Démarrer le service
Start-Service WazuhSvc
# Vérifier le statut
Get-Service WazuhSvc

Pour Windows Server 2022, la procédure est identique. On adapte simplement le groupe d’agents (par exemple windows-servers) pour distinguer les postes de travail des serveurs dans le dashboard.

Après l’installation, l’agent Windows est installé par défaut dans le répertoire C:\Program Files (x86)\ossec-agent\. Le fichier de configuration se trouve dans ossec.conf à la racine de ce répertoire, et les journaux dans le sous-dossier logs\ossec.log.

Pare-feu Windows

Si le pare-feu Windows est actif sur le poste client (ce qui est recommandé), on vérifie que les connexions sortantes vers le manager sur les ports 1514 et 1515 sont autorisées. En règle générale, le pare-feu Windows autorise les connexions sortantes par défaut, mais une GPO restrictive pourrait les bloquer.

# -------------------------------------------------------------------
# VÉRIFIER LA CONNECTIVITÉ DEPUIS WINDOWS (PowerShell)
# -------------------------------------------------------------------
Test-NetConnection -ComputerName <WAZUH_MANAGER_IP> -Port 1514
Test-NetConnection -ComputerName <WAZUH_MANAGER_IP> -Port 1515

6.3 Déploiement à grande échelle (GPO / Intune / Ansible)

Pour un parc de plusieurs dizaines ou centaines de machines, le déploiement manuel n’est pas envisageable. Plusieurs stratégies sont possibles :

GPO (Group Policy Object) : créez un script de démarrage (startup script) contenant la commande MSI d’installation silencieuse. Le MSI doit être placé sur un partage réseau accessible par les machines cibles. Cette méthode convient aux environnements Active Directory.

Microsoft Intune / SCCM : empaquetez le MSI comme application Win32 et déployez-le sur les groupes de machines ciblés. Les variables d’environnement peuvent être passées via la ligne de commande d’installation.

Ansible : Wazuh fournit des rôles Ansible officiels pour le déploiement des agents Linux et Windows. Les playbooks permettent de paramétrer l’adresse du manager, le mot de passe d’enrollment et le groupe d’agents de manière centralisée.

7. Validation fonctionnelle

Après le déploiement des agents, plusieurs vérifications permettent de confirmer le bon fonctionnement de la chaîne de collecte.

7.1 Vérification dans le dashboard

Connectez-vous au dashboard Wazuh et accédez au menu Agents management → Summary. Chaque agent correctement enregistré apparaît dans la liste avec le statut « Active ». Si un agent reste en statut « Disconnected » ou « Pending », reportez-vous à la section Dépannage ci-dessous.

7.2 Vérification via l’API

# -------------------------------------------------------------------
# LISTER LES AGENTS VIA L'API WAZUH
# -------------------------------------------------------------------
curl -k -u admin:<MOT_DE_PASSE> "https://127.0.0.1:55000/agents?pretty&sort=-dateAdd"

La réponse JSON contient la liste des agents avec leur identifiant, nom, adresse IP, système d’exploitation, version de l’agent, groupe et statut de connexion.

7.3 Test de connectivité depuis un agent Linux

# -------------------------------------------------------------------
# TEST DE CONNECTIVITÉ DEPUIS UN AGENT LINUX
# -------------------------------------------------------------------# Installer netcat si nécessaire :# Rocky Linux : sudo dnf -y install nmap-ncat
# Debian/Ubuntu : sudo apt-get -y install netcat-openbsd
nc -zv <WAZUH_MANAGER_IP> 1514
nc -zv <WAZUH_MANAGER_IP> 1515
nc -zv <WAZUH_MANAGER_IP> 55000

7.4 Générer un événement de test

Pour vérifier que la chaîne complète fonctionne (agent → manager → indexer → dashboard), on peut générer un événement de sécurité volontaire sur un agent Linux :

# -------------------------------------------------------------------
# GÉNÉRER UN ÉVÉNEMENT DE TEST (SUR L'AGENT LINUX)
# -------------------------------------------------------------------# Créer un fichier dans un répertoire surveillé par FIM
sudo touch /etc/test_wazuh_fim.txt
# Attendre quelques secondes, puis supprimer le fichier
sleep 10
sudo rm /etc/test_wazuh_fim.txt

Dans le dashboard, recherchez l’alerte correspondante dans le module « Security events » ou « File Integrity Monitoring ». On devrai voir une alerte signalant la création puis la suppression du fichier.

8. Bonnes pratiques d’exploitation

8.1 Gouvernance des alertes

Au démarrage, le volume d’alertes peut être important. On procède par étapes : on commence avec les modules de base (collecte de journaux, FIM sur un périmètre restreint), on classifie le bruit (alertes récurrentes sans valeur) et le signal (alertes exploitables), puis on active progressivement les modules supplémentaires (SCA, détection de vulnérabilités, Active Response). Les règles personnalisées et les listes d’exclusion (CDB lists) permettent d’affiner la détection au fil du temps.

8.2 Gestion des accès

Il faudra abandonner l’usage quotidien du compte admin au profit de comptes nominatifs associés à des rôles. et on ducumentra les droits de chaque rôle. Il sera possible de configure l’intégration dans un annuaire LDAP ou un fournisseur d’identité SAML pour centraliser l’authentification.

8.3 Réponse à incident

il sera préférable de définir des procédures de réponse (playbooks) avant de configurer l’Active Response. Chaque règle de réponse automatique doit être testée en environnement isolé. Attention au blocage IP déclenché par un faux positif. On privilégiera les actions réversibles (blocage temporaire plutôt que permanent).

8.4 Rétention et stockage

il faudra aussi surveiller la consommation d’espace disque de l’indexer, en particulier si la volumétrie d’alertes est élevée. Wazuh supporte les politiques de gestion du cycle de vie des index (ISM – Index State Management) pour archiver ou supprimer automatiquement les données anciennes.

8.5 Sauvegardes

On devra planifier des sauvegardes régulières de la configuration du manager (/var/ossec/etc/), des règles personnalisées (/var/ossec/etc/rules/ et /var/ossec/etc/decoders/), et des données de l’indexer. Dans le cas du homelab, le serveur est une VM dans proxmox à ce titre des bakcup régulier sont effectués.

9. Dépannage des problèmes courants

9.1 Agent en statut « Disconnected »

C’est le problème le plus fréquent après un déploiement d’agent. Les causes habituelles sont les suivantes :

Pare-feu : les ports 1514 et 1515 sont bloqués, que ce soit par le pare-feu du serveur (firewalld), par le pare-feu du poste client (iptables, Windows Defender Firewall), ou par un équipement réseau intermédiaire (ACL sur un switch ou un routeur).

Résolution DNS : Le FQDN pour WAZUH_MANAGER, on vérifie que l’agent peut le résoudre. Un nslookup ou dig depuis l’agent permet de confirmer la résolution.

Décalage horaire : un écart de temps important entre l’agent et le manager peut provoquer des erreurs de validation du certificat TLS. on check que chrony ou NTP est configuré sur tous les postes.

Mot de passe d’enrollment incorrect : si l’authentification par mot de passe est activée, toute erreur dans le mot de passe empêche l’enregistrement. Consultez les journaux du manager (/var/ossec/logs/ossec.log) pour identifier le message d’erreur.

9.2 Avertissement de certificat au premier accès

L’avertissement affiché par le navigateur lors de la première connexion au dashboard est normal avec un certificat auto-signé. En revanche, il faudre le remplacer par un certificat signé par une autorité de confiance (voir section 5.3).

9.3 Le dashboard ne se charge pas

Si le dashboard est inaccessible, on vérifie dans l’ordre : le statut du service (systemctl status wazuh-dashboard), l’écoute sur le port 443 (ss -lntp | grep :443), et les journaux du dashboard. Une cause fréquente est un manque de mémoire vive : si l’indexer consomme toute la RAM disponible, le dashboard peut ne pas démarrer.

9.4 Performances dégradées

Deux fichiers d’état permettent de diagnostiquer un problème de charge sur le manager :

# -------------------------------------------------------------------
# DIAGNOSTIC DE PERFORMANCE DU MANAGER
# -------------------------------------------------------------------# Vérifier si des événements sont perdus par le moteur d'analyse
cat /var/ossec/var/run/wazuh-analysisd.state | grep events_dropped
# Vérifier si des messages agents sont rejetés par le module réseau
cat /var/ossec/var/run/wazuh-remoted.state | grep discarded_count

Si events_dropped ou discarded_count augmentent, le serveur manque de ressources CPU ou RAM. Envisagez d’augmenter les ressources allouées ou de migrer vers une architecture distribuée.

10. Schéma récapitulatif du déploiement

Le diagramme ci-dessous résume les flux de communication entre les composants dans l’architecture all-in-one déployée dans ce guide :

C’était Zérosécu, et comme je dis toujours, la cybersécurité est moins cher que gratuit.

J’apporte la plus grande attention et le plus grand soin à chaque article, mais si toutefois, si vous repérez une erreur, faites-moi signe !

Note de les droits d’auteur (images): Les visuels intégrés peuvent provenir de la documentation officiels de Wazuh, et sont utilisés à des fins d’illustration et d’analyse conformément au droit de citation.

Sources et références: Wazuh Quickstart (installation all-in-one, prérequis matériels) | Architecture Wazuh et ports réseau requis | Guide d’installation du serveur Wazuh (prérequis, dimensionnement) | Guide d’installation de l’indexer Wazuh (dimensionnement stockage) | Déploiement des agents Linux (RPM, DEB) | Déploiement des agents Windows (MSI) | Enrollment : authentification par mot de passe (authd.pass) | Prérequis réseau pour l’enrôlement des agents | Variables de déploiement Linux | Variables de déploiement Windows | Module SCA (Security Configuration Assessment) Module de détection de vulnérabilités  | Notes de version Wazuh 4.14.0 (octobre 2025) |Liste des paquets Wazuh (toutes plateformes)