Custom Bouncer + Firewalld - Questions

I’ve got the system up and running, and am using the the custom bouncer as my system (Debian 11) is using firewalld. I’ve written a script for the bouncer that successfully adds IPs to an ipset in the drop zone of firewalld.

I’m using firewalld to add to the ipset due to loss of ‘state’ between firewalld and ipset if one adds/removes to the set via the ipset command manually. I’m also issuing a firewalld reload as part of the script.

I’ve got the following collections enabled, and am also using a custom parser for a zoneminder log (web_php). All seem to be working fine.

 NAME                               📦 STATUS   VERSION  LOCAL PATH                                         
 crowdsecurity/haproxy              ✔️  enabled  0.1      /etc/crowdsec/collections/haproxy.yaml             
 crowdsecurity/base-http-scenarios  ✔️  enabled  0.5      /etc/crowdsec/collections/base-http-scenarios.yaml 
 crowdsecurity/apache2              ✔️  enabled  0.1      /etc/crowdsec/collections/apache2.yaml             
 crowdsecurity/linux                ✔️  enabled  0.2      /etc/crowdsec/collections/linux.yaml               
 crowdsecurity/sshd                 ✔️  enabled  0.2      /etc/crowdsec/collections/sshd.yaml                

The thing I’ve noticed is that the crowd-sourced IPs that are being blocked – which is obviously data I want – is being fed to the custom bouncer one by one. Is this how it should be working? If so, what is the rate of the blocked IPs coming in? Or is there a larger list that could be front-loaded first, and then only use the incoming IPs after that?

I’ve noticed it’s inducing some load and am concerned about this as it will be running on a vps w/ a low amount of horsepower.

Thanks in advance

Hi, that’s the main issue with the custom bouncer.
The best way to manage that is to write your own bouncer, it’s easy to do that if you know how to make some GET on the LAPI with startup=true or false.

See here : Swagger UI

/v1/decisions/stream?startup=true to get all decisions.
/v1/decisions/stream?startup=false to get the new decisions since the last GET.

Ah, gotcha. Much appreciated for the swagger link – hadn’t seen that before, and will make things easier.

And pulling from the LAPI will allow me to customize handling ‘immediate’ blocks vs. those that can be queued.

Part of the issue is firewalld itself - when doing the firewall-cmd --reload – there is 1) a bug that causes the first reload to fail (still researching this), and 2) a noticeable pause in communication while the reload happens.