Nginx wp-admin access control

[Lawrence]

Thanks everyone for the great support.


After many replies I found that nginx did not like the cascading config that was suggested by some. Once I removed that, things seemed to stabilize  and all seems good.


Thanks
Lawrence



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

when you use fail2ban have a look on ipset it performe better on large 
lists.

Am 16.04.20 um 17:13 schrieb 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
> 
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> 
_______________________________________________
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/20200422/6b69051d/attachment-0001.htm>