El límite de tasa es una de las herramientas de mitigación DDoS más potentes y una de las que peor se usan. Impone una tasa máxima de peticiones para una identidad dada — normalmente una dirección IP o una sesión — y bien aplicado convierte una inundación en un goteo. Mal aplicado bloquea a tus propios clientes, genera tickets de soporte y enseña a tu equipo a desconfiar del mismísimo control que debería protegerlos. La diferencia entre ambos resultados está casi por completo en la granularidad y los umbrales.
Sobre qué aplicar el límite de tasa
- Por dirección IP: la dimensión más simple, pero débil frente a botnets distribuidas que envían una petición por IP a través de miles de direcciones.
- Por IP + User-Agent: añade una dimensión, aunque el User-Agent se falsifica trivialmente.
- Por token de sesión: preciso para endpoints autenticados, pero irrelevante para páginas públicas anónimas.
- Por ASN: una brocha ancha útil cuando un ataque se concentra en una red a la que no das servicio.
- Por endpoint: límites distintos para /search, /login y /checkout según lo caro que sea servir cada uno.
El problema del umbral
Los umbrales son donde falla la mayoría del límite de tasa. Ponlos demasiado bajos y bloqueas a usuarios legítimos tras el NAT compartido del operador, donde muchas personas reales comparten una IP móvil — un único límite las trata como un solo abusador. Ponlos demasiado altos y un bot que se autorregula justo por debajo del techo pasa directamente. No hay un único número seguro, porque el umbral correcto depende de cómo es realmente el tráfico normal para ese endpoint. La respuesta son umbrales derivados del comportamiento base observado en vez de una cifra global adivinada — mides cómo es lo normal y marcas lo que se aparta de ello.
Un enfoque de dos niveles funciona mejor
Usa un bloqueo duro solo en tasas extremas (digamos, más de 1.000 peticiones por minuto por IP) donde ningún usuario real podría estar de forma plausible, y un desafío suave — un test de JavaScript o CAPTCHA — en tasas moderadas (digamos, más de 50 por minuto por IP). Bloquea en el nivel extremo; desafía, nunca bloquees en duro, en el moderado, para que un falso positivo le cueste a un usuario real un segundo, no el acceso.
Reglas específicas por endpoint
La mayor mejora individual que pueden hacer casi todos los equipos es dejar de usar un único límite global. Una página de listado de productos puede absorber 500 peticiones por minuto sin inmutarse; un formulario de restablecimiento de contraseña que ve cinco por minuto desde una IP ya debería estar disparando alarmas. Los límites de tasa deberían reflejar qué hace y qué cuesta cada endpoint — generosos en páginas baratas, cacheables y públicas, y ajustados en las caras o sensibles como login, checkout y búsqueda.
Cómo lo aplica Akarguard
Akarguard te deja fijar límites de tasa y de conexión por dominio desde el panel y los impone en el edge de proxy inverso, delante de tu origen, de modo que las fuentes abusivas se estrangulan antes de llegar a tu servidor. Como el edge ve tu tráfico de forma continua, los límites pueden ajustarse contra tu base real en vez de una cifra global a ciegas, y el modelo de dos niveles surge de forma natural — las tasas extremas se descartan o se banean en el kernel (mediante la integración fail2ban del edge), mientras que las anomalías moderadas reciben un desafío que los navegadores reales superan de forma invisible. El resultado es una mitigación de inundaciones que no castiga al usuario móvil que comparte una IP de operador con otros mil.