SNMP v3 adds two optional levels of security to SNMP v2c Traps: Authentication and Privacy (Content Encryption).
To enable generated Audit events be sent using SNMP v3 flows, we rely upon software produced by the OpenSource Net-SNMP project. The main project along with binary distributions can be found at www.net-snmp.org. (Binaries are at www.net-snmp.org/download.html). This release of Micro Focus SNMP Audit Emitter was created to use Net-SNMP v5.4. It does not require a 3rd party OpenSSL installation, nor does it require an OpenSSL compliant Net-SNMP installation.
Note:
The use of SNMP v3 with authentication and privacy introduces the need to configure several basic options before the SNMP v3 Traps can be generated and sent. If you are not using authentication and privacy, you can ignore these options. They are as follows:
There are two further options which will only be used in a limited number of installations:
Depending upon the transmission privilege settings all of the options may be used. In most installations, all of the options are going to be required to enable correct authentication and cryptographically protected transmissions that can be received correctly at the management console where the trap messages are monitored.
The SNMP Audit Emitter can only send SNMP v3 traps under a single user identity. In order for the traps to be deciphered correctly, this identity must also be configured with exactly the same content at the receiver of the trap messages.
The first change to a standard V2 installation is to enable V3 operations.
mfaudit.emitter.snmp#agent.snmp_version = 3
Now we must select the level of security privilege that we require on our transmissions.
Whilst Authentication can be enabled or disabled at will, Privacy can only be enabled when Authentication is already enabled. So the three transmission privilege permutations are:
| "NoAuth" | No authentication or encryption of data |
| "AuthPriv" | Authenticate and use private (encrypted) data |
| "AuthNoPriv" | Authenticate user with no encryption of data |
When configuring the SNMP Audit Emitter, this choice is held in the "privilege" setting. The following example enables both Authorisation and Privacy.
mfaudit.emitter.snmp#agent.privilege = AuthPriv
When either Privacy or Authentication and Privacy are disabled, the relevant sections of the configuration are ignored.
To provided Authorisation, a user identity is configured at the monitoring trap receiver and the issuing Emitter. Five options define a user, and a further option defines the Security EngineID that groups the user within a logical group of users.
We shall now take a look at the User options in detail.
The Username
The username is a single text string with a simple name. This name cannot contain spaces.
mfaudit.emitter.snmp#agent.security_username = fred_jones
The Hash Method
The Hash Method and Authentication Pass Phrase (the Shared Secret in cryptographic terms) are combined to form a cryptic value. This value which will be compared with the receiver's similarly configured pairing which has a matching Username and Security EngineID. A mismatch will cause the authentication attempt to be rejected.
Most installations support the MD5 hash method, and later installations may also support SHA1. If configuring a new V3 user, you should choose to use the latest hash method installed at the monitoring location that will receive the traps. The original MD5 method is the default hash method as it will currently be pre-configured in more installations than SHA1.
mfaudit.emitter.snmp#agent.hmac = MD5
The chosen hash method is applied to a configured pass phrase. The pass phrase must be at least 8 characters in length and may be spacey if the phrase is contained within a single pair of quote characters. Non-spacey passwords may omit the quote characters.
mfaudit.emitter.snmp#agent.auth_passphrase = "auth password"
The Encryption Cipher
The Privacy cipher can be either DES or AES128. Like the SHA1 hash above, AES is a recent addition to SNMP V3 and may not be in place in all installations. As a result, the default setup is to use the DES cipher. As with choosing a hash method, if you are configuring a new v3 user you should choose to use the latest cipher method that is installed at the monitoring location that will receive the traps. This should ideally be AES, however the default setting is DES as this will match the majority of installations in the field today.
The three options are DES, AES and AES128. The latter two are equivalent. It is anticipated that additions to the SNMP V3 standard will add AES192 and AES256 support in the future. When this happens AES will refer to AES128.
mfaudit.emitter.snmp#agent.cipher = DES
Exactly the same rules apply to Privacy (Cipher) pass phrases and Authentication pass phrases.
mfaudit.emitter.snmp#agent.cipher_passphrase = "crypt password"
The Security Engine ID
Several copies of a given username can exist within an SNMP installation, however only one copy can exist within the scope of any one Security Engine. So the group of five options shown above are always paired with a Security Engine ID. This is a numerical string represented in hex format. There are many long and varied methods for determining what value to use for a security engine ID and there is as yet no formal consensus. This document is not the place to examine the arguments, however in the setup you will need to choose a value to use as the Security Engine ID. This must match the receiver's Engine ID and Username's config grouping of options.
The following example would work as an initial test value, however it lacks meaning in a wider SNMP context and your network management team should assign a security Engine ID for the Audit Emitter monitoring, or advise the user of an existing Engine ID that should be used.
mfaudit.emitter.snmp#agent.security_engineID = 0x0102030405
Putting this group together we have a collection that describes the user, the user's Security Engine in which it will work, and the methods of both proving the user's identity and encrypting the audit event's data content. Taken together this is the complete configuration describing a single user.
mfaudit.emitter.snmp#agent.privilege = AuthPriv mfaudit.emitter.snmp#agent.security_engineID = 0x0102030405 mfaudit.emitter.snmp#agent.security_username = fred_jones mfaudit.emitter.snmp#agent.hmac = MD5 mfaudit.emitter.snmp#agent.auth_passphrase = "auth password" mfaudit.emitter.snmp#agent.cipher = DES mfaudit.emitter.snmp#agent.cipher_passphrase = "crypt password"
The ContextID and ContextName
The final configuration items not mentioned so far are the Security Context ID and ContextName. These are paired together in much the same fashion as the SecurityEngineID and UserName to form a restricted connection entity.
Contexts can be useful in installations where several applications will be receiving SNMP data and the users do not wish all the applications to receive all the incoming data.
By giving different applications the same SecurityEngineID and UserName configuration, but different ContextEngine and ContextName configurations, data destined for specific locations can be sent to those locations without the need to configure extra Users in the SecurityEngine domain in order to distinguish the destinations and sources.
Again, in a similar fashion to the SecurityEngineID and UserName configuration items, the ContextEngineID is expected to be a hex string, and the ContextName a character string which usually has human readable content.
mfaudit.emitter.snmp#agent.context_engineID = 0x0102030405 mfaudit.emitter.snmp#agent.context_name = primary_audit_monitor
Related topics