Перенаправление событий Windows (Event Log)

В данной заметке я покажу как настроить перенаправление событий системы Windows 7 на централизованный сервер хранения логов поднятый в одной из заметок на моём блоге.

В моём, случае я разберу установку для архитектуры x86

Узнать используемую у Вас ось можно, к примеру через консоль командной строки, для этого введите следующую строку:

C:\Users\ekzorchik>Wmic os get osarchitecture

По указанной ниже ссылке скачиваем пакет применительно к Вашей архитектуре :

Распаковываем скачанный файл и копируем файлы evtsys.dll & evtsys.exe в каталог c:\windows\system32\

Далее через командную строку запускаем evtsys . exe :

C:\Users\ekzorchik>cd /d c:\windows\system32

C:\Users\ekzorchik>evtsys.exe -i -h 172.16.128.69

Checking ignore file…

Jan 29 12:26:43 WTEST Error opening file: evtsys.cfg: The system cannot f

ind the file specified.

Jan 29 12:26:43 WTEST Creating file with filename: evtsys.cfg — И создаётся также конфигурационный файл evtsys.conf

Command completed successfully

Далее открываем оснастку управления службами для системы :

Старт – Панель управления – Администрирование – Службы и видим, появилась служба

“Eventlog to Syslog”, запускаем её:

Либо через командную строку:

c:\Windows\System32>net start evtsys

Служба «Eventlog to Syslog» запускается.

Служба «Eventlog to Syslog» успешно запущена.

Данная служба работает по принципу пересылки событий журнала Windows.

Размер журнала пересылаемого на централизованный сервер редактируется через ветку реестра : — HKLM\SOFTWARE\ECN\EvtSys\3.0\

Min send packets: (из доки Reame.rtf)

The maximum size of a Syslog message is defined as 1024 bytes. Anything beyond this threshold is truncated.

The “Eventlog to Syslog” service polls for messages every 5 seconds.

MaxMessageSize 0x00000400 (1024)

Max send Packets: (из доки Reame.rtf)

The maximum size of a Syslog message is defined as 1024 bytes. Anything beyond this threshold is truncated.

The “Eventlog to Syslog” service polls for messages every 5 seconds.

MaxMessageSize 0x00001000 (4096)

После перезагрузки (или ручного запуска сервиса evtsys) все журналы Windows будут передаваться в rsyslog нашего сервера и, соответственно, будут доступны в веб-интерфейсе LogAnalyzer.

К примеру, создадим в ручную событие в системе через командную строку:

C:\Users\ekzorchik>eventcreate /L Application /so TestMessage /t error /id 1 /d

«Тестовое сообщение с системы Windows 7 x86″

УСПЕХ: событие ‘error’ создано в журнале ‘Application’ с источником ‘TestMessage

Открыв web интерфейс консоли мониторинга видим сообщение :

Щелкаем по нему и видим подробную информацию

, как видите сообщения успешно пересылаются, на консоль мониторинга.

Вот собственно и весь процесс установки. На этом всё, удачного мониторинга.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще 🙂

Карта МКБ: 4432-7300-2472-8059
Yandex-деньги: 41001520055047

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Перенаправление сообщений из EventLog Windows на удалённый syslog

В предыдущей статье было показано как можно настроить сбор логов с различных серверов под управлением Linux и FreeBSD на один используя syslog. Однако что делать если в сети есть ещё и машина под Windows?

Возникает разумное желание так же собирать EventLog из Windows на тот же сервер, что и логи с остальных серверов. Далее будет рассмотрено одно из возможных решений этой задачи.

Начальные условия у нас практически такие же, как и в предыдущей статье, с одним дополнением: в сети присутствует один (или несколько — не суть важно) сервер под Windows.

Самым удобным решением этой задачи является вариант с отсылкой сообщений из EventLog Windows в syslog на сервере сбора логов. Для этого можно использовать инструмент evtsys, разработанный в Purdue Univercity.

Для установки нужно скачать архив со страницы проекта и распаковать его в директорию %systemroot%\system32 (Обычно это C:\Windows\system32).

После распаковки нужно запустить командную строку: «Пуск» -> «Программы» -> «Стандартные» -> «Командная строка». И выполнить в ней следующие команды:

Первыми двумя командами осуществляется переход в директорию с файлами утилиты, третья устанавливает evtsys как системную службу (она получит имя «Eventlog to Syslog»). Последняя команда запускает эту службу.

После этого системные логи из EventLog начнут дублироваться в удалённый Syslog.

Если по какой-то причине нужно удалить evtsys то в командной строке нужно выполнить следующие команды:

Здесь сначала останавливается служба, потом удаляется запись о ней из реестра системы и наконец удаляются сами файлы утилиты.

Отдельно нужно оговориться о том, что в русской версии Windows сообщения пересылаются в кодировке cp1251, потому для чтения логов на сервере сбора логов имеет смысл воспользоваться примерно такой командой:

Converting and Forwarding Windows Event Log via Syslog for Log Collection

Log collection requires working with a number of different formats and protocols. Windows Event Log does not communicate with Unix-based Syslog out of the box due to architectural and design differences. However, converting Windows Event Log data to Syslog can be very helpful for centralized log collection.

Windows Event Log

The history of Windows Event Log dates back to Microsoft Windows NT in 1993 with the initial introduction of logging on Windows systems. Over time, it has evolved to its current format and features, such as including support for defining the event source has been added. Windows Event Log is a proprietary binary format where the raw event log data can be translated into XML using the Windows Event Log API.

Windows Event Log uses message templates which are similar to format strings. Variable parts—such as the username or IP address—are denoted by the percent sign ( %1 , %2 , etc.) in the template. The actual log record only stores the template identifier and the variable fields. When viewing the logs, the Windows Event Log API renders this data by substituting the variable field values into the message. This has a number of benefits including localization and reducing the storage space required. However, the format becomes more complex and processing of event records can have a significant overhead.

Syslog

As the standard choice for Unix-based systems, administrators may have Syslog as part of an arsenal of tools to cover their log collection, aggregation, and management needs. Syslog is very common and can be ingested into other systems, stored in files, sent to other Syslog daemons over the network and more.

BSD Syslog

The original BSD Syslog format was developed in the 1980s. It later became the de facto standard logging system for Unix-based systems, and has been implemented across many operating systems and applications. In 2001, the protocol was officially documented by the Internet Engineering Task Force (IETF) in informational RFC 3164.

BSD Syslog uses a simple format comprised of three basic parts: priority, header, and message. BSD Syslog uses UDP as its transport layer.

IETF Syslog

Due to limitations in the BSD Syslog protocol, in 2009 the IETF released RFCs 5424, 5425, and 5426, which document a replacement for the «legacy» BSD Syslog. This IETF Syslog provides a higher-precision timestamp with year, optional structured data, and TLS transport as well as other improvements.

Snare Syslog

Snare Syslog is a Snare formatted message used with a Syslog header. Syslog with a Snare-formatted message is a simple way to send Windows Event Log data to many SIEMs.

Other Syslog Formats

There are many other log formats that use the Syslog header and define a specific syntax for the message field. Here are a few:

It is common to encapsulate JSON-formatted log data by adding a Syslog header, as covered in JSON over Syslog. This is an excellent way to send structured data over Syslog, and can be used with Windows Event Log.

The HP ArcSight Common Event Format (CEF) uses Syslog for transport. By converting Windows Event Log data to Syslog-encapsulated CEF, it can be sent to ArcSight products.

The LEEF log format, used by IBM QRadar Security products, also uses Syslog for transport.

Converting Windows Event Log to Syslog

Unlike Windows Event Log, Syslog stores the actual rendered text instead of using message templates. When Windows Event Log is converted to Syslog, the fields are mapped and concatenated into a Syslog-formatted string as a single line of text. This conversion allows the Windows events to be used with SIEM suites and other software tools that understand the Syslog format.

This configuration reads events from the Security channel, converts each event to the Snare format (with a Syslog header), and forwards the log data via TCP.

Журналирование Windows EventLog и система оповещения для администраторов

Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.

Microsoft своими «добрыми» технологиями сделала Windows практически несовместимым со штатными системами журналирования событий(syslog), но оставила небольшую лазейку которую можно использовать.
Лазейка представляет собой комбинацию SNMP trap и программы экспорта системных событий evntwin.

Для работы связки нужен настроенный snmptrapd, а также активированный сервис SNMP на windows сервере (добавляется через «добавление/удаление компонентов»).

Первым делом нужно настроить сервер на который будут сбрасываться сообщения из Eventlog.

После того как сервис настроен, запускаем программу evntwin.exe
technet.microsoft.com/en-us/library/cc759390%28WS.10%29.aspx
Как она выглядит видно на следующем скриншоте.

Принцип использования evntwin прост. Вы выбираете категорию и код события которые Вас интересуют и добавляете их в список. При наступлении события сообщение одновременно будет сохранено в EventLog, а также будет «трапнуто» на сервер мониторинга.

На сервере мониторинга в snmptrapd.conf нужно добавить строку обработчика.

1. authCommunity log,execute public
2. format1 Trap from %B
3. format2 Trap from %B
4. traphandle default /usr/ local /etc/trapd.pl

Сам обработчик написан мной на perl, код можно взять по ссылке trapd.pl(Не рекомендуется копипастить подсвеченный код из поста, лучше взять по ссылке). Он разбирает входящие trap сообщения и формирует письмо администраторам.

use vars qw / $hostname $source $oid @data $trap $error /;

my @indata = (<>);
$trap -> = shift(@indata);
$trap ->= shift(@indata);
$trap -> = shift(@indata);
(undef, $trap ->) = split (/ /, $trap ->, 2 );
$trap -> = shift(@indata);
open OUT, «>>/var/log/snmptrapd.log» ;
chomp( $trap ->);
chomp( $trap ->);
chomp( $trap ->);
chomp( $trap ->);
print OUT «Hostname: $trap->\n» ;
print OUT «Source: $trap->\n» ;
print OUT «Uptime: $trap->\n» ;
$trap -> =

s/(.*)\.(\d+)$/ $2 /g;
print OUT «OID: $trap->\n» ;
my $str = join( «» ,@indata);
$str =

s/\n+/\n/g;
my @data = split (/SNMPv2\-SMI\:\:enterprises\. 311 \. 1 \. 13 \. 1 \. 9999 \.\d+\. 0 \s/, $str );
undef $error ;
my $part = $data [ 1 ];
my @str = split(/\n/, $part );
$trap -> = $str [ 0 ];
$trap -> =

s/\:$ //;
$error = «Hostname: $trap->\n» ;
$error .= «Source: $trap->\n\n» ;
foreach my $line (@str)
<
if ( $line =

close OUT;
exit ( 0 );

sub mail_send
<
# my @arr = shift;
use Net::SMTP;
$smtp = Net::SMTP-> new ( ‘localhost’ );
$smtp ->mail( ‘security@nagios.mydomain.ru’ );
$smtp ->to( ‘account_admin@mydomain.ru’ );
$smtp ->data();
$smtp ->datasend( «To: account_admin\@mydomain.ru\n» );
$smtp ->datasend( «Subject: $trap->\n» );
$smtp ->datasend( «\n» );
$smtp ->datasend( $error );
$smtp ->dataend();
$smtp ->quit;
>

Hostname: bdc.mydoman.ru
Source: UDP: [192.168.0.3]:1081

Change Password Attempt:
Target Account Name:pupkin_v
Target Domain:MYDOM
Target Account ID:%
Caller User Name:pupkin_v
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x39B1BD)

Hostname: sadc.mydomain.ru
Source: UDP: [192.168.0.4]:1074

User Account Locked Out:
Target Account Name:ivanov_v
Target Account ID:%
Caller Machine Name:MX
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)

Hostname: sadc.mydomain.ru
Source: UDP: [192.168.0.4]:1072

Logon Failure:
Reason:Unknown user name or bad password
User Name:Popov_V
Domain:MYDOM
Logon Type:3
Logon Process:Advapi
Authentication Package:Negotiate
Workstation Name:SADC
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)
Caller Process ID:580
Source Network Address:192.168.0.20
Source Port:36018

Так как мы подписаны только на интересующие нас сообщения, мы не видим остального системного мусора из EventLog.
Очень удобна данная система при вирусных эпидемиях типа Kido, когда сразу нельзя понять откуда пошло всё размножаться или при брутфорсе системных паролей. Потому что чётко виден Logon Failure и имя машины с которой была неудачная попытка.

Спокойной Вам работы.
PS: готовый конфиг с представленными на скриншоте категориями лежит тут