Eventlog to syslog service for windows

Перейти к содержанию

Опубликовано 19.04.2022

Evtsys (Eventlog to Syslog Service for Windows) — написана на языке C и предоставляет метод отправки событий Windows Eventlog на сервер syslog. Она работает с новой службой Windows Events, появившейся в Vista и Server 2008, и может быть скомпилирована как для 32, так и для 64-битных сред.

Содержание

Установка Evtsys
Параметры командной строки
Настройка Evtsys

Установка Evtsys

Скачиваем последнюю версию Evtsys для своей системы (X86 или X64)
Распаковываем архив
Перемещаем файлы в C:WindowsSystem32
Запустить командную строку от имени администратора и перейти в директорию C:WindowsSystem32 и выполнить для начала сбора и пересылки журналов
```
evtsys.exe -i -h ip сервера
```
После чего запустит службу

Для проверки работы необходимо зайти в службы и руками проверить запустилась ли служба установить режим запуска автоматически

Для проверки отправки, возможно создать тестовое сообщение

eventcreate /L Application /so TestMessage /t error /id 1 /d "Test"

Параметры командной строки

-i Установить сервис
-u Удалить сервис
-d Дебаг. Запуститься как консольная программа
-h host Имя хоста куда отправлять логи
-b host Имя второго хоста кому дублировать логи
-f facility Facility логов
-l level Минимальный уровень отсылаемых сообщений 0=Всё, 1=Критические, 2=Ошибки, 3=Предупреждение, 4=Информация
-n Отправлять только эвенты включенные в конфиге
-p port Номер порта syslog
-q bool Опросить DHCP чтобы получить имя хоста syslog и порт (0/1 = включить/выключить)
-s minutes Интервал между сообщениями. 0 = Отключить

Настройка Evtsys

После установки в директории system32 появится конфиг evtsys.cfg

'!!!!THIS FILE IS REQUIRED FOR THE SERVICE TO FUNCTION!!!!
'
'Comments must start with an apostrophe and
'must be the only thing on that line.
'
'Do not combine comments and definitions on the same line!
'
'Format is as follows - EventSource:EventID
'Use * as a wildcard to ignore all ID's from a given source
'E.g. Security-Auditing:*
'
'In Vista/2k8 and upwards remove the 'Microsoft-Windows-' prefix
'In Vista/2k8+ you may also specify custom XPath queries
'Format is the word 'XPath' followed by a ':', the event log to search,
'followed by a ':', and then the select expression
'E.g XPath:Application:<expression>
'
'Details can be found in the readme file at the following location:
'https://code.google.com/p/eventlog-to-syslog/downloads/list
'**********************:**************************
XPath:Application:<Select Path="Application">*</Select>
XPath:Security:<Select Path="Security">*</Select>
XPath:Setup:<Select Path="Setup">*</Select>
XPath:System:<Select Path="System">*</Select>
XPath:Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational:<Select Path="Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational">*</Select>
XPath:Windows PowerShell:<Select Path="Windows PowerShell">*</Select>
XPath:Microsoft-Windows-Windows Defender/Operational:<Select Path="Microsoft-Windows-Windows Defender/Operational">*</Select>
XPath:System:<Kaspersky Event Log="Kaspersky Event Log">*</Select>

В файл конфигурации можно добавить сбор логов из любых журналов windows

Синтаксис выглядит следующим образом

Для добавления переслки логов PowerShell

XPath:Windows PowerShell:<Select Path="Windows PowerShell">*</Select>

Для добавления переслки логов Kaspersky Event Log

XPath:System:<Kaspersky Event Log="Kaspersky Event Log">*</Select>

Таким образом можем добавить пересылку любых журналов.

Источник

Вступление

Это статья предназначена для системных администраторов, которые знакомы с Linux и используют семейство этих систем в смешанной среде прекрасно осознавая что разные ОС хороши в разных задачах. Так же она будет интересна всем администраторам, даже тем, кто не знаком с линуксом, своей теоретической частью.

В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.

Реалии таковы, что в нынешней корпоративной среде самое эффективное и надежное решение основывается на смешении серверных операционных систем из-за качества и способов решаемых ими задач. Рабочие станции, и, следовательно, групповое ими управление и администрирование проще делать на Active Directory; веб сервер, прокси сервер надежнее поставить на линукс; роутером быстрее сделать что-то из Cisco. Эта объективная реальность, с которой работают администраторы многих средних компаний (особенно знакомые с линуксом, от винды так или иначе им все равно не уйти и зачастую в фирме стоят домен-контроллеры на винде и прокси-сервер и роутер на линуксе) — в мелких фирмах можно обойтись одной виндой, в крупной фирме скорее всего раздельно существует администратор линуксоид и администратор виндузятник умело отвечающие за свои сектора. Так или иначе, эта статья не теоретизирование и не исследование на эту тему, эта статья про конкретную задачу, которая практически всегда приходит в голову любому администратору работающему в таком окружении, а вступление что-то затянулось.

Описание

Каждый работающий с серверами знает и ежедневно пользуется системой логов на своих машинах и каждый знает как они устроены — syslog на Linux и Event Log на винде.

До эры Windows Server 2008 Event Log был странной системой созданной как-будто не для серверов — каждый компьютер писал и хранил свои события локально и удобных механизмов для передачи их по сети для централизованного просмотра или хотя бы хранения не было вообще. Ну, впрочем, всем это известно. Просмотр логов для серверов напоминал квест в MMORPG — исследуй несколько локаций и собери несколько предметов в каждой. Начиная с Windows Vista был сделан шаг навстречу людям и создана система форварда локальных событий на другие Windows >Vista компьютеры. Это хорошо и прогрессивно и это именно то чего не хватало, но реальность такова что на данный момент осталось и не устарело много серверов с Windows 2003 для которых таких механизмов так и нет или они есть, но отталкивают своей монстроузной реализацией.

С другой стороны существует простая и надежная система syslog для Linux которая изначально разработана для распределённой передачи и приёма логов и содержит в себе всё что для этого необходимо. Она настолько хорошо делает своё дело что возможность отправлять логи по этому протоколу встраивают и в хардварные роутеры и в кучу разных других устройств и вполне реально сделать в сети сервер который будет собирать все логи со всех устройств в сети: серверов, роутеров, коммутаторов, принт-серверов, кофеварок, кулеров, ой что-то я разошелся… Кроме Windows. Врядли найдётся человек которому не приходила в голову мысль что если бы Windows мог отправлять свои логи в syslog это было бы идеальным решением для централизации логохранилища. Как удобно было бы все иметь в одном месте — можно было бы и хранить годами, архивируя текстовые файлы (они отлично ужимаются), и обрабатывать, разбирая один текстовый файл от нескольких серверов вылавливая одно критическое событие сразу для нескольких машин.

Задался таким вопросом и я. Задался я им несколько лет назад и потерпел неприятное фиаско — утилит позволяющих это сделать-то довольно много, но выглядят они все как кошмар профессионального администратора — какие-то ужасные утилиты иногда на C# размеров в 100 мегабайт с тысячей кнопочек и чекбоксов и что самое неприятно — _все платные_. Не знаю в чем прикол, но несколько лет назад Google был переполнен ссылками на коммерческий софт с таким функционалом. При этом софт не высокого качества, судя по стремным сайтам и скриншотам. Переполнен он ими и сейчас, и, по моим собственным наблюдениям, многие отнюдь не ленивые и не тупые администраторы способные с успехом для собственного удобства использовать такой функционал так и не нашли того что им нужно и не знают что такое бывает. По крайней мере за мой совет и ссылку меня не раз благодарили, и теперь я хотел бы поделиться и с вами. А именно некоторое время назад (довольно давно, это статью я решил написать только сейчас), мне удалось найти проект идеально подходящий под мои нужды и требования:

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

Опишу вкратце его достоинства:
— это системный сервис, т.е. ничего не надо запускать при старте, никаких странных экзешников которые можно случайно по забывчивости убить при очередной чистке хлама на сервере;
— лаконичная поставка — .dll, .exe и краткая, но всеобъемлющая документация;
— открытый исходный код;
— версия 32-bit и 64-bit;
— одинаковая работа и версия на любых версиях Windows имеющих Event Log;
— минимум настроек (настолько минимум что это командная строка при установке сервиса и текстовый файл для работы, который можно не открывать вообще при желании);
— покрывающий максимум функционала — все что должна делать эта программа она делает — умеет отправлять логи в разные facility, умеет исключать определённые события из отправления и так далее, даже получать имя log сервера по dhcp.

Добавлю от себя что во-первых вот уже полгода как эта программа на 8-ми моих серверах и 2003 и 2008 просто работает, после установки я _ни разу_ ни на одном из них не проверял, не перезапускал обвалившийся, не ковырял, не изменял и даже не смотрел в сторону этого сервиса, который так же никак не повлиял ни на одно другое приложение, он просто делает своё дело после установки — безустанно шлёт эвенты туда куда ему сказали. А во-вторых что программа очень динамично развивалась не так давно набирая функционал, после чего стабилизировалась и теперь достаточно регулярно, но не слишком часто, выходят билды которые причесывают функционал и фиксят мелкие редковоспроизводимые баги.

Перейдём к ещё большей конкретике.

Настройка

Настройка syslog на линуксе.
Включите принятие логов из сети, это ключ -r у демона syslogd. По умолчанию он почти всегда не прописан и при запуске без него syslogd сеть не слушает.

Затем вам наверняка не очень понравится если логи линуксов, роутеров и винды будут смешиваться в одном файле и превращаться в трудновоспринимаемую кашу. Для этого в системе syslog есть несколько разделов (facility) и приходящие на отдельные facility сообщения можно писать в разные файлы. Так как логи от винды не особо подходят ни под kernel, ни под mail, специально для этого в syslog есть несколько “безличных” facility которые называются local. Чтобы вынести например local1 в отдельный файл надо добавить в /etc/syslog.conf строку:

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

ну и запомнить что это local под номером 1. точно так же можно разделить остальные local от local0 до local7.
Обращаю ваше внимание что это простейшая конфигурация syslog которая позволит просто складывать логи от винды в отдельный файл, тонкая конфигурация syslog позволяет довольно замысловато распределить сообщения приходящие к демону, но всё это описано в мануале к syslog и скорее всего известно любому знакомому с линуксом администратору.
Установка evtsys на Windows.

Установка элементарна — скачиваем дистрибутив, в нём .dll и .exe, копируем их в %WINDIR%System32
Запускаем .exe с нужными параметрами.

Параметры evtsys.exe:
-i Установить сервис
-u Удалить сервис
-d Дебаг. Запуститься как консольная программа
-h host Имя хоста куда отправлять логи
-b host Имя второго хоста кому дублировать логи
-f facility Facility логов
-l level Минимальный уровень отсылаемых сообщений
0=Всё, 1=Критические, 2=Ошибки, 3=Предупреждение, 4=Информация
-n Отправлять только эвенты включенные в конфиге
-p port Номер порта syslog
-q bool Опросить DHCP чтобы получить имя хоста syslog и порт
(0/1 = включить/выключить)
-s minutes Интервал между сообщениями. 0 = Отключить

Необходимым является всего один параметр: -h хост. Чтобы установить evtsys как сервис надо указать и параметр -i. А так же нас интересует параметр -f, чтобы сменить facility по умолчанию (system daemons) на local1.
Evtsys использует цифровое обозначение facility, вот список:

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)

выберите тот который вам нужен, в нашем случае это 17 (local1) и вперед, целиком команда будет выглядеть так:
%WINDIR%System32evtsys.exe -i -h [адрес вашего линукса с syslog] -f 17

Если вы хотите исключить какое-то событие из отправки в syslog, например огромную кучу мусора появляющуюся по поводу каждого подключения к компьтеру по сети в разделе Security, можете создать файл (или открыть, если уже запустили сервис) %WINDIR%System32evtsys.cfg и забить в него события которые вас не интересуют в формате EventSource:EventID. Например строка “Security-Auditing:*” полностью отключит отправку раздела Security на Windows >Vista, строка “Security-Auditing:4624” отключит отправку только события с кодом 4624 (интерактивный доступ из сети к компьютеру, браузинг его кем-то из сети). Грустная ирония такова что при разработке нового Event Log’а для нового поколения серверных ОС Микрософт полностью сменила названия разделов и коды, а так же переписала и стандартные сообщения и вообще все события, так что на поколении Windows 2003 и поколении Windows 2008 названия разделов и номера событий будут кардинально различаться. Впрочем зачастую у них будет одинаковый смысл. Какое событие что значит и какие у них названия и номера удобно узнавать с сайта http://www.eventid.net/.

После чего можно открывать список сервисов Windows и запускать сервис под названием “Eventlog to Syslog” и логи начнут появляться в файле на сервере с syslogd примерно в таком виде:

# 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: 3 This event is generated when a logon session is destroyed. 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.

Заключение

Что ещё сделал лично я и что сможет повторить любой знакомый с регулярными выражениями администратор.

Для себя я написал на perl зацикленный парсер идущего лога который из всё-таки не совсем удобочитаемой простыни лога:
а) выкусывает события которые меня не интересуют: например всё те же обращения к компьютеру из сети (любой браузинг в сети одного компа вызывает на всех компах которые он у себя в сетевом окружении увидит сообщение об этом, а это реально большая куча сообщений на серверах, особенно если сразу с нескольких). У меня ушёл всего один день на то чтобы создать список таких “не интересующих меня” событий.
б) подкрашивает события которые меня интересуют и переводит их из технического вида в человеческий, например логин на сервер по RDP окрашивается синим и пишется не полная строка из лога, навроде той что я привёл выше из которой ещё надо понять кто на ком стоял, а в виде “Remote login by ‘xxx’ (ip: x.x.x.x) to ‘XXX’”.

В результате чего я получил консольную утилиту в которой то что меня интересует всегда выделенно, а всё что произошло кроме этого будет написано так что это реально разобрать, понять и быстро отреагировать. Можно просто изредка посматривать на протяжении дня на консоль в которой довольно редко появляется текст, зато если что-то пойдёт — это сразу можно поймать. Например недавно у меня начал подходить к концу пул DHCP, и я сразу узнал об этом увидев в консоли сообщение от DHCP (стоящем на домен контроллере) о том что DHCP-pool is 90% full, а не придя на работу через два-три дня и узнав что кто-то не может попасть в сеть.

Кроме того, утилита позволяет записывать в базу те события которые я хочу хранить и как-то обрабатывать.
Например недавно тут (на хабре) была статья о том как сделать статистику того, кто что распечатал, с дикой чехардой по SNMP. В моем же случае эта незначительная проблема входящая в общую решаемую задачу централизированного логирования, если принтер подключен к серверу и расшарен, и на нём включено логирование того что напечатано, не просто решается, а решается более чем полно. Ведь в логи кроме количества страниц и ip адреса, пишется:

— кто распечатал (логин)
— имя документа

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

Вот собственно и всё что я хотел сказать по этому поводу. Можно было бы пуститься в дальнейшие разглагольствования про возможность наделать оповещение о событиях по е-мейл и смс, но я считаю это что эта тема уже лишняя. Я хотел описать механизм и инструмент для решения одной из часто встречающихся задач в администрировании в смешенном окружении и мне кажется смог это сделать более чем полно. Спасибо за внимание и если дочитали до этого места.

Источник

This project is a fork of the eventlog-to-syslog project. This started live as part of an internal project to monitor who was logged in where and when and I wasn’t actually planning on releasing it — but here it is.

The main difference is that treats windows auth events differently. If you are a windows admin you know how many auth events happen on a windows server. This version of EvtSys condenses these auth messages so they only include the username, workstation and ip address of the auth event. It also makes an attempt (a lazy one) to filter out service type logins to further reduce spam.

The second big difference is that there is an installer — the nsis is included in the source. You can use the installer to install & configure the service, or you could mod the NSIS script with your settings and make a silent installer

Config Changes (evtsys.cfg)

While the format remains largely unchanged there are two key differences

Include and exclude supported in the same file
Additional field on xpath lines to define behavior

There are two line formats in the evtsys.cfg file — Include and Exclude

Include lines start with «XPath» and are in the form

XPath:[default|login]:<Application>:<XPath statement>

Note the XPath has the same limitations that apply when filtering the eventlog using the Event Viewer.

You may find it helpful to use the Create Custom View with in Event Viewer to create the XPath Expression

Exclude lines simple have an application and the event ID

<Application>:<EventID>

Example Config — Ignores some common/frequent SQL events

MSSQL$MICROSOFT##SSEE:17137
MSSQL$MICROSOFT##SSEE:2803
MSSQL$MICROSOFT##SSEE:18264
MSSQL$MICROSOFT##SSEE:3197
MSSQL$MICROSOFT##SSEE:3198
XPath:default:Application:<Select Path="Application">*</Select>
XPath:login:Security:<Select Path="Security">*[System[(EventID=4624 or EventID=4634)]]</Select>
XPath:default:Setup:<Select Path="Setup">*</Select>
XPath:default:System:<Select Path="System">*</Select>

Источник

Прочитано:
2 718

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

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

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

C:Usersekzorchik>Wmic os get osarchitecture

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

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

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

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

C:Usersekzorchik>cd /d c:windowssystem32

C:Usersekzorchik>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:WindowsSystem32>net start evtsys

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

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

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

Размер журнала пересылаемого на централизованный сервер редактируется через ветку реестра: — HKLMSOFTWAREECNEvtSys3.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.

HKLMSOFTWAREECNEvtSys3.0

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.

HKLMSOFTWAREECNEvtSys3.0

MaxMessageSize 0x00001000 (4096)

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

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

C:Usersekzorchik>eventcreate /L Application /so TestMessage /t error /id 1 /d

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

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

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

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

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

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

Источник

winlogd

Windows EventLogs to Syslog Forwarder

Getting Started

a) Copy executable to a folder
b) Using Task Scheduler, make a new Task to start on system startup (like a service)

Prerequisites

.NET Framework 4.7.2

Installing

a) Copy executable to a folder

b) Using Task Scheduler, make a new Task to start on system startup (like a service)

Can be used as simple console app.

winlogd -h

winlogd V:1.0.0. EventLog to Syslog Forwarder Daemon.


Options:
  -h --help     Show this help.
  -v --verbose  Verbose mode.
  -d --daemon   Run program without exit.
  -t --test     Test mode, doesn't forward events.
  -V --version  Show program version

Parameters:
  -s --server   [ip|name]   Syslog server address to forward.
  -p --port     [int]       Syslog server port to forward.
  -l --level    [level,...] Levels to forward:
                                Info     -> Informational Event
                                Warning  -> Warning Message
                                Error    -> Error Message
                                AuditOk  -> Success Audit
                                AuditFail-> Failure Audit Event
                                All      -> Any Event. Must be alone

Authors

Ramón Ordiales Plaza

License

This project is licensed under GNU 3.0 — see the LICENSE.md file for details

Acknowledgments and Notes

Original winlogd was a windows service written on c++ ten years ago.
Microsoft changed EventLog Access Permissions (starting with Windows Vista)
So, a new program becomes necessary to achieve same results.
Other free software available have a GUI.
With the wide availability of Windows Server CORE / NANO where no GUI is available, a simpler solution is necessary.
Porting to .NET Core is not possible, (as far I know) Security permission to audit Event Logs are not available in.NET CORE 3.0

Источник

Содержание

Перенаправление событий Windows (Event Log)
Перенаправление сообщений из EventLog Windows на удалённый syslog
ИТ База знаний
Полезно
Навигация
Серверные решения
Телефония
Корпоративные сети
Syslog серверы
Syslog сообщения
Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью
Задача
Выбор софта
Формат сообщений и legacy
Альтернатива протоколу syslog: RELP
Конфигурация rsyslog
Обработка сообщений
Примеры конфигурации
Клиент: пересылка логов с сохранением имени файла
Чтение лог-файлов, заданных через wildcard
Многострочные сообщения
Сервер
Надёжная доставка сообщений. Очереди
Отказоустойчивость
Взаимодействие с logrotate
Логи, которые пишет сам rsyslog
Логи, записываемые приложением и считываемые rsyslog
Перенаправление событий Windows (Event Log) на сервер syslog Linux
Вступление
Описание
Настройка
Заключение

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

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

C:Usersekzorchik>Wmic os get osarchitecture

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

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

C:Usersekzorchik>cd /d c:windowssystem32

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:WindowsSystem32>net start evtsys

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

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

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

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)

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

C:Usersekzorchik>eventcreate /L Application /so TestMessage /t error /id 1 /d

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

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

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

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

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

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

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

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

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

Карта МКБ: 4432-7300-2472-8059

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

Источник

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

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

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

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

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

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

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

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

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

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

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

laptop

Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.

Syslog серверы

Syslog сообщения

Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение.

Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog’а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».

	Emergency	Система не работоспособна
1	Alert	Система требует немедленного вмешательства
2	Critical	Состояние системы критическое
3	Error	Сообщения об ошибках
4	Warning	Предупреждения о возможных проблемах
5	Notice	Сообщения о нормальных, но важных событиях
6	Informational	Информационные сообщения
7	Debug	Отладочные сообщения

Недостатки syslog

У протокола syslog есть несколько недостатков.

Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам.

Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.

Онлайн курс по Linux

Источник

Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью

Задача

Передавать лог-файлы на центральный сервер:

Условия: в инфраструктуре используются только Linux-сервера.

Выбор софта

Зачем вообще нужен syslog-сервер, когда есть elastic beats, logstash, systemd-journal-remote и ещё много новых блестящих технологий?

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

Формат сообщений и legacy

Syslog появился в 80-х, и быстро стал стандартом логирования для Unix-like систем и сетевого оборудования. Стандарта не было, все писали по принципу совместимости с существующим софтом. В 2001 IETF описал текущее положение вещей в RFC 3164 (статус «informational»). Т. к. реализации очень отличаются, то в частности в этом документе сказано «содержание любого IP пакета отправленного на UDP порт 514 должно рассматриваться как сообщение syslog». Потом попробовали стандартизировать формат в RFC 3195, но документ получился неудачным, для него в данный момент нету ни одной живой реализации. В 2009 приняли RFC 5424, определяющий структурированные сообщения, но этим редко кто пользуется.

Вот тут можно прочитать, что обо всём этом думает автор rsyslog Рейнер Герхард (Rainer Gerhards). Фактически, по-прежнему все реализуют syslog как попало, и задача интерпретировать всё это разнообразие ложиться на syslog-сервер. Например, в rsyslog включен специальный модуль для разбора формата, используемого CISCO IOS, ну и для самых плохих случаев начиная с пятой версии можно определять собственные парсеры.

Сообщения syslog при передаче по сети выглядят примерно так:

Альтернатива протоколу syslog: RELP

Если сообщения пересылаются между хостами, использующими rsyslog, можно вместо plain TCP sysog использовать RELP — Reliable Event Logging Protocol. Был создан для rsyslog, сейчас поддерживается и некоторыми другими системами. В частности, его понимают Logstash и Graylog. Для транспорта использует TCP. Может опционально шифровать сообщения с помощью TLS. Надёжнее plain TCP syslog, не теряет сообщения при разрыве соединения. Решает проблему с многострочными сообщениями.

Конфигурация rsyslog

В отличии от второй распространённой альтернативы, syslog-ng, rsyslog совместим с конфигами исторического syslogd:

Начиная с шестой версии, появился си-подобный формат RainerScript, позволяющий задавать сложные правила обработки сообщений.

Т. к. всё это делалось постепенно и с учётом совместимости со старыми конфигами, то в итоге получилась пара неприятных моментов:

Чтобы не спотыкаться об эти тонкости (да, в документации они описаны, но кто же её целиком читает?), стоит следовать простым правилам:

Подробнее про формат конфига здесь.

Обработка сообщений

Примеры конфигурации

Клиент: пересылка логов с сохранением имени файла

Теперь создадим RuleSet, который будут использоваться для передачи логов по сети. Его можно будет присоединять к Input, читающим файлы, или вызывать как функцию. Да, rsyslog позволяет вызвать один RuleSet из другого. Для использования RELP надо сначала загрузить соответствующий модуль.

Теперь создадим Input, читающий лог-файл, и присоединим к нему этот RuleSet.

В случае, если какое-то приложение пишет в общий syslog с определённым тегом, и мы хотим как сохранять это в файл, так и пересылать по сети:

Последний stop нужен, чтобы прекратить обрабатывать эти сообщения, иначе они попадут в общий syslog. Кстати, если приложение умеет выбирать другой unix socket для syslog, кроме стандартного /dev/log (nginx и haproxy так умеют), то можно с помощью модуля imuxsock сделать для этого сокета отдельный Input и прицепить к нему нужный RuleSet, не разбирая логи из общего потока по тегам.

Чтение лог-файлов, заданных через wildcard

Программист: Не могу найти на лог-сервере логи somevendor.log за начало прошлого месяца, посмотри плиз.
Девопс: Эээ… а мы разве пишем такие логи? Предупреждать же надо. Ну в любом случае всё старше недели логротейт потёр, если мы его не сохраняли — значит уже нету.
Программист: бурно возмущается

Вайлдкарды поддерживаются только в режиме работы imfile inotify (это режим по-умолчанию). Начиная с верcии 8.25.0, вайлдкарды поддерживаются как в имени файла, так и пути: /var/log//.log.

Многострочные сообщения

Для работы с лог-файлами, содержащими многострочные сообщения, модуль imfile предлагает три варианта:

Сервер

Надёжная доставка сообщений. Очереди

Для некоторых Actions выполнение может иногда тормозить или приостанавливаться, например пересылка логов по сети или запись в базу. Чтобы не терять сообщение и не мешать работать следующим Actions, можно использовать очереди. Каждому Action всегда сопоставлена очередь сообщений, по умолчанию это Direct Queue нулевого размера. Ещё есть основная очередь для поступивших из всех Input сообщений, её тоже можно настраивать.

RuleSet на клиенте с очередью будет выглядеть так:

Теперь можно спокойно перезугружать лог-сервер — сообщения сохраняться в очереди и будут переданы, когда он станет доступен.

ВНИМАНИЕ: При передачи сообщений из очереди после восстановления сети их относительный порядок может нарушаться (спасибо zystem за комментарий). Автор rsyslog ответил, что это ожидаемое поведение, подробнее можно почитать тут: http://www.gerhards.net/download/LinuxKongress2010rsyslog.pdf (section 7 «Concurrency-related Optimizations»). Вкратце: попытка сохранить строгий порядок сообщений при многопоточной обработке очереди приводила к падению производительности из-за необходимости блокировок потоков; понятие строгой последовательности сообщений может не иметь смысла для некоторых типов транспорта, многопоточных генераторов и приёмников сообщений.

Отказоустойчивость

Можно настроить Action для выполнения только в случае, если предыдущее Action было приостановлено: описание. Это позволяет настраивать failover конфигурации. Некоторые Actions используют транзакции для увеличения производительности. В таком случае, успех или неудача будут известны только после завершения транзакции, когда сообщения уже обработаны. Это может приводить к потере части сообщений без вызова failover Action. Чтобы такого не происходило, надо ставить параметр queue.dequeuebatchsize=»1″ (по-умолчанию 16), что может снизить производительность.

Эту возможность я пока не пробовал в продакшене.

Взаимодействие с logrotate

Логи, которые пишет сам rsyslog

Логи, записываемые приложением и считываемые rsyslog

Для приложений, способных переоткрывать файлы по запросу(SIGHUP или что-нибудь ещё), дополнительная конфигурация не требуется. rsyslog заметит изменения inode файла и переоткроет его.

Получилась достаточно гибкая и удобная конфигурация. Логи передаются как из файлов, так и из syslog. Многострочные сообщения передаются корректно. Перезагрузка лог-сервера не вызывает потерю данных. Для добавления новых логов достаточно обновить конфигурацию клиента, сервер трогать не надо.

Работает для rsyslog v8, на более ранних версиях не проверялась. Для Ubuntu есть официальный ppa adiscon/v8-stable. Для CentOS/RHEL можно использовать официальный репозиторий.

UPD: Добавлено замечание о нестрогом сохранении порядка сообщений при использовании очередей, спасибо zystem.

UPD2: Добавлена секция о взаимодействии с logrotate.

Источник

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

Вступление

Описание

Перейдём к ещё большей конкретике.

Настройка

Заключение

Что ещё сделал лично я и что сможет повторить любой знакомый с регулярными выражениями администратор.

— кто распечатал (логин)
— имя документа

Источник

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

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

%SystemDrive%
cd %SystemRoot%System32
evtsys -i -h 192.168.2.1
net start evtsys

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

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

%SystemDrive%
cd %SystemRoot%System32
net stop evtsys
evtsys -u
del evtsys.*

iconv -f cp1251 192.168.2.201-notice.log | less

На этом всё. Приятной работы!

Источник

Despite Syslog’s popularity, Windows OS does not natively support sending event log data to a Syslog server. This is what SolarWinds Event Log Forwarder for Windows does.This free tool provides users the ability to collect Windows events on a syslog server for storage and analysis with other log sources.. It uses subscription-based filters that forward Windows events as a syslog to one or more Syslog servers.

Contents

Installation
Configuration
- System Errors
- Service Stop
Summary

Author
Recent Posts

Travis Roberts is a Cloud Infrastructure Architect at a Minnesota based consulting firm. Travis has 20 years of IT experience in the legal, pharmaceutical and marketing industries, and has worked with IT hardware manufacturers and managed service providers. Travis has held numerous technical certifications over the span of his career from Microsoft, VMware, Citrix and Cisco.

Syslog is a centralized logging service that began with Unix servers in the early days of computing. It has become the preferred logging method for many networking, security, and Linux environments. If you have more than a handful of routers, switches, firewalls, or Linux servers, there is likely a Syslog server somewhere in the environment.

A Syslog server acts as a central repository for logging messages. While a service like an SNMP server polls a client for information, a Syslog server is a listener. Clients send data to the server over UDP on port 514, with TCP options also available.

Installation

The environment I tested in consisted of Windows 2016 and 2019 servers. SolarWinds Kiwi Syslog Server was used to collect Syslog data. Installing SolarWinds Event Log Forwarder for Windows was as easy as it gets. The download contains both an executable and MSI installer. It was nice to see options to fit most automatic deployment scenarios. The installation was straightforward and only required input for installation location and icon placement.

Configuration

The Event Log Forwarder Dashboard has three tabs for simple configuration: Subscriptions, Syslog Servers, and Test.

Subscriptions – The subscriptions tab gives the user granular control over the data sent to the Syslog server. Each subscription specifies which logs and event details to forward, including keyword filters and exclusion criteria. This level of control limits unnecessary noise from entering the logging server.

Syslog Servers – This is the Syslog server that receives the forwarded events. Multiple servers can be configured, defined by hostname or IP and port number. The protocol can be changed if the Syslog server supports TCP.

Test – This tab writes sample events to the event log to test functionality. This is beneficial for verifying the configuration.

Below are examples of setting up the SolarWinds Event Log Forwarder for system errors and stopped service events.

System Errors

In this example, let’s configure SolarWinds Event Log Forwarder for Windows to send all error events from the system event log to the Syslog server. Start by opening Event Log Forwarder and clicking Add under Subscriptions.

Add Subscription

Select System in the Select Event Logs pane. Uncheck the event types Warning and Information. This filters out warning and informational messages. Notice the other filtering options available for fine-tuning the events forwarded to the Syslog server. There is also an option to show events matching the filter at the bottom of the screen. Click Next to configure the Syslog facility.

Forward system log errors

The Syslog facility is configured under Define Priority. Syslog facilities define which system created the message and are used to filter messages on the Syslog server. Syslog has its origins in Unix systems, and the list of facilities map to names of Unix processes. In this example, the Syslog facility is left as Kernel (messages). Click Finish to return to the dashboard.

Security log subscription priority

Give the subscription a new name by selecting it from the list of subscriptions and clicking Rename.

System log errors

Once the subscription is named, move to the Syslog Servers tab. Add one or more Syslog servers from this location. Syslog servers can be edited, disabled, or removed from this tab. The Syslog Server IP or hostname is required in this section, along with the port and protocol if the Syslog server is not using the default UDP port 514. Click Add to add the Syslog server.

Add Syslog Server

Enter the name of the server and modify the IP address, port, and protocol if needed. Notice that there are multiple options under Server Address. After the information is entered, click Create to finish setting up the server.

Server address options

SolarWinds Event Log Forwarder for Windows includes a test feature that generates a test event in the Event Log. In the Test tab, select System for the event log and Error for the type.

Configure test

Click Create a test event to finish. If configured correctly, the Event Log Forwarder will send the event to the Syslog Server. Below is the message logged to SolarWinds Kiwi Syslog Server for this example.

Event message test

Service Stop

The next example configures a subscription to forward Security Event 4689 to the Syslog server. This is the process termination event created when a service stops.

Service starts and stops are not logged to the event log by default and need to be enabled in the Local Security policy. Start by enabling success and failure of Audit Process Termination. This is configured in the Local Security Policy under Advanced Audit Policy Configuration, System Audit Policies, Detailed Tracking. Alternatively, use Group Policies to enforce the setting on multiple servers in Active Directory environments.

Local Security Policy

Create a new subscription for Security Event 4689 once auditing is enabled. Go to Subscriptions and click Add.

Add Subscription

Select Security under Event Viewer (Local). In the Include or Exclude Event field, enter 4689. Notice the granular filtering options available. If multiple Event IDs are needed, add them in this field, separated by commas, as well as ranges of Event IDs. Exclude Event IDs by specifying the minus sign before the ID. Once finished, the Add Event Log Subscription will look like the screen shown below. Click Next to continue.

Security Log Subscription

Leave the Syslog facility as Kernel and click Finish. Give the subscription a descriptive name.

Test the subscription by restarting a service. Go to Computer Management and to Services and Applications, Services. In this example, the Printer Spooler will be restarted to demonstrate the Syslog subscription. Restart the service.

The message sent by the Event Log Forwarder to the SolarWinds Kiwi Syslog Server shows details from the event log, shown below.

Syslog Spool Message

Summary

SolarWinds Event Log Forwarder is a useful free tool for sending Event Log data to a Syslog server. Environments that use Syslog servers as the primary monitoring and log collection tools will appreciate the ability to send Windows event log data to the Syslog server. The tool can be used for one-off alerts or as part of large-scale logging and alerting solution.

As with any monitoring system, tuning is required. Event Log Forwarder makes tuning easy with several filtering configuration options. Filtering at the client level prevents unnecessary noise from reaching the server.

Subscribe to 4sysops newsletter!

For more advanced log collection with built-in analytics, check out SolarWinds Log Analyzer. Log Analyzer collects a variety of logs, including Syslog, SNMP traps, VMware and Windows Events, and streams them for real-time visualization. Download a free 30-day trial of Log Analyzer here.

Источник

Установка Evtsys

Параметры командной строки

Настройка Evtsys

Вступление

Описание

Настройка

Заключение