Leaflet

6
OL-11615-01
directly connected to its destination subnet, and if the switch is configured to do so, that packet is
exploded as a broadcast on the destination subnet. In this way, a single directed broadcast packet can
reach multiple destinations, and can be used by programs such as smurf, to amplify the effects of an
attack. A smurf attack, named after its exploit program, is a DoS attack that uses spoofed broadcast ping
messages to flood a target system.
After you identify the services that are needed, it is a good practice to enable them only as they are
needed. Most network devices allow a selective configuration of services. Some services can be activated
either for the entire system, globally, or per component, typically at a module or interface level. Services
known to be prone to abuse should be deployed selectively whenever this feature is available. For
example, CDP is an available service on Cisco platforms that facilitates the administration and
troubleshooting of network devices. CDP is globally enabled by default, but in most cases there is no
real need to run this service on every interface. Running CDP on the wrong interface can give an attacker
the chance to obtain sensitive device and network information. For this reason, CDP should be enabled
only on the necessary interfaces.
Finally, disabling services is an activity that requires some planning. Prior to disabling any services,
determine if there are any dependencies (some services depend on other services to work correctly). This
helps avoid cases where one service unexpectedly breaks because another service was disabled.
The section, Unneeded Services, page 91 provides a list of available services on Catalyst switches that
might not be needed and can therefore be disabled. This section also includes the commands to disable
unneeded services, for both Cisco IOS and Catalyst OS.
Controlling Switch Access
Like other network infrastructure devices, switches often provide more access mechanisms than you
might realize, from console to remote sessions based on protocols such as Telnet and SSH. Some of these
mechanisms are enabled by default on some platforms, while other services need to be specifically
configured. Establishing controls on these access mechanisms is fundamental to prevent unauthorized
access and device misuse. Anyone who gains access to a switch can obtain critical information about the
network, reconfigure the device, and even take the device out of service. Therefore, each switch in the
infrastructure should be carefully configured to secure all the access mechanisms enabled on the system.
The following is a collection of best practices to help secure access to Catalyst switches:
• Secure local password management—Access to switches is controlled primarily by the use of user
names and passwords. The best way to handle most passwords is to maintain them on a centralized
system such as a TACACS+ or RADIUS authentication server. Unfortunately, it is not always
possible to handle all passwords on an authentication server, and often switches require the
configuration of local passwords for privilege access. It is also common to find special-use user
names, secret keys, and other password information in their configuration files. As a best practice,
all passwords and secrets contained in configuration files must be encrypted. Default passwords are
another concern. Switches might be delivered from the factory with default user names and
passwords. Users should be forced to change these default passwords, and to use non-trivial
passwords.
• Controlling interactive access—Switches can be accessed through a variety of interactive
mechanisms, including telnet, rlogin, and SSH. These access mechanisms always involve sessions
or lines that need to be properly protected. To that end, lines that are not going to be used need to
be disabled, access should be configured only for the protocols actually needed, and all lines should
be configured with authentication.