Hello Traefik Community!
I've been using Traefik v2 for some time now for some small personal sites hosting wordpress.
I have a middleware rule that IP restricts /wp-admin /wp-login.php and /xmlrpc.php
Recently I discovered if someone requests //xmlrpc.php or //////xmlrpc.php it works and completely ignores my middleware. I removed the xmlrpc.php file completely from my wordpress installation and that fixed that but now they are hitting /////wp-login.php. Traefik doesnt seem to care how many foward slashes /// are in the url. If it is not exactly /wp-login.php, it lets it through.
Not sure if this is a bug, but is there a way to fix it?
My wordpress installation is screaming with bots and all sorts of stuff trying to get past my login page.
Share your full Traefik static and dynamic config, and docker-compose.yml if used.
Use PathPrefix() because Path() only works for exact matches, and for sure there are sub-paths (URLs) to the admin site.
I think that it doesn’t matter if some ////wp-admin request gets through, as long as Traefik and Wordpress are configured correctly.
Of course the Wordpress web server should not respond with the regular login page, but a 404 "Not found". Check your access log.
If it does respond with the login page, then the web server needs to be configured correctly, but that’s not something Traefik can fix.
Of course you can just use a Traefik path regex as workaround, but that would not fix the mis-configuration in the Wordpress web server. And it might have side effects, for example when some media has the string in its name.
After writing my "me too" I spent a bunch of time on this yesterday and I think I finally got it figured out. There were a couple of things going on:
First, my NGINX configuration was copy/pasted from a Wordpress Multisite (site I'm currently working on is a single site) and had the following code that I think was responsible for redirecting from //xmlrpc to /xmlrpc, which in this case I removed:
But that wasn't quite what I wanted, I wanted Traefik to not even pass anything through to those routes so I can apply this to similar Wordpress Multisite sites.
This rule would indeed catch something with $DOMAIN/wp-admin, but only with exactly those routes, letting anything with a more complicated path through. Solution ended up being a REGEX path - REGEX is most definitely NOT my strong area, so had to do a lot of futzing around to get something that worked. But for reference and anyone else that might be struggling with a similar issue, here's what seems to be working for me:
I now get "Forbidden" when I try to access xmlrpc.php, wp-login.php or wp-admin from none whitelisted IPs. And this morning when I check my logs there are no global hackers trying to connect. Will continue to monitor to see if they find another way around these rules.