CrowdSec est un nouveau projet de sécurité conçu pour protéger les serveurs, services, conteneurs ou machines virtuelles exposés sur Internet. Par certains aspects, c’est un descendant de Fail2Ban, projet né il y a seize ans. Cependant, il propose une approche plus moderne, collaborative et ses propres fondamentaux techniques afin de répondre aux contextes modernes. L’outil est open source (sous licence MIT) et gratuit, disponible pour GNU/Linux (macOS et Windows figurent sur la feuille de route) car notre but est de rendre la sécurité accessible au plus grand nombre.
CrowdSec, écrit en Golang, est un moteur d’automatisation de la sécurité, qui repose à la fois sur le comportement et sur la réputation des adresses IP. Le logiciel détecte localement les comportements, gère les menaces et collabore également au niveau mondial avec son réseau d’utilisateurs en partageant les adresses IP détectées. Ceci permet alors à chacun de les bloquer de manière préventive. L’objectif est de bâtir une immense base de données de réputation IP et d’en garantir un usage gratuit à ceux participant à son enrichissement.
Documentation complète du projet ici.
Philosophie technique
L’objectif est de déployer le logiciel dans autant d’environnements que possible. Donc, pour le rendre portable, nous avons choisi de l’écrire en Golang. Son exécution rapide, sa compatibilité avec les conteneurs, sa facilité d’utilisation dans les environnements Cloud ainsi que sa capacité à fonctionner sur des écosystèmes UNIX, macOS ou Windows : tout cela nous permet d’adresser tout le marché.
Pour faciliter les contributions, nous avons décidé d’utiliser une grammaire très simple et efficace basée sur YAML. Les analyseurs, quant à eux, utilisent des expressions rationnelles Grok, pour faciliter l’écriture de connecteurs de données.
Globalement, le traitement de l’information ressemble à ceci :
Moteur d’analyse comportementale
C’est la première couche de protection. Il utilise le scénario défini par YAML pour corréler les événements entrant dans un leaky bucket et en extraire un signal si le bucket déborde. Vous pouvez ensuite appliquer la réponse de votre choix avec des bouncers. Les bouncers sont des moyens de répondre à une adresse IP agressive. Si vous utilisez le bouncer NGINX, il peut interrompre la connexion, en renvoyer une erreur HTTP 403, un CAPTCHA ou limiter l’accès aux sous‑dossiers. L’approche découplée a du sens car, dans l’architecture moderne, vous voudrez peut‑être envoyer tous les journaux dans un SIEM, un logstash, du Cloud trail ou encore en Syslogd, mais répondre sur votre pare‑feu, votre serveur Web ou même au sein d’une application, au niveau métier.
Moteur de réputation
Le moteur de réputation est un principe très simple, mais difficile à mettre en place. Fondamentalement, chacune des installations CrowdSec peut bénéficier d’une liste noire d’adresses IP organisée, distribuée par notre API centrale. Elle est créée sur mesure en fonction de votre empreinte technologique. Si vous utilisez du LAMP, vous n’avez pas besoin des adresses IP qui attaquent d’autres piles techniques comme Windows, par exemple. Cette base de données est alimentée par toutes les instances CrowdSec, dont les signaux sont filtrés et traités en central par notre API. Donc, fondamentalement, vous êtes récompensé par une liste d’adresses IP bloquées, car vous contribuez à les élaborer avec votre instance locale. Les faux positifs et les tentatives d’usurpation de la part de pirates sont un réel enjeu, d’où ce besoin de traitement des signaux qui remontent des installations CrowdSec. Nous pensons avoir une recette assez solide pour y parvenir, que nous appelons le consensus. Cela implique diverses techniques, telles que la vérification des signaux par d’autres membres de confiance, notre propre réseau de leurres (honeypots), des listes de canaris (une liste blanche d’adresses IP), etc.
Notre but est de distribuer uniquement des listes fiables à 100 %. De plus, identifier qui est dangereux et à quel moment dépend fortement d’un contexte et d’une période temporelle précise. Par exemple, une adresse IP jugée propre hier peut être compromise aujourd’hui et nettoyée par les administrateurs le lendemain. Une adresse IP à la recherche de SSH n’est pas dangereuse pour votre TSE, etc.
Visualisation
Le logiciel comprend un système de visualisation local et léger, basé sur Metabase. CrowdSec est également équipé de Prometheus, pour offrir une observabilité et des capacités d’alerte faciles à nos amis Ops. Nous pensons que cette partie bénéficiera à la fois d’investissements de notre côté et de développements communautaires, car la sécurité est meilleure lorsqu’elle est visible, compréhensible et fournit des signaux et rapports utilisables.
Le moteur de réputation a, actuellement, plus de 103 000 adresses IP sous « consensus » (qui ont passé le contrôle de poisoning et anti‑faux positif) mais nous n’en diffusons qu’environ 10 % jusqu’à présent, celles qui sont corrompues sans l’ombre d’un doute. Nous travaillons sur le consensus et l’API, ce qui va permettre des requêtes externes, faites sans l’agent, seulement avec des bibliothèques (PHP, JavaScript, Python, Arduino, etc.).
À ce jour, les membres de la communauté viennent de plus de cinquante pays répartis sur six continents.
Nous sommes à la recherche d’utilisateurs, contributeurs et ambassadeurs et serions ravis de connaître votre avis sur cet outil. N’hésitez pas à nous contacter via notre site Web, GitHub, Discourse ou Gitter, nous sommes à votre disposition pour échanger.
L’équipe CrowdSec
# IPv6 ?
Posté par Bruno Stévant (site web personnel) . Évalué à 4.
On est en 2020, la recherche du mot-clé "IPv6" sur votre doc ne renvoie rien … Ne me dites pas que la sécurité est un problème de l'ancien monde ?
[^] # Re: IPv6 ?
Posté par CrowdSec (site web personnel) . Évalué à 0.
Absolument !
[^] # Re: IPv6 ?
Posté par Bruno Stévant (site web personnel) . Évalué à 1.
lol :|
[^] # Re: IPv6 ?
Posté par xryl669 . Évalué à 6.
En Golang, la classe IP est par défaut en IPv6, il faut instancier la classe IPv4 pour avoir du IPv4, donc c'est normal que la recherche pour IPv6 ne retourne rien.
[^] # Re: IPv6 ?
Posté par Bruno Stévant (site web personnel) . Évalué à 1.
J'ai cherché dans la doc, pas dans le code, dans lequel effectivement, ça ne rends pas grand chose non plus.
[^] # Re: IPv6 ?
Posté par Philippe_CrowdSec . É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.
[^] # Re: IPv6 ?
Posté par darck . Évalué à 10.
Par contre, il n'y a en effet pas de test unitaire sur des IPv6, donc ça n'a peut-être pas été un focus particulier en dehors du support natif d'IPv6 par net.IP.
Je ne pense pas l'avoir vu dans le code, donc je peux me tromper, mais il faudrait probablement prendre en compte une des problématiques de l'IPv6 dans le ban : le nombre d'IPs dans les ranges /64.
Car sans NAT et IP publique limitées, ça laisse des plages d'attaques très large pour qui veut exploiter les milliards d'IPs du /64 de son subnet direct. Un peu comme le fait de pourrir le NDP des switches en local. Il me semble que ça pourrait servir à deux choses :
[^] # Re: IPv6 ?
Posté par CrowdSec (site web personnel) . Évalué à 4. Dernière modification le 10 novembre 2020 à 12:48.
Merci, c'est une bonne remarque que nous avons prise en compte.
[^] # Re: IPv6 ?
Posté par tarreau willy (site web personnel) . Évalué à 3.
Ce qui est pénible avec l'IPv6, c'est que le plus petit réseau est normalement un /64 mais le plus petit noeud reste un /128. On en effet peut parfaitement avoir 1000 machines dans un DC sur un même /64. On pourrait se dire que c'est le même LAN donc la même autorité qui les exploite et qui en est responsable, mais dans de l'hébergement massif de type dedibox, on peut être intéressé de faire la différence entre de multiples noeuds du même LAN.
Une bonne approche pourrait consister à garder le /128 comme identifiant de noeud mais déterminer des critères de groupement en fonction des sources d'attaques. Si 10 attaques (par exemple) proviennent de /128 dans le même /64, peut-être qu'on peut considérer ce /64 comme n'étant plus sous contrôle et donc comme étant malveillant.
Le même principe peut alors être utilisé pour tenter de remonter à la taille de la plage allouée à l'attaquant. Par exemple chez moi j'ai du /48 avec Nerim, ça me donne 64k réseaux (c'est beaucoup, c'est gâché mais IPv6 a été conçu pour ça).
Donc je pense que l'approche devrait être un premier saut de /128 vers /64, puis remonter d'un en un au moins jusqu'au /48 qui est normalement la plage individuelle la plus large.
[^] # Re: IPv6 ?
Posté par Astaoth . Évalué à 2.
Est-ce que les serveurs AWS, OVH ou autres qui proposent de l'IPV6 attribuent une adresse unique ou un /64 complet au serveur ?
Emacs le fait depuis 30 ans.
[^] # Re: IPv6 ?
Posté par darck . Évalué à 2.
AWS je ne sais pas, mais pour OVH chaque serveur a son propre /64.
[^] # Re: IPv6 ?
Posté par Storm . Évalué à 2. Dernière modification le 11 novembre 2020 à 15:50.
Les serveurs OVH "OVH" oui, par contre les Kimsufi c'est des /128 :| (officiellement, parce qu'il semble qu'on puisse utiliser le /64 entier).
[^] # Re: IPv6 ?
Posté par Flyounet (site web personnel) . Évalué à 0.
<HS> Philippe, tu me rappelles tellement le BDE de l'Epita en 1998. </HS>
[^] # Re: IPv6 ?
Posté par Philippe_CrowdSec . É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 xavier Granveaux . Évalué à 2.
Mais est-ce qu'en IPv6, la notion même de scan, de part la volumétrie du périmètre à couvrir, fait encore du sens ?
Dans certaines lectures, j'avais pu comprendre que le fait de scanner tout le périmètre IPv6, ce qui est le coeur ciblé de fail-to-ban, n'est juste pas matériellement, ou en tout cas économiquement, viable.
Après, si le produit doit évoluer vers la protection d'attaques ciblées, ce n'est plus forcément la même histoire … ni la même réponse d'ailleurs.
# typos
Posté par Francois Revol (site web personnel) . Évalué à 4.
[^] # Re: typos
Posté par Davy Defaud . Évalué à 3.
Corrigé. Merci de les avoir signalées.
# Ça donne envie
Posté par Ririsoft . Évalué à 3.
Fail2ban m'a bien servi mais je trouve son architecture vieillissante.
Je vais tester Crowdsec avec beaucoup d'intérêt. Mon cas d'usage est la protection d'un serveur personnel pour du traffic SSH et HTTP.
[^] # Re: Ça donne envie
Posté par CrowdSec (site web personnel) . Évalué à 8.
Merci pour votre retour. CrowdSec devrait parfaitement répondre à vos attentes lorsqu'il s'agit de la protection de votre serveur. Nous sommes heureux de vous fournir tout le support tech qui pourrait vous être nécessaire. Vous pouvez interagir directement avec la team sur Gitter:
https://gitter.im/crowdsec-project/community
# FreeBSD, deban et WebUI
Posté par Astaoth . Évalué à 4.
Le principe est intéressant, cependant lève en moins plusieurs questions :
Tout d'abord : est-ce qu'un support de FreeBSD est prévu ? Outre le déploiement possible sur les prods FreeBSD, ca permettrait également d'intégrer CrowdSec directement dans les firewall Opn/Pf/Sense.
Si je comprends bien le fonctionnement, ce sont les bouncers qui réagissent en bloquant les nouvelles adresses ajoutées à la DB centrale de Crowdsec :
- est-ce que cette DB peut être sur un hôte distant, même en sqlite ?
- si une adresse est supprimée de la DB, est-ce que le bouncer dé-bloque la dite adresse IP ? Je pense en particulier à celui-ci : https://hub.crowdsec.net/author/crowdsecurity/bouncers/cs-netfilter-blocker
- est-ce qu'un mécanisme de deban automatique est prévu ?
- (question bonus) si on entre manuellement une adresse directement en base de données (avec le bon format de données évidement), et donc sans passer par cscli, est-ce qu'elle sera traitée de la même façon que celles ajoutées par crowdsec ?
Par ailleurs, j'ai vu qu'une webui est déployable, mais seul un screenshot de présetantion est disponible dans la doc. Est-ce qu'il serait possible d'avoir plus d'informations sur les possibilités de cette UI, voir une démo ?
Emacs le fait depuis 30 ans.
[^] # Re: FreeBSD, deban et WebUI
Posté par CrowdSec (site web personnel) . Évalué à 6.
Merci pour vos questions. Je vais y répondre une par une.
est-ce qu'un support de FreeBSD est prévu ? Oui c'est en cours de développement.
est-ce que cette DB peut être sur un hôte distant, même en sqlite ? Avec la version actuelle de CrowdSec, cela n'est possible qu'avec MySQL. La nouvelle version (v1) en cours de développement, va être publiée dans les prochaines semaines. Elle contiendra notamment une API http, qui permettra la gestion de la DB sur un hôte distant, y compris en sqlite.
si une adresse est supprimée de la DB, est-ce que le bouncer dé-bloque la dite adresse IP ? Tout à fait.
est-ce qu'un mécanisme de deban automatique est prévu ? Oui, mais on vous conseille de passer par le cli ou par l’API REST de LAPI qui sera disponible avec la v1.
-(question bonus) si on entre manuellement une adresse directement en base de données (avec le bon format de données évidement), et donc sans passer par cscli, est-ce qu'elle sera traitée de la même façon que celles ajoutées par crowdsec ? Oui
[^] # Re: FreeBSD, deban et WebUI
Posté par Astaoth . Évalué à 2.
Super, ca donne envie de l'essayer !
Justement, je posais la question parce qu'en cherchant dans la doc, je n'y a qu'un seul screenshot et que des instructions d'installation et de démarrage/arrêt.
Emacs le fait depuis 30 ans.
[^] # Re: FreeBSD, deban et WebUI
Posté par CrowdSec (site web personnel) . Évalué à 0.
Je vous invite à vous mettre en relation avec l'équipe tech sur notre Gitter pour un éclairage plus exhaustif.
# Petite Question sur le moteur de réputation
Posté par Christophe B. (site web personnel) . Évalué à 5.
Ceci n'est pas une critique mais une question sur votre moteur de réputation.
Je me souviens des listes blanches noires etc … sur les adresses IP des serveurs SMTP
Et du mal de tête que j'avais eu en cherchant désespérément pourquoi on recevais des mails mais sans pouvoir en émettre.
Jusqu'au moment ou je découvrais que notre FAI nous avais mis en Liste d'attente car nous avions émis trop de mails en 1h, il venait d'instaurer cette règle mais n'avait pas pas franchement prévenu …
J'ai alors découvert que le service "marketing" inondait ses prospects/clients de lettres / mails etc … a raison de plusieurs milliers par heures.
Tout en étant persuadé de n'avoir émis qu'un seul mail avec beaucoup de destinataires en copie …
Mais bon comment expliquer a un service "marketing" que cela ne se fait pas, surtout avec le type de FAI que l'on avait et le cout ridicule de l'abonnement.
Bref ne risque t on pas de voir des scripts-kiddies bloquer une société parce qu'ils s'amusent avec des outils de hackers sur le net … en imaginant le pire ?
Comment gérer ce genre de choses ?
[^] # Re: Petite Question sur le moteur de réputation
Posté par CrowdSec (site web personnel) . Évalué à 1.
Nous avons tout mis en place pour nous et vous prémunir de cela en faisant un travail de filtrage et de nettoyage qui permet d'éviter le poisoning et les faux positifs. La section FAQ sur notre site (https://crowdsec.net/faq/) saura vous fournir de plus amples informations, dans la langue de Shakespeare en revanche :)
[^] # Re: Petite Question sur le moteur de réputation
Posté par morphalus . Évalué à 2.
Je pense que le service Marketing devrait utiliser des services type Mailjet (sans vouloir faire de la pub, c'est qu'un exemple) : ils ont ce qu'il faut pour envoyer des mails en masse :)
[^] # Re: Petite Question sur le moteur de réputation
Posté par Christophe B. (site web personnel) . Évalué à 5.
En règle général le service marketing a besoin d'utiliser son cerveau …
Car bien souvent ce sont les premiers a raler sur les spams et publicité qui font perdre du temps dans les mails …
# Business model ?
Posté par xavier Granveaux . Évalué à 10.
Bonsoir,
Quand j'ai lu votre news, j'ai trouvé le principe super intéressant.
En plus, en prenant comme référence le génial fail2ban, et en mettant le doigt sur ses limitations intrinsèques, saupoudré de buzz-word, je me suis dit wouaw … le futur est là; le let's-encrypt de la protection de scan vient de naitre. A coups de Go, de containers, et de portabilité …
Par contre, quand je lis appel à contribution, les détails à voir avec l'équipe tech, via moultes canaux digitaux, un site web hyper léché alors que le produit est à peine disponible, des comptes linuxfr crées pour le coup, à coups d'opensource washing …
Je m'interroge.
Tout ceci me semble bien pimpant, bien ambitieux, bien prosélyte, pour ne pas dire inquiétant.
Quelques recherches plus tard, je tombe sur la présentation de l’instigateur annoncé de ceci.
"I founded 5 companies and invested in 10. Former tech/pentester/CTO (10 years), did business development (strategy, content marketing (5 books, hundreds of blog posts), automation) the next decade. Frequent public speaker/panelist (Security, Ecommerce, 100+ talks)"
Du coup, je propose d'aller au bout de la transparence pour engager la communauté : c'est quoi le business model derrière cette initiative ? ou business plan ? Quel financement ?
Je n'ai pas souvenir que fail2ban ait commencé par déposer ses statuts avant que les scripts y liés soient mis à dispo de la communauté.
PS: l'intention est louable, et le sujet intéressant, et d'autres acteurs sont sur le coup
PPS: letsencrypt avait d'emblée annoncé des sponsors généreux qui ne cachaient pas leurs intentions …
[^] # Re: Business model ?
Posté par Frédéric Blanc . Évalué à 3.
Un début de réponse semble être donné à la section « Data monetization » de la FAQ.
[^] # Re: Business model ?
Posté par xavier Granveaux . Évalué à 9.
Merci pour le pointeur , les éléments les plus intéressants s’y trouvaient;
“Server-side treatments are the following:[…]These parts are not open »
Next …
PS : pour faire écho à un message récent, je trouve personnellement que la promotion d’une entreprise privative ne devrait pas avoir sa place en une de Linuxfr.org;
[^] # Re: Business model ?
Posté par InfoLibre . Évalué à 2. Dernière modification le 11 novembre 2020 à 08:48.
On est déjà bien ennuyés avec les systèmes RBL, les filtrages de courriel des FAI et autres systèmes imposés, pas la peine d'en rajouter une couche avec un nouveau filtrage sur lequel on n'aura pas la main.
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . É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 seveso . Évalué à 8.
Là où on n'aura pas forcément la main, c'est lorsqu'on sera victime d'un surblocage en essayant d'accéder à un service protégé par CrowdSec.
Comme le signale InfoLibre, c'est un problème qu'on rencontre déjà avec les emails aujourd'hui. On se retrouve avec des emails non distribués car certains serveurs de destination utilisent une RBL qui considère notre adresse IP comme source potentielle de spam, sans qu'on sache trop pourquoi.
Alors quand on creuse un peu on finit par comprendre pourquoi (et souvent c'est un critère très discutable, comme le fait d'avoir une IP correspondant à un abonnement xDSL chez un FAI grand public), et on finit par trouver comment se faire déblacklister de cette RBL. Mais c'est vraiment pénible de se retrouver ainsi régulièrement dans la situation d'un présumé coupable devant prouver son innocence.
[^] # Re: Business model ?
Posté par _kaos_ . Évalué à 5.
Salut,
Alors tu as bien de la chance.
D'expérience dans une association, c'est inexplicable :)
Matricule 23415
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . É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: Business model ?
Posté par xavier Granveaux . Évalué à 7. Dernière modification le 11 novembre 2020 à 13:06.
Bonjour,
Avant toute chose, entendons nous, je n'ai pas poussé la recherche jusqu'au profil linkedIn; la citation provient de votre site directement.
Pour ce qui est de la compatibilité business et
Open SourceLibre je n'y vois aucune incompatibilité. Et monétiser la valeur de la société sur des fonctionnalités Entreprise, ou du support, ou de la monétisation de Data (euh, la c'est à débattre) est tout légitime.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.
J'avoue que le premier contact que j'ai pu avoir avec votre solution, telle que je l'ai décrite initialement, ne m'a pas encouragé à approfondir d'avantage. J'ai peut-être manqué le passage où il était annoncé que les sources du service hébergé seraient également disponibles.
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . É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 xavier Granveaux . Évalué à 7.
Ouch …
Ceci est un site communautaire, j'interviens ici à titre privé, et non professionnel … et mes propos et opinions n'engagent en rien mon employeur (je préfère insister la-dessus, s'il devait y avoir un doute).
Manifestement, un de nous 2 a plus que l'autre fait du profilage, c'est de bonne guerre … je serais impatient qu'une partie de mon activité personnelle (=Data) se retrouve stockée sur vos infrastructures, et à votre entière disposition, à des usages désintéressés …
[^] # Re: Business model ?
Posté par Anonyme . Évalué à 4.
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 ?
Si la réponse à ma question ci-dessous est "oui" alors ce sera en effet le cas, sinon la «communauté» n'aura à sa disposition qu'un ensemble non fonctionnelle qu'elle devra compléter.
Je ne vois pas en quoi les réalisations passées de votre CTO valident les choix faits par CrowdSec aujourd'hui.
Je ne vous apprendrai certainement pas que licence libre et monétisation ne sont en rien opposées. Votre CTO aurait pu (ou a pu, je ne sais pas) tout à fait monétiser sa solution d'une manière ou d'une autre sans que sa licence en soit altérée.
Ceci dit, j'ai 2 questions :
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . É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 InfoLibre . Évalué à 4.
Si vous voulez convaincre vos clients, évitez de leur parlez en franglais.
features -> fonctionnalités
premium -> ?
BO ???
honeypots -> leurres
leaky bucket ???
bouncers ????
Cloud trail ????
poisoning ?
…
Sinon, Golang est un excellent choix.
[^] # Re: Business model ?
Posté par dj_ (site web personnel) . Évalué à 7.
Oui mais c'est un bot qui partage automatiquement le contenu posté ici.
Contenu écrit en totalité par vous.
Ça fait un peu le serpent qui se mord la queue.
Si vous vous payez un article publicitaire dans une revue d'informatique, vous partageriez aussi le sommaire du magazine en mode "ils parlent de nous" ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.