Install Crowdsec at the source on the OPNSense

Offering services on the Internet, even if this is done privately, always carries a risk, so these systems must be secured. One candidate for this is Crowdsec.

Introduction

If you offer services publicly on the Internet, it is inevitable that sooner or later attacks will be made on this computer. Be it just to test whether a port is open or an actual scan for vulnerabilities is started.

It is therefore advisable to secure such a system in any case. But even if you do not offer public services, it can’t hurt to think about security here.

Firewalls

For example, I used to secure my Nextcloud with the UFW firewall and also used the fail2ban program, which is common under Linux, to ensure that brute force attacks on an SSH login, for example, were unsuccessful.

Even with the ProxMox installation, but even more so with the OPNSense installation, new options arise here.

CrowedSec

CrowdSec is based on the fact that, as with Fail2an, certain attempts are recognized as scenarios and the respective computer is then excluded. Here, however, the intelligence of the crowd is used. Such attacks are reported to a central API and from there it can be decided how to deal with such attacks.

I had previously run CrowedSec on Proxmox, but with the installation of OPNSense it naturally makes sense to carry out this installation on the firewall itself.

CrowdSec Plugin

There is a plugin for CrowdSec for OPNSense, so that the firewall itself provides the local API. However, since I have several systems running, these should also be secured with CrowdSec and deliver their results to the local API.

Installing the plugin is actually relatively simple. However, you then have to make an addition to the configuration on the command line using the VI Editor (use_wal:true)
Something must have gone wrong with my installation, since I suddenly had several CrowdSec Firewall Bouncers in the process list. A new installation didn’t help either. But in the end I discovered a directory /var/db/crowdsec, which I then deleted before the new installation.

The Clients

CrowdSec is of course also installed on the other computers or containers that host Nextcloud and other services.

The system automatically recognizes which services are installed. For example, an NGinx or an SSH or even just Linux in general, the corresponding rules are installed for them. And then the bouncers too.

These then get the rules via the local API, in this case the firewall itself.

Block lists

CrowdSec manages, among other things, IP V4 block lists, i.e. a list of IP addresses that are generally considered bad or aggressive. And that’s around 20,000 IP V4 addresses in the IPV4 range.

This means that problematic IP addresses are excluded from the system and don’t get any further, while the others are then excluded, at least later, via the decisions.

Conclusion

The system had barely been installed when the first bands appeared, i.e. exclusions of IP addresses from different countries, who probably wanted to test whether our firewall was vulnerable.
Apart from the small error during the initial installation, the installation was actually problem-free and there is very good documentation for a distributed API in a local network when a computer like the open Cents or another computer is supposed to provide the local API for different systems in the network.
As you can see above, CrowdSec has already fended off a number of attacks for me and in that respect I am happy with this system.

ciao tuxoche