<html><head></head><body>Thanks everyone for the great support.<div><br></div><div>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.</div><div><br></div><div>Thanks</div><div>Lawrence<br><br><br><div><strong>
From:
</strong>
basti <mailinglist@unix-solution.de>
<br>
<strong>
To:
</strong>
<nginx@nginx.org>
<br>
<strong>
Sent:
</strong>
16/04/2020 6:04 PM
<br>
<strong>
Subject:
</strong>
Re: Nginx wp-admin access control
<br><br><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:1px solid #CCC;padding-left:1ex;">when you use fail2ban have a look on ipset it performe better on large <br>lists.<br><br>Am 16.04.20 um 17:13 schrieb Lawrence:<br>> Greetings All,<br>> <br>> WOW, thanks for all the suggestions guys. Not many of them are <br>> understood, I will try the fail2ban and see how far I get.<br>> <br>> Thanks gaian.<br>> Lawrence<br>> <br>> <br>> *From: * basti <mailinglist@unix-solution.de><br>> *To: * <nginx@nginx.org><br>> *Sent: * 16/04/2020 4:54 PM<br>> *Subject: * Re: Nginx wp-admin access control<br>> <br>> I have not follow the entire discussion.<br>> <br>> What is the goal to do with wp-admin?<br>> <br>> There are several ways to limit access:<br>> - http basic auth<br>> - use a x509 cert to authenticate instead of user/pass<br>> - write a hook plugin to wp_login() to use you own / external login<br>> <br>> - just use fail2ban to keep bad guys out<br>> - ...<br>> <br>> On 16.04.20 16:46, Francis Daly wrote:<br>> > On Wed, Apr 15, 2020 at 12:52:59PM +0200, Lawrence wrote:<br>> ><br>> > Hi there,<br>> ><br>> >> To start, I am very much a beginner to nginx and coding. I am a<br>> application support engineer, but got very little development skills.<br>> ><br>> > I don't know WordPress; but on the nginx side, what matters is the<br>> > request that is made (the url, handled in a "location") and the<br>> way that<br>> > you want nginx to handle that request.<br>> ><br>> > In nginx (in general), one request is handled in one location;<br>> > only the configuration in, or inherited into, that location<br>> > matters. Location-matching does not include the request query<br>> > string. Inheritance is per directive, and is either by replacement or<br>> > not at all. The "*_pass" directives are not inherited; the others<br>> are.<br>> ><br>> > There are exceptions to this description, but it is probably a good<br>> > enough starting point to understanding the configuration that is<br>> needed.<br>> ><br>> > The documentation for any directive X can be found from<br>> > http://nginx.org/r/X<br>> ><br>> >> My goal is to have the sites available but the access to all wp<br>> admin must be limited.<br>> >> below are a few of the solutions I found. Non seem to work<br>> fully. I assume it is my understanding of nginx configuration.<br>> >><br>> >> method #1 -- test unsuccessfully.<br>> ><br>> > In this case, does "unsuccessful" mean: the php file is not handled<br>> > when it should be; or the php file is handled when it should not<br>> be; or<br>> > something else? In general, it is good to be specific -- what<br>> request was<br>> > made, what response was returned, and what response was wanted<br>> instead.<br>> ><br>> ><br>> > So, with me not knowing WordPress, your mail and some brief web<br>> searching<br>> > suggests that you want your nginx to do the following:<br>> ><br>> > * allow any access to any request that ends in ".php", except<br>> > * restrict access to the request /wp-login.php and<br>> > * restrict access to any php request that starts with /wp-admin/,<br>> except<br>> > * allow any access to /wp-admin/admin-ajax.php<br>> ><br>> > where "restrict" is to be based on an infrequently-changing list<br>> of IP<br>> > addresses or address ranges.<br>> ><br>> > And this is in addition to the normal "try_files" config to just get<br>> > wordpress working.<br>> ><br>> > Is that an accurate description of the desired request / response<br>> > handling mapping?<br>> ><br>> > If so, something like (untested):<br>> ><br>> > ===<br>> > include fastcgi.conf; # has fastcgi_param, etc, but not<br>> fastcgi_pass<br>> > # Can directly paste the relevant lines here instead<br>> ><br>> > location / {<br>> > try_files $uri $uri/ /index.php?$args;<br>> > }<br>> > location ~ \.php$ {<br>> > location ~ ^/wp-admin/ {<br>> > allow 192.168.1.0/24;<br>> > deny all;<br>> > fastcgi_pass unix:/run/php/php7.0-fpm.sock;<br>> > }<br>> > fastcgi_pass unix:/run/php/php7.0-fpm.sock;<br>> > }<br>> > location = /wp-login.php {<br>> > allow 192.168.1.0/24;<br>> > deny all;<br>> > fastcgi_pass unix:/run/php/php7.0-fpm.sock;<br>> > }<br>> > location = /wp-admin/admin-ajax.php {<br>> > fastcgi_pass unix:/run/php/php7.0-fpm.sock;<br>> > }<br>> > ===<br>> ><br>> > looks like it should work. There are other ways to arrange things,<br>> > and there is repetition here of the "allow" list; it may be<br>> simpler to<br>> > maintain that list twice than to use another "include" file.<br>> ><br>> > If you are happy to test and report what fails, then it should be<br>> possible<br>> > to end up with a suitable config.<br>> ><br>> > Good luck with it,<br>> ><br>> > f<br>> ><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://mailman.nginx.org/mailman/listinfo/nginx<br>> <br>> <br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://mailman.nginx.org/mailman/listinfo/nginx<br>> <br>_______________________________________________<br>nginx mailing list<br>nginx@nginx.org<br>http://mailman.nginx.org/mailman/listinfo/nginx</blockquote></div></div></body></html>