Chapitre 212 minIntermédiaire
Architecture de Wazuh : indexeur, serveur, tableau de bord et agents
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- nommer les quatre composants de Wazuh et le rôle de chacun ;
- suivre le trajet d'un événement, de l'agent au tableau de bord ;
- écrire les règles de pare-feu dont Wazuh a besoin ;
- choisir entre un déploiement tout-en-un et un déploiement réparti.
3 exercices corrigés1 schéma
L'architecture de Wazuh repose sur quatre composants : des agents installés sur les machines surveillées, un serveur qui analyse ce qu'ils envoient, un indexeur qui stocke et indexe les alertes, et un tableau de bord web pour les consulter. Ce chapitre décrit le rôle de chacun, le trajet d'un événement de l'agent jusqu'à l'écran, les ports à ouvrir dans le pare-feu, les fichiers à connaître et les façons de déployer l'ensemble.
Les quatre composants
| Composant | Rôle | Écoute sur | Basé sur |
|---|---|---|---|
| Agent | Installé sur chaque machine surveillée : lit les journaux, contrôle l'intégrité des fichiers, fait l'inventaire, évalue la configuration, exécute les réponses actives | Rien : c'est lui qui se connecte au serveur | Le code d'OSSEC, réécrit et enrichi |
| Serveur (Wazuh server, ou manager) | Inscrit les agents, reçoit leurs données et le syslog, les décode, leur applique les règles, produit les alertes ; expose une API | TCP 1514 (agents), TCP 1515 (inscription), TCP 55000 (API), UDP ou TCP 514 (syslog, si activé) | Idem, plus Filebeat pour l'envoi vers l'indexeur |
| Indexeur (Wazuh indexer) | Stocke les alertes et l'inventaire, les indexe pour la recherche | TCP 9200 (API), TCP 9300 à 9400 (cluster) | Une version adaptée d'OpenSearch |
| Tableau de bord (Wazuh dashboard) | Interface web : alertes, modules, gestion des agents et des règles | TCP 443 (HTTPS) | Une version adaptée d'OpenSearch Dashboards |
Le serveur ne garde pas les alertes pour l'affichage : il les écrit dans des fichiers, puis Filebeat, installé sur le serveur, les transmet à l'indexeur en TLS. Le tableau de bord, lui, interroge l'indexeur pour afficher les alertes et l'API du serveur pour gérer les agents et les règles.
Le trajet d'un événement
Suis un échec de connexion sur le contrôleur de domaine srv-ad, de l'instant où Windows l'écrit jusqu'à l'alerte à l'écran :
- Sur
srv-ad, Windows écrit l'événement 4625 dans le journal Sécurité. - Le module de collecte de l'agent (logcollector) lit le canal Sécurité, comme le lui demande sa configuration, et récupère l'événement.
- L'agent chiffre le message (AES par défaut) et l'envoie au serveur sur le port TCP 1514. Si le serveur est injoignable, il garde les messages dans un tampon et les renvoie au retour de la connexion, dans la limite de sa taille.
- Le serveur reçoit le message (démon
wazuh-remoted), vérifie qu'il vient d'un agent inscrit et le déchiffre. - Le moteur d'analyse (
wazuh-analysisd) décode l'événement : il en extrait les champs, ici le compte visé, l'adresse source, le code d'erreur. - Il applique les règles : l'événement correspond à la règle 60122 « Logon Failure - Unknown user or bad password », de niveau 5. Si les échecs venus de la même adresse atteignent le seuil de la règle 60204 « Multiple Windows Logon Failures » (huit en quatre minutes), celle-ci se déclenche à son tour, au niveau 10.
- Le niveau étant supérieur ou égal au seuil d'enregistrement (3 par défaut), le serveur écrit l'alerte dans
/var/ossec/logs/alerts/alerts.json. - Filebeat envoie l'alerte à l'indexeur (port 9200, en TLS), qui la range dans l'index du jour (
wazuh-alerts-4.x-2026.11.03, par exemple). - Sur le poste d'administration, le tableau de bord (port 443) interroge l'indexeur et affiche l'alerte, avec sa technique ATT&CK.
Ce que fait l'agent
L'agent n'est pas un simple transporteur de journaux. Chaque fonction est un module qui se règle dans son fichier de configuration ossec.conf, entre des balises dont le nom vient de l'histoire d'OSSEC :
| Module | Balise dans ossec.conf | Ce qu'il fait | Chapitre |
|---|---|---|---|
| Collecte des journaux | <localfile> | Lit des fichiers, des canaux d'événements Windows, journald | 5 |
| Intégrité des fichiers | <syscheck> | Calcule les empreintes des fichiers et des clés de registre surveillés, signale les changements | 8 |
| Évaluation de configuration | <sca> | Vérifie la configuration selon des politiques (CIS Benchmarks) | 9 |
| Inventaire | <wodle name="syscollector"> | Recense matériel, système, logiciels, ports, processus, comptes | 9 |
| Détection de rootkits | <rootcheck> | Cherche des traces connues de rootkits et des anomalies | 8 |
| Réponse active | <active-response> | Exécute les actions commandées par le serveur | 12 |
L'agent consomme peu : quelques dizaines de mégaoctets de mémoire et un processeur presque au repos, sauf pendant les analyses d'intégrité et d'inventaire, qu'il étale dans le temps.
Les ports à ouvrir
| Port | Protocole | De | Vers | Usage |
|---|---|---|---|---|
| 1514 | TCP | Chaque agent | Serveur | Événements des agents, chiffrés (UDP possible, désactivé par défaut) |
| 1515 | TCP | Chaque agent | Serveur | Inscription d'un nouvel agent (une fois) |
| 514 | UDP (ou TCP) | Équipements sans agent | Serveur | Syslog : désactivé tant qu'on ne le configure pas |
| 55000 | TCP | Tableau de bord, scripts d'administration | Serveur | API REST du serveur |
| 9200 | TCP | Serveur (Filebeat), tableau de bord | Indexeur | API de l'indexeur |
| 9300 à 9400 | TCP | Nœuds de l'indexeur | Nœuds de l'indexeur | Cluster de l'indexeur (déploiement réparti) |
| 1516 | TCP | Nœuds du serveur | Nœuds du serveur | Cluster des serveurs (déploiement réparti) |
| 443 | TCP | Administrateurs | Tableau de bord | Interface web |
Dans une installation tout-en-un, les ports 9200, 55000, 9300 et 1516 ne servent qu'entre les composants de la même machine : ils n'ont pas à être joignables depuis le réseau.
Chez Sorbier, le pare-feu pfSense filtre les flux entre zones (cours Cybersécurité des infrastructures). La matrice des flux s'enrichit de ces lignes :
| Source | Destination | Service | Justification |
|---|---|---|---|
VLAN 10 POSTES (192.168.10.64/26) | srv-journaux .180 | TCP 1514, TCP 1515 | Agents des postes |
VLAN 20 SERVEURS (192.168.10.176/28) | srv-journaux .180 | TCP 1514, TCP 1515 | Agents des serveurs (même VLAN : pas de passage par le pare-feu si le switch de cœur route le VLAN) |
srv-web .225 (DMZ) | srv-journaux .180 | TCP 1514 ; TCP 1515 le temps de l'inscription | Agent du serveur exposé |
Pare-feu (interface SERVEURS .190) | srv-journaux .180 | UDP 514 | Journal du pare-feu |
VLAN 99 ADMIN (192.168.10.208/28) | srv-journaux .180 | TCP 443 | Tableau de bord, réservé aux administrateurs |
Les fichiers à connaître sur le serveur
Tout Wazuh vit sous /var/ossec, le répertoire d'installation hérité d'OSSEC :
| Chemin | Contenu |
|---|---|
/var/ossec/etc/ossec.conf | Configuration du serveur : collecte, syslog, alertes, courriel, réponse active, intégrations |
/var/ossec/etc/rules/local_rules.xml | Tes règles personnalisées |
/var/ossec/etc/decoders/local_decoder.xml | Tes décodeurs personnalisés |
/var/ossec/etc/shared/<groupe>/agent.conf | Configuration centralisée envoyée aux agents d'un groupe |
/var/ossec/etc/client.keys | Les clés des agents inscrits |
/var/ossec/ruleset/rules, /var/ossec/ruleset/decoders | Les règles et décodeurs fournis par Wazuh : on les lit, on ne les modifie jamais (ils sont remplacés à chaque mise à jour) |
/var/ossec/logs/ossec.log | Journal de fonctionnement du serveur : le premier fichier à lire en cas de problème |
/var/ossec/logs/alerts/alerts.json | Les alertes produites, une par ligne, au format JSON |
/var/ossec/logs/archives/archives.json | Tous les événements reçus, même sans alerte, si l'archivage est activé (désactivé par défaut) |
Sur un agent Linux, on retrouve /var/ossec/etc/ossec.conf et /var/ossec/logs/ossec.log. Sur un agent Windows, tout est dans C:\Program Files (x86)\ossec-agent\ : ossec.conf, ossec.log et client.keys.
Tout-en-un ou réparti
| Déploiement | Principe | Quand le choisir |
|---|---|---|
| Tout-en-un (all-in-one) | Indexeur, serveur et tableau de bord sur la même machine | Laboratoire, PME jusqu'à une centaine d'agents |
| Réparti (distributed) | Chaque composant sur sa machine, l'indexeur et le serveur éventuellement en cluster de plusieurs nœuds | Au-delà de cent agents, ou quand la perte du SIEM n'est pas acceptable |
| Conteneurs | Images Docker officielles, en un seul nœud ou en plusieurs | Équipes qui exploitent déjà Docker |
| Machine virtuelle prête à l'emploi | Image OVA fournie par Wazuh | Démonstration rapide, pas pour la production |
| Wazuh Cloud | Service hébergé et payant de l'éditeur | Organisation qui ne veut pas exploiter le serveur |
La documentation de Wazuh donne ce dimensionnement pour un tout-en-un, avec 90 jours d'alertes conservées :
| Agents | Processeur | Mémoire | Stockage (90 jours) |
|---|---|---|---|
| 1 à 25 | 4 vCPU | 8 Gio | 50 Go |
| 26 à 50 | 8 vCPU | 8 Gio | 100 Go |
| 51 à 100 | 8 vCPU | 8 Gio | 200 Go |
Au-delà de cent agents, la documentation recommande le déploiement réparti. Le stockage dépend surtout du volume d'événements : un contrôleur de domaine chargé ou un pare-feu bavard pèsent bien plus que dix postes. Le chapitre 5 montre comment le maîtriser.
Exercices
Exercice 1 sur 3 Le bon composant Réussi À revoir
Pour chaque symptôme, dis quel composant (ou quel élément du trajet) tu vérifies en premier, et pourquoi.
- Le tableau de bord affiche « agent déconnecté » pour
srv-gestiondepuis ce matin. - Les alertes de la nuit sont bien dans
/var/ossec/logs/alerts/alerts.json, mais le tableau de bord n'en montre aucune après 2 h. - Le pare-feu est configuré pour envoyer son journal à
192.168.10.180, mais aucun événement du pare-feu n'arrive. - La page
https://192.168.10.180ne s'ouvre pas depuis le poste d'administration, alors que les agents fonctionnent.
Voir la réponseMasquer la réponse de l'exercice 1
- L'agent de
srv-gestion: service arrêté, machine éteinte, ou flux TCP 1514 bloqué. On litossec.logsur l'agent. Le serveur, lui, reçoit les autres agents. - Filebeat et l'indexeur : le serveur a produit les alertes, c'est leur transfert ou leur stockage qui bloque (service Filebeat arrêté, indexeur arrêté, disque plein). Le tableau de bord ne lit que l'indexeur.
- La réception syslog du serveur : elle est désactivée par défaut et doit être déclarée dans
ossec.confavec les adresses autorisées (chapitre 5). Puis le flux UDP 514 entre le pare-feu et le serveur. - Le tableau de bord (service arrêté) ou le flux TCP 443 depuis le VLAN 99. Les agents utilisent d'autres ports, leur bon fonctionnement ne prouve rien pour le 443.
Tu avais trouvé ?
Exercice 2 sur 3 La matrice des flux Réussi À revoir
Sorbier ouvre une agence à Marseille, dont les serveurs sont dans le réseau 10.30.1.160/28. Le routage entre sites passe par les liens loués et les routeurs du cours Routage et commutation. Écris les lignes de flux à ajouter pour que deux serveurs Windows de Marseille aient un agent Wazuh qui remonte à srv-journaux. Faut-il ouvrir le port 9200 ?
Voir la réponseMasquer la réponse de l'exercice 2
| Source | Destination | Service | Justification |
|---|---|---|---|
10.30.1.160/28 (serveurs de Marseille) | 192.168.10.180 | TCP 1514 | Événements des agents |
10.30.1.160/28 | 192.168.10.180 | TCP 1515 | Inscription des agents (peut être refermé ensuite) |
Il ne faut pas ouvrir le 9200 : seuls Filebeat et le tableau de bord parlent à l'indexeur, et ils sont sur la même machine que lui. Les agents ne parlent qu'au serveur. Aucun flux n'est à ouvrir dans l'autre sens : c'est toujours l'agent qui ouvre la connexion.
Tu avais trouvé ?
Exercice 3 sur 3 Dimensionner le serveur de Sorbier Réussi À revoir
Sorbier veut un agent sur ses 5 serveurs Windows, sur srv-web et sur 38 postes Windows 11. Avec le tableau de dimensionnement de la documentation, quelles ressources donner à srv-journaux pour garder 90 jours d'alertes ? Que changerait une conservation de 180 jours ?
Voir la réponseMasquer la réponse de l'exercice 3
5 + 1 + 38 = 44 agents : la ligne « 26 à 50 » s'applique, soit 8 vCPU, 8 Gio de mémoire et 100 Go de stockage pour 90 jours. Pour 180 jours, le stockage des alertes double à peu près : prévois 200 Go, plus une marge pour le système et les mises à jour. Le processeur et la mémoire, eux, dépendent du nombre d'événements par seconde, pas de la durée de conservation. Ces chiffres sont des ordres de grandeur : on vérifie la consommation réelle au bout de quelques semaines, avec la supervision.
Tu avais trouvé ?