Simple Network Management Protocol (SNMP)
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 equipment 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:
This command replaces the older and no longer valid command:
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 offers. 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.