Déployer Wazuh sur VPS Hetzner : tutoriel complet 2026

📍 Article principal de la série : Wazuh 2026 : guide pratique.

Une heure pour installer Wazuh complet : Manager + OpenSearch + Dashboard sur Hetzner CCX23. Méthode validée chez plusieurs PME francophones.

Prérequis

• Hetzner CCX23 minimum (4 vCPU, 16 Go RAM, 160 Go NVMe).
• Ubuntu 22.04 LTS ou Debian 12.
• Domaine DNS : siem.votre-entreprise.com.
• Niveau attendu : avancé.
• Temps estimé : 60-90 minutes.

Wazuh (SIEM open-source basé sur OpenSearch) demande des ressources sérieuses. VPS Hetzner CX42 minimum (8 vCPU, 16 Go RAM, 240 Go SSD) pour 50-100 agents. CPX52 (16 Go RAM) pour 100-500 agents. Linux Ubuntu 22.04 ou Debian 12 fraîchement installé. Un domaine wazuh.example.sn avec DNS A. Comptez 2-3 heures pour cette installation initiale, puis 4-8 heures de tuning des règles avant déploiement à grande échelle.

Étape 1 — Installation all-in-one

curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
bash ./wazuh-install.sh -a -i

L’installer déploie Wazuh Manager + Indexer (OpenSearch) + Dashboard avec certificats auto-signés. Comptez 15-20 minutes.

Wazuh fournit un script all-in-one qui installe Manager, Indexer (OpenSearch) et Dashboard sur un seul serveur. Téléchargez : curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh && sudo bash wazuh-install.sh -a. Le script télécharge ~3-4 Go (OpenSearch est gourmand) et configure les services. L’installation prend 10-20 minutes selon la bande passante. Sortie attendue : URLs et credentials affichés à la fin du script.

Étape 2 — Récupérer credentials admin

tar -xvf wazuh-install-files.tar
cat wazuh-install-files/wazuh-passwords.txt
# Note password admin pour Dashboard

Le script génère un fichier wazuh-passwords.txt avec les mots de passe admin de chaque service (admin, kibanaserver, wazuh, etc.). Sauvegardez immédiatement ce fichier dans Bitwarden ou 1Password. Conservez aussi /etc/wazuh-indexer/certs/ qui contient les certificats internes nécessaires si vous ajoutez des nodes secondaires. Sans ces credentials, vous ne pouvez ni vous connecter au dashboard ni ajouter des agents.

Étape 3 — Accéder au Dashboard

Ouvrir https://siem.votre-entreprise.com:443. Login : admin / password copié. Dashboard charge en 30 secondes.

Ouvrez https://VOTRE_IP:443 dans le navigateur. Acceptez le certificat self-signed temporairement (l’étape 4 le remplacera par Let’s Encrypt). Connectez-vous avec admin et le mot de passe du fichier wazuh-passwords.txt. Le dashboard Wazuh s’affiche : 0 agents, 0 alerts au démarrage. Naviguez les sections Security Events, Vulnerabilities, MITRE ATT&CK pour comprendre l’organisation. Cette première exploration prend 15-30 minutes.

Étape 4 — Remplacer certificat self-signed par Let’s Encrypt

Caddy en façade pour HTTPS public propre :

siem.votre-entreprise.com {
  reverse_proxy https://localhost:443 {
    transport http {
      tls_insecure_skip_verify
    }
  }
}

Pour les utilisateurs externes (auditeurs, équipe distribuée), le certificat self-signed crée des warnings inutiles. Configurez Caddy ou Nginx en frontend qui termine le TLS avec Let’s Encrypt. Caddyfile minimal : wazuh.example.sn { reverse_proxy 127.0.0.1:443 { transport http { tls_insecure_skip_verify } } }. Cette double couche (Caddy avec cert valide + Wazuh avec cert interne) assure le chiffrement bout en bout sans warnings client.

Étape 5 — Vérifier services

systemctl status wazuh-manager
systemctl status wazuh-indexer
systemctl status wazuh-dashboard
# Tous doivent être active (running)

Trois services systemd Wazuh : wazuh-manager (orchestrateur), wazuh-indexer (OpenSearch), wazuh-dashboard (Kibana fork). Vérifiez avec systemctl status wazuh-manager wazuh-indexer wazuh-dashboard. Tous doivent être active (running). Si un service est en failed, consultez les logs avec journalctl -u wazuh-XXX. Erreur fréquente : OpenSearch out-of-memory si moins de 4 Go RAM disponibles, ce qui exige un upgrade VPS ou un tuning JVM heap.

Étape 6 — Allouer RAM OpenSearch

nano /etc/wazuh-indexer/jvm.options
# -Xms8g
# -Xmx8g

systemctl restart wazuh-indexer

OpenSearch alloue par défaut 1 Go de heap, suffisant pour 5-10 agents mais sous-dimensionné pour 50+. Modifiez /etc/wazuh-indexer/jvm.options.d/jvm.options : -Xms4g -Xmx4g pour 4 Go heap (allouez 50 % de la RAM totale au max). Redémarrez : systemctl restart wazuh-indexer. Vérifiez avec curl -k -u admin:PASSWORD https://localhost:9200/_cluster/health qui doit retourner status: green.

Étape 7 — Premier agent (test depuis le Manager même)

WAZUH_MANAGER='siem.votre-entreprise.com' \
  apt install -y wazuh-agent
systemctl daemon-reload
systemctl enable --now wazuh-agent

Sur le Dashboard → Agents → l’agent doit apparaître « Active ».

Pour tester sans VPS additionnel, installez l’agent Wazuh sur le même serveur que le Manager. Téléchargez le package : WAZUH_MANAGER='localhost' apt install wazuh-agent. Démarrez : systemctl enable --now wazuh-agent. Dans le dashboard, l’agent apparaît sous Management → Agents. Lancez logger 'TEST WAZUH' pour générer un événement et voir s’il remonte dans Security Events sous 1-2 minutes.

Étape 8 — Configurer alertes Slack/Mattermost

nano /var/ossec/etc/ossec.conf

<integration>
  <name>slack</name>
  <hook_url>https://chat.votre-entreprise.com/hooks/abc123</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

systemctl restart wazuh-manager

Wazuh intègre nativement plusieurs canaux d’alerting. Modifiez /var/ossec/etc/ossec.conf avec un bloc <integration><name>slack</name><hook_url>https://hooks.slack.com/services/...</hook_url><alert_format>json</alert_format></integration>. Pour Mattermost, utilisez le même format avec l’incoming webhook URL. Redémarrez wazuh-manager. Les alertes de niveau supérieur à 7 sont envoyées par défaut, ajustez via min_alert_level.

Étape 9 — Sauvegardes

# Cron quotidien
tar czf /backup/wazuh-config-$(date +%F).tar.gz \
  /var/ossec/etc /etc/wazuh-indexer /etc/wazuh-dashboard

# OpenSearch snapshot
curl -X PUT "https://localhost:9200/_snapshot/wazuh_backup" -k -u admin:PASSWORD -H 'Content-Type: application/json' -d'{"type":"fs","settings":{"location":"/backup/opensearch"}}'

Wazuh stocke trois données critiques. /var/ossec (config, règles custom, scripts) : sauvegardez via tar quotidien. /var/lib/wazuh-indexer (données OpenSearch indexées) : utilisez le snapshot OpenSearch vers S3 (Backblaze B2 ou MinIO). /etc/wazuh-* (configs et certificats) : sauvegardez via restic. Stockez hors VPS principal avec rétention 90 jours. Pour la conformité audit, certaines normes (PCI DSS, ISO 27001) exigent rétention 1 an des logs SIEM.

Erreurs fréquentes

Erreur	Cause	Solution
OpenSearch OOM	RAM heap mal allouée	jvm.options 8g min
Dashboard 502	Wazuh Indexer pas prêt	Attendre 5 min après start
Agent disconnect	Port 1514 bloqué	UFW allow 1514/tcp
Vulnerability feed manque	Internet sortant bloqué	UFW allow outbound 443
Disk plein logs	Retention pas configurée	OpenSearch ILM 30 jours

Trois choses à retenir pour le contexte local

Trois précisions. Coût : CCX23 28 €/mois pour SIEM enterprise-grade. Datacenter Falkenstein : latence acceptable depuis Afrique de l’Ouest. Audit ARTCI/CDP : exporter rapports CSV mensuels via Dashboard.

Premièrement, Wazuh consomme beaucoup de ressources : pour une PME à Cocody avec budget VPS serré, considérez d’abord CrowdSec qui couvre 60 % des cas pour 10x moins cher. Deuxièmement, le tuning des règles est crucial : sans personnalisation, vous noyez sous 1000 alertes/jour de false positives. Troisièmement, les logs Wazuh contiennent des informations sensibles (commandes exécutées, fichiers modifiés) — appliquez les mêmes contrôles d’accès que sur la production.

Tutoriels frères

• Agents multi-VPS
• FIM et vulnérabilités

Wazuh se complète bien avec d’autres outils sécurité. CrowdSec pour le blocage actif (Wazuh détecte, CrowdSec bloque). Authentik pour le SSO des admins. Restic pour les sauvegardes croisées. Mattermost pour la communication d’équipe en cas d’incident. Cette stack défense-en-profondeur transforme une infrastructure générique en environnement audité aux standards entreprise.

FAQ

Cluster multi-nodes ? Possible pour > 200 endpoints. Documentation cluster Wazuh.

Updates ? apt upgrade wazuh-manager. Lire changelog avant majeur.

Capacité 100 endpoints ? CCX23 confortable. CCX33 pour 500.

Performance impact agents ? < 100 Mo RAM, < 5% CPU.

Support paid ? Wazuh propose support à partir 2 USD/endpoint/mois.

Q : Wazuh vs Splunk vs Elastic Security ? R : Wazuh est gratuit et open-source, Splunk coûte 1500-5000 USD/Go/an, Elastic Security est freemium avec features avancées payantes. Q : Combien d’agents possibles sur un seul Manager ? R : Jusqu’à 1000 agents avec un VPS bien dimensionné. Au-delà, multi-cluster recommandé. Q : Conformité PCI DSS ? R : Wazuh fournit des templates de règles PCI prêts à l’emploi et des dashboards dédiés.

Dans la continuité

• 🔝 Retour au guide général : guide pratique Wazuh 2026
• Documentation : documentation.wazuh.com

Pourquoi Wazuh sur VPS reste pertinent en 2026

Wazuh est la plateforme SIEM open-source la plus déployée au monde, avec plus de 20 millions d’agents en production en 2026. Pour une PME ouest-africaine soucieuse de conformité (audit interne, exigences clients européens, RGPD), elle apporte détection d’intrusion, analyse de logs centralisée et conformité PCI/HIPAA sans payer Splunk ou Datadog. Le déploiement en cluster trois nœuds tient 5 000 endpoints sur des VPS modestes.

Wazuh 4.10 sortie en novembre 2025 introduit le moteur de détection vectorielle pour identifier les comportements anormaux par embeddings, et améliore l’intégration avec OpenSearch 2.18.

Étape 1 : Dimensionner les VPS du cluster

Pour 500 endpoints et 30 jours de rétention de logs, comptez : 1 nœud manager (4 vCPU, 8 Go RAM, 100 Go SSD), 3 nœuds indexer (4 vCPU, 16 Go RAM, 500 Go SSD chacun), 1 nœud dashboard (2 vCPU, 4 Go RAM, 40 Go SSD). Sur Hetzner, ça fait CCX13 manager + 3x CCX23 indexer + CX22 dashboard = environ 130 EUR par mois (85 300 FCFA).

Pour démarrer une PoC sur un seul VPS, le mode all-in-one tient 100 endpoints sur un CCX23 (8 vCPU, 32 Go RAM, 240 Go SSD à 25 EUR par mois, 16 400 FCFA). Migrer vers le cluster se fait à chaud sans perte de données.

Étape 2 : Préparer les VPS Ubuntu 24.04

Sur chaque nœud, durcissez le système et configurez le firewall. Wazuh utilise les ports 1514 (agents UDP), 1515 (enrollment TCP), 9200 (indexer), 55000 (API) et 443 (dashboard).

apt update && apt upgrade -y
apt install -y curl gnupg ufw
ufw allow 22/tcp
ufw allow 1514/udp
ufw allow 1515/tcp
ufw allow 9200/tcp
ufw allow 55000/tcp
ufw allow 443/tcp
ufw --force enable

La sortie de ufw status doit lister exactement ces ports. Si un port est absent, les agents ne pourront pas s’enregistrer ou les indexers ne se synchroniseront pas en cluster.

Étape 3 : Lancer l’installation Wazuh assistée

Wazuh fournit un script Bash qui automatise le déploiement complet. Pour un test all-in-one sur un VPS unique, utilisez la commande officielle.

curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
bash ./wazuh-install.sh -a

Le script installe l’indexer, le manager et le dashboard en une fois. Comptez 10 à 15 minutes selon la latence du VPS. À la fin, le mot de passe admin du dashboard est affiché — copiez-le immédiatement, il n’est pas resauvegardé en clair.

Étape 4 : Configurer un cluster trois nœuds

Pour la production, le cluster trois nœuds élimine le SPOF et tient une charge bien supérieure. Téléchargez d’abord le fichier de configuration et adaptez-le à vos noms de domaine.

curl -sO https://packages.wazuh.com/4.10/config.yml
nano config.yml
# Modifier : noms d'hôtes (wazuh-indexer-1, -2, -3), IPs Tailscale ou privées

Lancez ensuite le générateur de certificats : bash wazuh-certs-tool.sh -A. Les certificats sont créés dans wazuh-certificates/. Copiez-les sur chaque nœud avant de lancer l’installation par composant.

Étape 5 : Installer les indexers (cluster OpenSearch)

Sur chaque nœud indexer, copiez les certificats et lancez l’installation avec le flag indexer.

# Sur indexer-1
bash wazuh-install.sh -wi wazuh-indexer-1
# Sur indexer-2
bash wazuh-install.sh -wi wazuh-indexer-2
# Sur indexer-3
bash wazuh-install.sh -wi wazuh-indexer-3
# Initialiser le cluster une seule fois depuis n'importe quel indexer
bash wazuh-install.sh -s

La sortie doit indiquer « Cluster initialization completed » avec les trois nœuds en état « started ». Si un nœud reste en « yellow », vérifiez la résolution DNS entre indexers — souvent un fichier /etc/hosts incomplet.

Étape 6 : Installer le manager et configurer le filebeat

Le nœud manager reçoit les événements des agents et les pousse vers les indexers via Filebeat.

# Sur manager-1
bash wazuh-install.sh -wm wazuh-manager-1

Une fois installé, vérifiez que Filebeat est connecté aux indexers : filebeat test output doit afficher « OK » pour les trois nœuds. Si un test échoue, c’est généralement un certificat mal copié — relisez le chemin /etc/filebeat/certs/.

Étape 7 : Installer le dashboard

Le dashboard est l’interface web (basée sur OpenSearch Dashboards) qui présente alertes, agents et tableaux de bord.

# Sur dashboard-1
bash wazuh-install.sh -wd wazuh-dashboard-1

Au bout de 5 minutes, https://dashboard.acme.sn affiche la page de login. Connectez-vous avec admin et le mot de passe affiché à l’étape 3. Le tableau Overview doit afficher zéro agent — normal, on les ajoute à l’étape suivante.

Étape 8 : Enregistrer le premier agent Linux

Sur un serveur web Ubuntu à monitorer, installez l’agent et pointez-le vers le manager.

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 update
WAZUH_MANAGER='manager.acme.sn' apt install -y wazuh-agent
systemctl enable --now wazuh-agent

Au bout d’une minute, l’agent apparaît dans Wazuh dashboard → Agents avec statut « Active ». Si « Disconnected », vérifiez le firewall sur le port 1514/udp et la résolution DNS du manager. La commande tail -f /var/ossec/logs/ossec.log sur l’agent affiche les éventuelles erreurs.

Étape 9 : Activer les règles de détection MITRE ATT&CK

Wazuh inclut nativement des règles mappées sur le framework MITRE ATT&CK. Activez les modules les plus utiles : File Integrity Monitoring (FIM), Vulnerability Detection, et Security Configuration Assessment (SCA).

# Sur le manager, dans /var/ossec/etc/ossec.conf
<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
</syscheck>
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
</vulnerability-detection>

Redémarrez le manager : systemctl restart wazuh-manager. Les premières alertes FIM remontent dans les minutes qui suivent dès qu’un fichier surveillé est modifié. Le scan de vulnérabilités CVE prend une à deux heures pour la première passe.

Étape 10 : Configurer des alertes Slack et email

Wazuh route les alertes vers des intégrations externes via le module wazuh-integratord. Pour Slack, créez d’abord un Incoming Webhook dans Slack admin.

# Dans /var/ossec/etc/ossec.conf du manager
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/T.../B.../...</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Niveau 10 = alertes critiques (failed authentication multiple, bruteforce SSH, malware détecté). Pour les alertes de niveau 7-9, utilisez plutôt l’email afin de ne pas saturer Slack. Testez en simulant une attaque : for i in $(seq 1 10); do ssh fakeuser@server-monitored; done — l’alerte Slack tombe en moins d’une minute.

Pour creuser : Zitadel SSO self-hosted et Tailscale pour relier les agents en mesh.

Étape 11 : Déployer un agent sur Windows 11

Wazuh fournit un MSI signé pour Windows. Téléchargez et installez en ligne de commande pour automatiser le déploiement sur 50 postes via GPO ou Intune.

msiexec.exe /i wazuh-agent-4.10.0-1.msi /q WAZUH_MANAGER="manager.acme.sn" WAZUH_AGENT_GROUP="windows-workstations"
NET START Wazuh

Vérifiez dans le dashboard que l’agent apparaît avec OS Windows et statut Active. Les règles spécifiques Windows (sysmon, windows event logs, AppLocker) sont chargées automatiquement quand l’agent est dans le groupe windows-workstations.

Étape 12 : Activer la détection de vulnérabilités CVE

Le module Vulnerability Detection croise l’inventaire logiciel des agents avec la base CVE/NVD. Pour qu’il soit utile, il faut un inventaire complet et des feeds CVE à jour.

# Vérifier le statut du module
/var/ossec/bin/wazuh-control status | grep vulnerability
# Forcer un scan immédiat sur un agent
/var/ossec/bin/agent_control -R 001

Le scan complet d’un parc de 500 endpoints prend 2 à 4 heures. Les résultats apparaissent dans Vulnerability Detection → Inventory. Triez par sévérité critique pour identifier en priorité les CVE exploitées dans la nature (KEV catalog du CISA).

Étape 13 : Sauvegarder les configurations Wazuh

Trois choses à sauvegarder : la configuration manager (/var/ossec/etc/), la config indexer (/etc/wazuh-indexer/), et les snapshots OpenSearch (rétention indexée).

cat > /usr/local/bin/wazuh-backup.sh <<'EOF'
#!/bin/bash
DATE=$(date +%Y%m%d)
tar czf /backup/wazuh-config-$DATE.tar.gz /var/ossec/etc/ /etc/wazuh-indexer/
curl -X PUT -k -u admin:adminpass "https://localhost:9200/_snapshot/backup_repo/snap-$DATE?wait_for_completion=false"
find /backup -name "wazuh-*.tar.gz" -mtime +30 -delete
EOF
chmod +x /usr/local/bin/wazuh-backup.sh
echo "0 2 * * * /usr/local/bin/wazuh-backup.sh" | crontab -

Le snapshot OpenSearch capture l’état complet des indexes alertes/inventaires à la nuit. Restauration en cas de désastre : curl -X POST .../_snapshot/backup_repo/snap-XXX/_restore et redémarrage du cluster. Testez la procédure complète une fois par trimestre.

Étape 14 : Coût total annuel pour 500 endpoints

Cluster Wazuh trois nœuds sur Hetzner : environ 130 EUR par mois (1 560 EUR par an, 1 023 200 FCFA). Storage Box backup 1 To : 8 EUR par mois (52 480 FCFA par an). Domaine + certificats : 12 000 FCFA par an. Total annuel : environ 1 087 000 FCFA pour protéger 500 endpoints.

Comparé à Splunk Enterprise (environ 2 500 USD par Go par an, soit 16 400 000 FCFA/Go), Wazuh est gratuit logiciel. Comparé à un SOC managé externe (typiquement 4 à 8 USD par endpoint par mois, soit 15 700 000 à 31 500 000 FCFA par an pour 500 endpoints), l’économie est massive si vous avez en interne un ingénieur capable d’opérer Wazuh.

Étape 15 : Tester la chaîne d’alerte de bout en bout

Avant de mettre en production, simulez une intrusion contrôlée pour valider que la chaîne détection → alerte → notification fonctionne. Lancez Atomic Red Team ou simplement un script d’attaque basique.

# Simulation bruteforce SSH depuis une machine externe
for i in $(seq 1 20); do
  sshpass -p 'wrong' ssh -o StrictHostKeyChecking=no fakeuser@server-monitored
done
# Simulation modification fichier critique
echo "test" > /etc/passwd.test
mv /etc/passwd.test /etc/passwd_backup_test

En moins de deux minutes, vous devez recevoir une alerte Slack pour le bruteforce (rule 5712, level 10) et une alerte FIM pour la modification dans /etc. Si rien n’arrive, parcourez les logs du manager : tail -f /var/ossec/logs/alerts/alerts.log. La cause la plus fréquente est un niveau d’alerte trop élevé dans la config integration.

Étape 16 : Maintenance trimestrielle

Tous les trois mois, exécutez ces tâches pour garder l’instance saine : 1) mise à jour Wazuh vers la dernière mineure (4.10.x → 4.11.x), 2) vérification de l’espace disque sur les indexers (purger les indexes anciens si plus de 80 pourcent), 3) test de restauration du dernier snapshot, 4) revue des règles désactivées par erreur, 5) mise à jour des feeds threat intel personnalisés. Comptez une demi-journée par trimestre. Documentez chaque action dans un journal d’exploitation pour l’audit annuel.