Router Holes in BGP Threaten Net 177
Vishal Mishra writes "The widely used Border Gateway Protocol (BGP) for efficiently routing data through the Internet, is rife with security holes and needs to be replaced.
Some 12,000 routers that act as the gateway to approximately 130,000 networks are currently using BGP. A router running BGP can communicate with its neighbors, essentially telling them to which networks the router can efficiently send data. Check out this ZDnet article that says 'A compromised router can cause chaos by advertising itself as the best path to any significant network. That's because routers using BGP implicitly trust their neighbors on the Internet--they don't ask for any sort of digital identification.'"
Identification is of no use (Score:5, Informative)
- Andreas
Re:Identification is of no use (Score:2, Interesting)
Could, for example, some little bastard at home throw off his cable provider's network by routing all traffic to his neighbor's house, by re-signaling some router that doesn't know better, using his neighbor's MAC address?
Unless Im talking out my ass here (quite possible, IANANetworkExpert) this sounds like it has the potential to be a DOS-like attack without the hassle of finding machines to carry it out. Just re-route and watch the overload, like an ICMP storm against a 14.4...
Re:Identification is of no use (Score:5, Informative)
BGP is a connection-oriented protocol that runs over TCP. A BGP session is set up between two routers when the router's administrators tell those routers eacho other's IP addresses. Things like Access Lists and Filters control what is transmitted and received - it's not open slather (unless it's very poorly configured.)
BGP generally runs on major network routers only - often called Border routers - and these are the routers that interface one large network with another.
This is why BGP is called an Exterior Routing Protocol, as opposed to an Interior Routing Protocol - it's used for one large network (generally an ISP or something of that size) to talk to another. Within that large network an Interior Routing Protocol like EIGRP, OSPF or RIP is used.
The chances of "some little bastard at home" being able to get anywhere near a router running BGP is slim at best.
Re:Identification is of no use (Score:1)
Re:Identification is of no use (Score:4, Interesting)
Thats not to say the original article isn't overhyping it. You can bring the internet down that way, but its an awfully hard way to do it, only affects some chunks are is much easier to fix than many other attacks.
With computing security as poor as it is why would a terrorist go to so much unneccessary trouble
Re:Identification is of no use (Score:2)
Other than watching my boss turn new shades of red and screaming nothing much happend and life went on.
Re:Identification is of no use (Score:2)
Re:Identification is of no use (Score:1, Interesting)
Re:Identification is of no use (Score:3, Interesting)
This isn't something that can be fixed on napkins over dinner. And it's technically not something that needs new (read: overly complex) technology to fix. If the '97 incident was as serious as the article indicates, why don't I remember it? I remember some idiots stealing 199.72.1.0/24 and pissing us off for a few days. BGP has long since ignored 0/0 (unless instructed otherwise), so "[advertising] best route to the entire internet" would be over 120,000 route entries at this very moment. (things to be considered... as-path length, prefix-length, metrics which nobody sends, and locally configured preferences.)
Re:Identification is of no use (Score:2)
"which is pretty difficult to pull off."
And since there aren't to many reports about this even though the technology is wide spread, I'd say that this looks to me as a news-duck!
Re:Identification is of no use (Score:3, Informative)
All sane ISPs verify the routing updates versus access lists that are generated from routing registries like RIPE. Any routes that do not match what is declared publically and matches address space are discarded.
If you take routing updates without verification you get whatever you dererve.
Re:Identification is of no use (Score:2)
Even in the event of compromise, identity would be useful. It would allow other networks to explicitly ignore the offending router until it was fixed. Changing the ID wouldn't help the attacker since then it wouldn't have a trusted identity at all.
It would seem that a simple strategy of phasing in signed messages would help. Once providers get routers that can check signatures, they can require new downstream routers to sign messages. In the interem, they could at least keep track of who said what amongst the routers that do support signatures.
Re:Identification is of no use (Score:2)
Now, you could cause some problems by polluting IBGP routes, but that would only affect one ISP, and maybe any of their customers it has that use BGP to get only a default route (Fairly common for hulti T1 customers wanting failover).
But between AS's, route advertisment acceptance is based off agreed upon access or prefix lists. And you can't spoof another router, because hop-counts greater than 1 must be explicitly configured, and nobody sane sets ebgp multihop to be greater than 2.
Re:Identification is of no use (Score:2)
Generally, if the router the customer is peering with breaks, the customers circuit is down, so there's no point in doing multihop longer than 2(2 is so loopbacks work).
Possible Ideas (Score:1)
Re: You are right (Score:1, Informative)
--
Andre
Re:Possible Ideas (Score:2)
It's entertaining to see what people with only theoretical knowledge of backbone routing (Like Stephen Dugan) come up with for mythical security holes.
Re:Possible Ideas (Score:2)
Discovery only has one computer (HAL), so why would it have routers?
Router Holes in BGP Threatens Net (Score:4, Funny)
How? (Score:3, Interesting)
do you have to get physical access to it? i've not really heard of people hijacking routers, anyone have any info on this?
not that i fancy trying it, just interested
Re:How? (Score:2, Informative)
However, the article talks about weaknesses in the protocol as well as configuration problems.
However, a misconfigured router, or one that has been compromised by an online intruder, can cause chaos by advertising itself as the best path to an unrelated network
The problem is caused by the BGP protocol and the fact that the routers trust each other for information. Insert "trusted" script kiddie here. - chaos ensues.
Re:How? (Score:3, Insightful)
Access Lists and Prefix Lists.
So you need to comprimise a router which has a peer that was configured by rabid monkeys in order to break anything.
Backbone NOC's are extremely paranoid about this sort of thing, and the Author of the Article in question rather obviously know sweet fuck all about BGP.
Re:How? (Score:2, Insightful)
Re:How? (Score:5, Informative)
Re:How? (Score:2)
To secure a router for remote access, I would set up an ACL which would permit Telnet traffic destined to the router from certain IP addresses only, and deny telnet traffic from everywhere else.
Re:How? (Score:3, Interesting)
Re:How? (Score:2, Insightful)
*Sigh*
Granted, cisco routers are great, but they're also hella expensive.
We use a Linux based router, with 3 Dual T-1 cards (cyclades PC300's).
We run Zebra (emulate cisco, more or less) and bgpd (bgp service).
Because we're using our own software, we can do several really cool things.
One: Disable access to the router outside of the internal network.
Two: Disable telnet access.
And, a really cool third:
Multi-homed BGP, for those of you who don't know, is used for best route selection when your router is connected to two or more links. Roughly. Sort of. Search google for "Avi freedman doc BGP". It's really for announcing your network (autonomous system) to other routers, but it does the deciding on what to announce... anyway...
Unfortunately, one thing it doesn't take into account is bandwidth saturation on the network. We have one provider (sprint) who provides the bandwidth to another of our providers (ntelos). So, the route for Ntelos is at least two hops longer. As a result, our one T-1 through sprint may end up being completely slammed, and both of the nTelos ones may have only 10-20k going out them because BGP has decided that the best way to get everywhere is to go out sprint.
We could just prepend our sprint routes a couple of hops, but that requires all kinds of multihop wizardry.
Enter our autoscaling package. It's a set of modifications to the BGP source (eat it cisco). What it does is calculate the bandwidth available on any one link, and shift routes around to links with more available bandwidth, so that all our traffic is balanced.
Granted, it may take a slightly longer time over a link that BGP didn't select for that route, BUT we feel that having traffic going out a link that may have a slightly longer pathlength is preferable to having all bandwidth fight for the one "preferable" link.
Ahh, the joys of open source.
Or, you can try and knock it offline somehow, then try and impersonate it to cause mischief. That's a lot more difficult though.
Yep.
For us, if we're getting an attack from someone, usually all we have to do is start dropping their packets. Keep in mind, most home connections are short on outgoing bandwidth, and we have gobs of incomming bandwidth to spare, so this is usually enough. Alternatively, if it's a huge attack, we just figure out where it's comming from, and call our upstream ISP, and they block packets for us. It's kind of hard to ping flood the Quest backbone =). R1d3 tha L1gh7, script kiddies.
Also, another precaution we take is that we don't (can't) get into the BGP interface on the router unless we're already on the router, so unless someone on the internal network can sniff out a telnet connection to localhost, we're probably OK.
But, the point is well taken. If you have the password, you can cause havoc. Being able to secure your router because you have the source, and you can block accesses, does help, but it's not the end all be all.
Re:How? (Score:2)
Re:How? (Score:2, Informative)
SSH to it then login with your SecurID token. Make sure your IP address is in the ACL that allows access to the vty lines. Otherwise just attach a serial cable to the console or login to a terminal server that's attached to the router. What, did you think it was something easy like "Telnet to port 179 and type "login bgp"?
The only other time you're going to "compromise" a router is via extremely poor configs (like leaving default snmp communities setup like public/private or when there's a bug in one of the services like SNMP (happened a couple years ago) or SSH/Telnet.
Re:How? (Score:1, Funny)
20 PRINT "HELLO WORLD"
Well, it had a perfect track record until it encountered the lameness filter.
Oh, the irony.
Death of Internet predicted, film at 11... (Score:5, Informative)
Just about every ISP already implements route filters, so they will only accept expected routes from its peers. So if a rogue BGP speakers suddenly starts announcing a default route, not many (if any...) peers are going to believe it, keeping the impact on the global Internet next to nothing.
Several databases are used by ISPs to automatically build route filters, for example Merit's RADB [radb.net]. Although not every ISP participates in databases like this, all of them use at least a private scheme, unless they're especially small and/or clueless.
Secure BGP would be really nice (as would Secure DNS, etc.), since it would eliminate the need for a lot of manual and error-prone list maintenance. However, the infrastructure changes and (most importantly) the more difficult initial set-up for new sessions (need to authenticate and exchange keys out-of-band) will probably keep this from happening for a while.
Re:Death of Internet predicted, film at 11... (Score:1)
Re:Death of Internet predicted, film at 11... (Score:5, Interesting)
Well, that would depend on the nature of the compromise, and what exactly the attacker is trying to achieve. The worst case scenario as described by the article, the compromised router acting as some kind of global Internet default gateway, is unlikely to happen, though, for several reasons:
1. All peers of the compromised routers will have route filters in place. That means they simply will not accept announcements for unexpected address space, including 0.0.0.0/0;
2. Even if one or more peers are braindead, and have not configured route filters, the resulting traffic spike will cause link saturation, and thus the BGP session to go down at some point. The resulting flapping will definitely get noted by someone...
Of course, any situation where a router gets compromised is bad news, but even Secure BGP won't fix that: the current 'non secure' situation is a non-issue even in that light. Errors in protocol implementations, bad network security, etcetera are bigger problems, and can be mitigated today (by using IPsec to carry BGP traffic, amongst other things), without the BGP protocol redesign the article seems to want.
Re:Death of Internet predicted, film at 11... (Score:1)
Please... stop posting FUD to slashdot. It just sucks...
btw: This one was posted to "security" and the last ones were posted to "the internet" but who cares?
Re:Death of Internet predicted, film at 11... (Score:5, Informative)
This is correct in the case of small networks multi-homing with larger networks. Specifically, the 'upstream' peers (in the 'you pay them' sense) are ordinarily locked down to the point where you have to advise them BEFORE you add any additional prefixes to your BGP session with them, or they'll be silently dropped and you'll wonder why.
In the case of larger networks peering with a route server at a peering facility, this could be an issue. Considering the dynamic nature of the TLAs being advertised, the tier 1 (and to an extent tier 2) providers have to trust each other more or less implicitly. However, in the case of eBGP sessions at an IX, most everyone is only peering with one peer, the 'route server', and this box is likely to be about as locked down as they come.
CIDR provides a further saving grace - in order to cause mass chaos, one would have to advertise a prefix shorter than one already being advertised. Since most large providers in the states and elsewhere filter out almost everything shorter than a full TLA (/19) (there are exceptions to this, mostly concerning pre-1998 assigned class C nets), the best you could do is blackhole a random subset of traffic to a given block.
That said, considering the fact that 99.99% of the world's tier 1/2 BGP servers are run by competent admins who stand to lose their jobs and become gardeners or trash-os if their BGP routers get compromised and wreak the sort of havoc alluded to in this article, one can reasonably assume that they're secure. Additionally, (I know APnic does this, not sure about other RIRs,) the netblocks assigned for IXs are usually
I had a rad diagram here except the 'lameness' filter whacked it.
In an IX scenario, anyhow, all the routers speaking eBGP (as well as the route server) will be on unreachable IP addresses. The closest 'accessible' routers will likely be route reflectors peering via iBGP with both the eBGP 'peering' routers (unreachable) and the eBGP 'customer-side' routers (reachable, untrusted.)
So, to cut a short story long, this article is hype
Cheers,
MH
Routing Protocols (Score:2)
Anyway, If I crack (not gonna happen) a core router and advertise your network as living on fas0/0, then your network would cease to exist for a large portion of the internet. All the filters in the world will not stop that traffic from being shunted into oblivion.
Seems to me it would be just as effective as a DDoS. Well, not quite. A DoS would cost you bandwidth. The blackhole just causes you hits.
Of course, I could tell the router that every Class B lives on your line. Then the traffic would DoS you in a heartbeat.
Re:Routing Protocols (Score:2, Insightful)
Ahh, nothing more refreshing than another /.'er speaking out of his ass on a Monday morning.
You presume that anyone will listen to your advertisement and not ACL what they listen to from you.
Yet another /.'er speaking without any operational or technical experience. Wahoo.
darn, you beat me to it (Score:5, Informative)
Any network engineer who works for an ISP should tell you that the biggest likely problem with BGP isn't bad routes, it's BGP on a flapping connection, because until the auto-dampening kicks in, every time the circuit goes up, BGP restarts its handshake and route announcement, and when the line is just dirty enough to get lots of flaps but still some signal time, you get major load on the routers involved. The load from a flapping OC-12 can conceivably take down underpowered aggregate routers from some vendors, which can knock out entire regions of customers.
Now... think about how you connect in to fix one of those, if it doesn't stay up long enough for you to remote in.
Re:darn, you beat me to it (Score:2)
Re:darn, you beat me to it (Score:2)
You'd think so, except when the router is somewhere in Wyoming and there are no engineers on payroll near it, and the one nearest is a 4 hour plane ride away. Oh, and the insecure way the POP is laid out internally, you don't want anyone not on payroll, like a local contractor, getting entry.
Re:darn, you beat me to it (Score:2)
Re:darn, you beat me to it (Score:4, Funny)
Shush, you're ruining my nice example by being practical.
Re:darn, you beat me to it (Score:2)
At least have a plan in place to isolate the untrusted router from the network should things go haywire.
I mean, I'm no router god, but every router god I ever dealt with beat it into my head that you always have out of band access to your remote equipment.
Re:darn, you beat me to it (Score:2)
This is already covered in answers to other responses. Essentially, though, that's one good answer, and so is having the telco loop the circuit or otherwise disable it so it stops flapping and you can get to it through another line.
The example in reality that I'm thinking of involved an ISP that was bought out, and some of their backbone had yet to be suborned into the buyer's structure fully. Nobody left knew their term server dialin info, or if they even had one.
Re:darn, you beat me to it (Score:2)
You dial in to the modem attached to the AUX port.
Re:darn, you beat me to it (Score:2)
I didn't say the line stayed up long enough (remember, there are multiple lines, it's an aggregate), I said the router doesn't stay up enough. As in, would you even finish handshaking? Doubtful. But you could dial into a term server connected to it, then try to interrupt the loading process, reconfigure that flapping interface to be admin down, and so forth. Another good answer (as another reader mentioned) is to call the telco and have them shove the line down, like forcing a loop or something.
Re:darn, you beat me to it (Score:2)
All of that is true, and is why the sky won't fall anytime soon. However, it does strike me as 'fixing' the lack of a deadbolt for your door by hiring a guard rather than installing the deadbolt. In the IBM example, if the broadcasts from the small ISP had IBM's signature on them, you wouldn't need to do anything special at all to handle the change as long as you could obtain IBM's public key from an authoritative source.
As for the route flap problem, that wouldn't be so much of a problem if router's processors weren't so anemic.
Re:darn, you beat me to it (Score:3, Informative)
Properly implemented, routing object servers already provide this level of security. The downstream user has to modify the routing object, using his password/pgpkey/whatever, and he/she has to use his/her AS number when making the announcement. The AS is only accepted through his/her interface(s) (and those of other transit providers if he/she is multi-homed). The routing filters are built automatically incorporating the routing object server information, on a regular basis.
Everything stays smooth and secure, at least for the ISP side, because a compromise in the system almost certainly involves a broken password/pgpkey/whatever on the downstream side. The only real problem with this method, of course, is when customers get "consultants" who know nothing about routing objects, or BGP itself, or the customer's admin runs off with the password. The ISP can rewrite the password code for the object, or simply wipe the object and letthe customer start from scratch, but it can't do much about clueless consultants, because it's not selling a BGP training program
Re:darn, you beat me to it (Score:2)
Of course this is difficult if you don't have physical access. Most large core routers should have a console server attached to them with a different physical circuit attached to it, so you should still be able to console into it even if your primary net connections are down.
Authentication not much help... (Score:4, Redundant)
I don't know what the complete solution to this is, but simple authentication isn't it. At a first line of defence, what about some sanity checking on the routing information provided?
For more information.... (Score:5, Informative)
Jouster
Re:For more information.... (Score:2, Interesting)
BTW I assume that virusses on P2P networks use a similar method to spread as fast as possible.
Re:For more information.... (Score:1)
Yep, it's a bitch. I'm a big fan of throwing big ping packets at the broadcast addresses that cover the printer pool, though. Most printers have *terrible* protocol implementations. Send 30k ping to broadcast with a falsified source, you'll get twenty printers trying to respond. It's great!
Jouster
did anyone notice the .NET discussion underneath? (Score:3, Interesting)
most of the rest of the thread under that was people calling the
I knew Microsoft was trying to usurp the language for their own profit again.
the posts marked Storm teacup were informative, ie if we're using secure telnet ie the ssh part of putty or just plain old ssh or secure ftp, router spoofing won't matter a lot. I have trouble believing that routers have been misconfigured as GOD routers only once (1997). This must have happened more than once. How many routers would you need to stuff up to make a glitch in the internet?
DECnet had such a problem once (Score:1)
1) as most machines on both side of the pond automaticly updated their routing tables this unfortunate machine got almost all transatlantic traffic routed to it.
2) as transatlantic traffic virtually stopped then all of this machines immitiate neighbors rather quickly manually updated their routing cost to this machine to close to infinity.
Or this is at least how I remember the story...
neway.. (Score:1)
Didnt the internet figure out the security issues of trust-host relationships years ago?
But then like nething else thats core-of-the-net, no one wants the hassle of upgrading it.. alla BIND.
Re:neway.. (Score:1)
Secure BGP (Score:2, Informative)
There is also soBGP (you can google for it), but between the 2, I don't know which has more possibilities to go forward (if any).
Old news (Score:3, Informative)
Anyone administering a router that is NOT getting transit trhough a peer can prevent that peer from injecting new routes into their table. The RADB helps with this for those that do.
You have GOT to be kidding me (Score:5, Insightful)
Re:You have GOT to be kidding me (Score:1)
Re:You have GOT to be kidding me (Score:2)
The whole idea of authentication is dull anyway. Who needs P2P authentication when you know the hassle that one has to go through to get and maintain a peering agreement with a Tier1/2 service provider ? And of course, BGP neighbours are manually setup by the remote party. So it's not like you can suddenly take control of internet routers and modify the peering points or anything..
All major ISPs do filtering on their BGP Sessions (Score:5, Informative)
All major ISPs do heavy route filtering on all their border routers. Even the small ones do it. They do it for one simple reason: They don't want to transport traffic nobody is paying for. So in essence the market has already taken care of the problem.
Also when you look at the RIPE database you'll see what the individual filters are. Klick here to see such a Routing Policy [ripe.net] (Swisscom in this case). This is what the routers are enforcing.
The whole blabla about this BGPsec is useless and by nice engineering people who haven't got any clue how the network is managed and run nowadays. They propose to use DNS to authenticate the prefix announcements... How are you supposed to do that if you can't reach one of the DNS Root servers?
This entire BGP and security discussion is just some hyped non-issue and smells awfully like the
orange and banana alert bullshit the US government is so proud of...
--
Andre
Re:All major ISPs do filtering on their BGP Sessio (Score:1)
Old old old (Score:5, Informative)
RFC 2385 [ietf.org] was released three months later referring to the problem . . .
Non-story (Score:5, Interesting)
1) Misconfigured routers cause much more trouble that compromised ones. Routers seem to be cursed so that admins (especially junior ones) feel the need to 'tweak' them endlessly.
2) A compromised router (i.e. one that is under the control of someone 'bad' - a Junior admin for example) is a pain whatever - BGP extends the range of the damage that can be caused, but ultimately securing the router is more important.
Yes, I think S-BGP is a good idea, but hiding those router passwords is a better one.
Re:Non-story (Score:4, Insightful)
By the time you've graduated to fucking it up in SOURCE, you're qualified to administrate a production box. You understand the dangers of success.
One of the gentlemen in my division spent two years carefully toeing the line of what he understood. Finally, I pointed out the fuckbox we keep on the network for three dozen different uses, and explicitly told him to make it fail and then bring it back up. When he had completed that, I was at last willing to write up promotion papers (which is good, since we had been needing a new senior network tech).
I want my people capable of doing their day-to-day jobs without errors--if they couldn't do that, the network wouldn't be able to run. But at the same time, I want them to be able to do the occasional impossible task without fear of failure--THAT is how to run a network team.
Jouster
Re:Non-story (Score:3, Funny)
We are all morons. Not complete morons, of course. Assuming that we make mistakes 1% of the time, but catch those mistakes 99% of the time before they become a problem, that still means that we make un-caught mistakes (are morons) 0.01% of the time. Thus, everyone is at least 0.0001 of a moron. If there are 200,000 system and network administrators out there, that means there are 20 morons running the Internet.
Determining the number of morons using the Internet is left to the interested reader.
Re:Non-story (Score:3, Funny)
Then why don't we just fire those 20 guys?! Crimony!
Small Virginia ISP (Score:5, Informative)
Jouster
Re:Small Virginia ISP (Score:2, Interesting)
For those interested, an archived copy of the apology issued after this incident is here [archive.org]
The owner of the AS happens to be a close friend. I'm waiting for him to start advertising a block with it just to see how many routers still have an AS7007 filter up.
Geesh, now I feel like an old-timer.
Re:Small Virginia ISP (Score:2)
Re:Small Virginia ISP (Score:2)
That is why we need open source software people!!! (Score:4, Funny)
if a router is compromised, then your lost anyway (Score:5, Informative)
Filter, filter and filter
Do not accept announcements your peer should not announce. Second, using MD5 security is useless, as your router knows the password so if your router is being compromised, the password is known. MD5 security is only useful when it comes to macadress spoofing.
Sending out 0.0.0.0/0? Sure, go ahead, but see that prefix filtered. Sending out 1000 prefixes instead of the 10 you usually send? Sure, hit my maxprefix counters and see your sessions terminated.
In short: if you manage your router properly, you will have no problem if your neighbour is compromised.
Sigh (Score:2, Insightful)
Sounds familiar? Heard the following?
Y'know, if you read articles written by h4X0rz and warez d00dz, they often claim they do more good than harm by forcing people to create a better security infrastructure. When you read it it looks like a miserable attempt at satisfying their own conscience, but when I read something like this article I almost see their point.
Problem in Uni Halls (Score:3, Interesting)
When I was in halls last year, I discovered this as a problem. The routers and switches on the halls networks were badly configured and secured.
It all started off with some fun with Ettercap, and it was clear that ARP spoofing worked.
You could then easily pretend to be the gateway on the network. All the traffic on the same switch as me was coming through my box. Ettercap was limited, so a bit of hacking and scripting later, a combination of arpoison, fragrouter, and tcpdump was working on the network.
Sniffing got a bit dull (porn, e-mail, p2p) until someone tried logging into one of the switches. They had been connected badly, using 10Mb/s upstreams to chain lots of switches together, rather than using the proper backplane, so I think it meant I could see any traffic destined for switches further along the chain.
From this I got the password (no username required). It was an easy job changing my port to 100Mb/s, which removed some of the bottleneck when I was forwarding traffic when pretending to be the gateway.
However, each switch and router trusted the next. The whole network was like this. Although I didn't get far with my experimentation, it should have been possible to re-route traffic.
Thing was, they had slow connections. Unless you went onto JANET or the uni systems. You could use the uni proxy to speed it up a bit, but only with web traffic. It would have been interesting to try getting all traffic to take a faster route, but I would have got busted.
Only the 'leet script kiddies' would try this (Score:3, Insightful)
Luckily, the only people who would want to do this sort of DOS are the imature script kiddies who would only be following instructions from the current equivelant of rootshell.org (what happened to this site?). Responsible people, who would have the complete understanding of how it all worked, would not do this anyway.
Just my 2c.
--Shaun
Fear the FUD (Score:2)
We can't replace BGP anymore than we can replace the VHS tape. It's become too integrated into the operations of the Internet, and it's simply too hard to change (just like IPv6 vs v4. It's not going away anytime soon.)
Re:Fear the FUD (Score:2, Insightful)
Bull*cough*shit. Sure you can. BGP-4 is a replacement. Sure it can be replaced.
And, oh, btw, IPv6 is being deployed quite actively outside the U.S. And your assumption about IPv6 replacing all of IPv4 is fundamentally flawed. They're not mutually exclusive.
Moronic FUD postings on /. reign supreme.
Compromised Device? (Score:1)
Re:Compromised Device? (Score:1)
Protocols will always have holes The solution is proper maintenance.
Well DUH. (Score:2)
Screwed up BGP configs used to raise havoc once in a while. I don't know if they still do but it used to happen several times a year. This has been known since the inception of BGP, the guard against it has always been "well, keep control of your routers, and know what you're doing before you touch the config."
OK lets get real (Score:4, Informative)
Next router takeovers they can happen especialy as people arent using proper seperate management networks. This is a straight security thing. Next except between tier 1 is there a full trust relationship tier ones dont trust there clients they filter all prefixes not owned by the client general requiring the client to email them to allow out a new announcement. So you realy have to break into a tier ones routers to pop up a new announcement at best you can funnel traffic to that netblock from people that are relitivly close to that teir one. This will show up on just about everybodies radar screen as it's a netblock advertized by 2 AS numbers thats generaly a no no or som moron that insists they NEED to be redundant but isn't big enough to get there own IP block or AS (Joe corprate does not need there own AS for as much as they want one there are 65k of them to go around gets a good IPP to host your corp site and deal with multi directional NAT for the rest) Now you could take over the adversisement for a whole AS now this AS is going to start getting calles from perturbed individuals who cant get to here etc etc etc go visit a looking glass see the new advertisement and call up that ISP's noc to get things settled out. BGP has a lot of problems but we need out routing protocals doing crypto like a hole in the head. Oh yea anybody worth a grain of salt has started null routing all the bogons (addresses that shouldent be advertised the spammers used to love those) it's clean it's easy and you can do it automaticaly via a slew of services or by hand new
misconfiguration is the real problem (Score:2, Informative)
I wonder... (Karma whores, over here) (Score:3, Informative)
Long story short are there any good resources around for elucidating this field somewhat?
Re:I wonder... (Karma whores, over here) (Score:2, Informative)
Re:I wonder... (Karma whores, over here) (Score:2)
I remember this happening back in 1995 (Score:1, Interesting)
He barely lasted a month or so in our department.
From that point forward, we refered to this as "black holing".
The bigger problem is... (Score:3, Insightful)
This is why people so heavily filter what announcements they will take. This filtering is why there haven't been more problems with bad routes being advertised by the malicious.
So, forget trying to get the whole net to switch over to BGPsec... Let's just put pressure on the people who still aren't doing appropriate filtering of routes they receive.
Sean
Real risks (Score:5, Insightful)
Those really are the two biggest issues from my perspective. BGPv4 is attackable, always has been. SecureBGP deals with some aspects of the problem, but certainly not DOS issues. Huge routing updates consume CPU resources, and even with route dampening and other tricks, you can artificially (though rarely naturally) kill a router through BGP.
It's unfortunate that an article purporting to cover risks doesn't bother with the real ones and instead sticks to sensationalistic strategies.
planned attacks (Score:2)
My wondering is what IF a large politically motivated plan of action was contemplated and initiated. Perhaps these 5-6 serious brains at a few places were compromised, either blackmailed or bribed, or they were actual "true believers" of some large political factions ideologies? This could be a state sponsored event or a large private political faction. That to me looks more like the largest potential threat, short of just mass physical destruction of course. Your example of puncturing the tires of those gents to make them not be able to get to the shop reminded me of it, just turn it around to "the bad guys are in charge, on-site and are up to no good". What was the black hat geeks name in Jurassic Park? A deal like that but on steroids. Say I was "badguy" faction A and wanted to be able to conduct cyberwarefare at target country B. would it be a better bet and easier to accomplish remotely, or would it be easier for me to bide my time and get some few key ubergeek-personnel tagged in advance, compromised or "recruited" using a false flag approach? It would appear the latter plan has more chances of being more effective and easier to pull off. It's just a variant of script kiddies accumulating lower level zombie machines, it's just much bigger and uses various social engineering, which is nice because the preliminary work is not on the net for anyone to see indications it might be happening or being setup.
Now the main question I would have, how many people need to be compromised for this to be a pretty viable plan, in how many places? And suppose your own hierarchy is factionalized, that "orders may be given" to create some serious havoc, this could be done in such a way as to both create the havoc, and also to make it appear someone else did it, at least in the initial stages of the attack. Shifting the blame is a common "spooky" type of thing to do. So, how many across a big nation like the US would it take, one hundred, a thousand, 50? I don't know but perhaps it's a low number depending how far up the routing/traffic food chain you can get to.
It's already happened (Score:1)
This is SOOOO old... (Score:2)
This is FUD (Score:2, Interesting)
Overblown, underanalysed crap! (Score:2, Insightful)
Someone can send me incorrect information that causes routing problems no matter whether the protocol is secure or not. You can encrypt, key it, whatever, but the data coming from it has to be correct. There's more chance of a mistake causing routing instability, I can think of more examples of that than the one in the article!
130,000 (Score:3, Interesting)
Hrm, imagine that... When I check my BGP tables, there are about... yeah, 116,000 routes.
Of course, that is every network on the internet. Anywhere you need to go, you can go from your ISP router to the other person's ISP router via one of 116,000 routes.
Re:130,000 (Score:2)
Article is alarmist and misleading (Score:5, Informative)
1) BGP neighbor relationships are statically defined, permitting path information from specific autonomous systems advertised by specific peers.
2) Any major ISP is going to be running stringent as-path filters on inbound updates, to prevent blatantly false path information from being accepted.
3) BGP has internal controls that can be added to a config to specify preferred paths for outbound traffic, regardless of the inbound path preference information from a router's peers.
4) Compromising a properly secured router is no simple feat. At that level, remote access is always restricted, passwords are always strong, terminal access to every device is always logged, and network monitoring is always employed. An attack on a core router is going to be detected rather quickly through either automated log analysis or network management alerts.
All of that being said, if a router were compromised, ISP traffic is monitored in realtime. A sudden change in traffic will bring the immediate attention of an ISP's NOC, and the problem will either be corrected immediately, or the router will be taken offline, allowing traffic to fail over to another NAP until the problem can be solved. Barring a large-scale, coordinated attack (the logistics of which would be almost impossible to manage given the environment), the impact of such an attack would likely be minimal.
The Sky *IS* Falling(NOT!) (Score:2)
In the past I've managed peering with UUNet, Teleglobe, Level3, Concentric/XO, Genuity, Sprint, AT&T, and I currently manage a small AS that does provide transit for two peers.
I'm not sure what they're getting at in this article - the ISPs that are small enough to have security problems are generally at the edge of the Tier 1 guys and they're filtered to death - I offer five prefixes to Sprint and that is all they'll accept - the same goes for the AT&T and UUNet connections I manage.
I think the scenario of rogue network announcements could only happen between very large carriers - those who are so large (and disciplined) that they don't route filter between themselves.