Comments 6
Добрый день. Вы тестировали Wazuh с настройками из коробки - как есть? Или что-то крутили?
У него довольно много настроек (https://documentation.wazuh.com/current/user-manual/reference/internal-options.html). В том числе можно увеличить буфер агента или вообще отключить буферизацию - тогда агент будет передавать на менеджер данные с максимально возможной скоростью.
Мы повышали ОЗУ на сервере до 16ГБ и буфер (для мониторинга событий с одного клиента-хоста) и всё равно “через край стакана выливались события”. При 4ГБ событий приходило ещё меньше… Смотрели документацию: что можно сделать, чтобы увеличить процент “не потерянных” событий. Получали либо те же результаты теста, либо что-то, что не могли понять (контрольные суммы файлов после изменения не совпадали с реальными, и копии контента файлов не совпадали (съехали) c тем, к какому результату изменения относятся). И самое неприятное, это что агент теряет много событий ещё на этапе детектирования на хосте. Прото их игнорирует. Интересно узнать, какие результаты ещё получались при других конфигурациях сервера из продов, поделитесь пожалуйста...
Конкретно ваш случай не похож на наш.Могу сказать только, что значительно увеличив буферы на менеджере и отключив на агенте (установленном на WEF-сервере) использование буферизации вовсе, обрабатываем на менеджере свыше тысячи EPS без потерь. Однако у нас довольно мощная конфигурация - и RAM много и CPU.
Конкретно в модуль FIM глубоко не погружались, но подозреваю, что его тоже можно подтюнить.
Мы смотрели что можно подтюнить в модуле FIM Wazuh. Смотрели как менялся модуль, где создавали и использовали потенциал.
В старых модулях события забирались из файлов системных журналов. Это позволяло события не терять (они уже в журнал записаны в файл, файл никуда не девается, и информация не теряется). Но это создавало такую нагрузку на подсистему жесткого диска и подгружало CPU в пиках, что на ощутимых рабочих нагрузках снижало быстродействие приложений на хосте, вплоть до сбоев в работе таких приложений.
Тогда в новых версиях стали работать с системным журналом детектированных событий прямо в памяти процесса, который их пишет. Нагрузка на жесткий диск и CPU снизилась. Но получился казус асинхронной обработки таких событий самим модулем: пока считается хеш одного файла из очереди, остальные проходящие в очереди события просто игнорируются. Вот это мы и поймали у себя.
Наверное, если разработчики FIM как-то сильно распараллелят асинхронную обработку детектированных событий, потерь событий на постобработке станет меньше. Или если перейдут на собственное детектирование событий (не из системных журналов) ядерным модулем или из ebpf или fanotify, то что-то изменится.
Добрый день, честно говоря очень странный кейс вы решаете, даже используя средства автоматизации, тест "добавление 10 000 строк" в конфигурационный файл - выглядит мягко говоря нереальным. Для реагирования вам достаточно факта внесения изменений. Какой смысл в хранении и генерации созданного шума в тесте?
Мы тестировали по постинцидентной истории, когда за короткий промежуток времени меняется конфиг (файл xml) приложения на хосте и рестартуется служба (приложение запускается в конфиге новой версии конфиг файла) и после этого конфиг файл меняется обратно на правильный.
В итоге приложение работает в других (заданных злоумышленником) настройках (и это не видно нигде, а в мониторинге видно только, что текущая версия конфиг-файла правильная.
Некоторые истории с созданием точек входа в систему тоже требовали видеть все события изменений без пропусков.
Ещё есть история с возможностью видеть реалтайм конфигурацию всех хостов “в конюшне” (когда машины в группе/департаменте в одной конфигурации) и видеть где есть отклонение после релиза - вообще мимо( Все машины отображаются после релиза как разные… Хотя отклонение от ожидаемой конфигурации после релиза было только на двух из 55 машин и то по одному и двум файлам
Wazuh: тестирование обработки большого количества событий изменения файлов