Configure and verify device access control using local passwords

Now we move from concepts to the CLI. This objective is about protecting access to a router or switch itself, using passwords stored on the device (as opposed to a central AAA server, covered in 5.8).

The three doors into a Cisco device

A Cisco IOS device has several access paths, called lines:

• The console line (line console 0), a physical serial or USB port. Local access only.
• The auxiliary line (line aux 0), an older port for a modem, on some routers.
• Virtual terminal (vty) lines (line vty 0 4, and on many devices line vty 0 15), used for Telnet and SSH sessions over the network. Each simultaneous remote session uses one vty line.

Once through a line you land in user EXEC mode (prompt Router>), which is privilege level 1 and lets you run only basic show commands. Typing enable takes you to privileged EXEC mode (Router#), privilege level 15, which gives full control. So there are two passwords to think about: one on the line to get in, and one on enable to escalate.

Protecting privileged EXEC: enable password versus enable secret

R1(config)# enable password Cisco123
R1(config)# enable secret Str0ngPass!

The enable password command stores the password in clear text in the running configuration. Anyone who sees the config sees the password. It exists only for backward compatibility with very old IOS versions.

The enable secret command stores a hash of the password. A hash is a one-way mathematical function: the device can check whether what you typed produces the same hash, but nobody can turn the hash back into the password. By default enable secret uses MD5, shown in the configuration as type 5:

enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0

If both enable password and enable secret are configured, the secret wins and the enable password is ignored. There is never a reason to configure both; just use enable secret.

MD5 is now considered weak against modern password-cracking hardware. Newer IOS versions allow stronger algorithms with the algorithm-type keyword:

! Type 8: PBKDF2 with SHA-256
R1(config)# enable algorithm-type sha256 secret Str0ngPass!
! Type 9: scrypt (recommended)
R1(config)# enable algorithm-type scrypt secret Str0ngPass!

The resulting config lines begin with enable secret 8 $8$... or enable secret 9 $9$.... Type 9 (scrypt) is the strongest and is what Cisco recommends. (You may also see references to type 4, an early SHA-256 implementation that turned out to be flawed and was deprecated; do not use it.)

service password-encryption (type 7)

Line passwords and enable password are stored in clear text. The global command service password-encryption scrambles them so that they are not readable at a glance:

R1(config)# service password-encryption

Afterwards the config shows, for example, password 7 0822455D0A16. This is type 7 encryption, a simple reversible cipher. Free tools on the web decode a type 7 string instantly. It protects only against someone glancing over your shoulder at a show running-config. It does not affect enable secret or username ... secret, which are already hashed. The exam wants you to know that type 7 is weak and reversible, that type 5 is a hash, and that type 8 and 9 are the strong choices.

Protecting the console and vty lines with a line password

The simplest line protection is a password directly on the line plus the login command, which tells IOS to actually ask for it:

R1(config)# line console 0
R1(config-line)# password ConPass1
R1(config-line)# login
R1(config-line)# exec-timeout 5 0
R1(config-line)# exit
R1(config)# line vty 0 4
R1(config-line)# password VtyPass1
R1(config-line)# login
R1(config-line)# exec-timeout 5 0
R1(config-line)# transport input ssh

Two things to notice. First, password alone does nothing; without login, the line will not prompt. Conversely, login with no password set on a vty line causes IOS to refuse the connection with “Password required, but none set.” Second, exec-timeout MINUTES SECONDS logs the session out after that much idle time. The default is 10 minutes. exec-timeout 0 0 disables the timeout entirely, which is convenient in a lab but insecure in production. transport input ssh allows only SSH (not Telnet) on the vty lines; it is not strictly part of this objective but is standard hardening.

Per-user accounts: username and login local

A single shared line password gives no accountability (you cannot tell who logged in) and must be changed everywhere when someone leaves. The better approach is a local user database:

R1(config)# username admin privilege 15 secret Adm1nPass!
R1(config)# username helpdesk secret HelpPass1
! Optional: strongest hash for the user secret
R1(config)# username auditor algorithm-type scrypt secret Aud1tPass!
R1(config)# line console 0
R1(config-line)# login local
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh

username NAME secret PASSWORD stores a hash (type 5 by default, type 9 with algorithm-type scrypt). The older username NAME password PASSWORD stores clear text (type 7 with service password-encryption); avoid it. login local on a line replaces login and tells IOS to prompt for a username and password and check them against the local database. Note that SSH always requires a username, so login local (or AAA) is mandatory for SSH access; a plain line password is not enough.

The privilege 15 option on the username means that user lands directly in privileged EXEC mode after logging in, skipping enable.

Privilege levels

IOS has 16 privilege levels, 0 through 15, but only three matter for the exam:

• Level 0: almost nothing; only the commands disable, enable, exit, help, and logout.
• Level 1: user EXEC mode (Router>). The default for lines. Show commands and basic troubleshooting; cannot enter configuration mode.
• Level 15: privileged EXEC mode (Router#). Full access, including configure terminal.

Levels 2 through 14 are custom levels where an administrator can assign specific commands with privilege exec level N COMMAND, but that is beyond CCNA depth. You can see your current level with show privilege.

Banners

A banner is a text message displayed to anyone connecting. The message of the day (MOTD) banner is shown before the login prompt to every connection type, so it is where you put the legal warning (“Unauthorized access is prohibited”). Such warnings do not stop attackers but are needed in many jurisdictions to prosecute them. The banner text is enclosed by a delimiter character of your choice that must not appear in the message:

R1(config)# banner motd #
Enter TEXT message.  End with the character '#'.
*** Authorized access only. Activity is monitored. ***
#

Other banners exist: banner login (shown after MOTD, before the username prompt) and banner exec (shown after successful login). The exam mostly asks about banner motd. Do not put anything in a banner that helps an attacker, such as “Welcome to the Acme core router in building 3.”

Login protection against brute force

Two additional global commands are worth knowing:

! Block all logins for 120 seconds after 3 failures within 60 seconds
R1(config)# login block-for 120 attempts 3 within 60
! Require at least 10 characters in new passwords
R1(config)# security passwords min-length 10

Verification: what show running-config reveals

After the configuration above, the relevant portion of show running-config looks like this:

R1# show running-config | include secret|password|login|exec-timeout
service password-encryption
enable secret 9 $9$5TxRJ4nEJXKGl.$Wg0m3Ug7Z5bJvL3TdU3M0hL0jI2Yw6Q7v4x2rQ
username admin privilege 15 secret 5 $1$Ah4c$Xm3j2G1oKkfP9Qz0M5v7b1
username helpdesk secret 5 $1$ZqT8$L0kd6yRb4pQ1nS9tV7wX2.
 password 7 0822455D0A16
 login local
 exec-timeout 5 0

Notice that the secrets appear as hashes (5 $1$... for MD5, 9 $9$... for scrypt) that cannot be reversed, while the leftover line password appears as type 7, which can be. show privilege shows your current level, and show users or show line lists active sessions on the lines.