SNMP, is it as simple as the name implies?

SNMP or Simple Network Management Protocol was created to jointly manage all devices within a network, regardless of the type of device. This was a true development within the industry when managing devices connected to an Ethernet network due to its consistency, so most industrial devices are provided with a configurable SNMP agent.

This protocol is used for the network configuration information of a certain device. Due to the wide variety of industrial devices, sometimes from different manufacturers, involved in the different levels of the automation pyramid, the use of this protocol is certainly widespread.

We can say that the SNMP is a protocol that facilitates the exchange of information, SNMP messages, which is relevant regarding the configuration of the device, between the Manager or controller and the Agent or managed device. SNMP messages may be contained in monitoring or reading messages (get) and control or writing message (set). A special functionality of the SNMP, highly valued by system administrators, are TRAPS. This type of SNMP Trap network was designed to send notifications from a device or agent to the notification receiver (SNMP TRAPS). It allows to send different types of notifications: ‘start’, ‘stop’, ‘warm start’, ‘failure’, etc. It also allows to set up a number of events to be sent by this type of SNMP network, based on the specific device.

SNMP is implemented at layer 7 of the OSI model or application layer and it is usually sent by UDP/IP through ports 161 and 162. It currently has different versions based on the security level they apply.

SNMP in detail

In order to fully understand a SNMP network we need to think of it as a group of nested fields. The main information fragment is the OID, which exactly identifies the value to be read (get) or to be written (set). The OID (Object IDentifier) set available to a device is known as MIB (Management Information Base) and it acts as a table of contents where we can find the reference we are looking for. The type of data of OID are defined by ASN.1 and they employ a specific encoding called BER (Basic Encoding Rules).

For example, by means of a SNMP get network, with an OID .1.3.6.1.2.1.1.1 corresponding to a description of the sysDesc() device, represented in the image of the MIB tree, we will receive a response by the device with its corresponding value:

- Example of a response by a device after a request sysDesc() OID .1.3.6.1.2.1.1.1 -

- MIB chart and representation of OID -

If we think of the folder structure of computer files, the file with its corresponding file path would be an OID and the group of folders and files of a certain unit would be a MIB. The same device may have several disc units (Several MIB). Within each unit, all files (OID) are previously known, they are written and well-defined. Their content is stored by means of the SMI standard (Structure of Management Information).

- Example of a SMI information structure and its fields, of an OID contained on a MIB file -

ASN.1

When dealing with different types of data, as is the case with different programming languages, the number of bits used for their encoding may vary. In order to avoid different interpretations when dealing with, for example, Integer, an identifier and a variable length size are defined. This ensures that whenever an identifier appears, we can exactly know its encoding equivalence and the fact that such encoding is specific. SNMP offers two different data sets: primitive data type and complex data type, as shown in the table below.

- Table with examples of primitive and complex data types -

The length for these data types is variable so in order to solve this problem the BER (Basic Encoding Rules) is defined. A BER defines a standard format for encoding data types, both primitive and complex. Fields defined are the following:

• Type: Corresponding to the identifier shown in the table.
• Length: Length or size of the data field.
• Data: Value of the data type

Complex data types are defined as a nested sequence of fields.

- Encoding structure of a primitive data type -

The length field, which tells us the length in bytes of the data type, may need a value greater than 127. The length coding is done in a special way. The following describes how the length field encodes, for values above 127.

To encode a high number, e.g. 1002, a first octet consisting of the 'most significant bit' whose value is set to '1' is used to indicate that the length value is made up of a long number, and the next 7 'least significant' bits are used to indicate the next number of octets, which is where the long number is actually encoded. In the present case, to represent 1002 2 octets will be needed, so this first octet will be coded as 10000010 (0x82), indicating as shown in the image, that it is a large number and is followed by 2 Octets. The next two octets encode the value of the number, as is, using all the bits of the octets in their encoding.

- Rule for encoding large numbers in bytes for SNMP Field Length -

Not to be confused with the encoding of a large number within an OID field, as it is done in a different way:

- Encoding structure of complex data types -

- Traffic capture of a SNMP get-response request in wireshark -

Two needed nuances to fully understand the way values are coded in an OID:

• “Object Identifier”: The first two numbers of an OID (x.y….) are encoded using the special formula(40×x)+y, so the two first numbers of the OID (1.3….) = (40×1)+3=43=0x2B, sending (0x2B), the rest is encoded by means of the their hexadecimal correspondence of the integer. So, for an OID = 1.3.6.1.2.1.1.5.0, the corresponding encoding will be:

- Rule for the encoding of an OID in bytes for SNMP -

• Integers over 127 are specially encoded in OIDs, since more than one byte is necessary because the first (heaviest) bit is reserved. The specific rule for encoding large numbers that may appear in an OID is as explained below: the first bit of the first octet (byte) set to 1 indicates that it is a large number, and only the remaining 7 bits are used to form the number. Beginning to create bytes with the 7 least significant bits, using the most significant bit as 'FLAG', indicating, with a '1' if they continue bytes to delimit the number or with a '0' indicating that they are the last 7 bits of the number we are going to represent. Suppose we have inside an OID a large number (greater than 127) that we need to encode, for example, the number 1002. This will be coded in the following way (0x87 0x6A), as we see in the image:

- Rule for the encoding of large numbers in bytes for SNMP -

SNMP networks may be divided into two sections:

• SNMP Header: This section includes all control fields necessary for the processing of such network, as well as fields including security (version, community, type of encryption, if any, etc.).
• SNMP Body or PDU Data: It contains all information fields regarding the protocol (request type, ID, Error, OID, Value, etc.).

Analysis of a complete SNMP message:

- Traffic caption and explanation of all bytes of a SNMP network in wireshark -

- Bytes sent in the Header and Body of a SNMP message -

The SNMP network, as we can see in the picture, is considered a "sequence" starting with ‘0x30’ followed by the complete length of network ‘0x32’ (50 bytes). This network is transferred by the UDP/IP protocol:

- UDP encapsulation of a SNMP message -

PROPRIETARY MIB... DO WE KNOW WHAT THEY ENABLE?

All SNMP regulations state that any good practice would entail avoid using the protocol for configurations that may affect the behaviour of the device within the network. SNMP standards have virtually no variables the "ACCESS" of which, a variable which defines the way of accessing data (Reading, Reading/Writing), is in mode 'Read-Write'. This rule is not compulsory and there are many industrial manufacturers that take advantage of these configuration options to include certain functionalities in their industrial devices. This additional functionalities are described in the private MIB of the manufacturers.

Before performing a proper hardening of our SNMP agents we need to carry out an analysis of the MIB of our devices so as to establish if they have private MIB, analyse their scope and perform a risk report.

MIB files are similar to programming libraries, where OID functions are stored which, when called, provide a result.

OIDs are designed to show certain information, but they also used by some manufacturers to shift from one state to another, for example, or to reconfigure the manner the network is accessed. OID functionalities may be endless, so it is important to know them. A common option of a standard OID may be providing information on the manner of accessing the DHCP, BOOTP network but if a manufacturer, to make certain tasks easier, adds the possibility of shifting that state by means of said OID by changing a variable to Read-Write, then it becomes a control OID to be taken closely into account.

- Example of OIDs allowing to enable DHCP, BOOTP or to deactivate corresponding to a private MIB -

Manufacturers design private MIB in order to facilitate configuration among their products assuming a proper hardening of all elements of the network and without taking into account the functionalities of the device corresponding to a SNMP configuration which has not been properly hardened.

- Actual examples of OIDs with "additional functionalities" in private MIB -

Manufacturers have taken advantage of this SNMP characteristic to create true API as private MIB files allowing in some cases that a certain devices enables too many uncontrolled sensitive configuration options which are often unknown to their users.

- Examples of OIDs with "additional functionalities" in private MIB -

HARDENING

Once our risk report is carried out based on the MIB used for our industrial device, we are proceeding with the proper hardening of the SNMP agent. It is important to take into account the following good practices:

• If you do not need it, deactivate it.
• Do not use the default configuration under any circumstances. Use any time needed to properly set up the SNMP agent.
• Use the safest SNMP version enabled by the devices.
• If the risk report recommends a security level higher than the one enabled by the configuration of the device, apply additional measures, whenever possible, outside of the hardening of the device.

We would usually find different SNMP configuration environments. However, all of them, to a greater or lesser extent, must contain certain common fields which are key for a proper hardening.

- Configuration field regarding the selection of the SNMP version -

You must make sure to select the highest version accepted by our devices. It may be considered that SNMPv1 and SNMPv2c do not have sufficient security option, so we must avoid using those versions if possible, enabling communication to the agent by means of SNMPv3.

- Configuration field regarding IP enabled to manage the SNMP agent -

It is important to have configurations which are as restrictive as possible, single/individual IP, avoid enabling IPs by ranges or network masks and, most importantly, avoid default configurations.

- Configuration field regarding the selection of community password for SNMP -

Options will be conditional upon the type of device and the manufacturer and so options may significantly vary. The "Deactivate" option is the best option if we don't really need it. It is important to change the default password since it is included in every manual of the device. Complying with the length restrictions established by the manufacturer, it is important to create robust passwords.

The following fields are usually additional security options offered depending of the SNMP version chosen. To the extent possible, their use is always recommended.

- Configuration field regarding the selection of authentication coded for SNMPv2 and following versions -

- Configuration field regarding encryption of the SNMP message -

These security measures were introduced in version SNMPv2u User-Based Security Model (USM), and kept in version SNMPv3.

- Configuration field regarding VACM (View-Based Access Control Model) for SNMPv3 -

VACM (View-Based Access Control Model) is part of the SNMPv3 standard which, depending of the model and the manufacturer, shall provide certain options but the functionality is the same: creating accesses to certain OIDs grouped by users or roles, thus creating views for the different profiles of the industrial process.

MY SNMP_007 AGENT IS NOT THAT GOOD...

There are times in which hardening measures provided by the manufacturer are not robust enough. In these cases, we must apply additional measures, such as the following ones:

Add firewalls to the least robust industrial devices by creating rules to accept or reject SNMP traffic.

Being familiar with SNMP network may help us perform a passive traffic analysis and warn of odd behaviours in the network as well as create rejection rules for networks by means of deep packet inspection. In order to improve the security in devices which do not offer such security in their configuration, you may also use specific IDS/IPS tools to reject SET SNMP networks or more specific within the SNMP network such as the shutting of the traffic of specific OID which may be particularly important.

A deep knowledge of our protocols, as well as of the functionalities offered by our devices, are key when preparing risk reports. The configuration of any device must be methodical and be based on information and analysis. Default configurations are never an option. The information flow between the manufacturer and operators from all tiers (Field operation, Systems, Supervision, etc.) must be ongoing. These are the basis for a proper hardening of any device.