5.2Device access control and AAA

If the network device itself is taken over, all the traffic it was protecting is put at risk. That is why hardening management access to routers/switches is a top-priority control. This section builds the judgment to decide "what suffices at small scale" versus "what is needed at large scale or under audit requirements," from local password configuration on a single device up to AAA (authentication, authorization, and accounting via external servers) that centrally manages many devices.

5.2.1Local passwords and SSH

• Protect privileged EXEC mode (enable) with enable secret. enable secret is stored hashed (type 5 by default, type 8/9 scrypt on newer IOS) so the plaintext cannot be recovered. The legacy enable password is not encrypted and is weak, so do not use it. Note that service password-encryption, which weakly obscures line passwords as type 7, is reversible and provides no real protection.
• On the console (line console 0) and the VTY lines (line vty 0 4, the virtual lines for Telnet/SSH), set password plus login, or login local (authenticating against the local database of username/secret). Use username NAME secret PASSWORD to create per-user accounts (secret—hashed storage—is safer than password).
• Because Telnet sends the username, password, and commands in plaintext, always use SSH for remote management. Enabling SSH requires (1) setting a hostname and domain name, (2) generating an RSA key with crypto key generate rsa, (3) creating a local user, and (4) specifying transport input ssh under line vty. SSHv2 is recommended.

5.2.2Password policy and stronger authentication

• Complexity means a sufficient length plus a mix of upper/lower case, digits, and symbols to resist guessing and brute force. On IOS you can enforce a minimum length with security passwords min-length. Management means operational rules: periodic changes, immediately changing default passwords, no reuse, and disabling departed-employee accounts.
• Because a password alone (a knowledge factor) is vulnerable to leaks, multi-factor authentication (MFA) requires multiple factors: "knowledge (password) + possession (token/phone) + inherence (fingerprint/face)." Certificate-based authentication (device/user certificates via a public-key infrastructure, PKI) and biometrics can be combined as MFA factors, making authentication far stronger than a password alone.

5.2.3AAA and TACACS+/RADIUS

• AAA is the framework of three functions: Authentication (who you are), Authorization (what you are allowed to do), and Accounting (a record of what you did). Instead of managing local passwords on each device separately, centralizing them on an external authentication server enables account add/remove, control of command privileges, and unified audit logs.
• TACACS+ is a Cisco-proprietary protocol. It uses TCP port 49 and encrypts the entire packet body (payload). Because it handles AAA's three functions separately, it supports granular per-command authorization (restricting which commands each user can run), making it well suited to device administration.
• RADIUS is an IETF open standard protocol. It uses UDP (1812 for authentication/authorization, 1813 for accounting; legacy 1645/1646) and encrypts only the password (other attributes are in plaintext). Its authentication and authorization are combined, so it is poorly suited to granular per-command authorization, but it is widely used for network access authentication via 802.1X (admission control of wired/wireless user devices).

Suppose you are the network operations lead at a company with 50 sites nationwide and several hundred Cisco routers/switches, asked to design access control meeting these requirements: (1) restrict which IOS commands each administrator can run (juniors allowed only show commands, seniors allowed configuration changes); (2) retain an audit log of who ran which command, when, and on which device; (3) centralize management because creating local users on every device does not scale. First, per-device local password operation is inadequate given the device count and requirements (1) and (2), so centralized management via AAA is the premise. Next, in choosing the external-server protocol, requirement (1)—"per-command authorization"—is the deciding factor. RADIUS combines authentication and authorization and encrypts only the password in the packet, making it poorly suited to granular per-command authorization or device-administration auditing. TACACS+, by contrast, can separate AAA's three functions, control per-command authorization and accounting granularly, and encrypts the entire packet body, matching the device-administration requirements exactly. So in this case the correct answer is to adopt TACACS+. If the requirement were instead "802.1X authentication for admitting employee-brought PCs onto the wired/wireless network," then RADIUS would be the standard choice. The practical knack for protocol selection is to judge by purpose: "device administration versus network access authentication."

5.2.4Section summary

• Protect privileged mode with enable secret (hashed) and use SSH, not plaintext Telnet, for remote management. username secret plus login local is the baseline
• Protect passwords with complexity plus operational management; since a password alone is weak, combine MFA (knowledge/possession/inherence), certificates, and biometrics
• With centralized AAA, use TACACS+ (TCP 49, whole-packet encryption, AAA separation) for device admin/per-command authorization/audit, and RADIUS (UDP, open standard) for 802.1X network access