Sunday, September 16, 2012

SNMPv3 Configuration Basics on IOS

I was asked to assemble the configuration for SNMPv3 to be applied to our demo center. The requirements were that we use SNMPv3 with authPriv security level. Configuring SNMP communities (version 2c) is very straight forward and also very well known. The concerns that I have heard about SNMPv3 is that it is difficult to configure. I am not convinced so lets take a look.

A basic background...

SNMPv3 is based on a USM (User Security Model) meaning all security levels associated with the solution are based on the creation of an SNMP user in one form or another. OK. So what are the security levels and what do they mean?

  1. noAuthNoPriv - This security level simply means that there is no authentication password exchanged and the communications between the agent and the server are not encrypted. The SNMP requests are authorized based on a simple username string match.
  2. authNoPriv - password authentication is used based on either MD5 or SHA hash authentication and no encryption is used for communications between the devices.
  3. authPriv - authentication is hash based the same as #2 but the communications between the agent and the server are also encrypted. the encryption of the traffic between the two nodes will required a crypto software image on the devices.
That seems pretty simple.

The SNMP user provides the mechanism for authenticating the session where the SNMP group is utilized to control what the user can access.

SNMP views can be created to include or exclude various portions of the MIBs. These SNMP views are then associated with the SNMP groups. Users are associated with groups.


The security level noAuthNoPriv is actually very similar to the communities that we are used to already. They use the simple string match so the username is analogous to the community in this case. You can restrict who can access the device with that username via access lists just like communities and what they can access with customized SNMP views.

So how is v3 better? The enhancements are evident in the other security levels (authNoPriv and authPriv) that add a hash based password exchange and potentially encrypt the communications.

The configurations for SNMPv3 are actually very simple and straight forward. I will demonstrate the basic configurations and also how you can easily validate what you have done to ensure all is working as you intended.

Environment

I will utilize a simple single router in GNS3 connected to by local machine via a loopback interface. Validation tests will utilize a simple SNMP get request using snmpwalk and the OID = .1.3.6.1.4.1.9.3.6.5.0 which will display the IOS version information for the router.

basic-net-topology
Basic Network Configuration

Note: Syntax will vary from platform to platform by the concepts will remain the same.


Let's Go

noAuthNoPriv

Steps:

  1. Create an SNMPv3 Group
  2. Create an SNMPv3 User
  3. Validate noAuthNoPriv
Here are the router commands that I entered:

snmp-server group noAuthNoPriv v3 noauth

snmp-server user noAuthNoPriv noAuthNoPriv v3

The group parameters used specify the name of the group (noAuthNoPriv), the security model (v3) and the security level (noauth).

The user command then specifies the username (noAuthNoPriv), the group name to associate this user with (noAuthNoPriv) and the security model (v3).

Here is the snmpwalk command used for validation:

snmpwalk -v3 -u noAuthNoPriv 10.254.254.253 .1.3.6.1.4.1.9.3.6.5.0



Command line switches
-u = username

AuthNoPriv

  1. Create an SNMPv3 Group
  2. Create an SNMPv3 User
  3. Validate authNoPriv
Here are the commands that I entered on the router:

snmp-server group authNoPriv v3 auth
snmp-server user authNoPriv authNoPriv v3 auth md5 test1234


The group command used here has the same commandline parameters as the first example, but we have changed from noauth to auth. This means that the users associated with this group will be required to authenticate before accessing the permitted MIBs.

The additional options on the username specify that authentication protocol MD5 will be used and the password of test1234. Passwords of less an 8 characters will be rejected during the snmp request although the command would be allowed in the CLI.

Here is the snmpwalk validation command that I will use to test:
snmpwalk -v3 -u authNoPriv -A test1234 -l authNoPriv -a MD5 10.254.254.253 .1.3.6.1.4.1.9.3.6.5.0

Command line switches
-u = username
-A = password
-l = security level
-a = authentication protocol



Success!

authPriv

  1. Create an SNMPv3 Group
  2. Create an SNMPv3 User
  3. Validate authPriv
Here are the router commands that were entered:

snmp-server group authPriv v3 priv

snmp-server user authPriv authPriv v3 auth md5 test1234 priv des56 test1234

This final example is using the most secure security model and level. The group command option, priv, indicates the authPriv security level.

The new options on the user command here configure this user for priv security level with des56 encryption and a passphrase of test1234. This additional configuration is what requires encryption of the messages between the SNMP agent and management station.

Here is the snmpwalk command used for validation:


snmpwalk -v3 -u authPriv -A test1234 -l authPriv -a MD5 -x DES -X test1234 10.254.254.253 .1.3.6.1.4.1.9.3.6.5.0

Command line switches


-u = username
-A = password
-l = security level
-a = authentication protocol
-x = encryption protocol
-X = privacy passphrase used for encryption



Success!

Conclusion

Configuring SNMPv3 versus SNMPv2c is highly recommended due the increased security capabilities. Since the configurations are very straight forward, there is no reason not to.





Additional Reading

http://www.cisco.com/en/US/docs/ios-xml/ios/snmp/configuration/12-4t/nm-snmp-cfg-snmp-support.html

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en

http://www.net-snmp.org/docs/man/snmpwalk.html

8 comments:

  1. I hadn't seen any snmp guides using snmpv3 and scp as transport protocol. For those looking to implement, here is what worked for me.

    As with the other snmp config copy guides you will need to download the respective MIBS and load them in the snmp.conf file.

    This post will specifically cover the snmpset commands for a v3 setup.

    SNMP Environment:

    Name : net-snmp
    Version : 5.7.2
    Release : 17.fc20


    snmp conf file in ~/.snmp/snmp.conf

    contains

    defSecurityName XXX <- replace with v3 username
    defContext ""
    defAuthType SHA
    defPrivType AES
    defSecurityLevel authPriv
    defAuthPassphrase ***** <-replace with authentication pass
    defPrivPassphrase ***** <-replace with encryption pass
    defVersion 3
    showMibErrors no
    mibs ALL

    I would verify basic snmpv3 functionality with a snmpwalk of something simple like sysUpTime. When that's good proceed to the CONFIG-COPY snmp commands.



    This is my bash script that does the entire copy asking only for a single argument of IP/Hostname of the device being backed up. The 2>/dev/null shown in the script or at the cli below redirects STDERR to null to avoid the MIB modules parsing errors.

    #!/usr/bin/bash
    DEVICE=$1
    RANNUM=42
    USER=******
    PASS=******
    SERVER=X.X.X.X
    DATE=$(date +"%m_%d_%y")

    snmpset $DEVICE ccCopyProtocol.$RANNUM i 4 ccCopySourceFileType.$RANNUM i 4 ccCopyDestFileType.$RANNUM i 1 ccCopyServerAddress.$RANNUM a "$SERVER" ccCopyFileName.$RANNUM s "$DEVICE.$DATE" ccCopyUserName.$RANNUM s $USER ccCopyUserPassword.$RANNUM s $PASS ccCopyEntryRowStatus.$RANNUM i 4 2>/dev/null



    Once run you can check the status of the copy with the following command.

    [root@localhost hlsb]# snmpwalk sbs-tech-switch ciscoConfigCopyMIB 2>/dev/null
    CISCO-CONFIG-COPY-MIB::ccCopyProtocol.42 = INTEGER: scp(4)
    CISCO-CONFIG-COPY-MIB::ccCopySourceFileType.42 = INTEGER: runningConfig(4)
    CISCO-CONFIG-COPY-MIB::ccCopyDestFileType.42 = INTEGER: networkFile(1)
    CISCO-CONFIG-COPY-MIB::ccCopyServerAddress.42 = IpAddress: 10.10.10.193
    CISCO-CONFIG-COPY-MIB::ccCopyFileName.42 = STRING: sbs-tech-switch.07_09_14
    CISCO-CONFIG-COPY-MIB::ccCopyUserName.42 = STRING: XXXX
    CISCO-CONFIG-COPY-MIB::ccCopyUserPassword.42 = STRING: XXXX
    CISCO-CONFIG-COPY-MIB::ccCopyNotificationOnCompletion.42 = INTEGER: false(2)
    CISCO-CONFIG-COPY-MIB::ccCopyState.42 = INTEGER: successful(3)
    CISCO-CONFIG-COPY-MIB::ccCopyTimeStarted.42 = Timeticks: (52270199) 6 days, 1:11:41.99
    CISCO-CONFIG-COPY-MIB::ccCopyTimeCompleted.42 = Timeticks: (52270339) 6 days, 1:11:43.39
    CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.42 = INTEGER: active(1)
    CISCO-CONFIG-COPY-MIB::ccCopyServerAddressType.42 = INTEGER: ipv4(1)
    CISCO-CONFIG-COPY-MIB::ccCopyServerAddressRev1.42 = STRING: "10.10.10.193"



    After the successful copy completes the entry will exist for five minutes allowing for no further requests to be made with that particular random number. To send another request prior to the five minute clearing of the table send a "destroy" snmpset to clear the entry.



    [root@localhost hlse]# snmpset sbs-tech-switch CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.42 i 6 2>/dev/null
    CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.42 = INTEGER: destroy(6)



    Hope this will save some time for those looking to implement a more secure snmp config copy setup.

    V/R

    Cody Hartley

    ReplyDelete
  2. Wow, I really love your post and what you share with us is updated and quite informative. The visa to Turkey is completely open now and you can take advantage of the Turkey visa facility and Explore the Turkey like a local .

    ReplyDelete