Slashdot Mirror
Why Google Went Offline Today
New submitter mc10 points out a post on the CloudFlare blog about the circumstances behind Google's services being inaccessible for a brief time earlier today. Quoting:
"To understand what went wrong you need to understand a bit about how networking on the Internet works. The Internet is a collection of networks, known as "Autonomous Systems" (AS). Each network has a unique number to identify it known as AS number. CloudFlare's AS number is 13335, Google's is 15169. The networks are connected together by what is known as Border Gateway Protocol (BGP). BGP is the glue of the Internet — announcing what IP addresses belong to each network and establishing the routes from one AS to another. An Internet "route" is exactly what it sounds like: a path from the IP address on one AS to an IP address on another AS. ... Unfortunately, if a network starts to send out an announcement of a particular IP address or network behind it, when in fact it is not, if that network is trusted by its upstreams and peers then packets can end up misrouted. That is what was happening here.
I looked at the BGP Routes for a Google IP Address. The route traversed Moratel (23947), an Indonesian ISP. Given that I'm looking at the routing from California and Google is operating Data Centre's not far from our office, packets should never be routed via Indonesia."
And I thought the internet was a series of tubes...
I didn't even notice Google was down. This must have been a horrible outage.
... Network Admins who have no clue. Like when just 4 years ago, Pakistan took down Youtube...
http://securitywatch.pcmag.com/dns/285152-pakistan-takes-youtube-down
Clearly this should be on the agenda for the new "Cyber Reserves" of the department of Homeland Security. If Google can be taken down by accident in parts of the world, then it certainly can be taken down on purpose. Route filters are your friends!
CYBER RESERVES: http://www.techradar.com/news/internet/department-of-homeland-security-recruiting-for-cyber-reserve-1109906
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
OMG :-P
Another networking issue that is probably never going to go away, I'm just surprised it isn't used more maliciously than it is. - HEX
Horror & SciFi Erotic Nudes
Can this system of Network addresses and border gateways also be protected by DNSSEC? It seems like a pretty wide open way for mischief. It seems like it should all be part of BIND, but then I know just enough about IP routing to get m'self in trouble :-)
I hope my job application with Google wasn't misrouted as well...
I bet it was :\
Just gotta unplug the battery and plug it back in. It should be running in a few minutes.
I didn't notice or know about it at all. Everything seemed ok here.
From TFA:
Someone at Moratel likely "fat fingered" an Internet route. PCCW, who was Moratel's upstream provider, trusted the routes Moratel was sending to them. And, quickly, the bad routes spread.
Yes, someone at Moratel screwed up, but this is exactly why upstream ISPs should never allow advertisements from their customers for networks that their customer does not control.
PCCW is to blame for allowing this to happen. Never trust customers with things that don't belong to them.
Grammer Nazis - I mod you "troll" unless you actually add something on-topic. Yes, I know I have mispellings in my sig.
This sort of 'feature' did allow me once to escape from a misbehaving ISP holding me hostage and preventing me getting my mail to, for example, change my DNS glue records many many years ago. A helpful friendly new ISP managed to reroute traffic to me via them with a "bogus" routing announcement long enough for me to fix those records and then escape the old ISP when the new records propagated.
Rgds
Damon
http://m.earth.org.uk/
Seriously, a porn link in your sig?
Anyway... clearly Anonymous hasn't learned how to delete BGP filters and inject fake routes yet.
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
Hardware failure? Sure, Indonesia hasn't attempted to censor the internet so far.
China Telecom also hijacked web traffic to US government websites in April 2010 for 17 minutes. At least that incident seems to have been a purposeful disruptions to capture sensitive data and/or try out a novel cyberwarfare tactic.
Errr, yeah, what about that porn link? That's really... that's awful. I can't believe that they would have that there. Man, porn. Anyway, I've just got to go and do... a thing. Nothing interesting, don't you worry about it, just... Go about your business.
Since when does erotic nudes immediately equal "porn", and clearly you haven't visited the site.
This is why I use Macs and iOS devices. Safe, secure and virus-free.
What.
The cyberweapon that could take down the internet
http://www.newscientist.com/article/dn20113-the-cyberweapon-that-could-take-down-the-internet.html
More on BGP Attacks â" Updated
http://www.wired.com/threatlevel/2008/08/how-to-intercep/
http://dankaminsky.com/2008/08/27/the-emergence-of-a-theme/
"Flyin' in just a sweet place,
Never been known to fail..."
He may be, but you're a putz for writing that statement, since the security of your device has nothing to do with this issue.
Your Mac and iOS devices would also not be able to reach google in this scenario. Maybe that's what he meant....but really, probably just retarded.
"To understand what went wrong you need to understand a bit about how networking on the Internet works."
Perhaps Google ought to know a bit about how networking on the Internet works?
Do the editors even read the submissions?
I get the feeling that upstreams should start to not completely trust BGP announcements from peers. I know in my firewalls the configuration knows which networks ought to appear where, and the rules are set to block traffic when that network shouldn't be able to appear on that interface. Perhaps it's time to look into having an administrative communication of which ASes each peer ought to be handling, and having the BGP system at the upstream filter out or ignore announcements for ASes that that peer isn't supposed to be handling. The problem I see with that though is that it works well at the edges, but the closer to the core you get the larger the list of potentially valid ASes and I can see it getting unmanageable pretty quickly. But with the number of these incidents, I think we need to do something to change the assumption that you can unconditionally trust peers to only hand you valid routing data, because that assumption pretty clearly isn't true anymore.
A BGP attack matched with a cert. leak could yield you on a spoof site, and you would provide your credentials to that man in the middle whichever device you are using. Except if you are using google chrome, where you might understand with the pinned certificate error that something is not correct, or with an android device that you were so eager to dismiss...
Here's an iOS virus for you http://www.ibtimes.com/apple-ios-app-store-gets-first-virus-learn-about-app-steals-your-contacts-and-spams-your-friends
Since when does erotic nudes immediately equal "porn", and clearly you haven't visited the site.
Since it all goes in the spank bank. Different places maybe, but same bank.
That's a Trojan not a virus.
Seriously, a porn link in your sig?
Anyway... clearly Anonymous hasn't learned how to delete BGP filters and inject fake routes yet.
The only reason you replied was to bookmark!
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
Doesn't meet the definition of virus. It's a trojan, and also available for Android. It was pulled from the iOS App Store, no mention if it was pulled from Google Play.
It was not really the language that concerned him, but probably the lack of being on-topic.
I don't know what says more about the change in the average Slashdot reader--the fact that the summary for this story assumes that the reader doesn't know anything at all about BGP, or the fact that this is the first comment to bemoan that.
We don't do Porn, we try to keep on the erotic art side of things, and thanks for drawing attention to it lots of visitors from your mention! - HEX
Horror & SciFi Erotic Nudes
...to be fair, you *are* using a TLD explicitly intended for porn.
LegendMUD
Don't worry, We at the Nigerian Non Scammers Search Placement Company got your job application. To complete your job application we just need your bank account number, Mothers maiden name, and whatever other personal information you may have.
The Google logo got caught with its hand in the ballot box cookie jar! It's all over Google's front page!
Since when does erotic nudes immediately equal "porn"
Since it's in the top-level domain that's the Roman numeral for thirty.
Why bother breaking into systems when you can reroute them into your private network and use MIM attacks. It seems if you are a well connected pipe and you make sure the route can complete it would be possible to use bad bgp advertising to pull in a targets traffic, sniff it then forward it back to it's correct location out a different pipe.
Oh, really? I thought Route Origin Authorisations were designed to address exactly this issue?
Do you care about the security of your wireless mouse?
Strategic decision, while I do own the hex.ms domain I knew once .xxx came out it would be as recognized and memorable as the big three .com/.net/.org and just try getting a three char name on one of those. :P Also when we started we wanted the "freedom" to do "porn" if the story/script supported it, but the major issue is the credit card companies, we wouldn't be able to use Paypal, etc, so we dropped the idea. - HEX
Horror & SciFi Erotic Nudes
I call in the networking team/group when it gets to this point, but I've seen it happen so often behind the scenes at Fortune 500's as well as publicly like this occurrence to have heard that it's "un-fixable by design" from those networking folks. Glad to see some progress is being made to really fix the issue. - HEX
Horror & SciFi Erotic Nudes
Google keeps having error messages and random reloads on Gmail, Adsense, but not in Adwords at least. Their websites are dependent on JavaScript and the scripts can not cope with load errors, so they keep reloading the page until the servers are overloaded. I suspect that they are not aware of this too, becasue I have seen it last month already and they did nothing. I suspect that they run buggy code.
~ Best man at your service.
I read slashdot. I'm not an idiot. How about referencing articles and quoting sources that aren't for end users.
It's just that the link is right above the "Reply to This [comment]" link. Easy to click by accident. Somebody slashdoting from work may get in trouble or worse. And as for some other comment in this thread, no obviously I haven't clicked on it... I'm at work. Wait let me fix that... I'm at "work". Ok.
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
ZOMG HAX!
No wonder no one replies to me, they are all distracted by my link and visit my site instead! A bittersweet win-win situation! As for visiting from work, no one sets their alert threshold that low for even adult material, sure you might get a blocked page but you won't get HR on your back for it. Of course my area and level of IT we're exempt from filtering usually, too many good resource sites get erroneously filtered. (and we implement the filters lol) - HEX
Horror & SciFi Erotic Nudes
If I'm properly filtering at the border, I don't need to filter in the middle
You absolutely have to filter when crossing an international border. National security requires it. Maliciousness can be of a military nature, and you'd better be expecting it. The network admin on the other side may be coerced, an eager participant, or unaware. You ever can't trust what he does or what he says.
If BGP abuse lets China detect a previously-unknown site that communicates with a known US spy agency, China has learned something valuable.
Almost all BGP capable equipment at most exchanges is now able to filter the amount of address blocks each ISP can announce. Once someone starts announcing a whole lot more than the filter is set for, the announcements are ignored and alerts are triggered.
While that mitigates problems, the actual solution is already being put in place. IP address blocks are being assigned to parties and those parties can sign routing announcements for those IP blocks using a PKI system. By having the BGP equipment check each request with the public key of the published "owner" of the block, rogue announcements should be ignored. Not all equipment is capable of this and not all exchanges have made this mandatory, but this will most likely happen in the future. Sure, by stealing keys, finding weaknesses in the implementation of router vendors and such, attacks will still be possible, but admins making mistakes will hopefully not mess up things anymore.
This works perfectly for end points in routes, but I am not certain how routes through someone's AS to another AS are being dealt with. I assume you can tag certain ASes as "transit AS" and accept unsigned routes from them. That would make you still vulnerable for rogue announcements through those ASes, but only if those providers didn't use signed announcements and filters on how many netblocks a peer could announce.
I was promised a flying car. Where is my flying car?
UCLA's Cyclops is a great tool to monitor your own IP space and make sure you know immediately when this sort of this occurs.
Is that you?
Why the hell not? I thought the reason for the internet was to provide a way for data packages to get to their destination without having to have a particular fixed route. Does it says somewhere in the internet standard that data packets *must* be delivered using the shortest route possible?
So S-BGP don't prevent this to happen? is it in use already? or is just vaporware?
Here's a summary of the summary: someone broke the internet. That's right, "the internet is broken" actually applies here, lol.
Sounds like a use for ROVER (Route Origin VERification) being discussed at IETF.