ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Big Scary Daemons

Talk the SNMP Talk

08/10/2000

Related Articles:

Walk the SNMP Walk

Long-Term Monitoring with SNMP

Customizing mrtg

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 needs.

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 source, and 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 blat89h group.

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 ReadWrite.

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. The ReadWrite group, which only contains our snmphost, can read or write any MIB in the tree.

The example 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.