Je doute que je devrais utiliser l'authentification par clé lors de la connexion à SSH, ou tout simplement opter pour fail2ban + ssh (connexion root désactivée).
Fail2ban est-il sûr ou est-il vraiment préférable d'aller de l'avant et de générer des clés et de les configurer sur toutes mes machines clientes qui doivent se connecter à ssh?
Réponses:
Je le juge comme un produit stable et je le considère comme sûr. À titre de précaution supplémentaire, j'ajouterais votre adresse IP source à la ignoreipdirective jails.confpour vous assurer de ne pas vous bloquer.
Puisqu'il analyse les journaux ssh, une session TCP va devoir être établie, donc usurper les IP source et obtenir les bons numéros de séquences TCP pour créer une sorte de variation de rétrodiffusion semble peu probable.
L'utilisation de touches en plus de cela n'est pas une mauvaise idée. D'autres options qui aident à déplacer ssh vers une adresse IP non standard, à l'aide du module iptables "récent", ou à décider simplement que vous ne vous souciez pas si les gens essaient de forcer les mots de passe par force brute. Voir cet article sur les défauts de serveur pour en savoir plus.
Chaque fois que j'ai implémenté denyhosts ou fail2ban dans un environnement de production, il a créé un flux de tickets garanti de demandes de déverrouillage, des demandes de réinitialisation de mot de passe, des demandes de modification des paramètres ou de gestion de la liste blanche, et généralement des personnes qui abandonnent la connexion à examiner les choses et s'appuyer davantage sur les administrateurs système pour des choses qu'ils pourraient faire eux-mêmes.
Ce n'est pas un problème technique avec les deux outils en soi, mais si votre nombre d'utilisateurs se compte par dizaines ou plus, cela va être une augmentation notable de la charge de travail de support et des utilisateurs frustrés.
De plus, le problème qu'ils résolvent est qu'ils réduisent le risque d'attaques de connexion ssh par force brute. Honnêtement, le risque est incroyablement faible tant que vous avez même une politique de mot de passe modérément décente.
J'utilise depuis quelques années et au moins c'est une bonne protection contre les script kiddies.
Aucune connexion root, plus des mots de passe assez longs et aléatoires et fail2ban et peut-être un port différent est pour la plupart d'entre nous suffisamment sécurisé.
Bien sûr, les clés ssh sont bien meilleures que la sécurité.
J'utilise denyhosts sur plusieurs de mes serveurs de production et hors production, et cela fonctionne très bien (j'ai eu des problèmes avec la synchronisation des démons, donc je ne l'utilise pas maintenant, mais peut-être que ça fonctionne à nouveau correctement).
Non seulement votre système est plus sûr, mais il vous aide à conserver des journaux plus propres et à empêcher les personnes indésirables d'accéder à vos écrans de connexion ...
J'exécute Fail2Ban depuis un petit moment maintenant, et récemment j'ai vu des tentatives distribuées de s'introduire sur mon serveur SSH. Ils ne réussiront jamais au rythme où ils vont, mais j'ai gardé un œil dessus.
Ils ont parcouru un dictionnaire, chaque IP essaie deux fois, après l'échec de ces tentatives, une autre IP fait de même, etc. J'ai envisagé d'interdire les IP qui essaient des noms d'utilisateur inconnus x fois. Mais jusqu'à présent, j'ai obtenu quelques milliers d'adresses IP différentes essayant d'entrer; et je crains que même si je les bloque tous, il y en aura encore plus.
.conffichiers et de mettre vos configurations dans des.localfichiers. Cela facilite également les mises à niveau, car aucun de vos fichiers locaux n'est écrasé.