enhance: add allowlists support

[couloum]

What would you like to be added?

/kind enhancement

Context
Firewall bouncer is responsible for creating firewall rules (iptables, nftables or pf).

Issue
It is currently impossible to add an allowlist to prevent some IP addresses to be blocked by firewall rules.
It is also impossible to specify a TCP/UDP port on which we don't want to block any connection.

Proposition
Add support for 2 new configuration parameters:

• ignore_addresses: array of IP addresses or network ranges to be ignored by crowdsec firewall rules
• ignore_ports: array of TCP/UDP ports ports to be ignore by crowdsec firewall rules

For iptables, the bounce could create rules in CROWDSEC_CHAIN before its blocking rule, with an action RETURN if source IP address match an ip from ignore_addresses or if destination port match a port in ignore_ports.

Why is this needed?

When an IP address is present in Crowdsec CTI, it is currently impossible to not block it.
If we want to not use crowdsec for some traffic, we cannot change the firewall rules to apply to some specific ports only or to exclude some ports.
Crowdsec bouncer recreate its iptables CHAIN at every restart, so we cannot properly insert exceptions (maybe we could add a script launched by systemd after crowdsec start, but it's very hacky).

A workarround would be to use ipset mode only and create firewall rules manually. However, crowdsec creates multiple ipsets and its not possible in advance to know how many there will be.

[github-actions]

@couloum: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[github-actions]

@couloum: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.

• /kind feature
• /kind enhancement
• /kind refactoring
• /kind bug
• /kind packaging

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[couloum]

/kind enhancement

[LaurenceJJones]

It is currently impossible to add an allowlist to prevent some IP addresses to be blocked by firewall rules.

If you add a whitelist within CrowdSec then a decision will not be made on those addresses and will not end up in the firewall list:

https://docs.crowdsec.net/u/getting_started/post_installation/whitelists

If the address is classified as malicious and is given out via a blocklist then you can specify a CAPI whitelist:

https://docs.crowdsec.net/docs/next/whitelist/create_capi

So it is impossible from the firewall configuration, but not impossible from CrowdSec itself if you define the above items.

It is also impossible to specify a TCP/UDP port on which we don't want to block any connection.

Yes this is true, if the IP is malicious or in the blocklist take away from the above whitelisting issue do you want them to be able to contact any ports? there is a case where you may want them to access HTTP to get a captcha? however, you can configure a captcha remediation: https://docs.crowdsec.net/docs/next/profiles/captcha_profile

And these remediations do not get taken into effect when the firewall is processing the decisions since the remediation is captcha and not ban

If it more you never want to block these ports then you can add a postrun rule to the systemd unit of the firewall remediation (yes it is hacky workaround) EG:

[Unit]
Description=The firewall bouncer for CrowdSec
After=syslog.target network.target remote-fs.target nss-lookup.target crowdsec.service

[Service]
Type=notify
ExecStart=${BIN} -c ${CFG}/crowdsec-firewall-bouncer.yaml
ExecStartPre=${BIN} -c ${CFG}/crowdsec-firewall-bouncer.yaml -t
ExecStartPost=/bin/sleep 0.1
ExecStartPost=/bin/iptables -I INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
Restart=always
RestartSec=10
LimitNOFILE=65536
# don't send a termination signal to the children processes,
# because the iptables backend needs to run ipset multiple times to properly shutdown
KillMode=mixed

[Install]
WantedBy=multi-user.target

We wouldnt want the remediation to be the one to ignore decisions, you can configure CrowdSec to whitelist those instead so they would never end up in the LAPI decisions table.

[LaurenceJJones]

Moving issue across to remediation repository.

[github-actions]

@couloum: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Documentation to see if your issue can be self resolved.
2. You can also join our Discord

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[couloum]

If the address is classified as malicious and is given out via a blocklist then you can specify a CAPI whitelist:

Thank you for providing this as I completely missed it.

If I may, I would still argue that having a central place for whitelist would be a better UX rather than defining same IP address in multiple locations (both in the enricher and in the central API).

Yes this is true, if the IP is malicious or in the blocklist take away from the above whitelisting issue do you want them to be able to contact any ports?

We deploy crowdsec on front load balancers that receive traffic for multiple services. In our use case we want to filter everything that is HTTP/HTTPS but not SMTP as we rely on other mechanisms to block IP addresses, like RBL and other stuff. Also we want logging to be visible in our SMTP server when an IP is blocked. That's why we would like to exclude port TCP/25 from the ports being controlled by crowdsec.

If it more you never want to block these ports then you can add a postrun rule to the systemd unit of the firewall remediation (yes it is hacky workaround) EG

We'll probably do that, but I opened this enhancement request to provide a valid use-case where change in product would be nice.

[blotus]

If I may, I would still argue that having a central place for whitelist would be a better UX rather than defining same IP address in multiple locations (both in the enricher and in the central API).

We are working on this: we are going to add a dedicated allowlist feature in LAPI that will handle both content from CAPI (community blocklist and 3rd party blocklists) and local decisions, so you won't have to handle allowlists in a lot of different places.

We deploy crowdsec on front load balancers that receive traffic for multiple services. In our use case we want to filter everything that is HTTP/HTTPS but not SMTP as we rely on other mechanisms to block IP addresses, like RBL and other stuff. Also we want logging to be visible in our SMTP server when an IP is blocked. That's why we would like to exclude port TCP/25 from the ports being controlled by crowdsec.

For this situation, I'd suggest to use the ipset mode (if using iptables) or set-only mode (if using nftables) (see documentation here).
With this mode, the bouncer will only manage the content of the set itself (ie, a single set that you will have to create beforehand), and you will be able to create custom rules that will make use of it (eg, -m set --match-set my_crowdsec_set -p tcp -m tcp -m multiport --dports 80,443 -j DROP)

[couloum]

We are working on this: we are going to add a dedicated allowlist feature in LAPI that will handle both content from CAPI (community blocklist and 3rd party blocklists) and local decisions, so you won't have to handle allowlists in a lot of different places.

Good to know. I guess that answers 50% of my request, which is already good.

For this situation, I'd suggest to use the ipset mode (if using iptables) or set-only mode (if using nftables) (see documentation here).

That's true. We initially were afraid of that because we observed a change in recent crowdsec release where it created multiple ipset as all IP addresses could not fit in 1 single. And we thought we would have to identify how many ipset were used by crowdsec first. But after more tests, it seems that only 1 ipset is used when we're in ipset mode.
So, instead of using the systemd ExecStartPost, we will instead manage rules using puppet or ansible.

[blotus]

We initially were afraid of that because we observed a change in recent crowdsec release where it created multiple ipset as all IP addresses could not fit in 1 single

This change was made in order to add support for usage metrics (and here): as we need to track dropped packets or bytes per decision origin, we have to create multiple sets, it's not related to the maximum size of a set.

This change was not really documented, as we consider the way we manage the rules in managed mode to be an internal implementation detail (and we don't want people to rely on the chains/rules/sets we may or may not create), but we should probably at least mention it in the documentation.