Forwarding Windows Events via stunnel to a UNIX/Linux syslogd
Article created 2004-02-04 by
Windows Event Log data can securely be forwarded to a UNIX/Linux based syslogd via
stunnel. This article describes why and how this can be done. It is a
mini-howto that primarily focusses on the Windows side because there
are many good descriptions for the UNIX/Linux side.
The free stunnel project provides a way to
use ssl communication for any non-ssl aware client and server (daemon).
This is done much like a wrapper. Both on the client and on the server machine,
tunnel portals are created. The non-ssl aware client and server software is
configured to not directly talk to the remote partner, but to the local
(s)tunnel portal instead. Stunnel, in turn, takes the data received from the
client, encrypts it via ssl, sends it to the remote tunnel portal and that
remote portal sends it to the recipient process on the remote machine. The
transfer to the portals is done via unencrypted communication. As such,
it is vital that
the portal and the respective program that is talking to it are on the same
machine, otherwise data would travel partly unencrypted.
Tunneling, as done by stunnel, requires connection oriented communication. As
such, classical UDP-based
can not be used for tunneling. Consequently, you need to use a Syslog
implementation that supports TCP,
either non-standard raw TCP or one of the
newer standards like RFC
3195 (RFC 3195 supports encryption by itself, so it is
best to check first if your application supports this - if it does, this is
better than setting up a tunnel). Fortunately, Adiscon products support both
raw TCP syslog as well as RFC 3195, so you can talk to whatever you have on the
For this article, I assume that you run
on the UNIX/Linux side. It supports
raw TCP, only, so this is the mode of choice. I selected this scenario because
syslog-ng is quite common and chances are good that you will use it if you
think about securely transfering Syslog data to UNIX/Linux. Please note that the
stock syslogd does NOT support connection oriented (TCP) syslog, so you need to
replace it by something else if you would like to use stunnel.
As I wrote, I try not to duplicate the UNIX/Linux side howto's available. There is a
good one for syslog-ng at
I will use the settings from this tutorial while setting up the Windows side.
Please read through it, and understand how stunnel works before proceeding. If
you are more a UNIX/Linux-type admin, it may be a good idea to create a UNIX/Linux only lab
according to this howto - this will get you aquainted to the software.
I suggest that you set up your UNIX/Linux environment before proceeding.
You can fully utilize your stunnel knowledge on Windows, because there is an
excellent and fully equivalent port available. These are distributed as
- download your copy before proceeding. Copy the files to a location of your
choice. If in doubt what you need, download the latest stunnel binary as well as
the ZIP file with the openssl libararies. Place everything in the same
directory, e.g. c:\bin\stunnel. Please note that the stunnel binary (eg.
stunnel-4.04.exe) is the actual stunnel program and NOT a self-extracting exe
Once you have done this, you only need to supply stunnel with a correct
configuration file. You can use the one from the stunnel UNIX/Linux tutorial, step 5.
Make sure that you not only copy over the config file but also the needed .PEM
files. You probably need to change the pathes in the stunnel.conf file to
reflect your local Windows directory structure.
Once you have the config file ready, you can start the Windows stunnel. Please
note that it by default starts interactively. If all goes well, there is a
small icon in the icon tray. Double-Click it to get a status window. If
something goes wrong, the status window automatically appears with a nice error
Let's assume all went well. What is left is that we must tell the event log
monitor where to forward events to. This method applies to both the
EventReporter and the MonitorWare Agent
product. Both of them allow forwarding events via the
"forward syslog" action.
You need to configure this action to use TCP for the transport. Then, you must
set the address of the syslog server (receiver) to 127.0.0.1, the local
machine. This is important, because you will no longer directly talk to the
remote server but to the local stunnel portal instead! The port number must be
set to where the stunnel portal is listening, port 514 in this example.
Please note that it may be clever to change this port number to something
different form 514 (e.g. to 2514) because 514 may conflict with a syslog server
process running on the same machine. If you change it, make sure that you
change it both in EventReporter or MonitorWare Agent AND the client
stunnel.conf file. I am sticking with the default of 514 soley because I would
like to keep things as consistent with the UNIX/Linux tutorial as possible.
Once you have configured the event log monitor, you can restart the
EventReporter or MonitorWare Agent service and should see messages traveling
via the stunnel (assumed that the UNIX/Linux server part is already running...).
The remaining thing needed to do is to set stunnel to run non-interactively as
a Windows service. This can be done with "stunnel.exe -install". If in doubt,
see the stunnel documentation.
If you have sucessfully followed these steps, you have a logging system that
extracts Windows event log data and securely forwards it to a central syslog
daemon on UNIX/Linux. Please note that you could also transfer IIS logs,
other text files, database contents and a wealth of other important state
information if you use MonitorWare Agent. As the stunnel works in combination
with the "forward syslog" action, you can use it together with any data source
supported by the product.
If you can't find the links...
Don't worry! I am used to disappearing sites and information. As such, I have
cached a (PDF) copy of the UNIX/Linux
syslog-ng stunnel tutorial, the
stunnel windows binary, the
stunnel source and the openssl
binaries at the time of this writing. This material is kind of last
resort and most probably outdated. I strongly recommend visiting
www.stunnel.org to get it directly from the source.