Limitation du débit * demandes non authentifiées *

11

Disons que nous avons un équilibreur de charge qui limite également le débit. La limitation du débit semble assez simple pour les utilisateurs connectés - il suffit de regarder le JWT et peut-être d'utiliser un magasin de données en mémoire pour voir combien de demandes au cours des 10 dernières secondes pour cet utilisateur.

Mais qu'en est-il des utilisateurs non connectés (non authentifiés)? Nous ne savons pas avec certitude de qui ils proviennent ni d'où vient la demande. Nous ne pouvons donc pas facilement limiter ces demandes ou ..?

Existe-t-il des solutions intégrées à cela sur AWS et d'autres plates-formes d'hébergement? Il semble que nous devons gérer manuellement la logique de limitation de débit des utilisateurs connectés, mais qu'en est-il des utilisateurs non connectés?

Je suppose / j'espère qu'il pourrait y avoir un mécanisme intégré pour limiter les taux de demandes non authentifiées sur les plates-formes d'hébergement, veuillez nous en informer tous.

load-balancing nginx rate-limiting

2

Cette page ne mentionne jamais les utilisateurs connectés. En fait, les techniques décrites ici sont citées comme une atténuation des attaques par force brute sur les mots de passe, ce qui implique des utilisateurs qui ne sont pas connectés.

— Robert Harvey

1

Pourquoi voulez-vous utiliser la limitation de débit? Est-ce pour contrer les attaques par déni de service, pour empêcher les utilisateurs de dépasser leur plan de paiement, autre chose? Le cas d'utilisation affecte les méthodes que vous pouvez utiliser efficacement.

— Bart van Ingen Schenau

1

Cette question peut être plus adaptée à security.stackexchange.com , bien que je ne dis pas qu'elle est hors sujet

— Peeyush Kushwaha

@BartvanIngenSchenau tout cela?

Pourquoi devriez-vous avoir deux limites de taux différentes? Vendez-vous des "plans" avec différentes contraintes / fonctionnalités?

— Laiv

9

Mais qu'en est-il des utilisateurs non connectés (non authentifiés)? Nous ne savons pas avec certitude de qui ils proviennent ni d'où vient la demande. Nous ne pouvons donc pas facilement limiter ces demandes ou ..?

Il y a quelques approches que vous pouvez adopter. La première est que vous avez besoin d'un identifiant d'origine raisonnablement fiable, par exemple une adresse IP. Vous pouvez évaluer la limite par adresse IP, de sorte que les attaques sur une seule machine compromise seront limitées. Il s'agit d'une approche assez simple, mais il y a un inconvénient à ce que les grands fournisseurs de réseau ne peuvent utiliser que des adresses IP sortantes uniques pour masquer un très grand nombre d'utilisateurs derrière un NAT.

Une autre approche de limitation de débit que vous pouvez adopter consiste à exiger une preuve de travail pour toute demande non authentifiée. Votre serveur émet un code de défi que tous les clients qui font une demande non authentifiée (par exemple des demandes de connexion) doivent calculer une réponse gourmande en ressources avant le traitement de la demande. Une implémentation courante de cette idée nécessite que les clients calculent une réversion de hachage partielle.

— Lie Ryan
source

Je ne vois pas, comment une "preuve de travail" peut empêcher les attaques DOS? Le client pourrait ignorer le défi et continuer à envoyer des demandes jusqu'à l'échec. Existe-t-il un 3e processus pour relever le défi?

— Laiv

4

@Laiv POW peut être émis et vérifié de manière fiable sans se connecter à une base de données centrale, où la plupart des autres schémas de limitation de débit échouent. Cela augmente le coût d'une attaque pour un attaquant, car l'extension de votre défense et l'augmentation du facteur de charge sont moins chers pour vous et les utilisateurs légitimes que l'extension de l'attaque pour l'attaquant. Il crée une dissuasion économique pour attaquer le système, car il exclut également efficacement les appareils de faible puissance (par exemple, les imprimantes compromises, l'IOT, les routeurs) d'être utilisés comme une plate-forme d'attaque efficace.

— Lie Ryan

6

Pour savoir si une demande provient d'un utilisateur authentifié ou d'un utilisateur anonyme, vous devez nécessairement traiter la demande (quoique rapidement). Cela signifie toujours que votre application est vulnérable à une attaque par déni de service.

Vous devriez vérifier le nombre total de demandes par seconde, et si un certain nombre est dépassé, vous ignorez simplement le reste. Ce nombre doit être suffisamment élevé pour ne pas causer de problèmes pendant le fonctionnement normal, mais doit protéger contre de telles attaques.

De plus, en règle générale, vous ne devriez probablement pas supposer qu'une attaque ne proviendrait pas d'un utilisateur authentifié, du moins pour ce qui concerne les attaques DOS. Un mot de passe faible permettrait facilement à quelqu'un de présumer l'identité d'un ancien utilisateur. En supposant que vous puissiez effectuer une telle vérification, vos utilisateurs (humains) ne devraient jamais avoir à effectuer des demandes à de tels taux, non seulement parce que vous avez de nombreux utilisateurs individuels.

— Neil
source

Je suppose que vous pouvez utiliser des adresses IP et définir une limite de débit élevée pour chacune. Je suppose qu'une attaque DoS bien orchestrée pourrait utiliser des milliers d'adresses IP? peut-être plus? idk ... Je suis conscient que la même adresse IP pourrait être utilisée pour plusieurs clients différents, mais je dirais qu'il y a de fortes chances que ce soit le même utilisateur, non?

— Alexander Mills

@AlexanderMills Supposons bien que vous ayez décidé que l'algoritihm serait de rechercher plusieurs demandes à partir de la même adresse IP. Même s'il y en a des milliers, ils seraient répétés pour plus de 1000 requêtes. Votre serveur enregistre la première demande à partir d'une adresse IP donnée et l'inondation commence .. votre serveur est déjà en attente avec des demandes .. vous ne pouvez même pas traiter suffisamment de demandes pour arriver à la deuxième répétition à partir de la même IP (qui pourrait toujours être une demande légitime au fait). Il protégerait contre les attaques DoS où la même IP est utilisée uniquement. Mieux vaut utiliser les deux si quelque chose. : P

— Neil

0

L'une des principales offres de Cloudflare est la protection contre les attaques par déni de service en fournissant un proxy intelligent pour votre API / serveur Web. Le service de base est gratuit; ils font de l'argent avec d'autres services connexes comme les services CDN et l'équilibrage de charge. Ils fournissent également des services de limitation de taux plus sophistiqués et contrôlables , actuellement au taux de 0,05 $ US pour 10 000 bonnes demandes (sans frais pour les demandes rejetées), mais vous devez passer à des plans payants pour obtenir plus d'une règle globale.

Vous pouvez utiliser le service Cloudflare avec AWS ou toute autre plate-forme tant que vous contrôlez les serveurs de noms de votre domaine (comme dans, vous pouvez modifier les serveurs de noms enregistrés pour votre domaine).

Vous pouvez fournir des limites de taux distinctes pour les utilisateurs anonymes et connectés en dirigeant les utilisateurs connectés vers différentes URL. Par exemple, vous pouvez simplement préfixer tous vos chemins URL disponibles de manière anonyme avec «/ u» pour créer un point de terminaison qui nécessite toujours une authentification et a une limite de débit différente.

Notez que la limitation de débit de Cloudflare (comme toute limitation de débit commerciale pour les utilisateurs anonymes que je connais) définit un client par son adresse IP. Cela peut causer des problèmes aux personnes utilisant des VPN commerciaux ou Tor, car elles ont tendance à cacher un grand nombre de clients derrière 1 adresse IP pour plus de confidentialité.

— Old Pro
source

0

Dans AWS, il existe les services associés AWS Shield et AWS WAF . Ils sont principalement destinés à prévenir les attaques DDoS mais offrent également une prise en charge de la limitation de débit basée sur les adresses IP.

Dans WAF, le concept est appelé règles basées sur les taux . La prévention des tentatives de connexion basées sur la force brute est mentionnée comme cas d'utilisation dans l' annonce d'origine :

Ce nouveau type de règle protège les sites Web et les API des clients contre les menaces telles que les attaques DDoS de la couche Web, les tentatives de connexion par force brute et les mauvais robots. Les règles basées sur les taux sont déclenchées automatiquement lorsque les demandes Web d'un client dépassent un certain seuil configurable.

Les autres fournisseurs de cloud devraient proposer des offres similaires. Voici une comparaison tabulaire: Google Cloud Armor vs AWS WAF vs Cloudflare WAF .

Comme vous utilisez déjà Nginx, l'utilisation de la limitation de débit basée sur IP intégrée peut également être une option simple. Le module est appelé ngx_http_limit_req_module . Ce billet de blog décrit comment il peut être utilisé.

Veuillez noter que la limitation de débit basée sur IP est un concept relativement simple mais il n'est pas parfait:

Les adresses IP peuvent être partagées (personnes travaillant dans le même bureau) conduisant à des faux positifs
Un attaquant pourrait avoir un accès facile à plusieurs adresses IP et les utiliser pour contourner les limites (attaque de connexion par force brute distribuée)

En général, les adresses IP sont un bon début. Mais si vous avez besoin d'une protection renforcée, vos meilleurs choix dépendront de votre modèle de thread (quel type d'attaques vous souhaitez empêcher).

— Philipp Claßen
source