Hi Willy, Thank you for your reply. And thank you guys for a great product.
The requests are not coming from a single or even a few IP addresses and that what make us worry a bit though we have not got any complains from our users about errors or anything similar. I also tried to filter out those requests with ACL checking for only 1 byte in the request but with no success. Did you ever occur such a requests? (NULL byte) Best Regards, Shay On Wed, Dec 5, 2012 at 11:47 PM, Willy Tarreau <[email protected]> wrote: > Hi, > > On Thu, Nov 29, 2012 at 12:34:46AM +0200, SBD wrote: > > Hi, > > > > We have problem on our production server which having a big amount of > what > > appear to be null requests (about 1K/min). We add the option dontlognull > to > > our frontends but they still being logged and display as request errors > in > > the stats page. > > > > We are using the last stable version (1.4.22). This is an example of what > > we get when running "show errors": > > > > frontend ****** (#1): invalid request > > src ******, session #3468, backend <NONE> (#-1), server <NONE> (#-1) > > HTTP internal state 26, buffer flags 0x00909002, event #0 > > request length 1 bytes, error at position 0: > > > > 00000 \x00 > > > > As you can see the request is not empty but rather include one byte which > > is NULL. I'm not sure if this is what called "NULL Reqeust" but we have > no > > idea what causes this (except for port scanning or something similar) > > No, as indicated in the doc : > > it is possible to enable option "dontlognull" to indicate that a > connection on which no data has been transferred will not be logged > > Here you have a data transfer since the client sends one byte. so it is > normal that there is a log. Can't you simply block the source IP address ? > For example, using "tcp-request connection reject if { src XX.XX.XX.XX }" ? > > This should avoid the logs as the connection will be dropped just after > the accept(). Just an idea. Or maybe it's an internal component which > needs to be fixed ? After all, sending such a byte on an HTTP port is > clearly an indication of someone looking for trouble. > > Regards, > Willy > >
