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

15

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.

security ssh fail2ban dunxd
la source
2
Cette réponse n'est pas un argument valable, ni ne prétend que Fail2Ban est un théâtre de sécurité. Fail2Ban est une couche, ce n'est ni un remède universel, suffisant 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 par force brute et similaires (il n'y a tout simplement aucune excuse pour permettre à un serveur connecté à Internet d'être forcé par la force brute avec le savoir-faire en matière de sécurité d'aujourd'hui). La façon dont vous choisissez d'obtenir cette limitation de taux est votre choix.
Chris S

Réponses:

18

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.

pehrs
la source
1
+1 pour avoir suggéré un autre mécanisme.
dunxd
7

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.

pitr
la source
4

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.

symcbean
la source
1

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.

Sirex
la source
0

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
brownien
la source
1
-1, La première désactivation de l'authentification par mot de passe n'est pas toujours une option. Deuxièmement, Fail2Ban peut couvrir bien plus que le simple SSHd. Je l'utilise pour SMTP / IMAP, DNS, connexion HTTP et quelques autres services. Ce n'est pas un remède universel 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 vraiment très utile. Mais il ne peut pas protéger contre un mot de passe volé à l'épaule ou comme ça. Et, en effet, oui! - désactiver l'authentification pw n'est pas toujours une option, sûrement. Mais je suggérerais de trouver un moyen d'en faire une option.
brownian