blog
    Is this a Trap? SNMPv3
    22 March 10

    Is this a Trap? SNMPv3

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    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:

    1. noAuthNoPriv: requires username, but no MD5 validation of that user, and no encryption
    2. authNoPriv: requires username, provides MD5 validation, but no encryption
    3. authPriv: You guessed it. Requires username, uses MD5 validation, and encrypts too.

    Let’s configure the router to support a SNMPv3 manager who will be communicating with it. First, we assign an engineID. This is optional, as the router would have automatically assigned one, but helpful due to the fact that we may need to configure the engineID on the remote manager and by hard coding it on the router we will know what the value is beforehand. (Note: the 00 in food, are Zero Zero, as the engineID is in hexadecimal. :) )

    R1(config)#snmp-server engineID local badf00dbabe

    Next 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 included

    So 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 active

    Let’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: groupone

    Next, 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 v3

    Notice, 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: grouptwo

    Now, 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-passwd

    Notice 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 syslog

    Note:  Any names used in the demonstration are purely intentional.   Thanks to some of my fellow CCIE comrades, namely Anthony, Marvin, Scott and Petr.

    Thanks again James for your request, and best wishes to all in your studies.

     

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo