I actually think it’s the exact opposite.
Cloudflare set up correctly means enabling the proxy function for DNS entries, which leads to the server receiving the requests from Cloudflare server IPs. Therefore we are not able to detect the “real” IP of the visitor.
Therefore the only way to really identify the visitor is by looking at the CF-Connecting-IP
header which will always show the real IP of the user in case he came through Cloudflare. Of course usually we are able to fake HTTP headers but I’m pretty sure Cloudflare overwrites the header for stuff like CF-Connecting-IP
in order to ensure that there is always a way to identify the real IP of the visitor for further processing (e.g. for security purposes).
In combination with a block of any port 80/443 connection outside of whitelisted Cloudflare IP ranges (https://www.cloudflare.com/ips/) would make the visitor have to go through Cloudflare which would then ensure that the above mentioned header is always present which would make this the most efficient way to block attacks in my opinion.
There might be a mistake in my thoughts or I forgot something but right now this is how I think it is.
In conclusion for the plugin this would mean that there should be a check if the request comes from a Cloudflare IP and if so: It should use the above mentioned header for identifying the client and potentially blocking any request from a Cloudflare IP that has the same IP in the header. If the request comes from outside the Cloudflare network, it should keep working in the same way it does now.
-
This reply was modified 1 year, 9 months ago by
devopa.