Hierarchy of malformed requests and blocked IPs

[lists at lazygranch.com]

On Sat, 30 Jul 2016 23:49:30 +0300
"Valentin V. Bartenev" <vbart at nginx.com> wrote:

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

I can do the blocking in the firewall, but I could see a scenario where
a web hosting provider would want to do web blocking on a per domain
basis. That is, what one customer wants to be blocks will not be what
all customers want blocked. So it seems to me if the IP could be
checked first within nginx,there is value in that.

In my case, I only want to block web access, which I assume I can do
via the firewall. My point being the web server has a significantly
larger attack surface than email. So while I would want to block access
to my nginx server, I would allow email access from the same
"blocked" IP. After all, the user I blocked might want to email the
webmaster to inquire why they are blocked. Or there are multiple
domains at the same IP, and not everyone is a hacker. Eyeballs
generally come from ISPs and schools. Datacenters are not eyeballs,
Yeah, people surf from work, but if you block some corporate server
that has been attempting to hack your server, so be it. Email on the
other had DOES come from datacenters, so they shouldn't be blocked from
25.