Introduction
La containerisation a transformé les infrastructures applicatives, mais a également introduit de nouveaux vecteurs d’attaque souvent invisibles aux outils de sécurité traditionnels. Wazuh, en tant que SIEM et HIDS open source, propose des méthodes efficaces pour surveiller les environnements Docker, non pas uniquement au niveau container, mais aussi sur l’hôte, la couche réseau, et les processus.
Cet article présente une approche technique poussée pour tirer le meilleur parti de Wazuh dans un contexte Docker, avec ou sans Kubernetes, en respectant les contraintes de performance, d’intégrité, et d’évolutivité.
1. Comprendre le périmètre de Wazuh dans un contexte Docker
Wazuh peut interagir avec Docker de trois manières complémentaires :
- Agent installé sur l’hôte Docker
→ Supervision des containers via l’OS hôte (processus, fichiers overlay2, journalisation système) - Agent intégré dans l’image container
→ Cas particulier, utile pour des containers longue durée avec accès au système de fichiers persistant - API Docker supervisée par Wazuh
→ Requêtes régulières pour surveiller les événements du daemon Docker (start, stop, exec, etc.)
Chacune de ces approches présente des avantages spécifiques selon le niveau d’isolement des workloads.
2. Installation et configuration du module Docker
Prérequis sur l’hôte
- Docker installé et en fonctionnement
- L’utilisateur
wazuhdoit avoir accès à/var/run/docker.sockou à une API proxy sécurisée
Activation du module Docker dans ossec.conf :
<wodle name="docker-listener">
<enabled>yes</enabled>
<socket_path>/var/run/docker.sock</socket_path>
<run_on_start>yes</run_on_start>
</wodle>
Le module s’exécutera à chaque démarrage de l’agent et interceptera les événements Docker en temps réel.
3. Événements Docker collectés et analysés
Le module docker-listener capture plusieurs types d’événements :
- Container start/stop/restart
- Execution de commandes via
docker exec - Création/suppression d’images ou volumes
- Ajout/suppression de réseaux
- Modification des labels, variables d’environnement
Ces événements sont transmis à l’analyseur de règles de Wazuh, ce qui permet de générer des alertes précises, contextualisées et corrélées.
4. Exemple de règle personnalisée Wazuh pour Docker
Alerte si un container est lancé avec un binaire douteux :
<rule id="85010" level="10">
<if_sid>81400</if_sid>
<match>docker.*exec</match>
<match>/bin/nc|/bin/bash|/usr/bin/python</match>
<description>Execution suspecte via docker exec</description>
<group>docker,execution,anomalie</group>
</rule>
Cette règle surveille les commandes exécutées dans un container en cours d’exécution, ce qui est typique dans les phases de post-exploitation.
5. Intégration avec le File Integrity Monitoring (FIM)
Même si les containers sont éphémères, leur stockage repose sur une structure persistante dans /var/lib/docker/overlay2. Il est possible de surveiller cette couche pour :
- Détecter les modifications sur des fichiers système dans un container actif
- Identifier les écritures non planifiées sur les volumes montés
Exemple syscheck pour overlay2 :
<syscheck>
<directories check_all="yes" realtime="yes">/var/lib/docker/overlay2</directories>
<ignore>/var/lib/docker/overlay2/*/merged/tmp</ignore>
</syscheck>
6. Intégration avec Auditd : suivi des appels système dans les containers
Wazuh peut ingérer les logs d’Auditd, y compris ceux générés par les processus en espace utilisateur même dans les namespaces containers.
Auditd + Wazuh permet de :
- Suivre les appels
execve,open,connectdes process Docker - Corréler les ID utilisateur internes au container avec les UID/GID de l’hôte
- Surveiller les violations de règles SELinux/AppArmor à l’intérieur du container
7. Supervision réseau et latéralisation
Wazuh ne capture pas le trafic réseau lui-même, mais peut :
- Lire les logs
conntrack,iptables, ouebtablessur l’hôte - Utiliser une règle d’analyse pour identifier des flux sortants anormaux depuis une interface Docker
Exemple : flux réseau sortant vers un pays non autorisé :
<rule id="85020" level="12">
<if_sid>650</if_sid>
<match>docker0.*DST=.*RU|CN|KP</match>
<description>Flux réseau suspect depuis container Docker</description>
<group>docker,network,exfiltration</group>
</rule>
8. Gestion multi-hôte : Docker Swarm et Kubernetes
Dans Swarm :
- Déployer Wazuh agent sur chaque nœud manager et worker
- Utiliser un tag logique (cluster name, rôle, ID) dans le
agent.conf
Dans Kubernetes :
- Ne pas installer Wazuh dans les pods
- Installer l’agent sur les nœuds kubelet
- Surveiller
/var/lib/kubelet/pods,overlay2,containerdoucrio
Une bonne pratique consiste à centraliser les événements Wazuh dans un manager ou un cluster distribué, avec des dashboards Kibana personnalisés pour les environnements conteneurisés.
9. Recommandations et bonnes pratiques
- Ne pas surcharger l’agent Wazuh dans les hôtes avec trop de containers : privilégier des règles ciblées
- Ne pas utiliser FIM dans les répertoires de logs à haute fréquence (
/var/log/containers) sans filtre - Utiliser l’agent comme capteur comportemental, pas comme scanner antivirus
- Intégrer avec Sysmon (Windows) ou Auditd pour enrichir les corrélations
Conclusion
La surveillance de Docker via Wazuh dépasse la simple collecte d’événements système. Grâce à son module Docker natif, son intégration FIM/Auditd et sa capacité à corréler les événements avec des règles personnalisées, Wazuh peut être un véritable composant de détection comportementale dans un environnement conteneurisé.
En combinant cette approche avec une bonne segmentation réseau, une supervision des nœuds hôtes, et une gestion rigoureuse des droits d’accès Docker, les équipes DevSecOps peuvent maîtriser les risques liés aux conteneurs tout en maintenant l’agilité qu’ils offrent.
