Un ataque DDoS puede dejar tu sitio WordPress offline en minutos. La protección DDoS WordPress combina WAF, CDN, rate-limiting y configuración de servidor para absorber o filtrar el tráfico malicioso antes de que llegue a tu base de datos. Con las medidas correctas, un sitio puede mantenerse online incluso bajo ataques de varios Gbps.
En 30 segundos
- WordPress alimenta el 43% de la web, lo que lo convierte en el blanco más atacado: estructura predecible, endpoints conocidos como
wp-login.phpyxmlrpc.php. - Los ataques de Capa 7 (HTTP flood) son la amenaza principal para WordPress porque simulan tráfico legítimo y evaden filtros de red básicos.
- Desactivar XML-RPC, implementar un WAF como Sucuri o Cloudflare, y configurar rate-limiting en rutas críticas son los tres pasos con mayor impacto inmediato.
- Durante un ataque activo: activar modo defensivo en tu WAF, bloquear rangos de IP identificados, y contactar al hosting para mitigación en Capa 3/4.
- Wordfence (plan gratuito) cubre rate-limiting básico; Sucuri Firewall cuesta desde USD 9,99/mes y ofrece protección perimetral completa.
Por qué WordPress es objetivo de ataques DDoS
WordPress es el blanco favorito por razones muy concretas. El 43% de todos los sitios web del mundo corren sobre WordPress, lo que genera economías de escala para los atacantes: una herramienta de ataque funciona contra millones de sitios simultáneamente.
El tema es que WordPress tiene una superficie de ataque previsible. Cualquier instalación estándar expone los mismos endpoints: /wp-login.php para autenticación, /xmlrpc.php para publicación remota, /wp-admin/admin-ajax.php para operaciones AJAX, /?s= para búsquedas internas. Un atacante no necesita reconnaissance: sabe de antemano dónde pegar.
A eso sumale que el sitio promedio de WordPress tiene más de 20 plugins activos (cada uno con sus propios endpoints y lógica de base de datos), y que la mayoría corre en hosting compartido con recursos limitados. Una base de datos MySQL que responde consultas dinámicas para cada request es, en términos de infraestructura, un cuello de botella esperando ser explotado.
Ponele que un atacante manda 500 requests por segundo a /wp-login.php con combinaciones de usuario/contraseña. Cada request genera una consulta a la base de datos. El servidor de USD 10/mes no fue diseñado para eso, y a los 30 segundos el sitio empieza a dar 503.
Cómo detectar un ataque DDoS en tu WordPress
El primer síntoma es lentitud sin causa aparente, pero eso solo no alcanza para diagnosticar. Un servidor sobrecargado por un plugin mal configurado da el mismo síntoma. Para más detalles técnicos, mirá crear plugins de protección personalizados.
Los signos que sí indican DDoS:
- Errores 502 o 503 en cascada: el servidor está rechazando conexiones porque superó su capacidad.
- Discrepancia entre Analytics y logs del servidor: Google Analytics muestra 200 sesiones activas, pero los logs del servidor registran 50.000 requests por minuto. Esa diferencia son bots.
- Picos de CPU/RAM no correlacionados con tráfico real: el panel de hosting muestra recursos al 100%, pero el tráfico legítimo es normal.
- Hits repetidos a un solo endpoint: si el 80% de los requests van a
/xmlrpc.phpdesde 300 IPs distintas, es un ataque coordinado. - Rangos de IP geográficamente incoherentes: si tu audiencia es Argentina y estás recibiendo floods desde rangos de IP de cinco países que no visitan tu blog, no hace falta mucho análisis.
Para confirmar, revisá los access logs del servidor (generalmente en /var/log/apache2/access.log o /var/log/nginx/access.log) y filtrá por volumen de requests por IP en los últimos 5 minutos. El plugin Sucuri Security también tiene un log de actividad integrado que muestra patrones anómalos sin necesidad de acceso SSH.
Ataques de red (Capa 3-4) vs aplicación (Capa 7): cuál amenaza realmente a WordPress
Capa 3 y 4 son inundaciones de paquetes: UDP floods, SYN floods, ICMP floods. Son ataques volumétricos que saturan el ancho de banda. Para un sitio en hosting compartido, este tipo de ataque lo bloquea el propio proveedor de hosting antes de que llegue a tu servidor, porque afecta la infraestructura de red completa.
Capa 7 es otra historia.
Un ataque HTTP de Capa 7 manda requests HTTP/HTTPS legítimas, con headers correctos, a URLs reales de tu sitio. Desde la perspectiva del servidor, parece tráfico normal. La diferencia es el volumen y la coordinación: 10.000 bots mandando un GET a /?s=wordpress+security cada 2 segundos generan una carga que ningún servidor compartido aguanta, y cada request ejecuta una consulta de búsqueda en MySQL (operación cara).
Para WordPress, Capa 7 es la amenaza dominante. Los targets clásicos:
wp-login.php: fuerza bruta + flood combinadoadmin-ajax.php: procesamiento AJAX que puede generar múltiples queries por request- Páginas de búsqueda (
/?s=): sin caché, cada request golpea la base de datos xmlrpc.php: permite amplificación, un solo request puede generar docenas de operaciones internas
Deshabilitar xmlrpc.php, pingbacks y trackbacks
XML-RPC es una API legacy que WordPress mantuvo por compatibilidad con clientes de publicación remota (Jetpack, apps móviles antiguas). El problema es que permite autenticación en cada request y soporta llamadas en lote: con una sola petición HTTP, un atacante puede probar cientos de combinaciones de contraseña. Eso lo convierte en el endpoint favorito para amplificación de ataques.
Los pingbacks y trackbacks son notificaciones automáticas entre blogs WordPress: «oye, te mencioné en este artículo». Podrían ser útiles en 2008. Hoy son un vector de DDoS reflectivo: tu sitio puede ser usado como amplificador para atacar a otros, o recibir floods de pingbacks falsos.
Para deshabilitarlos hay tres opciones:
Via plugin (opción más simple)
Wordfence desactiva XML-RPC con un toggle en la configuración de firewall. All In One WP Security tiene una sección específica para pingbacks y trackbacks. Si ya tenés uno de esos plugins, no necesitás hacer nada más.
Via .htaccess (Apache)
Agregá esto al principio de tu .htaccess:
<Files xmlrpc.php>Order Deny,AllowDeny from all</Files>
Via Code Snippets
Para deshabilitar pingbacks y trackbacks sin tocar archivos del core, agregá en un snippet activo: add_filter('xmlrpc_methods', function($methods) { unset($methods['pingback.ping']); return $methods; }); y desactivá los pingbacks desde Ajustes > Comentarios desmarcando «Intentar notificar a los blogs enlazados». Sobre eso hablamos en proteger formularios contra ataques.
Implementar WAF y CDN como defensa perimetral
Un WAF (Web Application Firewall) analiza cada request HTTP antes de que llegue a WordPress y bloquea los que coinciden con patrones de ataque conocidos: floods, inyecciones, scrapers, scanners. Un CDN distribuye el tráfico en múltiples servidores globales, de modo que un ataque volumétrico se dispersa en lugar de concentrarse en tu servidor.
Acá viene lo importante: para que el WAF funcione, tu IP de servidor real no puede estar expuesta. Si un atacante conoce la IP directa de tu hosting, puede bypassear el CDN y pegarle al servidor sin pasar por ningún filtro. Cualquier configuración seria de protección DDoS empieza por ocultar la IP de origen (usando el WAF/CDN como único punto de entrada público).
Las opciones más usadas según Sucuri:
| Servicio | Modelo | Precio base | DDoS mitigation | WAF incluido |
|---|---|---|---|---|
| Sucuri Firewall | DNS proxy | USD 9,99/mes | Sí (Capa 7) | Sí |
| Cloudflare Free | DNS proxy | USD 0/mes | Básico | Reglas limitadas |
| Cloudflare Pro | DNS proxy | USD 20/mes | Mejorado | Sí (OWASP) |
| Cloudflare Business | DNS proxy | USD 200/mes | Avanzado + WAF custom | Sí |
| WordPress.com Modo Defensivo | Nativo | Incluido en planes | Sí (automático) | Parcial |
Cloudflare en su tier gratuito da protección básica contra floods volumétricos y permite crear reglas de firewall simples. Para la mayoría de los sitios chicos en Argentina, eso alcanza. Sucuri Firewall a USD 9,99/mes agrega análisis de comportamiento y un equipo de respuesta a incidentes que Cloudflare Free no tiene. Si el sitio genera ingresos, el costo de Sucuri se paga con el primer día de uptime que te salva.
Para el hosting en sí, si estás en Argentina, donweb.com ofrece planes con soporte local y posibilidad de configurar protecciones a nivel de servidor junto con cualquiera de estas soluciones perimetrales.
Rate-limiting en rutas críticas: wp-login.php y admin-ajax.php
¿Cuántos intentos de login necesita un humano real? Cinco, ponele diez si escribe la contraseña mal y se confunde. ¿Cuántos hace un bot de fuerza bruta? Miles por minuto desde decenas de IPs distintas.
El rate-limiting corta esa lógica: si una IP manda más de X requests a /wp-login.php en Y segundos, la bloqueás o la desafíás con CAPTCHA. Los umbrales recomendados para WordPress en 2026:
- wp-login.php: máximo 5 requests por IP por minuto. Más de eso es anómalo.
- admin-ajax.php: máximo 30 requests por IP por minuto (algunos plugins legítimos son más intensivos).
- xmlrpc.php: si no lo desactivaste, máximo 3 requests por IP por minuto.
- Páginas de búsqueda: máximo 10 búsquedas por IP por minuto.
Wordfence tiene rate-limiting incorporado en su versión gratuita (Firewall > Rate Limiting). All In One WP Security también. Si usás Cloudflare o Sucuri como WAF perimetral, configurás el rate-limiting directo en el panel del WAF y ahorrás carga de procesamiento en tu servidor, que es lo ideal (la solicitud nunca llega a PHP). Más contexto en automatizar defensas contra amenazas.
Mantener WordPress, plugins y temas actualizados
Las actualizaciones no previenen los ataques DDoS volumétricos, pero sí impiden algo peor: que usen tu WordPress como amplificador o que comprometan el servidor para lanzar ataques desde adentro.
En 2026, la mayoría de los ataques a WordPress combinan explotación de vulnerabilidades conocidas con flooding. Primero explotan un plugin desactualizado para ganar acceso, luego instalan un agente que forma parte de una botnet. Tu sitio termina siendo tanto víctima como atacante.
Wordfence mantiene una base de datos de vulnerabilidades actualizada en tiempo real. Con el plugin activo, te notifica cuando un plugin instalado tiene una vulnerabilidad conocida y te fuerza a actualizar antes de que sea explotada. WPVulnerability (que ya tenés instalado en seguridadenwordpress.com) cumple una función similar desde el dashboard de WordPress.
Plan de respuesta: qué hacer durante un ataque DDoS
El error más común es perder tiempo diagnosticando mientras el sitio sigue caído. El orden correcto:
- Paso 1 — Confirmá que es DDoS: revisá los access logs del servidor. Si ves miles de requests por minuto concentrados en 1-3 endpoints desde múltiples IPs, es DDoS. Si ves poca variación de IPs, podría ser un solo actor (más fácil de bloquear).
- Paso 2 — Activá el WAF en modo «ataque bajo»: tanto Sucuri como Cloudflare tienen un modo de protección elevada. En Cloudflare se llama «Under Attack Mode» (I’m Under Attack). Actívalo inmediatamente: agrega un challenge JavaScript a todos los visitantes, lo que filtra la mayoría de los bots automáticamente.
- Paso 3 — Bloqueá patrones identificados: si el ataque viene de rangos de IP específicos, bloquealos en el WAF. Si viene de un User-Agent particular, bloquealo también. Cada capa de filtrado reduce la carga.
- Paso 4 — Contactá al hosting: para ataques Capa 3/4 (volumétricos), solo el proveedor de hosting puede mitigar a nivel de red. Abrí un ticket urgente con los logs y el análisis. La mayoría de los planes tiene soporte para esto.
- Paso 5 — Preservá los logs: no borres ni sobreescribas los access logs durante el ataque. Son evidencia para análisis posterior y, eventualmente, para denuncias o escalado a tu proveedor de internet.
Si tenés habilitado el «Modo Defensivo» en WordPress.com o una configuración equivalente en tu hosting, ese modo activa automáticamente algunas de estas protecciones. (Spoiler: en la mayoría de los planes compartidos, no existe un modo así, y tenés que hacerlo vos manualmente.)
Errores comunes en la protección DDoS de WordPress
Error 1: Configurar el WAF pero dejar la IP del servidor expuesta. Si la IP directa de tu servidor está en registros DNS históricos o en headers HTTP, un atacante puede bypassear Cloudflare o Sucuri completamente. Después de activar el WAF, revisá que todos los registros DNS apunten al proxy, no al servidor. Herramientas como SecurityTrails o incluso Google Cache pueden revelar IPs antiguas. Tema relacionado: expandir seguridad con plugins adicionales.
Error 2: Confiar en el plan gratuito de Cloudflare para sitios con tráfico real. El tier gratuito no incluye WAF con reglas OWASP, rate-limiting granular por endpoint, ni soporte prioritario durante incidentes. Para un sitio que genera ingresos o que tiene audiencia regular, Cloudflare Pro (USD 20/mes) o Sucuri Firewall (USD 9,99/mes) son la inversión mínima razonable.
Error 3: Desactivar el caché «para hacer pruebas» y nunca reactivarlo. LiteSpeed Cache, W3 Total Cache o cualquier sistema de caché de páginas es una de las defensas más efectivas contra DDoS de Capa 7: si la página ya está en caché, WordPress y MySQL no procesan nada. Un sitio bien cacheado puede aguantar tráfico 10-20 veces mayor que uno que procesa cada request desde cero.
Preguntas Frecuentes
¿Cómo proteger mi sitio WordPress contra ataques DDoS?
La protección básica requiere tres capas: un WAF/CDN externo (Cloudflare o Sucuri) que filtre tráfico antes de llegar al servidor, rate-limiting en wp-login.php y admin-ajax.php, y desactivar XML-RPC si no lo usás. Para sitios con tráfico real, Sucuri Firewall desde USD 9,99/mes o Cloudflare Pro desde USD 20/mes son las opciones más prácticas con menor fricción de configuración.
¿Qué signos indican que mi WordPress está bajo ataque?
Los indicadores más claros: errores 502/503 sostenidos, discrepancia entre Analytics (tráfico normal) y logs del servidor (miles de requests por minuto), CPU/RAM al 100% sin correlación con visitantes reales, y floods concentrados en endpoints específicos como /wp-login.php o /xmlrpc.php desde múltiples IPs simultáneas.
¿Cuál es la diferencia entre DDoS de Capa 3 y Capa 7?
Capa 3/4 son inundaciones de paquetes de red (UDP, SYN, ICMP) que saturan el ancho de banda. Generalmente los bloquea el proveedor de hosting a nivel de infraestructura. Capa 7 simula requests HTTP legítimas y es la amenaza principal para WordPress, porque cada request puede ejecutar consultas de base de datos costosas y es más difícil de distinguir del tráfico real.
¿Qué debo hacer durante un ataque DDoS a mi sitio?
En orden: confirmá el ataque revisando los access logs, activá el modo «Under Attack» en tu WAF (Cloudflare o Sucuri), bloqueá los rangos de IP identificados, contactá a tu hosting para mitigación a nivel de red si el ataque es volumétrico, y preservá los logs para análisis posterior. No borres evidencia mientras el ataque está activo.
¿Cuánto cuesta implementar protección DDoS en WordPress?
Las opciones van desde USD 0 (Cloudflare Free + configuración manual de rate-limiting con Wordfence) hasta USD 200/mes para Cloudflare Business con WAF avanzado. El punto de equilibrio para la mayoría de los sitios en 2026 es Sucuri Firewall a USD 9,99/mes o Cloudflare Pro a USD 20/mes, que cubren los ataques de Capa 7 más comunes sin requerir configuración compleja.
Conclusión
No existe una defensa perfecta contra DDoS, pero sí existe la diferencia entre un sitio que cae en 30 segundos y uno que absorbe el ataque sin que los visitantes noten nada. Esa diferencia la dan las capas: WAF perimetral que filtra antes de llegar al servidor, rate-limiting en los endpoints más abusados, XML-RPC desactivado, caché agresivo, y un plan claro de qué hacer cuando empieza el flood.
Lo que cambió en 2026 es que los ataques de Capa 7 son más baratos y accesibles para atacantes de bajo presupuesto, mientras que las herramientas de defensa (Cloudflare Free, Wordfence) bajaron la barrera de entrada para el lado defensor también. La asimetría sigue existiendo, pero ya no es tan brutal como era hace cinco años. Un sitio bien configurado tiene chances reales.
Si tenés que empezar por algún lado, empezá por activar Cloudflare en modo proxy y desactivar XML-RPC. Eso solo elimina el 60% de la superficie de ataque típica de WordPress. El resto lo construís arriba de esa base.