Déployer un SIEM pédagogique avec Wazuh : guide de configuration pour 30 étudiants

Pourquoi Wazuh pour l'enseignement ?

Un SIEM pédagogique doit remplir une condition que les outils d'entreprise satisfont rarement : être accessible, gratuit, et suffisamment documenté pour qu'un étudiant puisse se l'approprier en quelques séances. Wazuh coche ces trois cases sans compromis majeur sur la profondeur fonctionnelle.

Wazuh est un projet open source distribué sous licence GPLv2. Son code source est public, son déploiement ne nécessite aucune clé de licence, et sa documentation officielle — disponible sur documentation.wazuh.com — couvre l'installation, la configuration des règles, les modules de conformité et l'intégration avec des outils tiers. Pour un formateur qui souhaite que ses apprenants puissent continuer à explorer l'outil après la formation, c'est un avantage décisif.

Sur le plan fonctionnel, Wazuh ne se limite pas à la collecte de logs. Sa stack intègre nativement :

• Détection d'intrusions basée sur les agents : chaque agent surveille l'intégrité des fichiers, les processus actifs et les connexions réseau de sa machine hôte.
• Analyse de vulnérabilités : le module de vulnerability detection compare les paquets installés aux bases CVE publiques (NVD, OVAL).
• Conformité : les modules CIS benchmarks, PCI DSS et HIPAA génèrent des rapports exploitables en TP.
• Réponse active : Wazuh peut déclencher des actions automatiques (blocage d'IP, exécution de scripts) en réaction à une alerte, ce qui ouvre la porte aux exercices de réponse à incident.

Cette richesse fonctionnelle n'a pas d'équivalent gratuit aussi accessible pour l'enseignement. Pour situer Wazuh dans le paysage des SIEM disponibles :

Elastic SIEM est plus flexible et la stack ELK est très présente en entreprise — c'est un argument pour l'enseigner. Mais la complexité d'une installation complète avec Elasticsearch, Logstash, Kibana et des règles de détection dépasse souvent les contraintes horaires d'un TP. Splunk, de son côté, prépare directement à l'outil qu'on retrouve dans de nombreux SOC, mais la limite de 500 Mo par jour est contraignante dès que plusieurs agents envoient des logs simultanément. Wazuh offre le meilleur compromis entre richesse fonctionnelle et facilité de déploiement pour un contexte pédagogique.

Architecture recommandée pour 30 étudiants

Un déploiement pédagogique pour une promotion de trente étudiants n'a pas besoin de la résilience d'un environnement de production. L'objectif est de fournir une plateforme stable, réinitialisable et suffisamment représentative pour que les apprenants comprennent les enjeux réels du métier d'analyste SOC.

L'architecture recommandée repose sur trois composants principaux :

En contexte pédagogique, les composants Manager, Indexer et Dashboard peuvent être installés sur une seule VM, ce que le script d'installation officiel de Wazuh fait automatiquement. Cette configuration tout-en-un suffit largement pour trente agents en TP — la fréquence d'événements en salle est sans commune mesure avec un environnement de production. C'est justement l'occasion d'expliquer aux apprenants pourquoi les déploiements en entreprise séparent ces composants sur des machines distinctes.

Réseau du lab

L'isolation réseau n'est pas strictement obligatoire dans une salle physique où les machines ne communiquent qu'entre elles, mais elle est fortement recommandée pour deux raisons : éviter que les logs des TP ne polluent ou n'interfèrent avec le réseau de l'établissement, et préparer les étudiants à la réalité des déploiements professionnels où le SIEM est toujours sur un segment d'administration dédié.

Un VLAN de gestion séparant le serveur Wazuh du reste du réseau scolaire est la solution minimale. En salle virtuelle (Proxmox ou VMware), un vSwitch interne suffit. Si les contraintes réseau ne permettent pas l'isolation, veillez au moins à ce que les ports 1514 (UDP/TCP, communication agents) et 55000 (API REST Wazuh) ne soient pas accessibles depuis le réseau général de l'établissement.

Installation pas à pas

Installation du serveur Wazuh

Wazuh fournit un script d'installation officiel qui déploie et configure automatiquement les trois composants (Manager, Indexer, Dashboard) sur une distribution Linux 64 bits (RHEL/CentOS 7-8, Ubuntu 20.04/22.04, Debian 10/11). C'est la méthode recommandée pour un environnement pédagogique : elle est reproductible, documentée et maintenue par l'équipe Wazuh.

# Télécharger le script d'installation (version 4.x)
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh

# Télécharger le fichier de configuration
curl -sO https://packages.wazuh.com/4.x/config.yml

# Lancer l'installation tout-en-un
bash wazuh-install.sh -a

L'option -a déploie tous les composants sur la même machine. À la fin de l'installation, le script affiche les identifiants d'accès au dashboard (nom d'utilisateur admin et un mot de passe généré). Conservez ces identifiants — ils seront nécessaires pour la configuration initiale et devront être transmis de façon sécurisée aux étudiants qui auront accès au dashboard.

Vérifiez ensuite que les services sont actifs :

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

Le dashboard est accessible sur https://<IP-du-serveur> (port 443 par défaut). Lors de la première connexion, le navigateur affichera un avertissement de certificat auto-signé — c'est attendu en environnement pédagogique.

Déploiement des agents étudiants

Sur une machine Linux (Debian/Ubuntu) :

La méthode la plus simple consiste à passer les variables d'environnement de configuration au moment de l'installation. Wazuh utilise ces variables pour enregistrer automatiquement l'agent auprès du Manager.

# Ajouter le dépôt Wazuh
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

# Installer l'agent et le connecter au Manager en une commande
WAZUH_MANAGER="<IP-du-serveur-Wazuh>" apt-get install wazuh-agent

# Démarrer le service
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Remplacez <IP-du-serveur-Wazuh> par l'adresse IP de votre serveur central. L'agent s'enregistre automatiquement et apparaît dans le dashboard Wazuh sous Agents > Manage agents.

Sur une machine Windows :

Depuis le dashboard Wazuh, naviguez vers Agents > Deploy new agent. L'interface génère automatiquement la commande PowerShell d'installation en fonction du système cible (Windows x86/x64). L'agent Windows est distribué sous forme de package MSI et s'installe sans intervention manuelle au-delà de l'exécution de la commande générée.

Vérification : Dans le dashboard, le statut de chaque agent doit passer de Never connected à Active dans les 30 secondes suivant le démarrage du service.

Configuration pédagogique des règles

Wazuh embarque plusieurs milliers de règles de détection couvrant les événements système courants : authentification, élévation de privilèges, modifications de fichiers sensibles, activité réseau suspecte. Ces règles par défaut sont actives dès l'installation et couvrent la majorité des scénarios pédagogiques sans configuration supplémentaire.

Les règles sont organisées par niveau de sévérité (0 à 15) et par groupe logique (syslog, sshd, sudo, auditd...). Pour un lab pédagogique, il est conseillé de filtrer l'affichage du dashboard sur les alertes de niveau 7 et supérieur afin de ne pas noyer les apprenants dans un flux d'événements de routine.

Créer une règle custom pour illustrer le principe

Les règles personnalisées se définissent en XML dans le fichier /var/ossec/etc/rules/local_rules.xml. Ce fichier est prévu pour les règles locales et n'est pas écrasé lors des mises à jour de Wazuh.

Voici un exemple de règle qui déclenche une alerte de niveau 10 lorsqu'un compte étudiant exécute la commande su pour changer d'utilisateur :

<group name="local,privilege_escalation,">

  <rule id="100001" level="10">
    <if_sid>5401</if_sid>
    <match>su root</match>
    <description>Tentative de changement vers root via su détectée.</description>
    <group>authentication_success,privilege_escalation,</group>
  </rule>

</group>

Après avoir enregistré le fichier, rechargez les règles sans redémarrer le Manager :

/var/ossec/bin/wazuh-control reload

Quelques points importants à expliquer aux apprenants lors de la création de règles :

• Les identifiants de règles custom commencent à partir de 100000 pour éviter tout conflit avec les règles intégrées (qui vont jusqu'à 99999).
• La balise <if_sid> permet d'hériter du décodage d'une règle parente : ici, la règle 5401 couvre les événements su déjà parsés par Wazuh.
• Le champ <group> permet d'indexer la règle dans des catégories exploitables pour les tableaux de bord et les filtres.

Exercices pratiques (3 TP clés en main)

TP 1 : Détection de tentatives de connexion SSH échouées

Contexte : Une machine du lab tente de se connecter en SSH à la VM d'un autre binôme en testant plusieurs mots de passe successifs depuis une adresse IP contrôlée.

Déroulé pour l'étudiant :

1. Depuis une VM attaquante, exécuter plusieurs tentatives de connexion SSH avec un mot de passe incorrect :

   for i in {1..10}; do ssh etudiant@<IP-cible> -o BatchMode=yes 2>&1; done
   

2. Dans le dashboard Wazuh, naviguer vers Threat Hunting > Events et filtrer sur rule.groups: sshd.
3. Identifier les alertes générées par la règle Wazuh 5712 (SSHD brute force trying to get access to the system).
4. Analyser les champs de l'événement : adresse IP source, compte ciblé, nombre de tentatives, horodatage.

Objectif pédagogique : Comprendre comment un SIEM corrèle des événements individuels (chaque tentative de connexion échouée) pour lever une alerte de niveau supérieur (brute force). Faire le lien avec le métier de l'analyste SOC qui trie ces alertes au quotidien.

TP 2 : Détection d'escalade de privilèges

Contexte : Depuis un compte étudiant standard (sans droits sudo), un apprenant exécute sudo su pour tenter d'obtenir un shell root.

Déroulé pour l'étudiant :

1. Sur sa propre VM Linux, exécuter depuis un compte non privilégié :

   sudo su -
   

2. Observer immédiatement dans le dashboard Wazuh l'alerte générée (règle 5402 : Successful sudo to root executed).
3. Exercice avancé : Créer une règle custom dans local_rules.xml qui monte le niveau d'alerte à 12 pour tout sudo su exécuté en dehors des heures de TP (facultatif selon le niveau du groupe).

Objectif pédagogique : Illustrer concrètement la valeur de la gestion des journaux pour la traçabilité des actions privilégiées. Montrer que Wazuh détecte non seulement les attaques extérieures, mais aussi les comportements internes à surveiller.

TP 3 : Rapport de conformité CIS Benchmark

Contexte : Le module Security Configuration Assessment (SCA) de Wazuh évalue la configuration d'une machine par rapport aux recommandations CIS benchmarks.

Déroulé pour l'étudiant :

1. Dans le dashboard, naviguer vers Modules > Security Configuration Assessment.
2. Sélectionner un agent (la propre VM de l'étudiant) et consulter le rapport généré automatiquement.
3. Identifier trois écarts de configuration (exemples typiques : service SSH autorisé avec PermitRootLogin yes, absence de délai d'expiration des sessions inactives, comptes système sans shell désactivé).
4. Pour chacun des écarts identifiés, rédiger une fiche de remédiation : description du problème, commande de correction, vérification post-correction.

Objectif pédagogique : Initier les étudiants aux audits de conformité tels qu'ils sont pratiqués dans les cours analyse SOC et dans les missions réelles d'audit de configuration. Les apprenants comprennent que la conformité n'est pas une finalité abstraite mais le résultat d'une revue systématique de chaque paramètre de configuration.

Maintenance entre les séances

Un lab pédagogique qui accumule les artefacts des sessions précédentes (anciens agents enregistrés, logs de plusieurs promotions, règles non documentées) devient rapidement une source de confusion. Voici les opérations de maintenance à systématiser.

Supprimer les agents entre deux promotions :

# Lister les agents enregistrés
/var/ossec/bin/manage_agents -l

# Supprimer un agent par son ID
/var/ossec/bin/manage_agents -r <ID-agent>

Avec Docker Compose (si Wazuh est déployé en conteneur), la réinitialisation complète est encore plus simple :

docker compose down -v && docker compose up -d

Cette commande supprime tous les volumes persistants (index, configuration des agents, règles custom) et repart d'un état propre. Pensez à exporter votre fichier local_rules.xml avant d'exécuter cette commande si vous souhaitez conserver vos règles personnalisées.

Archiver les logs pédagogiques :

Le dashboard Wazuh permet d'exporter les résultats d'une requête au format CSV depuis Threat Hunting > Events > Export formatted. Cet export peut servir de support pour les débriefs ou être intégré à un exercice d'analyse post-incident.

Rotation des identifiants entre deux séances :

Changez le mot de passe du compte admin du dashboard entre deux groupes d'étudiants pour éviter qu'une promotion accède aux données de la suivante. Sur Wazuh Dashboard (basé sur OpenSearch Dashboards), la gestion des utilisateurs s'effectue via Security > Internal users.

Alternatives et compléments

Selon le niveau du groupe et les objectifs pédagogiques du module, d'autres outils méritent d'être mentionnés ou intégrés en complément de Wazuh.

Elastic SIEM (stack ELK) est une alternative sérieuse que les apprenants rencontreront fréquemment en entreprise. La combinaison Elasticsearch + Logstash + Kibana offre une flexibilité et une puissance supérieures à Wazuh sur les aspects de corrélation avancée et de Machine Learning. En revanche, la configuration d'une pipeline d'ingestion complète demande davantage de temps que ce que permet généralement un TP de quelques heures. Elle est davantage adaptée à un module de spécialisation ou à un projet de fin d'études qu'à une introduction au cours blue team.

Splunk Education License permet aux établissements partenaires Splunk d'accéder à une version complète de Splunk Enterprise (sans limite de volume) à des fins d'enseignement. L'interface Splunk, son langage de requête SPL et son écosystème d'applications (Splunk ES) sont très représentatifs des environnements SOC d'entreprise. Le principal frein est la dépendance à un partenariat institutionnel et la moindre transparence sur le fonctionnement interne par rapport à une solution open source comme Wazuh.

TheHive est une plateforme open source de gestion d'incidents de sécurité. Elle n'est pas un SIEM, mais elle se connecte naturellement à Wazuh via des connecteurs : lorsqu'une alerte Wazuh dépasse un certain seuil, elle peut créer automatiquement un cas dans TheHive, que les étudiants traitent comme ils le feraient dans un vrai SOC. Intégrer TheHive à votre module Wazuh est une excellente façon d'approfondir la couverture du cycle complet détection → qualification → remédiation, une fois que les bases du SIEM sont maîtrisées.

Ce qu'il faut retenir

Wazuh est l'un des outils les plus complets et les plus accessibles pour introduire les étudiants aux réalités du métier de analyste SOC. Sa stack tout-en-un, son installation automatisée et sa documentation exhaustive en font un candidat idéal pour un lab pédagogique de 30 apprenants.

Voici les points essentiels à garder en tête pour réussir votre déploiement :

• Un serveur central 8 Go RAM / 4 vCPU suffit pour 30 agents en contexte pédagogique. Profitez-en pour expliquer l'écart avec les spécifications de production — c'est un enseignement en soi.
• Le script officiel wazuh-install.sh -a déploie tout en une commande. Ne réinventez pas l'installation en TP ; consacrez le temps économisé à la configuration des règles et aux exercices.
• Les règles custom en XML apprennent la logique de détection. Faire écrire une règle simple à chaque étudiant, la tester et voir l'alerte apparaître en temps réel dans le dashboard est l'exercice le plus formateur qu'un SIEM pédagogique peut offrir.
• Les modules SCA et conformité ouvrent sur des sujets plus larges. Un rapport CIS benchmark généré en quelques clics devient le point de départ d'un TP sur la remédiation, le durcissement système et les exigences réglementaires.
• Planifiez la maintenance dès le départ. Une procédure de réinitialisation documentée et testée avant le premier TP est un investissement qui vous évitera des complications entre chaque promotion.

Vous souhaitez faire intervenir un formateur expérimenté pour concevoir ou animer votre module SIEM avec Wazuh ? Retrouvez des intervenants spécialisés en blue team et opérations SOC sur cyberteachers.org. Que vous partiez d'un lab existant ou que vous construisiez votre infrastructure pédagogique from scratch, nos experts peuvent vous accompagner de l'architecture jusqu'à l'animation des TP, en passant par la rédaction des scénarios d'exercice.