
Explaining the “New” TCP Resource Exhaustion Denial of Service (DoS) Attack - prakash
http://insecure.org/stf/tcp-dos-attack-explained.html
======
tptacek
The people you're really worried about --- the people who are set up to carry
out extortion operations against your site, who know how to safely deliver
their demands and safely collect your money --- already have the ability to
take you down with the push of a button. Some of them herd massive botnets,
some of them have relays set up in various countries and on various networks.
Some of them are even set up to inject prefixes into BGP4.

From 2001-2005, I worked in various roles at Arbor Networks, now basically the
dominant DDoS defense company, deployed at every major ISP in the world. I
was, among other things, the lead developer on Peakflow DoS, their DDoS
tracking and remediation product. The thing I learned there that sticks most:
ISPs deal with tens or hundreds of DDoS attacks (real, honest to god attacks)
_per day_.

I can't see how any new DDoS research is going to change the game at this
point.

------
jsn
Last time we were under serious ddos, the attack vector shifted several times
in response to our countermeasures. One of those shifts was looking quite
similar to what fyodor describes. An attacking machine opened 1000+
connections, sent the request, then shrank the receive window to 1 byte. The
botnet segment doing that was maybe ~500 zombies or so.

Of course, it's trivially mitigated on linux with iptables connlimit match
(fyodor mentioned that, too).

The punchline: our colo provider insisted on having a PIX firewall in front of
our box, with stateful packet inspection and all that. And, of course, that
was way too much state for it to keep. So the PIX has gone down and we've got
our 24 hours of downtime.

------
alecco
Put up or shut up (until patch is ready.)

Simple. Else, it's egomania.

~~~
huhtenberg
There's no patch.

TCP is a stateful protocol. Per-connection state uses memory, so creating more
connections will exhaust memory OR it will cause no more connections to be
created - both cases are a form of DoS.

A naive approach is to initiate a lot of connections, but never complete the
setup. That's a SYN flood. Another approach is to actually complete the
handshake, then initiate a tear down and never complete it. The OS at the
server end gets stuck with a lot of half-closed connections that may take many
minutes to timeout and there's no application control over this. There's no
control over this 'stuck' connections at the OS level either, the only option
is to wait for them to die off as per TCP spec.

There are other variations, but you get the idea. I do agree though that these
two guys are simply whoring for attention.

~~~
brl
Don't forget to stuff the kernel buffers with a few (or many) megabytes of
data before getting those connections 'stuck'.

The amount of time it will take for them to die off (as per the TCP spec) is
'infinity' since there is no provision in the protocol itself for detecting
unresponsive peers. If your operating system implements a hack called 'tcp
keepalive' then those connections will die in a couple of hours in a typical
configuration.

