Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 06:28:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/privilege-escalation/docker-security
History
Translator 77db8f6d2e Translated ['linux-hardening/privilege-escalation/docker-security/docker
2023-12-19 21:54:17 +00:00
..
docker-breakout-privilege-escalation Translated ['linux-hardening/privilege-escalation/docker-security/docker 2023-12-19 21:54:17 +00:00
namespaces Translated to French 2023-06-03 13:10:46 +00:00
abusing-docker-socket-for-privilege-escalation.md Translated to French 2023-06-03 13:10:46 +00:00
apparmor.md Translated to French 2023-06-03 13:10:46 +00:00
authz-and-authn-docker-access-authorization-plugin.md Translated to French 2023-06-03 13:10:46 +00:00
cgroups.md Translated ['README.md', 'generic-methodologies-and-resources/pentesting 2023-06-14 15:05:39 +00:00
docker-privileged.md Translated to French 2023-06-03 13:10:46 +00:00
README.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2023-09-28 19:43:50 +00:00
seccomp.md Translated to French 2023-06-03 13:10:46 +00:00
weaponizing-distroless.md Translated to French 2023-06-03 13:10:46 +00:00

README.md

Sécurité Docker

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


Utilisez Trickest pour créer et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Sécurité de base du moteur Docker

Le moteur Docker effectue le gros du travail d'exécution et de gestion des conteneurs. Le moteur Docker utilise des fonctionnalités du noyau Linux telles que les espaces de noms et les groupes de contrôle pour fournir une isolation de base entre les conteneurs. Il utilise également des fonctionnalités telles que la réduction des capacités, Seccomp, SELinux/AppArmor pour une meilleure isolation.

Enfin, un plugin d'authentification peut être utilisé pour limiter les actions que les utilisateurs peuvent effectuer.

Accès sécurisé au moteur Docker

Le client Docker peut accéder au moteur Docker en local en utilisant un socket Unix ou à distance en utilisant le mécanisme http. Pour l'utiliser à distance, il est nécessaire d'utiliser https et TLS afin de garantir la confidentialité, l'intégrité et l'authentification.

Par défaut, il écoute sur le socket Unix unix:///var/
run/docker.sock et dans les distributions Ubuntu, les options de démarrage de Docker sont spécifiées dans /etc/default/docker. Pour permettre à l'API Docker et au client d'accéder au moteur Docker à distance, nous devons exposer le démon Docker en utilisant un socket http. Cela peut être fait en :

DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H
tcp://192.168.56.101:2376" -> add this to /etc/default/docker
Sudo service docker restart -> Restart Docker daemon

Exposer le démon Docker en utilisant http n'est pas une bonne pratique et il est nécessaire de sécuriser la connexion en utilisant https. Il existe deux options : la première option est pour le client de vérifier l'identité du serveur et la deuxième option est que le client et le serveur se vérifient mutuellement. Les certificats établissent l'identité d'un serveur. Pour un exemple des deux options, consultez cette page.

Sécurité des images de conteneurs

Les images de conteneurs sont stockées soit dans un référentiel privé, soit dans un référentiel public. Voici les options que Docker propose pour stocker les images de conteneurs :

  • Docker hub - Il s'agit d'un service de registre public fourni par Docker.
  • Docker registry - Il s'agit d'un projet open source que les utilisateurs peuvent utiliser pour héberger leur propre registre.
  • Docker trusted registry - Il s'agit de la mise en œuvre commerciale de Docker du registre Docker et il offre une authentification des utilisateurs basée sur les rôles ainsi qu'une intégration avec le service d'annuaire LDAP.

Analyse des images

Les conteneurs peuvent présenter des vulnérabilités de sécurité soit en raison de l'image de base, soit en raison des logiciels installés par-dessus l'image de base. Docker travaille sur un projet appelé Nautilus qui effectue une analyse de sécurité des conteneurs et répertorie les vulnérabilités. Nautilus fonctionne en comparant chaque couche d'image de conteneur avec un référentiel de vulnérabilités pour identifier les failles de sécurité.

Pour plus d'informations, lisez ceci (https://docs.docker.com/engine/scan/).

  • docker scan

La commande docker scan vous permet de scanner les images Docker existantes en utilisant le nom ou l'ID de l'image. Par exemple, exécutez la commande suivante pour analyser l'image hello-world :

docker scan hello-world

Testing hello-world...

Organization:      docker-desktop-test
Package manager:   linux
Project name:      docker-image|hello-world
Docker image:      hello-world
Licenses:          enabled

✓ Tested 0 dependencies for known issues, no vulnerable paths found.

Note that we do not currently have vulnerability data for your image.

trivy -q -f json <ontainer_name>:<tag>

snyk container test <image> --json-file-output=<output file> --severity-threshold=high

clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5

Signature des images Docker

Les images de conteneurs Docker peuvent être stockées soit dans un registre public, soit dans un registre privé. Il est nécessaire de signer les images de conteneurs afin de pouvoir confirmer qu'elles n'ont pas été altérées. L'éditeur de contenu se charge de signer l'image du conteneur et de la pousser dans le registre.
Voici quelques détails sur la confiance du contenu Docker :

  • La confiance du contenu Docker est une implémentation du projet open source Notary. Le projet open source Notary est basé sur le projet The Update Framework (TUF).
  • La confiance du contenu Docker est activée avec export DOCKER_CONTENT_TRUST=1. À partir de la version 1.10 de Docker, la confiance du contenu n'est pas activée par défaut.
  • Lorsque la confiance du contenu est activée, nous ne pouvons tirer que des images signées. Lorsque l'image est poussée, nous devons entrer une clé de balisage.
  • Lorsque l'éditeur pousse l'image pour la première fois en utilisant docker push, il est nécessaire d'entrer une phrase secrète pour la clé racine et la clé de balisage. Les autres clés sont générées automatiquement.
  • Docker a également ajouté la prise en charge de clés matérielles en utilisant Yubikey et les détails sont disponibles ici.

Voici l'erreur que nous obtenons lorsque la confiance du contenu est activée et que l'image n'est pas signée.

$ docker pull smakam/mybusybox
Using default tag: latest
No trust data for latest

Le résultat suivant montre que l'image du conteneur est en cours de téléversement vers Docker Hub avec la signature activée. Étant donné que ce n'est pas la première fois, l'utilisateur est invité à entrer uniquement la phrase secrète pour la clé du référentiel.

$ docker push smakam/mybusybox:v2
The push refers to a repository [docker.io/smakam/mybusybox]
a7022f99b0cc: Layer already exists
5f70bf18a086: Layer already exists
9508eff2c687: Layer already exists
v2: digest: sha256:8509fa814029e1c1baf7696b36f0b273492b87f59554a33589e1bd6283557fc9 size: 2205
Signing and pushing trust metadata
Enter passphrase for repository key with ID 001986b (docker.io/smakam/mybusybox):

Il est nécessaire de stocker la clé root, la clé du dépôt ainsi que la phrase secrète dans un endroit sûr. La commande suivante peut être utilisée pour sauvegarder les clés privées :

tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private

Lorsque j'ai changé d'hôte Docker, j'ai dû déplacer les clés root et les clés de dépôt pour pouvoir opérer à partir du nouvel hôte.


Utilisez Trickest pour créer facilement et automatiser des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Fonctionnalités de sécurité des conteneurs

Résumé des fonctionnalités de sécurité des conteneurs

Namespaces

Les namespaces sont utiles pour isoler un projet des autres, en isolant les communications entre les processus, le réseau, les montages... C'est utile pour isoler le processus Docker des autres processus (et même du dossier /proc) afin qu'il ne puisse pas s'échapper en abusant d'autres processus.

Il serait possible de "s'échapper" ou plus précisément de créer de nouveaux namespaces en utilisant la commande unshare (qui utilise l'appel système unshare). Docker l'empêche par défaut, mais Kubernetes ne le fait pas (au moment de la rédaction de ceci).
Quoi qu'il en soit, cela est utile pour créer de nouveaux namespaces, mais pas pour revenir aux namespaces par défaut de l'hôte (à moins d'avoir accès à certains /proc à l'intérieur des namespaces de l'hôte, où vous pourriez utiliser nsenter pour entrer dans les namespaces de l'hôte).

CGroups

Cela permet de limiter les ressources et n'affecte pas la sécurité de l'isolation du processus (à l'exception de release_agent qui pourrait être utilisé pour s'échapper).

Abandon des capacités

Je trouve que c'est l'une des fonctionnalités les plus importantes en ce qui concerne la sécurité de l'isolation des processus. Cela est dû au fait que sans les capacités, même si le processus s'exécute en tant que root, vous ne pourrez pas effectuer certaines actions privilégiées (car l'appel syscall renverra une erreur de permission car le processus n'a pas les capacités nécessaires).

Voici les capacités restantes après que le processus a abandonné les autres :

{% code overflow="wrap" %}

Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep

{% endcode %}

Seccomp

Il est activé par défaut dans Docker. Il aide à limiter encore plus les appels système que le processus peut effectuer.
Le profil Seccomp par défaut de Docker peut être trouvé à l'adresse https://github.com/moby/moby/blob/master/profiles/seccomp/default.json

AppArmor

Docker dispose d'un modèle que vous pouvez activer : https://github.com/moby/moby/tree/master/profiles/apparmor

Cela permettra de réduire les capacités, les appels système, l'accès aux fichiers et aux dossiers...

Namespaces

Les espaces de noms sont une fonctionnalité du noyau Linux qui partitionne les ressources du noyau de telle sorte qu'un ensemble de processus voit un ensemble de ressources tandis qu'un autre ensemble de processus voit un ensemble différent de ressources. La fonctionnalité fonctionne en ayant le même espace de noms pour un ensemble de ressources et de processus, mais ces espaces de noms font référence à des ressources distinctes. Les ressources peuvent exister dans plusieurs espaces.

Docker utilise les espaces de noms du noyau Linux suivants pour assurer l'isolation des conteneurs :

  • espace de noms pid
  • espace de noms mount
  • espace de noms réseau
  • espace de noms ipc
  • espace de noms UTS

Pour plus d'informations sur les espaces de noms, consultez la page suivante :

{% content-ref url="namespaces/" %} namespaces {% endcontent-ref %}

cgroups

La fonctionnalité du noyau Linux appelée cgroups permet de restreindre les ressources telles que le CPU, la mémoire, l'E/S, la bande passante réseau pour un ensemble de processus. Docker permet de créer des conteneurs en utilisant la fonctionnalité cgroups, ce qui permet de contrôler les ressources spécifiques du conteneur.
Voici un exemple de création d'un conteneur avec une limite de mémoire de 500 Mo pour l'espace utilisateur, une limite de mémoire du noyau de 50 Mo, une part de CPU de 512 et un poids de blkioweight de 400. La part de CPU est un ratio qui contrôle l'utilisation du CPU par le conteneur. Sa valeur par défaut est de 1024 et sa plage va de 0 à 1024. Si trois conteneurs ont la même part de CPU de 1024, chaque conteneur peut utiliser jusqu'à 33% du CPU en cas de conflit de ressources CPU. Le poids de blkioweight est un ratio qui contrôle l'E/S du conteneur. Sa valeur par défaut est de 500 et sa plage va de 10 à 1000.

docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash

Pour obtenir le cgroup d'un conteneur, vous pouvez faire :

docker run -dt --rm denial sleep 1234 #Run a large sleep inside a Debian container
ps -ef | grep 1234 #Get info about the sleep process
ls -l /proc/<PID>/ns #Get the Group and the namespaces (some may be uniq to the hosts and some may be shred with it)

Pour plus d'informations, consultez:

{% content-ref url="cgroups.md" %} cgroups.md {% endcontent-ref %}

Capacités

Les capacités permettent un contrôle plus précis des capacités autorisées pour l'utilisateur root. Docker utilise la fonctionnalité de capacité du noyau Linux pour limiter les opérations pouvant être effectuées à l'intérieur d'un conteneur, indépendamment du type d'utilisateur.

Lorsqu'un conteneur Docker est exécuté, le processus abandonne les capacités sensibles que le processus pourrait utiliser pour échapper à l'isolation. Cela vise à garantir que le processus ne pourra pas effectuer d'actions sensibles et s'échapper :

{% content-ref url="../linux-capabilities.md" %} linux-capabilities.md {% endcontent-ref %}

Seccomp dans Docker

Il s'agit d'une fonctionnalité de sécurité qui permet à Docker de limiter les appels système pouvant être utilisés à l'intérieur du conteneur :

{% content-ref url="seccomp.md" %} seccomp.md {% endcontent-ref %}

AppArmor dans Docker

AppArmor est une amélioration du noyau permettant de confiner les conteneurs à un ensemble limité de ressources avec des profils par programme :

{% content-ref url="apparmor.md" %} apparmor.md {% endcontent-ref %}

SELinux dans Docker

SELinux est un système d'étiquetage. Chaque processus et chaque objet de système de fichiers possède une étiquette. Les politiques SELinux définissent des règles sur ce qu'une étiquette de processus est autorisée à faire avec toutes les autres étiquettes du système.

Les moteurs de conteneur lancent des processus de conteneur avec une seule étiquette SELinux confinée, généralement container_t, puis définissent le conteneur à l'intérieur du conteneur avec l'étiquette container_file_t. Les règles de la politique SELinux disent essentiellement que les processus container_t ne peuvent lire/écrire/exécuter que des fichiers étiquetés container_file_t.

{% content-ref url="../selinux.md" %} selinux.md {% endcontent-ref %}

AuthZ & AuthN

Un plugin d'autorisation approuve ou refuse les demandes au démon Docker en fonction du contexte d'authentification actuel et du contexte de commande. Le contexte d'authentification contient tous les détails de l'utilisateur et la méthode d'authentification. Le contexte de commande contient toutes les données de demande pertinentes.

{% content-ref url="authz-and-authn-docker-access-authorization-plugin.md" %} authz-and-authn-docker-access-authorization-plugin.md {% endcontent-ref %}

DoS à partir d'un conteneur

Si vous ne limitez pas correctement les ressources qu'un conteneur peut utiliser, un conteneur compromis pourrait provoquer un déni de service (DoS) sur l'hôte où il s'exécute.

  • DoS du CPU
# stress-ng
sudo apt-get install -y stress-ng && stress-ng --vm 1 --vm-bytes 1G --verify -t 5m

# While loop
docker run -d --name malicious-container -c 512 busybox sh -c 'while true; do :; done'

Bande passante DoS

Une attaque de déni de service (DoS) par bande passante consiste à saturer la bande passante d'un système cible afin de le rendre indisponible aux utilisateurs légitimes. Cette attaque vise à épuiser les ressources réseau du système, ce qui entraîne une dégradation des performances ou une interruption complète du service.

L'attaquant peut utiliser différentes techniques pour mener une attaque de déni de service par bande passante, telles que l'envoi massif de requêtes, la génération de trafic réseau volumineux ou l'exploitation de vulnérabilités dans les protocoles réseau.

Pour se protéger contre une attaque de déni de service par bande passante, il est recommandé de mettre en place des mesures de sécurité telles que la limitation de la bande passante, la mise en place de pare-feux et de systèmes de détection d'intrusion, ainsi que la surveillance du trafic réseau pour détecter les anomalies.

Il est également important de garder les systèmes à jour avec les derniers correctifs de sécurité et de mettre en œuvre des politiques de sécurité solides pour réduire les risques d'attaques de déni de service par bande passante.

nc -lvp 4444 >/dev/null & while true; do cat /dev/urandom | nc <target IP> 4444; done

Intéressants drapeaux Docker

Drapeau --privileged

Sur la page suivante, vous pouvez apprendre ce que signifie le drapeau --privileged:

{% content-ref url="docker-privileged.md" %} docker-privileged.md {% endcontent-ref %}

--security-opt

no-new-privileges

Si vous exécutez un conteneur où un attaquant parvient à accéder en tant qu'utilisateur à faible privilège. Si vous avez un binaire suid mal configuré, l'attaquant peut l'exploiter et escalader les privilèges à l'intérieur du conteneur. Ce qui peut lui permettre de s'échapper.

L'exécution du conteneur avec l'option no-new-privileges activée empêchera ce type d'escalade de privilèges.

docker run -it --security-opt=no-new-privileges:true nonewpriv

Autre

Docker Security
Sécurité Docker

Docker is a popular containerization platform that allows you to package applications and their dependencies into a standardized unit called a container. While Docker provides many benefits in terms of portability and scalability, it also introduces security challenges that need to be addressed.

Docker est une plateforme de conteneurisation populaire qui vous permet de regrouper des applications et leurs dépendances dans une unité standardisée appelée conteneur. Bien que Docker offre de nombreux avantages en termes de portabilité et de scalabilité, il introduit également des défis en matière de sécurité qui doivent être résolus.

This section covers various security best practices and techniques to harden your Docker environment and protect it from potential attacks.

Cette section couvre différentes meilleures pratiques de sécurité et techniques pour renforcer votre environnement Docker et le protéger contre d'éventuelles attaques.

  • Docker Security Best Practices: Learn about the best practices to secure your Docker installation and containers.

  • Meilleures pratiques de sécurité Docker : Découvrez les meilleures pratiques pour sécuriser votre installation Docker et vos conteneurs.

  • Docker Image Security: Understand the security considerations when working with Docker images and how to mitigate potential risks.

  • Sécurité des images Docker : Comprenez les considérations de sécurité lors de la manipulation des images Docker et comment atténuer les risques potentiels.

  • Docker Network Security: Explore techniques to secure Docker networking and prevent unauthorized access to your containers.

  • Sécurité du réseau Docker : Explorez les techniques pour sécuriser le réseau Docker et empêcher l'accès non autorisé à vos conteneurs.

  • Docker Runtime Security: Learn about runtime security measures to protect your Docker containers from exploitation.

  • Sécurité d'exécution Docker : Découvrez les mesures de sécurité d'exécution pour protéger vos conteneurs Docker contre l'exploitation.

  • Docker Orchestration Security: Understand the security considerations when using Docker orchestration tools like Kubernetes and how to secure your orchestration environment.

  • Sécurité de l'orchestration Docker : Comprenez les considérations de sécurité lors de l'utilisation d'outils d'orchestration Docker tels que Kubernetes et comment sécuriser votre environnement d'orchestration.

  • Docker Logging and Monitoring: Learn about the importance of logging and monitoring in Docker security and how to implement effective logging and monitoring practices.

  • Journalisation et surveillance Docker : Découvrez l'importance de la journalisation et de la surveillance dans la sécurité Docker et comment mettre en œuvre des pratiques de journalisation et de surveillance efficaces.

  • Docker Compliance and Auditing: Understand the compliance requirements for Docker environments and learn how to perform audits to ensure compliance.

  • Conformité et audit Docker : Comprenez les exigences de conformité pour les environnements Docker et apprenez comment effectuer des audits pour garantir la conformité.

  • Docker Security Tools: Explore various security tools and utilities that can help you assess and enhance the security of your Docker environment.

  • Outils de sécurité Docker : Explorez divers outils de sécurité et utilitaires qui peuvent vous aider à évaluer et à améliorer la sécurité de votre environnement Docker.

Contributing
Contribution

Contributions are welcome! If you have any security best practices, techniques, or tools related to Docker security, feel free to submit a pull request.

Les contributions sont les bienvenues ! Si vous avez des meilleures pratiques de sécurité, des techniques ou des outils liés à la sécurité Docker, n'hésitez pas à soumettre une demande d'extraction.

License
Licence

This project is licensed under the MIT License - see the LICENSE file for details.

Ce projet est sous licence MIT - consultez le fichier LICENSE pour plus de détails.

#You can manually add/drop capabilities with
--cap-add
--cap-drop

# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined

# You can manually disable seccomp in docker with
--security-opt apparmor=unconfined

# You can manually disable selinux in docker with
--security-opt label:disable

Pour plus d'options --security-opt, consultez: https://docs.docker.com/engine/reference/run/#security-configuration

Autres considérations de sécurité

Gestion des secrets

Tout d'abord, ne les mettez pas à l'intérieur de votre image !

De plus, n'utilisez pas de variables d'environnement pour vos informations sensibles. Toute personne qui peut exécuter docker inspect ou exec dans le conteneur peut trouver votre secret.

Les volumes Docker sont meilleurs. Ils sont la méthode recommandée pour accéder à vos informations sensibles dans la documentation Docker. Vous pouvez utiliser un volume comme système de fichiers temporaire stocké en mémoire. Les volumes éliminent le risque de docker inspect et de journalisation. Cependant, les utilisateurs root pourraient toujours voir le secret, tout comme toute personne pouvant exec dans le conteneur.

Encore mieux que les volumes, utilisez les secrets Docker.

Si vous avez juste besoin du secret dans votre image, vous pouvez utiliser BuildKit. BuildKit réduit considérablement le temps de construction et offre d'autres fonctionnalités intéressantes, notamment la prise en charge des secrets au moment de la construction.

Il existe trois façons de spécifier le backend BuildKit afin de pouvoir utiliser ses fonctionnalités dès maintenant :

  1. Définissez-le en tant que variable d'environnement avec export DOCKER_BUILDKIT=1.
  2. Démarrez votre commande build ou run avec DOCKER_BUILDKIT=1.
  3. Activez BuildKit par défaut. Définissez la configuration dans /etc/docker/daemon.json sur true avec : { "features": { "buildkit": true } }. Ensuite, redémarrez Docker.
  4. Ensuite, vous pouvez utiliser les secrets au moment de la construction avec le drapeau --secret comme ceci :
docker build --secret my_key=my_value ,src=path/to/my_secret_file .

Lorsque votre fichier spécifie vos secrets sous forme de paires clé-valeur.

Ces secrets sont exclus du cache de construction de l'image et de l'image finale.

Si vous avez besoin de votre secret dans votre conteneur en cours d'exécution, et pas seulement lors de la construction de votre image, utilisez Docker Compose ou Kubernetes.

Avec Docker Compose, ajoutez la paire clé-valeur des secrets à un service et spécifiez le fichier secret. Un grand merci à la réponse de Stack Exchange pour le conseil sur les secrets de Docker Compose, dont l'exemple ci-dessous est adapté.

Exemple docker-compose.yml avec des secrets :

version: "3.7"

services:

my_service:
image: centos:7
entrypoint: "cat /run/secrets/my_secret"
secrets:
- my_secret

secrets:
my_secret:
file: ./my_secret_file.txt

Ensuite, démarrez Compose comme d'habitude avec docker-compose up --build my_service.

Si vous utilisez Kubernetes, il prend en charge les secrets. Helm-Secrets peut faciliter la gestion des secrets dans K8s. De plus, K8s dispose de contrôles d'accès basés sur les rôles (RBAC), tout comme Docker Enterprise. RBAC facilite la gestion et la sécurisation de l'accès aux secrets pour les équipes.

gVisor

gVisor est un noyau d'application, écrit en Go, qui implémente une partie importante de la surface du système Linux. Il comprend un runtime Open Container Initiative (OCI) appelé runsc qui fournit une frontière d'isolation entre l'application et le noyau hôte. Le runtime runsc s'intègre à Docker et Kubernetes, ce qui permet d'exécuter facilement des conteneurs sandbox.

{% embed url="https://github.com/google/gvisor" %}

Kata Containers

Kata Containers est une communauté open source qui travaille à la création d'un runtime de conteneur sécurisé avec des machines virtuelles légères qui offrent des performances et une isolation des charges de travail plus solides en utilisant la virtualisation matérielle comme deuxième couche de défense.

{% embed url="https://katacontainers.io/" %}

Conseils récapitulatifs

  • N'utilisez pas le drapeau --privileged ou montez un socket Docker à l'intérieur du conteneur. Le socket Docker permet de créer des conteneurs, il est donc facile de prendre le contrôle total de l'hôte, par exemple en exécutant un autre conteneur avec le drapeau --privileged.
  • N'exécutez pas en tant que root à l'intérieur du conteneur. Utilisez un utilisateur différent et des espaces de noms utilisateur. Le compte root dans le conteneur est le même que sur l'hôte, sauf s'il est remappé avec des espaces de noms utilisateur. Il est seulement légèrement restreint par les espaces de noms Linux, les capacités et les cgroups.
  • Supprimez toutes les capacités (--cap-drop=all) et n'activez que celles qui sont nécessaires (--cap-add=...). De nombreuses charges de travail n'ont pas besoin de capacités et leur ajout élargit la portée d'une attaque potentielle.
  • Utilisez l'option de sécurité "no-new-privileges" pour empêcher les processus d'obtenir plus de privilèges, par exemple via des binaires suid.
  • Limitez les ressources disponibles pour le conteneur. Les limites des ressources peuvent protéger la machine contre les attaques de déni de service.
  • Ajustez les profils seccomp, AppArmor (ou SELinux) pour restreindre les actions et les appels système disponibles pour le conteneur au strict minimum requis.
  • Utilisez des images Docker officielles https://docs.docker.com/docker-hub/official_images/ et exigez des signatures ou créez vos propres images basées sur celles-ci. N'héritez pas ou n'utilisez pas d'images compromises. Stockez également les clés racines et les phrases secrètes dans un endroit sûr. Docker prévoit de gérer les clés avec UCP.
  • Reconstruisez régulièrement vos images pour appliquer les correctifs de sécurité sur l'hôte et les images.
  • Gérez vos secrets avec prudence afin qu'il soit difficile pour un attaquant de les accéder.
  • Si vous exposez le démon Docker, utilisez HTTPS avec une authentification client et serveur.
  • Dans votre Dockerfile, privilégiez COPY plutôt que ADD. ADD extrait automatiquement les fichiers compressés et peut copier des fichiers à partir d'URL. COPY n'a pas ces fonctionnalités. Dans la mesure du possible, évitez d'utiliser ADD pour ne pas être vulnérable aux attaques via des URL distantes et des fichiers Zip.
  • Utilisez des conteneurs séparés pour chaque micro-service.
  • N'incluez pas SSH à l'intérieur du conteneur, "docker exec" peut être utilisé pour se connecter en SSH au conteneur.
  • Utilisez des images de conteneur plus petites.

Évasion de Docker / Élévation de privilèges

Si vous êtes à l'intérieur d'un conteneur Docker ou si vous avez accès à un utilisateur du groupe docker, vous pouvez essayer de vous échapper et d'escalader les privilèges :

{% content-ref url="docker-breakout-privilege-escalation/" %} docker-breakout-privilege-escalation {% endcontent-ref %}

Contournement du plugin d'authentification Docker

Si vous avez accès au socket Docker ou si vous avez accès à un utilisateur du groupe docker mais que vos actions sont limitées par un plugin d'authentification Docker, vérifiez si vous pouvez le contourner :

{% content-ref url="authz-and-authn-docker-access-authorization-plugin.md" %} authz-and-authn-docker-access-authorization-plugin.md {% endcontent-ref %}

Durcissement de Docker

Références

Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire facilement et **automatiser des flux de travail** alimentés par les outils communautaires les plus avancés au monde. Obtenez un accès dès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥