Security is a part of everyday life and is everyone’s responsibility. As network engineers, it is our job to secure the plumbing that everything else rides on. While some people may consider Cisco devices (routers and switches) to already run a hardened OS, they are still vulnerable to attacks. This post will cover some of the ways you can harden Cisco devices; it is not all-inclusive.

IOS Version

Cisco ships an IOS on every device. That IOS is never current, and if the gear has sat in a warehouse for a little while, it can be really old. For troubleshooting purposes, you should standardize on a IOS version for every platform (6500, 3750, 2960, etc). This standard IOS version needs to be updated on at least an annual basis to correct vulnerabilities in the IOS itself. There are parts of your network that may need to be updated more regularly, or when a specific vulnerability is discovered, such as the Internet Edge or a DMZ. Just make this a part of your standard operating procedure. If your change control process allows it, the newer IOS can be staged on a device (I don’t recommend it on stacking devices) so that if there is a power failure it can automagically upgrade your IOS for you. Also be sure to use the  verify /md5 flash:IOS_IMAGE.BIN and compare the hash with the image you downloaded. You can use a MD5 hash program on your computer to generate the MD5 after you download the file and save it as a text file so you have a permanent record of what the hash should be.

Last time I checked, this was the 21st century, and we do have encrypted protocols to access the CLI. So make sure you are using a ‘k9′ version of IOS so you can use SSH to access your devices.

SSH & VTY access

The legacy protocol to manage devices is telnet. Telnet is not secure as the data in all of the packets is transmitted unencrypted. Using a tool like Wireshark, someone could sniff a telnet session to your device and get your credentials to access it. It does not matter if you are using local, LDAP, or Active Directory authentication, your telnet session can be clearly seen and read.

To enable SSH, you need to configure a few pieces of information. First, you must have a domain name configured. Typically, just use your root DNS domain name that in internal to your organization.

Secondly, you must enable SSH version 2, as version 1 has some security vulnerabilities in it.

Third, you need to generate RSA keys for the SSH process to use.  If you can use a modulus of 2048, do so. If not, then use the highest your IOS supports until you can upgrade.

Example:

So now SSH is enabled. By default, all protocols are allowed on the VTY lines, so we need to restrict the VTY lines. If you are transitioning to SSH, you can use the command transport input telnet ssh; otherwise just use transport input ssh. This will limit the VTY access to telnet/ssh or ssh only respectively.

You should also restrict what IP addresses can SSH to your devices. This should be limited to a management system that backs up configurations or deploys them, a jump host of sorts that you can use when you are out in the field, and the subnet that belongs to the network administrators only. You create a standard access-list (ACL) with these addresses and apply it to the VTY lines. Be sure to include the deny any log at the end of the ACL so that you can log what bogus IPs are attempting to connect to your system.

AAA

If you don’t have a TACACS or RADIUS server, then at a bare minimum create separate accounts for anyone that you will give access to your devices. Yes, that may mean touching every device, but if you give a consultant/contractor your only credentials to your device, then that person will still have them when they leave. Maybe you can trust them now, but you never know what may happen down the road. To create a user account with privilege level 15, use the username <username> privilege 15 secret <password> command. Change the privilege level to 1 for a non-privileged user. Do not use password keyword in place of the secret keyword as that is a level 7 encryption, and easily crackable.

You can setup different privilege levels for different users, such as reduce privileges for a helpdesk user. This post is not going into detail on AAA; that will be another post.

To set an enable password is easy. Use the command enable secret <secret-password>. Again, do not use the password keyword, as it can be easily decrypted.

Now to make this work, you need to enable AAA. A simple configuration that would require a privilege level 1 user to enter the enable password to access the device, but not require it for a privilege level 15 user is:

The AAA configuration can get very complex depending on how you want to set it up, so we will leave the rest for a different post. What I’ve provided is a minimal configuration only.

Banners

There are some that say to not include a banner message on your device, but security folks I talk with say that you need to have one in order to prosecute anyone that may access your systems. The banner message is like a no trespassing sign. It is easy and doesn’t cost anything. My personal philosophy is to not include the name of the organization to give more information or verification to an attacker, but there are some that may disagree. The thought behind the other opinion is that an attacker can use the excuse that they didn’t know it was not their system because it never said it belonged to someone else. The banner message should include that unauthorized access is prohibited and that if you continue, then you accept that all activities may be monitored and/or recorded. With SSH, a username must be received before a banner message can be displayed. Here is the command to enable a banner message.

Logging

Logging is key to troubleshooting normal networking issues, but it is also key to track down who, when, and where an attacker entered the network. When correlating logs from multiple devices, it is critical to have the time synchronized between them. To do this, you use NTP. If you don’t have internal NTP servers, you can use public NTP servers from pool.ntp.org. You will want to have a minimum of three, and preferably four, so that NTP can properly synchronize the time.

You will also need to set the timezone. I have been finding it easier to just set all timezones to GMT/UTC, and I can mentally make the conversion to my timezone. Trying to do conversions from EST to PST to CST can become cumbersome.

Give the buffer a decent size to store logs locally, configure a rate limit on the logs, and then ship the logs off to a logging server. Information level of logging gives you good detail in your syslogs, but it not completely overwhelming like debugs. You should probably also log every login event to the device, success and failures.

One thing to keep in mind about your logging server: be sure that you can do without it. If you do have a breach and it needs to be investigated by law enforcement, they will take the entire logging server.

SNMP

Typically what I see out in the field is SNMP v1/2, so we will see how to secure that. Everyone should move SNMP v3, but details on that will be another post. So, what really needs to poll your network devices for information? Usually a network monitoring system, such as Solarwinds Orion or Cisco Prime. You may also write scripts that poll the network devices for information. If you don’t have these, then simply don’t enable SNMP. If you don’t have a valid need to send SNMP writes, don’t enable it. Do not use the community strings of public/private or anything that maybe related to your company. The community strings are like passwords that protect your network. Treat them as such.

One SNMP command that I have seen enabled and to me cannot be justified is the snmp-server system-shutdown command. What this does is allow someone to send a SNMP set (write) to the device and reboot it. Cisco shows you (bit.ly/S8yLPR) exactly how to do it. With SNMP, sets are sent via UDP. If you have a write string enabled, obscurity of the write community string and the obscurity of your ACL is all that is protecting you from someone rebooting your devices. With knowing your write community string and the IPs allowed by your ACL, someone can easily spoof the source of a SNMP set packet that your ACL allows and reboot your devices at will. Do not enable this command.

If you have a need to do SNMP sets, then create two ACLs; one for Read-Only and one for Read-Write. If you need to send SNMP traps/informs, use a separate community for that as well. Since you are using SNMP for your monitoring system and probably monitoring interfaces, make sure you enabled SNMP ifindex persistence to ensure after reboots that SNMP interface IDs don’t change.

Here is a basic configuration to security SNMP V1/2.

Services

You will not need the TCP and UDP small servers, so make sure that they are disabled. The finger service is something that the network does not need to run, so make sure it is disabled. Also, disable the web server on your network devices. If you don’t use them, don’t give a potential vulnerability an opportunity to be available for someone to exploit.

Enabling TCP keepalives can help reduce the CPU load on your device from hung sessions. It can also mitigate attacks trying to cause hung sessions. You can also reduce the time the control plane waits for a TCP session to establish. The default is 30 seconds. In modern networks, you should not have issues with TCP taking that long to establish, so reducing it helps avoid DoS types of attacks.

Summary

These are some of the basics you can do to harden your Cisco devices. There is more that you can do like securing your routing protocols, AAA with TACACS/RADIUS, SNMPv3, etc. that I will get into more detail later on. I hope this helps and gives you somewhere to start securing your network. As always, if you have something to add, please share it. Don’t keep it to yourself.