Allow it to be assigned to a multi system setup from the UI

[LePresidente]

Allow it to be assigned to a multi-system setup from the UI, where it doesn't have a local LAPI instead uses a central server

This would be helpful if you have multiple opnsense firewalls.

[0ranki]

This would be a nice feature. I just updated from 0.0.5 to 0.0.7 having a central LAPI server configured, and everything went smoothly, the central API still works.

To make it possible, the following would need to be configurable/doable from the UI:

• cscli lapi register -u <ip of central server>
• -no-api parameter for the rc startup command They wouldn't need to be separate options, of course, maybe just a field to enter the IP address of an external LAPI server which would trigger those config changes.

Maybe I didn't miss anything. I suspect there are quite a few users with central API servers, so this would be a good addition.

EDIT: I missed the critical part, the API key into cs-firewall-bouncer.yaml needs to be changed as well

[mmetc]

You may want to be careful with the 0.0.8 release, it will revert the configuration changes and break your setup. You can still install the 1.3.2 crowdsec package (released with 0.0.8) with the 0.0.7 plugin.

With 0.0.8, you need to re-apply your changes, then change this file: /usr/local/opnsense/scripts/OPNsense/CrowdSec/reconfigure.sh

and comment out the call to /usr/local/opnsense/scripts/OPNsense/CrowdSec/reconfigure.py

I plan to support your use case asap, in the meanwhile sorry for the inconvenience.

[mmetc]

I made https://github.com/crowdsecurity/opnsense-plugin-crowdsec/releases/tag/v0.0.9 You need to select the option to manage lapi manually, so it won't overwrite your changes.

I still have to decide how to implement remote lapi from the plugin (i.e. manage credentials or registration, etc) or at least document the procedure.

[0ranki]

I've been slightly busy, so I skipped 0.0.8 and installed 0.0.9 today.

As far as I could tell, the option to manage lapi manually had no effect, the configuration persisted through service restarts either way.

I didn't have time to test very thoroughly, but it seems that the firewall bouncer doesn't work. The ban decision was correctly sent from the central lapi server, but I still got through to my web server behind OPNSense. Will test more when I get a better chance again, might be that I misconfigured something.

For the configuration, I'd suggest a checkbox for an external lapi server, which adds the -no-api parameter to the rc script, and a field to enter the api key (which goes in the fw bouncer config file). It seems that the current fields already configure the server IP correctly in the necessary files.

I could write a draft of the docs for the manual configuration, once I can confirm that the setup actually works.

Thanks for your work on this!

EDIT: Also the cscli lapi register -u http://IP:port needs to be run

Edit2: Unrelated to this issue, but I did some more testing, and the bouncer works good. I updated OPNSense, my guess is that I should have reloaded the firewall after enabling CrowdSec.

[mmetc]

Hi, I'm back today, sorry for the delay.

The "manual lapi configuration" option means that the plugin will not overwrite my edits, I am free to change listen_uri and port after enabling the option. Not sure what you mean by "persisted through service restarts".

I did not do more because I hoped to publish the plugin with the minor opnsense release this month, now I'll target the next. Keep in mind that the plugin uses cscli, which in turn requires local_api_credentials.yaml, and if I edit that from the plugin, I need both a password for the external LAPI and a way to revert it if the user decides to keep LAPI on crowdsec after all. Also last week we added support for TLS so that's more options. I'll have to think it through when I automate that.

But you remind me of the "-no-api" parameter. I'll prepare a new version today to add custom flags to the executables.

Thanks

[0ranki]

The "manual lapi configuration" option means that the plugin will not overwrite my edits, I am free to change listen_uri and port after enabling the option. Not sure what you mean by "persisted through service restarts".

I assumed the plugin would overwrite the manual edits if the "manual lapi configuration" is not set and the agent or the bouncer is restarted, for me they were not. I might still be misunderstanding it.

Reverting back to local operation is a good point though.

[0ranki]

But you remind me of the "-no-api" parameter. I'll prepare a new version today to add custom flags to the executables.

What's the "correct" place to define flags for the executable now? I'm about to update to 0.1 this weekend and am thinking about doing a write up of the central LAPI server configuration from scratch.

[mmetc]

Hi @0ranki , I had to remove the flags option during the plugin review. Now, it's not "correct" in the sense that it's reverted if the crowdsec binary is reinstalled, but you can put them in /usr/local/etc/rc.d/crowdsec:

    ${command} -c "${crowdsec_config}" ${crowdsec_flags} [add flags here]

I'll have to come up with something to support your use case

[0ranki]

Thanks @mmetc, that's where I was putting it so far as well.

After thinking about it, I'm not sure if the integration in the plugin is necessary yet. On other platforms it is also necessary to e.g. override the systemd unit from the package manually, the steps are no more complicated on OPNSense than on Linux for example.

Perhaps if the GUI could detect that a remote LAPI server is configured, right now for me it shows that the latest connection to the LAPI server was 2 months ago, for both the agent and bouncer. I'm not yet on the latest version though.

I'll try to make a pr for documentation on the manual configuration soon, you can decide if you want to include it in.

[geekblog-dev]

I would also like to connect the Bouncer to a central instance of crowdsec. So i activated the manual lapi option and changed the bouncer.yml with the api key and api url. But anyway the bouncer connects to the opnsense instance.

So it would be nice to config the API-URL and API-KEY of the bouncer from the UI. But if not, then at least we should have an Option to allow these settings to take effect.

[mmetc]

Hi @geekblog-dev , doing what you say from the plugin is not trivial but I have updated the documentation here, it should work for you: https://docs.crowdsec.net/docs/getting_started/install_crowdsec_opnsense

Keep in mind that the plugin UI cannot list the machines and bouncers on the remote LAPI, so it shows the ones installed by default on the opnsense machine. A bit confusing I know, I'll have to change that.

Which version of the plugin are you using? By the way am going to prepare crowdsec 1.4 today.

[geekblog-dev]

@mmetc I Updated to the newest Version and followed your linked instructions now everything works just fine. Im also totaly fine with config some files in this special case.

Anyway i like to mention that in the dokumentation is written: "The following steps assume you already have set up a central LAPI server that is reachable by the OPNSense instance. You will also need SSH access with root permissions to both OPNSense and LAPI server."

And then there is directly a part where it is an HowTo setup the LAPI Server.

This is a little bit confusing, maybe just for me.

One Last Question how is it meant to be update in Version 22.1 just again "pkg upgrade os-crowdsec-devel" ?

[mmetc]

And then there is directly a part where it is an HowTo setup the LAPI Server. This is a little bit confusing, maybe just for me.

I explain how to connect to a LAPI server, not how to install it. By "reachable" I mean in the network sense. How could I reword it?

One Last Question how is it meant to be update in Version 22.1 just again "pkg upgrade os-crowdsec-devel" ?

On 22.1, you install os-crowdsec-deve. On 22.7, you install os-crowdsec or from the UI.