Follow these Best Practices for secure switch access:
Set system passwords – Use the enable secret
command to set the password that grants enabled access to the IOS system.
Because the enable secret command simply implements a
Message Digest 5 (MD5) hash on the configured password, that password still
remains vulnerable to dictionary attacks. Therefore, apply standard practices
in selecting a feasible password. Try to pick passwords that contain both
letters and numbers as well as special characters, for example, $pecia1$
instead of "specials," where the "s" has been replaced by
"$" and the "l" has been replace with
"1"(one).
Secure access to the console – Console access requires a minimum
level of security both physically and logically. An individual who gains
console access to a system will gain the ability to recover or reset the
system-enable password, thus giving that person the ability to bypass all other
security implemented on that system. Consequently, it is imperative to secure
access to the console.
Secure access to VTY Lines – The minimum recommended security for
Telnet access is:
Apply the basic ACL for in-band access to all VTY lines.
Configure a line password for all configured VTY lines.
If the installed IOS image permits, use Secure Shell Protocol (SSH) to
access the device remotely, instead of Telnet.
Use Secure Shell Protocol (SSH) – The protocol and application
provide a secure, remote connection to a router. Two versions of SSH are
available, SSH Version 1 and SSH Version 2. SSH Version 1 is implemented in IOS
software. It encrypts all traffic, including passwords, between a remote
console and a network router across a Telnet session. Because SSH sends no
traffic clear text, network administrators can conduct remote access sessions
that casual observers will not be able to view. The SSH server in IOS software
will work with publicly and commercially available SSH clients.
Configure system-warning banners – For both legal and administrative
purposes, configuring a system-warning banner to display prior to login is a
convenient and effective way of reinforcing security and general usage
policies. By clearly stating the ownership, usage, access, and protection
policies prior to a login, future potential prosecution becomes more solidly
backed.
Disable unneeded services – By default, Cisco devices implement
multiple TCP and UDP servers to facilitate management and integration into
existing environments. For most installations these services are typically not
required, and disabling them can greatly reduce overall security exposure.
These commands will disable the services not typically used:
no service tcp-small-servers
no service udp-small-servers
no service finger
no service config
Disable the integrated HTTP daemon if not in use – Although IOS
software provides an integrated HTTP server for management, it is highly
recommended that it be disabled to minimize overall exposure. If HTTP access to
the switch is absolutely required, use basic ACLs to isolate access from only
trusted subnets.
Configure basic logging – To assist and simplify both problem
troubleshooting and security investigations, monitor switch subsystem
information received from the logging facility. View the output in the
on-system logging buffer memory. To render the on-system logging useful,
increase the default buffer size.
Secure SNMP – Whenever possible, avoid using SNMP read-write
features. SNMP v2c authentication consists of simple text strings communicated
between devices in clear, unencrypted text. In most cases, a read-only
community string may be configured. In doing so, apply the basic access list to
mask to allow SNMP traffic to trusted hosts only.
Lab
Exercise 2: Using Local Usernames and Passwords
In this lab, students
will configure multiple local usernames with passwords. These will be used for
login authentication on the console port and virtual terminal lines.
In this lab, students will
configure multiple user accounts with advanced options to limit privilege
levels and use strong encryption to secure passwords.