Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: engineering --> ddos and flooding

  • From: Richard A. Steenbergen
  • Date: Mon Jun 04 15:51:19 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

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 <>
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.