Whitelist iPhone/office computer IP address to access wordpress login page, deny any other ip address

[Francis Daly]

On Tue, Nov 09, 2021 at 02:32:48PM -0500, Danran wrote:

Hi there,

> 1. NOW, What I want to do, is to whitelist the ip address of my phone (and
> my office computer at work), so that I can access the wordpress login page
> from my phone's IP address and/or my office computer, while still blocking
> any other outside internet traffic. To do so I go to www.whatsmyip.org on my
> phone, copy the ip address that it gives me, then modify the previous
> directive to look like the following:
> 
> server {
> # Allow local only to wp-login page
> location ~ /wp-login.php {
> allow my_phones_ip_address_as_shown_on_whatsmyip.org;
> allow 192.168.1.0/24;
> deny all;
> error_page 403 =444;
> include snippets/fastcgi-php.conf;
> fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
> fastcgi_split_path_info ^(.+\.php)(/.+)$;
> 
> HOWEVER, after reloading nginx, I still cannot access the wp-login
> (wordpress login) page from my phone.

The above config looks like it should work to allow the request.

What does your nginx log say?

What IP address was rejected by nginx, when your phone made the request to it?

(And if there are too many requests around the same time so that you
can't easily identify the one from your phone, perhaps add something
unique like ?testing=123 so you can find that in the logs.)

My guess is that your phone is either caching things so that the request
does not get to nginx at all; or that your phone's effective IP address
is changing between requests, so that you might want to allow a range of
addresses in that will include the next one your phone is likely to have.

But by looking at the logs, you don't need to guess.


> 2. What I also want to do, is for nginx to completely drop any connection
> that tries to access my wp-login page, instead of giving multiple redirects
> with "error_page 403 =444". I could not find any other way for nginx to
> completely drop the connection to the page if accessed from an outside
> source, and using the "error_page 403 =444" stanza was the closes workaround
> that I could find on the internet. Could someone please advise me on how to
> force nginx to completely drop any connection so it looks like the page
> doesn't exist when accessing it, instead of giving an error message? In
> other words, is there something I can use to replace "error_page 403 =444"
> with a directive that will make the page the user is trying to access
> non-existent?

If the user tried to access a non-existent page, they would probably
get a 404 response, not a closed connection, no?

At this point in the request, the user has already successfully negotiated
a SSL session; so they have a tcp connection and they have your server's
certificate -- they know the server is there. You sending them a different
response for /admin/wp-login.php compared with /admin/random-string is
going to show them that /admin/wp-login.php *is* special, if they can
just find the way in.

(Note - it is sensible to not want to expend any more resources on them,
so just closing the connection instead of giving them a useful http
response is not unreasonable. Just so long as you know why you are
doing it.)

That said -- http://nginx.org/r/error_page says that the last argument
it takes is the uri, so your configuration will end up sending a http
302 with a Location: of =444, which is likely to confuse any client.

(And, I guess there is no reason why the client would not cache *that*
response. So back to question#1 -- if your phone tried to access the
login page in the past and got this redirect; and then you reconfigured
the allow list and reloaded the config; and then you asked your phone
to access the login page again, your phone might use the cached response
without talking to nginx at all.)


So -- untested by me -- perhaps test something like

	error_page 403 =444 /;

in this location, or

	error_page 403 = /no;

in this location along with

	location = /no { return 444 }

nearby; or use "geo" (http://nginx.org/r/geo) at http level to set a
good/bad variable based on the connecting IP, and use

	if ($bad) { return 444 }

in this location.

I think that the latter two should work; the first one I'm not sure about.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org