Wazuh SIEM tutoriel : installation et configuration open source 2026

Lecture : 16 minutes · Niveau : sysadmin / sécurité · Mise à jour : avril 2026

Wazuh est en 2026 le choix rationnel pour une PME qui veut un SIEM + XDR + HIDS sérieux à coût d’infra seul. Open-source, déployable en 10-20 minutes sur un seul VPS via script officiel, avec agents pour Windows, Linux, macOS, et intégrations natives cloud (AWS, Azure, GCP, Microsoft 365). Ce tutoriel pratique couvre l’installation single-node, le déploiement d’agents, la configuration de règles de détection, l’intégration avec d’autres outils (Suricata, VirusTotal, MISP, Slack), et les optimisations production. Toutes les commandes sont testées sur Ubuntu 22.04 / 24.04.

Pour le contexte stratégique global, voir le pillar Sécurité défensive SOC PME.

Sommaire

Architecture Wazuh
Prérequis et dimensionnement
Installation single-node Ubuntu
Première connexion dashboard
Déployer des agents (Linux, Windows, macOS)
Configuration et règles de détection
Intégrations utiles
Tuning et performance
Sauvegardes et maintenance
Pièges fréquents
FAQ

1. Architecture Wazuh

3 composants principaux.

Wazuh Server.
– Cerveau du système.
– Reçoit télémétrie agents.
– Analyse via decoders + rules.
– Génère alertes.

Wazuh Indexer (basé OpenSearch).
– Stocke événements et alertes.
– Permet recherche, queries, dashboards.
– Précédemment basé Elasticsearch.

Wazuh Dashboard (basé OpenSearch Dashboards).
– Interface web (login, dashboards, recherche, configuration).
– Précédemment Kibana.

Wazuh Agents.
– Installés sur chaque endpoint à surveiller.
– Collectent : logs, processes, file integrity, vulnerabilities, system inventory.
– Envoient au Server via TLS.

Modes de déploiement.
– Single-node (all-in-one) : tout sur un VPS. Démarrage PME, jusqu’à ~100 agents.
– Multi-node : Server + Indexer + Dashboard sur machines séparées. Pour scaling 100-1000 agents.
– Cluster : multiples Indexers et Servers pour haute disponibilité et très grands volumes.

2. Prérequis et dimensionnement

Single-node Ubuntu 22.04 / 24.04.
– 4 GB RAM minimum, 8 GB recommandé pour PME (50 agents).
– 2 vCPU minimum, 4 recommandé.
– 50 GB SSD minimum (logs accumulent).
– Connexion internet pour installation et updates.

Dimensionnement par taille PME.
| Agents | RAM | vCPU | Storage |
|——–|—–|——|———|
| 10 | 4 GB | 2 | 50 GB |
| 50 | 8 GB | 4 | 100 GB |
| 100 | 16 GB | 4 | 250 GB |
| 250 | 32 GB | 8 | 500 GB |
| 500 | 64 GB | 8 | 1 TB |

Hébergeur recommandé PME ouest-africaine.
– Hetzner CX32 (8 GB RAM, ~12 EUR/mois) : excellent pour 50 agents.
– OVH VPS Comfort (~10 EUR/mois).
– AWS Cape Town t3.large (~50-80 USD/mois) si présence Afrique souhaitée.

Réseau.
– Port 1514/UDP : agents → server (events).
– Port 1515/TCP : agents → server (registration).
– Port 55000/TCP : API Wazuh.
– Port 443/TCP : dashboard web.
– Bonnes pratiques : whitelist IPs agents, certificats TLS, pas d’exposition internet du dashboard sans VPN.

3. Installation single-node Ubuntu

Étape 1 : préparer le VPS.

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl

Étape 2 : installation via script officiel.

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

L’installation prend 10-20 minutes selon connexion. Le script déploie Server + Indexer + Dashboard + certificats TLS auto-signés.

Étape 3 : récupérer les credentials.
À la fin, le script affiche les mots de passe générés (ou les sauvegarde dans wazuh-install-files.tar).

sudo tar -axf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt -O

Notez le mot de passe admin (pour le dashboard).

Étape 4 : vérifier statut services.

sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

Tous devraient être active (running).

Étape 5 : firewall.

sudo ufw allow 22
sudo ufw allow 443    # dashboard
sudo ufw allow 1514/udp  # agents
sudo ufw allow 1515   # registration
sudo ufw allow 55000  # API
sudo ufw enable

Étape 6 : accéder au dashboard.
– Ouvrir https://VOTRE_VPS_IP dans un navigateur.
– Login : admin + mot de passe noté.
– Dashboard Wazuh apparaît.

4. Première connexion dashboard

Vue d’ensemble.
– Modules : Security Events, Integrity Monitoring, Vulnerabilities, MITRE ATT&CK, Compliance (PCI DSS, HIPAA, GDPR, NIST), etc.
– Agents : liste des endpoints surveillés.
– Discover : recherche libre dans logs.

Premier check : Security Events.
– Cliquer Security Events → Dashboard.
– Voir alertes générées par les règles default.
– Le manager génère des événements internes même sans agents.

Naviguer dans logs.
– Discover → choisir index wazuh-alerts-*.
– Filtrer par sévérité (rule.level), agent, MITRE technique.
– KQL ou Lucene queries.

Configuration utilisateurs.
– Stack Management → Security → Users.
– Créer comptes pour analystes (rôle wazuh-admin ou custom).
– Activer MFA si possible (depuis OpenSearch 2.x).

5. Déployer des agents (Linux, Windows, macOS)

Linux Ubuntu/Debian.

# Sur l'endpoint à surveiller
curl -sO https://packages.wazuh.com/4.14/wazuh-agent_4.14.5-1_amd64.deb
sudo WAZUH_MANAGER='IP_DU_SERVER' dpkg -i ./wazuh-agent_4.14.5-1_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Linux RHEL/CentOS.

sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
sudo cat > /etc/yum.repos.d/wazuh.repo <<EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF
sudo WAZUH_MANAGER='IP_DU_SERVER' yum install wazuh-agent
sudo systemctl daemon-reload && sudo systemctl enable --now wazuh-agent

Windows.
– Télécharger MSI depuis wazuh.com/install.
– Installation interactive : renseigner IP du Manager.
– Ou via PowerShell automation :

Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi" -OutFile "C:\wazuh-agent.msi"
msiexec.exe /i "C:\wazuh-agent.msi" /q WAZUH_MANAGER="IP_SERVER"
NET START WazuhSvc

macOS.
– Télécharger pkg depuis wazuh.com.
– Configuration manuelle ou script.

Vérifier registration.
– Dashboard → Agents.
– Le nouvel agent doit apparaître Active après quelques minutes.

Mass deployment.
– Ansible playbook (officiel sur GitHub Wazuh).
– Group Policy (Windows AD).
– Image base VM (cloud).

6. Configuration et règles de détection

Architecture rules Wazuh.
– Règles définies en XML.
– Rules built-in : /var/ossec/ruleset/rules/.
– Custom rules : /var/ossec/etc/rules/local_rules.xml.
– Decoders parsing logs : /var/ossec/ruleset/decoders/.
– Custom decoders : /var/ossec/etc/decoders/local_decoder.xml.

Règles built-in importantes.
– Authentication : SSH brute-force, sudo failures, Windows logon failures.
– File Integrity Monitoring (FIM) : modifications fichiers critiques.
– Rootkits / Trojans : détection signatures connues.
– Vulnerability detection : CVEs sur applications.
– MITRE ATT&CK mapping : techniques tagged.

Exemple custom rule (alerter login admin).

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

<group name="custom,authentication,">
  <rule id="100100" level="10">
    <if_sid>5715</if_sid>
    <user>admin|root</user>
    <description>Critical: privileged user login from untrusted source</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Redémarrer manager :

sudo systemctl restart wazuh-manager

File Integrity Monitoring (FIM).

Configurer dans /var/ossec/etc/ossec.conf :

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" report_changes="yes">/var/www/html</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hostname</ignore>
</syscheck>

Vulnerability detection.
Activer dans ossec.conf :

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</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>
</vulnerability-detector>

Active response (réponse automatique).

Exemple : bloquer IP après brute-force SSH.

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>600</timeout>
</active-response>

MITRE ATT&CK dashboard.
– Modules → MITRE ATT&CK.
– Visualisation tactiques détectées sur votre environnement.
– Identifier gaps de couverture.

7. Intégrations utiles

VirusTotal.
– Hash files vérifiés contre VirusTotal pour identifier malware.
– Configuration dans ossec.conf avec API key.

Suricata (NIDS).
– Suricata = network IDS, complémentaire HIDS Wazuh.
– Wazuh peut ingérer alertes Suricata pour vue holistique.

MISP (threat intelligence).
– Plateforme partage IOCs.
– Wazuh enrichit alertes avec contextes IOC.

Slack / Discord / Email notifications.
– Webhook Slack pour alertes critiques.
– Configuration via <integration> block dans ossec.conf.

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Microsoft 365 / Azure AD.
– Module dédié logs M365 et Azure AD via Graph API.
– Détection compromission comptes, exfiltration, partages anormaux.

AWS CloudTrail / GuardDuty.
– Module ingestion logs AWS pour visibilité cloud.

Cloud Native Application Protection.
– Wazuh + Falco pour containers Kubernetes.
– Détection runtime anomalies pods.

SIEM federation.
– Wazuh peut forward vers SIEM externe (Splunk, Sentinel) pour stratégies hybrides.

8. Tuning et performance

Réduire false positives.
– Premier mois : bcp de faux positifs sur certaines règles.
– Identifier dans dashboard : top rules triggered.
– Whitelist patterns connus inoffensifs (<if_matched_sid> avec ignore).
– Ajuster level rules trop bruyantes.

Performance manager.
– analysisd.queue_size à augmenter si forte volumétrie.
– logcollector.queue_size similaire.
– Monitoring via /var/ossec/var/state/manager_state.

Performance indexer.
– Vérifier RAM utilisée par OpenSearch (heap typiquement 50 % RAM).
– ILM (Index Lifecycle Management) pour rotation et purge anciens logs.
– Suppression manuelle si stockage saturé : curl -X DELETE "https://localhost:9200/wazuh-alerts-4.x-2025.01.*".

Rétention.
– Default 90 jours typique.
– Adapter selon storage et compliance (RGPD : 1-3 ans logs sécurité parfois requis).

Backup configuration.
– /var/ossec/etc/ossec.conf : config manager.
– /var/ossec/etc/rules/local_rules.xml : custom rules.
– /var/ossec/etc/decoders/local_decoder.xml : custom decoders.
– Versionner dans Git (privé).

Monitoring Wazuh.
– Module Cluster pour status interne.
– Métriques : agents actifs, events processed/sec, alertes/min.
– Alerts si manager down (Prometheus + node_exporter sur VPS Wazuh).

9. Sauvegardes et maintenance

Sauvegarde quotidienne.
– Snapshot OpenSearch indices (sauvegarde alertes) :

# Snapshot vers S3 ou disque local
curl -X PUT "https://localhost:9200/_snapshot/wazuh_backup/snapshot_1?wait_for_completion=true"

Backup /var/ossec/etc/ (configurations).
Backup chiffré, rotation 30 jours minimum.

Mises à jour Wazuh.
– Wazuh sort 1-2 versions majeures/an + patches.
– Lire changelog avant chaque update (parfois breaking changes config).
– Test sur staging si critique.

sudo apt update && sudo apt upgrade wazuh-manager wazuh-indexer wazuh-dashboard

Mises à jour agents.
– Auto-upgrade depuis manager possible.
– Sinon redéploiement script ou Group Policy.

Health checks réguliers.
– Statut services manager / indexer / dashboard hebdomadaire.
– Volume disk < 80 % usage.
– Latence requêtes dashboard correcte.
– Agents actifs vs déployés (différence = problèmes connectivité).

Documentation interne.
– Runbook : que faire si Wazuh down, agents disconnectés, alertes critiques.
– Playbook par type d’incident.
– Onboarding nouveaux analystes.

10. Pièges fréquents

Dashboard exposé internet sans VPN. Risque d’exposition. Toujours derrière VPN ou Cloudflare Access.

Pas de tuning des règles. Premier mois noyé sous false positives → désactivation Wazuh par fatigue. Tuner activement.

Pas d’agents déployés. Manager seul génère événements internes mais pas vue endpoints. Déployer agents partout.

FIM sur tout. Surveiller / cause performance désastreuse. Cibler /etc, /usr/bin, dossiers critiques applicatifs.

Pas de backup configuration. Hardware crash = recommencer from scratch. Backup /var/ossec/etc/ essentiel.

Pas de rotation logs. Storage saturé en 6 mois. ILM obligatoire.

Custom rules sans tests. Règle qui crash analysisd → pas d’alertes. Tester avec wazuh-logtest.

Pas de monitoring Wazuh lui-même. Manager down silencieusement. Heartbeat externe (UptimeRobot ping API Wazuh).

Mots de passe non changés. admin avec mot de passe initial = breach garanti. Rotation immédiate post-install.

Updates ignorées. CVEs Wazuh non patchées = vulnérabilités. Patches mensuels.

Pas de plan IR pour utiliser alertes. Wazuh détecte mais pas de processus pour traiter = sécurité théorique.

Trop d’agents pour single-node. > 200 agents sur all-in-one = saturation. Migrer multi-node.

FAQ

Wazuh est-il vraiment gratuit ?

Oui, 100 % open-source (licence GPLv2). Coût uniquement infra (VPS) et temps humain. Wazuh Cloud (managed) existe en option payante (~$571/mois pour 100 agents) mais non obligatoire. La majorité des PME en 2026 self-hostent.

Combien d’agents max pour single-node ?

Jusqu’à environ 100-200 agents avec 8-16 GB RAM. Au-delà : migrer multi-node ou cluster. Performance variable selon volume logs par endpoint.

Wazuh fonctionne-t-il sur Windows Server ?

Le manager : non, uniquement Linux (Ubuntu, RHEL, Debian). Les agents : oui, Windows Server 2012+ supportés. Architecture typique : manager sur VPS Linux, agents sur serveurs Windows et stations.

Quelle différence Wazuh vs ELK Stack ?

ELK (Elasticsearch + Logstash + Kibana) est un stack généraliste de logging. Wazuh est un SIEM complet construit sur OpenSearch (fork Elasticsearch) avec règles, agents, MITRE mapping intégrés. Pour cybersécurité PME : Wazuh prêt à l’emploi vs ELK où il faut tout construire.

Wazuh remplace-t-il un EDR commercial ?

Wazuh agents font de l’EDR (file integrity, log monitoring, vulnerability detection, behavioral analysis). Performance moindre que CrowdStrike ou SentinelOne sur détection comportementale avancée. Pour PME standard : suffit largement. Pour environnements high-risk : compléter avec EDR commercial.

Comment intégrer Wazuh à mon ticketing system ?

Via webhooks ou API custom. Exemples : intégration Jira, ServiceNow, Zendesk. Wazuh API REST permet trigger automatique sur alertes.

Wazuh respecte-t-il RGPD/CDP ?

Wazuh peut être configuré pour respecter ces normes (logs pseudonymisés si nécessaire, accès strictement contrôlé, rétention selon politique). À documenter dans DPIA. Modules compliance built-in (PCI DSS, HIPAA, GDPR, NIST 800-53) facilitent l’audit.

Combien de temps pour qu’une équipe maîtrise Wazuh ?

1 sysadmin Linux fluent : 1-2 semaines pour install et fonctionnel. 1 mois pour tuning sérieux. 3 mois pour autonomie complète (custom rules, intégrations avancées). Formation officielle Wazuh ou hands-on TryHackMe accélère.

Articles liés (cluster Sécurité défensive)

Voir aussi : Linux administration avancée PME, Linux sécurité hardening production, Pentesting outils essentiels, DevOps moderne PME guide.

Article mis à jour le 26 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.