1

I'm running a wordpress install on nginx, and I'm looking at novel ways of securing wp-admin. I know theres more than one way to do this (e.g. adding an http basic auth layer, login lockdown, 2FA, etc.) but I want to try and make it to where wp-admin can only be access via localhost. Here is the location directive I want to configure with nginx:

#deny access to wordpress admin functions except from trusted networks/hosts
location /wp-admin {
    try_files $uri $uri/ =404;
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        fastcgi_param HTTPS on;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_intercept_errors on;
    }
            allow 127.0.0.1
            deny all;
}

The long and short of it is "only allow localhost to access this directory, and make sure that PHP files get processed by PHP via fastCGI."

So I use SSH to create a dynamic tunnel to my web server VM, and create a dynamic SSH tunnel. I then configure my web browser to use this dynamic tunnel, and point my web browser to https://127.0.0.1

Like most SOCKS5 proxies, this actually works, but the problem I run into is that as soon as I try to access https://127.0.0.1/wp-admin, I immediately get redirected to https://$site_url/wp-login.php

Not a big deal. I can get around this by just going to https://127.0.0.1/wp-login.php and logging in there directly. The problem I run into after THAT is that https://127.0.0.1/wp-login.php appears to be redirecting to https://$site_url/wp-admin.php

This immediately throws a 403 error. and when I attempt to manually point my web browser back to 127.0.0.1/wp-admin, I get redirected to https://$site_url/wp-login.php?redirect_to=https%3A%2F%2F127.0.0.1%2Fwp-admin%2F&reauth=1

I noticed the redirect_to parameter, but its not redirecting back to localhost.

My question is "Is there a way to disable redirects to the site URL?"

  • Would it not be easier to adjust the redirects to point to the 127.0.0.1 address instead? Then they'd be functional. Additionally, there should be no need for 127.0.0.1 in the URL, just change the hosts file so it knows that yoursite.com resolves to 127.0.0.1 and write code that verifies the user is indeed proxied. Lots of production live sites use proxies for their backends without resorting to this – Tom J Nowell Aug 29 at 18:29
  • Well, you'd think that was solution, but for reasons entirely beyond my comprehension, modern web browsers don't ever actually use /etc/hosts, at least on windows 10. I can easily confirm that other system commands use /etc/hosts for resolution, but firefox apparently doesn't. And yes, I've confirmed that DNS over HTTPS is disabled. Not only that, the SITE_URL setting is still redirecting it. – da667 Aug 29 at 19:08
  • i meant on the server itself, there's no reason your browser should be aware of anything other than it needs to proxy all traffic for your sites domain, as long as you have the appropriate authentication setup on your proxy, all you need to do is wp_die if is_admin or is_login are true if the user isn't proxied. No need for Nginx changes, no need for custom URLs or disabled redirects, etc Just make your proxy pass the traffic through as is but add a header with a secret value to check against – Tom J Nowell Aug 29 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.