Blog

Protokol SNMP

SNMP protocol

Network management requires adequate monitoring, i.e. detection of current events (monotoring) and possibly setting changes. How about SNMP protection from a cryptography perspective?

SNMP and its development

The SNMP protocol has been used for many years to find out information about the status of the device and possibly its settings. It currently exists in three versions, which differ significantly in terms of options and mainly protocol security. By security in this regard, I do not mean vulnerabilities in the code, but the protection of confidentiality (Confidentiality), integrity, non-repudiation and authenticity.

The proprietary protocol is based on uses PDU (Program Data Unit), specified in ITU-T standards. The end device must work as an agent, capable of receiving commands and sending data. Network management (NMS – Network Management Station) receives and evaluates data according to definitions in MIB files (Management Information Base). The definitions describe the properties of the system, for each property a separate OID is assigned, just like in X.509 certificates. Each of these properties can be assigned one or more values.

PortDescriptionVersion
UDP/161Port on which agent is listeningv1, v2, v3
UDP/162Port on which manager listens (SNMP Trap)v1, v2, v3
TCP/161Port on which agent listensv2, v3 (rare)
TCP/162Port on which manager listens (SNMP Trap)v2, v3 (rare)
UDP/10161SNMP/DTLS port on which agent listensv3 (rare)
UDP/10162SNMP/DTLS port on which manager listens (SNMP Trap)v3 (rare)
TCP/10161SNMP/TLS port on which the agent listensv3 (practically non-existent)
TCP/10162SNMP/TLS port on which the manager listens (SNMP Trap)v3 (practically non-existent)

SNMPv1

This protocol was created in 1988 and used communities (community, permission name) for reading and writing. These communities were sent in text form, without any protection. The given data could be read without any restrictions. Subsequent submissions of matching settings checked nothing but the matching string. If correct, the setting was applied.

Worse, there were default values for communities. Public was mostly used for monitoring, with some manufacturers read or monitor, then private for writing, sometimes also write.

Since the endpoints do not support any form of identification and authentication, any use of TLS/DTLS for protection is pointless. This protocol is extremely outdated and despite its universality it is advisable to avoid its deployment. If it is necessary to use it, it should only allow providing status information to specific points, the agent should be protected by a packet filter to limit communication.


SNMPv2

In 1993, the new SNMPv2 standard came, which after minor vicissitudes evolved into SNMPv2c. This is the current version in use. It brought significant optimization, TCP protocol support (at least on paper), brought the transition from 32-bit to 64-bit values, also allowed to start using the SNMPv2 agent as a proxy service for SNMPv1 ... it didn't bring any change in security. Here too, the possible use of TLS/DTLS for protection is nonsense and therefore the same rules apply as for SNMPv1.


SNMPv3

A significant change was brought about in 1999 by the SNMPv3 protocol. He rejected the originally used community strings, started using authentication, confidentiality protection and integrity protection. Custom cryptographic algorithms for protocol level protection control are part of USM (User Security Module), in case of TLS/DTLS use TSM (Transport Security Module) is used. The mentioned modules can be combined, it is recommended to use the same algorithms. TSM requires the use of X.509 certificates, so it is necessary to verify the corresponding support on the side of the agents and the NMS server before implementation.

TSM is an optional module that supports the following protocol sets:

  • TLS 1.0 for TCP (deprecated)
  • TLS 1.1 for TCP and DTLS 1.0 for UDP (deprecated)
  • TLS 1.2 for TCP and DTLS 1.2 for UDP (until 2030)
  • TLS 1.3 for TCP and DTLS 1.3 for UDP

USM is a mandatory module that has three basic states. The AuthNoPriv state supports authentication and integrity protection, the AuthPriv state supports authentication, confidentiality protection, and integrity protection.

  • Communication without authentication and protection of data integrity or confidentiality (NoAuthNoPriv)
  • Communication with authentication and data integrity protection, but without data privacy protection (AuthNoPriv)
  • Communication with authentication, protection of confidentiality and integrity of data (AuthPriv)

From the mentioned parameters, it is clear that communication in NoAuthPriv mode is completely inappropriate, does not provide any protection and is on the same level as SNMPv1 and SNMPv2. Communication in AuthNoPriv mode is only relevant in a limited area and only for monitoring. It is unsuitable for other purposes. The last one is communication in AuthPriv mode, which can be used both for monitoring and for setting parameters in a secure way.

In addition to the possibility of communication via a secure channel, it is advisable to think about the TSM module settings. What is important and neglected, since the code on the given elements may have security flaws, it is advisable to provide a separate and physically separated network for the management of these devices.

In the case of communication in AuthNoPriv and AuthPriv modes, it is possible to use the following groups of algorithms depending on the function.


Confidentiality Algorithms:

AlgorithmUsage ModeStandardMIB OIDKDF PasswordsNotes
No CipherRFC 34141.3.6.1.6.3.10.1.2.1 (usmNoPrivProtocol)Unsafe
DESCBCRFC 34141.3.6.1.6.3.10.1.2.2.1 (usmDESPrivProtocol)By hash*Wide support
3DESCBCRFC 38261.3.6.1.4.1.9.12.6.1.3 (cusm3DES168PrivProtocol)By hash*Not used in practice
AES-128CFBRFC 38261.3.6.1.6.3.20.1.1 (usmAesCfb128Protocol)By hash*Wide support
AES-192CFB1.3.6.1.4.1.9.12.6.1.1 (cusmAESCfb192PrivProtocol)By hash*Rare
AES-256CFB1.3.6.1.4.1.9.12.6.1.2 (cusmAESCfb256PrivProtocol)By hash*Supported by some manufacturers
3DES(EDE)CFBBy hash*Practically not used
IDEACFBN/A (Vendor specific)N/ANon-standard (2002-2005)

Integrity assurance algorithms:

AlgorithmMIB OIDStandardNotes
No verification1.3.6.1.6.3.10.1.1.1RFC 3414Use for authentication also disables integrity checking
HMAC-MD5-961.3.6.1.6.3.10.1.1.2.1RFC 3414Broken, HMAC function output is truncated to 96b
HMAC-SHA-961.3.6.1.6.3.10.1.1.2.2RFC 3414Broken, HMAC function output is truncated to 96b
SHA-1 (TSM variant)1.3.6.1.6.3.10.1.1.3RFC 6353Broken, derives key for TSM and ensures integrity
HMAC-SHA2-2241.3.6.1.6.3.10.1.1.4RFC 7860Deprecated, HMAC
HMAC-SHA2-2561.3.6.1.6.3.10.1.1.5RFC 7860HMAC, current implementation (until 2030)
HMAC-SHA2-3841.3.6.1.6.3.10.1.1.6RFC 7860HMAC, rare
HMAC-SHA2-5121.3.6.1.6.3.10.1.1.7RFC 7860HMAC, rare

Algorithms for providing authentication:

AlgorithmMIB OIDStandardNotes
No verification1.3.6.1.6.3.10.1.1.1RFC 3414usmNoAuthProtocol
MD5 (HMAC‑MD5)1.3.6.1.6.3.10.1.1.2RFC 3414usmHMACMD5AuthProtocol, broken
SHA1 (HMAC‑SHA‑1)1.3.6.1.6.3.10.1.1.3RFC 3628usmHMACSHAAuthProtocol, broken
SHA2-224 (HMAC‑SHA2-224)1.3.6.1.6.3.10.1.1.4RFC 7860usmHMAC128SHA224AuthProtocol, Deprecated
SHA2-256 (HMAC‑SHA2-256)1.3.6.1.6.3.10.1.1.5RFC 7860usmHMAC192SHA256AuthProtocol, current (until 2030)
SHA2-384 (HMAC‑SHA2-384)1.3.6.1.6.3.10.1.1.6RFC 7860usmHMAC256SHA384AuthProtocol, rare
SHA2-512 (HMAC‑SHA2-512)1.3.6.1.6.3.10.1.1.7RFC 7860usmHMAC384SHA512AuthProtocol, rare

A huge disadvantage of SNMP is the inability to define a separate algorithm for ensuring integrity and a separate algorithm for ensuring authenticity. In the case of configuration, the same function is always used for these purposes. It also creates a method of deriving key material, which is quite outdated from today's perspective. The SNMP standard clearly states the conditions. The password is repeated until it creates 1MB of data (1,048,576 bytes). The excess is cut off. The result is hashed and a working value is created:
Ku=HASH(buffer)
This is then used to locate the key material in the following way:

Kul = HASH( Ku || engineID || Ku )

Where:
- Ku is the global key (from the password)
- engineID is the unique identifier of the given SNMP engine
This is a historical and from today's perspective weak procedure. The main disadvantages based on current security experience are:
- Single iteration
- Fixed input length
- Missing salt
For the following reason, it is necessary to choose long and complex passwords in order to ensure at least some level of security.


A set of standards describing the SNMP protocol in all its versions:

StandardDescriptionVersion
RFC 1157A Simple Network Management Protocol - SNMPv1 DefinitionSNMPv1
RFC 1155Structure and Identification of Management Information for TCP/IP-based internets (SMIv1)SNMPv1
RFC 1212Concise MIB DefinitionsSNMPv1
RFC 1215Convention for Defining TrapsSNMPv1
RFC 1901Introduction to Community-based SNMPv2SNMPv2
RFC 1902Structure of Management Information for SNMPv2 (SMIv2)SNMPv2
RFC 1903Textual Conventions for SNMPv2SNMPv2
RFC 1904Conformance Statements for SNMPv2SNMPv2
RFC 1905Protocol Operations for SNMPv2SNMPv2
RFC 1906Transport Mappings for SNMPv2SNMPv2
RFC 1907Management Information Base for SNMPv2SNMPv2
RFC 1908Coexistence between Version 1 and Version 2 of the Internet-standard Network Management FrameworkSNMPv2
RFC 2089V2ToV1 Mapping SNMPv2 onto SNMPv1 (optional mapping)SNMPv2
RFC 3410Introduction and Applicability Statements for Internet-Standard Management FrameworkSNMPv3
RFC 3411An Architecture for Describing SNMP Management FrameworksSNMPv3
RFC 3412Message Processing and Dispatching for SNMPSNMPv3
RFC 3413SNMP ApplicationsSNMPv3
RFC 3414User-based Security ModelSNMPv3
RFC 3415View-based Access Control ModelSNMPv3
RFC 3416Version 2 of SNMP Protocol OperationsSNMPv3
RFC 3417Transport Mappings for SNMPSNMPv3
RFC 3584Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management FrameworkSNMPv3
RFC 3826The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security ModelSNMPv3
RFC 7860HMAC-SHA-2 Authentication Protocols in User-Based Security ModelSNMPv3
RFC 5590Transport Subsystem for the Simple Network Management ProtocolSNMPv3 TSM
RFC 5591Transport Security Model for SNMPSNMPv3 TSM
RFC 5953TLS Transport Model for SNMPSNMPv3 TSM
RFC 2578Structure of Management Information Version 2SMIv2
RFC 2579Textual Conventions for SMIv2SMIv2
RFC 2580Conformance Statements for SMIv2SMIv2

SNMP is a good servant but a bad master. Outdated configurations that do not allow solving data protection problems can be quite dangerous when managing a network. Even on a local network, not all participants can be trusted, therefore ensuring the authenticity of the message along with the protection of integrity and confidentiality should be a basic requirement.

References:

  1. RFC Index
    Source: https://www.rfc-editor.org/

Autor článku:

Jan Dušátko
Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.

1. Introductory Provisions

1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).
1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.

2. Creation of a contract by signing up for a course

2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.
2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.

3. Termination of the contract by cancellation of the application

3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.
3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.

4. Price and payment terms

4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.
4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.

5. Training conditions

5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.
5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.

6. Complaints

6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.
6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.

7. Copyright of the provided materials

7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.
7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.

8. Liability

8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.
8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.

9. Validity of the Terms

9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.

Consent to the collection and processing of personal data

According to Regulation (EU) No 2016/679 of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation, hereinafter referred to as "the Regulation"), the processor xxx (hereinafter referred to as "the Controller") processes personal data. Individual personal data that are part of the processing during specific activities at this web presentation and in the course of trade are also broken down.
Although the collection of data is ubiquitous, the operation of this website is based on the right to privacy of each user. For this reason, the collection of information about users takes place to the extent absolutely necessary and only if the user decides to contact the operator. We consider any further collection and processing of data unethical.

Information about the records of access to the web presentation

This website does not collect any cookies. The site does not use any analytical scripts of third parties (social networks, cloud providers). For these reasons, an option is also offered for displaying the map in the form of a link, where the primary source is OpenStreet and alternatives then the frequently used Maps of Seznam, a.s., or Google Maps of Google LLC Inc. The use of any of these sources is entirely at the discretion of the users of this site. The administrator is not responsible for the collection of data carried out by these companies, does not provide them with data about users and does not cooperate on the collection of data.
Logging of access takes place only at the system level, the reason being the identification of any technical or security problems. Other reasons are overview access statistics. No specific data is collected or monitored in this area and all access records are deleted after three months.

Information about contacting the operator of the site

The form for contacting the operator of the site (administrator) contains the following personal data: name, surname, e-mail. These data are intended only for this communication, corresponding to the address of the user and are kept for the time necessary to fulfil the purpose, up to a maximum of one year, unless the user determines otherwise.

Information about the order form

In case of an interest in the order form, the form contains more data, i.e. name, surname, e-mail and contact details for the organisation. These data are intended only for this communication, corresponding to the address of the user and are kept for one year, unless the user determines otherwise. In the event that a business relationship is concluded on the basis of this order, only the information required by Czech law on the basis of business relations (company name and address, bank account number, type of course and its price) will continue to be kept by the administrator.

Information about the course completion document

Within the course, a course completion document is issued by the processor. This document contains the following data: student's name and surname, the name and date of the course completion and the employer's name. The information is subsequently used for the creation of a linear hash tree (non-modifiable record). This database contains only information about the provided names and company names, which may or may not correspond to reality and is maintained by the processor for possible re-issuance or verification of the document's issuance.

Rights of the personal data subject

The customer or visitor of this website has the possibility to request information about the processing of personal data, the right to request access to personal data, or the right to request the correction or deletion of any data held about him. In the case of deletion, this requirement cannot be fulfilled only if it is not data strictly necessary in the course of business. The customer or visitor of this website also has the right to obtain explanations regarding the processing of his personal data if he finds out or believes that the processing is carried out in violation of the protection of his private and personal life or in violation of applicable legislation, and the right to request removal of the resulting situation and to ensure the correction.
Furthermore, the customer/visitor of this website may request restriction of processing or object to the processing of personal data and has the right to withdraw his/her consent to the processing of personal data at any time in writing, without prejudice to the lawfulness of their processing prior to such withdrawal. For this purpose, the contact e-mail address support@cryptosession.cz is used.
The customer/visitor has the right to file a complaint against the processing of personal data with the supervisory authority, which is the Office for Personal Data Protection.