crowdsec
-
So, what's the bottom line?
Any user can already install the ready-made CrowdSec package on pfSense. Yes, there are some inconveniences — for example, the package gets removed when pfSense itself is upgraded. But even Netgate themselves recommend uninstalling all packages before major upgrades and reinstalling them afterward.
Arguing that Snort and Suricata not being able to handle SSL traffic on the fly is somehow a competitive advantage sounds, to put it mildly, odd — because CrowdSec doesn’t do deep protocol inspection at all. Instead, it analyzes behavioral patterns based on system logs (such as SSH, HTTP, etc.) and blocks IP addresses accordingly.
In fact, CrowdSec can be more effective in certain scenarios — particularly due to its log-based behavioral approach. If you have public-facing services behind your firewall, CrowdSec can detect and respond to suspicious activity that traditional packet-level tools might miss.
For the average user who doesn’t host any services behind the firewall, pfBlockerNG with DNS blocking enabled is usually more than sufficient. I once compared both tools using community-maintained rule sets, and pfBlocker actually filtered out more junk traffic in practice.
At the same time, the lack of packet inspection in CrowdSec can also be seen as a limitation — not all types of attacks can be detected through log analysis alone. In that sense, all of these tools — CrowdSec, pfBlockerNG, Snort or Suricata — can complement each other when properly configured, each covering different aspects of network defense.
But again — nothing is stopping anyone from installing CrowdSec on pfSense right now.
As for official integration — I haven’t seen any response from Netgate. I don’t know what might be holding it back; possibly there are security concerns involved, but that’s just speculation.
-
@w0w Bottom line is it should be an integrated package. Instead of asking why should this be a package, my question is WHY NOT if it's already purpose built for that? The only gripes I see are people don't want to use it. Great then don't use it. A lot of people DO WANT TO USE IT. It compliments a weak point for pfSense and this is a next generation feature. OPNSense has fielded this with Sensei. If pfSense refuses to integrate it, I'm sure Crowdsec will go over there as well. Many who use pfSense in a hosting type environment could benefit greatly from this, especially since the Crowdsec team is basically doing all the heavy lifting to have it incorporated. Crowdsec IMHO is a better product than Sensei.
The only reason not to incorporate it is basic gripes of people who don't want it. Hell I don't want 75% of the packages already built with pfSense that offer nothing more than BS analytics you can do outside pfSense. This is a next generation security feature that actively blocks threats that DOES plug right in with pfSense, which is much more valuable if you want your pfSense product to be a relevant Next Generation firewall in 2025+.
I'm not going to continue to dish out for money for + licenses for a stagnant firewall, especially when I can go to OPNSense for free for the same features. However I'm a loyal pfsense user and remained here when the split happened, but that loyalty has it's limits. A lot of + users feel the same way. We paid expecting newer technology. Netgate will be losing money by not keeping their product relevant to their paid users. Less money to Netgate means less uptake for all packages and updates, and that hits the community edition people who are not contributing monetarily.
Bottom line is it's simple economics if they want their customers to remain loyal, you have to keep your product up to date with the times to your paying customers. Layer 3 firewalls are 90s technology and that includes Snort (Which was released in 1998). Newer threats need next generation features.
-
I get your point, and I agree that pfSense needs to evolve — but a few clarifications:
CrowdSec is already usable on pfSense — it can be manually installed and works fine. Official GUI integration would definitely improve adoption, but it’s not technically blocked today.
You’re saying that integrating tools like CrowdSec is a step toward a “next-gen firewall.” I get that — but let’s be clear:
CrowdSec is not a firewall. It’s more like a collaborative, modern fail2ban — a behavioral IP reputation engine that reacts to log activity. That’s useful only when there are services behind pfSense that generate logs (e.g., SSH, web servers, exposed APIs). If you're just routing traffic or using pfSense as an edge NAT gateway, there's very little for it to act on.
It doesn’t see actual traffic, can’t analyze protocol misuse, lateral movement, or application-layer anomalies. Snort and Suricata, while older, can still inspect traffic headers and patterns in real time — things CrowdSec simply can’t do by design.
So yes, integrating CrowdSec might be a step toward a more modern firewall stack, but it only covers a narrow layer of defense. And that layer is already accessible today — even if not officially packaged.
Personally, I’d wait for an official response from Netgate before jumping to conclusions.
-
https://www.crowdsec.net/pricing
Pricing of $348 to $46,800 per year is not the sort of feature I look forward to.Scroll down and you'll see a community plan.
Correct BUT with an organisation which view each paying customer as a very significant income stream the "free" offering WILL become very limited in applicability so as to ensure a paying customer is not missed.
Imo Netgate is more likely to find synergy with suppliers which help them support the market they address. Not my call obviously but loosing critical mass in a tool which adds value for the the majority of their paying customer is more significant than gaining enhanced support for a product aimed at different market.
-
@Patch you literally just described Netgate’s business model. You can’t have it both ways.
I’m a paying customer about to leave for a free firewall with better features. Network Security is the business. Crowdsec adds value to that. Are you a paying customer of Netgate? My situation is exactly opposite of and disproves your entire narrative.
Your whole argument is Netgate is not in the business of network security but that's exactly what a firewall is, network security. Are you drunk or something? lol
-
@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.
