Protección contra fuerza bruta en WordPress: qué hace un plugin

Un plugin de seguridad es bueno para frenar el adivinado de contraseñas. No puede detener una avalancha de tráfico. La protección contra fuerza bruta en WordPress y la protección contra DDoS son problemas distintos, y cada uno se resuelve en una capa diferente: sus cuentas, WordPress, el servidor web y el perímetro de red que hay delante.

Este artículo repasa los ataques que probablemente vea en sus registros: inicios de sesión fallidos en wp-login.php, ráfagas de peticiones a xmlrpc.php, enumeración de usuarios a través de la API REST y picos de tráfico. Para cada uno indica la capa que realmente puede pararlo. Y cada medida lleva una línea sobre lo que no hace.

La protección contra fuerza bruta en WordPress funciona por capas

El tráfico llega desde internet y atraviesa varias capas antes de tocar sus datos. Cuanto más lejos se frena una petición, menos le cuesta. Una petición rechazada en una CDN nunca llega a su servidor. Una rechazada por un plugin de WordPress ya ha consumido una conexión de red, un proceso del servidor web y un worker de PHP.

Un esquema aproximado:

Limitar los intentos de login: frenar el adivinado en wp-login.php

La limitación de intentos cuenta los fallos y responde con retrasos crecientes, un bloqueo temporal del origen o un desafío (CAPTCHA, por ejemplo). WordPress, de serie, no tiene ningún límite. Un atacante puede probar contraseñas contra wp-login.php tan rápido como responda su servidor.

Los límites por IP funcionan bien contra una única fuente ruidosa. Funcionan peor contra una botnet que reparte los intentos entre miles de direcciones, cada una por debajo de su umbral. Por eso conviene limitar también por nombre de usuario. Veinte fallos contra la cuenta «admin» desde veinte IP distintas siguen siendo un patrón.

El límite por usuario trae su propia trampa. Un bloqueo duro permite que cualquiera deje fuera a su administrador real fallando a propósito. Los retrasos crecientes o un desafío son más prudentes que un bloqueo total.

Dos cosas deciden si la limitación ayuda o perjudica:

• La IP del cliente. Detrás de una CDN o de un proxy inverso, todas las peticiones pueden parecer venir de la dirección del proxy. Un plugin que solo vea esa dirección limitará a todos sus visitantes a la vez. El error contrario es igual de malo: si el plugin se fía de la cabecera X-Forwarded-For de cualquiera, los atacantes pueden falsificar una IP nueva en cada petición y no los bloqueará nunca. Configure el plugin, o el módulo real-IP del servidor web, para aceptar cabeceras reenviadas solo desde los rangos de IP de su proxy.
• Su propia vía de vuelta. Añada su IP de oficina a la lista de permitidos si es fija, y conozca su vía de recuperación antes de necesitarla.

Lo que la limitación no hace: no convierte en segura una contraseña débil o reutilizada. Una contraseña de una lista de filtraciones puede funcionar al primer intento. La solución de fondo es un segundo factor en toda cuenta con privilegios elevados, configurado como se explica en autenticación en dos pasos para administradores de WordPress.

XML-RPC: por qué system.multicall convierte una petición en muchos intentos

xmlrpc.php está activado por defecto en WordPress. Es una interfaz antigua de publicación remota, y uno de sus métodos, system.multicall, ejecuta muchas llamadas dentro de una sola petición HTTP. Un atacante puede meter una lista larga de pares usuario/contraseña en un único POST.

Eso esquiva la protección de login que solo vigila wp-login.php o cuenta peticiones. Una línea en su registro puede significar cientos de intentos. Asegúrese de que su limitación cuenta los fallos de autenticación por XML-RPC, o elimine por completo esa superficie de ataque.

Los pingbacks de XML-RPC también pueden usarse de forma abusiva para que su sitio envíe peticiones a terceros. Es otra razón para desactivarlos si nada los necesita.

Antes de desactivar XML-RPC: compruebe qué lo sigue usando

Algunas herramientas legítimas todavía hablan con xmlrpc.php. Entre los candidatos: herramientas antiguas de blogging de escritorio y de publicación remota, configuraciones antiguas de apps móviles, algunos plugins conectores e integraciones creadas hace años. La conexión de Jetpack ha dependido históricamente de XML-RPC, así que consulte su documentación actual si lo utiliza.

Mire primero sus registros de acceso. En un servidor Apache o nginx típico con el formato de log combinado:

# ¿Qué IP envían peticiones POST a xmlrpc.php?
grep "POST /xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# ¿Qué user agents?
awk -F'"' '/POST \/xmlrpc.php/ {print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Ajuste la ruta a su servidor (por ejemplo /var/log/apache2/access.log) e incluya los logs rotados. Miles de peticiones desde IP cambiantes con user agents genéricos son ataques. Un puñado de peticiones desde la IP de un servicio conocido probablemente pertenece a una integración: pregunte a su agencia o al proveedor antes de cortarla.

Tiene dos opciones:

1. **El filtro xmlrpc_enabled.** Desactiva los métodos XML-RPC que requieren autenticación, lo que frena el adivinado de contraseñas vía XML-RPC. Los métodos sin autenticación, como los pingbacks, siguen funcionando. Consulte la referencia para desarrolladores de WordPress.
2. Bloquear el archivo en el servidor. Esto lo detiene todo, y PHP ni siquiera se ejecuta para esas peticiones.

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

location = /xmlrpc.php {
    deny all;
}

Tras el cambio, pruebe la publicación, su app y cualquier servicio conectado. Anote qué ha cambiado y por qué, para que la siguiente persona no lo «arregle» deshaciéndolo.

Enumeración de usuarios por la API REST y límite de peticiones anónimas

/wp-json/wp/v2/users lista a los usuarios que han publicado contenido, con sus slugs. /?author=1 redirige a un archivo de autor que revela el slug en la URL. Los slugs suelen coincidir con el nombre de usuario de acceso, lo que le regala al atacante la mitad de las credenciales.

Restringir el endpoint de usuarios para visitantes anónimos y bloquear los escaneos de autores reduce el ruido de reconocimiento. Pero los nombres de usuario no son secretos. Ocultarlos no es, por sí solo, un control de seguridad.

Limitar la tasa de peticiones REST anónimas ayuda contra el scraping y el sondeo automatizado. Aplíquelo solo al tráfico anónimo y pruebe después. El editor de bloques usa la API REST para los usuarios con sesión iniciada, y las integraciones se autentican con contraseñas de aplicación (incluidas en el núcleo desde WordPress 5.6). Un límite que las afecte romperá la edición o una tarea de sincronización de formas difíciles de rastrear.

Lo que no hace: limitar la tasa no corrige un endpoint REST vulnerable en un plugin. Solo ralentiza los intentos de explotarlo.

Por qué un plugin no puede detener un ataque DDoS

Un plugin es código PHP. Solo se ejecuta cuando la petición ya ha cruzado la red, ha sido aceptada por el servidor web y entregada a un worker de PHP. Una inundación volumétrica satura su ancho de banda, sus límites de conexión o su pool de workers de PHP mucho antes de ese punto. Aunque el plugin rechace cada petición en un milisegundo, cada rechazo sigue ocupando un worker, y un servidor solo tiene unos cuantos.

Las inundaciones en la capa de aplicación son distintas. Son muchas peticiones costosas pero de apariencia válida, como búsquedas o páginas sin caché. Aquí ayuda algo limitar la tasa más cerca de la aplicación, pero solo hasta la capacidad del servidor.

La alerta de picos de tráfico de un plugin es útil porque le avisa de que algo está pasando. No absorbe nada. Cualquier producto que llame «protección DDoS» a un plugin de WordPress está exagerando.

Qué hace en su lugar una CDN o un firewall perimetral, y qué puede añadir el servidor web

Una CDN o un firewall perimetral se sitúa delante de su hosting, en una red mucho mayor que la suya. Puede absorber y filtrar inundaciones, aplicar límites de tasa y reglas anti-bots antes de que el tráfico le llegue, servir páginas en caché cuando su servidor flaquea y lanzar desafíos a las peticiones a wp-login.php y xmlrpc.php. Una vez configurada, blinde el origen: permita en el firewall de su servidor solo los rangos de IP de la CDN. Si no, los atacantes pueden rodear la CDN e ir directos a la dirección real de su servidor.

En el servidor web, el [módulo limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html) de nginx puede limitar los intentos de login antes de que arranque PHP. Detrás de una CDN o de un proxy inverso, configure antes el módulo real-IP (confiando solo en los rangos de su proxy); si no, $binary_remote_addr es la dirección del proxy y todos los visitantes comparten un único límite:

# contexto http
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

# contexto server
location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    # mantenga aquí sus líneas fastcgi_pass / include existentes
}

fail2ban adopta otro enfoque. Lee sus registros y bloquea en el firewall a los reincidentes, lo que es más barato que responderles desde PHP. Detrás de una CDN no funciona tal cual: el firewall del servidor solo ve las direcciones de la CDN, de modo que los bloqueos deben hacerse en la CDN (o a través de su API). En un hosting gestionado, pregunte qué protección de red ofrece ya su proveedor.

También aquí hay límites. Un firewall perimetral no corrige contraseñas débiles ni plugins vulnerables. Tampoco ayuda con lo que un atacante puede hacer una vez dentro, tema de desactivar el editor de archivos de WordPress.

Orden de implantación para pymes europeas

1. Contraseñas robustas y únicas y 2FA para todos los administradores y editores.
2. Limitación de login con límites por IP y por usuario, detección correcta de la IP del cliente y una vía de recuperación probada.
3. La decisión sobre XML-RPC: revise los registros y use después el filtro o un bloqueo en el servidor.
4. Restricciones a la enumeración de usuarios y límites a las peticiones REST anónimas.
5. Una CDN o un firewall perimetral con el origen blindado, para los sitios en los que una caída cuesta dinero.

Esto también cuenta a efectos de cumplimiento. El art. 32, apartado 1, letra b), del RGPD exige garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas (RGPD en EUR-Lex). Para las entidades incluidas en el ámbito de la Directiva NIS2, el art. 21, apartado 2, letra j), enumera la autenticación multifactor entre las medidas mínimas (NIS2 en EUR-Lex). Consulte la normativa nacional de transposición de NIS2 de su país para los detalles.

El plugin Security Audit & Compliance de secaudit.eu ofrece limitación de intentos de login, desactivación de XML-RPC, límite de tasa para peticiones REST anónimas y alertas de picos de tráfico. No es protección contra DDoS; para eso use una CDN o un firewall perimetral. → secaudit.eu

Siguiente paso: repase el resto de la lista de comprobación de seguridad de WordPress. Si sus registros ya muestran inicios de sesión correctos que no reconoce, vaya mejor a las señales de un sitio hackeado.

FAQ

¿Romperá Jetpack o mi app si desactivo XML-RPC?

Puede ser. Busque en sus registros clientes XML-RPC legítimos y consulte la documentación actual del proveedor. El filtro xmlrpc_enabled es la opción más suave; el bloqueo en el servidor, la más estricta. Pruebe tras cualquiera de los dos cambios.

¿Cambiar el nombre de wp-login.php detiene la fuerza bruta?

Reduce el ruido de los bots simples, pero no es un control de seguridad. Los atacantes pueden encontrar igualmente la página de login o usar XML-RPC. Utilice también limitación de intentos y 2FA.

¿Basta mi plugin de seguridad durante un DDoS?

No. Contacte con su proveedor de hosting o de CDN. Lo que mantiene el sitio accesible es el filtrado en el perímetro y la caché.

¿Me bloqueará la limitación de intentos a mí?

Puede, si la IP del cliente se detecta mal o si se equivoca varias veces con su contraseña. Añada su IP a la lista de permitidos y tenga a mano WP-CLI o SFTP para desactivar el plugin.

Este artículo es información general y no constituye asesoramiento jurídico.