Wazuh : un SIEM open source

Dans les articles précédents de cette série, j’ai progressivement durci mon VPS OVH : stack LEMP sécurisé, PHP 8.3 renforcé, Fail2ban actif, AIDE pour la détection d’intrusion fichiers. Tout ça c’est bien, mais ça reste de la défense passive. Il me manquait un composant essentiel : un outil capable de centraliser les événements de sécurité de toute mon infrastructure, de les corréler et de m’alerter en temps réel.

C’est le rôle d’un SIEM (Security Information and Event Management). Et dans le monde open source, Wazuh s’impose comme la référence. Dans cet article, je te détaille comment j’ai installé Wazuh sur une VM chez moi, comment j’ai déployé les agents sur mon VPS OVH et mon serveur de backup, et comment j’ai configuré la détection des attaques SSH. Un prochain article traitera du déploiement de l’agent vers une machine Windows.

L’architecture mise en place

Avant de rentrer dans le vif du sujet, voici comment s’organise mon infrastructure de supervision :

• Wazuh Manager — installé sur une VM hébergée sur mon hyperviseur à la maison. C’est le cerveau : il reçoit les événements, applique les règles de détection et génère les alertes.
• Agent 1 — installé sur le VPS OVH (Ubuntu 24.04, julien.lagni.fr). Surveille les logs système, SSH, Nginx et l’intégrité des fichiers.
• Agent 2 — installé sur le serveur de backup (VM Freebox Delta). Surveille les accès SSH et les transferts rsync.

Les agents communiquent avec le manager via le port 1514/TCP. Le manager n’est pas exposé sur Internet — les agents initient la connexion vers mon IP fixe à la maison. Le dashboard Wazuh est accessible uniquement depuis mon réseau local.

Qu’est-ce que Wazuh ?

Wazuh est une plateforme open source de sécurité qui regroupe plusieurs fonctionnalités en un seul outil :

• SIEM — collecte et corrèle les logs de toutes les machines surveillées
• XDR/EDR — surveillance des processus, fichiers et connexions réseau sur les endpoints
• File Integrity Monitoring — détection de modifications de fichiers critiques, en complément d’AIDE
• Analyse de vulnérabilités — inventaire des paquets installés et CVE associées
• Conformité — tableaux de bord PCI-DSS, RGPD, CIS Benchmarks
• Réponse active — blocage automatique d’IP sur les agents via des scripts déclenchés par alertes

L’architecture Wazuh se compose de trois éléments déployés ici sur la même VM :

• Wazuh Manager — reçoit les événements des agents, applique les règles, génère les alertes
• Wazuh Indexer — stocke les alertes (basé sur OpenSearch, le fork libre d’Elasticsearch)
• Wazuh Dashboard — interface web de visualisation et d’investigation

Prérequis pour la VM manager

Wazuh en installation complète (all-in-one) est assez gourmand en ressources. La documentation officielle recommande, pour un déploiement de 1 à 25 agents : 4 vCPU, 8 Go de RAM et 50 Go de disque. Pour mon homelab avec seulement 2 agents, j’ai pu descendre un peu en dessous, mais si tu prévois de superviser plus de machines, respecte les recommandations officielles :

• OS : Ubuntu 24.04 LTS
• RAM : 8 Go recommandés — l’indexer OpenSearch en réserve environ la moitié pour sa JVM. 4 Go peuvent suffire pour 2-3 agents en homelab, mais c’est juste.
• CPU : 4 vCPU recommandés (2 en homelab minimaliste)
• Disque : 50 Go minimum — les index grossissent selon le volume de logs
• Réseau : IP fixe sur le LAN, accès Internet pour le téléchargement des paquets

Côté réseau, les ports suivants doivent être accessibles depuis les agents vers le manager :

Port	Protocole	Usage
1514	TCP	Communication agents → manager (envoi des événements)
1515	TCP	Enregistrement automatique des agents
443	TCP	Dashboard web (accès local uniquement)

Installation de Wazuh sur la VM

Wazuh propose un script d’installation assistée qui déploie les trois composants en une seule commande. En mode all-in-one (option -a), le script configure tout automatiquement — pas besoin de fichier de configuration : le fichier config.yml qu’on croise dans certains tutoriels ne sert que pour les installations distribuées (composants sur des machines séparées).

Télécharger et lancer l’installeur

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

Prévoir 10 à 15 minutes. Le script installe et configure automatiquement les trois composants, génère les certificats TLS et crée les comptes. À la fin, il affiche les identifiants — à noter immédiatement :

INFO: --- Summary ---
INFO: You can access the web interface https://<IP_DE_LA_VM>
    User: admin
    Password: <MOT_DE_PASSE_GENERE>

Vérifier que les services tournent

sudo systemctl status wazuh-manager  | grep Active
sudo systemctl status wazuh-indexer  | grep Active
sudo systemctl status wazuh-dashboard | grep Active

Les trois doivent afficher active (running). Le dashboard est ensuite accessible depuis le réseau local sur https://192.168.1.50 (l’IP de ta VM). Wazuh utilise un certificat auto-signé par défaut — accepter l’exception de sécurité dans le navigateur.

Déploiement des agents via SCP

Pour déployer les agents, j’ai préparé un script bash pré-configuré qui automatise l’installation sur n’importe quelle machine Ubuntu ou Debian : ajout du dépôt, installation du paquet, configuration avec l’IP du manager, démarrage du service.

Pour le transfert, j’utilise SCP — simple, sécurisé, et sans rien exposer sur Internet. On pourrait imaginer héberger ce script sur un serveur web pour le rendre accessible en une ligne, mais ça présenterait un risque : le fichier contient l’IP du manager et des informations sur la topologie réseau, autant d’informations utiles pour un attaquant qui tomberait dessus. Le SCP évite complètement ce problème.

Le script wazuh-deploy.sh

Le script est disponible en téléchargement en bas de cet article. Les seules variables à adapter avant utilisation :

# Variables à adapter à son infrastructure
MANAGER_IP="192.168.1.50"       # IP LAN de ta VM Wazuh manager
MANAGER_PORT="1514"             # Port de communication
WAZUH_VERSION="4.14"            # Version majeure Wazuh
AGENT_GROUP="linux-servers"     # Groupe d'agents par défaut

Le script accepte également des paramètres en ligne de commande pour personnaliser chaque déploiement :

sudo bash wazuh-deploy.sh --name mon-serveur --group linux-servers

Déploiement sur le VPS OVH

# Depuis la machine locale, transférer le script sur le VPS
scp wazuh-deploy.sh julie@julien.lagni.fr:/tmp/

# Se connecter au VPS et exécuter le script
ssh julie@julien.lagni.fr
sudo bash /tmp/wazuh-deploy.sh --name vps-ovh --group vps

Le script affiche sa progression et confirme la connexion au manager :

==> Vérifications préalables
[OK]    Distribution : Ubuntu 24.04.2 LTS
[OK]    Manager joignable sur 192.168.1.50:1514

==> Ajout du dépôt Wazuh 4.14
[OK]    Clé GPG ajoutée
[OK]    Dépôt configuré

==> Installation de l'agent
[OK]    Agent Wazuh installé

==> Configuration de l'agent
[OK]    Configuration écrite dans /var/ossec/etc/ossec.conf
[INFO]  Agent     : vps-ovh
[INFO]  Manager   : 192.168.1.50:1514
[INFO]  Groupe    : vps

==> Démarrage de l'agent
[OK]    Service wazuh-agent démarré
[OK]    Agent connecté au manager !

============================================
  Installation terminée
============================================

Déploiement sur le serveur de backup

# Transférer le script sur le serveur de backup
scp wazuh-deploy.sh julie@192.168.1.20:/tmp/

# Exécuter avec un nom et groupe spécifiques
ssh julie@192.168.1.20
sudo bash /tmp/wazuh-deploy.sh --name backup-freebox --group backup-servers

Vérifier les agents côté manager

sudo /var/ossec/bin/agent_control -l

Wazuh agent_control. List of available agents:
   ID: 000, Name: wazuh-manager (server), IP: 127.0.0.1, Active/Local
   ID: 001, Name: vps-ovh,        IP: any, Active
   ID: 002, Name: backup-freebox, IP: any, Active

Les deux agents apparaissent avec le statut Active. Si un agent reste en Pending ou Disconnected, les causes les plus fréquentes sont :

• Le port 1514 bloqué en sortie sur la machine ou en entrée sur la box
• Un décalage d’horloge NTP entre les machines — Wazuh est sensible à ça, tous les serveurs doivent être synchronisés
• Un pare-feu local (ufw) qui bloque la connexion sortante

# Diagnostic sur l'agent
sudo tail -f /var/ossec/logs/ossec.log | grep -E "connect|error|warn"

# Vérifier la synchronisation NTP
timedatectl status | grep "NTP service"

Surveillance des connexions SSH

Avec les agents connectés, Wazuh commence immédiatement à analyser /var/log/auth.log. Les règles de détection SSH sont intégrées nativement, sans aucune configuration supplémentaire :

Rule ID	Événement détecté	Niveau
5710	Tentative avec utilisateur inexistant	5
5712	Brute-force sur utilisateurs inexistants (seuil natif : 8 tentatives en 2 min depuis la même IP)	10
5715	Connexion SSH réussie	3
5720	Multiples échecs d’authentification	10
5763	Brute-force sur échecs de mot de passe — utilisateurs existants (8 tentatives en 2 min)	10

À noter : les règles 5712 et 5763 sont complémentaires — la première cible les tentatives sur des comptes qui n’existent pas, la seconde les mots de passe erronés sur des comptes valides. Le scénario le plus critique, des échecs multiples suivis d’une connexion réussie, existe aussi nativement (règle 40112 du groupe authentication), mais je préfère le gérer avec une règle personnalisée plus stricte ci-dessous.

Ajouter des règles personnalisées

Les règles natives couvrent les cas courants, mais j’ai voulu affiner la détection avec trois règles supplémentaires. Sur le manager, éditer /var/ossec/etc/rules/local_rules.xml :

sudo nano /var/ossec/etc/rules/local_rules.xml

<group name="ssh_custom,syslog,">

  <!-- Alerte critique si connexion SSH réussie en root -->
  <!-- Root login devrait être désactivé — cette règle sert de filet de sécurité -->
  <rule id="100010" level="12">
    <if_sid>5715</if_sid>
    <match>for root</match>
    <description>Connexion SSH réussie en tant que root - vérifier immédiatement</description>
    <group>authentication_success,high_risk</group>
  </rule>

  <!-- Brute-force avec seuil abaissé à 5 tentatives en 60 secondes -->
  <!-- Plus sensible que la règle native 5712 (8 en 2 min) -->
  <rule id="100011" level="10" frequency="5" timeframe="60">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>Brute-force SSH : 5+ tentatives en 60s depuis la même IP</description>
    <group>authentication_failures,brute_force</group>
  </rule>

  <!-- Scénario critique : brute-force suivi d'une connexion réussie depuis la même IP -->
  <!-- Corrélation : l'événement courant est une connexion réussie (5715) -->
  <!-- ET la règle 100011 s'est déclenchée dans les 5 minutes précédentes -->
  <rule id="100012" level="15" frequency="1" timeframe="300">
    <if_matched_sid>100011</if_matched_sid>
    <if_sid>5715</if_sid>
    <same_source_ip />
    <description>CRITIQUE : Connexion SSH réussie après brute-force détecté</description>
    <group>authentication_success,high_risk,incident</group>
  </rule>

</group>

Recharger le manager pour appliquer les règles :

sudo systemctl restart wazuh-manager

# Vérifier l'absence d'erreur de syntaxe
sudo grep -i "error" /var/ossec/logs/ossec.log | grep -v "ssl" | tail -5

Valider les règles avec wazuh-logtest

Avant de déployer une règle en production, je la valide toujours avec wazuh-logtest. Cet outil permet de soumettre un événement fictif et de voir exactement quelle règle se déclenche, sans attendre qu’une vraie attaque se produise :

sudo /var/ossec/bin/wazuh-logtest

Coller un log SSH typique :

Dec 10 09:22:15 vps-ovh sshd[1234]: Failed password for invalid user admin from 1.2.3.4 port 45231 ssh2

Wazuh décompose l’analyse en trois phases :

**Phase 1: Completed pre-decoding.
**Phase 2: Completed decoding.
    name: 'sshd'
    srcip: '1.2.3.4'
    srcuser: 'admin'
**Phase 3: Completed filtering (rules).
    id: '5710'
    level: '5'
    description: 'sshd: Attempt to login using a non-existent user'
**Alert to be generated.

Astuce : pour tester les règles à seuil comme la 100011, colle le même log plusieurs fois de suite dans la même session logtest — le compteur firedtimes s’incrémente et tu verras la règle de corrélation prendre le relais au bon moment.

Active Response — blocage automatique des attaquants

Wazuh peut déclencher automatiquement un blocage IP sur les agents lorsqu’une règle se déclenche. Le script firewall-drop est inclus nativement — il ajoute une règle iptables sur l’agent concerné, puis la retire automatiquement après un délai configurable.

Whitelister son IP — étape indispensable avant tout

Avant d’activer le blocage automatique, whitelister impérativement son IP dans /var/ossec/etc/ossec.conf sur le manager. Sans ça, on risque de se bloquer soi-même si on rate plusieurs fois son mot de passe SSH :

<ossec_config>
  <global>
    <white_list>127.0.0.1</white_list>
    <white_list>192.168.1.0/24</white_list>  <!-- Réseau local -->
    <white_list>TON_IP_PUBLIQUE</white_list>  <!-- IP FAI -->
  </global>
  ...
</ossec_config>

Configurer le blocage automatique

<ossec_config>
  ...
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5712,100011</rules_id>
    <timeout>600</timeout>  <!-- Blocage pendant 10 minutes -->
  </active-response>
  ...
</ossec_config>

# Vérifier les blocages actifs sur le VPS
sudo iptables -L INPUT -n | grep DROP

# Suivre les actions de l'active response en temps réel
sudo tail -f /var/ossec/logs/active-responses.log

Alertes par e-mail

Wazuh peut envoyer des alertes mail pour les événements dépassant un certain niveau. Je l’ai configuré avec msmtp déjà en place sur la VM manager. Attention à la structure : les paramètres SMTP vont dans la section <global>, mais le niveau minimal de déclenchement se configure dans une section <alerts> séparée :

<ossec_config>
  <global>
    <email_notification>yes</email_notification>
    <smtp_server>localhost</smtp_server>
    <email_from>wazuh@mondomaine.fr</email_from>
    <email_to>ton@email.fr</email_to>
  </global>

  <alerts>
    <email_alert_level>10</email_alert_level>  <!-- Mail pour niveau 10 et plus -->
  </alerts>
  ...
</ossec_config>

Surveiller les alertes SSH au quotidien

Quelques commandes utiles pour le suivi depuis la VM manager :

# Alertes SSH en temps réel
sudo tail -f /var/ossec/logs/alerts/alerts.log \
  | grep -E "ssh|5710|5712|5715|100011|100012"

# Top 10 des IP attaquantes aujourd'hui
sudo grep "$(date '+%b %e')" /var/ossec/logs/alerts/alerts.log \
  | grep "5710\|5712" \
  | grep -oP 'srcip: \K[\d\.]+' \
  | sort | uniq -c | sort -rn | head -10

# Connexions réussies anormales (niveau élevé)
sudo grep "5715\|100010\|100012" /var/ossec/logs/alerts/alerts.log \
  | tail -20

Ce que ça donne en pratique

Après quelques jours de fonctionnement, le tableau de bord Wazuh est parlant. Sur le VPS, les tentatives de connexion SSH sont constantes — entre 200 et 500 par jour selon les périodes, avec des pics nocturnes caractéristiques des bots automatisés. Fail2ban bloque la plupart localement, et Wazuh me donne la vision centralisée sur l’ensemble de l’infrastructure.

Sur le serveur de backup, l’activité est beaucoup plus calme : uniquement mes connexions rsync nocturnes et quelques tentatives de scan qui ne franchissent pas le seuil d’alerte.

Le module Security Events du dashboard permet de filtrer par agent, par règle, par IP source. Pour une analyse forensique rapide, c’est incomparablement plus efficace que de fouiller les fichiers de log à la main sur chaque serveur séparément.

Conclusion et suite

Avec cette configuration, mon infrastructure dispose maintenant d’une supervision centralisée. Les événements du VPS et du serveur de backup remontent vers le manager local, les règles SSH détectent les comportements anormaux, et Fail2ban assure le blocage local en cas d’IP dynamique côté FAI.

Le script wazuh-deploy.sh disponible en téléchargement ci-dessous permet de reproduire ce déploiement sur n’importe quelle nouvelle machine Ubuntu ou Debian en quelques minutes via SCP.

Dans le prochain article, je couvrirai le déploiement de l’agent Wazuh sur une machine Windows : installation, configuration du canal Sysmon pour enrichir la télémétrie, et premières règles de détection d’attaques Windows.

---

Téléchargements

• wazuh-deploy.sh — script de déploiement automatique de l’agent Wazuh (Ubuntu/Debian)

---