L'honorable fail2ban semble utilisé sur de très nombreuses petites infrastructures. NdM: Fail2ban est un framework de prévention contre les intrusions, écrit en Python (Wikipédia), ou dit autrement à bloquer et bannir des pénibles. Il est diffusé sous GPLv2+.
Il était installé sur mes serveurs, avant que j'essaie de le remplacer.
Mais dis-moi, pourquoi remplacer fail2ban ?
- Parce que fail2ban est lent
- Parce que sa configuration est très désagréable et mal documentée.
Mais dis-moi, il doit bien exister une alternative ?
Avant de me lancer yeux fermés dans l'implémentation d'une alternative, j'ai fait le tour du propriétaire libre :
- sshguard est uniquement adapté à SSH.
- crowdsec semble chouette, mais adapté à des grosses infras et à des workflows compliqués. De plus, je n'ai pas réussi à l'installer.
- salt est plus un WAF (Web Application Firewall). Pareil, semble chouette mais adapté à des grosses infrastructures.
- minos, développé par Exarius (un des CHATONS), efficace mais ne supporte que les logs stockés dans des fichiers texte et le pare-feu nftables.
- pyruse, que je découvre aujourd'hui sur LinuxFr.org avec l'étiquette fail2ban. Uniquement adapté à systemd/journald.
Cri de joie, de toutes les alternatives que j'ai trouvé, fail2ban semble être encore le mieux adapté !
Après 6 mois de développement à temps très partiel, je suis fièr·e de vous présenter mon petit bébé : reaction.
NdM: écrit en Go et C, placé sous AGPLv3.
Action… Réaction !
L'article sur mon blog présente le logiciel en détail, alors je vous fais un résumé que j'espère convaincant :
- À charge de travail égale, reaction consomme 30x moins de CPU et 10x moins de RAM.
- Il est codé en Go, ce qui est pour ce cas d'usage un bon équilibre entre facilité de développement et efficacité.
- La configuration est possible en JSON, YAML ou JSONnet.
- JSONnet est un langage étendant JSON, permettant d'écrire des commentaires, de définir des variables, des fonctions… Je l'aime beaucoup. C'est un peu comme le langage Nix de NixOS, mais avec une syntaxe agréable.
- Protéger un service, c'est seulement 8 lignes de configuration environ !
- Contrairement à fail2ban, reaction ne vient pas avec ses 160 fichiers de configuration par défaut (soit 8900 lignes de TOML bizarre).
- Au lieu de ça, il y a un wiki centralisant des bonnes pratiques, des expressions rationnelles (regex), des exemples, une FAQ.
Aperçu de la configuration
Je vous présente le coeur du fichier de configuration, en utilisant cette fois le YAML.
En remplacement des jails de fail2ban, on a des streams, qui définissent une source de données (par exemple tail -f /var/log/nginx/access.log pour nginx).
streams:
ssh:
cmd: ['journalctl', '-fu', 'sshd.service']À ces streams, on attache un ou plusieurs filters. Ce sont des groupes d'expressions régulières. C'est aussi sur un filter qu'on décide du nombre de mauvais essais (retry) qu'on accorde à une IP avant de réagir.
streams:
ssh:
cmd: ['journalctl', '-fu', 'sshd.service']
filters:
fail:
regex:
- 'authentication failure;.*rhost=<ip>'
retry: 3
retryperiod: '3h'À un filter, on rajoute une ou plusieurs actions, qui seront exécutées quand il se déclenche.
streams:
ssh:
cmd: ['journalctl', '-fu', 'sshd.service']
filters:
fail:
regex:
- 'authentication failure;.*rhost=<ip>'
retry: 3
retryperiod: '3h'
actions:
ban:
cmd: ['iptables', '-w', '-A', 'reaction', '-s', '<ip>', '-j', 'DROP']Elles peuvent être effectuées tout de suite, ou être délayées avec after, ce qui permet de bannir une IP maintenant, et de la débannir quelque temps plus tard.
streams:
ssh:
cmd: ['journalctl', '-fu', 'sshd.service']
filters:
fail:
regex:
- 'authentication failure;.*rhost=<ip>'
retry: 3
retryperiod: '3h'
actions:
ban:
cmd: ['iptables', '-w', '-A', 'reaction', '-s', '<ip>', '-j', 'DROP']
unban:
cmd: ['iptables', '-w', '-D', 'reaction', '-s', '<ip>', '-j', 'DROP']
after: '24h'Je recommande toutefois d'utiliser JSONnet, qui permettra d'éviter les répétitions, ici en définissant un ensemble d'actions banFor :
local banFor(time) = {
ban: {
cmd: ['iptables', '-w', '-A', 'reaction', '-s', '<ip>', '-j', 'DROP'],
},
unban: {
after: time,
cmd: ['iptables', '-w', '-D', 'reaction', '-s', '<ip>', '-j', 'DROP'],
},
};
{
streams: {
ssh: {
cmd: ['journalctl', '-f', '-u', 'sshd.service'],
filters: {
login: {
regex: [ @'authentication failure;.*rhost=<ip>' ],
retry: 3,
retryperiod: '3h',
actions: banFor('24h'),
},
},
},
},
}
Version 2
Et pour vous vendre quelque chose qui n'est pas encore fait :
La v2 sera capable de fonctionner en grappe, en échangeant en pair-à-pair des adresses IP à bannir (ou des recettes de cuisine, configurez-le comme vous voulez !)
Une bibliothèque Go couvre exactement mes cas d'usage : elle a été écrite pour Nomad, une alternative à Kubernetes.
J'ai donc confiance en l'arrivée de cette v2.
Mais avant de m'y atteler, j'essaie de faire connaitre un maximum reaction, pour avoir des retours le plus tôt possible.
Aller plus loin
- Article de présentation sur mon blog (637 clics)
- Presentation article on my blog (68 clics)
- Git (627 clics)
- 📽️ Action... Réaction ! (168 clics)
- Annonce Fediverse (73 clics)
# Très prometteur
Posté par Emeric . Évalué à 7.
En effet, je me suis pas mal pris les pieds dans le tapis avec fail2ban et des environnements atypiques notamment à base de dockers.
Je vais pouvoir tester ça…
[^] # Re: Très prometteur
Posté par totof2000 . Évalué à 4.
Pour moi le gros défaut de fail2ban était d'être écrit en python : conséquences : le probmème de lenteur évoqué par le P.I.
L'alternative proposée semble être écrite dans un langage mieux adamté au besoin.
Oui, je suis d'avis qu'utiliser un langage comme Python pour un serveur ayant besoin de perf (en l'ccurence peu de latence) est une erreur. Ca ne tient pas la charge, sauf à "tricher" à utiliser du code écrit en C et à utiliser Python pour lier le tout.
[^] # Re: Très prometteur
Posté par barmic 🦦 . Évalué à 7.
C'est pas le fonctionnement de base de python ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Félicitations!
Posté par Xavier Vello (site web personnel) . Évalué à 6. Dernière modification le 02 décembre 2023 à 12:19.
Félicitations pour cette release, et merci de partager ton travail. Je m'étais aussi pris les pieds dans la configuration de
fail2banet ai migré verssshguard, regrettant de laisser nginx non protégé. Je vais testerreaction!Tu mentionnes un wiki pour partager des configs, mais sans lien depuis la dépêche ni ton blog. N'hésite pas à ajouter un lien plus proéminent vers https://framagit.org/ppom/reaction-wiki
[^] # Re: Félicitations!
Posté par ppom . Évalué à 1.
Merci, bien vu !
J'ai ajouté le lien sur les articles de blog, mais je n'ai pas trouvé en 5 min comment éditer la dépêche 😅
[^] # Re: Félicitations!
Posté par BAud (site web personnel) . Évalué à 2.
seuls les forums et entrées de suivi sont éditables par la personne qui en est l'auteur (ajouter [résolu] au sujet par exemple ou ajouter des précisions ou synthèse de ce qui a fonctionné…) ; pour les dépêches il n'y a que la modération qui peut éditer, avec le texte que tu peux suggérer en commentaire.
cf. https://linuxfr.org/aide#aide-authentification (et plus bas ce que la modération peut faire)
[^] # Re: Félicitations!
Posté par ppom . Évalué à 1.
J'en profite pour informer à la ronde que le wiki est maintenant tout joli et disponible ici : https://reaction.ppom.me 🎉
# streams
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Est-ce que les "streams" ne fonctionnent que par analyse de logs? Est-ce que reaction pourrait directement "manger" d'autres types de flux (traces opentelemetry? kafka?) ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: streams
Posté par ppom . Évalué à 3.
Les streams ne fonctionnent que par analyse de lignes de textes. Si tu as un outil qui permet de "suivre" un flux et de le transformer en ligne de texte, c'est tout bon !
On peut penser à
docker logs -f,journalctl -f,tail -f,tail -f | jq,swaymsg -m,inotifywait -m…Je ne connais pas vraiment kafka ni opentelemetry, mais il doit bien y avoir un utilitaire qui permet ça.
Ça fait partie des choix de design qui sont importants pour moi. J'estime que les commandes de coreutils, systemd, docker et consorts sont censées être optimisées. Et j'ai envie de limiter au maximum d'avoir dans la base de code de reaction des développements spécifiques. Je pourrais dire que c'est pour respecter la tradition UNIX, KISS, etc, mais c'est surtout pour m'éviter de maintenir du code déjà écrit ailleurs 😉
# crowdsec
Posté par remyd1 . Évalué à 3.
Bonjour,
Pour info, crowdsec peut être compliqué, mais l'installation ne l'est pas.
Cf. cette vidéo de Korben : https://www.youtube.com/watch?v=5K7Aj5ya7uI
Bravo quand même pour l'initiative.
[^] # Re: crowdsec
Posté par Xanatos . Évalué à 4.
Admettons et pour un pauvre serveur autohébergé ?
Avec les années j'essaye de simplifier, j'ai une vie à côté.
Si certains ont des retours d'expérience (écrits) je suis intéressé.
[^] # Re: crowdsec
Posté par Astaoth . Évalué à 3.
Pour un petit serveur autohébergé dont on ne veut pas s'occuper, c'est parfait : crowdsec consomme très peut de ressource, pour l'installation il suffit littéralement de copier-coller les 2 commandes de la doc, et la commande de management ''cscli'' a tendance à très facilement afficher l'aide pour aider.
Pour avoir pu échanger avec leur équipe, ils sont très friand de retours pour voir ce qu'ils pourraient améliorer pour simplifier la vie des gens (la doc, les petits textes d'aide, l'interface, etc).
Emacs le fait depuis 30 ans.
[^] # Re: crowdsec
Posté par Xavier Vello (site web personnel) . Évalué à 10.
Bien que décrit comme "a community-driven project", le projet CrowdSec est porté par l'entreprise du même nom qui a levé 14 millions de d'euro de capital risque (de la VC money, d'investisseurs qui réclameront leur argent dans 5 ans).
Après les doigts d'honneur que Mongo, Elastic, Hashicorp (et d'autres) ont fait à leur communauté, je suis très frileux quand une société me propose son produit gratuitement. Je pars maintenant du principe qu'il sera probablement proprio l'an prochain, et évalue si je pourrai en sortir facilement quand ce sera le cas. Pour un tel produit d'infrastructure, ma réponse est non, donc je passe mon chemin.
Je privilégie maintenant les produits purement communautaires, ou maintenus par une société dont ce n'est pas le produit principal. Et je refuse de signer un CLA, sauf si je suis payé pour ma contribution.
[^] # Re: crowdsec
Posté par xandercagexxx . Évalué à 10.
Je pense que le souci c'est la perversion des entreprises à présenter des projets comme opensource alors que ce sont en réalité des projets opencore (l'opensource est pour appâter le chaland).
A l'OSXP 2022, certain produit présenté comme de l'opensource, était en réalité de l'opencore dès qu'il s'agissait de fonctionnalité dite "avancé". Pas possible de brancher les outil sur du LDAP par exemple, sauf en payant le module entreprise (non opensource bien sûr)
C'est la misère ce genre d'approche.
J'ai découvert ça aussi avec Rustdesk, qui est présenté comme l'alternative Opensource à Teamviewer, mais c'est de l'opencore aussi.
Je digrèsse un peu, mais au boulot on avait essayé Workadventure pour des échanges plus "fluide" avec les gens à distance. Quand on contacté la boite derrière l'outil, pour connaître leur tarif de support technique pour autohéberger la solution, nous avons découvert que la simple sécurisation d'un salon, était en fait dans la feature payante, non auto-hébergeable, et qu'il n'y avait pas de support possible en dehors des offres SaaS. La réponse était "il faut bien que l'on gagne de l'argent, et notre solution c'est de rendre propriétaire les features importante" (l'opensource c'est vraiment le travail de communication et de marketing en fait).
De mémoire pour crownsec, c'est pareil. Le produit en mode, je le met sur un serveur, c'est la partie opensource (mise a jour des liste 1 fois par jour). Si je veux un truc utilisable dans une infra (avec partage de blacklist en temps réel par exemple), il faut la licence entreprise (2500 $/mois), et cela ne semble pas être une partie opensource.
Le problème c'est pas que ce soit le produit d'une entreprise, le problème c'est que ce type d'entreprise ne fait pas de l'opensource par conviction, mais juste par intérêt pour la communication (c'est tendance). Une entreprise, peut très bien juste faire payer du service.
Les artisants en france, c'est des entreprises, et il propose du service. Un plombier ne pose pas que des robinets dont il serait le seul à avoir les outils pour le démonter :)
[^] # Re: crowdsec
Posté par Astaoth . Évalué à 3.
C'est une très bonne question. Tout a l'air d'être dispo sur leur github, et la version payante pour entreprise sert à apporter un support, et à avoir la possibilité de ne pas participer à la communauté de blacklist.
Crowdsec n'est pas comparable à un f2b dans le sens où t'as la partie communauté qui est présente. J'imagine que les versions payantes sont là pour financer le développement déjà (et ca se voit, crowdsec a une interface plus aboutie que f2b), la partie serveur pour partager les blacklists communautaires, et t'as également un dépôt de modules (j'en ai vu aucun payant) un peu comme grafana.
Tu peux utiliser la version gratuite dans une infra avec tout tes bounceurs qui parlent à un même serveur centrale dans la version gratuite, il me semble.
On peut ramener le problème dans l'autre sens aussi. Quand on a ses petits serveurs selfhostés, avoir un f2b qui demande moins de temps de setup (les filtres par défaut ne me conviennent pas), avec des blacklists communautaires toutes faites, une interface cli propre et simple à utiliser, opensource et audité, avec des modules libres pour les différents services qui peuvent tourner, ca reste toujours intéressant.
Peut-être que dans 5 ans leur version communautaire sera moins intéressante ou proprio. Mais pour l'instant elle fait l'affaire, comme f2b a pu l'être en son temps.
Emacs le fait depuis 30 ans.
[^] # Re: crowdsec
Posté par xavier Granveaux . Évalué à 2.
"Tout a l'air d'être dispo sur leur github […]"
Tout ? même ma partie serveur pour être indépendant ?
[^] # Re: crowdsec
Posté par Astaoth . Évalué à -1.
Tu veux dire la partie pour gérer les listes communautaires ? Je crois pas, mais d'un autre côté je vois mal le cas d'usage.
D'un côté on ne peut pas avoir de garanti que le code publié serait bien celui qui tourne chez eux.
De l'autre, je vois mal l'intérêt de selfhost mon propre serveur de communauté, les blacklists seraient assez vide. Si je veux partager mes listes de blocages entre l'ensemble des serveurs, je me contenterais de juste déployer les bouncers sur les clients, et de les connecter à un serveur de management central (ca a l'air d'être concu pour). Ou alors c'est pour faire sa propre communauté dans son coin ? Mais casserait un peu l'intérêt de crowdsec pour le coup.
A moins que tu dises ca par rapport à la propriété des blacklists ? Ca serait intéressant de voir si ils comptent traiter les tickets demandant d'importer ses propres black/white/listes (ouverts en 2022).
Emacs le fait depuis 30 ans.
[^] # Re: crowdsec
Posté par xavier Granveaux . Évalué à 5.
Intéressant …
J'imagine assez bien, sans trop d'efforts, un format de publication des listes de blacklist qui peuvent etre importée, ou pas, dans une instance.
Donc dans ce cas, peu importe que la version "Enterprise" hostée soit celle des sources ou pas … dans la mesure ou je pourrais avoir mon instance centrale pour ma communautée, bâtie elle à partir des sources, et que j'enrichirais des listes de une ou plusieurs instance, dont la principale par exemple.
On pourrait même envisager que je purges certains blocages, car, dans mon usage, je ne souhaite pas les bloquer. Imaginerions un scénario type censure ?
Je trouve qu'un modèle de type C&C où les agents sont open source, mais ou le serveur de contrôle ne l'est pas … n'est pas un modèle OpenSource, et surtout pas Open.
( on me soufflera dans l'oreille que les agents peuvent fonctionner de manière autonome … mais où serait l'intérêt ? )
[^] # Re: crowdsec
Posté par Astaoth . Évalué à 2.
L'intérêt c'est d'avoir un manager centralisé pour plusieurs serveurs, et donc de partager les listes de bloquages avec ses serveurs persos.
Tu peux déjà gérer ta whitelist sur ton manager.
Emacs le fait depuis 30 ans.
[^] # Re: crowdsec
Posté par Zatalyz (site web personnel) . Évalué à 10.
Ça dépend du parc qu'on gère mais si on a suffisamment de serveurs connectés, à mon avis on peut alimenter "tout seul" une jolie liste. Et puis justement, si on peut faire communauté… et bien on peut choisir "avec qui".
Ça c'est pour moi la raison pour laquelle je ne passerais pas à Crowdsec. Je ne les connais pas, ces gens. Je ne sais pas pourquoi ils décident de bloquer telle ou telle adresse. Des blocklists issues de communautés auxquelles je participe, où à qui je fais confiance, ça m'irait mieux. Et oui, je veux pouvoir boire un thé avec chacun des sysadmins avec qui je me "lierais". Je peux voir l'intérêt de mutualiser les blocklists, là-dessus pas de souci, mais je me méfie aussi des politiques qui les alimentent. On a encore plein de sysadmin de bonne foi qui bloquent suivant la géolocalisation. Or pour m'être amusé à des stats sur mon serveur mail, les plus pénibles ne sont pas forcément de pays mal aimés (y'en a, mais pas que), et il y a des choses légitimes aussi de la part de ces pays. Qui me dit que Crowdsec n'applique pas ce genre de bannissement un peu trop large et orienté ? Qui me dit qu'ils n'ont pas décidé, par soutien idéologique, de bannir tel et tel serveur avec qui je n'ai personnellement aucun souci ?
Enfin, peu importe que ça a un intérêt ou pas. Quand on communique en grand sur le fait d'être open-source, c'est malsain de rajouter des petits caractères pour dire "sauf ce module et ce module". Si je ne peux pas le faire tourner en entier chez moi, je ne peux pas avoir confiance en celui qui me le vend comme service, et ça reste du propriétaire avec de l'openwashing.
[^] # Re: crowdsec
Posté par Astaoth . Évalué à 2.
Pour un setup perso, tu peux déjà le faire en connectant tes bouncers à un manageur distant au lieu de local.
Tu te doutes que les blockages des autres ne sont pas reproduit directement chez toi. Pour qu'une IP soit intégrée à la blacklist, t'as différents critères, comme le nombre de remonté de la dite IP, la diversité des AS d'où proviennent ces remontées, etc.
Je crois que les blacklistages manuels ne sont pas remontés, seuls ceux détectés par les scénarios le sont.
Pose leur la question, ils te feront une jolie réponse en francais ;)
Je l'ai fait justement au lieu de supposer des trucs au hasard, d'où le paragraphe précédent. Et vu mes logs, il n'y a pas de blocage géographique dans leur liste, ce qui serait de toute facon assez stupide vu l'état du marché de l'IPv4.
Par contre tu peux le faire manuellement dans Crowdsec, et ca ne sera pas transmis à la communauté.
Tu te doutes bien que ce genre de problème est commun à tout le monde, selfhosted comme entreprises. Et tu te doutes que Crowdsec n'a aucun intérêt que ca arrive si ils veulent garder leur crédibilité.
Libre à toi d'utiliser ou pas la partie proprio, au même titre que tu es libre d'installer ou pas les drivers Nvidia proprio dans une Debian.
Mais du coup, est-ce que tu trouves ca malsaint les distributions qui embarquent le driver nvidia proprio, qui te préviennent et te permettent de les déployer avec le driver libre si tu le souhaites ? Pour toi ce ne sont pas des OS libre du coup ?
J'ai un doute sur le fait que ca soit la définition de l'open source ca. Par exemple Signal app est open source, tout est dispo, mais tu ne peux pas le faire tourner en l'état chez toi, tu vas avoir besoin de faire quelques modifs avant.
Par contre libre à toi de forker la partie libre de Crowdsec pour pouvoir gérer ta propre communauté de blacklist. C'est aussi ca le libre, ne pas forcément rejeter tout en block parce qu'un petit truc te plait pas, c'est aussi avoir la possibilité de forker et de redistribuer librement les modifications. De ce point de vu là, la partie open source de Crowdsec respecte d'ailleurs les 4 libertés du LL, je ne vois pas spécialement d'openwashing.
Je trouve ca dommage de crier au loup juste parce que tu n'aimes pas le produit.
Emacs le fait depuis 30 ans.
[^] # Re: crowdsec
Posté par barmic 🦦 . Évalué à 4.
Tu n'a aucun moyen de savoir quoi que ce soit sur un service. Tu peux avoir un code libre qui a l'air de se comporter comme le code libre que tu as sous les yeux, mais ça n'indique rien. Par construction le libre ne te donne aucune garantie, même en AGPL. Je pourrais utiliser le même code libre que je te distribue mais avoir un bout non libre pour faire ma tambouille
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . Évalué à 5.
Sur le point de l'algorithme de consensus, il est débattu et partagé, et vous pouvez y participer notamment sur notre discorde. Le principe est simple, une IP est ajoutée dans la blockliste quand elle est reportée par assez de membres du réseau, qui ont passé leur période de quarantaine, offrant assez de diversité en terme d'AS source et que cette IP n'est pas dans une whiteliste (genre m$ update, google bot, 8.8.8.8, etc.).
C'est du stream donc quand la pression mise par la communauté est suffisante, l'IP entre dans la blockliste et quand elle diminue et passe sous un certain niveau, elle est retirée.
l'agent est en MIT license, ce qui je pense reste de l'open source, mais libre à chacun de le décider. Le partage de signaux est optionel et désactivable.
Enfin en ce qui concerne la facon dont les signaux sont traités, c'est effectivement une API et pas local. Le code n'est pas publié pour trois raisons principales: 1/ c'est pas mal d'infra as code, car ca tourne sur des micro services donc c'est difficile à installer en local pour des utilisateurs et 2/ c'est en permanente évolution donc itérations rapides, donc ca serait complexe à open sourcer et maintenir avec le bon niveau de documentation à jour, de commentaires, etc. 3/ le faire tourner à échelle local ne fait pas énormément de sens par rapport au fait de le faire à l'échelle de plusieurs milliers de machines. Mais vous pouvez le faire avec la partie LAPI du soft en local, elle aussi open source et documentée.
Ceci dit, l'équipe est ravie d'échanger avec qui veut pour ces aspects d'algo, on est plus intelligents à plusieurs en la matière.
[^] # Re: crowdsec
Posté par barmic 🦦 . Évalué à 2.
Pardon, mais ce n'est pas une critique en vers vous de ma part. Ce qu'apporte ou non le libre dans un contexte de service est une réflexion de longue date chez moi et je ne suis pour autant pas complètement tranché sur le sujet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: crowdsec
Posté par orfenor . Évalué à 4.
Tu exagères ou bien tu es mal informé, Rustdesk est largement libre et ouvert, c'est pas de l'OpenCore avec un petit bout libre :
[^] # Re: crowdsec
Posté par xandercagexxx . Évalué à 4.
J'ai pas vu d'accès a l'administration simple d'un parc de machine dans la version libre de Rustdesk (mais peut-être que je l'ai loupé, je suis qu'un humain 😁 ).
Je l'ai juste vu dans la partie offre SaaS.
L'opencore, c'est pas un souci. C'est juste que faut accepter d'être transparent sur l'outil et pas juste dire : outil opensource et avec *sauf l'administration qui est payante et en saas.
Gitlab c'est de l'open core aussi. Tu a la version CE opensource sans licence, et la version avec licence payante pour les options avancées. Pour moi c'est ça l'opencore.
Si tu as accès à toutes les features, mais que leur mise en marche nécessite de mettre les mains dans le cambouis pour le faire marcher, pour moi c'est good (tu vends du support er de la simplification, mais tu ne vend pas l'accès au code). Maintenant, si tu ne peux pas en réalité mettre en place la version avancé car le code est pas disponible. Le fait de dire : tu peux développer toi même les briques avancé; ba c'est pas la définition d'un logiciel opensource (à mon sens).
Ce serait comme dire : l'OS debian est opensource mais si tu veux pouvoir l'utiliser, il faut soit que tu paye, soit que tu developpe tout l'installateur et les modules pour que les briques fonctionne entre elle. A mon sens, ce qui fait que debian est opensource, c'est que l'os est opensource et utilisable. Et ensuite, tu peux paser par des prestataires de ton choix, pour le mettre en oeuvre, pour le corriger ou l'améliorer. Mais la feature de gestion de compte utilisateur n'est pas une brique payante de Debian, c'est integré (brancher debian sur un ldap, ça ne nécessite pas de payer une version "debian entreprise").
Pour moi, la puissance/l'intérêt de l'openSource c'est pas juste une histoire de licence sur certaines brique du logiciel, c'est bien la possibilité d'être autonome si besoin.
Je ne dis pas que les entreprises n'ont pas à gagner d'argent, mais les autres briques pourraient très bien être aussi opensource et disponible, m1is pas packagé par exemple. C'est quand même différent, non ?
🤓
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . Évalué à 2.
Je le détail plus bas dans mon commentaire, mais j'aurais du l'inclure ici pour la lisibilité, désolé. Nous créons un network effect, l'outil est un moyen pas une fin. Si monétisions notre security engine demain, notre réseau s'éffondrerait et nous n'aurions donc plus de data a vendre à nos clients, d'où notre intérêt (collectif) à ce qu'il reste gratuit.
[^] # Re: crowdsec
Posté par raphj . Évalué à 7.
J'aime beaucoup l'image :-)
[^] # Re: crowdsec
Posté par xandercagexxx . Évalué à 1.
Merci raphj 😘
[^] # Re: crowdsec
Posté par Maclag . Évalué à 10.
Tu viens de me donner une idée. Je vais lancer un nouveau concept tout-en-un: tu n'achètes plus juste la plomberie, tu achètes un service fourni par la plomberie. En choisissant nos produits, tu signes un contrat à long terme qui comprend l'installation et la maintenance, ce aussi longtemps que tu souscris au contrat. Si tu souhaites le résilier, pas de problème, un de technicien viendra enlever le produit dont tu ne veux plus.
Nos produits viennent avec des vis et des assemblages non standards, merci de ne pas y toucher, vous n'avez pas les outils pour de toutes façons.
Nos plombiers sont des spécialistes (en fait ils sont en activité RSA minimum obligatoire et chaque intervention est classée dans "formation").
Grâce à une levée de fonds nous allons proposer des produits très nettement en-dessous des prix du marché pour lancer une dynamique.
Je me tâte pour le nom, mais je pensais à Pl-U(m)ber.
[^] # Re: crowdsec
Posté par Glandos . Évalué à 5.
Pour moi, les performances de crowdsec n'étaient pas là : https://discourse.crowdsec.net/t/cpu-usage-is-really-higher-than-fail2ban/1255
Oui, peut-être que c'est la consommation idle, et qu'avec une montée en charge, fail2ban s'en sort moins bien. J'ai passé du temps à envoyer des patchs de perfos sur fail2ban, je vois très bien que c'est pas très scalable.
Mais crowdsec, en plus d'être compliqué à installer, n'avaient pas de meilleures performances :)
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . Évalué à 2.
Nous avons testé CrowdSec sur de très gros setup et il est très performant. De l'ordre de 30 à 60x plus rapide que Fail2ban et nous sommes ouverts à tout benchmark que vous voudriez réaliser. Certains souci de performances sont essentiellement du à des problèmes de configurations ou de formats de logs incorrects par rapport au parser utilisé.
CrowdSec tourne dans des banques avec des centaines de machines, sans être visible dans le top des processus. Si vous avez des besoins particuliers de scaling horizontaux, on monte à 3 milliars de log lines traitées par jour sur 20 vpcu. Les versions plus récentes ont encore gagné en performances, mais on a pas refait le benchmark depuis.
https://www.crowdsec.net/blog/how-to-process-billions-daily-events-with-crowdsec
[^] # Re: crowdsec
Posté par Glandos . Évalué à 2.
Merci de votre réponse, ça fait plaisir d'échanger avec les auteurs :)
Je vais être clair : je ne doute pas que crowdsec soit performant pour lire des tonnes de fichiers de logs. Mon besoin est plutôt sur un petit serveur, avec beaucoup de temps morts (idle mon amour). J'ai déjà essayé de pousser du code dans cette direction là dans différents morceaux de logiciels pour que quand il n'y a rien à faire, le logiciel ne fasse rien, même pas un réveil.
Donc je m'étais contenté d'un benchmark un peu cru, adapté à mon cas d'usage, et il semblerait (chez moi ×2) que crowdsec a une consommation au repos plus élevée. Vu la charge de ma machine, c'est la métrique à laquelle je suis attaché, j'y partage un certain nombre de services sur peu de CPU.
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . Évalué à 1.
Il faudrait creuser mais CrowdSec ne prend du CPU et de la RAM que s'il y a des lignes de logs à traiter. En idle, il ne fait rien de plus que recevoir la blocklist toutes les 5 minutes. Sur un PI4 à la maison, où je fais tourner homeassistant, j'ai un CS qui tourne et il fait 0% du CPU (il tourne en container ici). Au repos sur mon firewall (un intel 4510), il prend 0.2% du CPU et 1.2% de la RAM (soit 48 Mo) pour traiter du bruteforce ssh, et les scans de ports.
Ceci dit je vais remonter l'info à la team pour qu'ils vérifient si il y a des raisons ou cas où CS pourrait consommer du CPU sans qu'il n'y ait d'activité log particulière. Vous avez des consos de quel ordre au repos ?
[^] # Re: crowdsec
Posté par Glandos . Évalué à 2.
J'avais constaté https://discourse.crowdsec.net/t/cpu-usage-is-really-higher-than-fail2ban/1255/2
Donc 2744s de CPU comptabilisé sur 13h de fonctionnement, soit 5%.
On m'avait demandé un pprof, et … oui, je ne suis pas allé plus loin, j'ai eu d'autres priorités qui se sont accumulées.
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . Évalué à 4.
Oui je comprends, c'est un des rapports en ce sens à ma connaissance dans notre discourse.
On a pas ou très rarement de report sur les perfs, et quand c'est le cas, 9 fois sur 10 c'est un souci de parser ou de scenario.
Mais l'équipe était prête à investiguer et le sera toujours. Again, on a des setups à plusieurs dizaines de millions d'events per day et ca ne pose aucun de souci. Jette un oeil sur le post de scaling, on atteind des perf ahurissantes sur des milliards de lignes de logs, qui ne sont clairement pas compatibles avec ce type de souci.
Je ne suis pas spécialiste du point mais à mon avis, ca vaudrait le coup de tester avec un F2B désactivé pour éviter la compétition en read sur la même log source. Le kernel pourrait faire des locks a chaque ajout de ligne.
# Quid du support du protocole IP actuel ?
Posté par dudule42 . Évalué à 4.
Je vois dans les exemples des appels à
iptablesmais aucune utilisation deip6tables.Sur le blog j'ai trouvé:
qui semble matcher des adresses IPv4 et aussi IPv6. Mais toujours pas d'appel à
ip6tables.Une des limitations de fail2ban est l'absence de support d'IPv6. C'est ce qui m'a fait changer pour Crowdsec.
Est-ce que reaction supporte IPv6 ?
[^] # Re: Quid du support du protocole IP actuel ?
Posté par Glandos . Évalué à 9.
https://github.com/fail2ban/fail2ban/blob/1.0.2/ChangeLog#new-features-7
Depuis la version 0.10 alpha 1 de 2016. La version 0.10 finale est sortie en août 2017. Ça a mis du temps, mais IPv6 est supporté depuis bien longtemps dans fail2ban.
[^] # Re: Quid du support du protocole IP actuel ?
Posté par oiseauroch . Évalué à 6.
Il semble que les stream font de simples appel vers une commande bash. Donc j'imagine que que ip6tables fonctionne aussi bien.
Et du coup pour le commentaire en dessous, j'imagine que nftable peut aussi s'utiliser.
[^] # Re: Quid du support du protocole IP actuel ?
Posté par Pol' uX (site web personnel) . Évalué à 5.
Pour abonder dans le sens que le support d'iptables n'est pas suffisant pour ce genre d'usage, une petite anecdote.
Un jour avec les collègues on a eu à faire face à un joli ddos sur un serveur géré naïvement avec fail2ban. La liste de ban a tellement grandi que ce qui effondrait le serveur était le traitement des connexions par le firewall (le coût de traitement des règles iptables est au moins linéaire en la taille du nombre de règle). Nous avons configuré ipset en lieu et place de iptables au niveau de fail2ban, et une fois la modif faite le serveur a rapidement retrouvé son calme.
Bref. Pour ce genre d'usage, la transparence vis à vis du mode de blocage est très utile.
Adhérer à l'April, ça vous tente ?
[^] # Re: Quid du support du protocole IP actuel ?
Posté par Glandos . Évalué à 4.
ipset pour iptables, ou un set dans nftables devrait être la configuration de base pour le bannissement. C'est compliqué d'un chouïa, et c'est même plus lisible à lire.
[^] # Re: Quid du support du protocole IP actuel ?
Posté par ppom . Évalué à 4.
Je prendrais avec grand plaisir un exemple de configuration qui utilise nativement
nftables! J'ai fait la doc aveciptablesparce que c'est ce que je connais, mais il faudra bien que je me mette ànftablesun jour 😁N'hésitez pas à alimenter le wiki si vous utilisez reaction !
[^] # Re: Quid du support du protocole IP actuel ?
Posté par ppom . Évalué à 3.
Bonne question !
On peut voir dans le readme que j'ai également codé un minuscule programme en C,
ip46tables, qui permet d'unifieriptablesetip6tables. Ça fait partie des détails qui sont simplifiés sur le blog, mais détaillés dans la conf exemple et le wiki.# Nftables à la place de iptables ?
Posté par xandercagexxx . Évalué à 9.
Ton projet est intéressant.
Par contre, cela est-il facilement compatible avec nftables qui est le firewall par défaut au moins de Debian12 ?
Vu que j'ai surtout fait des migration depuis la version 8 de Debian, j'ai tjrs eu la continuité avec Iptable. Mais sur de nouveau serveur en Debian12, fail2ban ne marche pas aussi bien/facilement avec du nftables (perso, je réinstall iptables sur cette distribution pour uniformiser mes config).
Pour ce qui est de la complexité, je ne trouve pas fail2ban complexe à configurer, et ce que je trouve pratique c'est qu'il y a déjà des filtres pour pas mal d'outil "historique" ce qui évite d'avoir à construire ses propres regex.
Avec ta solution, existe-t-il une bdd pour les ban en cours, pour les réappliquer en cas de redémarrage du service ? (même genre de question pour les ban issue du bannissement fait avec recidive sur fail2ban, qui j'imagine serais fait avec un autre stream avec ta solution)
Je vais essayer de suivre ce projet de près, car j'ai un peu la même impression que toi sur Crownsec, c'est un projet qui me faisait rêver, mais quand j'avais discuté avec des dev à l'OSXP ya genre 2-3ans, le fait d'avoir aucun module pour Apache m'avais refroidi.
[^] # Re: Nftables à la place de iptables ?
Posté par Zatalyz (site web personnel) . Évalué à 7.
Oui, les ban en cours sont stockés et réappliqués en cas de redémarrage du service. En fait en suivant la config de base, quand on éteint Reaction il vide iptable de ses ajouts, et les remets au redémarrage. Ça limite les doublons et assure une continuité.
[^] # Re: Nftables à la place de iptables ?
Posté par totof2000 . Évalué à 4.
Pour pouvoir le porter sur d'autres OS (xBSD par exemple), ou pour pouvoir gérer les transitions de firewall sur Linux, pourquoi ne pas mettre en place un backend par type de firewall ? Ca permettrait de mettre en place le nécessaire pour iptable, ip6table, nftable, et éventuellement IPF, Packet Filter, IPFW …).
[^] # Re: Nftables à la place de iptables ?
Posté par ppom . Évalué à 6.
En fait sur reaction il n'y a pas de configuration par défaut. Seulement un wiki qui donne des exemples. Pour l'instant il n'y a qu'un exemple de configuration pour
iptables/ip6tables/ip46tables, parce que c'est ce que j'utilise sur mon serveur.Mais j'adorerais qu'une personne qui connait
nftables(et autres) propose des configurations pour d'autres pare-feux !Encore une fois, il n'y a pas de backend officiel.
reactionc'est juste un outil qui lit la stdout d'un programme, matche des regexes dessus, et lance des actions quand il y a un certain nombre de matches.[^] # Re: Nftables à la place de iptables ?
Posté par ppom . Évalué à 3.
cf mes autres réponses à ce sujet !
Je t'en félicite (premier dégré !)
Moi, je m'y perds.
Comme a dit Zatalyz, yep, il y en a une ! Pour la petite histoire, elle fonctionne un peu comme celle de Redis : C'est juste un log (dans un format binaire) des matches et des actions exécutées. Il est réécrit périodiquement pour ne pas dépasser les quelques Mo, en ne gardant que les logs encore d'actualité.
Actuellement, il y aurait besoin de faire :
- soit un second filter avec les mêmes regexes sur le même stream (un peu dommage car ça testera plusieurs fois la même regex, ça pourrait être plus opti)
- soit un stream qui lit les logs de reaction pour voir les bans, et qui ferait des bans plus longs quand il voit plusieurs fois une IP se faire ban (ce qui est un peu crado, et qui nécessite d'avoir le loglevel à INFO au minimum).
En fait j'ai pas encore implémenté de feature de ce type parce que je ne vois pas comment écrire ça de manière élégante dans la configuration. Si vous avez des idées de ce côté, ça m'intéresse vraiment.
La configuration d'Apache est assez versatile, et ses logs aussi il me semble. Même chose pour NGINX, comme les logs sont très configurables, peuvent changer selon les distros, le module risque d'être inadapté.
C'est aussi à cause de ce genre de problématiques que je n'ai pas envie de maintenir une configuration officielle des services, mais plutôt d'avoir un wiki qui recense des configurations et des bonnes pratiques.
# ip46tables => ferm
Posté par Glandos . Évalué à 8.
J'ai vu que pour le besoin du projet, un utilitaire en C nommé
ip46tablesa été écrit.Je me permets de citer, pour ceux qui doivent encore utiliser
iptablesà la place denftque ferm est un très bon programme pour gérer ce genre de cas. Je m'en suis servi pendant des années, j'ai presque versé la larme quand je suis passé à nft. Mais la syntaxe y ressemble furieusement.[^] # Re: ip46tables => ferm
Posté par ppom . Évalué à 3.
J'ai regardé un peu ferm, qui a l'air d'un très chouette projet, et de gérer des cas plus complexes que ufw.
Par contre j'ai l'impression que ce n'est pas possible de ban une ip temporairement, juste avec un
ferm ... <IP>. ip46tables sert juste à ça, ce n'est pas du tout le même scope que ferm 🔀[^] # Re: ip46tables => ferm
Posté par Glandos . Évalué à 4.
Oui, en effet, c'est plutôt pour charger un script complet.
C'est pour ça que je m'étais mis à ipset, qui est vraiment facile : ferm crée la règle qui redirige vers le set, et fail2ban/reaction fait des ipset add quand il faut. C'est simple et performant.
# OSSEC, un F2B en C sous GPL2
Posté par Astaoth . Évalué à 5.
En IDS/IPS système, opensource, codé en C et qui doit avoir plus de 10 ans (mais toujours maintenu), il y a Ossec aussi. Que ca soit à ses débuts, quand ca appartenait à Trend Micro, ou maintenant, il y a toujours eu une version sous GPL2.
Y a-t-il une raison spéciale pour ne pas du tout en parler ?
Emacs le fait depuis 30 ans.
[^] # Re: OSSEC, un F2B en C sous GPL2
Posté par ppom . Évalué à 2.
Et oui, une raison très simple… Je ne connaissais pas du tout 😆
Après un rapide coup d'oeil, je le rangerais dans la même catégorie que salt et consorts : c'est un gros bouzin, avec une architecture 1 manager / N agents… Ça me semble beaucoup pour une petite infrastructure.
Merci pour le lien 🙂
[^] # Re: OSSEC, un F2B en C sous GPL2
Posté par Astaoth . Évalué à 2.
Ouais il est assez imposant, et intimidant. On peut quand même faire un setup standalone, de mémoire l'installeur est assez simplifié pour faire ca simplement. Par contre, je crois que pour faire des filtres customs c'était un peu plus pénible que f2b, du coup je l'ai jamais trop utilisé. Mais ca a pu évoluer depuis, j'avais regardé ca y a 7-8 ans.
Emacs le fait depuis 30 ans.
# Pas mal
Posté par Andre Rodier (site web personnel) . Évalué à 10.
C'est vrai que fail2ban a fait son temps, et ses fichiers de configuration ont graduellement explosé. Perso, je me suis contenté de nftables, mais bon.
Quelques remarques :
Je pense qu'il est possible de souscrire aux messages du journal système directement, utiliser une commande, c'est old school.
D'ailleurs, spécifier
'journalctl', '-fu', 'sshd.service'dans un fichier de configuration, c'est ce que j'appelle se tirer une balle dans le pied. À la limite, il vaudrait mieux quelque chose comme ça :Cela te permettra de laisser au programme le choix de l'implémentation, soit manuelle (i.e.
journalctl -fu sshd), soit native lorsque tu auras trouvé l'api systemd qui le fait.Pour le fichier de configuration, je les préfère exempts de toute logique, donc Yaml suffirait. Pour la raison mentionnée ci-dessus.
Même remarque pour cette ligne :
OK, c'est très flexible de supporter
cmd, mais ça devrait être une exception. Si par exemple, tu écris quelque chose comme ça:Le programme peut maintenant choisir d'utiliser nftables, iptables ou autre, en fonction du système.
Pour ssh, nftables fait ça très bien, avec sets + timeout. Je crois que la dernière version de iptables est juste un wrapper autour de nftables.
[^] # Re: Pas mal
Posté par Christophe . Évalué à 9.
Finalement ce sont juste deux approches différentes: soit on laisse le programme choisir, soit on laisse l'utilisateur choisir. Et en voyant ce qui a poussé l'auteur à implémenter sa propre solution, je pense qu'il a pris la seconde approche en toute connaissance de cause, pour ne pas s'enfermer sur telle ou telle techno.
Alors oui, ça introduit de la complexité dans un fichier de configuration, et l'intégration avec le système est moins bonne. Mais au moins, le programme "supporte" dès aujourd'hui «nftables, iptables ou autre», pas besoin d'attendre la version 2025.
Et rien n'empêche l'auteur d'ajouter ces raccourcis plus tard à Reaction; pour moi, c'est la bonne approche pour une première version du programme.
[^] # Re: Pas mal
Posté par xandercagexxx . Évalué à 3.
Je préfère également les fichiers de conf complexe mais qui laisse la main pour configurer comme on veut, plutôt que les truc "simplifiée" où l'on arrive jamais à faire ce que l'on voudrait 😁
[^] # Re: Pas mal
Posté par Piotr . Évalué à 2.
Je peux me tromper, mais il semble possible d'obtenir une syntaxe similaire avec les "fonctions" de JSONnet si j'en crois l'exemple en fin de dépêche.
[^] # Re: Pas mal
Posté par ppom . Évalué à 10.
Hello 😅
Je vais répondre à tes remarques, même si d'autres l'ont déjà fait
Je pense que j'ai deux contre-arguments plus concrets. Une commande, c'est :
Je n'ai pas envie de recoder des trucs déjà implémentés par
journalctl,tail,docker logs, etc… J'estime que ces commandes sont optimisées. Au bout de plusieurs semaines, une commandejournalctla utilisé moins d'une minute de temps de CPU, et je n'ai pas envie de compétiter !Il y a des distributions qui appellent ce service ssh, d'autres sshd, d'autres openssh.
Il y a des distributions qui utilisent systemd/journald, d'autres rsyslog, d'autres un plain text…
Je pense qu'hardcoder tous ces noms, tous ces paths, tous ces protocoles, dans reaction, c'est me tirer une balle dans le pied !
Idem, je ne préfère pas que le programme détermine lui-même quel système existe, quel système est en place… Je pense que c'est la porte ouverte à une flopée de bugs plus ou moins sournois.
Comme mentionné par quelqu'un d'autre, il est possible d'approcher ta syntaxe avec JSONnet :
Actuellement, le code de reaction fait ~1200 lignes de code, et ça me va bien !
Si je voulais implémenter/hardcoder autant de trucs, ben, déjà, je voudrais pas le faire haha, et ensuite, j'aurais plus de code dédié à des cas spécifiques qu'au coeur de ce que fait reaction : lire la stdout d'un programme, matcher des regexes dessus, et lancer des actions quand il y a un certain nombre de matches.
# Merci
Posté par Zatalyz (site web personnel) . Évalué à 10.
Merci pour ce logiciel, qui me plaît beaucoup.
Pour la petite histoire c'est un ami sur Mastodon, pourtant pas du tout sysadmin, qui a vu passer le pouet à propos de l'article de blog et me l'a envoyé. Je pense que j'ai traumatisé mon entourage à pester sur Fail2ban.
Cela fait donc quelques temps que je le teste tranquillement, quand j'ai le temps de bidouiller sur mon serveur à la maison. Et plus le temps passe, plus je suis convaincue.
Retrouver le niveau de fonctionnalité de Fail2ban est faisable sans difficulté. Il n'y a qu'à voir la mise en place finalement rapide et facile pour que je sois notifiée par mail de quand Reaction agit. La syntaxe est assez simple, ça juste marche. Ma propre config mérite du peaufinage mais c'est du détail.
J'aime beaucoup aussi le côté agnostique. Il y a moyen de passer par les divers autres outils installés sur la machine. Moi, plus j'ai de possibilité de personnaliser, plus je suis contente. Un exemple encore avec cette notification par mail : je ne sais pas trop comment personnaliser les messages avec Fail2ban, par contre avec Reaction et bien c'est aussi facile que d'écrire un script/une commande bash.
J'ai vu des remarques dans les commentaires à propos d'utiliser ipv6, nftables, etc. Ce n'est pas un souci. Au passage, sur Debian le paquet "iptable" est en réalité une surcouche à nftable pour lui parler sans devoir réapprendre la syntaxe. J'ai l'impression que l'info n'est pas si connue (et en tout cas moi je l'ai découvert récemment…). D'ailleurs chez moi iptable ne semble pas bien traduire ce que fait ipset…
Mais Reaction est en fait presque un framework de commandes. On peut utiliser n'importe quel autre pare-feu, il n'est pas contraignant là-dessus.
Ce côté versatile est bien sympa, d'ailleurs. Là, sur le serveur en question, je suis avec la syntaxe d'iptable parce que… parce que ! Mais mon objectif est de me former à mieux comprendre le réseau (que je gère actuellement en singe : je me contente de copier les consignes des gens en espérant qu'ils ne se plantent pas et que j'ai vaguement compris ; d'où très probablement mes soucis avec ipset), et donc à un moment je compte utiliser la syntaxe de nftable. Ça ne sera pas un souci de changer 2 règles dans mon fichier de config de Reaction, quand je serais prête :) Je sais que ça s'adaptera à divers besoins.
Et pour l'instant toutes les questions que j'ai pu soulever dans les tickets ont reçus des réponses simples et élégantes.
Bref, je suis ravie ! Je veux juste trouver un peu de temps pour copier les regex des services de fail2ban que j'utilise, pusher ça dans le wiki de Reaction et ce sera absolument parfait !
[^] # Merci²
Posté par ppom . Évalué à 2.
Merci pour ce chouette retour 😊
# Précision sur CrowdSec
Posté par Philippe_CrowdSec . Évalué à 10.
Bonjour à toutes & tous et bravo PPom pour ton projet.
Juste une précision sur CrowdSec, oui nous avons levé des fonds de VC et oui nous devons monétiser. Mais nous voulions justement éviter de prendre le chemin de trop nombreux projets FOSS: soit souffrir d'évolution trop rares ou lentes car le projet repose sur un bénévole soit devoir pivoter car une team plus large demande pas mal de moyens et certains abusent des projets gratuits pour en faire un business sans rémunérer l'éditeur.
Le principe de fond de CrowdSec est de créer un effet réseau pour générer des blocklistes temps réelles, ce qui avec pas loin de 250K servers protégés à être très efficace. Pour se faire, le réseau doit être le plus grand possible et donc la barrière d'entrée à l'usage la plus basse possible. D'où l'install en une ou deux lignes, le modèle gratuit, 3000+ packages, 300+ scenarios, etc.
Ce que nous monétisons, c'est la CTI et ses blocklistes premium, ainsi que le SaaS au dessus (totalement optionel) qui apporte des fonctions supplémentaires pour les entreprises. Et d'ailleurs, tous les participants gratuit au réseau ont aussi la blockliste sur leurs installations et bénéficient donc de l'effet réseau.
Si nous nous mettions à faire payer le composant FOSS, notre réseau s'éffondrerait et nous n'aurions donc plus de CTI à vendre ou de fonctions SaaS avancées à proposer à nos clients. Ce qui veut dire que, par design, monétiser cette partie serait parfaitement contre productif envers nos objectifs de monétisation. (Et ce raisonnement restera vrai pour la fonction WAF qui devrait arriver en general availability ce mois ci)
En résumé, si vous utilisez une version gratuite, CrowdSec est rémunéré en signaux et si vous utilisez une version payante en euros. Ces signaux peuvent ensuite être monétisés auprès de ceux qui souhaitent les utiliser mais pas forcément installer le security engine. Le but ici est de monétiser auprès des enterprises et d'avoir le logiciel gratuit pour les utilisateurs individuels.
Il y a surement de meilleurs modèles et celui-ci a ses contraintes, mais nous l'avons choisit avec ces éléments en tête.
Philippe.
[^] # Re: Précision sur CrowdSec
Posté par xandercagexxx . Évalué à 4.
Merci beaucoup pour toutes vos explications et précisions.
C'est enrichissant, et ça peut éviter que l'on (je) dises des conneries (ou qu'on les partages).
Serez-vous à l'OSXP cette année ? (Ce serait l'occasion pour poser quelques questions à la team et réfléchir plus posément à l'utilisation de cet outil côté boulot).
[^] # Re: Précision sur CrowdSec
Posté par Philippe_CrowdSec . Évalué à 5.
Ah malheureusement je ne pense pas pour l'OSXP et pas de souci pour les idées pré conçues, on a pas fait un excellent taf non plus à expliquer tout cela je dois avouer. Je suis dispo pour toute forme de communication mais on devrait laisser ce thread à ce nouvel outil et son auteur PPom.
Pour ceux qui veulent échanger / débattre / questionner CrowdSec, vous pouvez me contacter sur LinkedIn https://www.linkedin.com/in/philippehumeau/ et l'équipe est très réactive sur Discord en général (https://discord.com/invite/crowdsec).
# Créer des releases
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 5.
Bien intéressant, et je suis enthousiaste pour la suite. À tel point que je compte en créer un paquet pour Alpine.
Seulement, la condition pour le faire est l'existence de release. Il n'est pas très pratique ni bien vu (voir même proscrit) de faire des paquets à partir de hash de commits.
À quand la version 0.0.1 ?
Un gentil du net
[^] # Re: Créer des releases
Posté par xandercagexxx . Évalué à 4.
Je vais dans ce sens aussi, mais rien que pour le suivi de l'avancement du projet en tant que personne extérieure. Un petit tag avec une note de release de temps en temps, même si très très basique, ça aide à se motiver pour mettre à jour et/ou pour comprendre que le temps passe et que le projet continue sont évolutions :)
[^] # Re: Créer des releases
Posté par ppom . Évalué à 5.
Bon, ça doit pas être très clair sur le repo…
Pour l'instant, il n'y a pas de releases au sens GitLab du terme, mais il y a déjà des tags Git ! (v0.1, v0.2, v0.3, v0.4, v1.0, v1.0.1).
Et des binaires précompilés, aussi linkés dans le README du projet.
Je n'ai pas encore appris à faire des releases "propres" via GitLab/Framagit, mais elles sont d'ores et déjà là.
[^] # Re: Créer des releases
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 3.
Je n'avais pas vu les tags sur les commits.
Tu a apparemment appris à créer des releases sur gitlab, c'est parfait, ça va me faciliter les choses :)
Un gentil du net
[^] # Re: Créer des releases
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 1.
Hum, c'est étrange, tu as créé une release pour la 1.0, mais au niveau des tags ça va jusqu'à 1.0.2. Ce serait bien de créer des releases pour cette version aussi.
Un gentil du net
[^] # Re: Créer des releases
Posté par ppom . Évalué à 5.
Héhé, j'étais en train de les faire justement !
Mais en cours de route j'ai migré le stockage des binaires et de mon blog, de mon homeserver à mon VPS, pour avoir un uptime nickel.
Toutes les releases sont créées maintenant !
[^] # Re: Créer des releases
Posté par ppom . Évalué à 6.
Et waow, je n'avais pas bien lu 😮
Des releases pour Alpine, ce serait super chouette !
Je compte upstream mon package pour NixOS, mais c'est très niche.
Si quelqu'un maintenait un package Debian, ce serait incroyable aussi 🎅
[^] # Re: Créer des releases
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 3.
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56782
J'ai créé le paquet. Mais comme la release 3.19 d'Alpine Linux est imminente, pour l'instant l'intégration de nouveau paquets dans la branche edge est suspendue.
Pour info, quand un nouveau paquet est ajouté sur Alpine Linux, il est en premier lieu disponible dans le dépôt testing qui n'est disponible que sur la version edge d'Alpine (la version rolling-release). Quand on a suffisamment de feedbacks, alors on peut faire passer ce paquet au dépôt community (maintenu 6 mois) ou main (maintenu 2 ans).
Un gentil du net
[^] # Re: Créer des releases
Posté par ppom . Évalué à 6.
Chouette, merci ! Ça a boosté ma motiv, je suis en train de l'ajouter à NixOS de mon côté : https://github.com/NixOS/nixpkgs/pull/272264
[^] # Re: Créer des releases
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 3.
Ma MR a été mergée, il sera dans les dépôts dans quelques heures.
Un gentil du net
# Intelligence participative
Posté par Daniel Ed (site web personnel) . Évalué à 3.
La v2 sera capable de fonctionner en grappe, en échangeant en pair-à-pair des adresses IP à bannir (ou des recettes de cuisine, configurez-le comme vous voulez !)
Une très belle evolution à suivre !
# Question d'un profane
Posté par Ant . Évalué à 1.
Alors, je profite opportunément de la présence potentielle de connaisseurs dans le fonctionnement réseau et authentification pour poser une question : j'ai un RPI à la maison sur lequel je me connecte en ssh à distance sur un port quelconque (genre 10044) ouvert sur ma freebox, qui dispose d'une IP fixe.
Sur la freebox, j'ai une redirection du 10044 sur le port 22 de mon RPI.
Alors déjà j'ai énormément de connexions frauduleuses. Depuis 5 jours j'ai 4253 failed et 876 adresses ip bannies.
Ensuite, je ne comprends pas ce genre d'erreurs :
Bien évidemment les ports sur lesquels il y a des tentatives de connexion ne sont pas ouverts.
Ici, il y a des utilisateurs qui de toute façon n'existent pas mais je'ai aussi beaucoup de tentatives de connexion en root.
Question : Comment puis-je avoir des tentatives de connexion sur un port non ouvert au niveau de ma freebox ?
Est-ce que sshguard me donerait une meilleure protection ?
Merci pour vos lumières !
[^] # Re: Question d'un profane
Posté par Frédéric Blanc . Évalué à 3.
Les ports dont il est question dans les logs sont les ports sources, pas le port destination (22 sur votre rpi via la redirection du port 10044 de la Freebox).
[^] # Re: Question d'un profane
Posté par Ant . Évalué à 1.
Oui, ça parait logique !
Merci!
[^] # Re: Question d'un profane
Posté par lym . Évalué à 2.
J'ai longtemps eu un sshd ouvert sur l'extérieur et c'est visiblement une cible très recherchée depuis longtemps. Voir trop pour un outil comme fail2ban.
J'étais donc passé au port-knocking en choisissant une séquence simple et réalisable au besoin sans outil dédié (un triplet de ping uniques): Port/redirection toujours ouverte côté box, ainsi que celle concernant les ports utilisé en stimuli au knockd, ce dernier ouvrant juste le 22 sur la machine à la demande.
Puis Orange m'a un jour passé en IPv6 une nuit sans prévenir… et qq temps après, regardant les logs par hasard, je m'en apercoit car les tentatives de bruteforce ssh avaient repris!
Ce n'était pas qu'un pb de configuration de knockd: Il ne supporte pas IPv6… Et pas trouvé d'alternatives dans les dépôts Debian quand j'avais cherché.
La machine avec un sshd étant un PI qui héberge ma domotique déjà rendue accessible en https (via domaine no-ip et certificat let's encrypt) et ce dernier étant paradoxalement incomparablement moins visé que ssh (pas grand chose en dehors des robots d'indexation des moteurs de recherche qui lâchent l'affaire après lecture du robots.txt ou sur la page de login), ça a fini par un interrupteur virtuel sur la page domotique qui déclenche un script qui ouvre le 22 pour 1 minute sur demande, laissant le temps d’établir une connexion ssh externe.
AMHA, il n'y a guère le choix avec un serveur ssh: Le seul moyen d'avoir la paix c'est d'avoir un moyen adapté à sa situation pour l'ouvrir à la demande… C'est juste trop ciblé et même passer a l'authentification par clef ne résout aucunement la pollution de log et de son LAN par les tentatives.
[^] # Re: Question d'un profane
Posté par barmic 🦦 . Évalué à 4.
Perso j'ai commencé à abandonné ssh. Je ne fais plus de manipulation direct sur la machine (ou alors en physique). Je publie la mise à jour d'un playbook qui est régulièrement récupéré par la machine qui vérifie la signature avant de le jouer et m'envoie un mail s'il y a eu un problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Question d'un profane
Posté par Nibel . Évalué à 3.
Ça m'intéresse comme façon de procéder, tu aurais des ressources sur le sujet stp ?
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Question d'un profane
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 08 janvier 2024 à 05:54.
Non, je fais ça sans avoir lu de truc particulier dessus j'utilise un timer systemd pour lancer le playbook toutes les heures. Le playbook met à jour le dépôt git dans le quel il est et se lance. Je reçois un mail en cas d'échec.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# whitelist/blacklist
Posté par moi1392 . Évalué à 6.
Hello, ton outil à l'air sympa, je n'ai pas encore pris le temps de le regarder de plus près, il y a tout de meme 2 choses qui m'intéresseraient comme features :
Les blacklist : avec des classes d'ip : au bout d'un mometn, j'aimerais bannir des classes d'ip entières, quand 5, 10 voir 15 ips de la meme classe se font bannir et qu'il s'agit d'ip d'un pays obscur de l'autre bout du monde, je pense que j'ai assez donné et que je peux me permettre de tout bannir, et définitivement. C'est à dire inscrire ces classes d'ip en ban définitif sans possibilité d'unban à mon d'une intervention manuelle de ma part.
Les whitelist : il m'arrive de me tromper dans mes tentatives de login, quand je suis dans mon reseau local, je n'ai pas forcément envie d'etre aussi strict, une règle un peu plus souple en terme de retry et de temps de ban pourrait etre mise en place.
Cet intéret est limité et case gueule et je ne pense pas m'en servir personnellement, mais il y a un autre intéret aux whitelists que je décrit dans le point suivant.
Intéret combiné des whitelist avec les blacklist :
Je me suis écrit (en c++) un petit bout de code qui merge des ip en classe d'ip que je lance régulièrment sur le résultat de fail2ban-cli status [sshd ou autre], l'intéret d'avoir des whilelist dedans est aussi d'éviter de bannir automatiquement toute une classe d'ip qui contiendrait l'ip de mon boulot et/ou d'endroit dont je sais me connecter régulièrement.
Mon code est un peu tordu, certainememt buggué et évidement mal testé et documenté, mais j'arrive à m'en servir pour moi, si ça t'intéresse et qu'il te donne des idées, je peux te le filer. (licence balec, c'est du code écrit à la méthode rache (c))
[^] # Re: whitelist/blacklist
Posté par ppom . Évalué à 4.
Coucou !
Les allowlists (/whitelists) sont déjà implémentées, car on peut faire des exceptions à un pattern :
Exemple : dans mon cas, je ne peux pas me permettre de bannir mon routeur, unique accès pour mon serveur à l'Internet mondial™️, ce qui reviendrait à mettre le serveur hors-ligne.
[^] # Re: whitelist/blacklist
Posté par ppom . Évalué à 3.
Pour ce qui est d'une denylist (/blacklist) permanente, je sais pas si c'est pertinent d'implémenter ça directement dans reaction.
Par contre je viens de réfléchir à une configuration qui le permette de manière pas si dégueu !
reaction.jsonnetstore.shNotes:
['sh', '-c', 'echo <ip> >> ' + permanentfile], car faire unsh -cest risqué, de manière inhérente./24:iptables -w -A reaction -s a.b.c.0/24 -j DROP[^] # Re: whitelist/blacklist
Posté par ppom . Évalué à 1.
Et pour éviter de ban un réseau dans lequel tu as une IP que tu veux ignorer, c'est simple aussi :
[^] # Re: whitelist/blacklist
Posté par Marc Quinton . Évalué à 4.
répartition par adresse IP ou par groupe d'adresse IP concernant les tentatives d'authentification sur mon serveur SSH, sur 3 semaines :
et maintenant si je prends l'ensemble des IP
autrement dit :
- je n'ai qu'une seule occurence ou l'on rencontre 14 IP dans le réseau 64.62.197.0/24
- 2 fois, j'ai 8 IP en /24 (60.10.72, 103.110.43),
- et la majorité (2147) concernant une seule instance en /24
aussi, il ne semble pas très intéressant, voir risqué de vouloir blacklister tout un /24.
# plus que prometteur : nécessaire, indispensable et à développer!
Posté par tkr (Mastodon) . Évalué à 1.
cependant, je m'interroge
il est souvent entendu que l'accès simple en ssh/mdp +22 soit une aberration promettant un AVC au premier cyber-consultant/passionné/whatever qui passe.
je pense que cela peut se défendre (de ne pas le "laisser tel quel")
j'avais donc envisagé que la communauté frenchie linuxienne puisse encourager vers un mouvement de labellisation.
j'en dirai pas plus, ya tout un topac pour ça ;)
en revanche, ce sur quoi je peux moins me prononcer :
est ce que cela pallie aux problématiques du mdp, aka ceux qui passent par certificat ou qui sont "passwordless", cad sans authentification par mdp, ce script est utile ou non?
quelles sont pour vous, en addition de reaction/fail2ban, les minimaux indispensables?
quand je vois que debian/LMDE, tout simplement n'intègre juste pas ssh-server par défaut dans son installation de base.. précaution ou autre décision?
je vous remercie' ;)
[^] # Re: plus que prometteur : nécessaire, indispensable et à développer!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Qu'appelles-tu installation de base ? o_O
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: plus que prometteur : nécessaire, indispensable et à développer!
Posté par tkr (Mastodon) . Évalué à 1.
une installation tout juste terminée
je crois que LMDE est la seule distro (ou fork officielle de distro de mint) a ne pas intégrer openssh-server, par défaut, une fois installé ; il faut le rajouter manuellement. Il me semble que c'est pareil sur mint.
[^] # Re: plus que prometteur : nécessaire, indispensable et à développer!
Posté par barmic 🦦 . Évalué à 4.
Ça me paraît pas malin d'installer un serveur ssh par défaut et je suis à peu près certaint que les distributions majeures n'en installent pas pour des configurations du bureau (portable ou non). Sur debian et probablement toutes les dérivées de debian ça se configure via tasksel.
Ça permet de ne pas avoir d'environnement graphique sur serveur et pas de serveur sur des bureaux (mais en me laissant possible bien sûr pour des cas d'usages moins classiques).
La volonté de réduire l'installation initiale au minimum n'est pas dicté que par la sécurité, la place économisée, le temps d'installation réduit sont un facteur. Même quand il s'agit de sécurité ça ne vient pas nécessairement de la solidité intrinsèque. Ne pas installer un paquet pour réduire la surface d'attaque est un principe applicable quelque que soit le paquet en question et sa sécurité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: plus que prometteur : nécessaire, indispensable et à développer!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Ça me rassure car j’avais eu peur d’avoir loupé quelque chose. J’ai en effet souvenir dans les dernières installations qu’il fallait choisir (et effectivement dans les lots il y a explicitement le serveur SSH à part, que je ne choisis jamais sur du bureautique et presque toujours sur du serveur) C’est surtout qu’il y a des choix prédéfinis mais pas un choix standard minimale (pour faire une vraie installation minimale il faut choisir manuel pour virer certaines choses)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# reaction show -f json
Posté par Marc Quinton . Évalué à 2.
hello,
est-ce que le format JSON concernant le format de sortie ne pourrait pas être modifié pour permettre l'extraction d'un type "array" ?
actuellement :
- format YAML:
format JSON
il est assez difficile de récupérer via JQ les "keys" (adresses IP) concernés par le bannissement. Proposition : ouvrir un tableau
"failedlogin": [ ... ][^] # Re: reaction show -f json
Posté par Marc Quinton . Évalué à 3.
cette commande avec JQ semble faire le job:
[^] # Re: reaction show -f json
Posté par Marc Quinton . Évalué à 3.
et une autre option de formatage :
ce qui me semble plus simple à exploiter avec JQ.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.