Limitar una sola IP ya no es suficiente para detener el abuso moderno.
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.
Nuestro enfoque
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.
El modelo de ventana deslizante rastrea el comportamiento real del tráfico
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.
La clave de límite se elige para coincidir con la clase de ataque
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.
El modelo de acción se aplica progresivamente según la gravedad
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.
La arquitectura de contadores en proceso mantiene la latencia baja
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.
Capacidades
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.
Los perfiles de rate limiting integrados ofrecen un punto de partida listo para producció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.
Un límite blando y un techo duro — la respuesta es una subida, no un precipicio
Cada protección lleva dos umbrales. Cruzar el límite blando activa una respuesta medida — retrasar, desafiar, moldear — y solo el techo duro descarta tráfico. El modo observación informa de ambos por separado, de modo que los umbrales se fijan según lo que su tráfico hizo realmente y no según un número supuesto. Un único umbral impone siempre la misma elección: dejar pasar el ataque o descartar a sus clientes con él.
Los tipos de trigger separan solicitudes simples, logins fallidos y puntuación de riesgo
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.
Los alcances de IP, usuario y clave compuesta pueden usarse juntos
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.
La misma solicitud puede evaluarse contra múltiples políticas de rate de forma simultánea
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.
La acción de bloqueo temporal mantiene la clave bloqueada incluso después de que la tasa baje
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.
El CAPTCHA self-hosted enruta el tráfico sospechoso a verificación en lugar de un bloqueo duro
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.
La Regla de Límite de Ancho de Banda habilita el shaping condicional del tráfico
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.
Las variables de sesión AAM permiten el rate limiting por usuario
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.
Profundidad operacional
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.
Dimensionamiento adaptivo de la tabla de contadores
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.
Sincronización multi-instancia
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.
Continuidad de contadores entre recargas
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.
Capa de validación de políticas
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.
Compatibilidad de cadena de acciones
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.
Auditoría y observabilidad
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.
Cuándo usarlo
Límites por usuario y por IP en capas sobre un API gateway
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.
Control de intentos fallidos en un endpoint de login
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.
Protección por endpoint en un flujo de e-commerce
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.
Control de ancho de banda en el tráfico de descarga de archivos
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.
Preguntas frecuentes
¿Un rate limit por IP afecta a los usuarios reales detrás de NAT o salida compartida?
¿Cuál es la diferencia entre la acción de bloqueo y la acción de denegación?
¿Cómo funciona la integración CAPTCHA self-hosted?
¿Puede haber más de una política de rate aplicada al mismo endpoint?
¿La Regla de Límite de Ancho de Banda funciona de manera diferente al conteo de solicitudes?
¿Pueden diferentes instancias en un clúster compartir el mismo contador?
Adapte el rate limiting al contexto de su aplicación
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.