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

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