Securing the Router
Locking Down the Router
This section begins by identifying router services that are susceptible to attack and by explaining how security can be compromised by various router management services. You will learn two approaches for hardening a Cisco IOS router against attacks:
- Using Cisco SDM’s One-Step Lockdown feature
- Using the auto secure CLI command
Identifying Potentially Vulnerable Router Interfaces and Services
One of the most obvious steps to secure a router is to administratively shut down any unused router interfaces using the shutdown command in interface configuration mode. Another approach to securing a router involves turning off unneeded services.
Fortunately, hardening a router against attack does not require a thorough understanding of how an attacker can compromise router security through specific services. However, you should be acquainted with the services that are potentially running on your router, which might or might not be needed. If a service is not needed, typically it should be disabled to prevent it from inadvertently becoming a security hole. Table 5-2 provides an overview of several services and features available on many Cisco IOS routers.
NOTE SNMP version 1 and SNMP version 2c use community strings for authentication. These community strings, which are often set to a default of “public” (which provides read access) and “private” (which provides read-write access) are sent in clear text, and SNMPv1 and SNMPv2c can easily be spoofed. Therefore, Cisco recommends that SNMP be disabled. However, if SNMP is needed, Cisco recommends using SNMP version 3, which is more secure. Specifically, SNMP version 3 offers authentication, encryption, and access control features.
NOTE Although Cisco SDM supports either HTTP or HTTPS, Cisco recommends using HTTPS, because HTTPS encrypts the data exchanged between a router and the Cisco SDM workstation. For additional security, access to a router’s HTTPS service can be limited by an access control list (ACL), which can restrict the subnet(s) allowed to access a router via HTTPS.
NOTE By default, when a Cisco IOS router sends a DNS name query, the router sends the query to a broadcast address of 255.255.255.255. Attackers could leverage this default behavior by pretending to be a DNS server and responding to the router’s name queries with incorrect information.
Locking Down a Cisco IOS Router
Next, consider how you can follow the Cisco best-practice recommendations for disabling services and further securing a router. Instead of individually enabling or disabling selected services, you can use one of two automated approaches that Cisco offers, as summarized in Table 5-3.
AutoSecure The AutoSecure feature can be enabled from privileged EXEC mode by issuing the auto secure command, as shown in Example 5-1. Example 5-1 Enabling AutoSecure R1# auto secure --- AutoSecure Configuration --- *** AutoSecure configuration enhances the security of the router, but it will not make it absolutely resistant to all security attacks *** AutoSecure will modify the configuration of your device. All configuration changes will be shown. For a detailed explanation of how the configuration changes enhance security and any possible side effects, please refer to Cisco.com for Autosecure documentation. At any prompt you may enter '?' for help. Use ctrl-c to abort this session at any prompt. Gathering information about the router for AutoSecure Is this router connected to internet? [no]: yes Enter the number of interfaces facing the internet [1]: Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.0.29 YES NVRAM up up FastEthernet0/1 172.16.2.1 YES NVRAM up up Serial1/0 172.16.1.1 YES NVRAM up up Serial1/1 unassigned YES NVRAM administratively down down Serial1/2 unassigned YES NVRAM administratively down down Serial1/3 unassigned YES NVRAM administratively down down Enter the interface name that is facing the internet: FastEthernet0/1 Securing Management plane services... Disabling service finger Disabling service pad Disabling udp & tcp small servers Enabling service password encryption Enabling service tcp-keepalives-in Enabling service tcp-keepalives-out Disabling the cdp protocol Disabling the bootp server Disabling the http server Disabling the finger service Disabling source routing Disabling gratuitous arp Here is a sample Security Banner to be shown at every access to device. Modify it to suit your enterprise requirements. Authorized Access only This system is the property of So-&-So-Enterprise. UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED. You must have explicit permission to access this device. All activities performed on this device are logged. Any violations of access policy will result in disciplinary action. Enter the security banner {Put the banner between k and k, where k is any character}: %WA WA RNING: This router is the property of Cisco Press. Any unauthorized access is monitored. Violators will be prosecuted. % Enter the new enable password: Confirm the enable password: Configuring AAA local authentication Configuring Console, Aux and VTY lines for local authentication, exec-timeout, and transport Securing device against Login Attacks Configure the following parameters Blocking Period when Login Attack detected: 30 Maximum Login failures with the device: 3 Maximum time period for crossing the failed login attempts: 1 0 Configure SSH server? [yes]: Enter the domain-name: ciscopress. com Configuring interface specific AutoSecure services Disabling the following ip services on all interfaces: no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply Disabling mop on Ethernet interfaces Securing Forwarding plane services... Enabling CEF (This might impact the memory requirements for your platform) Enabling unicast rpf on all interfaces connected to internet Configure CBAC Firewall feature? [yes/no]: yes This is the configuration generated: no service finger no service pad no service udp-small-servers no service tcp-small-servers service password-encryption service tcp-keepalives-in service tcp-keepalives-out no cdp run no ip bootp server no ip http server no ip finger no ip source-route no ip gratuitous-arps no ip identd banner motd ^C WARNING: This router is the property of Cisco Press. Any unauthorized access is monitored. Violators will be prosecuted. ^C security passwords min-length 6 security authentication failure rate 10 log enable password 7 095F4B0A0B0003022B1F17 aaa new-model authentication login local_auth local line con 0 login authentication local_auth exec-timeout 5 0 transport output telnet line aux 0 login authentication local_auth exec-timeout 10 0 transport output telnet line vty 0 4 login authentication local_auth transport input telnet login block-for 30 attempts 3 within 10 ip domain-name ciscopress.com crypto key generate rsa general-keys modulus 1024 ip ssh time-out 60 ip ssh authentication-retries 2 line vty 0 4 transport input ssh telnet service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone logging facility local2 logging trap debugging service sequence-numbers logging console critical logging buffered interface FastEthernet0/0 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply no mop enabled interface FastEthernet0/1 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply no mop enabled interface Serial1/0 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface Serial1/1 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface Serial1/2 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface Serial1/3 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply ip cef access-list 100 permit udp any any eq bootpc interface FastEthernet0/1 ip verify unicast source reachable-via rx allow-default 100 ip inspect audit-trail ip inspect dns-timeout 7 ip inspect tcp idle-time 14400 ip inspect udp idle-time 1800 ip inspect name autosec_inspect cuseeme timeout 3600 ip inspect name autosec_inspect ftp timeout 3600 ip inspect name autosec_inspect http timeout 3600 ip inspect name autosec_inspect rcmd timeout 3600 ip inspect name autosec_inspect realaudio timeout 3600 ip inspect name autosec_inspect smtp timeout 3600 ip inspect name autosec_inspect tftp timeout 30 ip inspect name autosec_inspect udp timeout 15 ip inspect name autosec_inspect tcp timeout 3600 ip access-list extended autosec_firewall_acl permit udp any any eq bootpc deny ip any any interface FastEthernet0/1 ip inspect autosec_inspect out ip access-group autosec_firewall_acl in ! end Apply this configuration to running-config? [yes]: Applying the config generated to running-config 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#
NOTE In Example 5-1, the administrator is prompted for a variety of input. However, adding the no-interact option to the end of the auto secure command eliminates this interactivity and simply applies default configurations without any further prompts.
Cisco SDM One-Step Lockdown
Most of the actions performed by the AutoSecure feature can be configured graphically using Cisco SDM’s One-Step Lockdown feature. The following steps describe how to configure One-Step Lockdown:
Step 1 Click the Configure button in the Cisco SDM interface, as shown in Figure 5-1.
Step 2 Click the Security Audit button in the Tasks pane, as shown in Figure 5-2.
Step 3 Click the One-step lockdown button, as shown in Figure 5-3.
Step 4 Click the Yes button on the SDM Warning screen, as shown in Figure 5-4. It explains how to undo some of the settings about to be applied by the One-Step Lockdown feature.
Step 5 After the One-Step Lockdown feature generates a set of recommended security settings, click the Deliver button, as shown in Figure 5-5, to apply the recommended configuration to the router.
Step 6 Click the OK button after the recommended commands are delivered to the router, as shown in Figure 5-6.
Be aware that Cisco SDM’s One-Step Lockdown feature does not perform all the same actions as the Cisco AutoSecure feature. Following are a few distinctions to keep in mind:
- One-Step Lockdown does not support the disabling of NTP.
- One-Step Lockdown does not support the configuration of AAA.
- One-Step Lockdown does not support the setting of Selective Packet Discard (SPD) values.
- One-Step Lockdown does not support the enabling of TCP intercepts.
- One-Step Lockdown does not configure antispoofing ACLs.
- Although One-Step Lockdown does support the disabling of SNMP, it does not support the configuration of SNMP version 3.
- Although One-Step Lockdown supports the configuration of Secure Shell (SSH) access, it does not support the enabling of Service Control Point or the disabling of other access services and file transfer services (for example, FTP).
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-ofband 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.
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.
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.
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.
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.
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 (SNMPv1) and SNMP version 2c (SNMPv2c) specify three major components of an SNMP solution, as detailed in Table 5-5.
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.
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 SNMPv1 and SNMPv2c is considered weak. Specifically, SNMPv1 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 SNMPv1 concept of community strings.
Fortunately, the security weaknesses of SNMPv1 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 SNMPv1, 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 SNMPv1 and SNMPv2 support only the noAuthNoPriv security level.
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 SNMPv1 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.
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.
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 1 024 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 1 20 R1(config)# ip ssh authentication- retries 4 R1(config)# line vty 0 4 R1(config-line)# transport input ssh R1(config-line)# end R1#
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.
Step 2 Click the + next to Router Properties to expand the selection, and then click the Logging option, as shown in Figure 5-15.
Step 3 In the Logging configuration screen, click the Edit button in the upperright corner of the Cisco SDM screen to open a separate Logging window, shown in Figure 5-16.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.