Comment auditer votre SIEM Wazuh contre les vulnerabilites critiques en 6 etapes

— Pourquoi auditer votre SIEM est devenu une urgence

Wazuh est devenu le SIEM open source de reference pour les entreprises francaises. Deploye dans la sante, la finance, l industrie et les administrations, il surveille des milliers d endpoints et centralise les alertes de securite. Mais qui surveille le surveillant ?

Les vulnerabilites recentes, notamment CVE-2026-30893 (CVSS 9.9), ont rappele brutalement que le SIEM lui-meme est un composant d infrastructure critique qui necessite un audit regulier. Un Wazuh non patche en mode cluster peut etre compromis pour obtenir un acces root sur tous les noeuds, desactiver les alertes et pivoter vers l ensemble de l infrastructure.

Ce guide vous donne les 6 etapes concretes pour auditer votre deployment Wazuh, de la verification de version au hardening avance. Chaque etape inclut les commandes a executer, les fichiers a verifier et les criteres a evaluer. Que vous soyez RSSI, administrateur systeme ou prestataire en charge d un cluster Wazuh, ce guide est votre checklist de reference.

— Etape 1 : Inventaire de version et cartographie des noeuds

La premiere etape de tout audit Wazuh est de dresser un inventaire complet de votre deployment. Sans cette cartographie, vous ne pouvez pas evaluer votre exposition aux vulnerabilites connues.

Commandes a executer sur chaque noeud :

# Version Wazuh
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION

# Type de noeud (master ou worker)
/var/ossec/bin/wazuh-control info | grep WAZUH_CLUSTER_NODE_TYPE

# Nom du noeud
/var/ossec/bin/wazuh-control info | grep WAZUH_CLUSTER_NODE_NAME

# Etat du cluster
/var/ossec/bin/cluster_control -l

# Nombre d agents connectes
/var/ossec/bin/agent_control -l | wc -l

# OS et version kernel du serveur
cat /etc/os-release && uname -r

Ce que vous devez documenter : pour chaque noeud, consignez la version Wazuh, le type (master/worker), le nombre d agents rattaches, l OS hote et la date de derniere mise a jour. Ce document constitue la base de votre audit et sera requis pour le reporting NIS2.

Critere de conformite : toutes les versions doivent etre identiques au sein du cluster et correspondre a la derniere version stable (4.14.4 minimum au 18 mai 2026). Si des versions differentes coexistent, c est un red flag : le cluster est dans un etat de mise a jour incohérent, ce qui peut provoquer des dysfonctionnements de synchronisation et masquer des compromissions.

Pour automatiser cette verification sur un parc de plusieurs noeuds, utilisez Ansible ou un outil similaire. Creez un playbook qui collecte ces informations et genere un rapport consolide. Si vous gerez plusieurs clusters pour differents clients ou filiales, cette automatisation est indispensable.

— Etape 2 : Audit de la configuration cluster et reseau

Le mode cluster de Wazuh est la source des vulnerabilites les plus critiques recentes. Cette etape verifie que votre configuration cluster est securisee et que les communications inter-noeuds sont protegees.

Fichier principal a examiner : /var/ossec/etc/ossec.conf, section <cluster>.

# Extraire la configuration cluster
grep -A 20 "<cluster>" /var/ossec/etc/ossec.conf

# Verifier le statut du cluster
/var/ossec/bin/cluster_control -i

# Lister les noeuds actifs
/var/ossec/bin/cluster_control -l

# Verifier la cle cluster (authd.pass)
ls -la /var/ossec/etc/authd.pass
stat /var/ossec/etc/authd.pass

# Scanner les ports cluster exposes
ss -tlnp | grep 1516
nmap -p 1516 <adresse_noeud>

Points de verification critiques :

• Port 1516 : doit etre accessible UNIQUEMENT depuis les noeuds du cluster. Verifiez avec iptables -L -n | grep 1516 ou la configuration firewall equivalente. Aucun autre segment reseau ne doit y acceder.
• Cle cluster (authd.pass) : doit etre unique par cluster, complexe (minimum 32 caracteres), et ses permissions doivent etre restreintes (chmod 400, proprietaire root:wazuh). Si la cle est identique a celle d un autre cluster ou est une valeur par defaut, c est critique.
• Chiffrement TLS : verifiez que les communications cluster utilisent TLS. La section <cluster> doit contenir <hidden>no</hidden> et les certificats doivent etre valides et non expires.
• Noeuds declares : la liste des noeuds dans la configuration doit correspondre exactement aux noeuds actifs. Tout noeud non reconnu est un indicateur potentiel de compromission.

La securisation du port 1516 est la mesure de mitigation la plus efficace contre les vulnerabilites de type path traversal dans le cluster. Meme si vous etes a jour, cette segmentation reseau est une defense en profondeur indispensable. Consultez notre guide de mise en place SIEM pour les bonnes pratiques d architecture reseau.

— Etape 3 : Scan des CVE connues affectant votre version

Maintenant que vous connaissez votre version, croisez-la avec la base de vulnerabilites connues. Wazuh a publie plusieurs CVE critiques au cours des 12 derniers mois.

CVE recentes a verifier en priorite (mai 2026) :

Processus de verification :

# Recuperer la version actuelle
VERSION=$(/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION | cut -d'"' -f2)
echo "Version Wazuh : $VERSION"

# Verifier si la version est dans la plage vulnerable pour CVE-2026-30893
# Versions affectees : 4.4.0 a 4.14.3
python3 -c "
from packaging import version
v = version.parse('$VERSION')
if version.parse('4.4.0') <= v <= version.parse('4.14.3'):
    print('VULNERABLE a CVE-2026-30893')
else:
    print('Non vulnerable a CVE-2026-30893')
"

# Consulter le changelog officiel
curl -s https://raw.githubusercontent.com/wazuh/wazuh/master/CHANGELOG.md | head -100

Au-dela des CVE Wazuh, verifiez egalement les vulnerabilites des composants associes : Elasticsearch ou OpenSearch (stockage), Kibana ou OpenSearch Dashboards (interface), et les agents Wazuh deployes sur les endpoints. Un SIEM est aussi securise que son maillon le plus faible. Consultez les bulletins CERT-FR pour les alertes actualisees.

— Etape 4 : Controle des acces, des cles et des utilisateurs API

Le controle des acces est le pilier de la securite de votre SIEM. Un Wazuh avec des cles par defaut, des comptes API non revoques ou des permissions trop larges est une bombe a retardement.

# Verifier les utilisateurs API Wazuh
curl -k -u admin:admin https://localhost:55000/security/users?pretty
# Si la connexion reussit avec admin:admin, le mot de passe par defaut
# n a PAS ete change — CRITIQUE

# Lister les roles et permissions API
curl -k -u <user>:<pass> https://localhost:55000/security/roles?pretty

# Verifier les permissions du fichier de cle cluster
ls -la /var/ossec/etc/authd.pass
# Doit afficher : -r-------- root wazuh

# Verifier les cles d agents
ls -la /var/ossec/etc/client.keys
wc -l /var/ossec/etc/client.keys

# Verifier les permissions des fichiers sensibles
find /var/ossec/etc/ -perm -o+r -type f 2>/dev/null
# Aucun fichier ne devrait etre lisible par "others"

# Verifier les processus Wazuh et leurs utilisateurs
ps aux | grep wazuh | grep -v grep

Checklist des acces a verifier :

• Mot de passe API par defaut : le compte admin doit avoir un mot de passe unique et complexe. Les comptes d API non utilises doivent etre desactives.
• Acces SSH aux noeuds : verifiez qui a un acces SSH aux serveurs Wazuh. L acces doit etre restreint aux administrateurs autorises, avec authentification par cle SSH et 2FA si possible.
• Acces au dashboard : l interface web (Kibana/OpenSearch Dashboards) doit etre accessible uniquement via VPN ou reseau interne. Les comptes par defaut doivent etre supprimes.
• Cle cluster : doit etre differente de la valeur par defaut, unique par environnement (production, staging, dev), et renouvelee annuellement au minimum.
• Certificats TLS : verifiez les dates d expiration des certificats utilises pour les communications cluster, API et dashboard.

Un audit des acces revele frequemment des comptes de service oublies, des cles partagees entre environnements et des permissions excessives. Chaque anomalie identifiee doit etre corrigee immediatement et documentee dans le rapport d audit.

— Etape 5 : Analyse des logs de synchronisation et detection d anomalies

Cette etape est cruciale car elle peut reveler une compromission active ou passee. Les logs du cluster Wazuh contiennent des traces de toute operation de synchronisation, y compris les tentatives d exploitation de vulnerabilites comme CVE-2026-30893.

# Examiner les logs du cluster pour des anomalies
tail -1000 /var/ossec/logs/cluster.log | grep -i "error\|warning\|fail"

# Rechercher des operations de synchronisation suspectes
grep -i "decompress\|extract\|sync" /var/ossec/logs/cluster.log | tail -50

# Verifier les fichiers recemment modifies hors du repertoire Wazuh
find /etc/cron.d/ -newer /var/ossec/etc/ossec.conf -type f

# Rechercher des fichiers suspects crees par le processus Wazuh
find / -user wazuh -not -path "/var/ossec/*" -type f 2>/dev/null

# Verifier les connexions reseau actives des processus Wazuh
ss -tlnp | grep wazuh
ss -tnp | grep ":1516"

# Auditer les connexions sortantes suspectes
ss -tnp | grep wazuh | grep -v "127.0.0.1\|::1"

# Verifier l integrite des binaires Wazuh
md5sum /var/ossec/bin/wazuh-* 2>/dev/null | head -20

Signaux d alerte a rechercher :

• Erreurs de decompression inhabituelles : des erreurs repetees dans cluster.log liees a decompress_files peuvent indiquer des tentatives d exploitation de CVE-2026-30893.
• Fichiers hors perimetre : tout fichier cree par l utilisateur wazuh ou le processus Wazuh en dehors de /var/ossec/ est suspect.
• Taches cron non autorisees : verifiez /etc/cron.d/, /var/spool/cron/ et /etc/crontab pour des taches que vous n avez pas creees.
• Connexions sortantes inhabituelles : les noeuds Wazuh ne devraient communiquer qu entre eux (port 1516), avec les agents (port 1514/1515) et avec le stockage (Elasticsearch/OpenSearch). Toute autre connexion sortante merite investigation.
• Modifications de regles ou decoders : verifiez /var/ossec/etc/rules/ et /var/ossec/etc/decoders/ pour des modifications recentes non planifiees. Un attaquant peut desactiver des regles de detection pour operer sans alerte.

Si vous identifiez des indicateurs de compromission, ne redemarrez pas les services Wazuh avant d avoir fait une copie forensique des logs, de la configuration et des fichiers suspects. Documentez chaque anomalie avec horodatage et contexte. Pour une methodologie forensique complete, consultez notre guide d analyse malware.

— Etape 6 : Hardening et durcissement de la configuration

La derniere etape transforme votre audit en actions concretes de durcissement. L objectif est de reduire la surface d attaque de votre deployment Wazuh et de le rendre resilient aux futures vulnerabilites.

Actions de hardening prioritaires :

1. Segmentation reseau stricte. Le port 1516 (communication cluster) doit etre filtre par un firewall. Seuls les noeuds declares dans la configuration cluster doivent pouvoir communiquer sur ce port. Implementez des regles iptables ou des security groups specifiques :

# Exemple de regles iptables pour le port cluster
# Autoriser uniquement les noeuds du cluster
iptables -A INPUT -p tcp --dport 1516 -s <IP_MASTER> -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -s <IP_WORKER_1> -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -s <IP_WORKER_2> -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -j DROP

# Restreindre egalement le port API (55000)
iptables -A INPUT -p tcp --dport 55000 -s <IP_ADMIN> -j ACCEPT
iptables -A INPUT -p tcp --dport 55000 -j DROP

2. Rotation des cles et certificats. Changez la cle cluster (authd.pass), regenerez les certificats TLS et mettez a jour les mots de passe API. Documentez la procedure et planifiez une rotation annuelle.

3. Monitoring du monitoring. Configurez une surveillance externe de votre Wazuh : monitoring de la disponibilite des services, alertes sur les modifications de fichiers de configuration, et centralisation des logs Wazuh dans un second systeme independant (syslog distant ou SIEM secondaire). Si votre SIEM primaire est compromis, vous avez besoin d une source de verite alternative.

4. Mises a jour automatisees. Configurez un processus de mise a jour regulier pour Wazuh et ses composants. Utilisez un pipeline CI/CD avec tests automatises en staging avant deploiement en production. L objectif est de reduire le delai entre la publication d un patch et son application en production a moins de 72 heures pour les CVE critiques.

5. Sauvegarde et plan de restauration. Sauvegardez regulierement la configuration Wazuh (/var/ossec/etc/), les regles personnalisees (/var/ossec/etc/rules/local_rules.xml), les decoders (/var/ossec/etc/decoders/) et la base d agents. Testez la restauration au moins une fois par trimestre. En cas de compromission, vous devez pouvoir reconstruire un cluster propre rapidement.

— Apres l audit : mettre en place un suivi continu

Un audit ponctuel est necessaire mais insuffisant. La securite de votre SIEM Wazuh requiert un suivi continu. Voici les actions a planifier apres votre premier audit :

Frequence d audit recommandee : audit complet (les 6 etapes) tous les trimestres. Scan de vulnerabilites et verification de version mensuels. Audit cible immediat a chaque publication de CVE critique affectant Wazuh. Ces frequences sont alignees avec les exigences NIS2 pour les entites essentielles et importantes.

Automatisation : creez des scripts Ansible ou des playbooks qui automatisent les etapes 1 (inventaire), 3 (scan CVE) et 5 (analyse des logs). L automatisation reduit le temps d audit de 8 heures manuelles a 30 minutes pour les verifications de routine.

Documentation NIS2 : chaque audit doit produire un rapport date et signe, conserve pendant 3 ans. Le rapport doit inclure la liste des noeuds audites, les versions deployees, les vulnerabilites identifiees, les actions de remediation entreprises et les delais de correction. Ce document est votre preuve de diligence en cas de controle ANSSI ou d incident.

Veille continue : abonnez-vous aux advisories de securite Wazuh (GitHub Security Advisories), aux bulletins CERT-FR et aux newsletters de securite SIEM. La reactivite face aux nouvelles CVE est votre meilleure defense. Notre comparatif SIEM vous aide a evaluer si votre configuration actuelle est optimale.

— FAQ