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.
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
Pour les besoins d’Exarius, je développe un petit programme en Rust permettant de réduire au minimum les ressources utilisées pour « simplement » bloquer des connexions.
L’idée est de déléguer un maximum de choses au noyau Linux en surveillant les fichiers de journalisation avec inotify et en laissant nftables gérer les durées de bannissement. La « seule » fonctionnalité de ce programme est de faire des regex le plus efficacement possible (merci l’extrême performance de Rust à ce sujet) et d’ajouter des adresses à des setnftables en cas de dépassement des limites de détection dans un intervalle de temps.
Le programme nommé Minos (en tant que juge des Enfers grecques, pour ici juger des IP) et fonctionnel mais reste à améliorer et à documenter. Je n’aurais pas le temps de le faire ce week-end, il sera donc publié la semaine prochaine.
@ppom Pour l’usage de CLUB1 fail2ban est vraiment super, 2 lignes pour sélectionner le backend nftables, 2-3 lignes par service à monitorer. Comme on reste le plus proche possible des configurations par défaut des services, installés via les dépôts Debian, toutes les configs sont déjà présentes, il ne reste qu’à les activer. Après oui le daemon n’est pas des plus économes en ressources mais il se laisse clairement oublier à côté de Synapse.
Après si le soft en Rust que @pilot est en train de développer est compatible avec la config de fail2ban perso je serais intéressé par switcher, enfin, lorsqu’il arrivera dans Debian haha.
D’ailleurs je suis curieux de savoir comment tu fais ça. C’est une fonctionnalité intégrée à nftables ? Parce que sinon avec le backend nftables fail2ban génère aussi des set nftables contenant les IPs à bannir.
La conf fail2ban est assez complexe, ça m’étonnerait qu’une alternative qui se veut simple la reprenne (c’est pas mon cas) ! Après il suffit de récupérer les regexes dans la conf pour adaptation.
Comme annoncé, le code de Minos a été publié dans ce dépôt.
C’est une version alpha qui permet de surveiller un fichier de logs par jail et de bannir les adresses IP qui ont dépassé un certain nombre d’apparition dans une certaine fenêtre de temps. Chaque jail constitue un thread.
Les expressions régulières des filtres peuvent être extraites de fail2ban via un petit outil en Python.
N’hésitez pas à faire des retours ou à suggérer des idées.
Je ne connais plus la raison qui nous a dissuadé d’utiliser cet outil, je demanderai à l’occasion.