Cómo crear un entorno WSL 2 seguro y bien configurado

Si trabajas con Windows pero necesitas toda la potencia de Linux para desarrollar o administrar sistemas, WSL se convierte en un compañero casi obligatorio. El problema es que muchos lo instalan a toda prisa, sin pensar en seguridad, rendimiento ni en cómo integrarlo bien con las herramientas de la empresa. Eso, en un entorno corporativo o con datos sensibles, es jugar con fuego.

En las próximas líneas vas a ver cómo crear un entorno WSL 2 realmente seguro, bien configurado y cómodo, tanto si eres un desarrollador que trabaja en local como si gestionas decenas de equipos en una organización con Intune, Microsoft Defender y controles de red avanzados. La idea es que termines con un WSL robusto, controlable y fácil de mantener, y no con “otro Linux más” que nadie sabe muy bien qué está haciendo.

Qué es WSL y por qué es tan interesante… pero no inocuo

WSL (Windows Subsystem for Linux) es una característica de Windows 10 y Windows 11 que permite ejecutar distribuciones Linux completas directamente sobre Windows, sin necesidad de montar una máquina virtual clásica en VirtualBox o VMware. A efectos prácticos, instalas Ubuntu, Debian, Kali o AlmaLinux desde la Microsoft Store y los usas como si fueran una aplicación más.

Con WSL 2, Microsoft dio un salto importante: ahora se ejecuta un kernel Linux real sobre una máquina virtual ligera basada en Hyper-V. Esto mejora muchísimo el rendimiento, la compatibilidad con llamadas al sistema y hace posible usar herramientas que en WSL1 eran inviables, como Docker, bases de datos pesadas o entornos de machine learning acelerados por GPU.

La gran ventaja es que no tienes que gestionar manualmente la máquina virtual ni el networking complejo. Windows se encarga de levantar el entorno, montar los sistemas de archivos, exponer las rutas \wsl$ y hacer que Linux y Windows “se vean” mutuamente, tanto a nivel de archivos como de comandos, con una integración bastante transparente.

Para los desarrolladores y admins que viven en Windows pero despliegan en Linux, esto significa que ahora pueden trabajar en un entorno prácticamente idéntico a producción sin abandonar su escritorio habitual, reutilizando las mismas librerías, gestores de bases de datos, colas de mensajería, servidores web, etc. Y todo ello sin sacrificar la posibilidad de seguir usando Visual Studio, Office o las herramientas corporativas de siempre.

Instalación básica de WSL 2 de forma segura

Lo primero para tener un entorno WSL seguro es instalarlo correctamente y sobre una base de Windows actualizada. A partir de Windows 10 22H2 y Windows 11 22H2, WSL viene muy integrado en el sistema, y con el comando simplificado wsl --install puedes dejarlo funcionando en pocos minutos.

Antes de nada conviene comprobar la versión y compilación de Windows. Pulsa la tecla de Windows + R, escribe winver y revisa que estés en una build reciente. Si no, actualiza desde Configuración o usando el Asistente de actualización de Windows. Esto no es un capricho: muchas mejoras de red, seguridad e integración solo están disponibles en versiones modernas.

A continuación, abre PowerShell o el Símbolo del sistema como administrador y ejecuta el comando básico de instalación:

wsl --install

Este comando se encarga de habilitar los componentes opcionales de WSL y la Plataforma de máquina virtual, descargar el kernel Linux más reciente, establecer WSL 2 como versión por defecto e instalar una distribución Ubuntu automáticamente (aunque luego podrás añadir otras). Es posible que se requiera un reinicio durante el proceso; no lo saltes, porque sin él la virtualización y el kernel no se terminan de configurar bien.

Si prefieres elegir otra distribución distinta a Ubuntu, como Debian, Kali, AlmaLinux o similares, puedes usar los comandos para listar imágenes disponibles e instalarlas a mano con wsl --install -d <NombreDistro>, o bien descargarlas desde la propia Microsoft Store. En entornos empresariales, además, puedes usar imágenes personalizadas con wsl --import y wsl --export para garantizar que todo el mundo trabaja sobre la misma base aprobada.

Creación y gestión segura de usuarios y contraseñas en WSL

Una vez instalada la distribución, al ejecutarla por primera vez desde el menú Inicio se inicia un pequeño asistente que te pedirá crear un usuario y una contraseña de Linux propios. Estos credenciales no tienen ninguna relación con la cuenta de Windows; son independientes para cada distro.

Ese primer usuario se convierte en el usuario predeterminado con privilegios sudo, es decir, será el que podrá ejecutar tareas administrativas mediante sudo. A nivel de seguridad es importante tratarlo como lo que es: una cuenta potente. Elige una contraseña robusta, no reutilices la de Windows y evita compartirla “por comodidad” con el resto del equipo.

Ten en cuenta que cada distribución instalada en WSL tiene su propio set de usuarios y contraseñas. Si reinstalas, reseteas o importas una nueva distribución, tendrás que repetir el proceso de creación de usuario. Esto, bien gestionado, es una ventaja: puedes aislar entornos de desarrollo o pruebas con cuentas diferenciadas.

Para cambiar la contraseña de una cuenta, basta con ejecutar dentro de la distro el comando passwd, introducir la contraseña actual y luego la nueva. Si lo que ha ocurrido es que has olvidado por completo la contraseña de Linux, puedes entrar como root desde PowerShell ejecutando:

wsl -u root

Si la distro no es la predeterminada, usando:

wsl -d <NombreDistro> -u root

Una vez dentro, podrás actualizar la contraseña del usuario afectado con passwd <usuario>. Cuando termines, escribe exit para cerrar la sesión de root. Esta capacidad de elevar privilegios desde Windows es muy práctica, pero conviene proteger bien el acceso al equipo y a PowerShell, porque, si alguien se sienta en tu máquina desbloqueada, podría aprovechar esta vía para modificar cuentas de Linux.

Mantenimiento seguro: actualización de paquetes y kernel

Windows no se ocupa de actualizar automáticamente el espacio de usuario de Linux dentro de WSL. Eso significa que, igual que en un servidor Linux clásico, eres tú (o tu equipo de IT) quien debe aplicar parches de seguridad regularmente para evitar vulnerabilidades en librerías, bases de datos, intérpretes, etc.

En distribuciones basadas en Debian o Ubuntu, el ciclo mínimo de mantenimiento sería ejecutar periódicamente:

sudo apt update && sudo apt upgrade

Con eso obtienes la lista más reciente de paquetes y aplicas actualizaciones disponibles. En entornos empresariales puede ser conveniente integrar herramientas específicas de gestión de configuración (Puppet, Ansible, Chef, etc.) que permitan orquestar estos updates en muchas máquinas a la vez. Microsoft documenta, por ejemplo, cómo correr Puppet sobre WSL 2 para tal fin.

Por otro lado, el kernel de WSL también se actualiza de forma independiente. Si al intentar usar WSL 2 recibes mensajes del estilo “WSL 2 requires an update to its kernel component”, tendrás que descargar el paquete actualizado de kernel desde Microsoft e instalarlo manualmente. Es un ejecutable sencillo: lo lanzas, reinicias y listo. Mantener ese kernel al día es fundamental para beneficiarte de mejoras de rendimiento, compatibilidad y parches de seguridad.

WSL, WSL 2 y otras tecnologías: elegir bien el escenario

Antes de meterte de lleno a securizar un entorno WSL, merece la pena tener claro en qué casos es la herramienta adecuada y en cuáles no. Al fin y al cabo, tienes otras opciones: máquina virtual completa, arranque dual, contenedores Docker puros, etc.

WSL 1 era una capa de compatibilidad que traducía llamadas de Linux a Windows; útil para tareas básicas, pero limitada, sin soporte completo de kernel y con problemas para herramientas como Docker. WSL 2, en cambio, ejecuta un kernel Linux real en una VM ligera, con un hypervisor nativo, ofreciendo mejoras de rendimiento de hasta un 500 % en ciertas cargas y dando soporte a servicios que antes eran imposibles.

Comparado con una máquina virtual clásica, WSL 2 es mucho más ligero en consumo de RAM y CPU, arranca en segundos y se integra totalmente con el sistema de archivos de Windows. Eso sí, una VM tradicional sigue teniendo ventajas cuando necesitas un control muy granular del hardware, escenarios de alta producción o configuraciones de red muy específicas.

Frente al arranque dual, WSL evita tener que reiniciar el equipo para pasar de Windows a Linux y viceversa. Linux puede leer sin problemas particiones NTFS de Windows, y Windows, gracias a WSL, puede acceder a sistemas de archivos ext4. Eso reduce mucho la necesidad de andar cambiando de sistema operativo solo para consultar o copiar archivos.

Por último, Docker y WSL encajan bastante bien: Docker Desktop en Windows se apoya precisamente en WSL 2 para ofrecer contenedores basados en Linux de manera eficiente. Docker aísla servicios en contenedores mínimos, mientras que WSL te ofrece un entorno Linux completo donde desarrollar, testear y orquestar esos contenedores. Son piezas complementarias, no rivales.

Almacenamiento y acceso al sistema de archivos: seguridad y rendimiento

Uno de los puntos clave para asegurar y optimizar tu entorno es decidir dónde guardas los archivos del proyecto. Aunque Windows y Linux pueden acceder mutuamente a sus sistemas de archivos, no todos los escenarios dan el mismo rendimiento ni el mismo nivel de control.

La recomendación general para proyectos que se trabajan principalmente con herramientas Linux es almacenar el código dentro del sistema de archivos de la distro. Es decir, en rutas del tipo:

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

Acceder a esas rutas desde Linux es muy rápido; hacerlo desde Windows, por ejemplo con el Explorador, pasa por la ruta de red \\wsl$, que está perfectamente soportada.

Lo que conviene evitar es trabajar al revés: dejar los proyectos en C:\Users\<Usuario>\Proyecto y manipularlos desde Linux a través de /mnt/c. Esto funciona, pero penaliza el rendimiento y, en cargas grandes de I/O, puede ser notable. Además, mezclar permisos y ACLs de Windows con permisos POSIX de Linux puede generar confusión si no lo tienes claro.

Lanzar el Explorador de Windows en el directorio actual desde la propia terminal de WSL se hace simplemente con:

explorer.exe .

y desde Linux acceder a Windows mediante las rutas montadas en /mnt/c, /mnt/d, etc. El truco está en usar esta interoperabilidad como un comodín puntual y no como base principal de trabajo, especialmente si te preocupa el rendimiento o la trazabilidad de permisos.

Configuración de editores y herramientas de desarrollo sobre WSL

Para que tu entorno sea realmente productivo, necesitas un editor o IDE que se integre de forma nativa con WSL. Aquí Visual Studio Code y Visual Studio juegan un papel protagonista, con soporte específico para trabajar “dentro” de la distro como si fuera un servidor remoto.

Visual Studio Code, con el “Remote Development Pack”, te permite abrir una carpeta de WSL y ejecutar extensiones, terminal y depuradores directamente en Linux mientras la interfaz corre en Windows. Una vez instaladas las extensiones adecuadas, desde la terminal de WSL solo tienes que ejecutar:

code .

para abrir el directorio actual en VS Code conectado a tu distro. Esto te permite cambiar de entorno (host, WSL, SSH, contenedor) prácticamente al vuelo y sin “ensuciar” tu Windows con dependencias específicas de cada proyecto.

Visual Studio 2022 también ha mejorado su integración: ahora puedes compilar y depurar proyectos CMake dirigidos a WSL, a máquinas remotas por SSH o al propio Windows, todo desde la misma instancia del IDE. Para desarrollos C++ multiplataforma, esta opción es especialmente potente, ya que te permite verificar el comportamiento en Linux real desde la comodidad del entorno Windows.

Configurar tu shell para agilizar el día a día pero con cabeza es recomendable. Un ejemplo típico es editar el archivo .bashrc o .zshrc para incluir aliases que faciliten el acceso a rutas de Windows, como:

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

Eso sí, hay que ser cuidadoso al tocar estos ficheros: un error en .bashrc puede dejar la shell en un estado extraño. Por eso, lo ideal es abrirlos desde WSL con VS Code (code .bashrc) y hacer cambios incrementales, probando cada modificación.

Control de versiones y contenedores: Git y Docker en WSL

WSL está pensado para ser una pieza central del flujo de desarrollo moderno, y ahí Git y Docker se convierten en compañeros inseparables. Integrarlos bien es esencial tanto para productividad como para seguridad.

Con Git, la recomendación es instalarlo y usarlo directamente en la distribución Linux. De este modo, las terminaciones de línea, permisos de archivos ejecutables y rutas se manejan como en cualquier entorno Linux normal, lo que reduce sorpresas al desplegar en servidores. Puedes combinarlo con el Administrador de Credenciales de Windows para gestionar autenticaciones frente a GitHub, Azure DevOps o GitLab sin tener que exponer tokens en texto plano dentro del WSL.

En cuanto a Docker, la llegada de WSL 2 cambió las reglas del juego: Docker Desktop puede aprovechar la máquina virtual ligera de WSL como motor de ejecución de contenedores Linux, integrándose con tus distros y ofreciéndote un rendimiento muy decente. Con la configuración apropiada de networking y paths compartidos, puedes levantar contenedores desde la terminal de WSL como si estuvieras en un server Linux puro.

Para escenarios más avanzados, también puedes levantar contenedores directamente desde WSL sin Docker Desktop, usando dockerd dentro de la distro, aunque en un entorno empresarial suele ser más cómodo estandarizar sobre la solución oficial de Docker Desktop y sus políticas de actualización y telemetría.

Configuraciones de red avanzadas y firewall para un WSL seguro

Cuando hablamos de seguridad real, hay que mirar de cerca el comportamiento de red de WSL y su integración con el firewall de Windows. A partir de Windows 11 22H2 y WSL 2.0.9, las reglas de firewall del host se aplican automáticamente a las distribuciones WSL, lo que simplifica mucho el control.

Esto significa que cualquier política de firewall corporativa configurada en Windows Defender Firewall (o gestionada desde Intune o GPO) se replica de forma efectiva en el entorno WSL. Para casos especiales, puedes personalizar aún más el comportamiento ajustando el firewall de Hyper-V, sobre el que se apoya internamente WSL.

Además, Microsoft ha introducido opciones avanzadas en el archivo .wslconfig bajo la sección , como:

• networkingMode=mirrored: habilita un modo de red reflejada que mejora la compatibilidad con VPNs, IPv6 y entornos de red complejos, evitando muchos de los dolores de cabeza del modo NAT clásico.
• dnsTunneling=true: cambia la forma en que WSL resuelve DNS, usando capacidades de virtualización en lugar de depender de paquetes de red directos. Muy útil si tienes reglas de firewall agresivas, proxies o VPN que rompen la resolución de nombres.
• autoProxy=true: obliga a WSL a reutilizar la configuración de proxy HTTP de Windows, algo crucial en empresas donde todo el tráfico debe pasar por un proxy corporativo o sistemas de inspección.

Si todo esto se acompaña de un buen control de actualizaciones, políticas de acceso y segmentación de la red, puedes tener un entorno WSL que no suponga un “agujero lateral” dentro de tu arquitectura de seguridad, sino un componente más integrado y monitoreable.

Gestión empresarial: Intune, Defender para Endpoint e imágenes personalizadas

En organizaciones donde hay decenas o cientos de portátiles con WSL habilitado, ya no basta con que cada desarrollador “se apañe”. Es necesario un enfoque centralizado para configurar, supervisar y limitar el uso de WSL en línea con las políticas de la casa.

Por su parte, Microsoft Intune se puede usar para administrar el acceso a WSL, sus componentes y parámetros clave de seguridad. Desde Intune es posible aplicar políticas para habilitar o deshabilitar WSL como componente de Windows, definir configuraciones recomendadas, desplegar archivos .wslconfig con valores de red específicos y asegurar alineamiento con el resto de herramientas corporativas.

Un patrón muy interesante para empresas es la creación de imágenes WSL personalizadas. La idea es sencilla: instalas WSL en un equipo de referencia, descargas la distribución Linux que necesitas (por ejemplo, Ubuntu “corporativo” o AlmaLinux adaptado a tu stack), instalas paquetes, herramientas, agentes y configuraciones estándar y, cuando lo tienes todo como quieres, exportas la distro con:

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

Esa imagen en formato tar se puede distribuir internamente (compartidos de red, sistemas de gestión de software, etc.) y luego cada usuario o dispositivo la importa localmente con:

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

De este modo, todos los desarrolladores arrancan desde un entorno controlado y aprobado por seguridad, con las mismas versiones de intérpretes, bases de datos, agentes de monitorización y reglas de hardening. Esta estrategia es especialmente útil cuando se trabaja con distribuciones no presentes en la Store (CentOS, variantes corporativas de Red Hat, etc.) o cuando se quiere un baseline muy específico.

Interoperabilidad de comandos y acceso al sistema de archivos de Windows

Una de las características más potentes (y a la vez delicadas) de WSL es la interoperabilidad entre comandos de Linux y Windows. Desde PowerShell puedes ejecutar herramientas de Linux con wsl <comando>, y desde WSL puedes invocar ejecutables de Windows terminando en .exe.

Desde PowerShell puedes listar el contenido de un directorio usando ls -la propio de Linux con:

wsl ls -la

o combinar ls con findstr (wsl ls -la | findstr "git") para filtrar resultados, o al revés, usar dir | wsl grep git. Desde la terminal Linux puedes abrir el bloc de notas de Windows para editar .bashrc con notepad.exe .bashrc, o aprovechar herramientas como ipconfig.exe y procesar su salida con grep y cut.

En cuanto al acceso a archivos, cuando un binario Linux dentro de WSL abre un fichero en C:\, lo hace con los permisos del usuario de Windows que ejecutó wsl.exe. Eso significa que aunque dentro de la distro seas root, no podrás hacer operaciones administrativas sobre Windows si tu cuenta de Windows no las permitiría. La seguridad de Windows sigue siendo la “capa dura” por debajo.

Como contrapartida, esta interoperabilidad exige orden. No es buena idea, por ejemplo, dejar scripts que mezclen intensivamente rutas de Windows y Linux sin entender bien los permisos y el impacto. En entornos sensibles, conviene limitar qué herramientas de Windows se exponen a través de WSL y viceversa, y formar a los usuarios para que sepan qué se está ejecutando realmente en cada lado.

Aplicaciones de GUI, GPU y montaje de unidades en WSL

WSL nació pensado para uso de terminal, pero poco a poco han ido llegando capacidades más avanzadas: aplicaciones gráficas de Linux, aceleración por GPU y montaje de discos externos con sistemas de archivos típicos de servidores.

Ya es posible configurar WSL para ejecutar aplicaciones de GUI de Linux que se integran con el escritorio de Windows, minimizando la necesidad de máquinas virtuales completas. Para quienes necesitan usar IDEs nativos de Linux, herramientas con interfaz propia o entornos guiados de administración, esto abre un abanico muy interesante. En algunos casos aún se recurre a soluciones externas como Win-KeX (en Kali) que, vía VNC, proporcionan un escritorio completo integrado con Windows.

En el ámbito del machine learning y cargas pesadas, WSL también soporta entrenamiento acelerado por GPU. Configurando adecuadamente drivers y entorno, puedes aprovechar la gráfica del equipo desde Linux para tareas de alto rendimiento sin abandonar el ecosistema de Windows. Esto es especialmente útil para data scientists y desarrolladores de IA que quieren un único workstation “todo en uno”.

Por último, WSL 2 permite montar unidades externas o discos con sistemas de archivos Linux, como ext4, que normalmente no son visibles de forma nativa en Windows. De esta forma, si necesitas acceder a un disco con datos de un servidor Linux o un sistema antiguo, puedes montarlo desde WSL y trabajar desde la línea de comandos sin tener que recurrir a herramientas de terceros ni a una máquina virtual autónoma.

La recomendación, eso sí, es tratar estos montajes con el mismo nivel de cautela que en un servidor real: revisar permisos, evitar ejecutar scripts desconocidos y controlar quién tiene acceso al equipo físico y al entorno de WSL, porque los datos montados pueden ser muy sensibles.

Solución de problemas y buenas prácticas de seguridad

WSL es robusto, pero no está exento de errores típicos de instalación, problemas de compatibilidad y conflictos con la virtualización. Conocer los fallos más comunes ayuda tanto a resolverlos rápido como a evitar configuraciones chapuceras que luego pasan factura.

Entre los errores habituales están los códigos 0x80070003 y 0x80370102 durante la instalación, que suelen indicar problemas con la virtualización en la BIOS/UEFI o con la ubicación de las distribuciones (WSL solo funciona correctamente en la unidad donde está instalado Windows, normalmente C:). También es frecuente el error que indica que el componente opcional de WSL no está habilitado; se corrige activando “Subsistema de Windows para Linux” desde las características de Windows o con los comandos DISM/PowerShell adecuados.

Otro fallo muy visto es el mensaje “el Subsistema de Windows para Linux no tiene ninguna distribución instalada”, que puede aparecer aunque ya hayas descargado una distro. En estos casos, suele bastar con ejecutar la distribución al menos una vez desde el menú Inicio para que termine la configuración inicial antes de llamarla desde la línea de comandos.

A nivel de rendimiento, revisa que estés en WSL 2 (con wsl -l -v), que tienes suficientes recursos de hardware, que no estás trabajando sobre rutas lentas (/mnt/c para proyectos grandes) y que la virtualización no está siendo interferida por otras soluciones (por ejemplo, otras VMs de terceros o herramientas de seguridad mal configuradas).

En el plano puramente de seguridad, algunas buenas prácticas básicas serían limitar el número de distribuciones instaladas (evitar colecciones de distros sin uso real), usar solo imágenes aprobadas o conocidas, mantener tanto Windows como WSL actualizados, inhabilitar WSL en equipos que no lo necesiten y, en empresas, confiar en Intune y Defender para Endpoint para tener visibilidad y control centralizado.

Con todo lo anterior aplicado, WSL pasa de ser un simple “Linux metido en Windows” a un entorno de trabajo sólido, controlable y alineado con las políticas de seguridad, que permite a desarrolladores y administradores moverse con soltura entre mundos sin dejar cabos sueltos ni puertas traseras improvisadas.