El tráfico de bots y abuso a menudo no aparece como una ráfaga, sino como un comportamiento lento y sostenido. Una IP puede estar haciendo 30-50 solicitudes por minuto; eso por sí solo no es una catástrofe, pero cuando continúa durante 10 minutos puede convertirse en scraping, automatización o intento de contraseñas. El rate-limit instantáneo no siempre captura correctamente el carácter de este comportamiento distribuido en el tiempo.
Las firmas WAAP resuelven una pregunta diferente: ¿esta solicitud coincide con un patrón de ataque conocido? Patrones de contenido malicioso como SQL injection, XSS o command injection pueden capturarse. Pero el scraping, el seguimiento de precios, los intentos de cuenta o el uso agresivo de API que parecen legítimos pero generan tráfico intenso pueden eludir la protección basada en firmas.
Entre estos dos enfoques se necesita un modelo de aislamiento temporal. Si una fuente determinada ha mostrado un comportamiento que supera el umbral en los últimos N minutos, debe ponerse en cuarentena durante M minutos sin ser baneada permanentemente. Durante este periodo su tráfico puede bloquearse, llevarse a una página explicativa o redirigirse a otro flujo. Cuando expira el periodo, la fuente se libera automáticamente.
Este modelo requiere dos mecanismos independientes: la ventana de observación que mide el comportamiento y la ventana de cuarentena que aplica el aislamiento. La observación puede ser corta y la cuarentena más larga; o, según la sensibilidad de la aplicación, puede elegirse lo contrario. La acción tampoco debe ser de un solo tipo: para algunas fuentes puede ser más adecuado el bloqueo silencioso, para otras una página explicativa y para otras una redirección.
La Cuarentena de Tráfico de TR7 ofrece este modelo: dos ventanas de tiempo independientes para observación y cuarentena, cuatro tipos de clave, tres tipos de acción, la posibilidad de usar el estado de cuarentena como condición en otras reglas y visibilidad en vivo con intervención manual desde la pantalla del vService.
La Cuarentena de Tráfico de TR7 combina la observación del comportamiento con el aislamiento temporal en el mismo motor de políticas.
En cada regla de cuarentena se definen por separado la ventana de observación y la ventana de cuarentena. La ventana de observación mide el comportamiento de la fuente; la ventana de cuarentena determina cuánto durará la acción una vez superado el umbral.
La fuente no tiene por qué identificarse únicamente como IP. Con las opciones IP, IP + user agent, Host + IP y Host + IP + user agent se logra una distinción más precisa en escenarios de múltiples dominios, NAT y multi-tenant.
Durante la cuarentena, el tráfico puede bloquearse, redirigirse a otra URL o mostrarse una página de contenido personalizada. Así se puede aplicar un bloqueo silencioso al tráfico atacante, un mensaje explicativo al usuario real o una redirección acorde al flujo de trabajo.
Una fuente puesta en cuarentena se convierte en una señal de estado utilizable en todo el sistema. Otras reglas de tráfico, redirección y contenido pueden usar esta señal como condición para construir políticas compuestas.
La Cuarentena de Tráfico reúne la observación del comportamiento, el aislamiento temporal y el control del operador en un único modelo de funcionamiento.
En cada regla se ajustan de forma independiente el periodo de observación y el periodo de cuarentena. Dentro de la ventana de observación se contabiliza el comportamiento de la fuente; cuando se supera el umbral, la fuente se mantiene en una lista aparte durante la ventana de cuarentena. Cuando expira el periodo, el registro se elimina automáticamente. Esta estructura proporciona un aislamiento controlado y temporal en lugar de un baneo permanente.
La opción `ip` proporciona la observación clásica basada en la IP de origen. `ipUa` distingue los diferentes user agents detrás de la misma IP. `hostIp` cuenta por separado, en entornos de múltiples dominios, el comportamiento de la misma IP hacia distintos hosts. `hostIpUa` proporciona la distinción más granular en entornos multi-tenant y multi-cliente.
El operador puede definir un umbral para el número de solicitudes en una ventana de tiempo determinada. Reglas como "más de 100 solicitudes en los últimos 10 minutos" inician una cuarentena basada en comportamiento. La decisión no se basa en una sola solicitud, sino en el comportamiento total dentro de la ventana. A diferencia del rate-limit, este enfoque se basa en la observación.
La acción `block` se usa para descartar silenciosamente el tráfico de la fuente en cuarentena. En el tráfico de bots y automatización este comportamiento suele ser más eficaz; el atacante no recibe una respuesta clara de la aplicación. Esta acción es adecuada para escenarios de abuso de alto riesgo donde no es necesario mostrar una explicación. El impacto sobre usuarios reales puede seguirse desde la pantalla de monitor del vService.
`showContent` devuelve un código de estado HTTP y un contenido específicos a la fuente en cuarentena. Por ejemplo, puede mostrarse una página que explique que está limitada temporalmente por exceso de solicitudes. Este modelo se comporta de forma más suave que el bloqueo en escenarios donde existe posibilidad de falso positivo o donde la experiencia de usuario es importante. El contenido del mensaje puede prepararse según el lenguaje de soporte y de marca de la organización.
`redirect` se usa para redirigir la fuente en cuarentena a una URL diferente. El destino puede ser una página CAPTCHA, un portal explicativo, una página de upgrade de suscripción o una página de soporte. Así la cuarentena se convierte no solo en una herramienta de bloqueo, sino también en un medio para llevar al usuario al flujo de trabajo correcto. En escenarios multi-tenant y SaaS esta opción es especialmente valiosa.
Que una fuente esté en cuarentena puede usarse como condición en otras reglas. Las fuentes en cuarentena pueden redirigirse a un backend diferente, recibir cabeceras especiales, ver una respuesta de contenido especial o entrar en el alcance de una segunda regla más estricta. Esta función convierte una sola regla de cuarentena en una señal que desencadena un cambio de comportamiento en todo el sistema. Es uno de los puntos diferenciadores más importantes de TR7.
La Cuarentena de Tráfico puede usarse tanto para servicios HTTP como TCP. En el lado HTTP se observa el comportamiento basado en solicitudes, mientras que en el lado TCP la decisión se toma a nivel de conexión. El resultado técnico de la acción puede variar según el protocolo; pero el modelo básico es el mismo: observar, poner en aislamiento temporal a quien supere el umbral y liberar cuando expire el periodo.
En la pantalla de monitoreo en vivo del vService se listan las fuentes activas en cuarentena. El operador puede ver qué clave, por qué regla y durante cuánto tiempo está en cuarentena. En caso de falso positivo o usuario prioritario, puede realizarse una extracción manual. Como los registros que expiran se limpian automáticamente, la intervención manual no es obligatoria.
Bajo el mismo vService pueden trabajar juntas varias reglas de cuarentena. Por ejemplo, mientras la primera regla muestra una página de advertencia ante exceso de solicitudes, la segunda regla puede bloquear durante más tiempo la fuente que aún continúa. Se admiten 5 reglas de cuarentena en paralelo por vService. Esta estructura crea un control de abuso que avanza de lo suave a lo severo.
La Cuarentena de Tráfico se gestiona operativamente junto con el ciclo de vida de la tabla, el comportamiento en clúster, el efecto de la recarga, la pantalla de monitoreo y los registros de auditoría.
Cada regla de cuarentena utiliza dos áreas de monitoreo en vivo independientes para observación y cuarentena. Los registros se mantienen por tiempo y se limpian automáticamente cuando expira el TTL. A medida que llegan nuevas solicitudes, se actualiza el comportamiento de la ventana de observación. Esta estructura mantiene la cuarentena como un control de comportamiento temporal, no como un baneo permanente.
En cada solicitud se calcula primero la fórmula de clave, luego se actualiza el valor de observación y se evalúa la condición de cuarentena. Si la fuente ya está en cuarentena, se aplica la acción definida. Si la fuente no está en cuarentena, el flujo de tráfico normal continúa. La decisión se produce en la ruta de datos con bajo coste.
En instalaciones de doble nodo, las tablas de cuarentena pueden diseñarse para funcionar de forma local o sincronizada. Si la sincronización no está activa, tras el failover el nuevo nodo activo reconstruye el historial de cuarentena desde cero. Cuando la sincronización está activa, el estado de cuarentena puede conservarse tras el failover. Esta elección debe evaluarse según la necesidad operativa y el modelo de instalación.
Las tablas de cuarentena se mantienen en memoria y no se comportan como una blacklist permanente. Tras una recarga suave o un reinicio de tabla, el estado de cuarentena activo puede limpiarse. Este es un comportamiento aceptable, porque la cuarentena es un mecanismo de aislamiento temporal. Si se requiere un baneo de larga duración, debe usarse junto con feeds de reputación de IP.
En la pantalla de monitor del vService se ven los registros de cuarentena activos y el operador puede extraer una fuente determinada de la cuarentena. Esta operación elimina el registro de la tabla; la siguiente solicitud se evalúa en el flujo normal. Proporciona una intervención rápida en caso de usuario VIP, falso positivo o solicitud de soporte.
Los eventos de puesta en cuarentena y de salida de cuarentena pueden escribirse en los registros de auditoría. Si el SIEM log streaming está activo, los eventos pueden enviarse a un colector externo. Posteriormente puede examinarse qué clave, por qué regla, con qué acción y durante cuánto tiempo se puso en cuarentena.
El número de claves activas y el tipo de clave afectan al consumo de memoria. Las claves basadas en IP son más simples, mientras que las claves combinadas como Host + IP + user agent consumen más espacio. Como se admiten 5 reglas de cuarentena en paralelo por vService, el plan de capacidad debe hacerse según el perfil de tráfico.
Un sitio de e-commerce puede observar las fuentes que hacen scraping de precios con la clave `ipUa`. La combinación IP + user agent que supera las 100 solicitudes en 5 minutos se bloquea durante 30 minutos; los distintos usuarios reales detrás de la misma IP pueden evaluarse como claves separadas.
Un portal bancario puede observar los intentos repetidos en el endpoint de login por IP o IP + user agent. Cuando se supera el umbral, la fuente se lleva durante 60 minutos a una página explicativa y se le muestra al usuario real el motivo de la restricción temporal.
Una plataforma SaaS que aloja múltiples dominios puede observar por separado el tráfico de cada tenant con la clave `hostIp`. El uso agresivo de un tenant puede llevarse a una acción de redirección o bloqueo temporal sin afectar al tráfico de los demás tenants.
La primera regla redirige a una página de advertencia durante 10 minutos a la fuente que envía demasiadas solicitudes. Si la fuente sigue generando tráfico estando en cuarentena, entra en juego la segunda regla y aplica un bloqueo de 60 minutos. Que el estado de cuarentena sea condición en otras reglas hace posible este modelo escalonado.
Aislamiento temporal basado en comportamiento, estructura de reglas compuestas y visibilidad en vivo para el operador. Veamos juntos cómo funciona en su propio entorno.