Vulnerabilities Within Various Management Protocols

Many commonly used management protocols such as Telnet, Simple Network Management Protocol (SNMP), and syslog were not designed as secure protocols. These protocols transmit information in plaintext, which an attacker can capture. Also, some management protocols have no packet-level integrity, which allows an attacker to easily change the data within packets without your being aware that the data was changed.

Telnet

All Telnet data is transmitted in cleartext. If you are configuring a router or some other remote device, any attacker sniffing the wire can capture all your passwords and accounts. Telnet is not a good application to use within a secure computing environment. Instead of using Telnet, you can get the same functionality with SSH, a secure protocol that encrypts packets before they are transmitted to the destination. The use of SSH eliminates the potential theft of information. If the SSH is not supported on the code you are running on your devices, you can still use Telnet, but encrypt the traffic between source and destination.

SNMP

SNMP is a fantastic network-management protocol. It gives you the ability to remotely monitor devices. You can also use it to configure network devices such as routers, and those networking devices can proactively send information to you based on your own requirements. However, SNMP was not designed with security in mind. SNMP sends information in plaintext, so it is vulnerable to compromise. If you need to use SNMP on your network, ensure that you are using SNMP version 3 or higher, which contains security mechanisms that do not allow a hacker to view information that is transmitted by this protocol. Also, the use of strong community strings is essential. A community string is what SNMP calls a password. Also, it is highly recommended that you configure community strings that provide read-only access to devices.

Logging

Syslogging has a couple of different problems. First of all, all syslog packets are sent to a syslog server in cleartext. Also, syslog packets have no packet-level integrity. An attacker can manipulate or change the data within the syslog packets without your ever knowing that a change was made. There are a couple ways to mitigate the risks associated with syslogging. First, send syslog data down an IP Security (IPSec) tunnel to encrypt the data for confidentiality and also hash the packets to provide packet-level integrity. You should also use access lists to ensure that only legitimate syslog sources can send data to your syslog servers. These access lists also include RFC 2827 filtering, which we discussed earlier.

TFTP

Trivial File Transfer Protocol (TFTP) has some of the same issues as syslogging and Telnet in that all data is transmitted in cleartext. As you are aware, Cisco makes extensive use of TFTP servers not only to store and retrieve IOS images but also to store and retrieve configuration files. You don't want your configuration files exposed to malicious individuals. An easy technique to use to secure the TFTP protocol is to send TFTP packets across an IPSec tunnel, which provides the necessary confidentiality to keep your sensitive data private. Good practice in large networks is using an out-of- band (OOB) management network. An OOB management network is a private management network, and provides the highest level of security for management traffic.

NTP

Network Time Protocol (NTP) ensures that your devices have their time set correctly. Knowing the correct time is extremely important when viewing log files, syslog data, and other router output. You also need to know the correct time to troubleshoot network issues. There is no point to hanging out in the office at midnight when the actual cause of network issues occurred at noon. Further, digital-certificate “based authentication relies upon having the correct time and date configured on your devices. One simple DoS attack changes your clock times so that digital-certificate authentication fails because then your IPSec tunnel creation also fails. To ensure that an attacker cannot change your router's clock or manipulate NTP packets, you need to use a version of NTP that supports cryptographic authentication mechanisms.

NTP versions 3 and above support cryptographic authentication (Message Digest 5) mechanisms between peers.

SSH

The use of SSH is highly recommended when you configure your networking devices. SSH encrypts packets that are sent between peers; therefore, those packets are not subject to eavesdropping. Cisco supports SSH version 1 only.

SSH version 1 and SSH version 2 are entirely different protocols and are not compatible.

SSL

Many of the more recent GUI-based network-management applications from Cisco support the use of SSL. If you've ever bought anything over the Internet securely, you have used SSL. SSL ensures the confidentiality of the information transmitted between host and server. Therefore, it is highly recommended that you use SSL if it is available. SSL is an application-level protocol, and applications must support SSL. Otherwise, you cannot use it within this application.