|
Table Of Contents
SAFE: Best Practices for Securing Routing Protocols
Types of Attacks Against Routing Systems
Falsifying Routing Information
Misdirecting Traffic to Form a Routing Loop
Misdirecting Traffic to a Monitoring Point
Misdirecting Traffic to A Black Hole
Abusing Routing Stability Features to Reduce Network Availability
Forcing BGP Peer Damping By Injecting Flapping Routing Information
Forcing the Routing Protocol to Converge More Slowly by Injecting Flapping Routing Information
Protocol Semantics Peering Attacks
Compromising a Legitimate Member of the Routing Domain
Masquerading as a Member of the Routing Domain
Modifying Routing Information Passed Between Routers
Protecting Routing Domain Legitimacy
Protecting Routers from Being Compromised
Protecting Routing Information on the Wire
Protecting Against Illegitimate Devices Joining the Routing Domain
Other Issues with MD5 and Peer Authentication
TTL-Based Peering Session Protection (The BGP TTL Security Hack)
Protecting Routing Information
Use An Exterior Gateway Protocol for all Extranet Connections
Filter Routes Aggressively at the Extranet Edge
Dampen Prefixes Aggressively at the Extranet Edge
Limiting Route Count at the Extranet Edge
Sample Extranet BGP Configuration
Connections Within the Network
Route Filtering Within the Network
Future Directions in Routing Protocols Security
Protecting Routing Information on the Wire
Protecting Against Illegitimate Devices Joining the Routing Domain
Protecting Routing Information
White Paper
SAFE: Best Practices for Securing Routing Protocols
Overview
Routing, which provides the information required to forward traffic through networks, is increasingly scrutinized for security vulnerabilities and possible solutions. This document discusses the various threats against routing protocols, including peering disruption and falsifying of routing information, followed by a description of the methods and techniques used to attack a routing system—providing a background for the protections discussed in the final section of the document, which also includes a blueprint for future direction for routing protocols security.
The Routing System
The first consideration when considering routing security is usually to secure routing protocols—but this is too narrow a view of routing security—rather, the focus must be on the routing system, which consists of three major pieces:
•
The routing protocol, which consists of the semantics used to transport topology information across a network or internetwork, and the algorithms used to determine the shortest path to any given destination within the network
•
•
To protect routing within a network, it is necessary to protect each piece of the routing system, rather than focusing on the routing protocol and its semantics and algorithms.
Types of Attacks Against Routing Systems
To understand specific attacks leveled against a routing system, begin by understanding what the threats are to routing systems; what sorts of failures in a network can an attacker cause by attacking the routing system? Generally, the point of an attack against a routing system falls into one of two categories: disrupting peering and falsifying routing information.
Disrupting Peering
Peering disruption attacks generally attempt to deny the use of network resources to authorized users of the network. Peering disruption attacks are generally not as effective as they appear from the outside, since most routing protocols will rebuild their peering session once the attack has stopped. For example, if a peering session between two Open Shortest Path First (OSPF) Protocol adjacencies is brought down through an attack, the OSPF routers will rebuild their adjacency once the attack has stopped, and the routing system will continue forwarding traffic through the network.
Natural redundancy and other high-availability techniques can also defeat most peering disruption attacks, since a single peering failure will cause some amount of network disruption; but routing protocols will adjust to the disruption within a short period of time and route around the disruption in the network. Some examples of attacks against peering sessions are provided in Attacking A Routing System, below.
Falsifying Routing Information
A more subtle class of attacks against a routing system attacks the information carried within the routing protocol, including the topology and reachability information, to misdirect traffic. Falsified routing information may generally be used to cause a denial of service, to falsify information being carried between two systems, or to cause traffic to follow a path the traffic would not normally follow. Three examples of these types of attacks follow.
Misdirecting Traffic to Form a Routing Loop
Figure 1 illustrates a small network where an attacker has caused a routing loop.
Figure 1
Misdirecting Traffic to Form a Routing Loop
Normally, router C advertises reachability to 10.1.1.0/24 to routers D and A. Router D chooses the path to router C directly as its best path to 10.1.1.0/24, while router A chooses the path through router D over the path directly to router C. An attacker attaches itself to the segment between routers A and C and injects false routing information to Router C only, indicating 10.1.1.1/32-a part of the 10.1.1.0/24 network reachable behind C is reachable via router A.
With this false information injected, a routing loop is formed. When the host at 10.2.2.2 attempts to send a packet to 10.1.1.1, the following sequence takes place:
•
•
•
•
This loop will continue until the false routing information injected by the attacker is removed from the network, and routers A, C, and D converge again on the best path to 10.1.1.1.
Misdirecting Traffic to a Monitoring Point
If an organization routinely encrypts data when it is being passed through some sort of public network, it may be easier to simply redirect the traffic along an unprotected link by injecting false routing information than to attempt to break the encryption on the traffic stream. An example is illustrated in Figure 2.
Figure 2
Misdirecting Traffic Around a Protected Path
In this example, the normal path from 10.2.2.2 to 10.1.1.1 is through an encrypted VPN through a service provider (a public network). The attacker has attempted, without success, to break into the physical plant at the two corporate sites in order to trap the traffic destined to 10.1.1.1, and has also tried, without success, to grab the traffic stream and break the encryption as it travels across the public network. The attacker will now try a new tactic, simply redirecting the traffic across an unprotected link.
In this case, the attacker has successfully penetrated a corporate remote site and has injected false routing information that will cause the traffic he is interested in to pass through the remote site, where he has set up a monitoring station to collect the unencrypted traffic as it is passed to 10.1.1.1. The attacker has simply injected routing protocol information which informs router G 10.1.1.1/32 is reachable through router H; router G, in turn, advertises this information to router E, which then advertises this information to router A.
When router A forwards traffic to 10.1.1.1, rather than choosing the route to 10.1.1.0/24 through router B, it will choose the route to 10.1.1.1/32 through router E, bringing the traffic by the monitoring station.
Misdirecting Traffic to A Black Hole
If the attacker can direct traffic to a point in the network where the packets will be discarded by injecting false routing information, he can create a routing black hole, as illustrated in Figure 3. An attacker can also build a black hole by pulling traffic to the attacking machine and then discarding it, but this is riskier since it generally exposes the compromised host. It might also be possible to draw traffic to a host that will not accept the traffic, but this appears to be a complex attack.
Figure 3
Misdirecting Traffic into A Black Hole
In this case, the attacker knows about the existence of a lab network that does not permit any traffic, within narrowly defined limits, from entering from the production network. The attacker modifies the routing table on router A to draw traffic destined to 10.1.1.1, which normally travels along the path {A, B, C}, to router E, where it will be discarded. This an effective mechanism for discarding all traffic destined to a specific server or host, until the changes in the routing table are discovered, the root cause diagnosed, and the false routing information removed from the system.
Abusing Routing Stability Features to Reduce Network Availability
Technically, this class of attacks belongs under the general category of falsifying routing information, but they are discussed separately here for clarity. This form of attack requires strong knowledge of the routing protocol's semantics, and also the implementation of the routing protocol the network operator has deployed. Most routing protocols provide some form of stability enhancements to prevent rapid changes in the network's topology from overwhelming the processing power, memory, and other scarce resources available on devices running the routing protocol. An attacker may be able to exploit these safeguards, much as an attacker may purposely enter the wrong password on a safe multiple times to lock the rightful owner out of the safe for some long period of time.
These types of attacks normally fall within the realm of denial-of-service attacks, since they either remove legitimate routing information from the routing tables (forcing a router to underclaim its connectivity), or they slow down the convergence of the network so any real changes in the network topology cause all current sessions across the network to drop. Two possible attacks using routing protocol stability features to reduce network availability are discussed below.
Forcing BGP Peer Damping By Injecting Flapping Routing Information
Border Gateway Protocol (BGP) route dampening (or damping) was designed to reduce the change rate in the Internet's routing tables; generally, almost all BGP sessions between Internet Service Providers (ISPs) are aggressively dampened by the ISP to prevent flapping advertisements of routing information from wasting resources on the service provider's network. Figure 4 illustrates the concept of route dampening in BGP.
Figure 4
Route Dampening Theory
Route dampening is specified in terms of a penalty, damp threshold, reuse threshold, and halflife. Assume these are set to the following values in this network:
•
•
•
•
The following chain of events explains the route dampening operation.
•
•
•
•
•
•
•
•
An attacker could exploit the dampening mechanism in router A by artificially making it appear a given destination route is flapping. For example, if an attacker could forge a set of withdraws and updates advertising a given route again and cause router A to believe these changes in state when they are transmitted, the attacker could cause the ISP edge router to dampen the route for some long period of time, making the destination unreachable.
This is actually more insidious than simply causing router B to stop advertising 10.1.1.0/24, because the effects of the attack will be felt for some time after the attacker has left the network (possibly leaving no trace of how the attack was accomplished), and the only way to allow 10.1.1.0/24 to be reachable again is for action to be taken by the ISP, which may require more time than the business will allow.
Forcing the Routing Protocol to Converge More Slowly by Injecting Flapping Routing Information
Routing protocols traditionally converge in the 7- to 10-second range in most networks-but this isn't fast enough for newer applications being carried by networks. For example, if a single link fails, and it takes 7-10 seconds to reroute traffic, voice calls will drop, video streams will suffer horribly, and many other types of sessions will fail. Improving the speed of routing convergence within a network (and within large internetworks such as the Internet), has been, for some time, a field of extensive study and work by routing protocol designers.
The main problem a routing protocol faces when trying to converge quickly is information overload-how much information does it take to overwhelm the smallest/slowest devices in the network providing routing services? If a network changes quickly enough to surpass this threshold, the routing system quickly becomes unstable and may eventually fall into a condition called a "network melt," where the network will not converge again without human intervention, even when the original source of the information overload is removed from the network.
One of the primary tools available to routing protocol designers to prevent information overload from causing a network to melt, but allowing the network to react very quickly to a low or moderate number of topology/reachability changes, is the exponential backoff. This technique has been deployed in recent versions of Cisco IOS® Software for OSPF and Intermediate System-to-Intermediate System (IS-IS) Protocol. An attacker could take advantage of exponential backoff features to force the network to converge slowly on a constant basis, causing the network to fail to meet the requirements of the applications running on it. Figure 5 illustrates one such possibility.
Figure 5
Attacking Through Routing Stability Features
Assume there are two IP phones talking over a given network; the normal path for the traffic between the IP phones is {A, B, D}, with an alternate path of {A, C, D}. The routing protocol has been tuned to switch to the {A, C, D} path very quickly. One of the techniques used to accomplish fast switchover is exponential backoff, which allows the routers to converge quickly when single topology changes occur in the network, but slows down convergence as more and more events occur. If the exponential backoff is forced to its longest possible wait before allowing convergence, any voice over IP (VoIP) sessions across the network will fail.
Knowing this, the attacker, sitting behind router E, simply sends constantly changing routing information to router A. This forces the exponential backoff algorithm on router A to maintain the highest (longest) timers possible, since there is constant apparent change in the network topology. Now, when the {A, B, D} link fails, the convergence time will be long enough to force the call between the two IP phones in the network to fail, defeating the careful network design work and disrupting the services provided across the network. This could be a coordinated attack taking down the primary path intentionally, or a "chance attack," kept up for a long time, assuming some link is bound to fail causing a service outage across the network.
Attacking a Routing System
Previous sections discussed the types of results an attacker would like an attack to have on a network. Following sections discuss what techniques an attacker could use to disrupt peering or to inject false routing information. This section details specific actions an attacker could take to accomplish one of these two goals, including port flooding, using protocol semantics against the protocol, compromising a legitimate member of the routing domain, and others.
Port Flooding
Several well-known port flooding attacks are commonly used against hosts, including various distributed denial of service (DoS), synchronization (SYN) flooding, and other sorts of attacks which will overflow the buffer or other resources on the attacked device, causing the device to stop responding to legitimate traffic. This form of attack could be used against routers to disrupt peering between two routers.
Figure 6
Using a TCP SYN Flood Attack to Impact BGP Peering
In this network, the attacker is flooding router A with TCP SYN packets. If router A is not protected in some way, this can eventually exhaust all TCP resources on the router and cause it to refuse new BGP connections, or possibly drop existing ones. This could impact Internet connectivity for any networks dependent on the routing information transferred across BGP sessions with router A. Note the impact of this attack will only be felt while the attack is underway; once the attack ends, the BGP sessions will be rebuilt and routing information exchanged, allowing packets to be routed across this link again.
It is also possible to simply flood the port a protocol uses to consume processing resources and prevent the protocol from operating properly. In this case, the attacker could simply flood TCP port 179 with a large number of packets, hoping to starve out the TCP connection between the two routers.
Protocol Semantics Peering Attacks
It is also possible to attack routing protocol peering sessions by abusing the semantics of the protocol itself. With an understanding of the routing protocol peering semantics, an attacker can cause a routing protocol peering session to reset, causing a disruption in network services. Attacking a peering session between routers using an attack against the routing protocol's semantics focuses on DoS. Three attacks are presented here as examples of the types of attacks possible against a peering session.
BGP uses TCP as its transport, which means it is vulnerable to any attacks that will cause the TCP session to fail. Since it is possible for either end of a TCP session to reset the session by issuing a TCP reset (RST), it should be possible to reset a BGP peering session by injecting a false TCP RST into the session. Figure 7 illustrates.
Figure 7
Breaking a BGP Peering Session Through a TCP RST
To reset the BGP peering session, the attacker first listens to the TCP session between routers A and C, and, using the information gathered, generates a TCP RST which appears to originate from router C. While it is theoretically possible to generate this TCP RST without listening in on the TCP session between A and C, it is much more difficult than it first appears, for reasons we will not examine here.
Similar attacks can be made against various interior gateway protocols, generally against the neighbor discovery and maintenance state machines. Figure 8 illustrates this type of attack.
Figure 8
Breaking Interior Gateway Protocol Peering Through False Packet Injection
The attacker may transmit a packet resetting the neighbor state between routers A and B from any place within the network, with no prior knowledge of the state between these two routers.
•
•
Neither of these attacks requires any knowledge of state between routers A and B. The results of the attack are temporary, as all attacks against peering relationships are, which means the damage to the network would probably be small. However, repeated attacks could bring routing across a link down (or a network down) until the source of the attacks is discovered, and the attacks stopped or blocked in some way.
Compromising a Legitimate Member of the Routing Domain
One of the most straightforward ways to attack the routing system is to attack the routers running the routing protocols, gaining access to the routers themselves, and using that access to compromise the routing system in some way. This type of attack could be used to inject false information into the routing system, which could be used, in turn, to accomplish any of the goals listed above. Access to a router could also be used to bring peering relationships down between the compromised router and its peers, or to use the compromised router as a base for other types of peering disruption attacks.
Masquerading as a Member of the Routing Domain
Rather than taking over a valid member of the routing domain by attacking a router within the network, it is also possible to inject false routing information by simply attaching a device which runs routing protocols to the network through an open port, and injecting false routing information directly. The types of attacks that can be launched against a network by attaching a device to the network running a routing protocol are similar to the attacks that can be launched by taking over a legitimate member of the routing domain.
Modifying Routing Information Passed Between Routers
If an attacker know the semantics of routing information being passed on the wire between routers, it is possible (although very difficult) to replay modified routing information, causing any of the impacts noted earlier from injecting false routing information.
Protecting Routing Domain Legitimacy
The various classes of attacks and the types of attacks that can be leveled against a routing system are discussed above. This section describes the steps to take to prevent the attacks from taking place. Many of these protections fall within the best common practices found in other areas, as well.
Protecting Routers from Being Compromised
The first point of attack against a routing system is the routers themselves-the devices responsible for running the protocols that find the best path to each destination within the network-and forwarding packets along those best paths. It is much easier to strike targets at rest than it is to strike targets in motion, and information is no exception; it is easier to get at routing information and data flows, and to impact data flow through the network from a router than it is to try and do these things with access to the wires between the routers. Following the procedures outlined in Improving Security on Cisco Routers will greatly enhance the security of your routing system.
Protecting Routing Information on the Wire
Attacking a router is the easiest way to attack the routing system, but it is also possible (although difficult) to attack routing information on the wire. The best way to protect routing information on the wire is to authenticate routing protocol packets using Message Digest Algorithm 5 (MD5) or IP Security (IPsec) signatures. A cryptographic signature (Figure 9) combines three things:
•
•
•
Figure 9
Cryptographic Signatures
Generally, the originator of the routing information will produce a signature using the key and routing data it is about to send as inputs to the encryption algorithm. The router receiving this routing data can then repeat the process using an equivalent key or the same key, the data it has received, and the same routing data. If the signature the receiver computes is the same as the signature the sender computes, the data and key must be the same as the send transmitted.
BGP, EIGRP, OSPF, and IS-IS all support various forms of MD5 authentication, as the following configuration examples and references show:
! OSPF MD5 Configuration!interface Serial 0/0ip address 192.168.64.2 255.255.255.0ip ospf message-digest-key key1 md5 10a11b12cip ospf authentication message-digest!router ospf 10network 192.168.64.0 0.0.0.255 area 0area 0 authenticationOSPF does not allow the use of key chains to define multiple keys with specified key lifetimes, although work is in progress in this area. See Sample Configuration for Authentication in OSPF for further information on OSPF authentication.
!IS-IS MD5 Configuration!key chain ciscokey 100key-string tasman-drive!interface Ethernet3ip address 10.1.1.1 255.255.255.252ip router isis real_secure_networkisis authentication mode md5 level-1isis authentication key-chain cisco level-1!router isis real_secure_networknet 49.0000.0101.0101.0101.00is-type level-1authentication mode md5 level-1authentication key-chain cisco level-1IS-IS allows the use of key chains to configure MD5 keys which should be used for specific time periods. For more information on IS-IS MD5 authentication, see IS-IS HMAC-MD5 Authentication and Enhanced Clear Text Authentication. IS-IS Cryptographic Authentication, draft-ietf-isis-hmac-05.txt, also provides information on authentication.
!EIGRP MD5 Authentication Example!router EIGRP 100ip authentication mode eigrp 1 md5ip authentication key-chain eigrp 1 holly!key chain hollykey 1key-string 0987654321accept-lifetime infinitesend-lifetime 04:00:00 Dec 4 1996 04:48:00 Dec 4 1996key 2key-string 1234567890accept-lifetime infinitesend-lifetime 04:45:00 Dec 4 1996 infiniteFor more information on EIGRP MD5 authentication and EIGRP use of key chains for MD5 keys, see IP Enhanced IGRP Route Authentication.
!BGP MD5 Authentication Example!router bgp 109neighbor 145.2.2.2 password v61ne0qkel33&BGP supports MD5 authentication, but it does not support MD5 key chains (although work is in progress on this support). BGP does, however, allow mismatched MD5 keys for the dead interval. If you change the password on one BGP peer, you will have up to the configured dead interval (generally 180 seconds) to change the MD5 password on the other BGP peer before the BGP peering session fails. The use of MD5 with BGP is detailed in RFC2385.
MD5 authentication doesn't simply attach a password, or a passphrase, to the routing protocol updates. Instead, the MD5 key is used to compute a signature based on the data within the routing protocol update. For example, if you were to take a written document, count all of the instances of each given letter within the document, then pass those letter counts along separately, you could use these letter counts as a sort of signature. If the receiver calculates the same letter counts, then there is some assurance that the document has not been changed in transmission. MD5 signatures work on this same principle but in a much more complex way, so a single bit change within the packet is detected.
For more information on the MD5 signature algorithm, see RFC1321.
IPsec provides another alternative to protecting routing information being transmitted between routers; an IPsec connection is generally thought of as a secure tunnel between two routers. There are two basic protocols within IPsec:
•
•
There are also two modes of operation: tunnel mode, where the IP packet is tunneled through IPsec, and transport mode, where the IPsec header is placed after the IP header and authentication/encryption only occurs on the payload of the packet. Between the two protocols and the two transport modes, there are four basic modes an IPsec may operate in:
•
•
•
•
Figure 10 illustrates the combinations normally found in implementations of IPsec.
Figure 10
IPsec Modes of Operation
While either mode can be configured on Cisco® routers, the mode which would most likely be used for transporting a routing protocol session is tunnel mode using ESP with NULL encryption. ESP can be combined with many forms of encryption, but we are not normally concerned with the confidentiality of the information within a routing protocol packet, but rather with the integrity of the information.
IPsec usually relies on the Internet Key Exchange (IKE) protocol to manage key distribution between devices running IPsec. Generally, these are public/private key pairs exchanged between each pair of IPsec devices. IPsec is designed for unicast, point-to-point communications between devices, rather than broadcast or multipoint models of communication; IPsec cannot be used to protect data multicast between routers.
For this reason, the best use of IPsec protection is between BGP peers, especially external BGP (eBGP) peers bordering between two different autonomous systems. It is possible to run OSPF or EIGRP over IPsec by disabling the broadcast capabilities of each protocol and forcing all neighbor adjacencies to be built using unicast hellos and routing updates only, or by running the routing protocol over an encrypted GRE tunnel.
Protecting Against Illegitimate Devices Joining the Routing Domain
Remember from the discussion above that the cryptographic signature is built using three things: the key, the routing data being transmitted, and the encryption hash. If the routing data is changed in transit, the receiver will not be able to compute again the same signature the transmitter sent, so the routing data is discarded. In the same way, if the key the transmitter uses to build the signature is not the same as the key the receiver has, then the receiver will not be able to produce the same signature the transmitter has transmitted along with the data and the receiver will discard the data. Thus, unless the transmitter has the right key to build the signature with, it cannot be a part of the routing domain. Using MD5 or IPsec can be an effective way to prevent unauthorized devices from inserting false routing information into your routing domain.
When connecting to networks outside the local administrative domain-the Internet, business partners, and others-interior gateway protocols should be filtered at the edge of the network to prevent outsiders from injecting false routing data of any type into the network. Figure 11, with the following sample configurations, illustrates.
Figure 11
Preventing Interior Gateway Protocol Attacks Through a Domain Border
The attacker would like to inject false routing information into AS 65000 to disrupt routing. The easiest way to do this is to find router C's address, and unicast OSPF, EIGRP, or RIP packets directly to router C itself. The network administrator should set up filters on router A to prevent all interior gateway protocol packets from passing into the domain from outside.
!hostname router-a!access-list 100 deny ospf any anyaccess-list 100 deny eigrp any anyaccess-list 100 deny RIP any any....access-list 100 permit ip any anyOther Issues with MD5 and Peer Authentication
One of the most critical issues when using routing protocol authentication is choosing and using passwords. There are four password issues to consider when determining what passwords to use for routing protocol authentication:
•
•
•
•
A number of standard rules are available for picking hard to guess or break passwords; for more information on this topic, see:
•
•
•
There are two risks involved with using the same password on a large number of devices throughout a network:
•
•
For these reasons, consider using several keys for MD5 authentication in your network. The most logical system is likely to split key use along topological boundaries in the network. Consider changing keys at the same places where there are area boundaries and summarization is used. This provides a natural boundary for keys, makes it more convenient for operators to know what keys are used where, and also provides break points on what would be natural break points in the network anyway.
Keys used for routing authentication should be changed on a regular basis, as well; the frequency of change depends on many factors, including:
•
•
•
Any key used to protect sessions to outside routing domains should be different from keys used to protect routing traffic and peering sessions within the routing domain.
When using MD5 or IPsec protection of routing data, it is important to consider the processing required to perform the cryptographic operations required. Some scalability testing has been done in this area, but this work is in its beginning stages. The performance of these algorithms is also constantly under scrutiny, and various methods are used to improve their performance. However, network administrators should be aware a router running peering and route authentication will be able to peer with fewer routers and handle fewer "outside tasks" because of the processing overhead.
TTL-Based Peering Session Protection (The BGP TTL Security Hack)
In many of the attacks we've examined, we've shown the attacker multiple hops away from the routers being attacked, possibly attacking from outside the routing domain. The BGP time-to-live (TTL) security hack (BTSH), is designed to foil all possible attacks from attackers not connected directly to the physical network connecting two routers (Figure 12).
Figure 12
TTL-Based Peering Session Protection
If routers A and B are configured using normal BGP peering, router B would generate BGP packets destined to A with a TTL of 1. As A receives these packets, the TTL is reduced to 0 and the packets are processed normally, since they are destined to router A itself. If the attacker wants to inject false TCP or BGP packets into the A-to-B peering session, it can generate these packets with a TTL of 3 and transmit them. Router C will reduce the TTL on the packets to 2 and forward them to B; router B will reduce the TTL to 1 and forward the packets to A. When A receives these packets, it will reduce the TTL to 0 and process them normally. Clearly, in this example it is easy for the attacker to inject packets into the peering session between routers A and B.
If, instead, router B were configured to set the TTL of BGP packets it transmits to 255, and A is configured to ignore, or drop, all BGP packets with a TTL of 254 or lower, the attacker's ability to send packets to A through C will fail. Assume the attacker attempts to transmit a packet directed at A which will disrupt the peering session between routers A and B. The highest TTL the attacker can assign to the packet, because of limitations in the IP header, is 255. When C receives this packet it will reduce the TTL by one and forward it. Router B will likewise reduce the TTL by one, so the TTL is now 253, and forward it. When router A receives the packet, the packet will be discarded because it is a BGP packet with a TTL of less than 254.
BTSH effectively foils attackers from being able to impact the peering sessions between routers, and from being able to inject false routing information from anywhere other than on the link connecting the routers. This reduces the scope of attacks against routing protocols dramatically.
As the name indicates, BTSH was originally designed and specified for BGP, in the IETF draft The BGP TTL Security Hack (BTSH). Work is currently in progress to implement this for interior gateway protocols using IP as their transport, as well.
•
•
•
•
Protecting Routing Information
Beyond protecting peering sessions between routers with techniques like filtering at the edge of your network, and BTSH, how can you attempt to protect the information contained in your routing tables? In this section, we'll discuss a few ways you can protect the information carried by your routing protocols, the information that ultimately directs packets towards the right destinations throughout your network.
Extranet Connections
Prime points at which an attacker could inject false routing information into your network is at extranet connections; places where your network connects to networks outside your administrative control, primarily for business-to-business transactions or information sharing. Examples of these types of connections include connections to outside services, such as an outside financial company providing payroll or other financial services, a supplier where the connection is used for automatic reorders, and other systems and customers to whom you provide services. These types of connections tend to be prime points for false routing information to be injected because they represent trusted relationships, generally using an interior gateway protocol to exchange routing information.
In fact, such connections can be the source of many internal routing problems, whether or not they are intentional. Figure 13 illustrates two such possible situations.
Figure 13
Possible Impacts of Exchanging Routing Information with Outside Networks
MediumSocks, Ltd., has an inventory-sharing arrangement with BigShoes Corp. To facilitate this agreement, they have set up an extranet connection between their networks, shown here between routers E and F. MediumSocks has a server, 10.1.1.1, which has long been used for internal purposes and is not reachable to hosts in the BigShoes network. BigShoes does not know MediumSocks is using the 10.1.1.0/24 range of addresses, and BigShoes sets up a new segment, 10.1.1.0/24, attached to router G. When this segment is advertised into BigShoes' routing protocol, it is also advertised into MediumSocks' network, becoming the preferred path, at router C, to 10.1.1.0/24. This cuts off internal access to the 10.1.1.1 server from behind router C in the MediumSocks network. While this problem can be resolved by simple route filtering at the router E/router F border between the two companies, it isn't always simple to find this sort of problem, or to configure filtering when the initial configuration of routers E and F is done so this type of problem doesn't occur.
Another problem with sharing routing information in this way is the impact changes in one network have on the other network. For instance, suppose the server MediumSocks hosts actually interact with is 10.2.2.2, behind router H. The router G to H link becomes unstable, flapping constantly; each time it flaps, the MediumSocks network must converge to account for this change in network topology.
Both of these cases demonstrate the impact of simple misconfigurations, miscoordination, or failing links, which are normal events. However, as pointed out in earlier sections of this paper, these sorts of events may also be used as attacks against the network routing system. Thus, techniques should be used to prevent these types of network events in another network from causing damage to your network In the following sections, several techniques are explained you can use to protect your network from attacks or to keep routing information from other routing domains from causing problems in your network.
Use An Exterior Gateway Protocol for all Extranet Connections
The cardinal rule for all connections to extranets is to never use an interior gateway protocol to dynamically exchange routing information with an outside routing domain. Always use exterior gateway protocols, or use static routes, rather than dynamically exchanging routing information through an interior gateway protocol. Since many network administrators find using static routes unacceptable, primarily because of redundancy and resiliency reasons, this discussion focuses on using an exterior gateway protocol, BGP, to exchange routing information with an outside routing domain.
It may seem overly protective to use BGP to exchange just a handful of routes, but consider:
•
•
•
Based on these facts, you should use BGP when exchanging routing information with any routing domain outside your administrative control.
Note:
Filter Routes Aggressively at the Extranet Edge
Filtering at the network edge should be based on allowing the minimum necessary, rather than accepting everything except a few selected networks. In other words, filters used to limit the routes learned through BGP at the network edge should deny all routes by default, permitting just those necessary to reach the hosts and servers needed in each network.
Beyond this basic filtering, also make certain your outside peer does not advertise again your routes to other peers. While there is no way to guarantee this, you can mark the routes you advertise to your extranet peer with the NO_EXPORT community, which instructs their routers not to advertise the route to any of their external peers. For more information on using the NO_EXPORT community, see:
•
•
Also see the latest Cisco IOS Software IP Routing Configuration Guide. An example of setting the NO_EXPORT community is given in the sample Extranet BGP Configuration below.
You should also refuse to accept any routes from an extranet peer which do not originate within the extranet itself, and refuse to propagate route learned from an extranet peer to any other external BGP peers you may have configured. The easiest way to accomplish both of these tasks is to use AS Path filters on every eBGP peering session in your network. Effectively, you want to filter any routes you receive which have an AS Path length greater than 1 (or any AS Path containing more than one autonomous system), and you want to prevent your edge routers from advertising any routes not originating within your autonomous system (any route with AS Path length of greater than 1).
For more information on AS Path filters, see Using Regular Expressions in Cisco IOS, and the Cisco IOS Software Configuration Guides.
Dampen Prefixes Aggressively at the Extranet Edge
Route dampening is designed to prevent constant changes in a single prefix learned from an eBGP peer from destabilizing the local routing system. This can specifically address concerns about constantly changing routing information impacting the stability and convergence times of local routing, as discussed in the Extranet Connections and Forcing the Routing Protocol to Converge More Slowly By Injecting Flapping Routing Information sections above. For more information on route dampening, see Configuring Route Dampening, and the Route Flap Dampening Case Study.
The route dampening parameters given in most examples are not aggressive enough for most extranet connections, however. You will probably want to dampen routes you've learned from an extranet much more quickly than routes you've learned from an ISP for two reasons:
•
•
BGP route flap dampening has five parameters:
bgp dampening <half-life-period> <reuse-threshold> <suppress-threshold> <maximum- suppress-time> <restart-penalty>It is important to consider how many times a route should flap before dampening it, and how long you want it to be dampened before you allow it to be reinstalled in the routing table. You probably want the route to be suppressed rapidly, but you also want it to be advertised again in a fairly short period of time once it stops flapping-and you want to leave it out of the table for as long as it is flapping. Set the parameters to:
•
•
•
•
•
Limiting Route Count at the Extranet Edge
Extranet connections tend to have a very limited scope-there exists a set of well-defined routes accepted, so it is relatively easy to know, with some margin of error, how many routes you should be receiving over an extranet connection. One other filter you can implement on your network edge to prevent an outside network from flooding your network with extraneous network information, possibly overloading your network, is to limit the number of routes your routers can learn through BGP from the extranet. For more information on limiting the number of routes a BGP peering session will accept, see Configuring the BGP Maximum-Prefix Feature.
Generally, the maximum number of prefixes accepted should be set to a low number. For example, if you would normally expect the number of prefixes received across the BGP session with an extranet to be less than 20, then you set the maximum number of prefixes allowed to 30, which allows for some change in the partner's network, and would, at the same time, provide some protection for your network.
Sample Extranet BGP Configuration
Figure 14 illustrates a pair of extranet connections; sample configurations with comments follow.
Figure 14
A Sample Extranet Connection
Connections to the Internet
Connections to the Internet are often treated in the same way connections to extranets are treated-but there are several differences between the two to be considered, including route filtering, protecting the local network from becoming a transit, and different parameters in route dampening. Some of these issues are not directly security related, so they are only touched on here to give a complete picture of BGP use when connecting to an ISP.
For more information on general recommendations when connecting to an ISP, see Recommended Internet Service Provider Security Services and Procedures, RFC3013.
Route Filtering
Router filtering is very important for network security when you are connecting to the Internet through a service provider, but generally it is a different type of filtering than what is applied to extranet connections. Rather than denying all routes by default and permitting only a limited number of routes, you want to permit most routes, denying only specific routes. The routes you want to deny are:
•
•
•
Protecting Against Transit
If a network is connected to two ISPs, it is possible for the two ISPs to see the network as a transit network, capable of passing traffic between the two ISPs. See Figure 15.
Figure 15
Two Service Providers Transiting Traffic Through BigShoes, Ltd.
Normally, traffic between 10.1.1.0/24 and destinations in AS65004 should travel to AS65000, a service provider, then through AS65003, another service provider, to AS65002, and finally to AS65004 (the blue traffic path shown in the illustration). However, it is possible for traffic to flow from AS65005 to AS65000, then through AS65001 to AS65002 to AS65004, using BigShoes, Ltd.'s, corporate network as a transit between AS65000 and AS65002. Although this isn't a routing protocols security issue, it is an issue for resource utilization within BigShoes, Ltd. It is important for the routers at the edge of AS65001 to be configured to prevent routing information learned from AS65000 from being advertised to AS65002, and to prevent routing information learned from AS65002 from being advertised to AS65000.
The simplest configuration allowing this is to permit only routes originating in AS65001 to be advertised to AS65002 and AS65000 using an AS Path filter at these edge routers. For more information on configuring this type of filter, see BGP Case Studies, BGP Filtering section, and Using Regular Expressions in Cisco IOS.
Route Dampening
Route dampening is discussed in the section above on connecting to extranets; the primary difference when using route dampening on a connection to an Internet service provider is the aggressiveness of the dampening parameters. For more information on the recommended route dampening parameters when connecting to an ISP, see RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters (ripe-229).
Connections Within the Network
This discussion has considered protecting routing within the network from attacks through outside connections-but the largest threats to routing are going to come from insiders. You need to consider how to prevent attacks on your routing system through connections to open ports in wiring closets (especially at remote sites) as well. Many of the techniques discussed so far, including peer authentication and others, will mitigate many of these attacks, but there are two other techniques discussed below that will improve security against internal attacks.
Route Filtering Within the Network
Route filtering should also be employed within a network, at topological edges, to prevent false routing information from being injected. Typically, consider filtering routing information coming from remote sites back to a central location (or data center), and filtering routing information coming from any open areas of the network, such as lab networks. Figure 16, with the configuration following, demonstrates filtering routes received from remote sites.
Figure 16
Filtering Routes Within a Network
On router A, the routes learned from each of the remote networks are filtered to prevent false routing information from being injected from one of the remote sites. This filter isn't a "strict" filter, but more of a precaution, as it is shown here, to reduce the amount of administrative overhead associated with configuring and maintaining the filter.
!hostname router-a!access-list 10 permit 10.2.64.0 0.0.15.255!router eigrp 100network 10.0.0.0# distribute list in from remote site B, 10.1.64.0/24distribute-list 10 in serial 0/1.1# distribute list in from remote site C, 10.1.65.0/24distribute-list 10 in serial 0/1.1# distribute list in from remote site D, 10.1.66.0/24distribute-list 10 in serial 0/1.1....# distribute list in from remote site E, 10.1.67.0/24distribute-list 10 in serial 0/1.1For more information on filtering routing updates, see:
•
•
•
Traffic Segregation and Routing Protocol Traffic Filtering
One technique you can use to protect routing protocols, and the routing system, from internal attack to is segregate transit links from nontransit links in the network (Figure 17.)
Figure 17
Transit Links and Traffic Segregation
In this network, traffic leaving A and traveling to E first crosses through the link between routers B and C, passing by servers F, G, and H. This link is a transit link with servers. The packets are then forwarded by router C to the C-to-D link, across another transit link, and then, finally, the packets are forwarded by D to the final destination, host E. The links between A and B, and D and E, are considered access links since hosts are attached to the network on those links, and the links from C to D are considered transit links, since traffic transits those links.
The link between B and C, however, is a mixed link; it transits traffic, and there are servers attached to the segment. Generally, from a network design standpoint, this is a bad practice. From a network security standpoint, this is a bad idea as well, for several reasons-because routers B and C can be attacked directly by servers F, G, or H, if any of those servers are compromised, including the peering session between the routers. For example, even if you are running some solution such as BTSH on all the routers in this network, servers F, G, and H would be able to directly attack routers B and C by injecting routing protocol packets from on segment.
Further, while you can filter all routing protocol traffic from being accepted on the access links attached to Routers B and D, you cannot filter routing protocol traffic on the link between Routers B and C, since Routers B and C need to be able to exchange routing information.
In general, segregate transit links and access links, and filter out routing protocol traffic at points where hosts access the network. For further information about filtering routing protocols traffic, see Filtering Routing Protocol Updates with Access Lists on Cisco Online.
Future Directions in Routing Protocols Security
Protecting Routing Information on the Wire
The primary challenge to protecting routing information on the wire is the unicast nature of IPsec and the processing and key management issues within MD5. Several steps are currently being taken in these areas, including:
•
•
•
Other possible mechanisms for securing routing data on the wire, including faster encryption algorithms for authentication signatures, are also being considered.
Protecting Against Illegitimate Devices Joining the Routing Domain
The primary focus of providing more security against illegitimate devices joining the routing domain is on the 802.1x security mechanisms available within Cisco IOS Software; see Configuring 802.1X Port-Based Authentication for more information on this technology. The work being considered is to extend the authorization information returned by the AAA server in the 802.1x authorization process, allowing the server to return a filter that can be applied to the user's port. This will allow the administrator to filter all routing protocol packets at the user's port level, preventing attackers from being able to inject routing protocol packets from a user port.
Protecting Routing Information
More direct methods of protecting the information carried within routing protocols are being discussed and examined for future implementation, particularly for BGP. Two such methods are discussed in the Internet Protocol Journal, soBGP and S-BGP. Please see the article Securing BGP Through Secure Origin BGP and Securing the Border Gateway Protocol for more information on these routing authentication and authorization methods.
Posted: Tue Sep 28 14:19:20 PDT 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
