Creating a simple Syslog Server

Wednesday, May 25th, 2011

Step-By-Step Guides

Article created 2005-05-17 by Hamid Ali Raja
Article updated 2011-05-25 by Tom Bergfeld.

Creating a simple Syslog Server

In this scenario, a simple Syslog server will be created. No other services are configured. The Syslog server will operate as a standard Syslog server on the default port of 514/UDP. All incoming data will be written to a single text file.

Step 1 – Defining a Rule Set for File Logging

The rule set specifies what action to carry out. You might be tempted to define the service first, but starting with the rule set makes things easier as it will be already present when the service is defined later and needs to be bound to a rule set.

To define a new rule set, right click "Rules". A pop up menu will appear. Select "Add Rule Set" from this menu. On screen, it looks as follows:

Then,a wizard starts. Change the name of the rule set to whatever name you like. We will use "Write Syslog Log File" in this example. The screen looks as follows:

Click"Next". A new wizard page appears:

screenshot

There,select file logging. Do not select any other options for this example. Also, leave the "Create a Rule for each of the following actions" setting selected. Click "Next".

This is just a confirmation page. Click "Finish" to create the rule set.

The wizard closes and the client shows a newly created rule set.

As you can see, the "Write Syslog Log File" rule set is now present. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a "File Logging" action configured. We will review the settings just for your information. Click on "Filter Conditions":

As you can see, none of the filter conditions are enabled. This means that the all information units (incoming messages) will be matched by these filter conditions. As such, the rules for the "File Logging" action will always be carried out.

Please note that this also means that all Syslog priorities and facilities will be written to the same file.

Now let us check the "File Logging" action itself. Please select it in the tree view:

As you can see, it has been created with the default parameters. Each day, a file will be created in the C:\temp directory and its base name will be MonitorWare. It will include all information items in the file.

If you would like to store it into a separate directory or change the file name, here is the place to do it. Important: please make sure the directory you specify exists! If it does not yet exist, please create it before you start the service. If the directory does not exist, the service is not able to store any files.

In our example, we would like to save it to "c:\logfiles" with a base name of "Syslog". Therefore, we change these properties:

After doing so, you will notice the yellow text on top of the window. It tells you that the configuration changes have not yet been applied. To do so, press "save".

Now you have a workable rule set for logging incoming messages to a text file.

Step 2 – Create a Syslog Server Service

Now we need to define a Syslog server service. A Syslog server is also sometimes called a "Syslog daemon", "Syslogd" or "Syslog listener". It is the process that receives incoming messages.

To define it, right click on "Services", then select "Add Service" and the "Syslog Server":

screenshot

Once you have done so, a new wizard starts:

Again, you can use either the default name or any one you like. We will use "My Syslog Server" in this example. Leave the "Use default settings" selected and press "Next":

As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press "Finish" to create the service. The wizard completes and returns to the configuration client. There, you will see the newly created service beneath the "Services" part of the tree view:

To check its parameters, select it:

screenshot

Please note that since WinSyslog v11.x and MonitorWare v8.x IPv6 is supported.
As you can see, the service has been created with the default parameters. As such, it operates as a RFC compliant standard Syslog server.

Please note that the "Write Syslog Log File" has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. By default, the wizard will always assign the first rule set visible in the tree view to new services. If another one is to be used, you need to change it to the correct one here in the service definition.

Also, note that the wizard uses the default properties from the "Service Defaults". Obviously, if these are changed, the default properties for new services will differ.

This procedure completes the configuration of the Syslog server.

Step 3 – (Re-) Start the Service

Application cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our example, the service was not yet started, so we simply need to start it. If it’s already running, you need to restart it.

Service control can be done with both the respective operating system capabilities (like service manager MMC) or with the configuration client. These are shown in the red surrounded area in the following screen shot:

The buttons resemble Windows service manager – start, stop and restart. In this example, stop and restart are grayed out because the service is not running.

After service restart, the new definitions are active and application is ready to accept and store incoming messages.

Step 4 – Configure your Syslog-Enabled Devices

Even though application is now ready, it can only receive messages if some devices send them. Remember, Syslog is a protocol where the server is passively waiting for incoming messages. As long as no device sends message, the Syslog server will not log anything.

Since there are a large variety of devices, we unfortunately cannot provide device specific instructions. However, almost all devices need to be configured with their specific configuration tool. Typically, only two settings need to be made: one to activate Syslog messages at all and one with the Syslog server IP address or name.

For some devices, we have step-by-step guides. Please read "Sample Syslog Device Configurations" for further details.

Remember: the computer running application now acts as a Syslog server. As such, you need to find out its IP address or name and supply it to the device as the Syslog server. Please note that not all devices can operate with computer names. Use the IP address, if in doubt.

Centralized logging in a hybrid environment (Windows/Linux) – Step 4

Friday, March 11th, 2011

Step 4 – Setting up the Linux Clients

We still need to implement the Linux clients into our logging network. This could be Linux workstations or servers. Currently, rsyslog is already shipped with many Linux Distributions as the default syslog daemon already. Though, often a rather old version is installed (mostly v3), this will be sufficient for our current goals.

For our example we will use a Fedora system and alter the configuration accordingly. In the end, rsyslog should use the logs, that are logged locally and forward them via TCP to the central log server.

Please note: The example has been made with Fedora 13. Some steps may vary with other Linux distributions. Since there are so many possibilities, we cannot list them all. So we only concentrate on one version.

Step 4.1:

First of all, we need a terminal or command line and go into root mode with su. We do not need the root rights desperately, but it is a bit easier to achieve our goals.

Step 4.2

We need to alter the configuration accordingly. We will use the vi text-editor to do so. If you are not familiar with vi, you should consider getting some knowledge first with the vi man page.

You can find the default configuration file in

/etc/rsyslog.conf

This configuration file will be loaded once rsyslog is started.

Open the configuration file by the following command:

vi /etc/rsyslog.conf

Your terminal should look like this:

centralized_monitoring_4001

Step 4.3

Under the header "#### MODULES ####" you can see the loaded modules. The ones we need are already loaded. For sending syslog, we do not need a extra module to be loaded. Basically, the imuxsock.so is listening to the local log socket and imklog.so provides the support for kernel logging. More is currently not needed.

When going further down in the configuration, we see parts that are called UDP and TCP syslog reception. They are uncommented. We don’t need them, so we leave them that way. As you can see, there is the command to load a module (introduced my $ModLoad) and then a specific command that is given to the module which tells it to run as a syslog server on a specific port.

Step 4.4

When scrolling further down in the configuration file, we will find the header "#### RULES ####".

centralized_monitoring_4002

Here, some rules are defined about which logs are stored in which location. These rules have a basic format. Basically, this looks like this:

facility.severity storage_location

The facility roughly determines, what has generated the log message. The severity tells you, how urgent the message is. And the storage location determines, where to store the logs. In the default config, there are several rules for some important log files. They will all be stored in the folder /var/log.

We need to add another rule for forwarding all log messages via TCP syslog. For now, go to the last of the rules and insert the following:

*.* @@central_server:10514

This rule means that all messages, no matter the facility or severity, will be forwarded via TCP to the central server on port 10514. We need to choose port 10514, since our central server will listen to TCP syslog on this port.

In the configuration file, this should look like this:

centralized_monitoring_4003

You can now save and quit vi.

Step 4.5

Now that we have altered our configuration according to our needs (which hasn’t been too much), we still have one more thing to do. We need to restart the service.

Now that we are back on the command line, we can easily use the following command:

service rsyslog restart

This will tell the rsyslog service to stop and start again. Thus, the configuration will be loaded with the changes we made.

centralized_monitoring_4004

Step 4 – finished

We are now finished with setting up rsyslog correctly. It will take all the logs it receives and forwards them to our central log server via TCP on port 10514. In addition to that, the default log rules still exist and will log messages to the local harddrive.

Though, there could be many more scenarios and configurations. We decided to keep it simple for a basic setup.

<< Go back to the main page

Centralized logging in a hybrid environment (Windows/Linux) – Step 3

Friday, March 11th, 2011

Step 3 – Setting up the other Windows Servers

We already have the central server and the regular Windows clients set up. We now need to set up the other Windows servers. We assume, that we have other Windows 2008 Servers. On these servers we want to monitor the local Event Log and textfile-based log files. The log messages shall be transferred to the central server via TCP again.

To achieve this, we need MonitorWare Agent installed on those servers. This is simply because it is able to monitor textfiles in addition to the regular Event Log. In addition to MonitorWare Agent, we need nothing to be installed. Since we want to monitor textfile-based log files, we assume there is an IIS running.

Step 3.1

First, we will set up the ruleset. By doing this, we can create the services and they will automatically bound to the ruleset.

centralized_monitoring_1002

Right-click on RuleSets in the left hand list. A context menu will appear. Click on Add RuleSet

centralized_monitoring_3001

The RuleSet Wizard will appear now. You can give your ruleset a name of course. We will use TCP Forwarding for this example. After that, click on "Next".

centralized_monitoring_3002

On the second page of the wizard we can specify what actions we want. Since we only want the log messages to be forwarded via syslog, check the box next to "Forward Syslog". After that, click "Finish" to create the ruleset and action.

Step 3.2

centralized_monitoring_3003

When you expand the treeview now, you will find a rule named "Forward Syslog" with an attached action of the same name.

centralized_monitoring_3004

Now click on the action "Forward Syslog. You can see the default values now.

centralized_monitoring_3005

We need to change some of those settings now. First of all we need to enter the IP or hostname of our central server into the field "Syslog Server". After that, change the port to 10514, since our central server will listen to syslog on this port. And we need to change the protocol type. Change is to TCP (persistent connection). That is all for now. Click on the Save button on the top so we can go on configuring the Service itself.

Step 3.3

Currently, when clicking on Configured Services you will not see a thing. But we will configure the services now. Without them, MonitorWare Agent is not able to get any log messages. We will setup 1 EventLog Monitor and 1 File Monitor.

centralized_monitoring_3009

When right clicking on Configured Services a context-menu will open. By moving your cursor to "Add Service" you can see a list of Services, that may be configured. The list seems pretty long, but we basically need 2 services of them.

centralized_monitoring_3006

Click on "EventLog Monitor V2″ first. The Services Wizard will open. Simply click on Finish for now. Repeat this again for the File Monitor.

centralized_monitoring_3010

In the end, you should have a list with 2 Services. For our example I renamed the services by doing a right-click on the Service name I wanted to change and the choosing "Rename Service".

Step 3.4

Settings for Event Log Monitor V2

centralized_monitoring_3007

The Event Log Monitor V2 needs no additional setup. Again the default values are ok. If you want specific Event categories not to be stored, you can disable the options. But the basic format is sufficient.

Step 3.5

Settings for File Monitor

centralized_monitoring_3008

The File Monitor needs some additional settings. First, enable the option "Allow Directories or read multiple files". You will see, that the use of wildcards will be automatically enabled and some other options completely being disabled.

Then we need to set the source files. For our example, we want to monitor the IIS logfiles. At the top of the File Monitor configuration you can see the option "File and path name". There is a Browse button right next to it. Click it.

A windows explorer window will open, where you can choose the file you want to monitor. Navigate to the path C:\inetpub\logs\LogFiles\W3SVC1\. This is the location where the log files are stored. Please note, that the file location could be different when using another version of IIS. Choose the first file in the list. (Note: Daily Internet Information Server log files are  named  “u_exyymmdd.log”, with yy being the 2 digit year, mm the month and  dd the  day of month. To generate the same name with file monitor, use  the  following name “u_ex%y%m%d.log”.)
Set the Logfile Type to “W3C WebServer Logfile”.

Please note, that this step can be easily adapted for other log files (e.g. DHCP log files) as well.

Step 3 – finished

We have now finished setting up the other server. You only need to Save the configuration and start the Service with the "Play" button at the top of the Configuration Client. MonitorWare Agent will pull the logs from the Event Log and the text files and forward them via TCP syslog to our central log server.

<< Go back to the main page

Centralized logging in a hybrid environment (Windows/Linux) – Step 2

Friday, March 11th, 2011

Step 2 – Setting up the Windows Clients

Setting up the Windows Clients is rather easy. To do this, we only need to have EventReporter installed. EventReporter will be configured to pull the Windows Event Logs and forward them to our central syslog server via TCP syslog. Our example system will be Windows XP.

When you open the Configuration Client, you will see the configuration tree on the left. Most important are the part "Configured Services" and "Rulesets". Right now, both have no content. But we will change that now.

Step 2.1

As a first step, we will set up the ruleset again.

centralized_monitoring_2001

Right-click on RuleSets in the left hand list. A context menu will appear. Click on Add RuleSet

centralized_monitoring_2002

The RuleSet Wizard will appear now. You can give your ruleset a name of course. We will use TCP Forwarding for this example. After that, click on "Next".

centralized_monitoring_2003

On the second page of the wizard we can specify what actions we want. Since we only want the log messages to be forwarded via syslog, check the box next to "Forward Syslog". After that, click "Finish" to create the ruleset and action.

Step 2.2

centralized_monitoring_2004

When you expand the treeview now, you will find a rule named "Forward Syslog" with an attached action of the same name.

centralized_monitoring_2005

Now click on the action "Forward Syslog. You can see the default values now.

centralized_monitoring_2006

We need to change some of those settings now. First of all we need to enter the IP or hostname of our central server into the field "Syslog Server". After that, change the port to 10514, since our central server will listen to syslog on this port. And we need to change the protocol type. Change is to TCP (persistent connection). That is all for now. Click on the Save button on the top so we can go on configuring the Service itself.

Step 2.3

We need to configure our service now. Right-click on "Configured Services" in the configuration tree on the left to pop up a context menu.

centralized_monitoring_2007

When you go to "Add Service" you will see the list of available Services. The list is a lot smaller than in MonitorWare Agent. We need the regular Event Log Monitor in this case.

Note: If you are using Windows Vista, 7 or Server 2008 you might consider using the Event Log Monitor V2, since it is optimized for the new EventLog that has been introduced with Windows Vista.

centralized_monitoring_2008

When you have clicked on Event Log Monitor in the list, a wizard will open. Since we will not do any configuration now, just click on "Finish".

centralized_monitoring_2009

When clicking on Event Log Monitor in the configuration tree you will see the default options. We can leave these settings as they are. Probably you might want to change the preferred language or the sleep time. As you can see at the bottom, the service is already assigned to our ruleset we created earlier. Newly created services will automatically be assigned to the first ruleset in the list.

Step 2 is finished

Basically, that is it. Save the configuration and then start the service with the button that looks like the "Play" symbol. EventReporter will then start to pull Events from the Windows Event Log and forward them via TCP syslog to your central server.

<< Go back to the main page

Centralized logging in a hybrid environment (Windows/Linux) – Step 1

Thursday, March 10th, 2011

Step 1 – Setting up the central log server:

The central log server is the most important part of our central log storage and thus will be configured as the first part. And due to all the things it needs to do, it has the most work of course. When selecting your machine to install the central log server on, please keep in mind, that you need quite a good machine for larger networks. If you have a very large environment, it might be a good idea to use multiple servers for this scenario with a load balancer and a separate database server. But in this guide, we will have it all on one machine.

Prerequisites:

The following should be installed and working:

  • Windows Server operating system (Windows Server 2008)
  • Database Server (MSSQL)
  • IIS Webservice
  • MonitorWare Agent Professional Server (V7.2)

The list holds the things necessarily needed. In the brackets is schon which we will use in this example. Please note, that this will work with other versions as well, especially with MonitorWare Agent.

As mentioned before, MonitorWare Agent will have multiple purposes. It should receive syslog via TCP and UDP, monitor the local EventLog and textbased logfiles as well as writing everything into a database and sending email messages in case of error and critical messages occuring.

Step 1.1

First of all, we will set up the processing rules and actions. We will start this way due to the design of MonitorWare Agent. Since the Services need to be bound to a ruleset upon creation, we will start this way, so the ruleset is there already when creating the service.

centralized_monitoring_1001

When starting MonitorWare Agent the first time, you will see on the lefthand side our overview of "Configured Services" and "Rulesets". Right now, there shouldn’t be any entries here.

centralized_monitoring_1002

Right click on "Rulesets". A context-menu will open.

centralized_monitoring_1003

Choose "Add Ruleset". The ruleset wizard will open. On this first screen, we can choose the name of the ruleset.

centralized_monitoring_1004

After choosing a name (in this example "Storage & Alert"), click on "Next". Here we can set, what we will need. Leave the marker for "Create a Rule for each of the following actions" and choose "Send Email" and "Database Logging".

centralized_monitoring_1005

You can now click on Finish. You will now see a new ruleset in the treeview on the left hand side. If you expand this view completely, you can see the two rules that have been created and the actions that are in there. You should have a rule "Database Logging" and a rule "Send Email".

Step 1.2

We will now start with configuring the action for "Database Logging". Expand the branch called "Database Logging" completely. Under actions you will find the "Database Logging" action. When you click it, you will see the configuration window.

centralized_monitoring_1006

Click on the button "Data Source (ODBC)". This will open the ODBC Data Source Administrator.

centralized_monitoring_1007

Go to System DSN and click "Add…".

centralized_monitoring_1008

Select SQL Server from the list and click "Finish".

centralized_monitoring_1009

Choose a name for the datasource and a description. In this case we choose MyMWDB as name. As server choose the name of the server where the database is. In our example we use localhost. Now click on "Next".

centralized_monitoring_1031

Select “SQL Server Authentication” and type in your MSSQL Login ID and Password. If you have Windows NT authentication like in our case, leave it as is. Click on “Next”.

centralized_monitoring_1010

Select “Change the default Database to:” and choose your new created Database, in our example we use “MyMWDB” which we created beforehand. Click on “Next”.

centralized_monitoring_1011

Leave all at default settings and click “Finish”, a test Window will appear:

centralized_monitoring_1012

Click on “Test Data Source”, normally the following Window should be displayed:

centralized_monitoring_1013

If not, go back and check your Settings, if yes, Click “OK” and exit the System-DSN Wizard.

centralized_monitoring_1014

Now we are back in MonitorWare Agent. Insert the DSN for your database, User-ID and Password.

centralized_monitoring_1015

After that, click the "Create Database" button. We still need the tables that the log messages will be stored in. After clicking the button, a small window will open. Insert the DSN, User-ID, Password and choose the type of database you are using, in our case MS SQL. By clicking on the "Create" Button, the tables needed for the default database format of the MonitorWare Products will be created. After that, close the window.

Since we want to log all messages into the database, there is no need to set up any filters.

Step 1.3

In the next step, we want to set up the Send Email rule. But since we only want error log messages, we need to set some filters. Click on the Filter Conditions. You will see the overview over the filters for this rule.

centralized_monitoring_1016

Right now, the view is empty except for a AND operator. Double-click it to change it into a OR operator.

centralized_monitoring_1017

Right-click on the OR operator. A context menu will open. Go to Add Filter -> Syslog -> Priority.

centralized_monitoring_1018

Click on the filter setting and change the property value to "Error (3)".

centralized_monitoring_1019

Again click on Add Filter -> EventLog Monitor V2 -> Event Severity.

centralized_monitoring_1020

Click on the second filter setting and change the property value to "[ERR]".

We are now finished with the filter settings. The filter will accept all log messages that are either of syslog proiority error or critical or Windows Event severity error. The OR operator ensures, that every of these cases will be accepted. When the messages are approved of fitting into the filter, the action will process them.

centralized_monitoring_1021

Click on the "Send Email" action now. You will see the configuration window on the right pane. Currently, there are only the default values in there.

centralized_monitoring_1022

We need to change some settings here, like the Mailserver, Sender and Recipient, the subject and the Mail Priority. If necessary for your mail server, you need to change the authentification settings at the bottom as well. in our example we need SMTP Authentication for that. If you want, you could even enable the backup mail server.

Now we have all actions fully configured. It is now time to setup the configured services.

Step 1.4

Currently, when clicking on Configured Services you will not see a thing. But we will configure the services now. Without them, MonitorWare Agent is not able to get any log messages. We will setup 2 Syslog Receiver, 1 EventLog Monitor and 1 File Monitor.

centralized_monitoring_1030

When right clicking on Configured Services a context-menu will open. By moving your cursor to "Add Service" you can see a list of Services, that may be configured. The list seems pretty long, but we basically need 3 services of them.

centralized_monitoring_1024

Click on "Syslog Server" first. The Services Wizard will open. Simply click on Finish for now. Repeat this again for Syslog Server, EventLogMonitor V2 and File Monitor.

centralized_monitoring_1025

In the end, you should have a list with 4 Services. For our example I renamed the services by doing a right-click on the Service name I wanted to change and the choosing "Rename Service". This was mostly to distinct the two Syslog Servers.

Step 1.5

Settings for Syslog Server UDP

centralized_monitoring_1026

We can leave the "Syslog Server UDP" on default settings. It is already listening to UDP on port 514. The rest of the default settings is just fine.

Step 1.6

Settings for Syslog Server TCP

centralized_monitoring_1027

We will now go to the "Syslog Server TCP" now. Here we need to change several settings. Change the protocol type to TCP and the Listener Port to 10514. Further, we need to enable the option "Messages are separated by the following sequence" in the TCP options. It should look like this now:

Step 1.7

Settings for Event Log Monitor V2

centralized_monitoring_1028

The Event Log Monitor V2 needs no additional setup. Again the default values are ok. If you want specific Event categories not to be stored, you can disable the options. But the basic format is sufficient.

Step 1.8

Settings for File Monitor

centralized_monitoring_1029

The File Monitor needs some additional settings. First, enable the option "Allow Directories or read multiple files". You will see, that the use of wildcards will be automatically enabled and some other options completely being disabled.

Then we need to set the source files. For our example, we want to monitor the IIS logfiles. At the top of the File Monitor configuration you can see the option "File and path name". There is a Browse button right next to it. Click it.

A windows explorer window will open, where you can choose the file you want to monitor. Navigate to the path C:\inetpub\logs\LogFiles\W3SVC1\. This is the location where the log files are stored. Please note, that the file location could be different when using another version of IIS. Choose the first file in the list. (Note: Daily Internet Information Server log files are named “u_exyymmdd.log”, with yy being the 2 digit year, mm the month and dd the day of month. To generate the same name with file monitor, use the following name “u_ex%y%m%d.log”.)
Set the Logfile Type to “W3C WebServer Logfile”.

Please note, that this step can be easily adapted for other log files (e.g. DHCP log files) as well.

Step 1 Finished

We have now finished the configuration for our central server. It will now be able to receive syslog either via TCP (port 10514) or UDP (port 514), monitor the local Event Log as well as the IIS logfiles. Once more click the "Save" button to save the configuration (if not done already) and start the service. All log messages will now be stored into the database as they arrive/occur. Further, administrators will be alerted via email once an error occurs.

<< Go back to the main page

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

Monday, August 2nd, 2010

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

Monday, August 2nd, 2010

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

Monday, April 12th, 2010

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

Monday, April 2nd, 2007

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?

Wednesday, March 15th, 2006

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.