Simple Network Management Protocol

The Simple Network Management Protocol or SNMP (from English Simple Network Management Protocol) is a An application layer protocol that facilitates the exchange of management information between network devices. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and many more. It allows administrators to monitor network performance, find and resolve problems, and plan for growth.

SNMP is a component of the Internet protocol suite as defined by the IETF. It consists of a set of rules for managing the network, including a protocol application layer, a schema database, and a set of data objects. The most commonly used SNMP versions are SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2).

In addition to including functions to encrypt data packets, SNMP in its latest version (SNMPv3) has significant changes compared to its predecessors, especially in security aspects; however it has not been widely accepted in the industry.^{[citation needed]}

Basic Concepts

In typical SNMP uses, one or more administrative teams, called managers, are tasked with overseeing or managing a group of hosts or devices on a computer network. On each managed system, a software component called an agent is running at all times, which reports the information via SNMP to the manager. SNMP agents expose management data on managed systems as variables. The protocol also allows performing asset management tasks, such as changing and applying a new configuration through remote modification of these variables. The variables accessible via SNMP are organized in hierarchies. These hierarchies, and other metadata (such as the type and description of the variable), are described by Management Information Bases (MIBs).^{[citation required]}

Basic components

A network managed via SNMP consists of three key components:

• Network management systems (network management systems)Network Management SystemsNMS);
• Managed devices;
• Agents.

These components have the following functions:^{[citation needed]}

A network management system (NMS) runs applications that monitor and control managed devices. NMS's provide the volume of processing and memory resources required for network management. One or more NMS's must exist on any managed network.

A managed device is a device that contains an SNMP agent and resides on a managed network. These collect and store management information, which is made available to the NMS's using SNMP. Managed devices, sometimes called network elements, can be routers, access servers, switches, bridges, hubs, computers, or printers.

An agent is a network management software module that resides on a managed device. An agent has local knowledge of management information (free memory, number of received IP packets, routes, etc.), which is translated into an SNMP-compatible format and organized into hierarchies.

Basic commands

Managed devices are monitored and controlled using four basic SNMP commands: read, write, notify, and traversals.^{[citation required]}

The read command is used by an NMS to monitor network elements. The NMS examines different variables that are maintained by managed devices.

The write command is used by an NMS to control network elements. The NMS changes the values of variables stored within managed devices.

The notify command is used by managed devices to report events asynchronously to an NMS. When a certain type of event occurs, a managed device sends a notification to the NMS.

The traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially collect information into variable tables, such as a routing table.

SNMP Management Information Base (MIB)

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network management protocol, such as SNMP.

A managed object (sometimes called a MIB object, object, or MIB) is one of any number of characteristics specific to a managed device. Managed objects are made up of one or more object instances, which are essentially variables.

There are two types of managed objects: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped together in MIB tables.

An example of a managed object is atInput, which is a scalar object containing a single object instance, the integer value indicating the total number of input AppleTalk packets on an interface of a router.

An object identifier (object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be represented as a tree with an anonymous root and levels, which are assigned by different organizations.

The MIB tree illustrates the various hierarchies assigned by different organizations

Identifiers for objects at the top of the tree belong to different standard organizations, while identifiers for objects at the bottom of the tree are set by partner organizations.

Manufacturers can define private branches that include the managed objects for their own products. MIBs that have not been standardized are typically located in the experimental branch.

The atInput administered object could be identified by the object name iso.identified-organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput or by the equivalent object descriptor 1.3.6.1.4.1.9.3.3.1.

The heart of the MIB tree is made up of several groups of objects, which together are called mib-2. The groups are the following:

• System (1);
• Interfaces (2);
• AT (3);
• IP (4);
• ICMP (5);
• TCP (6);
• UDP (7);
• EGP (8);
• Transmission (10);
• SNMP (11).

It is important to note that the structure of a MIB is described using the Abstract Syntax Notation One standard.

Protocol Details

SNMP operates at the application layer of the Internet protocol suite (layer 7 of the OSI model). The SNMP agent receives requests on UDP port 161. The administrator can send requests from any available source port to port 161 on the agent. The agent's response will be sent back to the source port on the manager. The manager receives notifications (Traps and InformRequests) on port 162. The agent can generate notifications from any available port. When used with Transport Layer Security requests are received on port 10161 and traps are sent on port 10162. SNMPv1 specifies five core protocol data units (PDUs). Two other PDUs, GetBulkRequest and InformRequest were added in SNMPv2 and carried over to SNMPv3.^{[citation required]}

All SNMP PDUs are constructed as follows:

• IP head
• UDP headed community version
• Type of PDU
• Request-ID
• Status error
• Mistake index
• Variable links

SNMP messages

To perform the basic management operations mentioned above, the SNMP protocol uses a connectionless service (UDP) to send a small group of messages (PDUs) between managers and agents. The use of such a mechanism ensures that network administration tasks will not affect the overall performance of the network, since the use of control and recovery mechanisms such as those of a connection-oriented service, for example TCP, is avoided..

Commonly used ports for SNMP are as follows:

The packets used to send SNMP queries and responses have the following format:

• Version: Number of protocol version being used (e.g. 0 for SNMPv1, 1 for SNMPv2c, 2 for SNMPv2p and SNMPv2u, 3 for SNMPv3,...);
• Community: Name or keyword used for authentication. There is usually a reading community called "public" and a writing community called "private";
• SNMP PDU: Content of the Protocol Data Unit, which depends on the operation that is executed.

The GetRequest, GetNextRequest, SetRequest, and GetResponse messages use the following structure in the SNMP PDU field:

• Identifier: It is a number used by the NMS and the agent to send different requests and response simultaneously;
• Status and Error Index: They are only used in GetResponse' messages (in queries, zero is always used). The "indice of error" field is only used when "state of error" is different from 0 and has the objective of providing additional information about the cause of the problem. The "state of error" field may have the following values:
  • 0: There is no mistake;
  • 1: Too great;
  • 2: There is no such variable;
  • 3: Incorrect value;
  • 4: The value is read only;
  • 5: Generic error.
• Linking variables: It is a series of variable names with their corresponding values (coded in ASN.1).

GetRequest

Through this message, the NMS requests the agent to return the value of an object of interest through its name. In response, the agent sends a response indicating the success or failure of the request. If the request was successful, the resulting message will also contain the value of the requested object. This message can be used to collect a value of an object, or several values of several objects, through the use of lists.

GetNextRequest

This message is used to traverse a table of objects. Once a GetRequest message has been used to retrieve the value of an object, the GetNextRequest message can be used to repeat the operation with the next object in the table. Always the result of the previous operation will be used for the new query. In this way an NMS can traverse a variable length table until it has extracted all the information for each existing row.

SetRequest

This type of message is used by the NMS to request an agent to modify object values. To perform this operation, the NMS sends the agent a list of object names with their corresponding values.

GetResponse

This message is used by the agent to respond to a GetRequest, GetNextRequest, or SetRequest message. In the field "Request Identifier" carries the same identifier as the "request" to which you are responding.

Trap

A trap is generated by the agent to report certain conditions and state changes to a management process. The format of the PDU is different:

• Enterprise: Identification of the management subsystem that has emitted the rag;
• Agent address: IP address of the agent that has issued the rag;
• Generic type of rag:
  • Cold start (0): Indicates that the agent has been initialized or reinitialized;
  • Warm start (1): Indicates that the agent configuration has changed;
  • Link down (2): Indicates that a communication interface is out of service (inactive);
  • Link up (3): Indicates that a communication interface is in service (active);
  • Authentication failure (4): Indicates that the agent has received an unauthorized NMS requirement (normally controlled by a community);
  • EGP neighbor loss (5): Indicates that in systems where routers are using the EGP protocol, an adjacent team is out of service;
  • Enterprise (6): In this category are all new rags included by sellers.
• Specific type of rag: It is used for private rags (of manufacturers), as well as to specify the information of a particular generic rag;
• Timestamp: Indicates the time between the reinitialization of the agent and the generation of the rag;
• Linking variables: It is used to provide additional information about the cause of the message.

GetBulkRequest

This message is used by an NMS using version 2 or 3 of the SNMP protocol typically when a long data transmission is required, such as the retrieval of long tables. In this sense, it is similar to the GetNextRequest message used in version 1 of the protocol, however, GetBulkRequest is a message that implies a much faster and more efficient method, since through a single message it is possible to request the entire table.

InformRequest

An NMS that uses version 2 or 3 of the SNMP protocol transmits a message of this type to another NMS with the same characteristics, to notify information about managed objects, using the TCP layer 4 (osi) protocol, and will send the InformRequest until you get an acknowledgment.

Development and Use

Version 1

SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX).. SNMPv1 is widely used and is the de facto network management protocol in the Internet community.

The first RFCs for SNMP, now known as SNMPv1, appeared in 1988:
• RFC 1065 - Structure and identification of management information for the Internet based on TCP / IP.
• RFC 1066 - Management Information Base for TCP/IP-Based Internet Network Management.
• RFC 1067 - A Simple Network Management Protocol.

These protocols were obsolete by:
• RFC 1155 - Structure and Identification of Management Information for the Internet Based on TCP/IP.
• RFC 1156 - Management Information Base for Internet Network Management Based on TCP/IP.
• RFC 1157 - A Simple Network Management Protocol.

After a short time, RFC 1156 (MIB-1) was superseded by the more common:
• RFC 1213 - Version 2 of the management information base (MIB-2) for the management of Internet networks based on TCP / IP.

Version 1 has been criticized for its lack of security. Authentication of clients is done only by a "community string", in effect, a type of password, which it transmits in plain text. The 1980s design of SNMPv1 was done by a group of contributors who saw that the officially sponsored product (HEMS/CMIS/CMIP) by OSI / IETF / NSF (National Science Foundation) were both inapplicable on the computing platforms of the time, as well as potentially unfeasible. SNMP was approved based on the belief that it was an interim protocol necessary to accommodate the large-scale deployment of the Internet and its commercialization. In those days, Internet standards for authentication and security were a dream, at once discouraged by protocol-focused design groups.

Version 2

SNMPv2 (RFC 1441 - RFC 1452), revises version 1 and includes improvements in the areas of performance, security, and communication between managers. Introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large amounts of management data in a single request. However, the new security system based on SNMPv2 parties, seen by many as too complex, was not widely accepted. This version of SNMP reached the maturity level of Standard, but was considered obsolete by later versions.

In the community-based version, Simple Network Management Protocol 2, or SNMPv2c, is defined in RFC 1901 - RFC 1908. SNMPv2c comprises SNMPv2 without the controversial new SNMP v2 security model, using instead the SNMP v2 security model. security based on the simple community of SNMPv1. This version is one of the relatively few standards to meet the IETF draft standard maturity level, and was considered the de facto SNMPv2 standard. This too was later obsoleted by SNMPv3.

In the user version Simple Network Management Protocol 2, or SNMPv2u, is defined in RFC 1909 - RFC 1910. This is a compromise that is intended to offer greater security than SNMPv1, but without incurring the high complexity of SNMPv2. A variant of this was marketed as SNMP v2*, and the mechanism was eventually adopted as one of the two SNMP v3 security frameworks.

SNMPv1 and SNMPv2c interoperability

As currently specified, SNMPv2c is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2c messages use different header and protocol data unit (PDU) formats than SNMPv1 messages. SNMPv2c also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 2576 defines two possible SNMPv1/v2c coexistence strategies: proxy agents and bilingual network management systems.

Proxy Agents

An SNMPv2 agent can act as a proxy agent on behalf of managed SNMPv1 devices, as follows: • An SNMPv2 NMS issues a command destined for an SNMPv1 agent. • The NMS sends the SNMP message to the SNMPv2 proxy agent. • The proxy agent forwards How, GetNext, and Set messages to the SNMPv1 agent without change. • GetBulk messages are converted by the proxy agent to GetNext messages and then sent to the SNMPv1 agent. The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then sends them to the NMS.

Bilingual network management system

Bilingual SNMPv2 network management systems support both SNMPv1 and SNMPv2. To support this dual management environment, a bilingual NMS management application must contact an agent. The NMS examines the information stored in a local database to determine if the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP.

Version 3

Although SNMPv3 makes no changes to the protocol, other than the addition of cryptographic security, it appears to be very different due to new textual conventions, concepts, and terminology.

SNMPv3 mainly added security and SNMP remote configuration enhancements. Due to the lack of security in previous versions of SNMP, network administrators used other means, such as SSH for configuration, accounting, and fault management.

SNMPv3 addresses issues related to large-scale deployment of SNMP, accounting, and fault management. Currently, SNMP is used primarily for monitoring and performance management.

SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of SNMP entities. SNMPv3 provides a secure environment for managing systems that encompass the following:

• Identification of SNMP entities to facilitate communication only between known SNMP entities - Each SNMP entity has an identifier called snmpEngineID and SNMP communication is possible only if the SNMP entity knows the identity of its interlocutor. Traps and notifications are exceptions to this rule.
• Support for security models - A security model can define security policy within an administrative domain or an intranet. SNMPv3 contains the specifications for USM.

Definition of security objectives, where the objectives of the message authentication service include protection against the following:

• Modification of information - Protection against some unauthorized entities that alter SNMP in transit messages generated by a principal authorised.
• Masquerade - Protection against attempting management operations not authorized by a director when assuming the identity of another principal that has the corresponding authorizations.
• Current Message Modification - Protection against messages that get maliciously reordered, delayed, or reproduced to carry out authorized management operations.
• Disclosure - Protection against listening in exchanges between SNMP motors.

Specification for USM - USM (User Based Security Model) consists of the general definition of the following available communication mechanisms:

• Communication without authentication and privacy (noAuthNoPriv).
• Communication with authentication and without privacy (authNoPriv).
• Communication with authentication and privacy (authpriv).
• Definition of different authentication and privacy protocols - Currently, MD5 and SHA authentication protocols and privacy protocols and CBC_DES CFB_AES_128 are supported in the USM.
• Definition of a discovery procedure - To find the snmpEngineID of a SNMP entity for a common transport address and end point direction of transport.
• Definition of the time synchronization procedure - To facilitate authenticated communication between SNMP entities.
• Definition of the MIB SNMP framework - To facilitate the remote configuration and administration of the SNMP entity.
• Definition of the USM MIB - To facilitate the remote configuration and administration of the security module.
• Definition of VACM MIBs - To facilitate remote configuration and administration of the access control module.

SNMPv3 focuses on two main aspects, namely security and management. The security aspect is addressed, offering both strong authentication and data encryption for privacy. The administration aspect focuses on two parties, namely the notification originators and proxy agents. SNMPv3 defines a number of security-related capabilities. Initial specifications defined USM and VACM, which were later followed by a transport security model that provided support over SSH and SNMPv3 over SNMPv3 over TLS and DTLS.

• USM (User-based Safety Model) provides authentication and privacy functions (encryption) and operates at the message level.
• VACM (View-based Access Control Model) determines whether a given director is allowed, access to a particular MIB object, to perform specific functions and operates at the PDU level.
• TSM (Transport Security Mode) provides a method for authentication and encryption of messages through external security channels. Two transports, SSH and TLS/DTLS, have defined that they make use of the TSM specification.

Security has been the biggest weakness of SNMP from the beginning. Authentication in SNMP versions 1 and 2 consists only of a password (community string) sent in clear text between a manager and agent. Each SNMPv3 message contains the security parameters that are encoded as an octet string. The meaning of these security parameters depends on the security model being used. SNMPv3 provides important security features:

• Confidentiality - Encryption of packages to prevent listening by an unauthorized source.
• Integrity - Integrity of messages to ensure that a package has not been altered during transit that includes an optional mechanism for repeating packages.
• Authentication - to check that the message is from a valid source.

As of 2004 the IETF recognizes the Simple Network Management Protocol version 3 as defined in RFC 3411 - RFC 3418 (also known as STD0062) as the current standard version of SNMP. The IETF has designated SNMPv3 a complete Internet standard, the highest level of maturity for an RFC. Consider earlier versions to be obsolete (by variously designating them "Historical" or "Obsolete"). In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3.

Implementation difficulties

Implementations of the SNMP protocol may vary between different manufacturers. In some cases, SNMP is incorporated as an additional feature of the system and is not seriously considered as a fundamental element of the system design. Some major vendors tend to overextend their proprietary CLI to configure and control their systems. In February 2002, the Computer Emergency Response Team Coordination Center (CERT-CC) of the Carnegie Mellon Software Engineering Institute (CM-SEI) held a consultative process on SNMPv1, CA-2002-03, later, the University of Oulu Secure Programming Group led an analysis on SNMP message handling. Most SNMP implementations, regardless of which version of the protocol, use the same programming code to decode data units (PDUs). As a result, many manufacturers have had to release patches for their SNMP implementations. Among other problems that were found in the decoding of SNMP trap messages received by the SNMP management station or the requests received by the SNMP agent on the network device.

The powerful SNMP write capabilities, which allow configuration of network devices, have not been widely used by many vendors, partly due to lack of security in SNMP versions prior to v3, and on the other hand because many devices are simply not capable of being configured through changes in the MIB objects. The SNMP Set operation requirements are not easy to implement correctly, and many vendors have chosen to omit support for Set - probably to cut costs and reduce the size of the code, among other reasons.^{[citation needed]}

The seemingly simple tree-like structure and linear indexing of SNMP may not be sufficiently understood by the data structures that are elements of the platform's basic design. Consequently, processing SNMP queries on certain data sets may result in higher CPU usage than necessary. An example of this would be large routing tables, such as BGP and IGP.^{[citation needed]}

Some SNMP values (especially tabular values) require specific knowledge of table indexing schemes, and these index values are not necessarily consistent across platforms. This can cause correlation issues when collecting information from multiple devices that may not use the same table indexing scheme (for example, when collecting metrics on disk utilization, when a specific disk identifier is different between platforms).

SNMP Security Implications

Use SNMP to attack a network

Because SNMP is designed to allow administrators to remotely configure and monitor network devices, it can also be used to penetrate a Local Area Network (LAN). If SNMP is not going to be used on a network, it should be disabled, because aside from creating a vulnerability, it will consume available bandwidth and CPU cycles unnecessarily. A significant number of software tools could scan the entire network via SNMP, so misconfiguring the read-write mode could make a network susceptible to attack.

In 2001, Cisco published information that even in read-only mode the Cisco IOS 11.0 and 12.0 implementation (the operating system used by network switches and routers) is vulnerable to certain denial-of-service attacks. These security issues can be fixed with an IOS update. When configuring read-only mode, attention should be paid to the access control settings and from which IP addresses SNMP messages are accepted. If SNMP servers are identified by their IP address, SNMP is only allowed to respond to these IPs and SNMP messages from other addresses should be denied. However, IP address spoofing remains a concern.

SNMP Authentication

SNMP is available in several versions, 1, 2 and 3; each has its security issues. SNMP v1 sends plain text passwords over the network. Therefore, the passwords can be read by packet sniffing. SNMP v2 allows password hashing with MD5, but this must be configured. Virtually all network management applications support SNMP v1, but not necessarily SNMP v2 or v3. SNMP v2 was specifically developed to provide information security, i.e. authentication, privacy and authorization, but only SNMP version 2c gained Internet Engineering Task Force (IETF) approval, while versions 2u and 2 * did not get IETF approval due to security concerns. SNMP v3 uses MD5, Secure Hash Algorithm (SHA) and key algorithms to ensure protection against unauthorized data modification and masquerade attacks. If a higher level of security is required, the Data Encryption Standard (DES) algorithm could optionally be used in block-of-number chaining mode. SNMP v3 has been implemented since the Cisco IOS Release 12.0(3)T release.

SNMPv3 is susceptible to brute force attacks and dictionary attacks to guess authentication keys, or encryption, if these keys are generated using short (or weak) passwords, or passwords that can be found in a dictionary. SNMPv3 allows randomly distributed encryption keys, as well as user-supplied password generation. The risk of guessing authentication strings from hashed values transmitted over the network depends on the hashing function used and the length of the hashed value.^{[citation needed]} SNMPv3 uses the HMAC-SHA-2 Authentication Protocol for User Security Model (USM). The challenge-response exchange was not used to improve security. SNMPv3 (as well as the other versions of SNMP) is a stateless protocol, and it has been designed to minimize the amount of interactions between the agent and the manager. So the introduction of a challenge-response exchange for each command would have imposed a burden on the agent (and probably on the network itself) that the designers of the protocol considered excessive and unacceptable.^{[citation needed]}

Security deficiencies in all versions of SNMP can be mitigated by IPsec authentication and confidentiality mechanisms. The SNMP implementation of Datagram Transport Layer Security (DTLS) is also available.

SNMP Auto Discovery

SNMP-based network management applications send passwords repeatedly during normal network operations. Therefore, plain text passwords are a significant security risk. If SNMP v2 is used, network administrators must enable password encryption on the devices on the network, which are the SNMP servers on which it runs. This can be done with the snmp-server enable traps snmp authentication md5 command.

Many SNMP implementations include a type of automatic discovery when a new network component, such as a switch or router, is automatically discovered and grouped. In SNMPv1 and v2c this is done through a community string that is relayed in plaintext to other devices. For this reason, the community strings that are configured by default are public for access. read-only and private for read-write access. SNMP was first on the SANS Institute's list of Most Common Default Configuration Problems and number ten on the 2000 list of Most Critical Internet Security Threats. Network and system administrators do not change these settings frequently. The community string sent by SNMP over the network is not encrypted. As soon as the security chain became known outside the organization, it could become a target for an attack. To prevent easy discovery of the community string, SNMP must be configured to pass the "traps" of community name authentication failures and the SNMP management device needs to be configured. to react to the "trap" of authentication failure.

SNMPv1 and v2 are vulnerable to IP address spoofing attacks, whether running over TCP or UDP, and device access list movers have been implemented to restrict SNMP access. SNMPv3 security mechanisms such as USM or TSM prevent successful attacks. It would be pointless to use SNMPv3 VACM (View Based Access Control) without securing messages with USM or TSM.^{[citation needed]}