How To setup PIX centralized Monitoring with MonitorWare Console 3.x

How To setup PIX centralized Monitoring with MonitorWare Console 3.x

Article created 2005-05-17 by Hamid Ali Raja
Last Updated 2011-05-24 by Tom Bergfeld

Adiscon Products can be used to efficiently analyze PIX traffic as well. This article is strictly task focused. It does not describe why the systems should be monitored nor does it provide any further background. Please see the respective backgrounders or product documentation on this. This article is a step-by-step description of what you need to do in order to centrally monitor your PIX logs.

Centralized PIX Reports

In this step-by-step guide, WinSyslog is configured to work together with Adiscon’s MonitorWare Console to generate summaries for the traffic passing to and from PIX.

What you need

In this guide, I am focusing on building a solution with Adiscon’s WinSyslog and MonitorWare Console. This guide will be equally good for you if you want to configure MonitorWare Console with WinSyslog or to configure MonitorWare Console with MonitorWare Agent. The reason is that in this configuration a syslog server that will be listening for syslog messages is required. Since MonitorWare Agent and WinSyslog can act as syslog server, this guide can be used for both. The configuration steps are exactly the same in both cases.

This combination allows you to centralize all your logs and generate reports on them. Free 30 day trial versions are available at the respective product sites (links below), so you can try the system without the need to buy anything.

You need to run the following products:

  • 1 WinSyslog for the system that will act as the syslog server.
  • 1 MonitorWare Console to generate consolidated reports based on the gathered log data. This will also be installed on the same machine where you have installed WinSyslog.
  • You need administrative privileges on each of the machines. This is required in both cases, for installation and configuration. Make sure you log on with a sufficiently privileged user account.

    Step 1 – Download Software

    You need to download the following software to follow this step by step guide:

    1. www.winsyslog.com/en/download
    2. www.mwconsole.com/en/download

    Step 2 – Install WinSyslog

    Run the WinSyslog program on the system that is to act as the central server. Take a note of this server’s IP address or host name. You’ll need this value when configuring PIX to forward the messages to it.

    Step 3 – Configure a Syslog Server

    The steps to configure the WinSyslog as a syslog server are as follows:

    Configuring a Syslog Server

    Step 4 – Create a RuleSet for Database Logging

    In this section, you will create an action to write the messages that are coming from PIX to a database. Please note that these steps would be exactly the same for both MonitorWare Agent and WinSyslog.

    Database Logging Steps

    After configuring this RuleSet, make sure that

    • this rule set is associated with the syslog server service that you created in step 3. You can do this by clicking on the syslog server service on the left hand side and by selecting the name of the rule set that you created in step 4 in “Rule Set to Use” combo box on the right hand side.
    • The service is running. You can do this by clicking on the Play button at the top of the client.

    Step 5 – Configure PIX

    In this step, you will need to configure PIX in such a way so that it sends the messages to the syslog server that you created in the above step. You would need to give the IP address or the hostname in PIX.

    PIX Configuration Steps

    Step 6 – Installing and Configuring MonitorWare Console

    MWConsole- Installation and Configuration Steps

    Step 7 – Generating PIX Reports with MonitorWare Console Manually

    Following are the reports in MonitorWare Console that can be generated for PIX logs.

    • Accessed Web Sites Report
    • Blocked Ports Activity Report
    • Possible Attacks Report
    • PIX Summary By Message Type
    • PIX Summary by Severity Level
    • Traffic By Hour Report
    • Traffic By Port Report
    • Outbound Traffic By IP
    • Traffic by Target IP

    This section explains how the PIX reports can be generated with MonitorWare Console manually. In this section I will explain the generation of a specific report only. Please note that, the procedure for generating any report is almost the same.
    Generating PIX Reports with Console 3.0 Manually

    Step 8 – Scheduling the Generation of Reports with MonitorWare Console

    This section explains how the reports can be generated with MonitorWare Console automatically using Job Manager. With Job Manager, you can generate all the reports based on a pre-defined schedule and ask it to either store it in some location on the hard disk or send it to specified recipient via email. The following section explains the scheduling of System Status Report. You can use exactly the same method to generate any of the PIX reports that are mentioned above.

    Scheduling Reports with Console 3.0

    You are done!

    Well, this is all you need to do to configure the basic operations. We hope this article is helpful. If you have any questions or remarks, please do not hesitate to contact us at support@adiscon.com

Forwarding IIS Logs to a central File

Forwarding IIS Logs to a central File

Created 2004-04-02 by Timm Herget and Rainer Gerhards.

I would like to centralize IIS log files to a central log server. The files on that central server should be in the exact same format they are on the IIS machines.

This can be done with MonitorWare Agent 2.0 and above. Let’s look into the theory first: If you would like to forward IIS log files AND have them in the same format at the receiving machine, you need to make some special settings.

First of all, please note that the file monitor, when set to “W3C log files”, is optimized to extract the properties from each log line, not to forward the log literally. If you would like to forward them literally, you need to make sure that the format is set to “Standard”, which will disable all W3C-log specific handling (that would otherwise disturb the result). The syslog tag is not needed here, so it should be totally removed.

We must ensure that the send syslog action does not alter this message content. As such, we must make sure that the “Add Syslog Source when Forwarding” setting is NOT activated.

Unfortunately, that will not eliminate the tag as such from the syslog message, but we can handle this with the property replacer. As of RFC 3164, the syslog tag will be present in the so-generated message. In fact, the message will be “: <ORIGINAL line W3C>” with <ORIGINAL line W3C> literally being the line taken from the W3C log. Effectively, we end up with two extra characters (“: “) at the beginning of the line. Thankfully, we can eliminate these with the property replacer (it is capable of providing substrings of event properties). The message is in the “msg” property. So “%msg:3%” is everything from the third character position up until the end of the line (end position is not specified and so “end of line” is the default). To use the property replacer, we must just the “Write to File” action with “Custom” file format. Then, we can enter an arbriatary string that shall be written to the file. In our case, we use “%msg:3%%$CRLF%”: this instructs the write to file action to first write the original file line and then a Windows newline sequence. The later is needed because it was stripped out by the file monitor.

This looks in the dialogs as follows:

1. Sender : Forward Via Syslog Settings

The “Add Syslog Source when …”-Checkbox MUST be unchecked.

Figure 1: Forward Syslog Action Settings

2. Sender : File Monitor Service Settings

Please note that the “Syslog Tag Value” Field MUST be empty (not even a space in it).

Figure 2: File Monitor Service Settings

3. Recipient: Syslog Listener Settings

Please note that the “Enable RFC 3164 Parsing” MUST be checked

Figure 3: Syslog Listener Service Settings

4. Recipient: Write to File Action Settings

The “File Path Name” Directory must be available, MonitorWare Agent will not create it if its not present.

The “File Format” MUST be set to “Custom”. The following custom line format MUST be used:

%msg:3%%$CRLF%

Figure 4: Write to File Action Settings

With the above settings the recipient MonitorWare Agent  will successfully generate exact the same logfiles as the original ones are.

Sample Configurations

We have created some registry files for both the sender and the recipient server. If you download them, simply import them into the registry on the machine in question (if you system is a default-install, double-clicking the file is sufficient to do this). Be sure that the MonitorWare Agent client is closed while you do this. Please note that the sample configurations MUST be customized in order to make them work for you.

Sample configuration for MonitorWare Agent 2.0

Please note: samples may not work with versions other than the one specified in the download link!