Wazuh : Déployez votre SIEM/XDR Open-Source pour la Détection de Menaces

Introduction : Pourquoi un SIEM est devenu indispensable

En 2025-2026, les cyberattaques ont atteint un niveau de sophistication et de fréquence sans précédent. Ransomwares, attaques par chaîne d'approvisionnement (supply chain), phishing ciblé, exploitation de vulnérabilités zero-day : la menace est omniprésente, que vous soyez une multinationale ou une PME. Face à cette réalité, la capacité à détecter, analyser et répondre aux menaces en temps réel n'est plus un luxe, c'est une nécessité.

C'est précisément le rôle d'un SIEM (Security Information and Event Management) : collecter les logs et événements de sécurité de toute votre infrastructure, les corréler, détecter les anomalies et alerter les équipes de sécurité. Mais les SIEM commerciaux comme Splunk, IBM QRadar ou Microsoft Sentinel coûtent des dizaines, voire des centaines de milliers d'euros par an.

Architecture en un coup d'œil

Entrez Wazuh : une plateforme de sécurité open-source et gratuite qui combine les fonctionnalités d'un SIEM, d'un XDR (Extended Detection and Response) et d'un HIDS (Host-based Intrusion Detection System). Avec plus de 30 000 étoiles sur GitHub, une communauté massive et le soutien d'une entreprise dédiée (Wazuh Inc.), c'est devenu la référence open-source en cybersécurité défensive.

Ce guide complet vous accompagnera dans le déploiement de Wazuh, de l'installation à la configuration avancée des règles de détection, en passant par l'intégration avec votre infrastructure existante.

Qu'est-ce que Wazuh ? SIEM + XDR + HIDS

Wazuh est une plateforme unifiée de sécurité qui intègre trois grandes familles de fonctionnalités :

SIEM (Security Information and Event Management)

• Collecte centralisée des logs de toutes vos sources (serveurs, applications, équipements réseau, cloud).
• Corrélation d'événements : détecte des patterns d'attaque en croisant des événements de sources différentes.
• Analyse en temps réel : traitement immédiat des événements avec des règles de détection.
• Stockage et recherche : archivage des logs avec capacité de recherche pour l'investigation forensique.
• Tableaux de bord et rapports : visualisation des données de sécurité pour les équipes SOC.

XDR (Extended Detection and Response)

• Détection avancée des menaces sur les endpoints (serveurs, postes de travail).
• Réponse active : actions automatiques en réponse aux menaces détectées (blocage IP, kill process, isolation).
• Threat intelligence : intégration avec des sources de renseignement sur les menaces (MITRE ATT&CK, VirusTotal, AlienVault OTX).
• Investigation : outils pour analyser les incidents et comprendre la chaîne d'attaque.

HIDS (Host-based Intrusion Detection System)

• File Integrity Monitoring (FIM) : détection des modifications sur les fichiers critiques du système.
• Rootkit detection : recherche de rootkits et malwares sur les systèmes.
• System inventory : inventaire des logiciels installés, ports ouverts, processus en cours.
• Configuration assessment : vérification de la conformité des configurations (CIS Benchmarks).

Architecture de Wazuh

L'architecture de Wazuh est composée de quatre composants principaux :

1. Wazuh Server (Manager)

Le cerveau de la plateforme. Il reçoit les données des agents, les analyse avec le moteur de règles, déclenche les alertes et orchestre les réponses actives. Il gère également la configuration centralisée des agents.

2. Wazuh Indexer

Basé sur OpenSearch (fork d'Elasticsearch), il stocke et indexe les alertes et événements. C'est le moteur de recherche qui permet l'investigation forensique et la création de visualisations. Hautement scalable, il peut être déployé en cluster pour la haute disponibilité.

3. Wazuh Dashboard

Basé sur OpenSearch Dashboards (fork de Kibana), c'est l'interface web qui permet de visualiser les alertes, créer des tableaux de bord, gérer les agents, configurer les règles et investiguer les incidents. Accessible via HTTPS sur le port 443.

4. Wazuh Agents

Des agents légers installés sur chaque machine à surveiller. Ils collectent les logs, surveillent l'intégrité des fichiers, détectent les vulnérabilités et exécutent les réponses actives. Disponibles pour Linux, Windows, macOS, Solaris, AIX et HP-UX.

Flux de données

1. Les agents collectent les données sur les endpoints et les envoient au Wazuh Server via le protocole Wazuh (port 1514/1515, chiffré AES).
2. Le Wazuh Server analyse les données avec son moteur de règles et de décodeurs.
3. Les alertes générées sont envoyées au Wazuh Indexer pour le stockage et l'indexation.
4. Le Wazuh Dashboard interroge l'Indexer pour afficher les données aux analystes.

Installation avec Docker Compose

La méthode la plus simple et reproductible pour déployer Wazuh est d'utiliser Docker Compose. Wazuh fournit un dépôt officiel avec toutes les configurations nécessaires.

Prérequis

• Serveur Linux (Ubuntu 22.04/24.04 LTS, Debian 12, CentOS/RHEL 9).
• 8 Go de RAM minimum (16 Go recommandé pour la production).
• 4 CPU minimum (8 CPU recommandé).
• 50 Go d'espace disque minimum (plus selon le volume de logs).
• Docker et Docker Compose installés.

# Installer Docker et Docker Compose
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

# Augmenter la limite vm.max_map_count (requis par OpenSearch)
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -w vm.max_map_count=262144

# Vérifier
sysctl vm.max_map_count

Déploiement Single-Node

Le déploiement single-node est parfait pour les environnements de test, les petites infrastructures et les homelabs (jusqu'à ~100 agents).

# Cloner le dépôt officiel
git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.2
cd wazuh-docker/single-node

# Générer les certificats SSL auto-signés
docker compose -f generate-indexer-certs.yml run --rm generator

# Lancer le stack complet
docker compose up -d

# Vérifier que tous les conteneurs sont en cours d'exécution
docker compose ps

Voici le fichier docker-compose.yml officiel pour le déploiement single-node :

# docker-compose.yml - Wazuh Single-Node Deployment
version: '3.7'

services:
  wazuh.manager:
    image: wazuh/wazuh-manager:4.9.2
    hostname: wazuh.manager
    restart: always
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 655360
        hard: 655360
    ports:
      - "1514:1514"       # Agent communication
      - "1515:1515"       # Agent enrollment
      - "514:514/udp"     # Syslog collection
      - "55000:55000"     # Wazuh API
    environment:
      INDEXER_URL: https://wazuh.indexer:9200
      INDEXER_USERNAME: admin
      INDEXER_PASSWORD: SecretPassword
      FILEBEAT_SSL_VERIFICATION_MODE: full
      SSL_CERTIFICATE_AUTHORITIES: /etc/ssl/root-ca.pem
      SSL_CERTIFICATE: /etc/ssl/filebeat.pem
      SSL_KEY: /etc/ssl/filebeat-key.pem
      API_USERNAME: wazuh-wui
      API_PASSWORD: MyS3cr3tP4ssw0rd
    volumes:
      - wazuh_api_configuration:/var/ossec/api/configuration
      - wazuh_etc:/var/ossec/etc
      - wazuh_logs:/var/ossec/logs
      - wazuh_queue:/var/ossec/queue
      - wazuh_var_multigroups:/var/ossec/var/multigroups
      - wazuh_integrations:/var/ossec/integrations
      - wazuh_active_response:/var/ossec/active-response/bin
      - wazuh_agentless:/var/ossec/agentless
      - wazuh_wodles:/var/ossec/wodles
      - filebeat_etc:/etc/filebeat
      - filebeat_var:/var/lib/filebeat
      - ./config/wazuh_indexer_ssl_certs/root-ca-manager.pem:/etc/ssl/root-ca.pem
      - ./config/wazuh_indexer_ssl_certs/wazuh.manager.pem:/etc/ssl/filebeat.pem
      - ./config/wazuh_indexer_ssl_certs/wazuh.manager-key.pem:/etc/ssl/filebeat-key.pem
      - ./config/wazuh_cluster/wazuh_manager.conf:/wazuh-config-mount/etc/ossec.conf

  wazuh.indexer:
    image: wazuh/wazuh-indexer:4.9.2
    hostname: wazuh.indexer
    restart: always
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    ports:
      - "9200:9200"       # OpenSearch API
    environment:
      OPENSEARCH_JAVA_OPTS: "-Xms1g -Xmx1g"
      bootstrap.memory_lock: "true"
      discovery.type: single-node
      plugins.security.ssl.http.pemcert_filepath: /usr/share/wazuh-indexer/certs/wazuh.indexer.pem
      plugins.security.ssl.http.pemkey_filepath: /usr/share/wazuh-indexer/certs/wazuh.indexer-key.pem
      plugins.security.ssl.http.pemtrustedcas_filepath: /usr/share/wazuh-indexer/certs/root-ca.pem
      plugins.security.ssl.transport.pemcert_filepath: /usr/share/wazuh-indexer/certs/wazuh.indexer.pem
      plugins.security.ssl.transport.pemkey_filepath: /usr/share/wazuh-indexer/certs/wazuh.indexer-key.pem
      plugins.security.ssl.transport.pemtrustedcas_filepath: /usr/share/wazuh-indexer/certs/root-ca.pem
      plugins.security.authcz.admin_dn: "CN=admin,OU=Wazuh,O=Wazuh,L=California,C=US"
      compatibility.override_main_response_version: "true"
    volumes:
      - wazuh-indexer-data:/var/lib/wazuh-indexer
      - ./config/wazuh_indexer_ssl_certs/root-ca.pem:/usr/share/wazuh-indexer/certs/root-ca.pem
      - ./config/wazuh_indexer_ssl_certs/wazuh.indexer-key.pem:/usr/share/wazuh-indexer/certs/wazuh.indexer-key.pem
      - ./config/wazuh_indexer_ssl_certs/wazuh.indexer.pem:/usr/share/wazuh-indexer/certs/wazuh.indexer.pem
      - ./config/wazuh_indexer_ssl_certs/admin.pem:/usr/share/wazuh-indexer/certs/admin.pem
      - ./config/wazuh_indexer_ssl_certs/admin-key.pem:/usr/share/wazuh-indexer/certs/admin-key.pem

  wazuh.dashboard:
    image: wazuh/wazuh-dashboard:4.9.2
    hostname: wazuh.dashboard
    restart: always
    ports:
      - "443:5601"        # Dashboard web interface
    environment:
      INDEXER_USERNAME: admin
      INDEXER_PASSWORD: SecretPassword
      WAZUH_API_URL: https://wazuh.manager
      DASHBOARD_USERNAME: kibanaserver
      DASHBOARD_PASSWORD: kibanaserver
      API_USERNAME: wazuh-wui
      API_PASSWORD: MyS3cr3tP4ssw0rd
    volumes:
      - ./config/wazuh_indexer_ssl_certs/wazuh.dashboard.pem:/usr/share/wazuh-dashboard/certs/wazuh-dashboard.pem
      - ./config/wazuh_indexer_ssl_certs/wazuh.dashboard-key.pem:/usr/share/wazuh-dashboard/certs/wazuh-dashboard-key.pem
      - ./config/wazuh_indexer_ssl_certs/root-ca.pem:/usr/share/wazuh-dashboard/certs/root-ca.pem
      - ./config/wazuh_dashboard/opensearch_dashboards.yml:/usr/share/wazuh-dashboard/config/opensearch_dashboards.yml
      - ./config/wazuh_dashboard/wazuh.yml:/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
      - wazuh-dashboard-config:/usr/share/wazuh-dashboard/data/wazuh/config
      - wazuh-dashboard-custom:/usr/share/wazuh-dashboard/plugins/wazuh/public/assets/custom
    depends_on:
      - wazuh.indexer

volumes:
  wazuh_api_configuration:
  wazuh_etc:
  wazuh_logs:
  wazuh_queue:
  wazuh_var_multigroups:
  wazuh_integrations:
  wazuh_active_response:
  wazuh_agentless:
  wazuh_wodles:
  filebeat_etc:
  filebeat_var:
  wazuh-indexer-data:
  wazuh-dashboard-config:
  wazuh-dashboard-custom:

Accéder au Dashboard

Après le démarrage (attendez 2-3 minutes pour l'initialisation), accédez au dashboard via https://VOTRE_IP:443. Les identifiants par défaut sont :

• Utilisateur : admin
• Mot de passe : SecretPassword

Important : Changez immédiatement les mots de passe par défaut en production. Utilisez le script fourni par Wazuh ou modifiez les variables d'environnement dans le docker-compose.yml avant le premier démarrage.

# Changer le mot de passe admin de l'indexer
docker exec -it wazuh-docker-wazuh.indexer-1 bash
export INSTALLATION_DIR=/usr/share/wazuh-indexer
OPENSEARCH_PATH_CONF=${INSTALLATION_DIR}/config ${INSTALLATION_DIR}/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --change-all --admin-user admin --admin-password SecretPassword

# Redémarrer les services après le changement
docker compose restart

Déploiement Multi-Node (Production)

Pour les environnements de production avec un volume important de logs et des exigences de haute disponibilité, utilisez le déploiement multi-node :

# Cloner et utiliser la configuration multi-node
cd wazuh-docker/multi-node

# Ce déploiement inclut :
# - 1 Wazuh Manager (master)
# - 1 Wazuh Manager (worker) - pour la distribution de charge
# - 3 Wazuh Indexer nodes - pour la haute disponibilité des données
# - 1 Wazuh Dashboard

# Générer les certificats
docker compose -f generate-indexer-certs.yml run --rm generator

# Lancer le stack
docker compose up -d

# Vérifier le cluster indexer
curl -k -u admin:SecretPassword https://localhost:9200/_cluster/health?pretty

Déployer les Agents Wazuh

Les agents sont le fondement de la visibilité de Wazuh. Chaque machine que vous souhaitez surveiller doit avoir un agent installé.

Installation sur Linux (Debian/Ubuntu)

# Ajouter le dépôt Wazuh
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 -a /etc/apt/sources.list.d/wazuh.list

apt update

# Installer l'agent en spécifiant l'adresse du manager
WAZUH_MANAGER="192.168.1.100" apt install -y wazuh-agent

# Activer et démarrer l'agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

# Vérifier le statut
systemctl status wazuh-agent

# Vérifier la connexion avec le manager
/var/ossec/bin/agent-auth -m 192.168.1.100

# Logs de l'agent
tail -f /var/ossec/logs/ossec.log

Installation sur Linux (RHEL/CentOS/Fedora)

# Ajouter le dépôt Wazuh
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH

cat > /etc/yum.repos.d/wazuh.repo << '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/
protect=1
EOF

# Installer l'agent
WAZUH_MANAGER="192.168.1.100" yum install -y wazuh-agent

# Activer et démarrer
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Installation sur Windows

# Télécharger l'installeur MSI depuis le site officiel
# https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.2-1.msi

# Installation silencieuse via PowerShell (en tant qu'administrateur)
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.2-1.msi -OutFile ${env:tmp}\wazuh-agent.msi

msiexec.exe /i ${env:tmp}\wazuh-agent.msi /q WAZUH_MANAGER="192.168.1.100" WAZUH_AGENT_GROUP="windows-servers"

# Démarrer le service
NET START WazuhSvc

# Ou via l'interface graphique
# Exécutez le MSI et suivez l'assistant d'installation

Installation sur macOS

# Télécharger le package PKG
curl -O https://packages.wazuh.com/4.x/macos/wazuh-agent-4.9.2-1.pkg

# Installer avec la configuration du manager
sudo launchctl setenv WAZUH_MANAGER "192.168.1.100"
sudo installer -pkg wazuh-agent-4.9.2-1.pkg -target /

# Charger et démarrer le service
sudo /Library/Ossec/bin/wazuh-control start

# Vérifier le statut
sudo /Library/Ossec/bin/wazuh-control status

Enregistrement automatique des agents

Pour les déploiements à grande échelle, Wazuh supporte l'enregistrement automatique des agents avec authentification par mot de passe ou certificat :

# Sur le manager, configurer l'enregistrement automatique
# Dans /var/ossec/etc/ossec.conf (ou via le volume Docker) :

# <auth>
#   <disabled>no</disabled>
#   <port>1515</port>
#   <use_password>yes</use_password>
#   <force>
#     <enabled>yes</enabled>
#     <key_mismatch>yes</key_mismatch>
#     <disconnected_time enabled="yes">1h</disconnected_time>
#     <after_registration_time>1h</after_registration_time>
#   </force>
# </auth>

# Définir le mot de passe d'enregistrement
echo "MonMotDePasseAgent2025!" > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
chown root:wazuh /var/ossec/etc/authd.pass

# Sur l'agent, s'enregistrer avec le mot de passe
/var/ossec/bin/agent-auth -m 192.168.1.100 -P "MonMotDePasseAgent2025!"

Fonctionnalités clés de Wazuh

1. Détection d'intrusion (IDS)

Le moteur de détection de Wazuh analyse en temps réel les logs et événements à l'aide de règles de détection. Wazuh inclut plus de 4 000 règles prédéfinies couvrant :

• Tentatives de connexion échouées (brute force SSH, RDP, etc.).
• Élévation de privilèges suspecte.
• Modifications de fichiers système critiques.
• Installation de logiciels non autorisés.
• Activité réseau anormale.
• Comportements caractéristiques de malwares et ransomwares.

# Exemple de règle de détection : Brute force SSH
# Fichier : /var/ossec/etc/rules/local_rules.xml

<group name="local,sshd,">
  <rule id="100001" level="10" frequency="5" timeframe="60">
    <if_matched_sid>5710</if_matched_sid>
    <description>Brute force SSH détecté : 5 tentatives échouées en 60 secondes</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>authentication_failures,brute_force,</group>
  </rule>
</group>

# Règle prédéfinie 5710 : "Attempt to login using a non-existent user"
# Notre règle 100001 se déclenche quand 5710 apparaît 5 fois en 60 secondes

2. Analyse de Logs

Wazuh collecte et analyse les logs de multiples sources :

• Logs système : syslog, journald, Windows Event Log, macOS logs.
• Logs d'applications : Apache, Nginx, MySQL, PostgreSQL, Docker, Kubernetes.
• Logs de sécurité : audit logs Linux, Windows Security logs, firewall logs.
• Logs cloud : AWS CloudTrail, Azure Activity Log, Google Cloud Audit, Office 365.
• Logs réseau : Suricata, Snort, Zeek (Bro), pfSense, OPNsense.

# Configuration de la collecte de logs dans ossec.conf

# Surveiller les logs syslog
# <localfile>
#   <log_format>syslog</log_format>
#   <location>/var/log/syslog</location>
# </localfile>

# Surveiller les logs Nginx
# <localfile>
#   <log_format>syslog</log_format>
#   <location>/var/log/nginx/access.log</location>
# </localfile>

# <localfile>
#   <log_format>syslog</log_format>
#   <location>/var/log/nginx/error.log</location>
# </localfile>

# Surveiller les logs Docker
# <localfile>
#   <log_format>json</log_format>
#   <location>/var/lib/docker/containers/*/*.log</location>
# </localfile>

# Collecter les logs via syslog distant (port 514)
# <remote>
#   <connection>syslog</connection>
#   <port>514</port>
#   <protocol>udp</protocol>
#   <allowed-ips>192.168.1.0/24</allowed-ips>
# </remote>

3. File Integrity Monitoring (FIM)

Le FIM surveille les modifications, créations et suppressions de fichiers sur le système. Essentiel pour détecter les modifications non autorisées sur les fichiers de configuration, les binaires système ou les fichiers web.

# Configuration FIM dans ossec.conf

# <syscheck>
#   <disabled>no</disabled>
#   <frequency>300</frequency>  <!-- Scan toutes les 5 minutes -->
#   <scan_on_start>yes</scan_on_start>
#
#   <!-- Répertoires à surveiller -->
#   <directories check_all="yes" realtime="yes" report_changes="yes">/etc</directories>
#   <directories check_all="yes" realtime="yes" report_changes="yes">/usr/bin</directories>
#   <directories check_all="yes" realtime="yes" report_changes="yes">/usr/sbin</directories>
#   <directories check_all="yes" realtime="yes" report_changes="yes">/var/www</directories>
#   <directories check_all="yes" realtime="yes">/boot</directories>
#
#   <!-- Fichiers à ignorer -->
#   <ignore>/etc/mtab</ignore>
#   <ignore>/etc/hosts.deny</ignore>
#   <ignore>/etc/adjtime</ignore>
#   <ignore type="sregex">.log$|.swp$</ignore>
#
#   <!-- Surveillance Windows -->
#   <directories check_all="yes" realtime="yes">%WINDIR%\System32</directories>
#   <directories check_all="yes" realtime="yes">%WINDIR%\SysWOW64</directories>
#   <directories check_all="yes" realtime="yes">%PROGRAMFILES%</directories>
#
#   <!-- Surveillance du registre 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>
# </syscheck>

4. Vulnerability Detection

Wazuh détecte automatiquement les vulnérabilités connues (CVE) sur vos systèmes en comparant l'inventaire des logiciels installés avec les bases de données de vulnérabilités (NVD, Red Hat, Canonical, Microsoft).

# Activer la détection de vulnérabilités dans ossec.conf

# <vulnerability-detection>
#   <enabled>yes</enabled>
#   <index-status>yes</index-status>
#   <feed-update-interval>60m</feed-update-interval>
# </vulnerability-detection>

# <indexer>
#   <enabled>yes</enabled>
#   <hosts>
#     <host>https://wazuh.indexer:9200</host>
#   </hosts>
# </indexer>

# Le dashboard affichera automatiquement :
# - Liste des CVE détectées par agent
# - Score CVSS et sévérité
# - Logiciels affectés et versions
# - Recommandations de correction

5. Compliance : PCI-DSS, GDPR, HIPAA

Wazuh intègre des modules de conformité qui mappent automatiquement les alertes aux exigences réglementaires :

• PCI-DSS : Payment Card Industry Data Security Standard (commerce électronique, paiements).
• GDPR : Règlement Général sur la Protection des Données (données personnelles en Europe).
• HIPAA : Health Insurance Portability and Accountability Act (données de santé aux États-Unis).
• NIST 800-53 : Framework de cybersécurité du NIST.
• TSC (SOC 2) : Trust Services Criteria.
• CIS Benchmarks : Center for Internet Security configuration standards.

Le dashboard Wazuh propose des vues dédiées pour chaque framework de conformité, avec le statut de chaque contrôle et les actions correctives nécessaires.

6. Active Response

L'Active Response permet à Wazuh de réagir automatiquement aux menaces détectées. C'est la composante "Response" du XDR.

# Configuration de l'Active Response dans ossec.conf

# Bloquer une IP après détection de brute force
# <active-response>
#   <command>firewall-drop</command>
#   <location>local</location>
#   <rules_id>100001</rules_id>
#   <timeout>3600</timeout>  <!-- Bloquer pendant 1 heure -->
# </active-response>

# Commandes d'active response disponibles par défaut :
# - firewall-drop : bloque l'IP avec iptables/Windows Firewall
# - host-deny : ajoute l'IP dans /etc/hosts.deny
# - disable-account : désactive le compte utilisateur
# - restart-wazuh : redémarre l'agent Wazuh

# Créer une commande personnalisée
# <command>
#   <name>slack-notification</name>
#   <executable>slack-notify.sh</executable>
#   <timeout_allowed>no</timeout_allowed>
# </command>

# Script personnalisé /var/ossec/active-response/bin/slack-notify.sh
#!/bin/bash
ALERT_FILE=$1
WEBHOOK_URL="https://hooks.slack.com/services/xxx/yyy/zzz"
ALERT=$(cat "$ALERT_FILE" | jq -r '.parameters.alert.rule.description')
curl -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"🚨 Alerte Wazuh: $ALERT\"}" \
  "$WEBHOOK_URL"

Règles et Décodeurs personnalisés

La personnalisation des règles et décodeurs est ce qui transforme Wazuh d'un outil générique en une solution adaptée à votre environnement spécifique.

Comprendre les décodeurs

Les décodeurs extraient les champs pertinents des logs bruts. Wazuh inclut des centaines de décodeurs pour les formats de logs courants, mais vous pouvez créer les vôtres pour des applications custom.

# Exemple de décodeur personnalisé pour une application custom
# Fichier : /var/ossec/etc/decoders/local_decoder.xml

<decoder name="mon-app">
  <program_name>mon-app</program_name>
</decoder>

<decoder name="mon-app-login">
  <parent>mon-app</parent>
  <regex>Login (failed|success) for user (\S+) from (\S+)</regex>
  <order>status, user, srcip</order>
</decoder>

<decoder name="mon-app-error">
  <parent>mon-app</parent>
  <regex>ERROR \[(\S+)\] (.+)</regex>
  <order>module, message</order>
</decoder>

Créer des règles personnalisées

# Fichier : /var/ossec/etc/rules/local_rules.xml

<group name="mon-app,">

  <!-- Règle de base pour mon application -->
  <rule id="100100" level="0">
    <decoded_as>mon-app</decoded_as>
    <description>Événement de mon-app</description>
  </rule>

  <!-- Connexion réussie -->
  <rule id="100101" level="3">
    <if_sid>100100</if_sid>
    <match>Login success</match>
    <description>Mon-app : Connexion réussie de $(user) depuis $(srcip)</description>
    <group>authentication_success,</group>
  </rule>

  <!-- Connexion échouée -->
  <rule id="100102" level="5">
    <if_sid>100100</if_sid>
    <match>Login failed</match>
    <description>Mon-app : Échec de connexion pour $(user) depuis $(srcip)</description>
    <group>authentication_failures,</group>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

  <!-- Brute force sur mon application -->
  <rule id="100103" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100102</if_matched_sid>
    <same_source_ip />
    <description>Mon-app : Brute force détecté - 5 échecs de connexion en 2 minutes depuis $(srcip)</description>
    <group>authentication_failures,brute_force,</group>
    <mitre>
      <id>T1110.001</id>
    </mitre>
  </rule>

  <!-- Connexion depuis un pays suspect (nécessite GeoIP) -->
  <rule id="100104" level="8">
    <if_sid>100101</if_sid>
    <list field="srcip" lookup="address_match_key">etc/lists/suspicious-countries</list>
    <description>Mon-app : Connexion depuis un pays suspect par $(user) depuis $(srcip)</description>
    <group>authentication_success,suspicious_login,</group>
  </rule>

  <!-- Connexion admin en dehors des heures de bureau -->
  <rule id="100105" level="8">
    <if_sid>100101</if_sid>
    <match>admin</match>
    <time>8pm - 6am</time>
    <description>Mon-app : Connexion admin en dehors des heures de bureau</description>
    <group>authentication_success,after_hours,</group>
  </rule>

</group>

Niveaux de sévérité des règles

# Tester une règle avec l'outil de test intégré
/var/ossec/bin/wazuh-logtest

# Puis collez un log pour voir comment il est décodé et quelle règle se déclenche
# Exemple :
# Mar 07 14:23:15 web-server mon-app: Login failed for user admin from 203.0.113.42

# Sortie attendue :
# **Phase 1: Completed pre-decoding.
# **Phase 2: Completed decoding.
#   name: 'mon-app-login'
#   status: 'failed'
#   user: 'admin'
#   srcip: '203.0.113.42'
# **Phase 3: Completed filtering (rules).
#   id: '100102'
#   level: '5'
#   description: 'Mon-app : Échec de connexion pour admin depuis 203.0.113.42'

Intégration avec ELK et OpenSearch

Bien que Wazuh inclue son propre indexer basé sur OpenSearch, il peut s'intégrer avec des stacks existantes :

Intégration avec Elastic Stack (ELK)

Si vous disposez déjà d'un cluster Elasticsearch/Kibana, vous pouvez configurer Wazuh pour y envoyer ses alertes :

# Configuration Filebeat sur le Wazuh Manager
# /etc/filebeat/filebeat.yml

filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true
    archives:
      enabled: false

output.elasticsearch:
  hosts: ["https://elasticsearch.example.com:9200"]
  username: "elastic"
  password: "votre-mot-de-passe"
  ssl.certificate_authorities:
    - /etc/filebeat/certs/ca.pem
  index: "wazuh-alerts-4.x-%{+yyyy.MM.dd}"

setup.template.name: "wazuh"
setup.template.pattern: "wazuh-alerts-4.x-*"
setup.ilm.enabled: false

Plugin Wazuh pour Kibana

Si vous utilisez Kibana, Wazuh fournit un plugin dédié qui ajoute des dashboards et des fonctionnalités Wazuh directement dans l'interface Kibana. Cela vous permet d'avoir une interface unifiée pour vos logs applicatifs (ELK) et vos alertes de sécurité (Wazuh).

Alerting : Email, Slack et Webhooks

Notifications par email

# Configuration email dans ossec.conf

# <global>
#   <email_notification>yes</email_notification>
#   <smtp_server>smtp.gmail.com</smtp_server>
#   <email_from>wazuh-alerts@votredomaine.fr</email_from>
#   <email_to>security-team@votredomaine.fr</email_to>
#   <email_maxperhour>12</email_maxperhour>
# </global>

# Alertes email granulaires
# <email_alerts>
#   <email_to>admin@votredomaine.fr</email_to>
#   <level>10</level>
#   <group>authentication_failures,brute_force</group>
#   <do_not_delay />
# </email_alerts>

Intégration Slack

# Configuration de l'intégration Slack dans ossec.conf

# <integration>
#   <name>slack</name>
#   <hook_url>https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX</hook_url>
#   <level>8</level>
#   <alert_format>json</alert_format>
# </integration>

# Intégration avec filtrage par groupe de règles
# <integration>
#   <name>slack</name>
#   <hook_url>https://hooks.slack.com/services/xxx/yyy/zzz</hook_url>
#   <level>10</level>
#   <group>brute_force,rootkit,vulnerability-detector</group>
#   <alert_format>json</alert_format>
# </integration>

Webhooks personnalisés

# Intégration webhook générique (compatible avec n8n, Zapier, etc.)

# <integration>
#   <name>custom-webhook</name>
#   <hook_url>https://n8n.votredomaine.fr/webhook/wazuh-alerts</hook_url>
#   <level>7</level>
#   <alert_format>json</alert_format>
# </integration>

# Le payload JSON envoyé contient :
# {
#   "timestamp": "2025-03-07T14:23:15.000+0000",
#   "rule": {
#     "level": 10,
#     "description": "Brute force SSH détecté",
#     "id": "100001",
#     "mitre": { "id": ["T1110.001"], "tactic": ["Credential Access"] }
#   },
#   "agent": { "id": "001", "name": "web-server", "ip": "192.168.1.10" },
#   "data": { "srcip": "203.0.113.42", "srcuser": "root" }
# }

Intégration VirusTotal

# Scanner automatiquement les fichiers suspects avec VirusTotal

# <integration>
#   <name>virustotal</name>
#   <api_key>VOTRE_CLE_API_VIRUSTOTAL</api_key>
#   <group>syscheck</group>
#   <alert_format>json</alert_format>
# </integration>

# Quand le FIM détecte un nouveau fichier ou une modification,
# Wazuh envoie automatiquement le hash du fichier à VirusTotal
# et crée une alerte si le fichier est détecté comme malveillant.

Cas d'usage SOC (Security Operations Center)

Scénario 1 : Détection de compromission de serveur web

Un attaquant exploite une vulnérabilité dans une application web et obtient un reverse shell. Voici comment Wazuh détecte cette chaîne d'attaque :

1. FIM : détecte la création d'un fichier PHP suspect dans /var/www/html/ (webshell).
2. Log analysis : détecte des requêtes HTTP suspectes vers le fichier créé.
3. Rootcheck : détecte un processus shell lancé par l'utilisateur www-data (anormal).
4. Syscollector : détecte l'installation d'outils suspects (netcat, nmap).
5. Active Response : bloque automatiquement l'IP source et isole le processus suspect.

Scénario 2 : Ransomware

1. FIM : détecte un nombre anormalement élevé de modifications de fichiers en peu de temps.
2. Règle personnalisée : alerte quand plus de 100 fichiers sont modifiés en moins de 60 secondes.
3. Active Response : arrête le processus responsable et isole la machine du réseau.
4. Notification : alerte immédiate via Slack et email à l'équipe SOC.

# Règle de détection de ransomware (modifications massives de fichiers)

<rule id="100200" level="14" frequency="100" timeframe="60">
  <if_matched_group>syscheck_file_modified</if_matched_group>
  <description>ALERTE CRITIQUE : Possible ransomware - modifications massives de fichiers détectées (100+ en 60 secondes)</description>
  <mitre>
    <id>T1486</id>
  </mitre>
  <group>ransomware,critical,</group>
</rule>

Scénario 3 : Exfiltration de données

1. Network monitoring : détecte un volume inhabituel de données sortantes depuis un serveur de base de données.
2. Log analysis : corrèle avec des requêtes SQL anormales (SELECT * FROM users, exports massifs).
3. Active Response : alerte et possibilité de couper la connexion réseau suspecte.

Scénario 4 : Mouvement latéral

1. Agent Windows : détecte l'utilisation de PsExec ou WMI pour se connecter à d'autres machines.
2. Corrélation : un même utilisateur se connecte à 5+ machines en quelques minutes.
3. MITRE ATT&CK : mapped sur T1021 (Remote Services) et T1570 (Lateral Tool Transfer).

Dashboard et Visualisations

Le dashboard Wazuh fournit des vues prédéfinies pour chaque module :

Vues principales

• Security Events : vue globale de tous les événements de sécurité avec filtres par agent, niveau, groupe de règles.
• Integrity Monitoring : fichiers modifiés, créés, supprimés avec détails et timeline.
• Vulnerability Detection : CVE détectées par agent, avec scores CVSS, statut de correction.
• MITRE ATT&CK : mapping des alertes sur la matrice MITRE ATT&CK avec couverture tactique.
• Compliance : vues dédiées PCI-DSS, GDPR, HIPAA, NIST 800-53 avec statut de conformité.
• Agent Overview : statut de tous les agents, dernière activité, OS, version.

Créer des visualisations personnalisées

Le dashboard Wazuh étant basé sur OpenSearch Dashboards, vous pouvez créer des visualisations personnalisées :

• Pie charts : répartition des alertes par niveau de sévérité.
• Bar charts : top 10 des agents avec le plus d'alertes.
• Line charts : tendance des alertes dans le temps.
• Tables : détail des dernières alertes critiques.
• Maps : géolocalisation des sources d'attaque (avec GeoIP).
• Heatmaps : activité par heure et jour de la semaine.

Performance et Sizing

Recommandations de dimensionnement

Optimisation des performances

# 1. Optimiser la mémoire JVM de l'indexer
# Dans docker-compose.yml, ajustez OPENSEARCH_JAVA_OPTS
# Règle : 50% de la RAM disponible, max 32 Go
OPENSEARCH_JAVA_OPTS: "-Xms4g -Xmx4g"  # Pour 8 Go de RAM

# 2. Configurer la rotation des index
# Les index Wazuh grossissent rapidement, configurez l'ISM (Index State Management)
# Dashboard → Index Management → Index Policies

# Exemple de politique ISM :
# - Hot : 0-7 jours (SSD rapide, réplicas)
# - Warm : 7-30 jours (stockage standard, pas de réplicas)
# - Cold : 30-90 jours (compressé, lecture seule)
# - Delete : > 90 jours (suppression automatique)

# 3. Filtrer les logs inutiles côté agent
# Dans la configuration de l'agent, excluez les logs verbeux non pertinents
# <localfile>
#   <log_format>syslog</log_format>
#   <location>/var/log/syslog</location>
#   <exclude>CRON|systemd-timesyncd</exclude>
# </localfile>

# 4. Limiter la fréquence du FIM
# Par défaut, le scan complet a lieu toutes les 12h
# Le mode realtime est plus efficace mais consomme des inotify watches
echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf
sysctl -p

# 5. Monitorer les performances de Wazuh
# Vérifier les statistiques du manager
/var/ossec/bin/wazuh-analysisd -t
/var/ossec/bin/agent_control -ls

# Vérifier la santé du cluster indexer
curl -k -u admin:password https://localhost:9200/_cluster/health?pretty
curl -k -u admin:password https://localhost:9200/_cat/indices?v

Comparaison avec les alternatives

Wazuh vs Splunk

Splunk est le leader incontesté du marché SIEM enterprise, mais son coût est prohibitif pour la plupart des organisations. La licence Splunk est basée sur le volume de données indexées par jour, ce qui peut rapidement atteindre des centaines de milliers d'euros par an. Wazuh offre des fonctionnalités comparables (et même supérieures sur certains aspects comme le HIDS et le FIM) pour un coût nul en licences.

Wazuh vs ELK Stack

Le stack ELK (Elasticsearch, Logstash, Kibana) est excellent pour la collecte et l'analyse de logs, mais il n'est pas un SIEM à proprement parler. Il manque les règles de détection de sécurité, les agents endpoint, le FIM, la détection de vulnérabilités et l'active response. Wazuh utilise d'ailleurs OpenSearch (fork d'Elasticsearch) comme backend et ajoute toutes ces couches de sécurité. Les deux solutions sont complémentaires.

Wazuh vs Graylog

Graylog est un bon outil de gestion de logs avec des fonctionnalités SIEM basiques. Cependant, il n'offre pas d'agents endpoint, de FIM, de détection de vulnérabilités ni d'active response. Pour un usage purement SIEM de centralisation et analyse de logs, Graylog est une alternative valide. Pour une solution de sécurité complète, Wazuh est nettement plus complet.

Bonnes pratiques de déploiement

Architecture recommandée

• Séparez les composants : en production, déployez le Manager, l'Indexer et le Dashboard sur des serveurs distincts ou au minimum des conteneurs avec des ressources dédiées.
• Cluster d'indexeurs : utilisez au minimum 3 nœuds indexer pour la réplication des données et la haute disponibilité.
• Réseau dédié : isolez le trafic Wazuh (agents → manager, manager → indexer) sur un réseau séparé ou un VLAN dédié.
• Accès restreint : limitez l'accès au dashboard aux IP du SOC via un reverse proxy avec authentification.

Sécurisation de Wazuh

# 1. Changer tous les mots de passe par défaut
# Utilisez le script officiel
/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --change-all

# 2. Configurer le TLS entre tous les composants
# Les certificats doivent être générés pour chaque composant
# Manager, Indexer et Dashboard communiquent en TLS

# 3. Restreindre l'accès API
# Dans ossec.conf, limitez les IPs autorisées pour l'API
# <api>
#   <bind_addr>0.0.0.0</bind_addr>
#   <port>55000</port>
#   <https>yes</https>
#   <access>
#     <allow>192.168.1.0/24</allow>
#   </access>
# </api>

# 4. Activer l'audit de l'API Wazuh
# Chaque appel API est journalisé pour la traçabilité

# 5. Sauvegarder régulièrement
# Manager : /var/ossec/etc/ (configuration, règles, décodeurs)
# Indexer : snapshots OpenSearch vers S3 ou NFS
# Dashboard : export des objets sauvegardés (dashboards, visualisations)

Maintenance continue

• Mises à jour régulières : suivez les releases de Wazuh et appliquez les mises à jour de sécurité. Wazuh publie des mises à jour mineures fréquentes et des versions majeures annuelles.
• Revue des règles : examinez régulièrement les faux positifs et affinez vos règles personnalisées.
• Rotation des logs : configurez la politique de rétention des index pour équilibrer visibilité historique et espace disque.
• Tests de détection : effectuez régulièrement des exercices de red team pour valider que vos règles détectent les attaques.
• Documentation : documentez vos règles personnalisées, vos playbooks de réponse aux incidents et vos procédures d'escalade.

API REST Wazuh

Wazuh expose une API REST complète pour l'automatisation et l'intégration avec vos outils existants :

# Authentification et obtention d'un token JWT
TOKEN=$(curl -s -u wazuh-wui:MyS3cr3tP4ssw0rd -k \
  -X POST https://localhost:55000/security/user/authenticate?raw=true)

# Lister tous les agents
curl -s -k -X GET \
  -H "Authorization: Bearer $TOKEN" \
  https://localhost:55000/agents?pretty=true

# Obtenir les détails d'un agent
curl -s -k -X GET \
  -H "Authorization: Bearer $TOKEN" \
  https://localhost:55000/agents/001?pretty=true

# Lister les alertes récentes
curl -s -k -X GET \
  -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/alerts?pretty=true&limit=10&sort=-timestamp"

# Obtenir les vulnérabilités d'un agent
curl -s -k -X GET \
  -H "Authorization: Bearer $TOKEN" \
  https://localhost:55000/vulnerability/001?pretty=true

# Redémarrer un agent à distance
curl -s -k -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  https://localhost:55000/agents/001/restart?pretty=true

# Obtenir les statistiques du manager
curl -s -k -X GET \
  -H "Authorization: Bearer $TOKEN" \
  https://localhost:55000/manager/stats?pretty=true

Intégration avec le framework MITRE ATT&CK

Wazuh mappe nativement ses règles de détection sur le framework MITRE ATT&CK, le standard de l'industrie pour décrire les techniques d'attaque. Le dashboard affiche une matrice ATT&CK interactive montrant votre couverture de détection par tactique et technique.

Tactiques couvertes par défaut

• Initial Access (T1190, T1133) : exploitation de services, accès distants.
• Execution (T1059, T1053) : exécution de scripts, tâches planifiées.
• Persistence (T1053, T1098) : tâches planifiées, manipulation de comptes.
• Privilege Escalation (T1068, T1548) : exploitation de vulnérabilités, abus de mécanismes d'élévation.
• Defense Evasion (T1070, T1562) : suppression de logs, désactivation de sécurité.
• Credential Access (T1110, T1003) : brute force, dumping de credentials.
• Discovery (T1082, T1083) : découverte du système, des fichiers.
• Lateral Movement (T1021) : services distants (SSH, RDP, SMB).
• Collection (T1005) : collecte de données locales.
• Exfiltration (T1041) : exfiltration via canal C2.
• Impact (T1486, T1489) : ransomware, arrêt de services.

Ajouter des tags MITRE à vos règles

# Exemple de règle avec mapping MITRE ATT&CK

<rule id="100300" level="12">
  <if_sid>5715</if_sid>
  <srcip>!192.168.1.0/24</srcip>
  <description>Connexion SSH réussie depuis une IP externe - possible accès initial</description>
  <mitre>
    <id>T1078</id>        <!-- Valid Accounts -->
    <id>T1133</id>        <!-- External Remote Services -->
  </mitre>
  <group>initial_access,external_login,</group>
</rule>

Déploiement dans le cloud et Kubernetes

Wazuh et les environnements cloud

Wazuh s'intègre nativement avec les principaux fournisseurs cloud :

• AWS : collecte des logs CloudTrail, VPC Flow Logs, GuardDuty, WAF, S3 access logs.
• Azure : collecte des Activity Logs, Azure AD logs, NSG Flow Logs.
• Google Cloud : collecte des Audit Logs, VPC Flow Logs.

# Configuration pour la collecte de logs AWS CloudTrail
# Dans ossec.conf du manager :

# <wodle name="aws-s3">
#   <disabled>no</disabled>
#   <interval>5m</interval>
#   <run_on_start>yes</run_on_start>
#   <bucket type="cloudtrail">
#     <name>mon-bucket-cloudtrail</name>
#     <access_key>AKIAIOSFODNN7EXAMPLE</access_key>
#     <secret_key>wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY</secret_key>
#     <region>eu-west-1</region>
#   </bucket>
# </wodle>

Wazuh dans Kubernetes

Pour les environnements Kubernetes, Wazuh fournit un Helm chart officiel et peut surveiller les clusters Kubernetes :

# Déployer Wazuh dans Kubernetes avec Helm
helm repo add wazuh https://wazuh.github.io/wazuh-helm/
helm repo update

# Installer le stack complet
helm install wazuh wazuh/wazuh \
  --namespace wazuh \
  --create-namespace \
  --set wazuh-manager.replicas=1 \
  --set wazuh-indexer.replicas=3 \
  --set wazuh-dashboard.replicas=1

# Surveiller les événements Kubernetes
# Wazuh peut collecter les audit logs de l'API server Kubernetes
# pour détecter les activités suspectes dans le cluster

Conclusion : Wazuh, la cybersécurité accessible à tous

Wazuh a démocratisé la cybersécurité défensive. Ce qui nécessitait autrefois des budgets de plusieurs centaines de milliers d'euros en licences Splunk ou QRadar est désormais accessible gratuitement avec une solution open-source mature, complète et activement maintenue.

Les points forts qui font de Wazuh un choix incontournable en 2025-2026 :

• Solution tout-en-un : SIEM + XDR + HIDS + FIM + Vulnerability Detection + Compliance, le tout dans une seule plateforme.
• Agents multi-plateformes : surveillance unifiée de Linux, Windows et macOS.
• Règles de détection riches : plus de 4 000 règles prédéfinies avec mapping MITRE ATT&CK, extensibles à l'infini.
• Active Response : capacité de réponse automatique aux menaces, pas seulement de détection.
• Compliance intégrée : conformité PCI-DSS, GDPR, HIPAA, NIST prête à l'emploi.
• Scalabilité : du homelab avec 5 agents au SOC d'entreprise avec des milliers d'endpoints.
• Communauté et support : une communauté massive et un support commercial disponible.

Pour commencer, un simple docker compose up -d suffit à déployer un SIEM complet. Installez les agents sur vos serveurs, configurez vos règles personnalisées, et vous disposerez d'une visibilité de sécurité que beaucoup d'entreprises n'ont pas, même avec des budgets conséquents.

La sécurité n'est pas une option, c'est une nécessité. Et grâce à Wazuh, elle n'a plus besoin d'être un luxe.