What Have We Sacrificed
Sidebar 1 | Sidebar 2 | Article
A colleague expressed some concern about my hardening of the SNMP service:
“Without tons of experimentation, we don’t know if what you did locks down too tight, and for a large company using a vendorware SNMP management station, you might have broken monitoring in favor of hardening.” — Patrick Matlock, 10/10/2000.
Patrick suggested that we explore the SNMP service with the tool snmpwalk(1)
to see what variables are available before hardening and what remains after
hardening. That tool is part of the UCDavis SNMP Suite, which we have installed
on some systems. You won’t find any vendor provided tools on Solaris to
query the service unless you’ve installed some value-added packages. Here’s
an example of how you can use it to find out about “system” values:
[1:38pm wally] snmpwalk dilbert public system
system.sysDescr.0 = Sun SNMP Agent, SPARCstation-20
system.sysObjectID.0 = OID: enterprises.42.2.1.1
system.sysUpTime.0 = Timeticks: (619954285) 71 days, 18:05:42.85
system.sysContact.0 = dilbert@ist.uwaterloo.ca
system.sysName.0 = dilbert
system.sysLocation.0 = Machine Room, UW/IST, MC
system.sysServices.0 = 72
The arguments to the command are the system (e.g., “dilbert” is a computer
name), the community (e.g., “public” and “private” are the
defaults), and the optional objectId (i.e., the things you
want to know about). I understand that the objectId’s are all strings
that begin with one of these: at, icmp, interfaces,
ip, snmp, system, tcp, and udp.
We discovered, and this came as quite a surprise to me, that we had not lost any
SNMP values through hardening. Here’s how we determined this:
[1:39pm wally] snmpwalk system-a public | \
sed -e 's/[0-9.]
|
