Filtering Traffic Using Unicast Reverse-Path Forwarding

Problem

You want to more adequately filter traffic that is not coming through the proper interfaces to better prevent spoofing.

Solution

Turn on unicast reverse-path forwarding ( RPF) on the router:

	[edit routing-options]
	aviva@router1# set forwarding-table unicast-reverse-path active-paths

Then enable it on the desired interface:

	[edit interfaces so-0/0/0  unit 0 family inet]
	aviva@router1# set 
rpf-check 

 

Discussion

Unicast RPF is an extension of RPF, which is used by IP multicast routing protocols to prevent multicast routing loops. As the name implies, unicast RPF verifies unicast source addresses. When a router receives a packet, unicast RPF performs a route lookup on the source address to determine the interface closest to the source address (the reverse path to the source). If the receiving interface is not the closest interface, the packet is dropped.

Unicast RPF is one mechanism for dealing with address- spoofing DoS attacks. In these attacks, an intruder floods its target with packets that contain a spoofed source address, essentially impersonating another system's IP address. The flooding results in a DoS at the target, and because the source address is spoofed, the true source of the traffic is difficult to trace. UDP applications are more vulnerable to spoofing attacks than TCP applications because, though TCP uses sequence numbers and handshakes that require more than a single packet to establish and maintain a session, UDP applications perform their own internal verification to ensure that a given source is who it says it is and that the IP headers in the source of the packets have not been forged. rlogin and other Unix r-utilities and X Windows are commonly subject to spoofing attacks. DNS servers are also vulnerable to spoofing, because they regularly send queries to obtain the IP addresses of hosts, and cache this information, but do not authenticate the source of the answers they receive. This operation makes it possible for an attacker to send false or improper answers to DNS queries, thus poisoning the cache.

Figure 8-1 illustrates how a spoofing attack might work. The attacker, somewhere on the Internet at 10.0.0.1, sends packets through your router to one of your customers at 172.16.0.2.

Figure 8-1. DoS attack scenario

In a normal packet, the source address in the packet's header would be 10.0.0.1. The attacker modifies the packet's header, spoofing the source address and changing it to 172.16.0.3. The attacker then floods your customer with spoofed packets. The flood can look like it's coming from several compromised hosts all spoofing random addresses, or the source addresses will remain. To protect your customer from attacks, you configure unicast RPF on the router's interface A.

Configuring unicast RPF is a two-step process. First, enable it on the router with the unicast-reverse-path statement in the [edit routing-options] hierarchy. With the active-paths option, unicast RPF considers all active routes in the routing table when checking how to reach the packet's destination. Use this option if the routing paths through your network are generally symmetrical. However, if paths are asymmetrical, unicast RPF might drop legitimate packets. In this case, use the feasible-paths option to consider both active and nonactive routes in the routing table.

Then, select the interfaces on which to run unicast RPF. Use the set rpf-check command when configuring the interface's address family. This command places unicast RPF in strict mode, which, as the name suggests, performs the most stringent examination of incoming packets. Strict-mode unicast RPF checks that the source address in each incoming packet matches a prefix in the routing table and verifies that the interface is the closest to the source address and is the interface the router would use when sending packets to that address. An interface drops any packets that do not meet both these criteria.

A second mode, loose mode, performs only one of these checks, making sure that the source address matches a routing-table prefix but not verifying that the incoming interface as the one closest to the source address:

	[edit interfaces so-0/0/0  unit 0 family inet]
	aviva@router1# set rpf-check mode loose 

Loose-mode unicast RPF is good for filtering traffic that is sourced from bogon (invalid) address space and can be used in conjunction with or instead of routing policy filters that block specific bogon addresses. A key point to keep in mind when using loose-mode unicast RPF is whether your network uses a 0.0.0.0/0 ( default) route. The router automatically accepts all packets when loose-mode unicast RPF is configured on interfaces that the default route uses, so it may not be a good fit in your network for this reason.

To verify the configuration, look at the statistics on the logical interface:

	aviva@router1> show interfaces so-0/0/0.0 statistics
	 Logical interface so-0/0/0.0 (Index 67) (SNMP ifIndex 41)
	 Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
	 Protocol inet, MTU: 4470
	 Flags: 
uRPF
	  
RPF Failures: Packets: 23, Bytes: 2492
	 Addresses, Flags: Is-Preferred Is-Primary
	 Destination: 10.1.12.0/30, Local: 10.1.12.1, Broadcast: 10.1.12.3
	 Protocol iso, MTU: 4470
	 Flags: Is-Primary
	 Protocol mpls, MTU: 4458
	 Flags: Is-Primary

The Flags field shows that unicast RPF is enabled, and the next line shows the number of packets and bytes dropped because of unicast RPF checks.

When you think the router is experiencing a DoS attack, set up a firewall filter to count the packets dropped by the interface. Create a separate filter to count the unicast RPF traffic:

	[edit firewall]
	aviva@router1# set filter rpf-filter term default then count rpf-failed-count
	aviva@router1# set filter rpf-filter term default then reject
	aviva@router1# show
	filter rpf-filter {
	 term default {
	 then {
	 count rpf-failed-count;
	 reject;
	 }
	 }
	}

This filter has no from clause, so it applies to all incoming packets. The then clause creates a file named rpf-failed-count and rejects all packets. Then apply the filter to the interface:

	[edit interfaces so-0/0/0 ]
	aviva@router1# set unit 0 family inet rpf-check 
fail-filter rpf-filter 

Reference the filter you created in the fail-filter option of the rpf-check statement. Unicast RPF filters are not part of the normal firewall filter on an interface but are handled separately. They are evaluated after input filters and before output filters. Unicast RPF looks only in the inet.0 routing table for IPv4 packets and the inet6.0 table for IPv6 packets, so if an interface's input filter forwards packets to a different routing table, the unicast RPF check is not performed.

Check the firewall filter counts with the following command:

	aviva@ 
router1> show firewall filter  
rpf-failed-count
	Filter: 
rpf-filter
	Counters:
	Name Bytes Packets
	rpf-failed-count 2492 23

 

See Also

Recipe 9.8