J'ai quelques serveurs "identiques" au niveau de leur configuration, hébergement, usages et fonctionnalités (par exemple une grappe glusterfs, des serveurs proxmox, des serveurs mails etc.).
Et comme beaucoup de monde je déploie fail2ban systématiquement et ça fait des années que je me dis qu'il faudrait passer sur un truc plus "vision globale" du genre crowdsec mais voilà, la flemme, le manque de temps, le fait que fail2ban est déjà installé (recettes ansible aussi) … ça fait que je n'ai pas fait le saut.
Mais comme j'ai vraiment envie de "propager" mes ip blacklistées d'un serveur à l'autre j'ai commencé à regarder ce qui se fait (https://serverfault.com/questions/625656/sharing-of-fail2ban-banned-ips, AbuseIPDB, blocklist.de etc.) sans pour autant trouver mon bonheur.
Je veux une solution serveur libre éventuellement auto-hébergeable pour mon infra et un truc assez simple à déployer.
Alors j'ai codé et je propose https://fail2band.com pour faire que fail2ban marche en bande :-)
En suivant à la main le quickstart en moins de 5 minutes ça marche … sur une installation type debian buster.
À l'heure actuelle ça fait quelques jours que ça tourne sur mes serveurs, remontée d'ipv4 ok, ipv6 ok, propagation sur les autres serveurs ok, propagation des "unban" ok …
Il reste encore beaucoup de choses à faire, en particulier pour l'instant je m'appuie sur des cron pour venir chercher les ip à blacklister et à débannir … il faudrait passer sur un truc plus "push" du genre http2 ou xmpp … j'hésite encore pour trouver une solution qui ait le moins de dépendances possibles sur les machines.
À terme si ça intéresse du monde il faudra faire le nécessaire pour que ça puisse être déployé via ansible aussi.
Le support de nftables est en cours (mais pas encore fonctionnel) pour les installations qui l'utilisent à la place de iptables.
Bref le chantier est ouvert et si vous voulez participer c'est le moment :-)
# 0.o
Posté par minch . Évalué à 7. Dernière modification le 14 juillet 2021 à 16:46.
Je pensais être expert en flemme, mais j'en découvre tous les jours…
Tu as la flemme d'installer crowdsec….
… donc tu codes un nouveau projet 0.o
Bah pourquoi pas 🙃
(pour les ordres de ban/deban, tu veux pas juste faire une file type MQ ? et les clients s'abonnent au truc ?)
[^] # Re: 0.o
Posté par rycks . Évalué à 9.
J'avoue … mais à bien y réfléchir, si je résume, j'ai le choix entre
a) "ne rien changer à mes procédures" (déploiement, recettes ansible et tout le b*) et ajouter 4 fichiers pour que tout ce qui tourne déjà bénéficie en plus d'une mutualisation de blacklist d'un côté
b) supprimer fail2ban de toutes mes installations et "migrer" vers une autre solution pour laquelle il faudra se former et passer du temps pour atteindre un niveau de maîtrise semblable à celui que j'ai sur la solution existante
au passage un "gros" boulot de formation sur la solution alternative serait à faire en se posant quelques questions du genre est-il possible d'autohéberger son serveur crowdsec (si c'est la solution retenue par exemple) … etc.
De mon point de vue le choix est "assez vite fait" : une position un peu frileuse sans doute, mais j'ai un truc qui marche et pour lequel j'ai envie de partager les informations.
Plusieurs solutions se sont présentées et étant développeur "ma" facilité est celle-ci … (je n'ai pas la flemme pour coder par contre pour chambouler une infra et des outils qui touchent à la sécurité je suis plus frileux).
Dernier argument, quand on cherche des adminsys on en trouve beaucoup plus facilement qui connaissent déjà fail2ban que n'importe quoi d'autre d'équivalent… et l'air de rien c'est aussi un argument à prendre en compte.
eric.linuxfr@sud-ouest.org
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 0.o
Posté par Faya . Évalué à 4.
Je suis preneur de plus d'explications sur ce que tu as compris parce que je ne l'ai jamais testé mais je trouve l'idée intéressante
# Fail2ban
Posté par barmic 🦦 . Évalué à 6.
Je ne suis pas très enthousiaste avec fail2ban, je trouve que c'est une solution complexe et peu utile quand on cherche à sécuriser du ssh. Néanmoins, mon hebergeur est consciencieux et se tape des coups de flip quand mon serveur reçoit trop de tentatives de connexion.
J'ai étudié mes logs et j'ai quelques ip qui font beaucoup de tentatives des fois avec quelques jours d'absence et beaucoup de tentatives via des ip uniques.
Bref ça marche pas très bien avec fail2ban, je test la mise en place d'une simple liste d'ip autorisées chiffrée et signée que mon serveur va régulièrement aller chercher et mettre à jour. C'est plus simple et très efficace. Il est au final plus simple de lister les ip autorisées qu'interdites.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban
Posté par eric gerbier (site web personnel) . Évalué à 6.
ok pour du ssh : on connait en général ses utilisateurs. Mais pour d'autres services comme des sites web, c'est plus difficile.
Pour moi, fail2ban est un outil
- qui a une utilisation très simple si l'on prends les config prédéfinies
- qui a une souplesse incroyable si l'on sait écrire des regex pour définir de nouveaux filtres
[^] # Re: Fail2ban
Posté par barmic 🦦 . Évalué à 2.
Je met sincèrement en doute la pertinence de ses règles justement. Je vois beaucoup de monde en parler juste pour ssh, n'autoriser que les connexions par clefs est à la fois plus efficace et plus simple. Il n'est jamais mesuré sa pertinence (les ip ban tentent t'elles une requête après avoir était ban ? est-ce que les ip ballotent : se font ban, libérer, reban, relibérée, rereban,…).
J'irais pas jusqu'à dire incroyable, mais oui tu peux en faire des choses quand tu écris tes regex et tes actions. Perso je m'amuserais bien à ban les ip qui tentent d'accéder à ma machine en ssh en lisant les log de netfilter. Ça peut donner des hacks assez rigolos aussi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban
Posté par claudex . Évalué à 6.
Alors, je ne fais des stats régulières, mais j'ai déjà eu plusieurs centaines d'IP bloquées. Donc, il y en a qui essayent régulièrement. Et j'ai même constaté (encore une fois, ponctuellement) que les IP qui insistaient étaient celles qui tentaient un bruteforce des mots de passes, alors que celles qui ne passent qu'une fois essayent un user/password générique (d'ailleurs, tu es obligé de réutiliser des IP si tu veux faire du bruteforce (même en réduisant les possibilités)).
Ensuite, ça sert aussi de honeypot, s'ils tentent un bruteforce sur ssh et sont bloqués, ils ne pourront pas tenter sur un autre service. Et ce que j'ai constaté, c'est qu'ils ont tendance à d'abord essayer ssh avant d'essayer un service web qui leur donnera moins d'accès.
Je ne pense pas que fail2ban soit le graal de la sécurité mais ça fait une couche supplémentaire. Avantage aussi, ça évite de pourrir les logs avec pleins d'authentifications inutiles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fail2ban
Posté par barmic 🦦 . Évalué à 4.
De ce que j'ai vu dans mes logs, tu as des stratégies assez patientes avec des attentes de plusieurs jours entre des salves d'attaques.
C'est la stratégie que je voudrais mettre en place, mais bien plus agressive puisqu'au premier paquet que tu envoie sur le port 22 sans être autorisé t'es grillé sur tout le serveur.
J'ai beaucoup plus confiance en mon serveur ssh qu'en ce que fera fail2ban. Pour casser l'une de mes clef privée, il faut en vouloir.
Oui mais du coup moi j'avais 1/3 de mes tentatives qui étaient uniques, fail2ban ne peut rien contre ça.
C'est justement quand j'ai vu ça que j'ai décidé de passer à une liste autorisée plutôt qu'une liste d'exclusion, ça colle bien plus au besoin.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban
Posté par claudex . Évalué à 5.
C'est bien quand tu as la liste des IP qui vont pouvoir se connecter, ce n'est pas toujours le cas, entre mon adresse qui change sur mon adsl et mon adresse qui change en 4g ou un autre endroit où je pourrais me connecter, ça fait pas mal de possiblité.
Oui, mais fail2ban n'est pas là que pour ssh. Et ça m'est déjà arrivé de devoir laisser l'autorisation par mot de passe pour certains comptes car certaines appli (genre pour du sftp) ne permettait pas l'utilisation de clef (bon, c'est vrai que ça date).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fail2ban
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 15 juillet 2021 à 21:29.
Cette liste n'est pas dynamique, le serveur récupère régulièrement la liste des ips autorisées. C'est un fichier chiffré et signé, je ne crains pas qu'il soit falsifié. Le port knocking est aussi fait pour ça.
Je préfère généralement l'analyse de trafic. Les reverse proxy font ça très bien et sont très souples dans leur configuration.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban
Posté par flan (site web personnel) . Évalué à 3.
Mais mais tu peux utiliser les deux solutions en parallèle : uniquement par clef (ou « équivalent », genre Kerberos/GSSAPI) et fail2ban.
D'une part, tu n'es jamais à l'abri d'une erreur de config de ton SSH, et d'autre part ça permet parfois d'alléger les logs SSH.
Quand tu en as la possibilité, tu peux aussi n'autoriser que certaines IP à se connecter à ton SSH.
[^] # Re: Fail2ban
Posté par barmic 🦦 . Évalué à 2.
La simplicité de mise en place d'une authentification par clef privée uniquement me laisse penser que le risque est assez réduit et tu peux dire la même chose de fail2ban qui, mal configuré, peut DOS ton serveur.
C'est ce que je fais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban
Posté par eric gerbier (site web personnel) . Évalué à 2.
Pour ssh, j'applique la même politique que toi : que des authentifications par clef (et un mot de passe énorme aléatoire).
Fail2ban mets les ip en quarantaine, c'est à dire qu'il les bloque temporairement. Si elles reviennent régulièrement, il y a plusieurs mécaniques possibles :
- le filtre recidive (/etc/fail2ban/filter.d/recidive.conf) qui exploite les log de fail2ban
- depuis la version 0.11.1, une fonctionnalité "incremental bantime", qui augmente à chaque ban la durée de la quarantaine
dans les filtres rigolos, je peux citer https://github.com/sikevux/fail2ban/blob/master/portscan.conf qui permet de bloquer les scan de port via les log netfilter
[^] # Re: Fail2ban
Posté par barmic 🦦 . Évalué à 2.
Dans l’hypothétique cas où ton serveur ssh perd sa configuration ?
C'est vrai que pour un serveur web, ban du serveur web toute ip ayant tenté d'envoyer un paquet ailleurs que sur le port 443 (et 80 pour les navigateurs qui commencent en http plutôt qu'en https) ça peut être marrant. Mais faut faire gaffe à la mutualisation des ip v4 du coup.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# corosync ou un dossier commun
Posté par NeoX . Évalué à 5.
ta liste d'IP failbanned se trouve dans /etc/hosts.deny
suffirait de propager ce fichier
soit en le stoquant à un seul endroit (NFS par exemple)
soit en le synchonisant quand il change (inotify + rsync, ou bien des outils clusters comme corosync)
[^] # Re: corosync ou un dossier commun
Posté par rycks . Évalué à 10.
Heu …
"y dit qu'il voit pas l'rapport" :-)
Plus sérieusement, le hosts.deny est complété par fail2ban dans le cas précis où on utilise la règle action = hostsdeny
Ensuite comme tu le dis il "suffirait" de propager le fichier, et c'est là que les solutions se bousculent …
NFS ? pardon mais je ne me vois pas monter un serveur NFS pour ça et ensuite faire 30 montages NFS depuis les 30 vm (ou plus) … sans compter les accès en écriture concurrents ça risque de donner un beau bordel au final à mon avis
inotify+rsync … pourquoi pas, ça demande quand même à faire le rsync de 1 serveur -> 30 vm mais comment faire quand les 30 vm collectent aussi les données à blacklister ? les 30 font des rsync vers les 30 autres chaque fois que l'une d'entre elle détecte une nouvelle ip ?
ou alors on rsync vers un "serveur central" lequel ensuite répercute vers les autres ?
corosync et autres outils du genre posent la même question
C'est bien pour ça que je me suis lancé dans le dev de fail2band : un serveur central qui récupère toutes les données de tous les serveurs et met à dispo des autres les données mutualisées, propres, dédoublonnées, triées et uniquement le diff par rapport à la synchro précédente.
Chaque serveur a sa clé d'API "individuelle" permettant ainsi lorsqu'il pousse ou récupère la liste d'avoir les données différentiées par rapport aux autres serveurs de son "groupe".
En tant qu'administrateur j'ai un compte et autant de clé d'api que j'ai de serveur.
Voilà le principe de fonctionnement:
- serveur 1 envoie une ip à blacklister (ip1)
- serveur 2 envoie un autre ip à blacklister (ip2)
- serveur 3 demande quelles sont les ip en backlist et recoit ip1,ip2
- serveur 1 demande quelles sont les ip en backlist et recoit ip2 (car ip1 il l'a déjà vu que c'est lui qui l'a envoyé)
- serveur 2 demande quelles sont les ip en backlist et recoit ip1 (car ip2 il l'a déjà vu que c'est lui qui l'a envoyé)
- serveur 3 demande quelles sont les ip en backlist et recoit (rien) car aucune ip n'a été ajoutée en blacklist commune depuis sa dernière requête
eric.linuxfr@sud-ouest.org
# blocklist.de
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Je ne l'ai jamais utilisé (j'aime pas trop fail2ban que je trouves lourdingue) mais il semble que blacklist.de soit un service de mutualisation de fail2ban
[^] # Re: blocklist.de
Posté par rycks . Évalué à 4.
Certes … c'est bien pour ça que je l'ai listé dans le message initial :)
Mais je n'ai pas trouvé les sources du serveur blacklist.de et donc pas d'auto-hébergement possible (sans compter les questions habituelles d'audit du code du serveur, de gouvernance, de pérennité etc.).
eric.linuxfr@sud-ouest.org
# Maintenant on a des outils de message queuing comme RabbitMQ ou MQTT ....
Posté par totof2000 . Évalué à 2.
… mais à une époque je crois que j'aurais utilisé les queues lpd pour faire ce genre de boulot (je m'étais amusé à une époque à utiliser ces queues en files d'attente pour jouer des MP3).
[^] # Re: Maintenant on a des outils de message queuing comme RabbitMQ ou MQTT ....
Posté par Anonyme . Évalué à 4.
Quand je travaillais chez OVH, on utilisait serf pour propager un message et exécuter iptables.
[^] # Re: Maintenant on a des outils de message queuing comme RabbitMQ ou MQTT ....
Posté par totof2000 . Évalué à 2.
C'est de la balle ce truc …. On reconnaît la "patte" ashicorp : un truc relativement simple à mettre en oeuvre et qui fait des "miracles".
Merci pour le lien, je le ressortirai.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.