...
Configuring the Checkmk Agent
There's a bakery rule, "Finetune Windows Eventlog monitoring", that should be used to define which Eventlogs should be considered , and how.
In this use case, we are only interested in the Security log, so the rule should look like this and should match all hosts we want to monitor the Security log on:
...
We recommend using the spooling, so the events are buffered if the Event Console should be down for a moment. The syslog facility "local1" can be used later in the EC rules for efficient event handling.
After saving this rule, do make a service discovery on the affected hosts and activate the changes.
...
From now on, the events from the Windows Eventlog on your hosts will be translated to Checkmk Event Console events and put into the event archive (if not matching any EC Rule , yet):
To categorize and classify the incoming events, we We will create some EC Rules in the next paragraph to categorize and classify the incoming events. Using the message texts from the Event History, you can define the needed Regex patterns for that.
...
Go to the rules of this Rulepack:
There, create a rule to handle all events that are not matching any other rules , yet:
General properties
Setup → Events → Event Console rule packs → Add Rule
...
The first one is applied to the message text and defines three matching groups using the brackets:
Code Block language bash theme RDark .{3} [0-9]+ [0-9:]{8} [0-9]+\.([0-9]{4}) ([^ ]+) (.*)
The website https://regex101.com helps you to understand how the regex matches the message text and which groups are created:
These groups can later be accessed using the placeholders \1, \2, and \3 in the message text rewriting. They might also become important when automatic duplicate detection is used. We'll come to that later on.- The second regular expression "^(.*)$" simply matches on any Application text (in our case, it's always "Security", though) , and puts it into a matching group. Later, we can access this group using the macro "$MATCH_GROUPS_SYSLOG_APPLICATION_1$".
...
Unknown Security event with ID 4799: A security-enabled local group membership was enumerated. Subject: Security ID: S-1-5-18 Account Name: DESKTOP-DLP6NNN$ Account Domain: WORKGROUP Logon ID: ...
The application will also be replaced also using groups from above:
WinEvtLog_Unknown_$MATCH_GROUPS_SYSLOG_APPLICATION_1$_$MATCH_GROUPS_MESSAGE_1$
...
Based on the events that are now catched caught by the "unknown" rule, we can pick single Event IDs and create rules for them to handle them separately. Let's chose choose this event in the first step:
...
Clone the "unknown" rule and modify the following fields:
The Regex
Using the long message text, we pick out the important information (colored) and create a regular expression pattern, starting with the one we already used in the "unknown" rule:
...
Fill in the new pattern in the "Text to match" field:
Counting & Timing
The counting and timing also will be changed a bit:
For this kind of eventsevent, we want separate events if the match groups ("executing user name" and "affected user name") are different.
Also, we don't want to archive these events after a few hours, but after 3 three days ( => keep over the weekend).
...
In the rewriting section, the texts are also adjusted to the newly defined event:
Further Rules and Performance Considerations
...
- The first rule that matches will handle the event. All upcoming rules will not be checked at all. Thus, the order of your rules is important. The most common rule (in our case, the "unknown" rule) has to be last.
- Some rules might be moved up and down independently , because they have an explicit pattern or other conditions defined. In that case, put those rules to the top, that are used most to the top. This will increase your "rule hit ratio" and, thus, the performance of the Event Console.
- To further increase the performance, place a dropping rule on the top of your list , that drops all events that don't match rthe the syslog facility you have defined in your forwarding rule.
After that, your rule pack should look similar to this:
Testing these rules by creating and deleting a user on the monitored host results in the following events:
To get rid of the "unknown" events in-between, we can do two things:
...