Using Access Lists to Protect SNMP Access

Using Access Lists to Protect SNMP Access

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.

See Also