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 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(config)#snmp-server view MYVIEWRW cisco included
R1#show snmp viewLet’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:
*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 active
R1(config)#snmp-server group groupone v3 noauth read MYVIEWNote, 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(config)#snmp-server user keith groupone v3
Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...
R1#show snmp groupNext, 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.
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: groupone
R1(config)#snmp-server group grouptwo v3 noauth read MYVIEW write MYVIEWRWNotice, the show group and user commands include both users and groups. Grouptwo has a writeview specified, just as we configured it.
R1(config)#snmp-server user anthony grouptwo v3
R1#show snmp groupNow, lets add some MD5 authentication . No encryption yet, but we are making progress over groupone and grouptwo.
<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: grouptwo
R1(config)#snmp-server group groupthree v3 auth read MYVIEWNotice in the show command, that the new group includes “auth”. We are beginning to use the features that makes SNMPv3 desireable.
R1(config)#snmp-server user marvin groupthree v3 auth md5 marvin-passwd
R1#show snmp groupNow, we will add a group and user, that leverages the authentication and encryption.
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#
R1(config)#snmp-server group groupfour v3 priv read MYVIEWOur 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 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#
R1(config)#snmp-server group groupfive v3 priv read MYVIEW write MYVIEWRWSNMPv3 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.
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#
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 cpuNote: Any names used in the demonstration are purely intentional. Thanks to some of my fellow CCIE comrades, namely Anthony, Marvin, Scott and Petr.
R1(config)#snmp-server host 10.0.0.100 informs version 3 auth marvin cpu syslog
0 comments:
Post a Comment