How to process Syslog messages from Unix/Linux systems with non-standard formatting?

This article describes how to handle syslog messages from Unix/Linux systems that do not follow RFC 3164 standard formatting.

The Problem

Some Unix/Linux systems (historically Solaris 8/9, but also found in various Linux distributions) send syslog messages that deviate from the RFC 3164 standard. As an example, consider the following syslog message:

<38>Aug 2 11:49:23 su: [ID 366847 auth.info] su root succeeded for root on /dev/console

This message is missing the source hostname, which should appear before the syslog tag according to RFC 3164. A correctly formatted message would look like this:

<38>Aug 2 11:49:23 mymachine su: [ID 366847 auth.info] su root succeeded for root on /dev/console

When WinSyslog receives the first message, it treats the syslog tag value as the source hostname and does not continue parsing the syslog tag. This results in an empty syslog tag and an incorrectly parsed source. WinSyslog does not expect such non-standard messages and cannot handle them directly.

The Solution

The best approach to handle this problem is to disable RFC 3164 parsing in WinSyslog and implement your own preprocessing of the syslog message using the PostProcess action. The following steps explain how to do this:

Step 1: Reconfigure WinSyslog Settings

In your WinSyslog Server configuration, disable the following options:

• Use original message timestamp (RFC 3164)
• Take source system from Syslog message
• Enable RFC 3164 Parsing

Step 2: Create a PostProcess Action

Create a new rule in your main RuleSet and move it to the top of all rules. This is important because these actions will perform the RFC 3164 parsing that was previously handled by the built-in option.

In this rule, create a new PostProcess action with the appropriate template definition. You can download a predefined PostProcess template here. Use the Import Template button to load the predefined PostProcess template into your configuration.

The syslog tag will now be correctly set by the PostProcess actions, and the source will be taken from the network connection where the syslog message is received.

Important Notes

• Only messages with non-standard formatting will be affected by this configuration. If you have other syslog devices that send properly formatted messages, you may want to set up separate processing rules for them.
• This approach allows you to handle mixed environments where some devices send RFC 3164 compliant messages and others do not.
• Consider testing this configuration in a non-production environment first to ensure messages are parsed correctly.

Applicable Systems

This solution applies to:

• Legacy Solaris systems (Solaris 8/9/10)
• Modern Solaris systems (Solaris 11+ and OpenIndiana)
• Various Linux distributions with non-standard syslog implementations
• Custom or modified syslog daemons that do not follow RFC 3164 precisely