There are vulnerabilities in the design, the design of applications, the design of systems. There are weaknesses that are inherent in protocols, for example IEEE protocols, open standard protocols. They have those weaknesses because they’re there for interoperability and functionality. So they’re just there, okay. There are also software vulnerabilities. Some of those are by design, some of those are obviously accidental, then the human error and misconfiguration, okay, that’s a biggie.<\/p>\n
What are our threats?<\/p>\n
- \n
- Trust exploitation attacks<\/li>\n
- Login, authentication, and password attacks<\/li>\n
- Routing protocol exploits<\/li>\n
- Spoofing<\/li>\n
- Denial-of-service attacks<\/li>\n
- Confidentiality and integrity attacks<\/li>\n<\/ul>\n
Well, we’ve got trust exploitation, taking advantage of relationships between systems, and servers, and clients, and servers, for example. You got threats against login, access control, authentication; password attacks \u2013 different types of methods for extracting keywords, and passwords, and strings; exploiting routing protocols when there is no authentication in place; spoofing \u2013 spoofing IP addresses, spoofing MAC addresses. There are denial-of-service attacks and distributed DOS attacks. There are also attacks against confidentiality to break down cryptosystems, and integrity attacks take advantage of weak hashing mechanisms.<\/p>\n
What is the impact?<\/p>\n
- \n
- Exposed management credentials<\/li>\n
- High route processor CPU utilization (near 100 percent)<\/li>\n
- Loss of protocol keepalives and routing protocol updates<\/li>\n
- Route flaps and major network transitions<\/li>\n
- Slow or unresponsive management sessions<\/li>\n
- Indiscriminate packet drops<\/li>\n<\/ul>\n
Well, exposing credentials, using up CPU cycles, corrupting your routing table, flapping network transitions and disruptions, slow sessions, indiscriminate packet drops \u2013 just to name a few.<\/p>\n
We can see from the following diagram that this is a problem that’s going to be affecting our entire network infrastructure. Starting at the top with our edge customer, edge router that connects to our service provider to the Internet.<\/p>\n
![\"Network-wide](\"\/wp-content\/themes\/learncisco\/assets\/images\/iins\/020-network-security-problems.jpg\" "\\"Network-wide")
<\/p>\nWe have IP spoofing, we have denial-of-service attacks, we have routing protocol exploits, for example, if we’re using BGP to our provider. There are also password attacks to try to get through authentication mechanisms and authentication proxies on that perimeter router, or if we’re using authentication in our service provider. If you go down clockwise to the Wide Area Network, same thing there. Routing protocol exploits with our WAN protocols like OSPF, EIGRP, for example; trust exploitation between the peers in the routing protocols and other services, in the Campus Core or we would call our corporate LAN. You’ve got denial-of-service attacks, trust exploitation. Then of course, you’ve got spoofing of MAC addresses, and ARP spoofing, and exploitation of DHCP that can happen not only at the core, but more likely at the Access and Distribution layers of our network in the server farm or datacenter.<\/p>\n
Cisco NFP framework<\/h2>\n
Now in order to implement Network Foundation Protection, you have to understand that your router is typically divided into three functional planes, and actually these aren’t the only planes. There is actually a service plane, but we’re not going to talk about that here in this course. We have the data plane, we have the management plane, we have the control plane.<\/p>\n
![\"Device](\"\/wp-content\/themes\/learncisco\/assets\/images\/iins\/021-router-functional-planes.jpg\" "\\"Device")
<\/p>\nNow, the data plane could be considered transit traffic or customer traffic, and of course, the customer could be a service provider’s customer, or in our organization, the customer are own endusers, our business units, our departments, our buildings on our campus. So the data plane is basically the traffic that is moving through our router \u2013 transit traffic that’s being forwarded from one interface to another, and it’s typically 80% or more of our traffic. So we have a route processor there that’s managing certain packets.<\/p>\n
The management plane is separate from a functional perspective. This is basically traffic that is directed towards the router. So it’s towards an interface or an IP address on an interface for the purposes of management, okay \u2013 either packet-based management or character-based management of that device.<\/p>\n
The control plane is basically what controls all the other planes, okay. The control plane is dealing with the actual process of routing traffic through the device. So it could be used by the dynamic routing protocols, for example. Control plane packets would be ARP, BGP, OSPF, EIGRP packets. These are network device-generated or received packets that are for the generation and operation of the network itself. So that’s what we’re talking about with control plane.<\/p>\n
The management plane is going to have a lot of protocols like Telnet, Secure Shell, TFTP, SNMP, FTP, NTP. All those protocols are on the management plane. Typically, control plane packets and management plane packets are destined to the router itself on its receive interface to its processor.<\/p>\n
We need a well organized, structured approach to protecting the operational planes of our router, and these three functions will benefit if you have a combined effort. You can’t really protect the control plane, and the data plane, and the management plane all by themselves individually. We need a structured approach to protect all three functions. As we know, the control plane will affect our routing of our packets, it implements routing protocol functionality. The management plane affects the ability to configure and monitor and control our device and eventually implement our security control to the management plane. Then the data plane affects the ability to forward traffic, which is a huge percentage of the duties of our router. So by overloading the control plane, you can slow down the routing process, and therefore, you could degrade the other service levels and overall corporate productivity. So packets that traverse the control plane that are destined for the CPU with a router need to be protected, because all packets entering the control plane are actually redirected by the forwarding plane. So you can see they all kind of work together.<\/p>\n
Here we can see kind of a simplified explanation of these concepts where the Cisco Network Foundation Protection is going to secure the control plane, which is our ability to route. The management plane, which is the ability to manage, and the data plane, which is the ability to forward, and it’s a secure foundation to protect our device.<\/p>\n
![\"Cisco](\"\/wp-content\/themes\/learncisco\/assets\/images\/iins\/022-cisco-nfp.jpg\" "\\"Cisco")
<\/p>\nIt’s a series of IOS features, which specifically protect the control plane by locking down services and routing protocols, the device data plane for malicious traffic as well as protecting the device management plane.<\/p>\n
Cisco NFP toolkit<\/h2>\n
This table shows us the Network Foundation Protection Toolkit. There are other features and tools that are available but these are the main ones, and we’re going to be discussing most of these and of course, we’ll expand on these as you get into the CCNP security track.<\/p>\n
\n\n
\n Plane<\/th>\n Feature<\/th>\n Benefit<\/th>\n<\/tr>\n \n Control Plane<\/strong><\/td>\n Control Plane Policing (CoPP)<\/td>\n Filter or rate limit control plane traffic with no regard to physical interface<\/td>\n<\/tr>\n \n Control Plane Protection (CPP)<\/td>\n Extend CoPP with granular traffic classification<\/td>\n<\/tr>\n \n Routing protocol authentication<\/td>\n Integrity of routing and forwarding<\/td>\n<\/tr>\n \n Cisco AutoSecure<\/td>\n Automate device hardening<\/td>\n<\/tr>\n \n Management Plane<\/strong><\/td>\n Authentication, authorization and accounting (AAA)<\/td>\n A comprehansive framework for role-based access control<\/td>\n<\/tr>\n \n NTP, Syslog, SNMP, SSH, TLS<\/td>\n Secure management and reporting<\/td>\n<\/tr>\n \n CLI views<\/td>\n Obtain the benefits of RBAC for command line access<\/td>\n<\/tr>\n \n Data Plane<\/strong><\/td>\n Access control lists<\/td>\n Traffic filtering consistent across security device platforms<\/td>\n<\/tr>\n \n Layer 2 controls (private VLANs, STP guards)<\/td>\n Protect the switching infrastructure<\/td>\n<\/tr>\n \n Zone-based firewall, IOS IPS<\/td>\n Deployment flexibility in IOS form factor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n But at the control plane, we have the Control Plane Policing which is an older feature. We have a newer CPP \u2013 Control Plane Protection which extends CoPP with granular traffic classification. You have Routing Protocol Authentication to guarantee the integrity of routing and forwarding, and you also have the Cisco AutoSecure to protect and harden the control plane. At the management plane, we have AAA services \u2013 authentication, authorization, and accounting. We also have a NTP, Syslog, SNMP, Secure Shell, and TLS, and also role-based CLI or views giving you the benefits of a role-based access control for management. At the data plane, we have of course the access control list \u2013 the classic mechanism. We also have Layer 2 controls \u2013 PV LANs or private VLANs, Spanning Tree Protocol Guards, and others) and then zone-based policy firewall and IOS IPS. These are all features on the integrated services router.<\/span><\/p>\n
Cisco NFP in action<\/h2>\n
If we go back to that topology from earlier, we can look at some of our methodology for applying NFP. For all of our different modules or different zones, we’ll be using role-based access control, and secure management, and reporting.<\/p>\n
![\"Cisco](\"\/wp-content\/themes\/learncisco\/assets\/images\/iins\/023-cisco-nfp-in-action.jpg\" "\\"Cisco")
<\/p>\nMoving around clockwise, at the Internet layer or the customer edge router, we’ll have antispoofing mechanisms, CoPP, IOS IPS, and ACL filtering access control lists. For the WAN, we can use zone-based policy firewalls and authentication of routing protocols. At the Campus Core, we have a lot less policy there but we can still have CoPP and rate limiting on those high speed multilayer switches. At the access distribution network and server farm or datacenter, we can have Layer 2 controls and ACL filtering.<\/p>\n
What Cisco NFP does not consider<\/h2>\n