Wazuh SIEM/XDR Open Source : Déploiement, Configuration

Dans un paysage où les solutions SIEM commerciales atteignent des coûts de licence prohibitifs -- souvent facturés au volume d'événements ingérés --, Wazuh s'est imposé comme l'alternative open source la plus mature et la plus complète. Né en 2015 comme un fork d'OSSEC, Wazuh a évolué pour devenir une plateforme XDR (Extended Detection and Response) unifiée, capable de rivaliser avec des solutions comme Splunk, Microsoft Sentinel ou CrowdStrike Falcon sur de nombreux cas d'usage. Ce guide approfondi examine en detail les aspects fondamentaux et avances de Wazuh SIEM/XDR Open Source, en proposant une analyse structuree et documentee des enjeux actuels. Les professionnels y trouveront des recommandations concretes, des methodologies eprouvees et des retours d'experience terrain directement applicables en environnement de production. L'analyse integre les dernieres evolutions technologiques, les tendances emergentes du secteur et les meilleures pratiques recommandees par les experts du domaine.

Les chiffres parlent d'eux-mêmes : en 2026, Wazuh revendique plus de 100 millions de téléchargements d'agents, une communauté de 20 000+ contributeurs GitHub, et une adoption croissante tant dans les PME que dans les grandes entreprises et les MSSP (Managed Security Service Providers). La version 4.9, sortie fin 2025, a introduit des améliorations majeures en matière de performance d'indexation, de corrélation multi-sources et de réponse automatisée.

Ce qui distingue Wazuh des autres SIEM open source comme Elastic Security ou Graylog, c'est son approche agent-based native. Chaque endpoint déploie un agent léger qui collecte les logs, surveille l'intégrité des fichiers, évalue les vulnérabilités et applique les réponses actives -- le tout sans dépendre d'un collecteur centralisé. Cette architecture distribue l'intelligence de détection au plus près des sources, réduisant la latence et la bande passante réseau.

Ce guide s'adresse aux analystes SOC, ingénieurs sécurité et architectes qui souhaitent déployer Wazuh en production. Nous couvrons l'intégralité du cycle : de l'architecture et l'installation cluster, à la configuration des agents multi-OS, en passant par la création de règles de détection custom, l'intégration avec l'écosystème CTI (VirusTotal, MISP) et SOAR (TheHive), jusqu'au tuning de performance pour les environnements à fort volume. Chaque section contient des configurations concrètes, des exemples de règles et des recommandations issues de déploiements réels.

Point clé : Wazuh n'est pas qu'un SIEM -- c'est une plateforme XDR complète qui intègre nativement la détection d'intrusion, le FIM, le vulnerability assessment, le SCA, la réponse active et la conformité. Comprendre cette polyvalence est essentiel pour maximiser le retour sur investissement du déploiement.

2. Architecture Wazuh : comprendre les composants

2.1 Vue d'ensemble des composants

L'architecture Wazuh repose sur quatre composants principaux, chacun jouant un rôle distinct dans la chaîne de collecte, d'analyse et de visualisation des données de sécurité :

Wazuh Agent : déployé sur chaque endpoint (serveur, poste de travail, conteneur), l'agent est un processus léger qui collecte les événements système, surveille les fichiers, évalue les vulnérabilités et exécute les réponses actives. Il communique avec le manager via un canal chiffré (AES-256) sur le port 1514/TCP. L'agent supporte nativement Linux, Windows, macOS, Solaris, AIX et HP-UX, couvrant ainsi la quasi-totalité des environnements d'entreprise.

Wazuh Manager (Server) : c'est le cerveau de la plateforme. Le manager reçoit les données des agents, les décode via les decoders, les analyse via les rules, génère les alertes et orchestre les réponses actives. Il stocke également les configurations centralisées des agents et gère leur cycle de vie (enregistrement, mise à jour, désenregistrement). En mode cluster, plusieurs managers partagent la charge et assurent la haute disponibilité.

Wazuh Indexer : basé sur OpenSearch (fork d'Elasticsearch), l'indexer stocke et indexe toutes les alertes et les événements bruts. Il fournit les capacités de recherche full-text, d'agrégation et de rétention à long terme nécessaires aux investigations forensiques et aux exigences de conformité. Depuis la version 4.8, l'indexer supporte le hot-warm-cold architecture pour optimiser les coûts de stockage sur de longues périodes.

Wazuh Dashboard : basé sur OpenSearch Dashboards, il fournit l'interface graphique pour visualiser les alertes, explorer les données, gérer les agents et configurer les règles. Le dashboard inclut des modules prédéfinis pour chaque fonctionnalité (MITRE ATT&CK, Vulnerability Detection, FIM, SCA, etc.) et permet de créer des tableaux de bord personnalisés.

2.2 Flux de données et chaîne de détection

Le flux de données dans Wazuh suit une chaîne logique en cinq étapes. Premièrement, l'agent collecte les événements bruts (logs système, événements Windows, modifications de fichiers, résultats de scans). Deuxièmement, ces événements sont transmis au manager via le protocole Wazuh (port 1514/TCP), chiffré en AES-256 avec compression. Troisièmement, le manager applique les decoders pour extraire les champs structurés des logs bruts. Quatrièmement, le moteur de règles évalue chaque événement décodé contre l'ensemble des règles actives (plus de 4 000 règles par défaut) et génère des alertes lorsqu'un match est trouvé. Cinquièmement, les alertes sont envoyées à l'indexer pour stockage et à tous les canaux d'intégration configurés (webhook, email, SOAR).

Un point crucial pour le dimensionnement : chaque agent génère en moyenne 50 à 200 événements par seconde (EPS) selon le type de workload et la configuration du monitoring. Un manager single-node peut traiter environ 500 à 1 000 EPS avant de nécessiter un cluster. L'indexer est généralement le goulot d'étranglement, car il doit indexer, stocker et rendre searchable chaque événement.

2.3 Mode cluster : haute disponibilité

Pour les environnements de production, Wazuh supporte un mode cluster natif où plusieurs managers fonctionnent ensemble. Le cluster utilise un modèle master-worker : un noeud master synchronise la configuration et les clés d'agents, tandis que les noeuds workers traitent les événements. La répartition des agents entre les workers se fait automatiquement ou manuellement. En cas de panne du master, un worker peut être promu manuellement (le failover automatique du master n'est pas encore natif en 4.9, mais les workers continuent de fonctionner indépendamment).

L'indexer, basé sur OpenSearch, dispose de son propre mécanisme de clustering avec réplication des shards. Pour la production, un minimum de 3 noeuds indexer est recommandé pour garantir la résilience (factor de réplication = 1, ce qui signifie que chaque shard a une copie sur un autre noeud).

3. Installation et déploiement du cluster Wazuh

3.1 Prérequis matériels et logiciels

Avant de déployer Wazuh, dimensionner correctement l'infrastructure. Les ressources varient considérablement selon le nombre d'agents et le volume d'événements :

Composant	CPU	RAM	Stockage	Agents supportés
Manager (all-in-one)	4 vCPU	8 Go	100 Go SSD	Jusqu'à 100
Manager (production)	8 vCPU	16 Go	200 Go SSD	Jusqu'à 1 000
Manager (cluster worker)	8 vCPU	16 Go	200 Go SSD	1 000 par worker
Indexer (single node)	4 vCPU	16 Go	500 Go SSD	30 jours rétention
Indexer (production node)	8 vCPU	32 Go	2 To NVMe	90 jours rétention
Dashboard	4 vCPU	8 Go	50 Go	N/A

3.2 Installation du manager avec le script Wazuh

Wazuh fournit un assistant d'installation qui simplifie considérablement le déploiement. Voici la procédure pour un déploiement distribué sur Ubuntu 22.04 LTS :

# Télécharger l'assistant d'installation Wazuh 4.9
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.9/config.yml

# Éditer config.yml pour définir les noeuds
# nodes:
#   indexer:
#     - name: wazuh-indexer-01
#       ip: 10.0.1.10
#     - name: wazuh-indexer-02
#       ip: 10.0.1.11
#     - name: wazuh-indexer-03
#       ip: 10.0.1.12
#   server:
#     - name: wazuh-manager-master
#       ip: 10.0.1.20
#       node_type: master
#     - name: wazuh-manager-worker01
#       ip: 10.0.1.21
#       node_type: worker
#   dashboard:
#     - name: wazuh-dashboard
#       ip: 10.0.1.30

# Générer les certificats TLS
bash wazuh-install.sh --generate-config-files

# Sur chaque noeud indexer :
bash wazuh-install.sh --wazuh-indexer wazuh-indexer-01

# Sur le noeud manager master :
bash wazuh-install.sh --wazuh-server wazuh-manager-master

# Sur les workers :
bash wazuh-install.sh --wazuh-server wazuh-manager-worker01

# Sur le noeud dashboard :
bash wazuh-install.sh --wazuh-dashboard wazuh-dashboard

# Initialiser le cluster indexer (depuis n'importe quel noeud indexer)
bash wazuh-install.sh --start-cluster

3.3 Configuration du cluster manager

La configuration du cluster se fait dans /var/ossec/etc/ossec.conf. Voici la configuration du noeud master :

<cluster>
  <name>wazuh-cluster-prod</name>
  <node_name>wazuh-manager-master</node_name>
  <node_type>master</node_type>
  <key>c4ca4238a0b923820dcc509a6f75849b</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>10.0.1.20</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

Et la configuration d'un noeud worker :

<cluster>
  <name>wazuh-cluster-prod</name>
  <node_name>wazuh-manager-worker01</node_name>
  <node_type>worker</node_type>
  <key>c4ca4238a0b923820dcc509a6f75849b</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>10.0.1.20</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

4. Configuration des agents multi-OS

4.1 Déploiement de l'agent Linux

L'installation de l'agent Linux se fait via les dépôts officiels Wazuh. La procédure est identique sur Debian, Ubuntu, RHEL, CentOS et leurs dérivés :

# Ajouter le dépôt Wazuh (Debian/Ubuntu)
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor -o /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-get update && apt-get install wazuh-agent -y

# Configurer l'adresse du manager
sed -i 's/MANAGER_IP/10.0.1.20/' /var/ossec/etc/ossec.conf

# Enregistrer l'agent auprès du manager
/var/ossec/bin/agent-auth -m 10.0.1.20 -A $(hostname)

# Démarrer l'agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Pour un déploiement à grande échelle, Wazuh supporte l'enregistrement automatique via authd (avec mot de passe) ou via l'API REST du manager. L'approche API est recommandée pour l'intégration avec les outils d'orchestration (Ansible, Puppet, Terraform) :

# Enregistrement via l'API Wazuh (alternative à agent-auth)
TOKEN=$(curl -u wazuh-wui:MyS3cr3tP@ss -k \
  -X POST "https://10.0.1.20:55000/security/user/authenticate" \
  | jq -r '.data.token')

curl -k -X POST "https://10.0.1.20:55000/agents" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"web-srv-01","ip":"10.0.2.50"}'

4.2 Déploiement de l'agent Windows avec Sysmon

Sur Windows, l'agent Wazuh se combine idéalement avec Sysmon (System Monitor de Sysinternals) pour capturer les événements de processus, les connexions réseau, les chargements de DLL et les modifications du registre -- des données essentielles pour la détection des techniques Living off the Land et les investigations post-incident.

# Installation Sysmon avec configuration SwiftOnSecurity (recommandée)
sysmon64.exe -accepteula -i sysmonconfig-export.xml

# Installation agent Wazuh (MSI silencieux)
wazuh-agent-4.9.0-1.msi /q WAZUH_MANAGER="10.0.1.20" \
  WAZUH_AGENT_NAME="desktop-fin-01" \
  WAZUH_REGISTRATION_SERVER="10.0.1.20" \
  WAZUH_AGENT_GROUP="windows-workstations"

# Ajouter la collecte Sysmon dans ossec.conf de l'agent
# (ou via agent.conf centralisé sur le manager)
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Quel est votre taux de faux positifs et quel impact a-t-il sur la vigilance de vos analystes ?

4. Configuration des agents multi-OS : analyse approfondie

La configuration Sysmon doit être soigneusement choisie. La configuration SwiftOnSecurity est un excellent point de départ, mais pour les environnements à haut risque, la configuration Olaf Hartong (sysmon-modular) offre une couverture ATT&CK plus étendue, au prix d'un volume d'événements plus important. Quel que soit le choix, la détection des techniques d'escalade de privilèges Windows dépend directement de la qualité de cette configuration.

4.3 Configuration centralisée avec agent.conf et shared groups

L'un des atouts majeurs de Wazuh est la possibilité de gérer la configuration des agents de manière centralisée via le fichier agent.conf et le système de groupes partagés. Chaque agent peut appartenir à un ou plusieurs groupes, et hériter de la configuration de ces groupes :

# /var/ossec/etc/shared/linux-servers/agent.conf
<agent_config os="linux">
  <!-- Surveillance des fichiers critiques -->
  <syscheck>
    <frequency>3600</frequency>
    <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/boot</directories>
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore type="sregex">.log$|.tmp$</ignore>
  </syscheck>
  
  <!-- Collecte des logs -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
  
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/syslog</location>
  </localfile>
  
  <!-- Commandes de détection -->
  <localfile>
    <log_format>full_command</log_format>
    <command>netstat -tulnp</command>
    <frequency>300</frequency>
  </localfile>
  
  <!-- Vulnerability detection -->
  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <packages>yes</packages>
    <hotfixes>yes</hotfixes>
    <ports all="no">yes</ports>
    <processes>yes</processes>
  </wodle>
</agent_config>

Pour affecter un agent à un groupe, utilisez l'API ou la CLI :

# Affecter un agent au groupe "linux-servers"
/var/ossec/bin/agent_groups -i 001 -g linux-servers

# Ou via l'API REST
curl -k -X PUT "https://10.0.1.20:55000/agents/001/group/linux-servers" \
  -H "Authorization: Bearer $TOKEN"

5. Règles de détection custom et décodeurs

5.1 Comprendre le moteur de règles Wazuh

Le moteur de règles Wazuh est le coeur de la capacité de détection. Chaque événement traverse d'abord les decoders (qui extraient les champs structurés du log brut), puis les rules (qui évaluent les conditions de détection). Les règles sont organisées en niveaux de sévérité (0 à 15, où 0 = pas d'alerte et 15 = attaque critique), et peuvent être chaînées via le mécanisme if_sid (parent rule) pour créer des corrélations multi-événements.

Wazuh embarque plus de 4 000 règles par défaut couvrant les systèmes Linux, Windows, macOS, les applications web (Apache, Nginx), les bases de données, les équipements réseau et les services cloud. Ces règles sont stockées dans /var/ossec/ruleset/rules/ et ne doivent jamais être modifiées directement -- les mises à jour les écraseraient. Toute personnalisation doit être placée dans /var/ossec/etc/rules/local_rules.xml ou dans des fichiers custom dans le même répertoire.

5.2 Création d'un décodeur custom

Prenons un exemple concret : vous souhaitez décoder les logs d'une application métier qui écrit des lignes de la forme 2026-03-01 10:15:32 AUTH_FAILURE user=jdupont src=192.168.1.50 reason=invalid_password. Voici le décodeur correspondant :

<!-- /var/ossec/etc/decoders/local_decoder.xml -->
<decoder name="custom-auth-app">
  <prematch>^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) AUTH_</prematch>
</decoder>

<decoder name="custom-auth-app-fields">
  <parent>custom-auth-app</parent>
  <regex offset="after_parent">(\S+) user=(\S+) src=(\S+) reason=(\S+)</regex>
  <order>action,dstuser,srcip,extra_data</order>
</decoder>

Ce décodeur en deux parties (parent + enfant) extrait d'abord le pattern d'identification, puis les champs individuels. Le champ action contiendra "FAILURE" ou "SUCCESS", dstuser le nom d'utilisateur, srcip l'adresse IP source, et extra_data la raison de l'échec.

5.3 Création de règles de détection avancées

5. Règles de détection custom et décodeurs : analyse approfondie

Une fois le décodeur en place, créons des règles de détection progressives -- du simple échec d'authentification au brute force détecté :

<!-- /var/ossec/etc/rules/local_rules.xml -->

<!-- Règle de base : échec d'authentification applicatif -->
<group name="custom-auth,authentication_failed,">
  <rule id="100001" level="5">
    <decoded_as>custom-auth-app</decoded_as>
    <match>FAILURE</match>
    <description>Application auth failure: user $(dstuser) from $(srcip)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failed,</group>
  </rule>

  <!-- Corrélation : 5 échecs en 120 secondes = brute force -->
  <rule id="100002" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100001</if_matched_sid>
    <same_source_ip />
    <description>Brute force detected on custom app from $(srcip) targeting $(dstuser)</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>authentication_failed,attack,</group>
  </rule>

  <!-- Corrélation avancée : brute force distribué (même user, IPs différentes) -->
  <rule id="100003" level="12" frequency="10" timeframe="300">
    <if_matched_sid>100001</if_matched_sid>
    <same_field>dstuser</same_field>
    <different_source_ip />
    <description>Distributed brute force: multiple IPs targeting user $(dstuser)</description>
    <mitre>
      <id>T1110.004</id>
    </mitre>
    <group>authentication_failed,attack,</group>
  </rule>
</group>

Notez l'utilisation du mapping MITRE ATT&CK natif (<mitre><id>T1110</id></mitre>) qui permet de visualiser automatiquement les détections dans la matrice ATT&CK du dashboard Wazuh. Cette cartographie est essentielle pour structurer la couverture de détection et s'aligne avec les pratiques décrites dans notre article sur les techniques MITRE ATT&CK les plus utilisées.

5.4 Détection des techniques Living off the Land

Les attaques Living off the Land (LOLBins) exploitent des outils légitimes du système (PowerShell, WMI, certutil, regsvr32) pour échapper à la détection. Wazuh, combiné avec Sysmon, excelle dans la détection de ces techniques :

<!-- Détection d'utilisation suspecte de certutil pour téléchargement -->
<rule id="100010" level="12">
  <if_sid>61603</if_sid>
  <field name="win.eventdata.originalFileName">CertUtil.exe</field>
  <field name="win.eventdata.commandLine" type="pcre2">(?i)(urlcache|split|decode|encode|download)</field>
  <description>Suspicious certutil usage: possible download/decode operation</description>
  <mitre>
    <id>T1105</id>
    <id>T1140</id>
  </mitre>
</rule>

<!-- Détection de PowerShell encodé en base64 -->
<rule id="100011" level="14">
  <if_sid>61603</if_sid>
  <field name="win.eventdata.originalFileName">PowerShell.EXE</field>
  <field name="win.eventdata.commandLine" type="pcre2">(?i)(-enc|-encodedcommand|-ec)\s+[A-Za-z0-9+/=]{50,}</field>
  <description>PowerShell with long base64 encoded command detected</description>
  <mitre>
    <id>T1059.001</id>
    <id>T1027</id>
  </mitre>
</rule>

<!-- Détection de LOLBAS: mshta exécutant du contenu distant -->
<rule id="100012" level="13">
  <if_sid>61603</if_sid>
  <field name="win.eventdata.originalFileName">MSHTA.EXE</field>
  <field name="win.eventdata.commandLine" type="pcre2">(?i)(http|https|ftp|javascript|vbscript)</field>
  <description>MSHTA executing remote or scripted content</description>
  <mitre>
    <id>T1218.005</id>
  </mitre>
</rule>

6. FIM, Vulnerability Detection et SCA

6.1 File Integrity Monitoring (FIM)

Le module FIM (syscheck) surveille les modifications de fichiers et de répertoires sur les endpoints. Contrairement à un simple checksum périodique, Wazuh FIM supporte la surveillance en temps réel (via inotify sur Linux et ReadDirectoryChangesW sur Windows), la détection des changements de permissions, de propriétaires, et le who-data qui identifie le processus et l'utilisateur ayant effectué la modification.

<!-- Configuration FIM avancée pour serveurs critiques -->
<syscheck>
  <frequency>3600</frequency>
  <scan_on_start>yes</scan_on_start>
  
  <!-- Répertoires critiques avec surveillance temps réel -->
  <directories check_all="yes" realtime="yes" report_changes="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/usr/bin,/usr/sbin,/sbin,/bin</directories>
  <directories check_all="yes" realtime="yes" whodata="yes">/var/www</directories>
  
  <!-- Surveillance du crontab -->
  <directories check_all="yes" realtime="yes">/var/spool/cron</directories>
  <directories check_all="yes" realtime="yes">/etc/cron.d</directories>
  
  <!-- Registre Windows (sur agents Windows) -->
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce</windows_registry>
  <windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>
  
  <!-- Exclusions pour réduire le bruit -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">\.swp$|\.tmp$|\.log$</ignore>
  
  <!-- Synchronisation avec le manager -->
  <synchronization>
    <enabled>yes</enabled>
    <interval>5m</interval>
  </synchronization>
</syscheck>

Le FIM est particulièrement pertinent pour détecter les mécanismes de persistance (ajout de binaires dans les répertoires système, modification des scripts d'initialisation, création de services) et les webshells (création de fichiers PHP/JSP dans les répertoires web). Combiné avec les données de la forensique disque, le FIM fournit une timeline précise des modifications malveillantes.

6.2 Vulnerability Detection

Le module Vulnerability Detector analyse les paquets installés sur chaque agent et les compare aux bases de données CVE (NVD, Ubuntu, Debian, Red Hat, Windows). Il produit un inventaire continu des vulnérabilités affectant chaque endpoint, avec le score CVSS, la description et l'existence d'un correctif.

<!-- Configuration du Vulnerability Detector sur le manager -->
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <min_full_scan_interval>6h</min_full_scan_interval>
  <run_on_start>yes</run_on_start>
  
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>focal</os>
    <os>jammy</os>
    <os>noble</os>
    <update_interval>1h</update_interval>
  </provider>
  
  <provider name="redhat">
    <enabled>yes</enabled>
    <os>8</os>
    <os>9</os>
    <update_interval>1h</update_interval>
  </provider>
  
  <provider name="msu">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
  
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>

Le Vulnerability Detector est complémentaire aux scanners de vulnérabilités traditionnels (Nessus, Qualys) : il fonctionne en continu et sans scan réseau, ce qui le rend adapté aux environnements où les scans actifs sont limités (OT, systèmes critiques). Les résultats alimentent le dashboard et peuvent déclencher des alertes pour les CVE critiques (CVSS 9+).

6.3 Security Configuration Assessment (SCA)

Le module SCA évalue la conformité de chaque endpoint par rapport à des politiques de durcissement (CIS Benchmarks, PCI DSS, HIPAA, NIST 800-53). Wazuh embarque les politiques CIS pour les principaux systèmes d'exploitation et permet de créer des politiques custom :

6. FIM, Vulnerability Detection et SCA : analyse approfondie

# Extrait d'une politique SCA custom (YAML)
# /var/ossec/etc/shared/default/custom-sca-linux.yml
policy:
  id: "custom_linux_hardening"
  file: "custom-sca-linux.yml"
  name: "Custom Linux Hardening Policy"
  description: "Politique de durcissement interne"

checks:
  - id: 10001
    title: "SSH: PermitRootLogin should be disabled"
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PermitRootLogin\s+no'

  - id: 10002
    title: "SSH: Password authentication should be disabled"
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PasswordAuthentication\s+no'

  - id: 10003
    title: "Firewall should be active"
    condition: any
    rules:
      - 'c:systemctl is-active ufw -> r:^active'
      - 'c:systemctl is-active firewalld -> r:^active'
      - 'c:iptables -L -n -> r:Chain INPUT .+ policy DROP'

  - id: 10004
    title: "No world-writable files in /etc"
    condition: none
    rules:
      - 'c:find /etc -type f -perm -002 -> r:^/'

Le SCA est un outil puissant pour maintenir la conformité continue, particulièrement dans le contexte des exigences ISO 27001 et NIS 2 qui imposent une évaluation régulière de la posture de sécurité.

7. Intégrations : VirusTotal, MISP et TheHive

7.1 Intégration VirusTotal

L'intégration VirusTotal permet d'enrichir automatiquement les alertes FIM en soumettant les hashes de fichiers modifiés à l'API VirusTotal. Lorsqu'un fichier surveillé est modifié, Wazuh calcule son hash SHA256 et le soumet pour vérification. Si VirusTotal identifie le fichier comme malveillant (nombre de détections > seuil configuré), une alerte de niveau élevé est générée :

<!-- /var/ossec/etc/ossec.conf - Intégration VirusTotal -->
<integration>
  <name>virustotal</name>
  <api_key>YOUR_VT_API_KEY_HERE</api_key>
  <group>syscheck</group>
  <alert_format>json</alert_format>
</integration>

Avec une clé API gratuite, vous êtes limité à 4 requêtes par minute et 500 par jour. Pour un déploiement de production avec de nombreux agents, une clé premium est recommandée. Alternativement, utilisez les CDB lists (Constant Database) pour maintenir une liste locale de hashes malveillants connus, réduisant ainsi la dépendance à l'API externe. Cette approche est cohérente avec les techniques de détection d'infostealers où la vérification de hashes est critique.

7.2 Intégration MISP

MISP (Malware Information Sharing Platform) est la plateforme de référence pour le partage d'indicateurs de compromission (IOC). L'intégration Wazuh-MISP permet de croiser les événements Wazuh avec les IOC MISP en temps quasi réel. La méthode recommandée utilise les CDB lists synchronisées périodiquement depuis MISP :

# Script de synchronisation MISP -> Wazuh CDB lists
#!/usr/bin/env python3
"""Sync MISP IOCs to Wazuh CDB lists."""
import json
import requests

MISP_URL = "https://misp.internal.corp"
MISP_KEY = "YOUR_MISP_API_KEY"
WAZUH_CDB_PATH = "/var/ossec/etc/lists/"

# Récupérer les IOC IP des événements récents (30 derniers jours)
headers = {"Authorization": MISP_KEY, "Accept": "application/json"}
payload = {
    "type_attribute": ["ip-src", "ip-dst"],
    "last": "30d",
    "enforceWarninglist": True
}
resp = requests.post(f"{MISP_URL}/attributes/restSearch",
                     json=payload, headers=headers, verify=False)
attributes = resp.json().get("response", {}).get("Attribute", [])

# Écrire la CDB list
with open(f"{WAZUH_CDB_PATH}misp-malicious-ips", "w") as f:
    for attr in attributes:
        f.write(f"{attr['value']}:malicious\n")

# Recharger les listes Wazuh
import subprocess
subprocess.run(["/var/ossec/bin/wazuh-control", "reload"])

Puis, dans les règles Wazuh, référencez la CDB list pour enrichir les alertes :

<!-- Règle utilisant la CDB list MISP -->
<rule id="100020" level="14">
  <if_sid>5710,5712</if_sid>
  <list field="srcip" lookup="address_match_key">etc/lists/misp-malicious-ips</list>
  <description>Connection from MISP-flagged malicious IP: $(srcip)</description>
  <mitre>
    <id>T1071</id>
  </mitre>
  <group>threat_intel,misp,</group>
</rule>

7.3 Intégration TheHive (SOAR)

TheHive est une plateforme de réponse aux incidents qui s'intègre naturellement avec Wazuh pour créer automatiquement des cas d'investigation à partir des alertes critiques. L'intégration utilise le mécanisme d'intégration custom de Wazuh :

<!-- /var/ossec/etc/ossec.conf - Intégration TheHive -->
<integration>
  <name>custom-thehive</name>
  <hook_url>http://thehive.internal.corp:9000/api/alert</hook_url>
  <api_key>YOUR_THEHIVE_API_KEY</api_key>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

Le script d'intégration (/var/ossec/integrations/custom-thehive) transforme l'alerte Wazuh en alerte TheHive, avec les observables (IP, hashes, noms d'utilisateur) extraits automatiquement. Depuis TheHive, les analystes SOC peuvent lancer des analyses Cortex (analyseurs automatiques) et piloter la réponse à incident. Cette chaîne Wazuh-TheHive-Cortex forme un stack de détection et réponse open source complet, particulièrement adapté aux organisations qui ne peuvent investir dans des solutions commerciales mais doivent néanmoins atteindre un niveau de maturité SOC élevé.

8. Active Response : automatiser la réponse

8.1 Mécanisme d'Active Response

L'Active Response de Wazuh permet d'exécuter automatiquement des actions sur les agents en réponse à des alertes spécifiques. C'est l'équivalent d'un micro-SOAR intégré directement dans la plateforme. Les actions possibles incluent : bloquer une IP au firewall (iptables/Windows Firewall), désactiver un compte utilisateur, isoler un fichier suspect, redémarrer un service, ou exécuter un script custom.

<!-- Configuration Active Response dans ossec.conf -->

<!-- Définition de la commande -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Réponse active : bloquer l'IP source sur brute force détecté -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100002</rules_id>
  <timeout>3600</timeout>
</active-response>

<!-- Réponse active custom : quarantaine de fichier malveillant -->
<command>
  <name>quarantine-file</name>
  <executable>quarantine-file.sh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>quarantine-file</command>
  <location>local</location>
  <rules_id>100030</rules_id>
</active-response>

8.2 Script d'Active Response custom

Pour des cas d'usage spécifiques, vous pouvez créer des scripts d'Active Response custom. Voici un exemple de script qui isole un endpoint Windows compromis en bloquant toutes les connexions réseau sauf celle vers le manager Wazuh :

#!/bin/bash
# /var/ossec/active-response/bin/isolate-endpoint.sh
# Isolation réseau d'un endpoint compromis

LOCAL=$(dirname $0)
cd $LOCAL
cd ../

PWD=$(pwd)
ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5

WAZUH_MANAGER="10.0.1.20"

if [ "$ACTION" = "add" ]; then
    # Sauvegarder les règles actuelles
    iptables-save > /tmp/iptables-backup-$ALERTID.rules
    
    # Autoriser uniquement le manager Wazuh
    iptables -F
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP
    iptables -A INPUT -s $WAZUH_MANAGER -j ACCEPT
    iptables -A OUTPUT -d $WAZUH_MANAGER -j ACCEPT
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT
    
    echo "$(date) Endpoint isolated - Alert $ALERTID Rule $RULEID" >> ${PWD}/../logs/active-responses.log
    
elif [ "$ACTION" = "delete" ]; then
    # Restaurer les règles sauvegardées
    if [ -f /tmp/iptables-backup-$ALERTID.rules ]; then
        iptables-restore < /tmp/iptables-backup-$ALERTID.rules
        rm /tmp/iptables-backup-$ALERTID.rules
    fi
    echo "$(date) Endpoint un-isolated - Alert $ALERTID" >> ${PWD}/../logs/active-responses.log
fi

exit 0;

9. Dashboards et visualisation

9.1 Les modules du dashboard Wazuh

Le Wazuh Dashboard fournit une interface riche organisée en modules fonctionnels. Le module Security Events agrège toutes les alertes avec filtres par sévérité, source, technique MITRE et agent. Le module Integrity Monitoring affiche les modifications de fichiers avec diff, timeline et attribution (who-data). Le module Vulnerabilities présente l'inventaire des CVE par agent, CVSS et disponibilité de correctifs. Le module MITRE ATT&CK cartographie les détections sur la matrice ATT&CK avec heatmap interactive -- un outil précieux pour identifier les lacunes de couverture.

Pour les environnements multi-tenant ou les MSSP, le dashboard supporte le multi-tenancy via les rôles et groupes OpenSearch, permettant de segmenter l'accès aux données par client ou par équipe.

9.2 Créer des dashboards opérationnels

Au-delà des modules par défaut, construisez des dashboards opérationnels adaptés à votre contexte. Voici les visualisations recommandées pour un SOC :

• SOC Overview : nombre total d'alertes/24h par sévérité, top 10 des règles déclenchées, top 10 des agents, carte géographique des IPs sources.
• Authentication Monitoring : taux d'échecs d'authentification, tentatives de brute force, connexions depuis des géolocalisations inhabituelles, comptes verrouillés.
• Threat Intelligence : alertes VirusTotal/MISP, IOC matchés, nouveaux fichiers malveillants détectés via FIM.
• Compliance : score SCA global et par groupe, nombre de vulnérabilités critiques non corrigées, alertes de non-conformité PCI DSS/CIS.
• Agent Health : agents actifs/déconnectés/jamais connectés, version des agents, dernière communication, utilisation CPU/mémoire des agents.

10. Performance tuning et optimisation

10.1 Optimisation du manager

À mesure que le nombre d'agents et le volume d'événements augmentent, le tuning du manager devient critique. Les paramètres clés à ajuster :

<!-- /var/ossec/etc/internal_options.conf -->

# Nombre de threads d'analyse (par défaut: 0 = auto)
# Augmenter si le CPU n'est pas saturé mais les files d'attente grossissent
analysisd.event_threads=4
analysisd.syscheck_threads=2
analysisd.syscollector_threads=2

# Taille de la file d'attente d'événements
analysisd.event_queue_size=32768

# Nombre max d'agents par worker (cluster)
wazuh_db.worker_pool_size=8

# Buffer de réception réseau
remoted.recv_counter_flush=128
remoted.comp_average_printout=0

# Taux de logging (réduire en production)
analysisd.log_fw=0
analysisd.debug=0

10.2 Optimisation de l'indexer (OpenSearch)

L'indexer est souvent le composant qui sature en premier. Les optimisations essentielles incluent le dimensionnement du heap JVM (50% de la RAM, maximum 32 Go pour bénéficier du Compressed Oops), la stratégie de sharding (1 shard primaire par 30-50 Go d'index, pas plus de 20 shards par Go de heap), et la politique de rétention avec Index State Management (ISM) :

# Politique ISM pour gestion du cycle de vie des index
{
  "policy": {
    "policy_id": "wazuh-alerts-retention",
    "description": "Wazuh alerts retention policy - 90 days hot, 180 days warm, delete",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [
          {
            "rollover": {
              "min_index_age": "1d",
              "min_primary_shard_size": "30gb"
            }
          }
        ],
        "transitions": [
          {
            "state_name": "warm",
            "conditions": { "min_index_age": "90d" }
          }
        ]
      },
      {
        "name": "warm",
        "actions": [
          {
            "force_merge": { "max_num_segments": 1 },
            "replica_count": { "number_of_replicas": 0 },
            "allocation": {
              "require": { "data": "warm" }
            }
          }
        ],
        "transitions": [
          {
            "state_name": "delete",
            "conditions": { "min_index_age": "180d" }
          }
        ]
      },
      {
        "name": "delete",
        "actions": [
          { "delete": {} }
        ]
      }
    ]
  }
}

10.3 Réduire le bruit sans perdre en visibilité

Un déploiement Wazuh non tuné peut générer des milliers d'alertes par jour, noyant les vrais incidents dans le bruit. Les stratégies de réduction du bruit :

• Ajuster le seuil d'alerte : dans ossec.conf, configurez <alerts><log_alert_level>5</log_alert_level></alerts> pour ne stocker que les alertes de niveau 5 et plus.
• Créer des règles de suppression : utilisez des règles de niveau 0 avec if_sid pour supprimer les faux positifs identifiés sans modifier les règles par défaut.
• Affiner les exclusions FIM : exclure les fichiers et répertoires qui changent légitimement (logs rotatés, fichiers temporaires, caches).
• Utiliser les groupes d'agents : appliquer des configurations de monitoring différentes selon le type d'endpoint (serveur critique vs poste de travail standard).
• Évaluer la couverture vs le bruit : corrélez avec la matrice MITRE ATT&CK pour vous assurer que les règles supprimées ne créent pas de trous de détection critiques.

11. Cas d'usage opérationnels

11.1 Détection de ransomware via FIM

Le FIM Wazuh peut détecter les premières phases d'un ransomware en surveillant la création massive de fichiers avec des extensions de chiffrement connues (.encrypted, .locked, .crypto, etc.) et la suppression/modification rapide de nombreux fichiers. Une règle custom pour cette détection :

<!-- Détection de potentiel ransomware via FIM -->
<rule id="100040" level="15" frequency="20" timeframe="60">
  <if_matched_sid>550,553,554</if_matched_sid>
  <description>CRITICAL: Massive file modifications detected - possible ransomware activity</description>
  <mitre>
    <id>T1486</id>
  </mitre>
  <group>ransomware,attack,</group>
</rule>

Combinée avec une Active Response d'isolation réseau, cette règle peut contenir l'attaque avant que le chiffrement ne se propage latéralement. La rapidité de détection est critique -- chaque minute compte pour limiter l'étendue des dommages.

11.2 Détection d'exfiltration DNS

L'exfiltration via DNS tunneling est une technique furtive utilisée par les APT pour extraire des données en encodant les données dans les requêtes DNS. Wazuh peut détecter cette technique en analysant les logs DNS et en identifiant les requêtes anormales (sous-domaines anormalement longs, fréquence élevée vers un même domaine, entropie élevée). Pour une analyse approfondie des techniques d'attaques DNS, consultez notre article dédié.

11.3 Conformité PCI DSS avec Wazuh

Wazuh intègre nativement le mapping des règles vers les exigences PCI DSS 4.0. Les modules FIM (Requirement 11.5), log monitoring (Req 10), vulnerability detection (Req 6.3) et SCA (Req 2.2) couvrent une part significative des contrôles techniques. Le dashboard PCI DSS fournit un reporting prêt pour les audits, avec le pourcentage de conformité par requirement et la liste des findings.

12. Checklist de déploiement Wazuh

Voici la checklist complète pour un déploiement Wazuh en production :

Pour approfondir ce sujet, consultez notre outil open-source siem-correlation-rules qui facilite l'optimisation des règles de corrélation SIEM.

Questions frequentes

13. Conclusion : Wazuh comme fondation SOC open source

Wazuh représente une opportunité unique pour les organisations de toutes tailles de déployer une capacité de détection et réponse mature sans coûts de licence. La plateforme couvre l'essentiel des fonctions d'un SOC moderne : collecte centralisée de logs, détection basée sur les règles, surveillance de l'intégrité, évaluation des vulnérabilités, conformité continue et réponse automatisée.

Le véritable coût de Wazuh n'est pas dans la licence (il n'y en a pas) mais dans l'expertise nécessaire pour le déployer, le configurer et le maintenir efficacement. Les règles par défaut fournissent une couverture de base, mais la valeur réelle vient des règles custom adaptées à l'environnement, des intégrations avec l'écosystème CTI/SOAR, et du tuning continu pour maintenir un ratio signal/bruit acceptable.

Pour aller plus loin, explorez notre article sur le Threat Hunting qui explique comment utiliser les données collectées par Wazuh pour mener des chasses proactives aux menaces. Combinée avec une méthodologie de threat hunting structurée, la plateforme Wazuh devient un véritable multiplicateur de force pour les équipes de sécurité.

Mot de la fin : Un SIEM sans analyste compétent n'est qu'un générateur de logs coûteux. Un analyste compétent sans SIEM n'est qu'un pompier sans lance. Wazuh fournit l'outil -- investissez dans les compétences pour en extraire toute la valeur.