Modo Resistencia DDoS | SeenSecure Help

¿Qué es esto y en qué se diferencia del Rate Limiting?

DDoS significa "Denegación de Servicio Distribuida": muchos ordenadores distintos (a veces miles, en una "botnet") atacan tu web a la vez para saturarla y dejarla caída.

🐘 Por qué WordPress es un objetivo especialmente fácil

Un archivo estático (una imagen, un PDF, una página HTML plana) se sirve directamente desde el disco: el servidor lo lee y lo envía, sin pensar. Una página de WordPress no funciona así. Cada visita obliga a PHP a arrancar desde cero: cargar el núcleo de WordPress, los plugins activos, el tema, y lanzar varias consultas a la base de datos (MySQL) para montar esa página concreta con sus productos, comentarios o menú. Eso convierte cada petición en un trabajo de CPU y base de datos, no solo de ancho de banda.

Por eso un servidor que aguantaría sin despeinarse miles de peticiones por segundo a un archivo estático puede empezar a fallar con solo unas pocas decenas o cientos de peticiones por segundo a páginas de WordPress sin caché: la base de datos alcanza su límite de conexiones simultáneas mucho antes de que se sature la conexión de red. Cuando eso pasa, el sitio deja de responder incluso para los visitantes reales, aunque el ataque venga de un número relativamente modesto de peticiones comparado con un DDoS clásico a nivel de red.

⚖️ ¿Por qué no basta con el Rate Limiting?

El Rate Limiting cuenta peticiones por IP: si una IP se pasa, se bloquea esa IP. Pero en un DDoS real, el ataque no viene de 1 IP — viene de cientos o miles de IPs distintas a la vez. Cada IP nueva empieza su propio contador desde cero, así que nunca llega a superar el límite individual, y el ataque pasa desapercibido.

🧮 ¿Cómo lo soluciona esto?

En vez de contar por IP, cuenta el tráfico TOTAL de tu web (todas las IPs juntas). Si ese total se dispara, se activa el "modo flood": a cada visitante nuevo (sin importar su IP) se le pide resolver un pequeño cálculo matemático vía JavaScript antes de dejarle ver la página.

✅ Para el visitante real: se resuelve solo, en menos de un segundo, sin darse cuenta. Para un bot de ataque (sin motor JavaScript): nunca responde correctamente y se queda fuera, venga de la IP que venga.

Cómo funciona por dentro

SeenSecure cuenta cuántas peticiones recibe todo el sitio en ventanas cortas de tiempo.
Si ese total supera el umbral configurado, se activa el "modo flood" durante un tiempo mínimo (enfriamiento), para no encender y apagar el desafío constantemente si el tráfico ronda justo el límite.
Mientras el modo flood está activo, cada visitante nuevo recibe la página de verificación en vez de la página real, hasta que resuelve el cálculo (automáticamente, vía JavaScript).
Una vez verificado, el visitante puede navegar con normalidad durante el tiempo configurado (duración del pase) sin que se le vuelva a preguntar.

💥 Ejemplo real: una botnet de unas 4.000 IPs distintas lanza de golpe 15.000 peticiones/minuto contra la portada de una tienda WordPress sin caché de página completa. Cada una de esas peticiones ejecuta PHP y varias consultas SQL para montar el carrito, el menú y los productos destacados. En segundos, MySQL alcanza su límite de conexiones simultáneas y empieza a devolver errores 500 — no solo a los bots, también a clientes reales que estaban comprando en ese momento. Con el Modo Resistencia DDoS activo, SeenSecure detecta que el tráfico total del sitio supera el umbral configurado (por ejemplo, 15.000 peticiones/min frente a un límite de 600-1000) y activa el modo flood: los visitantes nuevos reciben la página ligera de verificación en vez de la página real de WordPress, una página que no toca PHP completo ni la base de datos. Los bots del ataque, sin motor JavaScript, se quedan atascados ahí sin generar carga real; la presión sobre MySQL cae en segundos y la tienda vuelve a responder con normalidad para los clientes que sí resuelven la verificación.

🔒 Nunca te quedas fuera de tu propia web: los administradores ya conectados, las IPs en tu Whitelist, y wp-admin/login/cron nunca ven el desafío, pase lo que pase con el tráfico.

Ajustes de esta sección

Umbral (peticiones/min de todo el sitio)

A partir de cuánto tráfico TOTAL se considera un posible ataque. Empieza alto (600-1000) y bájalo solo si tu web sufre ataques reales; ponerlo demasiado bajo puede activar el desafío en picos normales de visitas (ej. viralidad en redes).

Duración del pase (minutos)

Cuánto tiempo un visitante que ya resolvió el cálculo puede seguir navegando sin que se le vuelva a preguntar.

Enfriamiento (minutos)

Una vez activado, cuánto tiempo se mantiene el modo flood encendido tras bajar el tráfico, antes de desactivarse solo. Evita que se encienda y apague constantemente si el tráfico ronda justo el límite.

💡 Recomendación: déjalo desactivado si nunca has sufrido un ataque de este tipo. Actívalo solo si tu web ha sufrido caídas por exceso de tráfico repentino, o como medida preventiva si esperas un pico (lanzamiento, campaña, mención viral).

Lo que NO hace (límites honestos)

No protege formularios, pagos ni llamadas a la API (peticiones que no son de tipo "GET") — interrumpirlos a mitad sería peor que el propio ataque, así que se dejan pasar sin comprobar.
No sustituye a un CDN (como Cloudflare) frente a ataques a nivel de red/conexión — esto protege a nivel de aplicación (páginas web), no el tráfico de red en bruto.

⚠️ Ningún desafío es 100% infalible: este mecanismo filtra la inmensa mayoría de bots genéricos de flood (los que no ejecutan JavaScript), pero un atacante muy dedicado que estudie específicamente tu web podría, en teoría, reproducir el cálculo sin ejecutar JS. Para el caso real de un WordPress pequeño-mediano, esta es una mejora sólida y honesta, no una promesa de invulnerabilidad total.

❓ FAQ — Preguntas Frecuentes

🔹 ¿Debo tener esto activado siempre?

No es necesario para la mayoría de sitios. Actívalo si tu web ya ha sufrido caídas por exceso de tráfico repentino, o de forma preventiva antes de un evento que esperas que genere mucho tráfico (lanzamiento, campaña de publicidad, mención viral).

🔹 ¿Puede bloquear a mis clientes reales durante un pico de ventas?

No los bloquea — les pide un segundo de verificación automática (invisible para ellos) antes de mostrarles la página, solo mientras el modo flood esté activo. Un cliente real con un navegador normal lo pasa sin darse cuenta. Es más probable que active el modo flood en un pico de tráfico legítimo si el umbral está configurado demasiado bajo — por eso se recomienda empezar alto (600-1000 peticiones/minuto).

🔹 ¿Dónde se activa esto en el panel?

En Firewall → Rate Limiting, en la tarjeta "🛡️ Modo Resistencia DDoS" (justo debajo de la tarjeta "🚀 Primera Línea"). Disponible en el plan FREE, sin necesidad de PRO. No confundas las dos tarjetas: "Primera Línea" corre ANTES de que WordPress cargue y sigue funcionando aunque la base de datos esté saturada, mientras que "Modo Resistencia DDoS" corre DENTRO de WordPress con un umbral configurable por minuto. Son independientes entre sí y se recomienda mantener ambas activas.

💡 Consejo: si vas a lanzar una campaña que esperas que sea muy popular, sube temporalmente el umbral (o desactiva el modo) durante el evento, y vuelve a activarlo después.