Hi everyone,
I’ve created a flake with NixOS modules for Crowdsec and I thought I’d share.
Feedback and contributions are always welcome, especially code review wise and in terms of documentation.
Hope someone finds this useful 
Edit: I’m not affiliated with Crowdsec in any way, this is only just an open source effort
I really like the idea of Crowdsec but I’m not sure how I feel about about crowd-powered data ending up in a proprietary product and sold.
And I’m guessing only their client is open-source.
Obviously it might not be an issue at all for many people, I’m just thinking out loud.
Anyway, thanks for the module!
@bbigras Sharing is not obligatory, but you will get the most out of it if you share.
I think it’s worth noting that the information shared is not raw data. What is shared is the timestamp, malicious IP address and reason (think “trying to brute force SSH”) of decisions your local security engine already made. In other words, you are only sharing IPs that are determined to be malicious by your own rules.
If you decide you don’t like to share, you can still enroll the security engine and receive updates from public, third party blacklists like greensnow.
You may also decide do not enroll your security engine at all and run completely offline. The central console (“Crowdsec cloud app”) is really just an added benefit, the software itself is completely open source and works fine without any online service.
You can still get some benefit from running Crowdsec as compared to fail2ban. As an example, the security engine can consume logs from a central data source, eg. Loki, K8s or a central syslog or whatever, and distribute decisions only to your local bouncers. Think of it as if one server notices a brute force attempt, all other servers will also block the source in advance.
Hope this clarifies a few things
You mean not obligatory.
I’ve been intending to try this out, without sharing, it not being a shambling, half-maintained python chimera is definitely a benefit over fail2ban, too. Teaching fail2ban new tricks is hard, you e.g. need to compromise on user isolation to get prometheus data export from it.
There was no NixOS module though and making one seemed hard. Thanks for sharing, maybe this can eventually be upstreamed
You mean not obligatory.
Yes, indeed, please excuse the confusions. Second languages and all … 
I’ve been intending to try this out, without sharing, it not being a shambling, half-maintained python chimera is definitely a benefit over fail2ban, too. Teaching fail2ban new tricks is hard, you e.g. need to compromise on user isolation to get prometheus data export from it.
Just omit the enrollKeyFile from the settings and you are good to go.
You can still install collections, patterns etc. from the hub I think (not tested though), so should be easy to get going.
Disclaimer: I’m one of CrowdSec’s founders, obviously fundamentally biased.
Hi everyone,
Thanks @kampka for your contribution, we very much appreciate the gesture!
Don’t hesitate to connect with our community manager Jack or to connect to the discord.
Thank you all for your explanations and questions.
I know our business model is raising legitimate questions, which I hope, are formally answered in this blog post we published lately.
<TL/DR> We do not export anything more than necessary (security engine ID, timestamp, aggressive IP, behavior). We do not (and will not) monetize the security engine, which is a mix of WAF+IDS+IPS+SOAR. We haven’t Open sourced the consensus engine (the one including & removing IPs in the blocklists) because we do not yet take contributions on it, it’s as much code as it is infrastructure (so not really replicable), and we iterate quickly on this algo, making it complex to fully opensource with proper CI/CD, full documentation, etc. (Yet you can partake in its development by getting in touch with the tech team)
What we monetize are the data coming out of the network toward enterprises willing to buff up their CTI systems and extra layers of corporate services to handle large fleet of security engines.
I realize by writing it that a <TL/DR> of the <TL/DR> could help…
<TL/TL/DR> If it’s free, it’s because the bad guys (IP) are the product.
Happy blue teaming everyone.
That statement is slightly ironic on the NixOS discourse 
Thanks for the clarification, and the cool project. FOSS projects shouldn’t need to shy away from monetization so much IMO, as much as I often share the feeling. We’re just harming the community by being too suspicious of that.
Couldn’t agree more @tlater. And indeed, I just realized the irony of the code-infra part of my explainer. Stays that we would need to make the code infra-agnostic, which would cost us a large amount of engineering time and would be useless in the sense that without the hundreds of thousands of machines reporting signals, the code itself wouldn’t be useful.
On the other hand, people with expertise in the IP reputation domain and Byzantine Fault problems are more than welcome to join the group working on those aspects.
Regarding monetization, I’m not a Stallmanist. I’ve been called names time and time again but if users want to rely on strong, well architectures and maintained FOSS, the editor needs to pay smart people with sound money. The coding-monk living in the forest and feeding from edible moss doesn’t attract talents in my own experience.
So monetization is equally as important as asking yourself why you embraced the open-source route in the first place. Which I hope was properly described in the aforementioned blog post.
Heads up if you are using this Flake to deploy your crowdsec setup
The project repository has moved from Github to Codeberg and can now be found at
Please make sure to update your dependencies to receive further updates.