HowTo Enable SNMP with Security

A Cisco router capable of running SNMPv3 allows for more security measures to be applied. It is a good idea to disable the public community string. Then an access control list needs to be created to limit machine access to the router (through SNMP).

More than one machine may be added on the access-list. Following is an example that does this.

East# config t

Enter configuration commands, one per line. End with CNTL/Z

East(config)# no snmp-server community publicstring
East(config)# ! create access list to use later
East(config)# access-list 20 permit 14.2.6.6
East(config)# exit

After these commands, SNMP is still enabled but no one has access to the MIB because the community string, which solely defined access to the MIB, is disabled. A better method to allow access to the MIB is to use strict controls. Limited access may be given to the MIB by defining groups, users and MIB views. A MIB view defines a portion of the MIB that a user or group may see/modify provided they have the appropriate credentials. First, a group must be defined by specifying a group name, the version of SNMP and the security model desired. A specific SNMP MIB view, as well as the access to that view may also be defined. If this MIB view is not specified the default is to have access to basically the whole MIB. The second step is to add users to the group. Then a MIB view should be defined to either include specific MIB branches or exclude specific MIB branches.

The following example defines a non-privileged user, “jdoe”, who is a member of the “publicUser” group. This group has read access to the “sysonly” view, which is the “system” branch of the MIB. This branch contains useful information and is beneficial for users to have access to. No community string is required; instead authentication is based on the user name. This is an example of a noAuthNoPriv security model. The following example also introduces two new commands used to verify that the new groups and users have been added correctly.

East# config t

Enter configuration commands, one per line. End with CNTL/Z

East(config)# snmp-server group publicUser v3 noauth read sysonly
East(config)# snmp-server user jdoe publicUser v3
East(config)# snmp-server view sysonly system included
East(config)# exit
East#
East# show snmp group

groupname: publicUser

security model:v3 noauth

readview :sysonly

writeview:
notifyview:
row status: active
East#
East# show snmp user
User name: jdoe
Engine ID: 00000009020000500F033680
storage-type: nonvolatile
active
East#
East# show snmp
view sysonly system - included nonvolatile active
East#

The more secure model implemented is authNoPriv. This security model uses MD5 or SHA to hash the community string. The steps to support this security model are similar to the steps in supporting the noAuthNoPriv model. First, a group must be defined. Then users must be added to the group with a password string. This string may be hashed using MD5 or SHA. Then the MIB view is defined. A MIB view may be defined by more than one included/excluded statement to restrict the view to the appropriate MIB branches.

The following example defines a privileged user, “root” who uses MD5 for authentication. This means that when user “root” tries to access/modify MIB data, his community string “secret” will be hashed and then sent across the network. This makes it harder to compromise the community string. User “root” is a member of the “administrator” group. In this example, members of the administrator group have restricted read and write access, defined by the view “adminview”, to the MIB. This view gives access to all parts of the MIB except the branches that display routing information. So, even if the community string is somehow compromised, the routing tables are not accessible remotely. Likewise, the routing tables are not permitted to be modified remotely. Of course, while not shown, it is always a good idea to use the show commands to verify the new settings.


East# config t

Enter configuration commands, one per line. End with CNTL/Z

East(config)# snmp-server group administrator v3 auth read adminview write adminview
East(config)# snmp-server user root administrator v3 auth md5 “secret” access 20
East(config)# snmp-server view adminview internet included
East(config)# snmp-server view adminview ip.ipAddrTable excl
East(config)# snmp-server view adminview ip.ipRouteTable excl
East(config)# exit


The examples above showed some basic rules that should be followed when configuring SNMP on a router. Access-lists, users, groups and views must be defined to control access to the MIB. While SNMP is helpful because it allows an admin to remotely configure the router, it also provides a potentially dangerous conduit into a network.


biOos