Ataques de fuerza bruta contra el acceso de WordPress: cómo funcionan y cómo detenerlos

Un ataque de fuerza bruta es lo que suena: un script automatizado prueba combinaciones de usuario y contraseña contra tu página de acceso, una y otra vez, hasta que una funciona. No tiene nada de glamuroso, es extremadamente común y casi totalmente automático. La mayoría de los sitios WordPress reciben intentos a los pocos días de ponerse en línea, por poco conocidos que sean.

Por qué funciona

Solo tiene éxito donde coinciden tres condiciones: contraseñas débiles o reutilizadas, nombres de usuario predecibles (admin es el clásico) y ningún límite al número de intentos de un script. Quita cualquiera de ellas y un ataque de fuerza bruta deja de ser una amenaza real, por muchos intentos que lance un bot.

Una variante llamada credential stuffing no adivina nada. Prueba pares reales de correo y contraseña filtrados de otros servicios, apostando a que reutilizaste uno. Por eso una contraseña robusta pero reutilizada sigue siendo un riesgo.

Qué lo detiene de verdad

• Una contraseña única y robusta en cada cuenta. Esto solo frustra a la gran mayoría de los intentos. Un gestor de contraseñas lo hace sin esfuerzo.
• Ningún usuario «admin». Es el primer intento de cada ejecución automatizada. Crea un administrador con otro nombre, traspasa el contenido y borra la cuenta antigua.
• Intentos de acceso limitados. Bloquear una dirección tras un puñado de fallos convierte un juego de adivinanzas ilimitado en un callejón sin salida.
• Autenticación de dos factores. Incluso una contraseña adivinada o filtrada es inútil sin el segundo factor.
• Limitación de tasa en el servidor o el firewall. Bloquea la avalancha de peticiones antes de que lleguen a WordPress, lo que también protege los recursos del servidor. Una herramienta como fail2ban puede vetar una dirección que sigue fallando; la guía del firewall explica dónde encaja.

No olvides XML-RPC

El formulario de acceso no es la única puerta. WordPress también acepta accesos a través de xmlrpc.php, y esa interfaz puede probar muchas contraseñas en una sola petición, lo que esquiva los límites simples por petición. Si no usas la aplicación móvil, las funciones de Jetpack u otras herramientas que dependan de XML-RPC, bloquéalo o desactívalo. Muchos sitios nunca lo necesitan.

Los nombres de usuario son más fáciles de encontrar de lo que crees

WordPress puede revelar nombres de usuario a quien los pida. Una petición como /?author=1 redirige a una página de autor que contiene el nombre de acceso, y la API REST lista los usuarios en /wp-json/wp/v2/users. Los atacantes usan ambas para construir una lista antes de empezar a adivinar. Da a cada cuenta un nombre público distinto de su nombre de acceso y valora restringir el listado de usuarios si ningún tema o plugin necesita que sea público.

Lo que no ayuda de verdad

Renombrar wp-login.php u ocultar la página de acceso solo detiene a los bots más burdos, que no comprueban más que la dirección por defecto. Es un pequeño obstáculo y no una protección, y quedan otras puertas como XML-RPC. Vale como capa adicional, no como plan.

Cómo saber si te están atacando

Mira el registro de acceso de tu servidor: muchas peticiones POST a wp-login.php desde direcciones IP variadas. Desde la línea de comandos, esto lista las fuentes más activas:

grep "POST /wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Un pico breve es ruido de fondo normal en internet. Un patrón sostenido y de gran volumen merece actuar. Mira también el otro extremo: un acceso correcto desde una dirección desconocida, o un administrador que no creaste, significa que un intento tuvo éxito. En ese caso sigue la comprobación de hackeo en cinco minutos.