The idea for this post (like many others) came from a recent session I taught on Cisco IOS® router security. The IINS and SECURE router classes as well as the FIREWALL ASA training class focus on what’s required for secure device administration. While the use of an external authentication server (typically TACACS+ using CiscoSecure® ACS) certainly applies here, we’ll focus on a smaller scale implementation using the local user database.
First of all, to use a local database it’s necessary to implement at least one line in the router configuration in the form of either:
password or username secret
Since the earliest versions of Cisco IOS there’s been a
line configuration command that’s the simplest way to enforce the use of a local database. This was introduced along with the
command to give administrators the choice of internal versus external authentication. A more popular (and modular) implementation is to use the
commands family, which, for the router, must start with
Once you enter this command, a little-documented feature takes hold. Regardless of any previously configured passwords for the console (direct connect) or vty (telnet/ssh) lines, the authentication methods are respectively changed to none and local. Unless one of the username commands shown above was configured first, this could result in the admin getting potentially locked out of the router!
One key difference between the local login characteristic of the IOS router that we outlined here and that of the Cisco ASA (and PIX) firewalls is that the addition of a privilege argument to the username command can allow an administrative user access to all CLI commands upon login (at the highest level of 15). By contrast, the ASA/PIX requires the use of a supplemental login exec command with re-authentication to gain privileged access.
Besides the one-step login for the IOS or the two-step process for the ASA/PIX, both platforms support aaa authentication enable. When this is linked to the local user database, the admin user issues an “enable” command and follows this with their locally configured user-specific password instead of the globally configured enable secret (router) or enable (ASA/PIX) passwords. An added benefit of this aaa approach is that debugging will actually show the admin user by name performing commands instead of the generic enable_15 designation displayed with the single global password.