Slashdot Mirror
New Low Bandwidth Denial of Service Attacks
An anonymous reader writes "A paper from Rice University
appearing at the
2003 ACM Sigcomm Conference presents a new denial of service
attack where the attacker only needs to send at a low rate
to shutdown TCP flows. The trick exploits the retransmission timeout
mechanism in TCP. By sending small bursts of packets at just the right
frequency, the attacker can cause all TCP flows sharing a bottleneck
link to simultaneously stop indefinitely. And because the attacker
only needs to burst periodically, the attacker will not be
distinguishable from normal hosts. The presentation, and other
presentations from the conference, are available online (live
streaming)."
Comment removed based on user account deletion
Then, I downloaded the
Here's a sample:And that's one of the more lucid sentences.
Anyone who would be able to put together an actual attack from this paper probably has enough education to get a real job -- something that doesn't go well with writing malware on the side.
Of course, now that the paper's being discussed on Slashdot, all bets are off!
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
I'm pretty certain that my firewall would flag the bursts. If not, seems a simple rule or two would suffice to flag them. I'd like to see this in action. I suspect that it is pretty lame and easily detected.
:)
My guess is that by Friday night, the kiddies will have thousands of these going. So, I guess I can do see for myself tomorrow
Ah. sure dude.
Not sure how a firewall helps with DOS and DDOS attacks however. something floods your pipe, and its flooded, no matter how clever your firewall is. Try reading the article
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Insightful? This is CRAP. It's called TCP/IP. Whether its TCP/IP4 or TCP/IP6, theres still TCP, and that's what this attack targets.
"And because the attacker only needs to burst periodically, the attacker will not be distinguishable from normal hosts."
Except for the bursts of traffic from the same host at a certain frequency.
Since it requires accurate timing.
a) Even if the average bandwidth is low, the attacker will still need the ability to burst those peaks. Remember that in most cases, we pay for peak bandwidth and not average bandwidth. A 56k modem likely won't be able to perform one of these DoS attacks because it doesn't have the peak b/w capability.
b) The more hops you are away from your target, the more your peaks will get spread out and averaged. Keep in mind that most cable modem head-ends and the cable modems themselves have REALLY long packet queues. This is why upstream saturation is such a problem for cable modems. You can burst all you want, if you're DoSing from a cable modem it'll be averaged out and/or the timing completely FUBARed by the time the packets leave your neighborhood.
retrorocket.o not found, launch anyway?
No. Modems stopped increasing in baud at 2400, and then used various encoding methods (trellis, QAM, etc.) to squeeze more than 1 bit/baud. A 9600 bps modem, for instance, averages 4 bits/baud.
Well. Almost.
Better quality phone lines can support >2400 baud, but not by much. A 28800 bps connection is running at 3429 baud IIRC, and varying line conditions will reduce that baud rate, thus reducing your effective bps.
Compression is on top of all of this. It's an entirely different issue, and if you transfer straight text over a 28.8k modem you can get considerably more than 28.8kbps out of the modem.
You got the broad stuff right though, which is a lot more than most people grok.
Since the architectural flaw seems to be in the retransmission recovery sequences of TCP, eg, it can be spoofed in a way undistinguishable from normal retransmission recovery sequences, actual source of the packet can't be used as a deterrent to attacks.
The attack seems to exploit the mechanisms of congestion flow itself, so larger window sizes or in-order deliver of packets (I presume this is what you mean by sequenced packets) will not be sufficient to avoid this attack. The paper does examine several variants of TCP, with similarly glum results.
In the scenario illustrated by the paper, TCP enters its exponential backup phase, throttling the window to a single packet size and doubles the retransmission timeout (which starts off at 1 second). The paper seems to be saying that by timing the attacking responses to closely match that of the sender's RTO, we can cause the connection to effectively remain in exponential backoff.
To my thinking this would affect throughput for only the attacker's TCP flow, but the authors say that ALL TCP flows can be affected. I'm just not smart enough to understand why all TCP flows can be induced into the same exponential backoff phase.
sloth jr
Too bad this is a *completely different attack*! Jeez, read the friggin' paper, people. The paper you reference talks about a DoS which exploits data structures commonly used in TCP stacks. The DoS in the paper referenced for this article exploits TCP congestion control algorithms to "fool" the TCP stack into thinking the pipe is full when it really isn't by sending carefully timed packet bursts.