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

Проброс WAN:3389→10.0.10.x и WAN:445→файл делает периметр дырявым: brute, ransomware-сканеры, утечка NTLM. Снимите DNAT, закройте порты на filter, доступ — VPN (WG/IPsec) в 10.0.10.0/24 или бастион в mgmt 10.0.99.0/24. Смена порта на 3390 не считается. UPnP может вернуть проброс — выключите (UPnP). Не отключайте firewall. Сканируйте только свой 203.0.113.10.

До снятия — рабочий VPN и консоль гипервизора, иначе отрежете админов.

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

nmap с LTE своего IP: 3389/tcp open или 445/tcp open. На RouterOS dstnat tcp 3389. Windows Security: неудачные логоны с публичных адресов. Пользователи привыкли mstsc /v:203.0.113.10.

ПробросРискЗамена
3389brute RDPVPN затем RDP на 10.0.10.10
445/139SMB с мираVPN + внутренний SMB
22 на внутренний Linuxbrute SSHVPN / mgmt
443 на GUI FWадминкастатья админки
443 на web DMZнорма, если матрицане этот кейс

Не путать с публикацией HTTPS в DMZ 10.0.30.10 — это не RDP.

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

  1. «Так всегда работали удалённо».
  2. Подрядчик 1С.
  3. UPnP/«игровой» роутер в офисе.
  4. Облачный NSG 3389/Any.
  5. Второй WAN/старый микротик в шкафу.
  6. IPv6 проброс забыли.

Диагностика

С улицы, только свой белый:

nmap -Pn -p 22,139,445,3389,3390,8291 203.0.113.10

На шлюзе:

sudo nft list table ip nat
sudo nft list table inet nat
sudo ss -lnt | grep -E '3389|445'
/ip firewall nat print where chain=dstnat
/ip upnp print
/ip firewall filter print where dst-port=3389 or dst-port=445

На Windows-цели:

Get-NetTCPConnection -LocalPort 3389,445 -State Listen
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10

Концепция pf: rdr/WAN NAT 3389. GUI Port Forward. Скрин в заявку.

Инвентарь всех белых организации, не только основной A-записи.

Решение

Сценарий A. RouterOS dst-nat

Backup. Поднимите и проверьте VPN. Затем:

/ip firewall nat print where chain=dstnat
# disable правила tcp 3389 и 445/139 с in-interface-list=WAN
/ip firewall filter add chain=forward in-interface-list=WAN protocol=tcp dst-port=3389,445,139 action=drop comment="no rdp/smb wan"

Disable nat, не только filter: иначе conntrack/другой allow может ожить. Проверьте, что UDP VPN (51820/500/4500) allow остался.

Сценарий B. nftables DNAT

sudo cp /etc/nftables.conf /root/nftables.conf.bak.dnat
# удалить dnat tcp dport 3389 / 445
# forward: iif wan tcp dport { 3389, 445, 139 } drop
sudo nft -c -f /etc/nftables.conf
sudo systemctl reload nftables

Хост с белым на NIC: Windows Firewall 3389 только 10.0.10.0/24,10.8.0.0/24 (туннель).

Сценарий C. Пользовательский путь

Инструкция: VPN → pc01.contoso.example / 10.0.10.10. Один день cut-off старого IP. MFA на VPN.

Сценарий D. Подрядчик

Отдельная учётка VPN, маршруты только к нужной VM, срок, журнал. Не DNAT «на выходные».

Сценарий E. RDS Gateway на 443

Это не 3389, но тот же класс, если Any без MFA. Либо MFA+ограничение, либо тоже за VPN. Не путать с сайтом в DMZ.

Откат: enable nat из backup, если VPN внезапно умер — и сразу чинить VPN, не жить на пробросе неделями.

UPnP выключить в той же заявке.

Cut-over без потери админов и без возврата DNAT «на денёк»

День 0: VPN для всех, кто ходил на 203.0.113.10:3389, плюс консоль гипервизора, плюс один админ с проверенным профилем в сейфе заявки. День 1: disable dstnat 3389/445, filter drop этих портов с WAN, Windows Firewall на цели — 3389 только 10.0.10.0/24 и пул VPN. День 2: LTE nmap своего IP, Security log без новых публичных 4625. День 7: если DNAT не включали — delete, не держать disabled «вдруг».

Пользовательский mstsc на белый закройте коммуникацией в тот же день: иначе снова откроют. Подрядчику — учётка VPN с маршрутом к одной VM, не 445 на WAN. Проверьте второй WAN, IPv6 AAAA, хост с собственным белым: nmap всех адресов из договора. UPnP выключите в той же заявке, иначе mapping вернётся. Смена порта TermService на 3390 без закрытия WAN в отчёте помечайте как не выполнено.

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

  1. LTE: nmap своего IP — 3389/445 не open.
  2. LTE: VPN поднимается, Test-NetConnection 10.0.10.10 -Port 3389 success.
  3. Security log: новые 4625 с публичных на WAN-пути прекращаются.
  4. nat print без 3389/445 WAN.
  5. UPnP disabled.
  6. Повтор через неделю: не вернулось.
Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection 203.0.113.10 -Port 445

Fail. После VPN — success на внутренний хост.

Отдельно проверьте опубликованные «не 3389, но тот же смысл»: 3390, 3388, 22 на внутренний Windows OpenSSH, SSH-туннель на бастион с паролем с WAN, веб-панели удалённого доступа без MFA. Инвентарь: Get-NetTCPConnection -State Listen на серверах с маршрутом к белому и ss -lnt на Linux в DMZ. Всё, что даёт интерактивный стол или shell с 203.0.113.10, закрывается тем же принципом, что RDP. В матрице пометьте «удалённый доступ = только VPN». Пользовательский VNC/TeamViewer с Any — в ту же очередь, не «другая технология, значит можно».

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

  • Второй белый / IPv6 AAAA.
  • Хост слушает 3389 на собственном публичном.
  • Смена порта, сканер нашёл 3390 — уберите тоже.
  • TeamViewer/AnyDesk Any как замена — инвентарь remote tools.
  • Hairpin из LAN на белый всё ещё открывает — смотрите, нет ли dstnat без in-interface WAN (опасно).

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

  • Политика: запрет DNAT 3389/445/22 на WAN.
  • Квартальный периметр.
  • Алерт IDS/filter log на SYN 3389 WAN.
  • Offboarding VPN.
  • Запрет UPnP.

FAQ

Свой домашний IP в src DNAT?

Пока DHCP не сменится. VPN дешевле.

Только SMB подпись включить и оставить 445?

Нет. 445 не должен быть на WAN.

Бастион с 443 и MFA вместо VPN?

Возможно как продукт, не «голый RDP». Всё равно не 3389/Any.

Нужен ли RDP на DC с VPN всем сотрудникам?

Нет. Бастион/Jump, минимальные группы.

Проверка с офисного Wi‑Fi показала closed, а Shodan open

Вы не с улицы. Проверяйте LTE и все белые.