Cómo proteger una VPS Windows contra ataques de fuerza bruta en RDP

Toda VPS Windows expuesta a internet pública empieza a recibir intentos de login en RDP pocos minutos después del arranque. Los bots barren rangos enteros de IP buscando el puerto 3389 abierto y lanzan diccionarios de contraseñas comunes contra cuentas como Administrator, admin, user y variantes. En una VPS sin protección, el Event Log se llena de Event ID 4625 (fallo de logon) en pocas horas — y basta una contraseña débil para que un atacante consiga entrar.

Este tutorial está dirigido a sysadmins de Windows que han aprovisionado una VPS recientemente y quieren reducir la superficie de ataque del RDP antes de poner el servidor en producción. Las medidas aquí no requieren software de terceros — usan solo recursos nativos de Windows Server 2019/2022/2025. Tiempo estimado: 30 a 45 minutos para aplicar todas las capas.

El enfoque es por capas — ninguna medida por sí sola es suficiente. Vas a aplicar cuatro defensas: política de bloqueo de cuenta, cambio del puerto por defecto del RDP, restricción de firewall por IP de origen y bloqueo automático de IPs ofensoras mediante Tarea Programada disparada por evento.

Requisitos previos

Antes de empezar, abre el Visor de Eventos en Registros de Windows > Seguridad y filtra por Event ID 4625. En una VPS expuesta durante más de 24 horas normalmente verás cientos de intentos provenientes de IPs en China, Rusia, Brasil y EE. UU. Ese es el baseline que vamos a derribar.

Aplicar política de bloqueo de cuenta

La política de bloqueo hace que Windows deshabilite una cuenta temporalmente tras N intentos fallidos. Sin esto, un atacante puede disparar miles de contraseñas por minuto contra la cuenta Administrator. Con un bloqueo de 5 intentos y una duración de 30 minutos, el atacante consigue probar como máximo 240 contraseñas por día por cuenta — haciendo inviable el ataque de diccionario.

Configuración del equipo > Configuración de Windows > Configuración de seguridad >
Directivas de cuenta > Directiva de bloqueo de cuenta

gpupdate /force

net accounts

Cambiar el puerto por defecto del RDP

Cambiar de 3389 a un puerto alto (por encima de 49152, rango dinámico) elimina el ruido de los escáneres automatizados que solo buscan el puerto por defecto. No es seguridad real contra ataque dirigido — nmap -p- IP aún lo encuentra — pero reduce los Event ID 4625 en un 90%+ en VPS expuestas.

HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

New-NetFirewallRule -DisplayName "RDP Custom Port 54289 TCP" `
  -Direction Inbound -LocalPort 54289 -Protocol TCP -Action Allow

New-NetFirewallRule -DisplayName "RDP Custom Port 54289 UDP" `
  -Direction Inbound -LocalPort 54289 -Protocol UDP -Action Allow

Restart-Service TermService -Force

Restringir RDP por IP de origen

La medida más efectiva: el firewall solo acepta conexiones RDP desde IPs específicas. Funciona bien si tu equipo accede desde IPs fijas (oficina, VPN corporativa). No funciona si necesitas acceder desde redes residenciales con IP dinámica — en ese caso, considera la alternativa del túnel WireGuard.

(Invoke-WebRequest -Uri "https://ifconfig.me/ip").Content

Set-NetFirewallRule -DisplayName "RDP Custom Port 54289 TCP" `
  -RemoteAddress @("203.0.113.10", "198.51.100.42")

Get-NetFirewallRule -DisplayName "RDP Custom Port 54289 TCP" |
  Get-NetFirewallAddressFilter

Bloquear automáticamente IPs ofensoras

Incluso con bloqueo de cuenta y puerto cambiado, si no puedes restringir por IP de origen (atención al público, equipo distribuido), configura un bloqueo dinámico: cada vez que aparece un Event ID 4625 por encima de un umbral, una Tarea Programada dispara un script PowerShell que añade la IP de origen a una regla de firewall de bloqueo.

param([string]$EventRecordID)

$event = Get-WinEvent -LogName Security -FilterXPath `
  "*[System[EventRecordID=$EventRecordID]]"

$ip = ($event.Properties | Where-Object { $_.Value -match '^\d+\.\d+\.\d+\.\d+$' } |
  Select-Object -First 1).Value

if (-not $ip -or $ip -eq "127.0.0.1") { exit }

$ruleName = "AutoBlock-$ip"
if (-not (Get-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue)) {
    New-NetFirewallRule -DisplayName $ruleName -Direction Inbound `
      -RemoteAddress $ip -Action Block | Out-Null
    Add-Content "C:\Scripts\blocked-ips.log" "$(Get-Date -Format o) BLOCKED $ip"
}

-ExecutionPolicy Bypass -File C:\Scripts\BlockBruteforceIP.ps1 -EventRecordID $(EventRecordID)

Get-NetFirewallRule | Where-Object DisplayName -like "AutoBlock-*"

Verificación

Después de aplicar las cuatro capas, confirma cada una ejecutando:

# Política de bloqueo
net accounts | findstr "bloqueo"

# Nuevo puerto RDP activo
Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  | Select-Object PortNumber

# Firewall acepta conexión en el nuevo puerto
Test-NetConnection -ComputerName localhost -Port 54289

# La cuenta quedó efectivamente "blindada" — intenta login incorrecto 5 veces desde otra IP
# y verifica el Event Log buscando Event ID 4740 (Cuenta bloqueada)
Get-WinEvent -LogName Security -MaxEvents 50 |
  Where-Object Id -eq 4740 | Format-Table TimeCreated, Message -AutoSize

Espera 24 horas y vuelve al Visor de Eventos. Deberías ver los Event ID 4625 caer de cientos/miles por día a decenas o cero, dependiendo de cuán expuesto haya quedado el puerto original antes del cambio.

Próximos pasos

• Configura NLA (Network Level Authentication) si no está activo — exige autenticación antes del handshake completo de RDP, reduciendo la superficie de ataque a vulnerabilidades pre-auth.
• Considera migrar del RDP nativo a Azure Bastion o a un gateway RDS con MFA si el entorno lo justifica.
• Implementa auditoría de logon exitoso (Event ID 4624) y alertas por email para logins fuera del horario habitual.
• Haz backup periódico del registro (HKLM\System\CurrentControlSet\Control\Terminal Server) — así reviertes rápido si algo se rompe.
• Si estás aprovisionando una VPS nueva para producción, una VPS Hostini Windows ya viene con consola fuera de banda accesible desde el panel — así que aunque te bloquees fuera del RDP aplicando estas reglas, la recuperación no exige ticket de soporte.