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.
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.
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.
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 ?
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.
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.
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.
Nous ne faisons pas “d’open source washing”. Le logiciel est sous license MIT et
l’on pourrait difficilement trouver license plus ouverte et transparente. Il est
libre et gratuit, aujourd’hui et pour toujours.
Cela semble contredire votre FAQ, qui dit qu'une partie de votre solution coté serveur
n'est pas sous licence libre.
Votre solution est elle pleinement fonctionnelle et installable indépendamment de vos
serveurs et/ou services associés sans ces morceaux non libres ?
La partie serveur n'est pas indispensable, elle s'occupe de features enterprise notamment et des configurations des API pour les packages premium. Cette partie n'est pas open source, notre site et notre BO non plus. Mais le logiciel est utilisable sans cela, sans aucun souci. Le moteur de détection comportemental n'a nullement besoin de cette partie en ligne. La partie curation des signaux envoyé par le réseau est faite en central, car il faut pouvoir recouper les signaux et évacuer les faux positifs et les tentatives d'empoisonnement. Vous pouvez couper la partie réputation de notre coté et utiliser une autre source de réputation (ou en complément) si vous le souhaitez. Donc oui, vous êtes totalement autonomes avec le code publié sur github.
Merci de vos retours, la FAQ, faite dans un but de transparence, ne semble pas clair, je vais en profiter pour l'améliorer.
à moins d'avoir mal cherché, il ne me semble pas avoir vu de mentions légales complètes
sur votre site: quelle est la société qui héberge votre solution et dans quelle
localisation géographique ?
Non, nous y travaillons, en fait nous avons commencé à développer la partie opensource en début d'année mais n'avons eu de fonds que depuis septembre pour pouvoir mettre des avocats sur les sujets RGPD et mentions légales, contrats de travail, etc. C'est plus long que je n'aurais aimé, mais nous y travaillons.
Nos serveurs sont hébergés sur AWS en Irelande à ce stade.
Notre réseau de honeypots (servant à la confirmation des signaux) est distribué sur de nombreux hosters dans de nombreux pays.
en pied de page de votre site, vous citez un tweet de @linuxfr.org qui, comme ce compte
le fait pour toutes les dépêches publiées par le site linuxfr.org, mentionne la
publication de cette dépêche en particulier, laissant à penser que l'association
linuxfr.org pourrait soutenir d'une manière ou d'une autre votre projet: y a-t-il un
lien entre votre société et l'association linuxfr.org ou un de ses représentants, ou
avez-vous tout simplement utilisé la possibilité offerte à tout utilisateur inscrit
de publier une dépêche comme sur n'importe quel autre site vous permettant de développer
votre stratégie marketing ?
Nous citons juste les médias qui parlent de notre travail sur notre tweeter, qui est reprit en pied de page du site. (Pas uniquement ceux de Linuxfr.org) Nous n'avons aucun lien directs ou indirects avec l'association linuxfr.org. La publication de cet article n'a fait l'objet d'aucun sponsoring, échange pécunier ou engagement particulier entres nos deux entités.
Pour le point qui me dérange ici, c'est que toute la valeur de votre solution, à savoir
les services hébergés, sont annoncés comme n'étant pas Open. Partant de là, il ne me sera
pas possible d'intégrer votre solution dans son ensemble en autonomie, encore moins de
la forker.
Les moteurs de réputation et de comportement sont très utiles je pense et la valeur est principalement là. Les services hébergés ne sont que la valeur permettant de faire vivre la société, pas des entraves au logiciel. Notre comptabilité, notre plan marketing et tout un tas d'autres aspects ne sont pas open source, je le concède. Cela discrédite t'il l'utilité du code fait par l'équipe et distribué en MIT ? J'en doute, mais là encore, ce sont des points de vue.
Je suis preneur de vos retours cependant. Comment avez vous procédé pour vos propres productions open source ? Quelle license avez vous choisit ? Avez vous pu les maintenir dans le temps sans aucun modèle de monétisation ? Nous n'avons pu le faire que pour 3 logiciels de notre coté, qui se retrouve maintenant sans support pour deux d'entres eux, bien qu'encore très utilisés.
Dans mon expérience d'utilisateur et de contributeur opensource, les projets non financés sont souvent moins solides et durables car leurs teams ont besoin de se nourir et doivent faire des arbitrages entre travail et temps personnel. Le fait d'avoir un modele économique est donc, en général, un meilleur gage de durabilité. Ici, il me semble honnête puisque la communauté bénéficie d'un logiciel utile, performant et gratuit, à vie.
Elle bénéficie aussi de toute la curation des signaux effectuée en central, ce qui n'est pas sans cout non plus. Elle peut également s'en passer si elle le souhaite et avoir "juste" un fail2ban moderne et plus efficace. Si elle voit des entraves ou un déclin dans le soft, cette communauté pourra même le forker. Alors oui, pas notre backoffice API, ni notre site web, mais cela me semble assez loin de l'Open Source Washing.
Désolé que vous ne puissiez utiliser notre solution dans votre banque pour ces raisons.
Nous encourageons les contributeurs a discuter avec l’équipe, soit sur Gitter, soit sur Discourse, pour simplifier les échanges, mais il n’y à la aucune obligation.
Nous sommes en contact avec la plupart des membres de l’équipe Fail2ban. Cyrille Jacquier a commencé Fail2ban comme un projet pour apprendre Python. Il n’a effectivement pas déposé de statut pour faire son TP personnel. Arturo, Yaroslav et Sergey ont poursuivit le mouvement. A ce jour, à ma connaissance, seul Sergey continu occasionnellement la maintenance par manque de temps et de moyens.
Notre approche est assez différente. Effectivement, je (philippe puisque c'est de mon profile LinkedIn dont vous parlez) suis entrepreneur, mais je n’oppose pas open source et société. Nous avons des visions différentes semble t’il sur ce sujet, mais ce n’est pas bloquant je pense. Dans la mienne, si l’on veut un soft bien fait et durable, il faut des moyens pour garder une équipe cohérente et pointue dans le temps. Donc oui, CrowdSec est une entreprise et oui elle a vocation a être rentable. Est-ce incompatible avec l’open source, je ne le pense pas.
Nous ne faisons pas “d’open source washing”. Le logiciel est sous license MIT et l’on pourrait difficilement trouver license plus ouverte et transparente. Il est libre et gratuit, aujourd’hui et pour toujours. Si la communauté considère que l’on trahit nos engagements, elle pourra le forker à tout moment. Par ailleurs, Thibault, notre CTO, a déjà produit pas mal de logiciels open source, dont NAXSI (Snuffleu Paggus, PHPMF, etc.) et il est visible de tous qu’aucune monétisation n'en a été faite.
Quand au modèle est assez simple en fait. Chacun peut utiliser le moteur comportemental. Si en plus cette personne contribue a l’enrichissement de la base de réputation, elle bénéficie aussi gratuitement du moteur de réputation d’IP. Cette base, nous en effectuons la corrélation, le nettoyage, le filtrage anti faux positifs et anti poising. Son utilisations est gratuite pour ceux qui la nourrisse, à savoir ceux qui partagent.
Notre monétisation (à venir) vient de deux aspects: les fonctions corporate, qui nécessitent un traitement, un développement ou un stockage de notre coté, ce qui a un cout. Typiquement les systèmes de déploiement et de mise en place d’une politique de sécurité précise sur de nombreux endpoints. Ou de compliance / reporting. Mais surtout nous faisons payer l’accès (API) à la base de réputation d’IP pour ceux qui ne participent pas à son élaboration.
Le financement, à ce stade est effectué par l’équipe (à 30%) et des business angels (à 70%). Si l’on inclus les salaires (car nous ne nous payons pas encore), cela serait plus de l’ordre de 50/50 je pense.
Je suis intéressé par “les autres acteurs sur le coup” si vous souhaitez m'en parler, il est toujours bon de connaitre les autres projets et éventuellement construire des ponts avec eux.
Quand à Letsencrypt, je ne suis pas 100% familier du projet mais, de mémoire, c’est un consortium fondé par plusieurs géants de la tech pour démocratiser le HTTPS en mettant fin au braquage à main armé qui concerne les certificats. Si c’est bien le cas et le sens de votre question, nous n’avons pas de points commun sur le modèle, la destination ou les intérêts (à ma connaissance), même si je trouve l’intention tout à fait louable. Nous n’avons cependant pas trouvé (ou cherché) de généreux sponsors pour aller vers leur modèle.
En espérant que cela ait répondu à vos légitimes interrogations et que cela vous incitera a engager la communauté,
Nous sommes en 2020 et nous partageons votre conviction sur l'IPV6, ce n'est pas un sujet, donc le produit supporte entièrement IPV6. C'est une évidence pour notre équipe mais nous aurions du le préciser, je vous rejoins entièrement. Nous allons le mettre dans la doc et sur la FAQ.
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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.
[^] # Re: Précision sur CrowdSec
Posté par Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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).
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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 Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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 Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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 Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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
# Précision sur CrowdSec
Posté par Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. É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: Business model ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 1.
La partie serveur n'est pas indispensable, elle s'occupe de features enterprise notamment et des configurations des API pour les packages premium. Cette partie n'est pas open source, notre site et notre BO non plus. Mais le logiciel est utilisable sans cela, sans aucun souci. Le moteur de détection comportemental n'a nullement besoin de cette partie en ligne. La partie curation des signaux envoyé par le réseau est faite en central, car il faut pouvoir recouper les signaux et évacuer les faux positifs et les tentatives d'empoisonnement. Vous pouvez couper la partie réputation de notre coté et utiliser une autre source de réputation (ou en complément) si vous le souhaitez. Donc oui, vous êtes totalement autonomes avec le code publié sur github.
Merci de vos retours, la FAQ, faite dans un but de transparence, ne semble pas clair, je vais en profiter pour l'améliorer.
Non, nous y travaillons, en fait nous avons commencé à développer la partie opensource en début d'année mais n'avons eu de fonds que depuis septembre pour pouvoir mettre des avocats sur les sujets RGPD et mentions légales, contrats de travail, etc. C'est plus long que je n'aurais aimé, mais nous y travaillons.
Nos serveurs sont hébergés sur AWS en Irelande à ce stade.
Notre réseau de honeypots (servant à la confirmation des signaux) est distribué sur de nombreux hosters dans de nombreux pays.
Nous citons juste les médias qui parlent de notre travail sur notre tweeter, qui est reprit en pied de page du site. (Pas uniquement ceux de Linuxfr.org) Nous n'avons aucun lien directs ou indirects avec l'association linuxfr.org. La publication de cet article n'a fait l'objet d'aucun sponsoring, échange pécunier ou engagement particulier entres nos deux entités.
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 1.
Les moteurs de réputation et de comportement sont très utiles je pense et la valeur est principalement là. Les services hébergés ne sont que la valeur permettant de faire vivre la société, pas des entraves au logiciel. Notre comptabilité, notre plan marketing et tout un tas d'autres aspects ne sont pas open source, je le concède. Cela discrédite t'il l'utilité du code fait par l'équipe et distribué en MIT ? J'en doute, mais là encore, ce sont des points de vue.
Je suis preneur de vos retours cependant. Comment avez vous procédé pour vos propres productions open source ? Quelle license avez vous choisit ? Avez vous pu les maintenir dans le temps sans aucun modèle de monétisation ? Nous n'avons pu le faire que pour 3 logiciels de notre coté, qui se retrouve maintenant sans support pour deux d'entres eux, bien qu'encore très utilisés.
Dans mon expérience d'utilisateur et de contributeur opensource, les projets non financés sont souvent moins solides et durables car leurs teams ont besoin de se nourir et doivent faire des arbitrages entre travail et temps personnel. Le fait d'avoir un modele économique est donc, en général, un meilleur gage de durabilité. Ici, il me semble honnête puisque la communauté bénéficie d'un logiciel utile, performant et gratuit, à vie.
Elle bénéficie aussi de toute la curation des signaux effectuée en central, ce qui n'est pas sans cout non plus. Elle peut également s'en passer si elle le souhaite et avoir "juste" un fail2ban moderne et plus efficace. Si elle voit des entraves ou un déclin dans le soft, cette communauté pourra même le forker. Alors oui, pas notre backoffice API, ni notre site web, mais cela me semble assez loin de l'Open Source Washing.
Désolé que vous ne puissiez utiliser notre solution dans votre banque pour ces raisons.
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à -1.
Alors justement, on vous donnera la main, dès que le BO sera prêt, en permettant de régler les blocks lists qui seront appliquées.
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 10.
Bonjour M. Granveaux,
Nous encourageons les contributeurs a discuter avec l’équipe, soit sur Gitter, soit sur Discourse, pour simplifier les échanges, mais il n’y à la aucune obligation.
Nous sommes en contact avec la plupart des membres de l’équipe Fail2ban. Cyrille Jacquier a commencé Fail2ban comme un projet pour apprendre Python. Il n’a effectivement pas déposé de statut pour faire son TP personnel. Arturo, Yaroslav et Sergey ont poursuivit le mouvement. A ce jour, à ma connaissance, seul Sergey continu occasionnellement la maintenance par manque de temps et de moyens.
Notre approche est assez différente. Effectivement, je (philippe puisque c'est de mon profile LinkedIn dont vous parlez) suis entrepreneur, mais je n’oppose pas open source et société. Nous avons des visions différentes semble t’il sur ce sujet, mais ce n’est pas bloquant je pense. Dans la mienne, si l’on veut un soft bien fait et durable, il faut des moyens pour garder une équipe cohérente et pointue dans le temps. Donc oui, CrowdSec est une entreprise et oui elle a vocation a être rentable. Est-ce incompatible avec l’open source, je ne le pense pas.
Nous ne faisons pas “d’open source washing”. Le logiciel est sous license MIT et l’on pourrait difficilement trouver license plus ouverte et transparente. Il est libre et gratuit, aujourd’hui et pour toujours. Si la communauté considère que l’on trahit nos engagements, elle pourra le forker à tout moment. Par ailleurs, Thibault, notre CTO, a déjà produit pas mal de logiciels open source, dont NAXSI (Snuffleu Paggus, PHPMF, etc.) et il est visible de tous qu’aucune monétisation n'en a été faite.
Quand au modèle est assez simple en fait. Chacun peut utiliser le moteur comportemental. Si en plus cette personne contribue a l’enrichissement de la base de réputation, elle bénéficie aussi gratuitement du moteur de réputation d’IP. Cette base, nous en effectuons la corrélation, le nettoyage, le filtrage anti faux positifs et anti poising. Son utilisations est gratuite pour ceux qui la nourrisse, à savoir ceux qui partagent.
Notre monétisation (à venir) vient de deux aspects: les fonctions corporate, qui nécessitent un traitement, un développement ou un stockage de notre coté, ce qui a un cout. Typiquement les systèmes de déploiement et de mise en place d’une politique de sécurité précise sur de nombreux endpoints. Ou de compliance / reporting. Mais surtout nous faisons payer l’accès (API) à la base de réputation d’IP pour ceux qui ne participent pas à son élaboration.
Le financement, à ce stade est effectué par l’équipe (à 30%) et des business angels (à 70%). Si l’on inclus les salaires (car nous ne nous payons pas encore), cela serait plus de l’ordre de 50/50 je pense.
Je suis intéressé par “les autres acteurs sur le coup” si vous souhaitez m'en parler, il est toujours bon de connaitre les autres projets et éventuellement construire des ponts avec eux.
Quand à Letsencrypt, je ne suis pas 100% familier du projet mais, de mémoire, c’est un consortium fondé par plusieurs géants de la tech pour démocratiser le HTTPS en mettant fin au braquage à main armé qui concerne les certificats. Si c’est bien le cas et le sens de votre question, nous n’avons pas de points commun sur le modèle, la destination ou les intérêts (à ma connaissance), même si je trouve l’intention tout à fait louable. Nous n’avons cependant pas trouvé (ou cherché) de généreux sponsors pour aller vers leur modèle.
En espérant que cela ait répondu à vos légitimes interrogations et que cela vous incitera a engager la communauté,
Cordialement,
Philippe.
[^] # Re: IPv6 ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 1.
Aie, je sens qu'on va reparler de cette fete de saint valentin…
Mais merci pour la mémoire de ces moments assez épiques :)
[^] # Re: IPv6 ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 9.
Nous sommes en 2020 et nous partageons votre conviction sur l'IPV6, ce n'est pas un sujet, donc le produit supporte entièrement IPV6. C'est une évidence pour notre équipe mais nous aurions du le préciser, je vous rejoins entièrement. Nous allons le mettre dans la doc et sur la FAQ.