Securing Administrative Access to Cisco Routers

Securing Administrative Access to Cisco Routers

In this section, we examine some best practices for setting passwords on network devices (not just routers), as well as selected topics where we examine and configure other administrative security features, such as role-based access control to the command-line interface and basic operating system and configuration security practices.

Let’s focus on some of the technical controls needed to secure both local and remote administrative access to Cisco routers. As was discussed in Chapter 2, “Building a Secure Network Using Security Controls,” security controls are either physical, administrative, or technical (PAT).

Before we look at specific technical security controls, we must define the types of access that might be made to the router platform itself for the purpose of configuring the device. There are two categories of router configuration access: local access and remote access:

  • Local Access. Direct, physical access to the device through its integral console port. Often referred to as out-of-band access.
  • Remote Access. Indirect access to the device through a TCP/IP network.

Often referred to as in-band access. Encryption of manag recommended if it will be on the same links as other traffic. A dedicated management network, perhaps a separate VLAN, should be considered too.

Review Line Interfaces

Line interfaces differ from other interfaces (such as GigabitEthernet, Serial, ATM, and so on) in that they are interfaces that terminate or accept configuration traffic only. They are not traffic-passing interfaces in the sense that they route traffic. Line interfaces are a critical interface from a security standpoint because they are the interfaces that all configuration traffic terminates on. Curiously, many organizations overlook setting up even the simplest security on these interfaces. There are two broad types of line interfaces:

  • Those that you can touch (physical line interfaces). Console port and auxiliary ports.
  • Those that you can’t touch (virtual terminal line interfaces). vtys.

To configure a line interface, you use the line global configuration command, as illustrated with the following command sequence:

As you can see, when you select a line interface with the line command (for example, line console 0), the prompt changes and indicates that you are now in line configuration mode.
The following CLI output shows the section of a typical router’s configuration where the different line interfaces are configured:

Let’s briefly review the console, auxiliary, and vty line interfaces:

Console Line Interface

The console line interface is a serial DCE RJ45 port on the router. It provides a clock, and you have to match its settings. You can connect a dumb terminal or a computer running a terminal emulation program to it with a Cisco rollover cable and access the various command prompts on the router. The default settings for the console port are 9600 bps, no parity, 8 data bits, and 1 stop bit—or 9600-N- 8-1 for short. The terminal settings can be changed by modifying the configuration register using the config-register global configuration mode CLI command. Of course, router security starts with physical security controls, so make sure that only a privileged few have physical access to your router, or you might see it for sale on an online auction site! This is an out-of-band line interface.

Auxiliary Line Interface

All routers also have another physical line interface called the auxiliary port. You can attach an external modem to this interface so that you can dial in to the device’s auxiliary port over the plain old telephone system (POTS) to perform out-of-band configuration.

Cisco 800-series ISRs have a virtual auxiliary port because the console port and auxiliary port share the same physical RJ45 jack on the router. All other ISRs have separate RJ45 jacks for the console and auxiliary port and are clearly labeled.

Virtual Line Interfaces

Finally, let’s review the virtual terminal line interfaces or vtys. By default, all Cisco routers (and many other Cisco devices) come with five virtual terminal line interfaces: vty 0, 1, 2, 3, and 4. These virtual line interfaces are pseudo or dummy interfaces that terminate configuration traffic that arrives on the router in-band.

Out-of-band versus in-band have a special meaning in the context of these configuration interfaces. In-band means that a user must use a TCP/IP network and application proto cols such as Telnet and Secure Shell (SSH) to configure the device. The virtual terminal line interfaces are thus in-band. Out-of-band means that a user does not depend on a TCP/IP network to configure the device and therefore must physically connect to the device in order to configure it. The console port and auxiliary port are thus out-of-band.

Password Best Practices

You knew it was coming! We have to configure passwords to protect the router from unauthorized access, but what constitutes a good password according to Cisco? Cisco makes specific recommendations about this. The following is not an exhaustive list. You may want to add your own rules for password complexity, for example, but here are the Cisco recommendations for creating strong passwords:

  • Passwords should have at least 10 characters.
  • Passwords must begin with an alphabetic character.
  • Passwords can include the following:
    • Alphanumeric characters
    • Symbols and spaces
  • Do not use dictionary words, even as part of a password.
  • Leading spaces in passwords are ignored. All other spaces after the first character are not ignored.
  • Change the password often.

Configuring Passwords

When you put passwords on the console, auxiliary, and virtual terminal line interfaces, you are protecting user-level access only. Cisco makes specific recommendations for security best practices for passwords and other login settings on these line interfaces. We examine basic security of the user and enable modes (essentially review from CCNA) and then look at some more advanced security features, including how to secure the ROM Monitor (ROMMON) mode on the router.

Console Password

The console password protects the first configuration mode that a user sees when connected to the console line interface: user mode. The following commands illustrate how to set a password on the console:

Virtual Terminal Password

The console password protects the first configuration mode that a user sees when connected to the virtual terminal line interface, the user mode. The following commands illustrate how to set a password on the vtys:

Enable Password

Setting an enable password or, better yet, an enable secret password, protects the enable (super user) mode of the router:

Secret Password

The following command creates an encrypted secret password for the enable mode using an MD5 hash. When the enable secret password is set, it supersedes the enable password that is subsequently ignored:

Service Password Encryption

For even better security, you can encrypt all the passwords on the device (with the exception of the hashed enable secret). This is not as strong encryption as the MD5 hash on the enable secret, but it will prevent accidental discovery of the router’s passwords.

If you are using the auxiliary port, aux 0, for access, don’t forget to password protect its access too! The 800 Series ISR has a single console port that can be configured as a vir tual auxiliary port if you want to connect a modem to it for example. Other ISRs (1800, 2800, and 3800 Series) have a separate auxiliary port.

Setting Timeouts for Router Lines

Common sense (and hopefully your security policy, too!) dictates that no one should be able to remain forever on an inactive line interface (console, auxiliary, vty). The exec-timeout minutes seconds command terminates an inactive connection. For example, if you wanted to terminate an inactive console connection after 2 minutes and 15 seconds, you would type the following two commands.:

Configuring Minimum Password Length

While Cisco recommends a minimum password length for all passwords there is no enforcement by default. The security passwords min-length command enforces a minimum password length. For example, if you wanted the minimum password length to be 16 characters, you would type in the following command:

Username Password Security

Usernames and passwords are often stored in a local database on the router to enhance Authentication, Authorization, and Accounting (AAA) configurations. The passwords are not encrypted by default. Although these passwords would be encrypted with the service password encryption command, this level of encryption is not as good as a Message Digest 5 (MD5) hash. The following command will encrypt the password of a user called rtradmin with an MD5 hash. Note that a 0 denotes that what follows is a cleartext (unencrypted) password. When viewing the configuration, a 5 denotes that what follows is a hidden password. We can use context-sensitive help to demonstrate in the following sequence of commands. The password before (cleartext) and after (encrypted) is highlighted in the output:

Hashing functions, including Message Digest 5 (MD5), are discussed in Chapter 6, “Introducing Cryptographic Services.”
Verify that the user’s password is encrypted:

Securing ROMMON Mode

The ROM Monitor (ROMMON) mode is most often used while performing password recovery. To recover passwords, you must have physical access to the device with a terminal connected to the console port. If your security policy dictates that no one can recover passwords in this fashion, you need to disable the ability to break out of the router’s boot-up process in order to enter ROMMON mode with the no service password-recovery command. This is very dangerous, to say the least, because executing this command will disable the password recovery mechanism on the router. If you lose the enable password, your only remedy is to send the router back to Cisco for replacement!

Setting Multiple Privilege Levels

So far, we’ve treated user privilege as binary. They either have next-to-none (level 0) or they have super-user privilege when they’re in enable mode (level 15). There might be a number of people who need access to the router. The ISP might need access; the ACL administrator might need access; the Change Control and Configuration Management Policy might dictate that only one person is privileged enough to save the router’s configuration; and so on. To account for the need for these various privilege levels of access, the interim privilege levels (1–14) can be customized in a very granular fashion. You can assign what configuration mode(s) a user who has a defined privilege level is allowed to use. Optionally, you can set what commands they are allowed to execute. Let’s look at a simple example. If you wanted to allow users at privilege level 3 to enter the configure command (something that they’re not normally allowed to do), you could type in these commands:

Configuring Role-Based Access to the CLI

With the parser view feature, you can create a “view” that is a collection of all the commands that someone who has the password to that view is allowed to execute. A view is a contained shell environment that limits their view of the router. Unlike access granted via privilege levels where someone with level 10 access also has access to commands authorized at levels 1–9, role-based CLI is more modular. Access that is granted within one view is separate from other views. We’ll go through it step-by-step in a moment, but sometimes it’s better to take a look at an example first and use intuition.

Here’s an example of how views may be used in real life. Let’s say our router is managed by an ISP.

The following bullets list the items we want the ISP user to be able to accomplish while logged into the view, followed by the command keywords to enable this command in the view. These keywords are highlighted in the subsequent command output so you can pair them up with their descriptions below. Note that the parser view defines separately which exec commands and which configuration mode commands you are authorized to execute in the view. This follows the general hierarchy of CLI commands:

  • Exec Commands:
    • Ping IP hosts: ping
    • Use all show commands: all show
  • Configuration Modes:
    • Enter global configuration mode: configure
    • Create ACLs: access-list
    • Enter interface configuration mode: all interface
  • Use all IP configuration commands: all ip

If it’s not in the view, they can’t do it! For example, we don’t want our ISP to be able to write the configuration to the router’s NVRAM. If we don’t authorize them to use the copy command or the write command, then it’s not going to happen. Once authenticated to the view, the view will determine what they are authorized to do. No surprise, then, that we have to first enable AAA on the router. This is done using the aaa  new-model command before we can proceed. First, we enable the AAA system on the router:

Then we enable the view context and supply the enable secret password. The view hasn’t been created yet. The view context tells the router that subsequent commands are executed within the context of creating a view.

Now we enter global configuration mode and create the view by giving it a name, specify a password, and then we specify which exec mode commands can be executed in the view.

Now we specify which global configuration commands the user can execute. He can use the access-list command, and all forms of the interface command and ip command:

Once you’ve configured this view for the ISP, here’s what it looks like from the ISP’s perspective. Should he be able to execute the write mem command? The answer is no, because we have not given the ISP view access to that command. Let’s enable the view and try out all the commands that the ISP user is authorized to execute, as well as the write mem command, which he is not authorized to execute:

In summary, here are the steps to create a view:

  1. Enable AAA on the router (if it hasn’t already been enabled): aaa new-model
  2. Enable the router’s view context: enable view
  3. Enter global configuration mode: configure terminal
  4. Create a new view or enter an existing view: parser view view-name
  5. Assign a password for logging into the view: secret 5 encrypted-passwd (or secret 0 cleartext passwd)
  6. Specify the commands that can be executed in exec and configure modes: commands (see the examples for syntax of two parser modes)
  7. Exit from view configuration mode: exit

You should know the following about the enable view command and setting up parser views in general:

  1. The enable view command is not entered in global configuration mode. This is easy to remember if you recall that all enable commands are entered in an exec mode. This sounds like it might be a great trick question.
  2. Know at least two of the parser modes for the views, exec and configure, as these are the ones in Cisco’s course material and therefore likely to be on the exam.

Configuring the Cisco IOS Resilient Configuration Feature

The Cisco IOS resilient configuration feature enables the router to take secure snapshots of the router’s running configuration file and image. This protects the router against attempts by an attacker to erase the contents of NVRAM and flash (persistent storage). These secured files are hidden from standard commands that view the contents of persistent storage. For example, the show flash command will not show the secure image file. If a router has been compromised, the resulting down time is reduced because the router maintains secure archives of the required files and there is no need to search for backups of these files elsewhere. The first command creates a secure copy of the IOS image. It also indicates what happens if you don’t have an ATA disk (required):

The secure boot-config command functions properly only when the system is configured to run an image from a disk with an Advanced Technology Attachment (ATA) interface. The commands captured above were from a Cisco 871 ISR that does not support ATA; thus, we observe the notification “…No ATA disk found for storing archives.” Now, we’ll execute the command that verifies the bootset:

Remember that the only way you can view the secured copies of the configuration and IOS image is to execute the show secure bootset command.

Protecting Virtual Logins from Attack

Recall from Chapter 1, “Network Insecurity,” that there are two broad categories of attacks: access attacks and DoS attacks. We will examine three methods to mitigate the successfulness of these attacks against SSH, Telnet, and HTTP login to the IOS router:

  • Shutting down or “blocking” the login system if DoS attacks are suspected.
  • Enforcing a delay between successive login attempts.
  • Generating syslog messages for login detection.

Blocking the Login System

When a DoS attack on the login system is detected, subsequent login attempts can be blocked for a specified time [in seconds]. You must set the threshold of number of tries within a specified period [in seconds]. Here is the format of the command: login block-for seconds attempts tries within seconds

For example, if your security policy stipulates that five login attempts within 60 seconds constitutes a possible DoS attack, you might want to block subsequent logins for 120 seconds:
CiscoISR(config) #login block-for 120 attempts 5 within 60 This enforced blocking period (120 seconds in the preceding example) is known as a quiet period. During that quiet period, no login attempts will be accepted by the router. If you want to specify a policy as to who would be allowed to attempt a login during this quiet period, you can use an ACL to describe the IP addresses that can. Perhaps this is a management VLAN or IPsec VPN user. Recall from your CCNA studies that the way to limit access to the virtual terminal lines is to use the accessclass command to apply an ACL to the vtys. In this example, packets that match the named IP ACL “RA-VPN-Users” will be allowed to login during the quiet period. Note the use of the access-class parameter in the command syntax:

Enforcing a Delay Between Logins

To protect the IOS router against possible dictionary attacks, you can enforce a delay between successive login attempts. This will help frustrate an attacker and will also protect the login system such that legitimate users will get an opportunity to login to the device. For example, if you want to enforce a login delay of one second between attempts, issue this command:

If you use the auto secure command, a login delay of one second is automatically config ured. The auto secure command is discussed in Chapter 4.

Generating Syslog Messages for Login Detection

The following two commands generate logging messages for successful and failed login attempts respectively:

Verifying the Login Configuration

The show login command verifies that the modifications that we have made to the login subsystem of the router will be enforced. The shaded parts of the following output indicate these changes:

Configuring Banner Messages

Five different banners can be configured on the IOS router:

  • Exec. This banner is displayed when an exec mode (user or enable) is entered on the router.
  • Incoming. This banner is displayed when there is an incoming connection to a terminal line from a network host.
  • Login. This banner is displayed before the username/password prompt.
  • MOTD. The message-of-the-day banner.
  • SLIP-PPP. This banner is displayed for dial-in users on a Serial Line Internet Protocol (SLIP) or Point-to-Point Protocol (PPP) connection.

Remember that the router, in its role as a perimeter device, is often the first device an attacker is likely to see as he probes the network. The banners are the first thing that users see when they login to the routers. This would be an appropriate place to put warning messages and legal statements, such as the repercussions of unauthorized access to the system. Don’t give away any information inyour banner message that might be useful to an attacker. Above all, don’t tell anyone that they’re “Welcome.” If they’re an attacker, they certainly aren’t, and the router’s login banners should not be the equivalent of a welcome mat in any case. Here’s a partial configuration showing an example of a MOTD banner:

You can use replaceable parameters in the banner message. For example, the parameters $(hostname) and $(domain) will be replaced with the system’s hostname and domain name suffix respectively when the banner is displayed upon login.

About the author


Leave a Comment