Настройка сервера сбора логов на Windows Server

Обновлено 07.09.2022

logs file logo

Добрый день! Уважаемые читатели и гости 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. Открывайте командную строку от имени администратора и введите команду:

winrm qc или winrm quickconfig

Включение WinRM

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

Enable-PSRemoting

Включение WinRM через PowerShell

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

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

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

Добавление в группу Event Log Readers

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

Отсутствие оснастку управления локальными группами на контроллере домена

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

Читатели журнала событий

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

Error - Last retry time: 02.09.2022 12:40:22. Code (0x138C): <f:ProviderFault provider="Event Forwarding Plugin" path="C:\Windows\system32\wevtfwd.dll" xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault"><t:ProviderError xmlns:t="http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog">Windows Event Forward plugin can't read any event from the query since the query returns no active channel. Please check channels in the query and make sure they exist and you have access to them.</t:ProviderError></f:ProviderFault> Next retry time: 02.09.2022 13:00:22.

Ошибка 0x138C

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

wevtutil gl security или Wevtutil get-log security

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

channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

Права доступа к журналу безопасности

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

wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

или

wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

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

Добавление прав на чтение журнала безопасность

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

(Computer Configuration - Policies - Windows Settings - Security Settings - Restricted Groups)

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

Добавление групп в Restricted Groups

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

Добавление централизованных прав на логи Windows

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\EventLog\Security

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

Назначение прав на журналы Windows через реестр

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

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

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

wecutil qc

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

Настройте службу сбора событий

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

Настройка переадресованных событий

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

%SystemRoot%\System32\Winevt\Logs\ ForwardedEvents.evtx

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

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

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

Создание новой подписки в просмотре событий

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

Добавление серверов для сбора с них событий

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

Добавление серверов в список подключенных на подписку

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

Тестирование доступности сервера по подписке событий

4723,4724,4725,4726,4740,5139,5141,4739,1102,4735,4737, 4730,4734,5136,5137

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

Выбор событий в подписке Event Log

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

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

Настройка учетной записи для сбора событий Windows

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

Тестирование подключения сервера к подписке событий

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

Subscroption Runtime Status

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

Поступление перенаправленных логов

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

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

0x138C

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

Subscription Runtime Status Access is denied

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

Error – Last retry time: 2022-08-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time

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

The description for Event ID 6398 from source A cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

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

Централизованный сбор логов в Windows с разных компьютеров штатными средствами - источники в реестре

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

https://github.com/sanglyb/ps-copy-log-source если вдруг по какой-то причине скриптов не будет в доступе, то можете скачать их тут

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

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

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

.\export-log.ps1 crm

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

Выгрузка зависимостей для приложений из реестра

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

Выгрузка журнала Kaspersky с зависимостями

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

.\import-log crm

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

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

Посмотреть кто слушает и что netstat -ant, далее netsh http show iplisten

И удаляем:

netsh http delete iplisten ipaddress=ip

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

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

Конфигурация компьютера - Политики - Административные шаблоны - Компоненты Windows - Пересылка событий (Computer Confiruration - Policies - Administrative Tempates - Windows Components - Event Forwarding)

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

Server=http://FQDN:5985/wsman/SubscriptionManager/WEC

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

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

Настройка политики Configure target Subscription Manager

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

Автор - Сёмин Иван

2 Responses to Настройка сервера сбора логов на Windows Server

  1. lostprey:

    Добрый день!
    Есть проблема с отправкой логов с самого коллектора. Т.е. на коллектор отправляют логи все серверы и пк успешно, кроме самого коллектора. Ошибка Access denied 5 в журнале форвардинга. Дескрипторов безопасности перепробовал много, никакие не помогают. На соседней независимой площадке такой проблемы нет. Есть мысли куда копать?

  2. Иван Семин:

    Нужно описание вашей схемы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *