Slashdot Mirror

As the maintainer of Net-SNMP I've received a huge number of patches that would never have been given to us if Net-SNMP used a GPL license (though in this case, the code predates the GPL). Companies that have worked on the Net-SNMP code and have given back to it do so because they want to use their cool new feature they've developed for the code base in their proprietary software or hardware. IE, the Net-SNMP libraries and applications are the base upon which they build. It's important to them to contribute their patches to the base back to the core Net-SNMP repository so they can be assured future patches will not conflict with their feature (ie, because a patch isn't accepted that breaks the existing code base). Plus it gets their name in lights (ie, the COPYING file. Not many lumens, but still "lights").

I've been told many times that if Net-SNMP was GPLed code it would never be used. But since it's not, it's used in pretty much distributed by nearly ever OS vendor except Microsoft, and is used on a ton of embedded hardware. This would not have happened if it was a GPLed code base.

(ok, Microsoft still wouldn't be distributing it and linux* still would be; but all bets on Apple, Sun, etc, would be off)

the SNMP server
http://www.net-snmp.org/

A good IMAP server
http://www.washington.edu/imap/

Try this: you want the website for Net SNMP package. It's either www.net-snmp.org or www.netsnmp.org. One's the right site, the other is porn ads. You wanna guess which one I hit first at work?

Don't forget ucd-snmp.

The SNMP MIB tree is hierarchical. For example, the "version" parameter of NET-SNMP can be found by querying:

ucdavis.version.versionTag

Furthermore, these names have corresponding OID numbers, which are universally unique.

So why not just add builtin event notification to snmp?

What, like SNMP traps?

Come on.. this stuff ain't new. :)

For handling traps I use SNMPTT with Net-SNMP. It allows for traps to be converted to more meaningful messages using variable substitution.

I've seen it used in small and large environments.

http://www.snmptt.org/
http://www.net-snmp.org/

If your Unix system doesn't come with one Net-SNMP will install on many of them.

The SNMP daemon by default understands how to monitor Load Avg, Memory, Processes, and so forth. It may not be able to tell you details of the process, such as what user is logged into the POP3 daemon, but it will tell you that you have 500 of them running, and alert you (via SNMP Traps) of that fact.

ALl you need to do once you have checked the documentation for your SNMP agent and then configured it, is to setup a single (ok, maybe 2 or 3) machine to send your traps to so you can kick of alerts. With some simple scripting in $FAVORITE_SCRIPTING_LANGUAGE you can email, page, text message, update web page, or $OTHER.

Cricket or MRTG are nice utilities that will poll the servers in question (by default every 5 minutes) and produce graphs. MRTG was designed to handle network equipment and graph the bandwidth utilization, but with a change to the SNMP string, will graph anything. Cricket is the same concept but does things a little differently by using a tree configuration system for property inheritance and does graph generation on the fly instead of the at poll time method MRTG uses.

And last but not least, Transmeta produced a very good perl script monitoring package known simply as Mon. This package will do active polling of the servers including issuing a transaction to the service you are monitoring. Due to the way this software monitors, you can actually see if the remote machine is alive by actually utilizing the service to monitor instead of just the "I can ping it, it must be up" mentality some people have.

Best part about all the above mentioned software is that they are all applications with an OSI Approved OpenSource license. This means you don't spend anything but TIME, and possibly a few machines to do the actual monitoring with.

And you may wonder about the impact of system performance due to the monitoring by SNMP, MRTG/Cricket, and Mon. The short answer is that I couldn't detect a noticable increase. Other utilities such as Argent (Commercial Pay For Software) would impact a HP-UX V Class 8 CPU with 8GB RAM machine from 0% on all 8 CPUs to about 20% on ALL 8 CPUs while it telneted to the machine, created about 150KB of test scripts, and then ran them.

Distributions do a great job redistributing stuff, but don't do a great job working with the package authors themselves. The net-snmp package is an extremely hard one to maintain, for we support a really large number of operating systems for code which is very operating system sensitive (the architecture ifdefs in some portions of the code will drive you mad. Trust me.) net-snmp is redistrubuted through a number of distributions, and let me tell you that almost no bug reports get to us that are entered into distribution bug tracking databases. It's a nightmare, and because we can't continously search other bug databases for problems, we frequently are left out.

To make matters worse, the distributions often fix things. RedHat and other RPM packages simply roll their own patches into their redistribution and don't send it to us. FreeBSD has a ports tree that contains patches for projects that the projects themselves may have never seen.

I'll never forget the first time I opend the source rpm of the net-snmp package from redhat. There were 3 patches in it that I had never seen for bugs I didn't even know about. Why hadn't I heard of them? because the RedHat package maintainers didn't notify us that they had fixed something.

Finally, what's even worse is that all of the RedHat source RPMs are GPLed. Our package uses a BSD license and thus we can't pull the patches out of the RPMs and apply them to our source without getting explicit permission to re-license it.

The proper thing to do would be to probably search freshmeat for the project page and look at the documentation. Maybe submit it to both the package maintainer and to distribution maintainer if you really have the time (ha!).

My personal plea to the distribution maintainers: help the package authors out! Please!

Oh, sorry, did I just shoot your claim in the foot?

When you're making software that costs $(BIGNUM) a pop, it's a far better solution to buy pre-written, carefully tested and well-supported 3rd-party software for a couple of grand than to try to roll your own. The S in SNMP may be "Simple", but in reality it's one seriously hairy protocol.

And yeah, I know that NET-SNMP (ex-UCD-SNMP) is open source, but it's all C and our software has to work under Linux, Solaris, HP/UX and Windows -- this, of course, being why we use Java in the first place!

Cheers,
-j.

Create a separate VLAN or management network for your LAN infrastucture.

Protect this management network from the rest of the network via a firewall or at a minimum access-list.

Use access-list or similar technology to limit SNMP access to your WAN infrastructure from your management network, or better yet specific network management servers.

Use SNMPv3 if at all possible.

Just like any other security matter, make sure that you are running the appropriate version of code and or patches on your systems.

Hope this was helpful!

Fred Reimer

The security flaw is not in the protocol, but rather in how people and companies have implemented it. Unfortunately, most people did in fact implement it in such a way that makes the products vulerable to crashing and /or buffer-overflow attacks. A good portion of the SNMP code to date is written based on early work from the cmu-snmp package, which was a reference release of the protocol. Hence, many of the companies and products that make use of that original code (including ucd-snmp and net-snmp, which I'm the lead developer for) are subject to the vulnerabilities as well. The ucd-snmp and net-snmp packages have been fixed as of a few months ago (and upgrading software is easy on linux, *bsd, etc boxes). However, people with flashroms containing software will have a much more challanging time getting updates from their vendors and installing them in a quick fashion if the deployment numbers of those types of boxes are large.

The result is that most major Linux distros can't keep binary compatibility between updates and errata on the same OS release, much less between releases. Even with the LSB, I think it will be a while before we see binary compatibility between distros.

By far, the worst distributor in this regcard is RedHat. I figured for years they were merely building the source and distributing the binaries as is. The first time I looked at the spec file I found around 4 patches I had never seen before and didn't even know some of the bugs existed. Well, I thought, I'll contact them and see whats up. "Sorry, I'll try to make sure patches get your way in the future". Of course, when I checked the source rpm for the next release I found yet more patches I'd never seen... Sigh... I don't have a solution to this problem, though an obvious one might be something along the lines of at least asking the maintainer if they wished to receive CVS messages or CVS patches on a regular basis from the ports trees, or to be added as a default contact for the external bug database for a given package (To solve the redhat problem, I'm forced to go search through their bug database occasionally). Don't get me wrong, I think distributing the source and binaries in an external "easy-to-use" fashion is a great thing. What I consider wrong is to not at least mention to the original developers that changes have been made. Sure, its legal and even goes along with the licence in most cases, but in the long run I would think it would save the ports maintainers a lot of conflict merging if they kept in touch with the package developers.

Previously, we worked on a publicly available implementation of SNMPv3 (first in net-snmp and then from scratch in opensnmp, both of which are BSD copyrighted code).

My next project is targeted to large scale management of IPsec installations, the code for which should also be released to the public (though the popular FreeS/Wan code base won't accept US patches, so we'll probably be instrumenting Cerberus instead; FreeS/WAN's loss I guess, otherwise we might have implemented code for them both).

Working on projects like this is great, because it's typically in the form of "here's a hard problem", now "go solve it" without any mention of "do it this way".