El rate limiting tradicional se aplica habitualmente como un conteo de solicitudes por dirección IP. Ese modelo es simple, pero NAT, redes de operadores, puntos de salida compartidos y gateways anónimos pueden colocar a usuarios legítimos y fuentes de abuso en el mismo bucket. El tráfico elevado desde una sola IP no es siempre un ataque; del mismo modo, el tráfico distribuido de bajo volumen no es siempre inocente.
El comportamiento de las aplicaciones no es uniforme. Una ráfaga corta de solicitudes de recursos durante una carga de página es normal, pero la misma tasa en un endpoint de pago, login o API puede señalar abuso. Un modelo plano de «N solicitudes por minuto» puede tanto perjudicar la experiencia del usuario como dejar pasar ataques genuinos.
El credential stuffing, la enumeración de cuentas y los patrones de bots no pueden leerse únicamente a partir de conteos brutos de solicitudes. Un gran número de intentos fallidos de login en un endpoint de autenticación puede parecer bajo en el tráfico total. Los contadores que no se correlacionan con nombre de usuario, sesión, clave API, cabecera personalizada o comportamiento de respuesta pierden su contexto de seguridad.
La protección de recursos es una preocupación aparte. Incluso cuando clientes distribuidos envían solicitudes a una tasa baja por cliente, la carga agregada puede agotar el pool de conexiones de un backend, la infraestructura de búsqueda o la capacidad de descarga de archivos. El rate limiting es necesario no solo para detener a un atacante, sino para distribuir la capacidad del backend de forma justa y controlada.
El enfoque de TR7 eleva el rate limiting de un umbral IP-blunt a una política de seguridad controlada que puede aplicarse a través de dimensiones de usuario, endpoint, sesión, clave API, clave compuesta y ancho de banda.
TR7 implementa el rate limiting como un control WAAP multidimensional diseñado alrededor del alcance, el modelo de contador y la selección de acción trabajando juntos.
TR7 rastrea tasas de solicitudes, conexiones, errores y ancho de banda dentro de una ventana de tiempo configurable. Diferentes duraciones de ventana permiten evaluar de forma independiente los picos de corta duración y la alta carga sostenida.
Se pueden crear distintos alcances usando IP, IP y user agent, nombre de usuario, clave API, cookie, cabecera o claves compuestas. Esto permite capturar el abuso con mayor precisión sin penalizar a los usuarios legítimos detrás de la misma IP.
Una política puede denegar la solicitud, aplicar un bloqueo temporal, redirigir a verificación CAPTCHA o imponer un límite de ancho de banda. No todas las infracciones se tratan con el mismo nivel de respuesta.
Los contadores se mantienen dentro del flujo de datos — no se necesita una llamada a base de datos externa en el momento de la decisión. Los despliegues multi-instancia se soportan mediante sincronización de contadores, permitiendo una aplicación coherente de la política en configuraciones distribuidas.
TR7 Rate Limiting cubre distintos escenarios de abuso — desde políticas de bot predefinidas hasta claves compuestas personalizadas — a través de un único modelo de gestión.
TR7 incluye políticas predefinidas para escenarios comunes de bots y abuso. El perfil `bot_rateLimit` puede devolver HTTP 429 a 300 solicitudes por minuto por IP. `bot_rateLimitStrict` puede aplicar un bloqueo temporal de 5 minutos tras 100 solicitudes por minuto. `bot_rateLimitCaptcha` puede redirigir a un flujo CAPTCHA self-hosted tras 150 solicitudes por minuto.
El tipo `requests` rastrea la tasa bruta de solicitudes. `failedAuthAttempts` maneja los intentos de autenticación fallidos con un contador dedicado. `riskScore` puede tomar decisiones basándose en una puntuación de bot o conductual. `static` se usa para controles incondicionales como CAPTCHA obligatorio en un flujo específico.
El alcance `global` monitorea la carga agregada en todo un servicio. Los alcances `ip`, `ip+ua`, `username` y `composite` crean límites más específicos. La estructura compuesta puede combinar una cabecera personalizada, cookie, clave API o un campo del cuerpo de la solicitud para producir una clave de contador personalizada. Esta flexibilidad permite que las API B2B y las aplicaciones multi-tenant reflejen con mayor precisión los límites de uso real.
Un pool de servicio puede tener múltiples políticas de rate limiting activas al mismo tiempo. Por ejemplo, la misma solicitud puede estar sujeta tanto a un límite DDoS de alcance IP como a un límite de uso justo de alcance usuario. Cada política rastrea su propio contador independiente. Esta estructura permite un modelo de protección por capas en lugar de un único umbral.
Cuando se activa la acción `block`, la clave afectada se mantiene en la tabla de bloqueo durante la duración configurada. Esto impide que un atacante genere una ráfaga corta y regrese inmediatamente tras reducir la velocidad. La `blockDuration` se establece por política. Este modelo proporciona un control más sólido contra oleadas intensas de bots y fuentes de abuso reiterado.
La acción `captcha` puede redirigir el tráfico que ha superado el umbral o ha sido marcado como arriesgado a un flujo de verificación en lugar de cortarlo completamente. El proveedor predeterminado es `tr7Standard`. Tras una verificación exitosa, la solicitud del usuario continúa. Este enfoque ofrece una alternativa más equilibrada al bloqueo en escenarios donde separar a los usuarios reales de la automatización es la prioridad.
TR7 puede rastrear las tasas de ancho de banda de entrada y salida además de los conteos de solicitudes. Con la acción `bwLimit`, el tráfico que coincide con una condición específica puede colocarse bajo su propio límite de ancho de banda. Esto es útil para endpoints de descarga de archivos, endpoints que producen respuestas de gran tamaño o consumo de datos de alto volumen desde una única fuente — manteniendo el backend disponible sin cortarlo completamente.
Información como el nombre de usuario de una sesión AAM puede usarse como clave de rate limiting. Esto permite asignar un límite de uso justo separado a cada usuario tras el login. Los planes gratuitos y de pago, los grupos de usuarios internos y externos, o los distintos niveles de rol pueden estar gobernados por límites diferentes. Esto proporciona un control más preciso en escenarios de API y portal donde los límites basados en IP se quedan cortos.
Para que las políticas de rate limiting sean efectivas, el ciclo de vida de los contadores, el tamaño de las tablas, la sincronización en clúster, la observabilidad y el comportamiento de rollback deben gestionarse con claridad operacional.
Distintos alcances operan con distintos tamaños de tabla. El alcance global usa una única clave mientras que los alcances IP y compuesto pueden contener un número mucho mayor de entradas. Las claves largas como IP combinada con user agent pueden consumir más memoria, por lo que la selección de alcance debe hacerse teniendo en cuenta el perfil de tráfico esperado.
La sincronización de contadores entre instancias está soportada en despliegues en clúster. Las instancias que comparten la misma clave de política pueden descubrirse mutuamente e intercambiar estado de contadores. Esto dificulta que un atacante eluda un límite alternando entre instancias en un entorno con distribución de carga.
El nombramiento estable de tablas vinculado a la identidad de la política ayuda a preservar el estado de los contadores entre ciclos de recarga. Cuando la misma política continúa bajo el mismo nombre, los contadores no se resetean innecesariamente. Esto reduce el riesgo de que se abra una brecha de seguridad durante el mantenimiento o las actualizaciones de configuración.
Las políticas de rate limiting pasan por validación de esquema antes de ser desplegadas. Las definiciones de alcance, tipo de trigger o acción inválidas no pueden entrar en la configuración de producción. Este control reduce el riesgo de que una regla de seguridad mal configurada interrumpa el tráfico en vivo.
La política de bots, las reglas de bloqueo de cuenta y las decisiones WAAP pueden ejecutarse todas sobre la misma solicitud simultáneamente. El orden de prioridad y el comportamiento de coincidencia están gobernados por la configuración. El rate limiting opera por tanto no de forma aislada, sino como parte del pipeline de decisión WAAP más amplio.
En cada activación, se puede registrar el ID de regla, la acción, la clave y la información de tasa. Estos registros pueden reenviarse a un SIEM para análisis de incidentes y generación de informes. Los equipos de operaciones pueden monitorear las claves más frecuentemente activadas, los endpoints más ocupados y las tendencias de bloqueo a lo largo del tiempo.
Las organizaciones que ofrecen API B2B pueden aplicar un límite de plan por usuario y un límite de abuso por IP simultáneamente. TR7 ejecuta en paralelo una política de uso justo de alcance usuario y un límite duro de alcance IP.
Un alto número de entradas de credenciales fallidas en una pantalla de autenticación puede ser un indicador de brute-force. TR7 puede rastrear los fallos usando una clave combinada de nombre de usuario e IP y aplicar acciones escalonadas — CAPTCHA primero, luego un bloqueo temporal.
Una ráfaga corta de solicitudes en páginas de producto puede ser normal, pero el mismo patrón en un endpoint de pago es un riesgo. TR7 puede usar condiciones de endpoint y distintas ventanas de tiempo para limitar el abuso en el checkout sin degradar la experiencia de carga de página.
Una única fuente puede consumir la capacidad de I/O de un backend a través de descargas de alto volumen. TR7 usa la Regla de Límite de Ancho de Banda para limitar ese tráfico condicionalmente, manteniendo el servicio disponible para otros usuarios.
Política de rate multicapa en dimensiones de IP, usuario, clave API y ancho de banda. Permítanos guiarle a través de una configuración en vivo sobre sus propios servicios.