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
-----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 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...
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
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@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)
participants (2)
-
Matt Zito -
Richard A. Steenbergen