Apply IP deny list from CSF due to CloudFlare


Over the past 2 or 3 years, we've seen a dramatic increase in distributed brute force attacks towards WordPress websites and DoS attacks towards xmlrpc.php files. As you may know, these attacks send several requests per second and last for a few hours and sometimes even days. This often causes the server to overload, especially when multiple websites are targeted.

We've been able to mitigate/block these attacks using ModSecurity and CSF. ModSecurity would count the number of requests and CSF would block the attacker's IP after triggering ModSecurity a few times in a row.

The problem is when an attacked website is behind CloudFlare. In this case, ModSecurity and CSF block the attackers IP by getting it from the X-Forwarded-For header, but the attackers are still able to access the web server and sites because their requests come through CloudFlare's IPs, which must be whitelisted and can bypass CSF.

I've asked CloudFlare for a solution, but unfortunately, they haven't found one.

The solution that I can think of would be to have LSWS get the IPs from csf.deny and apply them to LSWS's deny list. I'm not sure how, but I hope you can consider this as a feature request. I'm sure we're not the only ones affected by this.

Another solution would be to have LSWS watch the error_log and deny IPs that trigger ModSecurity multiple times; the same way CSF does.

I hope you understand the idea. Thank you in advance for your consideration.

Last edited:


LiteSpeed Staff
If you use mod_security "drop" action when an IP is detected, litespeed should stop serving request from that IP.
I will double check the case when the request is forwarded from front-end proxy. LSWS still need to finish reading the request header, change IP to attacker's IP, then block it.

CloudFlare need to block those IPs, and stop forwarding requests from those IPs.
Well, LSWS can figure out the user's real IP by reading the X-Forwarded-For header, but unfortunately, a firewall like CSF cannot do this, as it sees the request coming from CloudFlare and the traffic passes through.

Comodo have confirmed that their rules can be adjusted to use "drop" instead of "deny". However, I don't think we'll implement it because this would cause confusion among clients who get false positives. Many of them will think that our server is down.

The most effective solution in my option would be to add a feature to LSWS to track ModSecurity and block/deny IPs that trigger ModSecurity rules too often. I'm not sure if this is possible, though.


LiteSpeed Staff
Then what you want you do with those IP? nothing can be done at firewall level. LSWS drop will cause confusion, sending back 403 deny is the same as default action of ModSecurity.

It will only make a difference if the IP send to cloudflare and let them to block those IPs.