How To setup the Forward via Syslog Action
This Guide is for the RSyslog Windows Agent.
1. First we define a new rule set. Right-click “Rules”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:
2. Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Forward syslog” in this example. The screen looks as follow:
Click “Next” to go on with the next step.
3. Select only Forward via Syslog. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.
4. As you can see, the new Rule Set “Forward syslog” is present. Please expand it in the tree view until the action level of the “Forward syslog” Rule and select the “Forward syslog” action to configure.
5. Configure the “Forward via Syslog” Action
Type the IP or the Hostname of your syslog server into the Syslog Server field in the form. Then Change the protocol to “TCP (octet-count based framing”. We use TCP that we will have no traffic lost. And edit the Port to 10514. Attention RSyslog Windows Agent and rsyslog must use the same port and the same protocol.
6. Finally, make sure you press the “Save” button – otherwise your changes will not be applied. Then start the service and you are done.
rsyslog statistics counter
Rsyslog supports statistic counters via the impstats module. It is important to know that impstats and friends only provides an infrastructure where core components and plugins can register statistics counter. This FAQ entry tries to describe all counters available, but please keep in mind that there may exist that we do not know about.
When interpreting rsyslog statistics, please keep in mind that statistics records are processed as regular syslog messages. As such, the statistics messages themselves increment counters when they are emitted via the regular syslog stream, which is the default (and so counters keep slowly increasing even if there is absolutely no other traffic). Also keep in mind that a busy rsyslog system is very dynamic. Most importantly, this means that the counters may not be 100% consistent, but some slight differences may exist. Avoiding such inconsistencies would be possible only at the price of a very tight locking discipline, which would cause serious performance bottlenecks. Thus, this is not done. Finally, though extremely unlikely, some counters may experience an overflow and restart at 0 for that reasons. However, most counters are 64-bit, so this is extremely unlikely. Those which are not 64 bit are typically taken from some internal data structure that uses lower bits for performance reasons and guards against overflow.
The listing starts with the core component or plugin that creates the counters and than specifies various counters that exist for the sub-entities. The listing below is extended as new counters are added. Some counters probably do not exist in older releases of rsyslog.
Below you can find all available core components and plugins. Please note that every core component or plugin are linked to a information site.
Queue
Actions
PLUGINS
LogTools 0.1.0 Released
We are happy to announce the initial public release of LogTools. This package aims at providing useful tools for log file manipulation and processing. The initial release focuses on a core ingredient, the tamper-proof log store. Besides that, the well-documented format is designed for long-term archiving. Both features together make it very useful for storing both valuable audit information as well as log files potentially meant as evidence in court.
Both the source tarball and an experimental Debian package are available via the LogTools download page.
The log store is tamper-proof by using a chain of hashes. This provides tamper protection if the last hash of the hash chain is regularly saved. In upcoming releases, the hash chain will become protected by digital signatures using strong cryptography. With that, it is no longer necessary (but still beneficial) to keep hashes in a separate location (that would guard even against a compromised key).
The log store is long-term-archival-friendly because its documented format is designed to remain easy to read and interpret even in many years: it is text-based, clearly documented (in the man page or, for example, here) and easily extensible. To support extensibility, it supports different record types and a cryptographic field that can be extended by type specifiers as well (this is not used initially because it is not needed – but the capability is already present). It is our pledge that this format will remain readable while it is being extended in the future.
So LogStore format is a perfect solution for tamper-protected texttual data that must last. And note that we say “textual data”, not “syslog messages” or even “log messages”. No matter what it is, if it is in text format, LogStore can protect it!
LogTools are also a good Linux citizen, following the Unix tradition of small tools that do one job and do it well. With the initial release, two filter-type programs (logreader and logwriter) have been released. They permit to create and read log stores (including a functionality to extract the last used hash for easy transmission). These tools can perfectly be used inside processing pipes. That, among others, means that LogStore data is perfectly “greppable”. Integration with other tools is simple. For example, to make rsyslog write LogStore format, rsyslog’s omprog output module can be utilized. All tools that can emit data to stdout can also be used to write LogStore format. So immediately there is a myriad of options available.
LogTools is an active project that will be further extend with new tools with the same philosophy. One of the next steps planned is to integrate liblognorm techology for easy normalization of incoming semi-structured data. We also appreciate suggestions, so please make yourself heard.
rsyslog 5.9.4 (v5-devel)
Download file name: rsyslog 5.9.4 (devel)
rsyslog 5.9.4 (devel)
md5sum: 408f59536a10f34a73e3af000ca81639
Author: Rainer Gerhards (rgerhards@adiscon.com)
Version: 5.9.4 File size: 2.382 MB
rsyslog 5.9.4 (devel) released
This release provides support for “trusted properties”, which may enhance overall system security. This is a new concept and feedback on it is appreciated. For more details on trusted properties, please visit
http://www.rsyslog.com/what-are-trusted-properties/
or Rainer’s blog post with some more background about trusted properties:
http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
In addition to this feature, we have reduced dependency on libgcrypt and fixed some bugs.
ChangeLog:
http://www.rsyslog.com/changelog-for-5-9-4-v5-devel/
Download:
http://www.rsyslog.com/rsyslog-5-9-4-devel/
As always, feedback is appreciated.
Best regards,
Florian Riedl
Changelog for 5.9.4 (v5-devel)
Version 5.9.4 [V5-DEVEL], 2011-11-29
- imuxsock: added capability to “annotate” messages with “trusted information”, which contains some properties obtained from the system and as such is sure to not be faked. This is inspired by the similiar idea introduced in systemd. removed dependency on gcrypt for recently-enough GnuTLS
see: http://bugzilla.adiscon.com/show_bug.cgi?id=289 - bugfix: imuxsock did no longer ignore message-provided timestamp, if so configured (the *default*). Lead to no longer sub-second timestamps.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=281 - bugfix: omfile returns fatal error code for things that go really wrong previously, RS_RET_RESUME was returned, which lead to a loop inside the rule engine as omfile could not really recover.
- bugfix: rsyslogd -v always said 64 atomics were not present
thanks to mono_matsuko for the patch
What are “Trusted Properties”?
Rsyslog can annotate messages from system log sockets (via imuxsock) with so-called “Trusted Properties”. These are message properties not provided by the logging client application itself, but rather obtained from the system. As such, they can not be faked by the user application and are trusted in this sense. This bases on the similar idea introduced in systemd.
The following trusted properties are available:
_UID | The userid under which the logging process is being executed. |
_GID | The group id under which the logging process is being executed. |
_PID | The PID of the logging process. Note that this PID, if configured, is also put into the syslog tag. |
_EXE | Path to the binary that is logging |
_COMM | The name (as visible by top) of the logging process. |
_EXE | The full command line of the logging process. Note that this string can contain spaces, thus it is always provided in quoted form. |
Property names are deliberately based on property names in the systemd proposal. Additional properties can be added upon request. User- and Group-IDs as well as the PID are obtained via SCM_CREDENTIALS and as such should be always available on a relatively recent Linux system. The other properties are obtained from the /proc virtual file system. Note that this can be somewhat racy. Most importantly, these properties can not be obtained if the process has already been terminated when the message is being processed by rsyslogd. This can occur for very quick processes (logger being a prime example) and has happened in practice (for the same reason, it is theoretical possible that invalid information is reported, if the PID are reused extremely quickly – this is so unlikely we did not care about this case).
All annotations are currently (Nov 2011) placed at the end of the message, starting with ” @[” (the first character being a space). The annotation is ended with “]”. This is done to keep consistent with legacy syslog implementations. However, the format will probably changed and is intended to be moved over to a RFC5424 structured data item. Also, the property names were currently chosen for best fit with systemd. As systemd does not follow the relevant standards, we may at later time change to standard names, once they become fully available. So please be prepared for some future change if you begin to use this feature. You may guess that we will preserve legacy format when doing changes, but we do not promise that ;)
A sample of a message with trusted properties looks as follows:
2011-11-29T16:57:13.634852+01:00 testhost su: pam_unix(su-l:session): session opened for user root by examp(uid=677) @[_PID=5933 _UID=0 _GID=677 _COMM=su _EXE=/bin/su _CMDLINE="su - "]
The annotation is given in boldface. Note that this is all on one line. It is broken across several lines just for readability.
This feature is available starting with version 5.9.4 in the v5 rsyslog branches.
First Impression of Journald
We got a couple of questions on the planned new logging system that shall come with systemd. Rainer Gerhards, rsyslog’s development lead, has taken a quick look at journald and posted about his first impression. Have a look at his blog post journal and rsyslog if you are interested in how we think rsyslog is affected. In the mean time, there is also a description of why we think journald’s log chaining is simply broken and conveys a false sense of security.
How to setup rsyslog to get Event Logs from a second maschine
The Article is applicable to all versions of EventReporter, MonitorWare Agent and rsyslog.
1. Configure EventReporter with a Service “Eventlog Monitor Service”.
Attention if you use Windows Vista or Windows 7 skip to step 1.2.
First, right click on “Services”, then select “Add Service” and then “Event Log Monitor”:
Once you have done so, a new wizard starts.
If the following Pop-up appears, please select “Create Service”:
Again, you can use either the default name or any one you like. We will use “My Event Log Monitor” in this sample. Leave the “Use default settings” selected and press “Next”.
As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
Now, you will see the newly created service beneath the “Services” part of the tree view. To check its parameters, select it. Click on Advanced Options then select “Use Legacy Format” :
1.2 Configure EventReporter with a Service “Eventlog Monitor Service 2”.
Note: This guide explains how to set up the EventLog Monitor Service for Windows Vista. These steps are not applicable if you are using Windows XP.
First, right click on “Services”, then select “Add Service” and then “Event Log Monitor V2”:
Once you have done so, a new wizard starts.
If the following Popup appears, please select “Create Service”:
Again, you can use either the default name or any one you like. We will use the default name in this sample. Leave the “Use default settings” selected and press “Next”.
As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
Now, you will see the newly created service beneath the “Services” as part of the tree view. To check its parameters, select it:
As you can see, the service has been created with the default parameters.
2. Add a “Forward via Syslog” Action.
First we define a new rule set. Right-click “Rules”. A popup menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:
Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Forward syslog” in this example. The screen looks as follow:
Click “Next” to go on with the next step.
Select only Forward via Syslog. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.
As you can see, the new Rule Set “Forward syslog” is present. Please expand it in the tree view until the action level of the “Forward syslog” Rule and select the “Forward syslog” action to configure.
3. Configure the “Forward via Syslog” Action.
Now, we are going to configure the necessary settings for forwarding via syslog. Type the IP or the hostname of your syslog server into the Syslog Server field in the form. Then Change the protocol to “TCP (octet-count based framing”. We use TCP that we will have no traffic lost. And edit the Port to 10514. Attention EventReporter and rsyslog must use the same port and the same protocol.
4. Configure Event Log Monitor which Rule to use.
Then Left-Click on Event Log Monitor then change “Rule Set to Use” to your Rule set. On the screen, it looks as follows:
5. Setup rsyslog for TCP reception
Now, we are going to configure the necessary settings for the TCP reception. Because EventReporter forward via syslog over a TCP connection so rsyslog must reception TCP.
Then open the rsyslog configuration. The normal path is “/etc/rsyslog.conf” and copy and paste this code into the Configuration.
Use this code for the TCP Syslog reception:
# Provides TCP Syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 10514
If you use a UPD connection then use this code:
# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 10514
Please restart rsyslog afterwards.
6. Test rsyslog
First switch to your Unix machine then open a new command prompt under Unix then type “tail -f /var/log/syslog”. With this command you now see all log messages which rsyslog receive.
Then open a new command prompt and write “logger test 1231”. Then you must see the message in the first command prompt.
On the screen, it looks as follows:
7. Verifying the configuration of rsyslog and EventReporter
First open a new command prompt under Unix then type “tail -f /var/log/syslog”.
Then switch to the second machine and start EventReporter. Then switch to your Unix machine and watch the command prompt there you see the incoming “Eventlogs” in the command prompt.
On the screen its look like:
If nothing arrive then check your EventReporter and rsyslog configuration if both use the same port and if both use the same protocol.
That’s it. This is how to receive syslog data from another device.
rsyslog client for Windows
As it currently looks, Adiscon will most probably create a specialised Windows client for rsyslog. This will be based on Adiscon’s MonitorWare technology and provide excellent and high speed integration of Windows clients into a rsyslog infrastructure. While the idea has somewhat matured, we are currently thinking about the details. Expect more information as discussions progress!
In the mean time, you may want to have a look at Adiscon’s EventReporter, which provides excellent Windows-to-rsyslog event log forwarding.