SNMP v1 gained popularity in the early 1990s and quickly became the standard way to monitor network devices remotely. It was quickly discovered that SNMP v1 had some inherent security flaws, but at the time, because it was so useful and e-commerce was in its infancy, few worried about these flaws. As the Internet progressed and more servers containing sensitive information were attached, the security flaw of SNMP v1 became more problematic.

A key security flaw in SNMP v1 is that the only authentication available is through a community string. Think of a community string as a group password—anyone who knows the community string is allowed access. Adding to this problem is the fact that all SNMP v1 packets are passed unencrypted across the network. Therefore, anyone who can sniff a single SNMP packet now has the community string needed to get access.

SNMP v2 was the first attempt to fix these security flaws. However, the members of the Internet Engineering Task Force (IETF) subcommittee responsible for the v2 standard had trouble agreeing on the security and administrative aspects of the protocol. Therefore, SNMP v2 never really took off. The only prevalent version of SNMP v2 today is SNMP v2c, which contains SNMP v2 protocol enhancements, but leaves out the security features that no one could agree on. The c designates v2c as being “community based,” which means that it uses the same authentication mechanism as v1—community strings.

SNMP v3 was the next attempt to fix the security vulnerabilities inherent to SNMP v1 and v2c. SNMP v3 provides many security enhancement, but is currently still a draft-standard and not yet a full standard. This has kept many vendors from implementing SNMP v3 or caused them to develop proprietary versions of SNMP v3. The key security additions to SNMP v3 are that it:

SNMP v3 allows you to choose to use no authentication and no encryption (NoAuthNoPriv), authentication but no encryption (AuthNoPriv), or authentication and encryption (AuthPriv). See Table 8-1 for a comparison of SNMP version features.

If you are new to SNMP, start with SNMP v1 to learn how SNMP works. On smaller, low-risk networks, SNMP v1 or v2c can be used regularly if community strings are changed and access is restricted to specific IP addresses. On larger, more sensitive networks, however, It is recommended that you use either SNMP v3 with encryption and authentication or IPSec to encrypt the SNMP v1 traffic between your routers and management stations.

Despite the benefits of SNMP v3, you will face some significant hurdles in its implementation. First, very few vendors who sell software for SNMP management stations currently support SNMP v3. Second, SNMP v3 uses Data Encryption Standard (DES) encryption, which many security professionals consider to be too weak to be effective for high-security networks.

First, for security reasons, it is strongly recommended that you disable SNMP v1 and v2c on all your routers. SNMP v3 is much better suited for secure enterprise-wide use. However, if SNMP v1 or v2 must be used, then the following security precautions must be taken:

The rest of this section discusses how to accomplish these tasks and make SNMP v1 and v2c as secure as possible.

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#snmp-server community UnGuessableStringReadOnly  RO
Router(config)#^Z

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#snmp-server community UnGuessableStringWriteable RW
Router(config)#^Z

Disabling SNMP can be done entirely with the command no snmp-server. Use the following example to specifically disable read/write or read-only access.

Router#config terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#no snmp-server community UnGuessableStringReadOnly  RO Router(config)#^Z

Router#config terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#no snmp-server community UnGuessableStringWriteable  RW
Router(config)#^Z

You should always limit SNMP access to only a few specific IP addresses; this is especially true when using SNMP v1 and v2c. To do this:

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#access-list 6  permit 130.218.10.8
Router(config)#access-list 6  permit 130.218.14.7
Router(config)#access-list 6  deny any
Router(config)#snmp-server community UnGuessableStringReadOnly  RO 6
Router(config)#^Z

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#access-list 8  permit 130.218.10.8
Router(config)#access-list 8  permit 130.218.14.7
Router(config)#access-list 8  deny any
Router(config)#snmp-server community UnGuessableStringWriteable  RW 8
Router(config)#^Z

There is a major security risk associated with SNMP read/write access that involves TFTP. When SNMP read/write access is enabled, attackers can use SNMP to cause the router to either TFTP its configuration file to them, or even have the router load a new configuration from an arbitrary TFTP server. To avoid this problem, it is important to use the snmp-server tftp-server-list command to limit what IP addresses are allowed to use TFTP servers via SNMP.

The following example shows how to use an ACL to restrict SNMP-controlled TFTP access to the IP 130.8.4.9:

RouterOne#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
RouterOne(config)#access-list 98  permit host 130.8.4.9
RouterOne(config)#access-list 98  deny any     
RouterOne(config)#snmp-server tftp-server-list 98
RouterOne(config)#^Z

If you don’t use TFTP, then create an empty ACL and apply it. Since ACLs are default deny, this will keep anyone from using SNMP and TFTP to manipulate your router.

Another way to help secure SNMP v1 and v2c is to limit what information remote systems can see. This is extremely useful when only specific information is needed through SNMP. To use views:

The snmp-server view command takes three arguments. The first is the name you want to call the view, then the table name or MIB Object Identifier (OID), and finally the keyword include or exclude. If you know SNMP well, you can create advanced lists by using the OID numbers. If you’re not an SNMP expert, you can use table names such as IP, ICMP, TCP, SYSTEM, INTERFACES, and so on. Like access lists, the default policy of a view is to deny access and not return any data. The following example creates a view called tcp-only that allows access to the MIB objects only under the TCP table:

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#snmp-server view tcp-only  tcp include
Router(config)#snmp-server community TcpOnlyCommunityString  view tcp-only
Router(config)#^Z

Now, when you attempt to get SNMP information from the router using the TcpOnlyCommunityString command, you see only the information in the TCP table:

% snmpwalk -v1 RouterOne TcpOnlyCommunityString
tcp.tcpRtoAlgorithm.0 = vanj(4)
tcp.tcpRtoMin.0 = 300 milliseconds
tcp.tcpRtoMax.0 = 60000 milliseconds
tcp.tcpMaxConn.0 = -1
tcp.tcpActiveOpens.0 = 0
tcp.tcpPassiveOpens.0 = 2
tcp.tcpAttemptFails.0 = 0
tcp.tcpEstabResets.0 = 0
tcp.tcpCurrEstab.0 = Gauge: 1
tcp.tcpInSegs.0 = 3698
tcp.tcpOutSegs.0 = 2549
tcp.tcpRetransSegs.0 = 1
tcp.tcpConnTable.tcpConnEntry.tcpConnState.130.218.9.50.23.130.218.59.1.64880 
= established(5)
tcp.tcpConnTable.tcpConnEntry.tcpConnLocalAddress.130.218.9.50.23.130.218.9.41.64880 
= IpAddress: 130.218.59.250
tcp.tcpConnTable.tcpConnEntry.tcpConnLocalPort.130.218.9.50.23.130.218.9.41.64880 
= 23
tcp.tcpConnTable.tcpConnEntry.tcpConnRemAddress.130.218.9.50.23.130.218.9.41.64880 
= IpAddress: 130.218.59.41
tcp.tcpConnTable.tcpConnEntry.tcpConnRemPort.130.218.9.50.23.130.218.9.41.64880 
= 64880
tcp.tcpInErrs.0 = 0
tcp.tcpOutRsts.0 = 0
End of MIB

Table 8-2 contains some useful keywords for creating views.

Finally, one of the most useful features of SNMP views is its ability to limit SNMP write access in addition to limiting read-only access.

The least-secure method of SNMP v3 uses no authentication and no encryption. This is referred to as NoAuthNoPriv. With this type of SNMP v3 packet, the only type of access control is through a username. To configure SNMP v3 NoAuthNoPriv access on a router, you must:

The snmp-server group command can take many different arguments, depending on how you want the group set up. The first two arguments indicate the name of the group and the SNMP version of the group. Additional arguments can specify access lists, restricted views, or authentication and encryption methods. In the following example, the v3 indicates SNMP v3 and noauth indicates that no authentication or encryption is to be used.

The snmp-server user command also takes various arguments. The first three are the name of the user, the name of the group that user belongs to, and the SNMP version that user runs. Additional arguments specify authentication and encryption information:

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#snmp-server group NoAuthGroup  v3 noauth                    
Router(config)#snmp-server user MyUser1 NoAuthGroup  v3 
Router(config)#^Z

Now you can use unauthenticated and unencrypted SNMP to access information about the router by specifying user MyUser1:

% snmpwalk -v 3 -l NoAuthNoPriv -u MyUser1 RouterOne
system.sysDescr.0 = Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-IS56I-M), Version 12.1(1), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 15-Mar-00 03:45 by cmong
system.sysObjectID.0 = OID: enterprises.9.1.208
system.sysUpTime.0 = Timeticks: (888383) 2:28:03.83
system.sysContact.0 = 
system.sysName.0 = RouterOne.kennesaw.edu
[ cut ]

Using no authentication and no encryption (NoAuthNoPriv) means that you are still vulnerable to someone sniffing your username and gaining SNMP access. If you are going to use SNMP v3, it is recommended that you use both authentication and encryption (AuthPriv).

The level of protection above a simple username is authentication. This is the AuthNoPriv level in which users are securely authenticated, but packets are still passed unencrypted. This level allows you to specify a different username and password for every user who requires SNMP access, giving you the accountability that you lack when using just a community string.

To configure SNMP v3 authentication, you must:

Now you can access the SNMP v3 information only by successfully authenticating yourself with the username MyUser2 and the password MyAuthPassword. Even though you are authenticating, you are still not using encryption and are at the AuthNoPriv level:

% snmpwalk -v 3 -u MyUser2
 -l AuthNoPriv -A MyAuthPassword RouterOne
system.sysDescr.0 = Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-IS56I-M), Version 12.1(1), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 15-Mar-00 03:45 by cmong
system.sysObjectID.0 = OID: enterprises.9.1.208
system.sysUpTime.0 = Timeticks: (1008588) 2:48:05.88
system.sysContact.0 = 
system.sysName.0 = RouterOne.kennesaw.edu
[ cut ]

Finally, there is the AuthPriv level, which uses both strong authentication and encryption. This level is the most appropriate level to use on secure networks. SNMP v3 requires separate passwords for authentication and encryption for each username. To configure a user to use authentication and encryption:

When you request SNMP v3 information from the router, you must use the correct username, authentication password, and encryption password. When you do, all communication is encrypted:

% snmpwalk -v 3 -u MyUser3 -l authpriv -A AuthPass -X PrivPass RouterOne
system.sysDescr.0 = Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-IS56I-M), Version 12.1(1), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 15-Mar-00 03:45 by cmong
system.sysObjectID.0 = OID: enterprises.9.1.208
system.sysUpTime.0 = Timeticks: (1008588) 2:48:05.88
system.sysContact.0 = 
system.sysName.0 = RouterOne.kennesaw.edu
[ cut ]

You can also use ACLs with SNMP v3 to further enhance your security. You can specify an access list at the group or user level. In either case, add the keyword access followed by the restricting ACL to any of the preceding snmp-server group or user commands.

The following example:

Limiting IP addresses on a per-user basis is similar:

Views can be applied to SNMP v3 groups, but not directly to users. The process is similar to creating views for SNMP v1 and v2c. When creating a group that restricts information with views, use the read or write keywords to indicate whether the view applies to read-only access or read/write access.

The following example restricts all the members of group IpOnly to viewing the IP information (but nothing else):

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#snmp-server view IpOnlyView ip  include
Router(config)#snmp-server group IpOnly  v3 noauth read IpOnlyView
Router(config)#snmp-server user heather IpOnly  v3 
Router(config)#^Z

Now when Heather uses SNMP v3 to access the router, she will only get information about the IP protocol.

Finally, you can combine views and access lists. This example creates a group that restricts access to the single IP 130.218.250.5 and allows read-only access to the interface information and nothing more:

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#access-list 10  permit 130.218.250.5
Router(config)#access-list 10  deny any
Router(config)#snmp-server view IntView interface  include
Router(config)#snmp-server group IntGroup  v3 auth read IntView  access 10
Router(config)#snmp-server user bob IntGroup  v3 auth md5 BobsPass
Router(config)#^Z