Anti-Spoofing Measures in Cisco Routers

julito4589 · ‎12-22-2014

I'm trying to implement anti-spoofing with access rules on two routers that are connected to each other.
Here's some info on the environment. I have a Cisco 3900 at the edge of the network (internet facing) that connects to two upstream providers. These are the interfaces for that device (IP addresses changed for privacy):
C3900# sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.10.30.1      YES NVRAM up                    up
GigabitEthernet0/1         XX.XX.XX.XX     YES NVRAM up                    up
GigabitEthernet0/2         YY.YY.YY.YY     YES NVRAM up                    up
NVI0                       10.0.30.1      YES unset up

I also have a Cisco 3825 router that connects on GigabitEthernet0/0 to the 3900 mentioned above. And these are the interfaces for that device (IP addresses changed for privacy):

C3825#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.10.30.2      YES NVRAM up                    up
GigabitEthernet0/1         unassigned      YES NVRAM up                    up
GigabitEthernet0/1.1       10.0.10.40       YES NVRAM up                    up
GigabitEthernet0/1.6       192.168.125.1    YES NVRAM up                    up
GigabitEthernet0/1.7       192.168.135.1   YES NVRAM up                    up
GigabitEthernet0/1.8       192.168.145.1   YES NVRAM up                    up
GigabitEthernet0/1.9       192.168.155.1   YES NVRAM up                    up
NVI0                       10.10.30.2      YES unset up                    up
Virtual-Access1            10.10.30.2      YES unset up                    up
Virtual-Access2            10.10.30.2      YES unset up                    up
Virtual-Access3            10.10.30.2      YES unset up                    up
Virtual-Access4            10.10.30.2      YES unset up                    up
Virtual-Access5            10.10.30.2      YES unset up                    up
Vlan1                      unassigned      YES unset up                    up
Vlan3                      192.168.65.1    YES NVRAM up                    up
Vlan4                      192.168.95.1    YES NVRAM up                    up
Vlan5                      192.168.75.1    YES NVRAM up                    up

I'm planning to set up egress ACLs. So for example, these would be the commands for int g0/0 in the 3900 router:

conf t
access-list 180 permit ip 10.10.30.1 0.0.0.255 any
access-list 180 deny ip any any log
int g0/0
ip acess-group 180 out
end

I'll use a similar set of commands on these interfaces in the 3800 router, but for the respective subnet:
GigabitEthernet0/1.1       10.0.10.40
GigabitEthernet0/1.6       192.168.125.1
GigabitEthernet0/1.7       192.168.135.1
GigabitEthernet0/1.8       192.168.145.1
GigabitEthernet0/1.9       192.168.155.1

QUESTIONS:
1. I'm not sure though whether I have to create egress rules in GigabitEthernet0/0 in the 3800. That's the interface that uplinks to the 3900. If it recommended to have egress rules, how would the permit rule(s) look like for this interface?

2. I'm also not sure if Virtual-Access1 - 5 interfaces and Vlan1 - 5 interfaces have to have egress rules as well

3. Finally, should I configure egress rules on the upstream providers interfaces in the 3900
GigabitEthernet0/1 XX.XX.XX.XX
GigabitEthernet0/2 YY.YY.YY.YY

I would appreciate any input on these questions and on additional configurations that I need to consider to effectively implement anti-spoofing measures in these routers.

vamikhai · ‎12-23-2014

Hello.

For anti-spoofing (from your local networks) I would suggest to use uRPF (on your end-host subnets).

If both routers are managed by single authority, there is no need to implement anti-spoofing toward each other.

If you configure ACL 180 as mentioned, the transit traffic via 3900 over G0/0 would be blocked (I doubt if it's desired behaviour).

Also you need anti-spoofing ACL on inbound for public interfaces (3900 G0/1 and G0/2).

julito4589 · ‎12-23-2014

Thanks for your answer. Just to make sure I understand your recommendations...

All the subnets ultimately end on the 3825, so based on your suggestion, I would have to implement uRPF on that device in all the internal interfaces
GigabitEthernet0/1.1       10.0.10.40       YES NVRAM up                    up
GigabitEthernet0/1.6       192.168.125.1    YES NVRAM up                    up
GigabitEthernet0/1.7       192.168.135.1   YES NVRAM up                    up
GigabitEthernet0/1.8       192.168.145.1   YES NVRAM up                    up
GigabitEthernet0/1.9       192.168.155.1   YES NVRAM up                    up

Vlan3                      192.168.65.1    YES NVRAM up                    up
Vlan4                      192.168.95.1    YES NVRAM up                    up
Vlan5                      192.168.75.1    YES NVRAM up                    up

But I'm still not clear on what uRPF, if any, should be implemented on the 3925. This is the internet facing router, so wouldn't I have to implement uRPF on the inside interface? You do suggest creating anti-spoofing ACLs on inbound for the public interfaces. Are you referring to something like what's described here:

http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html

In other words, ACLs that address:

"Special-use address and anti-spoofing entries that deny illegitimate sources and packets with source addresses that belong within your AS from entering the AS from an external source

Explicitly permitted externally sourced traffic destined to infrastructure addresses

deny statements for all other externally sourced traffic to infrastructure addresses

permit statements for all other traffic for normal backbone traffic en route to noninfrastructure destinations"

Vasilii Mikhailovskii · ‎12-23-2014

Hello.

Yes, you need uRPF on all end-user facing interfaces (3825).

No need to run uRPF of 3925 toward 3825, as you are supposed to trust 3825 (you are managing it and anti-spoofing is already there).

Yes, the link you provided is good, you need external-interface inbound ACL to deny packets like:

access-list 110 deny ip host 0.0.0.0 any
access-list 110 deny ip 127.0.0.0 0.255.255.255 any
access-list 110 deny ip 192.0.2.0 0.0.0.255 any
access-list 110 deny ip 224.0.0.0 31.255.255.255 any
access-list 110 deny ip 10.0.0.0 0.255.255.255 any
access-list 110 deny ip 172.16.0.0 0.15.255.255 any
access-list 110 deny ip 192.168.0.0 0.0.255.255 any
access-list 110 permit ip any host <my public IP>

PS: I would also deny inbound multicast destination (224.0.0.0/4) if you don't need it.