Wazuh

Mise à jour : 2026-10-19 | Relu intégralement : 2026-03-01

Wazuh est une plateforme de sécurité unifiée open source, qui combine trois fonctions souvent vendues séparément : SIEM (centralisation et historique des journaux), EDR (détection sur les postes et serveurs) et XDR (corrélation à l'échelle du système d'information).

Elle repose sur des agents installés sur les machines à surveiller, une plateforme centrale d'analyse, et un moteur de corrélation des événements. L'ensemble donne une vision consolidée de la sécurité, des postes aux serveurs.

1. Comprendre les concepts

Le vocabulaire de la cybersécurité

Avant Wazuh lui-même, quelques termes que l'on croise sans cesse.

EDR (Endpoint Detection and Response) : un outil installé sur les postes et serveurs. Il collecte les événements locaux (processus, authentifications, accès fichiers), détecte les comportements suspects, et peut déclencher une réponse (blocage, isolement).

SIEM (Security Information and Event Management) : il centralise les journaux de nombreuses sources (postes, serveurs, applications, équipements réseau), les corrèle, les conserve, et permet l'analyse et l'audit. Il apporte une vision centralisée avec historique.

XDR (Extended Detection and Response) : la vision "grand angle". Là où l'EDR regarde une machine, le XDR met en relation des événements venus de plusieurs systèmes. Son but est de relier des signaux qui, isolés, semblent anodins, mais qui ensemble révèlent une attaque (ex. connexion inhabituelle → exécution d'un programme → accès à des fichiers sensibles). Il s'appuie sur MITRE ATT&CK pour replacer chaque alerte dans un scénario d'attaque global.

CVE / CVSS :

• CVE (Common Vulnerabilities and Exposures) : l'identifiant unique d'une vulnérabilité connue. C'est sa carte d'identité : "quelle est la faille ?".
• CVSS (Common Vulnerability Scoring System) : un score de gravité de 0 à 10. C'est l'échelle de Richter du risque : "à quel point est-elle dangereuse ?". Il combine l'impact (triade Confidentialité / Intégrité / Disponibilité) et la difficulté d'exploitation.

MITRE ATT&CK : une base de connaissances mondiale qui décrit les méthodes des attaquants, en tactiques (leurs objectifs), techniques (leurs méthodes) et procédures (les TTP). Elle sert de grille de lecture commune pour analyser et contextualiser les alertes.

Ce que Wazuh fait concrètement

• EDR : via ses agents, il collecte les événements locaux, surveille l'intégrité des fichiers critiques (FIM), détecte les comportements anormaux, et identifie les vulnérabilités connues (CVE) présentes sur les systèmes.
• SIEM : il centralise et historise les journaux, les alertes et les résultats d'analyses, avec recherche et tableaux de bord.
• XDR / Threat Hunting : il met en relation les événements de plusieurs systèmes pour détecter des anomalies à l'échelle globale, avec MITRE ATT&CK comme grille de lecture.
• Vulnérabilités : il identifie les CVE selon les versions de l'OS et des logiciels installés. Il n'applique aucun correctif : il aide à décider lesquels prioriser.
• Conformité (SCA) : il analyse la configuration des systèmes face à des référentiels de bonnes pratiques (CIS...), pour un durcissement progressif.

Ce que Wazuh n'est pas

Même s'il en est techniquement capable, Wazuh n'est pas, dans un premier temps :

• un outil de blocage automatique systématique;
• une solution pilotée par l'IA sans interprétation humaine;
• un SOC externalisé clé en main.

Les mécanismes de réponse active (Active Response) existent mais ne sont pas activés par défaut : les mettre en œuvre demande une bonne connaissance de l'environnement et une validation rigoureuse, pour éviter les interruptions de service non maîtrisées. Wazuh est avant tout un outil d'aide à la décision, orienté analyse.

Les quatre composants techniques

Analogie : une chaîne de surveillance.

 Agents ──────► Manager ──────► Indexer ──────► Dashboard
(capteurs)     (cerveau)      (mémoire)       (écran de contrôle)
collectent     analyse,       indexe,         tableaux de bord,
les infos      génère les     stocke,         visualisation,
               alertes        historise       recherche

• Agents : installés sur les machines à surveiller, ils collectent logs et événements et les envoient au Manager.
• Manager : reçoit les événements, les analyse selon des règles, et génère des alertes.
• Indexer (basé sur OpenSearch) : indexe et stocke les données, permet les recherches rapides et gère la rétention.
• Dashboard : l'interface web, pour visualiser les alertes, interroger les données et piloter la sécurité.

2. Installer le serveur (single-node)

En single-node, les trois composants (Manager, Indexer, Dashboard) sont sur une seule machine. C'est l'installation adaptée à une infrastructure de taille modeste.

Wazuh fournit un assistant d'installation qui met tout en place :

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
less wazuh-install.sh         # auditer le script avant de l'exécuter
bash wazuh-install.sh -a

(remplacez 4.14 par la branche stable visée)

À la fin, l'assistant affiche l'URL du Dashboard (https://adresse-du-serveur) et le mot de passe du compte admin.

Vérifiez que les services tournent :

systemctl status wazuh-indexer wazuh-manager wazuh-dashboard

Remplacer le certificat TLS du Dashboard

Par défaut, le Dashboard présente un certificat auto-signé. Pour qu'il soit reconnu par les postes de l'entreprise, remplacez-le par un certificat signé par votre autorité de certification interne (PKI).

1) Placez le certificat et sa clé dans /etc/wazuh-dashboard/certs/. 2) Pointez le Dashboard dessus dans /etc/wazuh-dashboard/opensearch_dashboards.yml :

```yaml
server.ssl.enabled: true
server.ssl.key: "/etc/wazuh-dashboard/certs/mon-certificat-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/mon-certificat.pem"
```

3) Restreignez les permissions, puis redémarrez :

```sh
chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs
chmod 500 /etc/wazuh-dashboard/certs
chmod 400 /etc/wazuh-dashboard/certs/*
systemctl restart wazuh-dashboard
```

Le fichier de configuration du Manager

Le fichier principal du Manager est /var/ossec/etc/ossec.conf. Il contrôle les modules actifs (vulnérabilités, SCA, règles, réponses actives...) et les interactions avec les agents.

cd /var/ossec/etc/
cp ossec.conf ossec.conf.bck_$(date +%Y%m%d_%H%M)
nano ossec.conf

systemctl restart wazuh-manager
systemctl status wazuh-manager
tail -n 50 /var/ossec/logs/ossec.log

3. Déployer les agents

L'agent est un capteur installé sur chaque machine à surveiller. Il envoie les événements locaux au Manager.

Les groupes : la bonne pratique de départ

Avant de déployer, créez des groupes (Agents management > Groups), qui permettent d'appliquer une configuration homogène par type de machine. Une organisation courante :

Linux_clients     Linux_servers
Windows_clients   Windows_servers

Bonnes pratiques : toujours rattacher un agent à un groupe, ne jamais modifier la configuration locale d'un agent après enrôlement (tout se centralise par les groupes), et piloter vulnérabilités, conformité et règles via ces groupes.

Agent Linux

# 1. Ajouter le dépôt Wazuh
apt install -y curl gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee /etc/apt/sources.list.d/wazuh.list
apt update

# 2. Installer en déclarant le Manager et le groupe via des variables
WAZUH_MANAGER="wazuh.domaine.fr" WAZUH_AGENT_GROUP="Linux_clients" apt install -y wazuh-agent

# 3. Démarrer
systemctl enable --now wazuh-agent
systemctl status wazuh-agent

Les variables WAZUH_MANAGER et WAZUH_AGENT_GROUP évitent d'éditer le fichier ossec.conf de l'agent : elles y inscrivent directement l'adresse du Manager et le groupe.

Agent Windows (déploiement par GPO)

En environnement Active Directory, on déploie l'agent automatiquement par GPO, à partir du fichier MSI de l'agent et d'un transform MST qui définit les paramètres (WAZUH_MANAGER, WAZUH_AGENT_GROUP). Le MST se crée avec l'outil Orca de Microsoft. La GPO est appliquée à l'OU contenant les postes, et restreinte à un groupe de sécurité dédié qui a les droits de lecture sur le partage où sont stockés le MSI et le MST.

Pour mettre à jour, on ajoute le nouveau MSI dans la GPO en le configurant comme mise à niveau de l'ancien package : les postes sont mis à jour au prochain cycle de GPO.

Vérifier un agent

# Côté agent Linux
tail -f /var/ossec/logs/ossec.log
# Côté agent Windows (PowerShell)
Get-Service Wazuh

Côté Manager, l'agent doit apparaître dans Agents management > Summary, avec un identifiant, l'état Active, son groupe et son OS détecté.

Mettre à jour un agent, sous contrôle

Pour éviter qu'un apt upgrade ne mette à jour un agent avant le Manager (ce qui casserait la compatibilité), on gèle le paquet :

echo "wazuh-agent hold" | dpkg --set-selections   # geler
dpkg --get-selections | grep wazuh-agent          # vérifier (doit afficher "hold")

Une fois le Manager à jour et validé, on met à jour l'agent :

echo "wazuh-agent install" | dpkg --set-selections   # dégeler
apt update && apt install wazuh-agent
echo "wazuh-agent hold" | dpkg --set-selections      # regeler

4. Mettre à jour le serveur

# 1. Système
apt update && apt full-upgrade    # (reboot si le noyau est mis à jour)

# 2. Composants Wazuh
apt update
apt install wazuh-manager wazuh-indexer wazuh-dashboard

# 3. Redémarrer dans l'ordre
systemctl restart wazuh-indexer
systemctl restart wazuh-manager
systemctl restart wazuh-dashboard

# 4. Vérifier
systemctl status wazuh-indexer wazuh-manager wazuh-dashboard

Récapitulatif de l'ordre : sauvegarde VM → système Debian → composants Wazuh (Indexer, Manager, Dashboard) → vérifications → puis agents.

5. Piloter la sécurité : la routine

La valeur de Wazuh ne vient pas de l'outil, mais de son exploitation régulière. Voici une routine de pilotage hebdomadaire (voire quotidienne), pensée pour une équipe sans SOC dédié : une vision synthétique du risque, sans investigation lourde.

1) Santé de la plateforme (Dashboard > Overview) : combien d'agents actifs vs inactifs ? Un agent critique (serveur exposé) est-il hors ligne ? Les volumes d'événements sont-ils stables ?

2) Vulnérabilités (Vulnerability Detection) : de nouvelles CVE "Critical" ? Quels systèmes sont les plus exposés ? Décision : simple suivi, demande de mise à jour, ou action prioritaire si exposition sensible.

3) Conformité (SCA) : elle se lit par agent. On ne vérifie pas tout le parc à chaque fois, mais quelques machines clés (serveurs exposés, un ou deux postes représentatifs). Le score est-il stable ? Les écarts sont-ils compris et justifiés ?

4) Threat Hunting (Threat Hunting) : pas de pic d'alertes inhabituel ? Pas d'augmentation anormale des échecs d'authentification ? Aucune nouvelle alerte de niveau 12 ou plus ? But : repérer une anomalie grossière ou un signal faible.

5) Synthèse : formaliser rapidement soit "aucun point bloquant", soit une courte liste d'actions (vérifier un serveur, planifier une mise à jour, analyser un écart SCA).

6. Les niveaux de criticité

Chaque alerte est associée à une règle qui porte un niveau (rule.level) de 0 à 15 :

Dans les routines, concentrez-vous en priorité sur les niveaux 7 et plus. À noter : tous les journaux collectés ne deviennent pas des alertes. Un journal qui ne correspond à aucune règle est simplement archivé, sans rule.level.

7. Interpréter une CVE

Une CVE à score élevé ne signifie pas qu'une attaque est en cours, mais qu'un risque potentiel existe. Voici une méthode pragmatique.

Lire le CVSS avec recul. Le score évalue la gravité théorique, mais il ne connaît pas votre environnement : il ne sait pas si le service est exposé ou utilisé. C'est un indicateur de priorité, pas une décision automatique.

Se poser les bonnes questions :

• le système est-il exposé (en écoute sur Internet) ?
• le service vulnérable est-il actif et utilisé ?
• le système est-il critique ?
• la vulnérabilité est-elle activement exploitée (catalogue CISA KEV) ?
• un exploit public existe-t-il (Exploit-DB, PoC sur GitHub) ?
• observe-t-on une activité suspecte associée dans le Threat Hunting ?

8. Centraliser des sources externes via syslog

Certains équipements (pare-feu, IDS) ne peuvent pas recevoir d'agent Wazuh. On les intègre alors via syslog, le protocole standard d'envoi de journaux vers un serveur central ("puits de logs").

Côté Wazuh : écouter le syslog

Dans /var/ossec/etc/ossec.conf, un bloc <remote> fait écouter le Manager sur le port 514, en n'acceptant que les sources autorisées :

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.0.2.0/24</allowed-ips>
  <allowed-ips>198.51.100.10</allowed-ips>
</remote>

allowed-ips n'accepte qu'une IP ou plage CIDR par ligne : déclarez chaque source sur sa propre ligne. C'est essentiel pour éviter qu'un tiers n'injecte de faux journaux.

Côté source avec rsyslog (fichier local)

Pour une source qui écrit dans un fichier (CrowdSec, par exemple), rsyslog lit ce fichier et le transmet. Dans /etc/rsyslog.d/ma-source.conf :

module(load="imfile")

input(type="imfile"
      File="/var/log/ma-source.log"
      Tag="ma-source")

*.* @wazuh.domaine.fr:514

systemctl restart rsyslog

Diagnostiquer la réception

# Les paquets arrivent-ils sur le port 514 ?
tcpdump -i any port 514

Pour voir les journaux bruts reçus, activez temporairement l'archivage dans ossec.conf (<logall>yes</logall>), redémarrez le Manager, puis consultez /var/ossec/logs/archives/archives.log. Les alertes générées, elles, sont dans /var/ossec/logs/alerts/alerts.log.

Comment Wazuh traite un journal

Réception (bloc <remote>) → Pre-decoding (auto) → Decoding → Rule matching → Alerte

• Decoding : extrait les champs structurés (IP, utilisateur...) via les décodeurs de /var/ossec/ruleset/decoders/ (par défaut) et /var/ossec/etc/decoders/local_decoder.xml (personnalisés).
• Rule matching : compare le journal décodé aux règles de /var/ossec/ruleset/rules/ (par défaut) et /var/ossec/etc/rules/local_rules.xml (personnalisées). C'est l'étape qui déclenche les alertes.

Créer une règle personnalisée

Les règles locales, dans /var/ossec/etc/rules/local_rules.xml, transforment un journal en alerte. Le principe le plus simple : une correspondance textuelle (<match>) sur le journal brut.

<group name="local,">
  <rule id="100100" level="10">
    <match>ban on Ip</match>
    <description>CrowdSec ban detecte</description>
    <group>crowdsec,</group>
  </rule>
</group>

• match : correspondance textuelle, volontairement simple et robuste.
• level : la criticité (10 = événement significatif sans être critique).
• group : pour filtrer facilement dans les tableaux de bord (ex. rule.groups: crowdsec).

9. Configuration par groupe d'agents

Plutôt qu'une configuration unique pour tout le parc, on adapte le comportement des agents par groupe. Chaque groupe a son répertoire dans /var/ossec/etc/shared/, dont le nom doit correspondre exactement au nom du groupe, et un fichier agent.conf que les agents récupèrent automatiquement.

Exemple pour activer et régler l'analyse de conformité (SCA) sur un groupe Windows, dans /var/ossec/etc/shared/Windows_clients/agent.conf :

<agent_config>
  <sca>
    <enabled>yes</enabled>
    <scan_on_start>yes</scan_on_start>
    <interval>12h</interval>
    <policies>
      <policy>cis_win11_enterprise.yml</policy>
    </policies>
  </sca>
</agent_config>

10. Diagnostic

# État des services
systemctl status wazuh-manager wazuh-indexer wazuh-dashboard
systemctl list-units --type=service | grep wazuh

# Journaux de démarrage (systemd)
journalctl -u wazuh-manager -xe
journalctl -u wazuh-indexer -xe

# Journaux applicatifs
tail -n 50 /var/ossec/logs/ossec.log

# Permissions (propriétaire attendu : wazuh:wazuh)
ls -ld /var/ossec /var/ossec/etc /var/ossec/logs
chown -R wazuh:wazuh /var/ossec   # corriger si besoin

# Espace disque (surveiller / et /var en priorité)
df -h

# Santé de l'Indexer (OpenSearch)
curl -k -u admin https://localhost:9200

Un agent passe en "Disconnected"

Un agent passe Disconnected quand le Manager ne reçoit plus son signal "keep-alive" pendant 15 minutes (valeur agents_disconnection_time dans ossec.conf).

Causes possibles : machine éteinte ou en veille (le cas le plus courant pour un poste), perte de réseau, service agent arrêté, pare-feu bloquant les ports 1514/1515, problème DNS de résolution du Manager, ou agent désinstallé.

Interprétation rapide : un poste utilisateur hors ligne est souvent normal ; un serveur critique hors ligne doit être vérifié immédiatement.

Liens utiles

• Documentation officielle Wazuh
• CERT-FR (ANSSI) : veille et alertes en français
• NVD (NIST) : base officielle des CVE
• CVE.org : le programme CVE
• CISA KEV : vulnérabilités activement exploitées
• Exploit-DB : exploits et PoC publics
• MITRE ATT&CK : techniques d'attaque