8. Appendices 215 1. Top Ways to Quickly Secure a Cisco Router
8.2. Application to Ethernet Switches and Related Non-Router Network Hardware
This appendix identifies specific principles and recommendations from the main body of this guide that apply to Ethernet switches, managed hubs, access servers, and other network hardware components that are not IP routers. Prior to the 1990s, routers were the only LAN components with sufficient flexibility to need security configuration. Since the mid-1990s, hubs, switches, access servers, and other LAN components have been gaining substantial capabilities; many of them are as flexible and configurable as a router. Such devices almost always support remote
administration and management, and are therefore subject to compromise over the network. Because they are vital to network operations and because they can be used as a staging area for additional attacks, it is important to configure them securely.
The discussion below focuses mainly on media -level network components: switches, managed hubs, and bridges. These devices are characterized by participation in the network itself but forwarding and switching traffic based on a media layer address (e.g. an Ethernet MA C address). Because they cannot perform network layer or transport layer traffic filtering, switches and hubs cannot generally enforce security policies on network traffic. The focus for security for these devices is protecting their own configuration, and preventing their use by unauthorized individuals and attacker.
Another kind of common network device that needs protection is the access server.
An access server is a device that services a set of phone lines, and provides dial-up IP access for remote users. These kinds of devices usually have very extensive security and remote administration support, and configuring them securely requires a great deal of care. Configuring access servers is outside the scope of this guide.
8.2.1. Security Principles and Goals
The general security goals for a switch or smart hub are similar to those for a router, but simpler because such a network component does not act as a boundary device between different networks. The security goals for a switch or hub are listed below.
§ preventing unauthorized examination of device state and configuration
§ preventing unauthorized changes to the device state and configuration
§ preventing use of the device for attacking the local network
§ preventing unauthorized remote management/monitoring of the device To achieve these goals, the device must be configured to strictly limit all forms of access: physical, local connections, and remote network connections. If possible, it is best to create a security checklist for LAN switches. Follow the general form of the security checklist given at the end of Section 3.
8.2.2. Application to Cisco IOS -based LAN Equipment
Cisco makes several kinds of network switches, but they can be divided into two broad groups: those that use Cisco IOS or a derivative (e.g. 2900 series) and those that do not use IOS (e.g. Catalyst 5000 series). While the command syntax and command interface structure differ between Cisco IOS-based and other equipment, the same general principles apply to all of them. The syntax shown in Section 4 will work for IOS-based switches, but will not generally work on other devices.
Much of the security guidance given in Section 4 that can be applied to IOS-based Cisco switches, and even some smart Ethernet hubs. Before attempting to apply the detailed instructions from section 4, check whether the particular switch is running IOS or some other operating system. If you do not have the switch documentation handy, login to the switch and use the show version command to display the operating system name; the operating system name and version are underlined in the examples below.
IOS-based Catalyst 2900 Non-IOS Catalyst 5500
sw20c# show version
Cisco Internetwork Operating System Software IOS (tm) C2900XL Software (C2900XL-H-M), Version 11.2(8)SA, RELEASE SOFTWARE (fc1) .
.
sw20c uptime is 6 days, 3 hours, 9 minutes .
.
sw20c#
Cat5k# show version
WS-C5505 Software, Version McpSW: 4.5(1) NmpSW: 4.5(1)
. .
System Bootstrap Version 5.1(2) .
.
Uptime is 45 days, 3 hours, 51 minutes Cat5k#
The table below describes how to apply the guidance in each part of Section 4 to IOS-based LAN switches.
Section Topic Application to Switches
4.1 Access security All of this section applies to switches: setting up users and passwords, remote access restrictions, and configuration loading and maintenance.
4.2 Network service security
Most of this section applies to switches; any network service that is related to routing usually is not supported on a switch, and thus does not need to be configured.
Especially important for 2900 switches is restricting access to the HTTP server. In addition, all ports should be configured to block traffic to unknown addresses using the port block interface configuration command.
4.3 Access lists IOS-based switches support IP access lists, but do not use them for as many different purposes as a router does.
Basically, on a switch, access lists are used for limiting access to services on the switch itself, but not for filtering traffic passing through the switch.
Section Topic Application to Switches 4.4 Routing
protocols
This section is not generally applicable to switches.
[Note: some Catalyst 5000 and higher series switches are equipped with a ‘Route Switch Module’. This module is essentially a 4700-series IOS router attached to the switch.
It should be configured using Section 4 like any other router.]
4.5 Audit and Management
Almost all of this section applies to IOS-based switches;
some switch IOS versions do not su pport NTP, and must have their time set manually. All switches support RMON and SMTP; they should be disabled if not in use, or access to them should be restricted.
4.6 Access control with AAA
All of this section is applicable to IOS -based switches, if they support AAA (IOS 11.2 and later).
Note that Cisco switch-resident routing hardware (e.g. Catalyst 5000 series Route Switch Modules) can and should be configured using the guidance in Section 4, after careful consideration of its role in the network security policy.
Most of the security testing guidance given in Section 6 also applies to LAN switches.