Use this documentation with care! It describes the heavily outdated version 5, which was actively developed around 2010 and is considered dead by the rsyslog team for many years now.

This documentation reflects the latest update of the previously existing (now removed) v5-stable branch. It describes the 5.10.2 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 v5 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 no rsyslog community support available for this heavily outdated version. If you need to stick with it, please ask your distribution for support.

Setting up a client

In this step, we configure a client machine. We from our scenario, we use zuse.example.net. You need to do the same steps for all other clients, too (in the example, that meanst turng.example.net). The client check’s the server’s identity and talks to it only if it is the expected server. This is a very important step. Without it, you would not detect man-in-the-middle attacks or simple malicious servers who try to get hold of your valuable log data.

Steps to do:

  • make sure you have a functional CA (Setting up the CA)
  • generate a machine certificate for zuse.example.net (follow instructions in Generating Machine Certificates)
  • make sure you copy over ca.pem, machine-key.pem ad machine-cert.pem to the client. Ensure that no user except root can access them (even read permissions are really bad).
  • configure the client so that it checks the server identity and sends messages only if the server identity is known. Please note that you have the same options as when configuring a server. However, we now use a single name only, because there is only one central server. No using wildcards make sure that we will exclusively talk to that server (otherwise, a compromised client may take over its role). If you load-balance to different server identies, you obviously need to allow all of them. It still is suggested to use explcit names.

At this point, please be reminded once again that your security needs may be quite different from what we assume in this tutorial. Evaluate your options based on your security needs.

Sample syslog.conf

Keep in mind that this rsyslog.conf sends messages via TCP, only. Also, we do not show any rules to write local files. Feel free to add them.

# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /rsyslog/protected/ca.pem
$DefaultNetstreamDriverCertFile /rsyslog/protected/machine-cert.pem
$DefaultNetstreamDriverKeyFile /rsyslog/protected/machine-key.pem

$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer central.example.net
$ActionSendStreamDriverMode 1 # run driver in TLS-only mode
*.* @@central.example.net:10514 # forward everything to remote server

Note: the example above forwards every message to the remote server. Of course, you can use the normal filters to restrict the set of information that is sent. Depending on your message volume and needs, this may be a smart thing to do.

Be sure to safeguard at least the private key (machine-key.pem)! If some third party obtains it, you security is broken!