Search Results for: queue

This guide will tell you, how to quickly protect your disk queue through encryption. So you can be sure that unauthorized persons can’t read your queue.
Please note that we only use the “disk” queue format in this guide to show you the encrypted files but normally we recommend you to use the “LinkedList” queue format for a better performance.

This feature is available from version 7.5.0 or higher. In addition to rsyslog we need the most current version of librelp.

The Intention

Whenever two systems talk over a network, something can go wrong. For example, the communications link may go down, or a client or server may abort. Even in regular cases, the server may be offline for a short period of time because of routine maintenance.

A logging system should be capable of avoiding message loss in situations where the server is not reachable. To do so, unsent data needs to be buffered at the client while the server is offline. Then, once the server is up again, this data is to be sent.

This can easily be acomplished by rsyslog. In rsyslog, every action runs on its own queue and each queue can be set to buffer data if the action is not ready. Of course, you must be able to detect that “the action is not ready”, which means the remote server is offline. This can be detected with plain TCP syslog and RELP, but not with UDP. So you need to use either of the two. In this howto, we use plain TCP syslog.

Please note that we are using rsyslog-specific features. The are required on the client, but not on the server. So the client system must run rsyslog (at least version 7.5.0), while on the server another syslogd may be running, as long as it supports plain tcp syslog.

Normally the rsyslog queueing subsystem tries to buffer to memory if you use the “LinkedList” queue typ. So even if the remote server goes offline, no disk file is generated. File on disk are created only if there is need to, for example if rsyslog runs out of (configured) memory queue space or needs to shutdown (and thus persist yet unsent messages). Using main memory and going to the disk when needed is a huge performance benefit. But in this case we only want to create a disk queue which is encrypted. So we use “Disk” as the queue typ, disk means that rsyslog writes immediately.

How To Setup

First, you need to create a working directory for rsyslog. This is where it stores its queue files (should need arise). You may use any location on your local system.

What have to do next is instruct rsyslog to use a disk queue and then configure your action. There is nothing else to do. With the following simple config file, you forward anything you receive to a remote server and have buffering applied automatically. This must be done on the client machine.

module(load=” imuxsock”) # local message reception
$WorkDirectory /home/test/rsyslog/work # default location for work (spool) files

action(type=”omfwd”
queue.type=”disk” queue.fileName=”enc”
queue.cry.provider=”gcry” queue.cry.key=”/path/to/contrib/gnutls/key.pem”
target=”172.123.123.5
port=”10514″)

The “queue.fileName=”enc”” is used to create encrypted queue files, should need arise. This value must be unique inside rsyslog.conf. No two rules must use the same queue file. Also, for obvious reasons, it must only contain those characters that can be used inside a valid file name. Rsyslog possibly adds some characters in front and/or at the end of that name when it creates files. So that name should not be at the file size name length limit (which should not be a problem these days).
In the next value “queue.cry.key=”/path/to/key”” you have to provide the path to your keyfile, if this path is invalid rsyslog will not encrypt your queue files.

Please note that actual spool files are directly created because we use the “disk” mode, if you use the “LinkedList” mode then they are only created if the remote server is down and there is no more space in the in-memory queue. By default, a short failure of the remote server will never result in the creation of a disk file as a couple of hundered messages can be held in memory by default. [These parameters can be fine-tuned. However, then you need to either fully understand how the queue works (read elaborate doc) or use professional services to have it done based on your specs ;) – what that means is that fine-tuning queue parameters is far from being trivial…]

If you would like to test the encryption scenario, you need to stop, wait a while and restart your server. Then simply open a new generated queue file they should all be encrypted now.