Firewall won't block IP

F

Freddy

Verified User
Joined
Apr 14, 2016
Messages
142
I am loosing my mind over here. I have an abusive IP that I need to block. I use CSF and added the IP to the deny list. I can search for the IP and see that it's added in the firewall, but it still posts requests to my website. I dropped all IP's from the deny list except this one for testing, but no luck. I also switched from my default using IPSET to non-IPSET and the firewall rules clearly show the IP in the denyin chain, but it still gets through!!! How on earth?!! I checked the allow list to see if the IP was also listed there but it wasn't.

I have been using CSF for years and I have never seen this. I double checked for typos multiple times. I just copy the IP from my access logs so typos are practically impossible. So what is going on here? I could use any bump in the right direction. I am probably doing something very wrong but I can't seem to figure out what it is.
 
Yes, multiple times. Changing a configuration without restarting won't do much. It's currently on IPSET again. When I search for the IP it returns this message.

Code: 
Table  Chain            num   pkts bytes target     prot opt in     out     source               destination         
No matches found for <XX.XX.XX.XX> in iptables

IPSET: Set:chain_DENY Match:<XX.XX.XX.XX> Setting: File:/etc/csf/csf.deny

ip6tables:

Table  Chain            num   pkts bytes target     prot opt in     out     source               destination         
No matches found for <XX.XX.XX.XX> in ip6tables

csf.deny: <XX.XX.XX.XX> # Manually denied: <XX.XX.XX.XX> (DE/Germany/-) - Wed Sep  2 12:02:29 2026

I masked the actual IP for privacy. The IP should have been blocked since 12:02 and the access logs show these request.

Code: 
<XX.XX.XX.XX> - - [02/Sep/2026:13:05:33 +0200] "POST / HTTP/1.1" 200 33417 "https://mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36"
<XX.XX.XX.XX> - - [02/Sep/2026:13:05:35 +0200] "POST / HTTP/1.1" 200 29753 "https://mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36"
<XX.XX.XX.XX> - - [02/Sep/2026:13:05:35 +0200] "POST / HTTP/1.1" 200 34186 "https://mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36"
<XX.XX.XX.XX> - - [02/Sep/2026:13:05:37 +0200] "POST / HTTP/1.1" 200 28918 "https://mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36"
<XX.XX.XX.XX> - - [02/Sep/2026:13:05:38 +0200] "POST / HTTP/1.1" 200 34185 "https://mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36"
 
Strange, we experience exactly the same with certain ipv6 addresses. They show up in the csf.deny file and in the Block List in BFM. In the Failed Logins: IP List (BFM tab) we can block any ip-address but with certain ipv6 addresses the Blocked column Yes/No field does not change into Yes and the addresses are still able to access the server although they are added into csf.deny and the Block List in BFM.
 
Ohm J said:
behind cloudflare ?
Click to expand...
Yes! You are onto something.
Cloudflare proxies don't work with CSF I guess? Because the incoming connection is from a different IP of course. So stupid not to notice this. I don't use Cloudflare very often.

Is there any way to block IP's with CSF for domains that use the Cloudflare proxy?
 
Welcome to the CloudFlare conundrum.

When you add the mod_remoteip stuff into Apache (or equivalent for whatever web server you are using) - your webserver will report the CF-Connecting-IP as the remote IP. This is so your logs look correct.

But the actual connecting IP is CloudFlare's IP.

CSF (iptables/nftables) works at layers 3/4 of the OSI model. Your webserver is operating at layer 7. Layers 3 and 4 refer to the actual connecting IP - this is ideally where you want to block IPs because it prevents further processing of the malicious activity. When the packet gets to Layer 7, it's completed the full OSI model. You can block it in your webserver, but your server's already done significant processing of the packet.

One would think that if an IP is flooding your server that CloudFlare would stop it. But it doesn't. Maybe if you pay them big money for their higher tiered plans. But on the free plan, it doesn't do anything. It may give you some tools to block this - you may be able to log into your CloudFlare panel and block it, but you have to know to do that.

This is where CloudFlare becomes a major headache for server administrators.

Most end users (not bashing, just stating facts) are not technical savvy enough to monitor and adjust their CloudFlare settings when abuse happens on their website. But when a website is using CloudFlare it removes all control from server administrators (which probably describes most of us here on the DirectAdmin forums) to manage that abuse.

If a server administrator uses the mod_remoteip declarations to rewrite CloudFlare IPs to the CF-Connecting-IP defined IP and a website using CloudFlare starts getting hammered with brute force WordPress login attempts. Then if their CSF or iptables/nftables setup tries to block that IP for abuse... the abuse just keeps on happening. Because CSF has blocked an IP address that isn't really connecting to the server.

The only solution server administrators have is to remove the mod_remoteip declarations. That means website logs show the CloudFlare connecting IP instead of the CF-Connecting-IP IP, but it makes blocking IPs with iptables/nftables manageable.

The sucky part is though... if another website on the same server is using CloudFlare and they are not being attacked... they may eventually get blocked too, because the one website that is getting hammered with WordPress brute force attempts is eventually going to run through all of the CloudFlare IPs (maybe?) and that will prevent all CloudFlare sources from connecting to your server. But if you ask me... that's the price you pay for using CloudFlare.

Bottom line... don't use CloudFlare.

Unless you are a server administrator managing your own websites on your own server and you understand how to monitor and adjust your CloudFlare settings, CloudFlare in a shared hosting environment can be a nightmare.
 
You must log in or register to reply here.
Back
Top