Configuring privilege levels

This section of the chapter excerpt focuses on supporting multiple administrative levels of router configuration.

By: Michael Watkins, Kevin Wallace

Solution provider takeaway: The CCNA Security Official Exam Ceritifcation Guide is a Cisco exam study guide that focuses specifically on the objectives of the CCNA Security IINS exam. This chapter of the book examines configuring multiple administrative levels of your router.

Download the .pdf of the chapter here.

Larger enterprise environments might need to support multiple administrative privilege levels for router configuration. For example, help desk staff might need access to a subset of the IOS commands available to the primary router configuration team. Cisco IOS routers normally use two of the 16 supported privilege levels. Specifically, Cisco IOS routers support privilege levels in the range 0 to 15. By default, when you attach to a router, you are in user mode, which has a privilege level of 0. After entering the enable command and providing appropriate credentials, you are moved to privileged mode, which has a privilege level of 15.

However, for a finer granularity of administrative privileges, you can configure privilege levels in the range 1 to 14 using the privilege mode {level level command | reset command} command in global configuration mode. reset is used to reset the privilege level of a command to its original privilege level. To illustrate, Example 3-10 shows how to configure the debug command to be a privilege level 5 command and how to set the enable secret password for level 5 administrative access.

Example 3-10 Configuring a Privilege Level
R1# config term
R1(config)# privilege exec level 5 debug
R1(config)# enable secret level 5 L3v3l5P@55
R1(config)# end

After additional privilege levels are configured, an administrator can specify the privilege level she wants to change to using the enable level command. For example, for an administrator to switch to the previously configured privilege level of 5, she would enter the enable 5 command. After switching to a privilege level of 5, the administrator would have access to all commands associated not only with privilege level 5, but also all lower privilege levels.

Creating command-line interface views

Similar to making different commands available to different administrators using privilege levels, role-based command-line interface (CLI) views can be used to provide different sets of configuration information to different administrators. However, unlike making commands available via privilege levels, using role-based CLI views you can control exactly what commands an administrator has access to. Following are the steps required to configure these views:

Step 1 Enable AAA: Authentication, authorization, and accounting (AAA) is discussed in detail in Chapter 4, "Configuring AAA." For now, just realize that AAA must be enabled to support views. Example 3-11 shows how to enable AAA on an IOS router.

Example 3-11 Enabling AAA
R1# conf term
R1(config)# aaa new-model
R1(config)# end

Step 2 Enable the root view: The root view is represented by the set of commands available to an administrator logged in with a pri'vilege level of 15. You might be required to provide the enable secret password to enable the root view, as shown in Example 3-12.

Example 3-12 Enabling the Root View
R1# enable view

Step 3 Create a view: Use the parser view name command to create a new view, as shown in Example 3-13.

Example 3-13 Creating a View
R1# config term
R1(config)# parser view HELPDESK

Step 4 Set a password for the view: Use the secret 0 password command to set the password required to invoke the view. The 0 in the command indicates that the password provided is in plain text, as opposed to an MD5 hash value. Example 3-14 shows how to configure a view's password.

Example 3-14 Setting a Password for a View
R1(config-view)# secret 0 H3lpD3skP@55

Step 5 Add available commands to the view: The commands parser_mode
{include | include-exclusive | exclude} [all] [interface interface_identifier | command] command, issued in view configurationmode, allows an administrator to specify a command (or interface) available to a particular view. Example 3-15 shows how to specify that the copy command (followed by any keywords), the traceroute command, and the ping command will be available to a specific view (HELPDESK in this example).

Example 3-15 Specifying Commands Available to a View
R1(config-view)# commands exec include all copy
R1(config-view)# commands exec include traceroute
R1(config-view)# commands exec include ping

Step 6 Verify the role-based CLI view configuration: After creating a view, you can switch to that view with the enable view name command. After switching to the new view, you enter a ?, for context-sensitive help, to see what commands are available in your new view, as demonstrated in Example 3-16.

Example 3-16 Confirming Role-Based CLI Configuration
R1# enable view HELPDESK
Exec commands:
<1-99> Session number to resume
copy Copy from one file to another
enable Turn on privileged commands
exit Exit from the EXEC
ping Send echo messages
show Show running system information
traceroute Trace route to destination

Protecting Router Files

To protect a router's image and configuration from an attacker's attempt to erase those files, the Cisco IOS Resilient Configuration feature keeps a secure copy of these files. These files are called the bootset. Table 3-8 details the steps required to configure Cisco IOS Resilient Configuration.

Step Description
Step 1: Enable
image resilience
The secure boot-image command, issued in global
configuration mode, secures the Cisco IOS image. The secured
image is hidden so that it does not appear in a directory listing of
Step 2: Secure the
boot configuration
The secure boot-config command, issued in global
configuration mode, archives the running configuration of a
router to persistent storage.
Step 3: Verify the
security of the
The show secure bootset command can be used to verify that
Cisco IOS Resilient Configuration is enabled and that the files in
the bootset have been secured.

Enabling Cisco IOS Login Enhancements for Virtual Connections

Administrators, and therefore attackers, can create virtual connections to an IOS router using Telnet, SSH, and HTTP. Because an attacker does not need physical access to a router to attempt one of these "virtual" connections, you should further secure these connection types using the Cisco IOS Login Enhancements feature. This feature adds the following requirements to the login process:

  • Create a delay between repeated login attempts
  • Suspend the login process if a denial-of-service (DoS) attack is suspected
  • Create syslog messages upon the success and/or failure of a login attempt

These login enhancements are not enabled by default. To enable the login enhancements with their default settings, you can issue the login block-for command in global configuration mode. The default login settings specify the following:

  • A delay of 1 second occurs between successive login attempts
  • No virtual connection (that is, a connection using Telnet, SSH or HTTP) can be made during the "quiet period," which is a period of time in which virtual login attempts are blocked, following repeated failed login attempts.

You as an administrator, might want to alter the supported virtual login parameters to better detect and protect against DoS and/or dictionary attacks. Table 3-9 provides a command reference for these parameters.

Command Description
Router(config)# login block-for
seconds attempts attempts
within seconds
Specifies the number of failed login attempts
(within a specified time period) that trigger a quiet
period, during which login attempts would be
Router(config)# login quietmode
access-class {acl-name |
Specifies an ACL that identifies exemptions from
the previously described quiet period.
Router(config)# login delay
Specifies a minimum period of time that must pass
between login attempts. The default time period is
1 second.
Router(config)# login onfailure
log [every
Creates log messages for failed login attempts.
Router(config)# login onsuccess
log [every
Creates log messages for successful login attempts.
Router# show login Can be used to verify that enhanced support for
virtual logins is configured and to view the login

Consider the enhanced support for virtual logins configuration shown in Example 3-17.
After entering global configuration mode, the login block-for 30 attempts 5 within 10 command is used to block login attempts for 30 seconds after five failed login attemptsoccur within a 10-second time period. If logins are then blocked based on the firstcommand, the period of time that logins are blocked is called the quiet period. However, inthis example, the login quiet-mode access-class 101 command specifies that during thequiet period, traffic permitted by ACL 101 still is allowed to log in via Telnet, SSH, orHTTP. The delay between successive login attempts is configured to 3 seconds with the login delay 3 command. This configuration specifies that log messages should be generated upon every failed or successful login attempt using the login on failure log and login on success log commands. Finally, the show login command is issued to confirm theconfiguration of these virtual login parameters.

Example 3-17 Configuring Enhanced Support for Virtual Logins
R1# conf term
R1(config)# login block-for 30 attempts 5 within 10
R1(config)# login quiet-mode access-class 101
R1(config)# login delay 3
R1(config)# login on failure log
R1(config)# login on-success log
R1(config)# end
R1# show login
A login delay of 3 seconds is applied.
Quiet-Mode access list 101 is applied.
All successful login is logged.
All failed login is logged.
Router enabled to watch for login Attacks.
If more than 5 login failures occur in 10 seconds or less,
logins will be disabled for 30 seconds.
Router presently in Normal-Mode.
Current Watch Window
Time remaining: 9 seconds.
Login failures for current window: 0.
Total login failures: 0.

Creating a banner message

When someone connects to one of your routers, he sees some sort of message or prompt.
For legal reasons, Cisco suggests that a banner message be displayed to warn potential attackers not to attempt a login. For example, you wouldn't want to use a banner message that says, "Welcome! You are connected to Router 1." An attacker could use such a message as part of his legal defense, stating that he was told that he was welcomed to your router.

Please consult competent legal counsel when phrasing the banner message. However, as soon as you have the appropriate verbiage for your banner message, you can apply the message to your router with the banner motd delimiter message_body delimiter command. The motd parameter stands for "message of the day," and the delimiter is a character you choose to indicate the beginning and end of the banner message. Therefore, you should choose a delimiter that will not appear in the message body. Example 3-18 shows how to create a banner message. Notice that the $ character is used as the delimiter. Example 3-19 shows the new banner message presented to a user who just connected to the router via Telnet.

Example 3-18 Creating a Message-of-the-Day Banner
R1# conf term
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# banner motd $
Enter TEXT message. End with the character '$'.
WARNING: This router is the private property of Cisco Press.
Disconnect now if you are not an authorized user.
Violators will be prosecuted.

Example 3-19 Login Prompt with a Banner Message
WARNING: This router is the private property of Cisco Press.
Disconnect now if you are not an authorized user.
Violators will be prosecuted.
User Access Verification

CCNA Security Official Exam Ceritifcation Guide
 Defending the perimeter
 Password-protecting a router
  Configuring privilege levels
 Cisco Security Device Manager overview

About the book

 CCNA Security Official Exam Ceritifcation Guide is an exam prep book that focuses on the objectives for the CCNA Security IINS exam. Purchase the book from Prentice Hall.

Copyright 2008, Cisco Systems, Inc. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other uses.

This was last published in October 2008

Dig Deeper on Computer Network Installation and Administration Projects



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.