Pourquoi déployer Wazuh sur votre VPS
Un serveur Linux expose continuellement des signaux de sécurité : tentatives de connexion SSH, modifications de fichiers système, escalades de privilèges, processus inhabituels. Ces événements vivent dans des logs épars — /var/log/auth.log, les journaux de vos conteneurs, les logs applicatifs — que personne ne corrèle. Un SIEM (Security Information and Event Management) est précisément l'outil qui centralise ces flux, les analyse et fait remonter les incidents.
Wazuh est aujourd'hui la référence open source dans ce domaine. Son architecture repose sur un manager (cerveau de la détection) qui reçoit les données d'agents légers installés sur chacun de vos serveurs. Le manager embarque un moteur de corrélation de règles, un module d'intégrité de fichiers (FIM), un module de détection de vulnérabilités et des tableaux de bord de conformité réglementaire prêts à l'emploi.
Contrairement à Datadog SIEM ou Elastic SIEM en mode cloud, Wazuh ne vous facture pas à l'ingestion et vos données restent dans votre infrastructure. C'est l'approche à privilégier dès que vous gérez plusieurs serveurs et que vous devez justifier votre posture de sécurité — pour un audit, pour un client, ou simplement pour savoir ce qui se passe réellement.
Ce que Wazuh apporte concrètement sur votre infrastructure
- Centralisation des logs de tous vos serveurs Linux sur un seul tableau de bord : plus de connexion SSH de machine en machine pour lire
auth.log. - Détection d'intrusion basée sur les règles : tentatives de brute-force, escalades de privilèges, modifications de fichiers critiques — avec corrélation multi-sources.
- File Integrity Monitoring (FIM) en temps réel : toute modification de
/etc/passwd,/etc/sudoersou de vos binaires système déclenche une alerte immédiate. - Règles de conformité PCI-DSS, HIPAA, GDPR et NIST SP 800-53 intégrées dans le jeu de règles par défaut — chaque alerte est automatiquement taggée avec les contrôles réglementaires qu'elle touche.
- Détection de vulnérabilités active : Wazuh interroge les bases CVE et identifie les paquets installés exposés à des CVE connues.
- Complémentarité avec CrowdSec et Fail2ban : Wazuh corrèle et archive pour la conformité, CrowdSec agit au périmètre — les deux outils se renforcent sans se dupliquer.
- Aucun coût d'ingestion : vous gardez l'historique aussi longtemps que votre disque le permet.
Prérequis chiffrés avant de commencer
Le déploiement single-node Wazuh (manager + indexer + dashboard dans trois conteneurs Docker) est plus gourmand qu'un simple agent de monitoring. Voici les minima réalistes pour un usage de production.
Pour le manager (nœud central) :
- 4 vCPU minimum, 8 vCPU recommandés pour un parc de 10 serveurs ou plus.
- 8 Go de RAM minimum pour le nœud single-node (manager + indexer + dashboard). Comptez 16 Go si vous indexez un volume élevé d'événements ou si vous gérez plus de 50 agents.
- 50 Go de disque SSD minimum ; 100 Go ou plus si vous conservez un historique de 90 jours sur plusieurs serveurs.
- Ubuntu 22.04 LTS ou Debian 12, à jour.
- Docker Engine 24.0+ et Docker Compose v2 installés.
- Un nom de domaine pour exposer le dashboard Wazuh en HTTPS via un reverse proxy.
Pour chaque agent (sur vos autres serveurs) :
- L'agent Wazuh est très léger : moins de 64 Mo de RAM et moins de 1 % de CPU en régime normal.
- Compatible Linux (Debian, Ubuntu, AlmaLinux, Rocky), Windows et macOS.
Ports réseau à ouvrir sur le manager :
- 1514/UDP et 1514/TCP : communication agent → manager.
- 1515/TCP : enregistrement des agents.
- 55000/TCP : API REST Wazuh (accès local uniquement, ne pas exposer publiquement).
- 9200/TCP et 9300/TCP : Wazuh Indexer (usage interne entre conteneurs).
- 443/TCP : Wazuh Dashboard via votre reverse proxy.
Déployer Wazuh avec Docker Compose : procédure complète
Préparer le serveur et installer Docker
Mettez à jour le système, puis installez Docker Engine et Docker Compose v2 via le dépôt officiel Docker :
apt-get update && apt-get upgrade -y curl -fsSL https://get.docker.com | sh docker --version && docker compose versionVérifiez que Docker Compose v2 répond bien (commande
docker compose, sans tiret). Activez Docker au démarrage :systemctl enable --now docker.Cloner le dépôt officiel Wazuh Docker
Wazuh publie ses fichiers Docker Compose officiels dans le dépôt
wazuh/wazuh-docker. Clonez la branche correspondant à la version stable courante (v4.14.x au moment de cet article) :git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.8 --depth 1 cd wazuh-docker/single-nodeLe dossier
single-nodecontient ledocker-compose.ymlprécâblé avec les trois services :wazuh.manager,wazuh.indexeretwazuh.dashboard.Générer les certificats TLS inter-composants
Wazuh exige des certificats TLS pour la communication entre le manager, l'indexer et le dashboard. Le dépôt fournit un fichier Compose dédié à leur génération :
docker compose -f generate-indexer-certs.yml run --rm generatorLes certificats sont écrits dans
config/wazuh_indexer_ssl_certs/. Cette étape est requise une seule fois ; en cas de renouvellement, relancez la commande puis redémarrez le stack.Démarrer le stack Wazuh
Lancez les trois conteneurs en arrière-plan :
docker compose up -dLe premier démarrage télécharge les images officielles (environ 2 Go au total) et initialise l'indexer. Attendez 60 à 90 secondes, puis vérifiez que les trois services sont
healthy:docker compose psSi
wazuh.indexerreste enstartingau-delà de 3 minutes, consultez ses logs :docker compose logs wazuh.indexer | tail -50.Changer le mot de passe par défaut du dashboard
L'identifiant par défaut du dashboard Wazuh est
admin/SecretPassword. Changez-le immédiatement via l'API de l'indexer OpenSearch :docker compose exec wazuh.indexer curl -sk -X PUT \ https://localhost:9200/_plugins/_security/api/account \ -u admin:SecretPassword \ -H 'Content-Type: application/json' \ -d '{"password": "VotreNouveauMotDePasse", "current_password": "SecretPassword"}'Puis mettez à jour la variable
DASHBOARD_PASSWORDdansdocker-compose.ymlet relancezdocker compose up -dpour que le dashboard utilise le nouveau mot de passe.Exposer le dashboard via un reverse proxy HTTPS
Ne pas exposer le dashboard directement sur le port 443 sans reverse proxy. Avec nginx, créez un vhost qui proxifie vers
https://127.0.0.1:5601(le port interne du dashboard) en désactivant la vérification du certificat auto-signé côté upstream :server { listen 443 ssl; server_name wazuh.votre-domaine.com; location / { proxy_pass https://127.0.0.1:5601; proxy_ssl_verify off; } }Renouvelez votre certificat Let's Encrypt avec Certbot (
certbot --nginx -d wazuh.votre-domaine.com). N'exposez pas les ports 9200, 55000 ou 1514/1515 publiquement — seul le port 1514-1515 doit être ouvert pour les agents, et uniquement en provenance de vos propres serveurs.Installer et enregistrer un agent sur un serveur distant
Sur chaque serveur Linux que vous souhaitez surveiller, installez l'agent Wazuh en pointant vers l'IP ou le nom DNS de votre manager. Sur Ubuntu/Debian :
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \ --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \ chmod 644 /usr/share/keyrings/wazuh.gpg echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \ tee /etc/apt/sources.list.d/wazuh.list apt-get update && apt-get install -y wazuh-agentConfigurez l'adresse du manager dans
/var/ossec/etc/ossec.conf(balise<address>), puis démarrez et activez l'agent :systemctl daemon-reload systemctl enable wazuh-agent systemctl start wazuh-agentL'agent apparaît dans le dashboard sous Agents dans les 30 secondes qui suivent.
Configuration post-installation : agents, règles et dashboards de conformité
Une fois le stack opérationnel et vos premiers agents connectés, trois ajustements améliorent significativement la pertinence des alertes.
Activer la surveillance de l'intégrité des fichiers (FIM). Dans la configuration de l'agent (/var/ossec/etc/ossec.conf), ajoutez les répertoires sensibles dans la section <syscheck> :
<syscheck>
<frequency>43200</frequency>
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/var/www</directories>
</syscheck>Chaque modification dans ces répertoires déclenche une alerte de niveau 7 ou plus.
Explorer les dashboards de conformité. Dans le dashboard Wazuh, la section Modules expose des vues précâblées pour PCI-DSS, HIPAA, GDPR et NIST SP 800-53. Chaque alerte hérite automatiquement des tags réglementaires définis dans les règles XML du manager — par exemple, une tentative d'élévation de privilèges tague simultanément PCI-DSS 10.2.5 et HIPAA 164.312(b).
Personnaliser le niveau d'alerte. Le seuil d'alerte par défaut est 3. Pour ne recevoir que les alertes significatives, éditez /var/ossec/etc/ossec.conf sur le manager et remontez le seuil à 7 dans la section <alerts> :
<alerts>
<log_alert_level>7</log_alert_level>
<email_alert_level>9</email_alert_level>
</alerts>Relancez le manager après toute modification : docker compose restart wazuh.manager.
Durcissement du déploiement
Quelques réglages réduisent la surface d'attaque du manager lui-même.
Isolez le manager sur son propre VPS ou, au minimum, derrière un pare-feu qui n'ouvre les ports 1514-1515 qu'aux IP de vos agents — jamais à 0.0.0.0. Sur un VPS ServOrbit, l'option administration VPS vous donne accès à ufw préconfigurée : ufw allow from <IP_AGENT> to any port 1514 proto tcp.
Activez l'authentification mutuelle TLS entre agents et manager en générant des certificats d'agent signés par votre CA interne plutôt qu'en utilisant l'enregistrement automatique (ossec-authd). La documentation officielle Wazuh détaille la procédure sous « Agent enrollment via the Wazuh manager API ».
Chiffrez les volumes Docker qui contiennent l'index OpenSearch et les configurations — en particulier si vous hébergez le manager sur un VPS partagé. Un dump de l'indexer contient l'intégralité de vos logs de sécurité.
Surveillez le manager lui-même : installez un agent Wazuh sur le VPS qui fait tourner le manager pour détecter toute modification des images Docker ou des fichiers de configuration.
Dépannage : les erreurs courantes
Voici les cinq problèmes les plus fréquents lors d'un déploiement Wazuh Docker, avec les messages exacts et les corrections.
1. max virtual memory areas vm.max_map_count [65530] is too low
L'indexer OpenSearch exige au moins 262144. Ajoutez cette ligne dans /etc/sysctl.conf sur le hôte (pas dans le conteneur) : vm.max_map_count=262144, puis appliquez avec sysctl -p. C'est l'erreur la plus fréquente sur un VPS vierge.
2. wazuh.indexer reste en état starting indéfiniment
Vérifiez d'abord les logs (docker compose logs wazuh.indexer). Si vous voyez bootstrap checks failed, c'est presque toujours vm.max_map_count (voir ci-dessus) ou un manque de RAM. Si vous voyez certificate not found, les certificats n'ont pas été générés correctement — relancez docker compose -f generate-indexer-certs.yml run --rm generator.
3. L'agent apparaît Disconnected dans le dashboard
Vérifiez que le port 1514 est ouvert en entrée sur le manager et que l'adresse du manager est correctement renseignée dans /var/ossec/etc/ossec.conf de l'agent. Testez la connectivité depuis l'agent : nc -zv <IP_MANAGER> 1514. Si la connexion échoue, vérifiez votre pare-feu (ufw status, règles CSF).
4. ERROR: [agent_auth] Unable to create ssl context
L'agent ne peut pas valider le certificat TLS du manager. Vérifiez que le fichier ossec.cfg de l'agent pointe bien sur l'adresse DNS et non l'IP brute si vous utilisez un certificat nommé. Alternativement, désactivez la vérification de certificat côté agent en phase de test : balise <verify_host>no</verify_host> dans la configuration d'enregistrement (à ne pas laisser en production).
5. Too many open files dans les logs du manager
Augmentez les limites nofile sur l'hôte. Dans /etc/security/limits.conf : * soft nofile 65536 et * hard nofile 65536. Dans le docker-compose.yml, ajoutez ulimits: nofile: soft: 65536 hard: 65536 au service wazuh.manager, puis relancez.
Wazuh dans votre stack de sécurité
Wazuh n'est pas un outil isolé : il est le plus efficace quand il s'intègre à ce que vous avez déjà déployé. Associé à CrowdSec (qui bannit les IPs au niveau réseau), il couvre à la fois le périmètre et la profondeur système. Associé à Fail2ban, il lui apporte la corrélation et l'archivage réglementaire que Fail2ban ne peut pas produire seul. Et si vous avez déjà une stack Grafana + Prometheus, Wazuh complète l'observabilité système par une couche de sécurité : Prometheus vous dit que le CPU est à 90 %, Wazuh vous dit pourquoi — et si c'est une tentative de cryptominage.
Le hardening de votre serveur (checklist de durcissement Linux sur VPS) définit une posture statique. Wazuh est la surveillance continue qui vérifie que cette posture tient dans le temps — que personne n'a modifié /etc/sudoers, que vos binaires système n'ont pas été remplacés, que les événements d'authentification restent dans les plages normales.
Pour héberger votre manager Wazuh sur une infrastructure dont vous contrôlez le niveau de sécurité, consultez comment ServOrbit structure la sécurité de son infrastructure et choisissez le VPS adapté à votre parc d'agents.
