Layer 7 WAF with IPDB: Auto-Block Real IPs Behind Cloudflare & Akamai

cPFence

We're rolling out one of our most powerful updates yet: next-gen Layer 7 WAF with IPDB protection for proxied traffic. Attackers hiding behind Cloudflare, Akamai, Fastly, or Nginx? Not anymore. Our latest update exposes the real source IP—even through multiple proxy layers—and blocks them instantly on auto-pilot. No More Hiding Behind Proxies This update introduces a proxy-aware WAF module that …

This content is hidden. Log in to view the full discussion.

unlip

Even after blacklisting the IP addresses, a website using a Cloudflare proxy continued to suffer attacks. The same type of attacks from different IP addresses simultaneously. I blacklisted all the IP addresses and waited, but it didn't work.

I don't know if there's anything that can be optimized, but I'll leave the log here for possible investigation and improvement.

cPFence

unlip

It’s normal to see some IPs slip through because LiteSpeed Cache is very aggressive, attackers can still hit cached pages, which means they don’t always get intercepted right away. That’s why we added the “skip caching for login page” feature, so the captcha WAF protection kicks in instead of just serving a cached wp login.

If you check your WAF logs, you’ll see a large number of IPs already being blocked at layer 7. But no solution is 100% bulletproof with caching in place. WAF doesn’t play well with LiteSpeed caching, that’s a ModSecurity limitation that can’t really be avoided.

unlip

The attack is directed at random pages that do not exist.

They return a 404 error, overloading the web server.

Even after restarting LiteSpeed, the IP address was still accessible.

cPFence

unlip

Restarting LiteSpeed is irrelevant, it won’t fix this issue. As long as you use caching or Cloudflare proxies, you’ll always see these types of attacks. This is not a cPFence limitation; it applies to all security products.

The right way to stop it is at Cloudflare. Create a Custom Rule, go to Edit expression, and use:

(not cf.client.bot and not ip.src.country in {"UAE"})

Set the action to Managed Challenge and save.

Replace UAE with your client’s country. This ensures real visitors from that country and important bots get through, while most of the junk traffic is blocked at Cloudflare before it ever reaches your server.

unlip

cPFence

I had previously blocked it directly through CloudFlare.

The problem is that, in a mass attack targeting multiple domains, it's nearly impossible to manually adjust this for each domain on the server.

And this type of attack goes through CloudFlare without any issues, requiring manual action individually, which is quite complicated.

Thanks for the clarification.

cPFence

unlip

The rule above is a set-and-forget solution and can be tweaked if needed.