Tuesday evening's distributed denial of service (DDoS) attack on the
13 copies of the U.S. root server should serve as a warning to every
company employing DNS, said the inventor of the technology Wednesday.
Paul Mockapetris, who was one of the primary architects on the DNS
project and currently serves as chief scientist at Nominum, a DNS
consulting and management firm, said there is nothing in particular a
company can do against a threat as unsophisticated -- yet effective --
as a DDOS using ping floods.
Essentially, ping flooding -- the unceasing transfer of ping requests
to a DNS server from any number of computers -- is like a brute force
attack on a password or algorithm; the constant barrage inevitably
leads to a breach, or in the case of the U.S. root servers, a slowdown
or shutdown.
"There are more sophisticated attacks that are possible, and I think
that's really the danger from the standpoint of the root system,"
Mockapetris said.
The Internet Corporation for Assigned Names and Numbers (ICANN)
entrusted 13 organizations with copies of the U.S. root server, the
backbone for .com, .net, .org and others. According to Mary Hewitt,
ICANN spokesperson, the organizations at the affected sites were
running the latest security.
"I think the fact the servers were only down for an hour at the most
says something about our security," she said.
While there's not much a company can do against a DDoS, what people
need to watch out for, Mockapetris said, is the sophisticated attacks
that aren't always as easy to spot. In the case of ping flooding, the
attack is usually signaled by a massive influx in traffic, easily
visualized in a data traffic report.
Others aren't so easy to track, and are much harder to spot. DNS cache
poisoning happens when an attacker spoofs cache information and
redirects a network connection or blocks access. IP sequence
prediction attacks, on the other hand, grab the IP packet sequence
number from the victim's machine and trick the machine into thinking
its talking with a legitimate server. From there, the attacker can run
the server.
Mockapetris recommends every company check to make sure their DNS
server has the following:
A backup copy of the root server in case the "live" copy is
compromised.
The necessary infrastructure in place, so that if a company is brought
down by a DDoS it doesn't affect the entire network. Mockapetris
suggests a separate server for intranet communications.
Capacity is key - prepare in advance for a DDoS attack by having twice
the capacity available as used on a daily basis. That won't always
work, he said, because Tuesday's attacks spiked at 10 times the normal
capacity. But any extra capacity will help.
DNS is one of those unglamorous areas of IT that nobody thinks much
about until something goes wrong. Case in point: last year
Microsoft.com (Quote, Company Info) was broughtto its knees for almost
a week because an attacker found a point of weakness in the company's
DNS.
The cause of the collapse? A flaw in the company's DNS infrastructure,
where there was only one router standing between Microsoft's internal
network and its Internet connection. Shutting down the site was the
relatively easy matter of finding a weakness in that one router.
Although Microsoft had many servers segmenting its network, there was
only one DNS handling all the different network.
Paul Mockapetris' name was originally spelled incorrectly and has
since been corrected. Internetnews.com regrets the error.
I thought the Microsoft fiasco was down to incorrect maintenance
on the router, not malicious action, but either way the lack of
redundancy was inexcusable.
The Washington Post covered the DDoS story as well, but it was a
non-event from the end user perspective, just as it was designed
to be, although I agree more sophisticated attacks could cause
problems.
Using ICMP echo and going for the root servers was a triple
whammy, easy to sort from genuine traffic, using a type of
traffic often bandwidth limited in routers, and attacking
probably the best protected, connected and diverse set of name
servers. I'm guessing someone found these tools lying around
somewhere, and tried them out without thinking about what they
were trying to do.
Simon> I thought the Microsoft fiasco was down to incorrect
Simon> maintenance on the router, not malicious action, but either
Simon> way the lack of redundancy was inexcusable.
Indeed. IIRC the spin M$'s PR people put on this fiasco was the
problem had been caused by a malicious external attack. That deflected
people away from the root cause: M$'s appallingly bad DNS set up. Now
it seems this myth about an external attack has taken over from what
really went wrong. There *was* a DoS attack: somebody at M$ was stupid
enough to put all their name servers for microsoft.com behind one
router -- well duh! -- and then somebody else at the company screwed
up the configuration of that single point of failure.