New Low Bandwidth Denial of Service Attacks 366
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)."
Oh no! They're attacking... slowly... (Score:3, Interesting)
Re:Oh no! They're attacking... slowly... (Score:5, Interesting)
Re:Oh no! They're attacking... slowly... (Score:5, Funny)
Re:Oh no! They're attacking... slowly... (Score:2)
Of course. Old Age and Treachery ALWAYS overcome Youth and Skill.
Re:Obligatory simpsons quote... (Score:5, Funny)
yay (Score:4, Funny)
Re:yay (faker!) (Score:5, Funny)
Anyone who is actually old enough to have used one of these would certainly know how to spell it correctly.
I call faker! You are just trying to pretend you are some 31337 old geek when you probably have never used anything slower than a DSL line.
Now get out of here before I whip ya with this here cable with BNC connectors.
Re:yay (faker!) (Score:2, Funny)
Re:yay (faker!) (Score:5, Informative)
Re:yay (faker!) (Score:2, Informative)
Baud origin (Score:2)
Re:yay (faker!) (Score:2, Funny)
Re:yay (faker!) (Score:2)
Re:yay (faker!) (Score:2)
Or Banana nut coupler
Re:yay (faker!) (Score:3, Funny)
Re:yay (faker!) (Score:3, Funny)
Re:yay (faker!) (Score:2)
Bonus Points!!
Re:yay (faker!) (Score:2)
For 1337-speakers that may have never seen those... they were big pieces of METAL on the ends of network cables.
none of those sissy plastic phone-jack "snagless" wires in the olds days. These things were physically keyed. If you tugged on the cable hard enough, the thing you were most likely to do was pull the wire out of the connector. If that didn't happen, then you're probably dragging your computer along the floor.
While
Re:yay (faker!) (Score:3, Informative)
Re:yay (faker!) (Score:5, Insightful)
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.
Re:yay (faker!) (Score:3, Informative)
Illogically, it is actually easier to establish and maintain a 56k connection than it is a 33.6K connection, when the local phone line is the only thing in question. (with 56k, you also have to have no more than one analog->digital conversion in between you and the phone company).
A 33.6K connection requires a symbol rate of 3200, which is greater than the 2800 that the 56K uses; hence, when customers would ask "What
Re:yay (faker!) (Score:4, Interesting)
And there's a boatload of various technologies (loading coils for example) that are designed around maintaining those frequencies at the cost of all others, which causes problems with high speed modems and utterly breaks DSL.
It's ok that your data is from the 1990s... the phone system was designed in the 1930s and hasn't changed dramatically since
I had the pleasure of seeing the inside of a CO in downtown Atlanta in the early 90s. From the battery room with 45 gallon drums of baking soda in case of an acid spill, to the entryway with cables varying from the thickness of your arm (old, old, old copper) to less than a pencil (fiber), to 40 foot by 3 foot by 6 foot long switches that were being replaced by a pair of boxes the size of Coke machines. All an interesting mish mash of old and new technologies and all working together. At least they'd gotten rid of the mechanical switches
Re:yay (faker!) (Score:2)
As a Californian, I take exception to that statement.
And as a pedantic ass, I state that "any sentence challenging English usage or pronunciation that ends in a preposition needs revisiting."
And as a victim of Murphy, I don't doubt that someone will find grammatical errors in this posting.
Re:yay (faker!) (Score:2)
The "never-end-in-a-preposition-rule" is essentially absurd. I've read better texts explaining the origin and absurdity better, but that's the best one I could find on short notice.
Murphy strikes again.
-Rob
2400? 2400?!? (Score:4, Funny)
In my day, we had to get at 2:00am, clean the road with our tongues, crawl to work on broken glass and when we got there, we had to work with 6 baud modems that were powered by rabid hamsters. And we were glad for them.
Young fsking slacker is what you were... (Score:2)
Re:Young fsking slacker is what you were... (Score:2)
Tubes!!! You weenie.
We had to do all our programming on punch cards with an old Jacquard loom. And that was the new system.
Before that we were stuck with the old calculator that Pascal gave us.
Re:Young fsking slacker is what you were... (Score:3, Funny)
We had to do all our programming by having a Viking take a battle axe to particular monks in a line to represent ones and zeros. The cost of computing was enormous. Those Vikings didn't work cheap, and the price of monks went up every year. Then when Constantinople fell to the Turks, ...
Oh, I've had enough of this. I never wanted to be a geek. I wanted to be ... a lumberjack!
Re:Young fsking slacker is what you were... (Score:2)
Nails! You had rusty nails?
I had to chisel the packets into stone tablets, then carry them one-by-one, back-and-forth, through fields of knee-deep snow on the back of an angry, flatulant ox.
Re:2400? 2400?!? (Score:2)
uphill..
both ways..
Re:2400? 2400?!? (Score:2)
And you forgot that you had hot grits for breakfast.
Re:You lucky bastard. (Score:3, Funny)
We had to grab ahold of something just to keep from floating away, and us without bodies! Heck, it wasn't even really us back then, it was just me, and I didn't even have consciousness. I didn't have nothin'.
And I was glad to get it.
Things just aren't what they used to be. Young folks have got all these newfangled "physical laws" and "universal constants" to make things easy for 'em. It's gettin' so th
Re:yay (Score:5, Funny)
"101010100010100"
Re:yay (Score:2)
Re:yay (Score:2)
ISP?
You were lucky!
;-)
Re:yay (Score:2, Funny)
Well actually, running from one computer to another with a floppy containing the files to transfer
Re:yay (Score:2)
Re:yay (Score:4, Funny)
Faker :) (Score:2)
Re:yay (Score:5, Funny)
Re:yay (Score:3, Funny)
SCO? (Score:3, Funny)
Damn sneaky way to get another SCO story on to
"Coordinated DDOS" (Score:5, Funny)
[SUIT 1] Uh, hey, uh.. this one computer here.. it's like the webserver or something?
[SUIT 2] Yeah, I think, why?
[SUIT 1] Well, none of the lights on it are on.. that's.. hm.
[SUIT 2] Oh, yeah, hey, look at that, someone seems to have tripped over the cord and unplugged it. [[Switches it back on]]
[SUIT 1] Huh.. um.. it doesn't seem to have started up all the way. It's saying something about "fsck" and asking for a password. What does that mean?
[SUIT 2] Hm, not sure.
[SUIT 1] Well.. could we get one of the linux guys to come and reboot it? Or something?
[SUIT 2] Well, we fired all of the linux guys so that we could concentrate all our resources on the lawsuit.
[SUIT 1] Uh.. shit! Well, I guess I better figure something out.. hmm
[[ Two days later, after two days of phone calls, SUIT 1 finally finds an INDEPENDENT CONTRACTOR who doesn't just laugh and hang up on him when he says he wants them to come fix a linux server. INDEPENDENT CONTRACTOR starts the linux server up all the way and charges a great deal of money. "Coordinated DDOS" thus ends. ]]
Re:"Coordinated DDOS" (Score:4, Funny)
Step 2: ???
Step 3: Karma!
come on guys, that wasn't even very funny.
Tough paper to read (Score:5, Funny)
Re:Tough paper to read (Score:4, Funny)
SuDZ
Re:Tough paper to read (Score:5, Informative)
It could be a better tarpit for spammers (Score:2)
For example: SMTP traffic.
To be more specific, let's take the example of somebody you don't like (We'll call them Mr. Spammer for now) initiates a TCP connection to you, on some random port (let's pick port 25) You watch the traffic, and once you determine that the traffic is coming from Mr. Spammer, you init
Re:Tough paper to read (Score:2)
That is rather insightful...
Low bandwith DOSing? (Score:5, Funny)
This guy is an amateur, wait until he feels the slashdot effect on his server. His next presentation will be entitled, how to knock down any server by just posting an article.
Where can I read about this? (Score:2)
Best wishes
James
Re:Where can I read about this? (Score:5, Informative)
Or Cick Here [acm.org]
I doubt it... (Score:2, Interesting)
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.
Re: (Score:3, Informative)
Re:I doubt it... (Score:5, Insightful)
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
Re:I doubt it... (Score:2)
Maybe You should read the HEADLINE!
Re:I doubt it... (Score:2)
Alas. The main 2 defences mountable run at the trade off of 'shitifying' your tcp stack performance. Either way its a DOS in the tradition of those lil syn fucker type DOS's just has some maths in its head and rather operates on timeouts.
Eh... its 2.15. Time fer bed
Re:I doubt it... (Score:2)
Dupe story. Mod me sideways... (Score:4, Informative)
Re:Dupe story. Mod me sideways... (Score:3, Informative)
+i, Complex (Score:2)
Comment removed (Score:3, Insightful)
Re:Parent is right, others wrong (Score:2)
Group subscription is a useful mechanism for multicast congestion control: RLM, RLC, FLID-DL, and WEBRC form a promising line of multi-group protocols where receivers provide no feedback to the sender but control congestion via group membership regulation. Unfortunately, the group subscription mechanism also offers receivers an opportunity to elicit self-beneficial bandwidth allocations. In particular, a misbehaving receiver can ignore guidelin
Re: oops, i'm an idiot too (Score:2)
Denial of Service attacks are presenting an increasing threat to the global inter-networking infrastructure. While TCP's congestion control algorithm is highly robust to diverse network conditions, its implicit assumption of end-system cooperation results in a wellknown vulnerability to attack by high-rate non-responsive flows. In this paper, we investigate a class of lo
No, you read the wrong abstract. (Score:2)
This is the correct paper:
Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants) [acm.org]
This is the abstract you read:
Robustness to Inflated Subscription in Multicast Congestion Control [acm.org]
These are separate papers by different authors. The TCP DoS does not involve Multicast.
Security through obfuscation (Score:5, Insightful)
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!
Re:Security through obfuscation (Score:5, Interesting)
Bah, the paper isn't that bad. Heck, without reading the whole thing and knowing a little bit about what they discuss (based on the first section), I can understand what you've quoted (if I'm correct, this is from their section on mitigating attacks using randomized RTOs).
Really, the basic concepts are *incredibly* simple. Send a burst of traffic which causes drops in the short term. This results in the TCP stack backing off and re-transmitting the packet after the defined RTO. So, if you hit the stack with another burst of packets just as the RTO is expiring, the stack will back off again. Lather, rinse, repeat. This requires a lot less traffic, since your bursts are spaced apart (roughly a second per burst, typically, since that's a pretty standard RTO).
Really, all you need is a basic understanding of TCP flow control to understand the concepts in this paper (which, BTW, they attempt to explain in the first section). The rest of the content (modelling TCP flow rates relative to DoS flow rates, etc) is really just the formal analysis of the basic attack, which certainly isn't important if all you care about is implementing it.
Re:Security through obfuscation (Score:2)
Re:Security through obfuscation (Score:3, Funny)
Arrest them! (Score:5, Funny)
Just what we need... (Score:2, Interesting)
Re: (Score:2)
Re:Just what we need... (Score:2)
As for a better protocol. You are quite free to write and implement one. Just find other ppl to use it. Don;t forget there are quite a lot of protocols out there (UDP being probably the next biggest).
Re:Just what we need... (Score:3, Insightful)
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 s
Direct link to paper (Score:5, Informative)
better papers this year (Score:5, Interesting)
- Peer-to-Peer Information Retrieval Using Self-Organizing Semantic Overlay Networks
- Quantum Cryptography in Practice
- Making Gnutella-like P2P Systems Scalable
Just some more food for thought....
Saturation! (Score:5, Interesting)
Aha! (Score:4, Funny)
I call to all arms-bearing full-bloodied americans to rush home, take their trusty shotguuns, and relentlessly hunt down spammers until the last one is gutted and stuffed and put on display in the Smithsonian!!!
Does it really work. (Score:2, Interesting)
If that isn't the case in implementations, it would seem to be implementation error, not really a fault with the protocol itself.
Re:Does it really work. (Score:2, Interesting)
I don't expect an attack like this to be able to effect me.
Shhhhhhhh!!! (Score:4, Funny)
That was totally irresponsible. They should have not released theat information, and promptly committed Hari-Kiri so the information would never be uttered again on the face of the earth.
Timescale (Score:5, Funny)
Proof of Concept by Monday
Script Kiddies Version by Thursday
Internet dies on Friday
All back to normal Monday
Rus
Okay, I get the joke. (Score:2)
Of course, none of this is real, and time is just an illusion that keeps everything from happening at once.
Heh, heh
Sounds a lot like... (Score:2, Interesting)
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.
Summary for non-CS people (Score:4, Interesting)
TCP will do this with a preset procedure that was designed to elminate deadlock situation. The problem occurs when everytime the TCP stack trys to resend the information, you can fool it by filling the 'pipe' again. As long as you know when the TCP stack will retry again, you can continue this over and over. Because it does not take a lot of information to fill the 'pipe' for the short time that TCP attempts to resend, you can have a low bandwidth attack.
Worms can potentially exploit this (Score:5, Interesting)
But with this low-bandwidth exploit, which I believe is actually not a new idea, since IE uses a tricky method to increase speed by leaving persistent connections until they time out [slashdot.org] that could be exploited, now a worm can potentially DoS any website, even dynamically selecting the target from the users' IE favorites and performing the attack very quickly (maybe in a matter of hours) without having to rely it on being a widespread, coordinated DDoS or what the target OS/Server is.
The paper even claims that in order to protect a server from this type of attack you'd need to sacrifice a good deal of performance, which in most cases is not acceptable so many people can't really afford to implement defenses. Either a clever workaround is made for this exploit, or we have tough times ahead from worm outbreaks and script kiddies.
Re:Worms can potentially exploit this (Score:3, Funny)
This whole scheme breaks down badly as the Internet and it's protocols are scaled to the 'big mean world'. Spam is the result in the domain of email. Things like this low bandwidth DoS attack are the result in the domain of TCP.
Problems l
Tune in next week... (Score:2, Funny)
Re:Tune in next week... (Score:2)
Note to self: Must shield hidden reactor in basement better.
Dupe! (Score:2, Informative)
dupe
Dupe!
DUPE!!!
Posted by michael on Sunday June 01, @12:56AM from the advanced-topics dept. dss902 writes "We (Department of Computer Science, Rice University) present a new class of low-bandwidth denial of service attacks that exploit algorithmic deficiencies in many common applications' data structures... Using bandwidth less than a typical dialup modem, we can bring a dedicated Bro server to its knees; after six minutes of carefully chosen packets, ou
Re:Dupe! Or not... (Score:4, Insightful)
Undistinguishable? (Score:5, Insightful)
Except for the bursts of traffic from the same host at a certain frequency.
Re:Undistinguishable? (Score:2)
Yeah, because there's no way in HELL that anybody who could design this sort of system could POSSIBLY think to, gosh, some sort of, I don't know, maybe.... randomize the times they attack? Or even build, oh, I don't know, some sort of DISTRIBUTED smurf-like system so that the bitty little attacks are coming from RANDOM hosts at RANDOM times.
Good thing, too.
Duh! (Score:5, Funny)
Going to be tough to exploit. (Score:5, Insightful)
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.
Frequency (Score:5, Funny)
That's not a problem. All you have to do is periodically adjust your shield harmonics to keep the attacker from adapting quickly enough to do any harm.
Learn How To Protect Yourself!! READ THIS!! (Score:4, Funny)
Just set the evil bit, and all is well.
Re:Down with sexism! .. I mean, IPv4! (Score:5, Insightful)
Re:Down with sexism! .. I mean, IPv4! (Score:2)
10100111.01110001.11010101.10010000
A7.71.D5.9
or
2809255312
It used to be an obfuscation to use http://2809255312 in spam, I don't know if it is still used, I haven't seen it for a while
I know IE accepted it but Mozilla doesn't in FreeBSD
Re:Get the Lawyers ready. (Score:2)