Windows event collector что это

Время на прочтение
17 мин

Количество просмотров 61K

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

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

Категория аудита	Подкатегория аудита	События аудита	EventID	Комментарии
Вход учетной записи	Аудит проверки учетных данных	Успех, Отказ	4776	Целесообразно контролировать на домен-контроллерах при использовании NTLM-аутентификации.
Аудит службы проверки подлинности Kerberos	Успех, Отказ	4771	Неуспешная аутентификация учетной записи на контроллере домена с использованием Kerberos-аутентификации.
4768	Запрос билета Kerberos, при этом следует анализировать коды ответа сервера.
Примечание: Данный тип аудита следует включать на контроллерах домена, при этом для детального изучения попыток подключения и получения IP-адреса подключающегося устройства на контроллере домена следует выполнить команду nltest /dbflag:2080ffff и проводить аудит текстового лог-файла %windir%\debug\netlogon.log
Управление учетными записями	Аудит управления учетными записями компьютеров	Успех	4741	Заведение устройства в домен Active Directory; может использоваться злоумышленниками, поскольку любой пользователь домена по умолчанию может завести в домен 10 устройств, на которых может быть установлено неконтролируемое компанией ПО, в том числе вредоносное.
Аудит управления группами безопасности	Успех, Отказ	4728	Добавление члена глобальной группы.
4732	Добавление члена локальной группы.
4756	Добавление члена универсальной группы.
Аудит управления учетными записями пользователей	Успех, Отказ	4720	Создание учетной записи.
4725	Отключение учетной записи.
4740	Блокировка учетной записи.
4723	Смена пароля.
4724	Сброс пароля.
Подробное отслеживание	Аудит создания процессов	Успех	4688	При создании процесса.
4689	При завершении процесса.
Примечание: Чтобы для командного интерпретатора велась запись введенных команд, следует включить политику «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Система — Аудит создания процессов -> Включать командную строку в события создания процессов». Примечание: Чтобы велась запись выполняемых PowerShell-команд и загруженных PowerShell-модулей, следует включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Компоненты Windows — Windows PowerShell» политики «Включить ведение журнала модулей» (в настройках политики указать все модули символом «*») и «Включить регистрацию блоков сценариев PowerShell» (в настройках политики отметить check-box «Регистрация начала или остановки вызова блоков сценариев»). Работа PowerShell-скриптов регистрируется с EventID=4104,4105,4106 в журнале Microsoft-Windows-PowerShell/Operational, а загрузка PowerShell-модулей регистрируется с EventID=800 в журнале Windows PowerShell.
Вход/выход	Аудит выхода из системы	Успех	4634	Для неинтерактивных сессий.
4647	Для интерактивных сессий и RDP-подключений.
Примечание: При этом следует обращать внимание на код Logon Type, который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.).
Аудит входа в систему	Успех, Отказ	4624	При успешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM и Kerberos-аутентификации.
4625	При неуспешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM аутентификации; при Kerberos-аутентификации на контроллере домена создается EventID=4771.
4648	При попытке входа с явным указанием учетных данных, например, при выполнении команды runas, а также при работе «хакерской» утилиты Mimikatz.
Примечание: При этом следует обращать внимание на код входа (Logon Type), который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). Целесообразно также обращать внимание на код ошибки (Status/SubStatus), который также сохраняется в событии аудита и характеризует причину неуспешного входа — несуществующее имя учетной записи, недействительный пароль, попытка входа с заблокированной учетной записью и т.д.
Аудит других событий входа и выхода	Успех, Отказ	4778	RDP-подключение было установлено.
4779	RDP-подключение было разорвано.
Аудит специального входа	Успех	4672	При входе с административными полномочиями.
Доступ к объектам	Аудит сведений об общем файловом ресурсе	Успех, Отказ	5145	При доступе к системных сетевым ресурсам, таким как \\C$\ . Данное событие будет создаваться при работе ransomware, нацеленного на горизонтальное перемещение по сети.
Аудит других событий доступа к объектам	Успех, Отказ	4698	При создании задания в «Планировщике задач», что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе.
Изменение политики	Аудит изменения политики аудита	Успех	4719	Изменение политики аудита.
4906	Изменение настройки CrashOnAuditFail.
Примечание: Изменить реакцию ОС на невозможность вести журнал аудита безопасности (настройка CrashOnAuditFail) можно в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» в политике «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности».
Система	Аудит расширения системы безопасности	Успех	4610 4614 4622	При появлении в системе новых пакетов аутентификации, что не должно происходить несанкционированно.
4697	При создании нового сервиса, что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе.

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

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

1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY\NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN\Event Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
  </Query>
</QueryList>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

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

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe – файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>

2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
  </Query>
</QueryList>

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
  </Query>
</QueryList>

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
  </Query>
</QueryList>

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and 
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]] 
and 
*[EventData[Data[@Name='TargetImage']='C:\Windows\System32\lsass.exe']] 
and 
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
  </Query>
</QueryList>

Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

Источник

А вы в курсе, что в винде, начиная с 2008R2 есть замечательная возможность – собирать логи с разных компьютеров в сети, в одном месте? Эта функция называется Windows Event Forwarding. Сегодня покажу как её настроить.

Настраивать функцию можно двумя способами.

Collector Initiated – это когда сервер, на который должны поступать все записи о событиях сам шлет запросы на машины в сети, и получает с них логи.

Source initiated – когда, компьютеры сами стучаться на сборщик и отправляют ему информацию. Настройка тут производится посредством GPO, где указывается адрес сборщика событий.

Я покажу как собирать логи на примере Collector Initiated.

Первым делом, необходимо настроить машины, с которых нужно собирать логи.

Для этого на них должно быть включено удаленное управление, или другими словами – должен быть настроен winrm. Чтобы его настроить необходимо выполнить команду от имени администратора:

winrm qc

Либо можно воспользоваться powershell

Enable-PSRemoting

Дальше необходимо добавить учетную запись пользователя, или компьютера, на который будут отправляться логи (если вы по какой-то причине не захотите указывать при настройке учетную запись пользователя) в группу Event Log Readers. Но, в некоторых случаях членства в данной группе может быть недостаточно, тогда придется добавлять учетки в группу администратора.

Также если вы хотите собирать журналы безопасности, тогда придется учетной записи Network Service дать право на их чтение. Сделать это можно командой:

 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)

Тут все указанные SIDы – стандартные, мы добавляем запись (A;;0x1;;;S-1-5-20).

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

Wevtutil get-log security

Если у вас много компьютеров, тогда процесс выдачи прав можно сильно упростить выполнив команду в PowerShell:

Invoke-Command -ComputerName (Get-Content .\computers.txt) -FilePath .\security.ps1

Как вы поняли, в папке, откуда вы выполните эту команду должно быть 2 файла:

Computers.txt – список компьютеров, на которых нужно выполнить команду. Каждый – с новой строки.

Security.ps1 – тут только наша команда — 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)

На этом настройка отдающих – завершена. Переходим к настройке сервера, где всё будет храниться.

Первым делом включим службу Windows Event Collector, для этого, от имени администратора выполним:

wecutil qc

В оснастке службы должна будет появиться данная служба, с типом запуска Delayed Start.

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

Запускаем оснастку просмотр событий – eventvwr.msc, windows logs, правой кнопкой по Forwarded Events. И ограничиваем размер, чтобы логи не терялись – лучше выбрать Archieve the log when full, do not owerride events. И конечно указываем путь, где файл должен лежать.

Дальше, создадим подписку – правой кнопкой по Subscriptions – Create Subscription

Тут нужно ввести имя, выбрать лог, куда должны складываться события (по умолчанию – Forwarded Events, по этом ему мы и меняли расположение и размер).

Сразу идем в Advanced Settings и указываем пользователя, от имени которого будет действовать сборщик (если вы указывали имя компьютера ранее на клиентах, тогда этот шаг пропускаем).

Выбираем события, которые должны собираться – select events. Тут можете настроить под себя, как вам угодно. Но не стоит выбирать абсолютно всё, то есть и стандартные логи, и логи приложений, иначе практически наверняка у вас выскочит ошибка, во время сбора логов, о слишком большом запросе.

Осталось только добавить компьютеры, с которых хотим собирать информацию – select computers. После добавления каждого из компьютеров лучше сразу жать test, чтобы удостовериться, что всё будет работать как надо.

Выжидаем некоторое время, и смотрим на статус созданного коллектора. Если он активный, значит в скором времени в forwarded events начнут появляться записи.

Но на этом еще не всё. Когда к вам начнут прилетать записи, вы скорее всего увидите, что для записи отсутствуют описания. Что-то вроде:

The description for Event ID X 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.

Частично данную незадачу можно решить, выполнив команду:

wecutil ss "AllServers" /cf:Events

И перезапустив службу Windows Event Collector. По умолчанию, за место events установлен RenderedText. И по умолчанию события пререндерятся на удаленных компьютерах и отправляются с локализованными строками, из-за чего есть вероятность, что события не будут распознаны. Кроме того, изменение на Events немного снизит нагрузку на сеть и компьютеры – источники.

Но и после изменения параметра /cf проблема может уйти только частично. Как правило, указанные выше записи будут появляться для каких-то костюмных служб, которых нет на сборщике, например Exchange или SharePoint или еще что-то.

В событии внизу будет указано, кто является источником сообщения, из чего можно сделать вывод – чего не хватает.

Все источники и то, на какие DLL они завязаны можно посмотреть в реестре – HKLM\SYSTEM\CurrentControlSet\services\eventlog. Тут всё разбито по логам, типа Application, System и т.п. Соответственно если нужного источника тут нет, то его необходимо экспортировать с компьютера, где он есть. Соответственно и нужные, как правило, DLLки, со словарями можно посмотреть в этих ветках реестра – это параметры, где есть file в названии. Пути до файлов, для удобства, после импорта можно менять.

Если события пишет небольшое приложение, то источников для него, скорее всего будет 1-2, и их можно спокойно перенести руками, но вот если это что крупное, например exchange, то источников там уже 147. Согласитесь, такое количество руками переносить – мазохизм. Поэтому был написан скрипт, который всё сделает за нас.

Скрипт лежит на GitHub — https://github.com/sanglyb/ps-copy-log-source

Что нужно делать:

Копируем скрипт export-log на сервер, где нужная служба есть, переходим в папку со скриптом и запускаем его от имени администратора с ключом, которым является часть имени источника событий. Например, если мы увидели в просмотре событий, что нет описаний для MSExchange Certificate, то скрипт можно запустить так:

.\export-log exchange

Если источником событий является Microsoft-Sharepoint Foundation, то запустить можно с ключом sharepoint.

Скрипт создаст папку, пройдется по всем разделам eventlog, сделает дамп всех разделов, где в имени присутствует ключ, исходя из путей в параметрах скопирует в папку нужные файлы, а также создаст текстовый файл со списком сдампленных разделов.

Далее нужно скопировать созданную папку на сервер сборщик логов, в папку со скриптом import-log, перейти в powershell запущенном от имени администратора в папку со скриптом, и запустить его с тем же самым ключом.

.\import-log exchange

Скрипт скопирует нужные файлы, импортирует записи в реестр, и изменит пути до файлов в параметрах. Я сделал, чтобы файлы копировались в папку C:\CustomEvents\[ключ], соответственно папка C:\CustomEvents\ должна существовать.

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

Во время настройки этого хозяйства я столкнулся с некоторыми неприятными моментами, оставлю описание этих моментов тут.

На парочке серверов были непонятки с WinRM. В диспетчере серверов статус удаленного управления был обозначен как неизвестный. При попытке выполнить winrm qc выскакивало сообщение

WinRM service is already running on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.

Error number: -2147024894 0x80070002
The system cannot find the file specified.

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

Google настойчиво предлагал добавить правила в firewall:

netsh advfirewall firewall add rule name="Windows Remote Management (HTTP-In)" dir=in action=allow service=any enable=yes profile=any localport=5985 protocol=tcp

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

Как выяснилось, именно данная ошибка была связана с локализацией системы, на нее был установлен языковой пакет. После изменения языка системы – ошибка ушла, и команда отработала штатно, но доступа – не появилось.

Посмотрел на прослушиваемые порты командой netstat -ant — обнаружил, что порт winrm (5985) слушается только на адресе 127.0.0.1

Выполнение команды

netsh http show iplisten

показало, что iis слушает только на адресе 127.0.0.1

Помогло выполнение команд:

netsh http delete iplisten ipaddress=127.0.0.1
netsh http add iplisten ipaddress=0.0.0.0

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

2. Мы подцепили лог на диск iSCSI и после перезагрузки системы, данный лог стабильно отваливается. Связано это, скорее всего с тем, что после перезагрузки – iSCSI диски, либо переподключаются, либо изначально долго подключаются, и всё это происходит уже после запуска службы event log. Тут помогло указание в свойствах неправильного пути до лога, и когда система ругнется, что путь не верен – нужно указать верный путь, тогда файл подцепится.

Я добавил в планировщик заданий, на событие start up — простенький файл содержащий следующие строчки:

ping -n 240 127.0.0.1
wevtutil set-log ForwardedEvents /lfn:"E:\Forwarded Events\ForwardedEvents.evtx"

Источник

Про большую часть проблем, которые происходят с операционной системой и оборудованием, можно узнать через логи и журналы. В Windows, логи, называются так же событиями (events), а для их просмотра используется интерфейс под названием «Просмотр событий» (Event Viewer). События хранятся на компьютере, на котором они же и создаются. Такая ситуация может вызвать неудобства, если вы работаете со множеством серверов. Мы можем использовать функционал, который называется «Подписки» (Event Subscription) для сбора таких логов в одном месте. Как это можно сделать и будет рассмотрено, на примерах, в этой статье.

Как работают подписки на события

Главный компьютер (сервер), который будет получать и хранить события с других хостов, называют «сборщиком» (collector). Он может работать в двух режимах:

Коллектор может подключаться к выбранным компьютерам сам и забирать с них обновления (в GUI называется «Инициировано сборщиком»/ «Colletor Initiated»). Так же называют pull подпиской;
Компьютеры (клиенты) сами отправляют события на сборщик (сервер) (в GUI «Инициировано исходным компьютером»/»Source Computer Initiated»). Так же называется «event forwarding» или push подпиской.

Моменты, которые я отмечу для «Colletor Initiated»:

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

То что я отмечу для «Source Computer Initiated»:

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

Мой личный выбор — использовать «Collector Initiated» где количество клиентов меньше 10. Если планируется больше, то «Source Computer Initiated». С точки зрения нагрузки — количество клиентов вообще может не играть роли, если клиенты создают по одному логу в 10 минут.

Microsoft, например, рекомендует использовать 4 процессора и 16 ГБ ОЗУ для нагрузки в 2000-4000 клиентов. Как я смог понять это так же равно 3000 событий в секунду.

Логи физически хранятся на дисках. Если логов приходит много, то стоит обратить внимание на скорость дисков.

Предварительная настройка

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

# cmd
winrm qc

# powershell
Enable-PSRemoting

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

Get-Service -ComputerName 'localhost' -Name '*WinRM*' | fl *

WinRM, в зависимости от настроек, может использовать протокол HTTP на 5985/TCP порту либо HTTPS на 5986/TCP порту. Это же касается и сбора событий с компьютеров.

Если вы используете компьютеры, которые находятся в домене, у вас по умолчанию используется Kerberos. В некоторых других случаях может использоваться NTLM. В обоих случаях (Kerberos/NTLM или HTTP/HTTPS), обмен логов зашифрован и подключения проходят аутентификацию. Случай с HTTPS используется, когда вы хотите чтобы аутентификация была так же с помощью сертификатов SSL/TLS. Это может понадобиться, когда у вас компьютер вне домена и вы будете использовать NTLM. Вариант с HTTPS, в статье, рассматривается от части.

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

Test-NetConnection -ComputerName 'localhost' -Port 5985

Еще один важный момент — это работа сервиса подписок WEC (Windows Event Collector) на сервере, который будет собирать и хранить логи. По умолчанию, этот сервис, выключен. Вы должны включить его на сервере.

wecutil.exe qc

# проверяем работу службы через Powershell
Get-Service -Name 'Wecsvc' | fl *

Отправка событий на сервер-сборщик

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

Настройка отправляющего хоста

Для того, чтобы компьютер-клиент знал куда отправлять логи, ему нужно указать URL сервера. Этот url можно указать в групповой (или локальной) политике по пути:

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

По этому пути открыть политику «Настроить конечный диспетчер подписи» и указать строку следующего типа.

Server=http://<полное доменное имя сборщика>:5985/wsman/SubscriptionManager/WEC,Refresh=60

В этой строке, соответственно, нужно указать FQDN сервера, на который будут отправляться события. В моем случае это ‘sr2.domain.local’. Значение «Refresh=60» значит, что раз в 60 секунд будут проверяться новые подписки, а не время отправки логов.

Если вы планировали делать https сервер, то нужно будет указать иной порт (5986) и дополнительно заполнить параметр открытого ключа.

Настройка принимающего сервера

Кроме включенных сервисов (WEC и WinRM) и открытых портов нужно изменить разрешения для URL, которое настраивалось через политику выше. Разрешения по умолчанию могут не работать.

Дело в том, что в редакциях 2012 и старше, права на чтение запросов поступающих на URL ‘http://ВашСервер:5985/wsman/’, выдается только сервису — WinRM. Служба подписок ‘Wecsvs’ так же нуждается в доступе к этому URL. Эта ситуация может отличаться в разных редакциях. У Microsoft не всегда было описание этой проблемы и даже сейчас его сложно найти. Проверить есть ли права в вашем случае можно через следующую команду.

netsh http show urlacl url=http://+:5985/wsman/

Если у вас отображается один пользователь и в параметре SDDL только одна пара скобок «(…)» (как в примере выше), то это говорит об отсутствии нужных разрешений. Чтобы добавить пользователя мы должны удалить предыдущую запись и добавить новую запись.

# удаление
netsh http delete urlacl url=http://+:5985/wsman/
# добавление (рекомендую запускать в CMD, а не Powershell)
netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"

Создание подписки

После этого можно открыть Event Viewer и настраивать подписку нажав следующие кнопки.

В новом окне нужно указать название подписки, например «Сервера SQL». «Конечный журнал» — это место, в которое будут попадать логи. Чаще всего используется журнал «Перенаправленные события» так как он пустой и удобен для сбора логов (не будет путаницы). Часть параметров можно менять после создания подписки.

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

В окне «Выбрать события» можно выбрать журналы, их уровень и установить разные фильтры. Для диагностики и тестирования лучше выбирать один журнал и несколько событий. Большое количество журналов может расходовать весомое количество ресурсов. Во вкладке ‘XML’ настройки так же можно менять. XML так же можно копировать и использовать в других подписках (в т.ч. импорт через wecutil.exe).

В окне «Дополнительно» указывается протокол и скорость передачи событий. Эти настройки соответствуют следующим значениям:

Обычный (Normal) — отправка либо по достижению 5 событий либо раз в 15 минут;
Уменьшенная пропускная способность (Minimize Bandwith) — раз в 6 часов;
Уменьшенная задержка (Minimize Latency) — раз в 30 секунд.

После нажатия кнопок «Ок» подписка будет создана.

При открытии «Состоянии выполнения» вы должны увидеть зеленные галочки у компьютеров, которые вы добавляли. Они могут появиться не сразу (в моем случае это пару минут). Все события будут попадать в журнал «Перенаправленные события».

Зеленые отметки не всегда говорят, что все работает. Например, после подобных настроек у вас будут отправляться большая часть журналов, но некоторые так и не появятся. Например, для журнала «Безопасность» (Security) нужно будет так же изменить параметры доступа.

Настройка доступа для журнала «Безопасность» (Security)

Локальный доступ, к некоторым журналам, требует отдельных прав. Эти права есть у локальных групп «Читатели журнала событий» (Event Log Readers). Журналам «Безопасность» будет читать сервис «Network Service». Т.е. мы должны добавить эту учетную запись в журнал.

Добавить учетную запись можно через политики и собственноручно. Ниже показан вариант, где пользователь «Network Service» добавлялся в группу для сбора логов с домен контроллера.

Если это не домен-контроллер, то учетная запись добавляется в локальную группу через «Управление компьютером».

После добавления пользователей компьютеры нужно будет перезагрузить т.к. иначе «Network Service» не начнет работу. После перезагрузки, в моем случае, события начали приходить меньше чем за 1 минуту.

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

Сбор событий с компьютеров

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

Выдача разрешений на чтение журналов

Кроме открытия порта и запуска сервисов, в зависимости от ситуации, вам может понадобиться добавить в группу «Читатели журнала событий» разные учетные записи:

Учетная запись пользователя или компьютера, который будет забирать логи с удаленных компьютеров. Исключение — администраторы т.к. они уже имеют эти права.
Учетная запись «NETWORK SERVICE», если вы планируете собирать логи с журнала «Безопасность» («Security»). Даже если вы являетесь администратором — это понадобится.

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

Вариант, показанный на скриншоте ниже, работает через политику «Группы с ограниченным доступом» («Restricted Groups»). Будьте осторожны т.к. учетные записи, которые добавляются через эту политику, перезаписывают локальных пользователей в соответствующей группе. Чтобы добавить учетную запись — вам нужно:

Открыть или создать политику, затем пройти по соответствующему пути (видно на скриншоте ниже), нажать правой клавишей по «Группы с ограниченным доступом» и выбрать вариант «Добавить группу»;
Через кнопку «Обзор» выбрать локальную группу в которую вы планируете добавлять учетные записи. В нашем случае это «Читатели журнала событий» или «Event Log Readers»;
Выбрать пользователя, которого вы планируете использовать для сбора логов. В случае, если вы хотите добавить компьютер, то в конце нужно дописать «$», как и в примере ниже с «SR2». Так же добавьте «NETWORK SERVICE», если планируете собирать события из журнала «Безопасность».

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

Для того чтобы учетная запись «NETWORK SERVICE» полноценно заработала — потребуется перезагрузка компьютера.

Создание подписки

Откройте «Event Viewer» и нажмите следующие кнопки для создания подписки:

Переходим на страницу подписок;
Открываем окно создания подписки;
Выберете имя для подписки;
Тип подписки, в этом случае, «Инициировано сборщиком»;
Окно для добавления компьютеров.

В новом окне добавьте компьютер с которого хотите собирать события.

В следующем окне выберете типы журналов, событий и т.д., которые планируете забирать с удаленного компьютера. Рекомендую не выбирать большое количество журналов так как это нагрузит систему (при выборе больше 10 штук у вас появится аналогичное предупреждение).

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

Настройки доставки событий следующие:

Обычная (Normal) — раз в 15 минут или по достижению 5 событий;
Уменьшенная пропускная способность (Minimize Bandwidth) — раз в 6 часов;
Уменьшенная задержка (Minimize Latency) — раз в 30 секунд.

Настройка завершена. Проверьте, что у вас нет ошибок в окне с подписками.

Расширенные настройки подписок через wecutil и wevutil

Wecutil (Windows Event Collector Utility) — программа для настройки подписок, wevtutil (Windows Event Utility) — управление событиями.

Выведем более подробную информацию о конкретной подписке.

wecutil gs "Название подписки"

Мы можем изменить время отправки событий, которое в предыдущем случае равнялось 30000 миллисекундам (30 секунд). Для этого изменим профиль и установим новое значение.

wecutil ss "НазваниеПодписки" /cm:Custom
wecutil ss "НазваниеПодписки" /dmlt:"Миллисекунды"

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

wecutil gs "Название подписки" /f:xml > filename.xml

Этот XML файл можно так же импортировать в качестве новой подписки. Вы так же можете изменить XML файл тем самым минуя некоторых настроек, которые доступны только через ‘wecutil’.

wecutil cs C:\filename.xml

Обратите внимание, что вы должны будете удалить строку с версией и кодировкой XML документа и так же изменить название. Иначе вы будете получать ошибку «Code 0x80070057 The parameter is incorrect». Так же обращайте внимание на строку «ConfigurationMode», если она стоит в «Normal». Импортируемые подписки могут быть либо в режиме «Custom» или без блока «Delivery».

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

wecutil ss TestSubs2 /c:C:\filename.xml

Некоторые подписки имеют ограничения на количество событий отправляемых за раз. В документациях есть два упоминания, как это можно изменить. Первый — через ‘wecutil’ и параметр ‘DeliveryMaxItems’.

Wecutil ss “SubscriptionNameGoesHere” /dmi:1

Второй вариант — через WinRM и параметр ‘MaxBatchItems’. Сам я его не использовал если что.

# просмотр
winrm get winrm/config
# меняем на 5
winrm set winrm/config @{MaxBatchItems="5"}

Поиск ошибок

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

Общая диагностика

Первым, что стоит проверить — это открыты ли порты и запущены ли сервисы. Winrm должен быть запущен на обоих компьютерах. Сервис Wecsvc — собирает события и он должен работать только на сервере.

Get-Service -Name 'Winrm','Wecsvc' | select name,status

Порт должен быть открыт на обоих компьютерах.

'SR1','SR2' | Test-NetConnection -Port 5985

Вы так же можете попробовать подключиться через Winrm используя пользователя у которого есть такие права (у группы ‘Читатели журналов событий’ таких прав нет). Таким образом вы исключите проблему с Winrm.

$cred = Get-Credential
Invoke-Command -ScriptBlock {Get-Location} -Credential $cred -ComputerName 'SR1'

Если у вас не проходит подключение по Winrm, то может проблема в TrustedHost и NTLM подключении, если вы работаете вне домена. В Trusted Host добавляются компьютеры, которым разрешено подключение к текущему. В примере ниже команда, которая разрешает подключаться любым компьютерам.

Set-Item wsman:localhost/client/trustedhosts *

Самым главным окном, которое может рассказать об ошибке, является окно состояния подписки.

Примерно такой же результат можно увидеть, если посмотреть на подписку через консоль.

wecutil gr "НазваниеПодписки"

Кнопка «Повторить» так же может быть полезна, после изменения настроек.

Другие кандидаты на поиск ошибок — это журналы:

Журналы Windows -> Система;
По пути Application and Services Logs (Журналы приложений и служб) -> Microsoft -> Windows -> журналы EventCollector / Eventlog-Forwarding / Windows Remote Management.

Ошибок нет, но логи не приходят

Ошибки могут не появляться если вы создали подписку одновременно на несколько журналов. Вам нужно отметить только один журнал и посмотреть «Состояние выполнения». У вас либо появится ошибка, либо начнут приходить события.

Такая ошибка, как минимум, может произойти когда вы выбрали журнал «Безопасность» с каким-то другим журналом, но не дали права учетной записи «Wecsvc» на чтение данных по URL «http://+:5985/wsman/».

Ошибка 0x80338095 при проверке состояния подключения

Исчезает либо установкой «Оптимизация обработки событий» с «Уменьшенная задержка» в «Обычная» либо даем пользователю «Wecsv» читать данные с URL Wsman с помощью следующей команды (объяснение команды было в статье выше).

# удаление существующей записи
netsh http delete urlacl url=http://+:5985/wsman/
# добавление новой
netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"

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

Ошибка (0x5): Отказано в доступе

Связано с тем, что учетная запись компьютера или пользователя, которую настраивали для подключения, не имеет прав для подключения к компьютеру. Изменяется пользователь в следующем окне.

Ошибка 0x80338126

В этом случае либо закрыт порт/протокол на фаерволе или он указан неверный. Часть команд, которые могут помочь в диагностике.

Посмотреть, что порт открыт, на обоих компьютерах, можно с помощью следующей команды:

Test-NetConnection -ComputerName "SR1" -Port 5985

Проверим, что сервисы запущены и URL по 5985 порту принимает подключение:

Get-Service 'Winrm','Wecsvc'
netsh http show urlacl url=http://+:5985/wsman/

В некоторых случаях нужно убедиться, что WinRM принимает подключение с любых IP и вообще прослушивает 5985 порт на loopback (127.0.0.1) интерфейсе. С этим может быть связана так же ошибка с ID 10149.

winrm enumerate winrm/config/listener

Ну и самое главное, что верный порт указан в самой подписке:

Ошибка 0x138C и 5004

Если у вас добавлен пользователь «NETWORK SERVICE» и есть нужные права на канал WSMAN, то почитайте статью на сайте Microsoft (касается Windows Server 2008-2012 R2). Она основана на добавлении прав через реестр, но в моем случае, на 2019, были использованы решения описанные выше.

Работа с другими журналами приложений и служб

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

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

В следующей команде замените название журнала на ваше. Эта команда выведет конфигурацию журнала.

wevtutil gl /r:localhost "НазваниеЖурнала"

Если посмотреть на пример выполненной команды на скриншоте ниже, то видно, что там используется SID группы «Читатели журнала событий» («S-1-5-32-573»).

Если у вас этой записи нет, то вы можете добавить ее руками. Вам нужно будет скопировать старые разрешения и добавить их к новым SDDL. Значения, которые устанавливаются перед SID значат следующее:

0x01: Read;
0x02: Write;
0x04: Clear;
A — allow.

В примере ниже нужно заменить старые права. SDDL соответствует группе читателей событий.

wevtutil set-log "НазваниеЖурнала" /ca:СтарыеПрава(A;;0x1;;;S-1-5-32-573)

Пример с добавлением SDDL для примера.

Такие же изменения можно посмотреть и увидеть в реестре по пути «HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Название журнала«.

Эти же права можно выдать через политики и они так же могут перезатирать существующие значения:

Computer Configuration — Policies — Administrative Templates — Windows Components — Event Log Service;
Конфигурация компьютера — Политики — Административные шаблоны — Компоненты Windows — Службы журнала событий.

…

Теги:

#windows

#events

#события

Источник

Windows Event Collector is a Windows service (software component) that is used to collect and store events from local and remote computers. It is an important part of the Windows operating system and is used to collect and store events from other computers on the network. This service is used to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server. It is also used to collect and store events from computers running non-Windows operating systems, such as Linux and Mac OS X.

Why is Windows Event Collector Needed?

Windows Event Collector is an important part of the Windows operating system and is used to collect and store events from other computers on the network. This service is used to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server. It is also used to collect and store events from computers running non-Windows operating systems, such as Linux and Mac OS X. The Windows Event Collector service is used to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server. The Windows Event Collector service is used to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server.

The Windows Event Collector service is used to collect and store events from computers running Windows operating systems. It is used to collect and store events from computers running non-Windows operating systems, such as Linux and Mac OS X. The Windows Event Collector service is used to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server. The Windows Event Collector service is used to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server.

Yes, the Windows Event Collector service is safe and secure. It is designed to collect and store events from computers running Windows operating systems, such as Windows 10, Windows 8, Windows 7, Windows Vista, and Windows Server. The Windows Event Collector service is designed to be secure and reliable, and it is regularly updated with the latest security patches and updates. The Windows Event Collector service is also designed to be highly efficient and reliable, and it is designed to be able to handle large volumes of events with minimal impact on system performance.

Service Related Errors and Troubleshooting

If you experience any errors or issues with the Windows Event Collector service, it is important to troubleshoot the issue. The first step is to check the Windows Event Log for any errors or warnings related to the Windows Event Collector service. You can also use the Windows Event Viewer to view the events collected by the Windows Event Collector service. If you are unable to find any errors or warnings related to the Windows Event Collector service, you can try restarting the service or running the Windows Event Collector service in safe mode.

Can Windows Event Collector be Disabled?

Yes, the Windows Event Collector service can be disabled. However, it is not recommended to disable the Windows Event Collector service as it is an important part of the Windows operating system and is used to collect and store events from other computers on the network. If you do need to disable the Windows Event Collector service, you can do so by opening the Services window, selecting the Windows Event Collector service, and then clicking the Stop button.

How to Fix Windows Event Collector?

If you experience any errors or issues with the Windows Event Collector service, you can try the following steps to fix the issue:

Check the Windows Event Log – Check the Windows Event Log for any errors or warnings related to the Windows Event Collector service.
Run the Windows Event Collector service in safe mode – You can try running the Windows Event Collector service in safe mode to see if the issue is resolved.
Restart the service – You can try restarting the Windows Event Collector service to see if the issue is resolved.
Check for updates – Check for any updates to the Windows Event Collector service and install them if available.
Reinstall the service – If all else fails, you can try reinstalling the Windows Event

Источник

Политики аудита Windows

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Утилита Sysmon

XPath-запросы

IRP-система штатными средствами Windows

Как работают подписки на события

Предварительная настройка

Отправка событий на сервер-сборщик

Настройка отправляющего хоста

Настройка принимающего сервера

Создание подписки

<img loading="lazy" decoding="async" alt="Создание подписки в Windows" height="479" src="https://fixmypc.ru/media/uploads/2022/11/10/1.jpg" title="Создание подписки в Windows" width="921" />

Настройка доступа для журнала «Безопасность» (Security)

Сбор событий с компьютеров

Выдача разрешений на чтение журналов

Создание подписки

Расширенные настройки подписок через wecutil и wevutil

Поиск ошибок

Общая диагностика

Ошибок нет, но логи не приходят

Ошибка 0x80338095 при проверке состояния подключения

Ошибка (0x5): Отказано в доступе

Ошибка 0x80338126

Ошибка 0x138C и 5004

Работа с другими журналами приложений и служб

Why is Windows Event Collector Needed?

Service Related Errors and Troubleshooting

Can Windows Event Collector be Disabled?

How to Fix Windows Event Collector?