Best Practice: Securing Layer 2 Cisco IOS switch

LinkedIn
Facebook
Facebook
Google+
https://netfixpro.com/best-practice-securing-layer-2-cisco-ios-switch/
RSS
Follow by Email

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 P@ssW0rd

SW1(config)#line vty 0 4
SW1(config-line)# password P@ssW0rd
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 En@bleS3cr3t
SW1(config)#enable password En@bleP@$$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.

Encrypting passwords

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 En@bleP@$$w0rd
line con 0
 password P@ssW0rd
line vty 0 4
 password P@ssW0rd

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
Configure timestamps

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.

LinkedIn
Facebook
Facebook
Google+
https://netfixpro.com/best-practice-securing-layer-2-cisco-ios-switch/
RSS
Follow by Email

Ashutosh Patel

Ashutosh Patel is the Author and editor of netfixpro.com. He currently works as a Network Security Architect. Follow him on following social media to know more about him.

One thought on “Best Practice: Securing Layer 2 Cisco IOS switch

  • December 23, 2016 at 7:36 PM
    Permalink

    I want to practice on Cisco 45 and 65 series switch. Which I have to use for real life practice. Because Cisco packet tracer and GO S3 not support it. Help me

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Show Buttons
Hide Buttons

Enjoy this article? Please spread the word :)