Централизованый сбор Windows event логов, без установки агента, с последующей визуазизацией средствами ELK

[@ildarz]

Get-EventLog
…
происходит полное перекачивание файла с event-логами системы, и лишь затем осуществляется их обработка на компьютере, где выполняется скрипт.

Именно поэтому «родной» командой является Get-WinEvent, а не Get-EventLog. И правильно подобрать параметры.

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

[@zhylik]

Вы сами пользовались форвардингом большого количества событий (не выборочно, а прямо все события из Security лога) с большого количества раб. станций? Сколько событий/сек может нормально обрабатывать 1 сервер-коллектор?

[@ildarz]

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

[@zhylik]

А как сливаете — клиенты инициируют отправку или коллектор опрашивает клиентов и загружает логи? Работает ли это все дело, если клиент за НАТом (первый вариант сбора логов, разумеется)?

[@ildarz]

Стандартный режим, коллектор опрашивает. За NAT у нас клиентов нет, но в целом с точки зрения сети там требование одно — должна быть возможность подключиться через WinRM.

[@Hikedaya]

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

Detection of product '%1', feature '%2' failed during request for component '%3'

Вот именно в таком виде сообщения на хост для сбора логов и приходят, переменные не раскрываются. Скажите, насколько информативен такой подход?
Именно по этой причине в свое время обратил внимание на продукт Snare for Windows.

[@ildarz]

Если вы полностью опишете конкретную ситуацию, я, возможно, смогу как-то её прокомментировать. А так это из разряда «товарищи ученые, у нас в подполе раздаётся подземный стук».

[@Hikedaya]

Ради теста поднял небольшое окружение из трех серверов, DC, FS, WSUS. Сбор логов настроен на FS, логи собираются с сервера WSUS. Собираем все события из журналов Application, System. На WSUS перезапускаем службу DNS Client, чтобы получить событие, которое отправится на FS. В журнале Forwarded Events получаем следующее:

The description for Event ID 7036 from source Service Control Manager 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.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

DNS Client
stopped
44006E007300630061006300680065002F0031000000

В то время как в событии на WSUS указано всего лишь:

The DNS Client service entered the stopped state

Глядя на вот это конкретное событие, переданное на FS, еще можно догадаться, что дело в остановке службы DNS Client. Но сообщения бывают разные, далеко не такие тривиальные. И вот с более сложными уже могут возникнуть проблемы, пример был в комментарии выше.
С другой стороны, покопался немного на technet. В одном из комментариев было указано следующее, о чем во времена моего печального опыта работы с Windows Event Forwarding я не знал:
wecutil ss %subscription_name% /cf:events
После этого события на сервере коллекторе стали приниматься в должном виде.
Что ж, должен сказать вам спасибо :)

[@sdm]

Да, я в курсе, что у microsoft имеется свое решение…

[@ildarz]

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

[@sdm]

Собственно чуть ниже отписал, что winrm нигде не запущен, следовательно решение от microsoft не работает…

[@sdm]

В моем случае ни winrm, ни powershell на самих серверах не запущен…

[@usefree]

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

$systemlog = Get-EventLog $logjournal | Where-Object {((Get-date) - $_.TimeGenerated).TotalHours -le 1}

[@usefree]

Сорри, сказано же: " 7 раз отмерь, один отрежь." Таки нужны танцы с датой.
Я такие сделал.

# Выборка непустых журналов
        $LogJournals = Get-Winevent -ComputerName $Computer -listlog * | `
                                        Where-Object {($_.RecordCount -ge 1)}
# Выборка сообщений Warning и Error не старше часа
        foreach ($LogJournal in $LogJournals) {
                $CurrentLog = Get-Winevent -ComputerName $Computer -LogName $LogJournal.LogName | `
                Where-Object {(((Get-Date) - $_.TimeCreated).TotalHours -le 1) -and `
                        (($_.LevelDisplayName -eq 'Error') -or  ($_.LevelDisplayName -eq 'Warning'))}
        }

[@ildarz]

Перешли от Get-EventLog к Get-WinEvent — уже хорошо. :) Теперь для полноты счастья надо условия отбора из Where по возможности перенести в параметры запроса (-FilterXPath или -FilterHashTable) — сильно ускорит время обработки при хоть сколько-то значительных объемах логов.

И не используйте Get-Date в цикле — вы же на каждой итерации получаете новую дату, что не только неэффективно, но ещё и приведет к неожиданным для вас результатам в случае длительного выполнения команды. Сделайте, например, $date = (Get-Date).AddHours(-1) и дальше используйте переменную.

[@iltmpz]

Подскажите, а есть какие-нибудь готовые шаблоны для виндовых eventlog-ов?

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

Например, входы-выходы юзеров на терминалах и рабочих станциях, сгруппированные по полям логи exchange, логи домен-контроллеров и т.п.

Пока я взял дефолтовое правило из logstash для syslog и преобразовал к такому виду:
match => { «message» => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} (%{DATA:event_type}:(?: %{DATA:event_code}):?: %{DATA:event_result} %{GREEDYDATA:syslog_message}|%{GREEDYDATA:syslog_message})" }
В итоге оно вытаскивает время, имя хоста, тип события, и в большинстве случаев код события. А вот остальные поля парсятся корректно только для Security-Auditing.

В общем, чувствую, для корректного разбора виндовых логов надо потратить кучу времени на освоение сначала регекспов logstash, а потом на написание нескольких десятков (если не сотен) строк правил.
А велосипед изобретать не хочется — винда-то у всех есть, значит, под нее и шаблонов должно быть сколько угодно. Однако почему-то гугл более мощных шаблонов не выдает, или я плохо ищу?