CISCO CCNA SECURITY EXAM OBJECTIVES COVERED IN THIS CHAPTER:

•  2.1 Secure management
  • Compare in-band and out-of-band
  • Configure secure network management
  • Configure and verify secure access through SNMP v3 using an ACL
  • Configure and verify security for NTP
  • Use SCP for file transfer

 Controlling access to the management interface of a router or switch is critical to ensuring that there is no unauthorized access that can introduce malicious changes to the configuration of the device. Moreover, when network management and time synchronization protocols such as SMTP and NTP are in use, access to this information must be secured. Finally, as a technician, you should use secure protocols when performing file transfers. This chapter will cover all of these secure management topics.

In this chapter, you will learn the following:

• Comparing in-band and out-of-band
• Configuring secure network management
• Configuring and verifying secure access through SNMP v3 using an ACL
• Configuring and verifying security for NTP
• Using SCP for file transfer

In-Band and Out-of-Band Management

Many options are available to connect to a Cisco device for managing the device. Methods can be classified as either in-band or out-of-band. An in-band connection is one that uses the network as its transmission medium. In-band connection types include SNMP, virtual terminal (VTY), and HTTPS connections. Out-of-band connections include the console port and the AUX port, both physical connections that do not use the network as the transmission medium. It is good practice to have both in-band and out-of-band methods available for redundancy.

R1#show line
   Tty Typ    Tx/Rx    A Modem Roty AccO AccI  Uses  Noise  Overruns  Int
*    0 CTY                  -    -     -    -    -     0      0     0/0      -
    65 AUX  9600/9600  -    -     -    -    -    0     1     0/0             -
    66 VTY                  -    -     -    -    -     0      0     0/0      -
    67 VTY                  -    -     -    -    -     0      0     0/0      -

R1# conf t
R1(config)# line 65
R1(config-line)#modem inout
R1(config-line)#speed 115200
R1(config-line)#transport input all
R1(config-line)#flowcontrol hardware
R1(config-line)#login
R1(config-line)#password cisco
R1(config-line)#end

R1(config)# int loopback0
R1(config-if)#ip address 192.168.5.5 255.255.255.0
R1(config-if)#no shut

R1(config)#router eigrp 10
R1(config-rtr)#network 192.168.5.0 0.255.255.255
R1(config)#router ospf 1
R1(config-rtr)#network 192.168.5.0 0.255.255.255

R1(config)#line vty ?
R1(c0nfig)#line vty <0 15>

R1(config)#line vty 0 15
R1(config-line)#password cisco
R1(config-line)#login

SNMP

Another option for configuration management is SNMP. As with other methods that use the network as a transmission medium, it is also considered an in-band method. SMTP stores the settings in a MIB. This is a repository with a hierarchical structure with standardized locations for each piece of configuration or status information. These locations and their associated data are called OIDs. The OID number describes the path through the tree-like structure where the specific piece of information is located. Figure 8.1 shows a portion of the MIB. An example of an OID would be 1.3.6.1.2.1.1.5 (system name), which would be one of the subsections of sysDescr (1.3.6.2.1.1).

Notice also that there is a private branch in the tree where vendors can include settings and status information that might be unique to their products. Therefore, the path to Cisco-specific data is 1.3.6.1.4.1.9. Access to information stored by an individual device is done using get or set commands, while referencing the OID. get commands retrieve information, while set commands make configuration changes to IODs that can be changed. SNMP also allows for the creation of traps on devices, which can trigger a message to the management station when a threshold is met or an event occurs. In SMTP version 2, these trap messages are called informs.

SNMP has undergone three version changes over the years. Versions 1 and 2 used the knowledge of a community string as the access control mechanism to the MIBs of the devices. As this is quite a flimsy security system, version 3 adopted a user-based security model that provides for authentication, integrity hashing, and encryption of transmissions. These functions can be configured using three modes that represent various combinations of these capabilities.

• noAuthNoPriv: No hashing to secure authentication or encryption of data (referenced as noauth in the command)
• AuthNoPriv: Hashing to secure authentication but no encryption of data (referenced as auth in the command)
• AuthPriv: Hashing to secure authentication and encryption of data (referenced as priv in the command)

Later in this chapter, you will learn how to configure SNMPv3.

R83(config)line console 0
R83(config-line)#password cisco
R83(config-line)#login

Securing Network Management

Regardless of the interface with which you manage a Cisco device, you should ensure that the method used is secure. In this section, you’ll look at securing VTY ports and HTTP connections and using ACLs as a further line of defense in protecting these critical management interfaces. Finally, I’ll discuss banner messages and the role they can play in securing management interfaces.

R81(config)#no ip http server
R81(config)#ip https secure-server
R81(config)#copy run start

R84(config)#access-list 99 permit 192.168.5.0 0.0.0.255

R84(config)#snmp-server group test-group v3 priv write write-view access 99

R84(config)#snmp-server user nms-user nms-group v3 auth sha auth-pass priv aes 128 priv-pass 99

R85(config)#banner motd '
Enter text message , End with character '''
We will be down for 2 hours at 12 PM.'

R85(config)#banner exec '
Enter text message, End with character '''
This is your last chance to leave if you are unauthorized.'

R85(config)#banner login '
Enter text message, End with character '''
This is your first chance to leave if you are unauthorized.'

R86#telnet 10.10.10.10
Trying 10.10.10.10 ... Open
We will be down for 2 hours at 12 PM
This is your first chance to leave if you are unauthorized
Username:Admin
Password: <hidden>
This is your last chance to leave if you are unauthorized

Securing Access through SNMP v3

Configuring SNMP requires you to set an engine ID for any device used to manage SNMP. This is an ID number composed of 24 hex characters. When inform messages are sent to stations, it is the engine ID that identifies the station. It is entered as a 12-character string. Setting the SNMPv3 engine ID for the management station on a router is done as follows:

R82(config)#snmp-server engineID local 000010000203

Once the engine ID has been defined, the high-level steps to control access to SNMP are as follows:

1. Define an SNMP group and specify the cryptographic policy to be used by the group. In this same command, you can assign an MIB view.
2. Define SNMP users and assign them a user group, a view, an authentication hashing algorithm and shared secret, and when used an encryption algorithm.
3. Define SNMP views, each of which will control the information that can be accessed by users who have been assigned the view.
4. Define the SNMP host that will be the recipient of traps. You will also specify in the same command the user account (and the algorithms and keys associated with that account) under whose security context the traps will be sent.

First let’s define an SMTP group named snmp-group, specify version 3, and set it to use the priv security policy and to have read-only access to the view named read-view (to be created in a later step).

R82(config)#snmp-server group snmp-group v3 priv read read-view

Next let’s define an SNMP user named read-user, assign the user to the group snmp-group, set the version as version 3, configure SHA as the authentication algorithm using a shared key of troy-key, and configure 128-bit AES as the encryption algorithm using mac-key as the shared key for AES.

R82(config)#snmp-server user read-user snmp-group v3 auth sha troy-key priv aes 128 mac-key

Now let’s define the view that you referenced in the command creating the group. The view will only allow read access to the OID 1.3.6.1.2.1 and below.

R82(config)#snmp-server view read-view 1.3.6.1.2.1 included

Finally, let’s set the IP address of the management station to which any traps should be sent along with the version number, a cryptographic policy of auth, and a user account named test-user under whose security context the traps will be sent. This is an account you did not create in this example.

R82(config)#snmp-server host 10.10.10.10 version 3 priv test-user

Securing NTP

Synchronization of time among infrastructure devices has become more and more critical to the proper operation of networks. Digital certificates have explicit validity periods, certain Windows operations require strict time synchronization, and analysis of integrated log files becomes a nightmare when the devices from which the log files come have not been synchronized. Moreover, some compliance standards call for strict time synchronization.

While the need to use NTP is without question, network attacks leveraging NTP have appeared that now require you to secure the operation of NTP to prevent such attacks. These attacks can be prevented by configuring NTP authentication. This involves setting a shared secret between the NTP clients and the NTP server that will be used to compute a hash value of the update sent to the client. The client will perform a hash calculation of the update using the same shared key and will compare the results. A match serves as assurance that the update came from the legitimate NTP server. It is important to note that this does not encrypt the update; it only verifies its origin and trustworthiness. Figure 8.2 shows the process.

To configure NTP authentication, the high-level steps (to be performed on both server and client) are as follows:

1. Configure an NTP authentication key number and MD5 string (shared secret).
2. Specify at least one trusted key number referencing the key number in step 1.
3. Enable NTP authentication.

For the first step, let’s configure an NTP key numbered 87 with an associated MD5 string (the shared secret) of mykey on two routers.

R88(config)#ntp authentication-key 87 md5 mykey
 
R89(config)#ntp authentication-key 87 md5 mykey

Now let’s specify the use of key number 87 and its associated MD5 string to be used for NTP authentication.

R88(config)#ntp trusted-key 87
 
R89(config)#ntp trusted-key 87

Finally, all you need do is enable NTP authentication.

R88(config)#ntp authenticate
R89(config)#ntp authenticate

Using SCP for File Transfer

While FTP and TFTP can be used to transfer configurations and IOS images across the network, these protocols lack the ability to encrypt the transmission. A better alternative is Secure Copy Protocol (SCP). This is an implementation of the Remote Copy Protocol (RCP) that operates over an SSH connection. The server that is used to store images and configurations must be configured as an SCP server with a key that can be validated by the Cisco devices. That setup is beyond the scope of this book; however, we will cover the commands to be used on the Cisco devices to perform an SCP transfer.

With the server setup in place, you simply reference the SCP server by URL in the copy command. For example, if the server were named scp-srv and you wanted to copy the running configuration to it under the security context of an account named Admin with a password of mypass, while naming the file R88-config.txt, you would use the following command:

R88#copy run scp://scp-srv/admin:mypass/r88-config.txt

To restore that file to the startup configuration, you would use the following command:

R88#copy scp://scp-srv/admin:mypass/r88-config.txt start

Summary

In this chapter, you learned about the security differences in managing devices from in-band and out-of-band interfaces. You also learned that in-band interfaces include HTTP, VTY, and the physical interfaces on the device and that out-of-band interfaces include the console and AUX ports. The chapter also discussed methods of securing management interfaces including enabling the HTTPS server, securing SNMP v3 with a security policy, applying passwords to all management interfaces, and using SSH for remote management. Among the other topics covered in this chapter were the types of banner message that can be configured and the securing of the NTP protocol.

Exam Essentials

Identify in-band and out-of-band interfaces. In-band interfaces include HTTP, VTY, and the physical interfaces on the device. Out-of-band interfaces include the console and AUX ports.

Describe methods to secure management interfaces. These include disabling the HTTP server and enabling the HTTPS server, securing SNMP v3 with a security policy, applying passwords to all management interfaces, and using SSH for remote management rather than Telnet. It also includes applying ACLs to all management interfaces.

Identify the types of banner messages and their use. These include the message of the day banner, which appears when a connection is made, and login banners, which appear after authentication, after the MOTD and EXEC banners that appear.

List the three security policies that can be applied to SNMPv3. These include AuthNoPriv, which is no hashing to secure authentication or encryption of data; AuthNoPriv, which is hashing to secure authentication but no encryption of data; and AuthPriv, which is hashing to secure authentication and encryption of data.

Describe the steps to configure NTP authentication. These steps are configuring an NTP authentication key number and MD5 string (shared secret), specifying at least one trusted key number referencing the key number in the first step, and enabling NTP authentication.