What Is The Main Security Weakness In Using The Service Password-encryption Command

This chapter is from the book 

This chapter is divided into ii sections. The offset section looks at the configuration and verification of network device access control with usernames and passwords. It too covers the configuration and verification of role-based access control (RBAC) using privilege levels. The second section covers authentication, authorization, and accounting (AAA). It looks at the configuration and verification of network device access control on Cisco IOS devices using TACACS+ and RADIUS.

Cisco IOS CLI Session Overview

Cisco IOS software provides several features that you can use to implement basic security for network devices' command-line sessions. These features include:

Using different levels of authorization for CLI sessions to control access to commands that tin can change the status of the networking device and for commands that are used to monitor the device
Assigning passwords to CLI sessions
Requiring users to log in to a networking device with a username
Changing the privilege levels of commands to create new authorization levels for CLI sessions

You can found IOS CLI sessions on Cisco IOS devices in two ways:

Local CLI sessions: Local CLI sessions require straight access to the panel port of the networking device. Local CLI sessions start in user EXEC style. All of the tasks needed to configure and manage a networking device can be done using a local CLI session. The most common method for establishing a local CLI session is to connect a laptop to the panel port of the networking device and then launch a terminal emulation application, like Putty, on the computer. The type of cable and connectors required and the settings for the terminal emulation application depend on the type of networking device that you are configuring. Some devices have an auxiliary (aux) port for remote assistants through a dial-up modem. In most cases, this should be disabled with the no exec command under line aux 0.
Terminal lines and remote CLI sessions: A remote CLI session is created between a host and a networking device past using a remote final access awarding, such as Telnet or SSH. Almost of the tasks required to configure and manage a networking device tin can be washed using a remote CLI session. The exceptions are tasks that interact directly with the console port (such every bit recovering from a corrupted operating organization by uploading a new Os paradigm over the console port) and interacting with the networking device when it is in ROMMON style. SSH is a more secure alternative to Telnet. SSH provides encryption for the session traffic between the local management device and the networking device you are managing. Encrypting the session traffic with SSH prevents anyone who may have intercepted the traffic from decoding it.

With Cisco IOS networking devices, the discussion "lines" is used to refer to the software components that manage local and remote CLI sessions. You utilise the line console 0 global configuration control to enter line configuration style to configure options such as a password for the console port. Remote CLI sessions use lines that are referred to as vty lines. You utilise the line vty line-number [catastrophe-line-number] global configuration command to enter line configuration mode to configure options such as a countersign for remote CLI sessions. Once you are in the line configuration mode, you can set the protocol y'all will be connecting over (for example, SSH).

Example 6.1 shows the console, auxiliary, and vty lines in the running configuration that are available on R1.

Instance 6.1 Panel, Auxiliary, and vty Lines in the Running Configuration

          R1# R1#                          show running-config | section line                        line con 0 line aux 0 line vty 0 iv R1#

Before we look at how to protect access to Cisco IOS EXEC modes, let's take a look at the five different types of passwords available in Cisco IOS:

Type 0 passwords: Type 0 passwords are not encrypted and are stored in plaintext in the device configuration. The enable password command uses type 0 passwords. Type 0 passwords should not be used in a production surround.
Type 5 passwords: Type 5 passwords utilise an MD5 hashing algorithm. These passwords are easily reversible with tools available on the Net. The enable hole-and-corner and username username cloak-and-dagger commands employ blazon 5 passwords.
Type 7 passwords: Type seven passwords uses the Vigenère zippo encryption algorithm, which is known to exist weak. These passwords are easily reversible (in under ane second) with tools available on the Net. Type vii password encryption is enabled with the service password encryption command.
Blazon 8 passwords: Blazon 8 passwords use a Password-Based Key Derivation Function 2 (PBKDF2) with a SHA-256 hashed secret. Type 8 countersign security is considered good.
Type 9 passwords: Type nine passwords use the SCRYPT hashing algorithm. Type 9 passwords are considered the best passwords and should be used when supported.

Type 4 passwords were deprecated in IOS xv.3(3). The type 4 countersign hash was weaker than the type five (MD5) hash. Therefore, type 4 passwords should never be used. IOS xv.3(iii) introduced support for type eight and type 9 passwords, and these countersign types should always exist used when supported.

Protection of Access to Cisco IOS EXEC Modes

This department looks at the steps you can take to secure both user and privileged EXEC modes.

The first step in creating secure network device admission is to protect the user EXEC mode by configuring passwords for local and remote CLI sessions. You start by entering line configuration mode by selecting the line number for the console port (for example, line panel 0). One time you are in that mode, you employ the password command to assign a password to line panel 0. You use the login command at line panel 0 to enable countersign checking at login.

Side by side, permit's look at configuring a password for remote CLI sessions. After a countersign is configured for remote CLI sessions, the IOS device prompts for a password the next time you lot establish a remote CLI session with that device. Cisco IOS networking devices require that a password be configured for remote CLI sessions. If you try to start a remote CLI session with a device that does not take a password configured for remote CLI sessions, y'all get a message indicating that a password is required and that the password is not set. The remote CLI session will be terminated past the remote host.

To configure a password for remote CLI sessions, you start by inbound the line configuration mode and selecting the vty line (for instance, line vty 0 iv). When you are in that mode, y'all use the countersign control equally you do for the console line. You employ the login command at the vty line to enable password checking at login.

Example 6.2 shows how to assign a countersign to the console, auxiliary, and vty lines and verify it in the running configuration.

EXAMPLE vi.two Configuring and Verifying Line Passwords

          R1# R1#                          configure terminal                        Enter configuration commands, i per line.  End with CNTL/Z. R1(config)#                          line con 0                        R1(config-line)#                          password Cisco123                        R1(config-line)#                          login                        R1(config-line)#                          line aux 0                        R1(config-line)#                          countersign Cisco123                        R1(config-line)#                          login                        R1(config-line)#                          line vty 0 four                        R1(config-line)#                          password Cisco123                        R1(config-line)#                          login                        R1(config-line)#                          end                        R1# R1#                          show running-config | department line                        line con 0  password Cisco123  login line aux 0  password Cisco123  login line vty 0 iv  password Cisco123  login R1#

The previous section covers protection of access to both local and remote CLI sessions in user EXEC mode using line passwords. Now permit'due south look at how to protect access to privileged EXEC mode. To add together an additional layer of security, particularly for passwords that cross a network or that are stored with the configuration on a TFTP server, you can employ the enable secret global configuration command.

Cisco recommends the use of the enable secret command over the enable countersign command considering it uses an improved encryption algorithm. When you configure the enable secret control, information technology takes precedence over the enable password control. The two commands cannot exist in outcome simultaneously.

Permit'south look at the apply of the enable password command to configure a password for privileged EXEC mode. The password you lot enter with the enable password command is stored as plaintext in the device's running configuration. Yous tin can encrypt the password for the enable password command in the configuration file of the networking device past using the service countersign-encryption command. However, the blazon seven encryption level used by the service password-encryption command can be decrypted using tools available on the Cyberspace, and then it is not recommended for production deployments. The recommendation is to employ the enable hugger-mugger command because it provides stiff encryption by hashing the password using type five passwords past default. However, on modernistic platforms, you can utilize blazon eight or 9 passwords also. You lot configure a password in privileged EXEC mode by using the command enable secret [level level] unencrypted-password | encryption-type encrypted-countersign. Y'all can use the show privilege command to brandish the current level of privilege.

Example 6.3 shows the configuration and verification of protection of privileged EXEC mode using the enable password command. Note in the verification that the password is stored in the running configuration in plaintext. This is because the default password, of type 0, was used. Y'all can likewise set a type seven password or set the EXEC level here. The command service password-encryption would make the password unreadable in the running configuration.

EXAMPLE 6.3 Protecting Privileged EXEC with enable password

          R1# R1#                          configure terminal                        Enter configuration commands, one per line.  End with CNTL/Z. R1(config)#                          enable password                        ?            0      Specifies an UNENCRYPTED password will follow                          7      Specifies a HIDDEN countersign volition follow                          LINE   The UNENCRYPTED (cleartext) 'enable' password                          level  Set exec level password            
R1(config)#                          enable password ExamCram123                        WARNING: Command has been added to the configuration using a type 0 password. All the same, blazon 0 passwords will before long be deprecated. Drift to a supported password type R1(config)# *Oct 28 23:00:00.922: %AAAA-4-CLI_DEPRECATED: Alert: Command has been added to the configuration using a type 0 password. However, blazon 0 passwords volition before long be deprecated. Migrate to a supported password blazon
R1(config)#                          exercise evidence run | include password                        enable password ExamCram123            R1(config)# R1(config)#                          service password-encryption                        R1(config)#                          do show run | include password                        enable password seven 106B11180834000A01557878            R1(config)#                          cease                        R1#

Instance half dozen.4 shows the configuration and verification of protection of privileged EXEC mode using the enable hush-hush control. This provides stronger encryption and is the recommended method to use. This case uses type 9 encryption. When using type 9, you lot need to type in the encrypted countersign or use the algorithm-type command to hash a plaintext enable secret. Note that the verification output shows the encrypted type 9 password.

EXAMPLE 6.4 Protecting Privileged EXEC with enable hugger-mugger

          R1# R1#                          configure final                        Enter configuration commands, one per line.  Stop with CNTL/Z. R1(config)#                          enable ?                        algorithm-blazon  Algorithm to use for hashing the plaintext 'enable' clandestine            password        Assign the privileged level password (MAX of 25                   characters)   secret          Assign the privileged level secret (MAX of 25                   characters)
R1(config)#                          enable algorithm-type scrypt surreptitious ?                        LINE   The UNENCRYPTED (cleartext) 'enable' underground            level  Set exec level password
R1(config)#                          enable algorithm-type scrypt secret ExamCram123                        R1(config)#                          practise sho run | include underground                        enable hugger-mugger 9 $9$QlfhhreZrBM56f$VX4YG.twelvemonth/jHO/3gLFfTPqAw. cdraNRDSKJoEOtCrC3Q            R1(config)#                          end                        R1#

Later on you lot have protected admission to user EXEC manner and privileged EXEC fashion past configuring passwords for them, you can further increase the level of security on the device by creating usernames. You configure usernames to limit access to CLI sessions to a networking device to specific users. This is especially important if you are configuring a device to allow first-line technical back up user admission. These users typically would not need to run all commands available in privileged EXEC manner. For example, suppose you want technical support staff to be able to view the configuration on a device that will assist them to troubleshoot network issues without being able to alter the configuration. In this case, you tin can create a username, configure it with privilege level 15, and configure it to run the show running-config command automatically. When a user logs in with the username, the running configuration volition exist displayed automatically.

There are three means you lot tin configure a username on a Cisco IOS device:

Using the control username username countersign password configures a plaintext password (type 0).
Using the command username username secret password provides type 5 encryption.
Using the command username username algorithm-blazon [md5 | sha256 | scrypt] hugger-mugger password provides type 5, blazon 8, or blazon 9 encryption, respectively.

The last option provides the highest level of security since it allows for the highest level of password encryption (blazon eight or type ix). If the terminal option is not supported on a network device, and so the second option should be used since it provides MD5 encryption. The kickoff pick should exist avoided because it configures a plaintext password.

When yous enable password authentication on a line by using the password command, you need to enable password checking. Yous exercise so by using the login command. This is what allows password use on the line. One time y'all have an alternate connection to the device, yous can exam the login. It is a good idea to have an alternating connection to a device if there is a trouble logging in once more using the line you fabricated the changes on. The login local command allows for username/countersign pairs stored locally on the router to be used for the lines. By using the command login local, y'all can disable whatsoever password configured on lines.

To enable username and password hallmark on a line, you demand to do the following configuration:

Create the user with the username control in global configuration mode, using one of the three options listed earlier in this section.
Use the login local command in line configuration manner.

For remote CLI sessions, you tin further protect the lines by using the transport input command. This control controls what protocols are allowed to access the vty lines. This tin exist configured with the command transport input {all | none |telnet | ssh}. The all option allows both Telnet and SSH admission; none blocks Telnet and SSH; telnet allows only Telnet; and ssh allows simply SSH access. Using telnet ssh allows both Telnet and SSH access. For the nearly secure access, the vty lines should exist limited to SSH.

Example 6.five shows the configuration and verification of usernames. The user user1 is configured with a type 0 countersign, admin1 is configured with a blazon 9 password, tier1admin is configured with a blazon nine password (scrypt in this case), and tier2admin is configured with a type 8 password (sha256 in this case). The login local command is configured under the vty lines to tell it to utilise the router local user account database for authentication.

In this example, accept notation of the configured user accounts and the password types. user1 with the type 0 countersign is shown in running configuration in plaintext. Privilege level 15 gives admission to all commands, such equally the reload command, and allows a user to make configuration changes on the device.

Instance 6.v Configuring Usernames and Passwords

          R1# R1#                          configure terminal                        Enter configuration commands, i per line.  End with CNTL/Z. R1(config)#                          username user1 password weakpassword                        WARNING: Control has been added to the configuration using a blazon 0 password. However, type 0 passwords will shortly exist deprecated. Migrate to a supported password type R1(config)#                          username admin1 privilege xv secret admin1secret                        R1(config)#                          username tier1admin algorithm-type scrypt secret tier1adminsecret                        R1(config)#                          username tier2admin algorithm-type sha256 clandestine tier2adminsecret                        R1(config)#                          line vty 0 four                        R1(config-line)#                          login local                        R1(config-line)#                          finish                        R1# R1#                          show running-config | include username                        username            user1            countersign            0            weakpassword            username            admin1            privilege xv clandestine            nine            $9$iVS2wE3FxvTvDv$6k. NoCSCi2af4T8HpWeO1lBaTUnJzelT8S6xEETp7AI username            tier1admin            underground            9            $9$bIFEJkC8eW9Xyf$vXBZD.8ZSiHTcjpNVfuMWwX vveegKfHCfNXgLZUYA9w username            tier2admin            secret            8            $viii$PLF4/9DTLkfoTf$820AEmeaZA2mNh1oNJjAYk6 bYKSlLhUn9pULnifodyo R1#

Example six.6 shows how to institute a Telnet session from R2 to R1 past using username-based authentication with the tier1admin username and type 9 password created earlier. You can see here that you tin successfully connect and authenticate by using the tier1admin account.

EXAMPLE six.6 Verifying Username-Based Authentication for vty Lines

          R2# R2#                          telnet 100.1.ane.i                        Trying 100.1.i.one ...            Open up            
            User Access Verification
Username:            tier1admin            Password:
! Countersign entered is non displayed by the router            R1>            
R1# R1#                          show line                        Tty Typ     Tx/Rx  A Modem  Roty AccO AccI  Uses  Dissonance Overruns Int *    0 CTY            -    -      -    -   -    0      0   0/0     -      ane AUX 9600/9600  -    -      -    -   -    0      0   0/0     -            *  578 VTY            -    -      -    -   -    ii      0   0/0     -            579 VTY            -    -      -    -   -    0      0   0/0     -    580 VTY            -    -      -    -   -    0      0   0/0     -    581 VTY            -    -      -    -   -    0      0   0/0     -    582 VTY            -    -      -    -   -    0      0   0/0     -
Line(southward) not in async mode -or- with no hardware back up: two-577            ! the * in the output of the showline command indicates that the first vty (0) is in use            ! vty 0 is mapped to vty 578 automatically            
R1#

Secured Access with SSH

SSH is a far more secure option than Telnet. Although Telnet is the most pop protocol used to access Cisco IOS devices, it is an insecure protocol. Its session packets are carried in plaintext, making it piece of cake for someone to sniff and capture session information as it traverses the network. SSH provides encryption for session traffic betwixt a device and a terminal admission awarding. This prevents others from existence able to intercept and decode the traffic.

SSH is available in ii versions:

SSH Version ane (SSHv1): SSHv1 should be avoided considering in that location are some flaws in its implementation, including its weak CRC-32 integrity check.
SSH Version 2 (SSHv2): SSHv2 should be used when it is supported. The SSHv2 enhancement for RSA supports RSA-based public key authentication for a client and a network device. SSHv2 is not compatible with SSHv1.

Let united states now accept a look at the steps that are needed to set up a Cisco IOS device to run SSH:

Configure a hostname for the device, using the hostname hostname command.
Configure a domain name for the device, using the ip domain-name domain-proper name command.
Generate an RSA crypto primal. Generating a key pair on the IOS device automatically enables SSH. When you generate an RSA key, you are prompted to enter a modulus length. A longer modulus length takes longer to generate, but information technology is more secure. You generate an RSA fundamental with the crypto key generate rsa control.

Those three steps are mandatory. Afterwards yous accept taken those steps, you may need to set SSH to Version 2 considering information technology is at SSHv1 past default on some platforms. You lot exercise this with the ip ssh version 2 command. The other settings y'all tin can configure for the SSH service running on a device are the SSH timeout value and the authentication retries number. Y'all do so with the command ip ssh timeout seconds authentication-retries number. Side by side, y'all ready the transport input at the vty lines by using the transport input ssh command. Finally, besides at the vty lines, you use the login local control to cause the local username and password on the router to be used for authentication.

For verification, you tin employ the bear witness ip ssh command to view the version and configuration information for the SSH server. We tin can also use the show ssh command to show the status of the SSH server.

Example 6.7 demonstrates how to configure SSH, secure the vty lines to allow only SSH admission, and verify connectivity from R2 to R1.

EXAMPLE six.vii Configuring and Verifying vty Access with SSH

          R1# R1#                          configure last                        Enter configuration commands, i per line.  End with CNTL/Z. R1(config)#                          username admin2 secret Cisco123                        R1(config)#                          ip domain-name cisco.com                        R1(config)#                          crypto fundamental generate rsa                        The proper name for the keys will be: R1.cisco.com Choose the size of the key modulus in the range of 360 to 4096 for your Full general Purpose Keys. Choosing a primal modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]:                          2048                        % Generating 2048 bit RSA keys, keys will be not-exportable... [OK] (elapsed fourth dimension was 2 seconds)
R1(config)#                          ip ssh version two                        R1(config)#                          line vty 0 4                        R1(config-line)#                          login local                        R1(config-line)#                          ship input ssh                        R1(config-line)#                          cease                        R1#
R2#                          ssh ?                        -c    Select encryption algorithm   -l    Log in using this user name   -one thousand    Select HMAC algorithm   -o    Specify options   -p    Connect to this port   -v    Specify SSH Protocol Version   -vrf  Specify vrf proper noun   WORD  IP address or hostname of a remote arrangement
R2#                          ssh -l admin2 -v 2 100.one.one.1                        
            Password: ! Password entered is not displayed past the router
            R1>

Finally, yous tin can set a timeout for EXEC sessions that are left idle, which may pose a security risk. Under the line confirmation mode, y'all tin utilise the exec-timeout minutes seconds command to set the timeout. The default setting is ten minutes. Using exec-timeout 0 0 and no exec-timeout disables the EXEC timeout. You lot should not use these commands this way in a production surround.

The absolute-timeout minutes command in the line configuration mode sets the interval for closing the EXEC session after a specified time has elapsed. This session is closed even if information technology is being used at the time of termination. You tin use the logout-warning seconds command with the absolute-timeout command to notify users of an impending logout. Past default, the user is given 20 seconds' notice before the session is terminated.

Example vi.viii shows how to configure EXEC and accented timeouts and logout alert. For line con 0, a timeout value of 4 minutes is configured. For the vty lines, a value of 3 minutes and xxx seconds is configured. For the vty lines, an accented timeout of x minutes is configured, with a 120-2d logout warning.

Instance 6.8 Configuring EXEC and Accented Timeouts

          R1# R1#                          configure final                        Enter configuration commands, one per line.  End with CNTL/Z. R1(config)#                          line con 0                        R1(config-line)#                          exec-timeout four 0                        R1(config-line)#                          line vty 0 iv                        R1(config-line)#                          exec-timeout 3 30                        !next nosotros configure absolute timeout and logout alert            R1(config-line)#                          accented-timeout ten                        !logout warning is configured in seconds            R1(config-line)#                          logout-warning 120                        R1(config-line)#                          stop                        R1#

Privilege Levels and Role-Based Access Command (RBAC)

Now that we have examined the various ways of securing user and privileged EXEC modes, let's take a look at the utilise of privilege levels and RBAC. By default, Cisco IOS devices have three privilege levels:

Privilege level 0: Privilege level 0 allows for the use of five commands: enable, disable, help, logout, and exit.
Privilege level 1: Privilege level 1 is the user EXEC manner that yous saw configured before in this chapter, in the section "Protection of Access to Cisco IOS EXEC Modes." In this mode, it is not possible to make configuration changes.
Privilege level xv: Privilege level 15 is the privileged EXEC mode you saw configured before in this chapter, in Example half dozen.5. (It is too configured in the next example.) In this mode, all of the IOS CLI commands are available.

The commands that you can run in user EXEC mode at privilege level 1 are a subset of the commands that you can run in privileged EXEC mode at privilege fifteen. You lot can configure additional privilege levels from ii through 14 to provide customized access command. For example, you might desire to permit a group of technical support staff to configure only a specific set of interface-level commands on interfaces while preventing device-wide configuration privileges. You could configure this in global configuration mode by using the control privilege mode level level [command string]. After you lot create that technical support user and assign this privilege, the user will exist allowed to enter the interface and execute the commands specified in the command string. You lot tin can verify the configuration with the show privilege command.

Example 6.9 shows how to gear up up privileges to permit a network operation staff member to exercise basic manipulation of an interface. This case shows how to create the user user1noc with a blazon nine password and privilege level 5 configured. In this item case, a user with the user1noc username volition be allowed to shut, unshut, and assign an IP address on the interface because these are the only commands this configuration allows in privilege level five in interface configuration mode. A user who tries to type a command that is non allowed (such as the description command) gets the message "Invalid input detected."

EXAMPLE 6.ix Configuring and Verifying a Username and a Privilege Level

          R1# R1#                          configure last                        Enter configuration commands, 1 per line.  End with CNTL/Z. R1(config)#                          username user1noc privilege 5 algorithm-type scrypt secret Cisco123                        R1(config)#                          privilege exec level 5 configure terminal                        R1(config)#                          privilege configure level 5 interface                        R1(config)#                          privilege interface level five shutdown                        R1(config)#                          privilege interface level 5 no shutdown                        R1(config)#                          privilege interface level v ip address                        R1(config)#                          end                        R1#
R2#                          telnet 100.1.i.1                        Trying 100.1.1.1 ... Open up
User Access Verification
Username:            user1noc            Countersign:
R1#                          show privilege                        Current privilege level is 5            R1# R1#                          configure last                        Enter configuration commands, one per line.  End with CNTL/Z. R1(config)#                          interface GigabitEthernet 0/0                        
            !The options to configure on the interface are express            R1(config-if)#                          ?                        Interface configuration commands:   default   Gear up a command to its defaults   exit      Exit from interface configuration mode   help      Clarification of the interactive help organization            ip        Interface Internet Protocol config commands            no        Negate a command or ready its defaults            shutdown  Shutdown the selected interface            
R1(config-if)#                          description test                        ^ % Invalid input detected at '^' marker. R1(config-if)#                          stop                        R1#