Understanding the Importance of Net-SNMP for Linux Systems

SNMP (Simple Network Management Protocol) monitors devices by using a hierarchical tree of objects that are defined and organized in MIB files. A number and a text string identify each object.

Luckily, Linux systems come with an open, standards-compliant protocol implementation in installing and configuring Net-SNMP for Linux. Here are a few things you should know about it.

SNMP Community Strings

The SNMP protocol allows an administrator to read and sometimes write to a network device’s management information base (MIB). Each MIB object has a unique identifier called an object instance number (OID).

An attacker can access the SNMP interface of a router or other networking equipment by knowing or guessing a community string. The best practice is to make the community string difficult to guess and not use any passwords used elsewhere on the network or other devices.

Another good practice is to set the SNMP agent to operate in read-only mode so that an attacker cannot modify a device’s configurations remotely. Finally, always use SNMP version 3, which adds encryption and authentication for a more secure system. In addition, ensure that the SNMP agent is configured for the latest firmware version on the device. This can help defend against many known vulnerabilities. Using a program like SNMP Enabler to check your network devices is an easy way to verify that the proper SNMP settings are in place.

SNMP Security

SNMP enables network devices to exchange information about their status and performance. A combination of push accomplishes this and pull communications between the device and the management system. Each device is identified by a Management Information Base (MIB) entry with an object identifier.

MIBs contain various information, including a description of the device’s hardware, firmware version, and other configuration settings. Network managers can use SNMP GET requests to retrieve this information or SNMP SET commands to change the status of a device.

SNMP is particularly vulnerable to security attacks because it communicates community strings in clear text. This vulnerability can be mitigated by restricting SNMP access to read-only and encrypting SNMP traffic when possible. SNMPv3 addresses this issue by adding authentication and encryption features. Keeping the firmware of your network devices updated will also reduce the risk of these vulnerabilities being exploited. SNMPv2c uses the same basic architecture but adds support for 64-bit counters and enhanced error-handling support.

SNMP Agents

SNMP Agents are software modules embedded in network devices like switches, routers, and servers. They collect device data and compile it in a readable format for NMS tools to query and monitor.

Each SNMP Agent has a Management Information Base, or MIB, a collection of managed objects arranged hierarchically. Each managed object is identified by a unique identifier called an OID. The SNMP Manager can request values for specific OIDs using Get requests. It can also retrieve a set of values from a table using a Set request.

Unfortunately, SNMP v1 and v2 have inherent security risks. SNMP Community Strings are transmitted in plain text, making it easy for malicious entities to discover the string and use it to spoof network devices or reconfigure them. Fortunately, SNMP v3 makes major strides in addressing these security issues. This is why most network engineers and admins stick with v3 or later.

SNMP Traps

SNMP traps allow an SNMP manager to monitor network devices without polling them. An SNMP trap is sent from the device to the SNMP manager based on any number of inputs, such as contact closure alarm inputs (like those found on our NetGuardian 832A RTU).

Normally, the device agent only sends out a status message when prompted by a request from the SNMP manager. However, when the device agent detects an emergency on its managed device, it will send a trap to the SNMP manager without waiting to be polled.

The SNMP manager can then decide what to do with the trap; for example, it may filter the trap into an alert for the system user or log the message to syslog. The type of event a surprise is filtered for depends on the SNMP TRAP policy in the snmpd configuration file. SNMP version differences also impact the handling of traps; for example, SNMPv1 only supports 32-bit counters, which may cause undetected value rollover and corrupt trend-tracking data.