Skip to content

Conversation

@stevenandres
Copy link

It's quite common to have a cron task running on the webserver to trigger database cleanup tasks. By adding localhost (127.0.0.1 and ::1) to the allowed proxy list, we can use cron tasks aimed at localhost instead of making the external long-way-around-the-world request out to Cloudflare and then back into our web server.

It's quite common to have a cron task running on the webserver to trigger database cleanup tasks. By adding localhost (127.0.0.1 and ::1) to the allowed proxy list, we can use cron tasks aimed at localhost instead of making the external long-way-around-the-world request out to Cloudflare and then back into our web server.
@benjojo
Copy link
Contributor

benjojo commented Dec 12, 2015

I assume the reason for this is that you are using DenyAllButCloudFlare and that is causing issues with your cron jobs?

@stevenandres
Copy link
Author

Correct -- Sorry for not mentioning that crucial data point. This is because DenyAllButCloudFlare is denying connections from cron to https://localhost

@benjojo
Copy link
Contributor

benjojo commented Mar 11, 2016

@ejcx @dfritsch (sorry to bother) I'm trying to figure out if this has any downsides attached to it.

I fear that people will setup internal proxies or something on the same server and possibly cause real world requests to arrive at apache as a local IP.

The question is, should that be accepted as a thing that someone can shoot themselfs in the foot with?

On the other hand DenyAllButCloudFlare is an advanced option, a user has to read the manual and change their apache config to make this feature work.

This will also grant localhost to "spoof" the IP of the incoming, another possible issue

@IcyApril
Copy link
Contributor

Purely from the implementation perspective; not sure we should be adding localhost to a list of trusted proxies; effectively we'd also be allowing IP rewriting from localhost. We are effectively allowing remote IP and SSL header rewriting from requests from localhost. If we go down this route, the logic should purely apply to the denial element (though this of course doesn't address the internal reverse proxying issue described above).

Kinda off topic, but there are a lot of ways people can shoot themselves in the foot by running a curl request in their cronjobs. Ideally you should reference the PHP/application binary and run the script directly. The cron script should really be outside anything accessible by the web server.

@ttsak
Copy link

ttsak commented Apr 16, 2017

Please consider this scenario.
(it is based on this pull request but goes a little further).
You have a backend server for a website behind cloudflare.
You want to allow incoming http requests that pass through cloudflare.
You also want to allow some direct requests both from localhost and from some other servers you control (for api usage, etc).
And you want to deny everything else!
You can do this without the cloudflare module by allowing cloudflare IPs as well as the IPs of your other servers.
But if you use cloudflare module then you either have to allow everything or allow only cloudflare servers by using "DenyAllButCloudFlare".
I have tried adding my other server IPs on the "CloudFlareRemoteIPTrustedProxy" but it didn't work for some reason.
If there was some way to do this using "CloudFlareRemoteIPTrustedProxy" then this pull request might not be needed at all (anyone requiring access from localhost could just add localhost to the list of cloudflare IPs)
Any ideas?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants