Skip to main content

Обработка многострочных событий AuditD в KUMA

Введение

В данной статье будет рассмотрен процесс (workaround) обработки многострочных событий на примере событий AuditD.

1) БКаждая пачка событий, попавшая под агрегацию будет посчитана как 2 события (не 2 пачки). Так что в общем случае, когда в многострочном событии 2 и более событий увеличенноие числоа EPS не произойдет.
2) Метод не подразумевает высохранение исходуных событизй коллектора
2) Нет (Raw,Raw), при необходимости собирать сырые события нужно будет создать дополнительный коллектор, который будет за это отвечать
3) После склейки, все будет записамно в поле Extra/Message, из-за чего нужнстро будет переписать имеющиеся правила корреляции, либо добавить коллектор, который будет мапить склеенчное событие записывается в однао поляе KUMA
4) Данный метод(в примере далее это Extra и Message). Соответственно потребуется им тсполькзование кизмененных тенорм событалиям, козаторые можно агрегировать, подробнее по ссылке: https://kb.kuma-community.ru/books/sozdanie-parserov-v-kuma-cookbook/page/princip-raboty-pravila-agregacii-sxematicno.

Коробочный парсер в данном случае не подходит  

Принцип работы

Ниже представлена схема работы склейки многострочного события:

2.png


 

Рассмотрим этот алгоритм

1) На первом шаге в коллектор поступает событие, где происходит проверка, был ли отправлен syslog или json, в условиях экстранормализации, соответственно, выполняется проверка формата сообщения.

image.pngВ общем виде, проверка может быть любой. Основная идея - разделить на главном нормализаторе исходные события от источника от агрегированных событий.

image.pngimage.png

image.png

image.png2) В случае отправки syslog'а на этапе нормализации не будет происходит обогащения полями DeviceProduct и DeviceVendor, поэтому их можно будет добавить в условие для агрегации. Ниже приведен пример для агрегации событий AuditD:
   

Здесь также проверка может быть любой. Основная идея - под правило агрегации должно попадать только исходное событие. Попадание под правила агрегации должно быть исключено для событий, попавших в коллектор второй раз.

image.png

3)  На этапе маршрутизации есть две точки назначения: 1. Storage for AuditD - хранилище и loop - перенаправка событий обратно в коллектор (сам в себя). Во время этого этапа происходит проверка типа событий loop - для Type=2 (агрегированные события) и Storage for AuditD для Type=1 (базовые события). Обратите внимание, что при создании точки loop, нужно будет указать выходной формат json:

Основная идея - разграничение точек назначения по типу событий. Обратно на вход коллектора должны подаваться агрегированные события, а в хранилище должны записываться только повторно обработанные события.

image.png

image.png


4) После отработки loop, коллектор получает json, где уже происходит обогащение, а также вынос информации из Message в Extra. Это событие уже не будет считаться агрегированным из-за чего будет отправка в другую точку назначения.

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

image.png

СПолезные ссылки

1. Пример парсера (пароль для импорта ресурса q123123Q!): https://box.kaspersky.com/f/b44b00074feb4bf8b268/?dl=1 

2. Принцип работы правила агрегации (схематично): https://kb.kuma-community.ru/books/sozdanie-parserov-v-kuma-cookbook/page/princip-raboty-pravila-agregacii-sxematicno 

Back to top