WordPress mueve una gran parte de la web, lo que lo convierte en el objetivo por defecto de los ataques automatizados. También es inusualmente fácil de sobrecargar: una sola petición sin cachear puede disparar decenas de consultas a la base de datos, así que una inundación que un sitio estático ignoraría puede tumbar un origen WordPress con unos pocos cientos de peticiones por segundo.
Los tres endpoints que reciben los golpes
- xmlrpc.php — la interfaz heredada de publicación remota. Soporta el agrupamiento de peticiones, lo que la convierte en un amplificador: una petición HTTP puede llevar muchas operaciones.
- wp-login.php — el formulario de login, objetivo tanto para credential stuffing como para forzar peticiones sin cachear y pesadas en base de datos de forma barata.
- URLs de búsqueda y de archivos filtrados — cada cadena de consulta única salta la caché de página y llega a PHP y a la base de datos.
Por qué la caché por sí sola no es protección
Una caché de página solo ayuda cuando el atacante pide URLs cacheables. Añadir una cadena de consulta aleatoria a cada petición la derrota, que es justo lo que hacen las inundaciones automatizadas.
Las capas que importan, en orden
Empieza en el edge y avanza hacia dentro. Filtrar delante del origen es la única capa que mantiene el tráfico de inundación completamente fuera del servidor; todo lo demás es control de daños sobre tráfico que ya llegó.
- Filtrado en el edge con un desafío de navegador, para que los clientes automatizados nunca lleguen a PHP durante un ataque.
- Límites de tasa por dirección que sean estrictos en login y búsqueda, y laxos en los activos estáticos.
- Desactiva xmlrpc.php si no lo usas, o restríngelo a las direcciones que lo necesitan.
- Una caché de página completa con una política sensata para las cadenas de consulta, para que los parámetros de cache-busting no se conviertan en un camino libre a la base de datos.
- Un pool de workers de PHP ajustado: suficientes workers para usar la máquina, pocos como para que el agotamiento de memoria no tumbe el host entero.
Oculta el origen
La razón más común de que la protección en el edge falle en WordPress es que la dirección del origen sigue siendo pública. Se filtra por registros DNS antiguos, cabeceras de correo enviadas por el sitio, y subdominios que nunca se movieron detrás del proxy. Una vez que el tráfico se enruta por un proxy, el origen debería aceptar conexiones solo de las direcciones del proxy — una regla de firewall, no un ajuste de plugin.
Qué omitir
Los plugins de seguridad que bloquean direcciones desde dentro de PHP son, durante una inundación, simplemente otra escritura en base de datos por cada petición maliciosa. Son útiles contra ataques lentos de credenciales e inútiles contra el volumen. Lo mismo aplica a cualquier cosa que registre cada petición bloqueada en la misma base de datos desde la que el sitio intenta servir.