DEV Community: Hadi Mouter

Durcir un Active Directory de A à Z : construire, attaquer, défendre, auditer

Hadi Mouter — Fri, 26 Jun 2026 09:13:31 +0000

Cet article retrace un cycle complet de durcissement Active Directory, monté de bout en bout sur un lab Azure. On construit l'infrastructure, on applique le tiering, on durcit par GPO, on audite avec PingCastle, puis on remédie. La différence avec un guide classique : pour chaque mesure défensive, je montre d'abord l'attaque qu'elle bloque. Si vous administrez un AD et que vous voulez comprendre pourquoi on durcit, pas seulement quoi cocher, c'est pour vous.

Pourquoi cet article

Active Directory est la cible numéro un en environnement Windows. Une fois le domaine compromis, c'est toute l'organisation qui tombe. Pourtant la plupart des guides de durcissement se contentent d'une liste : désactivez SMBv1, activez LSA Protection, forcez NTLMv2. On exécute, on coche, mais on ne comprend pas ce qu'on bloque.

Le souci, c'est qu'on durcit à l'aveugle. On ne sait pas distinguer la mesure critique de la mesure cosmétique, ni défendre un arbitrage quand la production impose une contrainte. Tant qu'on ignore quelle attaque une mesure neutralise, on ne sait ni la prioriser ni l'expliquer.

J'ai pris le problème dans l'autre sens. Pour chaque protection, je commence par l'attaque : ce que fait vraiment un adversaire, et comment la mesure le bloque. C'est de mon avis la seule façon de durcir intelligemment.

Le tout est démontré sur un lab réel, avec les preuves à chaque étape. Pas "la mesure est censée marcher", mais "voici l'output qui montre qu'elle marche".

Le terrain : un lab volontairement minimal

Le lab tient sur trois machines hébergées sur Azure, organisées selon les trois niveaux du modèle de tiering Microsoft.

Tier	Machine	Rôle	IP privée
Tier 0	DC01	Contrôleur de domaine `lab.local` (AD DS + DNS)	172.16.0.4
Tier 1	SRV01	Serveur membre	172.16.0.5
Tier 2	WS01	Poste de travail (Windows 11)	dynamique

Soyons honnêtes tout de suite : ce lab n'est pas une architecture de production. C'est un environnement d'apprentissage minimal, fait pour démontrer les mécanismes. Les écarts assumés avec une vraie prod :

Un seul contrôleur de domaine. En prod, jamais moins de deux, sinon le domaine s'arrête quand le DC tombe. Ici, un seul, pour limiter le coût.
Pas de bastion ni de poste d'administration dédié (PAW). L'accès admin passe par du RDP filtré sur IP, là où une prod imposerait un point d'entrée séparé.
Pas de vraie segmentation réseau entre les tiers.

Pourquoi le dire ? Parce que savoir nommer ces écarts fait partie du métier. Un audit signalera "un seul DC" comme un risque, et la bonne réponse n'est pas de paniquer mais de documenter un risque accepté en connaissance de cause. On y revient plus bas.

Le tiering : la fondation de tout le reste

Avant de durcir quoi que ce soit, il faut comprendre comment un attaquant remonte dans un AD. Sans ça, le durcissement n'est qu'un tas de réglages sans logique.

Le chemin d'escalade

Voici le scénario classique, étape par étape.

D'abord, un attaquant compromet un poste de travail par hameçonnage. C'est la machine la plus exposée, celle d'un employé lambda. À ce stade il a les identifiants de l'employé, rien de plus. Peu de dégâts.

Plus tard, un administrateur se connecte sur ce poste pour le dépanner. S'il le fait avec un compte à hauts privilèges, ses identifiants restent en mémoire sur la machine, dans le processus LSASS.

L'attaquant, toujours présent sur le poste, lit cette mémoire (un dump LSASS, typiquement avec mimikatz) et récupère les identifiants de l'admin. Si c'était un compte du domaine, c'est terminé : il contrôle l'AD entier.

Le point à retenir : l'attaquant n'a pas besoin que l'admin soit connecté en permanence. Il suffit qu'un compte à privilège se soit connecté une seule fois sur la machine compromise.

La parade : segmenter par niveau

Le tiering répond exactement à ce chemin. Il sépare comptes et machines en trois niveaux de sensibilité, avec une règle stricte : un compte d'un tier ne doit jamais pouvoir s'authentifier sur une machine d'un autre tier.

Concrètement, le compte qui administre le contrôleur de domaine (Tier 0) ne doit jamais ouvrir de session sur un poste de travail (Tier 2). Comme ça, même si ce poste est compromis, aucun identifiant Tier 0 ne s'y trouve jamais. Le chemin d'escalade est coupé.

Mise en œuvre : OU, groupes, GPO

La structure repose sur des unités d'organisation (OU) qui matérialisent les tiers.

lab.local
├── OU=Admins
│     ├── OU=Tier0   → compte adm-t0, groupe T0-Admins
│     ├── OU=Tier1   → compte adm-t1, groupe T1-Admins
│     └── OU=Tier2   → compte adm-t2, groupe T2-Admins
├── OU=Servers       → SRV01
├── OU=Workstations  → WS01
└── Domain Controllers (OU par défaut) → DC01

Première bonne pratique : on cible des groupes, pas des comptes individuels. Les règles s'appliquent à T1-Admins, pas à adm-t1. Demain un nouvel admin serveur rejoint le groupe, et toutes les règles s'appliquent à lui automatiquement.

New-ADGroup -Name "T0-Admins" -GroupScope Global -Path "OU=Tier0,OU=Admins,DC=lab,DC=local"
New-ADGroup -Name "T1-Admins" -GroupScope Global -Path "OU=Tier1,OU=Admins,DC=lab,DC=local"
New-ADGroup -Name "T2-Admins" -GroupScope Global -Path "OU=Tier2,OU=Admins,DC=lab,DC=local"

Add-ADGroupMember -Identity "T0-Admins" -Members "adm-t0"
Add-ADGroupMember -Identity "T1-Admins" -Members "adm-t1"
Add-ADGroupMember -Identity "T2-Admins" -Members "adm-t2"

Un piège qui en piège beaucoup : quand une machine rejoint le domaine, elle atterrit par défaut dans le conteneur CN=Computers, sur lequel on ne peut pas lier de GPO. La première chose à faire après un join, c'est donc de la déplacer dans la bonne OU.

Move-ADObject -Identity "CN=SRV01,CN=Computers,DC=lab,DC=local" `
              -TargetPath "OU=Servers,DC=lab,DC=local"

Sans ce déplacement, vos GPO de tiering ne s'appliqueront jamais. Elles cibleront une OU vide.

Imposer le tiering techniquement

Le tiering devient réel grâce aux logon rights, des droits de connexion qu'on pilote par GPO. On crée une GPO par OU, qui interdit aux comptes du mauvais tier de se connecter.

GPO	Liée à l'OU	Comptes refusés (Deny log on locally + RDS)
Tier0-Deny-LowerTiers	Domain Controllers	T1-Admins, T2-Admins
Tier1-Deny-OtherTiers	Servers	T0-Admins, T2-Admins
Tier2-Deny-OtherTiers	Workstations	T0-Admins, T1-Admins

Le chemin dans l'éditeur de GPO :

Computer Configuration
└─ Policies > Windows Settings > Security Settings
   └─ Local Policies > User Rights Assignment
      ├─ Deny log on locally
      └─ Deny log on through Remote Desktop Services

Règle de sécurité non négociable : ne mettez jamais dans le deny le compte que vous utilisez pour administrer, ni le tier légitime de la machine. Sinon vous vous verrouillez hors de votre propre infra. Gardez toujours une session admin ouverte et testez après chaque GPO. Jamais de modification en masse.

La preuve que ça marche

On tente une connexion RDP sur le contrôleur de domaine avec un compte Tier 2 (adm-t2). Résultat :

L'erreur 0x2407 ("You might not have permission to sign in remotely") est la preuve visuelle. Détail important : le mot de passe a été accepté, l'authentification a réussi, mais la session est refusée par la GPO. Ce n'est pas un message "identifiants incorrects", qui voudrait dire mauvais mot de passe.

En clair : si un attaquant vole les identifiants adm-t2 sur un poste compromis, ils sont inutilisables pour atteindre le contrôleur de domaine. Le chemin d'escalade est coupé techniquement, pas par une consigne qu'on espère respectée.

Le durcissement : chaque défense face à son attaque

Le tiering protège qui peut se connecter où. Le durcissement, lui, désactive les protocoles et configurations faibles qui servent de vecteurs d'attaque. Voici le tableau central, chaque mesure reliée à l'offensive qu'elle bloque.

Mesure	Réglage	Attaque neutralisée
LSA Protection	`RunAsPPL = 1`	Dump LSASS
WDigest off	`UseLogonCredential = 0`	Mots de passe en clair en mémoire
SMBv1 off	`SMB1 = 0`	EternalBlue, propagation latérale
SMB signing	"Digitally sign communications (always)"	NTLM relay
LLMNR off	"Turn off multicast name resolution"	Responder / poisoning
NTLM hardening	NTLMv2 only, refuse LM & NTLM	Pass-the-hash, cracking offline
No LM hash	"Do not store LAN Manager hash"	Cracking offline

Le combo anti-LSASS

Les deux premières lignes méritent qu'on s'y arrête, parce qu'elles forment le cœur de la défense contre le vol d'identifiants.

LSASS est le processus Windows qui garde les identifiants en mémoire. C'est lui que vise un dump : on lit sa mémoire pour en sortir hash et mots de passe. Deux mesures le verrouillent.

LSA Protection (RunAsPPL = 1) transforme LSASS en processus protégé. Le système refuse alors qu'un autre processus lise sa mémoire, même en administrateur. Le dump échoue.

WDigest off (UseLogonCredential = 0) empêche le stockage des mots de passe en clair en mémoire. Une précision qui compte : sur Windows Server 2016 et plus récent, ce réglage est déjà à 0 par défaut. On ne referme donc pas un trou ouvert, on épingle le réglage pour qu'un attaquant ne puisse pas le réactiver. Repasser UseLogonCredential à 1 est une technique de persistance connue, qui rendrait à nouveau les mots de passe lisibles en clair après un dump. C'est de la défense en profondeur et de l'anti-tampering, pas une correction de défaut.

L'un rend la mémoire illisible, l'autre garantit qu'on ne pourra pas y réintroduire de mot de passe en clair. Ensemble ils ferment la porte au scénario d'escalade vu plus haut.

Ces réglages se poussent par GPO via les préférences de registre.

Côté méthode : on empile toutes les GPO de durcissement, puis on fait un seul redémarrage à la fin. On ne redémarre pas un contrôleur de domaine à chaque mesure, parce que pendant son reboot l'authentification de tout le domaine est coupée.

La preuve que LSA Protection est actif

Poser la clé ne suffit pas. LSA Protection ne s'active qu'au démarrage suivant, quand LSASS se lance en mode protégé. On vérifie donc que c'est vraiment effectif, pas seulement configuré.

Get-WinEvent -LogName System |
  Where-Object {$_.Message -like "*LSASS*protected*"} |
  Select -First 1 TimeCreated, Message

Le message "LSASS.exe was started as a protected process with level: 4" confirme. À partir de là, un dump LSASS sur cette machine se heurte au processus protégé et échoue.

Couper les protocoles faibles

Les autres mesures suivent la même logique.

SMBv1 est un protocole obsolète, vecteur d'EternalBlue (le mécanisme de propagation de WannaCry). Aucune raison de le garder.

SMB signing signe les paquets SMB, ce qui casse le NTLM relay : un paquet d'authentification falsifié est rejeté.

LLMNR est un protocole de résolution de noms de secours qu'un outil comme Responder exploite pour usurper des réponses et capturer des hash. On le coupe, en gardant en tête que LLMNR n'est qu'une partie du problème. NBT-NS et mDNS sont d'autres vecteurs de Responder, à traiter séparément.

Le durcissement NTLM force NTLMv2 et refuse LM/NTLMv1. Ces vieux protocoles produisent des empreintes cassables hors ligne en quelques minutes, et ouvrent la voie au pass-the-hash.

Une prudence pour la prod : couper NTLM totalement peut casser des applications anciennes. L'approche raisonnable, c'est de durcir (NTLMv2 seulement) sans tout casser, puis de mener un projet séparé d'audit avant un éventuel blocage complet.

L'audit : mesurer avec PingCastle

Une fois le durcissement en place, comment savoir où on en est ? PingCastle est un outil d'audit AD gratuit, devenu un standard. Il scanne le domaine et sort un score de risque sur quatre axes, avec un rapport HTML détaillé.

.\PingCastle.exe --healthcheck --server lab.local

Lire le score correctement

Voici le résultat initial sur le lab.

Le point le plus important pour interpréter PingCastle : le score global est le pire des quatre axes, pas leur moyenne.

Axe	Score
Stale Objects	15
Privileged Accounts	40
Trusts	0
Anomalies	55
GLOBAL	55

Ici, le 55 vient entièrement de l'axe Anomalies. Pour faire baisser le global, c'est donc cet axe qu'il faut attaquer en premier. Optimiser un autre axe ne changerait rien au global tant qu'Anomalies reste à 55.

Un point qui rassure

Avant même la remédiation, regardez ce que PingCastle ne signale pas : aucun finding SMBv1, aucun sur le dump LSASS, aucun NTLMv1. Pourquoi ? Parce que ces points ont été corrigés avant l'audit, pendant la phase de durcissement. L'audit confirme le travail déjà fait.

La remédiation : corriger n'est pas tout corriger

C'est là qu'on sépare l'amateur du pro. Un rapport PingCastle brut fait peur, tout semble rouge. Le réflexe du débutant, c'est de vouloir tout corriger. C'est une erreur.

Un rapport d'audit n'est pas une liste de cases à cocher en entier. C'est une base de priorisation. On trie les findings en trois catégories.

Catégorie 1 : les vraies failles, corrigées

Cinq findings exploitables, corrigés en priorité.

Finding	Action	Attaque visée
A-DC-Spooler	Désactiver le service Print Spooler sur le DC	PrintNightmare, coercition
A-RootDseAnonBinding	Bloquer le LDAP anonyme	Reconnaissance non authentifiée
A-AuditDC / A-AuditPowershell	Audit avancé + journalisation PowerShell	Aucune détection sans logs
A-MinPwdLen	Longueur minimale de mot de passe = 14	Force brute, devinette
S-AesNotEnabled	Forcer Kerberos AES (RC4 off)	Kerberoasting

Le service Spooler sur un contrôleur de domaine est un vecteur connu (PrintNightmare, et certaines techniques de coercition d'authentification). Un DC n'imprime rien, on coupe.

Stop-Service Spooler -Force
Set-Service Spooler -StartupType Disabled

L'audit avancé mérite une insistance, parce qu'il fait le lien avec la détection, le travail d'un SOC. Sans politique d'audit, le domaine est aveugle : aucune trace d'un Kerberoasting, d'une connexion suspecte ou d'une commande PowerShell malveillante. On l'active par GPO, ce qui couvre tous les contrôleurs de domaine, au lieu d'une commande locale qui ne couvrirait qu'une machine.

On ajoute la journalisation PowerShell (Module Logging et Script Block Logging), pour tracer l'exécution de scripts offensifs.

Catégorie 2 : les risques acceptés, documentés

Certains findings ne sont pas des failles à corriger, mais des choix assumés.

A-NotEnoughDC : un seul contrôleur de domaine. C'est notre décision de lab, pas une faille.
A-LAPS-Not-Installed : LAPS est un projet à part entière, hors périmètre.
S-DC-SubnetMissing, P-RecycleBin : cosmétique pour un environnement isolé.

En audit réel, on consigne ces findings comme risque accepté, avec leur justification. Le rôle de l'auditeur n'est pas de tout corriger aveuglément, mais de savoir quoi corriger et quoi assumer selon le contexte.

Catégorie 3 : les délais d'application

Une subtilité que beaucoup ignorent : certaines remédiations sont posées mais ne deviennent effectives qu'après un événement. Le finding S-AesNotEnabled en est l'exemple parfait. La GPO force AES, mais les clés AES des comptes ne se génèrent qu'au prochain changement de mot de passe. Juste après la GPO, PingCastle continue donc de remonter le finding. Ce n'est pas un échec, c'est un délai normal.

Le verdict : avant / après

On relance PingCastle après remédiation et on compare.

Axe	Avant	Après
Stale Objects	15	15
Privileged Accounts	40	40
Anomalies	55	35
GLOBAL	55	40

Le score global passe de 55 à 40, soit 15 points de moins, portés par une baisse de 20 points sur l'axe Anomalies, exactement l'axe prioritaire repéré au départ.

Et c'est là que le principe "le score est le pire des axes" se vérifie en direct. En faisant tomber Anomalies de 55 à 35, on a fait disparaître l'axe qui plafonnait le score. Mais un nouveau plafond apparaît tout seul : Privileged Accounts, resté à 40, est maintenant l'axe qui détermine le global. C'est donc lui la cible de la prochaine itération : nettoyer les délégations, les membres de Schema Admins, protéger les OU. La boucle se referme concrètement. On traite l'axe prioritaire, le plafond se déplace, on recommence.

La leçon centrale : la remédiation ne fait pas tomber le score à zéro, et c'est normal. Trois cas coexistent. Corrigé (Spooler, audit, longueur de mot de passe). Effectif après délai (AES attend un renouvellement de secret). Risque accepté documenté (un seul DC). Un audit se mesure à la baisse du score sur les axes prioritaires, pas à un 0/100 illusoire.

Les leçons à retenir

Au-delà des commandes, voilà ce qui se transpose à n'importe quel environnement.

Les bonnes pratiques :

Cibler des groupes, jamais des comptes individuels. Une règle s'applique à un rôle, pas à une personne.
Ranger les machines dans la bonne OU. Une GPO ne s'applique qu'à l'OU où elle est liée, et toute machine jointe atterrit d'abord dans Computers.
Imposer les règles techniquement, pas par consigne. Une restriction dans une GPO est appliquée. Une règle écrite dans un document est ignorée.
Garder une session admin ouverte et tester après chaque GPO. Le verrouillage accidentel est un vrai risque.
Empiler les GPO, un seul redémarrage à la fin. On ne redémarre pas un DC à chaque mesure.
Prouver l'effet par un output. Event "LSASS protected", auditpol /get, erreur 0x2407. Ne jamais supposer.
Trier un rapport d'audit. Risque accepté documenté contre faille exploitable corrigée. Ne pas viser le 0/100.

Les mauvaises pratiques à éviter :

Réutiliser le même mot de passe partout. Un compromis, et tout tombe.
Connecter un compte à hauts privilèges sur une machine exposée. Les identifiants restent en mémoire, prêts à être dumpés.
Exposer le RDP directement sur Internet. On filtre par IP source, ou on passe par un bastion ou un VPN d'administration.

Conclusion

Durcir un Active Directory n'est pas une case à cocher, c'est un cycle. On construit, on durcit en pensant comme l'attaquant, on audite pour mesurer, on remédie en priorisant, puis on recommence. Le score ne descendra jamais à zéro, et ce n'est pas le but. L'objectif, c'est de fermer méthodiquement les chemins d'attaque les plus exploitables et de documenter en conscience ce qu'on accepte.

L'angle attaque/défense n'est pas un gadget. Quand on sait précisément quelle technique une mesure neutralise, on sait aussi la prioriser, la justifier et l'expliquer. C'est la différence entre appliquer une checklist et sécuriser vraiment son environnement.

Lab monté de bout en bout sur Azure. Tous les outils sont gratuits : Active Directory, la console de gestion des stratégies de groupe, et PingCastle en édition gratuite (usage non commercial). Les commandes sont reproductibles telles quelles.

Docker hardening : durcir un conteneur en profondeur, du Dockerfile au daemon

Hadi Mouter — Thu, 07 May 2026 07:07:17 +0000

Voici un Dockerfile qu'on retrouve dans la majorité des dépôts publics :

FROM node:latest
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "server.js"]

Six lignes, ça compile, ça tourne, le CI passe.

Maintenant, supposons qu'une vulnérabilité dans une dépendance npm donne à un attaquant un RCE dans ce conteneur. Voici ce qu'il a effectivement entre les mains :

Un shell qui tourne en root (UID 0)
L'ensemble des Linux capabilities que Docker conserve par défaut, dont CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_NET_RAW et CAP_KILL
Un système de fichiers entièrement inscriptible
L'intégralité des ressources CPU et mémoire de l'hôte (aucune limite n'est posée par défaut)
Une image dont le contenu peut changer entre deux pulls (:latest)
Une surface d'attaque qui inclut un OS Debian complet, package manager compris

Aucun de ces points n'est un bug. Ce sont les valeurs par défaut.

Docker est conçu pour être ergonomique, pas pour être sûr, et ces deux objectifs ne sont pas alignés.

C'est l'idée centrale de cet article : la sécurité conteneur n'est pas une couche qu'on ajoute, c'est un ensemble de défauts qu'on retire. Le travail consiste à partir d'une configuration permissive et à la fermer méthodiquement, en sachant à chaque fois ce qu'on protège et contre quoi.

On va parcourir le sujet à trois niveaux :

Le runtime (la commande docker run ou son équivalent compose)
L'image (le Dockerfile lui-même)
Le démon (la configuration du daemon Docker côté hôte)

À la fin, tu auras une config de référence applicable telle quelle, et surtout les justifications pour chaque ligne. C'est ce qui permet de l'adapter intelligemment à un workload qui sort du cas standard.

Le modèle mental : isolation vs hardening

Avant les commandes, deux distinctions qui changent tout.

VM vs conteneur

Une machine virtuelle s'appuie sur un hyperviseur qui émule du matériel et fournit à chaque OS invité son propre noyau. La frontière entre invité et hôte est une frontière matérielle simulée, et la franchir demande de casser l'hyperviseur.

Un conteneur, lui, partage le noyau de l'hôte.

L'isolation se fait au niveau processus, via les namespaces et cgroups du kernel Linux. La frontière est logicielle, et elle s'effondre dès qu'on trouve une vulnérabilité dans le runtime (runC, containerd) ou dans le kernel lui-même.

CVE-2019-5736 sur runC en est l'exemple le plus connu : un conteneur non-privilégié pouvait écraser le binaire runC sur l'hôte et obtenir l'exécution de code en tant que root au prochain docker exec. CVE-2024-21626 ("Leaky Vessels", début 2024) a démontré que le sujet reste d'actualité.

La conséquence est importante. La surface d'attaque réelle d'un conteneur n'est pas le conteneur lui-même, c'est l'ensemble noyau hôte plus runtime. Tout ce qu'on appelle "container hardening" consiste à réduire cette surface, soit en limitant ce que le processus peut atteindre, soit en limitant ce qu'il peut faire avec ce qu'il atteint.

Isolation vs hardening

Ces deux mots sont souvent confondus alors qu'ils renvoient à deux mécanismes distincts.

L'isolation détermine ce que le conteneur voit. Elle est assurée par les namespaces Linux :

PID (arbre des processus)
NET (pile réseau)
MNT (système de fichiers)
IPC (System V / POSIX)
UTS (hostname)
USER (mapping UID/GID)

Casser un namespace, c'est élargir la vue du conteneur jusqu'à inclure des choses qui appartiennent à l'hôte ou à un autre conteneur.

Le hardening détermine ce que le conteneur peut faire, même s'il voit quelque chose. Il s'appuie sur les capabilities (sous-ensembles du privilège root), les profils seccomp (filtre de syscalls), les politiques MAC (AppArmor/SELinux) et les cgroups (limites de ressources).

Les deux sont nécessaires.

Une isolation parfaite avec aucun hardening permet à un conteneur compromis de saturer le CPU de l'hôte. Un hardening agressif avec une isolation cassée (par exemple --pid=host) laisse le conteneur lire les processus de l'hôte. La défense en profondeur consiste à empiler les deux, et à empiler plusieurs couches dans chaque catégorie.

Trois scénarios pour rendre ça concret

Avant de plonger dans la config, trois scénarios qui justifient chaque ligne qu'on va écrire.

Container escape via vulnérabilité runtime

CVE-2019-5736 (runC) en est le cas d'école. Un conteneur non-privilégié peut, dans certaines conditions, écraser le binaire /usr/bin/runc sur l'hôte au moment où un docker exec est lancé.

Au prochain démarrage de conteneur, c'est le code de l'attaquant qui s'exécute en tant que root sur la machine.

Mitigation : user namespaces (root du conteneur != root de l'hôte), patches kernel à jour, profils MAC actifs.

Abus de capabilities

Un conteneur démarré avec --privileged désactive tous les mécanismes de sécurité Docker en bloc : seccomp désactivé, AppArmor désactivé, toutes les capabilities ajoutées, accès aux périphériques de l'hôte.

À partir de là, un attaquant peut monter le filesystem de l'hôte (mount /dev/sda1 /mnt), écrire dans /etc/shadow, ou abuser des cgroups v1 release_agent pour faire exécuter un script en tant que root sur l'hôte.

Même sans --privileged, certaines capabilities suffisent. CAP_SYS_ADMIN à elle seule ouvre la voie à des dizaines d'évasions documentées.

Mitigation : --cap-drop=ALL par défaut, ajouts ciblés et justifiés.

Exposition du socket Docker

Le démon Docker écoute sur /var/run/docker.sock. Toute personne qui peut écrire dans ce socket peut piloter le démon, donc lancer n'importe quel conteneur, y compris un conteneur --privileged qui monte / de l'hôte.

Monter ce socket dans un conteneur (-v /var/run/docker.sock:/var/run/docker.sock) est une pratique courante chez les devs qui veulent faire du Docker-in-Docker pour leur CI ou leur Portainer. C'est l'équivalent d'un accès root effectif à l'hôte pour le processus du conteneur.

Mitigation : ne jamais monter le socket en production. Si vraiment nécessaire (CI builders), utiliser un proxy comme docker-socket-proxy qui filtre les API exposées.

Ces trois scénarios ne sont pas exhaustifs, mais ils couvrent l'essentiel : kernel/runtime, privilèges trop larges, exposition d'API. Chaque ligne de la config qui suit répond à au moins l'un des trois.

Anatomie d'une config durcie, ligne par ligne

Voici la commande de référence. On va la décortiquer en six blocs thématiques.

docker run -d \
  --name myapp \
  --user 1000:1000 \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/etc/docker/seccomp/default.json \
  --security-opt apparmor=docker-default \
  --pids-limit 100 \
  --memory 512m \
  --memory-swap 512m \
  --cpus 1.0 \
  --network myapp-net \
  -p 127.0.0.1:8080:8080 \
  -v myapp-data:/data \
  -v /etc/myapp/config.yml:/app/config.yml:ro \
  myapp@sha256:a1b2c3...

Tu remarqueras que --cap-add=NET_BIND_SERVICE, qu'on voit partout dans les configs partagées en ligne, n'est plus là. On y revient.

Bloc 1 : identité

--user 1000:1000

Par défaut, le processus à l'intérieur du conteneur tourne en root (UID 0). Si l'image n'a pas d'instruction USER et que les user namespaces ne sont pas actifs, ce root du conteneur est aussi root sur l'hôte.

Une évasion donne alors directement les droits root de la machine.

--user 1000:1000 force le processus à tourner avec un UID/GID arbitraire non-privilégié.

Cette protection est complétée au niveau du démon par les user namespaces (userns-remap dans /etc/docker/daemon.json), qui remappent l'intégralité des UIDs du conteneur vers une plage non privilégiée sur l'hôte. C'est la protection la plus efficace contre les évasions, et elle est désactivée par défaut. On verra la config dans la section dédiée au démon.

Attention : --user ne suffit pas si l'image elle-même a besoin d'écrire dans des chemins appartenant à root. C'est pour ça que l'instruction USER doit aussi figurer dans le Dockerfile, pour que les permissions de l'image soient cohérentes avec l'UID runtime.

Bloc 2 : capabilities

--cap-drop=ALL

Linux fragmente le privilège root en une quarantaine de capabilities (CAP_CHOWN, CAP_NET_RAW, CAP_SYS_ADMIN, etc.).

Docker conserve par défaut un sous-ensemble qui inclut encore CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_NET_RAW, CAP_KILL, CAP_SYS_CHROOT et quelques autres. Ce n'est pas anodin. CAP_NET_RAW permet par exemple de forger des paquets ARP et de lancer du spoofing sur le réseau du conteneur. CAP_DAC_OVERRIDE permet de contourner les permissions DAC sur les fichiers.

La règle est simple : --cap-drop=ALL au démarrage, puis --cap-add pour rajouter ce qui est strictement nécessaire et seulement ça.

Le piège classique : NET_BIND_SERVICE

On voit souvent --cap-add=NET_BIND_SERVICE dans les configs partagées en ligne. Cette capability autorise le processus à se binder sur un port < 1024.

Elle n'est utile que si ton processus écoute directement sur le port 80 ou 443 à l'intérieur du conteneur.

Or dans une architecture moderne, ton app écoute sur 8080 ou 3000. C'est Docker qui fait le mapping -p 80:8080 côté hôte. Le bind sur le port 80 est fait par le démon, pas par ton processus.

Si en plus tu as un reverse proxy (nginx, Traefik, Caddy) devant, ce dernier gère les ports privilégiés, et ton app n'a pas du tout besoin de cette capability.

Conclusion pragmatique : démarre avec --cap-drop=ALL sans rien ajouter. Si ton app crashe, le message d'erreur te dira ce qui manque, et tu ajouteras la capability ciblée. Ne pré-ajoute rien "au cas où".

Bloc 3 : syscalls

--security-opt seccomp=/etc/docker/seccomp/default.json
--security-opt no-new-privileges

Seccomp filtre les appels système que le processus peut faire au noyau.

Le profil par défaut de Docker bloque environ 44 syscalls jugés dangereux ou inutiles pour la majorité des workloads applicatifs : keyctl (manipulation du keyring kernel), unshare (création de nouveaux namespaces), mount, pivot_root, kexec_load, bpf, et d'autres. En pratique, ce profil est suffisant pour 95 % des applications.

Préciser explicitement --security-opt seccomp=... plutôt que de se reposer sur le défaut implicite a deux utilités. D'abord, ça rend la configuration auditable (un grep sur ton infra te dit immédiatement quels conteneurs ont seccomp activé). Ensuite, ça évite que quelqu'un retire silencieusement la protection.

Voir --security-opt seccomp=unconfined quelque part en production est un drapeau rouge immédiat. La seule raison légitime de désactiver seccomp est le debug ponctuel d'un syscall bloqué, et ça doit revenir à default aussitôt après.

--security-opt no-new-privileges applique le flag PR_SET_NO_NEW_PRIVS au processus. Cela empêche le processus et tous ses descendants d'élever leurs privilèges via un binaire SUID/SGID.

Sans cette option, un binaire SUID root présent dans l'image (ping, mount dans certains cas) peut être exploité pour regagner des privilèges malgré --user.

Le coût opérationnel est nul, le bénéfice est réel, donc on l'active toujours.

Bloc 4 : MAC (Mandatory Access Control)

--security-opt apparmor=docker-default

AppArmor (Ubuntu, Debian) et SELinux (RHEL, Fedora, CentOS) sont des modules kernel qui appliquent des politiques d'accès au niveau de l'hôte, en plus des permissions DAC standards.

Docker installe un profil par défaut (docker-default pour AppArmor, label container_t pour SELinux) qui restreint les conteneurs au-delà de ce que les capabilities et seccomp couvrent : interdiction d'écrire dans /proc/sysrq-trigger, dans /sys/firmware, dans certains chemins sensibles du sysfs.

Préciser apparmor=docker-default explicitement a la même logique que pour seccomp : auditabilité et défense contre une dérive de configuration. Sur un hôte SELinux, l'équivalent est --security-opt label=type:container_t (généralement appliqué automatiquement par le runtime).

Important : ces protections supposent que le module est activé sur l'hôte. Sur une distribution sans AppArmor ni SELinux, l'option est ignorée silencieusement. C'est pourquoi le hardening conteneur n'a de sens qu'avec un hôte lui-même durci.

Bloc 5 : système de fichiers

--read-only
--tmpfs /tmp:rw,noexec,nosuid,size=64m
-v myapp-data:/data
-v /etc/myapp/config.yml:/app/config.yml:ro

--read-only rend le rootfs du conteneur immuable. Un attaquant ne peut plus modifier les binaires du conteneur ni y déposer un implant persistant.

La majorité des applications web n'écrivent jamais sur leur rootfs, donc cette option passe sans douleur.

Pour le cas où l'app a besoin d'un répertoire temporaire, on remonte /tmp en tmpfs (donc en mémoire, pas sur disque), avec deux options de durcissement :

noexec : pas d'exécution de binaire depuis ce mount
nosuid : les bits SUID/SGID y sont ignorés

La taille est bornée pour éviter qu'un attaquant ne sature la RAM via ce mount.

-v myapp-data:/data utilise un named volume géré par Docker. C'est nettement préférable à un bind mount d'un chemin de l'hôte. Les named volumes vivent dans /var/lib/docker/volumes/, sont gérés par le démon, et n'exposent pas de structure du filesystem hôte au conteneur.

Les bind mounts (-v /home/user/data:/data) sont l'un des principaux vecteurs d'évasion. Un bind mount sur /, sur /etc, ou sur /proc casse l'isolation du namespace MNT.

-v /etc/myapp/config.yml:/app/config.yml:ro est le seul bind mount toléré ici, et il est en lecture seule (:ro). C'est un pattern courant : la configuration est sur l'hôte (gérée par Ansible, Terraform, ou montée depuis un secret manager), le conteneur la lit, point.

Le :ro est non négociable.

Et le grand absent : jamais de -v /var/run/docker.sock:... en production. Comme vu dans la section menaces, ça équivaut à donner les clés du démon, donc un accès root effectif à l'hôte.

Bloc 6 : ressources

--pids-limit 100
--memory 512m
--memory-swap 512m
--cpus 1.0

Ces options reposent sur les cgroups Linux et limitent ce que le conteneur peut consommer. Par défaut, Docker n'impose aucune limite : un conteneur peut allouer toute la RAM de l'hôte, faire un fork bomb, saturer le CPU.

--pids-limit 100 borne le nombre de processus/threads que le conteneur peut créer. C'est la protection la plus simple contre les fork bombs, qu'elles soient malveillantes ou accidentelles (un bug dans ton code qui boucle sur fork()).

--memory 512m plafonne la RAM. Au-delà, le conteneur se fait OOM-killer.

--memory-swap 512m réglé à la même valeur que --memory désactive le swap pour ce conteneur. Cela évite des comportements de performance imprévisibles et coupe une voie d'épuisement du swap de l'hôte.

--cpus 1.0 fixe un quota CPU équivalent à un cœur. Sur une machine multi-cœurs, ça laisse les autres conteneurs et l'hôte respirer même si le conteneur boucle.

L'argument sécurité est moins évident que pour les capabilities, mais il est réel. Un conteneur compromis ne devient pas un vecteur de DoS sur les voisins ou sur l'hôte. C'est de la résilience, et la résilience fait partie de la sécurité.

Et le réseau

--network myapp-net
-p 127.0.0.1:8080:8080

--network myapp-net place le conteneur sur un bridge user-defined plutôt que sur le bridge par défaut (docker0).

Le bridge par défaut autorise tous les conteneurs à se parler. Un bridge dédié couplé à icc: false dans le démon (voir plus loin) coupe cette communication non sollicitée.

-p 127.0.0.1:8080:8080 est un détail qui change tout. Sans préfixe d'IP, -p 8080:8080 bind sur 0.0.0.0, donc sur toutes les interfaces de l'hôte, y compris celles exposées sur Internet.

Sur un VPS bien configuré côté firewall, ce n'est pas catastrophique. Sur un poste de dev ou un serveur sans firewall strict, ça expose ton conteneur au monde.

127.0.0.1:8080:8080 ne bind que sur loopback, ce qui est ce que tu veux dans 90 % des cas (typiquement quand un reverse proxy en frontal route vers le conteneur).

Côté image : le Dockerfile

Le runtime n'est que la moitié du sujet. L'autre moitié est ce qui est dans l'image elle-même, et ça se construit dans le Dockerfile.

FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /out/myapp ./cmd/myapp

FROM gcr.io/distroless/static-debian12:nonroot
LABEL org.opencontainers.image.source="https://github.com/org/myapp"
COPY --from=builder /out/myapp /usr/local/bin/myapp
USER nonroot:nonroot
ENTRYPOINT ["/usr/local/bin/myapp"]

Quatre points méritent qu'on s'y arrête.

Multi-stage

L'étape builder contient toute la toolchain : compilateur, dépendances, code source. L'image finale n'embarque que le binaire compilé.

Conséquence directe : un attaquant qui obtient un RCE dans le conteneur n'a pas de gcc, de git, de curl, ni de npm à sa disposition pour construire son outillage post-exploitation.

La surface est fortement réduite.

Distroless

L'image finale dérive de gcr.io/distroless/static-debian12. Pas de shell, pas de package manager, pas d'utilitaires Unix. Pas de sh, pas de bash, pas de apt, pas de wget.

Un attaquant qui aurait quand même un RCE doit travailler uniquement avec les capacités de ton binaire et celles du kernel.

La variante :nonroot fournit en plus un utilisateur UID 65532, qu'on active avec USER nonroot:nonroot.

Pour un binaire statique compilé en Go, Rust ou C, c'est l'image la plus minimale possible. Pour Node.js ou Python, regarder du côté de gcr.io/distroless/nodejs ou gcr.io/distroless/python3.

Épinglage par digest, pas par tag

Dans l'exemple ci-dessus, gcr.io/distroless/static-debian12:nonroot est un tag mutable. Son contenu change quand Google republie l'image (ce qui est fréquent, pour de bonnes raisons de patches sécurité).

Pour une chaîne de build reproductible et auditable, on remplace le tag par un digest immuable :

FROM gcr.io/distroless/static-debian12@sha256:6b3b06...

Le digest est obtenu via docker pull <image>:tag puis docker inspect.

Au prix d'un peu de discipline (mettre à jour le digest à chaque audit), on garantit qu'aucune supply chain attack ne peut substituer une image silencieusement entre deux builds.

`.dockerignore`

Souvent oublié, parfois critique.

Sans .dockerignore, COPY . . copie tout le contexte de build dans l'image, y compris .git/, .env, node_modules/ (si tu builds en local avant), et tout fichier sensible que tu aurais laissé traîner.

Un .dockerignore minimal contient au moins :

.git
.env*
*.log
node_modules
.DS_Store
.idea
.vscode

Ce n'est pas du hardening au sens strict, c'est de l'hygiène. L'oubli est un classique des audits.

Le démon Docker : `/etc/docker/daemon.json`

Tout ce qu'on a vu jusqu'ici se configure par conteneur. Certains réglages se font une seule fois, au niveau du démon, et s'appliquent à tous les conteneurs.

C'est la couche que les développeurs ignorent parce qu'elle relève de l'admin de l'hôte. Et c'est précisément pour ça qu'elle mérite d'être traitée.

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "icc": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

`userns-remap: default`

Active les user namespaces sur l'ensemble des conteneurs.

Root (UID 0) à l'intérieur d'un conteneur est mappé vers un UID non privilégié (par exemple 100000) sur l'hôte. Une évasion qui aboutit avec UID 0 dans le conteneur se retrouve avec UID 100000 sur l'hôte. Elle ne peut donc pas écrire dans /etc/shadow, ni monter de filesystem, ni faire quoi que ce soit qui demande root réel.

C'est la protection la plus efficace contre les container escapes.

Elle est désactivée par défaut parce qu'elle introduit quelques contraintes sur les volumes (les UIDs des fichiers doivent être adaptés). Le coût en vaut largement la peine.

`no-new-privileges: true`

Au niveau démon, applique le flag PR_SET_NO_NEW_PRIVS à tous les conteneurs sans qu'on ait besoin de le préciser à chaque docker run.

C'est de la défense en profondeur : si un dev oublie l'option dans une commande, le démon la rajoute.

`icc: false`

Désactive l'inter-container communication sur le bridge par défaut.

Sans cette option, deux conteneurs sur docker0 peuvent se parler librement. Avec icc: false, ils sont isolés sauf si on les place explicitement sur le même réseau user-defined.

C'est de la segmentation réseau gratuite.

`live-restore: true`

Permet aux conteneurs de continuer à tourner si le démon redémarre (pour une mise à jour, par exemple).

Ce n'est pas du hardening au sens strict, mais ça réduit la fenêtre où on serait tenté de désactiver des protections "le temps d'un fix urgent". Moins de pression opérationnelle = moins de raccourcis sécurité.

Rotation des logs

max-size et max-file préviennent qu'un conteneur bavard remplisse /var/lib/docker/containers/... et finisse par saturer le disque de l'hôte.

Saturer le disque hôte est un vecteur de DoS comme un autre.

La checklist, en synthèse

Voici la grille d'évaluation qui résume tout. Elle peut servir de checklist d'audit, ou de gabarit pour un linter d'images comme hadolint, trivy config ou checkov.

Drop privileges

Exécution non-root (--user, USER dans le Dockerfile)
--cap-drop=ALL puis ajouts ciblés
User namespaces actifs au niveau démon

Restrict syscalls

Profil seccomp explicite (le default suffit dans la majorité des cas)
--no-new-privileges

Apply MAC

AppArmor docker-default ou SELinux container_t
Vérifier que le module est actif sur l'hôte

Limit volume risk

Named volumes plutôt que bind mounts
:ro quand l'écriture n'est pas nécessaire
Jamais de /var/run/docker.sock, /proc, /sys montés dans un conteneur applicatif

Runtime options

--read-only + tmpfs pour les chemins inscriptibles
--memory, --cpus, --pids-limit
Bind sur 127.0.0.1 plutôt que 0.0.0.0 quand un reverse proxy est devant

Build minimal images

Multi-stage
Distroless ou scratch pour les binaires statiques
Épinglage par digest, pas par tag
.dockerignore à jour

La formule à retenir : chaque case décochée doit être un choix conscient, pas un défaut hérité.

En entretien comme en code review, la mauvaise réponse est "je ne savais pas". La bonne réponse est "j'ai évalué que pour ce workload, le coût opérationnel dépasse le bénéfice, et voici la mitigation alternative en place".

Cas concret : Mini Secrets Manager

J'ai appliqué cette checklist à un projet personnel, un mini gestionnaire de secrets en NestJS/PostgreSQL. Le pipeline CI/CD intégrait Trivy pour le scan d'image, Snyk pour les dépendances, et Trufflehog pour la détection de secrets en commit.

Au premier passage, Trivy a remonté une CVE de niveau HIGH sur l'image de base que j'avais épinglée trois semaines plus tôt. Le correctif a consisté à bumper le digest, valider que les tests passent, republier.

Sans ce pipeline, la vulnérabilité serait restée en prod jusqu'au prochain audit manuel, c'est-à-dire potentiellement jamais.

La leçon n'est pas que ma config était mauvaise (elle suivait la checklist ci-dessus), c'est qu'une config durcie sans détection continue est une photographie qui périme. Les deux vont ensemble.

Ce que cet article ne couvre pas

Le sujet "sécuriser un conteneur" déborde largement de Docker en mode standalone. Quatre prolongements importants qu'il faut au moins savoir nommer.

Kubernetes

En production sérieuse, Docker seul est rare.

Kubernetes ajoute des primitives spécifiques qui transposent les concepts vus ici :

securityContext.capabilities pour les capabilities
securityContext.runAsNonRoot pour l'identité
seccompProfile pour les syscalls
NetworkPolicies pour la segmentation réseau

Et surtout les Pod Security Standards (Restricted, Baseline, Privileged) qui codifient des baselines applicables au niveau namespace. La philosophie du moindre privilège transpose directement, les commandes changent.

Rootless Docker

Docker peut tourner entièrement sans privilèges (le démon lui-même tourne en utilisateur non-root).

Ça change le modèle de menace : l'évasion de conteneur ne donne plus root sur l'hôte par construction. Le coût est en compatibilité (certaines fonctionnalités réseau et de stockage sont limitées).

Podman, l'alternative de Red Hat, fonctionne en rootless par défaut.

Sandboxing renforcé

Pour les workloads multi-tenant ou les environnements à très haute sensibilité, le partage du noyau hôte reste un risque.

gVisor (Google) interpose un "noyau utilisateur" entre le conteneur et le kernel hôte, qui filtre les syscalls.

Kata Containers va plus loin et lance chaque conteneur dans une micro-VM légère (KVM).

Le coût en performance n'est plus négligeable, mais l'isolation se rapproche du niveau VM.

Supply chain

Le hardening d'un conteneur est inutile si l'image qu'on déploie a été substituée en amont.

Les outils à connaître :

cosign pour signer cryptographiquement les images
Les attestations SLSA pour prouver la provenance d'un build
Les SBOM (Software Bill of Materials, format SPDX ou CycloneDX) pour documenter les composants

Sigstore et Notary v2 sont les écosystèmes de référence.

Chacun de ces sujets mérite son propre article. Mais le socle reste celui qu'on a parcouru ici : sans une config conteneur correctement durcie, ajouter Kubernetes, gVisor ou cosign ne sert pas à grand-chose. C'est l'ordre qui compte.

Le réflexe à garder : avant de copier une config trouvée en ligne (y compris celle-ci), ouvre docker inspect sur tes conteneurs en prod et compare. Tu seras surpris de ce qui tourne avec des défauts que personne n'a jamais remis en question.

C'est par là qu'on commence.