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:
CiscoISR(config)#line ? <0-6> First Line number aux Auxiliary line console Primary terminal line vty Virtual terminal CiscoISR(config)#line console 0 CiscoISR(config-line)#
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:
line con 0 transport input all login password N3v3rGu355M3! line aux 0 transport input all password N3v3rGu355M3! line vty 0 4 transport input telnet ssh login local
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.
NOTE
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.
NOTE
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:
CiscoISR(config) #line console 0 CiscoISR(config-line) #login % Login disabled on line 0, until ‘password’ is set CiscoISR(config-line) #password cisco
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:
CiscoISR(config) #line vty 0 4 CiscoISR(config-line) #login % Login disabled on line 2, until ‘password’ is set % Login disabled on line 3, until ‘password’ is set % Login disabled on line 4, until ‘password’ is set % Login disabled on line 5, until ‘password’ is set % Login disabled on line 6, until ‘password’ is set CiscoISR(config-line) #password sanjose
Enable Password
Setting an enable password or, better yet, an enable secret password, protects the enable (super user) mode of the router:
CiscoISR(config) #enable password cisco
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:
CiscoISR(config) #enable secret sanfran
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.
CiscoISR(config) #service password encryption
NOTE
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.:
CiscoISR(config) #line console 0 CiscoISR(config-line) #exec-timeout 2 15
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:
CiscoISR(config) #security passwords min-length 16
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:
CiscoISR(config) #username rtradmin secret 5 ? WORD The HIDDEN user secret string CiscoISR(config) #username rtradmin secret 0 ? LINE The UNENCRYPTED (cleartext) user secret CiscoISR(config) #username rtradmin secret 0 Can’tGue55M3
NOTE
Hashing functions, including Message Digest 5 (MD5), are discussed in Chapter 6, “Introducing Cryptographic Services.”
Verify that the user’s password is encrypted:
CiscoISR(config) #do show running-config | include username rtradmin username rtradmin secret 5 $1$C0GC$mSvkJRen9Qf4UjfnQ4tPH/
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!
CiscoISR(config) #no service password-recovery WARNING: Executing this command will disable password recovery mechanism. Do not execute this command without another plan for password recovery. Are you sure you want to continue? [yes/no]: yes CiscoISR(config)#
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:
CiscoISR(config) #privilege exec level 3 configure CiscoISR(config) #enable secret level 3 sanjose Now, when a user logs in, either in-band or out-of-band to the user mode, they can enable privilege level 3. The show privilege command indicates the current privilege level: CiscoISR>enable 3 Password: sanjose CiscoISR#show privilege Current privilege level is 3
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
NOTE
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:
CiscoISR(config) #aaa new-model
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.
CiscoISR#enable view Password: enablesecretpassword
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.
CiscoISR#config terminal Enter configuration commands, one per line. End with CNTL/Z. CiscoISR(config) #parser view ISP CiscoISR(config-view) #secret 0 hardtoguess CiscoISR(config-view) #commands exec include ping CiscoISR(config-view) #commands exec include all show Here we specify that the user can configure from all sources (for example: terminal, memory, terminal): CiscoISR(config-view) #commands exec include all configure
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:
CiscoISR(config-view) #commands configure include access-list CiscoISR(config-view) #commands configure include all interface CiscoISR(config-view) #commands configure include all ip
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:
CiscoISR>enable view ISP Password: hardtoguess Apr 19 13:19:03.892: %PARSER-6-VIEW_SWITCH: successfully set to view ‘ISP’ CiscoISR#configure terminal Enter configuration commands, one per line. End with CNTL/Z. CiscoISR(config)#exit CiscoISR#ping www.ciscopress.com Translating “www.ciscopress.com”...domain server (206.248.154.22) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.202.161.68, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/52/56 ms Everything works great up to now, but then the ISP user tries to execute a command that he is not authorized to execute: CiscoISR#write mem ^ % Invalid input detected at ‘^’ marker. CiscoISR# The show parser view command can be used to verify the views configured on the system: CiscoISR#show parser view all Views/SuperViews Present in System: ISP ———-(*) represent superview———- CiscoISR#
In summary, here are the steps to create a view:
- Enable AAA on the router (if it hasn’t already been enabled): aaa new-model
- Enable the router’s view context: enable view
- Enter global configuration mode: configure terminal
- Create a new view or enter an existing view: parser view view-name
- Assign a password for logging into the view: secret 5 encrypted-passwd (or secret 0 cleartext passwd)
- Specify the commands that can be executed in exec and configure modes: commands (see the examples for syntax of two parser modes)
- Exit from view configuration mode: exit
EXAM ALERT
You should know the following about the enable view command and setting up parser views in general:
- 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.
- 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):
CiscoISR(config) #secure boot-image CiscoISR(config)# 032787: Apr 18 14:08:30.989 NewYork: %IOS_RESILIENCE-5-IMAGE_NOTFOUND: Running image not found on removable disk That didn’t work too well. Let’s try to make a secure copy of the running configuration file: CiscoISR(config) #secure boot-config CiscoISR(config)# 032788: Apr 18 14:09:36.099 NewYork: %IOS_RESILIENCE-5- NO_SUPPORTED_DEVICE: No ATA disk found for storing archives ios resilience:failed to remove chkpt file
NOTE
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:
CiscoISR#show secure bootset %IOS image and configuration resilience is not active
EXAM ALERT
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:
CiscoISR(config) #access-list RA-VPN-Users permit 10.1.1.0 0.0.255 CiscoISR(config) #login quiet-mode access-class RA-VPN-Users
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:
CiscoISR(config) #login delay ? <1-10> Time period in seconds CiscoISR(config) #login delay 1
NOTE
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:
CiscoISR(config) #login on-success log CiscoISR(config) #login on-failure log
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:
CiscoISR#show login A login delay of 1 seconds is applied. Quiet-Mode access list RA-VPN-Users 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 60 seconds or less, logins will be disabled for 120 seconds. Router presently in Normal-Mode. Current Watch Window Time remaining: 57 seconds. Login failures for current window: 0. Total login failures: 0. CiscoISR(config)#
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:
banner motd ^C WARNING: You are connected to $(hostname) $(domain) This system is the property of ABC LLC. UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED. You must have explicit permission to access this device. All activities performed on this device are logged. Any violations of access policy will result in disciplinary action. ^C
NOTE
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.