Cómo proteger WordPress contra ataques DDoS

Qué supone un ataque DDoS en WordPress

Un ataque DDoS busca agotar recursos mediante un gran volumen de peticiones o conexiones. En WordPress esto puede manifestarse como una web que carga muy lenta, errores 502 o 503, panel de administración inaccesible, bloqueo del acceso a usuarios legítimos o consumo excesivo de CPU, memoria y procesos PHP. No siempre implica una intrusión ni malware, pero sí puede convertirse en una incidencia seria de disponibilidad.

El encaje típico en WordPress es una mezcla entre seguridad perimetral y estabilidad del entorno. Algunas campañas golpean directamente la capa HTTP y fuerzan páginas dinámicas, otras abusan de rutas como wp-login.php, XML-RPC o búsquedas internas, y otras saturan DNS o el ancho de banda antes de que WordPress llegue a responder. En ámbito general, la gravedad real depende tanto del patrón del ataque como del nivel de protección del hosting, del CDN y de la configuración de caché.

• Un DDoS no siempre tira el sitio por completo, a veces lo vuelve errático y difícil de diagnosticar.
• WordPress sufre más cuando las peticiones fuerzan PHP, base de datos o procesos de login sin caché.
• La disponibilidad afecta a negocio, leads, soporte, SEO técnico y confianza del usuario.
• Un entorno con poco margen de recursos puede fallar antes incluso con un ataque moderado.
• La protección eficaz suele combinar red, DNS, CDN, servidor, aplicación y monitorización.

Diagnóstico inicial y señales útiles

El primer paso es confirmar si la caída o degradación se parece a un problema de tráfico hostil y no a un fallo interno aislado. Las señales más útiles suelen ser errores 502, 503 o 504, picos inusuales de CPU, memoria o procesos concurrentes, avisos del hosting por consumo de recursos, saturación de conexiones, incremento súbito de solicitudes a wp-login.php o xmlrpc.php, o picos de ancho de banda en un intervalo corto. También pueden aparecer alertas de uptime, incidencias de CDN o mensajes del proveedor sobre mitigación activada.

Conviene hacer comprobaciones prudentes que no empeoren el problema. No es buena idea instalar varios plugins de seguridad sobre la marcha, vaciar cachés sin criterio o cambiar DNS en plena incidencia sin datos. Es preferible observar logs de acceso y error, comparar el comportamiento desde distintas ubicaciones, comprobar si el panel de administración también falla y revisar qué cambios recientes se hicieron en WordPress, en el servidor o en el proxy inverso. Si hay Search Console u otras herramientas de monitorización, pueden ayudar a distinguir un ataque de una caída más clásica, aunque no son la fuente principal para DDoS.

• Revise errores visibles como 502, 503, 504, timeouts, conexión rechazada o panel inaccesible.
• Compruebe picos de CPU, RAM, IOPS, procesos PHP y conexiones simultáneas en el hosting.
• Busque cambios recientes en plugins, reglas de caché, DNS, WAF, PHP o configuración del servidor.
• Analice logs de acceso para detectar ráfagas repetidas por IP, ASN, país, user agent o ruta.
• Evite tocar demasiadas variables a la vez y conserve capturas, horas exactas y URLs afectadas.

Vectores habituales y cómo confirmarlos

No todos los ataques DDoS se comportan igual. En WordPress son habituales las oleadas de peticiones HTTP a la portada, a URLs dinámicas o a recursos que no están bien cacheados. También se ven abusos de wp-login.php, xmlrpc.php, comentarios, búsquedas internas, REST API y peticiones repetidas a páginas de carrito o checkout cuando el sitio usa WooCommerce. Cada vector consume recursos distintos y exige una respuesta técnica diferente.

La confirmación razonable pasa por observar patrones. Si miles de solicitudes van a la misma ruta con parámetros similares, puede tratarse de saturación de aplicación. Si el servidor apenas recibe tráfico útil pero el proveedor informa de ancho de banda disparado, puede haber un problema de red o capa inferior que su mitigación perimetral debe absorber. Si el tráfico llega a una ruta dinámica sin caché y cada petición lanza PHP y consultas SQL, el impacto en WordPress será mayor aunque el volumen no parezca gigantesco.

• Petición masiva a wp-login.php o xmlrpc.php para agotar PHP y autenticación.
• Ráfagas a búsquedas, filtros, API o endpoints sin caché que elevan CPU y base de datos.
• Tráfico automatizado a carrito, checkout o formularios que consume sesiones y recursos.
• Consultas con user agents extraños, orígenes muy distribuidos o parámetros repetitivos.
• Incrementos de ancho de banda o conexiones que apuntan a mitigación necesaria en red o CDN.

Seguridad, abuso de recursos y accesos expuestos

Aunque un DDoS no equivale a una infección, conviene revisar la seguridad del sitio porque algunos ataques aprovechan superficies expuestas o entornos ya debilitados. En WordPress, los síntomas relacionados pueden incluir intentos masivos de acceso, creación de usuarios sospechosos, cambios no autorizados, archivos alterados, spam en formularios o cron descontrolado. También influyen plugins vulnerables, credenciales filtradas, permisos inseguros y reglas del servidor demasiado permisivas.

Las medidas razonables pasan por asegurar copia previa, rotación de contraseñas, revisión de usuarios con privilegios, comprobación de integridad básica y hardening elemental. No se trata de generar alarmismo, sino de evitar que un problema de disponibilidad se mezcle con una exposición innecesaria. Si una ruta como XML-RPC no se usa, puede limitarse o bloquearse. Si el acceso a administración puede acotarse por IP o por doble factor, mejorará la resistencia. Y si existen plugins desactualizados o abandonados, conviene auditarlos con prioridad.

• Revise plugins y temas por vulnerabilidades conocidas, mantenimiento y necesidad real.
• Cambie contraseñas de WordPress, hosting, SFTP, base de datos y panel DNS si procede.
• Compruebe usuarios administradores, permisos de archivos y accesos anómalos recientes.
• Limite o desactive XML-RPC si no aporta valor operativo al proyecto.
• Implemente hardening básico, autenticación reforzada y revisión periódica del entorno.

Rendimiento y estabilidad durante un DDoS

La mejor defensa no es solo bloquear tráfico, sino reducir el coste de cada petición legítima y no legítima. En WordPress esto implica servir cuanto más contenido cacheado mejor, minimizar rutas dinámicas innecesarias, optimizar consultas, reducir el peso de plugins y aprovechar CDN o caché de servidor cuando el proyecto lo permite. Un sitio que ya funciona al límite caerá antes ante un pico de tráfico anómalo.

También importa la estabilidad del stack técnico. Versiones de PHP adecuadas, límites de procesos bien ajustados, caché de página y de objetos cuando procede, reglas de rate limiting en servidor o proxy, y una correcta separación entre tráfico cacheable y sesiones críticas ayudan a mantener servicio. En WordPress con WooCommerce o áreas privadas hay que equilibrar protección y funcionalidad para no romper compras ni accesos de usuarios reales.

• Active cachés coherentes para páginas públicas y revise exclusiones en rutas dinámicas.
• Reduzca carga innecesaria de plugins, consultas lentas y tareas cron mal ajustadas.
• Aplique rate limiting en Nginx, proxy o WAF para patrones repetitivos de abuso.
• Separe tráfico estático de tráfico dinámico mediante CDN y reglas específicas.
• Monitorice tiempos de respuesta, procesos y errores para validar mejoras sin adivinar.

Plugins, temas y actualizaciones con enfoque preventivo

En protección frente a DDoS, los plugins y temas no deben tratarse como una solución aislada. Algunos añaden funciones útiles de limitación, firewall o registro, pero otros consumen recursos, solapan reglas o generan conflictos con caché y CDN. Antes de instalar o cambiar algo conviene valorar el impacto real en el flujo de peticiones y probarlo en staging si es posible, especialmente si el sitio tiene tráfico, formularios o comercio electrónico.

Las buenas prácticas incluyen control de cambios, copia previa, entorno de pruebas, revisión de compatibilidades y despliegue gradual. Si tras una actualización aparecen caídas o falsos positivos, hay que identificar qué se modificó, revertir de forma ordenada y comparar cabeceras, reglas y comportamiento de caché. Un conflicto entre plugin de seguridad, plugin de caché y CDN es más común de lo que parece, y puede bloquear usuarios legítimos o disparar peticiones al origen.

• Pruebe ajustes de seguridad y caché en staging antes de aplicarlos en producción.
• Mantenga un registro de versiones, fecha de actualización y motivo del cambio.
• Revise compatibilidades entre plugin de seguridad, caché, CDN y funcionalidades críticas.
• Si una actualización coincide con la incidencia, compare antes de desactivar indiscriminadamente.
• Retire plugins redundantes o abandonados que añaden complejidad y consumo de recursos.

Hosting, DNS y correo en España

El comportamiento de un ataque DDoS depende mucho del proveedor. En España, como en otros mercados, hay diferencias claras entre hostings compartidos, VPS, cloud gestionado y configuraciones con CDN o WAF externo. Algunos entornos ofrecen mitigación perimetral básica, otros solo reaccionan cuando el consumo desborda límites internos. Por eso conviene confirmar qué cubre realmente el servicio: protección de red, filtrado HTTP, rate limiting, caché de servidor, tiempos de respuesta del soporte y acceso a logs.

Además del hosting, hay que revisar DNS, SSL, versión de PHP, límites de recursos, cachés de servidor y correo transaccional. Un cambio DNS precipitado puede prolongar la incidencia si no se planifica. Un certificado mal renovado o una caché desalineada puede confundirse con una caída. Y si el servidor comparte recursos para web y correo, un episodio de saturación puede afectar también a formularios, avisos de pedidos o notificaciones del sitio. Esto puede variar según proveedor, registrador o arquitectura concreta, por lo que la validación debe hacerse caso por caso en España.

• Confirme si su hosting ofrece mitigación DDoS en red, WAF, CDN o solo límites internos.
• Revise DNS, proxy, TTL, SSL y resolución de dominio antes de cambiar configuraciones críticas.
• Compruebe versión de PHP, workers, memoria, procesos y límites de conexión disponibles.
• Valide cachés de servidor y exclusiones para login, administración, carrito y checkout.
• Compruebe si el correo transaccional se ve afectado por la saturación del mismo entorno.

Pruebas, accesos y documentación técnica

Sin evidencias, es fácil confundir un DDoS con una mala actualización, un problema de DNS o un cuello de botella interno. Por eso conviene reunir accesos mínimos y documentación técnica antes de aplicar medidas fuertes. La trazabilidad acelera el diagnóstico, permite coordinarse con hosting o proveedor CDN y evita cambios impulsivos difíciles de revertir.

En una revisión técnica, lo habitual es pedir acceso de lectura o exportación a logs, listado de plugins, capturas de errores, configuración de DNS y una copia verificable del sitio si fuera necesaria. En ataques de disponibilidad resulta especialmente útil relacionar hora, URL, respuesta del servidor y cambio reciente. Cuanto mejor se documenta, menos tiempo se pierde probando hipótesis en producción.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, tema en uso y changelog interno.
• Evidencias técnicas: logs de acceso y error, capturas, URLs afectadas, horas exactas y códigos de respuesta.
• Copias de seguridad disponibles, export de base de datos y posibilidad de restauración controlada.
• Accesos a panel de hosting, CDN, DNS, certificados, monitorización y alertas del proveedor.
• Informes de seguridad, reglas activas, listas de bloqueo y detalle de mitigaciones ya aplicadas.

Plan de contención y mitigación ordenado

Ante un posible DDoS, el orden de trabajo importa tanto como la medida concreta. Lo sensato suele ser contener primero, preservar evidencias y mantener el mayor servicio posible para usuarios legítimos. Después se analiza qué capa falla, se corrige lo que proceda y se verifica con monitorización si la mitigación realmente funciona. Este enfoque reduce improvisación y minimiza tiempos de caída.

Un plan razonable para WordPress empieza por confirmar el alcance, activar protección perimetral o endurecer la existente, asegurar copia, recoger logs, limitar rutas abusadas y revisar recursos del servidor. A continuación se validan plugins, cachés, DNS y configuración del origen. Tras la corrección, debe medirse el resultado y dejar monitorización reforzada, porque algunos ataques regresan con otra forma o se desplazan a otros endpoints.

• Contenga el tráfico hostil con CDN, WAF, rate limiting o ayuda del hosting antes de tocar WordPress.
• Haga o verifique copia y preserve logs para no perder información diagnóstica.
• Identifique la capa afectada: red, DNS, proxy, servidor web, PHP, base de datos o aplicación.
• Corrija rutas expuestas, reglas de caché, límites de acceso y componentes vulnerables.
• Verifique con pruebas reales y deje monitorización posterior para detectar recaídas.

Si ya se ha tocado algo o hay urgencia

Es frecuente llegar a la incidencia cuando ya se han hecho cambios con buena intención: instalar un plugin de seguridad, restaurar una copia parcial, mover el sitio de hosting, tocar functions.php, borrar un plugin crítico o intentar una limpieza manual sin copia. En estos casos, el riesgo principal es perder evidencia técnica o introducir un segundo problema que complique el primero. Por eso conviene parar, documentar y reconstruir la secuencia de cambios.

Si se ha aplicado una medida urgente, no significa que sea incorrecta, pero debe validarse. Un plugin de seguridad puede bloquear usuarios legítimos, una restauración parcial puede dejar base de datos y archivos desalineados, un cambio de hosting puede mover la incidencia al DNS o al SSL, y una edición directa de functions.php puede provocar errores fatales. Antes de seguir tocando, conviene congelar cambios no esenciales, guardar estado actual, comparar con copias y revisar logs para no tapar la causa de fondo.

• Documente qué se hizo, quién lo hizo, a qué hora y con qué resultado observable.
• No elimine logs, reglas ni copias antiguas sin revisar si contienen evidencia útil.
• Si se restauró una copia parcial, compruebe coherencia entre archivos, base de datos y DNS.
• Si se editó functions.php o se borró un plugin crítico, priorice recuperar estabilidad básica.
• Si hubo un cambio de hosting o CDN, valide propagación, SSL, caché y origen real del tráfico.

Preguntas frecuentes

Estas dudas son habituales cuando un sitio WordPress sufre picos de tráfico anómalo o caídas intermitentes. La respuesta correcta depende del entorno, pero hay criterios prácticos que ayudan a decidir.

P: ¿Un plugin de seguridad basta para frenar un ataque DDoS?

R: Normalmente no por sí solo. Puede ayudar en capa de aplicación, pero muchos ataques deben filtrarse antes de llegar al origen, mediante CDN, WAF, rate limiting o mitigación del proveedor.

P: ¿Debo bloquear XML-RPC en WordPress?

R: Si no se utiliza para ninguna función necesaria, limitarlo o bloquearlo suele ser una medida razonable. Debe comprobarse antes para no afectar integraciones legítimas.

P: ¿Cómo distingo un DDoS de una simple falta de recursos?

R: La diferencia suele verse en los patrones de logs y métricas. Un DDoS muestra picos y repeticiones anómalas por rutas, orígenes o conexiones, mientras que un problema interno suele relacionarse más con consultas lentas, tareas programadas o cambios recientes.

P: ¿Conviene cambiar de hosting en plena incidencia?

R: Solo si hay un motivo técnico claro y un plan controlado. Migrar con prisas puede añadir problemas de DNS, SSL, correo o caché y dificultar la lectura de la causa original.

P: ¿Qué debería guardar antes de aplicar cambios importantes?

R: Copia del sitio, exportación de base de datos, logs de acceso y error, capturas de fallos, horas exactas, listado de plugins y detalle de cualquier cambio reciente en WordPress, DNS, CDN o hosting.