1. Des images vulnérables ou non fiables
Une image Docker n'est pas un système d'exploitation « propre » : elle peut embarquer des paquets obsolètes, affectés par des failles connues, ou avoir été volontairement piégée pour du cryptominage ou l'installation d'une porte dérobée. Des images malveillantes ont déjà été découvertes jusque sur Docker Hub, le registre officiel. La protection passe par le choix des sources (registres officiels, éditeurs réputés) et par l'analyse systématique des images avant usage, avec des outils comme Trivy ou Snyk.
2. L'évasion de conteneur (container breakout)
Un conteneur compromis peut, dans certaines conditions, permettre à un attaquant d'en sortir pour atteindre directement l'hôte. Les causes les plus fréquentes sont des configurations dangereuses — le partage de l'espace des processus avec l'hôte, ou l'exécution en mode privilégié — mais des vulnérabilités dans Docker ou son moteur d'exécution runc permettent aussi ce type d'évasion (la CVE-2024-21626 en est un exemple connu). Le malware Hildegard, lié au groupe TeamTNT, combine exploitation de CVE et mauvaises configurations pour y parvenir. Une fois l'hôte atteint, l'attaquant a accès à tous les autres conteneurs qui y tournent, et potentiellement au reste du système d'information.
3. La compromission inter-conteneurs
Un conteneur compromis sert fréquemment de point de rebond vers d'autres conteneurs, vers l'Active Directory ou vers les postes utilisateurs — en particulier quand plusieurs conteneurs d'un même espace de noms partagent un réseau sans aucun filtrage entre eux, un cas de figure courant dans les environnements Kubernetes mal cloisonnés. La protection repose sur la segmentation réseau entre conteneurs et sur l'application, aux conteneurs, des mêmes règles de filtrage entrant/sortant qu'aux autres systèmes du réseau — ils sont souvent, à tort, oubliés de la politique de filtrage générale.
4. Le déni de service par épuisement de ressources
Par défaut, un conteneur ne porte aucune limite de mémoire ni de CPU : un processus gourmand, buggué ou franchement malveillant (cryptominage, par exemple) peut saturer l'hôte entier et affecter au passage tous les autres services qui y tournent. La parade consiste à fixer des quotas précis pour chaque conteneur — mémoire, CPU, nombre de redémarrages, descripteurs de fichiers — et à surveiller l'usage réel des ressources dans la durée, avec des outils comme Prometheus et Grafana.
5. La persistance et l'évasion de la détection
Les conteneurs sont, par construction, plus difficiles à surveiller pour un EDR classique qu'un poste de travail traditionnel — ce qui permet à un attaquant de maintenir un accès plus longtemps sans être repéré, que ce soit via un conteneur compromis durablement, une image piégée réutilisée, ou l'installation de Docker sur un hôte déjà compromis à d'autres fins. L'activité et les flux réseau des conteneurs doivent donc être explicitement intégrés à la supervision de sécurité (SIEM, SOC) et aux exercices de chasse aux menaces, et non traités comme un angle mort implicite.
Le MITRE tient une matrice ATT&CK dédiée aux conteneurs, qui recense les techniques d'attaque observées en conditions réelles sur ce type d'environnement — un signe que ces risques ne relèvent plus de la théorie. Vous exploitez des conteneurs en production et voulez vérifier que ces cinq points sont réellement couverts chez vous ? Parlons-en, ou découvrez notre offre de supervision et RMM, qui intègre la surveillance des charges applicatives dans la durée.