Fail2ban ne sécurise pas SSH, et son propre README le dit

Installer fail2ban, regarder le compteur de bannissements grimper, se sentir plus en sécurité. C’est cet enchaînement qui explique la présence de l’outil sur presque tous les serveurs, et c’est aussi pour cette raison que beaucoup de ces serveurs sont moins protégés que leurs administrateurs ne le croient.

L’énoncé le plus clair du problème ne se trouve pas dans une critique de fail2ban. Il se trouve dans le README de fail2ban lui-même.

Ce qu’il fait réellement

Le mécanisme est simple et il fonctionne. Fail2ban analyse des fichiers de journaux comme /var/log/auth.log et bannit les adresses IP qui effectuent trop de tentatives de connexion échouées. Il procède en mettant à jour les règles du pare-feu système pour rejeter les nouvelles connexions depuis ces adresses IP, pendant une durée configurable.

Il est livré prêt à lire de nombreux fichiers de journaux standards, dont ceux de sshd et d’Apache, et il peut être pointé vers n’importe quel fichier de journal de votre choix, pour n’importe quelle erreur que vous souhaitez. Depuis la version 0.10, il reconnaît également les adresses IPv6.

C’est une brique d’infrastructure réellement utile. Un serveur exposé à Internet collecte des milliers de tentatives de connexion automatisées par jour, et fail2ban transforme ce flot en filet d’eau.

La phrase que le projet inscrit dans son propre README

C’est ici que l’outil se montre plus honnête que la plupart des conseils qu’on donne à son sujet :

Bien que Fail2Ban soit capable de réduire le taux de tentatives d’authentification incorrectes, il ne peut pas éliminer le risque que présente une authentification faible.

Mesurez ce que cela concède. Fail2ban agit sur le taux. Il n’agit pas sur le risque. Ce sont deux grandeurs différentes, et les confondre constitue toute l’erreur.

Si votre serveur SSH accepte un mot de passe, un attaquant doit le deviner. Fail2ban ralentit la recherche à l’extrême et rend une force brute naïve impraticable. Mais la porte s’ouvre toujours pour quiconque détient le mot de passe, qu’il l’ait deviné, obtenu par hameçonnage, acheté dans une fuite d’identifiants ou récupéré depuis un identifiant réutilisé sur un site compromis sans rapport. Aucun de ces chemins ne passe par des échecs répétés, donc aucun ne déclenche de bannissement.

Ce que le projet vous dit de faire à la place

Le README ne s’arrête pas à l’avertissement. Il nomme l’alternative :

Configurez les services pour n’utiliser que des mécanismes d’authentification à deux facteurs, ou à clés publique/privée, si vous voulez vraiment protéger des services.

C’est le véritable correctif, et c’est un changement de nature plutôt qu’un changement de degré. Un serveur qui n’accepte que l’authentification par clé ne peut pas être attaqué par force brute du tout, parce qu’il n’y a rien à deviner. La surface d’attaque n’est pas réduite, elle est supprimée.

Notez le mot que. Ajouter une clé en laissant l’authentification par mot de passe activée ne change rien au risque, car c’est la méthode acceptée la plus faible qui définit votre exposition. Le réglage qui compte est la désactivation de l’authentification par mot de passe, pas l’ajout d’une clé à côté.

Faut-il donc l’utiliser

Oui, et pour la bonne raison.

Gardez-le pour le bruit. Des journaux que vous pouvez réellement lire valent beaucoup. Quand les tentatives d’authentification échouées passent de plusieurs milliers par jour à une poignée, une anomalie devient visible au lieu d’être noyée. C’est un bénéfice opérationnel réel et un bon argument en faveur de l’outil.

Ne le comptez pas comme votre sécurité SSH. Si un audit de sécurité de votre serveur s’arrête à « fail2ban est installé », l’audit s’est arrêté une étape trop tôt. La question qui décide de votre exposition est de savoir si l’authentification par mot de passe est encore acceptée.

Surveillez ce qu’il vous coûte. Les bannissements s’appliquent à des adresses, et les adresses sont partagées. Un mot de passe mal saisi sur un réseau d’entreprise ou mobile peut verrouiller tout le monde derrière cette adresse, vous compris. Fail2ban est l’un des moyens les plus courants par lesquels les administrateurs se verrouillent hors de leurs propres serveurs.

Le résumé honnête

Fail2ban fait exactement ce qu’il annonce : il réduit le taux de tentatives d’authentification échouées en bannissant les adresses bruyantes au niveau du pare-feu, pendant une durée configurable, sur la base de vos journaux.

Sa propre documentation est explicite : cela ne peut pas éliminer le risque que présente une authentification faible, et les services que vous voulez vraiment protéger devraient utiliser des mécanismes à deux facteurs ou à clés publique et privée. Ces deux phrases valent plus que la plupart des listes de contrôle de durcissement.

Faites tourner fail2ban pour garder vos journaux lisibles. Désactivez l’authentification par mot de passe pour garder votre serveur. Ce ne sont pas des substituts l’un de l’autre, et un seul des deux change ce qu’un attaquant est capable de faire.

La description du comportement de fail2ban, la limitation citée au sujet de l’authentification faible, la recommandation d’utiliser une authentification à deux facteurs ou à clés publique et privée, ainsi que la prise en charge d’IPv6 depuis la version 0.10, sont tirées du README du projet fail2ban lui-même, vérifié au moment de la rédaction. Les détails de configuration varient selon la distribution ; consultez la documentation de votre propre paquet avant de vous fier à un chemin ou à une valeur par défaut spécifique.