SELECT Name FROM Win32_OperatingSystem можно как-то исключить из профиля WMI Notification? а то он пытается это сделать на пространстве, где Win32_OperationgSystem не задан и ломается

Доброго вечера! Не работал эластик какое-то время, накопились очереди на ядре и storage. Разбор очередей очень медленно идёт, нагрузка при этом небольшая. Как я понимаю нужно настройки watchdog менять. Как?

18.1

Всем привет. Кто-нибудь имел успешный опыт настройки "не админских" прав доступа учеткам, для заданий аудита ESXi (ssh) и Windows (WMI/RPC)?

Лучше обратиться в саппорт. Сколько пачек в очереди storage скапливается? Индексы в эластике проверяли? Может эластик перегружен, вот и работает еле еле

Я ничего не понял. Специально просмотрел все 4 стандартных профиля этого крайне специфического модуля и не увидел этой конструкции.
Из операционки мы тащим занятую память, но там не такой запрос.

В целом же, я бы вообще сильно подумал о том, надо ли так делать. Мне кажется, через WMI подписку в eventlog работать проще и надёжнее

есть одна проблема - подписаться на ds_users просто так не получится. селект в запросе wmi, как следствие, совершенно другой

Саппорт ответил, что параметры выставлены с экспертной точки зрения и их редактирование клиентами не предполагается

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

Господа, доброе утро. забыл, если я обновляю core + kb мой контент останется или уйдет в закат?

останется

шпасибо

Доброе утро. Подскажите, где в документации можно почитать примеры перенастройки SIEM-server и Elasticsearch на новую адресацию? Меняется полностью подсеть у всех модулей - с агентом и ядром понятно, а вот с сиемом и эластиком возникли вопросы.

С точки зрения  KB - если отключали или правили дефолные правила из pt_content позитива (не делая при этом свою ветку установочной базы и/или группы с объектами),  то при апдейте базы обновится pt_content и правила вновь появятся.

О как, все коробочные по новой отключать

Нет, если они отключены в твоей кастомной ветке

Вроде

По логике вендора нужно:
- делать свою ветку (копию системной базы)
- делать свою базу установочной
- разивать объекты на 2 группы (которые устанавливаешь в SIEM сервер, которые не ставишь в SIEM сервер)
- при обновлении базы - все правила, формулы и списки падают в дефолтную системную базу pt_content (то есть в таблицы базы, у каждой записи наверняка есть поле ревизии, так как в пределах базы можно сравнивать ревизии и можно просматривать статистику - что добавилось, что удалилось, какие позиции изменились)
- далее правила из pt_content попадают в вашу версию базы (ветку), а там есть группа с установленными правилами и заблокированными
- таким образом, если вы не делаете свою ветку базы, а работаете в системной (не создав по крайней мере группы)  - удаляете, правите и т.д. то при очередном обновлении обновятся все правила из системной pt_content и если вы применете новую ревизию, то правила появятся вновь.
Как-то так я это себе представляю....