Hi all and @snorremd,
(Philippe from the CrowdSec team)
The $2.5K / month was for enterprise, but we didn't correctly understand the need and converted it to 2 optional prices: $1K for LTS and $1K for support.
This will be reflected in an update on our pricing page this week; thanks, everyone, for your patience in this matter.
It took us time to segment our four products properly. We wanted to avoid pivoting later, as it happened to so many other open-source tools recently.
* The Security Engine (IDS+WAF+IPS) is for everyone.
(Free / MIT license, three free blocklists)
* Its SaaS companion is made for anyone with a security engine.
(Generous free tier, $31/engine/month for pro industrialization features, 3 premium blocklists + all free ones. Volume discounts avail. We'll soon merge SecOPS and enterprise plans, all features at the price of the SecOPS plan)
* Blocklists are made for M/L entities to use.
(In the range of a few ten of K$ yearly, all blocklists, unlimited)
* The Full CTI database is intended to be used by L/XL Corps.
(It contains 32 fields about ~25M IP, with industry targeted, country targeted, tech stack targeted, AS and range reputation, etc. Local replication at your place, several updates/day. 10 to 20K$ / month, depending on some parameters)
PS: As we did for the Olympic Games 2024, we'll also give away a blocklist for the US presidential election of the most aggressive IP against US assets. With a quarter of a million machines running CS, we have a fairly good overview of this, in real-time.
CrowdSec is not designed specifically for SSH. It can ingest any type of logs and answer with a bouncer at pretty much any level. IP/Session/User/software stack. Ie, we are working on Magento to parse all logs (apache, magento's logs, etc.) and provide a bouncer that is user aware, at an applicative level. Some people are experimenting it to parse logs from airplane communications, to see if pilots behavior is close to a standard or deviate. We have experimentations on BGP protocol, etc.
Absolutely. We owe that transparency to our users. The 1.0 should be out in a month from now, and it will include a Local API, an abstraction layer between the core and the bouncers & data sources. This will help the community to dev their own scenario, bouncers & data source connectors. But at that stage, we had no report of CrowdSec daemon bugging a server, crashing it or over consume resources. It's even used by some hosting companies, to process their reverse proxies logs, without any meaningful perf impact. That being said, it's still beta because some features or architectural points could vary a lot at that early stage. We only distribute 5 to 10% of the IP rep DB because we are over cautious and don't want any false positive to happen. Our Consensus algorithm is getting better by the week by we are cautious by nature (and experience)
I should maybe have told you also, team members are from pentesting and high security hosting background.
We also have created some other OSS components before, like NAXSI (Waf over Nginx), Snuffleupagus, PHP malware finder, etc.
So we faced the hurdles of assembling, deploying, configuring, handling and maintaining sectools in our Devops & Secops environments, and we thought this tool with our years of experience in mind.
no risk here. Tool is MIT, if community doesn't like our approach, you fork it. So we'll be faithful to our commitments and this licensing model is the best insurance for it. Now, I can also tell you that people using the free software and contributing IPs will get back, for free, the IPs dangerous for their technology footprint. (like if you use Wordpress / SSH & Nginx scenario, you'll get the IP attacking those). Free. Period.
We monetize the aggregated, curated data and the features we offer that cost us infrastructure to run.
Well actually Spoofing on a private network is trivial, but in TCP over a public network, it's another story entirely and it's not simple at all. UDP can be easily spoofed though, hence we do not treat reports in the same way so far. Beyond this, there is eventually BGP spoofing, but funny enough, CrowdSec could detect them, provided you have logs. It should be fairly easy to track in terms of behavior.
You wouldn't have to spoof. I said seed, not spoof - you could just spin up a bunch of servers, connect it to the crowdsourced security networks, and issue false claims that IP address X has been attempting to break into your network, and suddenly block X from their own servers.
Well we have a consensus system that's quite advanced to avoid poisoning and false positives. To put it short, all members have a Trust rank, only TR1 can publish an IP without counter verification, and only if it doesn't shoot a Canari from our whitelist of IPs. TR1 mean perfect accurate reports for 1+ year. All other TR level can partake but need counter verification from either our own honeypot network or other TR1 peers before being integrated. There is also an AI that will be trained soon to confirm false negatives and extract more complexe patterns.
So basically anyone joining the network for the next year sits in limbo, the network is not capable of catching more "bad IPs" for that year, because any report by new members requires cross-verification by the original nodes/honeypots.
This seems pleasantly conservative. Also, is there a way for nodes to lose trust rank? (How will the network find out if a TR1 node is reporting false negatives?)
yepn indeed, we call it private sharding or private consensus. Far on the roadmap (4 months), but nevertheless, the team is thinking about it. You could also include or exclude some Geographics for ex if you don't trust a country or have a private consensus between only your own machine. If you are, say Morgan Stanley, you may be attacked only you by some machines and the crowd wouldn't know. But all your servers teaming together will see it.
LAN addresses, eh? People do still use internet addressing on our networks despite the consumer CPE vendors increasingly trying to sell you NAT stockholm syndrome :)
We'll (soon) provide a Backoffice, where you can choose which IP you decide to ban (based on their activities, like bot scrapping, bruteforcing, etc.) but also add some 3rd party blacklist, block some AS or ranges, Tor exit nodes or VPN. This is all being builded right now, but in a couple of months, should be available.
Perfwise, we have a user that previously used fail2ban to block some http botnets. He crunches 7000 IPs worth of logs in 50 mins with F2B. under a minute with CrowdSec. Another block 3000 IPs doing credit card stuffing directly at payment page, very quickly as well.
The $2.5K / month was for enterprise, but we didn't correctly understand the need and converted it to 2 optional prices: $1K for LTS and $1K for support. This will be reflected in an update on our pricing page this week; thanks, everyone, for your patience in this matter.
It took us time to segment our four products properly. We wanted to avoid pivoting later, as it happened to so many other open-source tools recently.
* The Security Engine (IDS+WAF+IPS) is for everyone. (Free / MIT license, three free blocklists)
* Its SaaS companion is made for anyone with a security engine. (Generous free tier, $31/engine/month for pro industrialization features, 3 premium blocklists + all free ones. Volume discounts avail. We'll soon merge SecOPS and enterprise plans, all features at the price of the SecOPS plan)
* Blocklists are made for M/L entities to use. (In the range of a few ten of K$ yearly, all blocklists, unlimited)
* The Full CTI database is intended to be used by L/XL Corps. (It contains 32 fields about ~25M IP, with industry targeted, country targeted, tech stack targeted, AS and range reputation, etc. Local replication at your place, several updates/day. 10 to 20K$ / month, depending on some parameters)
PS: As we did for the Olympic Games 2024, we'll also give away a blocklist for the US presidential election of the most aggressive IP against US assets. With a quarter of a million machines running CS, we have a fairly good overview of this, in real-time.
Safer together.
reply