Create a regular report on the Windows event log
The need to monitor the Windows event log is beyond doubt. On this topic, articles regularly appear, including on Habré. However, for some reason all the examples are reduced to the monitoring of pre-defined EventID. In my WinLogCheck utility, I chose another way - to receive a report on EventLog, excluding events that regularly appear and are of no interest to me.
As it turned out, this is not a unique option, the lincheck utility for Linux is based on the same approach. But it is quite possible that my decision, nevertheless, appeared a little earlier.
In this article I will try to do without technical details. A little about the history of creation - in my opinion, this will help to understand why and under what conditions this utility appeared and where-when it is better to use it. Further, a brief description of the algorithm and something similar to the instructions for use.
This solution allows me to control more than a dozen Windows Server now and has been helping me in my work since 1998. The first version was written in ActiveState Perl to monitor three servers on Windows NT 4. For Windows Server 2003, a shell was written for the Logparser in JScript. But with the release of Windows Server 2008 I had to start from scratch. There was an attempt to write Powershell, but since sometimes I take part in the development of programs and know a little C #, this option was convenient for me.
')
The very first version was designed to work in the domain - the utility was launched on one of the servers and a report was generated on all the servers in the domain. However, already in Windows Server 2003, the request to the event log on the network became fulfilled for too long (I did not understand the reasons), and servers appeared outside the main domain of the company in which I work in the service. Therefore, in some cases it is simply impossible to use any ready-made centralized solution.
When a few years ago, servers running Linux appeared in my “submission”, I learned about the existence of an analogue of my utility - logcheck. For those who do not know, the utility is mentioned and recommended in many Linux and FreeBSD security materials, for example, in the Debian Security Guide. After that, it was decided to make its utility more convenient to use and publish it under the name WinLogCheck (originally it was called UnknownEvents).
As a result, the utility became even more similar to logcheck - it starts at 9:00 on each server and after 5-10 minutes there are more than a dozen messages in my mailbox. Usually a couple of minutes are enough for me to see everything.
I tried several times to find a ready-made monitoring tool, but I never met anything convenient, simple and practical. Perhaps it's all a matter of habit. However, if you don’t have a very large number of servers, try, you might like my version.
Algorithm of the main mode of operation:
Despite the fact that .NET has its own methods for getting a list of events, I use WMI (more about WMI Tasks: Event Logs ). It's easier to work with the test message. The only drawback is the delay in the execution of queries with a large number of entries in the log. For example, at one of the domain controllers, creating a report takes 5-6 minutes.
At the beginning of the working day for each server, I get something like this report (this is a report from actually working Windows Server 2008 R2 with Hyper-V):
Everything is in order, a one-time error in the DNS-Client does not require special attention. Pay attention to Subject messages - most often letters do not even need to be opened: usually the topic ends with the phrase “errors = 0, warnings = 0, other = 0”.
The utility is run from the command line with administrator rights.
Required parameter - operation mode: EXCLUDE or INCLUDE. Run in the main EXCLUDE mode:
Two optional parameters are provided for the INCLUDE mode (for myself I call it the special reports mode):
-l <eventlog_name> - to specify the log for which to get the report
-f - the name of the filter in the file “\ path \ to \ winlogcheck \ include \ <eventlog_name> .conf
For example, for a separate report on successful connections to the RAS server on this server, I have the file “\ path \ to \ winlogcheck \ include \ system.conf” with such text (about the format of the filter file - below):
Runs once a day too:
Naturally, the same filter exists for EXCUDE mode - so that these records are absent in the general server report. One of the reports:
In EXCLUDE mode, I use optional parameters only for testing.
Parameters are stored in the configuration file winlogcheck.ini. The file is small, so I quote it completely with additional comments:
In the development of our company uses NLog, so I did not reinvent the wheel. The configuration file included in the package for NLog is configured to display the execution log to the console and to the file “\ path \ to \ winlogcheck \ logs \ winlogcheck.log” with rotation (every day a new file, the retention period is 10 days).
We turn to the most interesting. Typical Event Viewer screen on a server with IIS installed:
Probably everyone knows the events:
Everything is clear with them - we do not need them in the report.
Filters are written using SQL syntax, the names of the fields in the event log are different from what we see on the screen. To compile the filter, we can use:
And what we see in the event description is in the Message field.
Thus, to exclude the above events from the report, it is necessary to create the file “\ path \ to \ winlogcheck \ exclude \ system.conf” with the text:
Comments on the format of the file with filters
The main filters that I use in my work are included in the archive with the utility.
A special relation only to the security log - very often there are a lot of events in it, so the default filter is in effect: only errors are reported.
The issue of monitoring Active Directory is often raised. My solution can be used to solve this problem. However, I haven’t been involved in managing “large” domains for a long time, so I didn’t invent any fictional examples for monitoring AD events.
This solution does not claim to be universal, but, in my opinion, it can be useful on any network with a small number of servers running Windows.
As it turned out, this is not a unique option, the lincheck utility for Linux is based on the same approach. But it is quite possible that my decision, nevertheless, appeared a little earlier.
In this article I will try to do without technical details. A little about the history of creation - in my opinion, this will help to understand why and under what conditions this utility appeared and where-when it is better to use it. Further, a brief description of the algorithm and something similar to the instructions for use.
Brief history and who can be useful WinLogCheck
This solution allows me to control more than a dozen Windows Server now and has been helping me in my work since 1998. The first version was written in ActiveState Perl to monitor three servers on Windows NT 4. For Windows Server 2003, a shell was written for the Logparser in JScript. But with the release of Windows Server 2008 I had to start from scratch. There was an attempt to write Powershell, but since sometimes I take part in the development of programs and know a little C #, this option was convenient for me.
')
The very first version was designed to work in the domain - the utility was launched on one of the servers and a report was generated on all the servers in the domain. However, already in Windows Server 2003, the request to the event log on the network became fulfilled for too long (I did not understand the reasons), and servers appeared outside the main domain of the company in which I work in the service. Therefore, in some cases it is simply impossible to use any ready-made centralized solution.
When a few years ago, servers running Linux appeared in my “submission”, I learned about the existence of an analogue of my utility - logcheck. For those who do not know, the utility is mentioned and recommended in many Linux and FreeBSD security materials, for example, in the Debian Security Guide. After that, it was decided to make its utility more convenient to use and publish it under the name WinLogCheck (originally it was called UnknownEvents).
As a result, the utility became even more similar to logcheck - it starts at 9:00 on each server and after 5-10 minutes there are more than a dozen messages in my mailbox. Usually a couple of minutes are enough for me to see everything.
I tried several times to find a ready-made monitoring tool, but I never met anything convenient, simple and practical. Perhaps it's all a matter of habit. However, if you don’t have a very large number of servers, try, you might like my version.
How Winlogcheck Works
Algorithm of the main mode of operation:
- Get a list of registered event logs. For normal Windows Server 2008 - 7, for a server with Active Directory - 10.
- For each event log, a query is generated — get a list of events for the last 24 hours (approximately), excluding the events specified in the exception file “\ path \ to \ winlogcheck \ exclude \ <eventlog_name> .conf
- From the resulting list, a report is generated in HTML, which is written to a temporary file (in case the letter with the report does not reach).
- The report is sent by mail.
Despite the fact that .NET has its own methods for getting a list of events, I use WMI (more about WMI Tasks: Event Logs ). It's easier to work with the test message. The only drawback is the delay in the execution of queries with a large number of entries in the log. For example, at one of the domain controllers, creating a report takes 5-6 minutes.
At the beginning of the working day for each server, I get something like this report (this is a report from actually working Windows Server 2008 R2 with Hyper-V):
Everything is in order, a one-time error in the DNS-Client does not require special attention. Pay attention to Subject messages - most often letters do not even need to be opened: usually the topic ends with the phrase “errors = 0, warnings = 0, other = 0”.
How to use WinLogCheck
Command line parameters
The utility is run from the command line with administrator rights.
Required parameter - operation mode: EXCLUDE or INCLUDE. Run in the main EXCLUDE mode:
winlogcheck -m excludeTwo optional parameters are provided for the INCLUDE mode (for myself I call it the special reports mode):
-l <eventlog_name> - to specify the log for which to get the report
-f - the name of the filter in the file “\ path \ to \ winlogcheck \ include \ <eventlog_name> .conf
For example, for a separate report on successful connections to the RAS server on this server, I have the file “\ path \ to \ winlogcheck \ include \ system.conf” with such text (about the format of the filter file - below):
[General] RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272 Runs once a day too:
winlogcheck -m include -l system -f RASconnectsNaturally, the same filter exists for EXCUDE mode - so that these records are absent in the general server report. One of the reports:
In EXCLUDE mode, I use optional parameters only for testing.
Program parameters
Parameters are stored in the configuration file winlogcheck.ini. The file is small, so I quote it completely with additional comments:
[General] ## ( ). ## : 24 ( ) ## #TimePeriod = 24 ## ## : 'path\to\winlogcheck\reports\' ## , ## , -. ## - . ## #ReportPath = c:\inetpub\wwwroot\winlogcheckreports ## CSS . ## ! ## ReportCSS = h1 {margin:0;font-weight:400} .servername, .subhead {font-weight:700} table {width:100%;} td {padding:0.25em} th {border:1px 0} tr:nth-child(odd) td {padding-bottom:1.5em, border-bottom:1px} tr:nth-child(even) {background-color:rgb(248,248,248)} caption {font-size:120%;text-align:left;padding:10px;background:rgb(216,216,216)} .error, .failure {background:rgb(255,127,127)} .warning {background:rgb(255,233,127)} ## ## - . ## , ## . ## #[Mail] #SMTP_Server = localhost #Mail_From = Winlogcheck SERVERNAME <administrator@example.com> #Mail_To = Administrator SERVERNAME <administrator@example.com> Monitoring of the utility itself
In the development of our company uses NLog, so I did not reinvent the wheel. The configuration file included in the package for NLog is configured to display the execution log to the console and to the file “\ path \ to \ winlogcheck \ logs \ winlogcheck.log” with rotation (every day a new file, the retention period is 10 days).
Filter Settings
We turn to the most interesting. Typical Event Viewer screen on a server with IIS installed:
Probably everyone knows the events:
- Winlogon ID 7001 or 7002 - User Logon / Logoff Notification for Customer Experience Improvement Program
- “Service Control Manager”: ID 7036 or 7040 with the messages: “The WinHTTP Web Proxy Auto-Discovery Service” or “The WinHTTP Web Proxy Auto-Discovery Service „
Everything is clear with them - we do not need them in the report.
Filters are written using SQL syntax, the names of the fields in the event log are different from what we see on the screen. To compile the filter, we can use:
- The name of the event log. In this case, “System”, then we write the filter to the file “\ path \ to \ winlogcheck \ exclude \ system.conf”.
- Level - EventType (integer). In the journal itself is determined by the numbers:
- 1 - Error
- 2 - Warning
- 3 - Information
- 4 - Success
- 5 - Failure
- Event ID - Eventcode (integer)
- Category - CategoryString (string)
- Source - SourceName (string)
And what we see in the event description is in the Message field.
Thus, to exclude the above events from the report, it is necessary to create the file “\ path \ to \ winlogcheck \ exclude \ system.conf” with the text:
[General] UserNotify : SourceName = 'Microsoft-Windows-Winlogon' AND ( EventCode = 7001 OR EventCode = 7002 ) WinHTTP : SourceName = 'Service Control Manager' AND (EventCode = 7036 OR EventCode = 7040) AND Message LIKE '%WinHTTP%' Comments on the format of the file with filters
- Initially, the data types built into the language were used in the filter files, for example, in the JScript version, the Dictonary object. Then I tried JSON. But in all cases it is easy to make a mistake, so the ini-file format was chosen.
- The filter name is required, but is currently used only in INCLUDE mode when generating special reports.
- The string of conditions - should not cause questions.
- As you can see, all the examples are for the English version of Windows Server. Nevertheless, everything works fine on the Russian version. This requires that the filter files are in UTF-8. The meaning of the SourceName and CategoryString fields is translated in the Event Viewer itself, so English analogs should be used in queries, but the message text is in Russian. Perhaps in the next update of the program I will include an example for the Russian version of Windows Server.
The main filters that I use in my work are included in the archive with the utility.
A special relation only to the security log - very often there are a lot of events in it, so the default filter is in effect: only errors are reported.
Last notes
- The archive with the program and the source code of the program under the LGPL license are published on Codeplex (I didn’t understand it much). Since I am not a professional programmer, I don’t brag about the code.
- The utility was written specifically for WIndows Server 2008, but it also works on the only available Windows Server 2003. It has not yet tested the new version of WIndows Server 2012, but there should not be any problems. Should also work on Windows XP / Vista / 7/8.
- Description and brief instructions for Codeplex were prepared using Google Translate. The finished translation was checked by knowledgeable and found to be similar to real English. :-). If anyone has experience in translating technical documentation, I will be glad to hear comments and suggestions.
The issue of monitoring Active Directory is often raised. My solution can be used to solve this problem. However, I haven’t been involved in managing “large” domains for a long time, so I didn’t invent any fictional examples for monitoring AD events.
This solution does not claim to be universal, but, in my opinion, it can be useful on any network with a small number of servers running Windows.
Source: https://habr.com/ru/post/156937/
All Articles