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 <mailingl...@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

Reply via email to