Home / Apple / How-To
How-To

Setting up and using SNMPv3 on OS X

By John Welch
Macworld NOV 17, 2008 5:05 am PST

When it comes to monitoring your network, and devices on your network, the 800-pound protocol gorilla is Simple Network Management Protocol, or SNMP. The name is, in my opinion, a passel of lies—the way SNMP works is certainly simple, but setting it up is the exact opposite.

Still, when it comes to checking on your network, SNMP offers a relatively low-bandwidth way to see what’s happening. You can check traffic, server up-or-down status, the status of RAID devices, SANs, how your cooling system is doing, how your power is doing, how many users are on each of your wireless access points, and more.

You have many tools at your disposal for using SNMP’s feature set on Mac OS X—including things like Nagios, Cacti, LanSurveyor, Lithium, and Intermapper, among hundreds of other . The setup ranges from dead simple to rather complicated, and the price ranges from free to tens of thousands of dollars. However, they all use SNMP. And that leads us to a problem: Security.

See, SNMP is unencrypted—at least, versions 1 and 2 of the protocol were. Both versions send all sorts of information about your network around in plain text, allowing anyone armed with a packet sniffer to read them. For example, here’s the data in an SNMPv2 packet during a test probe of one of my servers:

data: get-response (2)    get-response        request-id: 240098041        error-status: noError (0)        error-index: 0        variable-bindings: 1 item            1.3.6.1.2.1.1.3.0: 85515481                Object Name: 1.3.6.1.2.1.1.3.0 (iso.3.6.1.2.1.1.3.0)                Value (Timeticks): 85515481

That happens to be the amount of time that particular server had been up in hundredths of a second. Now, this is not that valuable to an attacker, but there are other kinds of SNMP queries that will tell you things like specific OS version for your servers, firmware version for your wireless access points, what processes are running on what server, and so forth. That kind of information, when taken together, can give an attacker a very detailed view of your network and its major components—not something you’d want happening. Prior to SNMPv3, about all you could do was restrict your SNMP use to behind a firewall or over a VPN, and hope for the best. If someone got in and knew what to look for, they could slurp up a lot of information in a very short time.

Obviously, proper physical and access security are parts of the answer here, but why not encrypt the protocol? I mean, you encrypt other sensitive data. You don’t give out credit card information on Web sites that aren’t using SSL, right? (At least I hope you don’t.) So why not add an extra layer to SNMP’s security and encrypt it?

The folks behind SNMP agreed and came up with SNMPv3. This version of SNMP is based on multiple IETF RFCs, specifically RFCs 3411 through RFC 3418; it became the “current” version of SNMP in 2004. The biggest changes in SNMPv3 involve authentication and transmission of data. In versions 1 an 2 of SNMP, there was no encryption anywhere. So while you had to have a password, aka the “community string,” it wasn’t securely stored or transmitted. If we look at the more of the packet I showed you above, we can see the community string right there, plain as day:

Simple Network Management Protocolversion: v2c (1)community: bynkiidata: get-response (2)    get-response        request-id: 240098041        error-status: noError (0)        error-index: 0        variable-bindings: 1 item            1.3.6.1.2.1.1.3.0: 85515481                Object Name: 1.3.6.1.2.1.1.3.0 (iso.3.6.1.2.1.1.3.0)                Value (Timeticks): 85515481

The community string used here is bynkii. (For those who are interested, I used Wireshark for the packet captures. Fantastic tool.) So even if I pick a good password, anyone with a packet sniffer and a decent text editor can find it. So SNMPv3 fixes this by encrypting the passwords via flavors of either MD5 or SHA (specifically, either HMAC-MD5-96 or HMAC-SHA-96, with SHA being the recommended choice). In addition, the SNMPv3 traffic can also be encrypted via the DES encryption algorithm.

What’s the result? Let’s take a look at an SNMPv3 packet:

Simple Network Management ProtocolmsgVersion: snmpv3 (3)msgGlobalData    msgID: 530815    msgMaxSize: 65507    msgFlags: 07        .... .1.. = Reportable: Set        .... ..1. = Encrypted: Set        .... ...1 = Authenticated: Set    msgSecurityModel: USM (3)msgAuthoritativeEngineID: 80001F8880BBEF113416410E48    1... .... = Engine ID Conformance: RFC3411 (SNMPv3)    Engine Enterprise ID: net-snmp (8072)    Engine ID Format: Reserved/Enterprise-specific (128): Net-SNMP Random    Engine ID Data: BBEF1134    Engine ID Data: Creation Time: Apr 22, 2008 15:48:38msgAuthoritativeEngineBoots: 14msgAuthoritativeEngineTime: 856044msgUserName: snmpadminmsgAuthenticationParameters: B30963655F7A5A23488DEDFAmsgPrivacyParameters: 00000001F74583ADmsgData: encryptedPDU (1)    encryptedPDU: 051391661CEB7D3C9AF7B4EB5716DB68AFCBA5C722D10FC9...

If I’m an attacker, that’s kind of …useless. I can tell SNMPv3 is in use, but that’s about it. I can’t really see any of the data in the packet, nor can I see the user ID and password used for authentication. Since I’m a systems admin, and not an attacker, though, that’s much better—SNMPv3 makes caring about passwords worth the trouble. Now, to be clear, this is all only as good as the passwords you use. If your password is PUPPIES, it’s not going to last long in the face of a dictionary attack. If it’s *(Gb5^$Mnng1, that will probably survive a bit longer.

So now, we’ve added two more layers to the mix. The user ID and password, (actually, in SNMPv1 and SNMPv2, there’s no user ID) are encrypted, and the traffic itself is encrypted. While it’s not foolproof—and I’d still not send it willy-nilly across the public Internet—it just became a lot more useless to an attacker. Which is the idea.

But that’s just the backstory. What about the cool parts—namely setting up SNMPv3 and using it on Mac OS X? Fear not, good reader: that part of the story is upon us. But there are some caveats. To avoid this becoming a truly epic-length article, I’m not going to go into the basics of SNMP setup and usage. Instead, I’ll refer you to an earlier article I wrote that covers SNMP basics and setup in detail. It doesn’t cover SNMPv3, but it does address SNMPv1 and v2 rather nicely. That’s important because the way you use SNMP is not radically different between versions, and there are a lot of devices that still don’t support SNMPv3 well or at all. So you’re going to have to be comfortable with the older versions of SNMP to get the most out of it.

SNMPv3 setup

The first thing we have to do to use SNMPv3 is to set it up. Now, if you’re really good with snmpd.conf syntax… well, you don’t need this article. However, rather than hand-editing the conf file, we’re going to take advantage of a handy utility called snmpconf. (Warning for the Terminal-phobic: SNMP requires a lot of command-line work. There’s no way to really avoid it. If you’re an administrator who still fears Terminal and the command line, you’re going to need to move past that.) snmpconf is a Perl script designed to make setting up snmp easier—something which it’s pretty good at.

One nice thing, is that if you use snmpconf with the -i switch, (snmpconf -i), it will even put the various configuration files you create and modify in their correct locations for you. Handy, no? Of course, since you’re modifying system-level configurations, you have to run snmpconf via sudo to have the -i switch work correctly, so you have:

sudo /usr/bin/snmpconf -i

When you run this, if there are any existing configuration files, (and there most likely will be), you’ll be asked if you want snmpconf to read in the data from one, some, or none of those files. I prefer to start clean, so I usually pick none. (If you already have a functional SNMP setup and are adding SNMPv3 to it, pick the more appropriate option for your setup.) Enter none and hit return. Next, you’re going to be asked what files you want to modify: snmpd.conf, snmptrapd.conf, or snmp.conf. Since we want to set up how the system responds to SNMPv3 requests from other systems, we want to modify the configuration of the SNMP daemon, snmpd. Therefore, we’re going to select option 1—snmpd.conf:

The next screen will give you all the options available for snmpd. Since we’re trying to keep this at least somewhat small, and the other information is available elsewhere, we’re going to ignore all the options that don’t involve setting up SNMPv3. So, we’re going to choose option 1, Access Control Setup, because that’s where we start configuring our SNMPv3 users:

Once we’ve done this, we see we have two options for SNMPv3 setup; a read-write user and a read-only user. Since you can use SNMP to set values, not just get them, it is important to use a good password for the read-write user. As an example, a lot of networks use this setting ability, via the snmpset command, to disable ports on a switch if they detect a computer that’s been corrupted by malware, and is now trying to do inappropriate things on the network, like setting up IRC servers. So you have to give careful consideration to what the read-write user’s credentials will be. One thing you can do, and it’s not a bad idea, is to have different user logins for read-write and read-only. Monitoring software that won’t need to change settings only needs read-only access.

With all that in mind, let’s set up our read-write user, option 1:

We get an example of the arguments we’ll eventually use here, and then we’re asked for the user name. Only enter the user name here. I have learned, painfully, over the years that getting clever with snmpconf leads to madness and bad config files. Also note that snmpconf is telling you what user you’re configuring, namely rwuser:

For our example, we’re calling this user “r-wuser,” just to make what we’re doing more clear. Next, you’re asked the minimum security level required for that user with three options: noauth, auth, and priv, with the default being auth. The difference between the three is what kind of security is used for authentication. noauth is what you get with SNMPv1 and v2-no encryption; plus, as long as what you enter matches the password/community string, it’s good. auth uses either HMAC MDF or SHA to authenticate, so it’s quite a bit more secure than string matching. priv takes the mechanism used by auth, and encrypts it with DES for even more security. My preference here is to use priv. If you’re going to use noauth, there’s not much of a point in using SNMPv3. Enter the desired security level and hit return:

Next, you’re asked what OID you want to restrict this user to. As a quick background, an OID is the container for the value you’re requesting. So if you want to know uptime, you’d request the value in the 1.3.6.1.2.1.1.3.0 OID. In some cases, you may want to really lock down access to a device or devices for SNMP read-write access to a specific OID. If so, you’d enter it here. I have yet to have a need for this, so I just hit return, which grants access to all OIDs. That’s the last step in configuring the SNMPv3 read-write user, and you return back to the Access Control Setup screen:

Setting up the read-only user is identical to setting up the read-write user, so we won’t cover that in detail. Obviously, you’ll want to use a different user name for read-only than for read-write. Once you’re done, enter finished, hit return, and you move back to the snmpd config main screen:

Enter finished again, and you’re back to the snmpconf main screen:

If you enter quit here, snmpconf will write your selections to the snmpd.conf file, and move it to the correct locations. If you want to change anything before that happens, this is your last chance to do so without repeating every step. If you’re happy, then enter quit and hit return. snmpconf will tell you what happened, and where it put the files.

However, there’s one more step. All we did was tell snmpd what it needs to know when it is queried by another device using SNMPv3. We haven’t yet actually set up the user databases or the hashes needed for the authentication and encryption. To do that, you have to use net-snmp-config, at /user/bin/net-snmp-config. When you run net-snmp-config with the --create-snmpv3-user flags, you create the authentication information needed to take advantage of SNMPv3’s security. Before we actually start running net-snmp-config, let’s take a look at what the --create-snmpv3-user switch does. From the net-snmp-config man page:

--create-snmpv3-user [-ro] [-a authpass] [-x privpass] [-X DES|AES]	[-A MD5|SHA] [username]

Along with the username, we have some decisions here. First, is this a read-only user or read-write (-ro). We have to decide on both an authentication passphrase, (-a authpass) and an encryption passphrase (-x privpass) if we’re using encryption. If we are using encryption, (and why wouldn’t we?) then we need to decide on the kind of encryption we’re going to use. We can choose between DES or AES, (-X DES|AES). Finally, we have to decide on the authentication mechanism, MD5 or SHA, (-A MD5|SHA). Now, when you’re deciding on the encryption protocols and authentication mechanisms, you want to make sure whatever you pick is supported by the monitoring programs that will be querying snmpd on the Mac OS X computer we’ve been setting this up on. Picking the more secure options, (AES and SHA) won’t do us much good if the monitoring software can’t use it.

There are two ways to run this command. You can run sudo net-snmp-config --create-snmpv3-user interactively, but you lose control over what authentication and encryption protocols are used. For example:

If you want full control over creating the user, or you want to create a read-only user, you’re going to want to specify all the commands. For example, to use SHA instead of MD5 and AES instead of DES:

It’s a bit more complicated, but it does let me have more control over exactly how I want to create this user.

 

Once you’ve run net-snmp-config, it creates those users in a separate snmpd.conf file, located in /var/db/net-snmp/, which is only readable by root. The reason for this is because it stores the information on SNMPv3 users in plain text in this file:

createUser snmpv3test MD5 "78Y+-0u1#" DEScreateUser snmpv3test2 SHA "78Y+-0u1#" DES 78Y+-0u1#createUser snmpv3test3 SHA "78Y+-0u1#" AES 78Y+-0u1#

Note that this is in plain text. Anyone getting read access to this file will be able to get all the information they need to use SNMPv3 on this system. Yes, that’s insecure. But no one has claimed SNMPv3 was perfectly secure—only a lot more secure than earlier versions. However, if someone gets root access to one of your servers, you have far greater problems than them snarfing down all your SNMP traffic.

net-snmp-config also adds entries into the main snmpd.conf file, located in /usr/share/snmp/snmpd.conf:

rwuser snmpv3testrwuser snmpv3test2rwuser snmpv3test3

The reason for this is to allow you to add SNMPv3 users to an existing configuration without having to go through snmpconf. If that’s the case, then the only thing you’d want to add is a switch telling snmpd.conf about the authentication and encryption usage for these users. In our case, we’d add priv after each one for:

rwuser snmpv3test privrwuser snmpv3test2 privrwuser snmpv3test3 priv

However, if you’ve just created the user in snmpconf, and they already have an rwuser line in snmpd.conf, then you can delete the lines net-snmp-config added in your text editor of choice.

OK, so we’ve set up our SNMPv3 configuration and users, now, how do we use it all?

Using SNMPv3

If you look at the usage syntax for the various snmp commands, (just enter the command name without any options, and you get more info than you will out of the man pages), and you have a little familiarity with SNMP, then using SNMPv3 is pretty straightforward. You’ll need to specify the SNMP version, (3), the SNMPv3 user name, the authlevel, (I use authPriv, which sets it all up nicely), the authentication mechanism, the encryption protocol, and the passwords for authentication and encryption. For example, if you wanted to securely get a list of every SNMP option on a server named “test,” the command, snmpwalk would look like this:

snmpwalk -v 3 -u snmpv3test -l authPriv -a MD5 -A 78Y+-0u1# -x DES -X 78Y+-0u1# test.bynkii.com .1

The command is “walk the SNMP tree using version 3, (-v 3), with a user name of snmpv3test, (- u snmpv3test), an authentication level of authPriv, (-l authPriv), set the authentication mechanism to MD5, (-a MD5), with an authentication password of 78Y+-0u1#, (-A 78Y+-0u1#), set the encryption protocol to DES, (-x DES), with an authentication password of 78Y+-0u1# (-X 78Y+-0u1#), on test.bynkii.com, and start at the very beginning of the SNMP tree, (.1).”

Running that will get you the same results as using snmpwalk with earlier versions of SNMP, but it will be done in a secure manner. Yes, the passwords in the command line are not blanked out, but that’s common with this kind of command, and makes it far easier to integrate SNMPv3 into different monitoring tools. Again, the idea here isn’t “Top Secret” level security, just “more secure than SNMPv1 and v2.” Since SNMP commands tend to be really similar, if you just wanted to get the uptime of test.bynkii.com with snmpv3, you’d use:

snmpget -v 3 -u snmpv3test -l authPriv -a MD5 -A 78Y+-0u1# -x DES -X 78Y+-0u1# test.bynkii.com 1.3.6.1.2.1.1.3.0

While the commands aren’t as simple as point and click, having them all use similar syntax makes things much easier.

Caveats

The two biggest issues I run into with SNMPv3 are setup and ubiquity. For example, while setting up SNMPv3 on Mac OS X and most other Unix systems is pretty straightforward, setting it up various routers and switches can be nightmarish, since they all have to have their own terms and their own syntax.

 

The other issue is ubiquity. On the high end, SNMPv3 support is fairly standard. However, on mid-to low end devices, support gets weaker. As well, at least up through Windows Server 2003 R2, I’ve yet to find native SNMPv3 support on Windows at all. Server 2008 may change this, or it may be really well hidden. Either way, Windows has been the biggest fly in the SNMPv3 ointment.

As well, you’re going to find that while the commands and data transfer are pretty secure, setting up the commands and the various monitoring utilities are not. My two favorites, Nagios and Cacti, both support and use SNMPv3, but they store the passwords in plain text form. So you still have to deal with security on the systems running your monitoring tools so that an attacker doesn’t break into them and get your SNMPv3 authentication data.

Conclusion

As I said in my earlier SNMP article on my own site, I’m not going to pretend that this is a complete look at SNMPv3. Nor am I going to pretend that you can just read this article and be fluent in SNMP. If you already were using SNMP and wanted to add SNMPv3 to the mix, then this article should provide you with a good start. If you are completely new to SNMP, then please go back and read my earlier article first. Doing anything beyond the very superficial with SNMP is almost impossible without really knowing about things like OIDs, MIBs and a few other terms. However, once you do get comfortable with how and why SNMP works, you can do some pretty cool stuff with it that will make running your network far easier.

[John C. Welch is a senior systems administrator for The Zimmerman Agency, and a long-time Mac IT pundit.]