Cómo es realmente un ataque de fuerza bruta RDP

El ataque, en términos claros

Un ataque de fuerza bruta RDP no es una operación dirigida contra ti. Es un producto de masas: alguien alquila una botnet, le pasa una lista de rangos de IP y le hace intentar iniciar sesión en cada máquina que responda en el puerto 3389. La lista de contraseñas es corta y aburrida — Administrator con Password1, admin con admin, el nombre de la empresa con el año actual. Al bot no le importa qué hace tu servidor.

Lo que lo hace incesante es la economía. Un inicio de sesión exitoso vale dinero real en el mercado de accesos para ransomware, y el coste de un intento es prácticamente cero. Así que los bots nunca paran. Pon un Windows Server recién instalado en una IP pública con RDP abierto: el primer intento fallido suele llegar en menos de una hora, y una semana después son varios miles al día de forma constante.

El volumen es lo importante. Un humano adivinando tu contraseña es una anécdota; cien mil intentos al mes desde direcciones rotatorias es un fenómeno meteorológico. Las defensas que asumen lo primero son inútiles contra lo segundo.

Cómo saber que te está pasando

Windows registra cada inicio de sesión fallido como el evento 4625 en el registro de seguridad. Abre el Visor de eventos, ve a Registros de Windows → Seguridad y filtra por 4625. En un servidor tranquilo verás un puñado de entradas de gente que se equivocó al teclear. Bajo ataque verás un muro.

La señal no es el número en sí, es la forma. Un usuario que se equivoca produce dos o tres fallos desde una dirección, contra una cuenta que existe, y luego para. Un bot produce una serie larga contra nombres de cuenta que nunca existieron en tu máquina — admin, sql, backup, test, scanner, user1 — desde direcciones de rangos de hosting con los que nunca has tratado, a ritmo constante toda la noche.

Este comando devuelve las direcciones de origen más activas de las últimas 24 horas:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Por qué el consejo habitual solo funciona a medias

Toda lista de endurecimiento empieza con «usa una contraseña fuerte». Es correcto y no es suficiente. Una contraseña fuerte significa que los bots no la adivinarán — pero seguirán intentándolo eternamente, y cada intento te cuesta un hilo, una línea de registro de auditoría y una porción de CPU. Los servidores bajo ataque sostenido se ralentizan de forma medible, y el registro de seguridad rota tan rápido que el evento que necesitabas ya no está.

La siguiente línea suele ser «activa la directiva de bloqueo de cuentas». Cuidado con esa. El bloqueo cuenta fallos por cuenta, y los bots adivinan nombres de cuenta desde una lista. Bloquea Administrator tras cinco intentos fallidos y un atacante que nunca tuvo posibilidad de adivinar la contraseña puede ahora desactivar esa cuenta a voluntad, desde cualquier lugar, para siempre. Has convertido una molestia en una denegación de servicio contra ti mismo.

Network Level Authentication ayuda de verdad: obliga al cliente a autenticarse antes de crear una sesión, lo que elimina toda una clase de exploits previos a la autenticación y reduce el coste de cada intento. Actívalo. No reduce el ritmo de intentos.

Una VPN delante de RDP es la respuesta más sólida disponible y la que la mayoría de organizaciones no puede adoptar de verdad: significa que cada contratista, cada teléfono y cada inicio de sesión de emergencia a las tres de la madrugada pasa por infraestructura adicional que también hay que mantener y pagar. Si puedes, hazlo. La mayoría de los servidores que están siendo atacados ahora mismo pertenecen a quienes no pueden.

Qué reduce realmente los intentos

Lo único que cambia el volumen es negarse a hablar con el origen. Todo lo demás negocia con él.

Eso significa vigilar el flujo de fallos y, cuando una dirección cruza un umbral, añadirla a una regla de firewall que descarte sus paquetes antes de que Windows gaste nada en ellos. Es lo que hace fail2ban en Linux, y no existe equivalente integrado en Windows — por eso tantos administradores acaban escribiendo un script PowerShell programado.

Tres detalles separan una defensa que aguanta de una que gotea:

• Banear la subred, no la dirección. Los bots viven en rangos de hosting. Bloquea 203.0.113.47 y .48 arranca una hora después. Bloquear el /24 termina la serie entera de golpe — y los usuarios legítimos casi nunca comparten un /24 con un escáner.
• Banear de forma permanente y sobrevivir a los reinicios. Un baneo de una hora significa que la misma botnet vuelve esta noche. La regla tiene que vivir en el firewall, no en memoria.
• Ponerte a ti mismo en la lista blanca primero, antes de activar cualquier otra cosa. La forma más común de estropearlo es un administrador que bloquea su propia IP de oficina en un servidor al que solo llega por RDP.

Consolida las reglas o el firewall será el cuello de botella

Un detalle que solo aparece en producción: el Firewall de Windows maneja mucho mejor unas pocas reglas grandes que miles de pequeñas. Los scripts que llaman a New-NetFirewallRule por cada dirección baneada funcionan de maravilla durante quince días y luego empiezan a tardar minutos en evaluarse, porque el conjunto de reglas ha crecido a cinco cifras.

La solución es mantener una única regla cuya lista de direcciones se reescribe, en vez de una regla por atacante. Una pequeña decisión de diseño que determina si la defensa sigue funcionando dentro de seis meses.

Conseguir lo mismo sin escribir el script

RDP Protector es esa lógica empaquetada como un agente de Windows firmado. Lee el mismo flujo 4625 que leerías tú, decide localmente — así que sigue funcionando si cae la red — y mantiene una única regla de firewall consolidada con todos los rangos baneados.

Al instalarse detecta los puertos reales de RDP, FTP y MS SQL desde el registro y los sockets en escucha, de modo que un servidor que se movió del 3389 queda cubierto sin configuración, y pone en lista blanca la IP desde la que estás conectado antes de bloquear nada.

Lo que no puedes construir solo es la reputación compartida: una dirección que atacó a otro cliente ya está bloqueada en tu servidor antes de llegar. Un servidor es gratis para siempre, lo que basta para observar un flujo de ataques real en tu propia máquina y decidir con pruebas.