Firewall/Rampart is not blocking/dropping connections

Bug Report Template

Description

I have 2 IP’s in the blacklist which is not getting dropped (total blacklist contains 149 IPs and few /22 blocks)

I am using this cmd: cpcmd rampart:blacklist 47.76.99.127

Just for verification i tried: firewall-cmd --ipset=blacklist --add-entry=47.76.99.127 - Result: Warning: ALREADY_ENABLED: '47.76.99.127' already is in 'blacklist' - Same goes for the other IP.

When checking accesslog for my clients, i still see those 2 IPs trying to hit multiple URLs with response 200.
I was not expecting them to reach the log, due to rampart blocking is a DROP. Somehow they slips trough without any kind of filtering.

They are not overlapping any CIDR block as well. Just 2 individual IPs.


revision: b92d438d47999dc54a0deb7c27d10d84a92b6d96
timestamp: 1736887634
ver_maj: 3
ver_min: 2
ver_patch: 0
ver_pre: b92d438d4
dirty: false
debug: false

4.18.0-553.34.1.el8_10.x86_64

Is that site behind Cloudflare? Server is blocking the direct IP but not the Cloudflare proxied request, which appears directly in the access_log.

I realized the client did activate the CF proxy yesterday - so yes, you are spot on. Well it means CF is not blocking/filtering the request (bot attack) but just forwarding it to my server. So either i have to remove proxy and let my server drop it, or make the rule in CF. Right ?

Correct. Ideally if Cloudflare is in front providing DDoS deterrence it should be handling this rather than passing it through.

When the server performs a block, it sends a SOCK_DESTROY command over netlink, so these connections matching the offender’s IP will be immediately closed. Trouble with blocking upstream in Cloudflare is that the blocks applied to its API are per-account, so you would need to know your client’s Cloudflare credentials. In single-role setups where all domains on the server are managed by Cloudflare this is possible but infeasible on multi-tenant installs.

1 Like