nixos/crowdsec-firewall-bouncer: init module

[nicomem]

Fixes #358457

Initialize a module for configuring the CrowdSec Firewall Bouncer, fetching decisions from a CrowdSec API and applying them to the configured firewall.

This module defaults to a configuration that connects to the services.crowdsec local API such that a configuration like:

{
  services.crowdsec-firewall-bouncer.enable = true;
}

would work as intended, but should be configurable enough that it can support other types of configuration (e.g. leaving the user manage the rulesets itself, connect to an external CrowdSec API, etc.).

The module requires the user to manually register the bouncer to get the API key before enabling this module.
It may be possible to create another service that does this work automatically but this is not simple to do in a robust way and would not work when using an external CrowdSec API.
There is now an option (enabled by default if config.services.crowdsec.enable is set) to automatically register to the locally running crowdsec service, allowing for a no-manual-intervention setup.
This options is optional and the module still allows for other use-cases (e.g. specify an api_key to connect to an external CrowdSec API).

I have tested the nftables mode, both with the module creating the rulesets (set-only = true), or leaving the bouncer creating and updating them (set-only = false).
In both cases, the bouncer manages to create/update the appropriate nftables elements to block the IPs based on the current CrowdSec decisions.

I have not tested the iptables mode, where the bouncer will automatically create the ruleset for the iptables firewall. If one is able to test this case, I would be thankful.
I also did not write the creation of the ruleset for the iptables firewall as I was not too familiar on this topic.
-> Thus, I added an assertion when the user has set the ipset mode (the bouncer expects the ruleset to be created) and the create_rulesets option is left enabled.

I've only added myself as a maintainer but if others such as the crowdsec module maintainers want to also be added to this module, let me know and I will add you.

Upstream documentation and interesting files:

• Documentation
• Upstream systemd service file
• Upstream default config

Pinging the maintainers of the crowdsec module: @M0ustach3 @TornaxO7 @06kellyjac

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[nicomem]

On second thought, the bouncer could be automatically registered to the locally running crowdsec service in a similar way as the crowdsec-setup of the crowdsec module.
-> This could also potentially allow adding module tests as it would no longer require manual intervention

Converting the PR to draft while I'm working on this

[nicomem]

I added an option to automatically register the bouncer to the locally running CrowdSec service (enabled by default if config.services.crowdsec.enable is set).

I changed the naming of options from kebab-case to camelCase as it seems to be the most commonly used casing for modules options.

I tried to add module tests but I got stuck at the crowdsec-setup script trying to download from the hub, failing to do so, and thus making the service not start...
As this would require non-trivial work to be done on the crowdsec module, tests could be added at a later date once this problem has been fixed.