On Sat, 30 Jul 2016 13:18:47 +0300
"Valentin V. Bartenev" <vbart@nginx.com> wrote:
> On Friday 29 July 2016 23:01:05 lists@lazygranch.com wrote:
> > I see a fair amount of hacking attempts in the access.log. That is,
> > they
> show up with a return code of 400 (malformed). Well yeah, they are
> certainly malformed. But when I add the offending IP address to my
> blocked list, they still show up as malformed upon subsequent
> readings of access.log. That is, it appears to me that nginx isn't
> checking the blocked list first.
> >
> > If true, shouldn't the blocked IPs take precedence?
> >
> > Nginx 1.10.1 on freebsd 10.2
> >
>
> It's unclear what do you mean by "my blocked list". But if you're
> speaking about "ngx_http_access_module" then the answer is no, it
> shouldn't take precedence. It works on a location basis, which
> implies that the request has been parsed already.
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
My "blocked IPs" are implemented as follows. In nginx.conf:
------------------
http {
include mime.types;
include /usr/local/etc/nginx/blockips.conf;
-------------------------------------
Tne format of the blockips.conf file:
------------------
#haliburton
deny 34.183.197.69 ;
#cloudflare
deny 103.21.244.0/22 ;
deny 103.22.200.0/22 ;
deny 103.31.4.0/22 ;
-------------------------------
Running "make config" in the nginx ports, I don't see
"ngx_http_access_module" as an option, nor anything similar.
So given this set up, should the IP space in blockedips.conf take
precedence?
My thinking is this. If a certain IP (or more generally the entire IP
space of the entity) is known to be attempting hacks, why bother to
process the http request? I know I could block them in the firewall,
but blocking in the web server makes more sense to me.
Here is an example from access.log for a return code of 400:
95.213.177.126 - - [30/Jul/2016:11:35:46 +0000] "CONNECT check.proxyradar.com:80 HTTP/1.1" 400 173 "-" "-"
I have the entire IP space of selectel.ru blocked since it is a source
of constant hacking. (Uh, no offense to the land of dot ru).
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
