Pourquoi Wazuh pour répondre à NIS2 art. 21
L'article 21 de NIS2 impose quatre capacités : la journalisation des événements, la détection des incidents, la réponse et la notification. Wazuh couvre les trois premières nativement — collecte de logs, règles de détection, réponse active — et son tableau de bord produit les rapports d'audit nécessaires à la quatrième. Contrairement à un SIEM SaaS, les données restent sur votre infrastructure : aucun transfert vers des serveurs tiers, ce qui simplifie aussi la conformité RGPD pour les entités traitant des données personnelles. La version 4.14.8 (publiée le 25 septembre 2026) est la version stable actuelle ; elle regroupe le manager Wazuh, l'indexeur (moteur de recherche basé sur OpenSearch) et le tableau de bord dans un seul stack Docker Compose.
Wazuh vs alternatives SIEM self-hosted
Faites défiler le tableau
| Outil | Licence | Stack déploiement | Couverture NIS2 art. 21 |
|---|---|---|---|
| Wazuh 4.14 | GPLv2 (manager) / Apache 2 (indexer) | Docker Compose officiel | Journalisation + détection + réponse active |
| Elastic SIEM | SSPL (Elastic Stack) | Docker ou packages | Journalisation + détection (réponse via SOAR externe) |
| Graylog Open | SSPL | Docker Compose | Journalisation (détection limitée sans plugins) |
| Security Onion | GPLv2 | ISO bare-metal ou VM | Complet mais nécessite un serveur dédié |
Prérequis matériels et logiciels
Les prérequis officiels pour un déploiement single-node couvrant jusqu'à 25 agents sont : 4 vCPU, 8 Go de RAM et 50 Go de stockage (pour 90 jours de données indexées). Un VPS de gamme intermédiaire suffit pour une équipe jusqu'à 25 postes ou serveurs surveillés ; au-delà de 50 agents, passez à 8 vCPU et envisagez un volume supplémentaire. Côté logiciel, vous avez besoin de Docker Engine (version 24 minimum), Docker Compose v2, et Git. Le noyau Linux doit autoriser au moins 262 144 zones mémoire virtuelles pour l'indexeur — sans quoi le service refuse de démarrer.
Ce que Wazuh surveille dès l'activation des agents
- Intégrité des fichiers (FIM) — détecte toute modification, création ou suppression sur les chemins critiques (
/etc,/bin,/usr/binpar défaut) - Journaux système — collecte et indexe les logs d'authentification, syslog, journald et les logs applicatifs configurés
- Évaluation de la configuration (SCA) — compare l'état réel du système aux benchmarks CIS pour Ubuntu, Debian, RHEL et Windows
- Détection de rootkits — analyse les processus cachés et les anomalies du noyau via
rootcheck - Vulnérabilités — corrèle les paquets installés sur les agents avec les CVE de la National Vulnerability Database
- Réponse active — bloque automatiquement une IP après N tentatives d'authentification échouées, sans agent SOAR tiers
- Logs cloud — ingère les events AWS CloudTrail, Azure Activity Log et GCP Audit Log via des modules dédiés
Déploiement pas à pas sur un VPS Debian/Ubuntu
Préparer le système
Mettez à jour les paquets et installez les dépendances :
apt update && apt upgrade -y apt install -y docker.io docker-compose-v2 git curl systemctl enable --now dockerAjoutez votre utilisateur non-root au groupe docker si nécessaire :
usermod -aG docker $USERConfigurer vm.max_map_count
L'indexeur Wazuh (OpenSearch) exige au moins 262 144 zones de mémoire virtuelle. Appliquez le paramètre à chaud et rendez-le permanent :
sysctl -w vm.max_map_count=262144 echo 'vm.max_map_count=262144' >> /etc/sysctl.confSans cette étape, le conteneur
wazuh.indexers'arrête avec l'erreurmax virtual memory areas vm.max_map_count [65530] is too low.Cloner le dépôt officiel
Clonez la branche correspondant à la version stable actuelle :
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.8 cd wazuh-docker/single-node/Le répertoire
single-node/contient ledocker-compose.ymlprincipal et legenerate-indexer-certs.ymlnécessaire à l'étape suivante.Générer les certificats TLS inter-services
Wazuh chiffre toutes les communications internes (manager → indexer → dashboard). Générez les certificats avec l'utilitaire fourni :
docker compose -f generate-indexer-certs.yml run --rm generatorLes certificats sont déposés dans
config/wazuh_indexer_ssl_certs/. Ne les régénérez pas sans recréer le stack entier — les certificats sont signés mutuellement.Démarrer le stack
Lancez les trois services en arrière-plan :
docker compose up -dSuivez le démarrage en temps réel :
docker compose logs -fL'indexeur a besoin d'environ 60 secondes pour être prêt. Attendez la ligne
Node 'node-1' initializedavant de continuer.Accéder au tableau de bord et changer le mot de passe
Ouvrez
https://IP-DU-VPSdans votre navigateur. Acceptez l'avertissement de certificat auto-signé pour la première connexion. Identifiants par défaut : utilisateuradmin, mot de passeSecretPassword. Changez immédiatement le mot de passe via Security → Internal users → admin → Edit. Pour une automatisation en ligne de commande :docker exec -it single-node-wazuh.manager-1 \ /var/ossec/bin/wazuh-passwords-tool.sh \ -u admin -p 'NouveauMotDePasse!'Ouvrir les ports firewall nécessaires
Sur le VPS, autorisez le trafic entrant pour les agents et le tableau de bord :
ufw allow 443/tcp # Dashboard HTTPS ufw allow 1514/tcp # Agents (protocole Wazuh) ufw allow 1515/tcp # Enregistrement des agents ufw allow 514/udp # Réception syslog ufw allow 55000/tcp # API REST Wazuh (restreindre à vos IP) ufw enableRestreignez le port 55000 à vos IP de gestion uniquement (
ufw allow from 203.0.113.10 to any port 55000).Installer l'agent Wazuh sur un serveur à surveiller
Sur chaque machine à observer, installez l'agent et pointez-le vers votre VPS. Exemple sur 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" \ > /etc/apt/sources.list.d/wazuh.list apt update && apt install -y wazuh-agent WAZUH_MANAGER='IP-DE-VOTRE-VPS' \ WAZUH_AGENT_NAME='votre-serveur-01' \ dpkg-reconfigure wazuh-agent systemctl enable --now wazuh-agentL'agent apparaît dans le tableau de bord sous Agents dans les 30 secondes suivant son enregistrement.
Maillage — aller plus loin
Pour renforcer votre posture de sécurité au-delà de Wazuh, consultez nos guides connexes : [nis2-securite-informatique-hebergement-obligations] pour les obligations légales détaillées, [crowdsec-vs-fail2ban-securite-vps] pour le blocage collaboratif en amont au niveau réseau, et [zitadel-sso-self-hosted-vps] pour centraliser l'authentification et réduire la surface d'attaque sur votre tableau de bord Wazuh.
Architecture du stack single-node
Le stack Docker Compose officiel déploie trois services interdépendants. Le manager Wazuh est le cœur : il reçoit les événements des agents via le port 1514, applique les règles de détection, déclenche les réponses actives et transmet les alertes à l'indexeur. L'indexeur Wazuh (OpenSearch) stocke et rend ces alertes interrogeables ; il communique avec le manager sur le port 9200 et nécessite les ressources noyau spécifiques au moteur de recherche. Le tableau de bord Wazuh expose l'interface utilisateur sur le port 443 et interroge l'indexeur en HTTPS. Les trois services partagent des certificats TLS autosignés générés à l'étape de préparation ; modifier l'un sans régénérer les autres provoque des erreurs de validation mutuelle. Les données persistantes — configuration du manager, queue d'alertes, données d'index — sont stockées dans des volumes Docker nommés, séparés du cycle de vie des conteneurs : une mise à jour par remplacement d'image ne perd pas l'historique.
Configurer la rétention et les alertes email
Par défaut, Wazuh conserve les données 90 jours. Pour ajuster la rétention, modifiez le paramètre max_age dans le fichier de politique ISM de l'indexeur, accessible via Index Management → Policies dans le tableau de bord. Vous pouvez par exemple porter la rétention à 180 jours pour répondre aux exigences NIS2 de conservation des journaux, ou la réduire à 30 jours sur un VPS au stockage limité. Pour les alertes email, éditez /var/ossec/etc/ossec.conf dans le conteneur manager — ajoutez un bloc <email_notification> avec votre serveur SMTP et les niveaux d'alerte souhaités (niveau 7 et au-dessus est un bon point de départ pour les alertes critiques, niveau 5 pour inclure les alertes moyennes). Wazuh peut aussi envoyer des notifications via des webhooks vers Slack, Teams ou PagerDuty grâce à son mécanisme d'intégration. Redémarrez le manager après chaque modification de configuration :
docker compose restart wazuh.managerGénérer des rapports de conformité NIS2 / GDPR
Le tableau de bord Wazuh inclut des tableaux dédiés aux frameworks de conformité : GDPR, PCI DSS, HIPAA et NIST 800-53. Ces tableaux permettent d'exporter des rapports PDF listant les contrôles couverts et les événements associés — utiles pour justifier votre posture auprès d'un auditeur ou d'une autorité compétente NIS2. Pour NIS2 spécifiquement, utilisez la vue GDPR comme base (les obligations de journalisation et de détection se recoupent largement) et complétez avec les règles de détection d'incidents classées par catégorie Mitre ATT&CK disponibles sous Threat intelligence → Mitre ATT&CK. NIS2 imposant une notification dans les 72 heures suivant la détection d'un incident significatif, configurez des alertes de niveau 12 (critique) pour déclencher immédiatement une notification — Wazuh inclut des règles prêtes à l'emploi pour les tentatives d'exploitation de CVE connues, les mouvements latéraux et les escalades de privilèges. La vue d'ensemble Security events filtrée par agent fournit le contexte chronologique nécessaire pour rédiger la notification réglementaire.
Activez la politique de mots de passe forts dans Wazuh dès l'installation : sous Security → Security settings, cochez 'Require complex passwords' et 'Enable audit logging'. Ces deux options sont désactivées par défaut et doivent être activées manuellement avant la mise en production.
Mettre à jour Wazuh sans perdre les données
Les données de l'indexeur sont persistées dans des volumes Docker nommés. La procédure de mise à jour consiste à cloner la nouvelle version du dépôt dans un répertoire séparé, à copier les volumes existants, puis à redémarrer le stack. La documentation officielle recommande une sauvegarde des volumes avant toute mise à jour majeure :
docker run --rm \
-v single-node_wazuh-indexer-data:/data \
-v $(pwd)/backup:/backup \
alpine tar czf /backup/indexer-data-$(date +%Y%m%d).tar.gz /dataPour une mise à jour de version mineure (ex. 4.14.7 → 4.14.8), il suffit de mettre à jour le tag dans le docker-compose.yml et de relancer avec docker compose up -d --pull always.
Dépannage — erreurs courantes
Voici les cinq erreurs les plus fréquentes lors d'un premier déploiement Wazuh Docker, avec leurs causes et remèdes.
Erreurs fréquentes et remèdes
max virtual memory areas vm.max_map_count [65530] is too low— Le paramètre noyau n'a pas été appliqué. Exécutezsysctl -w vm.max_map_count=262144et vérifiez avecsysctl vm.max_map_countavant de relancer le stack.Connection refusedsur le port 443 aprèsdocker compose up -d— L'indexeur n'est pas encore prêt. Attendez 60 à 90 secondes et consultezdocker compose logs wazuh.indexerpour confirmer l'initialisation du nœud.Agent disconnecteddès l'enregistrement — Le port 1514/TCP ou 1515/TCP est bloqué côté VPS. Vérifiezufw statuset les règles de sécurité réseau de votre hébergeur (groupes de sécurité cloud).certificate verify faileddans les logs du dashboard — Les certificats auto-générés ne correspondent pas à l'IP ou au hostname utilisé. Régénérez les certificats (docker compose -f generate-indexer-certs.yml run --rm generator) après avoir vérifié queWAZUH_DASHBOARD_HOSTdans ledocker-compose.ymlcorrespond à votre IP ou nom de domaine.Wazuh API 401 Unauthorized— Le changement de mot de passeadminn'a pas été propagé à la configuration du dashboard. Après modification du mot de passe, mettez également à jourDASHBOARD_PASSWORDdans le fichier.envou dans les variables d'environnement du servicewazuh.dashboard, puis redémarrez avecdocker compose restart wazuh.dashboard.
