Hierarchy of malformed requests and blocked IPs

[Valentin V. Bartenev]

On Saturday 30 July 2016 10:52:46 lists at lazygranch.com wrote:
> On Sat, 30 Jul 2016 13:18:47 +0300
> "Valentin V. Bartenev" <vbart at nginx.com> wrote:
> 
> > On Friday 29 July 2016 23:01:05 lists at 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 ;
> -------------------------------

The "deny" directive comes from ngx_http_access_module.

See the documentation:
http://nginx.org/en/docs/http/ngx_http_access_module.html
 

> 
> Running "make config" in the nginx ports, I don't see
> "ngx_http_access_module" as an option, nor anything similar.
> 
[..]

It's a standard module, which is usually built by default.


> So given this set up, should the IP space in blockedips.conf take
> precedence? 

No.


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

Why bother to accept such connection at all?  There's no sense
to accept connection in nginx and then discard it immediately.

In your case it should be blocked on the system level.

  wbr, Valentin V. Bartenev