omrelp

This article will show you, how to use simple tls encryption with the RELP protocol for sending and receiving syslog messages.

We basically need two machines, both running at least rsyslog 7.3.16. In addition to rsyslog, we also need the most current version of librelp.

General information

When installing rsyslog, make sure to enable the RELP functionality by issuing the correct commands for the configure. The configure command should look like this:

./configure --prefix=/usr --enable-relp

This is the most basic command for our example. Please note, that you might need to enable other modules as well if you plan to use them.

Before you start to configure rsyslog on either machine, make sure you have librelp already installed. You might need to additionaly install the gnutls package.

Client Config

The configuration for the client is relatively simple.  Basically, we can use as inputs whatever we like and simply use RELP with TLS encryption for forwarding the messages. The configuration could look like this:

module(load="imuxsock")
module(load="imudp")
module(load="omrelp")

input(type="imudp" port="514")

action(type="omrelp" target="192.168.233.144" port="2514" tls="on")

As you can see, we first load our modules. That is a generic step. We also load the output module “omrelp” which enables us later to forward messages via RELP.

In the second stage we configure our input. This example has the ability to receive syslog via imudp on port 514.

And the final step is our action. We use omrelp to forward all log messages to our central server via port 2514. Please note the option tls=”on” which directs the module to encrypt all messages via TLS.

Server Config

The server configuration looks a bit different and is one step more complicated.

module(load="imuxsock")
module(load="imrelp" ruleset="relp")

input(type="imrelp" port="2514" tls="on")

ruleset(name="relp") {
action(type="omfile" file="/var/log/relptls")
}

Again, we first configure the modules. Contrary to the Client configuration, we load “imrelp” and create the input with it in the second step.

The input with imrelp must listen to the same port, that the client sends its messages to. Also we must enable the TLS option as well. The reason might seem obvious, because without the option enabled, imrelp will push only garbage messages into the processing system. So we need TLS enabled to decrypt the messages. Please note, that I also bound the input to a ruleset.

The ruleset and action are again very basic. The ruleset (which is bound to the input) ensures, that only the messages that are received via RELP are processend by the enclosed actions. This is much easier, than creating filters to determine the source of the message (not only from a setup point of view, but also in regards of processing speed). The action in the ruleset will then write all messages that run into the ruleset into a single file. Please note: for imrelp, you can only bind the module to a ruleset. In consequence, all created listeners of this type are bound to this single ruleset.