MonitorWare Agent 7.2 Released (Build-IDs: Service 7.2.0.398, Client 7.2.0.1322)

MonitorWare Agent 7.2 Released

Release Date: 2010-08-02

Build-IDs: Service 7.2.0.398, Client 7.2.0.1322

New Additions

  • Syslog Server
    – Added support for Syslog TLS (RFC 5425). It is possible to use the following modes: anonymous, x509name and x509fingerprint authentication. Note that this requires a valid server certificate as well. More details can be found in the manual.
  • Forward Syslog Action
    – Added support for Syslog TLS (RFC 5425) using your own certificate and
    keyfile, or the anonymous mode. When using the anonymous method, no client
    certifcate is needed.
  • Send Mail Action
    – Added support for STARTTLS command. This extension is required for SMTP Servers which can optionally enable encryption during communication.
  • Updated OpenSSL Components to v1.0.0 for more SSL/TLS stability

Bugfixes

  • Send Mail Action
    Fixed time issue in when “Use UTC Time” option was disabled
  • Property Engine
    Added property replacer option “replacepercent”. This option replaces all % occurrences with %%, which is needed in case that a string is reprocessed using the property engine.

You can download Free Trial Version of MonitorWare Agent.

2010-08-02 MonitorWare Agent 7.2 released

Adiscon is proud to announce the 7.2 release of MonitorWare Agent. This is a minor release including some a new feature and minor bug fixes.

As a very important enhancement, this release offers support for native and standards-compliant secure syslog transport via SSL/TLS. Based on RFC5425, MonitorWare Agent now permits sending and receiving of messages in a secure way. All RFC5425 authentication modes are supported, so messages can not only traverse the network encrypted but clients and server can also authenticate each other. Among others, this provides a reliable safeguard against man-in-the middle attacks. Note that this type of authentication is much stronger than IP-based authorization modes (as, for example, are usually found in firewalls). Of course, both can be used together for even stronger security.

The “Send Mail” Action was improved again, and now supports the STARTTLS command. This means the connection to a mailserver can be secured during transmission, if the mailserver supports it.

For more details read the version history

Version 7.2 is a free download. Customers with existing 6.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

Monitoring DHCP Logfiles

Monitoring Windows 2003 DHCP Server Logfiles via syslog

Created 2007-10-10 by Florian Riedl

Information for the usage of this guide. This guide will give you the hints to create a configuration to monitor Windows 2003 DHCP server logs as well as forward all log data to a syslog server. To make things easier, the guide is split up into several mini-guides, which will each cover one big step of the configuration. These mini-guides only describe the general procedure. You may have to adjust settings like IPs or pathnames to your personal needs.

Please note: In order to forward the DHCP logs you need MonitorWare Agent.
Further you need to setup your DHCP server to log into text files. Please review the manual for further instructions.

Step 1

The first step we are going to take is to create a RuleSet with the corresponding action. In this case we want to forward our logs via syslog. Therefore we need a “Forward via syslog”-Action. Instructions on how to create a ruleset and setup the action can be found here:

How to Setup a Forward via Syslog Action

Please Note: You have to edit the IP address of the syslog server. By default it is set to 127.0.0.1. If you do not change this, your syslog server will not receive any data.

Step 2

The next important step is to setup the FileMonitor. We need it to monitor the text file logs created by your DHCP server.

How to Setup the FileMonitor Service

Please Note: This is a general guide, you may have to alter the path- and filename. The default path and filename is “C:\WINDOWS\System32\dhcp\DhcpSrvLog-Fri.log”. The last 3 letters of the filename represent the day on which the log was created. You can use wildcards for the filename.

Step 3

The last and final step is to click on the Save button if necessary and then start MonitorWare Agent. You are now done. Finally you should receive all the log entries of your DHCP Firewall on your syslog server.

If you want, you can download the sample configuration file. Extract the .reg file to the machine where MonitorWare Agent is installed and execute it before opening MonitorWare Agent.

Monitoring MS ISA Firewall Logfiles via syslog

Monitoring MS ISA Firewall Logfiles via syslog

Created 2007-04-02 by Florian Riedl
Information for the usage of this guide. This guide will give you the hints to create a configuration to monitor ISA server logs as well as forward all log data to a syslog server. To make things easier, the guide is split up into several mini-guides, which will each cover one big step of the configuration. These mini-guides only describe the general procedure. You may have to adjust settings like IPs to your personal needs.

Please note: In order to forward the ISA Firewall logs you need MonitorWare Agent.
Further you need to setup your ISA server to log into textfiles. Please review the manual for further instructions. Important: Please ensure that the log format will be W3C logfile format. This is for compatibility reasons.

The scenario looks like this. The configuration we are going to make represents the first machine on the left side.

Step 1

The first step we are gonna take is to create a RuleSet with the corresponfing action. In this case we want to forward our logs via syslog. Therefore we need a “Forward via syslog”-Action. Instructions on how to create a ruleset and setup the action can be found here:
How to Setup a Forward via Syslog Action
Please Note:This is a general guide, you may have to adapt some steps.

Step 2

The next important step is to setup the FileMonitor. We need it to monitor the textfile logs created by your ISA server.
How to Setup the FileMonitor Service
Please Note:This is a general guide, you may have to alter the path- and filename.

Step 3

The last and final step is to click on the Save button if necessary and then start MonitorWare Agent. You are now done. Finally you should receive all the log entries of your EventLog as well as from your ISA Firewall on your syslog server.

How to process Syslog messages from Solaris 8/9 systems?

How to process Syslog messages from Solaris 8/9 systems?

Created 2006-03-15 by Andre Lorbach.

This article describes how to workaround problems which occur when you are receiving and processing Syslog messages from Solaris 8/9 systems.

  • The Problem: The problem exists in the way, the Syslog messages are formatted from Solaris 8/9. As an example, we take the following sample Syslog message:
<38>Aug  2 11:49:23 su: [ID 366847 auth.info] ‘su root’ succeeded for root on /dev/console

This message is missing the source, which has to be before the Syslogtag, as it is defined in RFC3164. So correctly, the Syslog would have to look like this:

<38>Aug  2 11:49:23 mymaschine su: [ID 366847 auth.info] ‘su root’ succeeded for root on /dev/console

In the first message, our Syslog Server treats the SyslogTag value as Source, and doesn’t continue to parse the SyslogTag Value. This will result in an empty SyslogTag, and wrong parsed source. The problem is that our Syslog Server does not expect such a message, and so it can’t be handled directly.

  • The Workaround: The best way to workaround this problem is to disable RFC3164 Parsing in the Syslog Server, and implement your own preprocessing of the Syslog message with the help of the Postprocess Action. The following steps explain and show how this can be done.

1. Reconfigure your Syslog Server configuration and disable the following options:

  • Use original message timestamp (RFC 3164)
  • Take source system from Syslog message
  • Enable RFC 3164 Parsing

2. Create a PostProcess Action for preprocessing the Solaris Syslog messages:

First create a new Rule in your Main RuleSet and move it on top of all Rules. This is important as these actions will do the job of the “Enable RFC 3164 parsing” option of the Syslog Server. In this Rule, create a new PostProcess Action with the following template definition like in screenshot below. You can download the predefined PostProcess template from here. Use the Import Template button to load the predefined PostProcess template into your configuration.

The SyslogTag will now be correctly set by the PostProcess Actions, and the source is taken from the network connection from where the Syslog message is received. Please note that only “wrong” formatted messages will now be correctly parsed. So if you have other Syslog devices, you should let them send their logs to another Syslog Server where normal processing is used.

MonitorWare Agent as Syslog and SETP Server

MonitorWare Agent as Syslog and SETP Server

Created 2003-04-04 by Wajih-ur-Rehman.

If I am forwarding the data from different MonitorWare Agents via SETP to a central MonitorWare Agent acting as a SETP Server, will I be able to send Syslog messages to this central server too?

Yes you will be able to send the Syslog Messages to the same MonitorWare Agent as well. The reason is that MonitorWare Agent has the capability of acting as a Syslog Server as well as the SETP Server simultaneously. So not only your Windows machines can forward the events via SETP protocol but also any other machine that generates syslog messages can forward the data using Syslog. Both kind of messages (SETP and Syslog) will be picked up by the Central MonitorWare Agent (but obviously you would need to configure it in such a way that it can do this)