Tu as suivi la série SIEM. Tu as monté Wazuh en tout-en-un sur ton VPS durci, puis déployé les agents. Ton dashboard s’allume, il liste tes machines, il affiche chiffres, courbes et alertes qui montent. Et là tu restes planté devant, avec une question bête que personne ne pose dans les tutos d’installation, tu en fais quoi de toutes ces infos ?

Parce qu’il faut être franc, le dashboard Wazuh, comme ça, de but en blanc, ben… ça ressemble un peu à un cockpit de Boeing. Un de nos lecteurs m’en a gentiment fait part, c’est l’origine de cette série d’articles.

Je dis bien série, parce qu’après avoir un peu réfléchi à la problématique, je me suis dit qu’un seul article au format normal ne suffirait pas.

La mauvaise réponse à la question initiale, celle vers laquelle tout te pousse, c’est de tout allumer d’un coup pour « ne rien rater ». La guirlande de Noël toute éclairée, c’est beau, mais avec tellement de trucs à regarder que tu ne sais plus où donner de la tête.

Wazuh n’est pas un antivirus. Il ne bloque rien avant que l’on active rootcheck et réponse active, il ne nettoie rien, en l’état il ne te protège pas. C’est un collecteur, un moteur de règles et un stockage. Il rend visible ce qui se passe sur tes machines. Toute sa valeur naît le jour où tu lui poses deux ou trois questions précises, pas le jour où tu le laisses tout observer et où tu essaies de suivre le match en même temps.

Aujourd’hui, on active tes trois premiers usages utiles, dans l’ordre, avec un fil rouge unique, ne pas te noyer sous les alertes. Ce tuto vise la branche 4.x de Wazuh, celle de toute la série SIEM, pas la nouvelle version 5.

Ce qu’il te faut

Rien à installer aujourd’hui, tout est déjà en place. On configure et on lit. Trois prérequis, tous hérités de la série.

• Ton manager Wazuh opérationnel, celui de l’épisode 2 SIEM.
• Au moins un agent en état Active, celui de l’épisode 3.
• Ton accès au tableau de bord, verrouillé en Tailnet, comme on l’a laissé.

Le déclic, Wazuh te montre, il ne te défend pas

Imagine une caméra de surveillance sans vigile derrière l’écran. Elle filme tout, parfaitement. Elle n’arrête personne. Wazuh, c’est ça, la caméra. Le vigile, c’est toi.

Et un vigile qui fixe quarante écrans en même temps ne voit plus rien. C’est le piège qui tue les SIEM de PME, pas en six mois, en deux semaines.

Classique, tu actives tous les modules le premier jour, chacun déverse ses centaines, voire milliers, d’événements, tu ne tunes rien, le signal se perd dans le vacarme, et au bout de quinze jours tu ne regardes même plus le dashboard.

Là, ton SIEM est mort. Pas planté, pas cassé, juste ignoré. Ce qui revient au même.

La règle d’or de tout ce qui suit, écris-la sur un post-it.

N’active aucune règle dont tu ne sais pas quoi faire quand elle se déclenchera. Si une alerte tombe et que ta seule réaction possible est de hausser les épaules, cette alerte n’aurait pas dû exister.

Trois usages, dans cet ordre précis. Chacun répond à une question, et à une seule.

Ce que ça change, ce que ça ne change pas

Ce que ça change. À la fin, tu ne regardes plus un mur d’alertes indistinct. Tu as trois vues qui t’apportent chacune une réponse claire, tu sais laquelle ouvrir et pourquoi.

Ce que ça ne change pas. Tu observes, tu ne bloques toujours pas. Décider quelles applications ont le droit de tourner, couper une connexion hostile, ça viendra, c’est un autre étage. Ici, on apprend à regarder juste avant d’apprendre à agir.

Premier usage, l’audit de configuration, ta seule liste qui a une fin

Commence par le SCA, pour Security Configuration Assessment, l’audit de configuration de sécurité. Et commence par lui pour une raison très concrète, c’est le seul module de Wazuh qui produit une liste finie.

Tous les autres crachent un flux sans fin, des événements qui tombent tant que tes machines tournent. Le SCA, lui, prend une machine, la compare à une politique de durcissement de référence, du type des référentiels CIS, et te rend un résultat borné, un score et une liste de points en échec. Cent quatre-vingts vérifications, une partie sans objet sur ta machine, et sur le reste tu en passes à peu près la moitié d’entrée. L’autre moitié te donne une liste d’échecs, bornée, que tu traites en une heure, sans rien tuner, dès le premier jour.

Dans le dashboard, ouvre la vue d’audit de configuration de l’un de tes agents, l’onglet Configuration Assessment si ton interface est en anglais. Tu y trouves un score global et le détail des contrôles, chacun avec son verdict, réussi ou échoué, et surtout la remédiation associée, la valeur attendue et comment l’atteindre.

Ta seule tâche, la voici.

1. Trie par contrôles en échec.
2. Repère ceux qui comptent vraiment pour toi, un service SSH mal configuré, un compte sans expiration de mot de passe, une permission trop large sur un répertoire système.
3. Corrige, relance le scan, regarde ton score grimper.

C’est gratifiant, et ce n’est pas un hasard si je te le fais faire en premier. Le SCA ne te réveille pas la nuit, il ne t’inonde pas.

C’est une check-list que tu ouvres, que tu traites, et que tu refermes. Le contraire exact d’une source d’angoisse. Le bon endroit pour prendre confiance avant d’affronter les modules qui, eux, parlent en continu.

Deuxième usage, la surveillance de fichiers, surveille peu pour entendre quelque chose

Le FIM, pour File Integrity Monitoring, la surveillance d’intégrité des fichiers. Tu l’as croisé à l’épisode 3, quand on l’a déployé via les groupes. Aujourd’hui, ce n’est pas la mécanique qui compte, c’est la discipline.

Le réflexe naturel, catastrophique, c’est de vouloir surveiller large. Tout /etc, tout /usr, tant qu’à faire tout le disque. Sauf que chaque mise à jour de paquets réécrit des dizaines de fichiers parfaitement légitimes, et le FIM t’alerte à chaque fois. Tu surveilles tout, donc tu entends un vacarme permanent, donc tu n’entends plus rien.

Fais l’inverse. Choisis trois ou quatre répertoires qui comptent vraiment, tes données clients, ta comptabilité, un partage métier, les configs critiques d’un service exposé. Ceux où un changement que tu n’as pas décidé est, en soi, une nouvelle qui mérite ton attention.

La configuration, tu la pousses proprement par le groupe, dans le fichier partagé du manager, exactement comme à l’épisode 3.

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

Le check_all="yes" enregistre tout ce qui caractérise un fichier, empreintes, taille, propriétaire, permissions, dates, la moindre altération est vue. Le realtime="yes" demande l’alerte à l’instant du changement.

Une nuance d’honnêteté déjà posée dans la série, ce temps réel n’existe que sur Linux et Windows. Sur macOS, le FIM retombe sur des scans planifiés, une modification entre deux passages n’est vue qu’au passage suivant.

Le principe à retenir tient en une phrase. Chaque répertoire surveillé est une promesse de réagir. Ne surveille que ce sur quoi tu bougerais vraiment. Le reste, c’est du bruit que tu t’infliges à toi-même.

À lire : Déploie Wazuh partout, le SIEM voit enfin ton réseau pour la mécanique complète des groupes et du FIM par agent.

Troisième usage, la détection de vulnérabilités, l’inventaire qui vieillit tout seul

En troisième seulement, la détection de vulnérabilités, l’onglet Vulnerability Detection du dashboard, que les versions récentes ne rangent plus à côté des deux premiers mais dans la section chasse aux menaces. Le principe est élégant, l’agent dresse l’inventaire des paquets installés sur chaque machine, et le manager croise cet inventaire avec un flux de failles connues, les fameuses CVE, pour Common Vulnerabilities and Exposures.

Le résultat, c’est une liste, par machine, des logiciels dont une version vulnérable est installée chez toi. Puissant. Et pour ça même, à manier en dernier des trois, parce que c’est le module qui déverse le plus. Sur un parc réel, tu vas voir tomber des centaines d’entrées, la plupart en sévérité basse ou moyenne.

Si tu débarques là-dessus sans avoir dompté les deux premiers usages, tu te noies. Alors on trie, on ne lit pas tout.

• Filtre par sévérité, concentre-toi sur le critique et le haut.
• Croise avec l’exposition réelle, une faille sur un service accessible depuis le Tailnet n’a pas le même poids qu’une faille sur un paquet jamais lancé, ou accessible depuis le net.
• Traite, patche ou mets à jour, puis laisse le prochain inventaire confirmer que la ligne a disparu.

Le piège ici est sournois. Une liste de vulnérabilités que tu ne tries jamais est pire que pas de liste du tout, parce qu’elle t’installe dans un faux sentiment de sécurité, tu crois savoir, tu ne fais rien. Un inventaire ne vaut que par le tri qui le suit, et par les correctifs qu’il engendre.

Ce qu’on n’allume surtout pas encore

Wazuh embarque d’autres modules, et deux d’entre eux te font de l’œil. Résiste.

Le rootcheck, la détection de rootkits et d’anomalies système, tourne déjà en tâche de fond par défaut. Ne t’y attarde pas pour autant, tant que les trois premiers usages ne sont pas calmes et lus, ce n’est pas là qu’est ta priorité du moment.

Et surtout, surtout, la réponse active. Ce module exécute des scripts en réaction à une alerte, bloquer une adresse, tuer un processus, couper une session. Sur le papier, c’est le rêve, le SIEM qui se défend seul. En vrai, branché avant d’avoir tuné tes règles, c’est le meilleur moyen de te verrouiller toi-même hors de ta propre infrastructure sur un faux positif. Il existe bien un garde-fou, une liste blanche d’adresses jamais bloquées où tu mets ton IP d’admin, mais c’est justement le genre de réglage qu’on ne cale bien qu’une fois qu’on maîtrise le reste.

La réponse active vient en dernier, une fois que tu connais tes règles par cœur et que tu leur fais confiance. Pas avant.

Tu vois le fil, il n’a pas changé depuis le premier paragraphe. On active dans l’ordre du plus calme au plus bavard, et on n’automatise une réaction que le jour où on sait exactement ce qu’elle va faire.

Les limites réelles

Wazuh est un excellent outil, souverain, gratuit, sans limite d’agents. Il a aussi des angles morts précis, que tu dois connaître pour ne pas te faire piéger.

Sur Mac, la surveillance de fichiers n’est pas en temps réel. On l’a vu plus haut, macOS retombe sur des scans planifiés. Concrètement, sur un parc majoritairement Apple, ne compte jamais sur une alerte à la seconde côté FIM, raisonne en fenêtres de scan et place tes garde-fous temps réel sur tes endpoints Linux et Windows.

Le SCA juge ta machine contre des politiques génériques. Certains contrôles ne collent pas à ta configuration réelle et remontent en échec alors que ton choix est délibéré et justifié. Ces faux positifs se trient à la main, une fois, puis se mettent de côté. C’est du travail d’humain, pas un défaut à corriger dans l’outil.

La détection de vulnérabilités raisonne au niveau du paquet et de sa version. Elle peut te signaler une CVE que ta distribution a déjà corrigée par un correctif rétroporté sans changer le numéro de version affiché. Résultat, une alerte pour un trou déjà bouché.

Croise systématiquement avec les bulletins de sécurité de ta distribution avant de t’affoler sur une ligne critique.

Aucune de ces limites n’est rédhibitoire. Toutes se gèrent, à condition de les avoir en tête avant, pas après une nuit blanche.

Si ça ne marche pas

Problème, l’audit de configuration reste vide ou à zéro

Cause probable, le module n’est pas actif sur l’agent, ou aucune politique n’est chargée pour ce système.

Solution, vérifie que le SCA est activé dans la configuration de l’agent et qu’une politique correspond bien à son système d’exploitation. Relance un scan et laisse-lui le temps de remonter.

Problème, le FIM ne t’alerte pas en temps réel sur un Mac

Cause probable, aucune. C’est le comportement attendu, le temps réel n’existe pas côté macOS.

Solution, rien à réparer. Sur Mac, tu raisonnes en scans périodiques. Si tu veux du temps réel, c’est sur tes endpoints Linux et Windows que ça se joue.

Problème, la détection de vulnérabilités n’affiche rien

Cause probable, le module vient d’être activé et son flux de failles n’a pas encore été téléchargé, ou l’inventaire des paquets n’est pas encore remonté.

Solution, patiente le temps du premier téléchargement du flux et de la première remontée d’inventaire. Si après un délai raisonnable c’est toujours vide, vérifie que le module est bien activé côté manager.

Pour les pressés

Ce que fait cet article. Une fois Wazuh installé et les agents déployés, il te dit quoi faire en premier, sans te noyer. Trois usages dans l’ordre, du plus calme au plus bavard, et deux modules qu’on laisse éteints exprès.

Concrètement, la marche à suivre.

1. Ouvre l’audit de configuration d’un agent, trie les contrôles en échec, corrige les quelques-uns qui comptent, relance le scan.
2. Restreins la surveillance de fichiers à trois ou quatre répertoires vraiment sensibles, via le groupe, bloc <syscheck> avec check_all="yes" et realtime="yes" (temps réel sur Linux et Windows seulement, pas macOS).
3. Active la détection de vulnérabilités, filtre par sévérité, traite le critique et le haut, ignore le tout-venant.
4. Laisse le rootcheck et surtout la réponse active éteints tant que le reste n’est pas calme et maîtrisé.
5. Règle d’or, n’active aucune règle dont tu ne sais pas quoi faire quand elle se déclenchera.

En résumé

Ton SIEM était allumé et muet pour toi, il devient lisible. Tu es parti d’un dashboard qui crépitait sans te parler, tu repars avec trois vues qui répondent chacune à une question nette.

L’audit de configuration t’a donné une liste finie à traiter en une heure. La surveillance de fichiers, restreinte à l’essentiel, ne t’alerte plus que sur ce qui compte. La détection de vulnérabilités te dresse l’inventaire de ce qui doit être patché, à condition que tu le tries. Et deux modules puissants restent au repos, parce qu’on ne les branche qu’une fois le reste dompté.

La techno n’était pas le dur. Le dur, c’est la retenue. Choisis peu de questions, mais réponds-y vraiment.

Et après, apprends à ton SIEM à agir

Tu viens d’apprendre à faire parler Wazuh, à lui poser peu de questions et à les écouter vraiment. C’est la moitié du chemin. L’autre moitié, c’est de le faire passer de spectateur à acteur, sans qu’il se retourne contre toi.

Cet article ouvre la marche. La suite s’écrit un cran à la fois, dans le même esprit, du plus calme au plus engageant.

• Épisode 2, écrire tes propres règles. Pour qu’il te réveille sur ce qui compte chez toi et se taise sur le reste.
• Épisode 3, brancher Santa sur Wazuh. Pour que ton SIEM voie non seulement ce qui s’exécute sur tes Mac sous contrôle d’exécution, mais aussi ce qu’on a bloqué.
• Épisode 4, la réponse active. Le module qu’on a laissé éteint exprès aujourd’hui, celui qui agit seul, bloque une adresse, coupe une session, et qu’on ne branche qu’une fois qu’on lui fait vraiment confiance.
• Épisode 5, la conformité SCA vers NIS2. Transformer l’audit de configuration en rapport de conformité présentable à un auditeur.

Et pour l’ajustement fin, calibrer les seuils, régler les notifications pour n’être réveillé que quand ça compte vraiment, la série a son chapitre dédié.

À lire : Alerting et coût total, le bilan de ton SIEM souverain

Rappel de la série

Cet article ouvre la suite de la série SIEM souverain, celle où on apprend à ton SIEM à lire puis à agir. Si tu débarques, rattrape d’abord les épisodes qui précèdent.

• Épisode 0, le fondement. 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.
• Épisode 4, la défense réseau. Bloquer les attaquants connus avant qu’ils n’arrivent.
• Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ta 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.