O RDP é uma das portas de entrada clássicas do ransomware num Windows Server: um serviço de administração útil, exposto à internet, descoberto em minutos — o hardening não é um único parâmetro — é uma pilha curta: desligar onde não é preciso, autenticação antes da sessão, acesso à distância encaminhado por VPN ou gateway, quem é que pode ligar, credenciais que não ficam no servidor e firewall com regras por origem. Este guia aplica cada camada com os comandos e os caminhos de GPO reais.

TL;DR — 6 camadas:

  1. Desliga o RDP nos servidores que não o precisam e confirma a exposição real a partir de uma rede exterior.
  2. Exige NLA (autenticação antes de a sessão existir) por GPO.
  3. Nunca abras o 3389 por reencaminhamento de porta — usa VPN ou RD Gateway, de preferência com MFA.
  4. Quem pode ligar: restringe por grupos no SO e por origem na firewall (Windows e perímetro).
  5. Administração com Restricted Admin ou Remote Credential Guard — as credenciais não ficam no servidor.
  6. Limites de sessão, certificado TLS de confiança e auditoria aos 4624/4625 (com NLA, os falhados chegam como tipo 3).

Índice

1. Saber onde estás agora

Primeiro, desliga o RDP nos hosts que não precisam dele (um servidor de ficheiros raramente precisa) — a orientação oficial de hardening começa exactamente aí. Nos que precisam, confirma a exposição a partir de uma rede que não seja a do servidor (o telemóvel em dados móveis, por exemplo):

Test-NetConnection o-teu-host.example -Port 3389


TcpTestSucceeded : False

O que é que este teste prova? Se devolve TcpTestSucceeded : True de fora, o 3389 está acessível a toda a internet — a camada de perímetro está mal (secção 6). Dentro da rede, o seguinte confirma que o serviço está activo e com NLA:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

fDenyTSConnections = 0 significa o RDP activo. UserAuthentication = 1 significa NLA exigido.

2. NLA: autenticar antes de a sessão existir

Com o Network Level Authentication, o cliente autentica-se (via CredSSP) antes de a sessão ser criada — reduz a superfície para exploits de pré-autenticação e para o DoS da fila de logons. Configuração oficial por GPO:

  • Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security
  • Require user authentication for remote connections by using Network Level Authentication → Enabled
  • Require use of specific security layer for remote (RDP) connections → SSL (TLS)

Em servidores sem AD, o registo faz o mesmo:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 1 /f

Nota: o NLA não protege contra uma palavra-passe roubada — apenas exige que a autenticação ocorra cedo. É uma camada, não o guarda-chuva: por isso as camadas 4 e 5 existem.

⚠️ Trocar o 3389 por outra porta não é hardening: os scanners de massa descobrem o RDP em portas qualquer em minutos. O que ganhas é falso sossego e confusão de gestão. O foco tem de estar em NLA + perímetro + MFA.

3. Quem pode ligar (e bloqueio de conta)

A pergunta do SO: que contas têm o direito de logon remoto? A GPO Allow log on through Remote Desktop Services (User Rights Assignment) deve listar apenas o grupo de administração — e nunca "Everyone". O bloqueio de conta corta a força bruta: as baselines de segurança Microsoft usam 10 tentativas:

  • Computer Configuration → Policies → Windows Settings → Security Settings → Account Lockout Policy → limiar 10, duração 15 min ou mais

Atenção ao nível da política: para contas de domínio, o bloqueio tem de estar na GPO ao nível do domínio — numa GPO de OU, afecta só as contas locais desse equipamento. Com contas de serviço/partilhadas é onde a coisa fica feia: contas de serviço não precisam de RDP — se as têm, tira-lhes o direito no User Rights Assignment. Cada conta com logon remoto é uma fila de tentativas no 4625.

4. Não abras o 3389: VPN e RD Gateway

A orientação oficial da Microsoft para o Windows Server é directa: quando o acesso remoto é preciso, passa por VPN ou Remote Desktop Gateway com MFA, restringindo redes de origem e grupos autorizados — nunca o 3389 exposto. Em ordem de preferência prática:

  1. VPN de acesso remoto (WireGuard/OpenVPN): o RDP fica na grelha privada. Liga-se à VPN e o mstsc usa o IP interno. Zero superfície na internet.
  2. RD Gateway: o RDP viaja em HTTPS (443) e fica num ponto único onde configurar MFA (RADIUS) e políticas de acesso. É a via quando não queres VPN nos equipamentos.
  3. Nada: reencaminhamento de porta para o 3389 (ou porta alta) no router/FW — não.

ℹ️ MFA ou NLA? O NLA confirma a conta/ palavra-passe. O MFA confirma que quem as digita é o que deve estar — é o que corta a força bruta e o roubo de credenciais (phishing, infostealers). Um gateway com MFA é o ideal para acesso externo.

5. Credenciais: Restricted Admin e Remote Credential Guard

No RDP normal, as tuas credenciais ficam no host a que te ligas (logon completo) — um atacante com esse host extrai-as (LSASS). Para administração:

  • Restricted Admin: mstsc /RestrictedAdmin — o logon usa a identidade do próprio host (sem as tuas credenciais). Suporta sessões para helpdesk. São duas peças: no cliente, a GPO Restrict delegation of credentials to remote servers impõe o modo no momento de ligar. No servidor, a GPO Remote host allows delegation of non-exportable credentials ou o registo DisableRestrictedAdmin = 0 (o valor 1 proíbe o modo). Trade-off a assumir: com o modo permitido no servidor, uma autenticação por pass-the-hash contra o RDP passa — o destino deixa de exigir as credenciais completas. E DisableRestrictedAdminOutboundCreds = 1 impede a sessão restrita de autenticar outros recursos com a tua identidade (sem SSO em cascata).
  • Remote Credential Guard: mstsc /remoteGuard — as credenciais nunca saem do teu PC (Kerberos redireccionado). Só funciona para alvos AD, por Kerberos (não NTLM), e não atravessa RD Gateway nem Connection Broker — limite documentado no post de hardening da Microsoft (nas Fontes).

A escolha da Microsoft: Remote Credential Guard para administração corrente a alvos AD, e o Restricted Admin para cenários de helpdesk a hosts possivelmente comprometidos.

6. Firewall: host e perímetro

O Windows Firewall por omissão já bloqueia o tráfego entrante não solicitado — a recomendação oficial é manter esse bloco por omissão e criar regras o mais específicas possível, com restrição de endereço de origem. No RDP, desactiva as regras por defeito do Remote Desktop e fica só com uma restrita:

Get-NetFirewallRule -Name 'RemoteDesktop-*' | Select-Object Name, DisplayName, Enabled, Profile


# desactiva as por defeito (os nomes técnicos são iguais em qualquer idioma):
Get-NetFirewallRule -Name 'RemoteDesktop-*' | Set-NetFirewallRule -Enabled False


# abre só à rede de gestão:
New-NetFirewallRule -Name 'RDP-gestao' -DisplayName 'RDP - rede de gestão' -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 192.168.10.0/24 -Action Allow -Profile Domain,Private

Sem regra de bloqueio a adicionar: o comportamento por omissão já bloqueia o entrante não solicitado — e uma regra de bloqueio explícito ganharia à tua própria excepção (o RDP ficava cortado para todos). Não esquece o UDP 3389 (a regra por defeito também existe): desactiva-o no Get-NetFirewallRule -Name de cima, se só usas TCP no teu cenário.

No perímetro: nenhuma porta (3389 ou outra) apontada para o servidor. No firewall do perímetro permite-se apenas VPN (UDP 51820, por exemplo) ou 443 para o RD Gateway — e, de novo, de origem conhecida sempre que possível. Se o teu perímetro é um pfSense/OPNsense, a WAN não recebe regra nenhuma para o RDP: as únicas regras de entrada são a VPN e a porta do gateway (443).

7. Sessão, TLS e auditoria

As três camadas finais do SO:

Controlo Onde Valor
Terminar sessões inactivas GPO Session Host → Session Time Limits limite de inactivo/desligado (1h-8h)
Certificado TLS do listener WinStations → SSLCertificateSHA1Hash cert da CA interna (não self-signed)
Camada de segurança GPO Security → security layer SSL (negociação TLS)
Auditoria de logons GPO Advanced Audit Policy → Logon/Logoff Success + Failure — 4624 tipo 10 e, com NLA, os 4625 chegam como tipo 3

Com a auditoria activa (o Logon/Logoff vem por omissão), tentativas de 4625 — com NLA, tipo 3 (o falhado chega na pré-autenticação) ou tipo 10 sem NLA — antes de um 4624 do tipo 10 de outra origem = sinal forte de força bruta a decorrer. É o rasto forense do Event Viewer do artigo de ransomware. E se aparecer um 4624 do tipo 10 que não corresponde a nenhuma sessão tua, esse é o ponto de partida do dia seguinte: alguém entrou.

Veredicto

O hardening de RDP não é um GPO: é uma pilha. Desligado onde não serve, NLA obrigatório, acesso externo por VPN/RD Gateway com MFA, grupos e origens restritas nas duas firewalls, credenciais que não ficam no host (Restricted Admin/Remote Credential Guard), limites de sessão e auditoria activa. Com a pilha completa, a pergunta "alguém está a tentar entrar?" responde-se nos 4625 — e a resposta "de onde" está no tipo de logon e no IP de origem.

Artigos Relacionados

Fontes Oficiais