Crowdsec OPNSense external sources

1

Dear all,

I’m running Crowdsec-Plugin on a OPNSense and everything looks fine.

Now I want to embed some more sources.

I have a internal machine with docker and vaultwarden installed. This machine is available through HA-Proxy on OPNSense. Now I want to include Vaultwardens Log-Files into Crowdsec (analyze on the machine on docker and block the atackers directly on OPNSense).

My problem is, I don’t know which modules I need on my docker machine (VMWare) and how to submit the result to OPNSense where Crowdsec incl. blocker for the firewall is already installed.

Are there any manuals out there or do you have some hints for me?

Thanks

2

So this is what we class as a “multi server setup”, so the aim is to install a security engine within the docker stack and forward alerts to the main opnsense.

https://www.crowdsec.net/blog/multi-server-setup

But what you want to achieve is your opnsense to listen to external events so that means the LAPI will need to bind to “external port” OR be proxied by HA-proxy (Within the video I show you how to proxy it via nginx which is same premise).

Then within the docker environment you want to spin up a container that will make a requests to the central LAPI. That’s all you need to do as the remediation components installed on opnsense should already handle blocking.

3

Dear iiAmLoz,

Thanks a lot.

Just to be sure I understand right:

  1. Modify LAPI on OPNSense to “hear” on one of the internal IPs (instead of 127.0.0.1) - this can be done via web-GUI
  2. Install Crowdsec on the Docker machine
  3. Install Vaultwarden-Collection on Docker machine
  4. Modify Crowdsec on Docker machine to report to OPNSense instead of LAPI on Docker machine

That’s all?

I will give it a try and hope I will success.

Just another question on crowdsec’s principle:

When Running Crowdsec on Machine 1 as a central Crowdsec instance - Machine 2,3,4 will report to Machine 1 and Machine 5,6,7 will have running bouncers/remediation components which also interact with machine 1 → all remediation components will block all attackers found on machines 2,3,4?

It’s not the fact, that for example Machine 2 with Remediation on machine 5 is paired and machine 4 with remediation on machine 6 is paired …? Or another example Machine 1 as central instance and machine 2 will have collections and remediation on one machine - same for machine 3 and 4 → here it’s also not right, that machine 2 will only block its own attackers, it will also block known attackers from machine 3 and 4 even if these doesn’t attack machine 2 - all in case every part reports to machine 1?

4

Exactly, centralizing the alerts means all your instances can share decisions between themselves.

5

Thanks a lot - it works like expected.

But it was hard to get it working on Ubuntu 22.04 and docker - a lot of manuals wrote different things and on top the docker-compose bundled with ubuntu (at this timepoint) was broken so that docker-compose exec … results in an error message.

A lot of trial and error solved the problems (the resulting milestones were:

  1. update docker-compose
  2. insert the credentials from local_api_credentials into docker-compose.yml otherwise it will overwrite the local_api_credentials on every restart of the container.)