In the Notifications via SNMP frame it is possible to configure the system for sending notifications by SNMP trap. Unlike an SNMP data collection service, a “Trap” is a notification service initiated by the monitored server, this initiates the communication and delivery of alerts to the remote SNMP server. The service supports communication with SNMP v1, SNMP v2 and SNMP v3 protocols.

Below we will detail a little about the differences of the SNMP protocol versions.

  • SNMP v1

The first version of SNMP has an extremely fragile authentication scheme, its only security mechanism being "community names". These represent a management group with specific permissions, that is, the assignment of the rights to use SET and GET instructions on a given parameter to members of this community. The storage of these names is local, that is, each agent that implements SNMP must register the permissions given to each management community that can make use of its parameters.

It is important to note that permissions are given to a particular community, not specific management stations, in fact, there is no listing of members of a community.

The "authentication" of an NMS “Network Management Station” is done through the declaration, sent in text format, of the name of the community to which it belongs. The NMS, therefore, must maintain a list of the relevant community names for each agent in the network. To simplify the management task, there is a tendency to maintain a certain uniformity in the management groups registered in the various entities of the network, but this is not mandatory.

The main flaw of this security model lies in the fact that anyone who knows the community name with the appropriate privileges can send an SNMP command over the network. To make matters worse, as there is no privacy in SNMPv1, information about community names is sent in text form and without encryption in UDP messages that travel over the network, it is extremely simple for an attacker to intercept these names and relate them to stations which are destined.

Given this total insecurity generated by the combination of the lack of privacy with the simple and decentralized authentication model, almost all implementations of this version of SNMP in production systems disable the SET instruction, and restrict the parameters accessible by the GET instructions to non-confidential information. This attitude greatly limits the functionality of the protocol, but at the same time guarantees security in environments where it is essential.

  • SNMP v2

Originally, a reform of the SNMP security model was part of the goals in creating the second version of the protocol. SNMPv2 (RFC 1901, 1996) emerged to address some of the shortcomings of SNMPv1.

Added at least two new functions:

  • Get-bulk-request: Access to large blocks of information in the MIB;
  • Inform-request: Allows a manager to send relevant information directly to other managers;
  • Among the novelties of SNMPv2, we highlight:
    • Management of decentralized networks, allowing the existence of more than one management station and, consequently, the exchange of information between them;
    • Possibility of transferring large blocks of information;
    • Introduction of 64-bit counters, enabling better monitoring of variables that reach their limits quickly with 32-bit counters;
    • Improvement in error handling of variables, defining the success or error status of the operation for each PDU variable and no longer for the PDU Thus, if one variable contains an error, the others will not be sacrificed, being the variable field in that the problem occurred filled with an error code.

The final version of the protocol that was standardized was version 2c, which despite introducing new features such as the “GetBulkRequest” instruction, did not make any changes to the protocol's security model and the model based on community names remained.

  • SNMP v3

This version of the protocol was mainly focused on improving the security offered by previous versions of the SNMP protocol. Mechanisms have been developed to address each of the security flaws discussed so far. In this way, it became possible to use the full potential of the protocol, including SET instructions, without compromising network security. The new security model guarantees confidentiality, integrity, authentication and access control.

Generally speaking, the effective PDU that carries the SNMP instruction (either SNMPv1 or SNMPv2) is encapsulated in an SNMPv3 PDU. This operation provides security-related functions at the message processing level. For this communication to be effective, both the management station and the agents must be using the same SNMP engine.

The two main modules of the SNMPv3 security model are the User-based Security Model (USM) and the View-based Access Control Model (VACM). The USM is in charge of authenticating, encrypting and decrypting SNMP packets, while the VACM is in charge of managing access to data in the MIB.

To send notifications via SNMP Trap, access the panel shown below and configure according to the interface fields and configuration parameters of the remote SNMP server and the version of the protocol in use.


To configure notifications, access the System menu, select the Administration option and on the Settings tab configure the Notifications panel via SNMP TRAP.


Administration - Notifications via SNMP


Initially, enable notifications via SNMP by checking the Enabled [] checkbox;


  • Version: Inform the version used by your SNMP server. The available options are SNMPv1, SNMPv2 and SNMPv3. Ex.: SNMPv2;
  • Community: Inform the community that has been configured on the SNMP server. This field will only be available in SNMPv1 and SNMPv2 versions. Ex.: Blockbit;
  • Destination: Inform the SNMP server IP. Ex.: 172.16.102.52;
  • Authentication Protocol: Inform which encryption method will be used, this feature is only possible for SNMPv3. Ex.: MD5;
  • EngineID: Inform which SNMP mechanism will be configured based on what was configured on the SNMP server, this feature is only possible for SNMPv3. The Engine ID is a mechanism that serves as a unique identifier for the agent. The Engine ID is used with a hash function to generate keys for authentication and encryption of SNMPv3 messages;
  • User: Inform a user to perform authentication on the remote service;
  • User Password: Enter a password for user authentication on the remote service;
  • Security Level: Inform the security level in the remote service, which can be authenticated private or authenticated non-private;
  • Cryptographic Algorithms: Inform the encryption algorithm that has been configured on the remote server for authentication;
  • Private Password: If the Security Level is configured as AuthPriv, it is necessary to configure the private password for the connection.

The Authetication Protocol, Engine ID, User, Password, Security Level, Cryptographic Algorithms, Private Password fields will only be enabled for completion, if the version chosen in the Version for SNMPv3 field.
In turn, if the selected version is SNMPv3, the Community field will be disabled.


Then click [] to save.


After making the settings, the notifications that occurred will be displayed by clicking on the notifications button [] located at the top of the screen.


For more information about notifications via Email, click on this page.

If you want to know about Blockbit MIBs, click on this page.

Finnaly, click here to get more information about Zabbix.


  • No labels