Philippe_H

CrowdSec scans also firewall logs like PSAD and much more applicative logs types than fail2ban. That being said I use tailscale to ssh to my servers.

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.

Safer together.

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.

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.

Sure, People activate the sharing of what they spot or not. If they do, no money is asked for them benefiting from the global IP rep DB. The one willing to use it without contributing will be able to do so, through API calls, but at a (moderate) cost. We'll have 2 plans, premium & enterprise. They we will provide support, tools for fleet management (like deploying a policy on X/Y/Z servers from a central location), AI (to spot larger trends), cold log analyzes (forensic, but harder coz of GDPR), tailor made bouncer responses, bounce back to us and self IP monitoring (to see if they are caught in a consensus, hence have been hacked). Also, bouncers, the components blocking Ingress IPs are able to work without the GO daemon, by just using the IP rep DB. Think for exemple someone willing to protect a group of IoT machines, low CPU, low mem, the API approach is close to costless in terms of resources and allow those machines to be protected without running the daemon.

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.

well just whitelist your Public IPs or use a combo of IPset & port knockd. Works fine for me for variable IPs.

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.

this is accounted for. By default you have a whitelist containing local lan IP ;)

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.

CrowdSec is for all protocoles / system generating logs (can be Cloud trail, syslog, kafka, etc.) and can ban at an applicative, user or IP level.

Sorry, we should have made it clear, it is totally optional. You just don't get the IP rep DB part of the soft if you don't share, but the behavior is still 100% functional.

(but I think they already send it through HTTPS)

Well hashing is (usually) a symmetric function and we are open source... Meaning you could recover the key in the code (or intercept it during transfer). I think Private/Public key is a simpler approach, reusable elsewhere in the code and it's known to be safe. But I'm not the CTO either, I could be mistaken.

Sure. To put it very short, we give every user a trust rank. It varies overtime. If you consistently, and for a long while, reported attacks that could be correlated by others and our own botnet, you progress, until you reach trust rank 1. Other are listened to, but need double verification from TR1 and/or our own botnet. We also have a canari list, which contains IP not too shoot. (Google bot, Microsoft update, DNS, etc.) and last but not list, an AI mashing logs to extract larger patterns. With this "consensus" chamber, a weighted vote is cast and the IP is then included in the DB. (We are always on the more conservative side if in doubt) If you ever feed bad intel, your TR regresses. If you shoot a canari, we'll either presume you are trying to poison or that your scenario is too twitchy. If you feed a bad intel, you TR regresses instantly and your voice weight less in the consensus (actually nothing in fact). IP are fresh, they were seen doing crap at max 72h before. Beyond this threshold, we consider them not relevant anymore and wait for a refresh. So if you are doing "headshots", 0 days style, only, the system would have hard time catching you. But if you port / web scan, bruteforce, do credential or CC stuffing, or whatever else, the system catches you quite quickly.

different approach, but I'm sure at some point we'll get close to one another.

Hi Guys, thanks for all your feedbacks. (I'm part of the CS team) I'll try to address some few questions.

1/ You don't have to communicate. If you don't, you get a modern, fast, decoupled fail2ban with many various remediations (instead of just drop) and observability. What you don't get though are the IPs spotted by the crowd and curated by us. You don't contribute, you don't get them, fair. If you contribute, only offending IP / timestamp / scenario triggered are sent back to us to establish what we call a consensus (to avoid false positives and poisoning)

2/ We are super vigilant and sensitive about privacy. We made the architecture and many other crucial points compatible with GDPR (EU Law framework regarding private data handling)

3/ IP sent: We could hash it, but it's very easy to reverse. Maybe have a public/private key encryption, quite a good point, I'll tell the team, thx.

4/ You can contribute scenario in YAML or data source connectors in Grok. We are not hardcore for or against any language, but Go allows portability (we'll release Win & Macos binaries) and is container friendly, plus super fast, easy to read and scalable. Ever since we released, tons of proposal were made to port it to a 'real' language, sorry we are fine with that choice, no intent to change, no intent to convert anyone either ;)

5/ Herd immunity is what we want to create indeed. We tried to explain the combination of Behavior + Reputation by using an analogy with Waze. It worked but is less accurate. I prefer the one with Immune system.

We are available for direct dialog on gitter. allow just some delays depending on your time zone, we are based in France, so CEST. (https://gitter.im/crowdsec-project/community) we answer in French & English.

Try it, it's free, MIT licensed and stable: https://github.com/crowdsecurity/crowdsec

Thanks,

Philippe.

Thank you, don't hesitate to reach us through gitter or discourse or else.

We would love to hear your comments if you feel like. To have a more textual version:

TL;DR: CrowdSec parses logs from various Data sources, normalizes and enriches them before applying heuristic scenarii to identify aggressive behaviors and protect you from most attack classes. Like with fail2ban, things like credential stuffing, web or port scans, ssh / ftp / telnet brute-force, and many others are really easy to defeat with the software, but CrowdSec modern grammar & architecture give the users more possibilities. The global thing is to generate a IP reputation Database, shared among our community members, that is fed by them, curated by us and sent back to all members. This could become the largest ever hack-interferometer.