Hi,
Using Loose Method:
ip verify unicast source reachable-via any
There is only a check if a matching prefix is in the RIB
Protects against:
- RFC1918 Spoofings
- Other Special Use Addresses (DUSA)
- Unallocated Addresses
- Source addresses routed to NULL Interface
[...]
If the source address of an incoming packet is resolved to a null adjacency, the packet will be dropped.
The null interface is treated as an invalid interface by the new form of the Unicast RPF command.
[...]
Regarding the last topic - NULL routes:
Customer has a PI called 1.2.0.0/15
He wants to supress Spoofing Attacks from Source 1.2.0.0/15 coming from Internet, he also configured a static route 1.2.0.0/15 to NULL.
But now there is also static route with a longer prefix configured – 1.2.0.0/16
So the regular route lookup would prefer the /16 route over the NULL.
Routing entry for 1.2.0.0/16
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 9.8.7.6
Routing entry for 1.2.0.0/15
Known via "static", distance 200, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Null0
Question:
What does this to the ip verify unicast source feature?
Is it still looking for NULL routes in the RIB and dropping Packets from Internet with source 1.2.0.0/15, or since there is now a more specific route only for 1.3.0.0/16?
In that case they would need an Spoofing ACL on the outside interface again.....
Thanks in advance for any hints!
Hi Mahesh,
yes, Strict Mode is not an option here because of a Mulithomed ISP Uplink setup...
The ACL option is a good hint, one thing would be interesting for me in this relation:
What's the performance impact of using an ACL list as uRPF option in relation to a simple traffic ACL on the interface?
What's more gentle for my Router blocking Spoofed Pakets with own IP Prefix as Source Address?
Finally I've tested the Loose Mode with more specific Routes and less specific NULL route.
We can see that the Lookup in the RIB is as usual for uRPF - a more specific Route overrules the less specific NULL Route and so the Spoofing of own IP Prefixes is not blocked in this case.
## Initial Configuration:
===============
interface FastEthernet0/0
ip address 172.16.10.254 255.255.255.0
no ip redirects
no ip proxy-arp
interface FastEthernet0/1
ip address 172.16.20.254 255.255.255.0
no ip redirects
no ip proxy-arp
## Notice NULL Route, covering longer prefix 172.16.10.0/24
R1#sh ip route
172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
S 172.16.0.0/20 is directly connected, Null0
C 172.16.10.0/24 is directly connected, FastEthernet0/0
L 172.16.10.254/32 is directly connected, FastEthernet0/0
C 172.16.20.0/24 is directly connected, FastEthernet0/1
L 172.16.20.254/32 is directly connected, FastEthernet0/1
## Spoofing Test without "ip verify unicast source" - Source == Destination:
===========================
gans@ubuntu3:~$ sudo nmap -PN -e eth1 -S 172.16.10.10 172.16.10.10 -p 80
Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-21 20:28 CET
gans@ ubuntu2:~$ sudo tcpdump -i eth1 port 80
20:28:33.106402 IP 172.16.10.10.52901 > 172.16.10.10.www: Flags [S], seq 1888407804, win 1024, options [mss 1460], length 0
20:28:34.106458 IP 172.16.10.10.52902 > 172.16.10.10.www: Flags [S], seq 1888473341, win 4096, options [mss 1460], length 0
## Spoofing Test without "ip verify unicast source" - Source != Destination
## Note: Source IP now matching NULL Route!
===========================
gans@ ubuntu3:~$ sudo nmap -PN -e eth1 -S 172.16.18.10 172.16.10.10 -p 80
Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-21 20:33 CET
gans@ ubuntu2:~$ sudo tcpdump -i eth1 port 80
20:33:10.949497 IP 172.16.18.10.60008 > 172.16.10.10.www: Flags [S], seq 832620857, win 1024, options [mss 1460], length 0
20:33:10.949530 IP 172.16.10.10.www > 172.16.18.10.60008: Flags [R.], seq 0, ack 832620858, win 0, length 0
----> Spoofing reaches the target host as estimated.
## Configuring verify unicast source - Loose Mode:
=======================
R1(config)#int f0/1
R1(config-if)#ip verify unicast source reachable-via any
R1(config-if)#^Z
R1#sh run int f0/1
!
interface FastEthernet0/1
ip address 172.16.20.254 255.255.255.0
ip verify unicast source reachable-via any
## Spoofing Test with "ip verify unicast source" on f0/1 - Source = Destination:
===========================
gans@ ubuntu3:~$ sudo nmap -PN -e eth1 -S 172.16.10.10 172.16.10.10 -p 80
Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-21 20:42 CET
gans@ ubuntu2:~$ sudo tcpdump -i eth1 port 80
20:42:46.214480 IP 172.16.10.10.34679 > 172.16.10.10.www: Flags [S], seq 1762140607, win 3072, options [mss 1460], length 0
20:42:47.213765 IP 172.16.10.10.34680 > 172.16.10.10.www: Flags [S], seq 1762206142, win 3072, options [mss 1460], length 0
----> Traffic hits the target host, because there is a more specific Route that overrules the NULL Route.
## Spoofing Test with "ip verify unicast source" on f0/1 - Source != Destination
## Note: Source IP matching NULL Route!
===========================
gans@ ubuntu3:~$ sudo nmap -PN -e eth1 -S 172.16.18.10 172.16.10.10 -p 80
Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-21 20:43 CET
gans@ ubuntu2:~$ sudo tcpdump -i eth1 port 80
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
---> no matches on target host, uRPF check works on NULL match.
(btw: RFC1918 Addresses had also been filtered by uRPF, results not shown here)
