J’utilise fail2ban (beaucoup sur mon infra perso et assez peu chez Picasoft) pour bannir (essentiellement via le pare-feu) les IPs qui tentent des scans et des bruteforce sur les serveurs. Ça fonctionne bien.
Mais je n’aime pas la configuration, que je trouve fouillie, pas assez claire, longue comme plusieurs bras.
Je trouve aussi le daemon trop gourmand. Selon moi, un daemon aussi simple gagnerait à être écrit avec un langage plus rapide que Python.
B. Si vous utilisez fail2ban, qu’est-ce que vous en pensez ? Qu’est-ce que vous aimeriez changer ? Tous les retours m’intéressent, parce que je m’attèle à l’écriture d’une alternative.
Réponse B
C’est vrai que c’est lourd pour ce que ça fait…
Moi j’aime bien les regex alors je trouve fail2ban plutôt cool pour ça… Aussi ce qui est top chez fail2ban c’est la quantité de logiciel déjà supporté.
La ligne de commande pour « unban » je m’en rappel jamais trop, je trouve pas très intuitifs…
Réponse B également, j’utilise fail2ban car cela permet clairement de protéger à minima un serveur.
Je n’ai pas trouvé d’alternative dans le sens où effectivement les fichiers de config peuvent être lourd, fouillies quelques part mais permet vraiment de faire sa propre configuration personnalisé et c’est l’un des grands avantages de fail2ban.
Par exemple lorsque je suis passé sur nftables plutôt que iptables, j’ai pu personnalisé mes confs et ne pas attendre que les dépôts et conf proposées soit à jour mais également personnalisé les règles, la façon de bannir…
C’est toujours un peu le problèmes des programmes qui sont très configurables, si on a une application pas très utilisée ou même développée personnellement, on peut faire les règles fail2ban qui vont bien.
Je ne sais pas si il peut y avoir d’équivalent plus léger mais aussi paramétrable.
Dans tous les cas les retours m’intéresse aussi.
Bonjour,
Mon retour d’expérience, pas du tout chatons, mais perso.
J’utilise fail2ban sur un raspberry depuis 15mois, qui héberge entre autre un logiciel de partage de photos pour ma famille, piwigo. (excellent au logiciel au passage) :
ssh sur un port autre que celui par défaut
vpn
les ports 80/443 pour piwigo
A aujourd’hui :
15799 apache.ref.banip.txt
662 openvpn.ref.banip.txt
9455 sshd.ref.banip.txt
Configuration un peu lourde au départ : oui c’est vrai, mais une fois que cela fonctionne la mission est remplie.
Je ne sais pas s’il existe un frontal pour fail2ban qui permettrait de simplifier configuration et gestion, cela serait un plus.
Point d’attention :
Le chargement des 26000 adresses rend 15mn au démarrage du pi ou lors d’un service fail2ban start, mais in fine ce n’est pas un réel problème.
CrowdSec : j’ai juste regardé, pas testé.
Phil
[EDIT]
J’ai oublié d’indiquer que j’utilise en complément le site : http://ip-api.com/
qui est très pratique pour récupérer plus d’information sur une adresse IP
ex :
$ curl http://ip-api.com/json/120.77.180.121
{« status »:« success »,« country »:« China »,« countryCode »:« CN »,« region »:« GD »,« regionName »:« Guangdong »,« city »:« Shenzhen »,« zip »:« »,« lat »:22.5559,« lon »:114.0577,« timezone »:« Asia/Shanghai »,« isp »:« Hangzhou Alibaba Advertising Co »,« org »:« Aliyun Computing Co., LTD »,« as »:« AS37963 Hangzhou Alibaba Advertising Co.,Ltd. »,« query »:« 120.77.180.121 »}
Pour réaliser ce tuto, dans lequel y a un paragraphe sur " Un filtrage des accès" texte en gras :
Depuis l’article j’ai enrichi avec ip-api.com que j’ai cité dans le post ci-dessus.
si je devais émettre un conseil … commencez très simple, simple c’est bien … et on comprend quand on y revient dans x mois.
Je veux proposer un programme avec une configuration simple, sans configuration par défaut.
Si ça vous intéresse, n’hésitez pas à faire des retours sur le format du fichier de configuration, ça m’intéresse !
Merci pour le ping ! Ravi d’apprendre que tu t’es déter pour créer cette alternative
Pour détailler du côté de La Contre-Voie : nous utilisons extensivement fail2ban chez nous, autant pour filtrer les requêtes HTTP que pour les requêtes SSH ou le mail.
Ce filtrage agit autant sur les requêtes que nous pouvons considérer comme malveillantes que sur des tentatives de bruteforce, en protégeant la plupart de nos formulaires HTML. Nous utilisons également les rate-limits de Nginx en complément efficace.
Le plus compliqué chez nous : nous avons une infrastructure « horizontale », avec plusieurs serveurs qui peuvent se relayer pour fournir le même service.
Nous avons donc besoin de répercuter le bannissement d’une IP sur plusieurs serveurs en même temps, sans pour autant lire et synchroniser les logs sur tous nos serveurs (ce qui consommerait beaucoup de ressources inutilement). Fail2ban n’est pas adapté pour cet usage, nous avons donc contourné son usage en utilisant un modèle client-serveur :
un « serveur » fail2ban sur le serveur de journalisation, qui lit les logs et qui émet les bannissements en les écrivant dans un journal partagé avec les autres serveurs ;
un « client » fail2ban, installé sur chaque machine, qui lit le journal de ce serveur et qui répercute les bannissements sur chaque machine.
Problème 1 : On contourne l’outil fail2ban pour le rendre « distribué », donc il devient (encore) plus difficile à maintenir. On aurait aimé un outil qui gère ça nativement.
Problème 2 : Fail2ban ne protège pas des attaques par déni de service distribuées, face à l’usage d’un grand nombre d’IPs. On aimerait bien un outil qui intègre ça aussi.
Problème : Fail2ban n’est pas capable de filtrer un trafic assez élevé (50 requêtes par seconde ?) sans consommer plus de 500 Mo de RAM et beaucoup de CPU. Et de manière générale, je trouve que Fail2ban est super lent et consommateur en ressources pour ce qu’il fait.
On a regardé Crowdsec il y a quelques mois, mais la solution ne semble gérer que les requêtes HTTP. Et pas sûr qu’on puisse l’utiliser dans des conteneurs Docker comme chez nous… (pour fail2ban, on utilise GitHub - crazy-max/docker-fail2ban: Fail2ban Docker image).
De notre côté on va rester sur cette solution (pas idéale mais encore à peu près fonctionnelle) dans l’attente que les alternatives se développent
Huhu, tu ne serais pas en train de me mettre la pression @denis ? ^^
Ha super, et merci pour la piste de https://github.com/Relkci/F2BDistro car on a le même « problème » chez Infini. Chez nous nginx est derrière haproxy, donc j’ai pensé à brancher fail2ban directement sur celui-ci, peut-être que ça serait plus simple comme option(au moins pour le trafic qui passe bien par ha).
ma participation se symbolisera sur ce lien, j’ai proposé une sorte de débat pour avoir peut etre un jour éventuellement pourquoi pas une labellisation sur les distros linux/nix/bsd/ qui embarqueraient un ssh activé mais dénué de mdp par défaut :
Malheureusement, c’est pas dans le cadre du projet pour l’instant ! L’idée en le réécrivant en Go est surtout d’adresser le problème des ressources utilisées !
Ça m’intéresse, mais je ne sais pas du tout comment gérer une attaque distribuée, ni même si c’est vraiment possible… On pourrait ban plus rapidement des IPs qui viennent du même lot d’IPs ou ASN, peut-être.
Salt a en effet l’air de faire du super travail ! Si j’ai bien compris par contre, c’est une plateforme as a service, pas un service auto-hébergé, ce qui est bloquant pour certain·es gaulois·es (dont moi hihi)
Non non, pas du tout, tu peux (on le fait) très bien utilisé salt sans aucun service externe en ayant tes masters et tes minions dans ton infra. C’est pas le genre de la maison chez @infini d’utiliser des trucs externes
Je ne connais plus la raison qui nous a dissuadé d’utiliser cet outil, je demanderai à l’occasion.