I’m making progress with setting up my Crowdsec installations with
- Seting up local api pod consisting of Crowdsec, Metabase and MariaDB container. This is working except for some sql problems because of using MariaDB instead of Sqlite.
- adding Crowdsec docker container to my services’ pods (Nextcloud, …). Working well so far. Scenarios are working and pushing to local api.
- Setting up bouncer on the OpenWrt router. This is a bit puzzling due to limited space on the device but is making progress.
All those setups are using latest available version of Corwdsec.
I now want to add another agent on system where I don’t have docker/podman and I’m limited to install Crowdsec from the repository, which is for Debian Bullseye, Crowdsec version 1.0.9.
I know Crowdsec is offering an own repository but I’m not wanting to add non Debian repositories on a production machine.
a) Will version 1.0.9 agent work with local api 1.3.2?
b) Is there a chance to get newer versions of Crowdsec into Bullseye backport repo?
That’s a very relevant question but unfortunately I see no other way than to add our repos on your production machine. As soon as Debian goes stable, not much is happening with any package and as you may imagine, things on CrowdSec are moving - fast. So no, I doubt you’ll get an old version of the agent working with a new version of the lapi.
In terms of backporting, it depends on which version gets into Debian unstable. The guy doing the package is hired to do this by us, so maybe we can ensure to always have the newest version here. But is there then any real difference to just adding our repo? Yes, I get that that there is a principal reason. But in reality?
Thanks for the quick answer.
But is there then any real difference to just adding our repo? Yes, I get that that there is a principal reason. But in reality?
That is exactly, what a bad guy would say.
Yes, I believe there is a real difference. Having software packages gone through the Debian process and testing gives it more trustfullness (for not causing problems and having it signed off in the process).
For a security software that is already in current Debian stable, it would looking good having it in backports as well. Not seeing it in backports was what made me ask, so … it looks a bit suspicious. I believe, I’m not the only one relying on official repos only for production machines.
As far as I know, there is a process to get packages a first time into backport process and after that it’s not a big effort for further updates (that’s what I’ve been told from Cockpit developers).
Although we never tested it, the crowdsec agent available in the official debian repositories should work with a LAPI runnning the latest crowdsec version (the API changes between those versions should be backward compatible).
The main issues I foresee are:
- the lack of new datasources (which might not be an issue for you if you only read from files)
- You will be restricted to an older version of hub, which means older version of the parsers and scenarios
- obviously all the bugs that were fixed since then will be present
We are currently in the process of adding the latest crowdsec version to debian unstable (no ETA yet), which may leads to it being available in the backports (this is not something we considered before, we will have to look into it).
Another solution would be for you to build the debian package yourself if you have an internal repository, the debian sources are available here: crowdsec/debian at master · crowdsecurity/crowdsec · GitHub (those are the sources for the package we provide in our own repositories, not the package in the official debian repositories)
Is your issue solved here @ne20002?
I now gor far a different approach and only used crowdsec agents in conatiner on my two pods (Friendica, Nextcloud). This works well so far. Currently parsing the Modsecurity OWASP errors does not work, but I give it a bit more testing …
Also I’m waiting for the bouncer to be installable on my OpenWrt router.
For the reverse proxy I will not use Crowdsec. I have a fail2ban in place blocking all requests to either pure IP or any server name not existing. This is filtering most of the bad attempts and those who are simply scanning ip ranges for open ports …