Configuring SSH Access

While Telnet can certainly be used to manage a router, this remote access technology transmits everything in clear text, making it unsuitable in today’s environments. For this reason, you should always use Secure Shell (SSH) for secure remote access. The SSH server on the router will require an RSA public/private key pair to use in the process of encrypting the traffic. It can generate this key pair but must have certain information configured before it can do so because it uses this information as the label for the key pair.

Therefore, the high-level steps to set up SSH are as follows:

1. Set the router name.
2. Set the router domain name.
3. Generate the RSA key.

Here are the actual commands:

Router(config)#hostname R63
R63(config)#ip domain-name mcmillan.com
R63(config)#crypto key generate rsa ?
  encryption    Generate a general purpose RSA key pair for signing and
                encryption
  exportable    Allow the key to be exported
  general-keys  Generate a general purpose RSA key pair for signing and
                encryption
  label         Provide a label
  modulus       Provide number of modulus bits on the command line
  on            create key on specified device.
  redundancy    Allow the key to be synced to high-availability peer
  signature     Generate a general purpose RSA key pair for signing and
                encryption
  storage       Store key on specified device
  usage-keys    Generate separate RSA key pairs for signing and encryption
  

R63(config)#crypto key generate rsa modulus 1024
The name for the keys will be: R63.mcmillan.com
 
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 2 seconds)
 
R63(config)#
*Mar 28 18:32:09.095: %SSH-5-ENABLED: SSH 1.99 has been enabled

In these steps, you can see I created a name, R63; set the domain name to mcmillan.com; and generated a key. The modulus keyword I used sets the length of the key, which in this case is 1,024 bits. Notice the syslog message that indicates SSH version 1.99 has been enabled. This indicates it is a version 2 server, which can accept connections from SSH version 1 devices.

Next you need to do the following:

1. Create a username and password for each user who needs SSH access.
2. Configure line vty to only accept SSH connections.

R63(config)#username troy secret mac
R63(config)#line vty ?
  <0-1114>  First Line number
 
R63(config)#line vty 0 1114
R63(config-line)#login local
R63(config-line)#transport input ssh
R63(config-line)#

Notice that I created a user named troy with a password of mac. You can create a single account to be shared by all authorized technicians and name it something like admin, or you can create separate accounts for each user. Separate accounts will provide accountability.

Also notice that when I entered line vty mode, I checked to see how many vty lines this device has so that when I run the command to enter that mode, the commands I apply will apply to all lines. The command login local tells the router that all user accounts will be found locally on this router and not on a remote server. That’s why I needed to create the local account that I did. Finally, I set the router to only accept SSH connections with the last command.

Configuring Privilege Levels in IOS

Privilege levels allow you to assign a technician sets of activities that coincide with the level the technician has been assigned. There are 16 levels, from 0 to 15. When you are in user mode (router>), you are at Privilege level 1. When you are in privileged mode (router#), you are at level 15.

You can assign levels between 0 and 15, and by linking these levels with commands, you can control the activities of each technician. This can be done on both IOS devices and on the Cisco Adaptive Security Appliance (ASA), although the details of each process are slightly different. Privilege levels are created at the global configuration prompt router(config)#. When a level is created, you also add a command at the same time, which means if you are adding multiple commands to the level, you will run the privilege command several times. Once a level is created, access to that level is obtained by entering a password assigned to that level. From a high level, here are the steps required:

1. Create the level and assign a command to that level.
2. Assign any additional commands to the level.
3. Set a password for the level.
4. Provide the level number and password to the technician (or technicians) who will use it.

First I will create a level numbered 12, and I will assign the show interfaces command to it. Notice that when I do this, I have to assign the command to the level where it is usually executed, in this case privilege exec level.

router(config)#privilege exec level 12 show interfaces

To demonstrate how to assign a command that is executed at a different level, I am now going to add the interface configuration command, and since that command is executed normally at the global configuration mode, I will use the configure keyword when I add it.

router(config)#privilege configure level 12 interface

My intent is to allow this technician to change IP addresses on interfaces, so I need to assign him that command. Since the ip command (along with the parameter address) is executed after entering interface configuration mode, I have to reference interface in the command, as shown here:

router(config)#privilege interface level 12 ip

Now I’m ready to assign a password for level 12 that I just created. That is done the same way any enable secret password is created, adding the level to which it applies as shown next (otherwise it will apply to level 15 as it usually does). The password I set is wordpass.

router(config)#enable secret level 12 wordpass

Once I provide the level number and password to the technician, he will use the password to enter the privilege level as shown here, making it possible to use those commands and no others. To verify the application of the level, he can type show privilege as is also shown.

router#enable 12
password:wordpass
router#show privilege 
Current privilege level is 12

If he attempts to use any other commands, he will receive the error message shown here:

router#show run
           ^
%invalid input detected at ‘^’ marker.

Configuring IOS Role-Based CLI

Another option you can use to control the operations of technicians is a role-based CLI. Using this approach, you can create roles, implemented as sets of operations called parser views. The only view that exists by default is called root, which as you would expect allows access to all commands. Access to this view is provided when you submit the enable secret password.

Once a parser view is created, you can permit access to the view with a password. This makes it simple to onboard a new technician by assigning him the role he will play in the network. Every technician granted the role will have the same set of operations available.

From a high level, here are the steps required:

1. Create and name the parser view.
2. Assign a password to the parser view.
3. Assign commands to the parser view.
4. Provide the parser view name and password to technicians in the role.

• First I will create a view called OSPFAdmin.

R63(config)#parser view OSPFAdmin
R63(config-view)#

Notice the prompt has changed, and now any commands I run will affect only this view. At this prompt I can both set a password and assign commands to the view. First I’ll assign a password.

R63(config-view)#secret OSPFp@$$
R63(config-view)#

Now I will assign commands. I won’t assign all commands required to manage OSPF, just enough to show you how it’s done. You must ensure that you have provided all commands required for the role.

R63(config-view)#commands exec include all show
R63(config-view)#commands exec include all debug ip ospf
R63(config-view)#commands exec include all no debug
R63(config-view)#commands exec include all undebug
R63(config-view)#commands configure include router ospf

I have allowed access in exec mode to all show commands and to the debug ip ospf commands required. Then I allowed access to the router ospf command, which will include all command within that context. After a technician has been assigned this role, he will access the role using the following commands. Notice that you can verify the application of the role by using the show parser view command.

R63#enable view OSPFAdmin
Password: OSPFp@$$
R63#show parser view
R63#current view is ‘OSPFAdmin’

Implementing Cisco IOS Resilient Configuration

While securing access to the router should be enough to effectively protect the configuration of the router, there is an additional way to prevent unwanted changes to the configuration. The IOS resilient configuration feature can provide a way to easily recover from an attack on the configuration, and it can also help to recover from an even worse attack in which the attacker deletes not only the startup configuration but also the boot image.

The configuration of this feature can be done with two commands. One enables protection of the boot image, and the other enables protection of the startup configuration. To enable protection of the boot image, issue the following command:

R64(config)#secure boot-image
*April 2 14:24:50.231: %IOS_Resilience-5-IMAGE_RESIL_ACTIVE: Successfully secured running  image

Notice the system message indicating the boot image is protected. To enable protection of the startup configuration, issue the following command:

R64(config)#secure boot-config
*April 2 14:24:50.231: %IOS_Resilience-5-CONFIG_RESIL_ACTIVE: Successfully secured config archive [flash: .runcfg-20140131-14259.ar]

Once these two items are secured (called the secure bootset), you cannot update the startup configuration without removing the secure configuration long enough to make the change and then resecuring it as was done in the first place. To remove the secure startup configuration, execute the following command:

R64(config)#no secure boot-config
*April 2 14:34:50.231: %IOS_Resilience-5-CONFIG_RESIL_INACTIVE: Disabled secure config archive [removed flash: .runcfg-20140131-14259.ar]

When finished making changes, execute the secure boot-config command to secure the configuration again.

But what do you do if the worst happens and the startup configuration is deleted? It can be restored, but you must know the location of the secure boot configuration, and you must reference it in the command. To identify its name and location, execute the following command:

R64#show secure bootset
IOS resilience router id FTX1125A67x

IOS image resilience version 12.4 activated at 14:24:50 UTC Mon April 2 2017
Secure archive flash:/c2800nm-advipservicesk9-mz.124-25e.bin type is image (elf) [] Runnable image, entry point 0x8000F000, run from ram
IOS image resilience version 12.4 activated at 14:24:50 UTC Mon April 2 2017
Secure archive flash:.runcfg-20140131-14259.ar type is config
Configuration archive size 4060 bytes

With the location of the secure configurations in hand, now run the following command to restore the configuration:

R64(config)#secure boot-config restore  flash:.runcfg-20140131-14259.ar
ios resilience: configuration successfully restored as flash: .runcfg-20140131-14259.ar

In case you were already wondering what would stop a hacker from using these commands, it is worth knowing that these commands can be run only from the console connection.

Implementing OSPF Routing Update Authentication

OSPF routing updates are secured using a hashing algorithm. You can use either MD5 or SHA-256HMAC. Be aware, however, that some devices may support only MD5. The following are the high-level steps to configuring this:

1. Define a keychain (a keychain can be used to hold multiple keys if required).
2. Define a key by number that will reside on the keychain.
3. Specify the key characters of the key.
4. Specify the hashing algorithm.
5. Apply the keychain to an interface.

In this following example, I’m going to use MD5 for the configuration. I will first configure router R64 and then router R65 on the other end of the link. The first step is to configure the keychain as shown here. The keychain on R64 will be ospf-keys.

R64(config)#key-chain ospf-keys
R64(config-keychain)#

Notice the prompt has changed, and I am now in keychain configuration mode, which is where I will define the key number as follows. The number I am using is 1.

R64(config-keychain)#key 1
R64(config-keychain-key)#

Again, the prompt has changed, and I am in key 1 configuration mode, which is where I define the characters in the key, called the key string. The string I am using is troymac.

R64(config-keychain-key)#key-string troymac
R64(config-keychain-key)#

The next step is to tell the router the algorithm (MD5) to use for this key, which is done at the same key 1 prompt.

R64(config-keychain-key)#cryptographic-algorithm md5
R64(config-keychain-key)#

The final step is to apply the keychain to the interface that connects to router R65.

R64(config-if)#ip ospf authentication key-chain ospf-keys
R64(config-if)#

The configuration can be the same on router R65, but I’m going to change two of the values that do not have to match just to show that they don’t have to match, while keeping the values that do have to match (the key string and the hashing algorithm) the same. The following is the entire set of commands on R65:

R65(config)#key-chain router-keys
R65(config-keychain)#key 2
R65(config-keychain-key)#key-string troymac
R65(config-keychain-key)#cryptographic-algorithm md5
R65(config-keychain-key)#end
R65(config)#int g0/1
R65(config-if)#ip ospf authentication key-chain router-keys

Implementing EIGRP Routing Update Authentication

Configuring EIGRP routing update authentication is similar to OSPF. However, OSPF specifies the hashing algorithms in the same mode where you specify the key string, but in EIGRP you specify that on the interface. The following are the commands for R64 and R65. Additionally, when you specify the algorithm, you specify the EIGRP AS number in the same command. In the following examples, that AS number is 66. Notice that, again, the keychain names and key numbers do not have to match, while the key string and hashing algorithms do have to match.

R64(config)#key-chain router-keys
R64(config-keychain)#key 1
R64(config-keychain-key)#key-string troymac
R64(config-keychain-key)#end
R64(config)#int g0/2
R64(config-if)#ip authentication key-chain router-keys
R64(config-if)#up authentication mode eigrp 66 md5

R65(config)#key-chain EIGRP-keys
R65(config-keychain)#key 2
R65(config-keychain-key)# key-string troymac
R65(config-keychain-key)#end
R65(config)#int g0/1
R65(config-if)#ip authentication key-chain EIGRP-keys
R65(config-if)#ip authentication mode eigrp 66 md5

Control Plane Policing

Control plane policing (CoPP) is a Cisco IOS feature that can be implemented to prevent these issues. Its implementation is an advanced topic not covered in the exam objectives; however, an understanding of its use is included in the exam objectives.

CoPP treats the control plane as a stand-alone entity with its own ingress and egress ports. It allows for the implementation of controls at the ingress port to the control plane. Figure 4.1 shows the relationship between those control plane ingress and egress ports and the physical interfaces. It also shows the paths taken by the four types of traffic discussed in the previous section.

Notice that three types of traffic can be controlled by CoPP, that is, management, control, and services traffic. Also notice that when access control lists (ACLs) are applied to the ingress physical interface and CoPP has also been applied, CoPP comes into play only for traffic that was allowed through the ingress physical interface ACL. As you can see, ultimately CoPP is designed to protect the route processor. Controls can be implemented that allow and disallow certain types of traffic and can also be used to rate-limit the traffic so as to prevent a DoS attack.

When CoPP is configured, the configuration follows the Cisco Modular QoS CLI (MQC). In this model, three mechanisms are used.

Class Maps Used to categorize traffic types into classes. ACLs are typically used to define the traffic, and then the ACL is referenced in the class map.

Policy Maps Used to define the action to be taken for a particular class. Actions that can be specified are allow, block, and rate-limit.

Service Policies Used to specify where the policy map should be implemented.

Figure 4.2 shows the relationship between these mechanisms.

This framework is used for other features as well, such as QoS and traffic shaping.