Simple Network Management Protocol (SNMP) is used by a variety of programs involved with network management. The beauty of SNMP is intertwined with its dangers. Because SNMP is designed to allow an administrator to monitor and configure devices remotely, SNMP can also be used in attempts to penetrate the corporate network. This section explores how to
minimize vulnerability while using SNMP.
A few simple configuration changes, as well as a few logical choices that should be made by the administrator, can greatly reduce the risks involved with SNMP. Both logical choices and configuration considerations are covered in this section.
The first consideration an administrator should make regarding SNMP is to turn it off. If SNMP is not being used, running it only takes away from available bandwidth, needlessly burns CPU cycles, and exposes the network to unnecessary vulnerabilities.
Before using SNMP in read/write mode, rethink the requirement to do so. Running SNMP in read/write mode with just a few minor configuration errors can leave the whole of your network susceptible to attacks. A great number of tools can scan any network over SNMP. These can map out your entire network if SNMP has a hole left open.
In late February of 2001, Cisco released information that there are also security issues with SNMP even when using only the read mode. Due to a defect within the Cisco IOS versions 11.0 and 12.0, SNMP is vulnerable to certain denial of service attacks designed to confuse products such as CiscoWorks. In order to fix these potential security problems, an IOS upgrade must be accomplished. If you have not upgraded your IOS since this time, it is strongly recommended that you read the information at the following two URLs to see if your specific equipment is affected:
www.cisco.com/warp/public/707/ios-snmp-ilmi-vuln-pub.shtml
www.cisco.com/warp/public/707/ios-snmp-community-vulns-pub.shtml
SNMP is available in versions 1, 2, and 3. There are some major differences between versions. First, version 1 sends passwords in clear-text format, and version 2 allows password
encryption using the MD5 encryption algorithms. Second, although virtually all management programs can use SNMP version 1, the choice is limited when using SNMP version 2. One of the original goals of version 2 was to provide commercial-grade security through
authentication, privacy, and authorization. Version 2 failed to accomplish these goals because version 2c, while having the endorsement of the Internet Engineering Task Force (IETF), failed to implement these security measures. Versions 2u and 2* implemented security but failed to gain acceptance from the IETF.
Version 3, available on the standard Cisco IOS since release 12.0(3)T, uses MD5, Secure Hash Algorithm (SHA), and keyed algorithms to protect against data modification and masquerade
attacks. Version 3 can optionally use Data Encryption Standard (DES) in the cipher block chaining mode when security is required.
From a security viewpoint, the passing of clear-text passwords should become a primary concern, especially because most SNMP applications send passwords repeatedly during normal operations. If your management software and equipme nt is compatible with version 2, there is no reason to run version 1. Assuming that the network in question is using only SNMP version 2, the administrator can ensure encryption by using the following command:
snmp-server enable traps snmp authentication md5 This command replaces the older and no longer valid command:
snmp-server trap-authentication
Unless you are purposely using SNMP version 1, the following command must be avoided at all costs:
snmp-server communityname
This command not only sets the community name, but also enables SNMP version 1 instead of version 2.
If version 1 is running, pay close attention to the name of the community. Because the community name is passed in clear text, this name should give no indication of either the company name or the type of company associated with the name. For example, assume that the company in question is Cisco Systems. Using the word "cisco" in any part of the
community name might alert hackers that they have gained access to Cisco Systems. Using a community name "routers" might also give hackers unnecessary information. When using SNMP
version 1, Cisco suggests that all equipment use differing community names. Although this might seem like an unreasonable restriction in a large network, using multiple community names will reduce the number of routers that are vulnerable because of the revealing of a single community name. If it is not possible to assign a different community name for all devices, find a balance between using a single community name and using a differing name on each piece of equipment. Finally, avoid using the names "public" or "private," because they are so commonly used.
Most networks have a few select management stations from which SNMP messages can legitimately originate. When using version 1 and the community name command, it is recommended that the optional access list number be included. This allows the administrator to control which stations have access, through a standard access list (numbered 1–99) applied to the SNMP services as if SNMP were an inbound router port.
Access control lists (ACLs) should be placed close to the edge of your network, preventing outside parties from probing your network over SNMP. Additionally, if the CPU cycles are available on interior routers, it might be worth the effort to add ACLs on certain routers in the interior of the network. This allows for the limitation of breaches, if they do occur.
If you are using SNMP in read-only mode, you need to ensure that it is set up with appropriate access controls . An example of proper protection follows:
access-list 7 permit 172.30.1.45 access-list 7 permit 10.1.1.53
snmp-server community 85tres76n RO 7 snmp-server trap-source Loopback0 snmp-server trap-authentication snmp-server enable traps config snmp-server enable traps envmon
snmp-server contact Joe Admin [[email protected]] snmp-server location main server room router 8 snmp-server enable traps bgp
snmp-server enable traps frame-relay snmp-server host 172.30.1.45 85tres76n snmp-server host 10.1.1.53 85tres76n snmp-server tftp-server-list 7
The preceding example uses ACL 7 and allows SNMP messages from only two IP addresses to be accepted. Because there are only two possible SNMP servers (172.30.1.45 and 10.1.1.53), these are the only IP addresses where SNMP is allowed to respond. SNMP messages from all other IP addresses would be implicitly denied.
Because the community string is not encrypted, care is taken to use "85tres76n," which has no known relation to the company or the services that the company offe rs. Once a community string is known outside of the organization, a point of possible attack is created. Unless SNMP is set up to pass community-name authentication failure traps, and the SNMP management device is configured to react to the authentication failure trap, the community name is easily discovered.
Keep in mind that accepting SNMP from only known good IP addresses does not necessarily guarantee security because of IP address spoofing. Unless serious antispoofing measures are in place, you cannot rely on IP addresses as the primary means of security on any system. With all security configurations, the objective of the administrator should be to build many obstacles to unauthorized personnel while providing seamless operation to authorized users. Notice that even the e -mail address of the administrator is not a company e-mail address. This is done in case the SNMP does become violated. If the SNMP system is violated, this
information could give clues about the company name to the violator.
The snmp-server host configuration shown in the preceding example lists the hosts to which SNMP information can be sent. If a means of collecting SNMP traps is not available, don't
configure snmp-server hosts. When using an SNMP server host, make sure that this host is configured to receive and respond to SNMP traps. Read/write community strings should not be used on networks in order to limit the risk of SNMP sets being used by unauthorized parties.
Network Time Protocol (NTP)
The Network Time Protocol (NTP) allows for time synchronization of equipment on the network. As commonly used, one router is set as the master to which other devices look for the current time. If the current time is different than the time received from the master time device, the time is adjusted accordingly. The master device also looks at a known time source. This time source may be a local device, a radio device connected locally, or a publicly available device on the Internet. Cisco's implementation of NTP allows for the delay that the packet carrying the current time experiences while crossing the Internet. By having all the devices synchronized to one clock, understanding an outage on a network is easier. By examining logs that have been time -stamped by one common time, the order in which events occurred can be determined, and the outage thus isolated to the proper culprit.
A device that uses radio to get the current time is the safest from a network security
perspective. This is illustrated in Figure 2-6. Using this method, no NTP services are expected or
accepted over the Internet.
Figure 2-6. Using NTP Through a Radio Device
If the router gets NTP times from an Internet source, as shown in Figure 2-7, you need to open
up your network to the Internet for this protocol. This is an accepted method because NTP does not usually pose a large threat to most networks. However, some precautions should be taken. When you are using NTP services, use MD5 hashing to authenticate the issuer of the
NTP packets. When you are not using NTP, specifically turn NTP off with the following interface command:
Figure 2-7. Using NTP Through a Network Device
no ntp enable
You should recommend that a single router be used to gain the current time and that internal routers look to this master for the time. This not only is the way in which NTP was designed to be used, but also exposes only a single router to any threat through NTP.
Banners
Cisco routers have two different types of banners: login and EXEC. Both of these banners should be enabled with a stern warning that all access attempts are logged, and unauthorized attempts to penetrate the system will be prosecuted to the fullest extent of the law. Placing a warning about logging all attempts at access is the equivalent of placing a home security system placard on your front lawn. Even if you do not log access, it might discourage some attempts. The name of the company, the IP address, or any other information that
unnecessarily reveals information about your system should not be included on the banner. A sample banner is as follows:
This equipment is privately owned. All access to this equipment is logged.
Disconnect immediately if you are not an authorized user. Violators will be prosecuted to the fullest extent of the law. Contact [email protected]
As with most other security settings, this banner has purposefully avoided giving any information, including using an e-mail address that will disclose no more information than absolutely necessary.