Protección DDoS en WordPress: guía 2026

Actualizado el 19/08/2026 — Este artículo fue actualizado con información reciente y secciones nuevas.

Un ataque DDoS puede dejar tu sitio WordPress offline en minutos. La protección DDoS WordPress combina WAF, CDN, rate-limiting, mitigación de tráfico a nivel de servidor y configuración robusta de infraestructura 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.

La protección DDoS WordPress es un conjunto integrado de técnicas que previenen ataques de denegación de servicio distribuido contra tu sitio web. En 2026, estos ataques son más accesibles para atacantes de bajo presupuesto y más sofisticados en su ejecución: ya no son solo floods volumétricos de paquetes, sino también HTTP floods que simulan tráfico legítimo y explotan vulnerabilidades conocidas para reclutar servidores en botnets. La defensa moderna requiere múltiples capas: un firewall de aplicación web (WAF) externo que filtre tráfico antes de llegar al servidor, un sistema de caché agresivo que reduzca la carga de procesamiento, rate-limiting en endpoints críticos, y un plan de respuesta probado para actuar en tiempo real cuando el ataque inicia.

¿Qué es un ataque DDoS y cómo funciona contra WordPress?

Un ataque de denegación de servicio distribuido (DDoS) es cuando miles o millones de máquinas controladas (botnets) envían solicitudes simultáneamente a tu servidor con el objetivo de saturar sus recursos y dejarlo sin capacidad para responder a visitantes legítimos. A diferencia de un ataque de denegación de servicio simple (DoS, desde una máquina), el DDoS es distribuido: viene desde múltiples ubicaciones geográficas, múltiples rangos de IP, múltiples conexiones simultáneas. Eso lo hace más difícil de bloquear en origen porque no es una sola fuente que puedas desconectar.

Para WordPress, un ataque DDoS típico funciona así: un atacante compra acceso a una botnet (red de computadoras comprometidas) y le instruye a todas las máquinas que envíen requests a tu sitio. Si la botnet tiene 50.000 máquinas y cada una manda 100 requests por minuto, tu servidor recibe 5 millones de requests por minuto. Incluso un servidor potente tiene un límite de conexiones simultáneas y de requests por segundo. Cuando se alcanza ese límite, el servidor empieza a rechazar conexiones nuevas con errores 502 o 503, y tu sitio se cae.

Lo particular de WordPress es que cada request puede ser costoso: una búsqueda activa una consulta a la base de datos, un login intenta validar las credenciales, cargar una página requiere ejecutar hooks de plugins. Eso significa que un ataque de Capa 7 (HTTP) no necesita enviar millones de requests para derrumbar tu sitio — con decenas de miles ya alcanza porque cada uno consume recursos significativos. Un servidor compartido de USD 10/mes está diseñado para procesar cientos de requests simultáneos, no decenas de miles. La asimetría es brutal: el atacante gasta USD 50-200 en rentabilidad de botnet, y vos pierdes tu negocio por horas.

Tipos de ataques DDoS contra WordPress: Capa 3-4 vs Capa 7

La distinción más importante en DDoS es qué capas del modelo de red ataca. Para WordPress en 2026, la amenaza real viene de Capa 7, no de los ataques volumétricos de Capa 3-4 que escuchas en las noticias.

Ataques de Capa 3-4: volumétricos pero generalmente bloqueados antes de llegar

Capa 3 es el nivel de red (IP, ICMP), Capa 4 es el nivel de transporte (TCP, UDP). Los ataques volumétricos aquí son simples: inundar tu servidor de paquetes UDP (UDP floods), o hacer SYN floods (enviar millones de handshakes TCP incompletos que cuelgan conexiones) o ICMP floods (pings masivos).

Un SYN flood funciona así: el protocolo TCP requiere un handshake de tres pasos (SYN → SYN-ACK → ACK) para establecer conexión. Un atacante envía millones de SYN sin completar los siguientes pasos, dejando conexiones semi-abiertas en la cola. El servidor agota su tabla de conexiones, y los usuarios legítimos no pueden conectarse. Es efectivo porque no requiere solicitudes válidas, solo paquetes crudos de red.

El punto: estos ataques volumétricos son devastadores para la infraestructura general, pero para WordPress en hosting compartido, casi nunca llegan al servidor. El proveedor de hosting (donweb.com, etc.) los bloquea a nivel de red antes de que lleguen a tu máquina. Es un papeleo de SLA («sí, detectamos el ataque y lo mitigamos») pero tu sitio sigue funcionando porque el ISP del hosting tiene scrubbing centers especializados.

Ataques de Capa 7: HTTP floods que WordPress no puede rechazar fácilmente

Capa 7 es la aplicación (HTTP, HTTPS). Un ataque HTTP flood manda requests HTTP válidas, con headers correctos, a URLs reales de tu sitio. Para el servidor, parece tráfico legítimo. La diferencia es el volumen: 100.000 bots visitando simultáneamente /?s=prueba (búsqueda) o /wp-login.php (login).

Cada búsqueda ejecuta una query en MySQL, cada login valida credenciales. Eso no es un «paquete de red descartable» — es procesamiento real. Un servidor compartido puede manejar quizá 100 búsquedas por segundo; 10.000 búsquedas por segundo lo colapsan. Y no puedes bloquearlo a nivel de ISP porque parece tráfico HTTP normal.

En 2026, Capa 7 es la amenaza dominante para WordPress. Los targets clásicos:

• wp-login.php: fuerza bruta + flood combinado. Los atacantes usan wordlists y botnets para probar millones de combinaciones usuario/contraseña por minuto.
• admin-ajax.php: procesamiento AJAX que puede generar múltiples queries por request. Muchos plugins legítimos usan esto; atacantes lo explotan.
• Páginas de búsqueda (/?s=): sin caché nativo, cada request golpea la base de datos con una query LIKE en la tabla de posts.
• xmlrpc.php: endpoint legacy que permite amplificación. Una solicitud puede generar docenas de operaciones internas.
• Endpoints de plugins vulnerables: REST APIs mal configuradas, formularios sin validación, endpoints que ejecutan código sin autenticación.

La asimetría: defenderse de Capa 3-4 es responsabilidad de tu hosting (y funciona). Defenderse de Capa 7 es responsabilidad tuya (y es más difícil).

Por qué WordPress es objetivo preferido de ataques DDoS

WordPress alimenta el 43% de todos los sitios web del mundo. Eso significa que una herramienta de ataque genérica funciona contra millones de sitios simultáneamente: un atacante desarrolla un exploit, lo lanza contra todo WordPress, y espera. Economía de escala del lado de los atacantes.

Pero hay más. WordPress tiene una superficie de ataque previsible. Cualquier instalación estándar expone los mismos endpoints: /wp-login.php, /xmlrpc.php, /wp-admin/admin-ajax.php, /?s=. Un atacante no necesita reconnaissance: ya sabe dónde pegar. Además, el sitio promedio de WordPress tiene 20+ plugins activos, cada uno con sus propios endpoints, colas de procesamiento y reglas de base de datos. Más superficie de ataque = más vectores para explotar.

Sumale que la mayoría de WordPress corre en hosting compartido con recursos limitados. Una base de datos MySQL que responde consultas dinámicas para cada request es un cuello de botella esperando ser explotado. Un atacante que manda 500 requests por segundo a /wp-login.php genera 500 queries por segundo contra MySQL. Un servidor compartido no fue diseñado para eso. A los 30 segundos, el sitio da 503.

Cómo detectar un ataque DDoS en tu WordPress

El primer síntoma es lentitud o errores 502/503, pero eso solo no alcanza para diagnosticar DDoS — un servidor sobrecargado por un plugin mal configurado da el mismo síntoma. Para diferenciar un ataque real de un problema técnico normal, necesitás revisar evidencia concreta en los logs del servidor.

Los signos que sí indican DDoS:

• Errores 502 o 503 en cascada durante minutos. El servidor rechaza conexiones porque superó capacidad de conexiones simultáneas.
• Discrepancia entre Analytics y logs del servidor. Google Analytics muestra 200 sesiones activas, pero los logs registran 50.000 requests por minuto. Esa diferencia son bots (muchos no ejecutan JavaScript, así que Analytics no los ve).
• Picos de CPU/RAM no correlacionados con tráfico real. El panel de hosting muestra 100% CPU, pero Google Analytics muestra tráfico normal. Los recursos se queman en procesar requests inválidas.
• Hits repetidos a un solo endpoint desde múltiples IPs. Si el 80% de los requests van a /xmlrpc.php desde 300 IPs distintas en 5 minutos, es coordinado.
• Rangos de IP geográficamente anómalos. Tu audiencia es Argentina, pero recibes floods desde China, Rusia y Nigeria simultáneamente. Eso no es coincidencia.
• User-Agents sospechosos o repetidos. Miles de requests con el mismo User-Agent (bots no cambian, navegadores sí). Ej: curl/7.64.1, Python-Requests, Mozilla/5.0 (genérico) sin variantes de versión.

Para confirmar, accedé a los access logs del servidor (generalmente /var/log/apache2/access.log o /var/log/nginx/access.log vía SSH o file manager) y filtrá por volumen de requests por IP en los últimos 5 minutos. Un comando útil si tenés acceso SSH: tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20 (muestra las 20 IPs con más requests en tiempo real).

El plugin Sucuri Security también tiene un log de actividad integrado que muestra patrones anómalos sin necesidad de acceso SSH, si ya lo tenés instalado. Wordfence hace lo mismo en su sección de Firewall > Activity Log.

Deshabilitar xmlrpc.php, pingbacks y trackbacks

XML-RPC es una API legacy que WordPress mantiene por compatibilidad con clientes de publicación remota antiguos (Jetpack, apps móviles de 2010). El problema: 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 usuario/contraseña. Eso lo convierte en el vector favorito para amplificación de ataques DDoS.

Los pingbacks y trackbacks son notificaciones automáticas entre blogs: «oye, mencionaste mi sitio». Son un vector de DDoS reflectivo: tu sitio puede ser usado como amplificador para atacar a otros, o recibir floods de pingbacks falsos.

Opción 1: Vía plugin (más simple)

Wordfence desactiva XML-RPC con un toggle en Firewall > Advanced Security > Disable XML-RPC. All In One WP Security tiene una sección específica bajo Firewall > Brute Force > Disable XML-RPC. Si ya tenés uno de esos plugins, no necesitás hacer nada más.

Opción 2: Vía .htaccess (Apache)

Agregá esto al principio de tu .htaccess (en la raíz de tu sitio):

• <Files xmlrpc.php>
• Order Deny,Allow
• Deny from all
• </Files>

Opción 3: Vía Code Snippets (recomendado)

Para deshabilitar pingbacks sin tocar archivos del core, usa el plugin Code Snippets y agregá un snippet activo:

• add_filter('xmlrpc_methods', function($m) { unset($m['pingback.ping']); return $m; });
• Luego, en Ajustes > Comentarios, desmarcá «Intentar notificar a los blogs enlazados».

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 de vulnerabilidades. 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.

Lo crítico: para que el WAF funcione, tu IP de servidor real no puede estar expuesta públicamente. 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.

Las opciones más usadas en 2026:

Servicio	Modelo	Precio base (2026)	DDoS mitigation (Capa 7)	WAF incluido
Sucuri Firewall	DNS proxy	USD 9,99/mes	Sí (análisis comportamental)	Sí (24/7)
Cloudflare Free	DNS proxy	USD 0/mes	Básico	Reglas limitadas
Cloudflare Pro	DNS proxy	USD 20/mes	Mejorado (Page Rules)	Sí (OWASP Top 10)
Cloudflare Business	DNS proxy	USD 200+/mes	Avanzado (DDoS Protection)	Sí (WAF personalizado)
WordPress.com Defensivo	Nativo (hosted)	Incluido en planes	Automático en ataques	Parcial

Cloudflare en su tier gratuito detecta y mitiga floods volumétricos básicos y permite crear reglas de firewall simples (ej: bloquear por rango de IP, User-Agent, País). Para la mayoría de los sitios en Argentina, eso alcanza como primer paso. Sucuri Firewall a USD 9,99/mes agrega análisis de comportamiento más profundo y un equipo de respuesta a incidentes que Cloudflare Free no ofrece. Si tu sitio genera ingresos, el costo de Sucuri se paga con el primer día de uptime que te salva.

Para hosting, 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. ¿Cuántos hace un bot? Miles por minuto desde decenas de IPs. 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.

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.
• Búsquedas (/?s=): máximo 10 búsquedas por IP por minuto.
• Registro de usuarios (/?route=register): máximo 3 intentos por IP por hora si permitís registro público.

Wordfence tiene rate-limiting incorporado en su versión gratuita: Firewall > Advanced Security > Rate Limiting. All In One WP Security también. Si usás Cloudflare o Sucuri como WAF perimetral, configurás el rate-limiting en el panel del WAF directamente y evitás que los requests maliciosos lleguen a PHP (mejor que bloquearlo en el servidor, porque ahorras recursos).

Protecciones a nivel de servidor: LiteSpeed, nginx y caché

La mejor defensa contra DDoS de Capa 7 es que nunca llegue a PHP. Si la página está en caché (HTML estático), WordPress y MySQL ni se tocan. Un sitio bien cacheado puede absorber tráfico 10-20 veces mayor que uno que procesa cada request desde cero.

LiteSpeed Cache (si tu hosting usa LiteSpeed)

LiteSpeed es un servidor web que reemplaza Apache/nginx y tiene caché integrada. Si tu hosting ofrece LiteSpeed Web Server (muchos lo hacen en Argentina, incluso DonWeb), el plugin LiteSpeed Cache es extremadamente efectivo: cachea no solo páginas completas, sino también APIs, AJAX, imágenes. Configurá en LiteSpeed Cache:

• Cache TTL: por defecto, 3600 segundos (1 hora). Para sitios con contenido evergreen, podés subir a 7200 (2 horas) o más.
• Cache AJAX: activá «Cache REST API» y «Cache AJAX», excepto endpoints críticos como /wp-json/wp/v2/users (eso querés dinámico).
• Purge on Update: asegurate que al actualizar un post, se purgue su caché (default sí, pero verificá).
• Mobile Cache Separation: activá para cachear versiones distintas de mobile vs desktop.

W3 Total Cache o WP Super Cache (si no tenés LiteSpeed)

Si tu hosting usa Apache o nginx, usá W3 Total Cache (más potente) o WP Super Cache (más simple). Configurá caché de páginas completas, caché de objetos y caché de navegador. Un sitio con W3 Total Cache bien tuneado aguanta 3-5 veces más tráfico que sin caché.

nginx rate-limiting a nivel de servidor

Si tenés acceso a la configuración de nginx (VPS, servidor dedicado), agregá rate-limiting a nivel de servidor. Esto es más efectivo que hacerlo en WordPress porque bloquea la conexión antes de que PHP inicie:

• limit_req_zone $binary_remote_addr zone=wp_login:10m rate=5r/m; (5 requests por minuto por IP)
• limit_req_zone $binary_remote_addr zone=wp_admin:10m rate=30r/m; (30 por minuto para admin-ajax)
• Luego, en la sección de location de tu sitio, aplica: limit_req zone=wp_login; para location ~ ^/wp-login.php$

Ventaja: nginx rechaza la conexión inmediatamente sin procesar PHP. Desventaja: si lo configurás mal, bloqueás usuarios legítimos. Testea primero en staging.

Mantener WordPress, plugins y temas actualizados

Las actualizaciones no previenen ataques DDoS volumétricos directos, pero sí previenen algo peor: que usen tu WordPress como amplificador o que comprometan el servidor para lanzar ataques desde adentro.

En 2026, muchos ataques combinan explotación de vulnerabilidades con flooding. Primero explotan un plugin desactualizado para ganar acceso (RCE), luego instalan un agente que forma parte de una botnet. Tu sitio termina siendo tanto víctima como atacante.

La nota de actualización menciona que WordPress forzó actualizaciones automáticas para parchear SQL injection + RCE no autenticado (CVE-2026-63030 y CVE-2026-60137) que permitía reclutar sitios en ataques distribuidos. Activá actualizaciones automáticas: en Ajustes > Actualizaciones, deja que WordPress se auto-actualice en versiones menores (recomendado en 2026).

Wordfence mantiene una base de datos de vulnerabilidades actualizada en tiempo real. Con el plugin activo, te notifica si tenés un plugin con CVE conocida y te bloquea si intentás acceder a esa función vulnerable. WPVulnerability hace lo mismo desde el dashboard de WordPress.

Monitoreo y alertas: detectar ataques antes de que causen daño

No esperes a que tus visitantes te avisen que el sitio está caído. Configurá monitoreo proactivo con alertas en tiempo real para detectar patrones anómalos antes de que se conviertan en outage total.

Monitoreo de uptime y error rates

Usá herramientas como Uptime Robot (gratuita) o StatusCake para monitorear tu sitio cada 5 minutos. Si devuelve error 502/503 por más de 2 minutos, recibís alerta SMS o Telegram. Configurá que te avise también si el tiempo de respuesta sube arriba de 5 segundos (síntoma de ataque o sobrecarga).

Alertas en Wordfence o Sucuri

Wordfence puede alertarte si detecta accesos anómalos, cambios de archivos, o números inusuales de fallos de login. Sucuri envía alertas si detecta tráfico bot masivo o patrones de ataque. Ambos se integran con Slack o email.

Monitoreo de recursos en hosting

La mayoría de los hostings ofrece un panel donde ves uso de CPU, RAM, ancho de banda en tiempo real. Configurá alertas si CPU sube al 80% o más por más de 10 minutos sin razón (update/backup scheduled). Picos recurrentes de CPU sin correlación con tráfico real son síntoma clásico de DDoS.

Si tu hosting es DonWeb, revisá cPanel > Statistics > CPU Usage o el panel similar que ofrezca tu plan.

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 de acciones es crítico. Ejecuta estos pasos en orden, sin saltarte ninguno:

• Paso 1 — Confirmá que es DDoS (60 segundos). Revisá los access logs del servidor. Si ves miles de requests por minuto concentrados en 1-3 endpoints desde múltiples IPs geográficamente dispersas, es DDoS. Si ves poca variación de IPs (todas de un mismo país, o mismo /16), podría ser un solo atacante (más fácil de bloquear).
• Paso 2 — Activá el WAF en modo «ataque bajo» (30 segundos). Tanto Sucuri como Cloudflare tienen modos defensivos elevados. En Cloudflare es «Under Attack Mode» (botón I’m Under Attack), que agrega un desafío JavaScript a todos los visitantes — filtra la mayoría de los bots automáticamente. En Sucuri es «Increase Firewall Sensitivity». Activalo ahora.
• Paso 3 — Bloqueá patrones identificados (5 minutos). Si el ataque viene de rangos de IP específicos (ej: 185.220.0.0/16), bloqueálos en el WAF. Si viene de un User-Agent particular (ej: Python-Requests), bloqueálo. Cada capa de filtrado reduce la carga.
• Paso 4 — Contactá al hosting para mitigación Capa 3-4 (inmediato). Si el ataque es volumétrico (medido en Gbps, no requests), solo el proveedor de hosting puede mitigar a nivel de red. Abrí un ticket urgente con los logs, IPs atacantes y análisis. Si tenés plan con SLA, invocalo.
• Paso 5 — Preservá los logs (durante). No borres ni sobreescribas los access logs mientras el ataque está activo. Son evidencia para análisis posterior y, eventualmente, para denuncias o escalado a tu proveedor de internet.
• Paso 6 — Verifica recuperación (post-ataque). Una vez que el tráfico baje a niveles normales (monitoreo < 100 requests/s durante 5 minutos), volvé a revisar logs para ver si fue un solo burst o si el ataque es sostenido. Si es sostenido, podría haber vulnerabilidad no parcheada.

Si tenés WordPress.com o una plataforma equivalente con «Modo Defensivo» nativo, ese modo activa automáticamente algunas de estas protecciones. Para hosting compartido o VPS, 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 (Google Cache, SecurityTrails, Censys), un atacante puede bypassear Cloudflare o Sucuri completamente y pegarle directo al servidor. Después de activar un WAF, revisá que todos los registros DNS apunten al proxy, no al servidor. Herramientas gratuitas como SecurityTrails o simplemente buscá site:.tudominio.com en Google seguido de cache: para ver si Google tiene versiones antiguas con tu IP real.

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 tráfico regular > 1000 visitas/día, 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 caché de páginas es una de las defensas más efectivas contra DDoS Capa 7: si la página ya está en caché, WordPress ni se toca. Un sitio bien cacheado aguanta tráfico 10-20 veces mayor que uno que procesa cada request. No desactives caché sin reactivarlo inmediatamente después de terminar las pruebas.

Error 4: No revisar logs de WAF y no identificar patrones antes de bloquear

A veces lo que parece un «ataque masivo» es en realidad un plugin defectuoso que hace 10.000 requests internos por página, o un servicio legítimo (crawler de Google, Uptime Robot) que se reintentó cien veces porque lo bloqueaste accidentalmente. Antes de bloquear agresivamente, revisá dos o tres ejemplos reales de los requests: URL, User-Agent, método. Si es diverso, es probablemente legítimo.

Preguntas Frecuentes

¿Cómo sé si mi WordPress está siendo atacado o simplemente sobrecargado?

Sobrecarga es típicamente por tráfico legítimo o un plugin defectuoso. DDoS es miles de requests idénticos desde múltiples IPs simultáneas. Revisá: (1) ¿son todos los requests a endpoints específicos (wp-login.php, admin-ajax.php)?; (2) ¿vienen de IPs geográficamente dispersas?; (3) ¿el User-Agent es genérico o bot-like (Python-Requests, curl)?. Si sí a los tres, es DDoS. Si ves tráfico legítimo normal pero con CPU alta, es sobrecarga: probablemente un plugin mal configurado, falta de caché, o una query de base de datos lenta.

¿Cloudflare gratuito me protege realmente de DDoS?

Cloudflare gratuito cubre ataques volumétricos básicos y filtra patrones simples (bots conocidos, IP reputation). Para protección avanzada contra HTTP floods sofisticados y análisis comportamental que distinga entre bots y usuarios reales, necesitás Cloudflare Pro (USD 20/mes) o Sucuri Firewall (USD 9,99/mes). La diferencia real la ves en «false positives» (bloquear usuarios legítimos) y «false negatives» (dejar pasar bots). El gratuito es mejor que nada, pero imperfecto.

¿Debo deshabilitar XML-RPC en mi WordPress?

Sí. XML-RPC es un endpoint legacy que casi ningún sitio moderno usa (Jetpack lo usaba hace años, hoy no lo necesita). Los atacantes lo usan para amplificar DDoS: una sola solicitud puede generar cientos de operaciones internas. Deshabilitalo sin perder funcionalidad. La única razón para mantenerlo: si usás aplicación de escritorio antigua de 2008 para publicar posts (muy probable que no).

¿Cuánto cuesta implementar protección DDoS en WordPress?

Las opciones van desde USD 0 (Cloudflare Free + Wordfence gratuito) hasta USD 200+/mes para Cloudflare Business con WAF avanzado. El punto de equilibrio para la mayoría de sitios en 2026 es Sucuri Firewall (USD 9,99/mes) o Cloudflare Pro (USD 20/mes), que cubren ataques Capa 7 comunes sin requerir configuración compleja. Si generás ingresos con tu sitio, la inversión se paga en el primer día de uptime que ahorrás.

¿Qué diferencia hay entre DDoS y un ataque de fuerza bruta contra wp-login.php?

Un ataque de fuerza bruta es intentar adivinar la contraseña: un atacante prueba usuario=admin, pass=123456; luego admin/123457; admin/123458. Puede ser desde una sola IP o múltiples (distribución de intentos). Un DDoS es flooded masivo: miles de requests idénticas o similares para saturar recursos, sin objetivo de «adivinar contraseña». Pueden coexistir: un DDoS puede *incluir* fuerza bruta como payload. La defensa contra fuerza bruta es rate-limiting + CAPTCHA; la defensa contra DDoS es WAF + caché.

Si sé la IP de los atacantes, ¿puedo bloquearlos directamente en nginx/Apache?

Sí, pero con limitaciones. Si identificás una IP atacante, bloqueárla en nginx o Apache es efectivo y rápido. El problema: los atacantes típicamente usan botnets de decenas de miles de IPs. Bloqueás 100 y quedan 99.900. Para ataques coordenados de verdad (no solo un scanner casual), necesitás una solución más escalable que bloquee por patrón (User-Agent, endpoint, rate), no por IP individual. El WAF es mejor porque hace eso automáticamente.

¿El hosting compartido de DonWeb puede manejar ataques DDoS?

DonWeb tiene protecciones a nivel de red (Capa 3-4) contra ataques volumétricos. Para Capa 7 (HTTP floods), el hosting absorbe mejor si tenés configuración local de caché + rate-limiting + WAF. Si el ataque es sostenido y de gran volumen, abrí un ticket con DonWeb y ellos pueden aplicar mitigaciones adicionales a nivel de infraestructura. La mayoría de ataques DDoS contra WordPress son Capa 7 (no volumétricos puros), así que las medidas locales suelen alcanzar.

Conclusión

No existe 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 visitantes noten nada. Esa diferencia la dan las capas: WAF perimetral que filtra antes de llegar al servidor, rate-limiting en endpoints abusados, XML-RPC desactivado, caché agresivo, monitoreo proactivo, y un plan de respuesta probado.

Lo que cambió en 2026 es que los ataques Capa 7 son más baratos y accesibles para atacantes de bajo presupuesto, pero también las herramientas de defensa (Cloudflare Free, Wordfence) bajaron la barrera de entrada para el lado defensor. La asimetría sigue existiendo, pero ya no es tan brutal como hace cinco años. Un sitio bien configurado tiene chances reales de aguantar.

Si tenés que empezar por algún lado: (1) activá Cloudflare en modo proxy (DNS swap, 5 minutos); (2) desactivá XML-RPC (2 minutos); (3) instalá Wordfence y activá rate-limiting (5 minutos). Eso solo elimina el 60% de la superficie de ataque típica. El resto lo construís arriba de esa base conforme gana tráfico tu sitio y la inversión se justifica.

Fuentes

• Sucuri Blog — WordPress DDoS Protection: How to Keep Your Site Online (2026)
• Declaraciones de seguridad WordPress — Actualizaciones críticas CVE-2026-60137 y CVE-2026-63030 (julio 2026)
• Cloudflare Learning Center — How to Improve WordPress Security (2026)
• Patchstack — State of WordPress Security in 2026 (junio 2026)
• Field Effect Security — WP2Shell vulnerability chain documentation (julio 2026)
• Malwarebytes — WordCamp Europe 2026 presentation on WordPress search endpoint DDoS vectors
• VyomCloud — Free DDoS Protection Solutions Analysis (mayo 2026)