Wednesday, February 24, 2010

Secure Routing

Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding (URPF) is a tool implemented on routers to thwart attempts to send packets with spoofed source IP addresses. A spoofed source IP address makes tracking the real source of an attack very difficult. For example, if site A is getting attacked with ICMP floods coming from a source IP address in the range 150.1.1.0/24, the only place for that site to look to stop this kind of attack is the network that contains the 150.1.1.0/24 subnet (site B). However, more than likely, the packets are actually coming from some other network (site C), often compromised too, that does not contain the 150.1.1.0/24 subnet. However, other than tracking the source of the packets one hop at a time, the attacked entity has no way of determining this. In this situation, it would be great if site C's network administrators (and, ideally, the administrators of all the other sites on the Internet) had some sort of mechanism in place on their routers that does not allow packets with source IP addresses not in the range belonging to their respective sites to go out.

URPF works by looking for the source IP address of any packet arriving inbound on an interface of a router in its routing table. Logically, if the source IP address belongs to the network behind the router and is not a spoofed address, the routing table contains an entry showing the router a way to get to that address via the interface on which the packet arrived. However, if the address is spoofed, there probably isn't an entry in the routing table, because the address does not lie behind the router, but is stolen from some other network on the Internet (site B in our example). If the router does not find the source IP address when it does the lookup, it drops the packet.

One thing to note here is that URPF needs to have Cisco Express Forwarding (CEF) enabled on the router. URPF looks at the Forwarding Information Base (FIB) that is generated by CEF rather than looking directly at the routing table. This is a more efficient way of doing the lookup. Figure 4-2 demonstrates how URPF works.


Figure 4-2 shows to two scenarios. In Scenario 1, a packet is allowed to pass through the router after it successfully passes the URPF check. In Scenario 2, a packet is dropped because it fails the URPF check. Let's look at each scenario separately, and in sequence:

Scenario 1:

1. The packet arrives on S0 with a source IP address of 90.1.1.15.

2. URPF does a reverse rate lookup on the source IP address and finds it can be routed back through S0.

3. URPF allows the packet to pass through.


Scenario 2:

1. The packet arrives on S1 with a source IP address of 90.1.1.19.

2. URPF does a reverse rate lookup on the source IP address and finds it can be routed back through S0 and not S1.

3. Because the interface on which the packet arrived is not the same one through which it can be routed back, URPF causes the packet to be dropped.


Configuring URPF is fairly simple. However, you should be careful when choosing the right place to configure it. It should not be set up on routers that might have asymmetric routes.

Asymmetric routing is said to occur when the interface through which the router sends return traffic for a packet is not the interface on which the original packet was received. For example, if the original packet is received on interface X, the return traffic for it is sent out via interface Y. Although this might be a perfectly legitimate arrangement for a network, this situation is incompatible with URPF. The reason is that URPF assumes that all routing occurring on a router is symmetric. It drops any traffic received on the router for which the return path is not through the same interface as the one on which the traffic is being received.

Generally, the best place to apply URPF is on the edge of a network. The reason is that this allows URPF's antispoofing capabilities to be available to the entire network rather than just a component of it.


Path Integrity

After routing protocols have been set up in a secure fashion, it is important to ensure that all traffic is routed based on the paths calculated as optimum by the routing protocols. However, some features in IP can let changes be made to the routing decisions that routers would make if they were left alone to rely on the routing protocols themselves. Two of the most important features in this regard are ICMP redirects and IP source routing.


ICMP Redirects

ICMP redirects are a way for a router to let another router or host (let's call it A) on its local segment know that the next hop on the same local segment it is using to reach another host (B) is not optimal. In other words, the path should not go through it. Instead, host A should send the traffic directly to the next hop in the optimal path to host B. Although the router forwards the first packet to the optimal next hop, it expects the sending host A to install a route in its routing table to ensure that next time it wants to send a packet to B, it sends it to the optimal next hop. If the router receives a similar packet again, it simply drops it.

Cisco routers send ICMP redirects when all the following conditions are met:
  • The interface on which the packet comes into the router is the same interface on which the packet gets routed out.
  • The subnet/network of the source IP address is the same subnet/network of the routed packet's next-hop IP address.
  • The datagram is not source-routed.
  • The router kernel is configured to send redirects.

Although redirects are a useful feature to have, a properly set-up network should not have much use for them. And it is possible for attackers to use redirects to change routing in ways that suit their purposes. So it is generally desirable to turn off ICMP redirects. By default, Cisco routers send ICMP redirects. You can use the interface subcommand no ip redirects to disable ICMP redirects.


IP Source Routing

IP source routing is an IP feature that allows a user to set a field in the IP packet specifying the path he or she wants the packet to take. Source routing can be used to subvert the workings of normal routing protocols, giving attackers the upper hand. Although there are a few ways of using source routing, by far the most well-known is loose source record route (LSRR), in which the sender defines one or more hops that the packet must go through to reach a destination.

Tuesday, February 9, 2010

Secure Routing

Building Security into Routing Design

In order to have a secure network, it is essential that you build security into how traffic flows in the network. Because routing protocols determine how traffic flows in the network, it is essential to make sure that the routing protocols are chosen and implemented in a manner that is in line with the security requirements of the network. Needless to say, a network with a secure routing architecture is less vulnerable to attacks and oversights than a network with a poorly designed routing structure. A properly designed routing infrastructure can also help reduce the downtime a network suffers during a network attack.


Route Filtering

Proper route filtering is important to any well-implemented network. It is especially important in a private network with routing links to the outside world. It is important in these networks to ensure that route filtering is used to filter out any bogus or undesired routes coming into the private network as well as make sure that only the routes actually contained on the internal network are allowed to be advertised. It is also important to make sure that the only advertised networks are those for which access from outside the private network is desired.

On any private network connected through an ISP to the Internet or a larger public network, the following routes should be filtered from entering the network in most situations (this filtering can also be carried out on the ISP routers):
  • 0.0.0.0/0 and 0.0.0.0/8— Default and network 0 (unique and now historical properties)
  • 127.0.0.0/8— Host loopback
  • 192.0.2.0/24— TEST-NET, generally used for examples in vendor documentation
  • 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16— RFC 1918 private addresses
  • 169.254.0.0/16— End node auto-config for DHCP
  • 224.0.0.0/3— Multicast addresses
The addresses belonging to the address space reserved by IANA can also be blocked. See the following URL for IANA address space allocations: www.iana.org/assignments/ipv4-address-space.

Filters can also be set up to ensure that IP address blocks belonging to a private network are not allowed to be advertised back into the network from outside. This is a necessary precaution to protect the traffic intended for some of the hosts on the inside network from being routed somewhere unintended.

Route filtering can also be used to hide one piece of a network from another. This can be important in organizations that need varying amounts of security in different parts of the network. In addition to having firewalls and other authentication mechanisms in place, route filtering can also rule out the ability of machines in a less-secure network area to reach a more-secure area if they don't have a route to that portion of the network. However, route filtering should not be used as the sole network security measure.

Applying filtering correctly is important as well. It is a good practice to filter both incoming and outgoing routes. Ingress filtering ensures that routes not intended for a network are not flooded into it during an erroneous or malicious activity on another network. Also, if something goes wrong in one part of the network, egress filtering can stop that problem from spreading to the rest of the network.

ISPs can also consider using what is called a net police filter, whereby no routes with prefixes more specific than /20 (or perhaps up to /24) are allowed to come in. This is often done to make sure that an attack cannot be staged on a large ISP's router by increasing the size of its routing tables. Routes more specific than /20 are often not needed by large ISPs.

Therefore, an ISP can filter out these routes to keep its routing table from getting out of control in terms of size. How specific a prefix a router should accept should be determined by a network administrator who understands what is necessary for the router to perform its functions properly.


Convergence

Fast convergence is important for having a secure routing infrastructure. A network that is slow to converge takes longer to recover from network-disrupting attacks and thus aggravates problems. On an Internet-wide basis, slow convergence of BGP for interdomain routing can mean a considerable loss of revenue for a large number of people. However, even for a small network, slow convergence can mean loss of productivity for a significant number of people.

A slow-converging network is also liable to be more susceptible to a denial of service (DoS) attack. The loss of one or two nodes at a time, making the network take a long time to converge, could mean that a DoS attack confined to just one node actually spreads to the whole network.

At various points in this chapter, we will touch on convergence and how it can be improved. In general, a network's convergence speed can depend on a lot of factors, including the complexity of the network architecture, the presence of redundancy in the network, the parameters set up for route calculation engines on the various routers, and the presence of loops in the network. The best way to improve convergence speed is for the network administrator to thoroughly understand the workings of the network and then to improve its convergence speed by designing the network around the aspect of faster convergence.


Static Routes

Static routes are a useful means of ensuring security in some circumstances. Static routes might not scale to all situations, but where they do, they can be used to hard code information in the routing tables such that this information is unaffected by a network attack or occurrences on other parts of the network. Static routes are also a useful way to define default route information.


Router and Route Authentication

The reason for having router and route authentication and route integrity arises from the risk of an attacker who configures his or her machine or router to share incorrect routing information with another router that is part of the network being attacked. The attacked router can be tricked into not only sending data to the incorrect destination, but through clever maneuvering can be completely put out of commission as well. Routing changes can also be induced simply to redirect the traffic to a convenient place in the network for the attacker to analyze it. This can result in the attacker's being able to identify patterns of traffic and obtain information not intended for him or her.

An example of such attacks occurs in RIP environments where bogus RIP route advertisements can be sent out on a segment. These updates are conveniently accepted into their routing tables by the routers running RIP unless an authentication mechanism is in place to verify the routes' source.

Another issue that prompts router authentication, especially in BGP, is the fear of an attack wherein a rogue router acting as a BGP speaker and neighbor advertises a lot of specific routes into a core router's routing table, causing the router to stop functioning properly due to the greatly increased size of its routing table.

There are two main ways in which Cisco routers provide security in terms of exchanging routing information between routers:
  • Authenticating routers that are sharing routing information among themselves so that they share information only if they can verify, based on a password, that they are talking to a trusted source
  • Authenticating the veracity of the information being exchanged and making sure it has not been tampered with in transit
Most major routing protocols support these measures. There are two ways that routers are authenticated to each other when sharing route information:
  • By using a clear-text key (password) that is sent along with the route being sent to another router. The receiving router compares this key to its own configured key. If they are the same, it accepts the route. However, this is not a very good method of ensuring security, because the password information is sent in the clear. It is more a method to avoid misconfigurations than anything else. A skilled hacker can easily get around it.
  • By using MD5-HMAC, the key is not sent over the wire in plain text. Instead, a keyed hash is calculated using the configured key. The routing update is used as the input text along with the key into the hashing function. This hash is sent along with the route update to the receiving router. The receiving router compares the received hash with a hash it generates on the route update using the preshared key configured on it. If the two hashes are the same, the route is assumed to be from a trusted source. This is a more secure method of authentication than the clear-text password, because the preshared secret is never shared over the wire.
The second method of authentication using MD5-HMAC also allows for checking route integrity. If the route information is tampered with during transit, the receiving router upon calculating the hash on the route information finds the hash to be different from the hash sent by the original router. Even if an attacker intercepts the route information and injects a new hash after changing the route information, the attempt fails, because the attacker does not know the correct key to calculate the hash. That key is known only to the sending and receiving routers. Figure 4-1 shows how route authentication occurs on Cisco routers.