Настройка службы syslog на ос windows server

Обновлено 07.09.2022

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В минувший раз мы с вами устранили ошибки оборудования с кодом 10 и кодом 43, вернув нормальное функционирование сервера. Идем далее и сегодня я хочу вас научить делать штатными средствами удобный сервер по сбору логов Windows, за счет пересылки нужных событий с нужных серверов. В результате чего получите единую точку для анализа событий происходящих в нужных системах.

Централизованный сбор логов в Windows

Когда что-то случается в операционной системе Windows или Windows Server, то первым делом куда должен зайти системный администратор после сбоя, это журнал событий с логами. Все это не сложно если у вас 5-10 серверов, а что делать когда их сотни, правильно для таких масштабов нужно иметь централизованный сервер по сбору и хранению логов, например elasticsearch. В случае с elasticsearch, это наикрутейший сервис, но его минус в том, что не все его могут правильно поднять, и нужно иметь приличный запас ресурсов под него.

Но не спешите расстраиваться Билли Гейтс позаботился о своем детище и встроил подобный функционал для реализации нашей задачи прямо по умолчанию в Windows. По умолчанию любой Windows Server умеет, как отправлять события, так и принимать их от других серверов.

Что я хочу:

• 1️⃣Иметь один сервер на который будут складываться все события с контроллеров домена и нужного мне списка серверов
• 2️⃣Настроить нужные мне серверы на отправку определенных событий на заданный сервер
• 3️⃣Возможность предоставления прав на централизованный сервер хранения логов для представителей хелпдеска
• 4️⃣Не устанавливать никакой дополнительный софт

Выглядит схематично это вот так. Тут у нас будут вот такие сущности:

• Сервер собирающий события (Collector Initiated) — Это и есть наш центральный сервер по сбору событий, мы будим его еще называть коллектор логов. В качестве данного сервера будет выступать виртуальная машина с Windows Server 2022.
• Сервер отправляющий события на центральный сервер (Source initiated). Тут по сути может выступать любая операционная система Windows.

Настройка сервера для отправки логов на центральный сервер

Первым делом вы должны настроить ваши сервера на отправку событий. Я для примера это буду делать для контроллеров домена. Чтобы у вас все работало, вам нужно включить службу для удаленного управления WinRM. Открывайте командную строку от имени администратора и введите команду:

Либо так же через PowerShell:

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

• Вы предоставите нужные права учетной записи компьютера, что по мне правильнее
• Либо можно производить подключение от имени доменной учетной записи (Можно и не доменной, но я рассматриваю исключительно окружение Active Directory)

Все, что нам нужно это предоставить учетной записи членство в локальной группе «Читатели журнала событий (Event Log Readers)«

Но если мы говорим про контроллер домена, то там локально вы не сможете увидеть данную оснастку с группами, она просто скрыта из соображений безопасности.

Для того чтобы дать права, откройте оснастку «Active Directory — Пользователи и компьютеры» и перейдите в раздел Bultin. Тут будет группа «Читатели журнала событий (Event Log Readers)«. Добавьте в нее пользователя или учетную запись компьютера, кому вы назначаете права (Члены этой группы могут читать журналы событий с локального компьютера)

Еще очень важно дать учетной записи Network Service право на чтение, иначе вы будите получать ошибку 0x138C:

Причина ошибки 0x138C, заключается в том, что служба удаленного управления Windows запускается под учетной записью сетевой службы. Нужно добавить SID учетной записи сетевой службы в разрешения на доступ к каналу журнала событий безопасности. Для начала давайте на контроллере домена, с которого я буду отправлять логи посмотрим текущие разрешения, сделать это можно в командной строке Windows.

Видим текущий канал безопасности:

Нам нужно в самый конец добавить SID Network Service. Это стандартный SID (A;;0x1;;;S-1-5-20). Команда будет выглядеть вот так:

или

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

Чтобы назначить массово права для Network Service, вы можете воспользоваться преимуществами Active Directory и создать на нужном OU групповую политику, в которой нужно перейти:

Тут вам нужно через правый клик добавить группу «Event Log Readers«.

Далее вам нужно ее отредактировать, добавив туда Network Service и все остальные группы, для которых вы выдаете права.

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

Тут будет ключ реестра CustomSD. В CustomSD вы увидите ту самую строку channelAccess. При желании вы можете отредактировать ключ, добавив нужный SID. Так же данный ключ можно менять централизованно через GPO, но это сложнее, чем Restricted Groups.

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

Настройка сервера получающего логи

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

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

Далее откройте оснастку просмотра событий (eventvwr.msc) и перейдите в раздел «Windows Logs — Forwarded Events«, вызовите его свойства через правый клик.

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

• 1️⃣Увеличьте размер текущего журнала исходя из ваших требования, если слишком большой будет журнал, то могут быть сложности с поиском и фильтрацией событий, так как их может быть более нескольких миллионов и дисковая подсистема должна с этим справляться.
• 2️⃣Выставите опцию для архивирования журнала в случае достижения нужного размера, для этого активируйте «Archive the log when full, do not overwrite evwents«

• 3️⃣Перейдите на вкладку «Subscriptions«. Создаем новую подписку.

• 4️⃣Укажите нужное имя для подписки, это ни на что не влияет, кроме вашего удобства. Описание так же можете указать, чтобы например описать список событий или еще какие-то критерии. Оставляем выбранным пункт «Collector initiated«. После чего нажмите кнопку «Select Computers«, чтобы указать с каких компьютеров нам нужно получать логи.

• 5️⃣Добавьте в список интересующие вас компьютеры. Небольшой лайфхак, группы безопасности тут так же работают, так что смело создавайте группу и добавляйте в нее все компьютеры, что нужно логировать.

• 6️⃣Обратите внимание, что у вас тут будет возможность провести небольшое тестирование на доступность удаленного управления и получения событий из журналов.

• 7️⃣Теперь перейдите в раздел «Select Events«, он нужен для фильтрации тех событий, что вы хотите отслеживать, так как нет смысла пересылать все, на это не хватит ни каких дисков. Для примера я хочу получать события связанные с блокировкой учетной записи пользователя в домене.

Выберите дату логирования, я оставляю всегда «Any time«, тип событий будет информационным. В Event logs я указываю стандартный набор журналов, но как вы можете обратить внимание, можно выбрать и более расширенные, например для мониторинга RDS фермы.

Выставите нужные ID событий, что вы собираетесь получать. При желании вы можете задать еще более точный фильтр, указав ключевые слова.

• 8️⃣Сохраните настройки. Остается теперь указать от имени какой учетной записи мы будим работать. Для этого есть пункт «Advanced«. Тут я оставляю работать от имени учетной записи текущего компьютера, но вы можете смело поменять и на пользовательскую учетку. Если вы используете нестандартный порт подключения, а это 5985, то вы смело его можете тут поменять.

• 9️⃣Давайте сразу протестируем доступность получения событий по подписке. Для этого в контекстном меню вызовите пункт «Runtime Status«.

Везде должен быть статус «Active«.

Как я и писал выше, минут через 10-15 логи начнут поступать.

Траблшутинг сервера-коллектора логов

Очень часто тут бывают ошибки 0x138C, как ее решать я описал выше.

Еще если вы не дали права, то получите «Access is denied«.

Еще если вы выбрали слишком много событий, то можете увидеть ошибку:

Если у вас есть такие крупные продукты, как SharePoint, MS Exchange, MS CRM, то получая с них события, вы можете видеть ошибку ID 6398:

Как я вам выше показал в реестре Windows каждый журнал описан в своей ветке и за него отвечает определенная DLL библиотека, если такого источника не будет на вашем коллекторе, то и могут возникать подобного рода ошибки. Для крупных приложений очень сложно произвести перенос в другое место, так как очень много источников, кто туда пишет. Поэтому PowerShell нам в помощью.

На просторах интернета есть добрые люди, кто столкнулся с такой задачей и ее прекрасно выполнил, и самое прекрасное, что человек поделился решением со всем интернетом.

Тут два скрипта:

• export-log — Для экспорта данных с серверов откуда собираем данные
• import-log — Для импорта на сервере-коллекторе недостающих данных

Алгоритм такой, копируем скрипт export-log на сервер со специфическим ПО, у меня это будет Dynamic CRM. Запустите PowerShell и перейдите в расположение вашего скрипта, выберите его и добавьте ключ, являющийся частью источника событий, например crm.

Данный скрипт создаст папку с названием ключа, далее просканирует все журналы событий, если найдет среди них похожий на crm, то сделает их дамп и создаст текстовый файл со списком сдампленных разделов.

Вот еще пример с Kaspersky.

Теперь идем на сервер коллектор и копируем туда созданную ранее папку. После чего открываем PowerShell так же в режиме администратора и импортируем все, что до этого получили.

В скрипте изначально задан каталог C:CustomEvents, так что создайте его заранее иначе будете получать ошибку. После этого все логи будут корректно отображаться.

Еще из проблем может быть недоступность порта 5985, который должна слушать служба winrm. Проверяем порт, как я рассказывал ранее. Может получиться так, что какая-то из служб может его занять, как в случае с 1С или IIS.

И удаляем:

Что делать если у вас несколько серверов коллекторов

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

Включаем параметр «Configure target Subscription Manager«. Тут задаем нужное количество серверов вы формате:

Еще тут через запятую можно добавить интервальность Refresh=10.

Можно сказать это как зеркалирование портов.

На этом у меня все. Я попытался описать полностью процесс настройки централизованного сервера коллектора логов на базе Windows Server 2022. Рассказал, про подводные камни и как их обходить. С вами был Иван Сёмин, автор и создатель IT блога Pyatilistnik.org. Если у вас остались вопросы, то жду их в комментариях.

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

Вступление

Это статья предназначена для системных администраторов, которые знакомы с 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 был переполнен ссылками на коммерческий софт с таким функционалом. При этом софт не высокого качества, судя по стремным сайтам и скриншотам. Переполнен он ими и сейчас, и, по моим собственным наблюдениям, многие отнюдь не ленивые и не тупые администраторы способные с успехом для собственного удобства использовать такой функционал так и не нашли того что им нужно и не знают что такое бывает. По крайней мере за мой совет и ссылку меня не раз благодарили, и теперь я хотел бы поделиться и с вами. А именно некоторое время назад (довольно давно, это статью я решил написать только сейчас), мне удалось найти проект идеально подходящий под мои нужды и требования:

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

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

Настройка

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

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

Параметры 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 = Отключить

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)

Если вы хотите исключить какое-то событие из отправки в 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 примерно в таком виде:

Заключение

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

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

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

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

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

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

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

Источник

16 лучших бесплатных серверов Syslog для Linux и Windows

Мы подробно расскажем о каждом инструменте, который мы выбрали для этого списка, но если вам просто нужна краткая сводка, вот список 16 лучших бесплатных серверов Syslog для Linux и Windows:

Syslog Серверы и Клиенты

Концепция «Сервер системного журналаДействительно относится к приложение, которое имеет дело с сообщениями системного журнала вместо предоставления выделенного компьютера для получения сообщений. Так что не заблуждайтесь этим словом «сервер» там.

Несмотря на то, что стандарт Syslog был кодифицирован специальной инженерной группой Internet, существует так много реализаций Syslog, что существует некоторая вариация в формате сообщения данных syslog. Со всеми различными типами сообщений вы могли бы извлечь выгоду из, вам нужно получить инструмент, чтобы разобраться во всех.

Сообщения системного журнала

Сообщения системного журнала можно рассматривать как эквивалент Linux / Unix журналов событий Windows. Таким образом, вы можете называть их «событиями системного журнала». Они предоставляют важную информацию и будут поддерживать ваши задачи системного администрирования посредством:

Записи в ваших файлах системного журнала записаны там, потому что производители вашего программного обеспечения и устройств посчитали определенные события значимыми, поэтому было бы ошибкой игнорировать этот богатый источник системной активности и информации о состоянии. Поэтому скачайте сборщик Syslog и активируйте его.

Номера портов системного журнала

Системный журнал работает через UDP, поэтому ожидать активности на UDP-порту 514 ваших сетевых устройств. Это вызвано всеми этими сообщениями о событиях системного журнала, циркулирующими по вашей сети. UDP-порт 514 используется клиентами Syslog для отправки сообщений, а также серверами Syslog для прослушивания сообщений. Следовательно, это и порты источника и назначения на всех стандартных коммуникациях Syslog. Не закрывайте это. С подозрением на активность на TCP-порту 514. Известно, что этот порт используется червем ADM и не используется для системного журнала..

Есть безопасные реализации Syslog. Поскольку защищенным службам необходимо установить соединение, вы не можете использовать для них порт UDP.. Безопасная версия Syslog известна как Syslog поверх TLS и использует TCP-порт 6514.. Если вы хотите управлять удаленным сервером Syslog, подключенным к сети через Интернет, вам нужно пройти маршрут Syslog по TLS, поскольку незашифрованные события Syslog, отправляемые через Интернет, могут серьезно подорвать безопасность вашей сети..

Лучшие бесплатные серверы Syslog для Linux и Windows

Если у вас нет бюджета на инструменты или вы не думаете, что стоит потратить деньги только на просмотр сообщений журнала, ознакомьтесь с нашим списком бесплатных серверов системного журнала. Большинство обзорных сайтов предоставят вам список из пяти или 10 лучших серверов системного журнала, но мы прошли лишнюю милю и нашли 16 отличных серверов системного журнала, которые можно бесплатно использовать.

1. Сервер Syslog для киви SolarWinds (СКАЧАТЬ БЕСПЛАТНО)

Система киви позволяет вам записывать журналы событий по IP-адресу, дате или по типу источника сообщений. Вы можете получать уведомления о высоких условиях трафика, отправленные на ваши уведомления по электронной почте. Тем не менее, если вы получаете платную версию, есть еще много условий, о которых вы можете выбрать, чтобы получать уведомления по электронной почте. Сервер системных журналов Kiwi доступен только для Windows. Его можно установить на Windows Server 2008 R2, Windows Server 2012, Windows 7 с пакетом обновления 1, Windows 8.1 и Windows 10.

ВЫБОР РЕДАКТОРА

Скачать: БЕСПЛАТНАЯ версия от SolarWinds.com

Официальный сайт: www.solarwinds.com/free-tools/kiwi-free-syslog-server/

ОПЕРАЦИОННЫЕ СИСТЕМЫ: Windows & Windows Server

2. Сетевой монитор Paessler PRTG (БЕСПЛАТНАЯ ПРОБНАЯ ВЕРСИЯ)

Вы можете скачать программное обеспечение PRTG с веб-сайта Paessler и установить его на Windows. Для Linux нет версии. тем не мение, Вы можете выбрать доступ к программному обеспечению в качестве облачной службы, которая не зависит от системы.

Функция системного журнала в PRTG называется Syslog Receiver. Это позволит собрать все данные системного журнала, путешествующие по вашей сети, и записать их в базу данных. После того, как сообщения находятся в базе данных, последующее управление этими записями зависит от настроек, которые вы указываете для системы. Вы можете записывать их в файлы журналов, запрашивать их на панели инструментов PRTG и запускать действия при определенных условиях. Вы можете скачать и оценить бесплатную пробную версию здесь.

Сетевой монитор Paessler PRTGСкачать 30-дневную бесплатную пробную версию

3. Loggly (БЕСПЛАТНАЯ ПРОБНАЯ ВЕРСИЯ)

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

Система Loggly сохраняет ваши Сообщения системного журнала в стандартизированном формате. Он также будет принимать журналы от Amazon Web Services (AWS), Docker, Logstash и множества других систем захвата журналов. Все эти записи адаптированы таким образом, чтобы доступ к информации в них был единым образом. Как только ваши журналы будут в системе Loggly, вы сможете анализировать их с помощью инструментов онлайн-сервиса..

Большим преимуществом использования Loggly является то, что вы получаете место для хранения, включенное в сделку. Вам нужно сделать резервную копию всех ваших файлов журналов на другом сайте, отличном от вашего собственного сайта, чтобы убедиться, что активный хакер не проник в вашу систему и не удалил все записи о его действиях. Так что вам все равно придется искать решение облачного хранилища. Регистрация на сервис Loggly дает вам отскок к архивированию ваших журналов, делая данные доступными для анализа.

Время, в течение которого ваши данные журнала доступны в системе Loggly, зависит от того, на какой из четырех пакетов вы подписались. Lite Пакет постоянно бесплатен, но он сохраняет данные только в течение семи дней и позволяет использовать только одну учетную запись пользователя. стандарт Пакет позволяет вам передавать один ГБ данных в день и будет хранить ваши записи в течение месяца. профессионал Служба Loggly имеет метод с переменной ценой и позволяет вам передавать данные от трех до двадцати ГБ в день с периодом хранения от пятнадцати до девяноста дней. Верхняя упаковка называется предприятие и это специально для клиента отделом продаж.

Loggly Log ManagementЗагрузить 14-дневную бесплатную пробную версию

4. ManageEngine EventLog Analyzer (БЕСПЛАТНАЯ ПРОБНАЯ ВЕРСИЯ)

EventLog Analyzer ManageEngine работает как сервер Syslog и является бесплатно до пяти источников журнала. Программное обеспечение для мониторинга может быть установлено на Windows или Linux, но он может отслеживать события, возникающие в любой операционной системе. Данные системного журнала могут поступать из любого подключенного к сети оборудования, включая коммутаторы, маршрутизаторы и виртуальные машины.

Панель управления ManageEngine включает в себя множество функций, которые позволяют вам указать действия, которые нужно выполнить с собранными данными системного журнала.. Типичным требованием к серверу системного журнала является запись всех записей в журналы событий.. Это действие доступно, но вы также можете запрашивать записи на панелях мониторинга, а также сортировать и фильтровать сообщения. Архивные журналы могут быть сжаты и зашифрованы. Шифрование позволяет накладывать права доступа на учетные записи пользователей., таким образом, видимость данных в файлах системного журнала может быть ограничена только несколькими пользователями сети с правами администратора..

EventLog Analyzer также может следить за сообщениями SNMP. ManageEngine производит комплексную систему мониторинга сети, которая называется OpManager. Бесплатное издание Этот инструмент доступен только для 5 источников журналов. Вы также можете скачать 30-дневная бесплатная пробная версия из Premium Edition. Для получения более подробной информации о ценах вы можете связаться с их отделом продаж.

ManageEngine EventLog AnalyzerDownload 30-дневная бесплатная пробная версия

5. WhatsUp Syslog Server

IPswitch выпускает успешный инструмент для мониторинга сети под названием WhatsUp Gold. Они также предлагают бесплатный сервер Syslog, который можно использовать как отдельную утилиту или интегрировать в пакет WhatsUp Gold. WhatsUp Syslog Server можно использовать бесплатно и может быть установлен на Windows.

Этот инструмент охватывает основные функции сервера Syslog: захват данных Syslog и их сохранение в журналах событий. Помимо этой стандартной функциональности, пакет предоставляет вам еще несколько возможностей, которые помогут вам лучше организовывать сообщения Syslog и обрабатывать их. Вы можете пересылать сообщения в другие приложения и сохранять записи в разные файлы выборочно. Сервер системного журнала включает консоль, на которой вы можете отображать записи и указывать, как программа работает с каждым типом сообщений..

Программа просмотра системного журнала показывает вам живые данные, как они поступают и вы можете фильтровать и сортировать записи, чтобы сосредоточиться на одном источнике типа сообщения. Объемы данных, которые инструмент может обработать, означает подходит для всех размеров сети, хотя это бесплатно. Консоль может обрабатывать до шести миллионов сообщений в час. Вы также можете импортировать архивные записи, чтобы анализировать события и получать долгосрочное представление о производительности сетевого оборудования..

Функции управления консоли позволяют указывать шаблоны, выделяющие конкретные условия оповещения или IP-адрес источника сообщения. Вы также можете создавать собственные предупреждения, указав комбинации условий, которые должны быть переведены в состояние предупреждения..

6. Системный журнал Watcher

Syslog Watcher от EZ5 Systems доступен для установки на Windows. Это бесплатный сервер системного журнала Программа с рядом дополнительных функций мониторинга. Поскольку почти каждое устройство, подключенное к вашей сети, отправляет сообщения системного журнала, сервер системного журнала должен работать быстро, если вы хотите, чтобы он делал больше, чем просто собирал и записывал эти сообщения в файл.. Syslog Watcher использует многопоточную архитектуру, поэтому сбор новых записей не задерживается до завершения обработки.

Панель управления предоставляет вам варианты обработки сообщений. Вы не ограничены хранением их в файлах, потому что у вас есть возможность записи их в базу данных. Получение сообщений Syslog в базе данных дает вам гораздо больше возможностей для работы с записями событий, потому что вы можете сортировать, фильтровать, группировать и считать их. Это позволяет вам комбинировать события для создания условий оповещения клиента. Вы можете получать оповещения, отправленные вам по электронной почте через Syslog Watcher.

Syslog Watcher может отслеживать сообщения как по UDP, так и по TCP и работать как с адресными системами IPv4, так и с IPv6..

ОБНОВИТЬ: Syslog Watcher бесплатен для домашнего использования. Бизнес-пользователи должны платить за инструмент. Тем не менее, EZ5 Systems предлагает 30-дневная гарантия возврата денег. Итак, если вы хотите попробовать его бесплатно, просто используйте его в течение месяца, а затем попросите вернуть свои деньги.

7. Системный журнал Fastvue

Fastvue специализируется на средствах сообщения о системных сообщениях. Одним из ее продуктов является бесплатная утилита сервера Syslog. Это программное обеспечение может быть установлено на Windows Server 2008 R2 и более поздние версии операционной системы Windows Server.

Система Syslog собирает входящие сообщения и записывает их в журналы событий. Это заботится о вашей основной функции сервера Syslog. Панель инструментов инструмента Fastvue проверяет все ваши архивные файлы и предоставляет отчет о размере каждого файла. Файлы сортируются по дате, и каждый из них становится партнером с помощью файла подтверждения, в котором хранится количество хэшей SHA-256. Следя за этой информацией, вы узнаете, не вмешивался ли файл журнала. Это важная функция для обнаружения вторжений, потому что хакеры будут изменять файлы журналов, чтобы скрыть свое присутствие.

Fastvue Syslog компилирует отдельные файлы журналов для каждого сообщающего устройства / IP-адреса, поэтому вы получаете каталоги файлов для каждого адреса устройства. Каждый файл содержит дневные сообщения с данными системного журнала, поступающие с устройства, которое скрывает каталог.

Этот сервер системного журнала фокусируется на создании и мониторинге файлов сообщений системного журнала, а не на предоставлении доступа к этим записям для анализа. Если вам нужна консоль для анализа записей, вам нужно будет импортировать файлы журналов в другое приложение.

8. Чувак

Чувак очень широко используется бесплатный инструмент для анализа сети это включает в себя функции сервера Syslog. Это приложение может быть установлено на любая версия Windows от Windows 2000, все версии Linux и macOS. Этот инструмент производится MikroTik, производителем маршрутизаторов из Латвии..

Эта система может контролировать ваши сетевые устройства и собирать данные системного журнала. Он может обрабатывать предупреждения SNMP, а также трафик ICMP и DNS. Чувак может контролировать как трафик TCP, так и UDP. Функции мониторинга сети включают автообнаружение и отображение топологии сети.

Доступ к функциям системного журнала The Dude можно получить на вкладке интерфейса.. Система может работать как полноценный сервер Syslog с дополнительными возможностями пересылки и фильтрации.. Вы можете заставить The Dude просто отправлять все записи в файл или указать правила для перенаправления соответствующих сообщений в другие места назначения, которые могут быть отдельными журналами событий или консолью системы. Вы также можете удалить определенные записи и заставить систему подавать звуковой сигнал, мигать или отображать всплывающее сообщение для пользовательских условий оповещения.

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

9. Логос Nagios

Nagios основан на проекте с открытым исходным кодом. Возможность загрузки исходного кода для системы означает, что вы можете использовать его для свободно. Тем не менее, существуют ограничения на бесплатную версию Nagios. Вы можете использовать систему бесплатно только до 500 МБ пропускной способности в день. Программное обеспечение Nagios может быть установлено на Windows и Linux.

Сервер журнала может собирать информацию о событиях Windows, системных журналах Linux и системных журналах сетевых устройств. Приложение объединяет сообщения журнала в одном центральном месте. Вы можете назначать физические серверы для хранения журналов событий, распределять хранилище по кластеру серверов, даже дублировать файлы в разных местах для создания резервных копий..

Консоль позволяет вам просматривать прямые трансляции сообщений журнала и получать доступ к ранее сохраненным данным системного журнала. Интерфейс включает в себя функции сортировки и фильтрации, которые помогут вам анализировать сообщения. Вы можете указать условия оповещения, которые могут состоять из комбинации состояний или обозначаться как оповещение о частоте появления определенных типов сообщений.. Возможности настройки Nagios распространяются даже на приборную панель. Можно заполнить панель мониторинга приоритетными функциями, включая списки сообщений. Другие элементы, которые вы можете разместить на панели инструментов, включают инструменты визуализации данных, такие как графики, гистограммы и диаграммы..

10. Ицинга 2

Исинга начинал как развилка Нагиоса. С момента своего создания в 2009 году этот пакет отошел от своего предшественника. Последняя версия программного обеспечения называется Icinga 2, и ее можно установить на Linux. Пакет состоит из двух частей. Основная система это процессор данных, и последняя версия этого программного обеспечения называется Icinga 2. Бэкэнд может взаимодействовать с целым рядом приложений для управления данными, в том числе графит и InfluxDB. Команда Icinga также производит свой собственный интерфейс, называемый Веб 2.0, который доступен на веб-сайте Icinga в отдельной загрузке.

Если вы посмотрите на сайт Icinga по цене, вы не найдете его, потому что этот инструмент мониторинга сети совершенно бесплатно.

11. Сервер визуальных системных журналов

На панели инструментов записи имеют цветовую кодировку с сообщениями об ошибках красного цвета и предупреждениями желтого цвета. Эти цвета могут быть настроены. Вы получаете в реальном времени сообщения и вы также можете загружать записи в программу просмотра из файлов..

Хотя эта утилита не имеет сложной графики или вариантов обработки, она легкая и быстрая, поэтому у нее есть рынок. Зритель представляет записи и позволяет фильтровать их и сортировать их. Интерфейс может быть настроен на воспроизведение звука при возникновении состояния тревоги. Вы также можете установить приложение на отправить вам электронное письмо, когда оно обнаружит предупреждение или предупреждение. Если ваша система электронной почты поддерживает шифрование, Visual Syslog Server будет шифровать отправляемые вам электронные письма с уведомлениями. Это удобный, бесплатный, готовый к использованию инструмент, который выполняет свою работу.

12. Системный журнал-NG

Syslog-NG является открытый источник пакет, который бесплатно использовать. Программное обеспечение для Syslog-NG может быть установлено только на Linux. Однако система управления журналами может собирать данные о событиях Windows, а также стандартные сообщения системного журнала, генерируемые микропрограммой для Linux, Unix и устройств..

Другие серверы системного журнала в этом списке могут анализировать данные из сообщений. Некоторые серверы Syslog имеют привлекательные информационные панели с функциями визуализации данных. Вы не получите ничего подобного с Syslog-NG. Если вы хотите получить больше функциональности для обработки сообщений системного журнала, вам нужно добавить инструмент анализа данных.

13. Nxlog

Система Nxlog с открытым исходным кодом, и вы можете использовать ее бесплатно. В этом инструменте нет никаких аналитических функций, поэтому, если вы хотите просматривать записи или каким-либо образом манипулировать ими, вам потребуется найти отдельный интерфейс для анализа. Это простой способ сбора сообщений и создания лог-файлов., делая его чистым сервером Syslog.

14. Logstash

Logstash является частью набора утилит под названием «Эластичный стек.Эта группа инструментов создается группой разработчиков, чей первый продукт называется Elasticsearch. Elasticsearch является вторым элементом в Elastic Stack, как и Kibana. Разделение труда между этими тремя пакетами состоит в том, что Logstash собирает сообщения журнала, Elasticsearch позволяет сортировать и фильтровать эти сообщения для анализа, а Kibana интерпретирует и отображает данные.. Все программы Elastic Stack работают в Linux.

Logstash также собирает данные из облачных сервисов, включая AWS. Он может собирать данные из таких приложений, как Ganglia, Salesforce, Graphite, Kafka и Twitter.. Вы можете настроить процесс сбора, чтобы включить TCP и UDP сообщения и он может получать сообщения, зашифрованные с помощью TLS. Logstash может читать сообщения из файла, из базы данных, получать сообщения SNMP, IRC и RSS-каналы, а также получать сообщения с почтовых серверов..

Logstash может фильтровать переадресацию и переформатировать сообщения во время обработки. Программа хранит записи в файлах или вставляет их в базы данных. Утилита предназначена для интеграции с Elasticsearch и может отправлять данные непосредственно в это приложение. Аналогично, Logstash может быть настроен на вывод данных в Loggly, Nagios, AWS, Graphite и Graylog. Другие плагины будут уведомлять вас о новых данных журнала по электронной почте или сообщением Slack.. Logstash доступен бесплатно.

15. Graylog

Graylog является система управления бревнами доступны для Linux. Это сложный инструмент анализа данных Syslog. Тем не менее, вы можете просто воспользоваться его возможностями сбора и хранения сообщений, чтобы использовать его как чистый сервер Syslog. Graylog свободен для объемов данных 5 ГБ или менее в день. Владельцам небольших сетей не нужно ничего платить за их использование. Функции анализа данных не генерируют дополнительную пропускную способность. Вы не получаете никакой поддержки с бесплатной версией Graylog. Тем не менее, форум сообщества на веб-сайте Graylog заполнен советами и рекомендациями других пользователей..

Graylog находится на вершине программного обеспечения виртуальной машины. Эта базовая система в Linux включает в себя средство rsyslog. Это на самом деле rsyslog, который будет выполнять функции сбора и хранения сообщений Syslog. Вы можете управлять rsyslog через интерфейс Graylog. Если вы платите за Graylog, вы также можете собирать данные через систему Sidecar. Это позволяет хранить журналы событий на компьютерах с Windows.

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

Панель инструментов позволяет создавать собственные условия оповещения. Вы указываете каждое предупреждение на основе типа потока данных. Например, вы можете выберите поток Syslog UDP, а затем настройте условие оповещения о количестве предупреждающих сообщений, которые поступают через. Системные настройки позволяют получать оповещения, отправленные вам в качестве уведомлений по электронной почте. Процедуры потоковой обработки позволяют вам анализировать записи, пересылать их или сохранять в файле или базе данных.

16. TFTPD32 / 64

TFTPD является небольшая утилита для Windows. Пакет доступен в виде 32-разрядного или 64-разрядного приложения. Центральным элементом этого программного обеспечения является реализация клиента TFTP. Этот клиент может быть настроен на получение сетевых сообщений от серверов DHCP, DNS и SNTP. Он также может получать данные системного журнала.

TFTPD может работать как с адресами IPv6, так и с адресами IPv4. TFTPD32 и TFTPD64 оба доступно бесплатно.

Серверы системного журнала по ОС

Syslog serverLinuxWindowsOther

Выбор сервера системного журнала

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

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

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

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

Сервер системного журнала, встроенный в инструмент управления сетью, может обеспечить широкие возможности анализа. Если у вас уже есть все необходимые аналитические инструменты, вам лучше сосредоточиться на инструментах сервера Syslog в этом обзоре. тем не мение, если у вас очень мало средств на программное обеспечение для управления системой, и в настоящее время у вас нет аналитических инструментов, затем перейдите к бесплатной утилите управления системой, которая включает в себя сервер системного журнала, чтобы контролировать вашу ИТ-инфраструктуру.

Управление ИТ-услугами требует соответствующих инструментов. Посмотрите на бесплатные инструменты рекомендуется в этом обзоре, который подходит для вашей операционной системы. Потратьте немного времени, чтобы поиграть с каждым инструментом, чтобы вы могли открыть для себя их функции. Учитывая, что все эти инструменты бесплатны, вам нечего терять, кроме времени, необходимого для их изучения..

Источник

Логи — это важно. Если устройств много, в целях удобства и резервного копирования хорошим решением является создание некоего log-сервера, на который серверы и оборудование будут свои логи по сети пересылать.

Далее речь пойдет о задаче сбора syslog-сообщений от unix-серверов и активного оборудования (cisco ios) на windows-сервере. В процессе разработки решения были найдены два opensource-продукта — syslog for windows и nxlog. Первый более прост в освоении и подходит для случаев, когда источников или немного, или не стоит задачи сортировки входящих сообщений. Второй продукт более «развесист», при его развертывании не обойтись без чтения документации, однако эта «развестистость» дает очевидно большую гибкость в решении задач сбора и сортировки входящих логов.

Теперь чуть более подробно. 

Syslog for windows — это форк классического unix-демона syslog. Собранный для работы в Windows, умеет регистрироваться и работать как системная служба (конечно, возможен и «ручной» запуск). Также имеется возможность работы в режиме «multi-instance» — регистрируются несколько служб с уникальными названиями. Документация по настройке довольно куцая, однако ее вполне достаточно для написания собственного конфиг-файла, ибо софт написан под выполнение конкретной задачи сбора и хранения логов и умеет только это. Но умеет хорошо.

Для тех, кто знаком с внешниим видом юниксового syslog.conf, многое покажется знакомым — разница лишь в том, что все они пишутся в xml-«обертке». Логика файла проста — в простейшем случае должны быть описаны три сущности: источник (source), назначение (destination) и путь (logpath). У каждой из сущностей есть свой набор настроек, с помощью которых задается их поведение.

Для решения задачи сортировки входящих логов должна быть определена директива filter, работа которой основана на понятиях facility и priority. У каждого отправляемого удаленным syslog-сервером сообщения определен уровень того и другого: facility может иметь численное значение в диапазоне 0..23 или буквенное kern…debug (полный список смотрим в документации); prority, аналогично, задается или численно в диапазоне 0..7, или буквенно — emerg..debug.  Таким образом, общая идея сортировки входящих сообщений — группировка по источнику (используем разные уровни facility для разных устройств) или по важности сообщений (по уровню proirity). Количество описанных фильтров и назначений не ограничено (разве что уровней facility всего 24, а удобных для работы уровней local — и того меньше, 8), главное, чтобы в каждом logpath было по одному того и другого. 

 syslogd —install —instance cisco

 syslogd —install —instance linux

одна из них зарегистрируется как syslogd_cisco и будет слушать 514/udp, другая — как syslogd_linux на порту 515/udp.

Входящие сообщения с удаленных syslog-серверов (настроенных на передачу данных на заданный сервер) пишутся в разные файлы согласно назначенным уровням facility. Опцией logdir мы задаем каталог хранения логов. В данном случае указан относительный (от места установки syslogd) путь, однако можно указывать и абсолютный.

Прямо в описании destination можно задать и опции ротации — с какой периодичностью и глубиной хранить историю (filename переименовывается в filename.1 и так далее до величины backlogs).

Помимо этого, все сообщения (включая те, что не попали ни в один из фильтров) записываются в общие log-файлы default.log и default1.log.

Практическая эксплуатация показала надежность этого решения — службы работают стабильно, друг дружке не мешают, никаких подвисаний себе не позволяют. Однако стоит помнить, что при наличии проблем в сети, связанных как с загруженностью каналов, настройкой коммутаторов или с иными причинами, данные могут быть не доставлены — протокол udp не гарантирует доставку пакетов.
 

Всем привет.

Как то мы разбирали ранее что события с Windows-сервера можно перенаправить на другой Windows-сервер.

Это легко можно устроить с помощью групповой политики. Для этого в групповой политике в ветке “Computer Configuration –> Policies –> Administrative Templates –> Windows components –> Event Forwarding” установить параметр “Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager” в значение “Enabled” со следующим значением опции “SubscriptionManagers”: Server=http://<Event Collector FQDN>:5985/wsman/SubscriptionManager/WEC

Для протокола HTTPS прописываете обмен через порт 5986.

И надо не забыть сказать кто(hostname or IP-adr) имеет право эти события забирать в политике Windows Components/Windows Remote Management (WinRM)/WinRM Service. This policy setting allows you to manage whether the Windows Remote Management (WinRM) service automatically listens on the network for requests on the HTTP transport over the default HTTP port. If you enable this policy setting, the WinRM service automatically listens on the network for requests on the HTTP transport over the default HTTP port. To allow WinRM service to receive requests over the network, configure the Windows Firewall policy setting with exceptions for Port 5985 (port for HTTP).

Но я решил такую трансляцию разнообразить и передавать все события и на сервер syslog для страховки. Для начала решаем чем же сделать шлюз.

Еvtsys.

Для того чтобы включить трансляцию событий из журналов сервера в syslog надо доставить на него один маленький сервис. Этот сервис Еvtsys хорошо известен в сети, и не менее популярно описан как самим автором так и благодарными пользователями.

Его установка весьма проста.

copy evtsys.* %systemroot%system32
%systemroot%system32evtsys.exe -h SYSLOGSRV -s 240 -i
net start evtsys

где SYSLOGSRV это имя нашего Syslog-сервера.

Далее неплохо бы поправить файл конфига %systemroot%system32evtsys.cfg
net stop evtsys
…правка…
net start evtsys

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

XPath:Application:<Select Path=»Application»>*</Select>
XPath:Security:<Select Path=»Security»>*</Select>
XPath:Setup:<Select Path=»Setup»>*</Select>
XPath:System:<Select Path=»System»>*</Select>

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

XPath:Microsoft-Windows-Sysmon/Operational:<Select Path=»Microsoft-Windows-Sysmon/Operational»>*</Select>
XPath:Directory Service:<Select Path=»Directory Service»>*</Select>
XPath:Security:<Select Path=»Security»>*[System[Provider[@Name=’Microsoft-Windows-Security-Auditing’ or @Name=’EvtSys’]
and (EventID=4624 or EventID=4625 or EventID=4720 or EventID=4725 or EventID=4726 or EventID=4740 or EventID=4767 or EventID=4771)]]</Select>

Краткая справка по 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)
По умолчанию system daemons пишет в local1.

Logparser.

Есть еще одна возможность тянуть события с журналов сервера ничего дополнительно не устанавливая на сервер. Оказывается горячо любимый Logparser может не только отобрать то что мне надо, но и передать результат в формате Syslog на другой сервер. К примеру формируем SQL-запрос в диапазоне прошедших суток.

fexp2.sql:
=========
SELECT  TimeGenerated,
        CASE SourceName
          WHEN ‘EventLog’ THEN ‘local0’
          WHEN ‘Service Control Manager’ THEN ‘daemon’
          WHEN ‘Print’ THEN ‘lpr’
          WHEN ‘Kerberos’ THEN ‘auth’
          WHEN ‘NETLOGON’ THEN ‘logaudit’
          WHEN ‘Application Popup’ THEN ‘local7’
          ELSE ‘local0’
        END AS MyFacility,
        CASE EventTypeName
          WHEN ‘Error event’ THEN ‘err’
          WHEN ‘Warning event’ THEN ‘warning’
          WHEN ‘Information event’ THEN ‘info’
          ELSE ‘info’
        END AS MySeverity,
        ComputerName,
        STRCAT(SourceName, ‘:’),
        EventID,
        Message
INTO @%Output%
FROM \%Source%Security
WHERE (EventID IN (4624;4625;4720;4725;4726;4740;4767;4771)
AND (TimeGenerated > TO_TIMESTAMP(‘%DY%’,’yyyy-MM-dd’) AND TimeGenerated <= TO_TIMESTAMP(‘%DT%’,’yyyy-MM-dd’)))

И не забываем в конце вызова Logparser указать параметр -o:SYSLOG

@echo off
set Source=DC01
set Output=SYSLOGSRV

set D=%date:~-10,2%
set /A D -= 1
set DateT=%date:~6,4%-%date:~3,2%-%D:~0,2%

set D=%date:~-10,2%
set /A D -= 2
set DateY=%date:~6,4%-%date:~3,2%-%D:~0,2%

Logparser.exe file:fexp2.sql?Out=%Output%+Src=%Source%+DT=%DateT%+DY=%DateY% -o:SYSLOG

Работает! Отличие от первого варианта — да, это будет не в режиме онлайн. Но можно исправить код запроса и установить вызов Logparser-а каждые 5 минут в планировщик задач. Или даже чаще.

Итак наш источник событий настроен, а что же у нас там с приемником т.е. Syslog-севером.

Tftpd64 сервер.

Все просто, все понятно — единственное что нет никаких фильтров на приеме сообщений и их просмотре. Поэтому я временно задействовал другой SYSLOG-сервер.

Visual Syslog сервер.

Успехов.

Please Note: This article is valid for EventReporter in addition to WinSyslog!

Windows NT/2000/XP/2003/Vista/2008/Windows 7 systems monitoring is really important for all small to large sized enviroments. MonitorWare line of products helps to accomplish this important task. This article is to help you establish a small setup to monitor your Windows systems.

This article is strictly task focused. It does not describe why the systems should be monitor nor does it provide any further background. Please see the respective backgrounders or each of the products documentation on this. This article is a step-by-step description of what you need to do in order to centrally monitor your Windows systems.

Centralized Event Reports

In this step-by-step guide, EventReporter is configured to work together with Adiscon’s WinSysLog and MoniLog to automatically generate event summaries for the monitored servers and other devices.

This guide focuses on a typical small to medium business topography with a single geographical location and 5 Windows clients and a central hub server. All systems are well connected via a local Ethernet. Event reports from all machines should be stored in a log file. The administrator shall receive daily consolidated event reports.

What you need

In this guide, I am focusing on building a solution with Adiscon’s EventReporter, WinSyslog and MoniLog. This combination allows you to centralize all your event logs and report events from them. Free 30 day trial versions are available at the respective product sites (links below), so you can try the system without the need to buy anything.

You need to run the following products:

• one EventReporter for each system that is to be monitored. In our scenario, this means 6 copies, one for each client and one for the central hub server to be monitored. (if you want to monitor the hub server as well.)
• one WinSyslog to receive and store event reports from the EventReporter monitoring agents.
• one MoniLog to automatically generate consolidated reports based on the gathered log data in a file.

Note: Please note that to deliver MoniLog reports, you need a local web server (for example Microsoft’s IIS or Apache) and a mail server capable of talking SMTP (most modern servers support this). Make sure that you log on to each machine with a sufficiently privileged user account.

MonitorWare Console

MonitorWare Console can also be used with EventReporter and WinSyslog. MonitorWare Console is a very strong and comprehensive tool that will help you out in carrying out sophisticated analysis of your system. For more information about MonitorWare Console, please refer to its manual and to have a clear idea about Monilog and MonitorWare Console reporting features, please visit Comparision of Monilog Report and System Status Report of MonitorWare Console.

Step 1 – Download Software

Please check the web sites for new versions of respective products if you downloaded your copies a while ago. Security and monitoring is a short lived business, and new product versions can appear quickly.

Please visit www.eventreporter.com/en/download and www.winsyslog.com/en/download to download the latest versions of EventReporter and WinSyslog respectively. In addition to these, you also need the MoniLog product. A free, full-featured 30 day trial is available at www.monilog.com/en/download/.

Step 2 – Install WinSyslog

Identify the system on which WinSyslog (and probably MoniLog) should run on. Take a note of its IP address or host name. You’ll need this value when configuring the EventReporter clients. For our example, I assume this system has an IP address of 192.168.1.0.

Run the WinSyslog setup with default parameters. When setup has finished, WinSyslog automatically is configured to operate as a simple Syslog server. However, it does not yet use file logging as we need that. We’ll later setup WinSyslog to write data into a file and also to configure Syslog server service, if you do not have it.

Step 3 – Install EventReporter

Run the EventReporter setup program on all systems that should be monitored. This means you need to run it on all 5 clients and the central hub server.

For larger installations (with many more servers) there are ways to set it up in a simpler fashion, but in a scenario like ours, it is faster to install it on each machine manually. You can install it with the default settings. When setup has finished, the program automatically is configured to operate as a simple EventReporter. However, it does not yet forwards the log to Syslog server. So we will go ahead and change this on each of the machines or by launching it on one machine and remotely connecting to the others. It is your choice. In this sample, I use the EventReporter on each machine (it is easier to follow). We will also see configuring an event log monitor service, if you do not have it.

Step 4 – Install Monilog

A standard setup program installs the application. The install set (the ZIP file you downloaded) contains a standard setup program and it’s necessary helper files. Please unzip the archive to any directory you like. After unzipping, simply double-click “setup.exe” and follow the onscreen instructions.

There are also self extracting exe files available for download. If you downloaded these versions, there is no need to separately unzip the program. The self extracting version might also start the setup process automatically. If you have Windows Installer already present on the target system, you can also setup the product by simply double clicking the .MSI file. Windows Installer is present on all Windows 2000 systems.

Step 5 – Create a RuleSet to Forward by Syslog (EventReporter)

Please note that delete the previous services or rules sets to follow or save those to registry file not binary for later use. To save your settings follow the link and just dont zip & send that file to us.

The steps to configure the EventReporters are as follows (repeat this on each of the 5 client machines). This step needs not to be done on the central hub server as well!:

1. Start EventReporter.

2. Select your language – in this example, I use English, so it might be a good idea to choose English even if that is not your preference. You can change it any time later, but using English makes it much easier to follow this guide here.

3. Then define a new rule set, right click “RuleSets”. A pop up menu appears. Select “Add RuleSet” from this menu as shown below:

4. Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Forward Syslog” in this example. The screen looks as follows:

Click “Next”. A new wizard page appears.

5. Select only Forward by Syslog. Do not select any other options for this example. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.

6. As you can see, the new Rule Set “Forward Syslog” is present. Please expand it in the tree view until the action level of the “Forward Syslog” Rule and select the “Forward by Syslog” action to configure.

7. Replace the message format from the original syslogformat to MoniLog format. To do so, click on “Insert” and then “Replace with MoniLog Format”. Also, please uncheck “Add Syslog Source when forwarding to other Syslog servers” Option and type the IP address or host name of our central hub server in the “Syslog Server” field:

8. Make sure you press the “Save” button – otherwise your changes will not be applied.

Step 6 – Create an EventLog Monitor to get all the Events from the Machine (EventReporter)

1. First, please rightclick on “Running Services” node in the left treeview (TOC). Select “Add Service” and then “Event Log Monitor” in the opened popup menu:

2. A wizard should open up, which looks like the screenshot below. Here type the name of the “Event Log Monitor” (In our case we will name it “My EventLog Monitor”). Then click on “Finish”:

3. Now the properties tab of the newly created “EventLog Monitor” will open up. Please leave it at default settings and still change the “Rule Set to use” to our above created “Forward Syslog” RuleSet. Please do not forget to save the changes.

Step 7 – Create a simple Syslog server on WinSyslog

Please note that delete the previous services or rules sets to follow or save those to registry file not binary for later use. To save your settings follow the link and just dont zip & send that file to us.

The Syslog server will operate as a standard Syslog server on the default port of 514/UDP. All incoming data will be written to a single text file.

Step 8 – Defining a Rule Set for File Logging

The rule set specifies what action to carry out. You might be tempted to define the service first, but starting with the rule set makes things easier as it will be already present when the service is defined later and needs to be bound to a rule set.

To define a new rule set, right click “Rules”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:

Then,a wizard starts. Change the name of the rule set to whatever name you like. We will use “Write Syslog Log File” in this example. The screen looks as follows:

Click”Next”. A new wizard page appears:

There,select file logging. Do not select any other options for this example. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”.

This is just a confirmation page. Click “Finish” to create the rule set.

The wizard closes and the client shows a newly created rule set.

As you can see, the “Write Syslog Log File” rule set is now present. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a “File Logging” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

As you can see, none of the filter conditions are enabled. This means that all information units (incoming messages) will be matched by these filter conditions. As such, the rules for the “File Logging” action will always be carried out.

Please note that this also means that all Syslog priorities and facilities will be written to the same file.

Now let us check the “File Logging” action itself. Please select it in the tree view:

Please enter a “File Base Name”. In our case we will name it “EventReporter”, cause all the Data comes from EventReporter’s. Its also important to make sure that the directory you specify exists! If it does not yet exist, please create it before you start the service. If the directory does not exist, the service is not able to store any files, last but not the least, do not forget to save the changes you do.
Note:Do NOT change anything else in the “WriteToFile-Action Configuration”!

Now you have a workable rule set for logging incoming messages to a text file.

Step 9 – Create a Syslog Server Service

Now we need to define a Syslog server service. A Syslog server is also sometimes called a “Syslog daemon”, “Syslogd” or “Syslog listener”. It is the process that receives incoming messages.

To define it, right click on “Services”, then select “Add Service” and the “Syslog Server”:

Once you have done so, a new wizard starts:

Again, you can use either the default name or any one you like. We will use “My Syslog Server” in this example. Leave the “Use default settings” selected and press “Next”:

As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client. There, you will see the newly created service beneath the “Services” part of the tree view:

To check its parameters, select it:

As you can see, the service has been created with the default parameters. As such, it operates as a RFC compliant standard Syslog server.

Please note that the “Write Syslog Log File” has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. By default, the wizard will always assign the first rule set visible in the tree view to new services. If another one is to be used, you need to change it to the correct one here in the service definition.

Also, note that the wizard uses the default properties from the “Service Defaults”. Obviously, if these are changed, the default properties for new services will differ.

This procedure completes the configuration of the Syslog server. Please do not forget to click save button and changes will start working after application restarts.

Monilog for Reporting

To deliver MoniLog reports, you need a local web server (for example Microsoft’s IIS or Apache) and a mail server capable of talking SMTP (most modern servers support this). Please make sure you log on with a sufficiently privileged user account.

Preparing Web Server for MoniLog

MoniLog publishes its reports through the local web server (central hub server).

To avoid confusion, we recommend creating a separate directory on the web server for MoniLog. Let us assume you use Microsoft Internet Information Server and run it in the default configuration. Then, you web pages are stored in the c:inetpubwwwroot directory. Create a subdirectory “monilog” directly beneath this directory.

Configuring Monilog

When setup has finished, start MoniLog, select your language (I have used English for this tutorial) and perform the following steps:

1. First, switch to the “General” tab.

2. “Logs Location” expects the DSN or Location where logs are dumped. You specify the location for your log file. Here we specify location of log file.

3. Select your “Select Syslog server type”.

4. Change the “Log prefix/Log name label” to the prefix you defined in your “WriteToFile” action in WinSyslog. In our case we named it “EventReporter”.

5. Next is to check the “Process Non-Windows Syslog messages” box. Leave all other options by default. Now it should look as follow:

Figure 1: General Tab Settings Form – For Log Files

Click “Apply” after making your changes!

5. This has already enabled MoniLog reporting. Now, we can verify the installation. To do so, switch back to the “Profiles” tab. Click the “New Profile” button and enter a name. In this example I use the name “Profile 1”.

Figure 2: Creating New Profile

Click “OK” button to create a new profile.

6. Under “Reports Location”, enter the directory where MoniLog reports should be stored. In our sample, we use “c:inetpubwwwroot”. Leave all other settings as default. The tab should look like this one:

Figure 3: Configuring Reports Location

Click “Apply” to save your changes!

7. Next step is to set your report options. To do so, click “Report Options”. A new window opens. Check Success Audit and Information. Now it should looks like this one:

Figure 4: Report Options Form

Click on “OK” to close the windows by using default options.

8. Click “Analyze now” to test it. After a short while, a browser window with a MoniLog report will appear. The actual content of this report varies greatly. It depends on which events have been forwarded while setting up the agents. Probably, your report will be empty. This simply indicates that there was not yet any data to be analyzed. Immediately after setup, this is OK. If you don’t receive any data after some hours then of course there is something wrong. If that is the case, check the steps done before. A typical report looks like follows:

Figure 5: A typical Monilog report

9. Now we have verified the system is working. Next, we can schedule the automatic report. To do so, we need to check “Enable Schedule” and also “Enable Email delivery”. A quick reminder: we would like to receive a pointer to the report via email each working day. We first need to set the web directory the reports are to be stored to and enable email delivery. It is all done in the following screenshot:

Figure 6: Enabling Email delivery and report scheduling options

The “Email Options” and “Scheduled Options” become colored and are now available.

10. Now we need to configure the email options. Click “Email Options…”. We assume the web server (192.168.0.1) is also acting as a mail server. The emails should be sent to “admins@sample.adiscon.com”. With that, the dialog looks like follows:

Figure 7: Configuring Email notification settings

Important: make sure the values match your configuration! This is vitally important because otherwise MoniLog is incapable of sending email correctly. Click “OK” to apply the new settings.

11. Next, click the “Report Options…” button. As we schedule reports only on working days, we need to tell MoniLog that it should include all those events occurred since its last run into the reports. We cannot leave the default of 24 hours, as this would exclude the weekend’s events. So change the “Report Type” option to “From last run till now” as seen below.

Figure 8: Setting Report Options form

Click “OK” to apply the setting.

12. Lastly, click on “Schedule Options” to set a schedule. As long as no schedule is set, no reports will be generated automatically. In our sample, we let MoniLog generate reports each working day at 8:00 in the morning. Weekends are not enabled. The dialog looks like this:

Figure 9: Configuring report generation schedule

13. Click on “OK” to apply the settings.The MoniLog service has not yet been started. It generates the scheduled reports (so you don’t need to run the client in foreground).

14. To conclude your configuration of MoniLog, start the service. To do so, select “Service”, then “Start Service” from the menu. This will start the service. During setup, the service is set to start automatically with system startup. So there is no need to manually restart the service after a reboot.

MoniLog is now completely configured. You will not immediately receive reports, because they will only be generated at 8 am each working day. So you need to wait for the next morning. If you would like to change the schedule to have an immediate feedback, please go to “Schedule” and change the time to be a few minutes in the future. Then click “OK” and restart the service. This can be done via the “Service” menu. A restart is necessary because the service reads changed parameters at startup, only.

Please Note: The only difference between configuring your reports to be generated either from Log Files or on underlying database is Step 2. From Step 3 onwards settings are the same.

You are done!

Well, this is all you need to do to configure the basic operations. Once you are comfortable with the basic setup, you can enhance the system with local pre-filtering of event, enhanced logging and alerting (with EventReporter and WinSyslog ) and changing report options (with MoniLog / MonitorWare Console).

What is recommended setting for MoniLog and Why?

Let’s quote Rainer Gerhards, design lead for the overall MonitorWare line of products, here:

Typically, MoniLog should work with Log Files, and not with the database. As using files is the recommended way with MoniLog. Why is it recommended? Because it is much faster! Why do we support database, too? Because this allows easier integration e.g. with the Web Interface! Would I recommend MoniLog and database if a customer also needs to run the Web Interface? In most cases: No! From a performance point of view its better to create both text files and database content.

Configures a Syslog Server service. Multiple protocols (IPv4/IPv6
and UDP/TCP) can be configured and are supported.

When configuring Syslog Services, the functionality can be checked
using the Test Syslog Server button. It will open the Syslog Test
Message function from the configuration client.

Service — Syslog Server Global Properties

Permitted Peers¶