Nginx wp-admin access control

[Lawrence]

Greetings All,


WOW, thanks for all the suggestions guys. Not many of them are understood, I will try the fail2ban and see how far I get.


Thanks gaian.
Lawrence



 From:   basti <mailinglist at unix-solution.de> 
 To:   <nginx at nginx.org> 
 Sent:   16/04/2020 4:54 PM 
 Subject:   Re: Nginx wp-admin access control 

I have not follow the entire discussion.

What is the goal to do with wp-admin?

There are several ways to limit access:
- http basic auth
- use a x509 cert to authenticate instead of user/pass
- write a hook plugin to wp_login() to use you own / external login

- just use fail2ban to keep bad guys out
- ...

On 16.04.20 16:46, Francis Daly wrote:
> On Wed, Apr 15, 2020 at 12:52:59PM +0200, Lawrence wrote:
> 
> Hi there,
> 
>> To start, I am very much a beginner to nginx and  coding. I am a application support engineer, but got very little  development skills.
> 
> I don't know WordPress; but on the nginx side, what matters is the
> request that is made (the url, handled in a "location") and the way that
> you want nginx to handle that request.
> 
> In nginx (in general), one request is handled in one location;
> only the configuration in, or inherited into, that location
> matters. Location-matching does not include the request query
> string. Inheritance is per directive, and is either by replacement or
> not at all. The "*_pass" directives are not inherited; the others are.
> 
> There are exceptions to this description, but it is probably a good
> enough starting point to understanding the configuration that is needed.
> 
> The documentation for any directive X can be found from
> http://nginx.org/r/X
> 
>> My goal is to have the sites available but the access to all wp admin must be limited.
>> below are a few of the solutions I found. Non seem to work fully. I assume it is my understanding of nginx configuration.
>>
>> method #1  -- test unsuccessfully.
> 
> In this case, does "unsuccessful" mean: the php file is not handled
> when it should be; or the php file is handled when it should not be; or
> something else? In general, it is good to be specific -- what request was
> made, what response was returned, and what response was wanted instead.
> 
> 
> So, with me not knowing WordPress, your mail and some brief web searching
> suggests that you want your nginx to do the following:
> 
> * allow any access to any request that ends in ".php", except
> * restrict access to the request /wp-login.php and
> * restrict access to any php request that starts with /wp-admin/, except
> * allow any access to /wp-admin/admin-ajax.php
> 
> where "restrict" is to be based on an infrequently-changing list of IP
> addresses or address ranges.
> 
> And this is in addition to the normal "try_files" config to just get
> wordpress working.
> 
> Is that an accurate description of the desired request / response
> handling mapping?
> 
> If so, something like (untested):
> 
> ===
>   include fastcgi.conf; # has fastcgi_param, etc, but not fastcgi_pass
>   # Can directly paste the relevant lines here instead
> 
>   location / {
>     try_files $uri $uri/ /index.php?$args;
>   }
>   location ~ \.php$ {
>     location ~ ^/wp-admin/ {
>       allow 192.168.1.0/24;
>       deny all;
>       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
>     }
>     fastcgi_pass unix:/run/php/php7.0-fpm.sock;
>   }
>   location = /wp-login.php {
>     allow 192.168.1.0/24;
>     deny all;
>     fastcgi_pass unix:/run/php/php7.0-fpm.sock;
>   }
>   location = /wp-admin/admin-ajax.php {
>     fastcgi_pass unix:/run/php/php7.0-fpm.sock;
>   }
> ===
> 
> looks like it should work. There are other ways to arrange things,
> and there is repetition here of the "allow" list; it may be simpler to
> maintain that list twice than to use another "include" file.
> 
> If you are happy to test and report what fails, then it should be possible
> to end up with a suitable config.
> 
> Good luck with it,
> 
>      f
> 
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200416/f683a67f/attachment.htm>