How to create a secure and well-configured WSL 2 environment

If you work with Windows but need The full power of Linux for developing or managing systemsWSL becomes an almost mandatory companion. The problem is that many install it hastily, without considering security, performance, or how to properly integrate it with the company's tools. In a corporate environment or with sensitive data, that's playing with fire.

In the following lines you will see how create a truly secure, well-configured, and comfortable WSL 2 environmentWhether you're a local developer or managing dozens of computers in an organization with Intune, Microsoft Defender, and advanced network controls, the goal is for you to end up with a robust, manageable, and easy-to-maintain WSL, not just "another Linux" that no one really knows what it's doing.

What is WSL and why is it so interesting… but not harmless?

WSL (Windows Subsystem for Linux) is a feature of Windows 10 and Windows 11 allowing Run complete Linux distributions directly on Windowswithout needing to set up a traditional virtual machine in VirtualBox or VMware. In practical terms, you install Ubuntu, Debian, Kali, or AlmaLinux from the Microsoft Store and use them like any other application.

With WSL 2, Microsoft took a major leap: it now runs a real Linux kernel on top of a lightweight virtual machine based on Hyper-VThis greatly improves performance, compatibility with system calls, and makes it possible to use tools that were unfeasible in WSL1, such as Docker. databases heavyweight or GPU-accelerated machine learning environments.

The big advantage is that You don't have to manually manage the virtual machine or complex networkingWindows is responsible for setting up the environment, mounting the file systems, exposing the \wsl$ paths, and making Linux and Windows "see" each other, both at the file and command levels, with a fairly transparent integration.

For developers and admins who live on Windows but deploy on Linux, this means they can now work in an environment virtually identical to production without leaving your usual desktop, reusing the same libraries, database managers, message queues, web servers, etc. And all this without sacrificing the ability to continue using Visual Studio, Office, or your usual corporate tools.

Safe basic installation of WSL 2

The first step to having a secure WSL environment is install it correctly and on an updated Windows systemStarting with Windows 10 22H2 and Windows 11 22H2, WSL is very well integrated into the system, and with the simplified command wsl --install You can get it working in just a few minutes.

First of all, it is advisable Check the Windows version and build numberPress the Windows key + R, type winver And check that you're on a recent build. If not, update from Settings or using the Windows Update Assistant. This isn't just a whim: many networking, security, and integration improvements are only available in recent versions.

Then open PowerShell or Symbol of the system as administrator and run the basic installation command:

wsl --install

This command is responsible for Enable the optional components of WSL and the Virtual Machine PlatformDownload the latest Linux kernel, set WSL 2 as the default version, and automatically install an Ubuntu distribution (though you can add others later). A reboot may be required during the process; don't skip it, because without it, the virtualization and kernel won't be configured correctly.

If you prefer to choose a distribution other than Ubuntu, such as Debian, Kali, AlmaLinux, or similar, you can use the commands to list available images and install them manually. wsl --install -d <NombreDistro>or download them from the Microsoft Store. In business environments, you can also use custom images with wsl --import y wsl --export to ensure that everyone works on the same approved basis.

Secure creation and management of users and passwords in WSL

Once the distribution is installed, running it for the first time from the Start menu will start a small wizard that will ask you create your own Linux username and passwordThese credentials have no relation to the Windows account; they are independent for each distro.

That first user becomes the default user with sudo privilegesThat is, it will be the one that can perform administrative tasks through sudoFrom a security standpoint, it's important to treat it as what it is: a powerful account. Choose one strong passwordDo not reuse the Windows one and avoid sharing it "for convenience" with the rest of the team.

Note that Each distribution installed in WSL has its own set of usernames and passwordsIf you reinstall, reset, or import a new distribution, you'll have to repeat the user creation process. When managed properly, this is an advantage: you can isolate development or testing environments with separate accounts.

To change the password From an account, simply run the command within the distro passwdEnter your current password and then your new one. If you have completely forgotten your Linux password, you can enter as root from PowerShell running:

wsl -u root

If the distro is not the default, wearing:

wsl -d <NombreDistro> -u root

Once inside, you will be able to update the affected user's password with passwd <usuario>When you finish, write exit to close the root session. This ability to elevate privileges from Windows is very practical, but it's advisable Protect access to the PowerShell team effectivelyBecause, if someone sits down at your unlocked machine, they could use this method to modify Linux accounts.

Secure maintenance: package and kernel updates

Windows doesn't handle Automatically update the Linux user space within WSLThis means that, just like on a classic Linux server, it is you (or your IT team) who must apply security patches regularly to prevent vulnerabilities in libraries, databases, interpreters, etc.

In Debian or Ubuntu-based distributions, the minimum maintenance cycle would run periodically:

sudo apt update && sudo apt upgrade

This gives you the latest list of packages and allows you to apply available updates. This can be useful in enterprise environments. integrate specific configuration management tools (Puppet, Ansible, Chef, etc.) that allow these updates to be orchestrated across many machines simultaneously. Microsoft documents, for example, how to run Puppet over WSL 2 for this purpose.

On the other hand, the WSL kernel is also updated independently. If, when trying to use WSL 2, you receive messages like “WSL 2 requires an update to its kernel component”, you will need to Download the updated kernel package Download the kernel from Microsoft and install it manually. It's a simple executable: launch it, restart, and you're done. Keeping that kernel up to date is essential to benefit from performance improvements, compatibility enhancements, and security patches.

WSL, WSL 2 and other technologies: choosing the right scenario

Before diving headfirst into securing a WSL environment, it's worth being clear on the following: In what cases is it the appropriate tool and in which cases is it not?Ultimately, you have other options: a full virtual machine, Boot dual, pure Docker containers, etc.

WSL 1 was a compatibility layer that translated Linux calls to Windows; useful for basic tasks, but limited, without full kernel support and with problems for tools like Docker. WSL 2, on the other hand, runs a real Linux kernel in a lightweight VM, with a native hypervisor, offering performance improvements of up to 500% on certain workloads and supporting services that were previously impossible.

Compared to a classic virtual machineWSL 2 is much lighter in RAM and CPU consumptionIt starts up in seconds and fully integrates with the Windows file system. However, a traditional VM still has advantages when you need very granular hardware control, high-production scenarios, or very specific network configurations.

Compared to dual boot, WSL avoids having to Restart the computer to switch from Windows to Linux and vice versa.Linux can read partitions without problems NTFS Windows, and Windows, thanks to WSL, can access ext4 file systems. This greatly reduces the need to switch operating systems just to view or copy files.

Finally, Docker and WSL are a good fit: Docker Desktop on Windows relies on WSL 2 to efficiently deliver Linux-based containers. Docker isolates services in minimal containers, while WSL offers a complete Linux environment in which to develop, test and orchestrate those containersThey are complementary pieces, not rivals.

Storage and file system access: security and performance

One of the key points to secure and optimize your environment is decide where to store the project filesAlthough Windows and Linux can access each other's file systems, not all scenarios offer the same performance or level of control.

The general recommendation for projects that primarily use Linux tools is store the code within the distro's file systemThat is, on routes of the type:

\\wsl$\<NombreDistro>\home\<Usuario>\Proyecto

Accessing those paths from Linux is very fastTo do it from Windows, for example with Explorer, involves the network path \\wsl$which is perfectly supported.

What should be avoided is working in reverse: leave the projects in C:\Users\<Usuario>\Proyecto and manipulate them from Linux through /mnt/cThis works, but it penalizes performance, and under heavy I/O loads, the impact can be noticeable. Furthermore, mixing Windows permissions and ACLs with Linux POSIX permissions can be confusing if you're not familiar with them.

Launch Windows Explorer in the current directory from the terminal WSL is done simply with:

explorer.exe .

and from Linux access Windows using the paths set up in /mnt/c, /mnt/detc. The trick is to use this interoperability as a a temporary wildcard and not as the main basis of workespecially if you're concerned about performance or permission traceability.

Configuring editors and development tools on WSL

To make your environment truly productive, you need an editor or IDE that integrates natively with WSL. Here Visual Studio Code Visual Studio plays a leading role, with specific support for working "inside" the distro as if it were a remote server.

Visual Studio Code, with the “Remote Development Pack”, allows you to Open a WSL folder and run extensions, terminal, and debuggers directly in Linux. while the interface runs on Windows. Once the appropriate extensions are installed, from the WSL terminal you just need to run:

code .

To open the current directory in VS Code while connected to your distribution. This allows you to switch environments (host, WSL, etc.). SSH, container) practically on the fly and without "cluttering" your Windows with project-specific dependencies.

Visual Studio 2022 has also improved its integration: now you can Compile and debug CMake projects targeting WSLto remote machines via SSH or to Windows itself, all from the same IDE instance. For cross-platform C++ development, this option is especially powerful, as it allows you to verify the behavior in real Linux from the comfort of the Windows environment.

Configure your shell To streamline daily tasks, but with a sensible approach, it's advisable. A typical example is editing the file .bashrc o .zshrc to include aliases that facilitate access to Windows paths, such as:

alias cnn="cd /mnt/c/Users/tu_usuario"

However, you must be careful when working with these files: an error in .bashrc can leave the shell in a strange stateTherefore, the ideal way to open them is from WSL with VS Code (code .bashrc) and make incremental changes, testing each modification.

Version control and containers: Git and Docker in WSL

WSL is intended to be a central piece of the modern development flow, and there Git and Docker become inseparable companionsIntegrating them well is essential for both productivity and safety.

With Git, the recommendation is to install and use it directly within the Linux distribution. This way, the line endings, executable file permissions, and paths They handle the same functions as in any normal Linux environment, reducing surprises when deploying to servers. You can combine it with the Windows Credential Manager to manage authentication with GitHub, Azure DevOps, or GitLab without exposing plaintext tokens within the WSL.

As for Docker, the arrival of WSL 2 was a game-changer: Docker Desktop can now take advantage of WSL lightweight virtual machine as a Linux container runtime engineIt integrates seamlessly with your Linux distributions and offers very decent performance. With the appropriate network configuration and shared paths, you can launch containers from the WSL terminal as if you were on a pure Linux server.

For more advanced scenarios, you can also Launching containers directly from WSL without Docker DesktopUsing dockerd within the distro, although in a business environment it is usually more convenient to standardize on the official Docker Desktop solution and its update and telemetry policies.

Advanced network and firewall configurations for a secure WSL

When we talk about real security, we need to take a close look at the WSL network behavior and its integration with the Windows firewallStarting with Windows 11 22H2 and WSL 2.0.9, host firewall rules are automatically applied to WSL distributions, which greatly simplifies control.

This means that any corporate firewall policy configured in Windows Defender Firewall (or managed from Intune or GPO) is effectively replicated in the WSL environment. For special cases, you can further customize the behavior by adjusting the Hyper-V firewall, which WSL relies on internally.

In addition, Microsoft has introduced advanced options in the file .wslconfig under section , such as:

• networkingMode=mirrored: Enables a mirrored network mode that improves compatibility with VPNs, IPv6, and complex network environments, avoiding many of the headaches of classic NAT mode.
• dnsTunneling=true: changes the way WSL DNS resolutionUsing virtualization capabilities instead of relying on direct network packets. Very useful if you have aggressive firewall rules, proxies, or VPNs that break name resolution.
• autoProxy=true: forces WSL to reuse the Windows HTTP proxy configuration, which is crucial in companies where all traffic must go through a corporate proxy or inspection systems.

If all this is accompanied by good update control, access policies, and network segmentation, you can have a WSL environment that do not create a "side hole" in your security architecturebut a more integrated and monitorable component.

Enterprise management: Intune, Defender for Endpoint, and custom images

In organizations where there are dozens or hundreds of portable With WSL enabled, it's no longer enough for each developer to "make do." It's necessary a centralized approach to configuring, monitoring, and limiting WSL usage in line with house policies.

Microsoft Intune, for its part, can be used to manage access to WSL, its components, and key security parametersFrom Intune, it's possible to apply policies to enable or disable WSL as a Windows component, define recommended configurations, and deploy files. .wslconfig with specific network values ​​and ensure alignment with the rest of the corporate tools.

A very interesting pattern for companies is the custom WSL image creationThe idea is simple: you install WSL on a reference machine, downloads You choose the Linux distribution you need (for example, "corporate" Ubuntu or AlmaLinux tailored to your stack), install packages, tools, agents, and standard configurations, and when you have everything the way you want it, export the distro with:

wsl --export <NombreDistro> <RutaArchivo.tar>

That image in tar format can be distributed internally (network shares, software management systems, etc.) and then to each user or device import it locally with:

wsl --import <NombreDistro> <RutaInstalacion> <RutaArchivo.tar>

In this way, all developers start from a controlled and security-approved environmentwith the same versions of interpreters, databases, monitoring agents, and hardening rules. This strategy is especially useful when working with distributions not available in the Store (CentOS, Red Hat enterprise variants, etc.) or when a very specific baseline is desired.

Command interoperability and access to the Windows file system

One of WSL's most powerful (and at the same time delicate) features is the interoperability between Linux and Windows commandsFrom PowerShell you can run Linux tools with wsl <comando>And from WSL you can invoke Windows executables ending in .exe.

From PowerShell you can list the contents of a directory using ls -la typical of Linux with:

wsl ls -la

or combine ls to findstr (wsl ls -la | findstr "git") to filter results, or vice versa, use dir | wsl grep gitFrom the Linux terminal you can open Windows Notepad to edit .bashrc to notepad.exe .bashrcor take advantage of tools such as ipconfig.exe and process its output with grep y cut.

Regarding file access, when a Linux binary within WSL opens a file in C:\, it does with the permissions of the Windows user who ran wsl.exeThis means that even if you have root access within the distribution, you won't be able to perform administrative operations on Windows if your Windows account doesn't allow them. Windows security remains the underlying "hard layer."

Conversely, this interoperability requires order. It's not a good idea, for example, to Leaving scripts that intensively mix Windows and Linux paths without a full understanding of permissions and impactIn sensitive environments, it is advisable to limit which Windows tools are exposed through WSL and vice versa, and to train users to know what is actually running on each side.

GUI, GPU, and drive mounting applications in WSL

WSL was originally designed for terminal use, but little by little other things have been arriving More advanced capabilities: Linux graphical applications, GPU acceleration, and external disk mounting with typical server file systems.

It is now possible to configure WSL to run Linux GUI applications These integrate with the Windows desktop, minimizing the need for full virtual machines. For those who need to use native Linux IDEs, tools with their own interfaces, or guided administration environments, this opens up a very interesting range of possibilities. In some cases, external solutions like Win-KeX (in Kali) are still used, which, via VNC, provide a complete desktop integrated with Windows.

In the area of ​​machine learning and heavy workloads, WSL also supports GPU-accelerated trainingSetting it up properly drivers And in this environment, you can leverage the computer's graphics from within Linux for high-performance tasks without leaving the Windows ecosystem. This is especially useful for data scientists and AI developers who want a single, all-in-one workstation.

Finally, WSL 2 allows Mount external drives or disks with Linux file systemsfile systems like ext4, which are not typically visible natively in Windows, can be mounted from WSL if you need to access a data disk on a Linux server or an older system. This allows you to work from the command line without resorting to third-party tools or a standalone virtual machine.

The recommendation, however, is to treat these setups with the same level of caution as a real server: Review permissions, avoid running unknown scripts, and control who has access to the physical equipment and the WSL environment.because the assembled data can be very sensitive.

Troubleshooting and security best practices

WSL is robust, but it is not without its flaws. Typical installation errors, compatibility issues, and virtualization conflictsKnowing the most common problems helps both to solve them quickly and to avoid botched configurations that later take their toll.

Common errors include codes 0x80070003 y 0x80370102 during installation, which they usually indicate problems with virtualization in the BIOS/UEFI or with the location of the distributions (WSL only works correctly on the drive where Windows is installed, usually C:). Another common error is that the optional WSL component is not enabled; this can be corrected by enabling "Windows Subsystem for Linux" from Windows Features or with the appropriate DISM/PowerShell commands.

Another common error is the message “The Windows Subsystem for Linux does not have any distribution installed,” which can appear even if you have already downloaded a distro. In these cases, it is usually enough to Run the distribution at least once from the Start menu. so that the initial configuration is completed before calling it from the command line.

At the performance level, Check that you are in WSL 2 (With wsl -l -v), that you have sufficient hardware resources, that you are not working over slow routes (/mnt/c for large projects) and that the virtualization is not being interfered with by other solutions (e.g., other third-party VMs or misconfigured security tools).

From a purely security standpoint, some basic good practices would be limit the number of installed distributions (avoid collections of distros without real use), use only approved or known images, keep both Windows and WSL up to date, disable WSL on computers that do not need it, and, in companies, rely on Intune and Defender for Endpoint for centralized visibility and control.

With all of the above applied, WSL goes from being a simple “Linux inside Windows” to a a solid, controllable work environment aligned with security policies, which allows developers and administrators to move freely between worlds without leaving loose ends or improvised backdoors.