Windows event forwarding что это



Настройка пересылки событий Windows

Применяется к: Advanced Threat Analytics версии 1.9

В версии ATA 1.8 и более поздних настройка сбора событий для упрощенных шлюзов ATA больше не требуется. Упрощенный шлюз ATA теперь может считывать события локально — настраивать переадресацию событий не требуется.

Чтобы улучшить возможности обнаружения, ATA требуется доступ к следующим событиям Windows: 4776, 4732, 4733, 4728, 4729, 4756, 4757, 7045. Они могут автоматически считываться упрощенным шлюзом ATA или, если упрощенный шлюз ATA не развернут, передаваться в шлюз ATA путем настройки прослушивания событий SIEM в шлюзе ATA или пересылки событий Windows.

При использовании основных серверных компонентов можно использовать wecutil для создания подписок на события, которые пересылаются с удаленных компьютеров, и управления этими подписками.

Настройка пересылки событий Windows для шлюза ATA с зеркалированием портов

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

Шаг 1. Добавление учетной записи сетевой службы в группу читателей журнала событий для домена

В этом сценарии предполагается, что шлюз ATA входит в домен.

  1. Откройте раздел «Пользователи и компьютеры Active Directory», перейдите в папку Builtin и дважды щелкните группу Читатели журнала событий.
  2. Выберите пункт Участники.
  3. Если в этом списке нет элемента Сетевая служба, нажмите кнопку Добавить и введите имя Сетевая служба в поле Введите имена выбираемых объектов. Щелкните Проверить имена и дважды нажмите ОК.

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

Шаг 2. Создание на контроллерах домена политики для изменения параметра «Настроить конечный диспетчер подписки»

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

Выполните следующую команду на каждом контроллере домена: winrm quickconfig.

В командной строке введите gpedit.msc.

Развертывание перенаправления событий компонентов Windows для административных шаблонов >> конфигурации > компьютера

Дважды щелкните Настроить конечный диспетчер подписки.

Выберите значение Включено.

В разделе Параметры щелкните Показать.

В разделе SubscriptionManagers введите следующее значение и нажмите кнопку ОК: Server=http:// :5985/wsman/SubscriptionManager/WEC,Refresh=10

(Например: Server= http://atagateway9.contoso.com:5985/wsman/SubscriptionManager/WEC,Refresh=10 )

Нажмите кнопку ОК.

В командной строке с повышенными привилегиями введите команду gpupdate /force.

Шаг 3. Выполнение действий на сервере шлюза ATA

Откройте командную строку с повышенными привилегиями и введите wecutil qc

Откройте средство просмотра событий.

Щелкните правой кнопкой мыши Подписки и выберите Создать подписки.

Введите имя и описание для подписки.

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

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

  1. Щелкните Добавить компьютер в домен.
  2. Введите имя контроллера домена в поле Введите имена выбираемых объектов. Щелкните Проверить имена и нажмите кнопку ОК.
  3. Нажмите кнопку ОК.

Щелкните Выбрать события.

  1. Щелкните По журналу и выберите Журнал безопасности.
  2. В поле Включить/исключить идентификаторы событий введите номер события и нажмите кнопку OK. Например, введите 4776, как в следующем примере.

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

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

Источник

Сборщик событий Windows

Вы можете подписаться на получение и хранение событий на локальном компьютере (сборщик событий), пересылаемых с удаленного компьютера (источник событий). Функции сборщика событий Windows поддерживают подписку на события с помощью протокола WS-Management. Дополнительные сведения о WS-Management см. в разделе «Сведения о Windows удаленном управлении».

Архитектура переадресации событий и коллекции событий

Сбор событий позволяет администраторам получать события с удаленных компьютеров и хранить их в локальном журнале событий на компьютере сборщика. Путь к целевому журналу для событий является свойством подписки. Все данные в переадресованном событии сохраняются в журнале событий компьютера сборщика (ни одна из данных не теряется). В событие также добавляются дополнительные сведения, связанные с пересылкой событий. Дополнительные сведения о том, как разрешить компьютеру получать собранные события или переадресовывать события, см. в разделе «Настройка компьютеров для пересылки и сбора событий».

Подписки

В следующем списке описаны типы подписок на события:

  • Подписки, инициированные источником: позволяет определить подписку на события на компьютере сборщика событий без определения исходных компьютеров событий. Затем можно настроить несколько удаленных исходных компьютеров событий (с помощью параметра групповой политики) для пересылки событий на компьютер сборщика событий. Дополнительные сведения см. в разделе «Настройка инициированной источником подписки». Этот тип подписки полезен, если вы не знаете или не хотите указывать все компьютеры источников событий, которые будут пересылать события.
  • Подписки, инициированные сборщиком: позволяет создать подписку на события, если вы знаете все исходные компьютеры событий, которые будут пересылать события. Все источники событий указываются во время создания подписки. Дополнительные сведения см. в разделе «Создание подписки, инициированной сборщиком».

Функции сборщика событий Windows

Дополнительные сведения и примеры кода, использующие функции сборщика событий, см. в разделе «Использование сборщика событий Windows».

Дополнительные сведения о функциях, используемых для сбора и пересылки событий, см. в разделе Windows Функции сборщика событий.

Источник

Настройка пересылки событий Windows

Датчик Microsoft Defender для удостоверений автоматически считывает события локально без необходимости настройки перенаправления событий.

Чтобы улучшить возможности обнаружения, Defender для удостоверений нуждается в событиях Windows, перечисленных в коллекции событий «Настройка». Их можно считывать автоматически датчиком Defender для удостоверений или в случае, если датчик Defender для удостоверений не развернут, его можно перенаправить в автономный датчик Defender для удостоверений одним из двух способов, настроив автономный датчик Defender для удостоверений для прослушивания событий SIEM или путем настройки пересылки событий Windows.

  • Автономные датчики Defender для удостоверений не поддерживают сбор записей журнала трассировки событий Windows (ETW), которые предоставляют данные для нескольких обнаружений. Для полного охвата среды рекомендуется развернуть датчик Defender для удостоверений.
  • Убедитесь, что контроллер домена правильно настроен для записи требуемых событий.

Конфигурация перенаправления событий Windows для автономного датчика Defender для удостоверений с зеркалированием портов

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

Шаг 1. Добавление учетной записи сетевой службы в группу читателей журнала событий для домена

В этом сценарии предполагается, что автономный датчик Defender для удостоверений является членом домена.

  1. Откройте раздел «Пользователи и компьютеры Active Directory», перейдите в папку Builtin и дважды щелкните группу Читатели журнала событий.
  2. Выберите пункт Участники.
  3. Если в этом списке нет элемента Сетевая служба, нажмите кнопку Добавить и введите имя Сетевая служба в поле Введите имена выбираемых объектов. Щелкните Проверить имена и дважды нажмите ОК.

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

Шаг 2. Создание на контроллерах домена политики для изменения параметра «Настроить конечный диспетчер подписки»

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

Выполните следующую команду на каждом контроллере домена: winrm quickconfig.

В командной строке введите gpedit.msc.

Развертывание административных шаблонов > конфигурации > компьютера Windows перенаправление > событий компонентов

Дважды щелкните Настроить конечный диспетчер подписки.

  1. Выберите значение Включено.
  2. В разделе Параметры щелкните Показать.
  3. В разделе SubscriptionManagers введите следующее значение и нажмите кнопку «ОК«: Server=http:// :5985/wsman/SubscriptionManager/WEC,Refresh=10 (например: Server=http://atpsensor9.contoso.com:5985/wsman/SubscriptionManager/WEC,Refresh=10 )

Нажмите кнопку ОК.

В командной строке с повышенными привилегиями введите команду gpupdate /force.

Шаг 3. Выполните следующие действия на автономном датчике Defender для удостоверений

Откройте командную строку с повышенными привилегиями и введите . wecutil qc Оставьте окно командной строки открытым.

Откройте средство просмотра событий.

Щелкните правой кнопкой мыши Подписки и выберите Создать подписки.

Введите имя и описание для подписки.

В параметре Журнал на конечном компьютере должно быть выбрано значение Пересланные события. Чтобы Defender для удостоверений считывал события, целевой журнал должен быть перенаправлен событиями.

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

  1. Щелкните Добавить компьютер в домен.
  2. Введите имя контроллера домена в поле Введите имена выбираемых объектов. Щелкните Проверить имена и нажмите кнопку ОК.
  3. Нажмите кнопку ОК.

Щелкните Выбрать события.

  1. Щелкните По журналу и выберите Журнал безопасности.
  2. В поле Включить/исключить идентификаторы событий введите номер события и нажмите кнопку OK. Например, введите 4776, как в следующем примере.

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как вы поняли, в папке, откуда вы выполните эту команду должно быть 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, для этого, от имени администратора выполним:

В оснастке службы должна будет появиться данная служба, с типом запуска 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. На парочке серверов были непонятки с 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:

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

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

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

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

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

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

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

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

Источник

You may also like...