RDP через WireGuard: безопасный доступ к Windows-серверу

MAATRIX

Стоит поднять Windows-сервер и открыть порт 3389 наружу — и в логах Windows Firewall уже через час-два появляются сотни попыток входа с чужих IP: боты по всему миру круглосуточно сканируют интернет в поисках открытого RDP и перебирают пароли автоматически, без участия человека. Проблема не гипотетическая: открытый RDP регулярно называют одной из главных точек входа при взломе серверов и заражении шифровальщиками. Решение при этом простое и давно обкатанное — не открывать 3389 в интернет вообще, а пускать к нему только через зашифрованный туннель WireGuard. Ниже — как устроена эта схема и как настроить её по шагам.

Почему открытый RDP — это риск

Порт 3389/TCP — один из самых сканируемых портов в интернете. Боты и ботнеты непрерывно обходят диапазоны IP-адресов в поисках открытого RDP и, найдя его, сразу начинают перебор логинов и паролей: пробуют стандартные учётки вроде Administrator, популярные пароли и утечки из старых баз. Если на сервере нет блокировки после нескольких неудачных попыток, брутфорс может идти сутками.

Проблема не только в переборе паролей. У протокола RDP была и остаётся история серьёзных уязвимостей — например, нашумевшая BlueKeep (CVE-2019-0708), позволявшая выполнить код на сервере без аутентификации вообще, просто отправив специально сформированный запрос на открытый порт. Патчи выходят, но сервер с открытым 3389 всё равно остаётся заметной целью: даже полностью обновлённая система тратит ресурсы на отражение потока мусорных подключений, а новая уязвимость в RDP-стеке становится доступна для эксплуатации мгновенно, как только сервер обнаружен сканером.

Итог простой: сам факт, что 3389 слушает публичный IP, уже создаёт риск — независимо от того, насколько сложный пароль установлен у администратора. Правильная защита начинается не с усложнения пароля, а с того, чтобы порт вообще не был виден снаружи.

Архитектура решения: RDP только через VPN-туннель

Идея в том, чтобы развести две вещи: сетевую доступность порта и право на подключение. RDP как сервис на сервере не трогаем — он по-прежнему слушает 3389, но не на публичном сетевом интерфейсе, а только на внутреннем адресе VPN-туннеля, поднятого через WireGuard.

Схема выглядит так. На сервере разворачивается WireGuard-интерфейс (обычно 10.8.0.0/24 или похожая приватная подсеть), у него появляется внутренний IP — например, 10.8.0.1. На клиентском устройстве — ноутбуке администратора — ставится клиент WireGuard, который получает свой адрес в этой же подсети, например 10.8.0.2. Как только туннель поднят, клиент и сервер видят друг друга напрямую по внутренним адресам, как будто находятся в одной локальной сети, хотя физически могут быть в разных странах.

Дальше остаётся закрыть 3389 на публичном интерфейсе средствами Windows Firewall и разрешить подключение к RDP только с IP из VPN-подсети. В результате порт 3389 продолжает существовать, но снаружи, с точки зрения интернет-сканера, сервер выглядит так, будто RDP на нём вообще не запущен — виден только UDP-порт WireGuard, а он не отвечает на неавторизованные пакеты и не выдаёт информации постороннему наблюдателю. Подробно про сам протокол — в статье про установку и настройку WireGuard на VPS, там же разбор, чем он лучше OpenVPN.

Настройка Windows Firewall: ограничиваем RDP только VPN-подсетью

Первый шаг — убедиться, что правило Windows Firewall для RDP разрешает подключения только с адресов внутри туннеля, а не с любого IP. Откройте PowerShell от имени администратора на сервере.

Сначала посмотрите текущее правило для RDP, чтобы понять, что уже настроено:

Get-NetFirewallRule -DisplayName "*Remote Desktop*" | Select-Object DisplayName, Enabled, Direction, Action

Штатное правило Windows разрешает RDP с любого адреса — его нужно либо отключить, либо переписать так, чтобы оно принимало трафик только из VPN-подсети. Проще всего отключить стандартные правила группы «Удалённый рабочий стол» и создать своё, узкое:

Disable-NetFirewallRule -DisplayGroup "Remote Desktop"

New-NetFirewallRule -DisplayName "RDP только через WireGuard" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -RemoteAddress 10.8.0.0/24 `
    -Action Allow `
    -Profile Any

Ключевой параметр здесь — -RemoteAddress 10.8.0.0/24: правило разрешает вход на 3389 только с адресов из подсети WireGuard-туннеля. Всё, что приходит на 3389 с любого другого IP, включая публичный интернет, будет отброшено ещё на уровне firewall — до того, как запрос вообще дойдёт до службы удалённых рабочих столов.

Проверить, что правило создалось и активно, можно так:

Get-NetFirewallRule -DisplayName "RDP только через WireGuard" | Format-List DisplayName, Enabled, Action
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -DisplayName "RDP только через WireGuard")

Если сервер физический, с несколькими сетевыми адаптерами, дополнительно стоит явно запретить 3389 именно на публичном интерфейсе — тогда даже случайно ослабленное правило не откроет порт наружу. Про базовую настройку файрвола на Windows-сервере в целом — настройка Windows Server с нуля.

Поднимаем WireGuard на сервере

Сама установка WireGuard на Windows-сервер — тема отдельной инструкции, здесь опишем логику коротко, чтобы было понятно, как она стыкуется с настройкой RDP.

На сервере разворачивается официальный клиент WireGuard для Windows (он же используется и как сервер — WireGuard симметричен, роль определяется конфигом), создаётся пара ключей и файл конфигурации интерфейса примерно такого вида:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <приватный ключ сервера>

[Peer]
PublicKey = <публичный ключ клиента>
AllowedIPs = 10.8.0.2/32

После запуска туннеля интерфейс WireGuard получает адрес 10.8.0.1, и именно на него, а не на публичный IP, нацелено правило firewall из предыдущего раздела. На Windows WireGuard работает как обычная служба и сетевой адаптер — с точки зрения RDP это просто ещё один интерфейс со своим IP. Полный разбор установки и генерации ключей — в статье WireGuard на Windows Server: установка, она готовится как продолжение этого материала.

Важный момент: на уровне сетевого firewall провайдера или в панели управления сервером тоже нужно открыть только UDP-порт WireGuard (в примере — 51820), а 3389/TCP не открывать вовсе — ни в панели, ни во внешнем firewall перед сервером.

Подключение клиента: mstsc по VPN-адресу

Когда туннель поднят с обеих сторон, подключение к серверу по RDP ничем не отличается от подключения в локальной сети — только вместо публичного IP используется внутренний адрес VPN.

На клиентском компьютере запустите mstsc и укажите VPN-адрес сервера вместо публичного:

mstsc /v:10.8.0.1

Или через графический интерфейс: «Подключение к удалённому рабочему столу» → в поле «Компьютер» ввести 10.8.0.1 вместо публичного IP или доменного имени. Подключение пройдёт через зашифрованный туннель WireGuard, а сама RDP-сессия останется дополнительно защищена собственным шифрованием протокола — получается два независимых слоя защиты.

Если WireGuard-туннель не поднят на клиентском устройстве, mstsc просто не сможет достучаться до 10.8.0.1 — время ожидания истечёт, и подключение не установится. Это ожидаемо: без активного VPN у атакующего нет шанса даже начать TCP-рукопожатие с портом 3389, потому что сам порт для него не существует.

Дополнительные меры защиты

VPN-туннель закрывает главный вектор — случайное и целенаправленное сканирование порта из интернета, — но имеет смысл добавить ещё несколько независимых слоёв защиты, на случай если один из них по какой-то причине откажет.

Network Level Authentication (NLA). Проверьте, что NLA включена — она требует аутентификации пользователя ещё до того, как откроется полноценная RDP-сессия, и снижает нагрузку на сервер от недоаутентифицированных подключений:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

Смена порта RDP. Сама по себе смена порта с 3389 на нестандартный не защищает от целенаправленной атаки — сканер портов найдёт сервис на любом порту за секунды, — но заметно снижает шум от массовых автоматических сканирований именно 3389. Как дополнительный, а не основной слой защиты, это оправдано:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "PortNumber" -Value 33890
Restart-Service TermService -Force

После смены порта не забудьте обновить правило Windows Firewall (-LocalPort в примере из третьего раздела) и подключаться через mstsc /v:10.8.0.1:33890.

RD Gateway и двухфакторная аутентификация. Если у вас не один сервер, а несколько, или к RDP нужен доступ по более строгой политике с журналированием и MFA, поверх схемы с WireGuard можно развернуть Remote Desktop Gateway с поддержкой двухфакторной аутентификации через Azure MFA, RADIUS или сторонний TOTP-провайдер. Для одного-двух серверов это обычно избыточно — VPN-туннеля с ограничением firewall по подсети достаточно, — но для инфраструктуры компании с несколькими администраторами и требованиями комплаенса RD Gateway с MFA стоит рассмотреть отдельно.

Учётные записи. Отдельная базовая гигиена, которая работает независимо от VPN: переименуйте или отключите встроенную учётную запись Administrator (она — первая цель любого брутфорса), используйте длинные уникальные пароли или сгенерированные фразы, и включите блокировку учётной записи после нескольких неудачных попыток входа через локальную политику безопасности.

Доступ для нескольких устройств и команды

Если к серверу нужен доступ не с одного ноутбука администратора, а с нескольких устройств или целой команде, схема расширяется естественным образом — WireGuard изначально проектировался под множество пиров.

Каждому устройству и каждому сотруднику стоит выдавать отдельную пару ключей WireGuard и отдельный внутренний IP-адрес, а не один общий конфиг на всех. Это даёт две вещи. Во-первых, при увольнении сотрудника или компрометации ноутбука достаточно удалить один блок [Peer] из конфига сервера — остальные подключения продолжают работать без изменений. Во-вторых, правило Windows Firewall для RDP при таком подходе остаётся неизменным — -RemoteAddress 10.8.0.0/24 уже покрывает всю подсеть, и добавление нового пира не требует правки firewall.

Для команды из нескольких человек стоит завести подсеть с запасом — например, /24 даёт больше 250 адресов — и вести простой учёт, кому какой адрес и когда выдан. Если состав команды меняется часто или нужен централизованный контроль доступа с логами, кто и когда подключался, имеет смысл присмотреться к RD Gateway с MFA из предыдущего раздела как к более управляемой альтернативе плоскому списку пиров WireGuard. Про общие принципы разграничения доступа на сервере — в статье разграничение прав доступа на сервере.

Частые вопросы