Simple Network Management Protocol
| SNMP (Simple Network Management Protocol) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Family: | Internet protocol family | ||||||||||||||||||||||||
| Operation area: | Network management | ||||||||||||||||||||||||
| Latest version: | SNMPv3 | ||||||||||||||||||||||||
| Ports: | 161 / UDP 162 / UDP (trap) |
||||||||||||||||||||||||
|
|||||||||||||||||||||||||
| Standards: |
RFC 1157 (SNMP, 1990) RFC 3410 ff (SNMPv3, 2002) (see text) |
||||||||||||||||||||||||
The Simple Network Management Protocol ( SNMP ; German Simple Network Management Protocol ) is a network protocol that the IETF , is designed to network elements (eg. Routers , servers , switches , printers, computers, etc.) from a central station monitor and control to be able to. The protocol regulates the communication between the monitored devices and the monitoring station. SNMP describes the structure of the data packets that can be sent and the communication process. It was designed so that every network-compatible device can be included in the monitoring. The network management tasks that are possible with SNMP include:
- Monitoring of network components,
- Remote control and remote configuration of network components,
- Error detection and error notification.
Due to its simplicity, modularity and versatility, SNMP has developed into a standard that is supported by most management programs as well as by end devices.
functionality
So-called agents are used for monitoring . These are programs that run directly on the monitored devices or hardware that performs the same tasks. These programs / devices are able to record the status of the network device and also to make settings themselves or to trigger actions. With the help of SNMP it is possible that the central management station can communicate with the agents via a network. There are seven different data packages that can be sent:
- GET REQUEST
- to request a management data set.
- GETNEXT REQUEST
- to get the record below (to iterate over tables).
- GETBULK (from SNMPv2)
- to retrieve a specified number of data records at once is similar to multiple GETNEXT-REQUEST.
- SET REQUEST
- to change one or more data records of a network element. Sometimes a network element requires several data records to be changed at the same time in order to check consistency. For example, the configuration of an IP address requires the network mask to be specified at the same time.
- GET RESPONSE
- Reply to one of the previous packages.
- TRAP
- unsolicited message from an agent to the manager that an event has occurred. Programs such as Wireshark , which are used to decode protocols such as SNMP, also call this data packet REPORT . A TRAP can also be sent if the data record change (s) described in a SET-REQUEST packet could not be carried out, and not only to indicate a malfunction (e.g. a defect in a module of a network element ) Report to.
- INFORM REQUEST
- structured like a trap, only that this is acknowledged by the recipient.
The three GET packages ( GET , GETNEXT , GETBULK ) can be sent by the manager to an agent in order to request data about the respective station. This replies with a RESPONSE packet that either contains the requested data or an error message.
With the SET-REQUEST package a manager can change values at the agent. This makes it possible to make settings or to trigger actions. The agent also confirms the acceptance of the values with a GET-RESPONSE packet.
If the agent detects an error while monitoring the system, it can report this to the management station without being requested to do so using a TRAP packet. These packages are not confirmed by the manager. The agent can therefore not determine whether the sent TRAP packet has arrived at the manager.
To keep the network load low, the connectionless UDP protocol is used to send messages . The agent and the manager communicate (requests / responses) on port 161, while port 162 is required to receive the TRAP messages.
Management Information Base
The framework of the SNMP-based management includes not only the protocol, but also the representation of the database that is available in the network device and that is referred to as the “Management Information Base” or “MIB” for short.
Versions
Version 1
The first version of SNMP was defined in the following RFCs in 1988 :
- RFC 1155 - Structure and Identification of Management Information for TCP / IP-based internets (replaces RFC 1065 )
- RFC 1156 - Management Information Base for Network Management of TCP / IP-based internets (replaces RFC 1066 )
- RFC 1157 - A Simple Network Management Protocol (replaces RFC 1067 and RFC 1098 )
The main problem with the first version is insufficient security during transmission. One of the problems is the unencrypted transmission of the password, which means that it can easily be intercepted and used by unauthorized parties.
Secure SNMP
The increased need for security led to the fact that in 1992 three RFCs about SNMPsec (Secure SNMP) were published.
- 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)
In 1993, SNMPv2p was published by the IETF . It improved SNMPv1 in terms of security and confidentiality by encrypting the community string and introducing communication between different managers. The new GetBulk command has made querying tables 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)
With SNMPv2u one tries to increase the security with user names.
- 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)
In terms of security, SNMPv2c is up to date with SNMPv1. It is only expanded by a few additional functions that were already available with SNMPv2p:
- Tables no longer have to be scrolled through with the GetNext command, but can be fetched at once with the GetBulk command.
- Communication between different managers.
This version has prevailed and received wide acceptance. Nowadays, when people talk about SNMPv2, they usually mean this version.
- RFC 1901 - Introduction to Community-based SNMPv2
- RFC 1905 - Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) (replaces RFC 1448 )
- RFC 1906 - Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) (replaces RFC 1449 )
Version 3
SNMP versions 1 and 2c offer almost no security mechanisms. This is where the joking interpretation of the abbreviation SNMP as "Security is not my problem" comes from. In the current version 3, the security mechanisms have been significantly expanded. The associated increase in complexity (e.g. key management ) has meant that SNMPv3 is not yet as widespread as SNMPv2.
SNMP in the latest version 3 is defined by a number of new RFCs (the specification was made 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)
Package structure (SNMPv1)
The description of the SNMP packets is done by ASN.1 , the coding for the transport over the network using Basic Encoding Rules (BER). Most of the SNMP packets are structured identically. Only in the case of trap messages is some other information sent in the PDU header.
| SNMP packet header | PDU header | PDU body | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Version number | Community name | Package type (Get, GetNext ...) | RequestID | Error status | Error index | Variable binding 1 | Variable binding 2 | ... | Variable binding n |
The packet structure of an SNMPv1 packet does not contain any size information, since each field is brought into the type-length-value format with the help of ASN.1 .
SNMP packet header
The version number (SNMPv1, SNMPv2 or SNMPv3) and the community name are transmitted in the header. By assigning communities, access rights are granted. In most cases, the community name "public" is used by default for read-only access and "private" for read-write access (read-write). Since these two community names are known as the default setting, they should be changed. However, this does not inevitably increase security as the community names are transmitted over the network as clear text.
PDU header (non-trap packets)
The type of SNMP packet and the size of the PDU are transmitted in the first part of the PDU header. The structure of the second part depends on the type of SNMP packet.
So that response packets can be assigned to the previous requests, there is the request ID, which are identical for request and response. This makes it possible to send several inquiries and to assign the answers correctly again.
The error status and index are used in response packets to indicate why a request could not be processed. As long as no error occurs, both fields are assigned the value zero. In the event of an error, the error index specifies the number of data records in which the error occurred. The error status indicates the reason for the error. With SNMPv1, the error status can have one of 6 possible values:
- no mistake
- Package is too big to send
- the OID is not supported
- wrong data type or value (only possible as an answer to set packages)
- read-only access (only possible as a response to set packages)
- unknown generation error
PDU header (trap packets)
The first two fields of the PDU header are identical to those of other SNMP packets for traps. The Packet Type field indicates that it is a trap. In the second part, other values are transferred that are only required for traps.
| PDU header | |||||
|---|---|---|---|---|---|
| Package type (trap) | OID of the device that generated the trap | Sender's IP address | general trap ID | company-specific trap ID | Time at which the trap event occurred |
The IP address of the sender and its manufacturer-specific OID (1.3.6.1.4.1. *) Are also sent to identify who the message is coming from. The OID indicates what kind of device it is. This is important to know if it is a company-specific trap that only applies to this device type.
This is followed by the general TrapID. There are seven possible general TrapIDs:
| designation | Value in the trap PDU |
|---|---|
| Cold start (coldStart) | 0 |
| Warm start (warm start) | 1 |
| Link Down (linkDown) | 2 |
| Link Up (linkUp) | 3 |
| Authentication Failure | 4th |
| EGP - Neighbors lost (egpNeighborLoss) | 5 |
| company-specific (enterpriseSpecific) | 6th |
If "company-specific (enterpriseSpecific)" is specified in the "TrapID" field, the ID of the company-specific trap is transferred in the following field.
Since it is possible that trap packets do not arrive in the order in which they were sent, there is also a time specification that specifies to hundredths of a second how long the SNMP agent ran until the trap event occurred. This makes it possible to put the trap events in the correct chronological order.
PDU body
The actual values are transmitted in the PDU body. Each value is transferred in a so-called variable binding:
| OID | Variable binding |
| value |
A variable binding includes its OID and the value itself.
There is no specification as to how many variable bindings can be sent in the PDU body. It is therefore possible to query several values with one get command. If, however, the response packet becomes too large, it can happen that the corresponding error message is sent back in the response packet.
With traps it is also possible that no variable bindings are sent. In this case the TrapID is considered sufficient information.
In the SNMP package, there is no provision for specifying the number of variable bindings sent. This can only be found out by specifying the size of the PDU body and the size of the individual variable bindings.
Security issues
A disadvantage of SNMP version 1 to 2c is the lack of security. These versions of SNMP do not support login with password and user name; so-called communities are used. However, these have the disadvantage that every user in the network can read out system information and even change values with a suitable program.
Communities are simple names, such as "PUBLIC" (can only read) or "PRIVATE" (can also write), which are transmitted by the SNMP service together with the request. They are nothing more than a previously agreed key ( pre-shared keys ). You can of course also use very long and complicated community names. However, this is of limited use, since SNMP packets are not encrypted and can therefore be easily "sniffed" (eavesdropped) by an attacker.
Allowed Host: There is, however, the possibility of restricting the IP addresses of the systems that are allowed to contact a monitored SNMP system. This is relatively simple protection, but it may be possible to override it with ARP spoofing and IP spoofing .
Management protection: Recently (1991) it has become common practice to create a separate network to monitor the systems in order to separate the user data traffic from the management traffic. This is called out-of-band. Traffic that flows over the conventional data network is called in-band communication. Since this second network increases the cost of monitoring, it only makes sense to use it in security-relevant areas, such as in the banking sector.
Read Only: It is also possible to assign a "Read Only" to certain systems. This means that each monitoring device can only read. This is often used with routers.
Among other things, SNMP Version 3 offers encryption and better authentication , which is currently often not used due to its greater complexity.
literature
- Larry Walsh: SNMP Mib Handbook. Wyndham Press, March 2008, ISBN 978-0-9814922-0-9 .
- Douglas R. Mauro and Kevin J. Schmidt: Essential SNMP: Help for System and Network Administrators 2nd Edition, O'Reilly Media, September 2005, ISBN 978-0-596-00840-6 .
- William Stallings: SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 . 2nd edition, Addison-Wesley Longman, February 1999, ISBN 978-0-201-48534-9 .
See also
- Agent Extensibility Protocol (AgentX)