What's the correct way to block non-Cloudflare traffic now that their IPs are trusted by default?

R

roy

Member
#1
#1
I read that as of v5.4.9, Cf's IPs are trusted by default, so how do I block traffic that doesn't come from them?

In .htaccess, I've tried this:
Apache config: 
Require all denied
Require ip 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
and this:
Apache config: 
Order Allow,Deny
Allow from 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
I've also tried both wrapped in a <RequireAny> tag.

Also tried the Access Control lists in the config manager GUI, even though you advise not to. It kills the whole site because every request gets a 403 response, but I can see in my browser's dev tools that the request is definitely going through Cloudflare. It's behaving as though Litespeed trusts Cloudflare, thus sets the remote address of the request to my real IP (based on the header Cloudflare sets) but then that real IP doesn't match the Cf IP ranges I've set, so the request is blocked.

If it's not as I suspect, then why is this simple Require ip rule failing? I've also tried it without the Require all denied which doesn't get denied through Cf, but nor is it denied when I force a direct request to the server from the command line using cURL, e.g.:
Bash: 
curl --resolve myhost.example:443:11.22.33.44 https://myhost.example/real-page --dump-header - | less
I get 200.

The normal rules are blocking either everything or nothing at all, so how do I limit traffic to only that which comes from Cloudflare?
 
R

roy

Member
#4
#4
@serpent_driver Thanks but I can't block traffic at the server level, that would mean other sites on the server are all forced to used Cloudflare as a proxy, which isn't going to happen. I know how to use firewalls and iptables/ufw work just fine for simple IP access lists.

This is something that LSWS should be able to handle.
 
R

roy

Member
#6
#6
@serpent_driver Please stop recommending tools that are massive overkill for a basic, Apache-compatible directive. I'm not converting an entire server to cPanel just to implement a single directive on one site.
 
R

roy

Member
#7
#7
I compared the environment of proxied and non-proxied requests with a line of PHP. It is as I suspected, Litespeed sets the REMOTE_ADDR env var to my real IP, and PROXY_REMOTE_ADDR to Cloudflare's origin. I didn't expect this as I hadn't set Use Client IP in Header in Litespeed's config manager, it doesn't specify a default in its help tooltip, and editing it selects No by default. Its default must be Trusted IP Only.

If I set it to "No" everything goes back to normal, but that means I'd have to maintain that list of trusted IPs myself rather than rely on Litespeed's internal version. Instead, I explicitly set that option to Trusted IP Only, then tried this:
Apache config: 
Require env PROXY_REMOTE_ADDR
It's supposed to have been supported since v5.4.2 but it didn't work, direct requests were allowed through. What worked was this:
Apache config: 
RewriteCond %{ENV:PROXY_REMOTE_ADDR} ^$
# allow loopback addresses
RewriteCond %{REMOTE_ADDR} !^127\.
# this should work but lsws bug gives bad value in SERVER_ADDR
RewriteCond %{REMOTE_ADDR},%{SERVER_ADDR} !^([^,]++),\1$
# instead you have exclude by literal IP
RewriteCond %{REMOTE_ADDR} !=123.123.123.123
RewriteRule ^ - [NS,R=403]
Uglier, but should do the job since it doesn't use (forgeable) HTTP headers.

I imagine that backwards-incompatible change to remote IP handling would have broken a number of sites' configurations, and Require env doesn't seem reliable, so it would be good if staff addressed those issues.
 
Last edited:
You must log in or register to reply here.
Top