cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
1373
Views
4
Helpful
4
Replies
hgans
Beginner

ip verify unicast source NULL and more specific routes...

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!

4 REPLIES 4
rparames
Cisco Employee

Hello Hgns,

You can configure "ip verify unicast source reachable-via rx" instead. This is different from "ip verify unicast source reachable-via any" as you would have to receive the packet from the exact RPF interface and not just match any route in the Routing Table.

So if you receive a packet from internet, it will fail the STRICT RPF check and get dropped.

HTH,

Rahul

Mahesh Gohil
Rising star

Hi,

Please make sure you are not multihomed or there is no asymmetric routing before configuring strict mode

as it could block legitimate traffic too.

Have you thought of blocking by access-list along with RPF..like you can include 1.2.0.0/16 ip as an access-list

Router(config-if)#ip verify unicast source reachable-via any ?
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number
  allow-default    Allow default route to match when checking source address
  allow-self-ping  Allow router to ping itself (opens vulnerability in verification)

Regards

Mahesh

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)

Hi,

Thanks for reply.

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?


Why I suggested acl with uRPF is because I am facing similar issue in my network and everytime I see different source ip. Earlier I configured simple

ACl to block source IP but again it changes and Now the worst case is I see 0.0.0.0 as a source IP. Unfortunately I can not go for RPF as it is yet

not validated by my engg. team.

This is kind of task where you need to closely monitor what ia happening with your network and accordingly decide what is best suitable for your

network.

I will definately let you know once I receive recommendation from engg. team

Regards

Mahesh