Cómo configurar acceso remoto (RDP) seguro en el servidor de MU

El RDP (Remote Desktop Protocol) es la puerta de entrada por donde administras el servidor de MU, y es exactamente por eso que es el blanco predilecto de quien quiere invadirlo. Dejar el puerto 3389 abierto a toda internet, con una cuenta "Administrador" y una contraseña mediocre, es prácticamente una invitación: existen botnets que escanean rangos enteros de IP buscando RDP expuesto y probando miles de contraseñas por hora. Un servidor de MU comprometido de esa forma significa base de datos robada, ítems duplicados, cuentas de jugadores filtradas y, muchas veces, ransomware. La buena noticia es que puedes mantener toda la practicidad del Escritorio Remoto y, al mismo tiempo, cerrar casi toda esa superficie de ataque con algunas capas bien colocadas.

Esta guía muestra cómo transformar un RDP "abierto y vulnerable" en un acceso remoto endurecido, capa por capa. Si todavía estás armando la estructura del servidor, revisa antes el paso a paso de cómo crear servidor de MU Online; aquí vamos a partir del supuesto de que Windows ya está en línea y que hoy accedes por RDP.

Requisitos previos

• Servidor Windows (Windows Server 2016/2019/2022 son los más comunes en VPS de MU).
• Cuenta con privilegio de administrador.
• Acceso a la consola KVM/VNC del panel del proveedor de VPS: la red de seguridad por si te dejas fuera. Confirma que funciona antes de empezar.
• Tu IP público de administración (anótalo en "mi ip"). Si cambia con frecuencia, considera contratar IP fija, una VPN o un segundo servidor "bastion" con IP fija.
• 30 a 40 minutos sin jugadores según el servidor, o al menos un horario de bajo movimiento.

Panorama de las capas de defensa

La seguridad del acceso remoto no es una única configuración, sino una pila. Cada capa, por sí sola, es evitable; juntas, elevan mucho el costo de un ataque. Vamos a aplicarlas en este orden:

El orden importa: empieza por la restricción por IP, que da la mayor ganancia con el menor riesgo, y ve apilando.

Etapa 1: restringir el RDP a tu IP en el firewall

Esta es la medida aislada más eficaz. En vez de dejar el 3389 abierto a 0.0.0.0/0, libera solo tu IP. En PowerShell/Símbolo del sistema elevado (cambia 203.0.113.10 por tu IP real):

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

Si administras desde dos o tres lugares fijos (casa, trabajo), puedes listar varios IPs separados por coma en remoteip. Luego, elimina o desactiva cualquier regla antigua que libere el RDP para todos:

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

Identifica reglas genéricas de "Escritorio Remoto" y restringe su alcance (o desactívalas), dejando válida únicamente tu regla por IP.

Etapa 2: endurecer las cuentas de acceso

Los bots asumen que existe una cuenta llamada Administrator/Administrador. Quita ese blanco del mapa.

1. Abre lusrmgr.msc (Usuarios y grupos locales).
2. Renombra la cuenta Administrador por defecto a algo no obvio (ej.: gm_root_2024).
3. Crea una cuenta de administración separada, también con nombre no obvio, y úsala en el día a día.
4. Define una contraseña fuerte: 16+ caracteres, mezclando mayúsculas, minúsculas, números y símbolos. Nada de nombre del servidor, "mu123", fechas o patrones de teclado.

Fuerza la política de contraseñas en secpol.msc → Directivas de cuenta → Directiva de contraseñas:

• Longitud mínima: 14
• Complejidad: Habilitada
• Vigencia máxima: 90 días (o según tu rutina)

Etapa 3: activar el bloqueo de cuenta (lockout)

Sin lockout, un atacante puede probar contraseñas infinitamente. Configura en secpol.msc → Directivas de cuenta → Directiva de bloqueo de cuenta:

Con esto, tras 5 contraseñas erradas la cuenta se bloquea por 15 minutos, volviendo impracticable la fuerza bruta. Solo ten cuidado de no bloquearte a ti mismo: por eso la restricción por IP (Etapa 1) va primero, ya que evita que los bots consuman tus intentos.

Etapa 4: garantizar el NLA (Network Level Authentication)

El NLA exige que el usuario se autentique antes de que se cree la sesión de escritorio, lo que ahorra recursos y bloquea una serie de ataques. En versiones modernas de Windows suele venir activado, pero confírmalo:

• SystemPropertiesRemote.exe → pestaña Remoto → marca "Permitir conexiones solo desde equipos que ejecuten Escritorio Remoto con Autenticación a nivel de red".

Verificación rápida vía PowerShell:

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

El valor 1 indica NLA activo. Si está en 0, actívalo por la interfaz de arriba.

Etapa 5: cambiar el puerto por defecto del RDP

Cambiar el 3389 por otro puerto es seguridad por oscuridad: no sustituye las capas anteriores, pero reduce mucho el ruido de los escaneos automáticos que solo golpean el 3389. El número exacto es libre; usa un puerto alto poco común (el valor de abajo es solo un ejemplo, varía según tu entorno).

1. Edita el registro en HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, clave PortNumber (defínela en decimal, ej.: 53389):

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

1. Abre el nuevo puerto en el firewall, aún restringido a tu 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. Reinicia el servicio de Escritorio Remoto (o el servidor). A partir de ahí, conéctate indicando el puerto en el cliente: TU_IP:53389.

Etapa 6: auditar los intentos de acceso

Activa la auditoría de inicio de sesión para ver quién está intentando entrar. En secpol.msc → Directivas locales → Directiva de auditoría, habilita "Auditar eventos de inicio de sesión" para error (y éxito, si quieres rastrear tus propios accesos).

En el Visor de eventos (eventvwr.msc) → Registros de Windows → Seguridad, el evento 4625 registra los inicios de sesión fallidos, incluido el IP de origen. Puedes automatizar el bloqueo de IPs reincidentes con un script programado que lea esos eventos y cree reglas de firewall:

# Bloquea IPs con muchos inicios de sesion fallidos en las ultimas horas (ejemplo, ajusta los 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 con $($grupo.Count) fallas"
    }
}

Prográmalo con el Programador de tareas para que corra cada cierto tiempo. Si ya restringiste por IP en la Etapa 1, este script se vuelve una segunda línea de defensa útil, sobre todo mientras el puerto siga siendo accesible desde fuera.

Etapa 7: la opción más segura — sacar el RDP de internet con VPN

Lo ideal en seguridad es que el RDP no sea accesible por internet. Con una VPN (WireGuard y OpenVPN son las opciones típicas), tú:

1. Instalas el servidor VPN en el propio VPS o en un pequeño bastion host.
2. Haces que el RDP escuche solo en la interfaz interna/privada.
3. Cierras completamente el puerto del RDP para el IP público en el firewall.
4. Pasas a acceder al servidor entrando primero a la VPN y luego abriendo el RDP por el IP interno.

Así, para un atacante externo, el puerto del RDP simplemente no existe. Alternativamente, el Remote Desktop Gateway de Windows permite publicar el RDP sobre HTTPS (443) con autenticación centralizada, lo que también elimina la exposición directa del 3389. Ambos enfoques exigen más trabajo, pero son el estándar de oro para servidores en producción.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Consola KVM/VNC del proveedor probada y funcionando
• RDP restringido a mi IP en el firewall
• Cuenta Administrador por defecto renombrada
• Contraseña fuerte (14+ caracteres) y política de contraseñas activa
• Bloqueo de cuenta (lockout) configurado
• NLA confirmado como activo
• Puerto por defecto cambiado y nuevo puerto probado antes de cerrar el antiguo
• Auditoría de inicio de sesión habilitada y evento 4625 monitoreado
• Script/rutina de bloqueo de IPs reincidentes programado (si aplica)
• Evaluada la migración a VPN/bastion para sacar el RDP de internet
• Backup de las reglas de firewall exportado
• Documentación del nuevo procedimiento de acceso guardada en lugar seguro

Con estas capas aplicadas, el acceso remoto de tu servidor de MU deja de ser el eslabón más débil. La combinación de restricción por IP, cuentas endurecidas, lockout y —en el mejor escenario— una VPN reduce la superficie de ataque al punto de volver la invasión por RDP económicamente inviable para la abrumadora mayoría de los atacantes automatizados.

Preguntas frecuentes