nanog mailing list archives

RE: engineering --> ddos and flooding


From: Matt Zito <mzito () register com>
Date: Mon, 4 Jun 2001 15:24:26 -0400




-----Original Message-----
From: Richard A. Steenbergen [mailto:ras () e-gerbil net]
Sent: Monday, June 04, 2001 3:09 PM
To: Matt Zito
Cc: Paul Johnson; nanog () merit edu
Subject: RE: engineering --> ddos and flooding
Rate-limiting ICMP is not so difficult - rate-limiting SYNs is
basically useless.  Syn floods work not because the amount 
of traffic
they do, but because they fill up state tables or make them so
horribly inefficient as to make the box cease responding on 
that port.
Given that, say, a linux box has a default queue depth of 128, I can
send 128 spoofed SYNs at a rate of one a second, and in two minutes
that box will stop responding.  The larger you make the queue, the
longer it will stand up to a slow SYN attack, but the more 
costly each
incoming SYN and SYN+ACK becomes, as the data structures become more
and more unwieldy.

Wrong, and very much out of date.

I didn't write all this down to waste my breath...

http://www.e-gerbil.net/ras/projects/dos/dos.txt


Well, what I said is inaccurate for SOME operating systems.  A default linux
box today still has a 128-syn queue.  Unless you enable syn cookies, you're
screwed - I haven't checked BSD or Solaris for slow-syn behavior recently.
Syn cookies also aren't a magic bullet - you lose TCP options that some
people really want/need.  And rate-limiting SYN is still a bad idea - if you
rate-limit to a certain bandwidth, either your server will not be able to
handle the incoming syns and will stop responding, or legitimate incoming
traffic will hit the floor because the queue on the router is full (or
approaching full and RED is invoked) and legitimate incoming requests will
be dropped.  This might be okay for places where one server performs many
functions - i.e. the box is still available on other ports, but in larger
infrastructures, a box generally has one purpose, and if its purposed port
is down, the box might as well be turned off.  

So, I prefer solutions that negotiate the connection before passing it back
to the host - like (insert basically any firewall product here).  Some do it
better than others, of course - the netscreen 100, 500, and 1000  seem much
better than anything else the field has to offer.

Thanks,
Matt


Current thread: