Comment protéger votre serveur contre les attaques par force brute?
L'une des cyberattaques les plus courantes est Bruteforce, quels sont les mécanismes disponibles pour protéger cette attaque et comment l'industrie applique ces mécanismes pour atténuer les attaques (meilleures pratiques)?
Les attaques par force brute ont deux côtés d'impact. L'une consiste à récupérer les informations d'identification par des séries de devinettes de mot de passe et l'autre consiste à créer un déni de service (DDoS) en lançant un nombre massif de tentatives.
Il existe plusieurs mécanismes utilisés par l'industrie sur une combinaison pour atténuer l'attaque, car la mise en œuvre d'un seul contrôle peut ne pas être adéquate.
Les contrôles d'atténuation possibles pourraient être:
- Verrouillage de comptes basé sur des échecs de connexion continus
- Création d'une pause dans le processus d'authentification après plusieurs échecs de connexion
- IP bloquantes - où plusieurs tentatives de connexion sont lancées pour plusieurs comptes
- Autoriser les utilisateurs à privilèges élevés à se connecter à partir d'une IP/IP particulière
- Tentatives de connexion avec plusieurs noms d'utilisateur à partir d'une adresse IP
- Limiter/bloquer le trafic lorsque les tentatives de connexion à un compte forment plusieurs adresses IP à la fois
- Ralentissez les devinettes en utilisant des cookies de l'appareil (Référence: https://www.owasp.org/index.php/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies )
- Utilisez un CAPTCHA pour empêcher les attaques automatisées
- Utilisez l'authentification à 2 facteurs pour empêcher les attaques
Maintenant, pourquoi il est important d'utiliser une combinaison de contrôles est de s'assurer que les utilisateurs légitimes ne sont pas affectés ou empêchés d'accéder aux ressources.
Par exemple, si nous n'implémentons que le "verrouillage de compte après plusieurs tentatives d'échec", les attaquants peuvent simplement abuser de ce contrôle et simplement verrouiller des milliers de comptes d'utilisateurs en envoyant une série de tentatives de force brute. En conséquence, cela se révèle être un DDoS et les utilisateurs légitimes souffriront de l'accès à leurs ressources.
Par conséquent, il est toujours recommandé d'utiliser une combinaison des contrôles énumérés ci-dessus en fonction du contexte de l'exigence de prévenir l'impact des attaques par force brutale.
Pour empêcher les attaques par force brute, vous pouvez utiliser les approches suivantes:
ralentissement artificiel des tentatives de connexion pendant le sommeil.
C'était quelque peu courant pour les sites Web PHP. Le problème avec cela est bien sûr qu'il prend des ressources sur votre serveur Web.
tilisez des captchas
exiger qu'une connexion doit résoudre un captcha.
limitation de débit
vous pouvez limiter le débit par IP, mais ... il y a aussi NAT ce qui rend cela un peu lourd pour certains utilisateurs finaux. De plus, vous pouvez utiliser d'autres types d'empreintes digitales de l'appareil afin de ne pas bloquer trop d'utilisateurs.
authentification à deux facteurs
vous pouvez même le faire par e-mail. certains utilisateurs finaux détestent cela parce que pour vous connecter, vous devez également vérifier vos e-mails maintenant.
verrouiller le compte après 10 tentatives, puis demander aux utilisateurs de déverrouiller le compte par e-mail
quelque peu faisable, mais cela signifie qu'un attaquant peut verrouiller constamment des comptes.
Edit: il y a aussi un potentiel de phishing (merci pour le commentaire)
hashcash
N'a jamais été très largement adopté. Fondamentalement, vous demandez au client de "casser" partiellement un hachage pour vous (vous spécifiez les premiers n bits et demandez au client de trouver une entrée dont le hachage commence par ces n bits). Vous pouvez rendre cela arbitrairement difficile (comme les 1 sur un ordinateur moderne).
inconvénients: nécessite plus de puissance CPU du client, vous devez également vérifier le hachage qui prend également une partie de la puissance CPU du serveur (bien que beaucoup, beaucoup moins que du client).
externaliser le problème
Utilisez la connexion via Facebook, Google ou autre. Toujours une option ... n'est peut-être pas toujours votre meilleur choix.
Tout le monde n'aime pas cela, car vous risquez de divulguer des informations sur les sites que vos utilisateurs visitent. (pourrait également ne pas être conforme au RGPD si vous êtes dans l'UE?)
détection "humaine"
Outre les captchas, il existe d'autres approches pour distinguer les robots des humains, telles que la vérification de leur agent utilisateur, la vérification des références, la vérification des fonctionnalités prises en charge par leur navigateur, etc., mais il est probablement plus facile d'utiliser simplement un fournisseur CAPTCHA existant qui le fait déjà de toute façon.
Vous pouvez être vraiment créatif avec cela, comme empiler des divs les uns sur les autres et les styliser avec CSS et les modifier avec JS de sorte que la bonne "connexion" soit la seule visible et que les autres ne le soient pas, ce qui signifie qu'un bot a du mal à dire quelle "connexion" est la bonne. C'est amusant de trouver des méthodes pour distinguer les robots des humains ... mais encore une fois ... il est généralement plus facile d'utiliser simplement un service CAPTCHA existant.
Aussi ... en gardant à l'esprit l'accessibilité ... seulement les CAPTCHA d'images rendront l'utilisation impossible pour certaines personnes. Les bons fournisseurs de CAPTCHA fournissent au moins également des CAPTCHA audio. Alors ... ne créez pas votre propre CAPTCHA. Ensuite, il y a des lecteurs d'écran ... que votre "détection humaine" pourrait interférer. (Hm, je ne sais pas si l'utilisation d'un tel fournisseur CAPTCHA externe est compatible GPDR?)
accélération au niveau du résea
Vous pouvez le faire si vous avez la bonne infrastructure. Si vous avez un hébergeur, il pourrait déjà le faire de toute façon après trop de demandes (en tant que protection DoS générale).
pot de miel
Je ne sais pas si quelqu'un le fait dans la pratique, mais essentiellement une fois que vous êtes certain qu'un compte est forcé par une brute, effectuez l'une de leurs tentatives de connexion et donnez-lui un faux site Web convaincant le bot que la connexion a réussi, mais pas effectivement réussi.
Il existe de nombreuses méthodes par lesquelles vous pouvez essayer de déjouer le forçage brut: l'authentification à deux facteurs, les CAPTCHA, la limitation de débit et bien sûr les exigences de complexité pw sont quelques-unes.
La réponse "que dois-je utiliser" sera basée sur votre modèle de risque; si vous êtes un petit site qui ne vaut pas le temps et l'effort de pirater, les règles de limitation de débit et/ou de complexité peuvent être plus que suffisantes. Si vous gérez un site de commerce électronique comme Amazon avec des tonnes de données confidentielles, 2FA peut être plus pertinent.
Vous devez d'abord réfléchir à ce qui est faisable, puis à ce qui est raisonnable à faire compte tenu de vos ressources et de votre niveau de risque.