Use this documentation with care! It describes
the outdated version 7, which was actively
developed around 2014 and is considered dead by the
This documentation reflects the latest update of the v7-stable branch. It describes the 7.6.8 version, which was never released. As such, it contains some content that does not apply to any released version.
To obtain the doc that properly matches your installed v7 version, obtain the doc set from your distro. Each version of rsyslog contained the version that exactly matches it.
As general advise, it is strongly suggested to upgrade to the current version supported by the rsyslog project. The current version can always be found on the right-hand side info box on the rsyslog web site.
Note that there is only limited rsyslog community support available for the outdated v7 version (officially we do not support it at all, but we usually are able to answer simple questions). If you need to stick with v7, it probably is best to ask your distribution for support.
Module Name: mmrfc5424addhmac
Author:Rainer Gerhards <email@example.com>
Available since: 7.5.6
This module adds a hmac to RFC5424 structured data if not already present. This is a custom module and uses openssl as requested by the sponsor. This works exclusively for RFC5424 formatted messages; all others are ignored.
If both mmpstrucdata and mmrfc5424addhmac are to be used, the recommended calling sequence is
with that sequence, the generated hash will become available for mmpstrucdata.
Module Configuration Parameters:
Action Confguration Parameters:
- key The “key” (string) to be used to generate the hmac.
- hashfunction An openssl hash function name for the function to be used. This is passed on to openssl, so see the openssl list of supported function names.
- sd_id The RFC5424 structured data ID to be used by this module. This is the SD-ID that will be added. Note that nothing is added if this SD-ID is already present.
rsyslog does not contain any tools to verify a log file (this was not part of the custom project). So you need to write your own verifier.
When writing the verifier, keep in mind that the log file contains messages with the hash SD-ID included. For obvious reasons, this SD-ID was not present when the hash was created. So before the actual verification is done, this SD-ID must be removed, and the remaining (original) message be verified. Also, it is important to note that the output template must write the exact same message format that was received. Otherwise, a verification failure will obviously occur - and must so, because the message content actually was altered.
So in a more formal description, verification of a message m can be done as follows:
- let m’ be m with the configured SD-ID removed (everything between ). Otherwise, m’ must be an exact duplicate of m.
- call openssl’s HMAC function as follows:
HMAC(hashfunction, key, len(key), m', len(m'), hash, &hashlen);Where hashfunction and key are the configured values and hash is an output buffer for the hash.
- let h be the extracted hash value obtained from m within the relevant SD-ID. Be sure to convert the hex string back to the actual byte values.
- now compare hash and h under consideration of the sizes. If these values match the verification succeeds, otherwise the message was modified.
If you neeed help implementing a verifier function or want to sponsor development of a verification tool, please simply email firstname.lastname@example.org for a quote.