Ataques de fuerza bruta en WordPress: wp-login.php, xmlrpc.php y cómo frenarlos

Qué es un ataque de fuerza bruta

Es un programa que prueba combinaciones de usuario y contraseña, una detrás de otra, hasta que acierta. No va a por tu web en concreto: recorre miles de webs WordPress a la vez desde muchas direcciones distintas. Por eso casi todas las webs lo reciben, y por eso la defensa no consiste en esconderse, sino en que acertar sea imposible.

Los dos puntos de entrada son siempre los mismos:

• wp-login.php, la pantalla de acceso normal.
• xmlrpc.php, una interfaz antigua para publicar desde aplicaciones externas. Es un objetivo frecuente porque admite muchas pruebas de contraseña en una sola petición (el método system.multicall), así que el ataque va más rápido y los límites de intentos por petición no lo ven.

Cómo saber si lo estás recibiendo

Si tienes un plugin de seguridad, su registro de accesos fallidos lo muestra. Si no, el registro de accesos del servidor (en el panel del hosting suele llamarse «Logs» o «Registros sin procesar»). Con acceso SSH, estos comandos solo leen y cuentan:

# Cuántas peticiones POST han llegado a cada archivo
grep -c "POST /wp-login.php" access.log
grep -c "POST /xmlrpc.php" access.log

# Desde qué direcciones llegan más intentos
grep -E "POST /(wp-login|xmlrpc)\.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Cientos o miles de peticiones al día desde muchas direcciones es el patrón típico. Lo que sí sería grave es un acceso correcto al panel desde una dirección o un país que no reconoces, o un administrador nuevo que nadie ha creado. Si ves eso, no es solo un intento: sigue la guía de cómo saber si tu WordPress está hackeado.

El análisis gratuito comprueba desde fuera si xmlrpc.php responde, si la web muestra los nombres de usuario y si la pantalla de acceso tiene algún límite.

Lo que lo frena, por orden de importancia

1. Contraseñas largas y únicas

Es lo que decide si el ataque funciona. Una contraseña larga, generada por un gestor de contraseñas y que no uses en ningún otro sitio, no la acierta un robot. Revisa sobre todo a los administradores y editores antiguos: la cuenta de la agencia que hizo la web, la de un empleado que ya no está. Las que no se usan, bórralas o bájalas de rol.

2. Verificación en dos pasos para los administradores

WordPress no la incluye de serie. La añade un plugin: el gratuito Two Factor, mantenido por colaboradores de WordPress, o la que traen Wordfence y Solid Security. Con un código de una aplicación en el móvil, aunque alguien adivine la contraseña no puede entrar. Actívala al menos en todas las cuentas con rol de administrador.

3. Límite de intentos, mejor fuera de WordPress

Un plugin de seguridad puede bloquear una dirección tras varios fallos, y es suficiente para la mayoría. Pero cada intento sigue llegando a PHP. Si el ataque es fuerte, el límite funciona mejor antes: en el cortafuegos de tu CDN o de tu hosting, o en el propio servidor. La documentación de WordPress propone, por ejemplo, limitar las peticiones a wp-login.php y xmlrpc.php en Nginx con limit_req.

4. Bloquear xmlrpc.php si no lo usas

Hoy casi nada lo necesita, pero antes de bloquearlo comprueba que no lo usa nada tuyo: Jetpack, alguna aplicación móvil o un servicio externo que publique en tu web. Si lo usas, mejor limitarlo que bloquearlo. Si no, en Apache (en el .htaccess de la raíz):

<Files xmlrpc.php>
  Require all denied
</Files>

En Nginx, dentro del bloque server de la web:

location = /xmlrpc.php {
  deny all;
}

Hay una tercera opción que verás en muchos tutoriales: el filtro xmlrpc_enabled. Ojo, porque a pesar del nombre no apaga XML-RPC entero: solo desactiva los métodos que piden usuario y contraseña. Corta la fuerza bruta por esa vía, pero el archivo sigue respondiendo (por ejemplo, a los pingbacks). Si quieres cerrarlo del todo, la regla del servidor es más limpia.

5. Que no se vean los nombres de usuario

Con el usuario adivinado, al atacante solo le falta la contraseña. Muchas webs WordPress muestran el nombre de acceso en las páginas de autor o en la API REST. Lo más sencillo es que el nombre visible sea distinto del de acceso: en Usuarios → Perfil, rellena el apodo y elige otro en «Mostrar este nombre públicamente». Y nunca uses admin como usuario. Esto ayuda, pero no sustituye a los puntos 1 y 2.

6. Contraseñas de aplicación para las integraciones

Si un servicio externo necesita publicar en tu web, usa una contraseña de aplicación (en tu perfil de usuario, desde WordPress 5.6) en lugar de tu contraseña real. Se puede revocar en cualquier momento sin tocar tu acceso.

Si sospechas que alguien ha entrado

1. Cambia la contraseña de todos los administradores desde un ordenador limpio.
2. Regenera las claves de seguridad de wp-config.php: cierra todas las sesiones abiertas.
3. Revisa Usuarios filtrando por administrador y borra lo que no reconozcas.
4. Revisa plugins, archivos .php en uploads y redirecciones, con la guía de cómo saber si tu WordPress está hackeado.

Si encuentras algo, la limpieza de WordPress hackeado cuesta 219 € (IVA no incluido), con 90 días de garantía. Si solo quieres dejar los accesos bien cerrados (verificación en dos pasos, usuarios, xmlrpc.php y límites), eso entra en la puesta a punto de la seguridad WordPress, y en el mantenimiento WordPress lo vigilo cada semana.

Fuentes

• WordPress: ataques de fuerza bruta (xmlrpc.php y system.multicall como objetivo frecuente, 2FA que el núcleo no trae, límite de intentos en el servidor o el cortafuegos y ejemplos para Apache y Nginx).
• WordPress: filtro xmlrpc_enabled (solo controla los métodos que requieren autenticación, no los pingbacks).
• WordPress: guía de las contraseñas de aplicación (WordPress 5.6, revocables por separado).
• Plugin Two Factor en WordPress.org (códigos de aplicación, correo y códigos de respaldo).
• Apache: control de acceso (Require all denied) y nginx: módulo de acceso (deny all).
• OWASP: ataque de fuerza bruta.