Tag: MonitorWare Agent

How to use the Event Severity filter?

How to use the Event Severity filter?

Created 2003-07-29 by Andre Lorbach

The ‘Event Severity’ can be used to filter by event type. The following values are possible and valid:

EVENTLOG SUCCESS1
EVENTLOG ERROR TYPE2
EVENTLOG WARNING TYPE4
EVENTLOG INFORMATION TYPE8
EVENTLOG AUDIT_SUCCESS16
EVENTLOG AUDIT_FAILURE32

To filter by multiple event types, you can use an OR filter on the top level and multiple Event Severity filters below. In this sample, you wil see Event Severity with ERROR TYPE and WARNING TYPE:

2003-07-29 MonitorWare Agent 1.2 ServicePack 1

MonitorWare Agent 1.2 ServicePack 1

  • Configuration Client enhancements – Added two new filters, Event Category and Event Type. These two filters can be used for EventMonitor filtering.
  • Configuration Client bugfix – If a RuleSet was deleted, all RuleSets below the deleted one could lose their filter. This has been corrected now.
  • Syslog Service – New setting Enable RFC 3164 Parsing added. If this setting is disabled, MW Agent will not try to search for a SyslogTag in Syslog messages.

Adiscon products and the Microsoft SQL Server 2000 Desktop Engine

Adiscon products and the Microsoft SQL Server 2000 Desktop Engine

Created 2003-07-24 by Lutz Koch.

How do MSDE security risks relate to Adiscon products?

As a general policy, MSDE is *not* installed with any of our products.
Even though this may cause some additional setup work for customers, we have decided to do so because of vulnerability issues of MSDE. If you decide to install MSDE however, we think that you should be aware that you install a potentially dangerous, large piece of software.

If you are concerned on MSDE security, you may want to use MySQL instead of MSDE. We do offer full support for MySQL.

What is “Event ID 107”?

What is “Event ID 107”?

Created on 2003-06-16 by Usman Khawaja

Message: “Couldn’t read last record for Security log (state 87) – nLastRecord set to 0 to recover.”

This actually is no error, but a status message. There can be three reasons for this message:

  1. This message occurs when by any chance the last entry in the event log gets deleted. By the network administrator or however. Because of this, nLastRecord (which keeps the track of last entry in the event log), which contains the last event log record read (of the particular event log part), is reset to 0. This parameter is usually not to be modified. If you would like to get a complete dump of your event log instantly, enter 0 in this parameter. There is a setting for this message in the options of the event log monitor service, called “Report truncated log”. If this option is checked, the message appears if a log is somehow truncated.
    If for any reason EvntSLog is unable to read the event log (e. g. truncated by administrator), it will reset nLastRecord to 0 automatically (that event, too, is logged in the NT application event log). The EventReporter manual will give you more information on this message.
  2. There can be one more reason for this message; that the Eventlog has become corrupted at some position. You can verify this by scrolling through the Eventlog with the EventViewer. If it is indeed corrupted, an error message will pop up.
  3. Third party applications that run on the same machine and interfere or lock the event log. One such application is the ISS RealSecure Server Sensor.

Please note that this information is only applicable to EventReporter 6.x and MonitorWare Agent.

How to setup file monitoring for ISA Server?

How to setup file monitoring for ISA Server?

Created 2003-05-23 by Lutz Koch.

How to setup file monitoring for ISA Server?

Since ISA Server logfiles are W3C based simple textfiles, they can be processed by MonitorWare Agent. To monitor the ISA logfiles, you just have to setup a File monitor service in the Agent:

Right-click on the services node and select “Add Service”. Then, select the File monitor service from the list. In the File monitor options, select the ISA Server logfile for “File and path name”. The File monitor service can be configured to check the file in very small time intervals, e.g. 1 second, so the monitoring is even near realtime.
The 2.x release of MonitorWare Agent has a special option for logging W3C-WebServer logfiles.

Once the file monitor is completely configured, you can setup MonitorWare Agent to perform various actions, such as sending an email or a syslog message. Please also see the FAQ “How can I forward IIS logs to a syslog deamon?” for information on IIS logfile monitoring and forwarding.

How to create complex filter conditions?

How to create complex filter conditions?

Created 2003-05-13 by Usman Khawaja.

I would like to create some more complex filters by combining ANDs and ORs.

(condition “a” AND condition “b”)
OR
(condition “c” AND condition “d”)
OR
…
where “condition a” could be one of the choices like “syslog priority < 4 “, etc.

In order to create the above mentioned scenario, follow these steps:

  1. First create a rule set and add rule to it. Click on the filter conditions of that rule set. You will see the default form for filter conditions. By default there is an AND condition set in the filter condition form. You can change that operator to OR/XOR/NOT/TRUE/FALSE by double clicking on the AND operator.
  2. Now Click on the AND operator from the toolbar shown on right side of the filter conditions form (in MonitorWare agent) in order to AND the conditions a and b. right click on the AND operator (which you just added) and add filter conditions.
  3. Now again click on the OR operator at the top and insert another AND operator from the tool bar. Follow the same process which you did in step 2, i.e. right click on the AND operator and add filter conditions c and d. You can create as many AND conditions as you like in order to implement the OR operator among them.

Please have a look at the picture below. It would give you better understanding of creating filter conditions for nested conditions.

Complex Filter Conditions.

Please note that this information is only applicable to WinSyslog 5.x and above, EventReporter 6.x and above and MonitorWare Agent 1.x and above.

Configuring Windows for the Event Log Monitor

Article created 2003-05-12 by Rainer Gerhards.

Configuring Windows for the Event Log Monitor

The event log monitor service pulls events from the Windows event logs. In Windows’ default setup, the information contained in the logs is sparse and far from sufficient for security monitoring. If you are solely interested in checking system health, the default setting can be sufficient. If you are interested in security monitoring, you definitely need to change some settings in order to receive a useful result. This will be described in detail later in this section.

No matter what your logging needs are, you need to change the log file overwrite mode. Windows uses a circular buffer for each event log. Once the log file maximum size is reached, whenever a new event is written, an old one is overwritten. This is no problem if the log file size is large enough – and the default typically is – because the event log monitor retrieves log entries on a regular basis and forwards them to the configured destination. As such, no event is lost when an old one is overwritten. However, in default setup, Windows will stop writing events to the event logs when these logs are full and events younger than 7 days would be overwritten. Windows indicates this by placing a respective event into the system log , which of course will not help us retrieve any of the lost logs.

As such, we highly recommend that the log mode is set to “Overwrite as needed” instead to “Overwrite after 7 Days”. In addition, we recommend extending the size of the event log files to 10 to 20 MB. This is just a security precaution – but with today’s hard disk sizes it does not really matter if 100 MB or so are set aside as an additional buffer for unusual high log activity.

Please note that the CERT advises to increase the log size but also advises not to allow Windows to overwrite the log files. Adiscon’s recommendation is not in contrast to the CERT advisory as the event log monitor takes care of the events before they can be overwritten. And, once to repeat, not allowing to overwrite logs can lead to lost log entries, even is a large amount of log space is set aside. A malicious user might first generate a massive amount of log data before the actual attack is carried out.

Creating a hardened log host

Step-By-Step Guides

Article created 2003-05-12 by Rainer Gerhards.

Creating a hardened log host

A hardened log host is a system that is especially configured to prevent malicious users from modifying any log data stored inside it. A hardened log host is especially useful if tampering with log data is to be avoided. Setting up a proper hardened host can definitely help if evidence for crime investigation is needed.

It is beyond the scope of this document to describe all steps necessary to set up a fully hardened log host that can be used in forensic log analysis – but this guide should be a good starting point.

Please note that this Step-By-Step guide does not go into the same detail as most of the others. Most importantly, screen shots are more or less missing. We highly recommend checking with other security sources as well as your local authorities as security needs change quickly. We are focussing on Windows 2000 in this guide, as it at the time of this writing is the most common platform for creating a secure central log server with Adiscon products.

If you have a Windows 2000 machine installed with the default setup, there are a number of essential steps to do before moving it into production:

  • Ensure physical security of the machine. A malicious person with physical access to the machine can overcome any software limitation!
  • Uninstall Internet Information Server (IIS) – there are many issues associated with IIS and it will definitely introduce a security weakness when left on the machine. Make sure you uninstall it – it is installed by default.
  • For the same reason, do not install any other web server – there are too many vulnerabilities in all products and the HTTP protocol itself (this is not a popular opinion but one proved in reality).
  • Rename your “Administrator” account. Give it a name that is not related to administrative functions. “Admin”, “Supervisor” or “root” would be bad names – “Tom” or “Jerry” would be good ones. Take a note of the new admin account name!
  • Be sure to use a strong password for the administrator account – one with at least 8 characters and consisting of numeric, alphabetic and special characters.
  • Create a backup administrator account with a good name and password – as above. Be sure to store the name and password in a safe. We too often have seen highly secured system looking out their legal owners – be sure to have a backup!
  • Be sure to apply the latest service pack (even though you might not like it on other machines) and the latest security patches. A good place to check for new patches is www.microsoft.com/security. Do not rely on Windows Update solely (it has been seen to miss patches). Also, be sure to install patches in the order they have been released! It has been seen that older patches overwrite part of newer patches if installed in any other order.
  • Stop and uninstall all services that need not to be present on the machine. For a highly secure system, be sure to remove the bindings for the file server. Follow the basic guideline: “as few services as possible”.
  • Either via the firewall and/or via Windows IP filters, block all traffic to and from the machine. Open up only the ports that you definitely need (that is 514/UDP for syslog and 5432/TCP for SETP).
  • Double-check that terminal services and telnet are not available on the machine.
  • Make a full backup of the system, including the emergency repair disk. Make sure all disks are protected by fault tolerance, that is either RAID 5 or disk mirroring. Ensure that a proper backup procedure is in place.
  • Check with your legal advisor if physically read-only media is required for storing your log files. If so, ensure that files are periodically written to CD-R or a similar media (do not use CD-RW or any other rewritable media!).

Difference between ReceivedAt and DeviceReportedTime

Difference between ReceivedAt and DeviceReportedTime

Created 2003-05-10 by Wajih-ur-Rehman.

What is the difference between ReceivedAt and DevicedReportedTime?

I will explain you the difference by giving you two different scenarios:

Scenario 1: Using MonitorWare Agent as Event Log Monitor and Forwarding the data to another MonitorWare Agent using Syslog

In this case, the DeviceReportedTime is actually the time that is there in the Windows Event Log i.e. the time at which the message was written into the Windows Event Log. ReceivedAt time on the other hand is the time when the Syslog message is received at the Syslog Daemon, which in this case is the MonitorWare Agent.

Scenario 2: Using MonitorWare Agent as Event Log Monitor and Forwarding the data to another MonitorWare Agent using SETP

In this case, the DeviceReportedTime is once again the time that is there in the Windows Event Log i.e. the time at which the message was written into the Windows Event Log. ReceivedAt time, in this case, is the time at which the MonitorWare Agent picks up the data from the event log. Note that by design, SETP protocol doesn’t modifies the message as it is sent to the central daemon. So when the message receives at the central daemon, its ReceivedAt time stamp will not be changed. In other words, the ReceivedAt time stamp of any message would stay the same (i.e. the time when the event was read from the Windows Event Log)