SNMP

SNMP

Most servers, routers and firewalls keep their operational statistics in object identifiers (OIDs) that you can remotely retrieve via the Simple Network Management Protocol (SNMP). For ease of use, equipment vendors provide Management Information Base (MIB) files for their devices that define the functions of the OIDs they contain. That's a lot of new terms to digest in two sentences, so take a moment to look more closely.

OIDs and MIBs

OIDs are arranged in a structure of management information (SMI) tree defined by the SNMP standard. The tree starts from a root node, which then descends through branches and leaves that each add their own reference value to the path separated by a period. Figure shows an OID structure in which the path to the enterprises OID branch passes through the org, dod, internet, and private branches first. The OID path for enterprises is, therefore, 1.3.6.1.4.1.

Management Information Bases (MIBs) are text definitions of each of the OID branches. Figure shows how some commonly used OIDs map to their MIB definitions. For example, the SMI org MIB defines all the topmost OIDs found at the next layer, which is named dod; the internet MIB under dod defines the function of the topmost OIDs in the directory, mgmt, experimental, and private branches. This MIB information is very useful for SNMP management programs, enabling you to click on an OID and see its value, type, and description.

You can refer to an OID by substituting the values in a branch with one of these more readable MIB aliases. For example, you can reference the OID 1.3.6.1.4.1.9.9.109.1.1.1.1.5 as enterprises.9.9.109.1.1.1.1.5.1 by substituting the branch name (enterprises) for its OID numbers (1.3.6.1.4.1).

Remember, only the OID value at the very tip of a branch, theleafactually has a readable value. Think of OIDs like the directory structure on a hard disk. Each branch is equivalent to a subdirectory, and the very last value at the tip (the leaf) correlates to a file containing data.

The Linux snmpget command outputs the value of a single leaf, and the snmpwalk command provides the values of all leaves under a branch. I'll discuss these commands later; for now, all you need to know is that the command output frequently doesn't list the entire OID, just the MIB file in which it was found and the alias within the MIB. For example:

     SNMPv2-MIB::sysUpTime.0

Here the OID value was found in the SNMPv2-MIB file and occupies position zero in the sysUpTime alias.

Equipment manufacturers are usually assigned their own dedicated OID branch under the enterprises MIB, and they must also provide information in universally accepted OIDs for ease of manageability. For example, NIC interface data throughput values must always be placed in a predefined location in the general tree, but a memory use value on a customized processor card may be defined in a MIB under the manufacturer's own OID branch.

SNMP Community Strings

As a security measure, you need to know the SNMP password, or community string, to query OIDs. There are a number of types of community strings, the most commonly used ones are the Read Only or "get" community string that only provides access for viewing statistics and system parameters. In many cases the Read Only community string or password is set to the word "public"; you should change it from this easy-to-guess value whenever possible. The Read/Write or "set" community string is for not only viewing statistics and system parameters but also for updating the parameters.

SNMP Versions

There are currently three versions of SNMP:

• SNMP Version 1: The first version of SNMP to be implemented, version 1 was designed to be a protocol to provide device statistics and error reporting without consuming a lot of system resources. Security was limited to community strings and access controls based on the IP address of the querying server. Data communication wasn't encrypted.

• SNMP Version 2: The second version of SNMP, often referred to as v2c, expanded the number of supported error codes, increased the size of counters used to track data, and had the ability to do bulk queries that more efficiently loaded response packets with data. SNMP v2c is backward compatible with version 1.

• SNMP Version 3: This version provides greater security and remote configuration capabilities than its predecessors. Access isn't limited to a single community string for read-only and read/write access, as usernames and passwords have been introduced. Views of OIDs in a MIB can also be limited on a per-user basis. Support for encrypted SNMP data transfer and transfer error detection is also provided.

Remember their differences, because you will need to specify the version number when doing SNMP queries.

Doing SNMP Queries

Configuring SNMP on a server isn't hard, but it does require a number of detailed steps.

Installing SNMP Utilities on a Linux Server

If you intend to use your Linux box to query your network devices, other servers or even itself using MRTG or any other tool, you need to have the SNMP utility tools package net-snmp-utils installed. When searching for the file, remember that the SNMP utility tools RPM's filename usually starts with net-snmp-utils, which is followed by a version number, as in net-snmp-utils-5.1.1-2.i386.rpm. (If you need an installation refresher, see Chapter 6, "Installing RPM Software.")

SNMP Utilities Command Syntax

The SNMP utility tools package installs a number of new commands on your system for doing SNMP queries, most notably snmpget for individual OIDs and snmpwalk for obtaining the contents of an entire MIB. Both commands require you to specify the community string with a -c operator. They also require you to specify the version of the SNMP query to be used with a -v 1, -v 2c, or -v 3 operator for versions 1, 2, and 3, respectively. The first argument is the name or IP address of the target device and all other arguments list the MIBs to be queried.

This example gets all the values in the interface MIB of the local server using SNMP version 1 and the community string of craz33guy.

     [root@bigboy tmp]# snmpwalk -v 1 -c craz33guy localhost interface
     ...
     ...
     IF-MIB::ifDescr.1 = STRING: lo
     IF-MIB::ifDescr.2 = STRING: eth0
     IF-MIB::ifDescr.3 = STRING: eth1
     ...
     ...
     IF-MIB::ifPhysAddress.1 = STRING:
     IF-MIB::ifPhysAddress.2 = STRING: 0:9:5b:2f:9e:d5
     IF-MIB::ifPhysAddress.3 = STRING: 0:b0:d0:46:32:71
     ...
     ...
     [root@bigboy tmp]#

Upon inspecting the output of the snmpwalk command, you can see that the second interface seems to have the name eth0 and the MAC address 0:9:5b:2f:9e:d5. You can now retrieve the individual MAC address using the snmpget command:

      [root@bigboy tmp]# snmpget -v 1 -c const1payted localhost
     ifPhysAddress.2
     IF-MIB::ifPhysAddress.2 = STRING: 0:9:5b:2f:9e:d5
     [root@bigboy tmp]#

You can confirm this information using the ifconfig command for interface eth0; the very first line shows a matching MAC address:

     [root@bigboy tmp]# ifconfig -a eth0
     eth0      Link encap:Ethernet  HWaddr 00:09:5B:2F:9E:D5
               inet addr:216.10.119.244  Bcast:216.10.119.255
     Mask:255.255.255.240
     ...
     ...
     [root@bigboy tmp]#

You'll now see how you can configure SNMP on your Linux server to achieve these results.

Configuring SNMP on a Linux Server

By default Fedora, installs the net-snmp package as its SNMP server product. This package uses a configuration file named /etc/snmp/snmpd.conf in which the community strings and other parameters may be set. The version of the configuration file that comes with net-snmp is quite complicated. I suggest archiving it and using a much simpler version with only a single line containing the keyword rocommunity followed by the community string. Here is an example:

[root@bigboy tmp]# cd /etc/snmp/
[root@bigboy snmp]# mv snmpd.conf snmpd.conf.old
[root@bigboy snmp]# vi snmpd.conf

rocommunity craz33guy

[root@bigboy root]# chkconfig snmpd on
[root@bigboy root]#

[root@bigboy root]# service snmpd start
Starting snmpd: [ OK ]
[root@bigboy root]#

[root@bigboy snmp]# snmpwalk -v 1 -c craz33guy localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux bigboy 2.4.18-14 #1 Wed Sep
4 11:57:57 EDT 2002 i586
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (425) 0:00:04.25
SNMPv2-MIB::sysContact.0 = STRING: root@localhost
SNMPv2-MIB::sysName.0 = STRING: bigboy
...
...
...
[root@bigboy snmp]# snmpwalk -v 1 -c craz33guy localhost interface
IF-MIB::ifNumber.0 = INTEGER: 3
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: wlan0
IF-MIB::ifDescr.3 = STRING: eth0
...
...
...
[root@bigboy snmp]#

Now that you know SNMP is working correctly on your Linux server, you can configure SNMP statistics gathering software, such as MRTG, to create online graphs of your traffic flows.

SNMP on Other Devices

In the example, you were polling localhost. You can poll any SNMP-aware network device that has SNMP enabled. All you need is the IP address and SNMP Read Only string and you'll be able to get similar results. Here is an example of a query of a device with an IP address of 192.168.1.1.

     [root@bigboy snmp]# snmpwalk -v 1 -c chir1qui 192.168.1.1 interface

Different SNMP Versions

There are currently three versions of SNMP; versions 1, 2 and 3. The Linux snmpwalk and snmpget commands have -v 1, -v 2c, and -v 3 switches for specifying the SNMP version to be used for queries. Always make sure you are using the correct one.

Basic SNMP Security

The most commonly supported versions of SNMP don't encrypt your community string password so you shouldn't do queries over insecure networks, such as the Internet. You should also make sure that you use all reasonable security measures to allow queries only from trusted IP addresses either via a firewall or the SNMP security features available in the snmp.conf file. You can also configure your server to use the TCP wrappers feature outlined in Appendix I, "Miscellaneous Linux Topics," to limit access to specific servers without the need of a firewall.

In case you need it, the snmpd.conf file can support limiting MIB access to trusted hosts and networks.

The snmpd.conf file has two security sections; a section with very restrictive access sits at the top of the file and is immediately followed by a less restrictive section. The example that follows is a modification of the less restrictive section. You will have to comment out the more restrictive statements at the top of the file for it to work correctly.

     ##       sec.name     source           community
     ##       ========     ======           =========
     com2sec  local        localhost        craz33guy
     com2sec  network_1    172.16.1.0/24    craz33guy
     com2sec  network_2    192.16.1.0/24    craz33guy


     ##       Access.group.name   sec.model        sec.name
     ##       =================   =========        ========
     group    MyROGroup           v1               local
     group    MyROGroup           v1               network_1
     group    MyROGroup           v1               network_2


     ##   MIB.view.name     incl/excl  MIB.subtree  mask
     ##   ==============    =========  ===========  ====
     view all-mibs          included   .1           80


     ##      MIB
     ##      group.name context sec.model sec.level prefix read     write
     notif
     ##      ========== ======= ========= ========= ====== ====     =====
     =====

     access  MyROGroup  ""      v1       noauth    0      all-mibs none
     none

In the example:

• Only three networks (localhost, 172.16.1.0/24, and 192.168.1.0/24) are allowed to access the server with the craz33guy community string.

• Each network is matched to a group called MyROGroup using SNMP version 1, and all the MIBs on the server are defined by the view named all-mibs.

• An access statement ensures that only the defined networks have read only access to all the MIBs.

• Modification of the MIBs via SNMP is denied because the word "none" is in the write section of the access statement.

These precautions are probably unnecessary in a home environment where access is generally limited to devices on the home network by an NAT firewall.

Simple SNMP Troubleshooting

If your SNMP queries fail, then verify that:

• You restarted your snmp.conf file so the configuration settings become active. Remember, the snmpd.conf file is only read by the snmpd daemon when it starts up.

• You are using the correct community string.

• Firewalls aren't preventing SNMP queries from the SNMP client to the SNMP target.

• Your SNMP security policy allows the query from your network.

• Any TCP wrappers configuration on your SNMP target machine allows SNMP queries from your SNMP client. Generally speaking in a home environment protected by NAT your TCP wrappers files (/etc/hosts.allow) and (/etc/hosts.deny) should be blank.

• Network routing between the client and target devices is correct. A simple ping or traceroute test should be sufficient.

• The snmpd daemon is running on the SNMP client.

• You are querying using the correct SNMP version.

• Your /var/log/messages file does not contain errors that may have occurred while starting snmpd.

Troubleshooting to get functioning SNMP queries is important as many other supporting applications such as MRTGwhich I'll discuss nextrely on them in order to work correctly.