“A complete description of common uses of the MonitorWare line of products. – Analysis

Common uses

Article created 2003-05-14 by Rainer Gerhards.

Updated 2004-06-21 by Tamsila-Q-Siddique.


If you are interested in receiving a consolidated view of your overall system
state and activity, you are probably interested in the analysis features of the MonitorWare system.

Please note that this chapter is currently being expanded. As such, the examples and uses given herein do only reflect some of the things that can be done with MonitorWare.

The MonitorWare Agent itself provides the necessary data-gathering facilities to supply event data for analysis. The MonitorWare Agent
itself does not include any analysis feature. As such, it is always teamed up with either other members of the Adiscon MonitorWare line of products or
third party solutions. MonitorWare Agent is also often used to integrate Windows-based event data like Event Log data or IIS log files into UNIX based management solutions.

Centrally Monitoring Windows Event Log Data

In this scenario, you are primarily interested in consolidating Windows Event Log data into a single system. Also, a scheduled overall system activity report should be automatically generated and provided for your review.

This scenario is so common that we have created a dedicated step-by-step
guide covering all steps necessary. Please find it at “Centralized Event
Reports with MonitorWare Console”

After following the step-by-step guide, you are encouraged to configure your Windows system to supply as many security related and audit information as needed. This is detailed in
“Configuring Windows for the Event Log Monitor”
Please note that in default configuration Windows supplies only limited
information and also runs the risk of event loss due to filled-up log
files. Follow the guide to resolve this.

The scenario described can easily be extended to include non-Windows
event data, for example Cisco router logs. These events will also become
part of the MonitorWare Console overview report.

Delivering Windows Event Data to UNIX based Management Solutions

In this scenario, Windows Event data is “just” to be forwarded to a
UNIX based management solution. Most often, the UNIX based solution is
already in operation but lacking Windows event information.

In this scenario, MonitorWare Agent is simply configured to forward
captured events via syslog to a central, UNIX based server. There, the
data is stored and further processed. Most often, customer scripts will
parse the gathered data and perform the actual analysis. The key point
here is that MonitorWare Agent enables these scripts and applications to
process Windows events, which are otherwise unavailable to them.

Please note that “Windows Events” does not only include Windows event log data but also text files like IIS log files.

Delivering Windows Event Data to Windows based Third-Party solutions

In this scenario, Windows event data (including event log data as well as
text files and other supported sources) is delivered to a central
Windows loghost and stored there for further analysis. In contrast to
other scenarios, the analysis part is done by third party software and
– most often in this scenario – customer developed scripts.

This scenario is not very common, but there are a number of customers with very specific needs that have great success with it. In general, it can
be combined with Adiscon’s analysis tools described in
Monitoring Windows Event Log Data”
If used without any Adiscon analysis software, events can be written to
whatever source the custom scripts supports, for example text files or
the database.

Delivering Windows Event Data to Third-Party Solutions

There are a number of third party “black boxes” out that can receive and
process Windows events. A popular example is the Counterpane Sentry, a
device that receives Windows event log data via syslog and stores and
processes it. The Sentry is part of Counterpane’s services offering.
For more information, please visit the Counterpane web site at

Forwarding Windows Events via stunnel to a UNIX/Linux syslogd

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