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

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Relaying Events

In all but the easiest scenarios event data needs to be relayed between
different machines. Please note that relaying is also often referred to
as “forwarding” – both terms have the same meaning in the context
of this documentation.

A typical relay scenario might look like follows:

Here, devices send event data to servers configured for relaying. These
servers in turn forward the data to its final destination, the central
server.

Please note that the so-called “Relay Server” need not be limited to the
relay function. It can also perform any other MonitorWare agent function
like data gathering or real time alerting. Also, the devices of course
can include Windows systems monitored by a MonitorWare Agent configured as data gathering- The idea behind the picture is to provide a quick sample – it is in no means complete.

Whenever it comes to relaying messages, an important decision must be made: the protocol used for relaying must be selected. Basically, either syslog or the SETP protocol can be used. This is an important choice, because the two protocols offer very different benefits:

syslog

supported by virtually all network devices (like routers, firewalls and the like)
standardized (but not necessarily all devices follow the standard)
THE universal network event notification protocol
UDP based, as such event data might be lost in transit
limited to 1024 characters per event, which is definitely too short for Windows
event log entries (larger messages can be processed by MonitorWare, but
this can result in more likely packet loss)
event source system typically can not be tracked correctly when using inside a cascaded system
event information for non-original syslog events is lost as they can not be transmitted in native format

SETP

Adiscon’s proprietary protocol for event notification
so far, supported by MonitorWare Agent exclusively
TCP based, reliable delivery possible
can be used with Windows IPsec
optimized for event data transmittal
events are transmitted in native format and thus can be fully reconstructed at
the receiving side
no event size limit
XML based

Given the advantages, Adiscon recommends using SETP whenever possible. This is then the case when an MonitorWare Agent sends events to another MonitorWare Agent. When events from other devices, e.g. routers, are to be received, syslog protocol must be used for these incoming events. If event data is to be sent to a non-MonitorWare Agent system (e.g. a management system on a Linux or UNIX system), syslog must also be used as these other systems do not “speak” SETP.

MonitorWare Agent can process both of these protocols concurrently. So it is no problem to use SETP in a mixed environment. Again, we highly recommend using SETP whenever possible.

A complete description of common uses of the MonitorWare line of products. – Solving Products

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Solving Problems

Solving problems is closely related to alerting. As with alerting, actions are to be executed if a trigger condition exists. With problem-solving,
these are actual corrective actions. Samples are deleting temporary
files when disk space goes low or blocking an external IP address in a firewall in case an attack is detected.

MonitorWare itself does only provide limited “canned” actions for
problem-solving. However, it contains the “execute program” action,
which is a very powerful tool in solving problem conditions.

The basic idea behind this concept is that the MonitorWare agent detects
correctable conditions and then executes an external program (or a batch
file!) to correct the problem. With the power of external program, batch
files and scripts, many minor conditions can be solved before they cause
deep trouble. Many routine tasks can be solved without operator
intervention which also means they can be solved while no operator is
available.

Problem-solving logic can be put on any Agent. However, Adiscon highly recommends placing it on the each of the machines that will use problem solving logic. This not only ensure quick response time and reliability, it also guarantees that actions are carried out as quickly as possible.

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

Common uses

Article created 2003-05-14 by Rainer
Gerhards.

Alerting

In this scenario, the primary concern is to receive alerts if specific events happen. Of course, alerting is often used together with other scenarios as alerting alone does not provide in-depth analysis or storage of the captured events.

Alerts can be generated by every running instance of MonitorWare Agent. As such, alerts can be generated both on each machine that is monitored as well as on a central machine. Also, alert generation can be combined.

There are advantages and disadvantages for each mode. The big plus of generating alerts on each monitored machine is that they will be triggered whenever they are detected. There is no interim system that events need to be passed to and as such no interim system that can fail. However, this implies that alerts need to be configured on each monitored machine, which can be inconvenient (but becomes less of a burden with the soon available central configuration service).

Central alert generation ultimately solves this issue, as alerts are only generated on a single machine – or at least few machines. On the other hand, if the reporting system is not able to reach the central server for some reason – or the central server fails, no alerts will occur at all. This, of course can be largely worked around by monitoring the central server’s health with another instance of the MonitorWare Agent running on another machine, but this adds complexity.

Fortunately, MonitorWare is flexible enough to allow all imaginable configurations. For example, it is possible to trigger for extremely urgent alerts on every monitored machine while less critical alerts are checked at a central server.

In any case, alerts are defined via rule sets. Inside the rule set, filters are defined for the alert conditions and action carry out the actual alert. Of course, alert actions are most often sending emails or starting a “net send” command to broadcast the message e.g. to a group of network administrators.

Alerts can be executed on a MonitorWare Agent who is also performing other functions.

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

Analysis

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
“Centrally
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
www.counterpane.com.