Securing SNMP on SolarisReg Quinton Solaris 8 (also known as Sun OS 5.8) is often configured with a large suite of network services, including several daemons for the Simple Network Management Protocol (SNMP) and related services, especially the Desktop Management Interface (DMI). If you are concerned with the security of your system, you should consider eliminating or hardening each service offered (see recommendation of CERT Coordination Center). The default SNMP configuration, while perhaps reasonably secure, can be made substantially more secure with a little effort. If you require SNMP services (e.g., to monitor a server in case of failover), you should configure it better. Recommendations are provided in the Sidebar "What Have We Sacrificed". I believe the observations made here apply equally to Solaris 7 and Solaris 2.6 (the two previous releases of Solaris) but have not confirmed that on both platforms. The Problem We have a Solaris 8 system (call it wally) that was configured with default SNMP services as provided by the vendor. Our operations staff monitor the status of the system using the InterMapper, and we wanted to restrict the SNMP service on our Solaris 8 system to just that one station (call the monitor ratbert) see the Intermapper Sidebar. Our basic problem is to configure wally to only answer SNMP questions from ratbert. Why would we even consider this problem -- the ratbert system is busy monitoring wally, what's the big deal? Some things to consider:
1. Given that you've done nothing special to allow ratbert to monitor wally, what's to prevent others from doing the same thing? Hackers use SNMP to profile a system before launching an attack. 2. SNMP includes get and set commands -- if ratbert can get information, what's to prevent it, or anyone else for that matter, from setting values? 3. Any time you offer a network service, you're open to several attacks. Here are some of the obvious:
If you are familiar with the Solaris history, you will recall that there have been serious security problems with SNMP services. If you follow Sun updates and patches, you know that there are security fixes for these services. A lesson we've learned the hard way is that no network service can be considered "risk free." 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 is worth reading. I know very little about SNMP, but 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. 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.
The snmpdx process that's listening at the "snmp"
port is a master that spawns off "subagents" (i.e.,
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 (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 that the subagents generate, but nothing had been configured -- our manager ratbert only polls wally. Traps are event-driven interrupts such as, "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 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. Our simple problem has now 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
but found four processes listening at ten ports, which is considerable
exposure. How can this be managed? The vendor has provided us
with a system that's far too complex -- complex systems are
always less secure than simple systems. We have to simplify.
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! 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 assume, but cannot confirm, that you cannot run DMI services without also running rpcbind, which is 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, which 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 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 is available in the 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 concerned with what looks like "read-write"
access to both the public and the private data.
We finally 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 localhostWe determined that the vendor configuration restricted the daemon to provide responses only to the localhost (i.e., to the same system). That's the "managers" line. 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. Conclusion After considerable effort, we've determined that there are few unnecessary services, and we can safely configure one daemon to restrict it's attention to a list of authorized managers. That's all we needed to satisfy our InterMapper requirements. If your requirements are similar to ours, you might try our configuration to satisfy your needs while minimizing your exposure. Recommendation To configure public SNMP services on a Solaris 8 server and restrict the service to a short list of managers, we recommend:
1. Be sure you have configured syslogd(1M) to be far more thorough about logging what's happening. We recommend a detailed audit (at least during the install):
[2:39 wally] grep /syslog /etc/syslog.conf
#mail.debug ifdef('LOGHOST', /var/log/syslog, @loghost)
*.debug ifdef('LOGHOST', /var/log/syslog, @loghost)
The default configuration is to log everything wrt. mail services
at the debug level to the file /var/log/syslog. We recommend
you log everything to the same file. When things go wrong, as
they sometimes do, a good audit trail will be important.
2. Stop the vendor-provided SNMP and DMI services on your system:
[2:40pm wally]# cd /etc/init.d [2:40pm wally]# ./init.dmi stop [2:40pm wally]# ./init.snmpdx stopIf you want to restart those services, run the shell scripts with a "start" option instead. You may find these scripts with different names on other versions of Solaris (but I suspect not). 3. Configure the boot sequence so the vendor-provided SNMP and DMI services aren't restarted at next reboot:
[2:41pm wally]# cd /etc/rc3.d [2:41pm wally]# mv S76snmpdx No.S76snmpdx [2:41pm wally]# mv S77dmi No.S77dmiRenaming the startup scripts effectively removes them from the boot sequence. You may find these scripts with different names on other versions of Solaris, but I doubt it. 4. Configure the "managers" that can send SNMP requests to the mibiisa(1) server -- edit the snmpd.conf file. Here's what we use (note that we've filled in the "system" information, restricted the service to only "public" information, tossed anything to do with "traps", and restricted the managers to just ratbert):
[2:43pm wally]# cd /etc/snmp/conf [2:43pm wally]# egrep -v '^$|^#' snmpd.conf sysdescr Sun SNMP Agent, SPARCstation-10 syscontact dilbert@ist.uwaterloo.ca sysLocation IST Machine Room, Rack 4, Tray 3 system-group-read-community public read-community public managers ratbertThe grep in the example tosses all commentary and empty lines -- there's not much to the file. Note the configuration shown only allows ratbert to query wally. It's a very simple configuration -- we've even tossed the traps that we didn't need. We've updated the "system" information so we can find the system (its physical location) and the support person. 5. Configure your boot sequence to bring up only the mibiisa(1M) daemon. Make sure you bring it up in read-only mode. Here's a sample configuration you might want to use:
#!/sbin/sh
#
# $Id: Solaris_SNMP_Harden.html,v 1.3 2000/10/27 21:00:54 reggers Exp $
#
# Start the minimal SNMP services required for select managers to get public
# data. Install as /etc/rc3.d/S99mibiisa (or insert into your favorite local
# boottime script). Make sure you disable S76snmpdx and S77dmi in the same
# directory.
#
# Reg Quinton <reggers@ist.uwaterloo.ca>; 5-Oct-2000
case "$1" in
'start')
/usr/lib/snmp/mibiisa -r </dev/null >/dev/null 2>&1 &
;;
'stop')
/usr/bin/pkill -9 -x -u 0 'mibiisa'
;;
*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
exit 0
The script should be installed in /etc/rc3.d and made executable.
6. Finally, you can start the daemon manually (it will be started automatically at next reboot if you installed the script in /etc/rc3.d):
[2:45pm wally]# ./S99mibiisa start
[2:45pm wally]# ps -ef | grep mibiisa
root 19762 1 0 11:55:35 ? 0:00 /usr/lib/snmp/mibiisa -r
[2:45pm wally]# lsof -i | grep snmp
mibiisa 19762 root 2u IPv4 0x300011f8660 0t0 UDP *:snmp (Idle)
If the daemon fails to start, you should check the audit trail
in /var/log/syslog. If you follow these recommendations,
you will have eliminated three daemons (snmpdx(1M), dmispd(1M),
and snmpXdmid(1M)) and nine network entry points. You'll
now have only one daemon (mibiisa(1M)) and one network
entry point -- the snmp port serviced by that daemon.
You will have made your system more secure.
References Sun Blueprints Online -- see the security papers. Sun Product Documentation -- includes Answerbook. SUNSOLVE ONLINE -- includes vendor patches. The Solaris Security FAQ (Sunworld, Peter Baer Galvin). Reg Quinton is a security professional at the University of Waterloo in Ontario, Canada. He has been working with UNIX systems in the education environment since 1983. His home page is http://ist.uwaterloo.ca/~reggers. This paper is an extract of a larger work in progress on Solaris Network Hardening |