Access control enables you to restrict access to the network server and its services to a specific group of users.The authentication, authorization, and accounting (AAA) network security services provide the primary framework through which you can set up access control on your router or access server. Authentication is a way of identifying a user before permitting access to the network and network services. The Carrier Packet Transport (CPT) supports local authentication mechanism to administer its security functions.
Securing the Switch CLI
By default, a Cisco Catalyst switch allows anyone to connect to the console port, access user mode, and then move on to enable and configuration modes without any kind of security. That default makes sense, given that if you can get to the console port of the switch, you already have control over the switch physically. However, everyone needs to operate switches remotely, and the first step in that process is to secure the switch so that only the appropriate users can access the switch command-line interface (CLI).
Securing the CLI includes protecting access to enable mode, because from enable mode, an attacker could reload the switch or change the configuration. Protecting user mode is also important, because attackers can see the status of the switch, learn about the network, and find new ways to attack the network. Note that all remote access and management protocols require that the switch IP configuration be completed and working. A switch’s IPv4 configuration has nothing to do with how a Layer 2 switch forwards Ethernet frames. Instead, to support Telnet and Secure Shell (SSH) into a switch, the switch needs to be configured with an IP address.
Securing User Mode and Privileged Mode with Simple Passwords
By default, Cisco Catalyst switches allow full access from the console but no access via Telnet or SSH. Using default settings, a console user can move into user mode and then privileged mode with no passwords required; however, default settings prevent remote users from accessing even user mode. The defaults work great for a brand new switch, but in production, you will want to secure access through the console as well as enable remote login via Telnet and/or SSH so you can sit at your desk and log in to all the switches in the LAN. Keep in mind, however, that you should not open the switch for just anyone to log in and change the configuration, so some type of secure login should be used.
Most people use a simple shared password for access to lab gear. This method uses a password only—with no username—with one password for console users and a different password for Telnet users. Console users must supply the console password, as configured in console line configuration mode. Telnet users must supply the Telnet password, also called the vty password, so called because the configuration sits in vty line configuration mode.
In addition, Cisco switches protect enable mode (also called privileged mode) with yet another shared password called the enable password. From the perspective of the network engineer connecting to the CLI of the switch, once in user mode, the user types the enable EXEC command. This command prompts the user for this enable password; if the user types the correct password, IOS moves the user to enable mode. An example of the user experience of logging in to a switch from the console when the shared console password and the shared enable password have both been set.
To configure the shared passwords for the console, Telnet, and for enable mode, you need to configure several commands. However, the parameters of the commands can be pretty intuitive. The configuration for these three passwords does not require a lot of work. First, the console and vty password configuration sets the password based on the context: console mode for the console (line con 0), and vty line configuration mode for the Telnet password (line vty 0 15). Then inside console mode and vty mode, respectively, the two commands in each mode are as follows:
password password-value: Defines the actual password used on the console or vty
login: Tells IOS to enable the use of a simple shared password (with no username) on this ine (console or vty), so that the switch asks the user for a password.
The configured enable password, shown on the right side of the figure, applies to all users, no matter whether they connect to user mode via the console, Telnet, or otherwise. The command to configure the enable password is a global configuration command: enable secret password-value.
The configuration checklist collects the required and optional steps to configure a feature as described in this book. The configuration checklist for shared passwords for the console, Telnet, and enable passwords is:
- Step1: Configure the enable password with the
enable secret password-valuecommand. - Step2: Configure the console password:
- Use the
line con 0command to enter console configuration mode. - Use the
password password-valuesubcommand to set the value of the console password. - Use the
loginsubcommand to enable console password security using a simple password.
- Use the
- Step3. Configure the Telnet (vty) password:
- Use the
line vty 0 15command to enter vty configuration mode for all 16 vty lines (numbered 0 through 15). - Use the
password password-valuesubcommand to set the value of the console password. - Use the
loginsubcommand to enable console password security using a simple password.
- Use the
Basic configuration commands:
Switch# configure terminal
Switch(config)# enable secret practonet2
Switch#(config)# line console 0
Switch#(config-line)# password practonet1
Switch#(config-line)# login
Switch#(config-line)# exit
Switch#(config)# line vty 0 15
Switch#(config-line)# password practonet
Switch#(config-line)# login
Switch#(config-line)# end
Switch#
If you run Switch# show running-config you can see all your password configuration.
Securing User Mode Access with Local Usernames and Passwords
Cisco switches support two other login security methods that both use per-user username/password pairs instead of a shared password with no username. One method, referred to as local usernames and passwords, configures the username/password pairs locally—that is, in the switch’s configuration. Switches support this local username/password option for the console, for Telnet, and even for SSH, but do not replace the enable password used to reach enable mode. The configuration to migrate from using the simple shared passwords to instead using local usernames/passwords requires only some small configuration changes.
Working through the configuration, first, the switch of course needs to know the list of username/password pairs. To create these, repeatedly use the username name secret password global configuration command. Then, to enable this different type of console or Telnet security, simply enable this login security method with the login local line. Basically, this command means “use the local list of usernames for login.” You can also use the no password command (without even typing in the password) to clean up any remaining password subcommands from console or vty mode because these commands are not needed when using local usernames and passwords.
The following checklist details the commands to configure local username login, mainly as a method for easier study and review:
- Step1. Use the
username name secret passwordglobal configuration command to add one or more username/password pairs on the local switch. - Step2. Configure the console to use locally configured username/password pairs:
- Use the
line con 0command to enter console configuration mode. - Use the
login localsubcommand to enable the console to prompt for both username and password, checked versus the list of local usernames/passwords.
- Use the
- Step3. Configure Telnet (vty) to use locally configured username/password pairs.
- Use the
line vty 0 15command to enter vty configuration mode for all 16 vty lines (numbered 0 through 15). - Use the
login localsubcommand to enable the switch to prompt for both username and password for all inbound Telnet users, checked versus he list of local usernames/passwords. - (Optional) Use the
no passwordsubcommand to remove any existing simple shared passwords, just for good housekeeping of the configuration file.
- Use the
When a Telnet user connects to the switch configured, the user will be prompted first for a username and then for a password. The username/password pair must be from the list of local usernames; otherwise, the login is rejected.
Securing User Mode Access with External Authentication Servers
Using a username/password configured directly on the switch causes some administrative headaches. For instance, every switch and router needs the configuration for all users who might need to log in to the devices. Then, when any changes need to happen, like an occasional change to the passwords for good security practices, the configuration of all devices must be changed. A better option would be to use tools like those used for many other IT login functions. Those tools allow for a central place to securely store all username/password pairs, with tools to make users change their passwords regularly, tools to revoke users when they leave their current jobs, and so on.
Cisco switches allow exactly that option using an external server called an authentication, authorization, and accounting (AAA) server. These servers hold the usernames/passwords. Typically, these servers allow users to do self-service and forced maintenance to their passwords. Many production networks use AAA servers for their switches and routers today. The underlying login process requires some additional work on the part of the switch for each user login, but once set up, the username/password administration is much less. When using a AAA server for authentication, the switch (or router) simply sends a message to the AAA server asking whether the username and password are allowed, and the AAA server replies.
While the figure shows the general idea, note that the information flows with a couple of different protocols. On the left, the connection between the user and the switch or router uses Telnet or SSH. On the right, the switch and AAA server typically use either the RADIUS or TACACS+ protocol, both of which encrypt the passwords as they traverse the network.
Securing Remote Access with Secure Shell
Telnet has one serious disadvantage: all data in the Telnet session flows as clear text, including the password exchanges. So, anyone that can capture the messages between the user and the switch (in what is called a man-in-the-middle attack) can see the passwords. SSH encrypts all data transmitted between the SSH client and server, protecting the data and passwords.
SSH can use the same local login authentication method as Telnet, with the locally configured username and password. (SSH cannot rely on authentication methods that do not include a username, like shared passwords.) So, the configuration to support local usernames for Telnet, also enables local username authentication for incoming SSH connections. Below shows one example configuration of what is required to support SSH.
IOS uses the three SSH-specific configuration commands in the figure to create the SSH encryption keys. The SSH server uses the fully qualified domain name (FQDN) of the switch as input to create that key. The switch creates the FQDN from the hostname and domain name of the switch. Then the third command, the crypto key generate rsa command, generates the SSH encryption keys. Seeing the configuration happen in configuration mode, step by step, can be particularly helpful with SSH configuration.
SW1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
!
! Step 1 next. The hostname is already set, but it is repeated just
! to be obvious about the steps.
!
SW1(config)# hostname SW1
SW1(config)# ip domain-name example.com
SW1(config)# crypto key generate rsa
The name for the keys will be: SW1.example.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 4 seconds)
SW1(config)#
!
! Optionally, set the SSH version to version 2 (only) - preferred
!
SW1(config)# ip ssh version 2
!
! Next, configure the vty lines for local username support, just like
! with Telnet
!
SW1(config)# line vty 0 15
SW1(config-line)# login local
SW1(config-line)# exit
!
! Define the local usernames, just like with Telnet
!
SW1(config)# username wendell password odom
SW1(config)# username chris password youdaman
SW1(config)# ^Z
SW1#
To control which protocols a switch supports on its vty lines, use the transport input {all | none | telnet | ssh} vty subcommand in vty mode, with the following options:
transport input all or transport input telnet ssh: Support both Telnet and SSHtransport input none: Support neithertransport input telnet: Support only Telnettransport input ssh: Support only SSH
To complete this section about SSH, the following configuration checklist details the steps for one method to configure a Cisco switch to support SSH using local usernames. (SSH support in IOS can be configured in several ways; this checklist shows one simple way to configure it.)
- Step1. Configure the switch to generate a matched public and private key pair to use for encryption:
• If not already configured, use thehostname namein global configuration mode to configure a hostname for this switch.
• If not already configured, use theip domain-name namein global configuration mode to configure a domain name for the switch, completing the switch’s FQDN.
• Use thecrypto key generate rsacommand in global configuration mode (or thecrypto key generate rsa modulus modulus-valuecommand to avoid being prompted for the key modulus) to generate the keys. (Use at least a 768-bit key to support SSH version 2.) - Step 2. (Optional) Use the
ip ssh version 2command in global configuration mode to override the default of supporting both versions 1 and 2, so that only SSHv2 connections are allowed. - Step 3. (Optional) If not already configured with the setting you want, configure the vty lines to accept SSH and whether to also allow Telnet:
• Use thetransport input sshcommand in vty line configuration mode to allow SSH only.
• Use thetransport input allcommand (default) ortransport input telnet sshcommand in vty line configuration mode to allow both SSH and Telnet. - Step 4. Use various commands in vty line configuration mode to configure local username login authentication.
Two key commands give some information about the status of SSH on the switch. First, the show ip ssh command lists status information about the SSH server itself. The show ssh command then lists information about each SSH client currently connected into the switch.
