Pages Rules issue relating to port 443


#1

I have set up Page Rules to redirect anyone visiting /wp-login.php to the UK nationalcrimeagency
This works great except for 1 issue I cannot fathom:

I have my Page Rule set like this (wildcard, to include all subdomains) *website.com/wp-login.php (not my actual website url).

And it redirects 90% of visits, but I still see occasionally login attempts in the log, when I block that IP directly in the Firewall and then view the Firewall Events when that IP attempts to visit it shows my website like this in the Event log: www do website.com:443

Is there some get around in relation to Page Rules, do I need to specify this specific port in the Page Rules (even though it IS redirecting https requests “as is” already)

Really kind of stumped by this as http attempts that are Firewall blocked do NOT show :80 in the Firewall Events and 90% of https attempts dont either, its is just “some login attempts” that seem to be able to get through and result in this :443 suffix being added to the end of the URL in the Firewall Events.

Looking forward to some help with this

Thanks in advance


#2
  1. Can you post the Match you’re using in the Page Rule? Feel free to edit it to be example.com instead of your actual domain.
  2. Do you have a way of finding out from your logs if that request is bypassing Cloudflare? Some bots might be targeting by IP address and hostname to get around Cloudflare.
  3. NCA might not take too kindly to redirects from your site, though it might be such a small blip they won’t notice.

#3
  1. I already have in the first post but here it is again: *example.com/wp-login.php (unless you mean something else)
  2. It is not bypassing CloudFlare, this is easy to ascertain as when I add the IP to my Firewall directly it blocks the login attempts. Therefore it is hitting the URL and not the IP or adding the Firewall Rule would have no impact and I would still see the login attempts…
  3. I have spoken directly to the NCA and they are happy to have this kind of traffic redirected to them.

#4

Try matching *example.com/wp-login.php* just in case passing args (e.g. ?blah=yaddayadda) causes the rule’s pattern match to fail - I can’t remember if this is the case or not with page rules.

And just to clarify the point RE firewall and blocking traffic circumventing Cloudflare, on the firewall on your backend (i.e. directly in front of your web host, not at Cloudflare) block all bar the Cloudflare IP address ranges: https://www.cloudflare.com/ips/ (and maybe add in the IP of any machines you test from too if you like).

If you want to go the extra mile, then maybe ensure that your site is set up to only display on your hostname (‘virtual host’ directive in Apache, say) and have a dummy site shown on access without the correct hostname.


#5
  1. Good shout on the /wp-login.php* have applied that now (but that is not what I am seeing in my tail og, it is the direct /wp-login.php url that is getting hit.
  2. Already set this.
  3. I’ll look into this.

Appreciate the help. Would be good to get some kind of idea what is happening here instead of trying to “patch it” as such. Do any CloudFlare staff reply here?


#6

I had similar redirect setup years ago and it seems to deter some but if you what to be done with it and just block all bad actors from the back-end, just create a free firewall rule like the one below using your IP or AS number if you want to allow all IP’s from yor ISP.

(http.request.uri.path contains “/wp-admin” and http.request.uri.path contains “/wp-login” and ip.src ne 192.168.1.1)