Security Review: Securing SNMP on Solaris
Information Systems and Technology
University of Waterloo

What we Learned

This section documents our efforts to answer the questions noted above and secure the SNMP service on a Solaris 8 system. If you're interested in quick answers you can safely skip to the Recommendations that follow. If you're interested in how we came to those recommendations this section may be worth reading.

My baseline: I know very little about SNMP. I do know that's it's often used to monitor systems and sometimes used to control them. Typically, network operations use tools (like the InterMapper noted above) that rely on SNMP to detect and resolve networking problems like router outages. People who know these things talk about SNMP traps, MIB's, OID's and other three letter acronyms. I'm not one of them.

A quick peek at our system with ps(1) and lsof(1) to find snmp services reveals a couple of candidates to investigate:

[1:28pm wally] ps -ef | grep snmp
    root   808     1  0   Oct 03 ?        0:00 /usr/lib/snmp/snmpdx -y -c /etc/snmp/conf
    root   815     1  0   Oct 03 ?        0:00 /usr/lib/dmi/snmpXdmid -s wally
 reggers 12675  9473  0 14:09:24 pts/2    0:00 grep snmp
[1:29pm wally]# lsof -i | grep snmp
snmpdx      808    root    4u  inet 0xf61c8418      0t0  UDP *:snmp (Idle)
snmpdx      808    root    5u  inet 0xf61c8568      0t0  UDP *:33037 (Idle)
snmpdx      808    root    6u  inet 0xf6459c70      0t0  UDP *:33038 (Idle)
snmpXdmid   815    root    0u  inet 0xf61c84f8      0t0  UDP *:33031 (Idle)
snmpXdmid   815    root    1u  inet 0xf6459f80      0t0  TCP *:32792 (LISTEN)
snmpXdmid   815    root    6u  inet 0xf6459d50      0t0  UDP *:33033 (Idle)
snmpXdmid   815    root    7u  inet 0xf6459ce0      0t0  UDP *:6500 (Idle)

We were expecting a simple daemon listening on one port for SNMP requests and we've found two daemons listening on seven different service ports. The manual pages tell us that snmpdx(1M) is the Sun Solstice Enterprise Master Agent while snmpXdmid(1M) is the Sun Solstice Enterprise SNMP-DMI mapper subagent. It turns out that there is an incredibly complicated web of service dependencies. Here's what we understand:

• The snmpdx process that's listening at the "snmp" port is a master that spawns off "sub agents" (ie. processes) to do the work -- an important one is mibiisa(1M).

  The snmpdx process starts the mibiisa(1M) process and instructs it to listen on a particular port (by default it would listen to the "snmp" port but that's busy with the snmpdx process!).

  SNMP requests received by the snmpdx process (received at the "snmp" port) are sent to mibiisa(1M) and the answers returned to the snmpdx process are then returned to the client who made the request. That's a simple relaying operation.

  The snmpdx process also relays SNMP traps the subagents generate but nothing had been configured -- our manager ratbert only polls wally. Traps are event driven interrupts like "Hey ratbert, I just ran out of memory!" We weren't using any of them.

  These processes are started at boot time from /etc/rc3.d/S76snmpdx.

• Likewise the snmpXdmid is a subagent that processes "snmp" requests (received on some other port) and spawns off a sub-process dmispd(1M).

  The snmpXdmid process accepts SNMP requests from snmpdx (and anyone else I suppose) and translates them into DMI requests serviced by the dmispd process. That's a translate and relay.

  The snmpXdmid process also relays certain DMI events as SNMP traps. But again nothing had been configured.

  These processes are started at boot time from /etc/rc3.d/S77dmi.

So now our simple problem has become even more complicated:

[1:31pm wally]# ps -ef | egrep 'dmi|mib|snmp'
    root   814     1  0   Oct 03 ?        0:01 /usr/lib/dmi/dmispd
    root   808     1  0   Oct 03 ?        0:00 /usr/lib/snmp/snmpdx -y -c /etc/snmp/conf
    root   838   808  0   Oct 03 ?        1:38 mibiisa -r -p 33036
    root   815     1  0   Oct 03 ?        0:00 /usr/lib/dmi/snmpXdmid -s wally
    root 12340 12307  1 13:32:41 pts/2    0:00 egrep dmi|mib|snmp
[1:31pm wally]# lsof -i | egrep 'dmi|mib|snmp'
snmpdx      808    root    4u  inet 0xf61c8418      0t0  UDP *:snmp (Idle)
snmpdx      808    root    5u  inet 0xf61c8568      0t0  UDP *:33037 (Idle)
snmpdx      808    root    6u  inet 0xf6459c70      0t0  UDP *:33038 (Idle)
dmispd      814    root    3u  inet 0xf61c85d8      0t0  UDP *:33030 (Idle)
dmispd      814    root    4u  inet 0xf6459e30      0t0  TCP *:32793 (LISTEN)
snmpXdmid   815    root    0u  inet 0xf61c84f8      0t0  UDP *:33031 (Idle)
snmpXdmid   815    root    1u  inet 0xf6459f80      0t0  TCP *:32792 (LISTEN)
snmpXdmid   815    root    6u  inet 0xf6459d50      0t0  UDP *:33033 (Idle)
snmpXdmid   815    root    7u  inet 0xf6459ce0      0t0  UDP *:6500 (Idle)
mibiisa     838    root    0u  inet 0xf6459c00      0t0  UDP *:33036 (Idle)

We assumed one process listening at the "snmp" port and find instead four processes listening at ten ports! That's a lot of baggage and considerable exposure. How can we manage this?

Our first success was to determine that we could safely disable all DMI services with no loss of functionality for the InterMapper at ratbert. That eliminates two processes listening at six different ports. We assume there are some SNMP requests that can only be answered by the dmispd(1M) daemon. But we're not using them!

An observation: At least some of those DMI services are delivered as RPC services -- you'll find them using rpcinfo. With a little digging you'll discover that both daemons are offering RPC services. By contrast SNMP services are not layered on RPC. We suppose, but cannot confirm, that you cannot run DMI services without also running rpcbind -- that's the rendezvous point to translate RPC service numbers into TCP/UDP port numbers.

We turned our attention to the snmpdx(1M) and mibiisa(1M) processes. Both are configured from files found in /etc/snmp/conf. The file names are a little confusing --- snmpd.conf configures mibiisa(1M) while snmpdx.acl configures snmpdx(1M). There are other configuration files there and elsewhere but we only looked at these.

The manual page for snmpdx(1M) is pretty minimal but it points to an access control file snmpdx.acl that looked promising. Unfortunately there's no manual page for that and the commentary in the access control file provided does not correspond at all to the Solaris Answerbook (which you will find at Sun Product Documentation). Nevertheless we spent several hours working with the configuration trying variations:

1. Uncommenting this stanza, killing and restarting the daemons, results in syslog gripes:

   # The list of hosts that can send SNMP queries.
   # If this list is empty, all the hosts are allowed to
   # send SNMP queries.
   
   #managers = {
   #}
   

   The "managers =" fragment is not recognized at all -- it's a syntax error. There are several top level stanzas in the vendor provided configuration -- the only allowed stanzas according to the Answerbook and our tests are "acl=" and "traps=".

2. We tried changing the "managers" list on this stanza (again killing and restarting the daemons after each change):

   # The list of community names needed for read/write access
   # to the entire MIB.
   # If the list is empty, the only valid community name is "public"
   # and its access type is read-only
   
   acl = {
           {
                   communities = public, private
                   access = read-write
                   managers = *
           }
   }
   

   But no matter what we did the server always responded to ratbert. We were also a little distressed by what looks like "read-write" access to both the public and the private data -- very scary.

Finally we gave up on configuring the snmpdx process and turned our attention to the mibiisa daemon. The manual page for mibiisa(1M) is very good and even has a section on security. The default configuration, when stripped of commentary, looks something like this:

sysdescr        Sun SNMP Agent, SPARCstation-10
syscontact      System administrator
sysLocation     System administrators office
system-group-read-community     public 
read-community  public 
trap            localhost
trap-community  SNMP-trap
managers        localhost

We determined that the vendor configuration restricted the daemon to provide responses only to the localhost (ie. to the same system). That's the "managers" line. Since we had learned to not trust the vendor documentation we ran the daemon in a debug mode to verify that, as configured, it would not respond to anyone other than the "managers" listed in the configuration file. Changing the "managers" to include ratbert meant the InterMapper got the information it needed.