RDP торчит в интернет: убрать проброс 3389, не меняя порт «на секретный»

Короткий ответ

RDP (3389/TCP) не должен быть доступен с интернета ни на WS-042, ни на Windows Server, ни на самом шлюзе. Схема: клиент → VPN → адрес LAN 10.0.10.10 → RDP. На edge снимите DNAT/проброс 3389. На хосте правило firewall: 3389 только с подсетей VPN и LAN, профили firewall включены. Смена порта на 3390 — не защита. Не отключайте Windows Firewall, чтобы «RDP заработал с улицы».

Прежде чем снять проброс, убедитесь, что VPN и RDP внутри туннеля уже работают у администратора. Иначе отрежете себя. Аудит входов должен видеть 4625 с публичных адресов — это аргумент закрыть порт, см. аудит входов.

Симптомы и как отличить

• Shodan/внешний скан: 3389 open на белом IP офиса.
• Security: 4625 пачками с иностранных адресов, учётки Administrator/admin/test.
• Пользователи вбивают в mstsc публичный IP.
• На MikroTik/Cisco есть dst-nat 3389 → WS-042.

Возможные причины

1. «Временный» проброс на время карантина/удалёнки, забыли.
2. Облачный NSG/Security Group allow 3389 с 0.0.0.0/0.
3. Windows Firewall Public allow Any.
4. RDS Gateway на 443 считают «уже безопасно» без MFA и без ограничения источника — это не повод держать ещё и 3389 Any.
5. IPv6 AAAA открыт, IPv4 закрыли.
6. Сменили порт, сканеры нашли новый.

Диагностика

1. С улицы (LTE, не Wi-Fi офиса)

Test-NetConnection <WAN-IP-офиса> -Port 3389
Test-NetConnection <белый-IP-WS-042-если-есть> -Port 3389

TcpTestSucceeded : True — дыра. Проверка с офисного Wi-Fi врёт из-за hairpin.

2. На самом хосте

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' | Select-Object fDenyTSConnections
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter |
  Format-Table InstanceID, RemoteAddress
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue

fDenyTSConnections = 0 значит служба RDP разрешена (это нормально внутри LAN). Смотрите RemoteAddress правил: Any на Public — плохо.

3. Журнал brute-force

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4625 } -MaxEvents 30 |
  Select-Object TimeCreated, Message

Публичные IpAddress в 4625 при закрытом периметре должны исчезнуть. Оставьте сбор логов включённым.

4. Шлюз

Ищите DNAT 3389, cloud security group, IPv6. На Windows-шлюзе:

Get-NetNatTransitionConfiguration -ErrorAction SilentlyContinue
Get-NetFirewallRule | Where-Object { $_.Enabled -eq 'True' } |
  Get-NetFirewallPortFilter | Where-Object LocalPort -eq 3389

Решение

Сценарий A. Проброс на роутере

1. Поднимите VPN, проверьте Test-NetConnection 10.0.10.10 -Port 3389 из туннеля.
2. Удалите правило проброса 3389.
3. С LTE снова Test-NetConnection на WAN IP — False.
4. Сообщите пользователям новый путь: VPN, затем WS-042.contoso.example.

Сценарий B. Белый IP на сервере

На NIC с WAN:

• снимите 3389 с этого интерфейса правилами firewall (профиль Public: блок 3389);
• лучше уберите белый IP с member-сервера, оставьте NAT.

Set-NetFirewallProfile -Profile Public -Enabled True
# пример: ограничить RDP источником LAN+VPN, не Any
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Set-NetFirewallRule -RemoteAddress 10.0.10.0/24, 10.8.0.0/24

Подставьте свои сети. Не используйте Set-NetFirewallProfile -Enabled False.

Сценарий C. Нужен вход подрядчика

Не открывайте 3389. Отдельный VPN-профиль, узкие маршруты, учётка без Domain Admin, срок жизни. MFA на VPN. После работ — отзыв.

NLA оставьте включённым (UserAuthentication / «Allow connections only from computers running Remote Desktop with NLA»). NLA не заменяет закрытый периметр.

На стороне DC01 это не «роль RDP», а журналы: если 4625 с публичных адресов идут на member-сервер, а не на контроллер, чините NAT/хост, не Netlogon. Пользовательские ярлыки в GPO должны указывать WS-042.contoso.example, а не WAN IP; иначе после закрытия 3389 люди снова попросят проброс. RDS Session Host в LAN остаётся легитимным: вы закрываете публикацию, не службу. Проверьте IPv6 на том же шлюзе, где сняли IPv4 DNAT: один забытый dstnat на 3389/IPv6 возвращает brute-force за ночь. Зафиксируйте в регламенте периметра: любой новый DNAT 3389 — инцидент, не «временная удалёнка».

Как проверить, что проблема устранена

• С LTE: 3389 на всех белых IP офиса не открывается.
• С VPN: RDP на WS-042.contoso.example работает.
• 4625 с публичных IP прекращаются (хвост — кеш сканеров на день-два).
• Firewall Domain/Private/Public Enabled True.
• Документация проброса обновлена: правила нет.

Повторите скан через неделю — забытые AAAA/второй провайдер.

Если не помогло

• IPv4 закрыт, IPv6 слушает — проверьте AAAA и ip6tables/аналог на шлюзе.
• Пользователь сидит в «VPN», но split tunnel и ходит на белый IP в обход — ярлыки и DNS.
• RDS Gateway 443 Any без MFA — закройте источник, это не эта статья, но тот же класс дыр.
• Облако: NSG != Windows Firewall, правьте оба.
• Не «смените порт» как финал заявки.

Профилактика

• Запрет DNAT 3389 в регламенте периметра.
• Мониторинг: внешний probe 3389 должен быть down.
• Базовый чеклист рисков.
• Привилегированный RDP только с jump, не Domain Admin с домашнего Windows 11.
• Журналы 4625 на SIEM.

FAQ

Сменить порт RDP безопасно?

Нет как единственная мера. Сканеры найдут. Закрывайте источник.

Можно ли whitelist только домашний IP директора?

Лучше VPN: домашний IP меняется, гостевой LTE, гостиница. Если whitelist — только как временный rollback, не архитектура.

NLA обязателен?

Да внутри LAN. Без NLA на открытом 3389 ещё хуже. С закрытым периметром NLA всё равно оставляйте.

Нужен ли UDP 3389?

RDP может использовать UDP для графики внутри LAN/VPN. С WAN не публикуйте ни TCP, ни UDP 3389.

Отключить RDP на сервере совсем?

Если управление только WinRM/консоль — можно выключить роль/fDenyTSConnections=1 после проверки консоли. Не выключайте firewall вместо RDP.

Пользователи не хотят VPN

Тогда нет удалённого рабочего стола. Исключений «ну очень надо 3389 на мир» для contoso.example не закладывайте.