Management Plane Protection (MPP) is a security feature for Cisco IOS routers that accomplishes two things:
- Restrict the interfaces where the router permits packets from network management protocols.
- Restrict the network management protocols that the router permits.
The management plane is the logical path of all traffic related to the management of the router. For example:
MPP makes it easier to protect management traffic. You need fewer access-lists because you can restrict most of the network management traffic with MPP. It also prevents network management packet flood attacks since it drops denied packets and does not forward them to the CPU. It’s a good tool to permit/deny most of your network management traffic. You can still use access-lists if you need to permit/deny specific subnets and/or IP addresses.
Let me show you how to configure MPP. This is the topology we’ll use:
H1 is on a trusted network we use to manage R1. H2 is on a remote network that should not be able to manage R1 with any network management protocols.
Want to look for yourself? Here you will find the startup configuration of each device.
hostname H1 ! interface GigabitEthernet2 ip address 192.168.1.1 255.255.255.0 ! end
hostname H2 ! interface GigabitEthernet2 ip address 192.168.2.2 255.255.255.0 ! end
hostname R1 ! interface GigabitEthernet2 ip address 192.168.1.254 255.255.255.0 ! interface GigabitEthernet3 ip address 192.168.2.254 255.255.255.0 ! end
Let’s do a “before” and “after” scenario where you can see the difference between when we use MPP or not.
Let me show you what happens behind the scenes when MPP is disabled. I’ll configure R1 so it only accepts SSH traffic on the VTY lines:
R1(config)#line vty 0 4 R1(config-line)#transport input ssh
To see what is going on, we enable a debug:
R1#debug ip packet IP packet debugging is on
Let’s try to telnet from H2 to R1:
H2#telnet 192.168.2.254 Trying 192.168.2.254 ... % Connection refused by remote host
We see that the connection is refused, this is expected because we don’t accept telnet on the VTY lines of R1. When you look at R1 you see it sends two packets to H2:
R1# IP: tableid=0, s=192.168.2.254 (local), d=192.168.2.2 (GigabitEthernet3), routed via FIB IP: s=192.168.2.254 (local), d=192.168.2.2 (GigabitEthernet3), len 40, sending
R1 responds to H2, refusing the connection. Transmit enough telnet packets from H2 and you can perform a denial of service attack on R1.
Let’s see if we can improve this situation. First, let’s enable telnet on the VTY lines of R1: