Secure Network Management and Reporting

In Chapter 4, we learned about Telnet, which is one of the most common management applications for remote access Cisco IOS routers. However, we also learned about the inherent security flaws in Telnet. This chapter describes the recommended alternative to Telnet – Secure Sockets Shell (SSH) – as well as Command Line Interface (CLI) and Security Device Manager (SDM) configuration tasks required to implement SSH in Cisco IOS routers. In addition to SSH, this chapter also explains reporting via the use of Syslog. The IINS exam objectives covered in this chapter are as follows:

• Use CLI and SDM to configure SSH on Cisco routers to enable secured management access
• Use CLI and SDM to configure Cisco routers to send Syslog messages to a Syslog server

We cover SSH and many other security protocols in our Cisco CyberOps Associate course.

This chapter is broken up into the following sections:

• Secure Sockets Shell Overview
• Implementing SSH via CLI
• Implementing SSH via SDM
• Syslog Overview
• Implementing Syslog via CLI
• Implementing Syslog via SDM

Back to book index.

Secure Sockets Shell Overview

Secure Sockets Shell (SSH) provides a more secure and reliable method for device access and administration than Telnet. SSH is an application and a protocol that provides secure replacement for the suite of Berkeley remote tools such as RSH, RLOGIN, and RCP.

RSH – Remote Shell – is a UNIX command-line utility that allows users to execute commands remotely. RLOGIN – Remote Login – is a software utility for Unix-like computer operating systems that allows users to log in on another host via a network, using TCP port 513. RCP –Remote Copy – is a command on UNIX operating systems that is used to copy one or more files from one computer system to another. RCP, RLOGIN, and RSH are beyond the scope of the IINS course requirements.

SSH secures the sessions using standard cryptographic mechanisms. SSH uses TCP and UDP port 22, although TCP port 22 is the de facto port listed for SSH. Unlike Telnet, SSH ensures that data is encrypted and is therefore untraceable by network sniffers, for example.

There are two versions of SSH available: SSH version 1 and SSH version 2. While SSH version 1 is an improvement over Telnet, which sends username and password information in clear text, some fundamental design flaws exist in SSH version 1. For example, there are numerous tools (which are not named, for ethical reasons) readily available on the Internet that can decrypt SSHv1 traffic on the fly, thus removing most security from encrypting the traffic with SSHv1. Therefore, when implementing SSH, it is highly recommended that SSH version 2 be used.

SSH version 2 is a re-worked and stronger version of SSH. In addition to all the features and functionality in SSH version 1, SSH version 2 brings encrypted File Transport Protocol (FTP), support for digital certificates and Public Key Infrastructure (PKI), and many other features. FTP is beyond the scope of the IINS course requirements; however, digital certificates and PKI are within scope and will be described in detail later in this guide.

Despite the advantages afforded by SSH version 2, it does not support some of the faster ciphers. Ciphers, which provide encryption or decryption, are a requirement in the IINS course and will be described in detail later in this guide. In addition to this, unlike most software that contains revisions, it is important to keep in mind that SSH version 1 and SSH version 2 are not completely compatible. For example, most SSH version 1 clients cannot automatically connect to an SSH version 2 server unless the server is compiled up to support “compatibility” mode.

SSH resides on top of the TCP/IP layers, protecting hosts from unknown devices. The SSH Transport Layer protocol is responsible for securing data by using a strong encryption algorithm. The following diagram illustrates the SSH protocol layers:

Figure 5.1. SSH Protocol Layers

SSH, coupled with the AAA mechanism using RADUIS or TACACS+, provides the best solution for a secure, scalable access mechanism.

Implementing SSH via CLI

Before we go into the configuration tasks pertaining to SSH implementation on Cisco IOS routers, it is important that you understand the restrictions that apply regarding SSH. The first restriction is that SSH version 1 is supported in Cisco IOS 12.1(1)T and later, while SSH version 2 is supported in Cisco IOS 12.3(4)T and later. Therefore, the version of SSH you are able to configure on the Cisco IOS router will be dependent on the version of software that the router is running.

The second restriction is that SSH is only supported in Cisco IOS images that have cryptographic capabilities. For example, if you are running Cisco IOS 12.4, but the image is a basic Enterprise image, the software will not support SSH configuration. It is therefore imperative to ensure that not only the correct version of software but also the capabilities and type of software on routers within the network are consistent throughout.

Once these two restrictions have been identified and addressed, the following steps are required to implement SSH on Cisco IOS routers:

1. Configure a domain name on the router. This is performed via the ip domain-name [name] global configuration command.

2. Generate the security keys that will be used by SSH. This is performed by using the crypto key generate rsa global configuration command and specifying the desired key size; or, alternatively, via the crypto key generate rsa general-keys and specifying the desired key size. Both of these commands automatically enable SSH when executed, and no further configuration is necessary. The key (modulus) size that is used for SSH can be up to 2048 bits in length. The larger the key size, the more secure the implementation; however, larger keys also take a longer time to generate. When generating a public key, Cisco recommends a minimum key size of 1024 bits.

3. Specify the time that the router waits on the SSH client, in seconds, to input username and password information before disconnecting the session via the ip ssh timeout global configuration command. This is an optional step because, by default, the router will wait for 120 seconds (2 minutes).

4. Specify the number of SSH authentication retries before a session is reset via the ip ssh authentication-retries global configuration command. By default, the Cisco IOS router will allow up to three failed logins before resetting the SSH connection. As is the case with the ip ssh timeout global configuration command, this is an optional step.

5. Allow only SSH sessions to the Cisco IOS router by issuing the transport input ssh line configuration command to allow only SSH. This is performed for all VTY lines.

6. Save your router configuration by using the copy running-config startup-config or the copy system:running-config nvram:startup-config commands, depending on the Cisco IOS version that is running on the device.

The following example illustrates how to enable SSH on a Cisco IOS router using the steps provided. The router will be configured to use the domain name howtonetwork.net, a general key size of 1024 bits for SSH, a 30-second SSH timeout, and will allow two authentication attempts before the SSH session is terminated. Finally, the router is configured to allow only SSH sessions and no Telnet sessions for remote access and management. These configuration steps are performed as follows:

R1(config)#ip domain-name howtonetwork.net R1(config)#crypto key generate rsa The name for the keys will be: R1.howtonetwork.net Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.   How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable…[OK]   R1(config)#ip ssh time-out 30 R1(config)#ip ssh authentication-retries 2 R1(config)#line vty 0 4 R1(config-line)#transport input ssh R1(config-line)#exit R1(config)#exit R1#copy system:running-config nvram:startup-config Destination filename [startup-config]? Building configuration… [OK] R1#

To verify the local public keys that have been generated on the router, administrators can use the show crypto key mypubkey rsa command. A sample output is provided below:

R1#show crypto key mypubkey rsa % Key pair was generated at: 02:57:45 UTC Mar 1 2002 Key name: R1.howtonetwork.net Storage Device: not specified Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00C98784 4F358BC6 2A3908F0 CF29F52B CD1BF757 23FF69C0 57A4B129 36F72D22 42CC205C 8BD5002B 7DC462C5 EBFC4ABE 4D404195 BD883014 19D423BB 6C490174 C27A0009 EC080C2E 0C23ABFA 7FCB66BD 495BD9D3 84BBC9EA 4951A292 5A8F395B 7BD57145 F69E83B0 3C76DF8B 8951B88C C033CE5C D8627EE1 5FD1ACA1 1C5DEC91 EB020301 0001 % Key pair was generated at: 02:57:51 UTC Mar 1 2002 Key name: R1.howtonetwork.net.server Temporary key Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C0E578 9B223536 CB3B6F88 25D03C0B B46803A9 1CCD589B 99704A48 0FD75C5E 0AFF9F76 D4DD51D7 DC8809D0 16A8E4AE D0963662 E2408242 4B33E42E 8CC405EA 233DBF39 E12DFAEE D9EB92C8 0D2B0C27 573B8386 BF0B761F 6ED634FC DCFBA622 ED020301 0001

In the real world, it is common practice to rotate keys every so often, in accordance with security policies. Therefore, to delete an existing key with the intention of configuring a new one, administrators can used the crypto key zeroize rsa global configuration command, as illustrated in the following output:

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]: y R1(config)#

Once SSH has been enabled on Cisco IOS routers, administrators can verify that only SSH, and not Telnet, is allowed for inbound remote access sessions to the router by using the show line vty [number] command, as illustrated in the following output:

R1#show line vty 0 Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int 66 VTY              –    –      –    –    –      0       0     0/0       –   Line 66, Location: “”, Type: “” Length: 24 lines, Width: 80 columns Baud rate (TX/RX) is 9600/9600 Status: No Exit Banner Capabilities: none Modem state: Idle Special Chars: Escape  Hold  Stop  Start  Disconnect  Activation ^^x    none   –     –       none Timeouts:      Idle EXEC    Idle Session   Modem Answer  Session   Dispatch 00:10:00        never                        none     not set Idle Session Disconnect Warning never Login-sequence User Response 00:00:30 Autoselect Initial Wait not set Modem type is unknown. Session limit is not set. Time since activation: never Editing is enabled. History is enabled, history size is 20. DNS resolution in show commands is enabled Full user help is disabled Allowed input transports are ssh. Allowed output transports are pad telnet rlogin mop v120 ssh. Preferred transport is telnet. No output characters are padded No special data dispatching characters

Additionally, depending on platform capability, administrators can also use the show ip ssh command to ensure that SSH version 2 has been enabled on the router. However, keep in mind that in Cisco IOS software, it will actually show up as SSH version 1.99. This is, in fact, SSH version 2, since there is no such thing as SSH version 1.99. A sample output of this command is illustrated below:

R1#show ip ssh SSH Enabled – version 1.99 Authentication timeout: 30 secs; Authentication retries: 2 R1#

Once SSH is enabled, administrators can log in using tools such as SecureCRT, which requires a license and must be purchased, or freeware, such as Putty. From a Windows-based client, administrators can simply telnet to the device and specify port 22 (SSH) as the intended destination port. The following screenshot illustrates the use of Putty to access a Cisco IOS router enabled for SSH remotely:

Figure 5.2. Putty Access to SSH Enabled Router

When the warning is displayed by the Putty client, simply click on the Yes button to proceed with the connection to the router and then log in using your credentials, as follows:

Figure 5.3. Login to SSH Enabled Router

While SSH access to a router is illustrated using the Putty client, it is important to keep in mind that this may be different for other SSH clients.

Implementing SSH via SDM

In addition to configuring SSH via CLI, you are also expected to demonstrate knowledge on SSH configuration via SDM. This is performed by clicking on the Additional Tasks button on the main configuration page in Cisco SDM. This is illustrated in the following screenshot:

Figure 5.4. Enabling SSH Using SDM

As we learned earlier in this section, before SSH can be enabled on a Cisco IOS router, a domain name must be configured on the router. This is performed by clicking on the + sign next to Router Properties menu, as illustrated in the following screenshot:

Figure 5.5. A Domain Name is Required

To configure a domain name, highlight Domain Name and click on the Edit button, as illustrated in the following screenshot:

Figure 5.6. Configuring a Domain Name

Next, simply type in the desired domain name and click on the OK button, as illustrated in the following screenshot:

Figure 5.7. Click ‘OK’ When Done

Once the DNS domain name has been configured, you can proceed and enable SSH access to the Cisco IOS router. This is performed on the Additional Tasks page in SDM, under the Router Access menu, as illustrated in the following screenshot:

Figure 5.8. Enable SSH Next

Under the Router Access menu, select SSH and then click on the Generate RSA Key, as illustrated in the following screenshot:

Figure 5.9. Generate RSA Key with SDM

In the following pop-up box, type in the desired RSA key size and then click on the OK button, as illustrated in the following screenshot:

Figure 5.10. Choose Key Size

Next, type in the credentials used to access the device via SDM. This username should have Level 15 access to the device, as required when configuring a router for SDM. Once you have typed in the credentials, click on the OK button, as shown in the screenshot below:

Figure 5.11. Choose Login Credentials

Once complete, SDM delivers the configuration commands to the device and SSH access will be enabled. To validate SSH access, you can use an SSH client (such as Putty) to connect to the router and then log in using your credentials, as illustrated in the following screenshots:

Figure 5.12. Loin Using SSH Client

Figure 5.13. Successful Login

Syslog Overview

Syslog is a protocol that allows a host to send event notification messages across IP networks to event message collectors – also known as Syslog Servers or Syslog Daemons. In other words, a host or a device can be configured in such a way that it generates a Syslog Message and forwards it to a specific Syslog Daemon (Server).

A Syslog Daemon or Server is an entity that listens to the Syslog messages that are sent to it. You cannot configure a Syslog Daemon to ask a specific device to send it Syslog Messages. In other words, if a specific device has no ability to generate Syslog Messages, then a Syslog Daemon cannot do anything about it. In the real world, corporations typically use Solarwinds (or similar) software for Syslog capturing. Additionally, freeware such as the Kiwi Syslog Daemon is also available for Syslog capturing.

Syslog uses User Datagram Protocol (UDP) as the underlying transport mechanism, so the data packets are unsequenced and unacknowledged. While UDP does not have the overhead included in TCP, this means that on a heavily used network, some packets may be dropped and therefore logging information will be lost. However, the Cisco IOS allows administrators to configure multiple Syslog servers for redundancy. A Syslog solution is comprised of two main elements: a Syslog server and a Syslog client. These components are illustrated in the following network diagram:

Figure 5.14. Syslog Server and Client

In the diagram above, the Syslog client (R1) sends Syslog messages to the Syslog sever using UDP as the Transport Layer protocol and specifying a destination port of 514. Syslog messages cannot exceed 1,024 bytes in size; however, there is no minimum length.  All Syslog messages contain three distinct parts:

1. Priority
2. Header
3. Message

Priority

The priority of a Syslog message represents both the Facility and Severity of the message. This number is an 8-bit number. The first 3 bits are the least significant and represent the Severity of the message (with 3 bits you can represent eight different Severities) and the other 5 bits represent the Facility of the message. You can use the Facility and the Severity values to apply certain filters on the events in the Syslog Daemon.

It is important to know that these values are generated by the applications on which the event is generated, and not by the Syslog server itself. The values sent by Cisco IOS devices are listed and described in the following table:

Table 5.1. Syslog Levels

Level	Name	Description
0	Emergencies	This level is used for the most severe error conditions that render the system unusable.
1	Alerts	This level is used to indicate conditions that need immediate attention from administrators.
2	Critical	This level is used to indicate critical conditions that are less than Alerts but still require administrator intervention.
3	Errors	This level is used to indicate errors within the system; however, these errors do not render the system unusable.
4	Warnings	This level is used to indicate warning conditions about system operations that did not complete successfully.
5	Notifications	This level is used to indicate state changes within the system, e.g. a routing protocol adjacency transitioning to a down state.
6	Informational	This level is used to indicate informational messages about the normal operation of the system.
7	Debugging	This level is used to indicate real-time (debugging) information that is typically used for troubleshooting purposes.

In Cisco IOS software, the logging facility global configuration command can be used to specify the Syslog facility. The options available with this command are as follows:

R1(config)#logging facility ? auth    Authorization system cron    Cron/at facility daemon  System daemons kern    Kernel local0  Local use local1  Local use local2  Local use local3  Local use local4  Local use local5  Local use local6  Local use local7  Local use lpr     Line printer system mail    Mail system news    USENET news sys10   System use sys11   System use sys12   System use sys13   System use sys14   System use sys9    System use syslog  Syslog itself user    User process uucp    Unix-to-Unix copy system

NOTE: Going into the specifics of logging facilities is beyond the scope of the IINS course requirements.

In order to specify a logging severity level in Cisco IOS software, you must first select the location to which Syslog messages will be sent. Once selected, an administrator can then select the severity of log messages that will be sent to that location. The options available are illustrated in the following output (which depicts logging to the local router buffer):

R1(config)#logging buffered ?   <0-7>              Logging severity level <4096-2147483647>  Logging buffer size alerts             Immediate action needed           (severity=1)   critical           Critical conditions               (severity=2)   debugging          Debugging messages                (severity=7) discriminator      Establish MD-Buffer association emergencies        System is unusable                (severity=0)   errors             Error conditions                  (severity=3)   informational      Informational messages            (severity=6)   notifications      Normal but significant conditions (severity=5)   warnings           Warning conditions                (severity=4) xml                Enable logging in XML to XML logging buffer <cr>

Administrators can use either the Cisco IOS-provided keyword or the number to perform the same action. For example, the logging buffered 7 and the logging buffered debugging commands will both log and send debugging Syslog messages to the specified destination, which is specified by using the logging [destination] global configuration command. In addition to this, it is imperative to remember that the severity level specified includes all other severity levels below it.

For example, if an administrator configures a router with the logging buffered notifications command, the router will log notifications as well as warnings, errors, critical messages, alerts, and emergencies. Similarly, if an administrator configures a router with the logging buffered notifications command, the router will log ALL messages to the local buffer, i.e. Levels 0 through 7 will be included and logged.

The Syslog destination options available in Cisco IOS software are provided, in bold font, in the router output illustrated below:

R1(config)#logging ?   Hostname or A.B.C.D  IP address of the logging host buffered             Set buffered logging parameters buginf               Enable buginf logging for debugging cns-events           Set CNS Event logging level console              Set console logging parameters count                Count every log message and timestamp last occurrence discriminator        Create or modify a message discriminator dmvpn                DMVPN Configuration exception            Limit size of exception flush output facility             Facility parameter for syslog messages history              Configure syslog history table host                 Set syslog server IP address and parameters message-counter      Configure log message to include certain counter value monitor              Set terminal line (monitor) logging parameters on                   Enable logging to all enabled destinations origin-id            Add origin ID to syslog messages persistent           Set persistent logging parameters queue-limit          Set logger message queue size rate-limit           Set messages per second limit reload               Set reload logging level server-arp           Enable sending ARP requests for syslog servers when first configured source-interface     Specify interface for source address in logging transactions   trap                 Set syslog server logging level userinfo             Enable logging of user info on privileged mode enabling

The following table lists and describes the bolded options, which you must be familiar with:

Table 5.2. Logging Options

Keyword	Description
Hostname or A.B.C.D	This option is used to specify the DNS hostname or IP address of the remote Syslog server.
buffered	This option is used to configure the Cisco IOS router to send and store Syslog messages in the local buffer.
console	This option is used to enable logging messages to the Console, which is enabled by default in Cisco IOS software.
host	This option is used to specify the IP address or DNS hostname of the remote Syslog server and specify advanced Syslog options.
source-interface	This option is used to specify the source IP address that will be used for Syslog messages. This is typically set at the Loopback interface.
trap	This option is used to specify the log severity level to send Syslog messages to a remote Syslog server.

Header

The header of a Syslog message contains the timestamp and the hostname or IP address of the device. The timestamp is the date and time at which the message was generated. In Cisco IOS software, routers can be configured to use Network Time Protocol (NTP) to sync their internal clocks or administrators can manually set the clocks on the devices via the clock set hh:mm:ss privileged EXEC command. NTP configuration is beyond the scope of the IINS course requirements.

Message

The message part will fill the remainder of the Syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. This part has two fields: the TAG field and the CONTENT field. The value in the TAG field is the name of the program or process that generated the message. The CONTENT field contains the details of the message.

The following screenshot illustrates a typical Syslog message received on a Syslog server. While the Syslog server used in this example is a Kiwi Syslog server, the message format presented will basically be the same in all Syslog servers.

Figure 5.15. Syslog Message

Implementing Syslog via CLI

To implement Syslog using CLI, the following sequence of steps should be taken:

1. Enable logging globally by issuing the logging on global configuration command.

2. Specify the location the router should send the logs using the logging For example, to send Syslog messages to the local buffer, the logging buffered command would be used; whereas to send Syslog messages to a Syslog server with the IP address 10.1.1.254, the logging 10.1.1.254 or logging host 10.1.1.254 global configuration commands would be used.

3. Specify the level of log messages to send to the Syslog server. For example, to send Level 7 (debugging logs) to the local buffer, an administrator would use the logging buffered debugging global configuration command; however, to send Level 5 logs to a remote Syslog server, an administrator would use the logging trap notifications global configuration command.

4. Specify the facility for Syslog messages using the logging facility global configuration command. This step is optional and you are not required to implement this as part of the IINS course requirements.

5. Verify logging by issuing the show logging This step is also optional.

To reinforce what we have just learned, we will go over a few configuration examples pertaining to Syslog configuration. The following example illustrates how to send all Level 6 Syslog messages to a remote Syslog server with the IP address 172.16.1.254:

R1(config)#logging on R1(config)#logging host 172.16.1.254 R1(config)#logging trap informational R1(config)#exit R1# R1#show logging Syslog logging: enabled (1 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)   No Active Message Discriminator.       No Inactive Message Discriminator.     Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging:  level debugging, 1 messages logged, xml disabled, filtering disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled Trap logging: level informational, 38 message lines logged         Logging to 172.16.1.254  (udp port 514,  audit disabled, authentication disabled, encryption disabled, link up), 22 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD,

The following example illustrates how to log all critical notifications to the local buffer:

R2(config)#logging on R2(config)#logging buffered R2(config)#logging buffered critical R2(config)#exit R2# R2#show logging Syslog logging: enabled (1 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)   No Active Message Discriminator.       No Inactive Message Discriminator.     Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging:  level critical, 0 messages logged, xml disabled, filtering disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled Trap logging: level debugging, 32 message lines logged   Log Buffer (4096 bytes):

When logging messages to the buffer, it is important to remember that older logs are deleted as the buffer becomes full. By default, the router buffer size is 4096 bytes. Depending on the level of logging enabled, it is possible that older messages will be flushed within a short period of time as new messages are received.

Therefore, in order to retain messages in the local buffer for a greater period of time, increase the size of the local buffer by issuing the logging buffered [size] global configuration command. This is illustrated and validated in the following router output:

R2(config)#logging buffered 10000 R2(config)#exit R2# R2#show logging Syslog logging: enabled (1 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)   No Active Message Discriminator.       No Inactive Message Discriminator.     Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging:  level debugging, 1 messages logged, xml disabled, filtering disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled Trap logging: level debugging, 33 message lines logged   Log Buffer (10000 bytes):

The following example illustrates how to log all Level 7 messages to a remote Syslog server with the IP address 172.16.1.254, while also logging all Level 6 messages to the local router buffer. In addition to this, all Console level logging is disabled:

R2(config)#logging on R2(config)#logging host 172.16.1.254 R2(config)#logging trap 7 R2(config)#logging buffered R2(config)#logging buffered 6 R2(config)#no logging console R2(config)#exit R2# R2#show logging Syslog logging: enabled (1 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)   No Active Message Discriminator.       No Inactive Message Discriminator.     Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging:  level informational, 2 messages logged, xml disabled, filtering disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled Trap logging: level debugging, 35 message lines logged Logging to 172.16.1.254  (udp port 514,  audit disabled, authentication disabled, encryption disabled, link up), 2 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled   Log Buffer (4096 bytes):   *Mar  1 00:56:16.486: %SYS-5-CONFIG_I: Configured from console by vty0 (172.16.1.1) *Mar  1 00:56:17.488: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 172.16.1.254 port 514 started – CLI initiated

Implementing Syslog via SDM

In Cisco SDM, administrators can configure Syslog parameters by clicking on the Additional Tasks tab and then selecting Router Properties, as illustrated in the following screenshot:

Figure 5.16. Syslog Using SDM

Next, under Router Properties, click on Logging to bring you to the following screen:

Figure 5.17. Select ‘Syslog Property’

As illustrated in the screenshot above, all logging capabilities are currently disabled on the device. To enable Syslog logging, highlight the Syslog property and then click on the Edit button, as illustrated in the following screenshot:

Figure 5.18. Select ‘Edit’

Next, check the Enable Logging Level checkbox and select the desired logging level from the Logging Level drop-down menu, as illustrated in the following screenshot:

Figure 5.19. Choose the Logging level

Once the desired logging level has been selected, click on the Add button to bring up the following pop-up window, which allows you to specify the IP address of the Syslog server:

Figure 5.20. Select ‘Add’ and the IP Address

Once you have entered the IP address of the server, click on the OK button. Next, click on the Logging Buffer checkbox to configure local buffer parameters, as illustrated in the following screenshot:

Figure 5.21. Select ‘Logging Buffer’

Next, select the desired level of logging from the Logging Level drop-down menu, as illustrated in the following screenshot:

Figure 5.22. Select the Logging Level

Optionally, you can also set the size of the local buffer by typing in the desired size in the Buffer Size option, as illustrated in the following screenshot:

Figure 5.23. Select Buffer Size

Once complete with your desired input and configuration, click on the OK button at the very bottom. SDM then configures the router, as illustrated in the following screenshot:

Figure 5.24. Choose ‘OK’

Click on OK and SDM shows the configured options as illustrated in the screenshot below:

Figure 5.25. View Your Selections

To view logging via SDM, click on Monitor – next to the Configure main tab – at the very top, and then click on Logging, as illustrated in the following screenshot:

Figure 5.26. Logging Screenshot

SDM then brings you to the following screen, which allows you to view Syslog messages – as well as other log messages, which will be described later in this guide. From this screen, you can select the drop-down menu to specify the level of messages you want to view. In addition to this, administrators can also clear the buffer or search through the logs:

Figure 5.27. View Logging Messages

Chapter Summary 

The following section is a summary of the major points you should be aware of in this chapter:

Secure Sockets Shell Overview

• SSH provides a more secure and reliable method for device administration than Telnet
• SSH secures the sessions using standard cryptographic mechanisms
• SSH uses TCP and UDP port 22, although TCP port 22 is the de-facto port listed for SSH
• There are two versions of SSH available: SSH version 1 and SSH version 2
• SSH version 1 is not safe and it is recommended that SSH version 2 be used
• SSH version 1 and SSH version 2 are not completely compatible

Implementing SSH via the CLI

• SSH version 1 is supported in Cisco IOS 12.1(1)T and later versions
• SSH version 2 is supported in Cisco IOS 12.3(4)T and later versions
• SSH is only supported in Cisco IOS images that have cryptographic capabilities
• The following steps are required to implement SSH on Cisco IOS routers:

1. Configure a domain name on the router. This is performed via the ip domain-name [name] global configuration command.

2. Generate the security keys that will be used by SSH. This can be performed by using the crypto key generate rsa global configuration command and specifying the desired key size; or, alternatively, via the crypto key generate rsa general-keys and specifying the desired key size. The key size, which is used for SSH, can be up to 2048 bits in size. The larger the key size, the more secure the implementation. However, keep in mind that larger keys also take a longer time to generate. Typically, a key size of 1024 is used.

3. Specify the time that the router waits on the SSH client, in seconds, to input username and password information before disconnecting the session via the ip ssh timeout global configuration command. This is an optional step because, by default, the router will wait for 120 seconds (2 minutes).

4. Specify the number of SSH authentication retries before a session is reset via the ip ssh authentication-retries global configuration command. By default, the Cisco IOS router will allow up to three failed logins before resetting the SSH connection. As is the case with the ip ssh timeout global configuration command, this is an optional step.

5. Allow only SSH sessions to the Cisco IOS router by issuing the transport input ssh line configuration command to allow only SSH. This is performed for all VTY lines.

6. Save your router configuration by using the copy running-config startup-config or the copy system:running-config nvram:startup-config commands, which depend on the Cisco IOS version that is running on the device.

Implementing SSH via SDM

To configure and implement SSH via Cisco SDM, perform the following steps:

1. On the main configuration page, click on the Additional Tasks button

2. On the Additional Tasks page select Router Properties to configure the domain name

3. On the Additional Tasks page select Router Access > SSH to configure SSH parameters

4. Click on the Generate RSA Key radio button to generate RSA keys

5. Type in the size of the RSA key and click OK

Syslog Overview

• Syslog allows a host to send event notification messages across IP networks
• A Syslog solution is comprised of a Syslog server and a Syslog client
• A Syslog server is an entity that listens to the Syslog messages that are sent to it
• A Syslog client is an entity that generates Syslog messages
• Syslog uses UDP as the underlying transport mechanism, using a destination port of 514
• Syslog messages cannot exceed 1,024 bytes in size
• All Syslog messages contain three distinct parts. These parts are the:

1. Priority – this field represents both the Facility and Severity of the message
2. Header – this field contains the timestamp and the hostname or IP address of the device
3. Message – this field the text of the message and includes the TAG and CONTENT fields

 Implementing Syslog via the CLI

To implement Syslog using the CLI, the following sequence of steps should be taken:

1. Enable logging globally by issuing the logging on global configuration command

2. Specify the location the router should send the logs using the logging command. For example, to send Syslog messages to the local buffer, the logging buffered command would be used; whereas to send Syslog messages to a Syslog server with the IP address 10.1.1.254, the logging 10.1.1.254 or logging host 10.1.1.254 global configuration commands would be used.

3. Specify the level of log messages to send to the Syslog server. For example, to send Level 7 (Debugging logs) to the local buffer, an administrator would use the logging buffered debugging global configuration command; however, to send Level 5 logs to a remote Syslog server, an administrator would use the logging trap notifications global configuration command.

4. Specify the facility for Syslog messages using the logging facility global configuration command. This step is optional and you are not required to implement this as part of the IINS requirements.

5. Verify logging by issuing the show logging This step is also optional.

Implementing Syslog via SDM

• To configure and implement Syslog via Cisco SDM, perform the following steps:

1. On the main configuration page, click on the Additional Tasks button

2. On the Additional Tasks page select Router Properties > Logging to configure Syslog

3. Select Edit to edit default Syslog parameters

4. Click OK when you are complete to have SDM issue the configuration on the router

• To view Syslog information via SDM, perform the following steps:

1. Click on Monitor – next to the Configure main tab

2. Select Logging on the main Monitor page

Commands Used in this Chapter

The following section is a summary of the commands used in this chapter: 

Command	Description
ip domain-name [name]	Used to configure a domain name on the router
crypto key generate rsa	Used to generate public RSA keys for SSH
crypto key generate rsa general-keys	Performs the same function as the crypto key generate rsa command and generates a public key for SSH
ip ssh timeout	Used to configure the SSH timeout value in seconds
ip ssh authentication-retries	Used to specify the SSH authentication attempts
copy running-config startup-config	Used to save the running-config (RAM) to the startup-config (NVRAM)
copy system:running-config nvram:startup-config	Used to save the running-config (RAM) to the startup-config (NVRAM)
transport input ssh	Allows SSH access only for the specified VTY lines
crypto key zeroize rsa	Used to delete the existing RSA public key
show crypto key mypubkey rsa	Used to view the configured RSA public key
show ip ssh	Used to view the current version of SSH enabled
logging facility	Used to specify a logging facility
logging buffered	Used to specify local buffer logging parameters
logging trap	Used to specify Syslog server logging parameters
logging on	Used to globally enable logging (enabled by default)
clock set hh:mm:ss	Used to set the local router time
logging host	Used to specify the IP address of the Syslog server
show logging	Used to view the local router log (buffer)

Cisco SSH guide.