Exploiter Wazuh au quotidien
agents, règles et lecture automatisée

Les trois briques, et ce que chacune fait

Wazuh n'est pas un logiciel unique mais un empilement de trois services, souvent confondus :

Brique	Rôle réel
Manager	Reçoit les événements des agents (port 1514), applique les règles de détection, déclenche les réponses actives
Indexer	Stocke et indexe alertes et états, c'est lui qui mange le disque
Dashboard	Interface web ; il interroge l'indexer et l'API du manager

Un piège classique : le tableau de bord répond, donc on croit que « Wazuh fonctionne ». Or il s'affiche même quand le manager est arrêté, il montre simplement un parc vide. Le seule contrôle qui compte est côté manager : wazuh-control status, avec wazuh-remoted et wazuh-analysisd en running.

Enrôler un agent, concrètement

Sur le manager, on déclare la machine et on récupère une clé :

/var/ossec/bin/manage_agents -a           # nom + IP (ou "any")
/var/ossec/bin/manage_agents -e <id>     # extrait la clé

Sur la machine surveillée, on importe cette clé puis on démarre le service. À partir de là, l'agent ouvre une connexion sortante vers le manager, jamais l'inverse. C'est ce qui rend le déploiement simple : aucune règle entrante à ouvrir sur les machines surveillées, et un agent qui se trouve derrière un NAT fonctionne sans configuration réseau.

Ce détail a une conséquence qu'on oublie : si le flux sortant est filtré, l'agent tourne, affiche active, et ne livre rien. C'est exactement la panne qu'on a eue, le pare-feu du serveur autorisait le web mais pas le port 1514.

Ce que l'agent remonte réellement

Un agent n'est pas un simple collecteur de journaux. Il exécute cinq modules, réglables séparément :

• logcollector lecture de fichiers de journaux et de journald, avec un décodeur par format
• syscheck intégrité des fichiers : empreintes, permissions, propriétaire, alertes sur modification
• rootcheck recherche de rootkits, ports cachés, permissions anormales
• syscollector inventaire : paquets installés, ports, processus, matériel, c'est la base de la détection de vulnérabilités
• SCA évaluation de durcissement contre un référentiel CIS, avec un score et la liste des contrôles en échec

La valeur ne vient pas du volume collecté mais de ce qu'on décide de surveiller. Un syscheck qui scanne tout le disque produit du bruit ; un syscheck limité à /etc/ssh, /etc/nginx, /etc/systemd/system et aux répertoires web produit des alertes qu'on lit.

La configuration, héritée d'OSSEC

Wazuh est un descendant direct d'OSSEC : le fichier s'appelle toujours ossec.conf, les binaires aussi (wazuh-agentd, wazuh-syscheckd…), et la syntaxe XML est identique. Ce qui a changé, c'est l'exploitation à l'échelle : là où OSSEC se configurait machine par machine, Wazuh permet une configuration centralisée par groupes.

<!-- agent : ce qui se règle localement -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/nginx/access.log</location>
</localfile>

<syscheck>
  <directories check_all="yes">/etc/ssh</directories>
  <directories check_all="yes">/etc/nginx</directories>
</syscheck>

Deux règles d'usage : ce qui est propre à une machine (chemins de journaux, disques) reste dans l'ossec.conf local ; ce qui doit être identique partout (politiques SCA, répertoires surveillés, règles actives) se pousse par groupe depuis le manager. Sans cette discipline, on finit avec vingt-deux configurations divergentes qu'on n'ose plus toucher.

Et un piège qui coûte une heure : une valeur invalide dans log_format empêche l'agent de démarrer, avec une erreur explicite dans ossec.log mais un systemctl status qui parle seulement de « processus de contrôle terminé ». nginx n'est pas une valeur acceptée, il faut syslog, le décodeur nginx s'appliquant de lui-même à la lecture.

Brancher un agent IA sur le SIEM

C'est l'étape suivante, et elle change l'usage : un SIEM produit plus d'alertes qu'un humain ne peut en lire. On ne cherche pas à automatiser la décision, mais la qualification.

Le montage tient en trois pièces :

Pièce	Détail
Accès	Un compte API Wazuh en lecture seule (readonly) et, si besoin, un utilisateur indexer limité à la lecture des index d'alertes. Jamais le compte administrateur dans un script.
Collecte	Un script Python qui interroge /alerts, /agents, /sca et l'indexer, agrège par machine et par règle, et sort un JSON compact.
Analyse	Un agent (Hermes, en local) reçoit ce JSON, écarte le bruit connu, croise avec l'inventaire des ports exposés, et rédige un rapport en français : ce qui a changé, ce qui est grave, ce qui attend une décision.

Ce qu'on lui demande, concrètement : repérer un agent muet depuis 24 heures, signaler une nouvelle machine qui commence à remonter, trier les alertes de niveau ≥ 10 par exposition réelle, et proposer les remédiations dans l'ordre. Ce qu'on ne lui demande pas : bannir une IP ou modifier une règle. Un modèle qui lit et rédige, un humain qui décide.

Le rythme visé est quotidien : un résumé le matin sur téléphone, et une alerte immédiate seulement au-delà d'un seuil qu'on définit nous-mêmes.

Ce qu'on retient

Un SIEM utile n'est pas celui qui collecte le plus, c'est celui dont on lit la sortie. Trois contrôles valent mieux que dix tableaux de bord : les agents remontent-ils, les règles se déclenchent-elles sur nos journaux, et quelqu'un regarde-t-il.

Et la question à se poser avant d'ajouter de la détection : est-ce que je saurais dire, aujourd'hui, depuis combien de temps ma machine la plus critique n'a pas parlé ?

Sources

• Wazuh, enrôlement des agents : manage_agents, clés et connexion sortante.
• Wazuh, référence ossec.conf : localfile, syscheck, active-response.
• Wazuh. Security Configuration Assessment : politiques CIS et lecture du score.
• Wazuh, référence de l'API REST : endpoints, authentification et permissions.

Installation de référence : Wazuh 4.13.1, vingt-deux agents, octobre 2026. Aucune machine, adresse ou identifiant interne n'est cité.