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
Syslog Server
NTPv3 Server
AAA Server
Figure 5-7 Network Using In-Band and Out-of-Band Management
SNMPv3 Server
Syslog Server
NTPv3 Server
AAA Server
In-Band Network Management with SSH nd HTTPS
Access
IPsec-Protected Tunnel
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:
Key Topic
■ 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.
Topic
■ 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
Figure 5-8 Syslog System
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.
|
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
|
% Kiwi Syslog Daemon (Version B.2.18) |
||||
|
I File Edit View Help |
|Çh |
D5B |
||
|
ib a m A i |
Display 00 [Default] v |
|||
|
I Date T |
ime Priority Hostname Message |
|||
|
11-20-2007 20:03:50 Local7.Info 192.168.0.29 30:'Mai 1 00:06:36.103: XSYS-6-LOG(3IN(3HOST_STARTSTOP: Logging to hosM92.168.0.95 slaited - CLI initialed |
||||
|
11-20-2007 20: [ |
13:49 Local7.Notice 192.168.0.29 29: 'Mai 1 00:06:35.099: 2SV |
l"S-5-CONFIG_I: Configured from console by vlyO [19 |
2.168.0.95) |
|
|
1 |
||||
|
100% 2MPH |
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.
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 (SNMPvl) and SNMP version 2c (SNMPv2c) specify three major components of an SNMP solution, as detailed in Table 5-5.
Specify Logging Level
Specify Logging Level
- Update Button Displays syslog Messages with the Specified Severity Level
|
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). |
|
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 SNMPv1 and SNMPv2c Network Management Components and Messages
Figure 5-12 SNMPv1 and SNMPv2c Network Management Components and Messages
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
**' Koy authentications. Cisco IOS supports the SNMPvl, SNMPv2c, and SNMPv3 security 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.
|
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 SNMPv1 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.
Network Management Station (NMS)
- 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.
Network Management Station (NMS)
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
% 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 |
UTC Mar 1 |
2007 |
||
|
Key name: R1.ciscopress.com |
|||||
|
Usage: General Purpose Key |
|||||
|
Key is not exportable. |
|||||
|
Key Data: |
|||||
|
30819F30 0D06092A 864886F7 |
0D010101 |
05000381 |
8D003081 |
89028181 |
009C3542 |
|
26FDD40C C0CEA5DE 8D4AEC7E |
2AB70ECB |
1F5EAC60 |
1459AA16 |
0EE4059B |
FD95C548 |
|
29126EC0 522501E3 6AEF0581 |
BDFF46FC |
1C145B94 |
6590C7BB |
931C1734 |
0BC90ACE |
|
57A726ED 5E233A92 02F2B5A6 |
DE10BA2A |
99D7EC00 |
2646FC20 |
39BB4298 |
55B4DED1 |
|
ED6F7D3F 289FFB3F 8F1F014B |
2252BC49 |
45D27160 |
0C50AC02 |
E51B1C1A |
9F020301 0001 |
|
% Key pair was generated at: |
01:34:21 |
UTC Mar 1 |
2007 |
||
|
Key name: R1.ciscopress.com.server |
|||||
|
Usage: Encryption Key |
|||||
|
Key is not exportable. |
|||||
|
Key Data: |
|||||
|
307C300D 06092A86 4886F70D |
01010105 |
00036B00 |
30680261 |
00D811FD |
3CF9D04F |
|
33A7D951 93ED5C01 90E3515B |
B9C23EF6 |
268E638F |
868D2AD2 |
3A7722BC |
52DF0CAF |
|
DC33C7F8 54208F5B 147CAB1E |
9B634B69 |
4D44F556 |
43482BB5 |
7B3A447B |
397F6E7E |
|
5C423F7C 903A391A B8970A32 |
51F7D9EB |
91FBE954 |
D7AEC02D |
31020301 |
0001 |
|
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.
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.
Logging Option
Router Properties
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.
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.
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.
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.
- Click to Confirm Entries
SNMP Server's IP Address 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.
NTP/SNTP Option
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 5-24 Adding an NTP Server
Check to Indicate One NTP Server Is Preferred Over Another One
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.
Router Access Option
Router Access Option
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.
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.
SSH Credentials
Click to Confirm Entries
Continue reading here: Defending Against Layer 2 Attacks
Was this article helpful?