Журнал регистрации 1С для SIEM: на «Нано-УТ» найдены 23 из 23 действий с ролями

Службе безопасности нужно узнавать о выдаче административной роли в 1С в тот же день. Выгрузка прав в Excel раз в месяц такого не даёт. Платформа пишет такие действия в журнал регистрации, но SIEM его не читает: у журнала собственный формат, роли в нём записаны идентификаторами, а прежнего состава пользователя в записи нет. Я написала скрипт rights_watch.py, который читает журнал и выдаёт события в JSON Lines и CEF, и проверила его на «Нано-УТ 2.0» двумя заходами опыта: создала и удалила пользователей через COM, выдавала и снимала роли, вводила неверные пароли.

Стенд и порядок работы

Стенд собирает make_stand.py из архива компаньона: одна команда с путём к репозиторию и коммитом. Базу и журнал каждого захода я оставляю как есть и не очищаю между заходами: во втором заходе рядом с новыми событиями лежат записи первого, и это нужно для проверки инкрементального режима.

Что пишет журнал о пользователях

Журнал старого формата состоит из словаря 1Cv8.lgf и файлов записей *.lgp (файлы по периодам, имя начинается с даты начала периода). В словаре лежат коды пользователей, компьютеров, приложений и событий, в записи стоят только коды и данные. Запись события — это фигурные скобки с полями через запятую: время, статус транзакции, номер транзакции, пользователь, компьютер, приложение, соединение, событие, важность, комментарий, метаданные, данные, представление данных, сервер, порты, сеанс.

Запись пользователя в моём опыте выглядит так (пробелы и переводы строк убраны):

1

{"P",{65534,{"B",0},{"B",1},{"B",0},{"S","ivanov_iiR"},{"O",{"#",fc01b5df-97fe-449b-83d4-218a090e681e,00000000-0000-0000-0000-000000000000}},{"B",0},{"B",1},{"B",1},{"S",""},{"S",""},{"S","Авто"},{"A",{3,{"O",{"#",fc01b5df-97fe-449b-83d4-218a090e681e,e2ac1ac5-e2e7-54b3-a575-2a8f767c2248}},{"O",{"#",fc01b5df-97fe-449b-83d4-218a090e681e,1b8bedb0-e69c-590a-8022-6f1fe3842d59}},{"O",{"#",fc01b5df-97fe-449b-83d4-218a090e681e,a65ef7fa-89c0-53d8-ad6f-f29724284295}}}},{"B",0},{"B",1},{"A",{0}},{"S","НеИспользовать"},{"B",1},{"S",""},{"B",0},{"B",0},{"A",{0}},{"S",""},{"D",20261025203635},{"S","SHA1"},{"B",0},{"B",0},{"B",0}}}

Это запись _$User$_.Update в 21:36:37 (шаг E4, выдана третья роль). Что в ней видно:

• Роли идут массивом {"A",{3,...}}: число ролей и ссылки на объекты метаданных вида «тип роли, GUID роли». Названий ролей нет: a65ef7fa-... — это Администратор, 1b8bedb0-... — Оператор, e2ac1ac5-... — Чтение. GUID совпадают с атрибутом uuid в файлах Roles/*.xml выгрузки конфигурации.
• В записи полное состояние пользователя после действия, 28 полей. Что было до действия, записать нечем: чтобы получить «выдана роль», нужно сравнить с предыдущей записью того же пользователя.
• Пароля и его хеша в записи нет. Есть дата установки пароля {"D",20261025203635} (по UTC, у записи журнала время локальное, разница в опыте 1 час) и строка SHA1.
• Удаление хранит только имя: {"P", { {"S","ivanov_iiR"} } } (внутренний список из одного поля с именем). Роли удалённого пользователя и их количество в записи не лежат.
• У неуспешного входа в поле «пользователь» стоит код 0, а логин, который вводили, лежит в данных: {"P",{518,{"S","ivanov_iiR"},{"S","TOP-DESKTOP\nasch"},{"N",1}}}. Скрипт берёт логин и имя пользователя ОС оттуда.
• Вокруг New и Update платформа пишет _$Transaction$_.Begin и Commit, вокруг Delete в моих записях транзакционных событий нет.

Положение полей я определила третьим заходом опыта: сценарий probe_user_fields.ps1 менял у пользователя по одному свойству, а diff_user_records.py печатал, какие позиции записи изменились. Результат из журнала probe-diff.txt:

Свойство ПоказыватьВСпискеВыбора в записи не изменило ни одной позиции: запись пользователя его не содержит, и в события оно не попадает. Остальные позиции в моих записях не менялись ни одним из девяти действий; скрипт их не читает.

Что делает rights_watch

Скрипт открывает журнал на чтение: каталог 1Cv8Log, каталог базы или каталог журнала. Выбор событий задан группами (--events): пользователи (_$User$_.New, .Update, .Delete и ошибки .NewError, .UpdateError, .DeleteError), аутентификация (_$Session$_.Authentication и AuthenticationError), начало и конец сеансов, доступ и отказ в доступе, обновление конфигурации; группа all отдаёт всё подряд. Для пользователей скрипт считает разность ролей и признак смены пароля, а для выдачи роли из списка --admin-role ставит admin_role_added.

Первый запуск на журнале стенда после первого захода (для снимков файлы журнала скопированы в каталог ibR рядом со скриптом):

1

python rights_watch.py ibR --state pos.json --jsonl events.jsonl --cef events.cef --brief --roles-dir Roles

Рисунок 1. Первый проход: 24 события первого захода опыта. Строки с + показывают выданные роли, с - снятые, у ivanov_iiR видны выдача и снятие роли администратора через 12 секунд.

В журнале на этот момент 24 записи выбранных групп из первого захода: 10 событий пользователей (три создания, четыре изменения, три удаления), 5 входов (четыре успешных и одна ошибка), 8 событий начала и конца сеансов и одно событие «Вход с отключенной проверкой прав» из DESIGNER. Транзакционные записи и обновление конфигурации в вывод не входят: это группы, которые не выбраны.

События записываются в два файла. В JSON Lines одно событие занимает одну строку с полями ts, kind, actor, target, roles_added, roles_removed, roles_after, password_changed, admin_role_added, id. В CEF те же данные в виде act, suser, duser, cs1-cs6; полный разбор полей лежит в README инструмента и в siem-rules.md компаньона. Полный набор из шести событий опыта в обоих видах приведён в event-examples.md; вот выдача роли администратора в CEF:

1

CEF:0|rights_watch|1C event log|1.0|user.update|Изменён пользователь ИБ|9|rt=1792960597000 act=user.update suser=admin_nanoR shost=Top-desktop sproc=COMConnection cn1=2 cn1Label=session cn2=2 cn2Label=connection cs6=838757faca8d0317 cs6Label=eventId duser=ivanov_iiR outcome=Success cs1=Администратор cs1Label=rolesAdded cs3=Администратор,Оператор,Чтение cs3Label=rolesAfter cs5=true cs5Label=adminRoleAdded

Опыт: двадцать три действия и двадцать три найденных события

Первый заход, run_rights_experiment.ps1, выполняется через COM из 32-битного PowerShell. Администратор создаётся в базе без пользователей, дальше все действия идут под ним.

Шаги записывает сам сценарий: id, действие, пользователь, ожидаемое событие и окно времени. Скрипт check_experiment.py сопоставляет каждый шаг с событием: должны совпасть имя события, цель (пользователь или логин) и время в окне шага плюс две секунды, а для шагов с ролями ещё и выданное со снятым. На шагах E3, E4, E7 и E8 события расположены в соседних секундах, поэтому каждое событие может достаться только одному шагу.

Второй заход, run_second_wave.ps1, проверяет сценарии для правил: администратор soc_adminR создаёт sidorov_vvR с ролью Оператор (W2), выдаёт ему Администратор (W3) и через 4 секунды снимает (W4); затем три неверных пароля подряд (W5.1-W5.3), успешный вход (W6), смена пароля администратором (W7) и удаление обоих (W8, W9). Сверка по всем 23 действиям двух заходов дала 23 найденных:

1

шагов 23, найдено 23

Состав вывода по группам: 17 событий пользователей (5 создания, 7 изменения, 5 удаления), 11 входов (7 успешных, 4 неуспешных), 14 событий начала и конца сеансов и одно событие доступа; всего 43 события из 76 записей журнала. Остальные 33 записи это транзакции (12 Begin и 12 Commit) и служебные события DESIGNER при загрузке конфигурации.

Повторный запуск выдаёт только новое

В файле позиции, который скрипт пишет после прохода, лежат смещение в байтах после последней целой записи каждого .lgp, формат журнала и последний известный состав ролей каждого пользователя. Повторный запуск сразу после первого вернул ноль событий, а файл JSON Lines остался с теми же 24 строками.

Рисунок 2. Второй проход подряд: 0 событий. Файл позиции хранит смещение 13183 байта и пустой список пользователей (все удалены).

После второго захода опыта я заменила файлы в каталоге ibR журналом стенда целиком, и тот же запуск вернул только новые записи:

Рисунок 3. Третий проход: 19 новых событий второго захода. Видны выдача и снятие роли у sidorov_vvR через 5 секунд, три неуспешных входа и успешный вход.

Три свойства режима проверены тестами. Запись, которую платформа дописывает в момент чтения, не засчитывается: тест обрывает файл на 40 байт раньше конца записи, проход не выдаёт её, после дописывания следующий проход выдаёт её один раз. Усечённый или заменённый файл читается заново, потому что смещение больше его размера. Состав ролей хранится в файле позиции: если оборвать журнал после создания пользователя и прочитать остаток при следующем запуске, выдача роли Оператор у него определяется по состоянию из прошлого запуска. Без такого состояния у существующего пользователя поля roles_added и roles_removed равны null, а в roles_note записана причина.

Правила корреляции на событиях опыта

Правила описаны в siem-rules.md компаньона и реализованы в correlate.py. На 43 событиях опыта они дали 16 предупреждений:

Рисунок 4. correlate.py на 43 событиях опыта: 16 предупреждений; check_experiment.py: 23 действия из 23.

Каждое правило сопровождено ключами порогов. Окно R1 в 6 секунд оставляет два предупреждения (petrov_ppR и sidorov_vvR), порог R2 в четыре неуспешных входа убирает его совсем: тесты test_r1_window_shorter и test_r2_needs_three. Для правила вне рабочего времени (R6) задаётся интервал --work-hours; на опыте, который шёл вечером, оно даёт предупреждение на каждое из 17 событий пользователей.

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

Формат журнала на платформе 8.3.27

Платформа 8.3.27.2130 пишет журнал файловой базы только в 1Cv8.lgf и *.lgp. Я положила готовый 1Cv8.lgd в каталог 1Cv8Log свежей базы: платформа создала рядом 1Cv8.lgf и .lgp, события пошли в них, размер .lgd остался прежним. Среди команд «Настройки журнала регистрации» переключателя формата нет. По статье на Хабре «Записки оптимизатора 1С (ч.13)» (ссылка в разделе «Источники»), начиная с 8.3.22 платформа не конвертирует журнал в SQLite и не поддерживает этот формат. Файлы .lgd встречаются в базах, которые работали на платформах 8.3.5-8.3.21, и в архивах их журналов. Скрипт читает такие файлы по схеме таблиц, которую выдала платформа, и проверен на файле, собранном из записей настоящего журнала: те же события, роли, цели и время, что на текстовом журнале (evidence/check-experiment.txt).

Опыт на журналах других баз

Чтобы проверить скрипт на данных, которых я не создавала в опыте, я прогнала его (только чтение, --events all) на журналах трёх других файловых баз этого компьютера:

Код возврата во всех трёх прогонах 0. Скорость около 0,9 МБ в секунду на этом компьютере при выводе каждого события.

Файлы к статье

К статье приложены два архива.

Инструмент rights-soc-26-3-tool.zip содержит rights_watch.py, README с описанием полей и пределов проверки, 21 тест и данные для них: журнал первого захода (словарь и записи), справочник ролей. Запуск из корня распакованного архива:

1
2

python rights_watch.py tests/fixtures/lgp_log --brief --roles-dir tests/fixtures/Roles
python -m unittest discover -s tests -v

Компаньон rights-soc-26-3-companion.zip содержит правила корреляции на событиях опыта (siem-rules.md), correlate.py и check_experiment.py, события опыта в JSON и CEF, шесть событий с разбором, чек-лист внедрения, сценарии COM для обоих заходов и сопоставления полей, make_stand.py для сборки стенда, журналы запусков и 9 тестов.

Рисунок 5. Тесты из распакованных архивов: 21 тест инструмента и 9 тестов компаньона, платформа не нужна.

Источники

• Записки оптимизатора 1С (ч.13). Что не так в журнале регистрации 1С в формате SQLite? - про исключённую с 8.3.22 конвертацию журнала в SQLite.

Итог

Журнал регистрации 1С 8.3.27 даёт SIEM события изменения пользователей с точностью до секунды и с составом ролей после действия. Скрипт rights_watch.py нашёл все 23 действия двух заходов опыта на «Нано-УТ 2.0» и выдал выдачу и снятие ролей в JSON Lines и CEF. Правила корреляции поймали роль администратора, снятую через 12 и 5 секунд, и подбор пароля с успешным входом.

Практический смысл: администраторам и SOC достаточно прочитать журнал и сохранить состав ролей по пользователям, чтобы получить события «выдана роль» и «снята роль» с именами. Для имён ролей нужна выгрузка конфигурации, для надёжного «выдано, снято» нужен файл позиции с резервной копией.

Выводы относятся к платформе 8.3.27.2130, файловой базе и текстовому журналу .lgf и .lgp. Клиент-серверные базы и журнал кластера, ограничения на уровне записей и профили групп доступа БСП (в событиях _$User$_.* их нет) в проверку не вошли; запросы для Splunk и Elastic в компаньоне остаются шаблонами.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S