Мы смотрели что можно подтюнить в модуле FIM Wazuh. Смотрели как менялся модуль, где создавали и использовали потенциал.
В старых модулях события забирались из файлов системных журналов. Это позволяло события не терять (они уже в журнал записаны в файл, файл никуда не девается, и информация не теряется). Но это создавало такую нагрузку на подсистему жесткого диска и подгружало CPU в пиках, что на ощутимых рабочих нагрузках снижало быстродействие приложений на хосте, вплоть до сбоев в работе таких приложений.
Тогда в новых версиях стали работать с системным журналом детектированных событий прямо в памяти процесса, который их пишет. Нагрузка на жесткий диск и CPU снизилась. Но получился казус асинхронной обработки таких событий самим модулем: пока считается хеш одного файла из очереди, остальные проходящие в очереди события просто игнорируются. Вот это мы и поймали у себя.
Наверное, если разработчики FIM как-то сильно распараллелят асинхронную обработку детектированных событий, потерь событий на постобработке станет меньше. Или если перейдут на собственное детектирование событий (не из системных журналов) ядерным модулем или из ebpf или fanotify, то что-то изменится.
Мы тестировали по постинцидентной истории, когда за короткий промежуток времени меняется конфиг (файл xml) приложения на хосте и рестартуется служба (приложение запускается в конфиге новой версии конфиг файла) и после этого конфиг файл меняется обратно на правильный.
В итоге приложение работает в других (заданных злоумышленником) настройках (и это не видно нигде, а в мониторинге видно только, что текущая версия конфиг-файла правильная.
Некоторые истории с созданием точек входа в систему тоже требовали видеть все события изменений без пропусков.
Ещё есть история с возможностью видеть реалтайм конфигурацию всех хостов “в конюшне” (когда машины в группе/департаменте в одной конфигурации) и видеть где есть отклонение после релиза - вообще мимо( Все машины отображаются после релиза как разные… Хотя отклонение от ожидаемой конфигурации после релиза было только на двух из 55 машин и то по одному и двум файлам
Мы повышали ОЗУ на сервере до 16ГБ и буфер (для мониторинга событий с одного клиента-хоста) и всё равно “через край стакана выливались события”. При 4ГБ событий приходило ещё меньше… Смотрели документацию: что можно сделать, чтобы увеличить процент “не потерянных” событий. Получали либо те же результаты теста, либо что-то, что не могли понять (контрольные суммы файлов после изменения не совпадали с реальными, и копии контента файлов не совпадали (съехали) c тем, к какому результату изменения относятся). И самое неприятное, это что агент теряет много событий ещё на этапе детектирования на хосте. Прото их игнорирует. Интересно узнать, какие результаты ещё получались при других конфигурациях сервера из продов, поделитесь пожалуйста...
Мы смотрели что можно подтюнить в модуле FIM Wazuh. Смотрели как менялся модуль, где создавали и использовали потенциал.
В старых модулях события забирались из файлов системных журналов. Это позволяло события не терять (они уже в журнал записаны в файл, файл никуда не девается, и информация не теряется). Но это создавало такую нагрузку на подсистему жесткого диска и подгружало CPU в пиках, что на ощутимых рабочих нагрузках снижало быстродействие приложений на хосте, вплоть до сбоев в работе таких приложений.
Тогда в новых версиях стали работать с системным журналом детектированных событий прямо в памяти процесса, который их пишет. Нагрузка на жесткий диск и CPU снизилась. Но получился казус асинхронной обработки таких событий самим модулем: пока считается хеш одного файла из очереди, остальные проходящие в очереди события просто игнорируются. Вот это мы и поймали у себя.
Наверное, если разработчики FIM как-то сильно распараллелят асинхронную обработку детектированных событий, потерь событий на постобработке станет меньше. Или если перейдут на собственное детектирование событий (не из системных журналов) ядерным модулем или из ebpf или fanotify, то что-то изменится.
Мы тестировали по постинцидентной истории, когда за короткий промежуток времени меняется конфиг (файл xml) приложения на хосте и рестартуется служба (приложение запускается в конфиге новой версии конфиг файла) и после этого конфиг файл меняется обратно на правильный.
В итоге приложение работает в других (заданных злоумышленником) настройках (и это не видно нигде, а в мониторинге видно только, что текущая версия конфиг-файла правильная.
Некоторые истории с созданием точек входа в систему тоже требовали видеть все события изменений без пропусков.
Ещё есть история с возможностью видеть реалтайм конфигурацию всех хостов “в конюшне” (когда машины в группе/департаменте в одной конфигурации) и видеть где есть отклонение после релиза - вообще мимо( Все машины отображаются после релиза как разные… Хотя отклонение от ожидаемой конфигурации после релиза было только на двух из 55 машин и то по одному и двум файлам
Мы повышали ОЗУ на сервере до 16ГБ и буфер (для мониторинга событий с одного клиента-хоста) и всё равно “через край стакана выливались события”. При 4ГБ событий приходило ещё меньше… Смотрели документацию: что можно сделать, чтобы увеличить процент “не потерянных” событий. Получали либо те же результаты теста, либо что-то, что не могли понять (контрольные суммы файлов после изменения не совпадали с реальными, и копии контента файлов не совпадали (съехали) c тем, к какому результату изменения относятся). И самое неприятное, это что агент теряет много событий ещё на этапе детектирования на хосте. Прото их игнорирует. Интересно узнать, какие результаты ещё получались при других конфигурациях сервера из продов, поделитесь пожалуйста...