engineering --> ddos and flooding

Mon Jun 4 19:43:06 UTC 2001

On Mon, 4 Jun 2001, Matt Zito wrote:

> 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.

Well I can't speak for Linux, maybe they are just really broken. But every
OTHER OS (including windows!) has the ability to drop older connections
from the queue without locking up the entire port. Trust me, this is not
the problem any more. The remaining problem is twofold, A) the victim
server will try to generate SYN|ACK's or RST's, spending its cpu time
building and launching these packets, and B) even if it doesn't generate
those, the victim will spend its cpu time throwing away these bad packets.
If the victim just let the port go, it would probably keep the machine
alive for other services. Unfortunantly most attackers don't give you that
option.

Also, you're speaking about the limitations of the Linux SYN Cookie
implementation, not syn cookies in general. Rate limiting SYNs is
perfectly fine, provided you know what you're rate limiting. If you don't
have sufficient control over what you're rate limiting, you will just make
it that much easier to kill the victim. 

> 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.

I can't speak to any commercial products, but I have made FBSD stand up to
a 300kpps SYN flood and keep services alive with no router intervention.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)