Un homelab SOC avec Wazuh, Suricata et l'Elastic Stack, c'est la façon la plus rapide de construire de vrais réflexes d'analyste, ceux que tu n'obtiens qu'en vivant avec les outils. Trois briques gratuites et open source : Wazuh pour le monitoring host et le front-end SIEM, Suricata pour l'IDS réseau, et l'Elastic Stack qui gère stockage et recherche. Ça tourne sur une petite VM, ou sur un vieux laptop qui prend la poussière dans un tiroir. À la fin, tu auras un dashboard qui avale les logs des endpoints, attrape les attaques réseau, les aligne sur MITRE ATT&CK et te laisse chasser dans un dataset qui a vraiment l'air réel. Une demi-journée du samedi, zéro budget matériel.
The short answer
Monte un homelab SOC fonctionnel en une seule passe : l'installeur single-node de Wazuh pose l'Indexer, le Manager et le Dashboard d'un coup, Suricata lit les paquets sur un span port et fait remonter ses alertes EVE JSON dans Wazuh, et un agent s'enrôle sur chaque endpoint. Ensuite tu lances tes propres attaques de test (brute-force SSH, une modification d'intégrité de fichier, un hit de signature IDS) et tu regardes le pipeline s'allumer face à MITRE ATT&CK.
Aucun cours ne m'a donné ça. Un homelab SOC (Security Operations Center), si. Les réflexes, je veux dire, ceux que tu ne construis qu'en vivant au quotidien avec les outils que les analystes fixent quand ça part vraiment en vrille. Alors voici le lab que je n'arrête pas de reconstruire. Trois briques gratuites et open source : Wazuh (monitoring host-based et front-end SIEM), Suricata pour l'IDS réseau, et la Elastic Stack qui gère le stockage et la recherche. Ça tourne sur une petite VM, ou sur n'importe quel vieux laptop qui prend la poussière dans un tiroir. À la fin, tu auras un dashboard qui avale les logs des endpoints, attrape les attaques réseau, les aligne sur MITRE ATT&CK et te laisse chasser dans un dataset qui a vraiment l'air réel. Une demi-journée du samedi. Zéro budget matériel.
Pourquoi monter un homelab SOC en 2026
Lire la doc Wazuh te mène peut-être à un tiers du chemin. Un bon workshop à la Black Hat, encore un tiers. Le dernier bout, c'est le plus dur. Trier une alerte à 3 h du matin, le cerveau à peine allumé, attraper le bon filtre Kibana à l'instinct pur, voir un agent passer dans le noir et comprendre pourquoi avant même d'avoir bu un café. Ça, tu ne l'obtiens qu'en pointant la stack sur tes propres machines et en les attaquant toi-même. C'est tout l'intérêt du lab. Pas cher, et sans danger à casser. Et franchement ? Ça paie en entretien d'une façon que je n'avais pas vue venir. Quelqu'un capable de te dérouler la règle exacte qui s'est déclenchée quand il a balancé mimikatz sur une VM Windows jetable, ce n'est pas du tout la même conversation que celui qui récite un programme de formation.
Ce que tu t'apprêtes à installer
Trois projets open source. Voici le boulot de chacun.
- Wazuh (apache-2.0). Un agent host sur chaque endpoint, plus un manager central qui fait le gros du travail. Évaluation des règles, mapping MITRE ATT&CK, surveillance d'intégrité, scan de vulnérabilités. Et l'UI dans laquelle tu vas pour ainsi dire vivre.
- Suricata (GPLv2). Un IDS / IPS réseau rapide qui lit les paquets sur un span port ou un tap, les confronte aux jeux de règles Emerging Threats, puis crache des alertes EVE JSON que Wazuh vient récupérer.
- Elastic Stack (Elastic License v2). Elasticsearch stocke et indexe tout. Kibana dessine les dashboards. Wazuh embarque les deux dans un installeur single-node, ce qui t'épargne de câbler OpenSearch ou Loki à la main (sauf si c'est vraiment ta définition d'un bon moment).
Prérequis et topologie
Tu peux tout caser sur une seule machine. Une VM avec 4 vCPU, 8 Go de RAM, 50 Go de disque sous Ubuntu Server 24.04 LTS ou Rocky Linux 9 (Wazuh documente les deux comme supportés en 2026). Ensuite, fais tourner une ou deux VM de plus pour servir d'endpoints monitorés. Une machine Linux avec sshd exposé, plus une VM Windows (la version d'essai de Server 2022 fait très bien l'affaire) pour pouvoir tripoter l'intégration Sysmon. C'est sur le réseau que les gens trébuchent. Mets chaque VM sur un adaptateur bridgé pour qu'elles partagent le même domaine de broadcast L2. C'est l'astuce qui permet à Suricata de vraiment voir le trafic dans un montage span. Saute-la et il reste planté là, sourd.
Hyper-V sur hôtes Windows : ton « span port » ici, c'est le switch virtuel External avec le « mode promiscuous » activé pour la VM Suricata. Sur VMware Workstation, c'est « VMnet0, Bridged » avec le mode promiscuous autorisé dans la config vmnet. Loupe ça et Suricata démarre parfaitement content, puis n'alerte jamais sur quoi que ce soit. Pénible à débugger.
Étape 1 : installer la stack Wazuh single-node
Wazuh livre un installeur unattended qui pose l'Indexer (son fork d'Elasticsearch), le Manager (le moteur de règles) et le Dashboard (son fork de Kibana), le tout d'un coup. Sur la VM Ubuntu 24.04 dédiée :
curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
sudo bash ./wazuh-install.sh -aLaisse-lui 10 à 15 minutes. Quand il termine, il laisse un wazuh-install-files.tar contenant les mots de passe générés. Copie-le hors de la machine tout de suite, avant de l'oublier. Les régénérer plus tard, c'est le genre de galère que tu n'as vraiment pas envie d'inviter.
# Wazuh install final stretch
Wazuh indexer cluster initialized.
Wazuh dashboard installation finished.
--- Summary ---
INFO: Wazuh web interface password: 8t&[redacted]
INFO: You can access the web interface https://<your-server-ip>
User: admin
Password: 8t&[redacted]
INFO: Installation finished.Ouvre https://<your-server-ip> dans un navigateur, passe outre l'avertissement de certificat auto-signé, connecte-toi en admin. Tu vas atterrir sur un dashboard qui montre exactement un agent (le manager qui se parle à lui-même) et zéro alerte. Pas de panique. C'est normal. La vraie télémétrie arrive juste après.
Étape 2 : déployer Suricata et faire remonter les alertes dans Wazuh
Tu peux poser Suricata sur la même VM pour un lab minuscule. Ou lui donner sa propre VM capteur si tu veux quelque chose de plus proche d'un vrai déploiement. Cette deuxième option, c'est celle vers laquelle je pencherais, même si pour un premier montage l'une comme l'autre conviennent. Sur Ubuntu 24.04 :
sudo apt update
sudo apt install -y suricata
sudo suricata-update
sudo suricata-update update-sources
sudo suricata-update enable-source et/open # Emerging Threats open ruleset
sudo suricata-updateOuvre /etc/suricata/suricata.yaml et pointe HOME_NET sur le sous-réseau de ton lab (disons "[192.168.10.0/24]"). Suricata moderne écrit déjà l'EVE JSON dans /var/log/suricata/eve.json par défaut, donc tu confirmes surtout que c'est bien actif. Ensuite, nomme ton interface de monitoring dans la section af-packet. Trompe-toi sur celle-là et tu te retrouveras à fixer un fichier de log vide, à te demander ce qui a bien pu casser.
Maintenant, il faut indiquer à Wazuh où vit ce log EVE. Sur le Wazuh manager, ajoute ceci à /var/ossec/etc/ossec.conf :
<ossec_config>
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
</ossec_config>sudo systemctl restart wazuh-manager
sudo systemctl enable --now suricataÉtape 3 : enrôler le premier agent sur un endpoint
Saute sur l'endpoint Linux que tu veux garder à l'œil :
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.0-1_amd64.deb
WAZUH_MANAGER='192.168.10.10' sudo dpkg -i ./wazuh-agent_4.10.0-1_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agentEn une trentaine de secondes, le manager enrôle automatiquement l'agent et commence à aspirer /var/log/auth.log et /var/log/syslog, les événements d'intégrité de fichiers sous /etc et /usr/bin, plus les résultats du scan de vulnérabilités. Voir ce premier agent basculer en « active », ça ne lasse jamais vraiment, même maintenant. Sous Windows, c'est la même idée avec wazuh-agent-4.10.0-1.msi. Pense juste à définir la variable d'environnement WAZUH_MANAGER avant de lancer le MSI, sinon l'agent démarre pointé sur, eh bien, rien du tout.
Étape 4 : le dashboard qui compte vraiment
Wazuh te livre une douzaine de dashboards d'office. Ignore la plupart pour l'instant. Deux sont ceux que tu ouvriras vraiment au début.
Le dashboard Security Events, c'est par là que je commence chaque triage du matin. Fais-en ta page d'accueil. Le module MITRE ATT&CK mâche les mêmes données en une heatmap tactiques-par-techniques, donc d'un coup d'œil tu vois quels types de comportements d'attaquant s'allument. Dans un lab tout neuf, cette heatmap a l'air presque vide la première semaine. Puis tu te mets à lancer des cas de test délibérés (étape 5) et elle se remplit vite. Ce moment-là, franchement, est plus satisfaisant qu'il n'a le droit de l'être.
Étape 5 : générer des alertes de test et vérifier le pipeline
La meilleure façon d'apprendre le dashboard ? Le faire sonner. Voici trois tests à faible risque, chacun déclenchant une classe d'alerte différente.
Brute-force SSH
Depuis un troisième hôte (ton laptop, une autre VM, ce que tu as sous la main), balance hydra sur l'endpoint Linux avec une liste de mots de passe que tu sais bidon. La règle Wazuh 5712 (brute-force SSH) se déclenche après cinq tentatives échouées en 120 secondes.
hydra -L users.txt -P bad-passwords.txt ssh://192.168.10.20En moins d'une minute, tu devrais voir une rafale d'alertes de niveau 5 (logins échoués). Puis celle que tu vises vraiment arrive : une alerte de corrélation de niveau 10 (brute-force sshd) qui apparaît sur le dashboard Security Events.
Intégrité de fichier
Sur l'endpoint Linux, touche un chemin surveillé et regarde la règle de file-integrity-monitoring (FIM) se déclencher. Petit test. Très satisfaisant.
sudo echo "test" >> /etc/important.conf
# Expected: rule 550 (file modified) fires within 15 secondsSuricata : signature de payload malveillant connu
Depuis le troisième hôte, fais un curl vers un domaine tiré de la liste publique d'URL malveillantes. Récupère un échantillon de test depuis la liste EICAR-test-domain, conçue pour être inoffensive exprès. Le ruleset ET de Suricata la matche et émet un événement EVE JSON. Wazuh le récupère, le tague, le fait remonter dans le module Suricata du dashboard. Voir ta propre sonde inoffensive ressortir en hit IDS, c'est, je crois, la façon la plus rapide de vraiment faire confiance au pipeline de bout en bout. Le lire ne fait jamais le même effet.
# Tail of /var/ossec/logs/alerts/alerts.log
** Alert 1748522473.31481: - ids,suricata,attack,mitre,
2026 May 29 14:01:13 wazuh-mgr->/var/log/suricata/eve.json
Rule: 86601 (level 10) -> 'Suricata: Alert - ET WEB_SERVER PHPMyAdmin probe detected'
Src IP: 192.168.10.99
Dst IP: 192.168.10.20
Mitre: T1190 (Exploit Public-Facing Application)Pièges classiques
- Suricata ne voit aucun trafic. Neuf fois sur dix, l'interface n'est tout simplement pas en mode promiscuous. Sur la VM Suricata, lance
ip link set ens33 promisc on, puis active aussi le mode promiscuous au niveau du switch virtuel. Les deux. Pas un seul. - L'agent apparaît en « disconnected » alors qu'il tourne. C'est un firewall sur l'hôte de l'agent qui mange discrètement le tcp/1514 sortant.
ss -tnpsur l'agent, plusjournalctl -u wazuh-agent, t'amènent droit dessus. - L'EVE JSON n'apparaît pas dans les alertes. En général, la balise
<localfile>a atterri dans la mauvaise section d'ossec.conf. Ou il y a une faute de frappe dans le chemin.sudo tail -f /var/ossec/logs/ossec.logte dit exactement quels fichiers le manager a réellement ouverts. - Dashboard lent au bout d'une semaine. Elasticsearch garde les indices 90 jours par défaut, et sur un disque de 50 Go ça se remplit plus vite que tu ne le crois. Pour un lab, mets une politique de cycle de vie des indices qui roule chaque jour et supprime après 14 jours, puis passe à autre chose.
- Dashboard inaccessible après un reboot. L'installeur single-node attend que tous les services montent ensemble, donc si Elasticsearch trébuche au démarrage, le dashboard te balance juste un 503 inutile. La première chose que je vérifie :
sudo systemctl status wazuh-indexer wazuh-manager wazuh-dashboard.
Sources et pour aller plus loin
Questions fréquentes
Je peux faire tourner ça sur un Raspberry Pi ?
Tu peux. Tout juste. Le Wazuh Manager et l'Indexer veulent ensemble 4 Go de RAM au minimum, et ils sont bien plus heureux avec 8. Un Raspberry Pi 5 avec 8 Go portera un ou deux agents, d'accord, mais la compaction de l'indexer rame et les recherches paraissent poussives. Honnêtement, un Intel NUC i5 d'occasion est le sweet spot, et c'est là que je t'orienterais plutôt.
La licence de l'Elastic stack pose problème ?
Pas pour ce que tu fais ici. Wazuh livre Elasticsearch et Kibana sous Elastic License v2 (forkés en wazuh-indexer et wazuh-dashboard), et pour un homelab ou un usage interne, l'ELv2 convient vraiment. Le jour où tu décides de revendre ça en SaaS, bascule sur la variante OpenSearch de l'installeur et toute cette restriction disparaît.
Combien de disque les données dévorent-elles ?
Avec deux endpoints et un capteur Suricata à la verbosité par défaut, je vois à peu près 1 à 2 Go d'événements indexés par jour. Donc prévois 30 à 60 Go si tu veux une fenêtre de 30 jours. Une fois que le disque local commence à serrer, des snapshots compressés vers du stockage objet te rachètent de la place sans toucher à quoi que ce soit en production.
Et OSSEC ou Velociraptor à la place de Wazuh ?
OSSEC, c'est la racine d'où Wazuh a grandi. Plus léger, mais pas de dashboard, et aucun des jeux de règles modernes. Velociraptor est une tout autre bête : forensics d'endpoint et DFIR, pas un pipeline SOC. Si tu apprends en 2026, fais Wazuh d'abord pour l'état d'esprit SIEM, puis Velociraptor pour l'état d'esprit forensic. Je n'irais chercher OSSEC qu'en troisième, et encore, seulement avec une raison concrète en main.
Est-ce que ça suffit pour me dire SOC-ready ?
Monter la stack te donne le vocabulaire. Pas le badge. Tu es SOC-ready le jour où tu peux raconter toute l'histoire sans notes : quelqu'un scanne le périmètre, Suricata le signale, Wazuh le relie à un login échoué, tu tries dans Kibana, tu griffonnes une courte note post-incident, puis tu ajustes la règle qui s'est déclenchée. Déroule cette boucle de bout en bout plusieurs fois, avec des schémas d'attaque différents à chaque fois. Trois, c'est un plancher raisonnable, même si plus ne fait jamais de mal.