Mitigar ataques DDoS en WordPress con medidas reales

Qué significa mitigar ataques DDoS en WordPress

Para mitigar ataques DDoS en WordPress no basta con instalar un plugin y esperar que el problema desaparezca. Lo que mejor funciona en la práctica es combinar protección perimetral, caché, reglas de limitación de peticiones, ajustes del servidor y coordinación con el hosting para reducir la superficie de ataque y absorber parte del tráfico malicioso antes de que llegue a PHP, MySQL o al panel de administración.

Un ataque DDoS en WordPress es un intento de saturar la disponibilidad del sitio mediante un volumen anómalo de tráfico o peticiones. En la mayoría de casos, WordPress no es el origen del problema: la aplicación simplemente sufre la saturación de red, de capa HTTP o de recursos del servidor.

Conviene distinguir cuatro escenarios. La saturación de red L3-L4 afecta a IP, puertos o conexiones antes incluso de que WordPress responda. Los ataques HTTP/L7 envían muchas solicitudes aparentemente válidas contra URLs, búsquedas o páginas no cacheadas. La fuerza bruta o abuso de login se concentra en wp-login.php o xmlrpc.php. Y un pico legítimo puede venir de campañas, bots buenos o tráfico viral sin intención maliciosa.

Cómo detectar si tu web sufre un DDoS o un pico legítimo de tráfico

La primera señal no siempre es una caída total. A veces aparecen respuestas lentas, errores 502 o 524, consumo elevado de CPU, muchas conexiones simultáneas o picos repentinos en el ancho de banda. La diferencia entre tráfico legítimo y tráfico hostil suele verse en los logs del servidor, el patrón de URLs y el origen de las peticiones.

• Si ves muchas peticiones repetidas a una misma ruta, con user agents extraños o desde rangos poco coherentes, puede haber automatización maliciosa.
• Si el tráfico crece tras una campaña, una mención en medios o una indexación fuerte de bots legítimos, quizá necesitas más caché y capacidad, no un bloqueo agresivo.
• Si el servidor apenas recibe peticiones HTTP pero la conectividad ya falla, el problema puede estar en red o en el proveedor.

En una operativa habitual en España, lo más útil es revisar métricas del CDN o del hosting, acceder a logs de acceso y error, activar alertas básicas y comparar el comportamiento actual con el histórico de tráfico normal del sitio si tu web en WordPress no carga.

Medidas perimetrales que sí ayudan: CDN, WAF y protección en red

La protección DDoS con más impacto real suele estar fuera de WordPress. Un CDN con capacidad de absorción de tráfico ayuda a servir contenido cacheado desde el borde y a descargar el servidor de origen. Un WAF WordPress gestionado puede filtrar peticiones sospechosas, aplicar rate limiting y bloquear patrones típicos de capa 7.

Para ataques L3-L4, la mitigación depende sobre todo de la infraestructura del proveedor de red, del hosting o de un servicio especializado. Para ataques HTTP/L7, el WAF, la caché a nivel perimetral y las reglas de firewall bien ajustadas suelen ser mucho más eficaces que cualquier plugin aislado.

Qué conviene pedir o activar

• CDN con caché de recursos estáticos y, si encaja, caché de HTML para páginas públicas.
• WAF gestionado con limitación de peticiones por IP, país, ASN o patrón de URL.
• Protección específica para wp-login.php, API y rutas sensibles.
• Canal claro de escalado con el hosting para blackholing, scrubbing o ajuste temporal de reglas.

Ajustes en servidor y WordPress para reducir el impacto

Aunque no sustituyen la protección de red, los ajustes locales ayudan a que el sitio degrade mejor bajo presión. Aquí sí entra en juego el hardening WordPress y la optimización del servidor.

• Cachea todo lo cacheable: páginas públicas, objetos y recursos estáticos.
• Limita XML-RPC si no se usa, o desactívalo por completo cuando no sea necesario.
• Protege el login con rate limiting, MFA, cambio de rutas si procede y bloqueo de intentos abusivos a nivel WAF o servidor.
• Reduce el trabajo de PHP y base de datos en búsquedas, precargas, cron y plugins pesados.
• Aplica reglas en Nginx o Apache para cortar métodos, user agents o rutas claramente abusivas.

Un plugin de seguridad puede aportar visibilidad o controles básicos, pero no reemplaza un firewall WordPress perimetral, un CDN ni la capacidad de red del proveedor. Si el cuello de botella está antes del servidor, WordPress ni siquiera tendrá oportunidad de defenderse.

Qué errores empeoran la protección DDoS en WordPress

• Confiar solo en un plugin cuando el problema es de red o de capa 7.
• Desactivar caché por comodidad y obligar a que cada visita ejecute WordPress completo.
• Mantener xmlrpc.php expuesto sin necesidad.
• No revisar logs ni activar alertas, lo que retrasa el diagnóstico.
• Aplicar bloqueos masivos sin diferenciar entre bots buenos, tráfico viral y abuso real.
• No coordinarse con el hosting cuando el origen ya está saturado y aparecen errores 508 Resource Limit en WordPress.

Plan de respuesta: qué hacer durante y después del ataque

Durante el incidente

1. Confirma si el problema es L3-L4, HTTP/L7, abuso de login o un pico legítimo.
2. Activa modo estricto en CDN o WAF: rate limiting, desafíos y reglas temporales.
3. Protege login, API y rutas costosas; si hace falta, limita funciones no esenciales.
4. Escala con el hosting si hay saturación de red o de conexiones.

Después del incidente

1. Analiza logs, IPs, ASN, rutas y horas de mayor presión.
2. Ajusta reglas permanentes y mejora la caché a nivel perimetral.
3. Revisa el rendimiento del origen, la base de datos y los plugins críticos.
4. Documenta un procedimiento interno con contactos, umbrales y pasos de escalado.

Si buscas el mayor impacto real, prioriza CDN, WAF gestionado, caché, protección del login, limitación de peticiones y revisión de logs. Esa combinación suele mejorar mucho más la disponibilidad del sitio que cualquier medida aislada dentro de WordPress.

El error más común es confiar solo en plugins cuando el ataque se produce antes o por encima de la aplicación. Como siguiente paso razonable, conviene revisar la arquitectura de seguridad, validar qué parte cubre el hosting y, si el riesgo o el negocio lo justifican, pedir ayuda técnica especializada para diseñar una mitigación adaptada a tu infraestructura, incluida la reparación urgente de WordPress caído.