Xavki Open your Sources.. live

Article

Wazuh 008 – Collecte des Docker métriques

par

Print Friendly, PDF & Email

TL;DR

Wazuh est une plateforme open source de sécurité utilisée pour centraliser des événements, détecter des comportements suspects, suivre la conformité et investiguer des incidents. Dans cet épisode, le sujet central est: Collecte des Docker métriques. L objectif est de relier la démonstration du dépôt Xavki à une compréhension exploitable en contexte SIEM/XDR.

La vidéo de référence

Vidéo: https://www.youtube.com/watch?v=0O8FHFtoQ6E

Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWoCKf3PDJYT2ihAd0hPZ0uM

Le dépôt support est disponible ici: https://gitlab.com/xavki/tutorials-wazuh. Le support de ce chapitre se trouve dans 08-docker-metrics/slides.md.

Wazuh et Collecte des Docker métriques: c est quoi exactement ?

Wazuh peut remonter des signaux de sécurité liés aux conteneurs. Les événements Docker racontent ce qui change, les métriques racontent comment cela se comporte. Les deux doivent être interprétés avec les logs applicatifs.

Le vrai sujet de ce chapitre est de collecter des événements et métriques Docker pour rapprocher sécurité endpoint et observabilité conteneur. Le dépôt Xavki sert de colonne vertébrale factuelle: il expose les slides, commandes et fichiers utilisés pendant les démonstrations. La documentation Wazuh complète ensuite le contexte officiel: architecture, installation, agents, règles, intégrations et capacités.

Points clés vus dans le support Xavki

  • create a wazuh group dedicated to container on master
  • add add agent to group container
  • add specific command to gather data on wazuh-manager
  • add docker decoders /var/ossec/etc/decoders/docker_decoders.xml
  • add docker rulesa/var/ossec/etc/rules/docker_rules.xml
  • then restart wazuh manager
  • and test with discover

Ces points doivent être lus comme une progression: d abord comprendre le signal collecté, ensuite vérifier la collecte, puis seulement interpréter l alerte dans Wazuh.

Modèle mental minimal

Un flux Wazuh se résume ainsi: endpoint -> agent -> Wazuh server -> rules/decoders -> indexer -> dashboard. Si une alerte manque, il faut diagnostiquer cette chaîne dans l ordre. Si une alerte existe mais n est pas utile, le problème vient souvent du bruit, du contexte ou du seuil de règle.

Découvrez  Wazuh 006 - File Integrity Monitoring et Who-Data

Notions et définitions sécurité

  • **SIEM**: Security Information and Event Management. Un SIEM centralise des journaux, applique des règles de corrélation et aide les équipes sécurité à investiguer des événements. Wazuh couvre ce rôle en collectant, normalisant, stockant et affichant des alertes.
  • **XDR**: Extended Detection and Response. Un XDR élargit la détection au-delà du simple log management: endpoints, comportements, réponse active, cloud, conteneurs et menaces. Dans Wazuh, cette dimension apparaît avec les agents, les capacités endpoint, la conformité et les intégrations.
  • **Agent**: Composant installé sur une machine surveillée. Il collecte des logs, fichiers, événements système, inventaires, métriques ou signaux de sécurité, puis les transmet au serveur Wazuh.
  • **Decoder**: Un decoder transforme un événement brut en champs compréhensibles: source IP, utilisateur, programme, message, code, chemin de fichier. Sans décodage correct, une règle peut ne jamais se déclencher.
  • **Rule**: Une règle Wazuh évalue un événement décodé et produit éventuellement une alerte avec un niveau, des groupes, une description et des métadonnées. Les règles sont le cœur de la détection.
  • **Faux positif**: Alerte techniquement déclenchée mais non pertinente dans le contexte. Un outil de sécurité utile doit gérer les faux positifs avec du tuning, des exceptions documentées et des seuils adaptés.
  • **Indicateur de compromission**: Un IOC est un signal qui peut indiquer une activité malveillante: IP, hash, domaine, chemin, comportement, signature IDS ou motif dans un log. Il doit toujours être interprété avec du contexte.
  • **Sécurité conteneur**: Surveillance des événements liés aux conteneurs: création, exécution, image, privilèges, montage, réseau, arrêt. Elle complète la sécurité hôte et applicative.
  • **Événement vs métrique**: Un événement décrit ce qui s est produit, par exemple un conteneur démarré. Une métrique mesure un état ou une tendance, par exemple CPU ou mémoire. Les deux sont utiles mais ne répondent pas aux mêmes questions.

Ces définitions sont volontairement pratiques. L objectif n est pas de réciter un glossaire, mais de savoir où placer chaque notion dans la chaîne de détection: collecte, décodage, corrélation, alerte, investigation et réponse.

Approfondissement spécifique

Pour les métriques Docker, l épisode est moins centré sur une attaque que sur la visibilité. Les métriques disent comment les conteneurs se comportent, mais elles doivent être corrélées avec événements, logs et contexte.

Une hausse CPU ou mémoire ne suffit pas à qualifier un incident. Elle devient intéressante si elle accompagne un conteneur inattendu, un scan, une erreur applicative ou une action utilisateur suspecte.

Découvrez  Wazuh 003 - Brute-force attack test on SSH

Le dépôt fournit aussi des fichiers concrets pour ce chapitre: 08-docker-metrics/slides.md. Ils servent à retrouver les commandes, scripts de test, sorties ou configurations utilisées dans la démonstration.

Ce que cet épisode cherche à modifier

  • collecter CPU, mémoire, réseau ou état conteneur
  • séparer métrique de performance et événement sécurité
  • croiser métriques Docker et alertes Wazuh

Chemin de diagnostic recommandé

  • vérifier l accès au socket ou aux logs Docker
  • différencier événement de conteneur et alerte sécurité
  • surveiller création, arrêt, suppression et anomalie
  • croiser avec les métriques et logs applicatifs
  • preuve attendue: collecter CPU, mémoire, réseau ou état conteneur
  • preuve attendue: séparer métrique de performance et événement sécurité
  • preuve attendue: croiser métriques Docker et alertes Wazuh

Points de vigilance sécurité

  • confondre métrique d observabilité et preuve d attaque
  • ne pas garder de contexte applicatif
  • alerter sur des seuils trop bas

Commandes et fichiers du chapitre

  • systemctl restart wazuh-manager

Liens utiles

Liens internes conseillés

Pour poursuivre la progression, consultez aussi Wazuh 009 – Integration of Suricata (IDS).

FAQ

Wazuh est-il plutôt un SIEM ou un XDR ?

Wazuh couvre des usages SIEM comme la centralisation, la corrélation et l analyse de logs, mais aussi des usages XDR comme la détection endpoint, la réponse active, la conformité, le FIM, la sécurité conteneur et l intégration de sources externes.

Faut-il installer un agent partout ?

Pas forcément partout dès le début. Il faut prioriser les machines critiques, les serveurs exposés, les bastions, les workloads sensibles et les environnements de test. L agent apporte la visibilité endpoint, mais il faut gérer bruit, charge et configuration.

Pourquoi mes alertes Wazuh ne remontent-elles pas ?

Les causes courantes sont une source de log absente, un agent non connecté, un mauvais chemin dans la configuration, une règle non déclenchée, un filtre dashboard trop restrictif ou un événement qui n est pas décodé comme prévu.

Wazuh remplace-t-il Prometheus ou Grafana ?

Non. Wazuh est orienté sécurité, conformité et détection. Prometheus et Grafana sont orientés métriques, SLO, tableaux de bord techniques et observabilité. Les deux approches se complètent.

Conclusion

Cet épisode 8 ajoute une brique à la compréhension de Wazuh. La bonne méthode consiste à partir du signal brut, vérifier la collecte, lire les règles déclenchées, puis seulement interpréter l alerte dans un contexte de sécurité réel. Le dépôt Xavki donne le lab, la documentation Wazuh donne le cadre officiel, et le deep dive permet de transformer la démonstration en méthode de diagnostic.

Explorer les formations Xavki

Pour apprendre dans l ordre, repartez depuis la roadmap ou une playlist thematique.

Roadmap DevOps YouTube