On a tous vécu ça en TP ou en prod. Un service tombe, un poste fait des trucs bizarres, un utilisateur jure qu’il n’a rien cliqué. Et toi tu te retrouves à ouvrir des journaux un par un, sur trois machines différentes, avec des horodatages pas alignés, des formats pas pareils, et évidemment l’événement intéressant est déjà parti dans la rotation.
Centraliser les logs, ça change tout. Pas besoin de viser tout de suite un SIEM énorme et coûteux. Pour un lab BTS SIO SISR, pour une petite infra, ou même pour apprendre sérieusement la supervision sécu, Wazuh est une option très solide. C’est un « SIEM léger » dans le sens où tu peux démarrer petit, comprendre ce que tu fais, et ajouter des briques ensuite.
Dans cet article, on va poser un Wazuh propre, récupérer des logs Windows et Linux, activer quelques détections utiles, et sortir un mini tableau de bord exploitable. Le genre de setup que tu peux refaire en atelier sur le Tech Lab du blog, et garder en base pour d’autres labs.
Note : l’écosystème Wazuh s’appuie sur un indexeur et un dashboard (basés sur OpenSearch) et un manager. L’ensemble est gratuit et très complet, mais ça reste une stack, donc ça demande un minimum de ressources et de méthode.
Pourquoi Wazuh pour un « SIEM léger »
Un SIEM, en vrai, ce n’est pas juste « je stocke des logs ». C’est plutôt :
- centralisation (collecte, normalisation),
- détection (règles, corrélation, IOC),
- investigation (recherche, timelines),
- et un minimum de réponse (alertes, intégrations).
Wazuh coche beaucoup de cases, et surtout il est pédagogique. Tu peux lire les règles, les adapter, voir exactement quel log déclenche quoi. Et ça, pour des étudiants SISR, c’est parfait.
Quelques points forts, version terrain :
- agents légers sur les machines,
- supervision d’intégrité des fichiers (FIM),
- vulnérabilités (inventaire paquets, CVE),
- règles de détection prêtes à l’emploi,
- dashboard déjà utilisable, sans passer 3 jours à faire des visualisations.
Et oui, tu peux l’utiliser juste pour centraliser des logs au début, puis activer le reste progressivement. C’est même conseillé.
Architecture simple pour un lab SISR
On part sur quelque chose de clair, reproductible, et pas trop gourmand.
Composants
- Wazuh manager : reçoit les événements des agents, applique les règles, génère des alertes.
- Wazuh indexer : stocke et indexe les événements (recherche rapide).
- Wazuh dashboard : interface web pour visualiser, rechercher, enquêter.
- Agents Wazuh : sur Linux et Windows.
Schéma rapide
text [Agent Linux] ----
[Agent Windows] ---+--> (1514/UDP ou TCP) --> [Wazuh manager] --> [Indexer] --> [Dashboard : 5601] [Agent Syslog] ----/
Ports typiques à retenir :
- Agent vers manager : 1514 (events) et 1515 (enrôlement), selon config.
- Dashboard : 5601 (HTTPS).
- Indexer : 9200 (HTTPS).
- Manager API : 55000 (souvent en local ou réseau restreint).
Prérequis matériels et réseau
Pour un lab, le minimum réaliste :
- VM Wazuh tout en un (manager + indexer + dashboard) : 4 vCPU, 8 Go RAM. 2 vCPU et 4 Go, ça démarre… mais tu vas souffrir dès que tu ajoutes Windows + un peu de volumétrie.
- Disque : 60 Go (logs, index).
- OS : Ubuntu Server 22.04 LTS ou Debian 12 (Ubuntu est souvent plus simple pour les tutos).
Réseau :
- Résolution DNS correcte (ou /etc/hosts propre).
- NTP activé partout. Vraiment. Les timestamps désalignés ruinent une investigation.
Installation de Wazuh (stack tout en un)
Wazuh fournit un installateur officiel qui fait gagner du temps. Pour un lab pédagogique, c’est très bien. Plus tard, tu pourras séparer les rôles.
1) Préparer la machine
Sur Ubuntu :
bash sudo apt update && sudo apt -y upgrade sudo apt -y install curl unzip sudo timedatectl set-timezone Indian/Mayotte || true sudo systemctl enable --now systemd-timesyncd
(Le fuseau horaire, adapte. L’idée, c’est surtout d’avoir l’heure juste.)
2) Lancer l’installation
bash curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh sudo bash wazuh-install.sh -a
L’option -a installe manager + indexer + dashboard sur la même VM.
À la fin, l’installeur affiche :
- l’URL du dashboard,
- un utilisateur et un mot de passe.
Note bien ces infos. Oui, prends une capture d’écran, c’est le genre de détail qui disparaît quand on ferme le terminal.
3) Vérifier l’accès au dashboard
Dans le navigateur :
https://IP_DU_SERVEUR:5601
Tu devrais voir le Wazuh Dashboard.
Images à insérer (où ça aide vraiment)
Ici, sur WordPress, tu peux ajouter des captures. Pour te guider, voilà des emplacements logiques.
Capture 1 : page de connexion Wazuh dashboard
Capture 2 : vue d’ensemble Security events / agents
(Si tu préfères, remplace par tes propres captures du lab, ça fera plus « Tech Lab », plus vrai.)
Enrôler un agent Linux (Ubuntu ou Debian)
Le but : envoyer les logs système au manager, puis vérifier qu’on voit l’agent et des événements.
1) Installer l’agent
Sur la machine cliente Linux :
bash curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo 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" | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update sudo apt -y install wazuh-agent
2) Déclarer l’adresse du manager
Éditer :
bash sudo nano /var/ossec/etc/ossec.conf
Cherche la section <client> et mets l’IP ou le DNS du manager :
xml
192.168.1.10
1514tcp
3) Enrôler l’agent (enregistrement)
Selon ta version, tu peux utiliser agent-auth ou l’enrôlement via clé. Exemple simple :
bash sudo /var/ossec/bin/agent-auth -m 192.168.1.10 sudo systemctl enable --now wazuh-agent
4) Vérifier côté manager
Sur le serveur Wazuh :
bash sudo /var/ossec/bin/agent_control -lc
Tu dois voir l’agent « Active ».
Dans le dashboard : section Agents. Il doit apparaître, avec son OS, son statut, sa dernière connexion.
Enrôler un agent Windows (Windows 10 ou Server)
Windows, c’est souvent là que les logs deviennent intéressants : authentifications, services, PowerShell, Defender, etc.
1) Installer l’agent
Télécharge l’agent depuis le site Wazuh ou utilise le MSI. Sur un lab, le plus simple est le MSI + config.
Page officielle (à utiliser comme référence) :
2) Configurer le manager dans l’agent
Fichier typique :
C:\Program Files (x86)\ossec-agent\ossec.conf
Même principe que Linux : l’adresse du manager.
3) Activer la collecte d’événements Windows
Dans ossec.conf, tu peux ajouter ou vérifier une section localfile pour le journal Windows. Exemple utile :
xml Security <log_format>eventchannel</log_format>
System eventchannel Microsoft-Windows-Sysmon/Operational eventchannel
Sysmon est optionnel, mais si tu veux apprendre la détection, Sysmon apporte une granularité énorme. Et ça fait un bon TP.
4) Démarrer le service
- Services Windows : Wazuh Agent en « Running ».
- Ou en PowerShell admin :
powershell Start-Service WazuhSvc
Premier objectif : centraliser et retrouver un événement
À ce stade, tu veux une preuve simple que ça marche. Pas un joli dashboard. Une preuve.
Test Linux
Sur l’agent Linux :
bash sudo su - tail -f /var/log/auth.log
Puis depuis une autre session, fais un login SSH (ou une tentative échouée). Tu dois voir l’événement.
Dans Wazuh Dashboard :
- Security events : filtre par l’agent, puis recherche
sshdouauthentication failure.
Test Windows
Sur Windows :
- Fais une connexion RDP échouée, ou lance une commande PowerShell.
- Va dans Security events, filtre sur l’agent Windows, puis cherche
4625(échec logon) ou4688(création de processus) selon la collecte.
Ça peut sembler basique, mais c’est le moment où tu sens que tu as repris le contrôle. Les logs ne sont plus éparpillés.
Activer des alertes utiles (sans tout casser)
Un piège classique : activer trop de règles, trop tôt. Résultat : bruit, alert fatigue, et tu ne regardes plus rien.
On va rester simple, très lab friendly.
1) Surveiller les tentatives de brute force SSH
Wazuh a déjà des règles pour ça. L’important est surtout de valider que les événements sont bien parsés et que les alertes montent.
Dans le dashboard, tu peux filtrer sur :
rule.groups: authentication_failedou similaire,- ou rechercher « sshd » + niveau d’alerte.
2) Sur Windows : échecs d’authentification
Event ID :
- 4625 : logon failed.
Crée-toi une petite routine d’investigation :
- combien d’échecs sur 10 minutes ?
- depuis quelle IP ?
- sur quel compte ?
Même si tu ne fais pas encore de corrélation avancée, tu apprends à poser les bonnes questions.
Collecter des logs applicatifs et syslog (bonus très utile)
Dans un réseau, tu auras des équipements qui parlent syslog : switch, routeur, firewall, AP, hyperviseur. Centraliser ça dans Wazuh est franchement pratique.
Réception syslog sur le manager
Wazuh peut intégrer syslog via rsyslog et lecture de fichiers.
Exemple rapide :
- Configurer rsyslog pour écouter en UDP 514.
- Écrire dans un fichier dédié (par exemple
/var/log/network.log). - Déclarer ce fichier dans Wazuh en
localfile.
Côté Wazuh manager, dans /var/ossec/etc/ossec.conf :
xml <log_format>syslog</log_format> /var/log/network.log
Puis reload :
bash sudo systemctl restart wazuh-manager
Rétention, volumétrie, et deux ou trois réalités
Tu vas vite te rendre compte d’un truc : les logs, ça grossit vite. Surtout Windows + Sysmon.
Quelques conseils simples :
- garde une rétention courte en lab (7 à 14 jours),
- surveille l’espace disque,
- n’active Sysmon que si tu sais pourquoi tu le veux,
- filtre ce que tu collectes.
Un SIEM « léger », c’est aussi ça. Un SIEM qui reste utilisable.
Mini scénario d’investigation (à faire en TP)
On va jouer une petite histoire, simple, mais réaliste.
Scénario
- Un utilisateur se plaint de ralentissements.
- Sur Windows, tu observes plusieurs échecs d’authentification.
- Puis une exécution PowerShell un peu suspecte (si Sysmon est là, c’est encore mieux).
Étapes dans Wazuh
- Va dans Security events.
- Filtre sur l’agent Windows.
- Recherche
4625sur les dernières 24 h. - Identifie une IP source répétée.
- Vérifie ensuite s’il y a des événements
4688ou Sysmon Process Create autour de la même période. - Note la timeline. Même à la main, c’est formateur.
C’est typiquement le genre d’exercice qu’on peut enrichir sur le blog BTS SIO2 SISR Tech Lab, en ajoutant des captures, des questions, une grille de correction, et des variantes. Par exemple : ajouter un compte lockout, ou un faux malware inoffensif, ou un script d’audit qui spamme les logs.
Bonnes pratiques rapides (celles qui évitent les galères)
- NTP partout : je le répète, parce que c’est vital.
- Nommer proprement les machines :
SRV-WAZUH,CLI-W10-01, etc. - Séparer réseau de management et réseau utilisateur si tu peux.
- Sauvegarder les configs :
/var/ossec/etc/côté manager, et les conf agents. - Documenter au fur et à mesure. Même deux lignes. Sinon tu oublies.
Limites de « SIEM léger » et quand passer un cap
Wazuh peut aller loin, mais si ton objectif devient :
- corrélation multi sources très avancée,
- ingestion massive (plusieurs milliers EPS),
- cas d’usage SOC avec playbooks,
alors tu vas penser à une architecture distribuée, du tuning OpenSearch, et à des processus SOC (triage, escalade, runbooks). Ce n’est plus juste un lab. Ce n’est plus « léger ». Et ce n’est pas grave.
Mais pour apprendre, pour monitorer une petite infra, pour faire des TPs réalistes en BTS SIO SISR, Wazuh est déjà une très grosse marche.
Conclusion
Centraliser les logs avec Wazuh, c’est un des meilleurs investissements temps pour un lab cybersécurité et supervision. Tu passes de « je cherche des indices sur chaque machine » à « j’ai un point unique, je filtre, je retrouve, je comprends ». Et ensuite seulement tu ajoutes la détection, les alertes, la vulnérabilité, le FIM.
Si tu veux, on peut transformer ce guide en vrai TP complet pour le site BTS SIO2 SISR Tech Lab avec objectifs, consignes, captures et questions, style fiche de lab. Tu peux aussi parcourir les autres articles sur https://sio1blog.blogspot.com/ pour rester dans la même logique, supervision, infra, cybersécurité, et du concret.
Annexe : checklist rapide (pratique pour ton cahier de lab)
- VM Wazuh installée, dashboard accessible en HTTPS
- Agent Linux enrôlé, logs auth visibles
- Agent Windows enrôlé, logs Security visibles
- Au moins un test d’événement retrouvé (SSH fail, 4625, etc.)
- Une alerte comprise (quelle règle, quel champ, quel log source)
- Rétention et disque vérifiés (pas de surprise demain)
Questions fréquemment posées
Qu'est-ce que Wazuh et pourquoi est-il recommandé pour un SIEM léger ?
Wazuh est une solution de SIEM légère qui permet la centralisation, la détection, l'investigation et la réponse aux incidents de sécurité. Il est idéal pour les petites infrastructures ou les labs pédagogiques car il est facile à déployer, pédagogique, avec des agents légers, des règles prêtes à l'emploi et un dashboard utilisable rapidement.
Quels sont les composants principaux de l'architecture Wazuh pour un lab SISR ?
L'architecture simple comprend : le Wazuh manager (reçoit événements et applique règles), l'indexer (stocke et indexe les logs), le dashboard (interface web d'analyse) et les agents Wazuh installés sur Linux et Windows. Les communications se font via des ports standards comme 1514 pour les événements et 5601 pour le dashboard.
Quels sont les prérequis matériels recommandés pour installer Wazuh dans un environnement de lab ?
Pour un lab réaliste, il est conseillé d'avoir une VM tout-en-un avec au minimum 4 vCPU, 8 Go de RAM, 60 Go de disque pour stocker logs et index. L'OS recommandé est Ubuntu Server 22.04 LTS ou Debian 12. La synchronisation horaire via NTP est essentielle pour éviter les problèmes d'investigation.
Comment installer rapidement la stack Wazuh tout-en-un sur Ubuntu ?
L'installation rapide utilise le script officiel : après mise à jour du système et installation des outils nécessaires, on télécharge le script avec curl puis on lance sudo bash wazuh-install.sh -a qui installe manager, indexer et dashboard sur la même machine. À la fin, l'URL du dashboard et les identifiants sont affichés.
Quels avantages pédagogiques offre Wazuh aux étudiants en BTS SIO SISR ?
Wazuh permet aux étudiants de comprendre concrètement comment fonctionne un SIEM : ils peuvent lire et adapter les règles de détection, voir quels logs déclenchent des alertes, apprendre la centralisation des logs, la supervision d'intégrité (FIM), l'inventaire des vulnérabilités et créer des dashboards exploitables sans complexité excessive.
Pourquoi est-il important d'avoir une bonne synchronisation horaire dans une infrastructure Wazuh ?
Une bonne synchronisation horaire via NTP est cruciale car elle garantit que tous les logs ont des horodatages alignés. Sans cela, il devient difficile voire impossible d'enquêter efficacement sur un incident de sécurité car les événements ne sont pas corrélés correctement dans le temps.
0 Commentaires