Simple Network Management Protocol

The Simple Network Management Protocol ( English for " Simple Network Management Protocol" ), short- SNMP is a network protocol that was developed by the IETF to network elements ( eg routers, servers, switches, printers, computers, etc.) from a central be able to monitor and control station. The protocol controls the communication between the monitored devices and the monitoring station. SNMP describes the structure of the data packets can be sent, and the communication procedure. It was designed so that any network-compatible device can be included in the monitoring. One of the tasks of network management, which are possible with SNMP include:

  • Monitoring of network components,
  • Remote control and remote configuration of network components,
  • Error detection and notification.

Due to its simplicity, modularity and versatility, SNMP has become the standard which is supported both by most management programs as well as from clients. So SNMP is not dependent on the IP network protocol, for example as a transport. There are implementations that over IPX ( Novell NetWare) or AppleTalk (Apple, MacOS ) can be addressed.

  • 4.1 SNMP packet header
  • 4.2 PDU header (non- trap packets )
  • 4.3 PDU header ( trap packets )
  • 4.4 PDU Body

Operation

In order to monitor so-called agents are used. These are programs that run directly on the monitored devices, or hardware that performs the same tasks. These programs / devices are able to detect the state of the network device and install the same settings or even trigger actions. Using SNMP, it is possible that the central management station can communicate with the agent via a network., There are six different data packets may be sent:

GET three packets (GET, GETNEXT, GETBULK ) can be sent from the manager to an agent to request information about the current station. This responds with a response packet, which includes either the requested data or an error message.

The SET Package may be a manager change values ​​at the agent. This makes it possible to make adjustments or initiate actions. The agent confirmed the transfer of values ​​also with a RESPONSE packet.

If the agent detects an error in the monitoring of the system, it may report unsolicited report using a TRAP packet to the management station. These packets are not acknowledged by the manager. The agent can not determine whether the transmitted TRAP packet has arrived at the manager therefore.

Thus, the network traffic is low, the connectionless UDP is used to send the messages. The agent receiving the queries (requests) to the port 161, while required for receiving the trap messages to the port manager 162.

Management Information Base

SNMP itself does not define which values ​​can supply a network component, or has, as the function of the nature of the component.

The values ​​that can be read and modified by a manager of a managed network component that can be called Managed Objects " thus described in a Management Information Base ( MIB short ). Here is description files where the individual values ​​are tabulated. The MIB is specific for a specific component (or a class of components, such as switches).

The information in the MIB are organized in a tree structure whose individual branches can be represented by either numbers or, alternatively, by alphanumeric designations. The MIB -2 is to be found, for example iso.org.dod.internet.mgmt.mib -2, which is uniquely determined just by the series of numbers 1.3.6.1.2.1 (1 for iso, 3 for org, etc.). This consists of points and figures string called an Object Identifier (OID ). The MIBs are stored in individual RFCs. Within these RFCs, the object identifier with its five ObjectType definition are clearly defined. Posted these RFCs are in the ASN.1 description language. At all data that can be retrieved or changed by the agent in these files, a number of information is provided:

  • Name
  • Data type
  • Access rights ( read-only, read-write, not- accessible )
  • Status (mandatory, optional, deprecated, obsolete)
  • Description Text

With the help of the description files management programs are able to represent any desired SNMP agent the hierarchical structure of the data and to request data from them.

Several such MIBs defined in RFCs, a number of technical and organizational documents to the Internet. Particularly worth mentioning is the already mentioned MIB -2, which was defined in RFC 1213 and is supported by all network components. Besides the standard MIB there is a whole series of further defined in RFC MIBs for different technologies ( eg ISDN MIB), protocols (eg OSPF - MIB) or components (eg UPS- MIB). They contain general objects such as port status, router ID, state of charge of the battery and the like.

In addition to the MIBs defined in RFCs any manufacturer of software or hardware can own MIBs, so-called private MIBs define that reflect the special characteristics of his product. These are under the OID iso (1 ). Org (3). Dod (6). Internet (1). Individual (4). Enterprises ( 1) with the IANA, one for the assignment of IP addresses, Top Level Domains and IP protocol numbers competent organization, registered. Meanwhile, several thousand companies registered under this OID (see private enterprise numbers ). If an OID once an object is assigned, the importance of this OID may - if supported by the device ( the SNMP agent ) - do not change again. There must be no overlap.

The " The MIB tree " shown in the image root nodes " ccitt " and "joint " are not used for SNMP. CCITT is for example a sub-tree, which is maintained by the International Telegraph and Telephone Consultative Committee, which also maintains JOINT subtree together with the International Organization for Standardization ( ISO).

What's really interesting for SNMP only the subtree. Iso.org.dod.internet ( .1.3.6.1 ), which can be shortened to just "internet". A snmpget for " internet.xy " ie the same value would provide such an snmpget for ". Iso.org.dod.internet.xy " or " .1.3.6.1. Xy".

Versions

Version 1

The first version of SNMP was defined in 1988 in the following RFCs:

  • RFC 1155 - Structure and Identification of Management Information for TCP / IP -based internets ( Replaced RFC 1065 )
  • RFC 1156 - Management Information Base for Network Management of TCP / IP -based internets ( Replaced RFC 1066)
  • RFC 1157 - A Simple Network Management Protocol ( Replaced the RFC 1067 and RFC 1098 )

The main problem with the first version is the poor security. One of the problems is the unsecured use of the password. The password is transmitted in clear text, can therefore easily be intercepted and thus used by unauthorized parties.

Secure SNMP

The increased need for security meant that in 1992 three RFCs were published on SNMPsec (Secure SNMP).

  • RFC 1351 - SNMP Administrative Model
  • RFC 1352 - SNMP Security Protocols
  • RFC 1353 - Definitions of Managed Objects for Administration of SNMP Parties

This version was never introduced, but replaced by SNMPv2.

Party -based SNMP version 2 ( SNMPv2p )

1993 SNMPv2p was published by the IETF. It improved SNMPv1 in terms of security and confidentiality and implemented a communication between different managers. The new GetBulk command to query tables was much easier.

  • RFC 1441 - Introduction to version 2 of the Internet - standard Network Management Framework
  • RFC 1445 - Administrative Model for version 2 of the Simple Network Management Protocol ( SNMPv2 )
  • RFC 1446 - Security Protocols for version 2 of the Simple Network Management Protocol ( SNMPv2 )
  • RFC 1447 - Party MIB for version 2 of the Simple Network Management Protocol ( SNMPv2 )

This version is no longer used today.

User -Based SNMP version 2 ( SNMPv2u )

In SNMPv2u trying to increase by username safety.

  • RFC 1909 - An Administrative Infrastructure for SNMPv2
  • RFC 1910 - User - based Security Model for SNMPv2

This version is no longer used today.

Community-based SNMP version 2 ( SNMPv2c )

SNMPv2c is for security at the level of SNMPv1. It is only enhanced by a few additional features that already existed in SNMPv2p:

  • Tables do not have to go through with the GetNext command, but can be brought to the GetBulk command at a time.
  • Communication between different managers.

This version has prevailed and gained wide acceptance. If today is spoken by SNMPv2, is mostly meant this version.

  • RFC 1901 - Introduction to Community-based SNMPv2
  • RFC 1905 - Protocol Operations for Version 2 of the Simple Network Management Protocol ( SNMPv2 ) ( Replaced RFC 1448 )
  • RFC 1906 - Transport Mappings for Version 2 of the Simple Network Management Protocol ( SNMPv2 ) ( Replaced RFC 1449 )

Version 3

SNMP versions 1 and 2c offer almost no security mechanisms. Therefore, the jocular interpretation of the abbreviation SNMP as " Security is not my problem" comes from ( security is not my problem ). In the current version 3 security mechanisms have been significantly expanded. The associated rise in complexity (eg key management ) but has led to SNMPv3 is not yet as widespread as SNMPv2.

SNMP in the latest version 3 is defined by a series of new RFCs ( the specification in December 2002):

  • RFC 3410 - Introduction and Applicability Statements for Internet - Standard Management Framework
  • RFC 3411 - An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
  • RFC 3412 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
  • RFC 3413 - Simple Network Management Protocol (SNMP) Applications
  • RFC 3414 - User - based Security Model ( USM) for version 3 of the Simple Network Management Protocol ( SNMPv3)
  • RFC 3415 - View- based Access Control Model ( VACM ) for the Simple Network Management Protocol (SNMP)
  • RFC 3416 - Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
  • RFC 3417 - Transport Mappings for the Simple Network Management Protocol (SNMP)
  • RFC 3418 - Management Information Base ( MIB) for the Simple Network Management Protocol (SNMP)

Packet structure (SNMPv1 )

The description of the SNMP packets is done by ASN.1, the encoding for the transport over the network using the Basic Encoding Rules (BER ). Most SNMP packets are identical. Some other information is sent in the PDU header only for trap messages.

SNMP packet header

The header contains the total size of the package, the version number (SNMPv1, SNMPv2 or SNMPv3), and the community name is transferred. By assigning communities access rights should be awarded. In most cases, but as a community name "public " is selected for read access and "private" for read and write access. Security can also be known by other names not be reached because the community name is transmitted in plain text and can be listened to by everyone in the net.

PDU header (non- trap packets )

In the first part of the PDU header, the type of SNMP packet, and the size of the PDU is transmitted. The structure of the second portion depends on the type of SNMP packet.

This response packets the previous queries can be assigned, there is the request ID, which are identical for request and response. This makes it possible to send multiple requests and responses correctly re.

The error status and index is used to communicate with response packets why a request could not be processed. As long as no error occurs, the two fields are assigned a value of zero. Error occurs, the error index indicates the error occurred after how many record. The error status of the reason for the error is specified. The error status can have in SNMPv1 one of six possible values ​​:

  • No error
  • Packet is too large to send
  • The OID is not supported
  • Incorrect data type or value (only possible response to set- packets)
  • Read-only access (only in response to Set packets)
  • Unknown generation error

PDU header ( trap packets )

The first two fields in the PDU header are identical to those of other packets in the SNMP traps. The packet type field indicates that it is a trap. Also here the size of the PDU is given. In the second part other values ​​are transmitted, which are only required for traps.

To recognize, from whom comes the message, the IP address of the sender and its OID is also transmitted. The OID specifies what it is for a device. This is important to know if it is a company-specific trap that is only valid for this device type.

Then follows the general TrapID. There are seven possible general TrapIDs:

  • Cold start
  • Warm start
  • Link Down
  • Link Up
  • Authentication error
  • Lost EGP neighbor
  • Company-specific

Is specified in this field indicates that this is a company- specific trap whose ID is transmitted in the following box.

Since it is possible that trap packets do not arrive in the order they were sent, there is additionally a time value that specifies exactly to hundredths of seconds, how long the SNMP agent is running until the trap event occurred. This makes it possible to bring the trap events in the correct time order.

PDU Body

In PDU body the actual values ​​are transferred. Each value is transferred to a so-called variable binding:

To a variable binding include the OID and the value itself.

There is no default, how many variable bindings in the PDU Body may also be sent. So it is possible to query multiple values ​​with a get command. But if the response packet it is too large, it may happen that the corresponding error message is returned in the response packet.

Traps, it is also possible that no variable bindings are sent along. In which case, the TrapID is regarded as sufficient information.

In the SNMP packet no indication is provided indicating the number of variable bindings mitgeschickten. This can only find out about the size specification of the PDU bodysuits and the size specification of each variable bindings.

Security Issues

A weak aspect of SNMP version 1 to 2c is security. These versions of SNMP support any application with password and user name, there are so-called communities use. These have the disadvantage that each user can with a matching program to read system information in the network and even change values.

SNMP version 3 provides, among other encryption and better authentication; which is often not used at the time because of the higher complexity.

Communities are simple names, such as "PUBLIC" (must read only) or "PRIVATE " ( may also write ) that are transmitted by the SNMP service with the Inquiry. One can of course use a very long and complicated community names, but the downside is that SNMP packets are not encrypted and therefore very simply " sniffed " by an attacker ( heard) can be.

Allowed Host: There is, however, possible to limit the IP addresses of the systems that are able to contact a monitored SNMP system. This is a relatively simple protection, but possibly can be cut short with ARP spoofing and IP spoofing.

Management protection: Recently it has become more common that you created for monitoring the systems own network to separate the user data traffic from management traffic. This is called out-of- band. Since this second network increases the cost of monitoring, the work is meaningful only in certain areas, such as in the banking sector.

ReadOnly: You also have the option of assigning certain systems a "Read Only". Thus, only read each monitoring device. Which is commonly used in routers.

Host (network) Network packet Internetwork Packet Exchange Wireshark Abstract Syntax Notation One ARP-Spoofing IP address spoofing
732287
de