Время на прочтение8 мин
Количество просмотров72K
Вступление
Это статья предназначена для системных администраторов, которые знакомы с 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%\System32\evtsys.exe -i -h [адрес вашего линукса с syslog] -f 17
Если вы хотите исключить какое-то событие из отправки в syslog, например огромную кучу мусора появляющуюся по поводу каждого подключения к компьтеру по сети в разделе Security, можете создать файл (или открыть, если уже запустили сервис) %WINDIR%\System32\evtsys.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 адреса, пишется:
— кто распечатал (логин)
— имя документа
А это уже нормальная корпоративная статистика, а не пустые цифры, и она оседает в базе откуда я в конце месяца сдаю подробный отчет заинтересованным лицам которые просто счастливы видеть кто, что, где, когда и сколько.
Вот собственно и всё что я хотел сказать по этому поводу. Можно было бы пуститься в дальнейшие разглагольствования про возможность наделать оповещение о событиях по е-мейл и смс, но я считаю это что эта тема уже лишняя. Я хотел описать механизм и инструмент для решения одной из часто встречающихся задач в администрировании в смешенном окружении и мне кажется смог это сделать более чем полно. Спасибо за внимание и если дочитали до этого места.
Прочитано: 3 763
В данной заметке я покажу как настроить перенаправление событий системы Windows 7 на централизованный сервер хранения логов поднятый в одной из заметок на моём блоге.
В моём, случае я разберу установку для архитектуры x86
Узнать используемую у Вас ось можно, к примеру через консоль командной строки, для этого введите следующую строку:
C:\Users\ekzorchik>Wmic os get osarchitecture
По указанной ниже ссылке скачиваем пакет применительно к Вашей архитектуре:
http://code.google.com/p/eventlog-to-syslog/downloads/list
Распаковываем скачанный файл и копируем файлы 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.
HKLM\SOFTWARE\ECN\EvtSys\3.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.
HKLM\SOFTWARE\ECN\EvtSys\3.0\
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 интерфейс консоли мониторинга видим сообщение:
Щелкаем по нему и видим подробную информацию
, как видите сообщения успешно пересылаются, на консоль мониторинга.
Вот собственно и весь процесс установки. На этом всё, удачного мониторинга.
Understanding the event log is essential in every Windows system and plays a key role in the tasks of all Windows administrators. In addition to providing security, Windows event logs can serve as a valuable resource for troubleshooting purposes.
Log messages are incredibly helpful for troubleshooting and often are the first indication that something is wrong. Although system status signals are generated by every program and operating system, for decade’s administrators would struggle to sort through all of them for valuable insights.
Threat prevention has been transformed thanks to the introduction of Security Information and Event Management (SIEM). As a result, now everyone is eager to gather and store every log message that is generated by all systems.
Two important standards for log messages exist Windows Events and Syslog. Open standard Syslog is often seen on Linux systems. As with other Microsoft-developed standards, Windows Events adhere to a strict set of guidelines. The Windows Event log format is used by third-party programs operating on Windows. Similarly, some software developers choose to use the Syslog message standard.
Log collectors and receivers
Because Windows Events and Syslog log messages must be merged, a bridge between the two types of log messages is required. A log message manager on a Windows system will collect and store all Windows Events log messages but will disregard Syslog messages that could be created on other parts of the network. In the same way, a Linux log file manager would capture and store Syslog messages but not Windows Event log messages, for example.
To administer both Windows and Linux computers, a systems administrator must maintain at least two distinct log stores — one for Windows Events and one for Syslog messages. This is not an ideal situation for detecting intrusions. Either Windows Event messages must be changed to Syslog format, or Syslog messages must be converted to Windows Event message format, is the answer to this issue. Any of these approaches would allow a single analytical tool to sift through all system messages stored in common files.
Converting Windows Events and Syslog messages to a neutral format is a third way to consolidate them. Even if Windows Events are transmitted to a Syslog server or a third-party aggregation application known as Event log forwarding, the process of delivering such events is known as event log forwarding.
Event log forwarders and servers
On your computer, the event log forwarder will be running at all times. There’s no requirement for the log server and consolidator to be on your premises at all. You may use a log server that is installed on your premises, or you can use one that is hosted in a cloud-based service.
Some of the hosted systems include the log collector, which is the Event log forwarder. It is still necessary to deploy the log collector on a Windows server at your site in these circumstances. “Agent” is the word of choice.
One of your Linux computers must have a Syslog forwarder installed to consolidate data from Windows and Linux environments. A Linux-based agent is also included in SaaS log file management solutions. The log collector/forwarder and the log server will still be different packages if you operate the log file server on your site. As a central repository for all log messages, the server may handle both Windows Events and Syslog.
Free event log forwarders and log consolidator
Event log forwarders and log servers and consolidators may be found for free, so you don’t have to pay for them. When selecting two services, make sure that they are compatible with each other. The chance of mismatch between Windows Events and Syslog is low since both are well-known standards. Just in case, it’s always a good idea to verify compatibility.
Event log forwarders and logging file servers purchased from the same vendor eliminate any risk of incompatibility. As a result, this is the approach we’ll use throughout this manual.
These are the ones I’d like to point out:
- SolarWinds Event Log Forwarder for Windows – FREE TOOL
- Kiwi Syslog Server Free Edition – FREE TOOL
- ManageEngine EventLog Analyzer – FREE TRIAL
- ManageEngine Log360 Cloud – FREE TRIAL
To cope with the mismatch between log file formats, we will transform Windows Event Log messages into a Syslog format and then transmit them to a Syslog server, as the titles of these two programs suggest. A Linux-based log message collector may also send Syslog messages to the server.
The following operating systems are compatible with both of these programs:
- Microsoft Windows Server 2016 / Windows 10
- XP, Vista, 7, 8, and 8.1
- Windows 10 is the latest version of the operating system
- Windows 8.1 is the most recent version of the operating system
- Microsoft Windows 8
These versions of Windows will also run the Event Log Forwarder:
- There are two versions of Windows 7 available: Windows 7 SP1 and Windows 7 SP1
- Service Pack 2, Service Pack 3 (SP3), and Service Pack 1 (SP1) are all versions of Windows Server 2008 that are supported
- Service Pack 2 (SP2) for Windows Server 2003 R2
Let’s get started with the installation of these two programs.
Install SolarWinds event log forwarder for Windows
SolarWinds offers a free download of the Event Log Forwarder. Event log messages may only be retrieved from computers that have the software installed. The page may be accessed by clicking the Download button.
SolarWinds Event Log Forwarder
FREE Tool
Enter your e-mail address and select the “Proceed to Free Download” button on the access page.
The SolarWinds Log Analyzer will be made available to you as a 30-day free trial. Following, you’ll see a button labeled “Download Now” on the next page, whether or not you accept this offer.
SolarWinds Log Analyzer
Start a 30-day FREE Trial
The zip file may be downloaded by clicking on the button. The folder may be opened after the download is complete. Zip the files up and then unzip them.
In the second folder, double-click on the installation. You’ll be prompted by Windows to provide access to launch the file. Click the “OK” button to confirm your action. This will open a wizard to guide you through the installation process. Click the Next button once you’ve agreed to the terms and conditions and have gone through the installation process. On the last page of the installation, click Finish to complete the process.
Set up the event log forwarder
The Event Log Forwarder may be opened by clicking on its Start menu or Desktop icon when the installation process has finished. Before the service starts, Windows will ask for your permission.
When you initially launch the system, you’ll see a giant blank panel on the Dashboard.
Specify even collection parameters
Adding a message type to the collector is required before it can begin collecting data.
The Add button is located at the top of the panel.
The events that are sent to the Syslog server may be narrowed down using the Event Type selection screen. Traffic will be reduced as a result. However, you may be compelled to submit all events if you are collecting log data for a SIEM system.
Filters for messages may be seen by hitting the Show preview of matching event records button, which can be found beneath the left panel on the screen.
Log records may be obtained in three ways. The first step is to specify the log message sources from which you want to gather data. The left panel of the screen shows a hierarchical structure that enables this. Select all events by checking the box at the top of the hierarchy. A drop-down list of event sources may be used to fine-tune this filtering approach. Here you’ll find a breakdown of the systems in the left-hand panel that you chose.
The Add screen’s main panel has a second filter at the very top. These incidents may be collected in a variety of ways, depending on how serious they are. Error, Warning, and Information-level messages may all be collected here.
Selecting certain task categories, user accounts, or machines for which log entries should be extracted is possible using a third filtering approach. To utilize the Task Category option, you must have a list of IDs. As a result, to take advantage of this functionality, you’ll need to know the unique IDs for all of the different types of log data you wish to gather. The task categories are selected from a drop-down menu, which by default all of the categories have ticked. After you pick event sources in the left-hand panel, this list will be updated with events.
If you want to exclude or include a certain work category, you may use the task category ID in the area above the drop-down list. All events, except for a specific list, may be logged by placing a negative sign in front of each event type’s ID.
After selecting an event source, click the Next button to go on to the next step. Define Priority is where you’ll find this option.
By default, all events are sent to a syslog server using this facility (s). Using this and the Event Type on each message, the Priority value will be applied to each record when it is translated to the Syslog standard.
To return to the main screen, click on the “Finish” button at the bottom.
The primary detail panel of the Dashboard’s Home screen has been updated to include a new entry.
Specify a Syslog Server
Afterward, you must tell the Event Log Forwarder where it should deliver the transformed event logs to. Click on “Syslog Servers” in the main panel at the top of the screen to open the window Activate the Add button by clicking it.
Enter the Syslog server’s IP address in the Add Syslog Server dialogue box. It is necessary to provide the IP address provided in the service’s setup instructions when using a SaaS system for log file consolidation. To use a Syslog server installed on a computer, you must provide the IP address of that machine. Port and Protocol are industry-standard values, so leave them alone.
If you have many Syslog servers, you may give each one its unique name in the Server Name column. For a single Syslog Server on your Dashboard, the name doesn’t matter much since you won’t need to differentiate between the entries that display on the Home page.
To return to the Dashboard’s main page, click the Create button.
The Event Log Forwarder’s settings should be checked
Click on the Test tab in the Event Log Forwarder’s main page to verify that the collector’s setup was successful. Using the drop-down menu under the Event logs section, choose a kind of event to which a test event should be added. Go for it and choose “All.” Select an event kind, such as a warning, in the second field.
To begin the test, click on the icon labeled “Create a test event.” You should be notified of either a success or a failure.
Use a Syslog Server
You’ve finished setting up your Event log forwarder now. This message forwarding mechanism requires the installation of a Syslog server, though. It is recommended that you use the SolarWinds Syslog Server Free Edition.
A form is required to get this server, which is the same form that you filled out to acquire the Event Log Forwarder.
Download and unzip the service, then execute the setup wizard to install the Syslog server on your computer or server.
Run a test in the Event Log Forwarder to see whether the Syslog Server is configured appropriately. This message should display in the dashboard after the Kiwi Syslog Server is up and running.
Alternatives to Kiwi Syslog Server
ManageEngine EventLog Analyzer – FREE TRIAL
ManageEngine EventLog Analyzer has a Free edition, so it makes a strong alternative to the Kiwi Syslog Server Free Edition. This package can collect Syslog messages, however, it can also collect Windows Event logs, so you wouldn’t have to worry about converting your Windows Events into Syslog with this service.
This package provides a great deal more than just log collection – it files logs and also displays them in a data viewer, which includes analytical tools.
The package also includes a threat hunting service. This applies pre-written searches to incoming log messages and identifies intruders. The service also implements file integrity monitoring, recording which user accessed which files.
The dashboard displays statistics about log arrival rates. These are also shown by log category and by originating standard or device. The EventLog Analyzer is able to manage logs so that they are available for compliance auditing for PCI DSS, GDPR, FISMA, ISO 27001, and SOX.
EventLog Analyzer is a software package for Windows Server or Linux and it is also available on the AWS and Azure marketplaces.
There is a problem with the proposition of using this ManageEngine tool in its Free edition: it is limited to collecting logs from five sources. However, there is a 30-day free trial of the full package, so you could use that version and then decide whether you want to buy it at the end of the period. If not, your installation will switch over to the Free edition.
ManageEngine EventLog Analyzer
Start a 30-day FREE Trial
ManageEngine Log360 Cloud – FREE TRIAL
ManageEngine Log360 Cloud is a cloud-based SIEM solution that provides comprehensive visibility and security management across both on-premises and cloud environments in a single platform.
With ManageEngine Log360 Cloud, you can access and manage syslog data from anywhere, scale your network architecture without worrying about the log volume, and cut your overall log storage spending.
The platform also enables you to audit security events and meet IT compliance requirements with ease. It provides security analytics, rule-based threat detection, threat analytics, compliance management, and security auditing and reporting.
Log360 Cloud provides a comprehensive view of your network’s security in real-time with multiple auto-updated, graphical dashboards.
Overall, Log360 Cloud by ManageEngine is an excellent option for a newly set-up Syslog server as it offers a range of features and flexibility to meet various IT security and compliance objectives. You can get started with a free plan with 50GB storage and a 15-day storage retention period.
ManageEngine Log360 Cloud
Start on a FREE Plan
What is event log forwarding?
Event log forwarding is the process of forwarding event log data from one computer to another for analysis and monitoring purposes. This is commonly used in enterprise environments where a central monitoring system is used to monitor multiple computers.
Why is event log forwarding important?
Event log forwarding is important because it provides a centralized view of system events and activities across multiple computers, which can help identify issues and potential security threats more quickly and efficiently.
What types of events are typically forwarded in event log forwarding?
Events that are typically forwarded in event log forwarding include system and application events, security events, and performance metrics.
What tools can be used for event log forwarding?
There are many tools available for event log forwarding, including commercial solutions like SolarWinds Log & Event Manager, ManageEngine EventLog Analyzer, and Splunk Enterprise Security. Open-source tools include Graylog, Logstash, and Fluentd.
How does event log forwarding work?
Event log forwarding works by using Windows Event Forwarding or a third-party tool to collect and forward event log data from a source computer to a destination computer or monitoring system. The data is typically sent using a secure protocol such as HTTPS, and can be filtered or consolidated before being analyzed.
What are some best practices for event log forwarding?
Some best practices for event log forwarding include configuring log forwarding policies to collect and forward relevant events only, setting appropriate alert thresholds to minimize false positives, using encryption to protect data in transit, and regularly reviewing and updating log forwarding policies and procedures. It’s also important to have a clear plan in place for responding to any security incidents or events that may occur.
3 min read
Syslog is the defacto standard for sending log messages in an IP network. Instead of pulling log messages from a remote computer as you would do it in a windows environment, the log files are sent by remote computers to a central log repository. This way of managing log files has become the standard for Linux / Unix environments. As our IT systems tends to become hybrids, the questions arises how it possible to send syslog messages from a windows computer. In this post I will present you a simple approach.
In the scenario we want to forward all security related messages from the windows log to the syslog server using PowerShell. To do so 3 script files are required.
First we need a function to send the message. Use PowerShell Gallery — Send-SyslogMessage function from the Posh-SYSLOG module.
Second a function is required for writing local log files. This one is optional, but recommended. The Write-Log cmdlet has been presented in a previous post.
Third and last the script that is forwarding the windows log messages to our syslog server.
Send-SecurityEventsToPRTG.ps1
param(
[String]$ServerName = "SYSLOG_HOSTNAME"
)
Import-Module (Join-Path $PSScriptRoot "Send-SyslogMessage.ps1")
Import-Module (Join-Path $PSScriptRoot "Write-Log.ps1")
$LogName = "security"
$EndTime = Get-Date
$StartTime = $EndTime.AddHours(-1)
$LogCycle = 10
$LogFilePath = Join-Path $PSScriptRoot "$(Get-Date -Format yyyy-M-dd) $($MyInvocation.MyCommand.Name).log"
try {
Write-Warning "Delete log files older than $LogCycle days"
Get-ChildItem -Path $PSScriptRoot | Where-Object {($Now - $_.LastWriteTime).Days -gt $LogCycle -and $_.extension -eq ".log"} | Remove-Item
Write-Host "Crawl for log entries"
$Events = Get-EventLog -LogName $LogName -After $StartTime -Before $EndTime
$Message = "$($Events.length) events have been found in the $LogName log that are forwarded to the server $ServerName"
Write-Host $Message
Write-Log -Path $LogFilePath -Message $Message -Component $MyInvocation.MyCommand.Name -Type Info
$Events | %{
switch($_.EntryType) {
"SuccessAudit" { [Syslog_Severity]$Severity = "Informational" }
}
Send-SyslogMessage -Server $ServerName -Message $_.Message -Severity $Severity -Facility ([Syslog_Facility]::logaudit) -Hostname $env:COMPUTERNAME -ApplicationName "EventLog" -Timestamp $_.TimeGenerated -MessageID $_.EventID
}
} catch {
Write-Error ($_ | Out-String)
Write-Log -Path $LogFilePath -Message ($_ | Out-String) -Component $MyInvocation.MyCommand.Name -Type Error
}
This examples crawls the security log messages from the last hour and forwards each to the server. Yet only one severity type is supported, the switch statement can be extended easily with additional types. Success and failure of this script are logged locally. Below is screenshot of the log file using CMTrace.
The script is intended to run on an hourly schedule. In case the windows scheduler is used to execute the script make sure that the job runs with the highest privileges available. Otherwise the script won’t be able to read the security log.
Categories:
scripting
,
Microsoft infrastructure
Tags:
event log
,
powershell
,
syslog
Edit this page
Show statistic for this page
Networking and Cyber Security Specialist
Updated: February 11, 2025
Can you forward Windows Event logs to Syslog? Yes, you can. We will show you how.
Event log forwarding is a critical component in network administration and security management. As organizations grow, the volume of log data generated by various systems and devices becomes overwhelming, making it challenging to monitor, analyze, and respond to potential security threats in real-time. Event log forwarding addresses this issue by enabling centralized collection and management of log data from multiple sources. That centralization provides a route to monitor and troubleshoot a network.
In its simplest form, event log forwarding involves configuring systems to send their logs to a central server or SIEM tool where the data can be analyzed and stored. This is a network monitoring process. It identifies performance issues, automates troubleshooting, and enhances security posture by making it easier to spot suspicious activities.
The importance of event log forwarding extends beyond just centralized log collection. It is a vital part of any comprehensive network monitoring strategy. It ensures that critical event logs, such as those related to system errors, authentication attempts, and security alerts, are not overlooked. By aggregating logs from multiple sources, administrators can correlate events, track anomalies, and perform proactive maintenance. Furthermore, it aids in compliance efforts by maintaining an organized log trail for audits and reports.
This guide to event log forwarding will explore the fundamental concepts and best practices to set up and manage an effective log forwarding system. It covers everything from configuring log forwarding on various operating systems to integrating it with SIEM tools for advanced analysis and reporting. By understanding and implementing these techniques, administrators can enhance their ability to detect, respond to, and prevent security incidents while maintaining the overall health of their networks.
Log collectors and receivers
The need to collect all log messages in one place means that there needs to be a bridge between the two tribes of log messaging: Windows Events and Syslog. A log message manager in a Windows system will collect and file all Windows Events log messages but ignore Syslog messages that might be generated on other parts of the network. Similarly, a log file manager written for Linux would collect and store Syslog messages but it wouldn’t handle Windows Event log messages.
So, a systems administrator with both Windows and Linux systems to manage is left with at least two separate stores of log messages – one for Windows Events and one for Syslog messages. This is not a good scenario for intrusion detection. The solution to this problem means that either the Windows Event messages need to be converted into the Syslog format or that the Syslog messages should be converted into the Windows Event message format. Either strategy would enable all system messages to be stored in common files and be searched through by one single analytical tool.
There is a third strategy for consolidating Windows Events and Syslog messages, which is to convert them into a neutral format. Whether Windows Events are sent to a Syslog server or to a third-party consolidating tool, the process of sending those messages is known as Event log forwarding.
Event log forwarders and log servers
The Event log forwarder will operate on your own system. The log server and consolidator do not need to be resident on your premises. There are log servers that you can install on-site and there are others that are hosted Software as a Service system.
Many hosted systems offer the log collector, which is the Event log forwarder as part of the package. In these cases, the log collector still has to be installed on a Windows host on your site. This is usually termed an “agent.”
If you are consolidating files from Windows and Linux environments, you will also need to install a Syslog forwarder on one of your Linux machines. SaaS log file management systems also provide a Linux-resident agent. If you run your log file server on your own site, the log collector/forwarder and the log server will still be separate packages. The server is intended as a manager for all log messages whether they be Windows Events or Syslog.
Free Event log forwarder and log consolidators
You don’t have to pay for an Event log forwarder or a log server and consolidator because there are some free packages available. One of the things that you need to consider is whether the two services that you choose are compatible. As both Windows Events and Syslog are universally-known standards, the likelihood of incompatibility is slim. However, it is still a good idea to check for compatibility, just in case.
You eradicate the possibility of incompatibility if you get both an Event log forwarder and a log file server from the same provider. This is the strategy that we will follow in this guide. Here we use two free utilities from SolarWinds. These are:
- SolarWinds Event Log Forwarder for Windows
- Kiwi Syslog Server Free Edition
As you have probably already guessed from the names of these two tools, we will deal with the incompatibility between log file formats by converting Windows Event log messages into a Syslog format and then send them to a Syslog server. The server is also capable of receiving Syslog messages from a Linux-based log message collector.
Both of these utilities run on the following operating systems:
- Windows Server 2016
- Windows Server 2012 and 2012 R2
- Windows 10
- Windows 8.1
- Windows 8
The Event Log Forwarder will also run on these Windows versions:
- Windows 7 and Windows 7 SP1
- Windows Server 2008, 2008 SP2, 2008 R2, and 2008 R2 SP1 *
- Windows Server 2003 R2 SP2 *
Let’s get on and install these two software packages.
Install SolarWinds Event Log Forwarder for Windows
The Event Log Forwarder is available for free download at the SolarWinds website. It needs to be installed on each computer from which you want to collect Event log messages. Click on the Download button to access the page.
Fill in the contact details form on the download access page and then press the Proceed to Free Download button.
You will be offered a free 30-day free trial of the SolarWinds Log Analyzer. Whether you choose this offer or not, the next screen gives you a download link in the form of a button, labeled Download Now.
Click on the button to get the download, which is a zipped folder. When the download completes, open the folder. Extract the files from the zip container.
Double-click on the second item in the folder, which is an installer. Windows will ask you for permission to run the file. Press OK. This will launch an installation wizard. Accept the Terms and Conditions and cycle through the installation stages by clicking on the Next button. Press the Finish button on the last page of the installer.
Set up the Event Log Forwarder
Once the installer closes, open the Event Log Forwarder by clicking on its entry in the Start menu or its icon on your Desktop. Windows will ask you for permission before the service opens.
The Dashboard for the system has a large blank panel in it when you first run it.
Specify Event collection parameters
In order to get the collector running, you need to add a type of message for it to capture.
Click on the Add button at the top of the display panel.
The Event type selection screen enables you to filter the events that will get forwarded to the Syslog server. This will cut down on traffic. However, if you are gathering log records to be used by a SIEM system, you might be required to send all events.
As you select filters for the messages, you can see the records that your setup will capture by pressing the Show preview of matching event records button, which is underneath the left panel on the screen.
There are three ways to select the types of log records that will be collected. The first lies with the specification of the sources of log messages that you would like to collect. This is enabled through a hierarchy structure shown on the left panel of the screen. Check the box at the root of the hierarchy to select all events. This filtering method can be refined through a drop-down list of event sources. This is a list of subcategories of the systems you selected in the left-hand panel.
The second filtering option is at the top of the main panel of the Add screen. This allows you to select the severity of events that you want to collect. The options here are to collect messages with the level of Error, Warning, and Information.
The third method for filtering allows you to specify task categories, user accounts, or computers to extract log records for. The Task Category option is a little obscure because it works on a list of IDs. So, you would need to know the identifiers of each of the specific categories you want to collect log records for in order to use this feature meaningfully. The selection of these Task Categories is through a drop-down list that has all of the categories checked by default. This list only gets populated after you have selected event sources in the left-hand panel.
It is also possible to use task category IDs in the Include or Exclude Event field above the Task Category drop-down list. If you want to capture all events except for a given list, put a minus sign in front of the ID for each event type.
After completing the event source selection, click on the Next button to proceed. This takes you to the Define Priority screen.
Select the Default Syslog Facility that the event records will be forwarded to the syslog server(s). This value, together with the Event Type on each message is used to generate the Priority value that will be added into each record when it is converted into the Syslog standard.
Click on the Finish button to return to the main screen.
You will now see an entry in the main detail panel of the Home screen in the Dashboard.
Specify a Syslog server
The next step is to tell the Event Log Forwarder where to send its converted event logs. Click on the Syslog Servers tab at the top of the main panel on the Home screen. Click on the Add button to proceed.
In the Add Syslog Server screen, enter the IP address of the host of the Syslog server utility. If you subscribe to a SaaS system for logfile consolidation, you should put in the IP address given to you in the setup guide for that service. If you will be using an installed Syslog server, put in the IP address of the computer that you installed it on – or intend to install it on. Leave the Port and Protocol fields as they are because these are industry standard values.
The Server Name field gives you an opportunity to put your own label on this Syslog server record, in case you set up several servers. If you only have one, the name you choose doesn’t matter too much because you won’t need to distinguish between the records that will appear in the Syslog Server section of the Home screen on the Dashboard.
Press the Create button to return to the main screen of the Dashboard.
Check the settings of Event Log Forwarder
In the main screen of the Event Log Forwarder, click on the Test tab in order to check whether the setup of the collector has been performed correctly. Select an event type in the Event logs you wish to add a test event to: drop-down list. Select the All option. Select an event type in the second field, such as Warning.
Click on the Create a test event button to run the test. You should see a success or failure notification.
Use a Syslog server
Now the setup of your Event log forwarder is complete. However, you will also need to set up a Syslog server in order to benefit from this message forwarding system. We recommend using the Kiwi Syslog Server Free Edition, which you can download from the SolarWinds website.
In order to download this server, you need to fill in a form, which is the same as the form you filled in to get the Event Log Forwarder.
Download the service, unzip the download container and run the install Wizard to get the Syslog server on your host.
In order to test whether the Syslog Server is set up correctly, go back to the Event Log Forwarder and run a test. With the Kiwi Syslog Server operational, you should see a test message appear in the Syslog Server dashboard.
If you are in the market for a full package of system and network administration tools, you could consider the Small Business Network Management Bundle. This includes the Kiwi Syslog Server as well as Kiwi CatTools, which helps you manage backups from network device configurations. You also get a Network Topology Mapper with this package. Finally, the group of software provides the Engineer’s Toolset, which contains more than 60 system and network administration tools in one console. Take a look at the Small Business Network Management Bundle with a 14-day free trial.