Logging inconsistencies during apparent DoS
djon00 at gmail.com
Sun Jul 27 02:15:20 MSD 2008
Thanks for your response. Sorry, I perhaps should have been clearer in
saying it was an *apparent* attack. It looked like a syn attack, but
there were a number of inconsistencies that indicated it was actually
something else, and potentially a problem within nginx.
Istvan Szukacs wrote:
> In every modern operating system including: linux*, *bsd, a couple of
> other unix-like systems there is syn cookie to avoid the situation when
> somebody flood your server with only SYN packets starting thousands of
> webserver process
The servers affected by this problem are behind a firewall, and a load
balancer that should be preventing these getting through. The load
balancer will only hand off a connection to the web server after a full
> sysctl -w net.inet.tcp.syncookies=1
> I dont know that much MacOS but I guess you have but try to search
> something like this with sysctl -a | grep syn and probably there is the
> same sysctl.
This particular variable doesn't exist on OSX 10.5 (nor anything like
it), so not sure how it would handle this situation.
The main inconsistency is the fact that we are seeing logged requests
that would have had to have a full TCP connection established, from an
unroutable (reserved space) address. eg :
248.240.43.0 host.com - [05/Jul/2008:06:26:38 +1000] "GET / HTTP/1.1"
301 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" "-"
So either nginx is logging incorrect information (and hence perhaps
pointing to a broader problem), or the load balancer is badly
translating connections though from the virtual IP.
I will add in extra firewalling at the individual hosts in an attempt to
help prevent this. However I am reluctant to do this without first
making sure we aren't just covering up a larger problem, that will come
back to bite us soon.
> John Barratt wrote:
>> We have been having problems with an apparent SYN-flood DoS
>> attack. However there are are inconsistencies with the resulting log
>> entries in nginx that along with the environment it is in, make me
>> wonder if it really is a DoS attack, and/or there is something else
>> going wrong.
>> We are running nginx 0.6.31 on OSX 10.5 Server. Details of the
>> problem go something like this :
More information about the nginx