Reverse-Path Forwarding (Unicast Traffic)
One useful Cisco IOS tool for preventing IP address spoofing is to use reverse path forwarding (RPF). RPF can be used for both unicast and multicast traffic; however, this book focuses on only unicast traffic. With RPF, the Cisco IOS checks its routing table to determine whether to accept a packet or to drop it. RPF prevents spoofing by examining the source IP address in the packet, the interface, the packet that was received, and routing information in the routing table. If there is a contradiction?for example, the source address is not located off the interface where the router thinks the packet belongs (based on the routing table)?the router drops the packet. Remember that this kind of spoofing is common in many forms of DoS attacks, such as a Smurf attack. Unicast RPF forwards only packets with valid source IP addresses based on information found in the router's routing table. This kind of policy enforcement is common in ISPs.
RPF Process
Refer to Figure 15-5 for this next illustration of RPF. Here is a simplified routing table based on the perimeter router's configuration:
199.1.1.0/24 E1 199.1.2.0/24 E0 199.1.3.0/24 E0 199.1.4.0/24 E0 199.1.5.0/24 E0 199.1.6.0/24 E0 199.1.7.0/24 E0 0.0.0.0/0 E1
Figure 15-5. Unicast RPF Example
As an example, assume that the perimeter router receives a packet on E0 with an IP address of 199.1.0.5. With RPF, the router knows that this is not valid because 199.1.0.0/25 is located off E1. In this instance, the router drops the packet. Basically, the router compares the source IP address with the routes in the routing table, to make sure that the packet is received off the correct interface. The router matches source IP packets only against best paths (the ones populated in the routing table).
If an inbound ACL is applied to the interface on which RPF is enabled, the router first checks the ACL and then performs its RPF check.
NOTE
For RPF to function, CEF must be enabled on the router. This is because the router uses the Forwarding Information Base (FIB) of CEF to perform the lookup process, which is built from the router's routing table. In other words, RPF does not really look at the router's routing table; instead, it uses the CEF FIB to determine spoofing.
Also, RPF cannot detect all spoofed packets. For the network in this example, the perimeter router cannot determine spoofing from packets received on the external E1 interface if they match the default route statement. Therefore, the more routes your router has in its CEF FIB table, the more likely the router will be capable of detecting spoofing attacks. In addition, RPF cannot detect any spoofed packets that are encapsulated, such as packets encapsulated in GRE, IPSec, L2TP, and other packets.
CAUTION
If you are using BGP on your perimeter router and have configured properties such as local preference and weight, this could affect the best path to the source and thus also could affect the operation of RPF. Therefore, care must be taken when using RPF and BGP.
ACL Enhancements
Unicast RPF forwarding supports ACLs for finer filtering. With the ACL feature, you associate an ACL with RPF. The Cisco IOS then uses the ACL to determine whether the RPF feature should be applied to packets entering the interface. First, RPF is used to determine whether the packet is spoofed. If it is, the Cisco IOS uses the ACL to determine the action performed on the packet. A permit statement in the ACL causes the spoofed packet to be allowed; a deny statement drops the spoofed packet.
NOTE
Without an associated ACL, RPF automatically drops packets that it believes to be spoofed.
One nice feature with the ACL association is that the Cisco IOS keeps traffic statistics for the Unicast RPF drops. If you add the log parameter to your ACL statements, the router creates a log record of spoofed packets (deny or permit statement matches).
CAUTION
If a DoS spoofing attack is occurring, the attack might drain your router's resources, especially if you are using RPF ACLs with logging enabled. Therefore, care must be taken when using this feature with the ACL log parameter.
Statistics
The Cisco IOS keeps track of two types of RPF statistics: global and interface. RPF global statistics can be used to display information about possible attacks against your network, but they are not helpful in determining the source of the attack (which interface). However, you can use the per-interface statistics to determine the source. Two types of per-interface RPF statistics are used:
Drops? Number of spoofed packets that were dropped
Suppressed drops? Number of spoofed packets that were permitted (not dropped because of a match on a permit statement in an RPF ACL)
Note that these are general statistics. If you want to see the actual source addresses of packets that are being dropped, you must enable RPF ACL logging.
RPF Usage
RPF works best at the perimeter of your network. If you use it inside your network, it is used best when your routers have more specific routes. With route summarization, a spoofing attack could be in process, and it would be difficult to determine which part of the summarized route the attack is occurring from. For external threats, the more ISPs and companies use RPF, the more likely it is that spoofing attacks can be a thing of the past. However, the more point-of-presence (POP) connections that an ISP has, the more difficult it becomes to use RPF because multiple paths might exist to the source. Using RPF as close to the sources of the addresses as possible is the best solution for ISPs directly connected to their customers.
RPF is deployed best on perimeter routers in networks that have a single connection to the outside world. Of course, RPF will work in multiple-connection environments, as well as with internal routers, but it might not provide the optimum solution in detecting spoofed packets. Figure 15-6 shows an example of the problem that can occur when using RPF in a dual-connection network. In this example, the perimeter router uses interface S0 to send traffic to the remote site. However, using BGP, the Internet has determined that the best path to return the traffic to the network on the left is to send this through S1 on the perimeter router. This creates a problem on the perimeter router with RPF because using its routing table, the router expects this traffic to come through S0. In this instance, the router would drop the returning traffic.
Figure 15-6. RPF and Dual-Connection Problems
One exception to using RPF for single connections is to use dialup access on an access server. One of the main sources of spoofing attacks is dialup access. By using RPF on your access servers, you can limit your exposure to this method of spoofing attack.
An alternative to RPF is to use ACLs. However, the main problem of ACLs are their performance and day-to-day maintenance. RPF, on the other hand, relies on information from the routing table, which can be built statically or dynamically. With CEF handling the process, you are not taking a performance hit.
RPF Limitations
Despite its advantages and usefulness in detecting and preventing spoofing attacks, RPF has the following limitations:
RPF requires CEF to function. Routers that do not support CEF or that have it disabled cannot use RPF.
Your routing table uses asymmetric routes to send traffic to and from a destination. In this situation, different paths are used; this creates problems with RPF by generating false positives for spoofing. Therefore, a single connection to the Internet on the router is the best situation in which to use RPF (you can have multiple connections to the Internet?just make sure that each of these connections is on a separate router).
RPF typically does not do well when activated on internal interfaces of routers (interfaces connected to the internal network) because of asymmetrical routing issues.
If you have any of these limitations, use ACLs to prevent spoofing attacks instead of RPF.
RPF Configuration
Before you configure RPF, make sure that you perform the following:
Set up egress filtering: Permit only source addresses that you have assigned, or allow and deny everything else. If you are using RPF, use an egress filter to define egress policies.
Set up ingress filtering: Deny all bogons and allow only connections to specific internal resources. Also examine source addresses for other anomalies, such as loopback interfaces, RFC 1918 addresses, broadcast addresses, and so on.
Set up an RPF ACL to handle issues with asymmetric routing if you have dual Internet connections on one router and returning traffic comes from a different network than what it used to reach it.
Optionally, enable logging on your RPF ACL entries to get a better idea of what traffic is being spoofed.
When you have done this, you are ready to set up unicast RPF. Of all of the features on the router, unicast RPF is one of the easiest to set up. The first thing you need to do is enable CEF:
Router(config)# ip cef
or
Router(config)# ip cef distributed
Use one of these two commands based on your router model. Remember that CEF must be enabled to use RPF. The distributed parameter is used on certain 7000 series routers and higher to allow line cards to perform express forwarding for those cards that support it, but to still allow the route process to handle normal routing functions, as well as switch traffic to and from legacy line cards.
After you have enabled CEF, you are ready to enable RPF. RPF must be activated on each interface that you want to check for packet spoofing. Typically, this is your router's external interface(s):
Router(config)# interface type [slot_#/]port_# Router(config-if)# ip verify unicast reverse-path [ACL_#_or_name]
The optional ACL enables you to specify what actions to take for packets that RPF deems to be spoofed. A permit entry in the ACL allows the packet (used to bypass asymmetrical routing issues), and a deny entry drops the packet. If you include the log parameter in your ACL entries, you can keep track of how often spoofing is occurring.
TIP
If you are using HSRP and you want to disable both RPF and CEF, make sure that you disable RPF first and then disable CEF. Failure to do this in the appropriate order will cause an HSRP failure to occur.
RPF Verification
When you have enabled CEF and RPF, you can verify its configuration with the following command:
Router# show cef interface [type [slot_#/]port_#] [statistics] [detail]
Example 15-16 shows output from the show cef interface command.
Example 15-16. Using the show cef interface Command
Router# show cef interface serial 2/0/0 Serial2/0/0 is up (if_number 8) Internet address is 199.1.1.1/24 ICMP redirects are never sent Per packet loadbalancing is disabled IP unicast RPF check is enabled Inbound access list is not set Outbound access list is not set Interface is marked as point-to-point interface Packets switched to this interface on linecard are dropped to next slow path Hardware idb is Serial2/0/0 Fast switching type 4, interface type 6 IP Distributed CEF switching enabled <--output omitted-->
As you can see in this example, RPF is enabled.
Besides using the previous command, you can use others to perform unicast RPF troubleshooting:
show ip traffic? Displays global unicast RPF statistics about drops and suppressed drops.
show ip interface? Displays per-interface unicast RPF statistics.
show access-lists? Displays ACL statistics on matches (as well as logging entries if the log parameter has been configured on your ACL statements).
Example 15-17 shows output from the show ip traffic command.
Example 15-17. Using the show ip traffic Command
Router# show ip traffic IP statistics: Rcvd: 0 total, 0 local destination 0 format errors, 0 checksum errors, 0 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options Opts: 0 end, 0 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 0 record route 0 stream ID, 0 strict source route, 0 alert, 0 other Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble 0 fragmented, 0 couldn't fragment Bcast: 0 received, 0 sent Mcast: 0 received, 0 sent Sent: 0 generated, 0 forwarded Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency 0 no route, 0 unicast RPF, 0 forced drop
Unicast RPF Example
Use the network shown previously in Figure 15-6 for this next illustration of how to use RPF. As you recall, this example had an asymmetrical routing issue, which inadvertently dropped traffic from a remote site (200.1.1.0/24). Example 15-18 shows the configuration to drop spoofed packets yet allow the asymmetrical routing for 200.1.1.0/24.
Example 15-18. Using RPF with Asymmetrical Connections
Router(config)# ip cef Router(config)# ip access-list extended RPF-ACL Router(config-ext-nacl)# permit ip 200.1.1.0 0.0.0.255 199.1.0.0 0.0.7.255 Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface serial0 Router(config-if)# ip verify unicast reverse-path RPF-ACL Router(config-if)# exit Router(config)# interface serial1 Router(config-if)# ip verify unicast reverse-path RPF-ACL Router(config-if)# exit
