Network Foundation Protection (NPF) is a Cisco technology that is implemented in IOS to protect the Cisco network equipment from network-based threats.
To implement NFP, Cisco has broken down the network devices into three planes: the control plane, data plane, and management plane.
The control plane provides the ability to route the packets correctly within your IOS router.
The data plane forwards your packets.
The management plane provides the user with management or administrative access to the IOS device.
The control plane is responsible for ensuring that all packets are routed correctly by the IOS router. The control plane handles all communication to and from the route processor, such as routing protocol updates and ICMP messages.
Control Plane Protection (CPPr) protects the IOS router from any type of attack or problem that would inhibit the ability of the IOS router to route traffic.
Four IOS security features protect the control plane of network devices:
• Receive Access Control Lists (rACL)
• Control Plane Policing (CoPP)
• Control Plane Protection (CPPr)
• Scheduler Allocate
Let’s look at a simple configuration of CPPr.
There are four required steps for configuring CPPr:
STEP 1 Define the trusted hosts with the use of an extended ACL.
STEP 2 Define the class map to match the CPPr ACL.
STEP 3 Define the policy map that applies the policy to the class map.
STEP 4 Apply the policy to the control plane.
The first step in CPPr configuration is to create an extended ACL to define which are the trusted hosts. Trusted hosts do not have the policy applied to them, so the ACL needs to deny the trusted host and allow all others.
The example provided sets 192.168.1.10 and 192.168.1.11 as trusted hosts, and every other host is classed as untrusted:
Router(config)# access-list 110 remark CPPr ACL
Router(config)# access-list 110 deny ip host 192.168.1.10 any
Router(config)# access-list 110 deny ip host 192.168.1.11 any
Router(config)# access-list 110 permit ip any any
We now configure a class map and match the ACL created for matching the untrusted hosts:
Router(config)# class-map match-any CPPr-Map
Router(config-cmap)# match access-group 110
Now that we have created both the access list and class map, the next step is to define the policy map. The policy map ties the class map with the service policy that you apply. In this example, we apply a service policy that polices the control plane for untrusted hosts at a maximum of 100,000 bits per second:
Router(config)# policy-map CPPr-Policy
Router(config-pmap)# class CPPr-Map
Router(config-pmap-c)# police 100000
The final step is to apply the policy map that we have just created to the control plane on the IOS router. To configure this, we have to access the control plane, and then apply the policy map that we created with the service-policy command:
Router(config)# control-plane host
Router(config-cp-host)# service-policy input CPPr-Policy
The data plane is the plane that handles most of the traffic that flows through the router. This is where the packets that traverse the router are handled.
You can prevent attacks both to the router itself and to devices that the router serves traffic for by enabling data plane protection. The data plane is protected using Flexible Pattern Matching (FPM).
FPM uses a series of Protocol Header Definition Files (PHDF) that are provided by Cisco. These files contain the patterns, or signatures, that most command attacks use so that they can be matched by FPM. The PHDF is delivered as an XML file and can be created by the end user to match specific traffic.
We are going to look at a sample implementation of FPM. The example we use looks for the match against MyDoom packets.
MyDoom can be identified by matching one of the following criteria:
• 90 > IP length > 44
Pattern 0x47455420 at 40 bytes from start of IP header
• IP length > 44
Pattern 0x6d3a3830 at 48 bytes from start of IP header
Pattern 0x47455420 at 40 bytes from start of IP header
Four steps are required to configure data plane protection using FPM: Load the required PHDFs
STEP 1 Load the required PHDFs.
STEP 2 Define the class map to match the required traffic.
STEP 3 Define the policy map that applies the policy to the class map.
STEP 4 Apply the policy to the required interface.
The first step is to load the required PHDFs. For this example, you are going to need the ip.phdf and the tcp/phdf files:
Router(config)# load protocol flash:ip.phdf
Router(config)# load protocol flash:tcp.phdf
Now that the PHDFs are loaded, we need to define a class map that will match the required traffic that identifies MyDoom.
Because there are two ways of detecting MyDoom, we will create two class maps. We initially create a stack class map to let FPM know which headers are present and in which order:
Router(config)# class-map type stack match-all ip-tcp
Router(config-cmap)# match field ip protocol eq 0x6 next tcp
The first class map, mydoom1, looks for the IP length of greater than 44 and less than 90:
Router(config)# class-map type access-control match-all mydoom1
Router(config-cmap)# match field ip length gt 44
Router(config-cmap)# match field ip length lt 90
Router(config-cmap)# match start l3-start offset 40 size 4 eq 0x47455420
The second class map, mydoom2, looks for the IP length of greater than 44:
Router(config)# class-map type access-control match-all mydoom2
Router(config-cmap)# match field ip length gt 44
Router(config-cmap)# match start l3-start offset 40 size 4 eq 0x47455420
Router(config-cmap)# match start l3-start offset 78 size 4 eq 0x6d3a3830
Now the class map has been defined and the traffic that needs to be matched defined, the next step is to link this to a policy map.
We initially link the mydoom1 and mydoom2 class maps to the fpm-tcp-policy policy map:
Router(config)# policy-map type access-control fpm-tcp-policy
Router(config-pmap)# class mydoom1
Router(config-pmap-c)# drop
Router(config-pmap-c)# class mydoom2
Router(config-pmap-c)# drop
We then define the fpm-policy policy map that is linked to the ip-tcp class map:
Router(config)# policy-map type access-control fpm-policy
Router(config-pmap)# class ip-tcp
Router(config-pmap-c)# service-policy fpm-tcp-policy
Step 4: Apply the Policy to the Required Interface
The last step is to apply the fpm-policy to the required interface:
Router(config)# interface FastEthernet 0/1
Router(config-if)# service-policy type access-control input fpm-policy
The management plane is concerned with securing management access to the Cisco IOS device. It is normal to manage a Cisco IOS device using protocols such as Telnet, SSH, SNMP, HTTP, or HTTPS.
Cisco IOS Management Plane Protection (MPP) provides the capability to restrict the interfaces on which network management packets are allowed to enter a Cisco IOS device. If you lose access to the management plane on a Cisco IOS device, you lose the ability to control the device.
Protecting the management plane can be done in a number of ways. The most common and historic way to control the management plane is by limiting who can gain administrative access to the device through the use of access lists and an access class applied to the vty interfaces. You can also specify which administrative protocols should be used with the transport-input command on the vty interfaces, and you can enable or disable the HTTP server on the device.
Cisco has implemented the management-interface command as part of the NPF.
To enable MPP using the NFP, enter the following commands:
Router(config)# control-plane host
Router(config-cp-host)# management-interface FastEthernet 0 allow ssh
The first command puts the router into control plane configuration mode. The second command is the command that allows access only to the management plane via SSH on the FastEthernet 0 interface. This enforces MPP.
In this final section, we covered Cisco NPF. The network foundation is made up of three planes: the control plane, data plane, and management plane.
We covered the ways that Cisco offers protection for each of these planes through configuring the required IOS services.
You can find further information about the NFP from the Cisco website at http://www.cisco.com/en/US/netsol/ns696/
networking_solutions_solution.html.
13.58.149.129