Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs
Registrar Joker.com suffers attack
Robert Lemos, 2006-03-27
Comments Mode:
Single point of failure 2006-03-27
Todd Knarr (1 replies)
Re: Single point of failure 2006-03-28
Anonymous (1 replies)
Re: Re: Single point of failure 2006-03-29
Anonymous
Except that if all the DNS servers are on one network, the attacker only has to launch one DoS against that network. The part of the attack aimed at any one DNS server is aided by the traffic from the attacks on the other nameservers on the same network because all that traffic comes from the same pipe worth of bandwidth. If the DNS servers are on two networks though, each with an independent path to different parts of the backbone, the attacker has to launch 2 DoS attacks because the traffic aimed at one network doesn't affect the off-network nameservers. That means the attacker has to dedicate 2 or 3 times as much resources to the attack to make it work. A determined attacker can still manage it, but he's got to do a lot more work to make it happen.

And of course with nameservers spread out you minimize the collateral damage. In the Joker.com attack that one DoS took out hundreds of domains. If those domains hadn't depended solely on Joker.com for DNS hosting, it's unlikely that all of them would've chosen the same networks for their nameservers. That means that anyone who wasn't the direct target wouldn't have been affected at all because the attacker wouldn't have been going after their off-Joker.com nameservers and those would've kept their domain accessible. It also makes targetting a registrar for DoS infeasible since to take out a large percentage of their customers the attacker would have to DoS not one or two but hundreds of different networks, a feat beyond the means of any known botnet.

And as a plus, distributing your DNS servers provides a protection against backhoes, switches electing a new pope and the like.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/newsbriefs/172/845#845







 

Privacy Statement
Copyright 2009, SecurityFocus