In my last article on BSD SNMP, we looked at installing the ucd-snmp package and using the snmpwalk tool. If you want to use the SNMP agent on your system, you need to set up the snmp daemon.
Rather than installing a default configuration file, the ucd-snmp port
installs a default configuration file in
/usr/local/share/examples/ucd-snmp/EXAMPLE.conf. This default
configuration includes a variety of possible security holes, in
addition to having default communities. You'll want to copy this to
/usr/local/share/snmp/snmpd.conf, and edit to fit your particular
Those of you experienced with SNMP are familiar with the default
communities of "public" and "private." You probably don't want to use
those, as they're the first thing an intruder will look for. Choosing
community names is like choosing passwords: Don't use easily-guessable
ones; don't use commonly-known words; mix letters and other
characters; and so on. If you don't intend to allow anyone to use
write-SNMP commands on your system, then you probably only need one
community name. In these examples I'm only going to set up read-only
access; nobody writes SNMP on any servers I run. Open your new
snmpd.conf file in your favorite text editor and follow along.
As usual, a leading # indicates a comment. Search for the first uncommented section. It should look something like this:
# sec.name source community com2sec local localhost COMMUNITY com2sec mynetwork NETWORK/24 COMMUNITY
com2sec is a generic label indicating that this line maps community
names and source IP addresses to security groups. The name of the security group is
sec.name. The source IP address is
community is the community name. The two examples given are good, but
you can be as specific as you like.
You can put any IP address, or range of IP addresses with a netmask, under source. For example, if you have a single workstation that is allowed to make SNMP queries, you could use:
com2sec snmphost 192.168.1.8 blat89h
The only host that could use SNMP on your BSD box would be
192.168.1.8, and only if it asked for the
If your entire internal network could make SNMP queries with that community name, you could use:
com2sec mynetwork 192.168.1.0/24 GoAway!
If you're feeling truly trusting, you could use:
com2sec world 0.0.0.0/0 public
Anyone who tried the default community could access your SNMP agent. If you do this, be sure you have nothing to hide.
The second section of the configuration file that you need to configure maps security communities to SNMP types and groups. SNMP comes in three flavors, version 1, version 2, and version 3. If you know what sort of SNMP utilities you want to use, you can specify which versions you want to use. Otherwise, you're probably better off allowing all three sorts on your system. You can specify groups in any order you like, using the security community names you specified before.
group ReadWrite v1 snmphost group ReadWrite v2c snmphost group ReadWrite usm snmphost group ReadOnly v1 world group ReadOnly v2c world group ReadOnly usm world
In this example, we're allowing the
snmphost protocol to use any
version of the protocol, and putting it in the group
You can restrict groups to only examining certain portions of the SNMP tree, or deny them access to parts of the tree. One set of access rights, or restrictions, is called a view. The example configuration file includes a view that allows the user to see the entire MIB tree:
# incl/excl subtree mask view all included .1 80
You can define other views, based on the contents of the MIB tree. For example, if you want a view that only allows people to see the system portion of the MIB tree, you could do:
view systemOnly included system 80
This would mask out portions of the MIB tree outside the system area.
Lastly, we'll give our two groups different access to the SNMP tree:
# context sec.model sec.level match read write notif access ReadOnly "" any noauth exact systemOnly none none access ReadWrite "" any noauth exact all all none
This configuration allows the
ReadOnly group (anyone in the world who
uses the "public" community name) access to read the system MIB tree.
ReadWrite group, which only contains our snmphost, can read or
write any MIB in the tree.
snmpd.conf includes methods of running scripts on your
system, but you don't need to use them. I highly recommend you
comment those out unless you know exactly what you're doing.
Later, we'll look at long-term monitoring of your system with SNMP.
Michael W. Lucas
Read more Big Scary Daemons columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.
Copyright © 2009 O'Reilly Media, Inc.