MAJ août 2026. La branche stable est passée à Wazuh 4.14.7 le 29 juillet, retrait du daemon déprécié wazuh-dbd, dépendances Python à jour, correctifs de synchro cluster. La commande d’install pointe sur la branche 4.14, elle te sert directement la 4.14.7, rien à changer.

À l’épisode précédent, tu as monté un coffre-fort vide. Un VPS chez un hébergeur suisse, durci jusqu’à l’os, SSH par clé, pare-feu fermé, administration repliée derrière Tailscale, sauvegardes chiffrées hors-site. Une belle machine. Qui pour l’instant… ne surveille rien !

Aujourd’hui, on la remplit. On installe Wazuh, le cerveau de toute la pile, sur ce seul nœud. Manager, indexeur et tableau de bord, les trois composants centraux d’un SIEM, sur la même machine. C’est le mode tout-en-un, et c’est exactement ce dont une PME a besoin pour démarrer.

La promesse de la série tient en une phrase, on l’a posée dès l’ouverture. L’équivalent fonctionnel d’un Splunk, pour le prix d’un VPS. À la fin de cet article, tu auras une console de sécurité qui tourne, qui voit déjà ta propre machine, et qui t’a coûté zéro euro de licence. Là où le même périmètre chez un éditeur américain se chiffre de quelques milliers à plusieurs dizaines de milliers de dollars par an, selon la taille de ton parc, avec tes journaux logés dans une juridiction très défavorable à tes intérêts.

Cette stack, je l’utilise au quotidien. Les commandes qui suivent sont celles que tu vas taper toi-même, dans l’ordre, sur le serveur de l’épisode 1.

Trois composants, une seule machine

Avant d’installer, comprends ce que tu installes. Un SIEM Wazuh, ce n’est pas un bloc monolithique, ce sont trois rôles qui se passent le relais.

• Le manager, c’est le cerveau. Il reçoit les journaux, fait tourner le moteur d’analyse, corrèle les événements, applique les règles et lève les alertes. C’est lui qui décide qu’une rafale d’échecs de mot de passe à 3 heures du matin mérite qu’on te réveille.
• L’indexeur, c’est la mémoire. Il stocke et indexe les alertes pour que tu puisses les rechercher, filtrer, remonter dans le temps. C’est un fork d’OpenSearch, le moteur de recherche open source, lui-même issu d’Elasticsearch. Retiens ce détail, il va revenir nous compliquer la vie de la meilleure des façons.
• Le dashboard, c’est la vitre. L’interface web par laquelle tu lis tout ça, accessible sur le port 443. Il interroge le manager pour la configuration et l’indexeur pour les données.

Un quatrième larron travaille dans l’ombre, Filebeat, le tuyau qui pousse les alertes du manager vers l’indexeur. Tu n’y toucheras pas, mais quand quelque chose coince, c’est souvent lui qu’on regarde.

En entreprise, ces trois composants vivent sur des machines séparées, pour encaisser le volume et tenir la haute disponibilité. Pour une PME jusqu’à une centaine de machines surveillées, c’est du gâchis. Le mode tout-en-un les pose tous les trois sur le même serveur, et c’est largement suffisant pour démarrer. La documentation officielle dimensionne d’ailleurs ce mode pour 1 à 100 agents.

On reviendra plus bas sur le moment où le tout-en-un ne suffit plus. Mais pour l’instant, une seule machine, et on y va.

L’installation en une commande

Wazuh propose deux chemins. Le premier, step-by-step, installe l’indexeur, puis le manager, puis le dashboard séparément, en éditant les fichiers de configuration à la main. C’est pédagogique, c’est long, et tu n’en as pas besoin pour un mono-nœud. Le second, c’est l’assistant officiel, qui fait tout d’un coup.

On prend l’assistant.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

Décortiquons. Le curl -sO télécharge le script d’installation depuis le dépôt officiel Wazuh, branche 4.14. Le sudo bash ./wazuh-install.sh -a le lance avec les droits administrateur, et le flag -a veut dire all-in-one, tout-en-un. C’est ce flag qui demande à l’assistant d’installer et de configurer les trois composants sur cette même machine, de générer les certificats TLS qui chiffrent leurs échanges, et de fabriquer les mots de passe.

À la fin, l’assistant affiche dans la console le mot de passe du compte admin. Note-le, c’est ta première clé d’entrée. Si tu l’as raté en remontant le terminal, tu le récupères proprement :

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Cette commande extrait, sans le décompresser sur le disque, le fichier qui liste tous les mots de passe générés à l’installation. On va d’ailleurs s’en occuper dans un instant, parce que des mots de passe générés par un script, c’est un point de départ, pas un point d’arrivée.

Au moment où j’écris ces lignes, la version stable est la 4.14.5, sortie le 23 avril 2026. La cadence de patchs est quasi mensuelle sur la branche 4.14. L’URL d’installation pointe sur 4.14/, ce qui te sert toujours la dernière de la branche, donc tu n’as rien à changer tant que la 4.14 reste la stable. Si une 4.15 est sortie quand tu lis ça, vérifie la branche courante sur la page des notes de version avant de lancer la commande.

Le piège mémoire, là où 90 % des installs rament

Si tu ne dois retenir qu’une chose de cet épisode, c’est celle-ci. La cause numéro un des Wazuh qui rament, qui plantent, qui s’arrêtent au bout de trois jours, c’est la mémoire mal réglée sur l’indexeur.

Souviens-toi, l’indexeur est un fork d’OpenSearch, qui tourne sur la JVM, la machine virtuelle Java. Et la JVM réserve à son démarrage une zone de mémoire fixe pour travailler, qu’on appelle le heap (le tas). Trop petit, l’indexeur étouffe sous les données. Trop grand, il prend toute la RAM et asphyxie le manager, le dashboard et l’OS qui tournent à côté sur la même machine. C’est tout l’enjeu du mononœud, trois gros consommateurs de mémoire se partagent une seule enveloppe.

La règle officielle est nette, et elle est simple. Le heap, c’est la moitié de la RAM de la machine. Et les deux bornes, minimale et maximale, doivent être identiques.

Pourquoi identiques ? Parce que si tu laisses la JVM redimensionner son tas à chaud, en cours de route, elle passe son temps à réallouer de la mémoire au lieu d’indexer tes logs. En fixant le plancher et le plafond à la même valeur, tu lui dis « voilà ton bac à sable, ni plus ni moins, maintenant travaille ».

Ça se règle dans un fichier, /etc/wazuh-indexer/jvm.options.

sudo nano /etc/wazuh-indexer/jvm.options

Tu y cherches les deux lignes -Xms (la borne basse) et -Xmx (la borne haute), et tu les fixes à la moitié de ta RAM. Voici pourquoi l’épisode 1 t’a fait viser 12 Go de RAM et pas 8. Sur une machine de 12 Go, le heap prend 6 Go, et il reste 6 Go pour tout le reste, le manager, le dashboard, Filebeat, le système. De la marge pour respirer.

-Xms6g
-Xmx6g

Puis on redémarre l’indexeur pour qu’il prenne en compte la nouvelle valeur.

sudo systemctl restart wazuh-indexer

Si tu as démarré sur 8 Go pour tester, ta valeur de heap est -Xms4g / -Xmx4g, et tu vis avec 4 Go pour le reste, c’est juste mais ça tient pour une découverte.

Un dernier point pour les curieux. La règle « moitié de la RAM » a aussi un plafond absolu, ne jamais dépasser environ 32 Go de heap, au-delà la JVM perd une optimisation interne sur ses pointeurs mémoire. C’est une bonne pratique générale du moteur OpenSearch, pas une limite Wazuh spécifique, et à l’échelle d’une PME on en est très loin, donc tu peux l’oublier pour l’instant. Je te le mentionne pour que tu ne sois pas surpris si tu tombes dessus en montant un jour une grosse infra.

Tant qu’on parle de mémoire, une règle voisine. La JVM ne doit jamais swapper. Si le système se met à utiliser le disque comme mémoire d’appoint pour l’indexeur, les performances s’effondrent. Sur un VPS correctement dimensionné, avec le heap réglé à la moitié de la RAM, tu ne devrais pas swapper, mais c’est le premier réflexe de diagnostic le jour où ça rame.

Verrouiller la maison

L’installation t’a livré une console fonctionnelle. Elle t’a aussi livré des mots de passe générés par un script et un dashboard qui, par défaut, ne demande qu’à être joignable. Deux choses à reprendre en main avant de t’asseoir aux commandes.

Changer tous les mots de passe par défaut

Les mots de passe générés à l’installation ne sont pas mauvais en soi, mais ils traînent dans un fichier sur le serveur, et tu n’en es pas l’auteur. La bonne hygiène, c’est de tout régénérer avec tes propres secrets. Wazuh embarque un outil pour ça, déposé par l’assistant dans l’indexeur.

sudo bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -a -A -au wazuh -ap <MOT_DE_PASSE_ACTUEL>

Le flag -a cible tous les utilisateurs, -A applique le changement, et le couple -au / -ap fournit l’utilisateur et le mot de passe administrateur actuels, ceux récupérés tout à l’heure. En mode tout-en-un, l’outil propage automatiquement les nouveaux mots de passe aux composants concernés, tu n’as pas à les recoller un par un.

Tes nouveaux mots de passe doivent respecter une complexité minimale, 8 à 64 caractères, au moins une majuscule, une minuscule, un chiffre, et un symbole parmi .*+?-. Génère-les avec ton gestionnaire de mots de passe, ne les invente pas de tête.

Les certificats, déjà là

Bonne nouvelle, tu n’as rien à faire côté chiffrement interne. L’assistant -a a généré une petite autorité de certification maison et déposé les certificats TLS sous /etc/wazuh-indexer/certs/ et compagnie. Les trois composants se parlent déjà en chiffré entre eux. C’est fait, c’est propre, on n’y touche pas.

Le seul effet visible, c’est qu’au premier accès au dashboard, ton navigateur affichera un avertissement de sécurité, parce que le certificat est auto-signé et non reconnu par une autorité publique. C’est normal, et pour un dashboard qui ne sera de toute façon jamais exposé au public, c’est parfaitement acceptable. Tu cliques pour continuer, et tu passes.

Un mot pour anticiper la tentation. Tu pourrais vouloir un « vrai » certificat reconnu, via Let’s Encrypt. Surtout pas ici. Let’s Encrypt valide ton certificat en vérifiant que ton serveur répond sur internet, donc en t’obligeant à ouvrir un port au monde entier. C’est l’exact contraire de ce qu’on construit depuis l’épisode 1.

Si l’auto-signé te dérange vraiment, Tailscale peut émettre un certificat propre pour ton nœud sans aucune exposition publique. Mais franchement, pour une console que tu es seul à consulter, l’auto-signé suffit. On ne va pas percer le mur qu’on vient de bâtir pour faire disparaître un avertissement de navigateur.

Le dashboard, invisible depuis internet

C’est le geste de sécurité le plus important de l’épisode, et c’est celui qui sépare un SIEM souverain d’un SIEM posé sur le trottoir. Par défaut, rien ne garantit que ton dashboard reste privé. Le port 443 qui sert l’interface ne doit jamais être joignable depuis internet.

Tes tableaux de bord de sécurité, c’est la carte de tes faiblesses, c’est précisément ce qu’un attaquant rêve de consulter.

La règle de la série, posée à l’épisode 1, est inflexible. Aucun service public. Le dashboard vit derrière Tailscale, accessible à toi seul, comme l’a fait SSH avant lui.

Deux verrous, complémentaires. D’abord, on demande au dashboard de n’écouter que sur l’adresse Tailscale du serveur, pas sur toutes les interfaces. Ça se règle dans son fichier de configuration.

sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Tu y trouves la ligne server.host. Si elle vaut 0.0.0.0, le dashboard écoute partout, y compris sur l’IP publique. À proscrire. Tu la fixes sur l’IP Tailscale de ton serveur, celle que tu récupères avec tailscale ip -4, vue à l’épisode 1.

server.host: "<IP_TAILSCALE_DU_SERVEUR>"

Puis tu redémarres le dashboard.

sudo systemctl restart wazuh-dashboard

Ensuite, le pare-feu, en ceinture et bretelles. On reprend exactement le pattern de l’épisode 1 pour SSH, on autorise le port 443 uniquement sur l’interface du réseau privé, jamais en global.

sudo ufw allow in on tailscale0 to any port 443 proto tcp

Le piège à éviter, c’est de taper sudo ufw allow 443/tcp tout court. Cette commande-là ouvre le dashboard au monde entier. La nôtre ne l’ouvre que sur tailscale0, ton maillage chiffré. La nuance est tout sauf cosmétique, l’une expose ta console de sécurité aux scanners du monde entier, l’autre la rend invisible.

Le résultat, c’est un dashboard joignable seulement par un membre de ton réseau privé. Un scan de ton IP publique ne révèle rien. Conforme à la promesse souveraine, et conforme au bon sens.

Le tour du propriétaire

Connecte-toi. Depuis une machine membre de ton Tailnet, tu ouvres https://<IP_TAILSCALE_DU_SERVEUR> dans ton navigateur. Avertissement de certificat, tu passes. Login admin, ton nouveau mot de passe. Tu es dans la console.

Cette capture vient d’une instance Wazuh en production, déjà peuplée de plusieurs agents. Sur ton install toute fraîche, tu ne verras pour l’instant que l’agent 000, le serveur qui se surveille lui-même.

Et là, surprise agréable, ce n’est pas vide. Tu t’attendais peut-être à un écran inerte en attendant de déployer des agents. Pas du tout. En mode tout-en-un, le serveur embarque un agent local, sous l’identifiant 000, qui se surveille lui-même. Ta machine est déjà sous l’œil de ton propre SIEM, avant même d’avoir touché au reste de ton parc.

Concrètement, tu as déjà des données et plusieurs modules qui tournent sur ce nœud.

• SCA, pour Security Configuration Assessment, l’audit de configuration. Il est actif par défaut, sans rien régler, et il scanne ta machine contre des référentiels de durcissement type CIS. Il te dit où ta config s’écarte des bonnes pratiques, un service de trop, une permission trop large, un réglage SSH oublié. Tu vas probablement y retrouver, validées noir sur blanc, les décisions de durcissement de l’épisode 1.

• La détection de vulnérabilités. Wazuh inventorie les paquets installés sur la machine et les croise avec les bases de CVE connues. Si un de tes paquets traîne une faille publiée, il te le signale, avec la référence et la criticité. Une nuance d’honnêteté, contrairement au SCA et au FIM qui tournent seuls, le scan du nœud local ne se déclenche pas au premier démarrage. Il faut l’activer d’un réglage, passer vulnerability-detection.disable_scan_manager à 0 dans /var/ossec/etc/internal_options.conf puis redémarrer le manager. Deux minutes, et ta propre machine est scannée elle aussi.

• Le FIM, File Integrity Monitoring, la surveillance d’intégrité des fichiers. Il garde l’empreinte de tes fichiers sensibles et t’alerte si l’un d’eux change. Un fichier système modifié sans raison, c’est souvent le premier signe qu’on a un invité.

• L’analyse des logs locaux, qui digère les journaux de la machine et les transforme en alertes lisibles.

Et il y a les tableaux de bord de conformité, prêts à l’emploi. Wazuh livre des vues taguées PCI DSS, HIPAA, RGPD, NIST 800-53, TSC, avec génération de rapports. Chaque alerte porte l’identifiant de conformité qu’elle touche, par exemple un tag gdpr_IV_32 qui renvoie à l’article 32 du RGPD sur la sécurité du traitement. C’est exactement le matériau dont tu as besoin pour le triptyque de notification qu’on a martelé à l’ouverture, détecter, journaliser, prouver.

Une honnêteté nécessaire sur NIS2, justement. Wazuh fournit toutes les briques fonctionnelles que NIS2 réclame, monitoring continu, intégrité des fichiers, analyse de vulnérabilités, contrôle de configuration, reporting. Mais il n’existe pas de tableau de bord NIS2 prêt à cliquer comme il en existe un pour le RGPD.

Pour suivre NIS2 finement, tu construiras tes propres vues, en t’appuyant sur les tags RGPD et NIST déjà présents. Wazuh te donne l’outillage de conformité, il ne te rend pas conforme tout seul. Le calibrage des règles, le réglage de la rétention, la réponse aux alertes, ça reste du travail humain. On l’a dit dès l’ouverture, le dur n’est pas la techno, c’est l’ajustement.

Pour l’instant, ton SIEM se voit lui-même. Il ne voit pas encore le reste de ton parc informatique. C’est précisément l’objet de l’épisode suivant.

Quand le tout-en-un ne suffit plus

Le mono-nœud n’est pas magique, et je ne vais pas te vendre l’inverse. Il a un plafond, autant que tu saches où il se situe avant de t’y cogner.

La métrique qui compte, c’est l’EPS, les événements par seconde que ta machine encaisse. Un nœud bien dimensionné, de l’ordre de 16 Go de RAM et 8 vCPU, absorbe grossièrement 5 000 événements par seconde. Pour une PME jusqu’à 50 ou 100 machines surveillées, avec des journaux d’activité normaux, tu es très loin de saturer. Le tout-en-un tient largement.

Le jour où tu t’en approches, le symptôme est désagréable. Quand la file d’ingestion sature, Wazuh ne ralentit pas poliment, il jette les événements qu’il n’a pas le temps de traiter. Et un événement jeté, c’est une alerte que tu ne verras jamais. Une caméra qui arrête d’enregistrer aux heures de pointe.

À ce moment-là, tu passes en multi-nœuds, le manager d’un côté, l’indexeur de l’autre, voire plusieurs de chacun. Détail contre-intuitif mais important, Wazuh scale mieux horizontalement que verticalement. Deux nœuds à ressources moyennes valent mieux qu’un seul gros nœud. C’est un autre chantier, hors de cette série, mais tu sais désormais que la porte existe.

Pour une PME qui démarre, retiens ça, le tout-en-un est parfait pour commencer, pas conçu pour l’infini. Et entre les deux, il y a beaucoup de place.

Ce que ça t’aurait coûté ailleurs

On a tease ce chiffrage depuis l’ouverture de la série. Le moment est venu de le poser, pour cette brique précise.

Côté Wazuh, le coût de licence est de zéro. C’est du 100 % open source, sous licence GPLv2, et il n’y a aucun palier payant. Pas de limite d’agents, pas de limite d’utilisateurs, pas de limite de logs ingérés. Ta seule dépense, c’est le VPS que tu as monté à l’épisode 1, entre 15 et 30 euros par mois selon le dimensionnement, plus ton temps d’installation et de calibrage. Et c’est tout.

Côté Splunk, la facture a une autre tête. Un avertissement d’abord, Splunk ne publie pas ses tarifs officiellement, donc tout ce qui suit relève de l’ordre de grandeur reconstitué par des sources secondaires sérieuses, pas du devis officiel. Avec cette réserve, le principe est simple, tu paies au volume de logs avalé chaque jour, compté en gigaoctets par jour.

Reste à traduire ça pour un parc réel, parce qu’un prix au gigaoctet ne parle à personne tant qu’on ne sait pas combien de gigaoctets une PME produit. Repère utile, avec une journalisation de sécurité raisonnable, compte autour de cinquante mégaoctets de logs par poste et par jour, soit à peu près un gigaoctet par jour pour quinze à vingt postes. De là, on peut poser des montants, licence seule, en gardant Wazuh en miroir.

• 15 postes, environ 1 Go de logs par jour. Splunk, de l’ordre de 2 000 à 5 000 dollars par an. Wazuh, le VPS, 180 à 360 euros par an. Point.

• 50 postes, environ 4 à 5 Go par jour. Splunk, de l’ordre de 8 000 à 12 500 dollars par an. Wazuh, le même VPS, à l’euro près.

• 100 postes, environ 8 à 10 Go par jour. Splunk, de l’ordre de 15 000 à 25 000 dollars par an. Wazuh, toujours le même VPS.

Au-delà de cent postes surveillés, on change de monde des deux côtés, cluster multi-nœuds chez Wazuh, paliers à plusieurs dizaines voire centaines de milliers de dollars chez Splunk. C’est une autre échelle, hors du périmètre de cette série pensée pour la PME.

La différence n’est pas qu’une histoire de montant. C’est une histoire de trajectoire. Chez Wazuh, ton coût d’infrastructure est plat, tu ingères plus de logs, ton VPS encaisse, ta facture ne bouge pas. Chez Splunk, le compteur tourne à chaque gigaoctet supplémentaire. Plus ton SIEM voit large et profond, plus il te coûte cher, alors que voir large et profond, c’est littéralement son métier. Tu es facturé sur la qualité même de ta surveillance.

Et il y a la question qui a fondé cette série, celle de la juridiction. Tes logs, ce sont les empreintes complètes de ton réseau. Chez Wazuh, ils dorment sur ta machine, en Suisse, sous ton contrôle.

Chez le SaaS américain, ils sont réquisitionnables au titre du CLOUD Act. Le prix, c’est une chose. Qui détient la donnée, c’en est une autre, et c’est celle qui compte le plus.

En résumé

Tu es parti d’un coffre-fort vide, tu repars avec une console de sécurité qui tourne.

Tu as installé les trois composants de Wazuh en une commande, manager, indexeur et dashboard sur ton seul nœud. Tu as réglé le piège qui fait échouer la plupart des installs, le heap de l’indexeur à la moitié de la RAM, bornes identiques, ce qui justifie les 12 Go recommandés à l’épisode 1.

Tu as repris la main sur la sécurité, mots de passe régénérés, certificats déjà en place, et surtout dashboard verrouillé en Tailnet-only, invisible depuis internet. Et tu as fait ton premier tour du propriétaire, SCA, vulnérabilités, intégrité des fichiers, tableaux de bord RGPD, le tout sur ta propre machine, sans avoir déployé le moindre agent distant.

Le tout pour zéro euro de licence, là où l’équivalent SaaS se compte de quelques milliers à plusieurs dizaines de milliers de dollars par an selon la taille de ton parc, avec tes journaux les plus sensibles logés sous une juridiction étrangère.

Mais ton SIEM ne voit encore que lui-même. Il regarde sa propre machine, et c’est déjà précieux pour valider ton durcissement. Le vrai saut, c’est quand il commence à voir le reste, tes serveurs, tes Mac, tes postes Windows. C’est l’épisode 3, le déploiement des agents, le moment où ton SIEM commence vraiment à voir ton réseau.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

• Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
• Épisode 1, le socle. Le VPS durci hors CLOUD Act.
• Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud. Tu viens de le lire.
• Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
• Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
• Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
• Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
• Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.