Vaut-il la peine de bloquer les tentatives de connexion infructueuses

Vaut-il la peine d'exécuter fail2ban , sshdfilter ou des outils similaires, qui mettent sur liste noire les adresses IP qui tentent et échouent de se connecter?

Je l'ai vu argumenter qu'il s'agit d'un théâtre de sécurité sur un serveur "correctement sécurisé". Cependant, je pense que cela fait probablement passer les script kiddies au serveur suivant dans leur liste.

Disons que mon serveur est "correctement sécurisé" et je ne crains pas qu'une attaque par force brute réussisse réellement - ces outils maintiennent-ils simplement mes fichiers journaux propres, ou ai-je un avantage valable à bloquer les tentatives d'attaque par force brute?

Mise à jour : Beaucoup de commentaires sur la devinette des mots de passe par force brute - J'ai mentionné que je n'étais pas inquiet à ce sujet. J'aurais peut-être dû être plus précis et demander si fail2ban avait des avantages pour un serveur qui n'autorise que les connexions ssh basées sur les clés.

Le taux de limitation des tentatives de connexion est un moyen facile d'empêcher certaines des attaques de devinettes de mot de passe à grande vitesse. Cependant, il est difficile de limiter les attaques distribuées et beaucoup s'exécutent à un rythme lent sur des semaines ou des mois. Personnellement, je préfère éviter d'utiliser des outils de réponse automatisés comme fail2ban. Et cela pour deux raisons:

1. Les utilisateurs légitimes oublient parfois leurs mots de passe. Je ne veux pas interdire aux utilisateurs légitimes de mon serveur, me forçant à réactiver manuellement leurs comptes (ou pire, essayez de déterminer laquelle des 100/1000 adresses IP interdites est la leur).
2. Une adresse IP n'est pas un bon identifiant pour un utilisateur. Si vous avez plusieurs utilisateurs derrière une seule adresse IP (par exemple, une école qui exécute NAT sur 500 machines pour étudiants), un seul utilisateur faisant quelques mauvaises suppositions peut vous amener dans un monde de douleur. En même temps, la majorité des tentatives de devinettes de mots de passe que je vois sont distribuées.

Par conséquent, je ne considère pas fail2ban (et les outils de réponse automatisés similaires) comme une très bonne approche pour sécuriser un serveur contre les attaques par force brute. Une règle IPTables simple définie pour réduire le spam de journal (que j'ai sur la plupart de mes serveurs Linux) est quelque chose comme ceci:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Il empêche plus de 4 tentatives de connexion d'une seule IP à ssh en 60 secondes. Le reste peut être géré en s'assurant que les mots de passe sont raisonnablement solides. Sur les serveurs haute sécurité, forcer les utilisateurs à utiliser l'authentification par clé publique est un autre moyen d'arrêter de deviner.

Des outils comme fail2ban aident à réduire le trafic réseau inutile et à garder les fichiers journaux un peu plus petits et plus propres. Ce n'est pas un gros problème de sécurité, mais facilite un peu la vie d'administrateur système; c'est pourquoi je recommande d'utiliser fail2ban sur des systèmes où vous pouvez vous le permettre.

Il ne s'agit pas seulement de réduire le bruit - la plupart des attaques ssh essaient de deviner par brute-force les mots de passe. Donc, même si vous verrez beaucoup de tentatives ssh échouées, peut-être au moment où il obtient la 2034e tentative, il se peut qu'elles obtiennent un nom d'utilisateur / mot de passe valide.

La bonne chose à propos de fail2ban par rapport à d'autres approches est qu'il a un effet minimal sur les tentatives de connexion valides.

Eh bien, cela permet d'économiser quelque peu votre réseau contre les attaques par déni et d'économiser sur la charge de traitement des échecs.

Ne pas être le serveur le plus faible d'une liste de script kiddies est toujours une bonne chose.

Désolé, mais je dirais que votre serveur est correctement sécurisé si votre sshd refuse les tentatives d'authentification avec des mots de passe.

PasswordAuthentication no