Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Defeating DDOS

By noeld in News
Mon Apr 03, 2000 at 10:38:15 AM EST
Tags: Security (all tags)
Security

Fernando Schapachnik has updated his proposal for defeating Distributed Denial of Service Attacks based on changing network routes.

This paper describes a technique that can be used to defeat the recent DDOS attacks _in_real_time_. The solution presented here is based on routing and it requires a certain amount of extra network infrastructure.


Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o proposal
o Also by noeld


Display: Sort:
Defeating DDOS | 8 comments (8 topical, editorial, 0 hidden)
That's an interesting idea. What I'... (none / 0) (#1)
by rusty on Mon Apr 03, 2000 at 07:15:43 AM EST

rusty voted 1 on this story.

That's an interesting idea. What I'm unclear on is, what if your DDoS clients are hitting 'www.example.com' instead of 10.0.0.1 (i.e., the host name, not the IP). Changing your IP address won't help at all, will it? It doesn't seem like doing a lookup would be a huge issue, since each client doesn't need to produce all (or even "most") of the traffic by itself. You might need a few more slave DOS clients, to account for the bandwidth each one spends doing a DNS lookup, but overall, would it be that hard to get around the proposed solution this way?

____
Not the real rusty

This doesn't seem to be a reasonabl... (none / 0) (#2)
by mattdm on Mon Apr 03, 2000 at 09:11:29 AM EST

mattdm voted 0 on this story.

This doesn't seem to be a reasonable solution for very many cases. It requires a large amount of spare IP addresses to be left sitting around "just in case". But more importantly, with a large enough attack, it's likely that the ISP is getting overwhelmed, not just "example.com" -- and in that case, this wouldn't help at all. The real solution to this problem is for sysadmins at large institutions to keep their own security tight so there is nowhere to launch an attack from. Here at Boston University, we detected and shut down several breakins last year which we believe were related to the famous recent incident. If we'd been less on our toes, we'd've been part of the problem too.

Having worked for a couple of ISPs ... (none / 0) (#3)
by eann on Mon Apr 03, 2000 at 10:21:54 AM EST

eann voted 1 on this story.

Having worked for a couple of ISPs in the past, I can say near-categorically that the problem with doing anything the "right" way is the cost. The author is talking about significant network infrastructure improvements, and most companies would (on paper) rather suffer a few hours of missed business (but added publicity) than shell out up front for a spare T3 and Cisco 7000-series (or whatever they're up to these days).

The other problem with this guy's proposal is that DNS is far to slow to just switch to a different address (remember, your ISP's nameserver is allowed to cache what it gets from theirs up to the specified TTL). I've never seen any survey about "average" TTL on nameservers around the net, but I expect it's fairly high for some of the really hot sites to save the nameservers as much work as possible. And, that DNS is often handled by a machine on the same subnet as the web (or other affected) server anyway.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.


Re: Having worked for a couple of ISPs ... (none / 0) (#4)
by fluffy grue on Mon Apr 03, 2000 at 11:05:00 AM EST

The paper specifically stated that the DNS would have a TTL of 0. Myself, I'd set it to 60 (okay, so they have one minute of potential downtime, big deal). However, this circumvention of the attack will only work until the DDOS "tools" get a "no route to host" error and then re-lookup the target host. Also, most of the websites out there (Yahoo and CNN included) already have a whole buttload of systems serving webpages (using multiple-record DNS), and not just a single address. The DDOS clients obviously already make this a non-issue, and probably just jam the upstream servers anyway.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: TTL of 0?!? (none / 0) (#5)
by eann on Mon Apr 03, 2000 at 12:18:02 PM EST

Somehow, I missed that TTL=0 when I read the article. Anyway, I picked a couple of likely DDoS targets (some of which have already been hit), as well as a couple of other sites most of us know, and wondered what kinds of TTLs I would find. So I asked the primary nameserver (as reported by whois to whois.networksolutions.com) on each domain:
  • www.ask.com - 5 minutes
  • www.yahoo.com - 15 minutes
  • www.advogato.org - 1 hour
  • www.lycos.com - 1 hour
  • www.slashdot.org - 1 hour
  • www.technocrat.net - 1 hour
  • www.cnn.com - almost 3 hours
  • www.etrade.com - almost 4 hours
  • www.kuro5hin.org - 10 hours
  • www.ebay.com - 24 hours
  • www.google.com - 24 hours
AskJeeves and Yahoo! are likely the only big-name sites listed that could get away with reducing the TTL. And, at least in the case of Yahoo!, I think I could make a case that the user experience would suck 99.9% of the time when they're not under attack, to potentially save some trouble during the small time that they are.

Without any statistics on exactly how often these nameservers are hit, and without going back to see which seem to be on different network segments than the hosts they're providing DNS for, I'm going to stick with my earlier comment: the proposed solution is not practical for sites with heavy traffic, especially if they run their own nameservice. And, as others have pointed out, if the DDos client is programmed to check DNS, it won't matter that much anyway.

If the Internet in general wants to prevent DDoS attacks, then the Internet in general is responsible for beefing up security to prevent them from being possible to begin with.

P.S. - an afterthought: is the so-called Slashdot Effect different and/or distinguishable from a DDoS attack?

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.


[ Parent ]
Re: TTL of 0?!? (none / 0) (#6)
by fluffy grue on Mon Apr 03, 2000 at 12:49:25 PM EST

My impression of DDOSes, and DOSes in general, is that they use mostly ICMP and low-level IP rather than TCP-based stuff, so at least from that point of view the /. effect looks somewhat different than a typical DDOS. Of course, it's just a TCP-level DDOS instead, which can be even more insidious.

There are, on a related note, some very fun purely-TCP-level DOSes on older versions of Apache which took a long time to parse /s out of GET strings. One of them (called 'beck' IIRC) is quite effective against Apache 1.2.x, and it's a very simple attack to do which any skript kiddie can understand.

The main reason most DOSes happen at the lower level, in any case, is because full TCP sessions nearly-impossible to spoof properly due to the three-way SYN-based handshake, and so there's no easy way for the attacker to hide their identity. In a DDOS situation, however, it's probably not so much of an issue, especially if it's fired through cron or at from a compromised account which is normally used a lot and was compromised long enough back that the origin of the compromise can't be properly determined.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

darn! (none / 0) (#7)
by xah on Mon Apr 03, 2000 at 12:59:55 PM EST

Darn! I was hoping to be the first one to successfully cross post to both Slashdot and Kuro5hin! Congratulations to the winner, whoever you are.

Apologies if the two posts are actually different. They look pretty close to me.

Re: Defeating DDOS (none / 0) (#8)
by Inoshiro on Mon Apr 03, 2000 at 07:22:51 PM EST

This solution does not seem effective at all.

From my understanding of the situation, packets (not complete TCP sessions, as pointed out by Fluffy Grue) used to flood the server. How hard is it to, in case of a sudden kick up in traffic, filter packets that are not complete TCP session handshakes? It'd ignore other packets, such as bogus ICMP responces, etc.

It's also interesting to question which service is under attack. In all the DDoSes I know about, the goal was to deny HTTP access to a site. Why not offload all other services (FTP, DNS, email) to an alternate server, and place the HTTP system behind a load-balancing router with the traffic shaping/illegal packet ignoring mechanism implemented? I really don't see the need for a "stub" network when a simple RST would suffice.



--
[ イノシロ ]
Defeating DDOS | 8 comments (8 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!