HI, Can any of you cite cases where an attack has been carried out against a network's routing protocol (BGP or OSPF in particular)? My apologies if this question is too far off-topic, but if anyone knows of such incidents it would be the members of this group. Jeff
Can any of you cite cases where an attack has been carried out against a network's routing protocol (BGP or OSPF in particular)? I heard people talking about a Dos (not DDos) attack from your neighbor peer router that overflows your routing table with too much data. I am not aware of any DDos on routing packets(?).There are chances for man-in-the-attacks between BGP sessions. The question is how much the crypto- based security mechanisms like MD5 helps prevent routing vulnerabilities. But, I guess misconfiguration can also be considered as a reason behind many vulnerabilities.
__________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
On Tue, Aug 13, 2002 at 01:55:50PM -0700, senthil ayyasamy wrote:
Can any of you cite cases where an attack has been carried out against a network's routing protocol (BGP or OSPF in particular)?
I heard people talking about a Dos (not DDos) attack from your neighbor peer router that overflows your routing table with too much data. I am not aware of any DDos on routing packets(?).There are chances for man-in-the-attacks between BGP sessions. The question is how much the crypto- based security mechanisms like MD5 helps prevent routing vulnerabilities. But, I guess misconfiguration can also be considered as a reason behind many vulnerabilities.
Senthil, Hi there.. Agreed, I think there are two major classifications you can lump things under; exploitation of a weak router / misconfiguration to manipulate a legitimate speaker's advertisements, OR a 3rd party box somehow manipulating a routing protocol between other devices. (Using something like nemesis, etc..) While tools like nemesis and other scripts are out there, and perfectly capable of forging/manipulating routing protocol packets, how common is this? Of the problems folks have run into, are they more often the result of a legitimate speaker being compromised & playing with advertisements somehow (and getting through filters that may or may not be present), or from devices actually spoofing their way into the IGP/EGP? Are there any specific attacks anyone is aware of & can share? ..Dylan -- , Dylan Greene , + Juniper Networks + + +1 617/407-6254 + ` dylan@juniper.net '
On Mon, 12 Aug 2002 dylan@juniper.net wrote: :Of the problems folks have run into, are they more often the result of a :legitimate speaker being compromised & playing with advertisements :somehow (and getting through filters that may or may not be present), or :from devices actually spoofing their way into the IGP/EGP? Are there :any specific attacks anyone is aware of & can share? My first pointer would be to the Phrack article Things to do in Ciscoland when you are Dead. While this is not routing protocol specific, it's more about fun that can be had with tunneling traffic from a compromised network. The next would be someone taking advantage of poorly configured EGP that blindly redistributed information from the IGP. An example of this would be a big provider a few years ago whose ospf core was accepting unauthenticated RIP from the dial pool and redistributing it into BGP. Teehee. Another issue would be vendors who don't fully implement the authentication features of a protocol. It's probably time for an audit of BGP implementations to see if anyone hasn't implemented anything other than Null as an authentication method. Tim Newshams paper called "The Problem With Random Increments" about random TCP ISN's from last year could have been cause for uglyness if Cisco hadn't fixed their ISN generators. However, it is possible that other vendors are still vulnerable (Routers based on old BSD or VxWorks code) to this. He demonstrated that it was still practically possible to insert data into a tcp stream because ISN generation based on random increments wasn't sufficiently random to make it secure against sequence number guessing. I recently got a frantic call from an associate asking me how to respond to an ex-peer who was making hostile annoucements of his routes. They were announcing his netblocks to any of their peers that would listen, but had them blackholed over some disagreement. I said if they won't listen to you, have your lawyer get them on the phone.:) So, as far as attacks against protocols themselves, they are really more to do with the underlying network/session protocols (UDP, TCP, OSPF, ICMP, IGMP) and would depend on a lack of session state keeping and authentication being implemented in the way the routing protocol manages its sessions. Otherwise, it's an issue of attacks against the routers, which can be catagorized as run of them mill application/daemon attacks like format string and overflow attacks. I am not aware of any of these specifically, however, it is not hard to imagine where one would look for them, as routing daemons are like any other daemon, running on any old OS, on any old host. The short term solution would be routers that denied all layer-3 traffic destined to it by default, (passing it to elsewhere)and only accepted traffic from specifically configured peers. (Type Enforcement(tm) on interfaces anyone?) Routers should be shipped in a state that is functionally inert to packets on layer 3. Alas.. -- batz
At 07:43 PM 13-08-02 -0400, batz wrote:
On Mon, 12 Aug 2002 dylan@juniper.net wrote:
:Of the problems folks have run into, are they more often the result of a :legitimate speaker being compromised & playing with advertisements :somehow (and getting through filters that may or may not be present), or :from devices actually spoofing their way into the IGP/EGP? Are there :any specific attacks anyone is aware of & can share?
My first pointer would be to the Phrack article Things to do in Ciscoland when you are Dead. While this is not routing protocol specific, it's more about fun that can be had with tunneling traffic from a compromised network.
Better yet: http://www.phenoelit.de/vippr/index.html http://www.phenoelit.de/irpas/index.html Also note that keepalives and routing updates are process switched (for Ciscos). Think about it.
The short term solution would be routers that denied all layer-3 traffic destined to it by default, (passing it to elsewhere)and only accepted traffic from specifically configured peers. (Type Enforcement(tm) on interfaces anyone?)
Don't forget layer-2 as well (from Networkers 2002): http://www.cisco.com/networkers/nw02/post/presentations/general_abstracts.ht... http://www.cisco.com/networkers/nw02/post/presentations/docs/SEC-202.pdf -Hank
Routers should be shipped in a state that is functionally inert to packets on layer 3.
Alas..
-- batz
What are the best current practices ISPs use to maintain routing protocol security? 1. None - May be acceptable in some environments 2. I don't tell anyone about my routing protocols 3. Firewalls protect me 4. Don't exchange routing information with external parties 5. Explicit routing neighbor assocations - passive-interface default 6. Address validation on all edge devices 7. Signed routing messages - MD5 or something else 8. Non-routed routing infrastructure - RFC1918 for core 9. Non-IP routing protocols - ISIS 10. Out-of-band route servers - SS7 here we come
On Wed, Aug 14, 2002 at 01:23:01PM -0400, Sean Donelan wrote:
4. Don't exchange routing information with external parties
And don't trust them. Use limits on the amount of prefixes you're willing to accept. Verify routes received with some third party (e.g. routing database).
5. Explicit routing neighbor assocations - passive-interface default
Both inbound and outbound. On Cisco's, in addition to passive-interface you might do 'distribute-list 1 in <interface>' where 1 is an ACL that can be simply 'deny any'.
6. Address validation on all edge devices
Filter to only allow neighbor IPs to the specific routing protocol. For example on a BGP peer, filter TCP port 179 on each peer interface to only allow the expected peer IP. Also: Apply damping as appropriate, but protect subnets serving root DNS servers from accidental damping. Limit maximum prefix length you're willing to accept. Make extensive use of remote logging and monitoring. Keep an eye on routing table changes over time and the overall operation of the routers. Filter out known bogus routes such as reserved, private, and special use address space as appropriate. John
On Wed, Aug 14, 2002 at 01:44:26PM -0500, John Kristoff wrote:
6. Address validation on all edge devices
Filter to only allow neighbor IPs to the specific routing protocol. For example on a BGP peer, filter TCP port 179 on each peer interface to only allow the expected peer IP.
Agreed.. If one or both sides aren't doing any sort of uRPF or ingress filtering on their edges, it may still be possible to throw packets at bgp from behind the remote peering router. It's probably not a bad idea to have an additional filter to block traffic going to port 179 on the peer's dst from _any_ src on all of the other interfaces on the peering router. (Or some other mechanism which does the same thing, which I think Sean was pointing out.) It's sort of mutually beneficial for both sides of a given peering to protect each other, as it's not really possible for a filter on one side to fully protect itself. (Just my additional $0.02) ..Dylan -- , Dylan Greene , + Juniper Networks + + +1 617/407-6254 + ` dylan@juniper.net '
Must depend on the router architecture tho if this is feasible.. ie why just BGP, can do this for all routing protocols and that means filtering all ingress packets through several "lines" of filter.. if you could do this by filtering out to a loopback this wouldnt be bad but current practises are to peer real interface ips (specifiaclly to ensure quick withdrawal when a link flaps). i guess i can just see some unwanted overheads arising. no ideas on actual metrics tho, may be negligible in practice. Steve On Tue, 13 Aug 2002 dylan@juniper.net wrote:
On Wed, Aug 14, 2002 at 01:44:26PM -0500, John Kristoff wrote:
6. Address validation on all edge devices
Filter to only allow neighbor IPs to the specific routing protocol. For example on a BGP peer, filter TCP port 179 on each peer interface to only allow the expected peer IP.
Agreed..
If one or both sides aren't doing any sort of uRPF or ingress filtering on their edges, it may still be possible to throw packets at bgp from behind the remote peering router.
It's probably not a bad idea to have an additional filter to block traffic going to port 179 on the peer's dst from _any_ src on all of the other interfaces on the peering router. (Or some other mechanism which does the same thing, which I think Sean was pointing out.) It's sort of mutually beneficial for both sides of a given peering to protect each other, as it's not really possible for a filter on one side to fully protect itself.
(Just my additional $0.02)
..Dylan
participants (8)
-
batz -
dylan＠juniper.net -
Hank Nussbacher -
Jeff Doyle -
John Kristoff -
Sean Donelan -
senthil ayyasamy -
Stephen J. Wilcox