Here our some ground rules when using SNMP and client server tools to monitor systems and network devices

1. Do not trust your firewall when using SNMP

   SNMP version 1 transfers all data, including passwords, in the clear. There are a bunch of worms and trojans these days which sole purpose is to penetrate your firewall, then start network sniffers. SNMP monitoring data will be music to crackers ears when it finally reaches them.

   So any SNMP data that travels your firewall protected internal LAN should be encrypted, which is why everyone should be using SNMP version 3 when possible.

2. Beware of client/server schemes

   Most centralized monitors rely on agent modules on on monitored hosts to listen to their requests and respond with relevant information.

   Which means that on every host, the agent will very likely open a TCP or UDP port to listen to requests. This may sound paranoïd again, but every open port is a door a potential cracker might use to access the system. It really depends on the quality of the code that opened the port.

   A more secure way of monitoring a host is having the host send information by itself, on a time or event (trap) driven basis. This avoids the always-open-port potential vulnerability issue.

   Even with SNMP, it is possible to restrict access to the SNMP database to the localhost only, and then have some monitoring code on the host itself send reports and alerts after querying the local MIB.

My laptop's disk let me down yesterday. It's now full of bad blocks. This prevented me from posting for most of yesterday's afternoon. I've managed to keep current bad blocks in check, and restored a working system partition, but this may not hold for long.

Once they have gained a large enough beachhead, it gets difficult to repel a bad blocks invasion.

Anyway, the second part of yesterday's System And Network Monitoring tutorial at the Usenix conference was focused on monitoring packages such as MRTG, Cricket, BigBrother and their ilk, plus what John Sellens call a case study. More on those tools in my upcoming SNMP OPML resources directory.

John is a real SNMP-head. He's written a very simple open source utility, Thresh, to leverage SNMP for system monitoring. I like Thresh because you can see John's experience as a sysadmin through it. It is very 'real world' oriented.

What I think John's presentation lacks is proper focus on security: to my liking, he is not paranoïd enough. More on this subject in my next post.

John covered a number of basic SNMP tools this morning. The most impressive seems to be Net-SNMP

The Net-SNMP project is hosted at SourceForge. The Net-SNMP agent implements the standard MIB-II, more interestingly for host monitoring, it also implements both the 'ucdavis' Enterprise MIB and the Host Resources MIB. Net-SNMP is mostly a Unix based subsystem.

MacOS X admins should refer to the Net-SNMP for MacOS X site.

Windows 2000 server has pretty good support for SNMP built-in, even though there have been recent vulnerability issues.

Garth William's site points to a host of PC/Windows SNMP resources.

For low-level SNMP programming in Perl, Simon Leinen's BER.pl and SNMP_Session.pm modules, avalaible through CPAN, seem good enough. No implementation of MIB vocabulary though. A Perl module is also part of Net-SNMP.

Scotty is a TCL shell that is cool to query MIBs if you're into TCL.

Jürgen Schönwälder, Scotty's author, has also released scli, the SNMP Command Line Interface, for less TCL minded sysadmins.

Python lovers should check the PySNMP project on SourceForge.

I'll probably set-up an OPML based directory for SNMP resources based on the tutorial later today.

RFC 1514 defines a Management Information Base for host systems.

At last a little Win32 sysadmin related contents in s l a m.

The file sharing mechanism in Windows NT and Windows 2000 sometimes doesn't close shared open files properly. When this happens, anyone trying to access the file gets a "file busy" error message.

This recently happened for my instant outline on UserLand's new Windows based static server:

Upstream 1 file: The server reported an error: The file "L:\static\xmlStorageSystem\users\0104487\instantOutliner\marcBarrot.opml" is busy.

To release the file in Windows 2000, use the Computer Management console, connect to the server that is publishing the file, expand System Tools and Shared Folders in the console tree, then select Open files. The faulty file should be listed in the right pane. You can close it by right-clicking on it and selecting the Close Open File option, then confirming with Ok.

To release the file in Windows NT4, use the Server Manager, connect to the server that is publishing the file, click the 'In Use' button, then select the faulty file in the list, and click the 'Close Resource' button.

This problem occurs so often that I usually try to keep away from SMB file sharing, but sometimes, there are no other solutions.

Catching up on Martin Heller's PHP Revisited column on Byte.com, I've just realised I am responsible for a site with public Internet exposure and PHP 4.1.1 for Windows.

Oops, this is a serious mistake:

[27-Feb-2002] Due to a security issue found in all versions of PHP (including 3.x and 4.x), a new version of PHP has been released. Details about the security issue are available here. All users of PHP are strongly encouraged to either upgrade to PHP 4.1.2, or install the patch (available for PHP 3.0.18, 4.0.6 and 4.1.0/4.1.1).[PHP Security Update]

It doesn't take much digging into the advisory notice to realize these vulnerabilities in fileupload could allow an evil minded attacker to execute arbitrary code on a pre 4.2.2 PHP system.