Hierarchy of malformed requests and blocked IPs

lists at lazygranch.com lists at lazygranch.com
Sat Jul 30 17:52:46 UTC 2016

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:
deny ;
deny ;
deny ;
deny ;

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

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: - - [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).

More information about the nginx mailing list