Network management requires adequate monitoring, i.e. detection of current events (monotoring) and possibly setting changes. How about SNMP protection from a cryptography perspective?
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.
| Port | Description | Version |
| UDP/161 | Port on which agent is listening | v1, v2, v3 |
| UDP/162 | Port on which manager listens (SNMP Trap) | v1, v2, v3 |
| TCP/161 | Port on which agent listens | v2, v3 (rare) |
| TCP/162 | Port on which manager listens (SNMP Trap) | v2, v3 (rare) |
| UDP/10161 | SNMP/DTLS port on which agent listens | v3 (rare) |
| UDP/10162 | SNMP/DTLS port on which manager listens (SNMP Trap) | v3 (rare) |
| TCP/10161 | SNMP/TLS port on which the agent listens | v3 (practically non-existent) |
| TCP/10162 | SNMP/TLS port on which the manager listens (SNMP Trap) | v3 (practically non-existent) |
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.
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.
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:
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.
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:
| Algorithm | Usage Mode | Standard | MIB OID | KDF Passwords | Notes |
| No Cipher | RFC 3414 | 1.3.6.1.6.3.10.1.2.1 (usmNoPrivProtocol) | Unsafe | ||
| DES | CBC | RFC 3414 | 1.3.6.1.6.3.10.1.2.2.1 (usmDESPrivProtocol) | By hash* | Wide support |
| 3DES | CBC | RFC 3826 | 1.3.6.1.4.1.9.12.6.1.3 (cusm3DES168PrivProtocol) | By hash* | Not used in practice |
| AES-128 | CFB | RFC 3826 | 1.3.6.1.6.3.20.1.1 (usmAesCfb128Protocol) | By hash* | Wide support |
| AES-192 | CFB | 1.3.6.1.4.1.9.12.6.1.1 (cusmAESCfb192PrivProtocol) | By hash* | Rare | |
| AES-256 | CFB | 1.3.6.1.4.1.9.12.6.1.2 (cusmAESCfb256PrivProtocol) | By hash* | Supported by some manufacturers | |
| 3DES(EDE) | CFB | By hash* | Practically not used | ||
| IDEA | CFB | N/A (Vendor specific) | N/A | Non-standard (2002-2005) |
Integrity assurance algorithms:
| Algorithm | MIB OID | Standard | Notes |
| No verification | 1.3.6.1.6.3.10.1.1.1 | RFC 3414 | Use for authentication also disables integrity checking |
| HMAC-MD5-96 | 1.3.6.1.6.3.10.1.1.2.1 | RFC 3414 | Broken, HMAC function output is truncated to 96b |
| HMAC-SHA-96 | 1.3.6.1.6.3.10.1.1.2.2 | RFC 3414 | Broken, HMAC function output is truncated to 96b |
| SHA-1 (TSM variant) | 1.3.6.1.6.3.10.1.1.3 | RFC 6353 | Broken, derives key for TSM and ensures integrity |
| HMAC-SHA2-224 | 1.3.6.1.6.3.10.1.1.4 | RFC 7860 | Deprecated, HMAC |
| HMAC-SHA2-256 | 1.3.6.1.6.3.10.1.1.5 | RFC 7860 | HMAC, current implementation (until 2030) |
| HMAC-SHA2-384 | 1.3.6.1.6.3.10.1.1.6 | RFC 7860 | HMAC, rare |
| HMAC-SHA2-512 | 1.3.6.1.6.3.10.1.1.7 | RFC 7860 | HMAC, rare |
Algorithms for providing authentication:
| Algorithm | MIB OID | Standard | Notes |
| No verification | 1.3.6.1.6.3.10.1.1.1 | RFC 3414 | usmNoAuthProtocol |
| MD5 (HMAC‑MD5) | 1.3.6.1.6.3.10.1.1.2 | RFC 3414 | usmHMACMD5AuthProtocol, broken |
| SHA1 (HMAC‑SHA‑1) | 1.3.6.1.6.3.10.1.1.3 | RFC 3628 | usmHMACSHAAuthProtocol, broken |
| SHA2-224 (HMAC‑SHA2-224) | 1.3.6.1.6.3.10.1.1.4 | RFC 7860 | usmHMAC128SHA224AuthProtocol, Deprecated |
| SHA2-256 (HMAC‑SHA2-256) | 1.3.6.1.6.3.10.1.1.5 | RFC 7860 | usmHMAC192SHA256AuthProtocol, current (until 2030) |
| SHA2-384 (HMAC‑SHA2-384) | 1.3.6.1.6.3.10.1.1.6 | RFC 7860 | usmHMAC256SHA384AuthProtocol, rare |
| SHA2-512 (HMAC‑SHA2-512) | 1.3.6.1.6.3.10.1.1.7 | RFC 7860 | usmHMAC384SHA512AuthProtocol, 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 )A set of standards describing the SNMP protocol in all its versions:
| Standard | Description | Version |
| RFC 1157 | A Simple Network Management Protocol - SNMPv1 Definition | SNMPv1 |
| RFC 1155 | Structure and Identification of Management Information for TCP/IP-based internets (SMIv1) | SNMPv1 |
| RFC 1212 | Concise MIB Definitions | SNMPv1 |
| RFC 1215 | Convention for Defining Traps | SNMPv1 |
| RFC 1901 | Introduction to Community-based SNMPv2 | SNMPv2 |
| RFC 1902 | Structure of Management Information for SNMPv2 (SMIv2) | SNMPv2 |
| RFC 1903 | Textual Conventions for SNMPv2 | SNMPv2 |
| RFC 1904 | Conformance Statements for SNMPv2 | SNMPv2 |
| RFC 1905 | Protocol Operations for SNMPv2 | SNMPv2 |
| RFC 1906 | Transport Mappings for SNMPv2 | SNMPv2 |
| RFC 1907 | Management Information Base for SNMPv2 | SNMPv2 |
| RFC 1908 | Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework | SNMPv2 |
| RFC 2089 | V2ToV1 Mapping SNMPv2 onto SNMPv1 (optional mapping) | SNMPv2 |
| RFC 3410 | Introduction and Applicability Statements for Internet-Standard Management Framework | SNMPv3 |
| RFC 3411 | An Architecture for Describing SNMP Management Frameworks | SNMPv3 |
| RFC 3412 | Message Processing and Dispatching for SNMP | SNMPv3 |
| RFC 3413 | SNMP Applications | SNMPv3 |
| RFC 3414 | User-based Security Model | SNMPv3 |
| RFC 3415 | View-based Access Control Model | SNMPv3 |
| RFC 3416 | Version 2 of SNMP Protocol Operations | SNMPv3 |
| RFC 3417 | Transport Mappings for SNMP | SNMPv3 |
| RFC 3584 | Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework | SNMPv3 |
| RFC 3826 | The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model | SNMPv3 |
| RFC 7860 | HMAC-SHA-2 Authentication Protocols in User-Based Security Model | SNMPv3 |
| RFC 5590 | Transport Subsystem for the Simple Network Management Protocol | SNMPv3 TSM |
| RFC 5591 | Transport Security Model for SNMP | SNMPv3 TSM |
| RFC 5953 | TLS Transport Model for SNMP | SNMPv3 TSM |
| RFC 2578 | Structure of Management Information Version 2 | SMIv2 |
| RFC 2579 | Textual Conventions for SMIv2 | SMIv2 |
| RFC 2580 | Conformance Statements for SMIv2 | SMIv2 |
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.
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“).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.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.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.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.6. Complaints
6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.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.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.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.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.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.