Networking / Beginners

---

Enabling SNMP on Linux Hosts

If you want to collect data using SNMP from a Linux host, the first step is to see if the SNMP daemon (snmpd) is already installed. You can enter chkconfig -list snmpd, which will list the snmp daemon if it is installed, and indicate which run levels it is configured to start in. If the daemon is not installed, it can be installed using whatever method is appropriate for your distribution. On Fedora Core 5, for example, all it takes is yum install net-snmp. The daemons and some utilities are included in the net-snmp package. There is also the net-snmp-utils package, which includes utilities aimed more at using SNMP, such as MIB browsers and such, but does not include the daemon.

After you have snmpd installed, it needs to be configured. We will discuss two ways to configure snmpd. The current version of the daemon is very robust, which has the side effect of including a very complicated configuration file located at /etc/snmp/snmpd.conf. The simplest way to get SNMP up and running to just collect data, is to save the sample snmpd.conf file under a new name and create your own.The new snmpd.conf can contain only the single line rocommunity labcommunitystring. In this example, the read-only community string would be set to labcommunitystring. Obviously, you should select a secure password of your own.This type of configuration file is quick and easy but not overly secure.

You could also use the netfilter firewall and/or tcpwrappers to restrict SNMP access based on the IP address of the communicating system. Another option is to use the access control built into the SNMP daemon.To configure the snmpd access control, you will need to edit the snmpd.conf file. Granting access to the SNMP MIB requires four basic steps, which are all done in the configuration file.The example below includes a variety of configuration settings to hopefully provide a good idea of the possibilities. Add the following lines to the configuration file.

## 	sec.name 	source 		community
## ---------------------------------------------------------
com2sec local 		localhost 	snmplocalstring
com2sec internal 	10.0.0.0/8 	snmpcommunitystring
com2sec admin_net 	192.168.1.0/24 	snmpadminstring

These lines serve to map a community name to a security name, thus the com2sec directive. The security name is just a name to use to reference the access you are granting. You can use whatever name you like.The source is the hosts that will use that access profile. You can also use a source of default, which will mean any IP address. The community is the community string to be used for that access. Note that there is no differentiation made between a read-only community string and a read-write community string.This is because the access that the security name will have will be defined later in the configuration file.

## 	Access.group.name 	sec.model 	sec.name
## ---------------------------------------------------------
group 	Full_Group 		v1 		local
group 	RO_Group 		v2c 		internal
group 	Full_Group 		any 		admin_net

The next section maps a security name into a group name using the group directive. In this case, we mapped both the local security name and the admin_net security name to the same group (Full_Group).The sec.model determines which version of SNMP (1 or 2) will be used/allowed. Using version 3 requires a different configuration altogether.

## 	MIB.view.name 	incl/excl 	MIB.subtree 	mask
## ---------------------------------------------------------
view 	all-mibs 	included 	.1
view 	limited 	included 	.1.3.6.1.2.1.2

This section defines a view, which basically defines a portion of the MIB tree.The all-mibs view includes the entire MIB tree, whereas the limited view includes only the .1.3.6.1.2.1.2 section, which consists of the network interfaces and related metrics.You can configure a given view's MIB subtree to be included or excluded. By excluding, you can omit certain sensitive portions of the MIB tree. You can use the MIB tree name instead of the number if desired. In the example used above, you could use included .1.3.6.1.2.1.2 or you could instead use this command: included .iso.org.dod.internet.mgmt.mib- 2.interfaces. The mask is an optional bit mask on the MIB tree that specifies which bits to match for the indicated access.The default (without the mask) is to match only the bits that are indicated in the view.You would most commonly use the mask to match a particular row or rows in a table. So in this example, the all-mibs view has access to .1 and everything under it.

## MIB.group.name context sec.model sec.level    rite  notif
prefix read 
## ---------------------------------------------------------------
access Full_Group "" 	any    noauth     0    all-mibs none none
access RO_Group   "" 	any    noauth     0    limited  none none

The final section is where you define access for a group name to a view. The context is optional and no context,"" is the default. For SNMP v1 or v2, the sec.level needs to be noauth. Under the read and write column, you define the view.The notify column is where you would specify the capability to send traps, except the notify view is not currently implemented.

After making your changes, you will need to restart the snmpd for the changes to take effect. So what does all this accomplish? The MIB is accessible form the localhost using the snmplocalstring as the community string, which will provide read access to the entire MIB tree. Users from the 10.0.0.0/8 networks, which are assumed to be the bulk of the user base, can access the MIB using the snmpcommunitystring community string, and they will have read-only access to the network interface subtree only. Hosts on the 192.168.1.0/24 subnet, a network management subnet for example, can use the snmpadminstring community string to gain read-only access to the entire MIB tree.

After all this configuring you might be wondering what the difference is between one version of SNMP and another. As the protocol has matured, it has gone through several changes, the majority of which revolve around security. The basic differences between one version and another are highlighted for your reference.

• SNMP v1 Included only basic functionality and sent SNMP data using clear text.
• SNMP v2 Mostly introduced security features, including two new branches of the MIB tree, 1.3.6.1.5 (security) and 1.3.6.1.6 (SNMPv2). Introduced the GetBulk operation, used for requesting large amounts of data in a single request. SNMP v2 also sends information using clear text.
• SNMPv3 Introduced the digest authentication protocol, which is used for data integrity, ensuring that the message that was sent is the same one that is received using MD5. Introduced the symmetric privacy protocol to ensure data confidentiality using Data Encryption Standard (DES) encryption. Note that DES is not generally considered secure by modern standards and was replaced with triple DES (3DES), and, more recently, with Advanced Encryption Standard (AES). Introduced the User-based Security Model (USM) and the View-based Access Control Model (VACM).