Solicitudes limitadas de velocidad * un * no autenticadas

Digamos que tenemos un equilibrador de carga que también limita la velocidad. La limitación de velocidad parece bastante sencilla para los usuarios que han iniciado sesión: solo mire el JWT y tal vez use un almacén de datos en memoria para ver cuántas solicitudes en ese último 10 segundos para ese usuario.

Sin embargo, ¿qué pasa con los usuarios no registrados (no autenticados)? No sabemos con certeza quiénes son o de dónde proviene exactamente la solicitud, por lo que no podemos limitar fácilmente esas solicitudes o ...

¿Hay soluciones integradas para esto en AWS y otras plataformas de alojamiento? ¿Es algo de lo que debemos preocuparnos? Parece que necesitamos manejar la lógica de limitación de velocidad de los usuarios registrados manualmente, pero ¿qué pasa con los usuarios no registrados?

Mi conjetura / esperanza es que podría haber algún mecanismo incorporado para limitar las solicitudes no autenticadas de limitación de velocidad en las plataformas de alojamiento, infórmenos a todos.

Sin embargo, ¿qué pasa con los usuarios no registrados (no autenticados)? No sabemos con certeza quiénes son o de dónde proviene exactamente la solicitud, por lo que no podemos limitar fácilmente esas solicitudes o ...

Hay un par de enfoques que puede tomar. Una es que necesita un identificador de origen razonablemente confiable, por ejemplo, una dirección IP. Puede calificar el límite por dirección IP, de modo que los ataques en una sola máquina comprometida serán limitados. Este es un enfoque bastante simple, pero existe el inconveniente de que hay grandes proveedores de red que solo pueden usar direcciones IP salientes únicas para ocultar una gran cantidad de usuarios detrás de un NAT.

Otro enfoque para limitar la velocidad que puede adoptar es exigir una prueba de trabajo para cualquier solicitud no autenticada. Su servidor emite un código de desafío que cualquier cliente que realice una solicitud no autenticada (por ejemplo, solicitudes de inicio de sesión) debe calcular una respuesta intensiva de recursos antes de que se procese la solicitud. Una implementación común de esta idea requiere que los clientes calculen una reversión hash parcial.

Para saber si una solicitud es de un usuario autenticado o de un usuario anónimo, necesariamente debe procesar la solicitud (aunque rápidamente). Esto todavía significa que su aplicación es vulnerable a un ataque de denegación de servicio.

Debe verificar las solicitudes generales por segundo, y si se excede un número determinado, simplemente ignore el resto. Ese número debe ser lo suficientemente alto como para no causar problemas durante el funcionamiento normal, pero debe proteger contra tales ataques.

Además, como regla general, probablemente no debería suponer que un ataque no vendría de un usuario autenticado, al menos en lo que respecta a los ataques de DOS. Una contraseña débil permitiría fácilmente que alguien presuma la identidad de un usuario anterior. Entonces, suponiendo que pueda hacer una verificación de este tipo, sus usuarios (humanos) nunca deberían necesitar realizar solicitudes a tales velocidades, a pesar de que simplemente tienen muchos usuarios individuales.

Una de las principales ofertas de Cloudflare es la protección contra ataques de denegación de servicio al proporcionar un proxy inteligente para su API / servidor web. El servicio básico es gratis; ganan dinero con otros servicios relacionados, como los servicios CDN y el equilibrio de carga. También brindan servicios de limitación de tarifas más sofisticados y controlables , actualmente a razón de US $ .05 por cada 10 mil solicitudes válidas (sin cargo por solicitudes rechazadas), pero debe actualizar a planes pagos para obtener más de una regla global.

Puede usar el servicio de Cloudflare con AWS o cualquier otra plataforma siempre que tenga control sobre los servidores de nombres de su dominio (como en, puede cambiar los servidores de nombres registrados para su dominio).

Puede proporcionar límites de velocidad separados para los usuarios anónimos y registrados iniciando sesión a los usuarios registrados a diferentes URL. Por ejemplo, puede simplemente prefijar todas sus rutas URL disponibles de forma anónima con '/ u' para crear un punto final que siempre requiera autenticación y tenga un límite de velocidad diferente.

Tenga en cuenta que la limitación de velocidad de Cloudflare (como toda limitación de velocidad comercial para usuarios anónimos que conozco) define a un cliente por su dirección IP. Esto puede causar problemas a las personas que usan VPN comerciales o Tor, ya que tienden a ocultar una gran cantidad de clientes detrás de 1 dirección IP para mayor privacidad.

En AWS, existen los servicios relacionados AWS Shield y AWS WAF . Están destinados principalmente a prevenir ataques DDoS, pero también ofrecen soporte para limitar la velocidad en función de las direcciones IP.

En WAF, el concepto se llama Reglas basadas en tasas . La prevención de intentos de inicio de sesión basados ​​en fuerza bruta se menciona como un caso de uso en el anuncio original :

Este nuevo tipo de regla protege los sitios web de los clientes y las API de amenazas tales como ataques DDoS de capa web, intentos de inicio de sesión de fuerza bruta y bots defectuosos. Las reglas basadas en tarifas se activan automáticamente cuando las solicitudes web de un cliente exceden un cierto umbral configurable.

Otros proveedores de la nube deberían tener ofertas similares. Aquí hay una comparación tabular: Google Cloud Armor vs. AWS WAF vs. Cloudflare WAF .

Como ya está usando Nginx, usar la limitación de velocidad basada en IP incorporada también podría ser una opción simple. El módulo se llama ngx_http_limit_req_module . Esta publicación de blog describe cómo se puede usar.

Tenga en cuenta que la limitación de velocidad basada en IP es un concepto relativamente simple, pero no es perfecto:

• Las direcciones IP pueden ser compartidas (personas que trabajan en la misma oficina) y dar lugar a falsos positivos.
• Un atacante podría tener acceso fácil a múltiples direcciones IP y usarlas para evitar los límites (ataque de inicio de sesión de fuerza bruta distribuido)

En general, las direcciones IP son un buen comienzo. Pero si necesita una protección más fuerte, sus mejores opciones dependerán de su modelo de hilo (qué tipo de ataques desea evitar).