Windows Event Forwarding (Event Log) to Linux syslog server

Introduction

This article is intended for system administrators who are familiar with Linux and use the family of these systems in a mixed environment, knowing full well that different operating systems are good for different tasks. It will also be of interest to all administrators, even those who are not familiar with Linux, their theoretical part.

It describes a simple and reliable method (even a rather simple and reliable third-party utility) for transferring system events from Event Logs of Windows-based servers to Linux syslog for the convenience of centralized storage and processing.

The realities are such that in the current corporate environment the most efficient and reliable solution is based on mixing server operating systems due to the quality and methods of the tasks they solve. Workstations, and, therefore, group management and administration are easier for them to do in Active Directory; web server, proxy server is more reliable to put on Linux; a router to make something from Cisco quicker. This objective reality with which administrators of many medium-sized companies work (especially those familiar with Linux, they still don’t get away from Windows anyway and often the company has domain controllers on Windows and a proxy server and Linux router) - in small firms You can do with one Windows, in a large company, most likely there is a separate administrator, Linux administrator and Windows administrator, who are skillfully responsible for their sectors. Anyway, this article is not a theorizing and not a study on this topic, this article is about a specific task, which almost always occurs to any administrator working in such an environment, but the entry has been delayed.

Description

Everyone who works with servers knows and uses a daily logging system on their machines and everyone knows how they work - syslog on Linux and Event Log on Windows.
')
Before the Windows Server 2008 era, Event Log was a strange system created as if not for servers - each computer wrote and stored its events locally and convenient mechanisms for transmitting them over the network for centralized viewing or at least there was no storage at all. Well, however, everyone knows that. Viewing logs for servers resembled a quest in the MMORPG - explore several locations and collect several items in each. Starting from Windows Vista, a step was taken towards people and a system of forward local events to other Windows> Vista computers was created. This is good and progressive, and this is exactly what was missing, but the reality is that there are many Windows 2003 servers left and not out of date for which there are no such mechanisms or mechanisms, but they are repelled by their monstrous implementation.

On the other hand, there is a simple and reliable syslog system for Linux which was originally designed for distributed transmission and reception of logs and contains everything that is needed for this. It does its job so well that the ability to send logs using this protocol is built into hardware routers and into a bunch of different other devices and it’s possible to make a server on the network that will collect all logs from all devices on the network: servers, routers, switches, print servers, coffee makers, coolers, oh, something I sold ... Except Windows. Hardly there is a person who did not come up with the idea that if Windows could send its logs to syslog, this would be an ideal solution for centralizing the log store. How convenient it would be to have everything in one place - it would be possible to store it for years, archiving text files (they are perfectly compressed), and process by disassembling one text file from several servers and catching one critical event for several machines at once.

I asked myself this question. I asked them a few years ago and suffered an unpleasant fiasco - there are quite a lot of utilities that allow you to do this, but they all look like a nightmare for a professional administrator - some terrible utilities sometimes in C # sizes of 100 megabytes with a thousand buttons and checkboxes and the most unpleasant - _all paid_. I do not know what the joke is, but a few years ago Google was overflowing with links to commercial software with such functionality. At the same time, the software is not of high quality, judging by the dumb sites and screenshots. He is overwhelmed with them now, and, according to my own observations, many not so lazy and not stupid administrators who are able to use such functionality for their own convenience have not found what they need and do not know what happens. At least for my advice and the link thanked me more than once, and now I would like to share with you. Namely, some time ago (quite a while ago, I decided to write this article just now), I managed to find a project ideally suited to my needs and requirements:

http://code.google.com/p/eventlog-to-syslog/

I will describe in brief its merits:
- this is a system service, i.e. nothing needs to be started at the start, no strange executables that can be accidentally killed by the next cleaning of trash on the server by forgetfulness;
- concise delivery - .dll, .exe and brief but comprehensive documentation;
- open source;
- 32-bit and 64-bit version;
- the same work and version on any versions of Windows with Event Log;
- a minimum of settings (so much so that it is a command line when installing a service and a text file for work, which you can not open at all if you wish);
- covering the maximum of the functional - all that this program should do is - can send logs to various facilities, can exclude certain events from the departure and so on, even get the name of the log server by dhcp.

I’ll add from myself that firstly for six months now this program on my 8 servers and 2003 and 2008 just works, after installation I never checked one of them, didn’t restart a collapsed one, didn’t pick, changed or even I did not look in the direction of this service, which also did not affect any other applications in any way, it just does its job after installation - it constantly sends events to where it was told. And secondly, that the program was developing very dynamically not so long ago, gaining functionality, after which it stabilized and now quite regularly, but not too often, there are builds that brush the functionality and fix small rarely reproducible bugs.

Let us turn to even more specifics.

Customization

Configuring syslog on Linux.
Enable acceptance of logs from the network; this is the -r key of the syslogd daemon. By default, it is almost always not registered, and when you start without it, the syslogd network does not listen.

Then you probably don’t really like it if the logs of Linux, routers and Windows will be mixed in one file and turn into a hard-to-read mess. To do this, the syslog system has several sections (facility) and messages arriving at individual facilities can be written to different files. Since the logs from Windows are not particularly suitable for either the kernel or the mail, especially for this, there are several “impersonal” facilities in the syslog which are called local. For example, to put local1 into a separate file, add a line to /etc/syslog.conf:

local1. * - / var / log / local1.log

Well, remember that this is local number 1. In the same way you can divide the rest of local from local0 to local7.
I draw your attention to the fact that this is the simplest syslog configuration that allows you to simply add logs from Windows to a separate file, a thin syslog configuration allows you to quite intuitively distribute the messages coming to the daemon, but all this is described in the syslog manual and most likely is known to any Linux administrator.
Installing evtsys on Windows.

The installation is elementary - we download the distribution, it contains .dll and .exe, copy them to% WINDIR% \ System32 \
We start .exe with the necessary parameters.

Parameters evtsys.exe:
-i Install service
-u Delete service
-d debag Run as a console program
-h host hostname where to send logs
-b host Name of the second host to whom to duplicate logs
-f facility Facility logs
-l level Minimum level of sent messages
0 = All, 1 = Critical, 2 = Errors, 3 = Warning, 4 = Information
-n Only send events included in the config.
-p port syslog port number
-q bool Poll DHCP to get syslog hostname and port
(0/1 = enable / disable)
-s minutes Interval between posts. 0 = Disable

Only one parameter is required: -h host. To install evtsys as a service, you must specify the -i parameter. And we are also interested in the -f option to change the default facility (system daemons) to local1.
Evtsys uses the digital facility designation, here is the list:

0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security / authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security / authorization messages
11 ftp daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)

choose the one you need, in our case it is 17 (local1) and forward, the whole command will look like this:
% WINDIR% \ System32 \ evtsys.exe -i -h [your Linux address with syslog] -f 17

If you want to exclude any event from sending to syslog, for example, a huge pile of garbage appearing about each connection to your computer over the network in the Security section, you can create a file (or open it if you have already started the service)% WINDIR% \ System32 \ evtsys. cfg and score events into it that you are not interested in in the EventSource: EventID format. For example, the line “Security-Auditing: *” will completely disable sending the Security section to Windows> Vista, the line “Security-Auditing: 4624” will disable sending only events with code 4624 (interactive access from the network to the computer, browsing it from someone from the network) . The sad irony is that when developing a new Event Log for a new generation of server OS, Microsoft completely changed the section names and codes, and also rewrote standard messages and all events in general, so that on Windows 2003 generation and Windows 2008 generation, the section names and numbers events will be radically different. But often they will have the same meaning. What event means and what names and numbers they have convenient to learn from the site http://www.eventid.net/ .

After that, you can open the list of Windows services and start a service called “Eventlog to Syslog” and the logs will start to appear in the file on the server with syslogd in approximately the following form:

# head -n 1 /var/log/local1.log
Jun 20 09:13:30 srv SRV Security-Auditing: 4634: An account was logged off. Subject: Security ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-2304319227-3176 Account Name: XXXXXX $ Account Domain: XXX Logon ID: 0x325f90ec Logon Type is 3. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

Conclusion

What else did I personally do and what can any administrator with regular expressions repeat?

For myself, I wrote on perl a looped parser of a going log which, of course, is not quite a readable log sheet:
a) bites out events that do not interest me: for example, all the same calls to a computer from a network (any browsing on a network of one computer causes all computers that it has in a networked environment to see a message about it, but this is really a big bunch of messages on servers especially if from several at once). It took me only one day to create a list of such “events that do not interest me”.
b) tints events that interest me and translates them from a technical form to a human one, for example, the login to the server via RDP is colored blue and not the full line is written from the log, like the one I mentioned above from which you still need to understand who was standing for “Remote login by 'xxx' (ip: xxxx) to 'XXX'”.

As a result, I got a console utility in which what interests me always is dedicated, and everything that happened except this will be written so that it is really possible to disassemble, understand and quickly respond. You can just occasionally glance throughout the day at the console in which the text rarely appears, but if something goes, you can immediately catch it. For example, recently, the DHCP pool began to come to an end at me, and I immediately found out about it when I saw a message from DHCP in the console (standing on the domain controller) that the DHCP-pool is 90% full, and not coming to work in two or three days and having learned that someone cannot get into the network.

In addition, the utility allows you to record in the database those events that I want to store and somehow handle.
For example, recently here (on Habré) there was an article about how to make statistics of who printed what, with a wild leapfrog over SNMP. In my case, this minor problem is part of the overall centralized logging task being solved, if the printer is connected to the server and shared, and logging is enabled on what is printed, it is not just solved, but solved more than fully. Indeed, in addition to the number of pages and ip addresses, it is written to the logs:

- who printed (login)
- document name

And this is already normal corporate statistics, and not empty numbers, and it settles in the database from where I give a detailed report at the end of the month to those interested who are just happy to see who, what, where, when and how much.

That's all that I wanted to say about this. It would be possible to start further rantings about the possibility of making an alert about events via e-mail and SMS, but I think that this topic is already superfluous. I wanted to describe the mechanism and tool for solving one of the most frequently encountered tasks in administering in a mixed environment and it seems to me that I was able to do this more than completely. Thank you for your attention and if you have read this far.