Using Access Lists to Protect SNMP Access | Simple Network Management Protocol

Problem

You want to provide extra security to SNMP using access lists.

Solution

You can use the following commands to restrict which IP source addresses are allowed to access SNMP functions on the router. This is the legacy method:

Router#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#access-list 99 permit 172.25.1.0 0.0.0.255
Router(config)#access-list 99 permit host 10.1.1.1 
Router(config)#access-list 99 deny any 
Router(config)#snmp-server community ORARO ro 99
Router(config)#access-list 98 permit 172.25.1.0 0.0.0.255 
Router(config)#snmp-server community ORARW rw 98
Router(config)#end
Router#

Here is a newer method to do the same thing using SNMP server groups:

Router#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#access-list 99 permit 172.25.1.0 0.0.0.255
Router(config)#access-list 99 permit host 10.1.1.1 
Router(config)#access-list 99 deny any 
Router(config)#snmp-server group COOKRO v1 access 99
Router(config)#snmp-server user TESTRO1 COOKRO v1 
Router(config)#end
Router#

Beginning with IOS Version 12.3(2)T, support for standard named access lists was added:

Router2#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#ip access-list standard SNMPACL  
Router2(config-std-nacl)#permit 172.25.1.0 0.0.0.255 
Router2(config-std-nacl)#permit host 10.1.1.1 
Router2(config-std-nacl)#deny any 
Router2(config-std-nacl)#snmp-server community ORARO1 ro SNMPACL
Router2(config)#end
Router2#

Discussion

By default, when you enable inbound SNMP services, the router will permit all IP addresses to access the SNMP agent on the standard well-known UDP port number 161. We highly recommend using SNMP ACLs to restrict SNMP access to a few trusted hosts or subnets. This will help to protect sensitive data.

You could restrict SNMP access by simply applying an interface ACL to block incoming SNMP packets that don't come from trusted servers. However, this would not be as effective as using the global SNMP commands shown in this recipe. Because you can apply this method once for the whole router, it is much simpler than applying ACLs to block SNMP on all interfaces separately. Also, using interface ACLs would block not only SNMP packets intended for this router, but also may stop SNMP packets that just happened to be passing through on their way to some other destination device.

Despite the different syntax, all of the examples shown in this recipe work the same way. First, you define a standard access-list. Then you apply this access-list to your SNMP community string. You can assign each SNMP community a separate and unique access-list to restrict access. This can be useful when there are several different people or NMS systems that need to access information on different groups of routers. You can also assign an access-list to a read-write community string to block SNMP set commands from unauthorized IP source addresses.

SNMP access-lists alone are not an effective way of protecting read-write access to your routers. Because SNMP is a UDP protocol, a rogue device with access to your network can spoof the IP source address so that it matches the IP address of your management server. This means that somebody who knows your community string and the IP address of your management server can submit potentially dangerous SNMP set commands to your router. This information is relatively easy to discover with a protocol analyzer on a well-chosen network segment because SNMP sends packets in clear text.

Applying a nonexistent access-list to your SNMP configuration commands implicitly allows all IP source addresses to access your router's SNMP services. Always ensure that the access-list exists before applying it to an SNMP community string.

The following command shows the status of a particular access-list:

Router#show access-list 99
Standard IP access list 99
 permit 10.1.1.1 (1745 matches)
 permit 172.25.1.0, wildcard bits 0.0.0.255 (477 matches)
 deny any (7 matches)
Router#

Notice that the router has denied seven requests. This means that the router received and discarded seven SNMP requests because source addresses were not allowed. Although the router automatically appends an implicit "deny all" to the end of every access-list, we recommend that you explicitly include a "deny all" statement at the end of each access-list to let you keep track of denied packets like this. It is an easy way of telling how often your routers receive SNMP requests from bad source addresses.

The show snmp group command shows you which access-lists are assigned to which SNMP community strings:

Router>show snmp group
groupname: ORARO security model:v1 
readview :v1default writeview:  
notifyview: 
row status: active access-list: 99

groupname: ORARW security model:v1 
readview :v1default writeview: v1default 
notifyview: 
row status: active access-list: 98

groupname: ORARO1 security model:v1 
readview : v1default writeview:  
notifyview:  
row status: active access-list: SNMPACL

Router>

In this example, the SNMP community string ORARO is protected by access-list 99, the SNMP community string ORARW is protected by access-list 98, and the SNMP community ORARO1 is protected by the named access-list SNMPACL. Note that the show snmp group command is available only in 12.0(3)T and above.