crowdsec has always struck me as a really odd approach to security. You give out your logs to strangers and block IPs based on their say-so.
The cause and effect are so far removed that I can’t wrap my head about how it’s supposed to be efficient. It’s been proven in real-world tests that it lags badly behind the first waves of new vulnerabilities and by the time it starts blocking IPs that were related to those attacks the attackers have moved on and there are also patches available.
The “thousands of IPs blocked” image reminds me of that WWII airplane bullet-holes image.
I don’t believe there are any logs being transferred, just the abusive IPs are shared with the central DB.
So if an IP starts hitting a ton of rules (like .env access, repeated 403s, 404s, 429s, etc… Or specific AppSec rules) then that IP is blocked and sent to their central DB where it’s pushed out to everyone running crowdsec.
On my setup crowdsec has been more effective than cloudflare at stopping scanners and bots from overloading things, cloudflare just lets basically everything through so I stopped using it.
That said I’m curious if you remember the source of the real world tests, because I’d love to see what’s actually better.
Sure, but that WAF solution is not for us, it’s aimed at clients who can measure their web presence in millions of requests per second.
Cloudflare is a CDN first and foremost, their success competing with Fastly and Akamai has been good to them, but they don’t care if you get pwned unless you have a ton of money.
CrowdSec isn’t really for protection against novel threats. It’s just a crowdsourced Fail2Ban that’s extensible with custom rules.
If you and I are both using CrowdSec, and some foreign machine is trying to brute force into one of my services, then when it tries to do the same to you it doesn’t even get the chance to try. It cuts down on the load.
You can also define your own scenarios. Most of the rules it ships with block IPs using a leaky bucket method but I have a custom rule that instantly blocks anyone trying to log into anything using usernames like admin, root, pgadmin, etc.
You’re not wrong. If CrowdSec is your entire approach, it’s a little weird. But I use it as a (small) part of my overall blocking strategy. I use other lists and frankly, block most IPs by default. Those other IPs aren’t counted in the email screenshot though… only the CrowdSec based ones are coming through. I think a lot of the 137k above are just scanning bots to be frank.
crowdsec has always struck me as a really odd approach to security. You give out your logs to strangers and block IPs based on their say-so.
The cause and effect are so far removed that I can’t wrap my head about how it’s supposed to be efficient. It’s been proven in real-world tests that it lags badly behind the first waves of new vulnerabilities and by the time it starts blocking IPs that were related to those attacks the attackers have moved on and there are also patches available.
The “thousands of IPs blocked” image reminds me of that WWII airplane bullet-holes image.
I don’t believe there are any logs being transferred, just the abusive IPs are shared with the central DB.
So if an IP starts hitting a ton of rules (like .env access, repeated 403s, 404s, 429s, etc… Or specific AppSec rules) then that IP is blocked and sent to their central DB where it’s pushed out to everyone running crowdsec.
On my setup crowdsec has been more effective than cloudflare at stopping scanners and bots from overloading things, cloudflare just lets basically everything through so I stopped using it.
That said I’m curious if you remember the source of the real world tests, because I’d love to see what’s actually better.
Cloudflare is in the business of keeping infrastructure up and working. Any security benefits of CF are secondary.
They do talk a lot about security and their WAF on their home page, it might be secondary but they mention it a lot.
Sure, but that WAF solution is not for us, it’s aimed at clients who can measure their web presence in millions of requests per second.
Cloudflare is a CDN first and foremost, their success competing with Fastly and Akamai has been good to them, but they don’t care if you get pwned unless you have a ton of money.
I guess? They advertise it as blocking bots and bad actors and such but it doesn’t really do that.
CrowdSec isn’t really for protection against novel threats. It’s just a crowdsourced Fail2Ban that’s extensible with custom rules.
If you and I are both using CrowdSec, and some foreign machine is trying to brute force into one of my services, then when it tries to do the same to you it doesn’t even get the chance to try. It cuts down on the load.
You can also define your own scenarios. Most of the rules it ships with block IPs using a leaky bucket method but I have a custom rule that instantly blocks anyone trying to log into anything using usernames like admin, root, pgadmin, etc.
You’re not wrong. If CrowdSec is your entire approach, it’s a little weird. But I use it as a (small) part of my overall blocking strategy. I use other lists and frankly, block most IPs by default. Those other IPs aren’t counted in the email screenshot though… only the CrowdSec based ones are coming through. I think a lot of the 137k above are just scanning bots to be frank.
Do you have a source on the real world tests?