IP Spoofing Part 2 | Unicast Reverse Path Forwarding

---

IP Source Guard

Unicast Reverse Path Forwarding

IP Spoofing originating from layer 3 has to be treated differently than layer 2 with switch based DHCP tracking out of scope. Another variety of intelligence is required to suppress this attack.

IP Spoofing Lab: WAN

For continuity with the previous post, I’ll spoof ICMP IP headers again but this time the spoofed source is originating from a WAN router boundary and targeting a device located across another layer 3 boundary.

Here’s the lab topology:

First, we see the attacker initiating an ICMP request using the spoofed source IP of the target:

When we look at the HQ router, ICMP debugging shows the HQ generating ICMP replies attempting to answer the attacker but sending them to the target instead:

Packet capture on the target router shows the ICMP replies arriving from the HQ router:

WAN IP Spoofing Mitigation with Unicast Reverse Path Forwarding

While IPSG enforces legitimate IP addressing on layer 2 through switch ports, Unicast Reverse Path Forwarding (uRPF) is designed to protect router’s layer 3 ports from IP spoofing.

Here is the attack and mitigation that will be performed in this lab:

The intelligence used by uRPF to inspect traffic depends on whether it is enabled in loose or strict mode. In loose mode uRPF will compare the source IP of inbound packets to its routing table and if a route to the source is present the traffic is allowed. In strict mode, the router performs an additional check to see if traffic not only is present in the routing table but if it is arriving on the same interface that the routing table route entry installed for. Note that loose mode is necessary when traffic can arrive on different interfaces from asymmetric routing.

In this lab and outlined the diagram below, we will use strict mode:

This is the routing table on the HQ router which shows the connected routes for 11.1.1.0/24 and 12.1.1.0/24:

In order to turn uRPF strict mode on the HQ router:

Here we can see uRPF debugging dropping the attacker’s spoofed ICMPs:

---

Terms of Use For Packet Orbit

By reading anything at PacketOrbit.com, you acknowledge and agree to, all of the following:

All information and software available on this site are for educational purposes only. The author is no way responsible for any misuse of the information. The website owner expressly disclaims all liability for any information presented here. The owner of this website and its posts shall not be held liable for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so at your own risk.