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@unix-solution.de>
> *To: * <nginx@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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx