MAJ août 2026. La branche stable est passée à Wazuh 4.14.7 le 29 juillet. Les commandes ci-dessous nomment encore l’agent 4.14.5, remplace le numéro par 4.14.7 ou récupère le dernier .pkg/.msi sur la page des paquets Wazuh.

À l’épisode précédent, tu as monté une console de sécurité qui tourne. Wazuh en tout-en-un sur ton VPS durci, manager, indexeur et tableau de bord sur un seul nœud, dashboard verrouillé en Tailnet-only. Une belle machine. Qui, pour l’instant, ne voit qu’une seule chose : elle-même.

C’est déjà utile, ton serveur s’auto-surveille, valide ton durcissement, remonte ses propres CVE. Mais un SIEM qui ne regarde que le serveur sur lequel il tourne, c’est une caméra braquée sur sa propre boîte. Aujourd’hui, on la retourne vers le reste de la pièce.

On va déployer les agents Wazuh sur ton parc. Tes serveurs Linux, tes Mac, tes postes Windows. Chaque machine reçoit une sonde qui collecte ses journaux, ses événements de sécurité et l’intégrité de ses fichiers, et fait remonter tout ça au manager. C’est le moment où ton SIEM passe de myope à panoramique.

Un point non négociable, posé dès l’épisode 1 et qui commande tout ce chapitre. Cette remontée passe par le Tailnet, jamais par l’internet ouvert. Le manager n’ouvre ses oreilles que sur ton maillage privé. Un agent qui n’est pas dans ton Tailnet ne parle à rien.

Cette stack, je l’utilise au quotidien. Les commandes qui suivent sont celles que tu vas taper toi-même, dans l’ordre, sur ton manager puis sur chaque machine à surveiller.

Avant de commencer

Trois choses à avoir en tête avant la première commande.

Ce qu’il te faut. Le manager Wazuh de l’épisode 2, opérationnel. Un accès administrateur sur chaque machine à enrôler. Et surtout, chaque machine à surveiller doit être membre de ton Tailnet, exactement comme ton manager. C’est le prérequis structurant de cet épisode. Le tailscale up vu à l’épisode 1, tu le rejoues sur chaque endpoint. Sans ça, rien ne remonte.

Ce que ça change. À la fin, ton dashboard ne listera plus un seul agent, mais autant que tu auras de machines. Chacune remonte ses logs, son audit de configuration, ses vulnérabilités et l’intégrité de ses fichiers, au même endroit, sous ton œil unique.

Ce que ça ne change pas. Un agent observe, il ne bloque rien. Il te dit qu’une application a démarré, qu’un fichier a changé, qu’une connexion a échoué. Décider quelles applications ont le droit de se lancer sur tes Mac, ça viendra, c’est un autre outil, un autre épisode. Ici, on regarde. On ne barre pas encore la route.

Ouvrir les bonnes portes, et seulement celles-là

Avant de toucher au moindre endpoint, un geste sur le manager. Jusqu’ici, ton serveur n’écoutait le monde extérieur sur rien, et le dashboard était replié sur le Tailnet. Les agents distants, eux, ont besoin de joindre le manager sur deux ports.

• Le port 1515, pour l’enrôlement. C’est la poignée de main initiale, chiffrée, par laquelle un nouvel agent se présente et reçoit sa clé d’authentification.
• Le port 1514, pour la remontée des logs et des événements, une fois l’agent enrôlé.

Et c’est exactement là que se joue la souveraineté de toute la série. Ces deux ports, on les ouvre uniquement sur l’interface Tailscale, jamais en global.

sudo ufw allow in on tailscale0 to any port 1514 proto tcp
sudo ufw allow in on tailscale0 to any port 1515 proto tcp

Tu reconnais le geste, c’est celui de SSH à l’épisode 1, celui du dashboard à l’épisode 2. On autorise sur tailscale0, ton maillage chiffré, et nulle part ailleurs. Le piège, toujours le même, ce serait de taper sudo ufw allow 1514/tcp tout court. Cette commande-là offre ton SIEM aux scanners du monde entier. La nôtre le garde invisible.

Vérifie l’état de ton pare-feu.

sudo ufw status

Tu dois voir tes deux nouvelles règles portant bien la mention on tailscale0. Si un 1514/tcp global traîne, retire-le sans hésiter, c’est une brèche.

Dernière chose à noter, l’adresse Tailscale de ton manager, celle que chaque agent devra viser.

tailscale ip -4

C’est cette adresse, et pas l’IP publique du VPS, que tu passeras aux agents. L’IP publique n’écoute rien sur ces ports, de toute façon. Dans tout ce qui suit, je la note <IP_TAILSCALE_DU_MANAGER>.

Étape 1, enrôler un serveur Linux

On commence par le plus simple, un serveur Ubuntu ou Debian. Trois temps, ajouter le dépôt Wazuh, installer l’agent en lui donnant l’adresse du manager, le démarrer.

D’abord le dépôt officiel.

sudo apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /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 -a /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

Rien d’ésotérique. On importe la clé de signature du dépôt, on déclare le dépôt Wazuh, on rafraîchit la liste des paquets. C’est la routine APT habituelle.

Puis l’installation, avec l’astuce qui fait tout le travail. En préfixant la commande d’installation par la variable WAZUH_MANAGER, tu dis au paquet vers qui se tourner. L’agent s’enrôle tout seul auprès de ce manager pendant l’installation.

sudo WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent

Le WAZUH_AGENT_GROUP="linux" range d’emblée cette machine dans un groupe nommé linux. On verra plus bas à quoi servent les groupes, retiens juste que c’est le bon moment pour les assigner.

Enfin, on démarre le service et on l’active au boot.

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Et voilà, ton serveur Linux remonte. Si tu tournes sur du RHEL, de l’Alma ou du Rocky, le principe est identique, tu remplaces le dépôt APT par le dépôt YUM et apt-get install par dnf install, la variable WAZUH_MANAGER fonctionne pareil.

Étape 2, enrôler un Mac

Le Mac, c’est là que ça devient intéressant, parce que macOS a ses propres règles du jeu. Commençons par le déploiement, la subtilité vient juste après.

L’agent macOS se livre en paquet .pkg, et il en existe deux versions, une pour les Mac Apple Silicon et une pour les vieux Mac Intel. Sur un parc récent, c’est l’Apple Silicon.

curl -O https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.5-1.arm64.pkg
echo "WAZUH_MANAGER='<IP_TAILSCALE_DU_MANAGER>' && WAZUH_AGENT_GROUP='macos'" > /tmp/wazuh_envs
sudo installer -pkg wazuh-agent-4.14.5-1.arm64.pkg -target /

Le mécanisme change un peu de forme mais pas de fond. Sur macOS, les variables de déploiement ne se collent pas devant la commande, elles s’écrivent dans un fichier temporaire, /tmp/wazuh_envs, que l’installateur lit au passage. Le résultat est le même, l’agent connaît son manager et son groupe. Pour un Mac Intel, tu remplaces arm64 par intel64 dans les deux lignes qui la mentionnent.

On lance ensuite l’agent.

sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist

Sur macOS, l’agent vit sous /Library/Ossec/, et son binaire de contrôle est /Library/Ossec/bin/wazuh-control, avec les verbes start, stop et status si tu veux le piloter à la main.

La chausse-trappe macOS, TCC et l’accès disque complet

Maintenant, la vérité que la plupart des tutoriels passent sous silence. Sur macOS, ton agent va démarrer, s’enrôler, apparaître comme actif dans le dashboard, et pourtant rester à moitié aveugle.

La raison tient à TCC, pour Transparency, Consent and Control, le système de permissions par usage d’Apple. C’est lui qui fait surgir ces fenêtres « telle application veut accéder à vos documents ». TCC filtre l’accès aux dossiers sensibles, et il ne fait pas de cadeau. Or l’agent Wazuh n’est pas une application au sens d’Apple, c’est un ensemble de binaires empaquetés. Résultat, sans autorisation explicite, il se voit refuser l’accès aux zones que TCC protège. Sa surveillance d’intégrité des fichiers tourne, mais ne voit pas ce qu’elle ne peut pas lire.

La parade, c’est d’accorder à l’agent l’accès disque complet, le Full Disk Access. Sur un parc géré, ça se fait proprement par MDM, un profil de configuration poussé par Jamf ou équivalent, qui déclare la permission une fois pour toutes sur toutes les machines. Sur une ou deux machines, ça se règle à la main dans les réglages de confidentialité. C’est un cran de plus que sur Linux, et c’est spécifique à Apple, autant le savoir avant de s’étonner que le Mac remonte moins de choses que le serveur.

Étape 3, enrôler un poste Windows

Windows, dernier larron. L’agent s’installe via un paquet MSI, en mode silencieux, depuis une console PowerShell ouverte en administrateur.

msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_NAME="poste-compta" WAZUH_AGENT_GROUP="windows"

Même logique que partout, les variables passent le manager, un nom lisible pour le poste et son groupe. Le WAZUH_AGENT_NAME est confortable sur Windows, où tu vas vite avoir dix postes qui se ressemblent, autant les baptiser.

Puis on lance le service.

Start-Service WazuhSvc

En CMD classique, ce serait NET START WazuhSvc, au choix. L’agent s’installe sous C:\Program Files (x86)\ossec-agent.

Ce que Windows apporte de spécifique, c’est la lecture des journaux d’événements Windows, la fameuse triade Security, System et Application, là où atterrissent les échecs d’ouverture de session, les élévations de privilèges, les créations de comptes. Et le FIM peut y surveiller le registre, terrain de jeu favori des malwares qui veulent survivre à un redémarrage. Ton poste Windows n’est plus une boîte noire.

Étape 4, vérifier que tout remonte

Trois machines enrôlées, il est temps de s’assurer qu’elles parlent bien au manager. Retour sur le serveur Wazuh, une seule commande.

sudo /var/ossec/bin/agent_control -l

Elle liste tous tes agents avec leur identifiant, leur nom et leur état. Quatre états possibles, et il faut savoir les lire.

• Active, l’agent est connecté et remonte. C’est ce que tu veux voir partout.
• Pending, il vient de s’enrôler et attend sa première poignée de main complète. Transitoire, patiente une minute.
• Disconnected, il était connecté et ne l’est plus. Le manager considère un agent perdu s’il n’a pas donné signe de vie depuis quinze minutes.
• Never connected, il s’est enrôlé mais n’a jamais réussi à remonter. C’est le symptôme classique d’un port fermé ou d’une machine hors Tailnet, on y revient plus bas.

Le même tableau existe côté dashboard, en plus agréable à l’œil. La vue Agents t’affiche le décompte Active, Disconnected, Pending, Never connected, et la fiche de chaque machine, ses modules, sa dernière activité. C’est ta salle de contrôle, désormais peuplée.

Et là, le basculement. Chaque machine active fait tourner, sur elle-même, exactement les modules que ton serveur faisait tourner sur lui à l’épisode 2. L’audit de configuration contre les référentiels CIS. La détection des vulnérabilités connues sur ses paquets. La surveillance d’intégrité de ses fichiers. L’analyse de ses journaux. Sauf que maintenant, ce n’est plus une machine, c’est ton parc, et tout converge vers un seul écran.

Aller plus loin, surveiller un dossier précis

Par défaut, l’agent surveille déjà des répertoires système sensibles, ceux qu’un intrus aime modifier. Mais tu as sûrement un dossier qui compte plus que les autres, tes données clients, ta comptabilité, un partage métier. Tu veux savoir à la seconde près si quelqu’un y touche.

C’est le rôle du FIM, le File Integrity Monitoring, la surveillance d’intégrité des fichiers. Et plutôt que de l’éditer machine par machine, on utilise les groupes qu’on a assignés à l’enrôlement. Un groupe partage une configuration, poussée automatiquement par le manager à tous ses membres. Tu écris une fois, ça s’applique partout.

Sur le manager, tu édites le fichier de configuration partagée du groupe concerné, par exemple /var/ossec/etc/shared/linux/agent.conf, et tu y déclares le répertoire à surveiller.

<syscheck>
  <directories check_all="yes" realtime="yes">/srv/donnees-clients</directories>
</syscheck>

Deux attributs à comprendre. check_all="yes" enregistre tout ce qui caractérise un fichier, ses empreintes cryptographiques, sa taille, son propriétaire, ses permissions, ses dates. La moindre altération est repérée. realtime="yes" demande une surveillance en temps réel, l’alerte tombe à l’instant du changement, sans attendre le prochain scan.

Une nuance d’honnêteté sur ce temps réel. Il n’est disponible que sur Linux et Windows. Sur macOS, le FIM retombe sur des scans planifiés, périodiques. Une modification entre deux passages n’est vue qu’au passage suivant. Ce n’est pas un défaut de Wazuh, c’est une contrainte de la plateforme, mais mieux vaut le savoir avant de compter sur une alerte instantanée côté Mac. Autre détail qui piège, le répertoire doit exister avant que tu redémarres l’agent, sinon il est ignoré.

Si ça ne marche pas

Le déploiement d’agents, c’est simple quand tout va bien, et ça a toujours la même poignée de causes quand ça coince. Voici les vraies, dans l’ordre où tu les rencontreras.

Problème, l’agent reste en « Never connected »

Cause probable, dans neuf cas sur dix en ce qui nous concerne, un problème de chemin réseau. Soit les ports 1514 et 1515 ne sont pas ouverts sur tailscale0 côté manager, soit la machine n’est pas dans le Tailnet, soit tu as donné à l’agent l’IP publique du VPS au lieu de son IP Tailscale.

Solution, vérifie les trois. Sur le manager, sudo ufw status doit montrer tes règles 1514 et 1515 bien accrochées à tailscale0. Sur l’endpoint, tailscale status doit confirmer qu’il est bien dans le maillage. Et relis la valeur de WAZUH_MANAGER, elle doit pointer sur l’adresse Tailscale du manager, pas sur son IP publique.

Problème, l’agent passe de « Active » à « Disconnected »

Cause probable, il remontait, il ne remonte plus. Le manager coupe au bout de quinze minutes sans nouvelles. Souvent le service de l’agent s’est arrêté, ou la liaison Tailscale a sauté.

Solution, vérifie que le service tourne. sudo systemctl status wazuh-agent sur Linux, Start-Service WazuhSvc sur Windows, /Library/Ossec/bin/wazuh-control status sur macOS. Et jette un œil au log de l’agent, toujours au même endroit selon la plateforme, /var/ossec/logs/ossec.log sur Linux, /Library/Ossec/logs/ossec.log sur Mac, le dossier d’installation sur Windows.

Problème, le Mac est « Active » mais ne remonte presque rien

Cause probable, le fameux TCC. L’agent tourne, mais sans accès disque complet il est aveugle sur les zones protégées par macOS.

Solution, accorde-lui le Full Disk Access, par MDM sur un parc géré, à la main sur une machine isolée.

Problème, les agents sont « Active » mais le dashboard reste vide

Cause probable, attention, ce n’est pas un problème d’agent. Si les machines remontent bien mais que rien n’apparaît dans l’interface, le maillon qui coince est en aval, entre le manager et l’indexeur. Souvenir de l’épisode 2, c’est Filebeat qui pousse les alertes vers l’indexeur.

Solution, le diagnostic se fait côté serveur, pas côté agent. Tu vérifies que Filebeat parle bien à l’indexeur et que l’indexeur digère. Ne perds pas une heure à réinstaller des agents qui, eux, font parfaitement leur travail.

Le premier jour est bruyant, c’est normal

Un dernier mot d’honnêteté, parce que je préfère te le dire avant que tu le découvres seul. Le jour où tu branches dix machines d’un coup, ton dashboard va crépiter.

Chaque poste arrive avec son audit de configuration qui remonte des dizaines d’écarts par rapport au référentiel CIS. Chaque FIM signale des fichiers parfaitement légitimes qui changent au fil de l’usage. Au début, le bruit noie le signal, et c’est déstabilisant.

Ce n’est pas un bug. C’est l’état brut d’un SIEM qu’on vient d’allumer sur un parc réel. Le travail qui suit, calibrer les règles, écarter les faux positifs, régler les seuils pour n’être réveillé que quand ça compte, c’est du travail humain, pas de la magie logicielle. On l’a dit depuis l’ouverture de la série, le dur n’est pas la techno, c’est l’ajustement. Cet ajustement fin, l’alerting calibré, ce sera le bilan de l’épisode 7.

Pour l’instant, savoure. Ton SIEM ne se regarde plus le nombril, il voit ton réseau.

Pour les pressés

Ce que fait cet article. On déploie les agents Wazuh sur tout le parc, serveurs Linux, Mac, Windows, pour que chaque machine remonte ses logs, son audit de configuration, ses vulnérabilités et l’intégrité de ses fichiers au manager. Toute la remontée passe par le Tailnet, jamais par l’internet ouvert. On vérifie l’enrôlement, on étend la surveillance de fichiers, on encaisse le bruit du premier jour.

Concrètement, les commandes.

• Sur le manager, ouvrir les ports agents sur le Tailnet uniquement : sudo ufw allow in on tailscale0 to any port 1514 proto tcp puis idem pour 1515. Jamais en global.
• Prérequis absolu, chaque endpoint doit être dans le Tailnet (tailscale up).
• Linux : ajouter le dépôt Wazuh, puis sudo WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent, puis systemctl enable --now wazuh-agent.
• macOS : curl -O le .pkg arm64, écrire les variables dans /tmp/wazuh_envs, sudo installer -pkg ... -target /, sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist. Puis accorder le Full Disk Access à l’agent.
• Windows : msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_DU_MANAGER>" WAZUH_AGENT_GROUP="windows", puis Start-Service WazuhSvc.
• Vérifier depuis le manager : sudo /var/ossec/bin/agent_control -l, viser l’état Active partout.
• Étendre le FIM via le groupe, dans /var/ossec/etc/shared/<groupe>/agent.conf, bloc <syscheck> avec check_all="yes" realtime="yes" (temps réel Linux et Windows seulement, pas macOS).

En résumé

Tu es parti d’un SIEM qui ne voyait que lui-même, tu repars avec un SIEM qui voit ton parc.

Tu as ouvert les ports agents sur le seul Tailnet, 1514 et 1515 sur tailscale0, jamais en public, fidèle à la promesse souveraine de la série. Tu as enrôlé tes trois familles de machines, Linux en trois commandes, Mac en gérant la contrainte TCC, Windows en MSI silencieux. Tu as vérifié la remontée avec agent_control -l et dans le dashboard, et tu as étendu la surveillance d’intégrité sur tes dossiers sensibles via les groupes.

Chaque machine que tu branches est gratuite côté licence, c’est du 100 % open source, sans limite d’agents. Là où le SaaS américain facture au volume de logs, donc au nombre de machines, plus tu vois large, plus tu paies. Chez toi, voir large ne coûte rien.

Mais tu observes. Tu vois les attaques, tu ne les arrêtes pas encore. À l’épisode 4, on ajoute la première ligne de défense active, CrowdSec, le réseau communautaire qui bloque les attaquants connus avant même qu’ils ne frappent à ta porte. Ton SIEM commence à mordre.

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.
• Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows. Tu viens de le lire.
• É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.