Securing Physical Access to the Catalyst Switch

Securing Physical Access to the Catalyst Switch

Similar to troubleshooting, our first layer of defense for securing the switched network should start at the Physical layer. Specifically, we need to secure access to the physical switch itself and the cables that are connected to it. It doesn’t take a skilled attacker to physically destroy a switched network to which he or she has complete access.

With that being said, the first and probably most critical step of securing your network is to ensure that the switches themselves are secured in a cool room in which only you or those authorized have access. If users have physical access to the switches, they can easily console into the switch and perform a password-recovery exercise (easily found on the Internet) just by repowering the switch and holding down a button during power-up. Even unintentional attacks such as custodial staff unplugging your switches to run the vacuum can occur easily if not secured correctly. If you can, also make sure that the Ethernet cabling between the switches and end devices is not in plain sight and therefore can’t be easily damaged. You don’t want the last act by a fired employee to be taking down your entire network by ripping out your existing wiring.

Physically securing Cisco devices is an integral step in implementing a secure Cisco network.

Securing Terminal Access to the Catalyst Switch

After we have ensured that the switch is physically secured, the next layer of defense to implement is securing terminal access to the switch so that attackers cannot perform reconnaissance or manipulate configurations. Because there are several ways to gain access to the Cisco IOS, due diligence is required to ensure that all terminal connections are secured.

To start, the first logical terminal access to secure is the console and auxiliary port. Many might ask why, because we already physically secured the switch. To answer a question with a question, would you have an account at a bank that leaves your money out on a table because they have an alert security guard standing at the door? A layered defensive approach entails having security measures at each step of the way so that attackers will have many obstacles in their way in achieving their objective.

To secure access to the console and aux port, the simplest defense you can use is securing them with a password. Just as in router configurations, this is achieved in the line configuration using the password command. It is also a good idea to make sure that your passwords are strong passwords containing at least eight characters and that they have a combination of numbers, symbols, and lower and uppercase letters:

What’s more, you can create a local username and password combination that is stored in the configuration. This username and password will be required to be entered when someone attaches to the console and gets an EXEC prompt. The only difference in the configuration is that you no longer need to specify a password in the line configuration, because you achieved
that in defining the username and password combination, and you also must use the keyword local in the login command. This keyword tells the IOS to use the local username and password combination that can be found in the configuration:

If you configure the console and aux login to use the username and password using the login local command and a password configuration is present on the line as well, the IOS uses the username and password over the password line configuration.

You can use a special username and password command that encrypts the password similarly to the enable secret command. Conveniently enough, the command is username username secret password. This applies an MD5 hash of the password so that it cannot be easily acquired if the configuration is accessed.

To Telnet or Not to Telnet

Recall that although Telnet is a convenient way to gain EXEC access to the Cisco device, it also is extremely dangerous, because everything that is sent using Telnet is in clear text and can be intercepted by anyone eavesdropping on the session. With that being said, whenever possible, use SSH for remote terminal connectivity to the Cisco device. Recall that the configuration for enabling SSH on a Cisco device is as follows:

  1. Change the default hostname of the Cisco device.
  2. Configure a domain name with the ip domain-name command.
  3. Generate the RSA key with at least a 1024-bit key with the crypto key generate rsa command.
  4. Create a username and password.

A recommended third step in this process, however, is to limit the vty lines on the Cisco device to accept only SSH as an input protocol. In other words, this step entails disallowing Telnet into the vty lines. The command to limit the terminal input on the vty lines is transport input SSH on the vty line configuration:

When you exclude the keyword telnet in the transport input command, only SSH is allowed as a terminal input protocol on all the vty lines.

To specify SSH as the only secure terminal input, use the transport input SSH command.

Whether you are using SSH or are only left with using Telnet, make sure you have properly secured user EXEC access through the vty lines using the same methods as the aux and console. Specifically, configure a password on the vty lines or use the login local command to prompt for a username and password.

As a final defensive measure on these vty lines, you can also specify an IP or IP subnet that is permitted to gain access to these vty lines. If the source IP address of the Telnet or SSH session is not from the permitted IP(s), the session will not be allowed to connect. This command is the access-class command; it is discussed in detail in Chapter 19, “Using Cisco Access Lists.”

Additional IOS Security Practices

In addition to securing access to Cisco IOS, it is also a good idea to secure the contents of the configuration using some practical and simple configuration steps that we have discussed. This list is not exhaustive by any means, but it is a good beginning point:

  • Encrypt your enable password to privileged EXEC using the enable secret command.
  • Encrypt all other clear-text passwords in the configuration using service passwordencryption.
  • Create a login banner that warns against unauthorized access attempts to the EXEC prompt.
  • Disable EXEC access on unused terminal access ports (such as aux ports) using the no exec command in the line configuration.
  • Limit how long the terminal session stays idle to not exceed one minute with the exec-timeout command (exec-timeout 1 0).

Now that you have a basic checklist of security dos and don’ts for physical security and connectivity to a switch, it is time to evaluate your existing switched network and consider if your switches are secured. If you do not have a switch network, imagine that you just received a switch, and think about what you should do to secure it. Then check yourself with the following questions:

  1. Are the switch and its cables physically secured?
  2. Are the console and auxiliary port secured?
  3. If your switch has a supported IOS, are you running SSH for remote management?
  4. If you do not have SSH, have you fully secured your vty lines for Telnet?
  5. Are all passwords encrypted?

About the author


Leave a Comment