Est-ce une bonne pratique d'interdire une adresse IP si trop de tentatives de connexion sont effectuées à partir de celle-ci?
Puisqu'une adresse IP ne représente pas nécessairement un périphérique spécifique, mais probablement tout un réseau/entreprise/etc. est-il judicieux de bloquer une adresse IP s'il y a une quantité importante de fausses tentatives de connexion?
Je prévoyais de mettre en œuvre la vérification IP ainsi que des essais pour un utilisateur/compte/e-mail spécifique, mais je ne sais pas s'il est préférable de laisser la vérification IP complètement par conséquent.
D'un autre côté cela permet à un attaquant d'essayer à peu près une quantité spécifique de mots de passe pour chaque utilisateur sans jamais être banni (en même temps, empêchant ces utilisateurs de se connecter car leurs comptes seront verrouillé pendant un certain temps).
Quelle est la bonne approche pour empêcher quelque chose comme ça (éventuellement sans utiliser de matériel dédié)?
La réponse à cette question dépend beaucoup de la posture de sécurité de votre site, qui décide si le risque d'accès non autorisé est supérieur ou inférieur au risque de déni de service pour certains utilisateurs.
Pour les sites à haut risque, je pourrais choisir l'option de blocage, en particulier lorsque la plupart des utilisateurs sont susceptibles d'être des utilisateurs à domicile et ont donc probablement des adresses IP distinctes.
Un compromis pourrait être où vous détectez des attaques par devinettes de mot de passe, ajoutez un peu d'anti-automatisation (par exemple CAPTCHA) aux connexions à partir de cette adresse IP pendant un certain temps. Cela a pour effet de rendre l'attaque plus difficile à réaliser tout en ne bloquant pas complètement les utilisateurs légitimes du site.
Si vous obtenez toujours beaucoup de connexions invalides avec le CAPTCHA terminé, il semblerait que vous voyez une attaque plus ciblée (car ils devraient probablement payer pour un service de résolution de CAPTCHA si votre CAPTCHA est bon), et à ce Je serais plus enclin à bloquer l'adresse IP pendant un certain temps et à rediriger les utilisateurs vers un message expliquant le blocage (quelque chose comme "une activité malveillante a été détectée à partir de votre adresse IP, veuillez contacter le support sur [your_support_email_here]).
Comme l'a dit @Rory, cela dépend de votre posture de sécurité, mais si ce n'est pas un site à très haut risque et que vous craignez de bloquer plusieurs utilisateurs qui partagent la même IP, une approche que vous pourriez utiliser serait de suivre le nombre de tentatives de connexion par IP et appliquer une limitation très modérée (pour un humain) qui rendrait une attaque par force brute prohibitive.
Par exemple, si plus de X tentatives à partir d'une adresse IP donnée ont été tentées dans la dernière seconde (où X est votre nombre estimé de tentatives de connexion simultanées par seconde à partir d'une seule adresse IP), envoyez un 4 ( ou mieux, un 429 ) avec un message qui dit quelque chose comme "Trop de tentatives ont été faites récemment, veuillez patienter quelques instants et réessayer."
De cette façon, il est très peu probable qu'un humain ait un problème, même s'il a une adresse IP partagée, tandis que toute attaque par force brute sera limitée à X par seconde, ce qui est des centaines à des milliers de fois plus lent qu'une attaque non limitée. .
Si vous souhaitez le rendre un peu plus sûr sans recourir à l'interdiction automatique, vous pouvez également envoyer un e-mail automatisé pour prendre en charge chaque fois que le seuil de connexion maximal a été atteint un nombre excessif de fois (peut-être 100) à partir d'une seule IP. De cette façon, vous pouvez inspecter les journaux et décider par vous-même si cette adresse IP particulière vaut la peine d'être interdite ou non.
Cette approche troque un peu de sécurité pour la convivialité, car nous évitons les captchas ou toute autre chose qui ralentirait un humain.
Une autre solution réalisable consiste à créer un mécanisme alternatif permettant à l'utilisateur de se connecter. L'utilisateur pourrait utiliser ce mécanisme alternatif lorsque le mécanisme de connexion habituel a été désactivé (en raison d'un trop grand nombre de tentatives de connexion échouées par Mallory)
Ce mécanisme alternatif demanderait généralement beaucoup plus d'informations pour garantir que seul l'utilisateur réel est en mesure de se connecter avec succès. Par exemple, en plus du mot de passe, nous pouvons demander à l'utilisateur d'en fournir un ou plusieurs:
un code SMS
un dongle matériel
un code envoyé à un email (sécurisé)
Ce mécanisme alternatif ne doit pas être limité en taux (sinon Mallory le spammerait simplement avec des ordures pour obtenir un déni de service).
Puisqu'il n'est pas limité en débit, les entrées doivent être suffisamment longues pour résister aux attaques de force brute "infinies".
Je voudrais mentionner un autre problème: cela peut être une catastrophe d'utilisation ...
Ce bloc peut être très ennuyeux (il m'est arrivé plus d'une fois). Prenons le cas d'un fournisseur Internet avec des adresses IPv6 natives où IPv4 n'est disponible que via NAT. Disons qu'il y a 1000 personnes derrière ce NAT, soit 1000 personnes avec la même adresse IP. Si vous interdisez un seul d'entre eux par son adresse (IPv4 la plus probable?), Vous interdirez également les 999 autres personnes. Cela vous semble-t-il une bonne idée? Je ne pense pas. Je ne suis pas sûr des effets secondaires si vous vérifiez l'adresse IPv6.
(le scénario ci-dessus avec IPv4 uniquement sur NAT s'applique au moins à certains grands fournisseurs d'accès Internet en Allemagne)