Internet Backbone DDOS "Largest Ever"

wontonenigma writes "It seems that yesterday the root servers of the internet were attacked in a massive Distributed DoS manner. I mean jeeze, only 4 or 5 out of 13 survived according to the WashPost. Check out the orignal Washington Post Article here."

Comments

Well there we go!

[MattCohn.com]

If the servers can withstand the attack without going compleatly down, I guess they know they did something right.

Article:
"Despite the scale of the attack, which lasted about an hour, Internet users worldwide were largely unaffected, experts said."

All I can say is that if you think of this as a test, I'm happy it passed.

(Insert joke about Beowulf cluster of DDOS attacks / the servers ability to withstand the slashdot effect.)

Re:Well there we go!

[Grit]

The attackers were idiots. They used ICMP echo requests (easily filterable, since the DNS servers don't _have_ to answer those) and quit after an hour. More publicity stunt than actual attempt to damage, IMNSHO.

I've been trying to publish a paper about exactly this (and how to redesign DNS to avoid the vulnerability) and I'm just pissed that they didn't tell me in advance so that I could do some measurements. :)

Before anybody gets their panties in a knot

[Indomitus]

This attack has generally been considered "piddly and unintelligent" according to people who are actually in charge of running things on the net. Here's a good quote from the NANOG mailing list:

"when uunet or at&t takes many customers out for many hours, it's not a problem
when an attack happens that was generally not even perceived by the users, it's a major disaster
i love the press"

With something like the root nameservers, if it was an important attack, you would have noticed. I run an ISP and we had zero complaints, even from the Everquest whiners who complain at the drop of a hat about anything.

Re:Couldn't have been that bad...

[kennylives]

FWIW, I did see massive problems. I had done a Google search for mountain bikes, and only 1 in 5 sites would resolve. I popped open a terminal window to cross-check some of the failing queries against a different nameserver, and nslookup/dig would hang or timeout on the ones that Mozilla had a problem with. Very annoying, to say the least.

Twenty minutes later, though, everything seemed fine, and the sites that wouldn't resolve earlier finally did. I wondered if something... erm.. unusual was going on, and it looks like there was...

As always, your mileage will undoubtedly vary...

Re:oh my...

[Dionysus]

I doubt the root servers run on Windows.

And *nix systems are infinitely more scriptable, so I think it's more likely those were used for the attack (if I remember correctly, unsecured Linux where used for the big DDOS attacks on Yahoo and Ebay etc some years ago).

Re:And...

[nege]

doesnt have to be your own ISPs DNS servers though right? I have been using earthlink's for about 3 years though have not been a customer of theirs...

Re:undisclosed location

[Anonymous Coward]

I mean, if I were a terrorist and read this, I'd immediately start salivating and try to find out as much about Verisign as possible -- everything from employee car rentals and hotel rentals to phone calls, merchandise, shopping... id do everything in my power to find the 'undisclosed location'. Is this another weakness that hasn't truly been protected yet?

Disclaimer, I work for VeriSign. This is a personal opinion, not company policy. The details of the disaster recovery scheme are of course confidential. However I can tell people that we did think about these issues during the design. We have always known that people might think the DNS was a single physical point of failure for the internet. That is why we designed it so that it is not.

There are multiple locations. The 'A root' is NOT a single machine. There are actually multiple instances of the A root with multiple levels of hotswap capability.

Incidentally it is no accident that the VeriSign root servers stayed up. They were designed to handle loads way beyond normal load. The ATLAS cluster is reported to handle 6 billion transactions a day with a capacity very substantially in excess of that.

Even if all the A roots were physically destroyed the roots can be reconstructed at other locations. Basically all that is needed is a site with a very fast internet connection. In the case of a major terrorist attack AOL or UUNet or even an ARPAnet node could be comandered. The root could even be moved out of the country entirely, British Telecom is a VeriSign affiliate, there are also several other affiliates with nuclear hardened bunkers.

Most Americans have only been thinking about terrorism since 9-11. VeriSign security was largely designed by people who thought about terrorism professionaly, unless of course they were in charge of securing nuclear warheads.

All a terrorist could do is to kill a lot of people, there is absolutely no single point of failure. Even if the entire constellation is destroyed it would result in an outage of no more than a day given the resources that would become available in the aftermath.

Re:And...

[Istealmymusic]

Yes, IP is more important than DNS. But is Ethernet more important than TCP?

I would draw an opposite conclusion

[xant]

piddly and unintelligent

Fine, so the attack was unintelligent. What will happen when someone attacks MAJORLY and INTELLIGENTLY?

This gets my panties in a knot. A piddly attack brought down 65% of the root name servers! A good attack would have brought them all down! That doesn't that worry you?

Re:I work for JPNIC

[Mike Schiraldi]

HACZBY : FADABOI
CORPZ : MVDOMIZN HELLO TO KOTARI ON UNDERNET

Well, this shouldn't take the FBI long. A quick Google search shows that Undernet's Kotari owns the domain www.kotari.com, which he's recently taken down but still shows whois records..

Running NT and BIND?

[Inoshiro]

Why?

It's really easy to setup a system which dumps your SQL database out to a TinyDNS file. TinyDNS is provably secure software. I would expect that you would use it on the root servers, since it's designed to work at very high levels of output/uptime, and be attack resistant to the point of being attack proof.

Say what you will about D. J. Bernstein, he does have a very capable DNS solution available.

The important caching

[billstewart]

It's not just caching the pointers from . to .com or .zr, it's the caches of the 2LD names in .com that matter. (.org and .net are important, but .com is the really annoying failure. And country-code name service gets handled elsewhere, though taking down .co.uk might be a target also.)

For the most common 2LD names, any major ISP will have cached the addresses for them, and won't need to hit the .com server until the typical 1-week or 24-hour cache timeout periods. If your nameserver is ns.bigisp.net, somebody there will have looked up google.com in the last 2 seconds, even though nobody at your ISP has looked up really-obscure-domain.com this week - but even that one may be in the cache because some spammer was out harvesting addresses. An obvious scaling/redundancy play for the root servers and for the major ISPs would be to have them cache full copies of the root server domains to keep down the load and reduce dependency. It's not really that much data - 10 million domains averaging 30 characters for name and IP addresses is only half a CD-ROM. An interesting alternative trick would be for the Tier 1 ISPs to have some back-door access to root-level servers for recursive querying.

Comment removed

[account_deleted]

Comment removed based on user account deletion

WD40

[driehuis]

Most good routers are designed to have the ability (if you enable it) to look inside of the packets

Hmmm, last I looked at the Cisco feature set (or the like from Foundry and Nortel and what have you), it was a challenge to put in rules that
a) didn't take out significant "good" traffic, and
b) did take out significant "bad" traffic.

I agree that rate limiting ICMP traffic is an appropriate answer, especially in the light of this particular attack, but I'm appalled by the number of illitarate dorks who copy snippets titled "how to block all ICMP" from a textbook into their firewall without the slightest understanding of why ICMP was implemented in the first place.

I hate to think of what could happen if the 31334 hackers really start mixing attacks.

I positively _love_ wd40, but I will not apply it to reduce the squeeking of my cars brakes. Too many people use the Internet equivalent of WD40 on their network brakes.

DDOS Sophistication Varies

[billstewart]

The first time a given technique gets used, it may be sophisticated, but after that it's often just script kiddiez. Some attacks are pretty crude, just borrowing a few thousand 0wned machines and slashdotting a victim, but some DOS attacks really do use some insight and then use the distributed attack as a lever, or as a way to hide the source of the attack. The clever attacks look for the critical resources on the target machine and tie those up. Sometimes that's something like the TCP SYN attacks which create half-open sessions to clog tables, but those can be easier to block, and they often depend on forged source addresses, which can be traced by a persistent ISP. Other attacks look more like brute force - find the asymmetrically resource-intensive part of a real transaction (like doing CPU-burning digital signatures, or downloading a really big file or causing some thrashy database lookup) and flooding that with lots of real transactions from your zombies, which is harder to block without also blocking real transactions from real users. In some cases, the crude attacks also work well because the fix requires applications programming so it's not something your ISP or router can just block for you.

But, yeah, some of the attacks aren't much different than using a loudspeaker to announce "Free Beer at Victim.com"

Re:And...

[Kiwi]

The reason my DNS server does not have this is because this is best done at the networking level; in other words, setting up a firewall to not allow connections to the DNS server.

What my DNS server does is mandate an ACL (list of IPs allowed to make recursive queries; this can be set to "all hosts on the internet" if desired) if recursion (talking to other DNS servers) is enabled. Recursion takes a lot more work to do than authoritative requests; it is best to limit access to this.

Unlike Dan, I feel that a DNS server should be both recursive and authoritative because it allows one to customize the resolution of certain hostnames. The idea is similiar to /etc/hosts, but also works with applications which ignore /etc/hosts and directly perform DNS queries. For example, I was able to continue to connect to macslash.com when a squatter bought the domain and changed its official ip; I simply set up a zone for macslash.com, and made MaraDNS both recursive and authoritative.

SMTP servers have IP restrictions at the application layer because this gives people some idea why they can't send email to a given host. A firewall restriction gives a vague "connection timed out" message in the bounce email message; application-level filtering allows the bounce message to say something like "You're from a known Spam-friendly ISP; go away".

- Sam