Como configurar acesso remoto (RDP) seguro no servidor de MU

O RDP (Remote Desktop Protocol) é a porta de entrada por onde você administra o servidor de MU — e é exatamente por isso que ele é o alvo predileto de quem quer invadir. Deixar a porta 3389 aberta para a internet inteira, com uma conta "Administrador" e uma senha média, é praticamente um convite: existem botnets que varrem faixas inteiras de IP procurando RDP exposto e testando milhares de senhas por hora. Um servidor de MU comprometido dessa forma significa banco de dados roubado, itens duplicados, contas de jogadores vazadas e, muitas vezes, ransomware. A boa notícia é que dá para manter toda a praticidade do Área de Trabalho Remota e, ao mesmo tempo, fechar quase toda essa superfície de ataque com algumas camadas bem colocadas.

Este guia mostra como transformar um RDP "aberto e vulnerável" em um acesso remoto endurecido, camada por camada. Se você ainda está montando a estrutura do servidor, veja antes o passo a passo de como criar servidor de MU Online; aqui vamos partir do princípio de que o Windows já está no ar e você acessa por RDP hoje.

Pré-requisitos

• Servidor Windows (Windows Server 2016/2019/2022 são os mais comuns em VPS de MU).
• Conta com privilégio de administrador.
• Acesso ao console KVM/VNC do painel do provedor de VPS — a rede de segurança caso você se tranque para fora. Confirme que ele funciona antes de começar.
• Seu IP público de administração (anote em "meu ip"). Se ele muda com frequência, considere contratar IP fixo, uma VPN ou um segundo servidor "bastion" com IP fixo.
• 30 a 40 minutos sem jogadores dependendo do servidor, ou pelo menos um horário de baixo movimento.

Panorama das camadas de defesa

Segurança de acesso remoto não é uma única configuração, e sim uma pilha. Cada camada, sozinha, é contornável; juntas, elas elevam muito o custo de um ataque. Vamos aplicar nesta ordem:

A ordem importa: comece pela restrição por IP, que dá o maior ganho com o menor risco, e vá empilhando.

Etapa 1: restringir o RDP ao seu IP no firewall

Esta é a medida isolada mais eficaz. Em vez de deixar a 3389 aberta para 0.0.0.0/0, libere apenas o seu IP. Em PowerShell/Prompt elevado (troque 203.0.113.10 pelo seu IP real):

netsh advfirewall firewall add rule name="ADMIN - RDP restrito" dir=in action=allow protocol=TCP localport=3389 remoteip=203.0.113.10

Se você administra de dois ou três locais fixos (casa, trabalho), pode listar vários IPs separados por vírgula no remoteip. Em seguida, remova ou desative qualquer regra antiga que libere o RDP para todos:

netsh advfirewall firewall show rule name=all dir=in | findstr /i "3389 Desktop Remote"

Identifique regras genéricas de "Área de Trabalho Remota" e restrinja o escopo delas (ou desative), deixando valer apenas a sua regra por IP.

Etapa 2: endurecer as contas de acesso

Bots assumem que existe uma conta chamada Administrator/Administrador. Tire esse alvo do mapa.

1. Abra lusrmgr.msc (Usuários e Grupos Locais).
2. Renomeie a conta Administrador padrão para algo não óbvio (ex.: gm_root_2024).
3. Crie uma conta de administração separada, também com nome não óbvio, e use-a no dia a dia.
4. Defina uma senha forte: 16+ caracteres, misturando maiúsculas, minúsculas, números e símbolos. Nada de nome do servidor, "mu123", datas ou padrões de teclado.

Force a política de senha em secpol.msc → Diretivas de Conta → Diretiva de Senha:

• Comprimento mínimo: 14
• Complexidade: Habilitada
• Idade máxima: 90 dias (ou conforme sua rotina)

Etapa 3: ativar o bloqueio de conta (lockout)

Sem lockout, um atacante pode testar senhas infinitamente. Configure em secpol.msc → Diretivas de Conta → Diretiva de Bloqueio de Conta:

Com isso, após 5 senhas erradas a conta trava por 15 minutos, tornando a força bruta impraticável. Cuidado apenas para não trancar a si mesmo: por isso a restrição por IP (Etapa 1) vem primeiro — ela evita que bots consumam suas tentativas.

Etapa 4: garantir o NLA (Network Level Authentication)

O NLA exige que o usuário se autentique antes de a sessão de desktop ser criada, o que economiza recursos e bloqueia uma série de ataques. Em versões modernas do Windows ele costuma vir ligado, mas confirme:

• SystemPropertiesRemote.exe → aba Remoto → marque "Permitir conexões apenas de computadores que executam a Área de Trabalho Remota com Autenticação no Nível da Rede".

Verificação rápida via PowerShell:

Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication

O valor 1 indica NLA ativo. Se estiver 0, ative pela interface acima.

Etapa 5: trocar a porta padrão do RDP

Trocar a 3389 por outra porta é segurança por obscuridade — não substitui as camadas anteriores, mas reduz muito o ruído dos scans automáticos que só batem na 3389. O número exato é livre; use uma porta alta pouco comum (o valor abaixo é apenas exemplo, varia conforme seu ambiente).

1. Edite o registro em HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, chave PortNumber (defina em decimal, ex.: 53389):

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name PortNumber -Value 53389

1. Abra a nova porta no firewall, ainda restrita ao seu IP:

netsh advfirewall firewall add rule name="ADMIN - RDP porta custom" dir=in action=allow protocol=TCP localport=53389 remoteip=203.0.113.10

1. Reinicie o serviço de Área de Trabalho Remota (ou o servidor). A partir daí, conecte informando a porta no cliente: SEU_IP:53389.

Etapa 6: auditar tentativas de acesso

Ative a auditoria de logon para enxergar quem está tentando entrar. Em secpol.msc → Diretivas Locais → Diretiva de Auditoria, habilite "Auditar eventos de logon" para falha (e sucesso, se quiser rastrear seus próprios acessos).

No Visualizador de Eventos (eventvwr.msc) → Logs do Windows → Segurança, o evento 4625 registra falhas de logon, incluindo o IP de origem. Você pode automatizar o bloqueio de IPs reincidentes com um script agendado que lê esses eventos e cria regras de firewall:

# Bloqueia IPs com muitas falhas de logon nas ultimas horas (exemplo, ajuste os limites)
$limite = 10
$desde  = (Get-Date).AddHours(-2)

$falhas = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$desde} -ErrorAction SilentlyContinue
$ips = $falhas | ForEach-Object {
    ($_.Properties | Where-Object { $_.Value -match '^\d+\.\d+\.\d+\.\d+$' }).Value
} | Group-Object | Where-Object { $_.Count -ge $limite }

foreach ($grupo in $ips) {
    $ip = $grupo.Name
    if (-not (Get-NetFirewallRule -DisplayName "AUTOBLOCK RDP - $ip" -ErrorAction SilentlyContinue)) {
        New-NetFirewallRule -DisplayName "AUTOBLOCK RDP - $ip" -Direction Inbound -Action Block -RemoteAddress $ip -Protocol TCP
        Write-Output "$(Get-Date) bloqueado $ip com $($grupo.Count) falhas"
    }
}

Agende com o Agendador de Tarefas para rodar de tempos em tempos. Se você já restringiu por IP na Etapa 1, esse script vira uma segunda linha de defesa útil principalmente enquanto a porta ainda estiver acessível de fora.

Etapa 7: a opção mais segura — tirar o RDP da internet com VPN

O ideal de segurança é que o RDP não seja acessível pela internet. Com uma VPN (WireGuard e OpenVPN são as escolhas típicas), você:

1. Instala o servidor VPN no próprio VPS ou em um pequeno bastion host.
2. Faz o RDP escutar apenas na interface interna/privada.
3. Fecha completamente a porta do RDP para o IP público no firewall.
4. Passa a acessar o servidor entrando primeiro na VPN e depois abrindo o RDP pelo IP interno.

Assim, para um atacante externo, a porta do RDP simplesmente não existe. Alternativamente, o Remote Desktop Gateway do Windows permite publicar o RDP sobre HTTPS (443) com autenticação centralizada, o que também elimina a exposição direta da 3389. Ambas as abordagens exigem mais trabalho, mas são o padrão-ouro para servidores em produção.

Erros comuns e soluções

Checklist de lançamento

• Console KVM/VNC do provedor testado e funcionando
• RDP restrito ao meu IP no firewall
• Conta Administrador padrão renomeada
• Senha forte (14+ caracteres) e política de senha ativa
• Bloqueio de conta (lockout) configurado
• NLA confirmado como ativo
• Porta padrão trocada e nova porta testada antes de fechar a antiga
• Auditoria de logon habilitada e evento 4625 sendo monitorado
• Script/rotina de bloqueio de IPs reincidentes agendado (se aplicável)
• Avaliada a migração para VPN/bastion para tirar o RDP da internet
• Backup das regras de firewall exportado
• Documentação do novo procedimento de acesso guardada em local seguro

Com essas camadas aplicadas, o acesso remoto do seu servidor de MU deixa de ser o elo mais fraco. A combinação de restrição por IP, contas endurecidas, lockout e — no melhor cenário — uma VPN reduz a superfície de ataque ao ponto de tornar a invasão por RDP economicamente inviável para a esmagadora maioria dos atacantes automatizados.

Perguntas frequentes