fail2ban est-ce vraiment utile ? Partage d'expérience
04/04/2019
Mais est-ce vraiment utile d'implémenter ce logiciel (ou un logiciel similaire) sur son serveur GNU/Linux ? Et dans quels cas est-ce utile ou inutile ?
Nous répondrons à ces questions dans cet article, ou du tout moins, nous donnerons notre point de vue sur fail2ban en nous basant sur notre expérience de la sécurisation de serveurs et en partageant un retour d'expérience quant à l'implémentation de fail2ban.
fail2ban, est-ce bien utile ?
Non, fail2ban n'est pas utile ; fail2ban est absolument indispensable.
Soyons parfaitement clair, il nous paraît totalement inconcevable d'avoir un serveur GNU/Linux hébergeant un service accessible sur le réseau (que ce soit un réseau public comme Internet ou privé comme un réseau local) sans que ne soit implémenté fail2ban ou un outil similaire.
À partir du moment où votre serveur est allumé et connecté à un réseau, il devient de facto une cible d'attaques ; qu'il soit connecté à Internet ou non, et que vous en ayez conscience ou non.
Le premier type d'attaque que l'on rencontre le plus fréquemment est la tentative d'intrusion par force brute (brute-force). Ces attaques peuvent cibler un serveur SSH, un CMS Wordpress, un service Asterisk, etc. fail2ban protège efficacement contre ce type d'attaque en identifiant les tentatives de connexions infructueuses et en bloquant (via iptables, par exemple) les adresses IP à l'origine de ces tentatives d'intrusions.
Le second type d'attaque est la tentative de déni de service. fail2ban peut protéger couramment contre ce type d'attaque en identifiant rapidement les adresses IP à l'origine de trop nombreuses requêtes.
Pas convaincu de la nécessité de fail2ban ? Partage d'un retour d'expérience
Pour se convaincre de l'utilité d'implémenter un service comme fail2ban, nous avons réalisé l'expérience suivante : nous avons configuré fail2ban sur trois serveurs hébergeant les services suivants :
- serveur 1 : SSH (port 22) et Asterisk (port 5060)
- serveur 2 : SSH (port 22) et Apache (port 80)
- serveur 3 : SSH (port 22) et Apache (port 443)
Nous avons mesuré le nombre de tentatives d'intrusions sur le port SSH sur chacun de ces serveurs et nous sommes demandés si le fait d'avoir d'autres services en écoute avait une incidence sur ce nombre.
Dans le cadre de ce test, nous avons configuré fail2ban pour superviser uniquement le port SSH et bannir les adresses IP faisant 3 tentatives de connexions infructueuses en moins de 10 minutes. La durée de bannissement a été défini à 15 jours. Le test a duré 15 jours. Ainsi, au cours de ces 15 jours, nous sommes certains de ne pas avoir banni plusieurs fois la même adresse IP.
Le graphique ci-dessous présente en bleu l'évolution heure par heure du nombre d'adresses IP bannies pour les trois serveurs ; la courbe rouge représente la courbe de tendance au démarrage de la mesure (attention à l'échelle) :
1° constat : au bout de 15 jours, chaque serveur a banni plus de 6 000 adresses IP uniques !
2° constat : la progression est continue au cours des 5 à 8 premiers jours, avant de commencer à décliner par la suite.
3° constat : le serveur hébergeant un service Asterisk est nettement plus attaqué que ceux hébergeant un serveur Apache (+30% d'attaques environ)
4° constat : le serveur hébergeant un service Asterisk a banni plus de 3 000 adresses IP les 3 premiers jours, tandis que les deux autres serveurs en ont banni environ 1 750 sur les 3 premiers jours ; soit +70% d'attaques environ sur le serveur Asterisk lors des 3 premiers jours.
Le graphique ci-dessous présente en bleu le nombre d'adresses IP bannies heure par heure ; la courbe rouge représente la courbe de tendance (attention à l'échelle) :
1° constat : le nombre de tentatives d'intrusions baisse clairement au fil du temps ; la plus forte baisse étant constatée sur le serveur 1 (SSH + Asterisk), qui était le serveur enregistrant le plus d'attaques. Le serveur 2 (SSH + Apache) est celui qui a la tendance la plus stable.
2° constat : sur les 15 jours, il y a eu en moyenne 21 tentatives d'intrusion par heure sur le serveur 1 (SSH + Asterisk), 16 sur le serveur 2 (SSH + Apache) et 17 sur le serveur 3 (SSH + Apache). La valeur médiane pour les serveurs 2 et 3 est équivalente à leur moyenne à moins d'un point près (valeur médiane à 16 pour tous les deux) ; pour le serveur 1, la valeur médiane est de 18.
3° constat : il y a plus de tentatives d'intrusions la nuit (créneau 20h - 08h), que le jour (créneau 08h - 20h) ; 35 % en moyenne.
4° constat : nous n'avons pas vu d'augmentation significative du nombre d'attaques durant le week-end. De notre point de vue et de notre expérience, un serveur qui essuie une attaque par force-brute durant le week-end (à partir du vendredi soir, bien souvent...) a généralement déjà été testé de manière beaucoup moins virulente durant la semaine ; dans le cadre de ce test, notre script bannissant directement pour 15 jours, cela empêche l'attaquant d'effectuer un repérage en semaine avant de lancer une attaque durant le week-end.
Conclusion : fail2ban, c'est indispensable !
Il est extrêmement simple d'installer fail2ban sur n'importe quel serveur GNU/Linux. Il est inclus dans toutes les distributions.
Debian/Ubuntu/Mint : apt-get install fail2ban CentOS/RedHat : yum install fail2ban (s'il ne trouve pas le paquet fail2ban, le faire précéder d'un yum install epel-release)
Dès qu'il est installé, il est immédiatement opérationnel pour le port SSH.
fail2ban incorpore un nombre important de règles prédéfinies pour énormément de logiciel, ce qui facilite grandement sa mise en œuvre.
Il ne vous reste plus qu'à le personnaliser pour mettre vos adresses IP en withelist par exemple ou pour modifier la durée du bannissement.
Il existe de nombreux tutos sur Internet pour chaque service que vous souhaiterez superviser par fail2ban.
fail2ban est également indispensable pour les serveurs internes (non-accessibles depuis Internet) car vous n'êtes pas à l'abri d'une personne mal-intentionnée ou qu'un ordinateur de votre réseau local soit infecté par un bot ou un ver informatique.
À noter que vous pouvez configurer fail2ban pour qu'il vous envoie un e-mail dès qu'il détecte un nombre important de tentatives d'intrusions. Nous recommandons l'utilisation de cette option d'alerte par e-mail pour les serveurs accessibles uniquement en interne.
À noter : si votre fail2ban est amené à bloquer un très grand nombre d'adresses IP, alors l'hébergeur Octopuce propose de coupler fail2ban à IPset plutôt que iptables. Vous pouvez lire leur article : IPSET & filtrages des attaques sur les serveurs. Ils partagent le code source de leurs scripts sur leur espace GitHub.
Et vous, utilisez-vous fail2ban ?
Dans l'article [Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban, nous présentons comment sécuriser simplement et efficacement un serveur Asterisk avec un peu de bon sens, fail2ban et iptables.
Pour aller plus loin
[Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense & OPNsense
Tags de l'article : linuxsécurité
10 commentaires
cmic - 04/04/2019 à 11:55:14
Excellent article.
Perso j'utilise SShGuard sur un serveur dont seul le port SSH est ouvert sur internet. Efficace également.
--
cmic
Bruno - 04/04/2019 à 13:56:05
Ah ben zut alors…
J'attendais avec interêt les arguments sur l'inutilité de fail2ban. Mais non un seul point de vue, sans aucune nuance…
fail2ban est inutile pour un service SSH correctement configuré avec identification uniquement par clés.
fail2ban ne protège pas des faiblesses de configuration de services en amont.
fail2ban ne protège pas d'une vraie attaque DDOS.
Guillaume - 04/04/2019 à 14:22:10
@Bruno :
Bonjour,
Ne vous trompez pas de lecture.
Cet article présente l'intérêt évident de fail2ban dans une stratégie de sécurisation d'un serveur ; il n'a pas vocation à discuter sur comment configurer et/ou sécuriser un serveur SSH.
Il est écrit nul part que fail2ban protège d'une attaque par déni de service distribué. Ce n'est d'ailleurs pas la fonction première de fail2ban.
Enfin, si on veut creuser le sujet, on pourrait s'interroger sur la pertinence même d'avoir un service SSH en écoute sur un serveur accessible par Internet sans aucun filtrage. Mais ce n'est pas le sujet de l'article. ;-)
Cordialement,
Guillaume
--
Provya
BENZZ - 04/04/2019 à 14:46:29
@Guillaume :
Bah non justement , au titre de ton article je suis moi aussi déçu.Tu enfonces des portes ouvertes et c'est dommage !
Au final pour des services de base comme ssh , un simple durcissement de la conf suffirait sans parler du hardenning sytemd .
Ca te permet de ne pas rajouter un programme tiers comme Fail2ban à ton système et qui plus est tourne sur ta machine avec les privilèges root
Et attention , je ne dis pas que fail2ban ne sert à rien . Dans certains cas il est très complémentaire. Mais un peu de nuance aurait été de bon aloi et t'aurais différencié des centaines d'autres articles qui traitent du sujet sans vraiement connaitre les possibilités natives :P
.
nico - 04/04/2019 à 15:19:34
SSH c'est keypair auth only. Du coup fail2ban ne sert absolument à rien dans ce cas.
Par contre certain logiciel qui repose sur du mot de passe n'ont pas de sécurité de ce type par défaut et la oui un Fail2ban peut être intéressant.
Matou - 04/04/2019 à 20:29:58
Fail2ban ce n'est pas que du ssh. C'est aussi du contrôle pour le smtp, le pop, l'imap, le http, le ftp et de manière générale tout ce qui peut générer des logs utilisables, donc oui c'est très intéressant.
De plus même si vous avez des briques d'authentifications solides comme du roc, fail2ban permet de réduire le nombre de tentatives de connexion et d'éviter des dénis de service sur l'auth.
farouq - 07/04/2019 à 22:16:23
@nico :
ou pas.
Prétendre qu'il y a une seule solution absolue en matière de sécurité est la marque d'une grande méconnaissance pour ne pas dire incompétence, et est dommageable aussi bien pour la réputation de l'auteur que pour le domaine de la sécurité en général.
Une utilisation par clé uniquement complexifie sensiblement les choses, il faut maintenant avoir une politique de gestion des clés correspondant au modèle de menace, et ça impose un peu de gymnastique pour traverser la machine qui sert de rebond pour accéder au réseau interne. voir https://blog.octo.com/le-bastion-ssh/ pour plus de détails.
Au delà de cette complexification, elle introduit des incompatibilités avec certains usages et introduit des failles et des problèmes de sécurité avancées qui n'existent pas forcément avec un mot de passe.
L'usage de clé est souvent un bon choix mais ce n'est pas toujours le cas. Par rapport à mon modèle de menace personnel l'usage d'un bastion ssh dont le service est masqué derrière du port knocking apporte le niveau de sécurité suffisant sans avoir besoin de recourir à l'usage de clés.
Julian - 09/08/2019 à 16:30:58
Je me sers de fail2ban pour :
- Filtrer tous les accès à mes applications web
- Vérifier qui fait du forcing sur plusieurs autres services
- Je m'en sers également pour parer les attaques les plus "basiques" de type injections SQL, XSS, etc..
- Je m'en sers contre tous les bots ou non, cherchant des accès à des pages admins
- J'ai même une règle qui ban ceux qui génèrent des 403 (ce qui ne devrait jamais arriver, à moins qu'un mec cherche des pages/scripts à la mano..)
- etc..
Je fais d'abord du hardening sur mes confs, je teste et verrouille ça, puis me sert de f2b comme filet de secours et aussi pour pouvoir dresser des stats (avec munin) et éventuellement détecter des activités suspectes (de la prise d'empreinte par exemple).
Il ne faut pas prendre fail2ban comme un outil opérationnel dès qu'il est installé, il faut aller plus loin, ne pas hésiter à jouer avec les regex. C'est de mon point de vue très puissant.
Maintenant, pour protéger un serveur ssh pure et dure, il n'y aucun intérêt, effectivement. Je le laisse par défaut car il ne fait pas de mal (je m'auth en clef RSA), mais je n'aurais que ça à protéger, je n'utiliserais pas f2b.
F2B permet de centraliser une politique pro active de sécurité, je le prends plus comme un framework complet plutôt qu'un bête outils de ban.
Autourdupc - 20/08/2020 à 09:45:06
J'utilise Fail2ban + pfsense...
J'héberge un serveur asterisk "ouvert" sur le port 5060 car je dois pouvoir m'y connecter à distance en VoIP via mon smartphone(le nombre de tentatives d'intrusions est phénoménal).
L'usage d'un VPN pour les nomades VoIP n'est pas adapté (décrochages lors de mauvaises conditions de réception, temps de connexion, etc) aussi j'utilise Fail2ban sur mon asterisk en association avec pfblockerNG sur mon pfsense.
En effet, je récupère chaque heure les IP bannies sur mon asterisk que j'injecte dans pfblockerNG ainsi je déporte le blocage sur le pfsense en amont du serveur asterisk (avec drop des paquets).
Cette configuration a l'avantage de pouvoir paramétrer Fail2ban avec des recherches de log sur de courtes durées limitant ainsi l'usage CPU, et de laisser le travail de blocage au pfsense dont c'est le rôle.
pfblockerNG permet de bloquer les IP par pays et/ou par listes noires, et l'association avec Fail2ban permet de filtrer unitairement les IP qui tentent d'entrer.
Avec cette méthode, je n'ai jamais eu aucune intrusion depuis des années d'usage.
Julian - 25/08/2020 à 11:44:24
Hello,
Fail2ban est indispensable, oui, mille fois oui. Je ne comprends pas pourquoi par contre il y en a qui s'obstinent à ne parler que de SSH avec Fail2ban. Oui, il existe des filtres SSH avec f2b, mais ce n'est qu'une goutte d'eau dans l'océan. Et j'ai presque envie de dire qu'avec une configuration de sshd réellement propre (auth RSA avec limitation @host, plus règle FW), Fail2ban n'est même pas utile.
Fail2ban, c'est avant tout la garantie de pouvoir générer des règles à partir de puissantes regex pour n'importe quelle log, et c'est génial.
Me concernant, une de mes fonction est gérer un ERP vieillissant, en PHP, je n'ai pas les ressources pour le mettre à niveau, je corrige tout ce que je trouve (sqli, xss, etc..), je passe un maximum de chose de _mysql à PDO filtré, mais ça ne suffit pas, il peut y avoir des oublis. Fail2ban me rend ici un service immense en filtrant mes logs nginx et dès qu'une tentative d'injection SQL est détectée (du moins les plus courantes), boom, c'est le ban.
Idem pour toutes les requêtes un peu trop chelou, les appels à des pages/scripts inexistants.
Rien que pour que ce type d'utilisation, fail2ban fait un boulot extra. Je l'ai couplé avec plein d'outils. Alors évidemment, avant de mettre fail2ban, il faut avoir une configuration propre de base, bien maîtriser l'ensemble et la portée des paramètres utilisés, faire du hardening, mettre en place des règles FW propre, puis, seulement, rajouter la couche Fail2ban.
Fail2ban ne doit en revanche jamais être considéré comme un pansement pour ceux qui ne veulent pas se casser la tête à faire du hardenning.
Flux RSS des commentaires de cet article