Six worst Internet routing attacks
Here's our list of the biggest security incidents involving the Internet's core routing protocol, the Border Gateway Protocol. Some of these incidents were attacks; others were accidental misconfigurations. But all of them disrupted traffic to Web sites or entire networks because of incorrect routing messages being propagated across the Internet through BGP. (Read the latest on U.S. government efforts to secure BGP, and about four open source BGP tools.)
Pakistan Telecom blocks YouTube
In February 2008, Pakistan Telecom inadvertently brought down the entire YouTube site worldwide for two hours as it was attempting to restrict local access to the site. When Pakistan Telecom tried to filter access to YouTube, it sent new routing information via BGP to PCCW, an ISP in Hong Kong that propagated the false routing information across the Internet.
ICANN puts root server at risk
The Internet Corporation for Assigned Names and Numbers (ICANN) screwed up in November 2007 when it renumbered the DNS root server "L" that it operates. ICANN failed to notice several unauthorized L root servers operating across the Internet until six months later. By May 2008, ICANN had all the bogus L root servers turned off.
Malaysian ISP blocks Yahoo
In May 2004, Yahoo's Santa Clara data-center prefix was hijacked by DataOne, a Malaysian ISP. Network security experts say the incident was malicious, with DataOne intentionally trying to block traffic from Yahoo. The Yahoo attack involved the hijacking of two of its in-use prefixes.
Northrop Grumman hit by spammers
In May 2003, a group of spammers hijacked an unused block of IP address space owned by Northrop Grumman and began sending out massive amounts of unwanted e-mail messages. It took two months for the military contractor to reclaim ownership of its IP addresses and get the rogue routing announcements blocked across the Internet. In the meantime, Northrop Grumman's IP addresses ended up on high-profile spam blacklists.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
On Twitter now
security
Powered by Twitter
jfruh
Apple syncing patent can't come soon enough
pasmith
New Twitter features borrow from 3rd party clients
Esther Schindler
Open Source Changes the Software Acquisition Process
mikelgan
How to set up continuous podcast play on the new iTunes
David Strom
Five important Windows 7 mobility features
sjvn
Guard your Wi-Fi for your own sake
Sandra Henry-Stocker
Grepping on Whole Words
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.













Wrong folks to slam.
Carolyn,Having been intimately involved in the event, I can say with some authority that the second item on your list, "ICANN puts root server at risk" is simply wrong and most definitely did NOT "[disrupt] traffic to Web sites or entire networks because of incorrect routing messages being propagated across the Internet through BGP."
For historical reasons, ICANN had been using an address for the L root server that was allocated for the purposes of number Internet exchange points (which, at the time, I would argue was a reasonable choice). When ICANN undertook to improve the L root server infrastructure, we decided to renumber to a new address dedicated to the L root server. ICANN followed standard procedures in announcing the renumbering of the L root server, including a transition period when we continued to answer DNS queries at the old L root server address. Unbeknownst to us, however, another individual associated with the root server operators took it upon himself to enter into an agreement with a third party to serve the exact same DNS root data at the old address. Since during the transition DNS queries were still be answered at the old L root server by design, the fact that someone else was answering DNS queries with the same data was not obvious.
When ICANN turned off the name server at the old L root server address, we immediately noticed answers kept coming back to queries sent to that address. Within minutes, we had ascertained what was happening and undertook to have that unauthorized root DNS service discontinued. The fact that it took a few days for the unauthorized service to stop is a function of the lack of centralized control of the Internet and I doubt you are suggesting that this be changed. The fact that no ISP, security organization, network monitoring group, etc., noticed the fact that the old L address was being announced may also say something.
However, throughout this incident, the L root server was NOT at risk and no traffic was disrupted. If the DNS server responding on the old L root server address had responded with anything other than correct data or had responses been disrupted in any way, it would have been quickly detected and remedied. Where ICANN could have done (and now does do) better was monitoring the routing system (not just the destinations) to detect unauthorized announcements of critical Internet prefixes.
Having read your work in the past, I have felt you were a cut above many of the tech journalists I have read or been interviewed by. I am disappointed you would slam ICANN for "screwing up", particularly when the problem you write about doesn't even meet the criteria you yourself set for being among the "six worst Internet routing attacks" and the presentation you reference states there was no evidence of any disruption.
Regards,
-drc
バッテリー
大阪でバッテリー販売。 セルモーターリビルト。 オルタネーターリビルト。リビルト在庫多数。大阪で電装品販売。リンク品在庫多数。大阪でウイング車モーター修理・販売・在庫多数。大阪でパワーゲート車モーター修理・販売・在庫多数。