DDoS Layer 7 en WordPress: detectalo y frenalo ya

Un ataque DDoS de capa 7 contra WordPress no llega con banner ni aviso previo. Lo que ves primero es el sitio lento, después caído intermitente, y recién cuando revisás los logs te das cuenta que miles de requests simultáneos estaban martillando /wp-login.php hasta agotar PHP y MySQL. Este es el patrón que enfrentaron miles de sitios WordPress en 2026, y acá te explico cómo detectarlo, frenarlo y no volver a pasarla mal.

Qué es un ataque DDoS de capa 7 (application layer)

Un ataque DDoS de capa 7 es un ataque distribuido de denegación de servicio que opera en la capa de aplicación del modelo OSI, enviando peticiones HTTP o HTTPS que parecen legítimas pero que buscan agotar los recursos del servidor (CPU, memoria, conexiones a base de datos) en vez de saturar el ancho de banda.

La diferencia con un ataque de capa 3 o 4 es clave. En capa 3/4 el objetivo es inundar el link de red con paquetes UDP o ICMP, algo que el proveedor de hosting puede filtrar a nivel de infraestructura sin que llegue a tu aplicación. En capa 7, los paquetes llegan completos, la conexión TCP se establece y el servidor tiene que procesar cada request. WordPress inicia una nueva ejecución de PHP, consulta MySQL, carga plugins. Multiplicá eso por 10.000 requests por segundo y entendés por qué el servidor colapsa aunque haya 100 Mbps libres.

Los ataques de capa 7 crecieron un 118% interanual a principios de 2025 (hace aproximadamente 16 meses), según datos de la industria de ciberseguridad. Y WordPress, con el 43% de la web corriendo sobre él, concentra una porción desproporcionada de esos ataques.

Por qué WordPress es el blanco principal

Ponele que sos un atacante y querés armar un script automatizado. Con WordPress no tenés que adivinar nada: los endpoints son conocidos por cualquier persona que haya tocado el panel de administración una sola vez.

• /wp-login.php: formulario de login accesible sin autenticación previa. Ideal para ataques de credential stuffing.
• /xmlrpc.php: el más peligroso. Permite autenticarse por cada request y encima soporta llamadas en lote (multicall), lo que significa que con una sola petición HTTP podés probar cientos de combinaciones usuario/contraseña.
• /wp-admin/admin-ajax.php: maneja peticiones AJAX de plugins. Muchos plugins lo dejan expuesto sin rate limiting, y bajo carga genera queries pesadas a MySQL.
• /wp-json/: la REST API de WordPress. Si está abierta y sin throttling, puede revelar usuarios y procesar requests costosos.

XML-RPC merece párrafo aparte. Fue diseñado para permitir publicar desde aplicaciones de escritorio remotas. Hoy nadie lo necesita para eso, pero el archivo sigue activo por defecto en WordPress. Un atacante que encuentra xmlrpc.php activo tiene acceso a amplificación de fuerza bruta a escala industrial. ¿Cuántos sitios WordPress tienen xmlrpc.php activo sin saberlo? La mayoría.

Cómo detectar un ataque DDoS Layer 7 en tiempo real

Los síntomas son reconocibles si sabés qué buscar. El más común: el sitio carga muy lento o cae de forma intermitente sin que haya habido ningún cambio técnico de tu parte. Los errores 503 empiezan a aparecer. La memoria PHP se agota. MySQL reporta demasiadas conexiones. Relacionado: configurar un WAF especializado.

Lo primero que hacés es revisar los access logs del servidor. En Apache o nginx vas a ver algo como esto: la misma IP (o bloque de IPs correlacionadas) haciendo cientos de requests por segundo al mismo endpoint, con User-Agents idénticos o variaciones mínimas. Si ves 5.000 POST a /wp-login.php en los últimos 10 minutos desde tres rangos de IP distintos, eso no es tráfico legítimo.

Herramientas útiles para el diagnóstico:

• Dashboard de Cloudflare: si ya tenés el sitio detrás de Cloudflare, la pestaña de Analytics muestra picos de tráfico y amenazas bloqueadas en tiempo real.
• AbuseIPDB: para verificar si las IPs atacantes tienen historial de comportamiento malicioso.
• Sucuri SiteCheck: escaneo rápido para detectar si el sitio está en listas negras o tiene indicadores de compromiso.
• Query Monitor (plugin): si el sitio todavía responde aunque lento, Query Monitor te muestra qué queries están tardando más y qué requests están generando carga inusual.

Si el hosting te da acceso a métricas del servidor (CPU, RAM, conexiones MySQL), mirá los gráficos de las últimas horas. Un spike vertical que coincide con la lentitud es la confirmación que necesitás.

Configurar WAF y rate limiting: tres pasos inmediatos

Acá viene lo concreto. Cuando ya confirmaste que estás bajo ataque, estos son los pasos con mayor impacto inmediato.

Paso 1: activar el modo «Under Attack». Si usás Cloudflare, en el panel de tu dominio vas a Security > Settings y activás «I’m Under Attack Mode». Cloudflare agrega un challenge JavaScript a cada visitor antes de servir el contenido. Los bots que no ejecutan JS (la mayoría) quedan bloqueados. El impacto es casi inmediato.

Paso 2: configurar rate limiting por endpoint. Estos son los umbrales que funcionan en la práctica:

Paso 3: bloquear rangos IP identificados. Desde los logs anotás los rangos /24 de los atacantes y los bloqueás en el firewall de Cloudflare o directamente en el .htaccess (o en la configuración de nginx). Es manual y temporal, pero da alivio inmediato mientras configurás protección sistémica.

En cuanto a soluciones WAF con protección DDoS Layer 7: Sucuri Firewall cuesta USD 9.99/mes en su plan básico y ya incluye mitigación DDoS. Cloudflare Pro cuesta USD 20/mes y agrega reglas WAF avanzadas, rate limiting granular y bot management básico. Ambas son opciones reales para un sitio de tamaño mediano (no hace falta la versión enterprise para tener protección decente). Esto se conecta con lo que analizamos en las mejores defensas contra DDoS.

Desactivar y endurecer endpoints vulnerables

La mejor defensa contra un ataque que apunta a xmlrpc.php es que xmlrpc.php no exista (o al menos no responda). Podés desactivarlo completamente agregando esto en el .htaccess:

• Deshabilitar XML-RPC vía .htaccess: <Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
• Filtrar en wp-config.php: agregá add_filter('xmlrpc_enabled', '__return_false'); en functions.php o via snippet de código.
• Proteger wp-login.php: limitá el acceso a tu IP estática si trabajás siempre desde la misma red, o agregá autenticación HTTP básica al directorio.
• Deshabilitar pingbacks: en Ajustes > Discusión, destildá «Permitir notificaciones de enlace de otros blogs». Esto corta otro vector de amplificación.
• Ocultar la versión de WordPress: sacá la etiqueta de versión del header y del feed con remove_action('wp_head', 'wp_generator');.

Ojo con la REST API. Deshabilitar /wp-json/ por completo puede romper Gutenberg y varios plugins modernos que la usan internamente. Lo mejor es restringir qué endpoints son públicos, no bloquear todo el namespace.

Implementar caché agresivo como defensa

Un sistema de caché bien configurado puede ser la diferencia entre un servidor caído y un sitio que aguanta un ataque sin parpadear.

La lógica es simple: si la página ya está en caché, PHP y MySQL no se ejecutan. El servidor sirve un archivo estático. Multiplicá eso por el volumen del ataque y el impacto es enorme. Un sitio con caché de página puede manejar tráfico 10 a 20 veces mayor que uno sin caché, bajo las mismas condiciones de hardware.

Cloudflare y Sucuri cachean automáticamente las páginas estáticas en sus proxies cuando están configurados como CDN. El contenido se sirve desde servidores edge distribuidos globalmente, sin tocar tu servidor de origen. Para las páginas dinámicas (carrito, login, perfil), el caché no aplica, pero esas son exactamente las que deberías proteger con rate limiting.

Si usás donweb.com como hosting, el servidor ya tiene LiteSpeed, lo que facilita mucho la configuración del plugin LiteSpeed Cache. Con las reglas de caché por defecto y el modo «crawl optimizer» activado, el tiempo de respuesta bajo ataque mejora sustancialmente sin tocar la CDN.

Herramientas especializadas en Layer 7 para 2026

No todas las protecciones son iguales. Esto es lo que hace cada una en el contexto de un ataque DDoS capa 7 WordPress:

DataDome merece una mención aparte. Es una solución dedicada a detección de bots y mitigación de DDoS Layer 7 que toma decisiones en menos de 2 milisegundos usando modelos de machine learning entrenados sobre comportamiento de tráfico. Cada request se evalúa en tiempo real contra su base de datos de patrones maliciosos. Para un blog de seguridad de tráfico moderado puede ser overkill, pero para un e-commerce con WooCommerce bajo ataque constante, la diferencia es notable. Ya lo cubrimos antes en con plugins de seguridad confiables.

Cloudflare, con su plan gratuito, ya da bastante. El plan Pro agrega WAF con reglas OWASP y el modo «Under Attack» con CAPTCHA gestionado. El salto a Business (USD 200/mes) suma protección DDoS avanzada y bot management con ML. Para la mayoría de los sitios WordPress, Pro alcanza.

Plan de acción durante un ataque DDoS activo

Cuando el ataque ya está en curso, el orden importa. Acá el protocolo que funciona:

• Confirmá el ataque: revisá access logs buscando patrones de requests repetidos (mismo endpoint, mismo User-Agent, alta frecuencia). No confundas un pico de tráfico legítimo con un ataque.
• Activá «Under Attack Mode»: en Cloudflare o en el panel de Sucuri. Inmediato, de mayor impacto.
• Bloqueá rangos IP identificados: desde los logs, armá una lista de los /24 más activos y creá reglas de bloqueo en el firewall de la CDN.
• Contactá al hosting: si el ataque está saturando recursos del servidor a pesar del WAF, el hosting puede aplicar mitigación a nivel de red (null routing de IPs atacantes antes de que lleguen al servidor). Esto es clave si no tenés CDN configurada.
• Preservá los logs: no los borres. Los vas a necesitar para el análisis post-ataque, para identificar vectores y para reportar a servicios como AbuseIPDB.
• Verificá integridad después del ataque: algunos ataques Layer 7 se combinan con intentos de inyección. Una vez que el tráfico se normalizó, corré un escaneo de malware (Wordfence o Sucuri SiteCheck).

Subís el WAF, activás el modo Under Attack, bloqueás las IPs más activas, avisás al hosting, y de repente el tráfico empieza a normalizarse en los logs mientras los requests legítimos vuelven a recibir respuesta normal. Eso es lo que se siente cuando la defensa funciona (si es que «se siente» como algo en medio del stress de ver el sitio caído).

Errores comunes al enfrentar un ataque DDoS en WordPress

Error 1: desactivar Cloudflare durante el ataque para «ver si el problema está en el servidor». Exactamente lo contrario de lo que hay que hacer. Sin Cloudflare como proxy, el tráfico malicioso llega directo al servidor de origen. El sitio cae en segundos.

Error 2: instalar más plugins de seguridad mientras el servidor está bajo carga. Cada plugin activo agrega carga a PHP en cada request. Bajo un ataque Layer 7 activo, instalar Wordfence, Anti-Malware y dos plugins más al mismo tiempo puede ser el empujón final que colapsa la base de datos. Configurá primero el WAF externo (Cloudflare/Sucuri), que no agrega carga al servidor.

Error 3: no configurar rate limiting en admin-ajax.php por miedo a romper plugins. El argumento es que «varios plugins lo usan y si lo limito mucho algo se va a romper». El límite de 30 requests por IP por minuto que figura en la tabla más arriba es suficientemente generoso para cualquier interacción legítima de un usuario real. Ninguna persona hace 31 peticiones AJAX por minuto de forma legítima.

Error 4: creer que el problema se resuelve solo después de unas horas. Un ataque DDoS Layer 7 coordinado puede durar horas o días. Si no tomás medidas activas, el servidor va a seguir bajo presión. El «espero que se cansen» no es una estrategia de mitigación. Cubrimos ese tema en detalle en usando soluciones gratuitas disponibles.

Preguntas Frecuentes

¿Cómo sé si mi WordPress está siendo atacado por DDoS?

Los indicadores principales son: lentitud extrema o caídas intermitentes sin cambios técnicos recientes, errores 503 o «Error al conectar a la base de datos», picos de CPU o memoria en el hosting que no corresponden al tráfico habitual, y requests masivos a los mismos endpoints visibles en los access logs. Si revisás el log de acceso y ves cientos de POST a /wp-login.php desde el mismo rango de IPs en minutos, es un ataque.

¿Cuál es la diferencia entre DDoS capa 3/4 y capa 7?

Los ataques de capa 3 y 4 saturan el ancho de banda o las conexiones de red con paquetes malformados o en volumen masivo. Son más fáciles de detectar y filtrar a nivel de infraestructura. Los ataques de capa 7 envían peticiones HTTP/HTTPS completas y válidas que el servidor procesa normalmente, agotando CPU, memoria y conexiones a MySQL. Son más difíciles de distinguir del tráfico legítimo y requieren análisis de comportamiento para mitigarlos.

¿Cuánto cuesta proteger WordPress contra ataques DDoS?

El plan gratuito de Cloudflare ya da protección DDoS básica. Para protección Layer 7 con WAF y rate limiting granular, Cloudflare Pro cuesta USD 20/mes y Sucuri Firewall USD 9.99/mes. Wordfence Premium (USD 119/año) agrega protección on-premise sin CDN. Para sitios de alto tráfico o e-commerce, las soluciones dedicadas como DataDome tienen precios variables según volumen de tráfico.

¿Qué plugins de WordPress previenen ataques DDoS?

Ningún plugin por sí solo previene un DDoS Layer 7 grande porque todos corren dentro de PHP, que es lo que el ataque busca agotar. Wordfence agrega rate limiting y bloqueo de IPs, pero es más efectivo para ataques de fuerza bruta que para DDoS a escala. La protección real viene de un WAF externo como Cloudflare o Sucuri, que filtra el tráfico antes de que llegue al servidor.

¿Cómo desactivo XML-RPC en WordPress para evitar ataques?

La forma más directa es bloquear el acceso al archivo desde .htaccess con <Files xmlrpc.php> Deny from all </Files>. También podés desactivarlo a nivel de PHP agregando add_filter('xmlrpc_enabled', '__return_false'); en el functions.php del tema hijo. Si usás Cloudflare, podés crear una regla de firewall que bloquee cualquier request a /xmlrpc.php directamente desde el panel, sin tocar el servidor.

Conclusión

Un ataque DDoS de capa 7 contra WordPress no es un evento teórico para 2026: está pasando ahora, apunta a los mismos endpoints de siempre, y la mayoría de los sitios no tienen ni el WAF configurado ni el rate limiting activo.

La buena noticia es que la protección básica es accesible. Cloudflare gratis ya bloquea una parte importante del tráfico malicioso. Agregar rate limiting en wp-login.php y desactivar xmlrpc.php toma menos de 30 minutos. El caché agresivo multiplica la capacidad de absorber picos. Con esas tres cosas en orden, tu sitio tiene una superficie de ataque mucho más chica y una tolerancia mucho más alta a los intentos de saturación.

Si ya sufriste un ataque y seguís reconstruyendo, priorizá en este orden: WAF externo primero, rate limiting segundo, hardening de endpoints tercero. No al revés.

Fuentes

• SeguridadenWordPress.com – Protección DDoS WordPress: guía 2026
• Wallarm – Qué son los ataques DDoS Layer 7 y cómo mitigarlos
• ReparaWordPress – Mitigar ataques DDoS en WordPress con medidas reales
• CiberseguridadPyme – Amenazas cibernéticas de capa 7 que necesitás conocer
• CarlosMarca.com – Cómo proteger tu sitio WordPress contra ataques DDoS