WAF + Limitación de velocidad + Gestión de bots: la trifecta de protección de bordes

La suposición más común de los equipos que acaban de habilitar Cloudflare WAF es que la aplicación ahora está protegida. Esta conclusión es técnicamente incorrecta, no porque WAF no funcione, sino porque los ataques que bloquea son sólo un subconjunto de los que recibirá. Los otros dos subconjuntos tienen productos diferentes, con una lógica de detección completamente diferente, y los tres rara vez se configuran juntos desde el principio.

Lo que realmente ve cada capa

La forma más clara de entender la división es pensar en tres dimensiones de la solicitud: qué contiene, cuántos llegan y quién los envía.

WAF opera sobre el contenido: inspecciona la carga útil de la solicitud y comprueba si coincide con los patrones de ataque conocidos. Un ' OR 1=1 -- en un parámetro de consulta, una etiqueta de script en un campo de formulario, una secuencia ../../../etc/passwd en una ruta: estas son firmas que el motor reconoce y bloquea. El WAF es quirúrgico en la dimensión que y ciego en las otras dos.

La limitación de velocidad funciona según la velocidad. No importa lo que contenga la solicitud: si una IP envía 50 intentos de inicio de sesión en diez segundos, algo anda mal. WAF no puede detectar esto porque cada solicitud individual es formalmente válida: la consulta SQL es correcta, no hay carga útil maliciosa, la solicitud HTTP sería aceptada por cualquier servidor sin objeciones. El problema no es el formato, es la frecuencia.

Bot Management opera sobre la identidad conductual. Un robot sofisticado que aleatoriza los intervalos entre solicitudes, utiliza un grupo de IP rotativo y mantiene las tarifas dentro de los límites configurados en Limitación de tarifas pasará por las dos primeras capas sin fricción. Lo que genera este tipo de tráfico es la huella digital del comportamiento: patrones de navegación que no existen en sesiones humanas, ausencia de eventos del mouse antes del envío, secuencias de solicitud sin los activos auxiliares que cargaría un navegador real, uso de huellas digitales TLS asociadas con pilas de automatización. Bot Management puntúa cada sesión en esta dimensión de comportamiento y actúa en función de la puntuación, independientemente de la carga útil y la velocidad.

Cómo pasa el relleno de credenciales a través de WAF y por qué se populariza la limitación de velocidad

El ataque que mejor ilustra la necesidad de las tres capas es el relleno de credenciales con una cadencia controlada. El atacante tiene una lista de credenciales filtradas de otros servicios y prueba cada par con el punto final de inicio de sesión de su aplicación, no en ráfagas, sino metódicamente, de 3 a 5 intentos por minuto por IP. Utiliza servidores proxy residenciales para distribuir intentos y garantiza que ninguna IP individual vaya más allá de límites obvios.

Desde la perspectiva de la WAF, este ataque es invisible. La solicitud de inicio de sesión es un POST con campos de correo electrónico y contraseña, estructuralmente idéntico a lo que enviaría cualquier usuario legítimo. La contraseña incorrecta no es una carga útil maliciosa; es solo texto que fallará autenticación. No hay ninguna firma que WAF pueda reconocer.

Con Rate Limiting, configura una regla en el punto final /login con una ventana de tiempo y un límite de intentos por IP. Cinco solicitudes en diez segundos activan Block. Tres solicitudes en quince minutos en el punto final de recuperación de contraseña, lo mismo. El atacante que calibró su bot para que estuviera por debajo de este umbral aún logrará pasar, pero usted ha eliminado la capa más barata de relleno de credenciales: los scripts que simplemente se activan sin control de cadencia.

Lo que Rate Limiting no resuelve es que el atacante lo distribuya entre suficientes IP para mantenerse por debajo del límite en cada una. Aquí es donde entra en juego Bot Management: incluso si cada IP individual solo hace dos intentos, la puntuación de comportamiento de la sesión indicará automatización.

La arquitectura del producto y lo que desbloquea cada plan

Rate Limiting es un producto independiente de WAF: no son reglas dentro del mismo sistema, son sistemas con lógica y configuraciones independientes. Esta distinción es importante al configurar, porque los equipos acostumbrados a trabajar solo con reglas WAF a menudo buscan la limitación de velocidad en el lugar incorrecto de la interfaz.

Las dimensiones de control disponibles en Rate Limiting incluyen IP, combinación de IP y ruta, cookie específica y agente de usuario. Las acciones son Bloquear, Desafío y Registrar, siendo Registrar el equivalente al modo de vigilancia de WAF, útil para calibrar umbrales antes de activar el bloqueo en producción.

El plan gratuito de Cloudflare permite una única regla de limitación de velocidad. Pro ($20/mes) incluye hasta cinco reglas. El negocio se para al cien. Enterprise elimina el límite de reglas y desbloquea la administración de bots completa, incluido el acceso a cf.bot_management.score como variable en las expresiones de reglas: un número entre 0 y 99 donde los valores más bajos indican más tráfico automatizado.

En Pro, el equivalente de Bot Management es el modo Super Bot Fight: una configuración simplificada que bloquea bots definitivamente automatizados, desafía a los probablemente automatizados y permite el paso del tráfico verificado. No accede a la puntuación numérica ni escribe reglas basadas en ella, pero la cobertura contra las categorías de bots más comunes está activa.

Qué cubre en la práctica la combinación del plan Pro

Por 20 dólares al mes, una aplicación web con una mínima atención a la configuración puede cubrir la mayor parte de la superficie de ataque automatizado. WAF con conjuntos de reglas administrados por Cloudflare en modo Bloque para OWASP nivel 1 intercepta SQLi, XSS, recorrido de ruta y explotación de CVE conocidos. Las cinco reglas de limitación de velocidad cubren puntos finales críticos: inicio de sesión con un límite de cinco solicitudes en diez segundos por IP, recuperación de contraseña con tres solicitudes en quince minutos, registro de cuenta con diez solicitudes en una hora, punto final de pago con diez solicitudes en una hora y API raíz con cien solicitudes por minuto. El modo Active Super Bot Fight bloquea el volumen de robots que no tienen la suficiente sofisticación para disfrazar su comportamiento.

Lo que esta combinación no cubre son bots con comportamiento genuinamente humano: sesiones que navegan a una velocidad plausible, con patrones sintéticos pero convincentes de mouse y teclado, usando IP domésticas con historiales limpios. Este nivel de sofisticación es costoso para el atacante y poco común en ataques dirigidos a aplicaciones que no son objetivos de alto valor. Para la mayoría de las aplicaciones web, el espacio que queda en Pro es aceptable.

¿Dónde tiene sentido escalar a Business o Enterprise?

La decisión de actualizar es una ecuación de riesgo y costo, no de ambición tecnológica. Business justifica el salto, especialmente si necesita más de cinco reglas de limitación de velocidad: una aplicación con docenas de puntos finales sensibles agotará el límite Pro rápidamente. Cien reglas en Negocios resuelven este problema sin llegar a la inversión empresarial.

La empresa tiene sentido cuando el perfil de amenaza incluye adversarios con capacidades para eludir la detección simplificada: fraude financiero sofisticado, competidores sistemáticamente raspando precios con robots que imitan el comportamiento humano o relleno de credenciales altamente distribuidas contra un servicio de alto valor. El acceso a la puntuación numérica de Bot Management le permite crear reglas con una granularidad que el modo Super Bot Fight no ofrece: bloquear por encima de 30, desafiar entre 30 y 60, permitir por encima de 60, con lógica adicional mediante ruta o método HTTP. Esta expresividad tiene un costo, y el costo sólo se justifica cuando el riesgo mitigado es proporcional.