Forwarding Windows Events via stunnel to a UNIX/Linux syslogd

Article created 2004-02-04 by Rainer Gerhards.

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 syslog 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 UNIX/Linux side.

For this article, I assume that you run syslog-ng 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 http://www.stunnel.org/examples/syslog-ng.html. 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 binaries at http://www.stunnel.org/download/binaries.html – 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 program.

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 message.

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.