TP Bonus — Wazuh : un SIEM clé-en-main

Acte 2 · SIEM Bonus Wazuh · OpenSearch · Comparaison

Auteur : Thibaut Fontaine — Kodetis Institution : Université de la Réunion Date : 2026

---

Table des matières

• Objectif & cadrage
• Prérequis
• Étape 1 — Déployer Wazuh
• Étape 2 — Brancher 3 sources
• Étape 3 — Détecter l’attaque jour J avec Wazuh
• Étape 4 — Comparaison Wazuh vs SOC Grafana-natif
• Étape 5 — Décision d’architecture
• Livrables & validation
• Annexe enseignant — corrigé

---

1. Objectif & cadrage

📡 Poste SOC · La Réunion — Acte 2, Détecter · hors enquête : un contrepoint d’outillage, pas une étape du jour J.

Tu as construit ton SIEM (TPs 1-3 : Sigma → LogQL, alerting Discord, couverture ATT&CK). Voici maintenant un SIEM acheté monté : Wazuh. Le but n’est pas de le préférer — c’est de comprendre le compromis pour choisir avec lucidité ce qu’on déploie en prod.

🔴 Au fil de l’enquête (hors fil rouge)

Ce TP est volontairement détaché de l’incident jour J. C’est un bench-off d’architecture : déployer un SIEM mainstream, faire passer dedans les mêmes données que dans Grafana, et mesurer la différence.

Objectifs pédagogiques

• Déployer Wazuh Manager + Indexer + Dashboard (architecture stack complète).
• Brancher 3 sources représentatives : Linux agent, Windows agent, Falco events.
• Détecter la même attaque jour J avec les règles out-of-box de Wazuh.
• Comparer capacités gagnées (FIM, SCA, vuln scanning, corrélation native) vs coût (RAM, complexité, 2ᵉ vitre).
• Décider : quel SIEM pour la prod TAAF (golden-box vs SAE) — et argumenter.

Ressources — lire avant de commencer

Wazuh exige 8 Go RAM plancher (JVM OpenSearch de l’Indexer) + vm.max_map_count=262144. Infaisable sur la golden-box — ce TP tourne sur la VM Vagrant SAE uniquement. Si vous n’avez pas la VM SAE, n’essayez pas sur la golden-box : OOM Killer garanti.

Architecture du TP

graph TB
 subgraph "VM monitoring (existante)"
 FALCO[Falco]
 GRAF[Grafana + Loki
SOC Grafana-natif]
 LOKI[(Loki)]
 end

 subgraph "VM SAE (nouvelle)"
 WMGR[Wazuh Manager
port 1514/1515/55000]
 WIDX[Wazuh Indexer
OpenSearch
port 9200
~4 GB RAM]
 WDSH[Wazuh Dashboard
port 5601
~1 GB RAM]
 end

 subgraph "Sources"
 LINUX[Linux agent
TAAF-FS-001]
 WIN[Windows agent
TAAF-W-PAF07]
 end

 LINUX -->|agent native| WMGR
 WIN -->|agent native| WMGR
 FALCO -->|webhook/syslog| WMGR
 WMGR --> WIDX
 WIDX --> WDSH

 FALCO -->|alloy| LOKI
 LOKI --> GRAF

 classDef existing fill:#99ff99,stroke:#333,stroke-width:2px
 classDef new fill:#ffcc99,stroke:#333,stroke-width:2px

 class FALCO,GRAF,LOKI existing
 class WMGR,WIDX,WDSH,LINUX,WIN new

---

2. Prérequis

VM SAE — ressources minimum

vagrant ssh sae
free -h
# total: 12Gi   used: 2.1Gi   free: 9Gi+
# → OK pour Wazuh

Si vous n’avez pas la VM SAE, déclarez-la dans le Vagrantfile :

config.vm.define "sae" do |sae|
  sae.vm.box = "ubuntu/jammy64"
  sae.vm.hostname = "TAAF-SAE-001"
  sae.vm.network "private_network", type: "dhcp"
  sae.vm.provider "virtualbox" do |vb|
    vb.memory = 12288    # 12 GB
    vb.cpus = 4
  end
end

Préparer le kernel

# Sur la VM sae
echo "vm.max_map_count=262144" | sudo tee /etc/sysctl.d/99-wazuh.conf
sudo sysctl -p /etc/sysctl.d/99-wazuh.conf
# → vm.max_map_count = 262144

---

3. Étape 1 — Déployer Wazuh

3.1 — Installateur all-in-one (recommandé)

curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
sudo bash wazuh-install.sh -a -i
# -a : all-in-one (Manager + Indexer + Dashboard sur la même machine)
# -i : ignore les warnings de ressources (à utiliser si on est juste à 12 GB)

Durée : ~10-15 minutes. À la fin, l’installeur affiche :

INFO: --- Summary ---
INFO: You can access the web interface https://IP_SAE
    User: admin
    Password: <auto-généré, copier dans le coffre-fort>

3.2 — Vérifier les 3 services

systemctl status wazuh-manager wazuh-indexer wazuh-dashboard
# Tous en "active (running)"

curl -k -u admin:<password> https://IP_SAE:9200/_cluster/health?pretty
# → status "green" ou "yellow", 1 node

3.3 — Ouvrir le dashboard

https://IP_SAE → login admin / <password> → tableau de bord Wazuh.

📸 Capture obligatoire #1 : page d’accueil Wazuh montrant 0 agent enrôlé (état initial).

---

4. Étape 2 — Brancher 3 sources

4.1 — Agent Linux sur TAAF-FS-001 (la VM monitoring)

Sur la VM monitoring :

# Récupérer la commande d'enrôlement depuis le dashboard Wazuh :
# Agents → Deploy new agent → Linux → suivez les étapes

curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.0-1_amd64.deb
WAZUH_MANAGER='IP_SAE' WAZUH_AGENT_GROUP='taaf-linux' \
  sudo dpkg -i wazuh-agent_4.10.0-1_amd64.deb

sudo systemctl enable --now wazuh-agent
sudo systemctl status wazuh-agent
# → Connected to server <IP_SAE>

4.2 — Agent Windows sur TAAF-W-PAF07

# Sur TAAF-W-PAF07, PowerShell admin
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.10.0-1.msi" `
  -OutFile "$env:tmp\wazuh-agent.msi"
msiexec.exe /i $env:tmp\wazuh-agent.msi /q `
  WAZUH_MANAGER="IP_SAE" WAZUH_AGENT_GROUP="taaf-windows"

Start-Service WazuhSvc
Get-Service WazuhSvc
# → Status: Running

4.3 — Falco events vers Wazuh (intégration custom)

Falco peut pousser ses alertes en HTTP via falcosidekick. Configurez un endpoint Wazuh :

# Sur la VM monitoring, dans falcosidekick.yaml
webhook:
  address: "https://IP_SAE:55000/security/user/authenticate"
  customheaders:
    Authorization: "Basic <base64(wazuh-api-user:password)>"

# Et un parser Wazuh côté manager (/var/ossec/etc/decoders/falco.xml)

Plus simple : rediriger les logs Falco vers syslog sur la VM Wazuh :

# Falco config
syslog_output:
  enabled: true
  host: IP_SAE
  port: 514

4.4 — Vérifier les 3 agents enrôlés

Dashboard Wazuh → Agents :

Agent	OS	Status	Group
TAAF-FS-001	Linux	Active	taaf-linux
TAAF-W-PAF07	Windows	Active	taaf-windows
TAAF-MONITORING-001 (via Falco syslog)	Linux	Active	taaf-linux

📸 Capture obligatoire #2 : page Agents avec les 3 agents en “Active”.

---

5. Étape 3 — Détecter l’attaque jour J avec Wazuh

5.1 — Rejouer l’attaque

Sur la VM monitoring, rejouez les actions du jour J :

# Simuler le log d'auth e.bernard externe
logger -t auth -p auth.info \
  'service=vpn user=e.bernard src_ip=203.0.113.42 auth_status=success'

# Simuler l'accès au coffre
docker exec -u root nextcloud-alfred-faure \
  cat /var/www/html/data/admin.cloud.af/files/CLASSIFIED-VAULT-X/KER-2024-002.fasta > /dev/null

Sur TAAF-W-PAF07 (PowerShell) :

# Simuler PowerShell -enc depuis Excel
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("Write-Host 'attack'"))
& powershell.exe -NoP -W Hidden -enc $encoded

5.2 — Voir les alertes Wazuh

Dashboard Wazuh → Security events → filter agent.name: TAAF-W-PAF07 + dernière heure.

Vous devez voir :

Rule ID	Description	Severity
60101	Windows PowerShell encoded command execution	10 (high)
553	NextCloud unauthorized access	7 (medium)
5715	sshd authentication failure (variante)	5

→ Wazuh a détecté out-of-box des choses pour lesquelles vous avez dû écrire la règle au TP1 SIEM.

📸 Capture obligatoire #3 : trois alertes affichées par Wazuh sans qu’on ait écrit une seule règle.

5.3 — Visualiser la corrélation native

Wazuh corrèle nativement les événements multi-sources. Dashboard Wazuh → MITRE ATT&CK → vous voyez automatiquement le chemin attaque colorié sur la matrice ATT&CK.

📸 Capture obligatoire #4 : matrice ATT&CK colorée par Wazuh sans intervention.

→ Vs TP3 Couverture : vous avez dû générer un layer S2AN, l’importer manuellement. Wazuh fait tout en arrière-plan.

---

6. Étape 4 — Comparaison Wazuh vs SOC Grafana-natif

6.1 — Tableau comparatif (livrable principal)

Critère	SOC Grafana-natif (vos TPs 1-3)	Wazuh
Détection	Sigma → LogQL (vous écrivez)	~5000 règles XML out-of-box + Sigma custom
Corrélation ordonnée	Approximée 2 étages (TP3)	Native, multi-source, multi-règle
FIM (intégrité fichiers)	À rebâtir (Falco ou auditd custom)	Clé-en-main, configuration GUI
SCA (CIS audit)	Manuel via Lynis (Acte 3)	Intégré + tableau de bord
Vulnerability scanning	À rebâtir (Trivy/Grype Acte 3)	Intégré (inventaire ↔ CVE base NVD)
Agent système (syscalls hôte)	Falco uniquement	Wazuh + Falco possibles
Couverture ATT&CK	S2AN + Navigator manuel (TP3)	Tableau de bord auto
Alerting	Grafana Alerting → Discord (TP2)	Wazuh notifications + intégrations
Format de règle	YAML Sigma	XML Wazuh (verbeux)
Langage requête	LogQL	OpenSearch DSL (JSON)
Ressources	~3-4 Go (golden-box)	≥ 8 Go (JVM OpenSearch)
Cohérence formation	Une seule vitre (Acte 1+2+3)	Univers séparé du monitoring
Open Source	100 % (Grafana OSS, Loki AGPL)	100 % (GPL v2)
Souveraineté	Hébergement local complet	Hébergement local complet
Apprentissage	Long mais profond (vous comprenez tout)	Rapide mais boîte noire

6.2 — Reformuler en forces / faiblesses

SOC Grafana-natif (TPs 1-3) :

• ✅ Économe en ressources (tient sur la golden-box)
• ✅ Une seule vitre pour observabilité + sécurité
• ✅ Vous comprenez et maîtrisez chaque ligne (LogQL)
• ❌ Pas de corrélation ordonnée native (compromis TP3)
• ❌ FIM/vuln/SCA absents par défaut
• ❌ Vous devez écrire et maintenir vos règles

Wazuh :

• ✅ FIM, SCA, vuln scanning, corrélation native — clé-en-main
• ✅ 5000 règles + matrice ATT&CK auto
• ✅ Standard mainstream (employabilité, doc abondante)
• ❌ 8+ Go RAM (lourd pour une petite infra)
• ❌ Stack séparée du monitoring (2 vitres)
• ❌ Règles XML verbeuses, langage requête à apprendre en plus

---

7. Étape 5 — Décision d’architecture

7.1 — Pour la prod TAAF

Question : Quel SIEM déployer en prod sur les bases polaires TAAF ?

Contraintes :

• Golden-box ~3-4 Go RAM (équipes réduites, hardware modeste).
• Pas de SOC 24/7.
• Connectivité SATCOM contrainte (privilégier solutions résilientes au offline).
• Audit ANSSI / NIS2 / IGI 1337 obligatoire.

Recommandation attendue : SOC Grafana-natif pour le tronc commun, Wazuh sur les bases principales (Crozet Alfred Faure, Kerguelen PAF) qui ont plus de hardware, pas sur les bases isolées (Amsterdam, Dumont d’Urville) où chaque Go RAM compte.

7.2 — Pattern hybride proposé

graph LR
 subgraph "Bases isolées"
 G1[Falco + Alloy
SOC Grafana-natif léger]
 end

 subgraph "Bases principales"
 W1[Wazuh agent + Manager local]
 end

 subgraph "Hub La Réunion"
 H[Wazuh Manager central
+ Grafana Loki
+ Dashboard unifié]
 end

 G1 -->|logs SATCOM compressés| H
 W1 -->|enrôlement Wazuh| H

 classDef edge fill:#99ff99,stroke:#333,stroke-width:2px
 classDef main fill:#ffcc99,stroke:#333,stroke-width:2px
 classDef hub fill:#99ccff,stroke:#333,stroke-width:2px

 class G1 edge
 class W1 main
 class H hub

Argumentaire :

• Bases isolées : SOC Grafana-natif autonome offline, alerting Discord/SMS quand SATCOM up.
• Bases principales : Wazuh agent local avec corrélation, sync vers Hub périodiquement.
• Hub Réunion : Wazuh Manager central + dashboard unifié Grafana + Wazuh side-by-side.

7.3 — Coût opérationnel

Aspect	SOC Grafana	Wazuh	Hybride
RAM totale (3 bases)	3 × 4 Go = 12 Go	3 × 8 Go = 24 Go	1×4 + 2×8 + Hub 16 = 36 Go
Personnel à former	LogQL + Sigma	Wazuh XML + OpenSearch DSL	Les deux
Temps d’investigation	Lent (rédiger LogQL)	Rapide (dashboards prêts)	Hub centralise
Résilience SATCOM down	✅ Tout local	⚠️ Manager doit être local	✅ Bases autonomes

---

8. Livrables & validation

Livrables

1. Wazuh fonctionnel : page d’accueil + 3 agents enrôlés (captures).
2. 3 sources branchées : Linux agent, Windows agent, Falco events (logs visibles dans Wazuh).
3. Captures détection jour J : ≥ 3 alertes Wazuh sans règle custom + matrice ATT&CK colorée.
4. Tableau comparatif complet (15+ lignes) avec colonnes Grafana-natif / Wazuh.
5. Tableau forces/faiblesses des 2 approches.
6. Décision d’architecture argumentée pour la prod TAAF (≥ 1 page).
7. (Bonus) : déploiement réel du pattern hybride sur 2 VMs.

Grille de validation

Critère	Pondération
Wazuh déployé et 3 services en running	15 %
3 agents enrôlés (Linux + Windows + Falco)	15 %
Détection jour J fonctionnelle (≥ 2 alertes capturées)	15 %
Tableau comparatif détaillé (≥ 15 critères)	20 %
Tableau forces/faiblesses cohérent	10 %
Décision d’architecture argumentée (contraintes TAAF)	20 %
(Bonus) Pattern hybride déployé	+10 % bonus

Format de rendu : PDF nom-prenom-promo.pdf sur Moodle.

---

9. Annexe enseignant — corrigé

Décision attendue : argumentation

Option recommandée : SOC Grafana-natif partout, Wazuh sur le hub Réunion comme couche d’agrégation/corrélation centrale.

Raisons :

1. Souveraineté de la donnée : les bases isolées gardent leurs logs en local, sync différé sur SATCOM up.
2. Résilience offline : un SOC Grafana-natif fonctionne sans connexion SATCOM. Un Wazuh dont le Manager est ailleurs ne corrèle plus.
3. Empreinte hardware : la golden-box (~4 Go) tient un Grafana-natif. Wazuh sur chaque base = doublement du hardware.
4. Compétences : les équipes TAAF apprennent un stack (Sigma + LogQL) et le maîtrisent — pas deux.

Réserve : si une base devient hub régional avec ≥ 8 Go RAM dispo, Wazuh local devient pertinent pour la corrélation et le FIM. Le pattern hybride est l’évolution naturelle.

Erreurs courantes à pénaliser

• “Wazuh est mieux car ça a tout” sans considérer la RAM golden-box → -15 % (manque la lucidité des contraintes).
• “Grafana natif est mieux car on l’a construit” sans reconnaître les manques (FIM, SCA, vuln) → -10 %.
• Tableau comparatif < 10 critères → -10 %.
• Pas de décision argumentée ou décision binaire (tout l’un ou l’autre) → -15 %.
• Pas de prise en compte des bases isolées et de la SATCOM → -10 %.

Pont avec la SAE

À la SAE, l’étudiant doit défendre son architecture devant un jury “RSSI TAAF”. Le tableau comparatif et la décision argumentée de ce TP sont directement réutilisables dans le rapport SAE final.

Pour la prod

En vraie prod TAAF (hypothèse), le choix dépendra fortement :

• Du budget hardware réel disponible.
• De l’existence d’un CERT-FR partenaire (qui peut piloter le Wazuh central).
• De la fréquence des connexions SATCOM (bases isolées vs hub).

Alternative plus légère/standard (mention)

OpenSearch + plugin Security Analytics (Apache-2.0, 2200 détecteurs Sigma natifs + corrélation) — même coût JVM mais un composant de moins que Wazuh. À évaluer en bonus de bonus.

---

Références

• Wazuh — installation guide
• Wazuh — out-of-box rules
• OpenSearch Security Analytics
• Falco — webhook output / falcosidekick
• Article comparatif : SIEM open source 2026 (Kodetis blog)