Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Network + Systems Management
W O R K S H O P  
Simplifying SNMPv3

  September 18, 2003
  By Bruce Boardman


>> continued from previous page

Hands On Experience

TOC Issue TOC
Printer Print full article
Printer Print this page
Printer Download as PDF
E-Mail E-Mail this URL
Discuss Discuss this article
flame author Flame the author
 
  In this article
arrow
Introduction
arrow
Feeling Secure
arrow
Hands On Experience

You can't set up SNMPv3 security using SNMP, so how do you get started? We ran through basic version 3 configuration on some devices in Network Computing's Real-World Labs®at Syracuse University, and found that configuring more than two devices for SNMPv3 was way too much work and prone to errors. Although devices like routers and switches have the SNMP hooks to support USM authentication and encryption and VACM access control, the management applications still have to be configured manually.

First you create a "view" of the network, which is defined in SNMPv3 VACM. The specification can generally be the ASN.1 notation (1.3.6.2.4) or the name of the SNMP MIB branch, like system or Internet. Then you need to define a group, where the users are matched to their approved security level, noAuthnoPriv, authNoPriv or authPriv.

On a single switch, we created a view named "ALLMIB" with a scope of the Internet or OID 1.3.6.1, which is at the root of MIB II and all private MIBs. Next we created a group named "READALL." This group used MD5 authentication and DES encryption for authPriv security. We linked the ALLMIB to the READALL group's view.

We then created a view named "SYSTEM," and another group called "WRITE" (and gave it write access). We linked WRITE to the SYSTEM view, with authPriv as its security level. Members of this group could access only the system or OID 1.3.6.1.2.1.1 section of the MIB, but could read and write values.

Then we created two users, placing each into one of the two groups created on the switch--USERREAD went to READALL and USERWRITE to WRITE. We repeated the same process creating views, groups and users on a different switch. (We copied the configuration to the switch because they were both Cisco Catalyst 2900s, but that won't work with different brands of switches).

At that point, just the two network devices were configured with SNMPv3 security. Next, we needed to configure the management application to use the same security parameters. So for the two switches configured above, we created two users with the same security levels and same user IDs and passwords. We only needed two user IDs and passwords on our SNMPv3 management station.

Now we were able to access both switches with SNMPv3 security. When we attempted to change the system contact, which resides within the system portion of the MIB as USERREAD, we could not. And when we attempted to read interface counters as USERWRITE, we could not do that either. So version 3 security worked.

But even with just the two switches we manually configured in the lab, it was obvious that implementing SNMPv3 across an entire network would be too labor-intensive.


start top  Feeling Secure Hands On Experience

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers