Механизмы разбора

Данный раздел используется как справочный материал по работе в разделе Источники → Правила разбора.

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

GROK Паттерн;
CEF;
EXECVE;
Ключ-Значение;
CSV;
SYSLOG;
XML;
JSON;
Функция преобразования;
Не требуется.

GROK паттерн

GROK паттерны – это именованные регулярные выражения, которые позволяют пользователям сопоставлять конкретные шаблоны в тексте. С их помощью можно быстро идентифицировать и извлекать поля из поступающих событий без необходимости писать сложные регулярные выражения с нуля.

В Платформе Радар GROK паттерны делятся на системные и пользовательские. Подробнее см. раздел GROK паттерны. Описание.

GROK паттерн представляет собой шаблон. Синтаксис шаблонов GROK, при использовании следующий:

%{SYNTAX:SEMANTIC}

где

SYNTAX – имя паттерна, который будет применен;
SEMANTIC – имя объекта (поле, группа), к которому будет применен паттерн.

Пример настройки данного механизма приведен на рисунке 1.

Рисунок 1 – Добавление правила разбора. Механизм "GROK паттерн"

Для настройки механизма в поле Паттерн укажите GROK паттерн. Для использования пользовательских или системных GROK паттернов введите символ {, откроется список ключей поддерживаемых GROK паттернов. Сначала будут выведены пользовательские, а затем – системные.

Пример работы:

Сырое событие:

{"Message":"<7> 7/26/2023 2:39:42 PM pgr-1c-00 {\"Event\":{\"Level\":\"Information\",\"Date\":\"2023-07-26T14:39:42\",\"ApplicationName\":\"BackgroundJob\",\"ApplicationPresentation\":\"Background job\",\"Event\":\"_$Data$_.Update\",\"EventPresentation\":\"Data. Change\",\"User\":\"00000000-0000-0000-0000-000000000000\",\"UserName\":\"\",\"Computer\":\"\",\"Metadata\":\"Константа.ПоследнееОбновлениеДоступа\",\"MetadataPresentation\":\"Constant. Последнее обновление доступа\",\"Comment\":null,\"Data\":\"something Команда: Выполнить обновление\",\"DataPresentation\":\"\",\"TransactionStatus\":\"Committed\",\"TransactionID\":\"7/26/2023 2:39:42 PM (2934007)\",\"Connection\":\"3\",\"Session\":\"34\",\"ServerName\":\"\",\"Port\":\"\",\"SyncPort\":\"0\"}}","a":"a7e42e20-03a1-4998-a301-c97fa77cbe73","a_c":"","a_src_ip":"172.30.250.141","a_src_o":"445","a_src_r":"smb","a_src_t":[],"a_ts":"2024-10-21T12:41:44.993Z"}

Поле сырого события, к которому будет применен GROK паттерн:

\"Event\":\"_$Data$_.Update\"

Применяемый GROK паттерн:

^_\$%{WORD:job_type}\$_.%{WORD:job_status}

Результат работы приведен на рисунке 2.

Рисунок 2 – Пример работы механизма "GROK паттерн"

CEF

Общий формат событий (Common Event Format (CEF )) – это расширяемый текстовый формат, предназначенный для поддержки нескольких типов устройств, предлагая наиболее актуальную информацию.

Синтаксис сообщений сокращен для работы с нормализацией ESM. CEF специально определяет синтаксис для записей журнала, содержащих стандартный заголовок и расширение переменной, отформатированные как пары "Ключ-Значение". Формат CEF может использоваться с локальными устройствами и с поставщиками облачных услуг.

При использовании данного механизма при создании правил разбора дополнительных настроек не требуется.

EXECVE

Данный механизм будет разбирать тип событий EXECVE от auditd для Unix систем.

Пример настройки данного механизма приведен на рисунке 3.

Рисунок 3 – Добавление правила разбора. Механизм "EXECVE"

Пример события в формате EXECVE имеет следующий вид:

{"b_ts":"2025-10-14T11:18:26.000+03:00","a_m":"2671","Message":"<190>Oct 14 11:18:26 deb12-auditd audit: node=172.30.250.165 type=EXECVE msg=audit(1760435954.705:104635): argc=2 a0="/usr/bin/printf" a1=D0A2D0B5D181D182D0BED0B2D0B0D18F5FD181D182D180D0BED0BAD0B05C6E","a":"c2795d7b-1415-47bc-be88-4bf922a0b362","a_c":"","a_src_ip":"172.30.250.165","a_src_o":"37983","a_src_r":"udp_input","a_src_t":[],"a_ts":"2025-10-14T08:18:26.211Z"}

Для описания примера работы механизма разбора возьмем часть:

a0="/usr/bin/printf" a1=D0A2D0B5D181D182D0BED0B2D0B0D18F5FD181D182D180D0BED0BAD0B05C6E"

Механизм разбора выполнит следующие действия:

Извлечет все параметры a0, a1, a2 и т.д.

Применит механизм Hex to text к каждому полю, которое не имеет кавычек в значении:

a0="/usr/bin/printf"
a1=D0A2D0B5D181D182D0BED0B2D0B0D18F5FD181D182D180D0BED0BAD0B05C6E" --> Hex to text: Тестовая_строка\n

Последовательно склеит через пробел все полученные поля и выведет в таксономию. Итоговый результат преобразования:

node=<ip-адрес узла платформы> type=EXECVE msg=audit(a0="/usr/bin/printf" a1=D0A2D0B5D181D182D0BED0B2D0B0D18F5FD181D182D180D0BED0BAD0B05C6E"): a0="/usr/bin/printf" a1="Тестовая_строка\n"

Ключ значение

Данный механизм будет разбирать пришедшее поле на пары "Ключ-Значение" в соответствии с заданными параметрами.

Пример настройки данного механизма приведен на рисунке 4.

Рисунок 4 – Добавление правила разбора. Механизм "Ключ-Значение"

Для настройки механизма разбора "Ключ-Значение" указывается следующая информация:

Разделитель пары "Ключ-Значение" – укажите символ, который будет являться разделителем пары "Ключ-Значение". Например:
```
Приходящая пара "Ключ-Значение":
"a":"1"

Разделитель пары "="

Результат:
a=1
```
Разделитель строк – укажите символ, который будет являться разделителем строк. Например:
```
Приходящие пары Ключ-Значение:
"a":"1" "b":"2"

Разделитель строк ","

Результат:
a=1,b=2
```
Примечание: если оставить поле пустым, то в качестве разделителя строк будет использоваться "перенос строки".
Экранирование значений – задается последовательный набор символов, которые будут стоять перед каждым значением в паре и после него;

Поля значений. Задается последовательный список, по которому будут переопределяться "ключи" из пары "Ключ-Значение". Например:

Приходящие пары Ключ-Значение:
"a":"1" "b":"2"

Поля значений:
value_1
value_2
value_3

Результат:
value_1=1
value_2=2
value_3 - поле применено не будет, так как пришло всего две пары "Ключ-Значение"

Пример работы механизма разбора приведен на рисунке 5.

Рисунок 5 – Пример работы механизма разбора "Ключ-Значение"

CSV

Механизм используется в случае, если в поле сырого события вложены данные в формате CSV.

Механизм работает и настраивается аналогично механизму Ключ-Значение.

SYSLOG

Если источником событий является ОС семейства Unix, то с наибольшей вероятностью события будут журналироваться одной из следующих служб:

rsyslog;
syslog-ng;
auditd.

Если используются данные механизмы журналирования, то для разбора событий рекомендуется использовать механизм SYSLOG.

Для создания правила разбора, с использованием данного механизма, дополнительных настроек не требуется.

Пример сырого события от ОС Linux:

{"a_src_ip":"172.30.249.201","a_src_o":"2671","a_c":"","a_src_t":[""],"a_src_r":"","a_ts":"2024-09-25T10:09:51.088.088144459+00:00","a":"a1a1795a-6a18-4345-9020-77723a724d38","Message":"<22>Sep 18 16:55:01 v-stand-05 audispd: node=172.30.254.95 type=EXECVE msg=audit(1663937111.702:73702361): argc=5 a0=\"ps\" a1=\"-o\" a2=\"rss=\" a3=\"-p\" a4=\"1736\""}

Пример успешного применения механизма разбора, примененного к полю Message сырого события, приведено на рисунке 6.

Рисунок 6 – Пример работы механизма разбора "SYSLOG"

XML

Механизм используется в случае, если в поле сырого события вложено XML-выражение.

При использовании данного механизма при создании правил разбора дополнительных настроек не требуется.

Особенностью данного механизма является то, что XML может быть вложенный, то есть в ключ может быть вложен ключ, в который также вложен ключ.

Результатом применения данного механизма будет ключ следующего вида:

"Ключ первого уровня"__"Ключ второго уровня"__"Ключ n-уровня"="Значение"

Пример события со вложенными ключами:

{"a_src_ip":"172.30.249.201","a_src_o":"1217","a_c":"","a_src_t":[""],"a_src_r":"","a_ts":"2024-09-13T14:09:12.731.731790640+00:00","a":"fdf1c240-ecfe-4d76-9ac9-0d2c315b744c","Message":"{\"AccountDomain\":\"IMG-WIN2019\",\"AccountName\":\"Administrator\",\"Bookmark\":\"\",\"Channel\":\"Security\",\"ChannelText\":\"Security\",\"ClientAddress\":\"172.30.253.104\",\"ClientName\":\"DESKTOP-FJ5FBMT\",\"EventData\":\"\",\"EventDataErr\":null,\"EventID\":4778,\"EventTime\":\"2024-08-14T10:07:28.86689Z\",\"EventType\":\"AUDIT_SUCCESS\",\"ExecutionProcessID\":620,\"Hostname\":\"img-win2019\",\"IDText\":\"\",\"Keywords\":null,\"KeywordsRaw\":\"0x8020000000000000\",\"Level\":0,\"LevelText\":\"Information\",\"LogonID\":\"0x000000000004b543\",\"Msg\":\"\",\"OpcodeText\":\"Info\",\"OpcodeValue\":0,\"ProviderText\":\"\",\"PublisherHandleErr\":null,\"Qualifiers\":0,\"RecordID\":17728,\"RenderedFieldsErr\":null,\"SessionName\":\"RDP-Tcp#1\",\"SourceName\":\"Microsoft-Windows-Security-Auditing\",\"SubscribedChannel\":\"Security\",\"TaskText\":\"\",\"TaskValue\":12551,\"ThreadID\":680,\"User\":\"\",\"UserData\":\"\",\"Version\":0,\"XML\":\"\\u003cEvent xmlns=\\\"http:\/\/schemas.microsoft.com\/win\/2004\/08\/events\/event\\\"\\u003e\\u003cSystem\\u003e\\u003cProvider Name=\\\"Microsoft-Windows-Security-Auditing\\\" Guid=\\\"54849625-5478-4994-a5ba-3e3b0328c30d\\\"\/\\u003e\\u003cEventID\\u003e4778\\u003c\/EventID\\u003e\\u003cVersion\\u003e0\\u003c\/Version\\u003e\\u003cLevel\\u003e0\\u003c\/Level\\u003e\\u003cTask\\u003e12551\\u003c\/Task\\u003e\\u003cOpcode\\u003e0\\u003c\/Opcode\\u003e\\u003cKeywords\\u003e0x8020000000000000\\u003c\/Keywords\\u003e\\u003cTimeCreated SystemTime=\\\"2024-08-14T10:07:28.866890+00:00\\\"\/\\u003e\\u003cEventRecordID\\u003e17728\\u003c\/EventRecordID\\u003e\\u003cCorrelation ActivityID=\\\"ee7f716d-ee30-0003-9971-7fee30eeda01\\\"\/\\u003e\\u003cExecution ProcessID=\\\"620\\\" ThreadID=\\\"680\\\"\/\\u003e\\u003cChannel\\u003eSecurity\\u003c\/Channel\\u003e\\u003cComputer\\u003eimg-win2019\\u003c\/Computer\\u003e\\u003cSecurity\/\\u003e\\u003c\/System\\u003e\\u003cEventData\\u003e\\u003cData Name=\\\"AccountName\\\"\\u003eAdministrator\\u003c\/Data\\u003e\\u003cData Name=\\\"AccountDomain\\\"\\u003eIMG-WIN2019\\u003c\/Data\\u003e\\u003cData Name=\\\"LogonID\\\"\\u003e0x000000000004b543\\u003c\/Data\\u003e\\u003cData Name=\\\"SessionName\\\"\\u003eRDP-Tcp#1\\u003c\/Data\\u003e\\u003cData Name=\\\"ClientName\\\"\\u003eDESKTOP-FJ5FBMT\\u003c\/Data\\u003e\\u003cData Name=\\\"ClientAddress\\\"\\u003e172.30.253.104\\u003c\/Data\\u003e\\u003c\/EventData\\u003e\\u003c\/Event\\u003e\",\"XMLErr\":null}"}

Пример успешного применения механизма разбора, примененного к полю XML, приведено на рисунке 7.

Рисунок 7 – Пример работы механизма разбора "XML"

JSON

В основном, все источники посылают события в формате RAW-JSON. При разборе событий в этом формате необходимо в качестве первого этапа использовать механизм JSON, а потом любые из доступных в платформе, в зависимости от типа данных в исходном событии.

Обычно все сырые события помещаются в поле Message.

Примечание: для просмотра наименования поля, в которое приходит сырое событие, запустите механизм тестирования и в результатах просмотра перейдите на вкладку "Сырое событие". Найдите пару "Ключ-Значение", в которой значением будет являться сырое событие.

Пример настройки данного механизма приведен на рисунке 8.

Рисунок 8 – Добавление правила разбора. Механизм разбора "JSON"

Для настройки механизма разбора укажите следующие значения:

в поле Поле события укажите поле, в которое пришло сырое событие;
в поле Механизм разбора выберите значение "json".

Функция преобразования

Поддерживается функция преобразования HEX to Text которая при разборе события преобразует числовое представление последовательности номеров и символов в текстовое.

Пример настройки данного механизма приведен на рисунке 9.

Рисунок 9 – Добавление правила разбора. Механизм разбора "Функция преобразования"

Пример сырого события с HEX представлением:

{"a_src_ip":"172.30.249.201","a_src_o":"2671","a_c":"","a_src_t":[""],"a_src_r":"","a_ts":"2024-12-04T12:12:06.382.382328581+00:00","a":"8b3beadb-c7bc-48f2-9bf1-d2012ed9d17e","Message":"Dec  4 12:50:40 v-stand-05 audispd: node=172.30.254.95 type=PROCTITLE msg=audit(1733305840.550:51886): proctitle=757365726D6F64002D61002D470076696C61696E73007261766573"}

Где:

ключ поля – proctitle;
значение поля – 757365726D6F64002D61002D470076696C61696E73007261766573.

Пример успешного применения правила разбора приведен на рисунке 10.

Рисунок 10 – Пример успешного выполнения механизма разбора "Функция преобразования"

Не требуется

В случае, если нет необходимости использовать специфические парсеры для какого-либо поля, то можно использовать имеющиеся значение поля "как есть". Для этого необходимо выбрать значение Не требуется при выборе механизма разбора (см. рисунок 11).

Рисунок 11 – Добавление правила разбора. Механизм разбора "Не требуется"

← Назад