Simple Network Management Protocol

src: i.ytimg.com

Simple Network Management Protocol ( SNMP ) is the Internet Standards protocol for collecting and managing information about devices managed on an IP network and for modifying the information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

SNMP is widely used in network management for network monitoring. SNMP exposes management data in the form of variables in managed systems organized in the management information base (MIB) that describes system status and configuration. These variables can then be asked remotely (and, in some circumstances, manipulated) by managing the application.

Three significant versions of SNMP have been developed and disseminated. SNMPv1 is the original version of the protocol. The latest versions, SNMPv2c and SNMPv3, feature improved performance, flexibility, and security.

SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It consists of a set of standards for network management, including application layer protocols, database schema, and a set of data objects.

Video Simple Network Management Protocol

Basic overview and concepts

In typical use of SNMP, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system runs a software component called agent that reports information via SNMP to the manager.

The SNMP-managed network consists of three main components:

• Managed devices
• Agents - software running on managed devices
• Network management station (NMS) Ã, - software running under manager

Managed devices are network nodes that implement SNMP interfaces that allow one-way (read-only) or two-way access (read and write) to node-specific information. The managed device exchanges node-specific information with NMS. Sometimes called network elements, managed devices can be any type of device, including, but not limited to, routers, access servers, switches, cable modems, bridges, hubs, IP phones, IP video cameras, host computers, and printers.

Agent is a network management software module residing on a managed device. An agent has local knowledge of management information and translates that information to or from a specific form of SNMP.

A network management station runs an application that monitors and controls the managed device. NMS provides most of the processing and memory resources needed for network management. One or more NMSs may exist in a managed network.

Maps Simple Network Management Protocol

Management information base

The SNMP agent exposes management data on managed systems as variables. The protocol also enables active management tasks, such as configuration changes, through remote modifications of these variables. Variables that can be accessed via SNMP are arranged in the hierarchy. SNMP itself does not specify which variables should be offered by managed systems. Instead, SNMP uses an expandable design that allows applications to define their own hierarchy. This hierarchy, described as a management information base (MIB). MIB describes the data management structure of the device subsystem; they use a hierarchical namespace that contains an object identifier (OID). Each OID identifies a variable that can be read or set via SNMP. MIB uses a notation defined by the Management Information Structure of Version 2.0 (SMIv2, RFCÃ, 2578), part of ASN.1.

src: images.slideplayer.com

Protocol details

SNMP operates in the application layer of the Internet protocol. All SNMP messages are transported via User Datagram Protocol (UDP). The SNMP agent receives a request on the UDP port 161. The manager can send requests from any available source port to port 161 in the agent. The agent response is sent back to the source port of the manager. The manager receives notifications ( Traps and InformRequests ) on port 162. Agents can generate notifications from the available ports. When used with Transport Layer Security or Transport Layer Security Datagram, requests are received on port 10161 and notifications are sent to port 10162.

SNMPv1 assigns five units of core protocol data (PDU). The other two PDUs, GetBulkRequest and InformRequest are added in SNMPv2 and Report The PDU is added in SNMPv3. All SNMP PDUs are built as follows:

The seven types of SNMP PDUs identified by the PDU-type field are as follows:

GetRequest

Request manager-to-agent to extract variable values ​​or variable lists. The desired variable is specified in the variable bindings (the value field is not used). The specified variable value retrieval must be performed as an atomic operation by an agent. A Response with the current value returned.

SetRequest

Request manager-to-agent to change variable value or variable list. Binding variables are specified in the body of the request. Changes for all specified variables must be created as atom operations by agents. A Response with (currently) a new value for the variable is returned.

GetNextRequest

Manager-to-agent request to find available variables and values. Returns Response with variable binding for the next lexicographic variable in MIB. All MIB agents can run with iterative application GetNextRequest starting at OID 0. The table row can be read by specifying the OID column in the bindings variable of the request.

GetBulkRequest

Manager-to-agent request for multiple iterations GetNextRequest . Optimized version of GetNextRequest . Returns Response with multiple batches of running variables from bindings to variables or bindings in the request. The special field of non-repeater PDU and max-repetitions is used to control response behavior. GetBulkRequest was introduced in SNMPv2.

Response

Returns variable bindings and acknowledgments from agent to manager for GetRequest , SetRequest , GetNextRequest , GetBulkRequest and < i> Inform Request . Error reporting is provided by the error-status and error-index fields. Although it's used as a response to get and manage, this PDU is called GetResponse in SNMPv1.

Trap

Asynchronous notification from agent to manager. While in other SNMP communications, managers actively request information from agents, these are PDUs sent from agent to manager without being asked explicitly. The SNMP trap allows the agent to notify important event management stations via unsolicited SNMP messages. The PDU trap includes the current sysUpTime value, an OID that identifies the type of trap and optional option breaking. The purpose addressing for traps is determined in a special way of application, usually via trap configuration variables in MIB. The trap message format is changed in SNMPv2 and the PDU is renamed SNMPv2-Trap .

InformRequest

Acknowledge asynchronous notifications. This PDU was introduced in SNMPv2 and was originally defined as the manager to manager communication. The subsequent implementation has relaxed the original definition to allow the agent to manager communication. Manager-to-manager notification is possible in SNMPv1 using Traps , but since SNMP usually runs over UDP where delivery is not guaranteed and packets dropped are not reported, my Trap InformRequest fixes this as the acknowledgment is returned when received.

RFC 1157 specifies that the SNMP implementation should receive messages of at least 484 bytes in length. In practice, the SNMP implementation receives a longer message. If implemented correctly, the SNMP message is discarded if the message decoding fails and thus the SNMP request error is ignored. The translated SNMP request is then authenticated using community strings. If the authentication fails, the generated trap indicates an authentication failure and the message is dropped.

SNMPv1 and SNMPv2 use communities to build trust between managers and agents. Most agents support three community names, each for read-only, read-write and trap. These three community strings control various types of activities. Read-only communities apply for get requests. The read-write community string applies to the set request. Community string traps apply to receive traps . SNMPv3 also uses community strings, but allows for secure authentication and communication between the manager and the SNMP agent.

src: i.ytimg.com

Development and use

In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3.

Version 1

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

The First Request for Comments (RFC) for SNMP, now known as SNMPv1, appeared in 1988:

• RFCÃ, 1065Ã, - Structure and identification of management information for Internet TCP/IP
• RFCÃ, 1066Ã, - Basic management information for network management from TCP/IP-based internet
• RFCÃ, 1067Ã, - Simple network management protocol

This Protocol has been deprecated by:

• RFCÃ, 1155 - Structure and identification of management information for Internet TCP/IP
• RFCÃ, 1156 - Basic management information for network management from TCP/IP-based internet
• RFCÃ, 1157Ã, - Simple network management protocol

After a short time, RFCÃ, 1156 (MIB-1) was replaced by the more frequently used:

• RFC 1213 - Version 2 of the management information base (MIB-2) for network management from Internet-based TCP/IP

Version 1 has been criticized for its poor security. Client authentication is only done by "community strings", basically a type of password, which is transmitted in cleartext. The SNMPv1 80s design was performed by a group of collaborators who looked at officially-sponsored OSI/IETF/NSF (National Science Foundation) efforts (HEMS/CMIS/CMIP) because they could not be implemented on computing platforms at the time and also potentially unworkable. SNMP is approved based on the belief that it is the interim protocol necessary to take steps towards large-scale Internet deployment and commercialization. In that time period, Internet standard authentication/security was a dream and desperation by a focused protocol design group.

Version 2

SNMPv2 (RFC 14 1441-RFCÃ, 1452), revises version 1 and includes improvements in the areas of performance, security, confidentiality, and inter-manager communication. It introduces GetBulkRequest , an alternative to repetitive GetNextRequests to retrieve large amounts of management data in a single request. However, the new party-based security system in SNMPv2, considered by many to be too complex, is not widely accepted. This SNMP version reaches the proposed Standard Maturity level, but is considered obsolete by the newer version.

the Community-Based Simple Network Management Protocol version 2 , or SNMPv2c , defined in RFCÃ, 1901-RFCÃ, 1908. SNMPv2c is composed of a new SNMPv2 without controversial Security model SNMP v2, using a simple community-based security scheme from SNMPv1. This version is one of several relative standards to meet the standard level of the IETF Draft Standards, and is widely regarded as the de facto standard SNMPv2. It was also later obsolete, by SNMPv3.

Simple Network Management Protocol version 2 User-Based or SNMPv2u , defined in RFCÃ, 1909-RFCÃ, 1910. It is a compromise that attempts to offer greater security than SNMPv1, but without incurring the high complexity SNMPv2. This variant is used commercially as SNMP v2 * , and the mechanism was eventually adopted as one of two security frameworks in SNMP v3.

SNMPv1 & amp; SNMPv2c interoperability

As currently specified, SNMPv2c is incompatible with SNMPv1 in two main areas: message format and protocol operation. SNMPv2c messages use various server formats and header characters (PDU) of SNMPv1 messages. SNMPv2c also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 3584 (which obscures RFC 2576) defines two possible coexistence strategies SNMPv1/v2c: proxy agents and bilingual network management systems.

Proxy agent

Agent SNMPv2 may act as a proxy agent on behalf of devices administered SNMPv1, as follows:

• NMS SNMPv2 issues commands intended for SNMPv1 agents.
• The NMS sends an SNMP message to the SNMPv2 proxy agent.
• The proxy agent forwards the message Get , GetNext , and Set to the SNMPv1 agent without any changes.
• The GetBulk message is converted by a proxy agent to the GetNext message and then passed to the SNMPv1 agent.

The proxy agent maps the SNMPv1 trap message to the SNMPv2 trap message and then passes it to NMS.

Two-language network management system

The bilingual SNMPv2 network management system supports SNMPv1 and SNMPv2. To support this dual management environment, management applications in bilingual NMS should contact the agent. NMS then checks the information stored in the local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, NMS communicates with the agent using the appropriate SNMP version.

Version 3

Although SNMPv3 makes no changes to protocols other than the addition of cryptographic security, it seems very different because of new textual conventions, concepts, and terminology.

SNMPv3 mainly adds security and remote configuration enhancements to SNMP. Due to lack of security with the use of SNMP, network administrators use other means, such as telnet and SSH for configuration, accounting, and fault management.

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

SNMPv3 defines SNMP versions safely and also facilitates remote configuration of SNMP entities.

SNMPv3 provides a secure environment for system management that includes the following:

• Identify 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 its partner identity. Traps and Notifications are exceptions to this rule.
• Support for security model - The security model can specify security policies within the administrative or intranet domains. SNMPv3 contains specifications for USM (User Based Security Model).
• The definition of a security goal in which the purpose of the message authentication service includes protection of the following:
  • Information Modification - Protection against some unauthorized SNMP entities that alter transit messages generated by authorized principles.
  • Masquerade - Safeguards against management operations operations that are not allowed for some principles by assuming the identity of other authorized authorized principals.
  • Message Flow Modification - Protection against messages that are maliciously damaged, delayed, or played back for unauthorized management operations.
  • Disclosure - Protection against intercepts on interchange between SNMP machines.
• The specification for USM - USM (User Based Security Model) consists of the following common definitions of the following communication mechanisms:
  • Communications without authentication and privacy (NoAuthNoPriv).
  • Communication with authentication and without privacy (AuthNoPriv).
  • Communication with authentication and privacy (AuthPriv).
• Different authentication definitions and privacy protocols - Currently, the MD5 and SHA authentication protocols and the privacy protocols CBC_DES and CFB_AES_128 are supported in USM. The current IETF Operations and Management Working Group (OPSAWG) (March 2015) developed the HMAC-SHA-2 authentication protocol for USM.
• Definition of discovery procedure - To find SNMPEngineID of SNMP entity for transport address and address of given transport end point.
• Definition of time synchronization procedure - To facilitate authenticated communication between SNMP entities.
• Definition of the SNMP MIB framework - To facilitate configuration and remote administration of SNMP entities.
• USM MIB Definition - To facilitate remote configuration and administration of security modules.
• Definition of MIB VACM - To facilitate remote configuration and administration of access control module.

SNMPv3 focuses on two main aspects, namely security and administration. The security aspect is handled by offering strong authentication and data encryption for privacy. Aspects of administration focused on two parts, namely the originator of notification and proxy forwarder.

SNMPv3 defines a number of security-related capabilities. The initial specification defines USM and VACM, which is then followed by a transport security model that provides support for SNMPv3 via SSH and SNMPv3 via TLS and DTLS.

• USM (User-Based Security Model) provides authentication and privacy (encryption) functions and operates at the message level.
• VACM (View-Based Access Control Model) determines whether a principal is granted access to a specific MIB object to perform a particular function and operates at the PDU level.
• The TSM (Transport Security Model) provides a method for authenticating and encrypting messages via an external security channel. Two transport, SSH and TLS/DTLS, have been specified using TSM specification.

Security has been SNMP's biggest weakness since its inception. Authentication in SNMP Versions 1 and 2 is nothing more than a password (community string) sent in clear text between managers and agents.

Each SNMPv3 message contains a security parameter encoded as an octet string. The meaning of these security parameters depends on the security model used.

SNMPv3 provides important security features:

• Confidentiality - Package encryption to prevent surveillance by unauthorized sources.
• Integrity - Message integrity to ensure that packets have not been tampered with in transit including optional packet replay protection mechanisms.
• Authentication - to verify that the message is coming from a valid source.

In 2004 the IETF recognized the Simple Network Management Protocol version 3 as defined by RFC 3411-RFC 3418 (also known as STD0062) as the current standard version of SNMP. IETF has established SNMPv3 the complete Internet standard, the highest maturity level for RFC. It considers the previous version to be obsolete (designating them with various "Historical" or "Obsolete").

src: slideplayer.com

Implementation problem

SNMP implementation varies across platform vendors. In some cases, SNMP is an additional feature, and is not considered serious enough to be a core design element. Some major equipment vendors tend to overestimate their proprietary command line interface configuration (CLI) and control systems. In February 2002 the Carnegie Mellon Software Engineering Institute (CM-SEI) The Computer Emergency Response Coordination Center (CERT-CC) issued an Adviser on SNMPv1, CA-2002-03, after the Oulu University Security Programming Group conducted a thorough analysis of SNMP message handling. Most SNMP implementations, regardless of which version of the protocol, use the same program code to decode the protocol data unit (PDU). So many vendors have to issue patches for their SNMP implementations. Among other problems are found with SNMP trap messages received by SNMP management stations or requests received by SNMP agents on network devices.

The powerful SNMP writing capability, which will allow network device configuration, is not fully exploited by many vendors, partly due to the lack of security in the SNMP version prior to SNMPv3, and in part because many devices can not be configured through individual MIB object Changes. Operating requirements The SNMP settings are not easy to implement properly, and many vendors choose to ignore support for Set - perhaps to lower development costs and reduce code size, among other reasons.

The SNMP tree structure that looks simple and linear indexing may not always be well understood in the internal data structure that is the element of the platform's basic design. As a result, processing SNMP requests on certain data sets may result in higher CPU utilization than necessary. One example is a large routing table, such as BGP or IGP.

Some SNMP values ​​(especially tabular values) require special knowledge of the indexing scheme of tables, and the value of these indices is not always consistent across platforms. This can cause correlation issues when retrieving information from multiple devices that may not use the same table indexing scheme (eg taking disk usage metrics, where certain disk identifiers differ across platforms.)

src: i.ytimg.com

Resource indexing

Modular devices can dynamically increase or decrease their SNMP indexes (examples a) whenever the added enhancements are added or removed. Although this is the most common with hardware, the virtual interface has the same effect. Index values ​​are usually set at boot time and fixed until the next reboot. The hardware or virtual entity is added when the 'live' device may have an index defined at the end of the existing range and possibly reset on the next reboot. Network inventory and monitoring tools must have the device update capability by reacting correctly to the cold start trap of the reboot device to avoid corruption and mismatch of the data being surveyed.

The index assignment for SNMP device instances may change from poll to polling largely as a result of changes initiated by the system administrator. If information is required for a particular interface, it is important to specify the SNMP index before retrieving the required data. Generally, a description table such as ifDescr will map an easy-to-use name such as Serial 0/1 (Blade 0, port 1) to the SNMP index. However, this does not always apply to certain SNMP values, and can be arbitrary for SNMP implementations.

src: 4.bp.blogspot.com

Security implications of SNMP

Using SNMP to attack the network

Because SNMP is designed to allow administrators to monitor and configure network devices remotely, it can also be used to penetrate local area networks (LANs). If SNMP is not used in the network, it must be turned off, because in addition to creating the vulnerability, it will consume available network bandwidth and do not need to use CPU cycles. A large number of software tools can scan the entire network through SNMP, therefore errors in the read-write mode configuration can make the network vulnerable to attack.

In 2001 Cisco released information that even in SNMP implementation read mode from Cisco IOS 11.0 and 12.0 (operating systems used by Switches and Routers) are vulnerable to denial of service attacks. This security issue can be fixed through IOS upgrade. When configuring SNMP read-only mode, attention should be given to the access control configuration and from which the IP address of the SNMP message is received. If the SNMP server is identified by their IP, SNMP is only allowed to respond to this IP and SNMP messages from other IP addresses will be rejected. However, the IP spoofing address remains a security concern.

SNMP authentication

SNMP is available in various versions 1, 2 and 3, each with its own security issues. SNMP v1 sends the password clearly over the network. Therefore, the password can be read with the sniffing package. SNMP v2 allows password encryption with MD5, but this must be configured. Almost all network management software supports SNMP v1, but not necessarily SNMP v2 or v3. SNMP v2 is specifically developed to provide data security, authentication, privacy and authorization, but only SNMP version 2c gets support from the Internet Engineering Task Force (IETF), while versions 2u and 2 * fail to obtain IETF approval due to security issues. SNMP v3 uses MD5, Secure Hash Algorithm (SHA) and locked algorithms to offer protection against unauthorized data modification and masquerade attacks. If a higher level of security is required, the Data Encryption Standard (DES) can be optionally used in cipher block coupling mode. SNMP v3 is implemented on Cisco IOS since the release of 12.0 (3) T.

SNMPv3 can be the target of a brute force and dictionary attack to guess the authentication key, or encryption key, if this key is generated from a short (weak) password, or a password that can be found in the dictionary. SNMPv3 allows both to provide uniform random distributed cryptographic keys, and generates cryptographic keys from user-provided passwords. The risk of guessing the authentication string of the hash values ​​sent over the network depends on the Hash function used and the length of the hash value. SNMPv3 uses the HMAC-SHA-2 Authentication Protocol for User-Based Security Models (USM). A response-response handshake is not used to improve security. SNMPv3 (like other SNMP protocol versions) is a no-state protocol, and has been designed with a minimal amount of interaction between agents and managers. Thus introducing a challenge-response handshake for each command will burden the agent (and possibly on the network itself) prescribed by excessive and unacceptable protocol designers.

Security shortcomings of all versions of SNMP can be reduced by IPsec authentication and confidentiality mechanisms. Implementation of SNMP through Transport Layer Security Datagram (DTLS) is also available.

SNMP autodiscovery

The SNMP-based network management software sends passwords repeatedly during normal operation across the network. Therefore, clear text passwords are a significant security risk. If SNMP v2 is used, the network administrator must enable password encryption on the network device, which is the SNMP server running it. This can be done with the snmp-server command allowing traps snmp authentication md5 .

Many SNMP implementations include a type of automated discovery in which new network components, such as switches or routers, are discovered and collected automatically. In SNMPv1 and v2c this is done via community string that is broadcast in clear-text to other devices. Because of their default configuration on community strings, they are public for read-only and private access to read-write SNMPs to the SANS Institute's General Default Failure Issues list and the tenth on 10 Most Secure Internet SANS Biggest Internet Threats for 2000. System administrators and networks often do not change this configuration. The community string sent by SNMP over the network is not encrypted. Once a community string is known outside the organization, it can be the target of attack. To prevent easy community discovery, SNMP must be configured to forward the trap of community-name authentication failures and SNMP management tools need to be configured to react to failure of authentication failures.

Source of the article : Wikipedia