Log Consolidator and Alerter
Adiscon today announced the immediate availability of MonitorWare Agent 1.2 SP1. This version has some minor bugfixes and some minor enhancements. For more details see below. Continue reading “2003-07-29 MonitorWare Agent 1.2 ServicePack 1 Released”
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.
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:
Please note that this information is only applicable to EventReporter 6.x and MonitorWare Agent.
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.
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:
Please have a look at the picture below. It would give you better understanding of creating filter conditions for nested 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.
Article created 2003-05-12 by Rainer Gerhards.
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.
Article created 2003-05-12 by Rainer Gerhards.
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:
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)
Article created 2003-05-09 by Tamsila-Q-Siddique.
This step-by-step guide was inspired by a customer question. The customer had a need to record all events seen in the event logs. But due to the overall setup, a lot of event log truncated messages occured. These, too, should be forwarded, but only one in a row (there occured multiple of such event quickly after each other, uselessly filling up the central log). This scenario also serves as a good sample on how to report only the first instance of frequently reoccuring events while reporting all of the rest. In this example we assume that all messages should be forward via syslog to the central syslog server at 10.0.0.1. We use the default format for forwarding. Please replace this with whatever actions you desire.
In order to achieve this goal, we have to use filter conditions. Whenever a log is truncated Event ID 1011 is registered in Windows Event Log by Configuration Program. Keep in mind that an Event ID alone is not meaningful, so we need to complement it with the Source and the Log part to make it unique. The filter process will now basically work as follows (for details see steps below):
Obviously, Rule 3 can be many rules, as many as you like. Rule 1 and 2 can be iterated if you have more than a single event to be treated that way.
1. Once Configuration Program is opened, create a new service i.e. Event Log Monitor.
2. Add a new Ruleset. We name it as Reporting Log Truncation Rule.
3. Add a new rule named as Log Truncation.
4. Click on the Filter Conditions of Log Truncation. Now start applying filters, in the end your filter condition will look like as in the screen-shot shown below. To prevent this rule from firing too often we would enable “Minimum Wait Time”. This will make sure that the “log truncation” events are only forwarded once within a specified period.
5. Now create a new action as “Forward via Syslog” and configure it according to your settings e.g. Syslog Server has been configured to 10.0.0.1.
6. Don’t forget to bind your ruleset i.e. Reporting Log Truncation Rule to the service i.e. Event Log Monitor.
1. Add a new Rule named as “Discard”.
2. Click on the Filter Condition and set the filter as described in step 4 but with out enabling Minimum Wait Time. It should look like as follow:
3. Now we define an action as called as “Discard”. This Discard action will make you to get rid of all those events after its been forwarded as Syslog.
1. Add a new Rule named as “Forward Syslog”.
2. Leave the Filter Condition as it is i.e. no filters are specified. By default this apply to the rule as whole.
3. Now define a new action as “Forward via Syslog”. And set the configurations according to your settings e.g. Syslog Server has been configured to 10.0.0.1 as in First Rule.
Once done with the rules, don’t forget to restart your Configuration Program!