La limitación de velocidad es una estrategia para limitar el tráfico de red. Pone un tope a la frecuencia con la que alguien puede repetir una acción en un determinado marco de tiempo, por ejemplo, intentar iniciar sesión en una cuenta. La limitación de velocidad puede ayudar a detener ciertos tipos de actividades de bots maliciosos. También puede reducir la presión sobre los servidores web. Sin embargo, la limitación de velocidad no es una solución completa para gestionar la actividad de los bots.

El rate limit es el término anglosajón que se utiliza en la jerga técnica para limitar el número de peticiones HTTP que recibe un sitio web o una API en un periodo de tiempo determinado. Se conoce también como rate limiting o throttling. Esta restricción puede estar basada en la dirección IP del cliente (en Transparent Edge, la cabecera True-Client-IP), una cookie, una URL o cualquier otra opción que tenga sentido para tu site.

Limitar el tráfico sirve para bloquear usuarios o aplicaciones que están haciendo un uso excesivo de la plataforma y pueden, por ende, poner en riesgo la disponibilidad de los recursos y la seguridad de la web. Esto incluye la detección de determinados ataques de bots maliciosos que aumentan la presión sobre los servidores web.

El rate limit es fundamental para asegurar la continuidad del servicio. Además, ayuda a mitigar ataques de fuerza bruta y ataques de credential guessing. También evita sobrecostes a las empresas en las infraestructuras cloud. Durante nuestros ejercicios de pentest, de hecho, hemos detectado riesgos que habrían podido llevar a empresas a cerrar debido a esta ausencia de control.

¿Cómo funciona la limitación de velocidad?

La limitación de velocidad se ejecuta dentro de una aplicación, en lugar de ejecutarse en el propio servidor web. Normalmente, la limitación de velocidad se basa en el seguimiento de las direcciones IP de las que proceden las solicitudes y en el seguimiento del tiempo que transcurre entre cada solicitud. La dirección IP es la principal forma en que una aplicación identifica quién o qué está realizando la solicitud.

Una solución de limitación de velocidad mide la cantidad de tiempo entre cada solicitud de cada dirección IP, y también mide el número de solicitudes en un período específico. Si hay demasiadas solicitudes de una sola IP en un período determinado, la solución de limitación de velocidad no atenderá las solicitudes de la dirección IP durante un tiempo determinado.

En esencia, una aplicación con límite de velocidad dirá, "Oye, baja la velocidad," a los usuarios únicos que están realizando solicitudes a mucha velocidad. Esto es comparable a un agente de policía que para a un conductor por exceder el límite de velocidad establecido en esa carretera, o a un padre que le dice a su hijo que no coma tantos caramelos en tan poco tiempo.

Cómo saber qué límite de tráfico poner en mi página web o API

No existe una cifra de referencia, ya que el tráfico no es igual para una página institucional que para la  portada de un diario deportivo. 

Nuestra recomendación es fijar un límite sobre el registro de tráfico habitual, evitando ser demasiado restrictivos para no dejar fuera a personas que están haciendo un uso responsable de la página. 

Además, conviene revisar la regla si se prevé algún pico de tráfico como podría ser el periodo de rebajas para un e-commerce.

Un ejemplo real de rate limit

Twitter establece una tasa de uso responsable para aliviar la carga de su infraestructura. Sus límites incluyen acciones de todos los dispositivos, incluida la API. Si un usuario utiliza varias aplicaciones de terceros en su cuenta, como un software de gestión de contenidos, alcanzará el límite de forma más rápida que un usuario que solo accede desde la API oficial.

Precisamente, hace un tiempo conocíamos el bloqueo de Tweetbot por incumplimiento de reglas de uso de la API de Twitter.

¿Qué tipos de ataques de bots se detienen con la limitación de la velocidad?

La limitación de velocidad se suele emplear para impedir que los bots perjudiciales afecten de forma negativa a un sitio web o aplicación. Entre los ataques de bots que la limitación de velocidad puede ayudar a mitigar se incluyen:

• Ataques de fuerza bruta
• Ataques DoS y DDoS
• Apropiación web

La limitación de velocidad también protege contra el uso excesivo de la API, lo cual no es necesariamente malicioso ni se debe a la actividad de los bots, pero que en cualquier caso conviene prevenir.

429 Too Many Requests

El código de estado de respuesta de error de cliente HTTP 429 Demasiadas solicitudes indica que el cliente ha enviado demasiadas solicitudes en un tiempo determinado. Este mecanismo de pedir al cliente que reduzca el ritmo de solicitudes se denomina comúnmente «limitación de velocidad».

Se puede incluir una cabecera Retry-After en esta respuesta para indicar cuánto tiempo debe esperar el cliente antes de volver a realizar la petición.

Las implementaciones de la limitación de velocidad varían; las restricciones pueden ser a nivel de servidor o por recurso. Normalmente, las restricciones de velocidad se basan en la IP del cliente, pero pueden ser específicas para usuarios o aplicaciones autorizadas si las solicitudes están autenticadas o contienen una cookie.

¿Qué es el código de estado HTTP 429?

En la comunicación basada en web, los códigos de estado HTTP desempeñan un papel vital como medio a través del cual un servidor comunica el estado de la solicitud de un cliente. El Código de Estado HTTP 429, coloquialmente conocido como «Demasiadas Peticiones», es uno de esos códigos, que cumple un papel único y específico dentro de este paradigma de comunicación.

El código 429 forma parte de la clase 4xx de códigos de estado HTTP, diseñados para indicar errores del cliente. Estos códigos existen en el rango de 400-499, y cada código transmite un mensaje específico sobre un fallo generado por el cliente, a menudo relacionado con una sintaxis de solicitud errónea o parámetros de solicitud no rellenables debido a algún error atribuido al cliente.

En concreto, el código de estado HTTP 429 denota que el cliente ha enviado un número excesivo de peticiones en un periodo de tiempo determinado. La función principal de este código de estado es salvaguardar la integridad de los servicios y servidores web frente a una posible avalancha de peticiones. Esta avalancha puede ser intencionada, como se ve en los ataques de Denegación de Servicio Distribuido (DDoS), o no intencionada, como cuando un script o aplicación se comporta mal y envía peticiones repetidas en un corto periodo de tiempo.

Cuando un servidor devuelve un estado 429, está enviando un mensaje claro al cliente: «Tu tasa de peticiones es demasiado alta. Tienes que ir más despacio». La mayoría de las veces, este código de estado va acompañado de una cabecera Retry-After, que sugiere el número de segundos que el cliente debe esperar antes de volver a enviar una solicitud.

NGINX Rate Limiting - Prevenir ataques DoS & DDoS

Una de las características más útiles, pero a menudo mal entendida y mal configurada, de NGINX es la limitación de velocidad. Permite limitar la cantidad de peticiones HTTP que un usuario puede realizar en un periodo de tiempo determinado. Una solicitud puede ser tan simple como una solicitud GET para la página principal de un sitio web o una solicitud POST en un formulario de inicio de sesión.

La limitación de velocidad puede utilizarse con fines de seguridad, por ejemplo, para ralentizar los ataques de fuerza bruta para adivinar contraseñas. Puede ayudar a proteger contra DoS y DDoS limitando la tasa de peticiones entrantes a un valor típico para usuarios reales, y (con registro) identificar las URLs objetivo. De forma más general, se utiliza para proteger los servidores de aplicaciones upstream de ser abrumados por demasiadas peticiones de usuarios al mismo tiempo.

¿Cómo funciona la limitación de velocidad de NGINX?

La limitación de velocidad de NGINX utiliza el «algoritmo del cubo con fugas», ampliamente utilizado en telecomunicaciones y redes informáticas de conmutación de paquetes para hacer frente a las ráfagas cuando el ancho de banda es limitado. La analogía es con un cubo en el que el agua se vierte por la parte superior y se filtra por la parte inferior; si la velocidad a la que se vierte el agua supera la velocidad a la que se filtra, el cubo se desborda. En términos de procesamiento de solicitudes, el agua representa las solicitudes de los clientes, y el cubo representa una cola donde las solicitudes esperan a ser procesadas según un algoritmo de programación FIFO (primero en entrar, primero en salir). Las fugas de agua representan las solicitudes que salen del búfer para ser procesadas por el servidor, y el desbordamiento representa las solicitudes que se descartan y nunca se atienden.

La limitación de velocidad se configura con dos directivas principales, limit_req_zone y limit_req, como en este ejemplo:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {

    location /login/ {

        limit_req zone=mylimit;

        proxy_pass http://my_upstream;

    }

}

La directiva limit_req_zone define los parámetros para la limitación de velocidad mientras que limit_req habilita la limitación de velocidad dentro del contexto en el que aparece (en el ejemplo, para todas las peticiones a /login/).

En el ejemplo es la variable NGINX $binary_remote_addr, que contiene una representación binaria de la dirección IP de un cliente. Esto significa que estamos limitando cada dirección IP única a la tasa de peticiones definida por el tercer parámetro. (Usamos esta variable porque ocupa menos espacio que la representación de cadena de una dirección IP de cliente, $remote_addr).

Zone define la zona de memoria compartida utilizada para almacenar el estado de cada dirección IP y la frecuencia con la que ha accedido a una URL de petición limitada. Mantener la información en memoria compartida significa que puede ser compartida entre los procesos worker de NGINX. La definición tiene dos partes: el nombre de la zona identificado por la palabra clave zone=, y el tamaño que sigue a los dos puntos. La información de estado para unas 16.000 direcciones IP ocupa 1 ;megabyte, por lo que nuestra zona puede almacenar unas 160.000 direcciones.

En el ejemplo, la tasa no puede superar las 10 peticiones por segundo. NGINX rastrea las peticiones en milisegundos, por lo que este límite corresponde a 1 petición cada 100 milisegundos (ms).

Así que ahora cada dirección IP única está limitada a 10 peticiones por segundo para /login/ - o más exactamente, no puede hacer una petición para esa URL en los 100ms siguientes a la anterior. Esa es una forma de prevenir ataques DoS con NGINX.

Fuentes:

https://www.transparentedge.eu/blog/que-es-el-rate-limit-y-por-que-debes-limitar-el-trafico-a-tu-site/

https://doc.traefik.io/traefik/middlewares/http/ratelimit/

https://www.haproxy.com/blog/four-examples-of-haproxy-rate-limiting

https://medium.com/@mohan.velegacherla/nginx-rate-limiting-preventing-dos-ddos-a208f9179b6e