Using Secure Management and Reporting

Network management and reporting applications help network administrators proactively monitor and configure their network. However, left unsecured, management and reporting traffic can be used by potential attackers to compromise network security. For example, captured management and reporting traffic might contain administrative credentials for logging onto a system. Therefore, this section focuses on securing such traffic types.

Specifically, you will learn about securing syslog, SSH, and SNMPv3. In-band and out-of-band network management will be contrasted, and you will see how Cisco SDM can be used to monitor log messages and enable management features.

Planning for Secure Management and Reporting

Because smaller networks generate a relatively small amount of logging information, as compared to large enterprise networks, collecting and analyzing logging and reporting information poses an increasing challenge as a network grows larger. Similarly, the challenge of configuring network devices, and limiting administrative access to those devices, increases as a network's size increases. When planning for secure management and reporting, consider the following recommendations:

With feedback from network and security team members, determine the most important information to log.

Select appropriate syslog logging levels to collect an appropriate volume of log information.

Secure the transmission and storage of log information to prevent the malicious tampering of the logs.

Use Network Time Protocol (NTP) to synchronize logging time stamps, which aids in event correlation. Preferably, use NTP version 3, to leverage its ability to provide authentication for time updates.

Consult your security policy to determine what log data would be required to provide appropriate evidence for a criminal investigation.

Allocate sufficient storage capacity for anticipated logging demands.

Identify an enterprise management system for managing multiple devices.

Develop a change management plan for tracking configuration changes.

Secure Management and Reporting Architecture

Two primary schools of thought exist about how management traffic should be sent between a management station and a managed device. One approach is to allow management traffic to traverse a production data network. The other approach is to use a separate network to transport management traffic. This approach, where management traffic is isolated from production data traffic, is called out-of-band (OOB) management.

Obviously, allowing management traffic on a production network poses a security risk. Therefore, Cisco recommends that management traffic usually be relegated to a separate network, in an OOB management configuration. However, design constraints might necessitate situations in which management traffic must flow over a production network.

When such a requirement exists, you should take precautions to further secure the management traffic.

NOTE Even though OOB management is usually preferred over in-band management, some management applications benefit from in-band management. For example, consider a network management application that checks the reachability of various hosts and subnets. To check this reachability, an application might send a series of pings to a remote IP address, or check the availability of various Layer 4 services on a remote host. To perform these "availability" checks, the network management application needs to send traffic across a production data network. Also, in-band network management often offers a more economic solution for smaller networks.

Figure 5-7 illustrates a network using both in-band and OOB management approaches.

Figure 5-7 Network Using In-Band and Out-of-Band Management

SNMPv3 Server

NTPv3 Server

Syslog Server

AAA Server

Figure 5-7 Network Using In-Band and Out-of-Band Management

SNMPv3 Server

NTPv3 Server

Syslog Server

AAA Server

Access

In-Band Network Management

IPsec-Protected Tunnel

Access

In-Band Network Management

Out-of-Band (OOB) Network Management

Switch

Switch

To an Isolated Out-of-Band (OOB) Management Network

Notice the following characteristics of this mixed-management-style network:

■ Even though the servers (that is, the NTP, syslog, AAA, and SNMPv3 servers) are attached to the same Cisco Catalyst switch, they are isolated from one another through the use of private VLANs (PVLAN). Using PVLANs, if an attacker compromised one of the servers, he would be unable to use that server to obtain access to another server.

■ The IOS router running the Firewall Feature Set supports configuration via Secure Shell (SSH) and Secure HTTP (HTTPS), both of which provide encryption for management traffic.

■ Any management traffic coming from an untrusted network (the Internet in the figure) is sent via an IPsec-protected tunnel. Additionally, you should use ACLs to limit what devices (or subnets) are allowed to initiate an IPsec tunnel with the IOS router. If an IPsec tunnel is unfeasible, consider another secure method of transport, such as Secure Sockets Layer (SSL).

■ SNMP is being used in the network. Specifically, SNMPv3 is used because of its encryption and authentication features.

■ The network contains three managed routers that are connected to a router acting as a terminal server. This terminal server provides asynchronous connectivity to the console ports of the managed routers. Because the router acting as a terminal server is part of the production network, access to that router should be protected via an access class, which determines which IP addresses, or subnets, are allowed to administratively connect to the router. Also, the access should be via SSH, as opposed to Telnet, because Telnet does not encrypt traffic.

■ Although not illustrated in its entirety, the figure indicates that managed devices are also accessible for management purposes over a separate OOB management network.

■ A AAA server is provided to give a centralized location for authentication, authorization, and accounting functions for administrative access to managed devices.

■ A syslog server is used to store log information from the managed devices. Access to the syslog server should be limited (using VLAN ACLs [VACL] and ACLs) to specified managed devices.

■ A Network Time Protocol (NTP) server is used to synchronize the time on the managed devices. Time synchronization is critical for event correlation purposes. For example, after an attack, an administrator might examine log messages stored on a syslog server. To map out the sequence of events that occurred during the attack, the devices involved need a common clock so that they can appropriately time stamp their syslog messages. Sometimes, attackers can send invalid NTP traffic as part of their attack. Incorrect NTP information can cause valid digital certificates to appear invalid or can cause the routers to incorrectly time stamp syslog messages. Fortunately, the network shown in Figure 5-7 uses NTPv3, which supports cryptographic authentication between NTP peers, helping mitigate NTP attacks.

Keep in mind that some networks might require unsecured protocols to be used from time to time. For example, TFTP occasionally might be required to update a router's IOS image. Consider allowing such unsecured applications on an as-needed basis, in which you configure permissions for the application when required and then remove the permissions after the application finishes.

Configuring Syslog Support

Administrators analyze router logs, in addition to logs from other network devices, for a variety of reasons. For example, log information can provide insight into the nature of an attack. Log information can be used for troubleshooting purposes. Viewing logs from multiple devices can provide event correlation information (that is, the relationship between events occurring on different systems).

Cisco IOS routers can send log output to a variety of destinations:

■ Console: A router's console port can send log messages to an attached terminal.

■ Vty lines: Virtual tty (vty) connections (such as Telnet connections) can also send log information to a remote terminal (such as a Telnet client). However, the terminal monitor command should be issued to cause log messages to be sent out of a vty line.

■ Buffer: When log messages are sent to a console or a vty line, those messages are not later available for detailed analysis. However, log messages can be stored in router memory. This "buffer" area can store messages until a router is rebooted.

■ SNMP server: When configured to run an SNMP agent, a router can send log messages, in the form of SNMP traps, to an SNMP server. Although this approach to logging can preserve log messages for an extended time, considerable setup and configuration are required.

■ Syslog server: A very popular choice for storing log information is a syslog server, which is easily configured and can store a large volume of logs.

A syslog logging solution consists of two primary components: syslog servers and syslog clients. A syslog server receives and stores log messages sent from syslog clients. As shown in Figure 5-8, various types of network devices can act as syslog clients and send logging information to a syslog server.

Figure 5-8 Syslog System

Firewall

Syslog Server

Syslog Messages

Syslog Messages

Switch

Router

Not all syslog messages are created equal. Specifically, they have different levels of severity. Table 5-4 lists the eight levels of syslog messages. The higher the syslog level, the more detailed the logs. Keep in mind that more-detailed logs require additional storage space, and also consider that syslog messages are transmitted in clear text.

— Table 5-4 Syslog Severity Levels

Level

Name

Description

0

Emergencies

The most severe error conditions, which render the system unusable

1

Alerts

Conditions requiring immediate attention

2

Critical

A less severe condition as compared to alerts, which should be addressed to prevent an interruption of service

3

Errors

Notifications about error conditions within the system that do not render the system unusable

4

Warnings

Notifications that specific operations failed to complete successfully

5

Notifications

Nonerror notifications that alert an administrator about state changes within a system

6

Informational

Detailed information about the normal operation of the system

7

Debugging

Highly detailed information (for example, information about individual packets) that is typically used for troubleshooting purposes

Consider the format of a syslog message, as illustrated in Figure 5-9. The syslog log entries contain time stamps, which are helpful in understanding how one log message relates to another. The log entries include severity level information in addition to the text of the syslog messages.

Figure 5-9 Structure of a Syslog Message

pysHir"1"1111'

n 8.2.1B)

EMM

1 " 0 £¡3 A Display DD (Default] v|

Dale Time Priority Hostname M es sane A

11-20-2007 20: ( 11-20-2007 20: (

13:50 Local7.lnfo 132.168.0.29 30: "Mar 1 00:06 36.103: ZS' 13:49 Loca(7.Notice 192.168.0.29 29: 'Mai 1 00:06:35.099: %S'

l'S-6-LO G Gl N GH □ S T_STAR T STO P: Logging to host i"S-5-C0NFIG_l: Configured fiom console bji vlyO |19

192.168.0.95 started - CLI initiated 2.168.0.95)

I

1

100ÍÍ 2 MPH

20:06 11-20-2007 |

Time Stamps Names of Log Text of syslog Messages

Message and Severity Levels

Time Stamps Names of Log Text of syslog Messages

Message and Severity Levels

NOTE A variety of systems can be used to act as a syslog server (for example, a CiscoWorks server). In Figure 5-9, the Kiwi Syslog Daemon is used. This freeware utility can be downloaded from http://www.kiwisyslog.com/kiwi-syslog-daemon-download.

Syslog messages can also be viewed from within Cisco SDM. As shown in Figure 5-10, you click the Monitor button along the top of the Cisco SDM window, and then click the Logging button in the Tasks pane, to view a variety of router logs, including syslog messages.

Figure 5-10 Cisco SDM's Logging Window

Monitor Menu Button

Monitor Menu Button

Figure 5-10 Cisco SDM's Logging Window

Logging Button

As shown in Figure 5-11, you can drop down the Select a Logging level to view menu and filter the logs displayed based on their severity level. After you select an appropriate severity level, click the Update button to display all syslog messages with a severity level greater than or equal to the severity level you selected. The log messages are displayed in a pane at the bottom of the Cisco SDM interface, in columnar format, showing the severity level, time-stamp information, and a description of each syslog message.

Figure 5-11 Filtering Syslog Messages by Severity Level

Specify Logging Level

Figure 5-11 Filtering Syslog Messages by Severity Level

Specify Logging Level

Update Button Displays syslog Messages with the Specified Severity Level

Securing Management Traffic with SNMPv3

The first Request for Comments (RFC) for SNMP came out in 1988. Since then, SNMP has become the de facto standard for network management protocols. The original intent of SNMP was for it to manage network nodes, such as network servers, routers, switches, and hubs. SNMP version 1 (SNMPv1) and SNMP version 2c (SNMPv2c) specify three major components of an SNMP solution, as detailed in Table 5-5.

Table 5-5 Components of an SNMPvl and SNMPv2c Network Management Solution

Component

Description

SNMP manager

An SNMP manager runs a network management application. This SNMP manager is sometimes called a Network Management Server (NMS).

SNMP agent

An SNMP agent is a piece of software that runs on a managed device (such as a server, router, or switch).

Management Information Base (MIB)

Information about a managed device's resources and activity is defined by a series of objects. The structure of these management objects is defined by a managed device's MIB.

As shown in Figure 5-12, an SNMP manager (that is, an NMS) can send information to, receive request information from, or receive unsolicited information from a managed device (a managed router in this example). The managed device runs an SNMP agent and contains the MIB.

Figure 5-12 SNMPvl and SNMPv2c Network Management Components and Messages

Manager Agent and Management

Information Base (MIB)

SNMP Trap

Network _SNMP Get Managed

Management SNMP Set Router

Station (NMS)

Even though multiple SNMP messages might be sent between an SNMP manager and a managed device, consider the three broad categories of SNMP message types:

■ GET: An SNMP GET message is used to retrieve information from a managed device.

■ SET: An SNMP SET message is used to set a variable in a managed device or to trigger an action on a managed device.

■ Trap: An SNMP trap message is an unsolicited message sent from a managed device to an SNMP manager. It can be used to notify the SNMP manager about a significant event that occurred on the managed device.

Unfortunately, the ability to get information from or send configuration information to a managed device poses a potential security vulnerability. Specifically, if an attacker introduced a rogue NMS into the network, the attacker's NMS might be able to gather information about network resources by polling the MIBs of managed devices.

Additionally, the attacker could launch an attack against the network by manipulating the configuration of managed devices by sending a series of SNMP SET messages.

Although SNMP does offer some security against such an attack, the security integrated with SNMPvl and SNMPv2c is considered weak. Specifically, SNMPvl and SNMPv2c use community strings to gain read-only access and/or read-write access to a managed device. You can think of a community string much like a password. Also, be aware that multiple SNMP-compliant devices on the market today have a default read-only community string of "public" and a default read-write community string of "private."

NOTE Notice that this section refers to SNMPv2c as opposed to SNMPv2. SNMPv2 did contain security enhancements, in addition to other performance enhancements. However, few network administrators adopted SNMPv2 because of the complexity of the newly proposed security system. Instead, Community-Based Simple Network Management Protocol version 2 (SNMPv2c) gained widespread acceptance because it included the performance enhancements of SNMPv2 without using SNMPv2's complex security solution. Instead, SNMPv2c kept the SNMPvl concept of community strings.

Fortunately, the security weaknesses of SNMPvl and SNMPv2c are addressed in SNMPv3.

To better understand these security enhancements, consider the concept of a security model and a security level:

■ Security model: A security model defines an approach for user and group authentications. Cisco IOS supports the SNMPvl, SNMPv2c, and SNMPv3 security [ Topic models.

■ Security level: A security level defines the type of security algorithm performed on SNMP packets. Three security levels are discussed here:

— noAuthNoPriv: The noAuthNoPriv (no authorization, no privacy) security level uses community strings for authorization and does not use encryption to provide privacy.

— authNoPriv: The authNoPriv (authorization, no privacy) security level provides authorization using Hashed Message Authentication Code (HMAC) with Message Digest 5 (MD5) or Secure Hash Algorithm (SHA). However, no encryption is used.

— authPriv: The authPriv (authorization, privacy) security level offers HMAC MD5 or SHA authentication and also provides privacy through encryption. Specifically, the encryption uses the Cipher Block Chaining (CBC) Data Encryption Standard (DES) (DES-56) algorithm.

As summarized in Table 5-6, SNMPv3 supports all three of the previously described security levels. Notice that SNMPvl and SNMPv2 support only the noAuthNoPriv security level.

..■•— Table 5-6 Security Models and Security Levels Supported by Cisco IOS

..■•— Table 5-6 Security Models and Security Levels Supported by Cisco IOS

Security Model

Security Level

Authentication Strategy

Encryption Type

SNMPvl

noAuthNoPriv

Community String

None

SNMPv2c

noAuthNoPriv

Community String

None

SNMPv3

noAuthNoPriv

Username

None

authNoPriv

MD5 or SHA

None

authPriv

MD5 or SHA

CBC-DES (DES-56)

Through the use of the security algorithms, as shown in Table 5-6, SNMPv3 dramatically increases the security of network management traffic as compared to SNMPvl and SNMPv2c. Specifically, SNMPv3 offers three primary security enhancements:

■ Integrity: Using hashing algorithms, SNMPv3 can ensure that an SNMP message was not modified in transit.

■ Authentication: Hashing allows SNMPv3 to validate the source of an SNMP

message.

■ Encryption: Using the CBC-DES (DES-56) encryption algorithm, SNMPv3 provides privacy for SNMP messages, making them unreadable by an attacker who might capture an SNMP packet.

In addition to its security enhancements, SNMPv3 differs architecturally from SNMPvl and SNMPv2c. SNMPv3 defines SNMP entities, which are groupings of individual SNMP components. As shown in Figure 5-13, SNMP applications and an SNMP manager combine into an NMS SNMP entity, and an SNMP agent and a MIB combine into a managed node SNMP entity.

Figure B-1S SNMPv3 Entities

Network Management Station (NMS)

Network Management Station (NMS)

Managed Router

Managed Node SNMP Entity

Enabling Secure Shell on a Router

When administrators remotely connect to a router to perform configuration, monitoring, and troubleshooting tasks, Cisco recommends that the administrators connect using Secure Shell (SSH), as opposed to using Telnet. Telnet is not considered secure, and the contents of the Telnet session are transmitted in clear text. SSH, however, uses encryption to protect transmissions between an administrator's workstation and a router.

NOTE Cisco IOS 12.1(1)T and later support SSH version 1, and SSH version 2 is supported in Cisco IOS 12.3(4)T and later.

When you configure SSH on a Cisco router, the router acts as an SSH server. You then can use SSH client software (such as PuTTY) to securely connect to the router. Following are the steps required to configure a Cisco IOS router to act as an SSH server:

Step 1 Configure a domain name on your router using the ip domain-name name command in global configuration mode.

Managed Router

Step 2 Use the crypto key generate rsa general-keys modulus modulus-size command in global configuration mode to generate the security keys used by SSH. Cisco recommends that the minimum value for the modulus be 1024 bits.

NOTE After generating the keys, you can issue the show crypto key mypubkey rsa command from privileged EXEC mode to view the generated public key.

Step 3 Specify the SSH timeout (that is, the number of seconds the router waits on the SSH client) with the ip ssh timeout seconds command from global configuration mode.

Step 4 Issue the ip ssh authentication-retries number command from global configuration mode to specify the number of SSH authentication retries before an interface is reset.

Step 5 To prevent Telnet sessions, issue the no transport input telnet command in line configuration mode for all your vty lines.

Step 6 Permit SSH connections using the transport input ssh command, still in line configuration mode, for all your vty lines.

Example 5-2 illustrates the configuration of an SSH server. Notice the use of the crypto key zeroize rsa command issued in global configuration mode. This command can be used to delete any existing RSA keys on a router. Also note that Example 5-2 uses the ip ssh timeout command, as opposed to the ip ssh timeout command previously described. This command varies by IOS version. IOS 12.4(12) is used in the example.

Example 5-2 Enabling SSH R1# conf term

Enter configuration commands, one per line. End with CNTL/Z. R1(config)# ip domain-name ciscopress.com R1(config)# crypto key zeroize rsa

% All RSA keys will be removed.

% All router certs issued using these keys will also be removed. Do you really want to remove these keys? [yes/no]: yes R1(config)#

*Mar 1 01:33:35.455: %SSH-5-DISABLED: SSH 1.99 has been disabled R1(config)# crypto key generate rsa general-keys modulus 1024

The name for the keys will be: R1.ciscopress.com

% The key modulus size is 1024 bits

Example 5-2 Enabling SSH (Continued)

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R1(config)#

*Mar 1 01:34:20.235: %SSH-5-ENABLED: SSH 1.99 has been enabled

R1(config)# ip ssh time-out 120

R1(config)# ip ssh authentication-retries 4

R1(config)# line vty 0 4

R1(config-line)# transport input ssh

R1(config-line)# end

Example 5-3 provides the output of the show crypto key mypubkey rsa command, which displays the generated keys.

Example 5-3 Viewing the Generated Keys R1# show crypto key mypubkey rsa

% Key pair was generated at: 01:34:20 Key name: R1.ciscopress.com Usage: General Purpose Key Key is not exportable. Key Data:

30819F30 0D06092A 864886F7 0D010101 26FDD40C C0CEA5DE 8D4AEC7E 2AB70ECB 29126EC0 522501E3 6AEF0581 BDFF46FC 57A726ED 5E233A92 02F2B5A6 DE10BA2A ED6F7D3F 289FFB3F 8F1F014B 2252BC49 % Key pair was generated at: 01:34:21 Key name: R1.ciscopress.com.server Usage: Encryption Key Key is not exportable. Key Data:

307C300D 06092A86 4886F70D 01010105 33A7D951 93ED5C01 90E3515B B9C23EF6 DC33C7F8 54208F5B 147CAB1E 9B634B69 5C423F7C 903A391A B8970A32 51F7D9EB R1#

Using Cisco SDM to Configure Management Features

Several management features available on Cisco IOS routers (for example, syslog logging, SNMP, NTP, and SSH) can be configured using Cisco SDM's graphical interface. These features, however, are not separate wizards available in the Tasks pane of Cisco SDM. Rather, you can configure these features by clicking the Additional Tasks button in the Tasks pane.

UTC Mar 1 2007

05000381 8D003081 89028181 009C3542 1F5EAC60 1459AA16 0EE4059B FD95C548 1C145B94 6590C7BB 931C1734 0BC90ACE 99D7EC00 2646FC20 39BB4298 55B4DED1 45D27160 0C50AC02 E51B1C1A 9F020301 0001 UTC Mar 1 2007

00036B00 30680261 00D811FD 3CF9D04F 268E638F 868D2AD2 3A7722BC 52DF0CAF 4D44F556 43482BB5 7B3A447B 397F6E7E 91FBE954 D7AEC02D 31020301 0001

Configuring Syslog Logging with Cisco SDM

The following steps describe how to configure syslog logging using Cisco SDM:

Step 1 Click the Configure button, near the top of the Cisco SDM window, and then click the Additional Tasks button in the Tasks pane, as shown in Figure 5-14.

Figure 5-14 Accessing the Additional Tasks Screen in Cisco SDM

Configure Menu Button

Figure 5-14 Accessing the Additional Tasks Screen in Cisco SDM

Configure Menu Button

Additional Tasks Button

Step 2 Click the + next to Router Properties to expand the selection, and then click the Logging option, as shown in Figure 5-15.

Figure 5-15 Accessing the Logging Configuration Screen

Logging Option

Router Properties

Figure 5-15 Accessing the Logging Configuration Screen

Logging Option

Router Properties

Additional Tasks Button

Step 3 In the Logging configuration screen, click the Edit button in the upper-right corner of the Cisco SDM screen to open a separate Logging window, shown in Figure 5-16.

Figure 5-16 Opening the Logging Editing Window

Open an Add Logging Host Dialog Box

Figure 5-16 Opening the Logging Editing Window

Open an Add Logging Host Dialog Box

Step 4 Click the Add button to open the Add logging host window. Use the dialog box in this window to enter the IP address or hostname of your syslog server, as shown in Figure 5-17. Then click OK to close this window.

Figure B-17 Adding a Syslog Server

IP Address of syslog

Server

IP Address of syslog

Server

Step 5 After you return to the Logging window, you can optionally select the level of severity for the messages you want to log, using the Logging Level drop-down menu shown in Figure 5-18. When your configuration is complete, click the OK button.

Figure 5-18 Specifying a Logging Level

Figure 5-18 Specifying a Logging Level

Select Message Severity Level

Configuring SNMP with Cisco SDM

The following steps explain how to enable a Cisco IOS router for SNMP using Cisco SDM:

Step 1 Expand the Router Properties option available in the Additional Tasks window as previously described. Then click the SNMP option, as shown in Figure 5-19. To enable and configure SNMP, click the Edit button in the upper-right corner of the Cisco SDM screen.

Figure

Step 2 From the SNMP Properties window, click the Enable SNMP checkbox, as shown in Figure 5-20. Then click the Add button in the Password area of the window to open the Add a Community String window. Enter a community string to be used as your password, and click either the ReadOnly or Read-Write radio button to specify the privilege level accessible with this community string. Click the OK button when you are finished. You might want to add both a read-only and read-write community string.

5-19 Accessing the SNMP Configuration Screen

SNMP Option

SNMP Option

Figure 5-20 Enabling SNMP

Check to Enable SNMP

Community String

Type of Community String

Figure 5-20 Enabling SNMP

Check to Enable SNMP

Community String

Type of Community String

Step 3 After adding the community string(s), click the Add button in the Trap receiver area of the SNMP Properties window, as shown in Figure 5-21. Enter the IP address or hostname of the SNMP server and a corresponding password. When you are finished, click the OK button.

Figure 5-21 Configuring a Trap Receiver

Figure 5-21 Configuring a Trap Receiver

Click to Confirm Entries

SNMP Server's Password

Open Add a Trap Receiver Dialog Box

Click to Confirm Entries

SNMP Server's Password

Open Add a Trap Receiver Dialog Box

Step 4 You can optionally enter location and contact information for the SNMP server, as shown in Figure 5-22. Click the OK button when you are finished entering this information.

Figure 5-22 Entering Location and Contact Information

Figure 5-22 Entering Location and Contact Information

Click to Confirm Entries SNMP Server Configuration Area

Configuring NTP with Cisco SDM

As a best practice, you should synchronize the time on your routers using NTP. For example, having your router clocks in sync allows you to better identify and correlate events by viewing syslog messages. The following steps explain how to enable a Cisco IOS router for NTP using Cisco SDM:

Step 1

Expand the Router Properties option available in the Additional Tasks window as previously described. Then click the NTP/SNTP option, as shown in Figure 5-23.

Figure 5-23 Accessing the NTP Configuration Screen NTP/SNTP Option

Figure 5-23 Accessing the NTP Configuration Screen NTP/SNTP Option

Step 2 Click the Add button to bring up the Add NTP Server Details window, as shown in Figure 5-24. From this window you can specify the IP address or hostname of the NTP server and select the router interface that is used to connect to the NTP server. If you configure more than one NTP server, you can use the Prefer checkbox to indicate which server is the preferred server. Optionally, you can check the Authentication Key checkbox to provide information used to secure your NTP communication. When you are finished, click OK.

Figure B-24 Adding an NTP Server

Check to Indicate One NTP Server Is Preferred Over Another One

IP Address of NTP Server

Open the Add NTP Server Details Dialog Box

IP Address of NTP Server

Open the Add NTP Server Details Dialog Box

Interface Used to Receive NTP Information Click to Confirm Entries

Configuring SSH with Cisco SDM

As discussed earlier, using SSH to access a router prompt is preferred to using Telnet, because Telnet uses clear text, whereas SSH provides encryption. Although you can enable SSH on a router using the CLI, as previously demonstrated in Example 5-2, Cisco SDM can alternatively be used to enable SSH. The following steps show you how to enable a Cisco IOS router for SSH using Cisco SDM:

Step 1 Navigate to the Additional Tasks window as previously described. Then doubleclick the Router Access option to expand it, as shown in Figure 5-25.

Figure 5-25 Navigating to the Router Access Option

Router Access Option

Cisco Router and Security Device Manag

ir (SDM): 192.168.0.29 Q®®

I File Edit View Tools Help

I

Home

S| Configure jg)

Refresh Save Search Help CISCO

Tasks

S0 Additional Tasks

EN'S Router Properties T

\ User AccountsMew 'VTY

i Management Access _ ISSH Secure Device Provisioning 0-Q DHCP -f^DNS

-g|[ Dynamic DNS Methods 0-Q ACL Editor —ff Port to Application Mappings 0-QS URL Filtering

-fP Local Pools ® Router Provisioning 0-Q Configuration Management

You can control access to the router by setting up individual user accounts, and configuring VTY lines forthe telnet and SSH protocols. You can also configure management access policies that specify the protocols that can be used to connect to the router and that specify the hosts that can be used to manage it

User Accounts Configuration

Configure user accounts to specify which users can access the router. Vou can also associate user accounts with Access control views, which define the SDM features available to the user.

VTY Line Configuration

VTY line configuration defines how the router command line interface is accessed remotely. You can specify that telnet and/or SSH protocols be used over a VTY line.You can also associate an access control list with a VTY line.

You can activate Secure Shell (SSH) by creating an RSA key which will be used to encrypt data travelling between the management host and the router.

Management Access

Create policies that control access to the router on a network and protocol basis. You can define trusted hosts and subnetworks from which the router can be managed, specify which protocols can be used to manage the router, and specify the interfaces through which the router can be managed. When you create a policy, user accounts and VTY line configurations may be modified to eliminate conflicts.

Configuration delivered to router.

04:55:59 UTC Fri Mar 01 2002

Step 2 Click the SSH option. If the router is not already configured for SSH, you see a Generate RSA Key button, as shown in Figure 5-26.

Figure 5-26 Accessing the SSH Configuration Screen

SSH Option

Click to Create RSA Key

Figure 5-26 Accessing the SSH Configuration Screen

SSH Option

Click to Create RSA Key

Step 3 Click the Generate RSA Key button to begin the key generation process. After clicking the button, you see the Key modulus size window, as shown in Figure 5-27. Cisco recommends that you specify a value of at least 1024 bits for this field. However, if you enter a value in the range 512 to 1024, the value must be a multiple of 64. If you want to use a value greater than 1024, you can select either 1536 or 2048. After entering your desired modulus size, click the OK button.

Figure 5-27 Setting the Modulus Size

Figure 5-27 Setting the Modulus Size

Click to Confirm Entry

Specify Size of Key Modulus in Bits

NOTE To successfully generate an RSA key, a router first must have been configured with a domain name. You can configure a router's domain name by clicking the Edit button in the Router Properties configuration screen, which is available from the previously described Additional Tasks window.

Step 4 You are prompted to enter your SSH username and password credentials, as shown in Figure 5-28. After entering the appropriate credentials, click OK.

Figure 5-28 Providing SSH Username and Password Credentials

Figure 5-28 Providing SSH Username and Password Credentials

SSH Credentials

Click to Confirm Entries

0 0

Post a comment