Installer WSL 2 sous Windows 10 et 11, configuration et sécurité

Installer WSL 2 sous Windows 10 et 11, configuration et sécurité

WSL (Windows Subsystem for Linux) fait tourner une distribution Linux sur un poste Windows, sans double amorçage ni hyperviseur tiers. L’installation tient en une commande ; ce qui compte vient après : version 1 ou 2, réseau, proxy, mises à jour, sauvegarde, et une surface d’attaque dont l’installeur ne dit rien. Position défendue ici : WSL 2 partout où la virtualisation est disponible, fichiers de travail sur le disque Linux, et aucune illusion sur l’isolation, car WSL est une commodité de développement, pas un bac à sable.

Explication de la marmotte

Imaginer une maison où l’on aménage un atelier dans le garage : d’autres outils, d’autres habitudes, mais la même porte d’entrée et le même trousseau de clés. C’est pratique pour bricoler sans déménager. Seulement, l’atelier n’a pas de serrure à lui : qui entre dans la maison entre aussi dans l’atelier.

→ Lire l’explication complète de la marmotte

Prérequis WSL 2 : build Windows, virtualisation matérielle et droits

Quatre conditions, à vérifier avant de taper quoi que ce soit.

• Build Windows. La commande wsl --install exige Windows 11, ou Windows 10 version 2004 (build 19041) et ultérieures. Les options réseau modernes (mode miroir, tunnel DNS, pare-feu Hyper-V, proxy automatique) exigent Windows 11 22H2 (build 22621) au minimum. Windows 10 est sorti du support standard le 14 octobre 2025 : y installer un environnement de travail neuf revient à meubler un immeuble promis à la démolition.
• Virtualisation matérielle. Les extensions Intel VT-x ou AMD-V doivent être activées dans le firmware UEFI (Unified Extensible Firmware Interface). Sur un poste lui-même virtualisé, il faut en plus que l’hyperviseur expose la virtualisation imbriquée, sinon WSL 2 ne démarre pas.
• Fonctionnalités Windows. WSL 2 repose sur « Plateforme de machine virtuelle » (VirtualMachinePlatform). La fonctionnalité « Sous-système Windows pour Linux » (Microsoft-Windows-Subsystem-Linux) ne sert qu’à WSL 1. Le rôle Hyper-V complet n’est pas requis.
• Droits. L’installation demande une session administrateur et un redémarrage. L’usage quotidien, lui, se fait sans élévation.

# Build : 19041 minimum pour wsl --install, 22621 pour le mode miroir
[System.Environment]::OSVersion.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      26100  0

# État de la virtualisation vu par Windows
systeminfo | Select-String "Hyper-V", "hyperviseur"

Deux sorties possibles : soit les lignes « Configuration requise pour Hyper-V », dont « Virtualisation activée dans le microprogramme : Oui » ; soit le message « Un hyperviseur a été détecté », signe que la couche de virtualisation tourne déjà. Un « Non » sur la ligne du microprogramme renvoie au firmware, pas à Windows. Cette case décochée reste une cause d’échec très courante, loin devant tout ce qui ferait une belle conférence.

WSL 1 ou WSL 2 : couche de traduction contre machine virtuelle légère

Les deux versions portent le même nom et n’ont presque rien en commun. Le schéma montre où passent les appels système dans chaque cas.

WSL 1 traduit les appels système Linux en appels Windows. Pas de noyau Linux, donc une compatibilité partielle : c’est un exploit d’ingénierie auquel il manque toujours l’appel système dont on a besoin ce jour-là. WSL 2 démarre un vrai noyau Linux, maintenu par Microsoft, dans une VM (Virtual Machine, machine virtuelle) utilitaire posée sur un sous-ensemble d’Hyper-V. Chaque distribution reçoit son disque virtuel au format VHDX (Virtual Hard Disk v2), formaté en ext4.

Le compromis central se lit ici. WSL 2 apporte la compatibilité complète (conteneurs, systemd, modules du noyau) et des accès disque rapides sur ext4. Il coûte une VM opaque pour les outils de sécurité Windows, un noyau et une distribution à maintenir, et des accès lents aux fichiers Windows.

Détail d’architecture à retenir : d’après la documentation Microsoft, toutes les distributions WSL 2 partagent la même VM, le même noyau et le même espace de noms réseau ; elles n’ont en propre que leurs espaces de noms de processus, de montage et d’utilisateurs. Un service qui écoute dans une distribution est joignable depuis l’autre sur localhost. Deux distributions ne font pas deux zones de confiance.

Recommandation : WSL 2 par défaut. WSL 1 ne se défend que dans deux cas, l’absence de virtualisation (poste virtualisé sans virtualisation imbriquée) ou un travail fait presque exclusivement sur des fichiers Windows.

Installation avec wsl —install et choix de la distribution

Dans un PowerShell ouvert en administrateur :

wsl --list --online            # catalogue des distributions proposées
wsl --install -d Ubuntu-24.04  # sans -d : Ubuntu par défaut

Installation : Plateforme de machine virtuelle
Plateforme de machine virtuelle a été installé.
Installation : Ubuntu 24.04 LTS
L'opération demandée est réussie. Les modifications ne seront pas effectives
avant que le système ne soit redémarré.

Le libellé exact varie selon la version. La commande active les fonctionnalités Windows, installe le paquet WSL et son noyau, règle WSL 2 comme version par défaut et télécharge la distribution. Après redémarrage, le premier lancement demande un nom d’utilisateur et un mot de passe UNIX : ce compte est membre du groupe sudo et n’a aucun lien avec le compte Windows.

Si la commande échoue (Microsoft Store bloqué, image durcie), activer les fonctionnalités avec DISM (Deployment Image Servicing and Management), puis récupérer le paquet depuis GitHub :

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
# après redémarrage
wsl --update --web-download
wsl --install -d Ubuntu-24.04 --web-download

Quelle distribution ? Celle qui ressemble le plus à la cible de production. À défaut de cible, une Ubuntu à support long ou une Debian stable : la quasi-totalité des documentations d’outils les prennent pour référence. Une organisation qui veut une base maîtrisée construit son archive et la distribue par wsl --import (voir plus bas).

Premier geste dans la distribution, avant tout autre :

sudo apt update && sudo apt full-upgrade -y

Commandes wsl —status, —list, —update et —shutdown

Cinq commandes couvrent l’exploitation courante.

wsl --status
wsl --list --verbose
wsl --version

Distribution par défaut : Ubuntu-24.04
Version par défaut : 2

  NAME            STATE           VERSION
* Ubuntu-24.04    Running         2

Version WSL : 2.6.1.0
Version du noyau : 6.6.87.2-1

Les numéros sont indicatifs. La colonne VERSION tranche la question WSL 1 ou 2 par distribution ; wsl --set-version Ubuntu-24.04 2 convertit une distribution restée en version 1.

wsl --update     # met à jour le paquet WSL, noyau Linux compris
wsl --shutdown   # arrête la VM et toutes les distributions

Trois couches se mettent à jour séparément : Windows, le paquet WSL (qui embarque le noyau), et les paquets de la distribution. wsl --update ne touche pas à la troisième ; apt ne touche pas à la deuxième. Là où le Microsoft Store est bloqué, le noyau reste celui du jour de l’installation jusqu’au prochain wsl --update --web-download. Et une distribution éteinte ne se corrige pas : les mises à jour automatiques d’une Ubuntu ne tournent que pendant que la VM vit, c’est-à-dire pendant qu’un terminal est ouvert.

Attention

wsl --unregister <distribution> détruit le disque virtuel sans confirmation ni corbeille. wsl --terminate <distribution> arrête une distribution sans rien effacer : ne pas confondre les deux.

Fichiers .wslconfig et /etc/wsl.conf : portée et prise en compte

Deux fichiers, deux portées, et une confusion fréquente entre les deux.

• %UserProfile%\.wslconfig vit côté Windows et règle la VM WSL 2 entière : mémoire, processeurs, mode réseau. Il n’existe pas par défaut. Sans lui, la VM peut consommer jusqu’à 50 % de la mémoire de l’hôte et tous les processeurs logiques. Prise en compte : après wsl --shutdown uniquement.
• /etc/wsl.conf vit dans chaque distribution et règle son comportement : systemd, montage des disques Windows, interopérabilité, utilisateur par défaut. Prise en compte : après arrêt de la distribution (wsl --terminate). Fermer le terminal ne suffit pas, la distribution survit quelques secondes à sa dernière fenêtre.

Une section [experimental] existe dans .wslconfig (récupération de mémoire, disque creux). Ses clés changent de nom et de section d’une version à l’autre : vérifier la documentation Microsoft correspondant à wsl --version avant d’en dépendre.

Exemple de configuration .wslconfig et wsl.conf pour un poste d’entreprise

Côté Windows, fichier %UserProfile%\.wslconfig :

[wsl2]
# Défaut : 50 % de la mémoire Windows
memory=8GB
# Défaut : tous les processeurs logiques
processors=4
# Défaut : 25 % de la mémoire Windows
swap=2GB
# Windows 11 22H2 et suivants ; défaut : NAT
networkingMode=mirrored
# Résolution DNS confiée à Windows
dnsTunneling=true
# Reprend le proxy déclaré dans Windows
autoProxy=true
# Règles du pare-feu Windows appliquées à WSL
firewall=true

Dans la distribution, fichier /etc/wsl.conf :

[boot]
# Nécessaire aux services (conteneurs, minuteries)
systemd=true

[automount]
enabled=true
# Permissions Linux conservées sur /mnt/c
options="metadata,umask=022,fmask=011"

[interop]
enabled=true
# Le PATH Windows n'est plus ajouté au PATH Linux
appendWindowsPath=false

[user]
# À remplacer par le compte créé au premier lancement
default=dev

Les commentaires tiennent sur leur propre ligne, comme dans les exemples de la documentation Microsoft. Deux réglages méritent une explication. appendWindowsPath=false empêche qu’un node, un git ou un python installé côté Windows réponde à la place du binaire Linux, erreur silencieuse et pénible à diagnostiquer ; en contrepartie, explorer.exe ou code ne se lancent plus sans chemin complet. metadata fait persister chmod et chown sur les fichiers Windows ; sans cette option, tout fichier sous /mnt/c apparaît en 0777, et un client SSH (Secure Shell) refuse une clé privée aussi ouverte.

Application et vérification :

wsl --shutdown
wsl -d Ubuntu-24.04 -- systemctl is-system-running

running

Une réponse degraded signale une unité systemd en échec, pas une panne de WSL.

Modes réseau WSL 2 : NAT, mode miroir, dnsTunneling et pare-feu Hyper-V

Le mode réseau décide de qui voit qui. Le schéma oppose les deux modes ; lire surtout les flèches entrantes.

En mode NAT (Network Address Translation), la VM reçoit une adresse privée qui change à chaque redémarrage. Windows atteint un service Linux par localhost ; l’inverse demande l’adresse de la passerelle (ip route show default). Ce mode supporte mal les clients VPN (Virtual Private Network), qui réécrivent routes et résolution DNS (Domain Name System) sans prévenir la VM : le symptôme classique est une distribution qui ne résout plus aucun nom dès que le tunnel monte.

Le mode miroir (networkingMode=mirrored) réplique les interfaces de Windows dans Linux : mêmes adresses, IPv6 (Internet Protocol version 6) compris, 127.0.0.1 partagé dans les deux sens, meilleure tenue derrière un VPN. dnsTunneling fait répondre Windows aux requêtes DNS par un canal de virtualisation plutôt que par des paquets réseau, ce qui contourne les filtrages qui cassent le mode NAT. D’après la documentation Microsoft, le tunnel DNS est actif par défaut sous Windows 11 22H2 et suivants, et le pare-feu Hyper-V l’est à partir de WSL 2.0.9 ; ces défauts ont bougé au fil des versions, les écrire explicitement évite la surprise.

Recommandation : sous Windows 11 22H2 et suivants, mode miroir, tunnel DNS et pare-feu actifs. Rester en NAT si un outil de conteneurs du poste ne supporte pas le miroir, point à valider avant généralisation.

Le mode miroir expose un risque nouveau : un serveur de développement qui écoute sur 0.0.0.0 dans Linux écoute désormais sur les adresses du poste. Seul le pare-feu Hyper-V le sépare du réseau local. Ouvrir port par port :

# Identifiant fixe désignant les VM créées par WSL
New-NetFirewallHyperVRule -Name "WSL-8443" -DisplayName "WSL 8443 entrant" `
  -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `
  -Protocol TCP -LocalPorts 8443

La commande qui passe l’action entrante par défaut à Allow figure dans à peu près toutes les réponses de forum sur le sujet. Elle règle le problème du jour et expose chaque futur service de test au réseau d’entreprise. À proscrire. Pour le reste du sujet, voir le domaine réseaux.

Proxy d’entreprise et autorité de certification interne dans WSL

autoProxy=true recopie le proxy déclaré dans Windows vers les variables d’environnement Linux. Trois limites. sudo nettoie l’environnement, donc sudo apt ne voit pas ces variables. Les services lancés par systemd n’en héritent pas non plus. Et le mécanisme transmet une adresse, pas une identité : un proxy qui exige l’authentification intégrée Windows reste à traiter côté Linux.

Pour apt, déclarer le proxy explicitement (adresse à ajuster) :

echo 'Acquire::http::Proxy "http://proxy.example.internal:3128";' \
  | sudo tee /etc/apt/apt.conf.d/95proxy

Quand le proxy inspecte les flux TLS (Transport Layer Security), la distribution doit connaître l’autorité de certification interne. Le magasin de certificats de Windows n’est pas partagé avec Linux. Export côté Windows, en ajustant le filtre sur le nom de l’autorité (il doit ne retenir qu’un seul certificat) :

$c = Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*AC Racine Interne*"
Export-Certificate -Cert $c -FilePath $env:PUBLIC\ac-interne.cer
certutil -encode $env:PUBLIC\ac-interne.cer $env:PUBLIC\ac-interne.crt

Import côté Linux (Debian, Ubuntu) :

sudo cp /mnt/c/Users/Public/ac-interne.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

1 added, 0 removed; done.

Certains environnements d’exécution ignorent le magasin système. Node.js attend NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt, la bibliothèque Python requests attend REQUESTS_CA_BUNDLE avec la même valeur. C’est le point de blocage habituel des assistants de code en ligne de commande, d’où le statut de prérequis de cette page pour les guides Claude Code, Codex et GitHub Copilot en mode agent.

Désactiver la vérification des certificats « le temps de l’installation » est une mesure temporaire au sens où l’entend le secteur : elle sera encore là à la prochaine migration. Le domaine PKI et TLS détaille ce que cette vérification garantit.

Performances : /mnt/c contre le disque ext4 de la distribution

Sous WSL 2, les disques Windows montés sous /mnt ne sont pas des disques locaux : chaque accès traverse la frontière de la VM par un serveur de fichiers (protocole 9P). Les opérations sur beaucoup de petits fichiers paient le prix fort : git status, installation de dépendances, compilation. Microsoft recommande de garder les fichiers d’un projet sur le système de fichiers du système qui les manipule.

Règle : le dépôt vit dans le répertoire personnel Linux (~/projets), jamais sous /mnt/c/Users/.... Windows y accède par le partage \\wsl.localhost\Ubuntu-24.04\, et les éditeurs dotés d’un mode distant travaillent directement dans la distribution.

Autre effet de bord : les notifications de modification de fichiers ne remontent pas de façon fiable depuis les lecteurs Windows vers Linux. Un outil de rechargement à chaud qui « ne voit rien » surveille presque toujours un dossier sous /mnt/c.

Surface d’attaque de WSL : ce que la distribution n’isole pas

WSL n’est pas une frontière de sécurité vis-à-vis de l’utilisateur Windows qui le lance. Le présenter comme un bac à sable revient à présenter une porte battante comme un sas. Le schéma liste les passages ouverts par conception.

Conséquences directes :

• Le mot de passe sudo ne protège rien contre le compte Windows. wsl -u root ouvre un shell root sans rien demander. Tout logiciel qui tourne dans la session Windows peut en faire autant.
• Les secrets rangés dans la distribution sont ceux de la session Windows. Clés SSH, jetons d’accès, fichiers de configuration cloud : lisibles par \\wsl.localhost ou par montage du fichier ext4.vhdx, qui n’est pas chiffré en propre. La protection au repos vient du chiffrement de disque de l’hôte, pas de WSL.
• Un processus Linux compromis agit sur Windows. Il lit et modifie les fichiers de l’utilisateur sous /mnt/c et lance des binaires Windows par interopérabilité. enabled=false dans [interop] coupe ce canal, mais root peut réécrire /etc/wsl.conf : c’est un garde-fou, pas un contrôle.
• Angle mort de détection. Vu de Windows, WSL 2 se résume à un processus de machine virtuelle. Un EDR (Endpoint Detection and Response) ou une journalisation Sysmon côté Windows voient le lancement de wsl.exe et sa ligne de commande, ainsi que les binaires Windows démarrés par interopérabilité, mais rien de ce qui s’exécute dans Linux. Le guide journalisation Sysmon des postes Windows couvre la partie visible.

Ce qu’une organisation peut encadrer, d’après la documentation Microsoft :

• Stratégies de groupe et Intune. Des paramètres dédiés autorisent ou interdisent WSL en entier, WSL 1, le noyau personnalisé, la ligne de commande du noyau, la configuration réseau personnalisée, la modification du pare-feu par l’utilisateur, la virtualisation imbriquée, le montage direct de disques et le shell de débogage. La liste évolue : la vérifier pour la version déployée.
• Plug-in Microsoft Defender for Endpoint pour WSL. Il étend la télémétrie de l’hôte aux distributions WSL 2. Il suppose un poste déjà enrôlé et une version de WSL récente (2.0.7 au minimum selon la documentation).
• Durcissement de la distribution. Mises à jour, comptes, services en écoute : les principes du guide durcir un serveur Linux de production s’appliquent, en gardant en tête qu’aucun ne résiste à wsl -u root.

Ce que WSL ne garantit donc pas : l’isolation d’un code non fiable, la séparation entre distributions, la confidentialité des secrets vis-à-vis de la session Windows. Pour exécuter du code douteux, il faut une VM distincte, avec son propre compte et son propre réseau.

Sauvegarde et reprise : wsl —export, wsl —import et fichier ext4.vhdx

Toute la distribution tient dans un fichier ext4.vhdx rangé dans le profil Windows. Pour le localiser :

(Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss |
  Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu-24.04' }).GetValue("BasePath")

Le chemin renvoyé se trouve sous %LOCALAPPDATA%, soit le dossier que les profils itinérants et bon nombre de politiques de sauvegarde de poste excluent. Une réinitialisation de profil ou une réinstallation du poste emporte la distribution avec elle. Le fichier grossit avec l’usage et ne rétrécit pas tout seul quand on supprime des données.

Export, puis preuve par la réimportation :

New-Item -ItemType Directory -Force $env:USERPROFILE\wsl-sauvegarde | Out-Null
wsl --export Ubuntu-24.04 $env:USERPROFILE\wsl-sauvegarde\ubuntu-2404.tar
wsl --import Ubuntu-test $env:USERPROFILE\wsl-test $env:USERPROFILE\wsl-sauvegarde\ubuntu-2404.tar
wsl -d Ubuntu-test -- whoami

dev

Une fois la preuve faite, wsl --unregister Ubuntu-test supprime la copie d’essai (et elle seule : relire le nom avant de valider). La réponse est root si /etc/wsl.conf ne contient pas de section [user] : l’utilisateur par défaut d’une distribution installée est mémorisé côté Windows et ne voyage pas dans l’archive. Raison de plus pour l’écrire dans le fichier.

Trois règles d’exploitation. L’archive contient les secrets de la distribution en clair et se traite comme eux. Une archive stockée dans le même profil que sa source disparaît avec lui : la copier ailleurs. Et une sauvegarde jamais réimportée est un fichier .tar accompagné d’un espoir ; la démarche générale est décrite dans tester une restauration après sinistre. Le plus robuste reste de traiter la distribution comme jetable : code dans un dépôt distant, configuration dans un script d’amorçage, et reconstruction en quelques minutes.

🐝 Ce qui arrive si on s’en passe

Sans WSL, le besoin d’outils Linux sur un poste Windows ne disparaît pas : il se déplace. Il part vers des machines virtuelles tierces installées à la main, dont l’hyperviseur, le réseau et les images échappent aux stratégies de groupe prévues pour WSL et au plug-in de supervision. Ou vers des portages Windows des mêmes outils, où chemins, permissions et fins de ligne divergent de la cible de production, ce qui fabrique des scripts validés sur un système qui n’existe nulle part ailleurs. Et un poste où WSL est interdit sans alternative fournie voit apparaître des contournements que personne n’inventorie : on perd alors la seule chose qu’un encadrement apportait, la visibilité sur ce qui tourne.

🦫 Explication de la marmotte 🍫

Windows et Linux sont deux systèmes différents : un programme écrit pour l’un ne démarre pas sur l’autre. L’outil décrit ici lance Linux à l’intérieur de Windows, sans redémarrer l’ordinateur. Pour y arriver, le processeur doit accepter de faire tourner un second système en même temps que le premier ; cette capacité se règle au démarrage de la machine, et sans elle rien ne se lance. Une seule commande, tapée avec les droits d’administrateur, active les composants nécessaires, télécharge Linux et demande un redémarrage. Ensuite, Linux vit dans un gros fichier rangé dans le dossier de l’utilisateur Windows. Deux fichiers de réglages décident du reste : l’un fixe la mémoire et le type de connexion réseau, l’autre fixe le comportement de chaque Linux installé. Trois choses cassent souvent. Le réseau d’une entreprise bloque les téléchargements tant que Linux ne connaît ni le relais obligatoire ni le fichier qui permet de vérifier l’identité des sites. Les fichiers rangés côté Windows sont lents à lire depuis Linux. Et les mises à jour ne partent pas toutes seules : il faut les lancer. Dernier point : ce Linux n’est pas protégé de Windows. La personne connectée à Windows peut y devenir administrateur sans mot de passe, et Linux peut lire ses fichiers Windows. Les outils de surveillance de l’entreprise n’y voient presque rien sans un module ajouté. Enfin, le gros fichier doit être copié ailleurs régulièrement, sinon tout disparaît avec lui.

À lire aussi

• Évasion de VM et isolation matérielle des hyperviseursComprendre l’évasion de machine virtuelle, les failles d’hyperviseur et les limites de SEV-SNP et TDX face à un hôte compromis.
• Virtualisation réseau, NFV et data planes ouvertsComprendre la virtualisation réseau comme abstraction d’équipements, de fonctions et de chemins : isolation, overlays, NFV, data planes accélérés et plateformes open source.
• Isolation multi-locataire face à un locataire hostileQuelle frontière poser à chaque couche d'une plateforme mutualisée quand l'un des locataires est hostile, du noyau partagé à l'hôte dédié, et ce que chaque palier laisse passer.
• Isolation des conteneurs Docker : namespaces, cgroups et évasionsCe qu'isole réellement un conteneur Docker sous Linux (espaces de noms, cgroups, capacités, seccomp, AppArmor ou SELinux), les évasions documentées et les configurations qui annulent cette isolation.

Pages voisines

La citent

• Kali Linux pour les tests d'intrusion, usages, limites et détection

Installer WSL 2 sous Windows 10 et 11, configuration et sécurité

Elle cite

• ⇄Lien dans les deux sens :Installer et utiliser Claude Code, l'agent de code d'Anthropic
• ⇄Lien dans les deux sens :Installer et utiliser Codex, l'agent de code d'OpenAI
• ⇄Lien dans les deux sens :Installer et utiliser GitHub Copilot en mode agent
• Centraliser les journaux Sysmon des postes Windows
• Durcir un serveur Linux avant la mise en production, checklist
• Tester une restauration après sinistre simulé
• Construire une autorité de certification privée interne
• EDR : fonctionnement, angles morts et contournements
• Hyperviseur Type 1 ou Type 2 : lequel choisir

⇄ : les deux pages se citent l’une l’autre.