One of our students asked me for a concise example of SNMPv3. James, here you go! This blog has examples and explanations of the features used in SNMPv3.
Older versions of SNMP didn’t provide all the features of SNMPv3. V3 supports a User-based Security Model (USM) for authentication, and a View-based Access Control Model (VACM) to control what that user account may access. Of course the user accounts don’t represent end users, they are just the configuration elements we configure on the SNMP devices, primarily for creating the connection to or from the SNMP device.
With version 3 we may use the following methods:
)
To set up traps and informs, we can use the syntax below. Note that the traps are being sent using an account that doesn’t use MD5 authentication, or encryption, based on the user account configured to send it. The inform destination is using an account that uses authentication, but not encryption. A better use would be to include authentication and encryption, using an account that is assigned to groupfive. The SNMP manager would need to be properly configured with the correct user account information to receive these traps and inform PDUs. The parameters at the end of the command indicate what will trigger the traps/informs.
Older versions of SNMP didn’t provide all the features of SNMPv3. V3 supports a User-based Security Model (USM) for authentication, and a View-based Access Control Model (VACM) to control what that user account may access. Of course the user accounts don’t represent end users, they are just the configuration elements we configure on the SNMP devices, primarily for creating the connection to or from the SNMP device.
With version 3 we may use the following methods:
- noAuthNoPriv: requires username, but no MD5 validation of that user, and no encryption
- authNoPriv: requires username, provides MD5 validation, but no encryption
- authPriv: You guessed it. Requires username, uses MD5 validation, and encrypts too.
)R1(config)#snmp-server engineID local badf00dbabeNext we can define a view that specifies what may be managed (VACM, see above). In this example, the two views refer to mib-2 and Cisco object IDs respectively.
R1(config)#snmp-server view MYVIEW mib-2 included R1(config)#snmp-server view MYVIEWRW cisco includedSo far, these views are not worth much, as they are just sitting in the config, and not being called on. We can verify the views exist, and also see the other default views present on the router.
R1#show snmp view *ilmi system - included permanent active *ilmi atmForumUni - included permanent active MYVIEW mib-2 - included nonvolatile active MYVIEWRW cisco - included nonvolatile active v1default iso - included permanent active v1default internet.6.3.15 - excluded permanent active v1default internet.6.3.16 - excluded permanent active v1default internet.6.3.18 - excluded permanent active v1default ciscoMgmt.394 - excluded permanent active v1default ciscoMgmt.395 - excluded permanent active v1default ciscoMgmt.399 - excluded permanent active v1default ciscoMgmt.400 - excluded permanent activeLet’s set up some groups and users, so that a remote SNMP manager may get information from this router and/or configure via SNMP. We have options. If we want to allow the manager station to request data, but not require a MD5 hash validation of the user, nor require encryption for the SNMP traffic, we could create a group that doesn’t require MD5 authentication nor encryption. The group and user that we might put in this group may look like this:
R1(config)#snmp-server group groupone v3 noauth read MYVIEW R1(config)#snmp-server user keith groupone v3 Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...Note, this would not be much better than SNMPv1, with simple plain text passwords. To verify the group and user, we can use a few simple show commands.
R1#show snmp group groupname: ILMI security model:v1 readview : *ilmi writeview: *ilmi notifyview: row status: active groupname: ILMI security model:v2c readview : *ilmi writeview: *ilmi notifyview: row status: active groupname: groupone security model:v3 noauth readview : MYVIEW writeview: notifyview: row status: active R1#show snmp user User name: keith Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: None Privacy Protocol: None Group-name: grouponeNext, we create another group, still with NO authentication or encryption, but we will add the ability to write via SNMP based on the view named MYVIEWRW.
R1(config)#snmp-server group grouptwo v3 noauth read MYVIEW write MYVIEWRW R1(config)#snmp-server user anthony grouptwo v3Notice, the show group and user commands include both users and groups. Grouptwo has a writeview specified, just as we configured it.
R1#show snmp group <snip> groupname: groupone security model:v3 noauth readview : MYVIEW writeview: notifyview: row status: active groupname: grouptwo security model:v3 noauth readview : MYVIEW writeview: MYVIEWRW notifyview: row status: active R1#show snmp user <snip> User name: anthony Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: None Privacy Protocol: None Group-name: grouptwoNow, lets add some MD5 authentication . No encryption yet, but we are making progress over groupone and grouptwo.
R1(config)#snmp-server group groupthree v3 auth read MYVIEW R1(config)#snmp-server user marvin groupthree v3 auth md5 marvin-passwdNotice in the show command, that the new group includes “auth”. We are beginning to use the features that makes SNMPv3 desireable.
R1#show snmp group groupname: groupone security model:v3 noauth readview : MYVIEW writeview: notifyview: row status: active groupname: grouptwo security model:v3 noauth readview : MYVIEW writeview: MYVIEWRW notifyview: row status: active groupname: groupthree security model:v3 auth readview : MYVIEW writeview: notifyview: row status: active R1#show snmp user <snip> User name: marvin Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: None Group-name: groupthree R1#Now, we will add a group and user, that leverages the authentication and encryption.
R1(config)#snmp-server group groupfour v3 priv read MYVIEW R1(config)#snmp-server user scott groupfour v3 auth md5 scott-passwd priv des crypt-key R1#show snmp group groupname: groupfour security model:v3 priv readview : MYVIEW writeview: notifyview: row status: active R1#show snmp user User name: scott Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: DES Group-name: groupfour R1#Our final group and user will use authentication and encryption, along with the ability to write to the SNMP device based on the view MYVIEWRW. This is the most secure of all the examples shown here.
R1(config)#snmp-server group groupfive v3 priv read MYVIEW write MYVIEWRW R1(config)#snmp-server user petr groupfive v3 auth md5 peter-passwd priv 3des crypt-key R1#show snmp group <snip> groupname: groupfive security model:v3 priv readview : MYVIEW writeview: MYVIEWRW notifyview: row status: active R1#show snmp user User name: petr Engine ID: BADF00DBAB0E storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: 3DES Group-name: groupfive R1#SNMPv3 has the ability to communicate via TRAPs and INFORMs. A TRAP is an SNMP message sent from one application to another, probably the manager station. Unfortunately, TRAPs are not acknowledged so the router doesn’t know if the remote device received it. SNMPv2 and v3 may use an INFORM, which is nothing more than an acknowledged TRAP.
To set up traps and informs, we can use the syntax below. Note that the traps are being sent using an account that doesn’t use MD5 authentication, or encryption, based on the user account configured to send it. The inform destination is using an account that uses authentication, but not encryption. A better use would be to include authentication and encryption, using an account that is assigned to groupfive. The SNMP manager would need to be properly configured with the correct user account information to receive these traps and inform PDUs. The parameters at the end of the command indicate what will trigger the traps/informs.
R1(config)#snmp-server host 10.0.0.100 version 3 noauth keith snmp ipsla hsrp cpu R1(config)#snmp-server host 10.0.0.100 informs version 3 auth marvin cpu syslogNote: Any names used in the demonstration are purely intentional. Thanks to some of my fellow CCIE comrades, namely Anthony, Marvin, Scott and Petr.
0 comments:
Post a Comment