Csf Does Not Block Attacks from Cloudflare

5 posts Page 1 of 1
marcoastriders
Junior Member
Posts: 1
Joined: 03 Jan 2017, 08:52


hello,

We are using WHM in a Dedicated Server at Hostgator, we have 50% of our domains in Cloudflare Free Plan . the Csf is been installed, and I asked Hostgator to add the "mod_cloudflare" also i whitelisted the Cloudflare ip in csf.allow. (in the server check the mod_cloudflare is green and says "OK" the apache status)

but i'm still receiving email from lfd saying that the IP where is come from the attack is cloudflare. :confused:

this is a sample of the email
Time: Tue Jan 3 01:37:46 2017 -0600
IP: 108.162.229.181 (FR/France/-)
Failures: 4 (mod_security)
Interval: 3600 seconds
Blocked: Temporary Block (IP match in csf.allow, block may not work)

Log entries:

[Tue Jan 03 00:44:20.025308 2017] [:error] [pid 4927:tid 139832997103360] [client 108.162.229.181] ModSecurity: Access denied with code 406 (phase 1). Pattern match "^Mozilla\\\\/4\\\\.0 \\\\(compatible:" at REQUEST_HEADERS:User-agent. [file "/opt/mod_security/hg_rules.conf"] [line "8"] [id "900205"] [msg "XMLRPC Request UA used in DDOS"] [hostname "painlessstopsmoking.com"] [uri "/xmlrpc.php"] [unique_id "WGtIRMYBUNUAABM-nFkAAACW"]
[Tue Jan 03 00:59:23.580885 2017] [:error] [pid 4927:tid 139833282131712] [client 108.162.229.181] ModSecurity: Access denied with code 406 (phase 1). Pattern match "^Mozilla\\\\/4\\\\.0 \\\\(compatible:" at REQUEST_HEADERS:User-agent. [file "/opt/mod_security/hg_rules.conf"] [line "8"] [id "900205"] [msg "XMLRPC Request UA used in DDOS"] [hostname "painlessstopsmoking.com"] [uri "/xmlrpc.php"] [unique_id "WGtLy8YBUNUAABM-ntoAAACC"]
[Tue Jan 03 01:26:44.549118 2017] [:error] [pid 21970:tid 139833122981632] [client 108.162.229.181] ModSecurity: Access denied with code 406 (phase 1). Pattern match "^Mozilla\\\\/4\\\\.0 \\\\(compatible:" at REQUEST_HEADERS:User-agent. [file "/opt/mod_security/hg_rules.conf"] [line "8"] [id "900205"] [msg "XMLRPC Request UA used in DDOS"] [hostname "painlessstopsmoking.com"] [uri "/xmlrpc.php"] [unique_id "WGtSNMYBUNUAAFXSfLYAAAFK"]
[Tue Jan 03 01:37:43.406692 2017] [:error] [pid 21970:tid 139832976123648] [client 108.162.229.181] ModSecurity: Access denied with code 406 (phase 1). Pattern match "^Mozilla\\\\/4\\\\.0 \\\\(compatible:" at REQUEST_HEADERS:User-agent. [file "/opt/mod_security/hg_rules.conf"] [line "8"] [id "900205"] [msg "XMLRPC Request UA used in DDOS"] [hostname "painlessstopsmoking.com"] [uri "/xmlrpc.php"] [unique_id "WGtUx8YBUNUAAFXSfowAAAFY"]
It says "(IP match in csf.allow, block may not work)"

I used to receive 5-10 attacks daily with this kind of issue

so what should I do in order to resolve this issue? it's a CSF issue? a bug? :confused:

Thanks For The Help! :)
postcd
Junior Member
Posts: 45
Joined: 15 May 2014, 17:10


> IP match in csf.allow, block may not work
does this mean that you have that IP listed in /etc/csf/csf.allow ?
Also i am a noob, but isn"t possible that CSF blocking 403 and not 406 ?
aww+
Junior Member
Posts: 105
Joined: 27 Aug 2012, 20:53


I'm just another CSF user but I can answer this question for you because I am dealing with the same problem and understand what is happening

basically CSF/LFD just sets up the linux iptables firewall, which normally can only inspect the true, native incoming IP address

in this case the incoming ip address is cloudflare

cloudflare adds HTTP headers to the incoming request to reflect the original (bad, banned) IP address but iptables is completely ignorant of that because it cannot inspect or decode that secondary address which is buried in the HTTP headers

so it is impossible for CSF/LFD to solve this without adding deeper packet inspection - while someone might come up with a way to do that, even then HTTPS encrypted requests can NEVER be caught that way and of course this adds overhead to every inbound request

the bad IP can only be caught by the next layer, your web server software, typically apache or nginx, once it fully decodes the request and inspects the headers (another option is the third layer of the PHP or Perl application)

so unfortunately this is out of the hands of CSF

it's not just cloudflare, any 3rd party reverse proxy would have this issue

cloudflare does offer a free firewall of it's own where individual ip addresses or /24 /16 blocks can be banned from being forwarded to your server but of course this is not automated unless someone comes up with an addon to use the cloudflare API to do this

I've made a suggested feature request for CSF/LFD to use that cloudflare API and synchronize the temporary bans that CSF/LFD makes with cloudflare's firewall but I cannot imagine such a feature would be a priority, as popular as cloudflare is
postcd
Junior Member
Posts: 45
Joined: 15 May 2014, 17:10


25 Sep 2017, 16:41aww+ wrote:
the bad IP can only be caught by the next layer, your web server software, typically apache or nginx, once it fully decodes the request and inspects the headers (another option is the third layer of the PHP or Perl application)
so unfortunately this is out of the hands of CSF
Apache module "mod_cloudflare" (https://www.cloudflare.com/technical-re ... cloudflare) will make the "bad IPs" hidding behind cloudflare to appear in the apache error/access logs i assume. And the CSF is watching error_log so it can ban this bad IP, so i assume when this happen, the bad visitor/bot will be unable to view the web page or i am wrong?
aww+
Junior Member
Posts: 105
Joined: 27 Aug 2012, 20:53


25 Sep 2017, 20:38postcd wrote:
Apache module "mod_cloudflare" (https://www.cloudflare.com/technical-re ... cloudflare) will make the "bad IPs" hidding behind cloudflare to appear in the apache error/access logs i assume. And the CSF is watching error_log so it can ban this bad IP, so i assume when this happen, the bad visitor/bot will be unable to view the web page or i am wrong?
unfortunately you are wrong - here's why - sure LFD can be setup to monitor the log, and it can even add the rule to iptables to ban the bad IP

except the bad IP is not the one coming into the server, it's cloudflare's IP, so it marches right through the iptables

mod_cloudflare can change the IP at the next *webserver* layer, which is another layer AFTER iptables (the topmost one that CSD/LFD controls) - mod_cloudflare inspects the HTTP headers from the request, where cloudflare adds a reference to the original (bad) IP - CSF/LFD itself cannot decode and "see" that http header

so it's too late then because the request is already in the server

layers:
1 iptables (controlled by CSF/LFD) - ip ends up banned here but ip is never seen here
2 webserver (apache with mod_cloudflare) - ip is changed here and added to CSF but too late
3 php or perl, etc.

apache would need it's own IP ban list, which can be done by htaccess and httpd.conf but that is never controlled by CSF/LFD

however it MIGHT be not too hard to make some kind of include file for httpd.conf that adds the csf.tempban file via RewriteMap https://stackoverflow.com/questions/130 ... g-htaccess

that does not exist yet though, it would have to be a feature request
5 posts Page 1 of 1