Hi all!

Weird thing started to happen. As part of the security onion, I ban all IPs that try connecting to the web server (Nginx) via IP directly and not through a hostname (fail2ban regex on access.log).

Today I found out that one of the legitimate clients got banned and upon closer inspection I found this logged for his requests:

xx.xx.xx.xx - - [23/Aug/2011:17:11:01 +0000] "-" 400 0 "-" "-" "-"

(IP censored)

So I figured there must be something wrong with his browser (Firefox 3.6 on Windows), but the log is full of such entries, for various remote IPs (not just this client's I suppose), beside standard webapp sniffers. I guess this client is the first who complained.

Tried to google for it, perhaps it's a bug in FF, but I came up short. Top entries in Google suggest clearing the cache, and I'll suggest that to the client but I'm sure there are no cookies involved with the domain they're accessing (basic auth over https). I also do not know if any other browsers are "affected" since there is no UA reported.

Anyone familiar with this issue?

My first thought was that this might be a relic of pre-fetching; many web browsers attempt to predict what the human is going to click on and start fetching it before they do, bailing out if the human decides to do something else.

But then I saw this: http://orensol.com/2009/01/18/nginx-and-weird-400-bad-request-responses/ ... dunno, but it sounds plausible.

From an operational standpoint, I probably wouldn't use a fail2ban regexp like that, as it seems way too prone to false-positives. Plus, if it is something like a forum with user-generated content, all of your users could be taken out by some crazy git inserting an "image" like .

_________________

/* TODO: need to add signature to posts */

Yeah, googling for "Nginx 400 0" results with suggestions to drop cookie cache, and I'll suggest that to the client, though there are no cookies involved for the domain he's accessing.

Best thing to do will be to fire up tcpdump and correlate timestamps.