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.
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
: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..
: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.html#mitigation
http://www.cisco.com/networkers/nw02/post/presentations/docs/SEC-202.pdf
-Hank
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
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
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
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