Question Est-il utile de bloquer les tentatives de connexion infructueuses?


Est-ce que ça vaut la peine de courir fail2ban, sshdfilter  ou des outils similaires, quelles adresses IP de la liste noire tentent et ne parviennent pas à se connecter?

Je l'ai vu argumenté qu'il s'agit d'un théâtre de sécurité sur un serveur "correctement sécurisé". Cependant, j'estime que cela incite probablement les enfants de script à passer au serveur suivant dans leur liste.

Supposons que mon serveur soit "correctement sécurisé" et que je ne crains pas une attaque par force brute. Ces outils permettent-ils simplement de garder mes fichiers de journalisation en ordre, ou ai-je un quelconque avantage à bloquer les tentatives d'attaque par force?

Mettre à jour: Beaucoup de commentaires à propos de la conquête forcée des mots de passe par la force brute - j'ai mentionné que cela ne m'inquiétait pas. J'aurais peut-être dû être plus spécifique et me demander si fail2ban avait des avantages pour un serveur qui n'autorise que les connexions ssh basées sur des clés.


14
2017-12-29 10:43


origine


Cette réponse n'est pas un argument approprié, elle ne prétend pas non plus que Fail2Ban est un théâtre de la sécurité. Fail2Ban est une couche, ce n'est ni une panacée, ni suffisante en soi, ni nécessaire. Tout mécanisme de connexion doit avoir une méthode de limitation de débit pour empêcher les attaques brutales et similaires (il n’ya aucune excuse pour permettre à un serveur connecté à Internet d’être brutalement forcé avec le savoir-faire en matière de sécurité d’aujourd’hui). Comment vous choisissez d’obtenir cette limitation de taux, c’est votre choix. - Chris S


Réponses:


La limitation du nombre de tentatives de connexion est un moyen simple d’empêcher certaines des attaques à la recherche de mots de passe à grande vitesse. Cependant, il est difficile de limiter les attaques distribuées et beaucoup tournent à faible allure pendant des semaines ou des mois. Personnellement, je préfère éviter d'utiliser des outils de réponse automatisés tels que fail2ban. Et ceci pour deux raisons:

  1. Les utilisateurs légitimes oublient parfois leurs mots de passe. Je ne veux pas bannir les utilisateurs légitimes de mon serveur, ce qui m'oblige à réactiver manuellement leurs comptes (ou pire, essayez de déterminer laquelle des 100 ou 100 adresses IP interdites leur appartient).
  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 utilise NAT sur 500 ordinateurs d'étudiants), un seul utilisateur qui émet quelques hypothèses peut vous mener à la douleur. Dans le même temps, la majorité des tentatives de détection de mot de passe que je vois sont distribuées.

Par conséquent, je ne considère pas que fail2ban (et des outils de réponse automatisés similaires) soit une très bonne approche pour sécuriser un serveur contre les attaques par force brute. Un simple ensemble de règles IPTables visant à réduire le spam de journalisation (que j'ai sur la plupart de mes serveurs linux) ressemble à 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 adresse IP à SSH par période de 60 secondes. Le reste peut être traité en s'assurant que les mots de passe sont raisonnablement forts. Sur les serveurs à haute sécurité, obliger les utilisateurs à utiliser l'authentification par clé publique est un autre moyen d'arrêter de deviner.


18
2017-12-29 15:06



+1 pour suggérer un autre mécanisme. - dunxd


Des outils tels que 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 cela simplifie un peu la vie de l'administrateur système; C'est pourquoi je recommande d'utiliser fail2ban sur des systèmes où vous pouvez vous le permettre.


7
2017-12-29 11:08





Il ne s'agit pas uniquement de réduire le bruit: la plupart des attaques ssh tentent de deviner par la force des mots de passe. Ainsi, même si vous rencontrez de nombreuses tentatives infructueuses de ssh, peut-être qu’elles auront peut-être un nom d’utilisateur / mot de passe valide.

Le point positif de fail2ban par rapport aux autres approches est qu’il a un effet minimal sur les tentatives de connexion valides.


4
2017-12-29 13:14





Eh bien, cela évite quelque peu votre réseau d’attaques par déni et évite les frais généraux liés au traitement des défaillances.

Ne pas être le serveur le plus faible sur une liste de scripts pour enfants est toujours une bonne chose.


1
2017-12-29 10:47





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

0
2017-12-29 13:34



-1, la première désactivation de l'authentification par mot de passe n'est pas toujours une option. Deuxièmement, Fail2Ban peut couvrir beaucoup plus que SSHd. Je l'utilise pour SMTP / IMAP, DNS, connexion HTTP et quelques autres services. Ce n'est pas une panacée, et ce n'est certainement pas nécessaire, mais c'est très utile. - Chris S
:-) Je n'ai pas dit "si et seulement si". Oui, fail2ban est très utile, en effet. Mais il ne peut pas protéger contre le mot de passe volé à l'épaule ou comme ça. Et effectivement, oui! - Désactiver pw auth n'est pas toujours une option. Mais je suggérerais de trouver un moyen d'en faire une option. - brownian