SNMPv3 is similar to SNMPv1 or SNMPv2 but has a completely different security model. SNMPv1 and SNMPv2 use a community-string that is used as the password, and there’s no authentication or encryption.
SNMPv3 is able to use both authentication and encryption and has a new security model that works with users, groups, and three different security levels. Users will be applied to a group and access policies will be applied to a group so that you can determine what groups have read or read-write access and which MIBs (Management Information Bases) they should be able to access.
SNMP offers three different security levels:
Auth stands for Authentication, and Priv for Privacy (encryption).
- noAuthNoPriv = username authentication and no encryption.
- AuthNoPriv = MD5 or SHA authentication but no encryption.
- AuthPriv = MD5 or SHA authentication AND encryption.
SNMPv1 and SNMPv2 only support noAuthNoPriv since they don’t offer any authentication or encryption. SNMPv3 supports any of the three security levels. When you decide to use noAuthNoPriv for SNMPv3 then the username will replace the community-string.
The community-string for SNMPv1 and SNMPv2 is sent in clear-text. SNMPv3 is far more secure because it doesn’t send the user passwords in clear-text but uses MD5 or SHA1 hash-based authentication, encryption is done using DES, 3DES, or AES.
Let’s take a look at a simple SNMPv3 configuration example on a Cisco IOS router.
First, we’ll create a new group and select a security model:
R1(config)#snmp-server group MYGROUP ? v1 group using the v1 security model v2c group using the v2c security model v3 group using the User Security Model (SNMPv3)
We’ll call our group “MYGROUP”, and of course, we will select SNMPv3 as the security model. The next step is to select the security level:
R1(config)#snmp-server group MYGROUP v3 ? auth group using the authNoPriv Security Level noauth group using the noAuthNoPriv Security Level priv group using SNMPv3 authPriv security level
By using the
priv parameter we will select the AuthPriv security level. There are several options for security levels:
R1(config)#snmp-server group MYGROUP v3 priv ? access specify an access-list associated with this group context specify a context to associate these views for the group match context name match criteria notify specify a notify view for the group read specify a read view for the group write specify a write view for the group <cr>
The first item is the access-list, you can use this to select what IP addresses or subnets should be permitted for users. Optionally you can select certain views:
- If you don’t specify a read view, then all MIB objects are accessible. Use this if you want to limit the number of MIBs that your NMS (Network Management Software) can monitor.
- Without a write view then nothing is writable, you will have read-only access.
- The notify view is used to send notifications to members of the group. If you don’t specify any, then it will be disabled by default.
To keep this example simple we won’t use any views for now, this means that we’ll have full read access to all MIBs:
Wonderful site. The best I have seen in a long time
Thank you Richard!
Very helpfull with complete description. Thank you Rene, I always recommend your sites to friends.
Hi, I added the command below and I can see through ‘debug snmp packet’ that the router is sending traps, but I can’t receive the traps in observium. Polling works fine, but traps don’t seem to be received.
snmp-server host 192.168.1.11 traps version 3 priv MYUSER
Do you know how to configure sending traps to observium using snmp v3?
This is Very helpful article thank you very much