Une fois qu'on comprend les modules Wazuh et qu'on sait réagir à une alerte, l'étape suivante est très concrète, comment faire surveiller une machine par Wazuh. Bonne nouvelle, depuis les versions récentes, plus besoin de bricoler un dépôt ou de générer une clé à la main, le dashboard Wazuh génère lui-même la commande d'installation complète, prête à coller sur la machine cible. Ce guide montre cette méthode, la plus simple et la plus fiable, avant de couvrir la vérification et le déploiement en masse.

La méthode simple, le générateur de commande intégré

Dans le dashboard Wazuh, direction Agents (ou Endpoint Summary selon la version), puis Deploy new agent. L'assistant demande le système d'exploitation cible, éventuellement un nom d'agent et un groupe, puis génère une commande unique, déjà pré-remplie avec l'adresse de votre manager et la clé d'enrôlement. Il ne reste qu'à copier cette commande et la coller sur la machine à surveiller.

💡 Pourquoi c'est mieux que l'installation manuelle

La commande générée embarque déjà l'adresse du manager et gère l'enrôlement automatiquement, plus besoin d'échanger une clé à la main ni de se souvenir des paramètres exacts. C'est la méthode à privilégier dans l'immense majorité des cas.

Sur Linux

Une fois la commande copiée depuis le dashboard, ouvrez un terminal en root sur la machine cible et collez-la. Elle ressemble à ceci (les valeurs entre guillemets sont déjà remplies automatiquement par le générateur) :

curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.0-1_amd64.deb && \
sudo WAZUH_MANAGER='IP_DU_MANAGER' WAZUH_AGENT_NAME='NOM_AGENT' dpkg -i ./wazuh-agent.deb

Puis démarrer le service (le dashboard fournit généralement ces deux lignes à la suite de la commande d'installation) :

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

Sur RHEL/CentOS, le générateur produit la même logique avec un paquet .rpm et yum ou dnf à la place de dpkg, copiez-collez simplement la commande fournie par le dashboard pour la distribution sélectionnée.

Sur Windows

Même principe, sélectionnez Windows dans l'assistant, copiez la commande PowerShell générée, et collez-la dans un terminal PowerShell ouvert en administrateur sur la machine cible :

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi -OutFile $env:tmp\wazuh-agent.msi; `
msiexec.exe /i $env:tmp\wazuh-agent.msi /q WAZUH_MANAGER='IP_DU_MANAGER' WAZUH_AGENT_NAME='NOM_AGENT'; `
NET START WazuhSvc

Trois lignes, copiées-collées depuis le dashboard, exécutées une fois, et la machine remonte déjà ses événements quelques secondes plus tard.

Déploiement en masse

Comme la commande générée est un simple script autonome (pas d'interaction requise), elle se prête très bien à un déploiement automatisé sur plusieurs postes à la fois, en la collant dans une GPO de démarrage, un playbook Ansible, un script Intune, ou tout outil de déploiement déjà en place. Le nom d'agent peut être remplacé par une variable (nom de la machine) pour éviter les collisions si vous déployez sur plusieurs postes avec la même commande.

Vérifier que l'agent est bien connecté

Deux façons simples de confirmer que l'agent remonte bien ses données.

Depuis le dashboard, le module Agents liste l'ensemble du parc avec un statut par machine, système d'exploitation détecté, version de l'agent et dernière synchronisation. Un agent qui vient de s'installer apparaît en Active en général en moins d'une minute.

Depuis le manager en ligne de commande, pour une vérification rapide sans passer par l'interface :

/var/ossec/bin/agent_control -l

Un statut Never connected signifie que l'agent ne parvient pas à joindre le manager, généralement un problème réseau (port 1514 bloqué) ou une adresse de manager incorrecte dans la commande collée. Un statut Disconnected signifie que l'agent s'est connecté au moins une fois puis a cessé de répondre, souvent un service arrêté côté agent.

Erreurs fréquentes

SymptômeCause probable
Agent en statut Never connectedPort 1514 bloqué par un firewall entre l'agent et le manager, ou adresse manager erronée dans la commande collée
Agent en statut DisconnectedService arrêté côté agent, ou coupure réseau prolongée
La commande générée échoue au téléchargementPas d'accès internet sortant depuis la machine cible vers packages.wazuh.com, à prévoir en environnement isolé (proxy ou miroir local)
Agent connecté mais peu d'événementsNormal les premières minutes, la configuration de base (FIM, logs système) est activée par défaut et monte en charge progressivement

Pour diagnostiquer plus finement une connexion qui échoue, le fichier de log de l'agent reste la référence, /var/ossec/logs/ossec.log sur Linux, ou C:\Program Files (x86)\ossec-agent\ossec.log sur Windows.

Questions fréquentes

Faut-il générer une clé d'enrôlement manuellement pour ajouter un agent Wazuh ?
Non, plus besoin. Le générateur de commande du dashboard (Agents > Deploy new agent) intègre déjà l'adresse du manager et gère l'enrôlement automatiquement dans la commande fournie.

Quel port doit être ouvert pour connecter un agent Wazuh au manager ?
Le port 1514/TCP suffit pour le fonctionnement courant, remontée des événements et enrôlement compris via la commande générée par le dashboard.

Comment vérifier qu'un agent Wazuh est bien connecté au manager ?
Le plus simple est de consulter le module Agents du dashboard, qui affiche le statut de chaque machine en direct. En ligne de commande, /var/ossec/bin/agent_control -l donne le même résultat depuis le manager.

Peut-on déployer l'agent Wazuh en masse sur plusieurs postes ?
Oui, la commande générée par le dashboard est un script autonome sans interaction requise, elle se déploie telle quelle via GPO, Ansible, Intune ou tout outil de déploiement déjà utilisé sur le parc.

Besoin d'aide pour déployer Wazuh sur votre parc ?

ONYX-CYBER déploie et opère Wazuh pour ses clients MDR, du premier agent jusqu'à la supervision 24/7 complète.

Demander un diagnostic gratuit
← Retour au blog