Comments 10
алерт, что на сервере не работает служба, почему не работает служба, потому что она остановилась (штатно?) когда? строчка с командой остановки, parent process id, owner
почему остановилась?
показать события, которые были рядом с событием остановки (фильтр по хосту, время -1 минута от события Ч), ага, там авторизовался наш 1с-ник Вася, и решил что-то перезапустить, а то что зависимая служба сама не поднимется, он не знает.
ну как-то так.
Первую часть алерта обычно решает заббикс, вторую часть поиска logbeats+elasticsearch+kibana
Судя по скриншотам для выборки событий используется скрипт на LUA.
Довольно необычный подход (если ты конечно не разработчик игр или embedded систем ;))
Если посмотреть конкурентов то это SQL подобные DSL (SPL у splunk, PDQL у позитива, Lucene/KQL у ELK SIEM).
Вроде так сложнее выстрелить себе в ногу и это понятнее аналитикам ИБ?
Чем вызван такой непривычный выбор?
Ничего личного не имею против Lua, но в 2020 году вообще мало осталось аргументов в пользу него )
Lua в Suricata и в Zeek используют для кастом логики в детектировании, сами сигнатуры в IDS пишутся декларативными языками.
Для выборки из списка событий в той же Suricata предлагают использовать JSONquery Так что аналогия не вполне уместна)
На мой взгляд, требовать от какого-нибудь аналитика 1-ой линии в SOC знание Lua, чтобы он мог отфильтровать и отсортировать события например за неделю, как-то чересчур. Но, как говорится, на вкус и цвет. )
Насчёт быстродействия — да (LuaJIT один из лидеров впрочем как и PyPy), но это если сравнивать именно с другими скриптовыми языками. Разумеется SQL-like запросы компилируются, а их выдача — кэшируется. Так что сомневаюсь что Lua тут выиграет и по перформансу, но тут ответ зависит конечно от того как вы с Postgre работаете.
А правила корреляции событий в SIEM тоже на Lua?
Имеется возможность использования переменных, ожидания данных по определенному фильтру, задавать временные окна, проверять на отсутствие данные по фильтру и т.п. По написанию правил корреляции мы подготовим отдельную статью.
В ходе нагрузочного тестирования на сервере чуть выше начального уровня с процессором Хeon E5-2650 v2 2.60GHz (10 ядер) и 32 Гб ОЗУ была получена скорость обработки событий порядка 5500 EPS (запись событий и индексов).
Подождите-подождите, но ведь ещё в предыдущих версиях вашего продукта, Комрад 2 и Комрад 3 (судя по Tadviser ещё 2016 году) вы доблестно отрапортовали не о 5500 EPS, а в 2 раза больше, о целых 10 000 EPS на абсолютно такой же (сюрприз-сюрприз!) серверной конфигурации:
Текст Комрад 2 у tadviser:
производительность: до 20 000 EPS. 10 000 EPS на серверной платформе со следующими характеристиками: 2 CPU Intel Xeon E5 2650, ОЗУ: 32 Гб, HDD: 2 Тб.
Те же 10 000 EPS указаны в магазине Softline, где продают Комрад 3:
производительность: до 20 000 EPS. 10 000 EPS на серверной платформе со следующими характеристиками: 2 CPU Intel Xeon E5 2650, ОЗУ: 32 Гб, HDD: 2 Тб.;
Какие должны напрашиваться выводы у читателя?
У вас последние 5 лет используется один и тот же сервер для тестирования?
Продукт стал глючнее и тормознее в последней версии? EPS разворовываются и уводятся в офшоры? ))
Не знаю, буду рада услышать вашу точку зрения))
«КОМРАД 4.0»: кросс-платформенная отечественная SIEM-система с дружественным интерфейсом и высокой производительностью