Protección DDoS de Cloudflare y modo Under Attack: qué hacer cuando atacan su sitio
Su sitio está detrás de Cloudflare y de repente recibe una avalancha de tráfico. Así encajan la protección DDoS, el modo Under Attack, la limitación de tasa y el bloqueo del origen, con una lista para incidentes.
Si el sitio web de su empresa de repente está lento, no responde o recibe una avalancha de solicitudes, y está detrás de Cloudflare, usted ya cuenta con protección contra DDoS: la documentación de Cloudflare indica protección DDoS estándar y sin medición para las capas 3 a 7 en todos los planes, incluido el Free. Lo que haga en los primeros minutos tiene más que ver con ajustar que con comprar: active el modo Under Attack si los visitantes reales no logran entrar, agregue una regla de limitación de tasa para la página que están atacando y asegúrese de que los atacantes no puedan saltarse Cloudflare apuntando directamente a la dirección IP de su servidor. Esta guía explica cada control en lenguaje sencillo y termina con una lista de verificación para incidentes que puede imprimir.
Para lo básico, consulte nuestra guía para proteger su sitio web con el WAF de Cloudflare; este artículo explica qué hacer cuando el ataque ya está en curso.
Cómo se ve un DDoS o una avalancha de bots para una pequeña empresa
Un ataque de denegación de servicio distribuido (DDoS) envía más tráfico del que su sitio puede manejar, desde muchas fuentes a la vez. Para la mayoría de las pequeñas y medianas empresas, el problema no es un ataque de red de récord. Es una avalancha en la capa de aplicación (capa 7): miles de solicitudes por segundo a la página de inicio, al buscador, a un formulario de inicio de sesión o de contacto, a menudo desde servidores alquilados o dispositivos comprometidos.
Síntomas típicos:
- El sitio carga lento o devuelve errores 5xx (502, 503, 504 o los errores 52x de Cloudflare).
- Su proveedor de hosting le avisa de límites de CPU o de conexiones, o suspende la cuenta.
- Los registros del servidor muestran una ráfaga de solicitudes a una misma URL desde muchas direcciones IP.
- Los formularios de contacto se llenan de envíos basura, o las páginas de inicio de sesión reciben oleadas de intentos fallidos.
La red de Cloudflare absorbe buena parte de esto antes de que llegue a usted. Los elementos que verá a continuación deciden cuánto llega a su servidor.
Protección siempre activa: el conjunto de reglas administrado HTTP DDoS
Cloudflare ejecuta un conjunto de reglas administrado llamado HTTP DDoS attack protection. Según la documentación de Cloudflare, está siempre habilitado para las zonas de todos los planes; no se puede desactivar, solo ajustar su comportamiento.
Sensibilidad y acción
Puede crear una excepción (override) que cambia dos cosas para todo el conjunto de reglas:
| Ajuste | Opciones | Qué significa |
|---|---|---|
| Sensibilidad del conjunto (Ruleset sensitivity) | High (predeterminada), Medium, Low, Essentially Off | Mayor sensibilidad significa un umbral más bajo, así que Cloudflare mitiga antes |
| Acción del conjunto (Ruleset action) | Block, Managed Challenge, Interactive Challenge | Qué ocurre con el tráfico identificado como parte de un ataque |
En el panel, vaya a Security rules, abra la pestaña DDoS protection y seleccione Create override bajo HTTP DDoS attack protection. En los planes que no son Enterprise con Advanced DDoS Protection usted dispone de una sola excepción, y se aplica a todo el tráfico.
Nuestra recomendación: deje la sensibilidad en High. Si una integración legítima es mitigada una y otra vez, corrija esa integración en lugar de debilitar la protección para todo.
Protección según la tasa de errores de su servidor
Cloudflare también documenta una regla llamada Adaptive DDoS Protection for Origins, que vigila el tráfico que provoca una cantidad inusual de errores en su servidor, y está disponible en cualquier plan.

Modo Under Attack: el interruptor de emergencia
El modo Under Attack agrega una verificación adicional a cada visita. Los visitantes ven una breve página intermedia mientras Cloudflare evalúa el navegador; los visitantes validados siguen hacia el sitio y el tráfico sospechoso se bloquea. Cloudflare lo describe como uno de los últimos recursos cuando una zona está bajo ataque.
Cómo activarlo y desactivarlo
- Para todo el sitio: abra su dominio en el panel de Cloudflare y active Under Attack Mode en el panel Quick Actions de la página de resumen. En el nuevo panel de seguridad, la API y Terraform, lo mismo se controla con el ajuste security level.
- Para una parte del sitio: cree una configuration rule que coincida con una ruta (por ejemplo, la ruta URI empieza por
/login) y fije el nivel de seguridad en I'm Under Attack. Es una buena opción cuando solo atacan una página.
Desactívelo en cuanto el ataque disminuya. Los visitantes que superan la verificación no vuelven a ser desafiados hasta que vence el tiempo de Challenge Passage.
Efectos secundarios que debe prever
Cloudflare advierte que el modo Under Attack puede afectar el tráfico de API y las analíticas, porque la verificación necesita un navegador que ejecute JavaScript. Antes de activarlo, piense en todo lo que se comunica con su sitio sin un navegador:
- Webhooks de pagos y formularios (Stripe, PayPal, servicios de formularios) que envían datos a su servidor.
- Aplicaciones móviles e integraciones que llaman a su API.
- Monitores de disponibilidad y tareas programadas que consultan páginas.
La solución es la misma función de configuration rules a la inversa: si el modo Under Attack está activo en todo el sitio, agregue una regla que lo desactive para /api/ o para la ruta de sus webhooks, y proteja esa ruta con una regla de limitación de tasa. Pruebe el envío de un webhook después de cualquier cambio.
Reglas de limitación de tasa: frenar a los pocos que hacen ruido
Una regla de limitación de tasa (rate limiting rule) cuenta las solicitudes que coinciden con una expresión y actúa cuando un cliente supera el límite, por ejemplo bloqueándolo o desafiándolo durante un tiempo. Es la herramienta adecuada para páginas de inicio de sesión, buscadores, formularios de contacto y API.
Lo que obtiene depende del plan. La documentación de Cloudflare indica estos límites para el plan Free:
| Función en el plan Free | Límite |
|---|---|
| Número de reglas | 1 |
| Campos con los que puede filtrar | Ruta (Path) y Verified Bot |
| Conteo por | Dirección IP |
| Período de conteo y tiempo de mitigación | 10 segundos |
Una sola regla basta para proteger la página más importante. Un buen punto de partida es una regla en la ruta de inicio de sesión o del formulario de contacto que bloquee a una IP que envíe en 10 segundos muchas más solicitudes de las que una persona llenando un formulario enviaría jamás. Los planes de pago agregan períodos más largos, más reglas y más formas de contar.
Proteja el servidor de origen para que no puedan rodear a Cloudflare
Cloudflare solo protege el tráfico que pasa por su red. Si un atacante encuentra la dirección IP real de su servidor, puede saltarse Cloudflare por completo. La guía de Cloudflare para proteger el servidor de origen cubre las principales filtraciones y sus soluciones.
Formas comunes en que se filtra la IP del origen
- Historial de DNS antiguo. Los servicios públicos de historial de DNS guardan registros de antes de que usted se pasara a Cloudflare. Por eso Cloudflare recomienda cambiar las IP de origen después de incorporarse.
- Correo en el mismo servidor. Si el sitio web y el correo comparten servidor, los encabezados de los mensajes y los rebotes pueden revelar la dirección. Cloudflare aconseja no alojar el correo en el mismo servidor que el sitio protegido.
- Registros solo DNS. Los registros con la nube gris, y los registros SPF u otros TXT que incluyen la IP del servidor web, la delatan. Revise todos los registros que no pasan por el proxy.
- Subdominios como
ftp,cpanelodevque apuntan a la misma IP sin el proxy.
Cómo cerrar la puerta
- Pase por el proxy cada registro web (nube naranja) que sirve su sitio.
- Permita solo los rangos de IP de Cloudflare en los puertos 80 y 443 del firewall del servidor. Cloudflare señala que, por sí solo, esto es moderadamente seguro.
- Authenticated Origin Pulls, que permite a su servidor verificar que una solicitud realmente llegó a través de Cloudflare. Requiere el modo SSL/TLS Full o Full (strict).
- Cloudflare Tunnel, que conecta su servidor con Cloudflare mediante conexiones solo salientes, de modo que el servidor no necesita una IP pública accesible para el sitio. Requiere instalar el servicio
cloudflared.
Pregunte a su proveedor de hosting cuáles de estas medidas están implementadas; nuestro servicio de administración de hosting web las incluye como parte de una configuración estándar.
Lista de verificación: cuando el sitio está bajo ataque
- Confirme que es un ataque. Revise los eventos de seguridad y las analíticas de Cloudflare, y la carga del servidor, antes de suponer nada.
- Identifique el objetivo. ¿Una URL, todo el sitio o la IP del servidor directamente (tráfico que no aparece en Cloudflare)?
- Si los visitantes no logran entrar, active el modo Under Attack, en todo el sitio o con una configuration rule para la ruta atacada.
- Exima el tráfico de máquinas (webhooks, API, monitores) con una configuration rule, y pruebe un webhook.
- Agregue o ajuste una regla de limitación de tasa en la ruta atacada.
- Si el tráfico evita Cloudflare, restrinja el firewall del servidor a los rangos de IP de Cloudflare y planifique un cambio de IP de origen.
- Avise a su equipo y a sus clientes clave si los formularios, los pagos o el portal están afectados, y anote horas y acciones para después.
- Desactive el modo Under Attack cuando el tráfico vuelva a la normalidad y revise qué funcionó.
- Después, corrija las filtraciones que encontró y documente quién tiene acceso al panel. Si el ataque pudo servir de distracción, siga nuestra guía sobre las primeras 24 horas después de una brecha.
Un ataque DDoS es disruptivo, pero por sí solo rara vez es una brecha de datos. Las empresas que se recuperan más rápido son las que ya saben dónde están los interruptores y qué integraciones dejarán de funcionar al activarlos.
Si quiere que alguien revise su configuración de Cloudflare y de su servidor antes de necesitarlo, solicite una evaluación de TI gratuita. Core Florida IT es un proveedor de TI independiente que configura Cloudflare y protege servidores empresariales para compañías en Miami-Dade y todo el sur de la Florida, como parte de nuestros servicios de ciberseguridad.
Fuentes
- DDoS Protection: resumen y disponibilidad por plan (Cloudflare Docs)
- HTTP DDoS Attack Protection managed ruleset (Cloudflare Docs)
- Parámetros del conjunto HTTP DDoS: sensibilidad y acciones (Cloudflare Docs)
- Under Attack mode (Cloudflare Docs)
- Security Level (Cloudflare Docs)
- Rate limiting rules (Cloudflare Docs)
- Protect your origin server (Cloudflare Docs)


