<html><head></head><body><div>Greetings All,</div><div><br></div><div>WOW, thanks for all the suggestions guys. Not many of them are understood, I will try the fail2ban and see how far I get.</div><div><br></div><div>Thanks gaian.</div><div>Lawrence<br></div><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 4:54 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;">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 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 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 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 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 admin must be limited.<br>>> below are a few of the solutions I found. Non seem to work 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 be; or<br>> something else? In general, it is good to be specific -- what request was<br>> made, what response was returned, and what response was wanted instead.<br>> <br>> <br>> So, with me not knowing WordPress, your mail and some brief web 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/, except<br>> * allow any access to /wp-admin/admin-ajax.php<br>> <br>> where "restrict" is to be based on an infrequently-changing list 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 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 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 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</blockquote></div></body></html>