La pregunta habitual
Cuando tu web está detrás de Cloudflare y sufres oleadas de bots, es normal descubrir que el servidor de origen sigue respondiendo si se le llama directamente por su IP, por ejemplo con una prueba como esta:
curl -I --resolve tudominio.com:443:IP_DEL_SERVIDOR https://tudominio.com/
La respuesta es HTTP 200. De ahí surge la propuesta lógica: ¿por qué no bloqueamos en el cortafuegos los puertos 80 y 443 para que solo acepten tráfico desde los rangos oficiales de Cloudflare?
Por qué no lo hacemos
En un servidor administrado esa restricción rompe cosas que no se ven desde fuera. Los puertos 80 y 443 del servidor los usan muchos más servicios además de las visitas de tu web:
Copias de seguridad y sincronización con el almacenamiento externo.
Actualizaciones del panel, del sistema y de las aplicaciones instaladas.
Comprobaciones de licencia (cPanel, LiteSpeed, CloudLinux, Imunify360, plantillas y módulos comerciales).
Emisión y renovación de certificados SSL.
Servicios y webhooks de terceros que tus webs necesiten (pasarelas de pago, ERPs, integraciones).
Otros dominios y cuentas alojados en el mismo servidor que no usan Cloudflare.
Además, la lista de rangos de Cloudflare cambia con el tiempo: si no se actualiza, un día la web deja de responder sin motivo aparente.
Por eso lo consideramos, como mucho, una última instancia tras evaluar caso por caso qué servicios se verían afectados. En la práctica, todos los ataques de este tipo que hemos gestionado se han resuelto por otra vía.
Cómo se mitiga realmente
La vía efectiva es aplicar reglas robustas en el propio Cloudflare, sin tocar el cortafuegos del servidor. Un ejemplo de mitigación real:
Bloqueo de un bot concreto solo en las URLs de filtros o facetas, no en toda la web.
Challenge (no bloqueo) al navegador falso exacto que usa el ataque, aplicado a facetas y a las peticiones AJAX derivadas.
Los buscadores legítimos siguen respondiendo 200, sin 403 ni 429.
El tráfico de campañas de pago, el carrito y el proceso de pedido se dejan intactos y verificados.
El efecto es inmediato y medible: en un caso real la carga del servidor bajó de 11,9 a 1,9 y el tráfico de 15-17 a 2,4 peticiones por segundo, con la cola de procesos PHP a cero.
Por qué te pedimos que desactives el modo "Under Attack"
El modo I'm Under Attack de Cloudflare estabiliza la web de forma inmediata, y es razonable activarlo como parche mientras esperas. Pero tiene un efecto secundario: oculta el tráfico del ataque, porque todos los visitantes pasan por una pantalla de verificación.
Mientras está activo no podemos ver el patrón real (qué User-Agent, qué URLs, qué frecuencia), y por tanto no podemos crear las reglas específicas que sí resuelven el problema de forma permanente.
Por eso el procedimiento es:
Nos avisas de que lo tienes activado.
Cuando te lo pidamos, lo desactivas y nos lo confirmas.
Analizamos el tráfico real durante unos minutos y aplicamos o ajustamos las reglas.
Verificamos que la web responde bien y que no se ha roto nada.
Si vuelves a activarlo sin avisar, el análisis se detiene y la mitigación se retrasa.
Ten en cuenta que el ataque cambia de patrón
Los ataques de bots modernos mutan cuando se les bloquea: cambian de User-Agent, de rango de IP o de tipo de URL. Es habitual necesitar varias rondas de ajuste en días sucesivos. No podemos aplicar reglas muy estrictas de golpe, porque dejarían de funcionar partes legítimas de la web (filtros, carrito, pasarela de pago, buscadores).