Ataques de fuerza bruta a WordPress: rate limiting y bloqueo eficaz

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Si revisas los logs de acceso de cualquier WordPress expuesto a Internet, verás lo mismo: cientos o miles de intentos de inicio de sesión que nadie de tu equipo hizo. No es personal —es automatización. Un ataque de fuerza bruta a WordPress consiste en que un bot prueba combinaciones de usuario y contraseña de forma incansable hasta acertar, apoyándose en listas de credenciales filtradas en otras brechas. Dentro de la seguridad y hardening de WordPress, defender el formulario de acceso es de lo primero que hay que resolver, porque es la puerta que todo atacante prueba antes que ninguna otra.

Cómo funciona un ataque de fuerza bruta a WordPress

Hay dos variantes que conviene distinguir:

• Fuerza bruta clásica. Contra un usuario conocido (a menudo admin), el bot itera contraseñas: primero un diccionario de las más comunes, luego combinaciones. Barato y sorprendentemente efectivo contra contraseñas débiles.
• Credential stuffing. El atacante ya tiene pares usuario/contraseña reales, robados de otra filtración, y los prueba a ciegas contando con que la gente reutiliza credenciales. No adivina: reutiliza. Por eso una contraseña «fuerte» pero repetida en otro sitio ya comprometido no te protege.

El objetivo final es siempre el mismo: una sesión válida. Con ella, el atacante entra por la puerta principal sin explotar ningún fallo de código, lo que hace el compromiso difícil de detectar si solo vigilas vulnerabilidades técnicas.

Rate limiting: el freno que lo cambia todo

La defensa central es el rate limiting: limitar cuántos intentos de acceso se permiten en una ventana de tiempo. Un humano legítimo falla su contraseña dos o tres veces; un bot falla miles. Esa asimetría es tu arma. Configurado con criterio:

• Tras un número reducido de fallos (por ejemplo, 5), se bloquea temporalmente el origen durante minutos.
• Los bloqueos repetidos escalan la penalización: cada reincidencia alarga el tiempo de espera.
• El coste computacional del ataque se dispara: probar millones de contraseñas a razón de cinco cada quince minutos deja de ser viable.

El rate limiting no impide que lo intenten, pero convierte un ataque de horas en uno de siglos. Para el atacante automatizado, eso equivale a rendirse y buscar un objetivo más blando.

Bloqueo eficaz sin dispararte en el pie

Un bloqueo mal diseñado puede dejar fuera a usuarios legítimos o abrir una vía de denegación de servicio. Diseñarlo bien implica matices:

• No bloquees solo por IP a ciegas. Los ataques distribuidos rotan miles de IPs, y varios usuarios legítimos pueden compartir una (oficinas, operadores móviles). Combina IP con patrones de comportamiento.
• No reveles si el usuario existe. Un mensaje de error que distingue «usuario incorrecto» de «contraseña incorrecta» regala al atacante la mitad del trabajo. Usa un mensaje genérico.
• Cuidado con el auto-bloqueo. Deja siempre una vía de recuperación de acceso por si te bloqueas a ti mismo.
• Protege también los orígenes legítimos. Considera una lista de confianza para las IPs fijas de tu equipo.

El hueco que casi todos olvidan: xmlrpc.php

Aquí está el error clásico. Muchos administradores blindan wp-login.php con rate limiting y dan el tema por cerrado, pero xmlrpc.php es una segunda puerta de autenticación que a menudo queda desprotegida. Peor aún: su método system.multicall permite probar cientos de contraseñas en una sola petición HTTP, multiplicando la eficiencia del ataque y esquivando los contadores que solo miran el login clásico. Si no usas XML-RPC —la mayoría de sitios no lo necesitan—, deshabilítalo por completo. Si lo necesitas para algo concreto, restríngelo a los métodos imprescindibles y aplícale el mismo rate limiting que al login.

La fuerza bruta se combate en capas, no con una sola medida. Se apoya en una estrategia de backups con la regla 3-2-1 —para recuperar rápido si pese a todo alguien entra— y en la disciplina de las actualizaciones seguras con staging y rollback, porque un componente sin parchear puede regalar credenciales que hagan innecesario el ataque de fuerza. La defensa real es el conjunto.

Más allá del bloqueo: capas que rematan el ataque de fuerza bruta a WordPress

El rate limiting frena; otras capas rematan:

• Contraseñas fuertes y únicas, imposibles de adivinar por diccionario y no reutilizadas —lo único que detiene el credential stuffing.
• Autenticación de doble factor, para que, incluso si aciertan la contraseña, les falte el segundo factor.
• Nombres de usuario no predecibles, sin admin, sin el nombre visible del autor de los posts.
• Monitorización de logs, para detectar el patrón de un ataque en curso y reaccionar antes de que acierte.

Este enfoque por capas es el que documentan WordPress.org y el Wordfence Learning Center, cuyos datos muestran que el acceso por credenciales es uno de los vectores más frecuentes —muy por delante de muchas vulnerabilidades catalogadas en la NVD del NIST. En PathSentinel investigamos también incidentes en entornos exigentes —banca y comercios con datos de tarjeta—, donde un login sin rate limiting no es una molestia sino un incumplimiento con consecuencias. La buena noticia es que cerrar esta puerta es de lo más asequible que puedes hacer por tu seguridad.