Порт RDP: 3389 по TCP и UDP, порты RD Gateway и как их проверить

Коротко: удалённый рабочий стол (RDP) по умолчанию слушает TCP-порт 3389, а в современных версиях Windows ещё и UDP-порт 3389. Без TCP не обойтись; UDP — необязательный, более быстрый транспорт, и если он заблокирован, RDP просто остаётся на TCP. Шлюз удалённых рабочих столов (RD Gateway), если он у вас есть, вместо этого занимает TCP 443 и UDP 3391, а больше ничего (ни 135, ни 139, ни 445) клиенту для подключения к серверу не нужно.

IANA регистрирует 3389 под именем службы ms-wbt-server и для TCP, и для UDP, поэтому nc и Nmap пишут это имя, а не «RDP». Номер — лишь значение по умолчанию: администратор может его сменить, и тогда новый порт придётся указывать в каждом клиенте. Как сменить порт, пошагово описано в статье как изменить порт RDP (англ.); здесь речь о том, какие порты задействованы, как их проверить и как защитить.

RDP работает по TCP или UDP?

По обоим протоколам, причём в строгом порядке. Клиент всегда сначала открывает TCP 3389. Через это подключение сервер предлагает второй транспорт поверх UDP, защищённый TLS или DTLS, и после успешного UDP-рукопожатия основная часть трафика, прежде всего обновления экрана, переходит на UDP, а TCP-подключение остаётся открытым. В документации Microsoft к протоколу это называется multitransport extension; сам по себе UDP-канал никогда не создаётся. Отсюда два практических следствия:

• Закройте UDP 3389 — RDP продолжит работать. Он останется только на TCP; на Wi-Fi с потерями или мобильном интернете это ощущается медленнее, в остальном разницы нет.
• Закройте TCP 3389 — не заработает ничего. Сам по себе UDP сеанс не начнёт, так что правило файрвола только для UDP бесполезно.

UDP-транспорт появился в RDP 8.0 вместе с Windows 8 и Windows Server 2012 (Windows 7 SP1 получила его с обновлением). В актуальных Windows Server и клиентских Windows он включён по умолчанию с обеих сторон. Отключить его может групповая политика: на сервере это «Выбор транспортных протоколов RDP» (Select RDP transport protocols) в разделе «Конфигурация компьютера» → «Административные шаблоны» → «Компоненты Windows» → «Службы удаленных рабочих столов» → «Узел сеансов удаленных рабочих столов» → «Подключения». Проверить, не задал ли её кто-то:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name SelectTransport -ErrorAction SilentlyContinue

Пустой вывод значит, что политика не задана и UDP разрешён. SelectTransport : 1 означает принудительное «Использовать только TCP» (0 и 2 разрешают UDP). Клиент тоже может отказаться от UDP сам: клиентская политика «Turn Off UDP On Client» выставляет fClientDisableUDP в подразделе Client того же ключа — частый обходной путь, когда сеансы зависают на нестабильном UDP. Во время полноэкранного сеанса значок качества связи на панели подключения открывает окно, где видно, включён ли UDP. На сервере каждое принятое подключение записывается в журнал вместе с транспортом и адресом клиента:

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'; Id = 131 } -MaxEvents 10 |
    Format-List TimeCreated, Message

В английской Windows текст события 131 такой: «The server accepted a new TCP connection from client…» (или то же с UDP). Оно пишется ещё до входа, так что на сервере с открытым в интернет 3389 в журнале видны и адреса всех посторонних, кто стучится.

Какие порты RDP не нужны?

Во многих списках «портов RDP» добавлены TCP 135, 139 и 445 — якобы для проброса принтеров и дисков. Проброс устроен не так. Диски, принтеры, буфер обмена, звук и смарт-карты передаются виртуальными каналами внутри RDP-подключения на 3389, поэтому клиент, которому доступен только 3389, получает их все. Порты RPC и SMB есть в списке портов RDS у Microsoft для трафика между серверами развёртывания Remote Desktop Services: узлы сеансов обращаются к серверу лицензирования, брокеру подключений и Active Directory. На одиночном Windows-сервере, к которому вы подключаетесь из дома, их открытие лишь выставит SMB и RPC в интернет, а этого не нужно никогда.

То же с ICMP: ping удобен для диагностики, но RDP его не использует, и сервер, который не отвечает на ping, вполне может принимать подключения к удалённому рабочему столу.

Как узнать, какой порт слушает RDP

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

# настроенный порт (десятичное число)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

# что на самом деле слушается, TCP и UDP
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetUDPEndpoint -LocalPort 3389

PortNumber   : 3389

LocalAddress LocalPort RemoteAddress RemotePort State  AppliedSetting OwningProcess
------------ --------- ------------- ---------- -----  -------------- -------------
::           3389      ::            0          Listen                1052
0.0.0.0      3389      0.0.0.0       0          Listen                1052

LocalAddress LocalPort
------------ ---------
::           3389
0.0.0.0      3389

В редакторе реестра (regedit) то же значение PortNumber показано как 0x00000d3d (3389): сначала шестнадцатеричное число, в скобках — десятичное. Клиентам нужно десятичное.

Если PortNumber показывает другое значение, подставьте его в две следующие команды. Если реестр и таблица сокетов расходятся, порт уже сменили, но службу удалённых рабочих столов ещё не перезапустили; клиенты видят то, что в таблице сокетов. Если строки TCP нет вовсе, удалённый рабочий стол выключен или его служба не запущена. Если TCP слушается, а UDP нет, проверьте политику транспорта, описанную выше.

Классическая команда тоже работает, в командной строке или PowerShell:

netstat -ano | findstr :3389
tasklist /svc /fi "SERVICES eq TermService"

  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1052
  TCP    [::]:3389              [::]:0                 LISTENING       1052
  TCP    192.0.2.10:3389        198.51.100.23:50412    ESTABLISHED     1052
  UDP    0.0.0.0:3389           *:*                                    1052
  UDP    [::]:3389              *:*                                    1052

Image Name                     PID Services
========================= ======== ============================================
svchost.exe                   1052 TermService

Последний столбец netstat — идентификатор процесса, а tasklist подтверждает, что он принадлежит TermService, службе удалённых рабочих столов (Remote Desktop Services), которая работает внутри процесса svchost.exe. Строка ESTABLISHED с чужого адреса — это чей-то клиент, который подключён или пытается войти. Учтите, что findstr :3389 найдёт и порты вроде 33890, так что смотрите на номера.

Затем проверьте, какие порты на самом деле пропускает брандмауэр Windows. Встроенная группа правил в английской Windows называется «Remote Desktop»:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
    Where-Object Enabled -eq True |
    Get-NetFirewallPortFilter |
    Format-Table Protocol, LocalPort

Get-NetFirewallRule -Group "@FirewallAPI.dll,-28752" |
    Where-Object Enabled -eq True |
    Get-NetFirewallPortFilter |
    Format-Table Protocol, LocalPort

Ожидаемый результат — TCP и UDP с портом из реестра. Строка с TCP и Any — это правило теневого подключения (в английской Windows — «Remote Desktop - Shadow»): оно привязано к программе RdpSa.exe, а не к порту. Если RDP работает на другом порту, встроенные правила ему уже не соответствуют, и нужны собственные, как в статье о смене порта.

Как проверить порт RDP снаружи

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

Test-NetConnection YOUR_SERVER_IP -Port 3389
# короткий вариант, только для 3389:
Test-NetConnection YOUR_SERVER_IP -CommonTCPPort RDP

nc -vz -G 5 YOUR_SERVER_IP 3389

nc -vz -w 5 YOUR_SERVER_IP 3389

• TcpTestSucceeded : True или строка nc, которая заканчивается на [tcp/ms-wbt-server] succeeded!: путь открыт. Если вход всё равно не удаётся, дело в учётных данных, NLA или клиенте.
• Connection refused (nc отвечает сразу): сервер ответил, но на этом порту никто не слушает. Удалённый рабочий стол выключен, а правило брандмауэра осталось открытым, или он слушает другой порт.
• Timed out (nc ждёт все пять секунд): кто-то отбрасывает пакеты. Это файрвол на сервере или у провайдера, неверный IP или ваша собственная сеть, которая блокирует исходящий 3389, — так часто делают в гостиницах и корпоративных сетях.

Test-NetConnection в обоих случаях неудачи пишет TcpTestSucceeded : False и не отличает отказ от отбрасывания пакетов; nc отличает.

Без терминала поможет наш Open port checker (англ.): он выполняет тот же TCP-тест с нашего сервера в Амстердаме для любого публичного IP-адреса (не имени хоста) и порта. Если вы уже ограничили 3389 своим адресом, ждите там результата No answer (filtered): значит, правило работает. Ни один из этих инструментов не докажет, что UDP-порт открыт: у UDP нет рукопожатия, и тишина выглядит одинаково, открыт порт или фильтруется. UDP подтверждайте через окно сеанса или событие 131. Если проверка не прошла и нужен полный список проверок, по порядку он разобран в статье удалённый рабочий стол не подключается (англ.).

Как подключиться к RDP на нестандартном порту

Любой клиент принимает порт после адреса, через двоеточие. Без него клиент пробует 3389.

mstsc /v:YOUR_SERVER_IP:13389

# Debian 12: xfreerdp (FreeRDP 2) · Debian 13, Ubuntu 24.04: xfreerdp3
xfreerdp3 /v:YOUR_SERVER_IP:13389 /u:Administrator

• «Подключение к удаленному рабочему столу» (Windows, mstsc): введите YOUR_SERVER_IP:13389 в поле с именем компьютера. В сохранённом .rdp-файле это строка full address:s:YOUR_SERVER_IP:13389.
• macOS, iPhone, iPad, Android: приложение Windows App от Microsoft, которое заменило Microsoft Remote Desktop. Нажмите + → Add PC и введите YOUR_SERVER_IP:13389 как имя компьютера.
• Remmina (Linux): новый RDP-профиль, сервер YOUR_SERVER_IP:13389.
• IPv6: возьмите адрес в квадратные скобки, [2001:db8::10]:13389, чтобы двоеточия адреса не приняли за разделитель порта.

Вместо 13389 подставьте порт своего сервера. Через RD Gateway клиент обращается к шлюзу на 443, а целевой сервер указывается отдельно: mstsc /v:SERVER /g:GATEWAY.

Ограничьте порт 3389 своим IP

Открытый 3389 быстро находят сканеры, которые прочёсывают весь интернет, и дальше он круглые сутки получает попытки подбора пароля. Самое действенное средство — пускать к нему только свои адреса. Ваш текущий публичный адрес покажет наш инструмент What is my IP (англ.).

# замените на свой адрес (адреса); диапазоны вида 192.0.2.0/24 тоже подходят
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress YOUR_IP

# проверьте результат
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilter |
    Format-Table RemoteAddress

Так сужаются сразу оба встроенных правила, TCP и UDP; в русской Windows используйте -Group "@FirewallAPI.dll,-28752" вместо -DisplayGroup, как выше. Незаметно свести это на нет могут две вещи. Первая — другое правило, которое открывает тот же порт для всех; вот как такие найти:

Get-NetFirewallPortFilter | Where-Object LocalPort -eq 3389 | Get-NetFirewallRule |
    Format-Table DisplayName, Enabled, Direction, Action

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

Set-NetFirewallRule -DisplayName "RDP 13389 TCP", "RDP 13389 UDP" -RemoteAddress YOUR_IP

Делает ли смена порта RDP сервер безопасным?

Нет. С другим портом вы выпадаете из прицела самых ленивых ботов, и в журнале становится тише. Но сканирование всех 65 535 портов всё равно найдёт слушающий сокет и опознает в нём RDP, а слабый пароль на порту 13389 так же слаб. Что на самом деле защищает RDP-сервер:

• Список разрешённых адресов, как выше. С ним подбирать пароли с чужих адресов просто не получится.
• Никакого публичного порта. Подключайтесь к RDP через VPN или SSH-туннель (англ.) к 127.0.0.1:3389 на сервере либо через RD Gateway на 443, а 3389 закройте снаружи.
• Проверка подлинности на уровне сети (NLA). Она включена по умолчанию и заставляет клиента пройти аутентификацию до того, как Windows построит экран входа. Значение реестра UserAuthentication в том же ключе RDP-Tcp должно быть равно 1.
• Политика блокировки учётных записей. Текущие значения показывает net accounts. Системы, установленные с октябрьскими обновлениями 2022 года или позже, уже блокируют учётную запись на 10 минут после 10 неудачных попыток. Если порог блокировки не задан (в английской Windows это строка Lockout threshold: Never), задайте его командой net accounts /lockoutthreshold:10 /lockoutwindow:10 /lockoutduration:10. Встроенный Administrator под защитой, только если включена политика «Allow Administrator account lockout», и даже тогда блокировка касается лишь сетевых входов, таких как RDP, так что через VNC-консоль вы всё равно войдёте.
• Обновления. Несколько серьёзных уязвимостей RDP не требовали пароля вовсе: BlueKeep (CVE-2019-0708) позволял любому, кто достучался до 3389, выполнить код на непропатченных Windows 7 и Server 2008 R2.

Журналирование, сертификаты и остальной список мер по защите — в статье как защитить Windows-сервер с RDP (англ.).

Если вам нужен Windows-сервер, где всё это вы настраиваете сами, Windows VPS даёт учётную запись Administrator и удалённый рабочий стол на стандартном порту 3389, а тарифы Windows RDP работают в Амстердаме и Франкфурте, с VNC-консолью в личном кабинете на случай ошибки в правиле брандмауэра.

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