This article details some of the trivial but necessary configuration best practices for Cisco IOS-based layer 2 switches. Many security administrators don’t think of security when it comes to Layer 2 of the network infrastructure (where switches operate), and it’s one of the most overlooked aspects of network security and reliability. In this article, I’ll show you how to fix the most common mistakes in switch configuration and architecture.
NOTE: This article does not cover spanning-tree and VTP security but I already have written other separate articles about them. Click Here to find out more about securing spanning-tree and Click here to find out more about VTP’s best practices and security.
Disable IP domain-lookup
By default, when a command in user or enable mode is entered into the switch, and the command is not recognized, the switch thinks that the invalid command is the name of a device that the user is attempting to reach.
SW1# end Translating "end"...domain server (255.255.255.255) (255.255.255.255) Translating "end"...domain server (255.255.255.255)
As such, this switch attempts to resolve this if it cannot find a lookup on the switch itself. It will send out a broadcast. This can take several seconds for the switch prompt to return, while it waits for a response from hopefully a DNS server. And this can be very frustrating, especially when you’re trying to configure, learn the configuration commands from the start, and or if you’re not very good at typing. You can disable this by issuing the following command.
SW1(config)# no ip domain-lookup
Create a login banner
The Cisco IOS global command set includes an option that allows you to configure messages that anyone logging into the switch via the console port will see. Go ahead and login here. Click on the CLI tab. Expand the screen. Hit enter, enable, config t. A login banner known as the message of the day or an MOTD banner should be configured to warn anyone accessing the device that unauthorized access will not be tolerated.
SW1(config)#banner motd #Go ahead and login here#
The delimiter character can be any character. For example, pound sign, as long as the character does not occur in the body of the message.
Securing console and ssh access
Applying a password to the console and vty lines will add an additional layer of security in case someone gains access to the switch and/or attempts to log in via the console port or via telnet/ssh through the management network. Setting the password will force the user to enter the correct password prior to being granted access to the user mode.
SW1(config)# line console 0 SW1(config-line)# password [email protected] SW1(config)#line vty 0 4 SW1(config-line)# password [email protected] SW1(config-line)# login
Using telnet, usernames and passwords are sent in clear text, which is a potential security risk so as a best practice you should avoid using telnet overall and only use ssh (version 2) when possible. SSH uses encryption, which means that all data transmitted over a network is secure from eavesdropping.
SW1(config)# line vty 0 4 SW1(config-line)# transport input ssh
Of course, you will need to add to SSHv2 related other configurations which is not covered in this article.
Securing Privileged EXEC mode
It is important to remember that all the switch commands can be accessed from the Privileged EXEC Mode. Configuring a password to protect the Privileged mode from unauthorized access is considered a best practice. There are two options available, the enable password, and the enable secret. Both of these commands accomplish exactly the same thing. They allow you to configure a password that the user must enter in order to access the Privileged EXEC mode. The enable secret option is the better choice because it encrypts the password.
SW1(config)#enable secret [email protected] SW1(config)#enable password [email protected]@$$w0rd
So if both of these commands have been entered on the switch, you will have to enter the enable secret password in order to gain access to the Privileged EXEC Mode. The enable secret command has priority over the enable password command.
By default, the Cisco IOS will display all of the passwords except the enable secret password in clear text. Let me show you that now.
SW1# show run | in line|pass no service password-encryption enable password [email protected]@$$w0rd line con 0 password [email protected] line vty 0 4 password [email protected]
Enable service password-encryption to secure all clear-text passwords.
SW1(config)# service password-encryption
Terminate idle and hung TCP sessions
The exec-timeout command must be used in order to log out sessions on vty or tty lines that are left idle. By default, sessions are disconnected after ten minutes of inactivity. In the following example, I am setting 15 minutes of idle (No activity) timeout.
SW1(config)# line con 0 SW1(config-line)# exec-timeout 15 SW1(config)# line vty 0 4 SW1(config-line)# exec-timeout 15
To ensures that the device on the remote end of the connection is still accessible and that half-open or orphaned connections are removed from the local Cisco IOS device, use the service tcp-keepalives-in and service tcp-keepalives-out global configuration commands and enable a device to send TCP keepalives for TCP sessions. This will terminate hung TCP sessions from the local Cisco IOS device.
SW1(config)# service tcp-keepalives-in SW1(config)# service tcp-keepalives-out
Timestamps are useful for viewing when certain events happen on a local device. Timestamps are also helpful for troubleshooting because they allow the network administrator to compare simultaneous events on the network device and analyze whether one occurrence caused, or was a result of, another. As a best practice, enable timestamps for logging and debugging events and fine tune them with msec and proper timezone as shown below.
SW1(config)# service timestamps debug datetime msec show-timezone SW1(config)# service timestamps log datetime msec show-timezone
Restrict HTTP/HTTPS access
Disable the web interface access by disabling HTTP and HTTPS server on a local switch.
SW1(config)# no ip http server SW1(config)# no ip http secure-server
Restrict PAD service
Disable Packet Assembler/Disassembler (PAD) service, which is used for X.25 networks by issuing the no service pad command in global configuration mode.
SW1(config)# no service pad
Memory Threshold Notifications
This feature allows you to mitigate low-memory conditions on a device. You can use Memory Threshold Notification, which generates a log message in order to indicate that free memory on a device has fallen lower than the configured threshold. You can also set Memory Reservation so that sufficient memory is available for critical notifications. This ensures that management processes continue to function when the memory of the device is exhausted.
The following example specifies a threshold of 20000 KB of free I/O and processor memory before the switch issues notifications: It also reserves 1000 KB of memory for critical notifications:
SW1(config)# memory free low-watermark processor 20000 SW1(config)# memory free low-watermark io 20000 SW1(config)# memory reserved critical 1000
CPU Thresholding Notification
The CPU Thresholding Notification feature allows you to detect and be notified when the CPU load on a device crosses a configured threshold. When the threshold is crossed, the device generates and sends an SNMP trap message. Two CPU utilization thresholding methods are supported in Cisco IOS software: Rising Threshold and Falling Threshold.
The following example shows how to set a rising CPU thresholding notification for total CPU utilization. When total CPU utilization exceeds 80 percent for a period of 5 seconds or longer, a rising threshold notification is sent.
SW1(config)# process cpu threshold type total rising 80 interval 5
The following example shows how to set a falling CPU thresholding notification for total CPU utilization. When total CPU utilization, which at one point had risen above 80 percent and triggered a rising threshold notification, falls below 70 percent for a period of 5 seconds or longer, a falling threshold notification is sent.
SW1(config)# process cpu threshold type total rising 80 interval 5 falling 70 interval 5
Disable CDP when needed
Cisco Discovery Protocol (CDP) is a network protocol that is used in order to discover other CDP-enabled devices for neighbor adjacency and network topology. CDP can be used by Network Management Systems (NMS) or during troubleshooting. CDP must be disabled on all interfaces that are connected to untrusted networks.
This is accomplished with the no cdp enable interface command. Alternatively, CDP can be disabled globally with the no cdp run global configuration command. Note that CDP can be used by a malicious user for reconnaissance and network mapping.
Other Best Practices
Here are some of the other recommended best practices which is not covered in this article but you should follow as per your requirements.
- Manage the switches in a secure manner. For example, use SSH, authentication mechanism, access list, and set privilege levels.
- Restrict management access to the switch so that untrusted networks are not able to exploit management interfaces and protocols such as SNMP.
- Always use a dedicated VLAN ID for all trunk ports.
- Be skeptical; avoid using VLAN 1 for anything.
- Disable DTP on all non-trunking access ports.
- Shut down or disable all unused ports on the switch, and put them in a VLAN that is not used for normal operations and turn on & configure the ports as you go.
- Deploy the Port Security feature to prevent unauthorized access from switching ports. Use port security mechanisms to provide protection against a MAC flooding attack.
- Use MD5 authentication where applicable.
- Use port-level security features such as DHCP Snooping, IP Source Guard, and ARP security where applicable.
I hope you enjoyed this article. Please feel free to leave any comment or feedback.