In the previous articles, we have discussed and implemented some Cisco firewall technologies. In this article, we will be focusing on the Cisco IOS devices (routers and switches) and the security measures that should be applied to the different planes of such devices. This article will be more explanatory than hands-on but there will still be some practice.

CCNA Training – Resources (Intense)

Introduction to the Cisco IOS device’s planes

Cisco IOS devices can be viewed as consisting of three basic parts or planes:

  • Management Plane: This part deals with the configuration and management of the device itself. It is the part of the device to which the network administrator connects to. This plane consists of traffic that is sent to the device itself including protocols such as SSH and SNMP. In simple terms, when you are configuring a router through the CLI or through a GUI (such as the Cisco Configuration Professional tool), you are interfacing with the management plane of that device.
  • Control Plane: The control plane ensures that the network device can maintain the functionality of the network. It contains protocols that enable communication on the network. The protocols that operate in this plane include routing protocols like EIGRP, OSPF, BGP and other protocols such as ICMP.
  • Data Plane: This is the plane we are most likely familiar with because it deals with transit traffic. If Host A on a network sends a packet to Host B and the packet has to travel through the Cisco IOS device, the plane that handles this transit data is the data plane.

Securing the Management, Control and Data Plane

When it comes to the security of the device itself, the least important plane is the data plane, but usually, this is the plane most concentrated on. Imagine putting all the ACLs and firewalls on a network (which are data plane security measures as we will discuss soon) and then allowing the router to be managed via Telnet. That’s like building a castle on sand.

Securing the Data Plane

In this section, we will begin with the data plane because many of us are already familiar with the security measures applied in this plane. As we have said, the data plane deals with traffic that flows through your network device. Think about it for a minute: what kind of protection do you want at this plane? For one, we don’t want certain types of traffic to flow through our device to the hosts on the other side. This unwanted traffic may include viruses or ‘illegal’ connections. One such illegal connection is a user on the web being able to connect directly to an internal host. The security measures against this include IOS Intrusion Prevention System (IPS), Cisco IOS Zone-based Policy Firewall (ZFW) and Access control lists (ACLs).

What other security attacks can we think about? Denial of Service (DoS) is one of them. A DoS attack is a resource starvation attack that occurs when a server (or any computing device) cannot handle the amount of resource requests it gets and consequently fails (crashes). This kind of attack has been successful against famous websites like Facebook and Twitter. SYN attack is a type of DoS attack. Remember the three-way handshake of the TCP connections?

A SYN attack is basically the target host (the server in this case) getting a flood of SYN packets and trying to respond with SYN+ACK packets but never receiving the last ACK packet back. This type of connection is known as half-open connection because it is not fully established. Since the server dedicates resources waiting for this connection to become established, it can become overwhelmed if there are many such connections made to it. This is how a SYN attack works. We can use the TCP Intercept feature on Cisco IOS devices to protect against this.

TCP Intercept works by ‘intercepting’ the TCP connection and responding to the initiating device (HOST in our example) on behalf of the target host (SERVER in our example) and only sending it to the target host once the connection is fully established. The IOS device can handle this because it can better detect and respond to an attack than the target device.

Other security measures on this plane include Dynamic ARP Inspection, Unicast Reverse Path Forwarding and Port security.

Securing the Control Plane

Protecting the control plane is essentially about protecting the engine of the Cisco IOS device – the CPU. If the CPU is overwhelmed, all the other planes will be affected because packets will not be processed effectively. Also, if the router is fed with bad information, then the network can be made unstable, for example, by routing all transit traffic to a rogue device.

Control Plane Policing (CoPP) allows the administrator to control the ‘amount’ of traffic that is destined to the router itself. For example, you can specify that management traffic such as SSH and HTTPS from non-administrative hosts be dropped completely.

Another control plane security measure is Control Plane Protection (CPPr) which is similar to CoPP but allows for finer details and more granularity. It can be used to restrict traffic that is destined to the CPU of the IOS device.

The last security measure we will discuss in this section is Routing Protocol Authentication. Like we said earlier, you don’t want your router receiving false updates and then routing traffic to a rogue device. You can therefore specify passwords for routing protocols between trusted hosts on your network. This way, your network devices will not form adjacencies with untrusted devices. Let’s see how this works with an example.

This is the relevant portion of the configuration for Good-Rtr1:

Below is the relevant portion of configuration for Good-Rtr2:

Finally, below is the configuration for Rogue-Rtr:

Notice that there is MD5 authentication configured between Good-Rtr1 and Good-Rtr2 but not on Rogue-Rtr. To see the effects of this, we will check the OSPF neighbour tables of the good routers and also confirm that there is no “” network in their routing table since that route belongs to the rogue router.

As you can see from the above, the good routers have not formed adjacencies with the rogue router because of routing protocol authentication.

Securing the Management Plane

The management plane needs to be secured because it gives access to the configuration of the IOS device. Unauthorised access to this plane can be devastating. One important thing to consider when connecting to the IOS device is the use of secure channels like SSH and HTTPS, which uses Secure Sockets Layer (SSL) and Transport Layer Security (TLS) for authentication and date encryption, rather than clear-text protocols Telnet and HTTP. Even when these secure protocols are used, the users that can manage the IOS device should be restricted to trusted users, e.g. using ACLs to permit certain IP addresses.

AAA (Authentication, Authorisation, and Accounting) should also be enabled rather than allowing every user to connect using the same password. With AAA configured, users can be assigned username and password combinations (authentication) and can also be restricted in their activities (authorisation). The activities of the user may then be logged (accounting) for review.

Other security measures include Role-based access control (RBAC), using a secure version of SNMP (version 3), authenticated Network Time Protocol (NTP) and Syslog for logging and reporting capabilities. We will look at NTP and Syslog in a bit more detail.

Network Time Protocol (NTP)

NTP can be used to sync the clock of an IOS device with a central (and possibly trusted) clock. This offers numerous benefits, the major two being accurate timestamps on logs and proper validation of digital certificates. Digital certificates have issue dates and expiry dates; if the IOS device’s clock is out of sync, it may reject a valid certificate or accept an invalid one. Just like routing protocols that we saw earlier, NTP can also be authenticated.

We will use the simple diagram above. Before we begin configuring, let’s check the time on the routers.

Now, we will set the NTP Server’s date to May 22, 2013 and time to 12:00:00.

*It’s funny how the clock is set in the EXEC mode and not the configure mode.

Now, we will configure authenticated NTP between Good-Rtr1 and Good-Rtr2 using a key of ‘cisco’.

Now let’s check the clock of the NTP Client.

Aha! Now it has synced up with the server. We can also check NTP synchronisation and association using the following commands: show ntp associations and show ntp status.

On a side note, NTP can sometimes have a very weird behaviour. If after you configure it and it doesn’t come up immediately, give it some time as long as you are sure your configuration is right (and there are no ACLs blocking such traffic).


Logging is very important because it can tell you what happened on a network. Although it is a reactive measure rather than a proactive one, it is very useful for audit purposes and alerting. There are eight logging levels (0-7) on Cisco IOS devices. Remember that there are 8 and not 7 because thinking about 0-7 can make you jump into a false conclusion.

Figure: Logging severity levels. Photo courtesy:

Log messages can be sent to various places including the device console, terminal line (via remote connection using Telnet or SSH), the device buffer, Syslog server and so on. Keep in mind that if you enable logging for a particular level, all levels higher than it are also logged. For example, if you enable logging for level 5, level 0-4 messages are also logged. Usually during troubleshooting, you want to see all logs (from 0-7) but these messages may overwhelm the router and so it is not advised to log to the console especially on a live network.

  • Console logging: Use the command logging console<severity level>. Keep in mind that the log messages will be shown on the console window. If it is too much, it will flood the screen and you may not be able to type any command to stop it, effectively causing a DoS attack for yourself (speaking from experience *covers face*).
  • Terminal logging: Use the command logging monitor<severity level>. Beware of the same challenge as console logging.
  • Buffered logging: Logging to the IOS buffer allows you to store the log messages temporarily in a buffer so you can view at a later time. You can specify the size of the buffer (logging buffered<size>) and use the show logging command to view the logs.
  • Syslog: This allows log messages to be sent to a Syslog server. You do this by specifying the server’s IP address (logging host<ip-addr>) and the severity level of the log messages (logging trap<severity level>). Syslog protocol uses UDP port 514 and it sends messages in clear-text. For security purposes, Syslog traffic should be encrypted (by using IPsec for example) or it should be on an out-of-band management area of the network.

We will see all these logging options in the diagrams that follow below. First let’s configure console logging. I will generate a log by bringing up an interface.

Now let us see Terminal logging. I will telnet to the router and shutdown an interface and see what happens.

Nothing. Well, something happened alright, but we don’t see it because by default, logging is not configured for terminal lines. There are two things you need to do to configure it: specify the severity level using the logging monitor command and then configure the IOS device to show the logs on the terminal using the terminal monitor command.

The terminal monitor command is another funny command because to disable it, you specify terminal no monitor rather than the no terminal monitor that you may think.

Let’s move on to buffered logging.

I will shut down an interface again. You issue the show logging command to view the logs.

Finally, we can configure Syslog. I have a Syslog server (3CDaemon) located on

So I will configure the router to send logs to this server and then bring up an interface.

Notice that it gives the severity level of the log messages (informational, notice and error).


There you have it: securing the management plane, control plane, and data plane. Protection in the management plane includes using SSH and HTTPS, authenticated NTP and logging. Security measures for the control plane include Control Plane Policing, Control Plane Protection and Routing protocol authentication. Finally, the data plane can be secured using port security, DAI, and ACLs.

In the next article, we will discuss and implement AAA on network devices. Till then, I hope you have found this article insightful and I wish you success in your studies.

Reference and Further Reading