Dans ma tête il est plutôt là pour bloquer les attaques en brute force, dont en particulier celles des bots.
Cela ne les bloque pas puisque les IP changent, au mieux cela ralenti un peu. Et n'oublie pas que fail2ban agit après coup en analysant les logs. Le temps qu'il réagisse il peut y avoir eu des dizaines de tentatives provenant de la même IP.
Quant aux attaques par force brute des bots elles ne consistent pas à « casser » les mots de passe mais à essayer des combinaisons triviales utilisateurs/mot de passe (je l'ai déjà mentionné et c'est facile à vérifier). Casser un mot de passe à distance un tant soit peu solide prendrait un temps infini en raison du temps entre deux tentatives.
Donc si ton service est bien configuré avec des mots de passe solide ces attaques n'aboutiront jamais et fail2ban est souvent là juste pour rassurer.
Pour le SSH un mot de passe très solide ou une connexion par clés peut sembler équivalent d'un point de vue sécurité. Dans l'absolu une clé ED25519 ou sera toujours beaucoup plus difficile à casser (est-ce seulement déjà arrivé ?) qu'un mot de passe. Et là encore il faudrait un temps et une puissance de calcul phénoménaux.
En Outre une configuration excluant la connexion par mot de passe par défaut peut éviter une étourderie de l'administrateur système qui a créé un compte test, mot de passe test pour tester (situation similaire déjà vue en vrai).
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Voltairine . En réponse au journal Fail2ban, ajustement des valeurs par defaut. Évalué à 6.
Cela ne les bloque pas puisque les IP changent, au mieux cela ralenti un peu. Et n'oublie pas que fail2ban agit après coup en analysant les logs. Le temps qu'il réagisse il peut y avoir eu des dizaines de tentatives provenant de la même IP.
Quant aux attaques par force brute des bots elles ne consistent pas à « casser » les mots de passe mais à essayer des combinaisons triviales utilisateurs/mot de passe (je l'ai déjà mentionné et c'est facile à vérifier). Casser un mot de passe à distance un tant soit peu solide prendrait un temps infini en raison du temps entre deux tentatives.
Donc si ton service est bien configuré avec des mots de passe solide ces attaques n'aboutiront jamais et fail2ban est souvent là juste pour rassurer.
Pour le SSH un mot de passe très solide ou une connexion par clés peut sembler équivalent d'un point de vue sécurité. Dans l'absolu une clé ED25519 ou sera toujours beaucoup plus difficile à casser (est-ce seulement déjà arrivé ?) qu'un mot de passe. Et là encore il faudrait un temps et une puissance de calcul phénoménaux.
En Outre une configuration excluant la connexion par mot de passe par défaut peut éviter une étourderie de l'administrateur système qui a créé un compte test, mot de passe test pour tester (situation similaire déjà vue en vrai).