Как защитить WSL в Windows от атак через уязвимости WSL

Автор На чтение 7 мин Просмотров 1 Опубликовано

Если вы используете WSL для разработки, Docker, парсинга или тестов, не воспринимайте её как отдельный безопасный Linux-сервер. WSL — это прослойка между Windows и Linux: у неё общий сетевой стек, доступ к Windows-файлам и тесная интеграция с системой. Поэтому под WSL-vulnerabilities обычно понимают не одну конкретную “дыру”, а набор рисков в компонентах WSL, дистрибутиве, Docker, SSH, сетевых сервисах и связанных утилитах.

Цель защиты простая: оставить себе удобство WSL, но убрать лишнюю поверхность атаки. Ниже — практический порядок действий, который я бы сделал на рабочей машине.

Содержание
  1. Где именно WSL может стать точкой входа
  2. Сначала решите: WSL действительно нужен на этой машине
  3. Обновляйте не только Linux внутри WSL
  4. Закройте лишние сетевые входы
  5. Не превращайте WSL в публичный сервер
  6. Разберитесь с .wslconfig и .wsl.conf
  7. Где хранить ключи, токены и пароли
  8. Особое внимание Docker
  9. Какие меры что дают

Где именно WSL может стать точкой входа

Уязвимость в WSL сама по себе не всегда означает, что кто-то сразу получит полный контроль над компьютером. Чаще риск появляется в связке: устаревший компонент WSL + открытый сетевой порт + Docker + ключи в проекте + доступ к Windows-дискам.

Основные места, где стоит смотреть защиту:

  • Компоненты WSL в Windows. Их обновляют через Windows Update, Microsoft Store и команду wsl --update.
  • Linux-дистрибутив внутри WSL. Ubuntu, Debian, Kali, Alpine и другие дистрибутивы нужно обновлять отдельно.
  • Сеть. WSL2 использует сетевую интеграцию с Windows. Сервис, который слушает 0.0.0.0, может стать доступен не только внутри Linux, но и через Windows-хост.
  • Docker и контейнеры. Docker socket фактически даёт root-уровень доступа к Docker-среде. Если контейнеры запускаются с пробросом портов и монтированием рабочих папок, риск растёт.
  • SSH-ключи и секреты. Файлы в /mnt/c/... лежат на Windows-файловой системе. Там не стоит хранить приватные ключи, токены, .env с доступами к продакшену и похожие данные.
  • Сам Windows-аккаунт. Если злоумышленник уже получил доступ к Windows, WSL не является надёжным сейфом. Дистрибутивы WSL хранятся в виртуальных дисках VHDX в профиле пользователя.

Главная мысль: WSL удобна, но это не полноценная изоляция. Защищать нужно и Windows, и Linux-дистрибутив, и сеть, и Docker, и места хранения секретов.

Сначала решите: WSL действительно нужен на этой машине

Самый надёжный способ закрыть риски, связанные с WSL, — не держать WSL включённой там, где она не используется. Если это личный ноутбук только для кода, всё нормально. Если это компьютер бухгалтера, менеджера или общего доступа, лишний Linux-инструмент внутри Windows не нужен.

Проверьте, что установлено:

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

Если WSL не используется, её можно отключить из PowerShell от имени администратора:

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Если старые дистрибутивы остались “на всякий случай”, их лучше удалить. Но перед этим обязательно сделайте резервную копию:

wsl --export Ubuntu ubuntu-backup.tar

Удаление дистрибутива делается так:

wsl --unregister Ubuntu

Не нажимайте wsl --unregister наугад: команда удаляет файловую систему дистрибутива. Если внутри были проекты, ключи или базы, восстановить их без резервной копии может быть невозможно.

Обновляйте не только Linux внутри WSL

Частая ошибка — обновить Ubuntu через apt и считать, что WSL защищена. Это не так. Уязвимости могут быть в самом компоненте WSL, в ядре, в механизме проброса localhost, в интеграции с Windows или в Docker Desktop.

  1. Обновите Windows. Откройте Windows Update и установите все доступные обновления. Не откладывайте накопительные обновления безопасности.
  2. Обновите WSL. В PowerShell выполните: 
    wsl --update
wsl --shutdown
  3. Обновите дистрибутив. Внутри WSL: 
    sudo apt update
sudo apt full-upgrade
sudo apt autoremove
  4. Обновите Docker Desktop, если используете Docker. Docker-бэкенд через WSL тоже получает обновления отдельно.
  5. Проверьте расширения IDE. VS Code Remote — WSL, SSH-плагины и похожие инструменты тоже лучше держать актуальными.

После обновления WSL перезапускается. Если у вас были запущены dev-серверы, базы данных или Docker-контейнеры, их придётся запустить заново.

Закройте лишние сетевые входы

WSL часто используют для локальных серверов: Node.js, Python, PostgreSQL, Redis, Jupyter, Django, FastAPI. Проблема начинается, когда такой сервис слушает все интерфейсы.

Проверьте открытые TCP-порты внутри WSL:

sudo apt install iproute2
ss -ltnp

Если видите что-то вроде:

0.0.0.0:8000
0.0.0.0:5432
0.0.0.0:6379

это значит, что сервис слушает все сетевые интерфейсы. Для локальной разработки обычно нужно:

127.0.0.1:8000
127.0.0.1:5432
127.0.0.1:6379

Примеры безопасного запуска:

python -m http.server 8000 --bind 127.0.0.1
uvicorn app.main:app --host 127.0.0.1 --port 8000
docker run -p 127.0.0.1:8080:8080 image:tag

Последний пример особенно полезен для Docker. Запуск с -p 8080:8080 может открыть порт шире, чем вы ожидали. Лучше явно указывать 127.0.0.1, если сервис не должен быть доступен в локальной сети.

Не превращайте WSL в публичный сервер

WSL удобна для разработки, но это не лучшая площадка для публичного хостинга. Если вы временно “пробрасываете” сервис наружу через туннель, reverse proxy, ngrok, Cloudflare Tunnel или порт-форвардинг Windows, риск становится выше.

Если сервис должен быть доступен извне, лучше использовать нормальный Linux-сервер, VPN или корпоративный шлюз. Если без временного доступа не обойтись, добавьте хотя бы:

  • авторизацию на уровне приложения;
  • ограничение доступа по IP или VPN;
  • отдельный тестовый токен, не используемый в продакшене;
  • логи подключения;
  • быстрый способ остановить сервис.

Разберитесь с .wslconfig и .wsl.conf

WSL можно ограничить через конфигурационные файлы. Но здесь не стоит слепо копировать настройки из интернета: разные версии WSL ведут себя по-разному, а слишком жёсткие настройки могут сломать привычную работу.

Файл .wslconfig находится в профиле Windows пользователя. Пример для современных сборок WSL:

[wsl2]
networkingMode=mirrored
firewall=true
localhostForwarding=false

После изменения выполните:

wsl --shutdown

Что здесь может быть полезно:

  • firewall=true — включает дополнительные правила фильтрации для WSL, если ваша версия WSL поддерживает этот параметр.
  • localhostForwarding=false — отключает автоматический проброс localhost из WSL в Windows. Это может повысить безопасность, но ломает сценарии, где Windows-приложения обращаются к Linux-сервисам через localhost.
  • networkingMode=mirrored — режим сети, который поддерживается не во всех сборках. Если после включения WSL работает нестабильно, уберите эту строку и обновите WSL.

Файл /etc/wsl.conf находится уже внутри дистрибутива Linux. Он влияет на монтирование Windows-дисков и интеграцию с Windows.

Если вы не хотите, чтобы WSL автоматически монтировала C:, D: и другие диски:

[automount]
enabled = false

[interop]
appendWindowsPath = false

Если доступ к Windows-дискам нужен, но вы хотите более нормальные Linux-права на файлы, можно использовать metadata:

[automount]
enabled = true
options = "metadata,uid=1000,gid=1000"

Перед применением проверьте свой UID и GID:

id -u
id -g

Где хранить ключи, токены и пароли

Приватные SSH-ключи, API-токены, облачные credentials и .env с продакшен-доступами не стоит держать в папках Windows, которые подключены в WSL как /mnt/c/....

Более безопасный вариант:

  • хранить SSH-ключи в ~/.ssh/ внутри Linux-файловой системы WSL;
  • ставить парольную фразу на приватный ключ;
  • не использовать один SSH-ключ на все проекты;
  • не включать SSH agent forwarding без необходимости;
  • не класть токены в репозиторий;
  • использовать отдельные тестовые ключи для локальной разработки.

Проверьте права на SSH-ключ:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Если ключ лежит в /mnt/c/Users/..., Linux-права могут не работать так, как вы ожидаете. Для чувствительных файлов лучше использовать Linux-файловую систему дистрибутива.

Особое внимание Docker

Docker в WSL — отдельная зона риска. Если пользователь имеет доступ к /var/run/docker.sock, он фактически получает мощные права в Docker-среде. Через Docker можно запускать контейнеры, монтировать файловые системы, пробрасывать порты и читать данные из примонтированных каталогов.

Что стоит сделать:

  • не запускать контейнеры от root, если это не требуется;
  • не монтировать весь домашний каталог Windows в контейнер;
  • не пробрасывать базы данных, Redis и админки наружу;
  • использовать -p 127.0.0.1:порт:порт для локальных сервисов;
  • держать Docker Desktop и образы обновлёнными;
  • удалять старые unused-контейнеры и образы.

Проверьте, что запущено:

docker ps
docker network ls

Если вы часто работаете с контейнерами и хотите сильнее разделить права, посмотрите в сторону rootless Docker или Podman. Это не панацея, но уменьшает последствия ошибок при запуске контейнеров.

Какие меры что дают

Решение Что снижает риск Когда использовать О чём помнить
Полностью отключить WSL Убирает поверхность атаки WSL Если WSL не нужна на этой машине Потом придётся включать компонент Windows заново
Обновлять Windows, WSL и дистрибутив Закрывает известные уязвимости компонентов Для любой рабочей установки Нужна регулярность, одного обновления “навсегда” нет
Слушать сервисы только на 127.0.0.1 Не даёт открыть dev-сервис в локальную сеть Для веб-серверов, баз, Redis, Jupyter Некоторые инструменты по умолчанию слушают 0.0.0.0
Не монтировать Windows-
Оцените статью
PEFile — Безопасность и технологии простым языком
© 2026 PEFile — Безопасность и технологии простым языком