Recently stumbiled across CrowdSec. Sounds interesting, plus it’s Open Source 
Wonder if we will ever have an Add-On for this?
CrowdSec is an open-source and lightweight software that allows you to detect peers with malevolent behaviors and block them from accessing your systems at various level (infrastructural, system, applicative).
Hi,
welcome to the IPFire community. 
Just to be clear on that: Closed-source software is a dealbreaker for us. We expect things to be open source if they wanted to have a chance to land in IPFire.
I read through their documentation and, to be honest, cannot really see the benefit of it. If I understood it right, CrowdSec is about reporting offending IP addresses (“offending” defined by the configurations of software reporting them), preemptively blocking them on any other CrowdSec installation.
There are numerous services like this already available. I do not really see the benefit in fragmenting this landscape even further.
At IPFire, I tend to care more and more about the outgoing traffic, not the incoming one. This is because we are quite good at filtering incoming traffic (that’s the minimum requirement for a firewall, isn’t it? 
), and have things like the IPS available if any port has to be exposed to the internet.
On the other hand, people are pretty reluctant from regulating outgoing traffic, because this is hard, requires some knowledge on your network, and users are offended if something does not work afterwards. At IPFire, we try to make it easier to block outgoing network traffic to networks known as hostile (i. e. used for dissemination of malware, trojan downloaders, botnet controllers), and to improve the overall security, I think we should focus more on this side of the traffic.
Having information about IP addresses attacking other services is nice, but I would prefer a curated and freely available list of malicious IP addresses hosting cybercriminal infrastructure over it. To the best of my understanding, CrowdSec provides the former, not the latter.
That being said, you are invited to work on providing CrowdSec as an add-on. Please see here for further information on this topic.
Thanks, and best regards,
Peter Müller
+1 !
No FW ruleset can hinder a user to unintentionally catch malicious code via email etc.
But:
If the attacker’s mischief cannot re-connect back to it’s C&C, it is “locked-in”.
Hey and thanks for the suggestion @adamgibbo. I am head of community at CrowdSec so I thought I’d join the discussion
CrowdSec is an IDS and IPS which protects services by looking at logs and detecting attacks, so yes, this is about ingress traffic. But contrary to the common perception in this thread there is nothing quite like it. Let me explain why.
CrowdSec enables all users to share intelligence on attacks on whatever service you’re exposing with everyone else in the CrowdSec network. This means that if you’re running a Wordpress server and someone tries to bruteforce attacks the wp-admin backend, the rest of the CrowdSec community who’s using it to protect Wordpress are informed and blocks traffic from the ip that attacks you - and vice versa. In short: everybody protects each other.
Some see CrowdSec as an advanced Fail2Ban. That is not completely wrong but not true either. Fail2Ban is a great tool but it’s a bit limited in the attacks it detects and how it mitigates the threats. CrowdSec has a way more flexible engine for detecting attacks and can detect bot scraping, data exfiltration; in short it detect anomalies based on an advanced ruleset consisting of grok and yaml. In terms of mitigating it doesn’t just block traffic on network level but is able to mitigate traffic on application layer directly in nginx, wordpress, traefik and whatever is supported - even Cloudflare, Fastly and very soon AWS WAF just to name a few. And it’s able to force connections marked as malevolent throught a captcha, for instance.
In terms of ip lists of attackers vs c&c we are working on various ways to adopt external CTI feeds into CrowdSec. One property of CrowdSec that is a bit overlooked is that it’s also a powerful platform to distribute CTI that’s normally only used by SIEMs and SOCs and make it useable for everybody. We would really love that. The ultimate goal of CrowdSec is to get so much CTI collected in almost real time and a direct connection to BGP blocklist distributors and many more so that we can burn the ips of the criminals, forcing them out of business. We’re not there yet but we’re definitely working on it!
So I had a look at the crowdsec source files to see how its build and install approach would fit in with the IPFire approach for whoever wanted to pick this up as an addon.
In the GitHub repository there is a crowdsec-release.tgz file. This just installs already compiled and built binaries, so not appropriate for IPFire.
There is a second source file called Source code (tar.gz). This contains the source code for crowdsec and crowdsec-cli. These are built using go which is available in the build system for IPFire.
However there is only a Makefile and no configure file. Looking at the Makefile the build intends to put the binaries into /usr/local/bin which is kept for IPFire specific scripts and helper programs. To change the location for the bin files the crowdsec Makefile would need to be patched.
Additionally looking at the wizard.sh script, which needs to be used after the make and make install steps, the crowdsec daemon is run as a systemd service. Also all the search for which services are running on the machine to know which logs need to be investigated is done via a systemd approach. There is no SysV approach for running the crowdsec daemon.
As IPFire 2.x does not use systemd this I believe would be a showstopper without major additional work on the script.
Crowdsec uses pattern files to define the structure of the log file info. For firewalls this pattern only includes Cisco and Shorewall. So someone would need to add a pattern description to this file to define how the logging information would be accessed in IPFire.
The above is just based on a quick search through the source tarball and I might have interpreted some bits incorrectly but it looks like whoever would like to try and make an IPfire addon of crowdsec would have a significant job on their hands above what is normally required for the building and release of an IPFire addon.