Assumed Standard rsyslog.conf
When I initially started to write this book, I provided only excerpts of rsyslog.conf that showed which lines you had to add. Quickly, I received feedback that this is inadequate to make the recipies easy to use – because everyone still needed to guess where to place the excerpts. Or, even worse, place them at the wrong spots, not knowing that sequence of statements is important in rsyslog.conf.
To solve this issue, I now use a “standard” syslog config, just like can be found on many systems. Your’s may not be exactly the same, but I guess the standard config helps you find where the configuration samples need to go into. As a reference point, this is the “standard” config that all samples build on:
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* /var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log
local7.* /var/log/boot.log
I was hesitant at first to use a real-life sample – repeating it in any recipe requires much space. However, I have convinced myself that this space is well spent, facilitating the adoption of the samples. Only occasionally, when I give some counter-examples, I spare myself from reproducing the full standard rsyslog.conf, hoping that the context makes clear what is meant.
In each recipe, a full rsyslog.conf, based on above example, is specified. The recipe-specific alterations to the config file are given in a different typeface, so that they can be easily identified.
Using a different log Format for all Files
Rsyslog comes with a limited set of log file formats. These resemble the default format that people (and log analyzers) usually expect. However, for some reason or another, it may be required to change the log format. In this recipe, we define a new format and use it as the default format for all log files.
Config Statements
$template myFormat,"%rawmsg%\n"
$ActionFileDefaultTemplate myFormat
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* /var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log
local7.* /var/log/boot.log
Things to think about
The template and ActionFileDefaultTemplate statements must be made at the top of the configuration file, before any of the files are specified.
How it works
The Template-statement defines the new format. It consist of fields to be written, potential modifications as well as literal text. In the sample config statement, “rawmsg” ist a property that contains the syslog message as it was received by rsyslogd (“received” from any source, for example a remote system or the local log socket). The string “\n” is a line feed (ASCII LF), a constant being added to the string. Usually, log line templates need to end with “\n”, because without that, all log records would be written into a single line. Note that there are many fields and options for these fields that you can specify. The system is very flexible. But getting into the detail of all of that is beyond the scope of this cookbook-style book. Please see the “property replacer” official documentation for more details.
The $ActionFileDefaultTemplate then makes the newly defined template the default for all file actions. This saves you from specifying it with any single action line. But otherwise, it is equivalent to
$template myFormat,"%rawmsg%\n"# The authpriv file has restricted access.
authpriv.* /var/log/secure;myFormat# Log all the mail messages in one place.
mail.* /var/log/maillog;myFormat# Log cron stuff
cron.* /var/log/cron;myFormat# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler;myFormat# Save boot messages also to boot.log
local7.* /var/log/boot.log;myFormatChangeLog for 4.3.0 (devel)
Version 4.3.0 [DEVEL] (rgerhards), 2009-04-17
- new feature: new output plugin omprog, which permits to start program and feed it (via its stdin) with syslog messages. If the program terminates, it is restarted.
- improved internal handling of RainerScript functions, building the necessary plumbing to support more functions with decent runtime performance. This is also necessary towards the long-term goal of loadable library modules.
- added new RainerScript function “tolower”
- improved testbench
- added tests for tcp-based reception
- added tcp-load test (1000 connections, 20,000 messages)
- added $MaxOpenFiles configuration directive
- bugfix: solved potential memory leak in msg processing, could manifest itself in imtcp
- bugfix: ompgsql did not detect problems in sql command execution this could cause loss of messages. The handling was correct if the connection broke, but not if there was a problem with statement execution. The most probable case for such a case would be invalid sql inside the template, and this is now much easier to diagnose.
SQL Injection Vulnerability in rsyslogd
An SQL injection vulnerability was found in all rsyslog releases prior to the ones announced on 2005-09-23. An attacker can send a specifically-crafted syslog message to rsyslogd and potentially take ownership of the machine.
This can be locally exploited if rsyslogd is listening on the local socket. Wes assume it is doing this in almost all cases. It can also be exploited remotely if rsyslogd is listening on network sockets and the attacker is not blocked from sending messages to rsyslogd (e.g. if not blocked by firewalling).
The vulnerability can potentially be used to take full ownership of the computer a compromised rsyslog is running on. The extend of the compromise is depending on the permissions of the user used to connect to MySQL.
We do not know of any case where this was exploited in practice. The bug was discovered during security-testing rsyslogd.
As of this writing, fixed versions exist both for the stable and the development branch. They are named 1.0.1 and 1.10.1. They can be obtained via the following links:
For 1.0.1 stable:
http://www.rsyslog.com/Downloads-index-req-getit-lid-17.phtml
For 1.10.1 development:
http://www.rsyslog.com/Downloads-index-req-getit-lid-18.phtml
As this is a serious vulnerability, we urge all users to update to the fixed version as soon as possible.
If you have turned on NO_BACKSLASH_ESCAPES in MySQL, you MUST make changes to your configuration file. Read DETAILS below to learn more. Continue reading “SQL Injection Vulnerability in rsyslogd”