Pas vraiment d'accord pour dire que c'est indispensable. En désactivant l'authentification par mot de passe pour ne laisser que l'authentification par clé, les chances d'un brute-force réussi sont quasi-nulle. En plus, il me semble qu'OpenSSH introduit un délai entre chaque tentative de reconnexion, et rien que ça c'est un gros frein à une attaque réussie même par mot de passe. Et ça permet d'éviter d'avoir un démon qui parse les logs en permanence. Maintenant ça m'intéresserait de savoir ce qui consomme le plus, entre fail2ban qui parse les logs en continu, et les attaquants qui tentent de se connecter en continu.
Par contre si l'authentification par mot de passe est activée, je recommande en effet très fortement d'avoir fail2ban ou équivalent.
Sauf qu'entre des tentatives de connexion, même vouées à l'échec, peuvent poser quelques problèmes. On a souvent eu le cas au taf d'une attaque DOS où l'attaquant fait des pre-auth sans même donner de login ensuite. Ça sature le serveur de connexions, et les connexions légitimes échouent par intermittence, rendant l'accès au serveur difficile pour nous et notre monitoring.
Et fail2ban ne fait pas que du SSH. Il nous est surtout utile sur Apache / Nginx, pour bloquer les DOS qui provoquent un grand nombre de requêtes PHP et/ou MySQL, plombant le serveur et rendant le site difficilement accessible, voire inacessible, fail2ban le bloquant alors avant même de toucher Apache.
On l'utilise aussi pour les mails (tentatives d'utilisation du Postfix comme d'un relais ouvert, même si sa conf ne le permet pas, certains essayent).
Pas vraiment d'accord pour dire que c'est indispensable. En désactivant l'authentification par mot de passe pour ne laisser que l'authentification par clé, les chances d'un brute-force réussi sont quasi-nulle. En plus, il me semble qu'OpenSSH introduit un délai entre chaque tentative de reconnexion, et rien que ça c'est un gros frein à une attaque réussie même par mot de passe. Et ça permet d'éviter d'avoir un démon qui parse les logs en permanence. Maintenant ça m'intéresserait de savoir ce qui consomme le plus, entre fail2ban qui parse les logs en continu, et les attaquants qui tentent de se connecter en continu.
Par contre si l'authentification par mot de passe est activée, je recommande en effet très fortement d'avoir fail2ban ou équivalent.
Sauf qu'entre des tentatives de connexion, même vouées à l'échec, peuvent poser quelques problèmes. On a souvent eu le cas au taf d'une attaque DOS où l'attaquant fait des pre-auth sans même donner de login ensuite. Ça sature le serveur de connexions, et les connexions légitimes échouent par intermittence, rendant l'accès au serveur difficile pour nous et notre monitoring.
Et fail2ban ne fait pas que du SSH. Il nous est surtout utile sur Apache / Nginx, pour bloquer les DOS qui provoquent un grand nombre de requêtes PHP et/ou MySQL, plombant le serveur et rendant le site difficilement accessible, voire inacessible, fail2ban le bloquant alors avant même de toucher Apache.
On l'utilise aussi pour les mails (tentatives d'utilisation du Postfix comme d'un relais ouvert, même si sa conf ne le permet pas, certains essayent).