Wazuh SIEM à petit budget : Pi, N100 ou cloud

Wazuh SIEM à petit budget tourne sans broncher sur du matériel que vous achetez pour moins de 100 EUR, ou que vous louez pour moins de 10 EUR par mois, même si la plaquette commerciale veut vous coller sur un gros cluster. Je le fais tourner des deux façons chez moi, alors j'ai choisi la machine la moins chère qui fonctionne vraiment pour les trois profils que je croise tout le temps. Le bricoleur du dimanche. Le sysadmin qui veille sur un seul bureau. Et le nomade dont les agents vivent partout sauf sur le LAN. Vous aurez la commande wazuh-install.sh exacte pour chacun, plus l'endroit où ça coince. Tout a tourné sur un seul banc : bundle Wazuh 4.10 single-node, Ubuntu 24.04 LTS, dashboard en HTTPS.

Wazuh se vend comme un SIEM d'entreprise. La plaquette commerciale veut vous coller sur un gros cluster. Ce que la plaquette ne dit pas : ce même installeur tout-en-un tourne sans broncher sur du matériel que vous pouvez acheter pour moins de 100 EUR, ou louer pour moins de 10 EUR par mois. Je le fais tourner des deux façons, chez moi. Du coup j'ai choisi la machine la moins chère qui fonctionne vraiment pour les trois profils que je croise tout le temps. Le bricoleur du dimanche. Le sysadmin qui veille sur un seul bureau. Et le nomade dont les agents vivent partout sauf sur le LAN. Vous aurez la commande wazuh-install.sh exacte pour chacun, plus l'endroit où ça coince, histoire de savoir à la seconde où ça cesse d'être une bonne affaire. Tout ce qui suit a tourné sur un seul banc d'essai : bundle Wazuh 4.10 single-node, Ubuntu 24.04 LTS, dashboard en HTTPS, entre 10 et 80 agents qui le martèlent comme la vraie vie sait le faire.

Pourquoi Wazuh à petit budget marche vraiment

Pourquoi ça passe ? L'installeur single-node « all-in-one » s'étale normalement sur trois machines. L'Indexer (un fork d'OpenSearch), le Manager, le Dashboard. Là, il les empile tous sur un seul hôte. Avec 10 agents qui remontent, le truc tourne au ralenti autour de 2,4 Go de mémoire résidente. Poussez-le à 80 agents sous charge normale et vous êtes plutôt vers 4,5 Go. Le CPU pique une fois par jour, chaque matin, quand la base de règles se recharge. Puis il retombe sous les 15 % sur une puce quatre cœurs et reste planté là. Largement à la portée d'un Raspberry Pi 5 8 Go ou d'un mini-PC Intel N100, et le nœud ARM le moins cher que Hetzner vous louera s'en sort aussi. Aucun n'est un vrai serveur. Ils font tous tourner la stack très bien quand même.

Ça devient intéressant plus tard, et tout se joue sur deux questions. Combien de temps gardez-vous les logs, et voulez-vous Suricata dans le mix ? Vous voulez 90 jours de logs hot et un IDS inline ? Sautez directement au chemin B, vous me remercierez. À l'aise avec 14 jours et pas d'IDS ? Alors, franchement, le chemin A ou le chemin C répondent à ça sans le moindre astérisque.

Bien dimensionner : combien d'agents par Watt

Cette colonne « peak agents ». Ce n'est pas un mur de briques. C'est l'endroit où l'Indexer se met à lâcher des événements en douce, parce que la heap de la JVM est configurée prudemment d'usine et que les files d'écriture bulk s'engorgent. Et personne ne vous prévient. Vous remarquez juste les trous dans votre timeline, des semaines plus tard. Donc gardez-vous de la marge. Moi, je table sur la moitié du pic annoncé en régime stable et je garde le reste comme réserve pour quand une tempête d'alertes débarque et que toutes les machines remontent en même temps.

Chemin A, Raspberry Pi 5 (~95 EUR)

C'est celui que je file à quiconque débute. Home labs. Une formation que vous êtes en train d'avaler. La poignée d'agents sous un même toit.

Ce que vous achetez : Pi 5 8 Go (75 EUR) + NVMe HAT + NVMe 64 Go (28 EUR pour les deux) + l'alim officielle 27 W (12 EUR) + un boîtier passif (10 EUR), ce qui tombe à 95 EUR. Ne mettez pas ça sur une carte SD. Booter depuis du NVMe est le plus gros gain de fiabilité que vous obtiendrez sur une machine qui ne s'éteint jamais, et c'est une assurance pas chère. Flashez Ubuntu 24.04 LTS ARM64 sur le NVMe avec rpi-imager, mettez le hostname à wazuh-pi, et déposez vos clés ssh dès le premier boot pour ne pas avoir à taper un mot de passe plus tard. Une fois que SSH répond :

sudo apt update && sudo apt install -y curl gnupg
ssh-copy-id wazuh-pi.local   # from your laptop
# enable cgroup v2 memory accounting (Wazuh installer requires it on ARM)
sudo sed -i 's/$/ cgroup_enable=memory cgroup_memory=1/' /boot/firmware/cmdline.txt
sudo reboot

Je le redis parce que ça compte : ne faites pas tourner Wazuh sur un Pi depuis une carte SD. L'Indexer écrit sur le disque sans arrêt. Une carte SD rend l'âme en 6 à 9 mois, et j'en ai déjà tué deux comme ça pour que vous n'ayez pas à le faire. NVMe HAT ou SSD USB. Sans exception.

Chemin B, mini-PC N100 (~180 EUR)

Si je dépensais mon propre argent pour poser une machine Wazuh dans un bureau, c'est celle que je prendrais. Elle convient au sysadmin d'une petite boîte qui veut une « machine Wazuh de bureau » qui reste là et fait son boulot. Elle couvre aussi un lab où vous voulez Suricata plus 90 jours pleins de rétention.

Prenez n'importe quelle unité Intel N100 livrée avec 16 Go de RAM et un NVMe 256 Go ou 500 Go. Un Beelink S12 Pro fait l'affaire. Un GMKtec NucBox G3 aussi, ou un Minisforum UN100, et ils sont assez proches en prix pour que j'achète simplement celui qui est en stock. Il sirote 8 à 12 W au repos et plafonne sous 25 W. Installez Ubuntu 24.04 LTS depuis une clé USB, pas d'arguments de boot capricieux cette fois. Deux choses le placent devant le Pi. D'abord, c'est du x86, donc tout l'écosystème de paquets Wazuh vous traite en citoyen de première classe et la doc arrête de prendre des pincettes à propos de l'ARM. Ensuite, ces 16 Go vous laissent de la place pour faire tourner Suricata à côté en daemon annexe, qui écrit dans ~/var/log/suricata/eve.json pendant que Wazuh le lit en continu.

# after first boot
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl gnupg ufw chrony fail2ban
sudo timedatectl set-timezone UTC
sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp   # Wazuh dashboard
sudo ufw allow 1514/tcp  # agent enrolment
sudo ufw enable

Chemin C, cloud ARM Hetzner CAX21 (~7 EUR/mois)

Optez pour ça quand vos agents vivent déjà aux quatre coins du monde. Des portables de boulot, une flotte de VPS, le serveur maison de votre cousin que vous finissez par administrer on ne sait comment. Et que vous préféreriez ne pas exposer votre WAN domestique juste pour leur donner un endroit où appeler.

Le CAX21 de Hetzner Cloud tourne sur des cœurs Ampere Altra, c'est du vrai ARM de classe serveur, pas une carte de dev qui fait semblant. Les perfs restent stables au lieu de se brider sur vous. Vous avez 4 vCPU, 8 Go de RAM, 80 Go de NVMe, plus 20 To de trafic sortant pour environ 0,0094 EUR de l'heure, plafonné autour de 7 EUR par mois. Cliquez sur commander, connectez-vous en SSH en moins de trois minutes, et vous voilà sur Ubuntu 24.04 ARM64. À partir de là, c'est la même install que le chemin A, sans le réglage cgroup. L'image Hetzner arrive déjà avec ça en place.

Le truc à bien peser ici, c'est la résidence des données. Vos logs quittent maintenant la maison. Hetzner est compatible RGPD et 100 % UE d'origine, donc pour la plupart d'entre nous c'est très bien. Mais si vous êtes une boîte régulée, allez voir votre DPO avant d'en tomber amoureux. L'autre point est l'évidence même. Cette machine fait désormais face à l'internet ouvert, donc la section firewall ci-dessous n'est pas optionnelle pour le chemin C.

L'install commune : wazuh-install.sh -a

C'est la partie qui fait flipper les gens, et honnêtement c'est la plus facile. Un curl, un script, terminé. Comptez 7 à 11 minutes sur le Pi, 4 à 6 sur le N100, environ 5 sur Hetzner. Allez vous faire un café. Lancez-le en root.

cd /root
curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

Quand il a fini, le script affiche le mot de passe admin et l'URL du dashboard local. HTTPS, certificat auto-signé, le classique. Copiez ce mot de passe quelque part de sûr dès maintenant. Il ne revient pas si vous scrollez trop loin, et la danse de récupération n'a rien d'amusant.

INFO: --- Summary ---
INFO: You can access the web interface https://<wazuh-dashboard-ip>
 User: admin
 Password: 9X<your-password-here>
INFO: Installation finished.

Maintenant, ouvrez cette URL du dashboard. Sur le chemin A ou B, faites-le depuis une autre machine du même LAN. Sur le chemin C, n'exposez pas le port du dashboard au monde entier. Faites plutôt un tunnel : ssh -L 8443:127.0.0.1:443 root@your-vps, puis allez sur https://127.0.0.1:8443. Votre navigateur va râler à propos du certificat auto-signé. Passez outre et connectez-vous avec le mot de passe admin que l'installeur vient de vous donner. Si tout s'est bien passé, vous atterrissez sur une vue Discover en direct, avec des événements qui arrivent déjà.

Enrôler les premiers agents

Le dashboard fait l'essentiel du boulot ici. Allez dans Agents, Deploy new agent, choisissez l'OS, et il vous crache la commande d'install exacte avec votre serveur déjà intégré. Voilà à quoi elles ressemblent sur les trois plateformes que je fais tourner :

# Linux endpoint
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.0-1_amd64.deb
sudo WAZUH_MANAGER='your-server-ip' dpkg -i wazuh-agent_4.10.0-1_amd64.deb
sudo systemctl enable --now wazuh-agent

# Windows endpoint (PowerShell)
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.10.0-1.msi -OutFile wazuh-agent.msi
msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER='your-server-ip'
NET START WazuhSvc

# macOS endpoint
curl -sO https://packages.wazuh.com/4.x/macos/wazuh-agent-4.10.0-1.pkg
sudo /usr/sbin/installer -pkg wazuh-agent-4.10.0-1.pkg -target /
echo 'WAZUH_MANAGER="your-server-ip"' | sudo tee /Library/Ossec/etc/preloaded-vars.conf
sudo /Library/Ossec/bin/wazuh-control start

Laissez-lui environ 60 secondes et l'agent apparaît sous Agents en Active. Le petit basculement de statut en vert est bizarrement satisfaisant, ou alors c'est juste moi. Maintenant, répétez l'opération pour chaque machine que vous possédez.

Réglages petit budget : rétention, indices, bruit des alertes

D'usine, Wazuh garde 90 jours en hot. Ça paraît généreux jusqu'à ce que vous fassiez le calcul. Sur un NVMe Pi de 64 Go avec 25 agents, le disque se remplit en six semaines environ, et un disque Indexer plein, c'est franchement un mauvais après-midi. Trois boutons vous ramènent à la raison.

• Rollover ILM plus court. Éditez /etc/wazuh-indexer/opensearch.yml et passez le cycle de vie de l'index wazuh-alerts à 14 jours en hot, puis suppression. C'est le gros levier. Ça réduit votre disque d'environ 80 %.
• Désactivez les groupes de règles bruyants. Dans Management, Rules, filtrez par groupe syslog, sshd, ossec, puis tuez tout ce qui se déclenche plus de 100 k fois par jour et que vous ne lirez jamais vraiment. Rien que ça réduit les écritures dans la base d'alertes d'environ 40 %.
• Compressez au repos. Basculez le codec de l'indexer sur best_compression via index.codec. Ça vous coûte peut-être 5 % de CPU, ça vous rend environ 30 % de disque. Prenez ce deal.

Encore un, chemin C uniquement. Cette machine est sur l'internet public, alors traitez-la comme telle. Mettez fail2ban sur SSH. Refusez tout le trafic entrant sur 1514/tcp sauf les IP d'agents en qui vous avez vraiment confiance, et laissez certbot poser un vrai certificat TLS sur le dashboard pour que Chrome arrête de vous engueuler à chaque connexion. Sautez tout ça et vous faites tourner un SIEM ouvert pour des inconnus.

Sources et pour aller plus loin

• Wazuh, documentation
• MITRE ATT&CK

Questions fréquentes