crowdsec
-
@Zermus ...
From my perspective, CrowdSec relies heavily on a large user base to feed data into its system, making it fundamentally a reactive security tool. In practice, this means something harmful must happen to one user before others benefit from a preemptive defense. The more users, the more effective the system becomes. This is likely why there's a strong push to get it installed broadly—it benefits CrowdSec more than it benefits Netgate.
Netgate already provides a pathway for users to install CrowdSec voluntarily. Including it as an officially approved package would require additional oversight and transparency regarding how user data is handled. It would also mean Netgate is funneling another layer of potentially sensitive information into a cloud-based, Security-as-a-Service platform—something that introduces increased risk and undermines the principles of local firewall control.
CrowdSec's model depends on constant data collection from users to remain viable. Naturally, they want to onboard as many pfSense users as possible to build a fast, reactionary threat intelligence database. But that raises the question: what does Netgate gain from this relationship, beyond a shared ban list? In doing so, Netgate would be trading increased exposure of its user base for the benefit of CrowdSec’s threat modeling system.
“Crowd-based intelligence” is not without risks. There are significant compliance considerations around GDPR, CCPA, and HIPAA. The nature of threat modeling involves persistent log collection—tracking what IPs are communicating with whom, around the clock. For a firewall platform that exists to shield that kind of data, this represents a fundamental shift in risk posture.
Relying too heavily on a shared intelligence model can also create a false sense of security—especially in an environment where polymorphic threats and obfuscation tactics are evolving constantly. It's only a matter of time before something breaks, and when it does, the entity holding all that centralized data becomes a high-value target. That same data can also be weaponized to improve offensive attack modeling.
Personally, I believe in keeping things simple and minimizing attack surfaces. If someone wants to use CrowdSec, they can install it manually. As for me, I’ll continue relying on tried-and-true methods that have protected networks since the 1990s. Overreliance on automated tools can lead to dangerous blind spots, especially when those tools are built on shiny blacklists that often overpromise and underdeliver.
-
@JonathanLee Just from your response I can tell you've never worked in Fortune 100 or Government Network/Infosec IT.
We get it, you don't need this. Time to move on. You probably don't even pay Netgate for your use. Me as a paying customer, I'm going to be using a firewall that doesn't want to support my needs and incorporate future technology, I'm moving and taking my $$ elsewhere.
-
This post is deleted! -
@Zermus
Could you provide examples and typical usage scenarios of CrowdSec on pfSense? It would help everyone here understand the context in which it would actually be used on a firewall and why it can not be used right now. -
@w0w So I just want to point out I'm not associated with Crowdsec, but I am following their work, and I'm a fan.
Crowdsec works by collecting logs on your infrastructure. You install a "Security engine" in your environment somewhere. I run it on a VM off my Proxmox. You can feed it any and all logs you want it to analyze in your footprint. It's kind of like an AI log aggregator and attack response. You can install a client on these machines to do it's own analysis or just feed it the logs.
Crowdsec has 3 packages for pfSense. A small, medium, and large package.
The small package basically just acts as a bouncer on pfSense. It takes block requests from the Security engine and blocks them on your firewall access list depending on what is attacking your network, yes kind of like how Fail2ban works, but it's a lot more than Fail2ban since this is all based off threat intelligence from Crowdsec and what is being attacked.
The medium package adds the Crowdsec client to the pfSense firewall to analyze it's logs and analyze any attacks or scanning that might be occurring to feed it to it's threat intelligence feed. (IMHO this is the sweet spot)
The large package, I'm not really a fan of personally, but I guess it works in a pinch for some people. It puts the security engine on pfSense and handles it all on the pfSense server. I can definitely see how support for this would be a headache, but hey if Crowdsec is willing to do it, why not? I'd probably never use it since I run the Security engine on it's own server.
Firepower from Cisco and Wildfire for Palo are very similar to this and are used on their NG Firewalls.
-
Just from your response I can tell you've never worked in Fortune 100 or Government Network/Infosec IT.
Please take a moment to breathe before posting. While I might not agree with everything @JonathanLee said in his post, I did find it to be a reasoned presentation. There is no benefit to being rude.
-
@dennypage His whole argument was essentially he's not interested in using it and if he wasn't nobody else should. If he had a valid point that's one thing, but he kept repeating his opinion is the most important in the world over and over again like a broken record. IMHO that was much more rude but to each his own. Modern big brand firewalls offer many features like what Crowdsec is offering to use on pfSense. I mentioned Firepower and Wildfire.
Also when he said keeping your attack surface small (which is a good thing) keeping a simple defense is almost never recommended. I've got a CISSP and plenty of experience on the Infosec side and the Neteng side. Almost every literature and my 20+ years of experience on this subject preaches a defense in depth.
-
but he kept repeating his opinion is the most important in the world over and over again like a broken record
He isn't the only one that could be accused of this.
FWIW, I have a great deal of experience as well, and I see valid points on both sides of the argument. Honestly, I think this discussion has completely run its course.
-
@dennypage We'll have to agree to disagree on "valid" on this one.
-
@Zermus I appreciate the honest back-and-forth.
Based on your experience (especially with 20 years in the field and a CISSP under your belt), I’m genuinely curious how you see the comparison between CrowdSec and something like Security Onion — particularly with its Kibana/Elastic stack.-
Do you see CrowdSec’s real-time, community-driven blocking as overlapping with what Security Onion does, or are they fundamentally different in purpose?
-
Security Onion seems great for deep forensic analysis and manual threat hunting, while CrowdSec feels more automated and lightweight — maybe more of a first line of defense?
-
From a cost and operational perspective, do you think the lighter footprint of CrowdSec brings enough value, especially in smaller environments where a full SO deployment might be overkill?
Not trying to stir the pot — just trying to get a clearer picture of where these tools fit best from someone who's seen a wide range of deployments.
-
-
@JonathanLee Security Onion is something I really like from what I've seen. You're right. Crowdsec is more automated while Security Onion offers that defense in depth approach and they go crazy with it. I don't have much experience with most of their stuff, but what I've tested I like.
I've personally only used their honeypot on my home/colo environment, and it seemed to be solid and the best well maintained honeypot product I could find, although I was just testing it out and it didn't add much to my personal environments and I stopped maintaining it. I should probably keep one running though. I need to test out more of their stuff, because I did really like what I saw, but I have other stuff running that would make it redundant, but it's worth checking out to see if it's better. Wish I had the free time lol.
It's a shame Elastic took their stuff in house and ELK stacks are no longer free. Tom Lawrence's (https://www.youtube.com/@LAWRENCESYSTEMS) videos convinced me that I should go over to Graylog Open on my personal stuff when that happened and I'm happy with it.
What I really like about Crowdsec is it is automated based on log analytics and they claim to block active attack networks based on your location. It's a good system that keeps you informed and protected without having to do much manual log correlation. In fact it seems to eliminate the need for manual log correlating for the most part. You can think of it like a fail2ban on borg collective steroids and it is always adapting new filters to catch and adapt on it's own to block threats. Instead of blocking locally it blocks on the perimeter firewall, which in most of our cases here would be pfSense. It can also use pfSense's data on blocks to build a better threat model. The more you feed it the better it gets.
-
It's a shame Elastic took their stuff in house and ELK stacks are no longer free. Tom Lawrence's (https://www.youtube.com/@LAWRENCESYSTEMS) videos convinced me that I should go over to Graylog Open on my personal stuff when that happened and I'm happy with it.
I always viewed ELK as overly complicated. Graylog is much more manageable, although the console isn't as nice. Work in progress.
