uRPF only mitigate spoof of IP address , right ?? Also , please do clarify which pattern of source IP address that will not exist in routing table.I think, we can also filter Invalid source IP using InfastructurE ACL,right ?
Below is the example of Infrastructure ACLâŚ
GW#show access-lists
Extended IP access list InfastructurE ACL
10 deny ip 0.0.0.0 0.255.255.255 any
20 deny ip 10.0.0.0 0.255.255.255 any
30 deny ip 127.0.0.0 0.255.255.255 any
40 deny ip 172.16.0.0 0.15.255.255 any
50 deny ip 192.168.0.0 0.0.255.255 any
60 deny ip 224.0.0.0 15.255.255.255 any
70 deny ip host 255.255.255.255 any
80 deny ip 103.9.181.0 0.0.0.255 any
90 deny ip 103.12.83.0 0.0.0.255 any
100 permit ip any any
I have got that if received packet source ip not in routing table then packet will be drop but canât understand that which pattern of source IP address(which ip will not exist in RT ) that will not exist in routing table.
Letâs say our router has two entries in its routing table:
192.168.1.0/24
192.168.2.0/24
When it receives an IP packet from 192.168.1.1 or 192.168.2.2, RPF will accept it since these we have a route for these sources in our routing table. When we receive an IP packet sourced from 192.168.3.3, it will be dropped since we donât have an entry that matches 192.168.3.3 in the routing table.
I got the uRPF function clearly but want to know how uRPF prevents these spoofing attacks. Actually want want to know âspoofing attacksâ Scenario.Sorry for bothering you again n Again .Thanks
Assuming the attackerâs goal is to access the âtarget devicesâ behind R1 ( that is to establish a TCP connection with return path). The attacker that has the spoofed Source Address can indeed reach the target hosts, however when the âtarget hostâ replies , R1 will forward the reply to the legitimate device holding the âtrueâ source network ( 2.2.2.2 in your example). So in any case the attacker cannot "access " its victim, but rather send them packet with no response right ?
The example in the lesson tries to ping the actual interface of R1. Adding a host behind R1 and having the attacker try to reach that device is an even more realistic scenario, and yes, you are correct that that is what an attacker would attempt.
In such a case, when an attacker tries to reach a host on the internal network, the uRPF will still function at the router. That is, if the spoofed SOURCE address is in the routing table and corresponds to a DIFFERENT interface than that which it came in on, the packet will be blocked at R1 and will not be further transferred to the âtarget deviceâ behind R1.
uRPF essentially functions within the routing procedure of the router. It prevents the actual routing of a packet when the aforementioned conditions are met.
If you have a routing table that states that the subnet 2.2.2.0/24 for example can be reached via the Fa0/0 interface, then it is only logical that any packets with a source address of 2.2.2.X will come in to the router on that interface.
If a packet comes in to the router with a source address of 2.2.2.X from any other interface, then this behaviour is fishy . Itâs an almost unmistakable sign of an IP spoofing attack. Such an attack involves an attacker trying to hide his identity or trying to impersonate a âtrustedâ source.
Thank you for the informative article. It is much clearer than in the official certification guide! I have a couple of questions:
Does the uRPF check happen in hardware using the FIB? Or does it happen in software?
If you specify an access list at the end of the ip verify unicast. command, how does that function? If a packet matches a permit statement does that allow it to bypass the uRPF check?
It really depends on the platform you are using. Higher end platforms (6500/6800 with the appropriate supervisor as well as Nexus platforms for example) will support uRFP occurring in hardware thus providing for fast checking and no taxing of other resources.
If you specify an access list, you are essentially telling the router which range of addresses you want checked. So if a source is in the access list specified, the uRPF takes place. If it is not specified in the access list, then the uRPF check is bypassed.
Thanks for the info, but I think your second statement is incorrect. According to this page:
When you configure an access control list (ACL) and a packet fails the Unicast RPF check, the Unicast RPF checks the ACL to see if the packet should be dropped (by using a deny statement in the ACL) or forwarded (by using a permit statement in the ACL). Regardless of whether the packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.
So it seems that permitting traffic through an ACL doesnât bypass the URPF check, but does in effect override it.
Yes I stand corrected. So first the uRPF is checked regardless of the access list, and if and only if uRPF cannot find a reverse path for the packet, then it is either dropped or forwarded based on the ACL that has been specified using the ip verify unicast source reachable via command.
uRPF is a feature that checks the source address on a packet and compares it to the routing table. This means that by definition, uRPF will ONLY function on incoming packets. It can be enabled on any interface, but it will only operate on incoming packets on that interface. Packets that are exiting an interface have already gone through the routing table lookup and thus any uRPF operation cannot be applied to them.
Yes this is correct. According to Cisco:
An important consideration for deployment is that Cisco Express Forwarding switching must be enabled for Unicast RPF to function. This command has been enabled by default as of IOS version 12.2. If it is not enabled, administrators can enable it with the following global configuration command: ip cef
CEF is enabled by default on most routers so it is not so much of a concern. However, you must confirm that CEF is enabled for uRPF to operate.
uRPF is not actually a routing operation. It essentially checks certain conditions and if those conditions are met, the packet can then be routed normally. It doesnât come into play at all in load balancing or routing protocol path manipulation. In this sense, it functions more like an access list than a routing protocol. Once the conditions are met (either in loose or strict mode) the packet can then be routed normally using whatever routing protocol and whatever load balancing functionality has been configured. If they are not met, the packet is dropped before it even gets to the routing table lookup.
When you enable uRPF, it checks to see that the source of the packet is in the routing table. However, whenever a router (or any network device) pings itself, the packet flow is emulated, because the packets are actually sourced from the CPU and enter the interface buffer from inside the router itself. The return path to the routerâs own CPU doesnât go via an interface, therefore it will not be routed, therefore, the source address will not be checked against the routing table and will be dropped.
By configuring allow-self-ping, you are telling the router to modify that default behaviour of uRPF, and process a self ping as a special case, so that such pings will be successful.
The Unicast RPF drop count tracks the number of drops at the interface. The Unicast RPF suppressed drop count tracks the number of packets that failed the Unicast RPF check but were forwarded because of the permit permission set up in the ACL.
So the suppressed drop count iterates by one whenever the uRPF condition is not met, but the packet is forwarded anyway because of a permit entry in the ACL.
This has been taken from the following Cisco documentation:
. Itâs an almost unmistakable sign of an IP spoofing attack. Such an attack involves an attacker trying to hide his identity or trying to impersonate a âtrustedâ source.