OSSIM. Створення простого плагіна для розбору логів

Цей матеріал буде корисний початківцям адміністраторам, виявляє інтерес до системи OSSIM.
Установка системи вже була докладно описана на хабре, тому на даному моменті я зупинятися не буду.
У статті описана процедура написання плагіна для обробки журналів подій, що отримуються системою OSSIM по протоколу syslog від додатка, що працює на віддаленій машині. Тут слід зазначити, що цей додаток не підтримується OSSIM "з коробки". Таким чином, дана інструкція підійде для розробки плагіна для будь-якого Вашого додатки, яке для передачі журналів подій використовує протокол syslog.
В якості основи використовувалися документи вендора:
Alienvault. Building collector Plugins
Alienvault. How to create a data source plugin

1. Вихідні дані

1.1 Архітектура
Сервер з встановленим OSSIM (далі — Сервер OSSIM), має IP адресу 192.168.0.111 і ім'я alienvault.
Сервер під управлінням CentOS 6.6 (далі — Сервер) з IP адресою 192.168.0.54 і ім'ям cnc-2. На Сервері встановлено додаток (умовно назвемо його bw_lists), яке відправляє журнали подій у режимі реального часу за протоколом syslog Сервер OSSIM.
Додаток є певною модифікацією стандартного шелла, що виконує фільтрацію вводяться користувачем команд.

Малюнок 1 – Архітектура рішення
1.2 Опис структури події
Формат події:
<дата у форматі syslog> <ім'я хоста> bw_lists[<номер сесії>]: user:<ім'я користувача> ip:<IP Сервера> ip_tko:<IP цільової системи> IN:<виконана користувачем команда> OUT: Res: <звіт виконання або відмови> <текст команди> <висновок цільової системи>
У кожне подій, що надсилається за syslog додаток включає:
1) номер сесії (в квадратних дужках відразу після слова bw_lists)
2) ім'я користувача, що виконав команду
3) IP адреси Сервера та цільової системи, на якій ця команда повинна відпрацювати
4) команду, виконану користувачем (наприклад — "configure terminal")
5) звіт про виконання або відмову у виконанні команди, відданої користувачем (ACCEPT або DENY)
6) висновок, отриманий в консолі (наприклад — "Enter configuration commands, one per line. End with CNTL/Z")
Приклад подій, отриманих від програми:
Nov 20 14:15:33 cnc-2 bw_lists[19025]: user:oper1 ip:192.168.0.54 ip_tko:192.168.1.104 IN: configure terminal OUT: Res: ACCEPT configure terminal Enter configuration commands, one per line. End with CNTL/Z.
Nov 20 14:15:39 cnc-2 bw_lists[19025]: user:oper1 ip:192.168.0.54 ip_tko:192.168.1.104 IN: interface Gi0/1 OUT: Res: ACCEPT interface Gi0/1 ^ % Invalid input detected at '^' marker.
Nov 20 14:16:29 cnc-2 bw_lists[19025]: user:oper1 ip:192.168.0.54 ip_tko:192.168.1.104 IN: exit OUT: Res: ACCEPT exit

2. Завдання

1) Налаштувати на Сервері OSSIM прийом журналів подій за протоколом syslog від Сервера і запис їх у файл;
2) Налаштувати розбір (парсинг) отриманих журналів подій в системі OSSIM. Необхідно мати наступну інформацію:
  • номер сесії (в квадратних дужках відразу після слова «bw_lists»);
  • ім'я користувача, що виконав команду (після «user:»);
  • IP адреси Сервера (після «ip:») та цільової системи (після «ip_tko:»), на якій ця команда повинна відпрацювати;
  • пункт, виконану користувачем (після «IN:», наприклад — «configure terminal»);
  • звіт про виконання або відмову у виконанні команди (після «Res:»), відданої користувачем (ACCEPT або DENY).

3. Рішення

3.1 Налаштування на Сервері OSSIM прийому журналів подій від Сервера
У рамках виконання цього завдання на Сервері OSSIM буде налаштований rsyslog для прийому журналів подій, що приходять від Сервера за протоколом syslog.
Для цього відредагуємо файл /etc/rsyslog.conf і додамо в нього рядок:
if $programname contains 'bw_lists' then -/var/log/SR/bw-list-log.log

І перезапустим rsyslog, щоб зміни вступили в силу:
/etc/init.d/rsyslog restart

Таким чином, події, отримані Сервером OSSIM від Сервера і містять "bw_lists" буде записано у файл /var/log/SR/bw-list-log.log. Далі налаштуємо розбір подій з цього файлу самим OSSIM.
3.2 Налаштування розбору (парсинга) і відображення цих подій у OSSIM
Процес налаштування розбору подій в OSSIM поділяється на два етапи:
  • створення конфігураційного файлу-парсера журналів подій;
  • додавання інформації про парсере і типі(ах) подій в базу даних OSSIM;
  • включення плагіна.
Перший файл відповідає за парсинг самого журналу і розподіл отриманої інформації по полях схеми опису подій, використовуваної OSSIM, другий — для відображення типів і класів подій в інтерфейсі OSSIM, а також для призначення пріоритетів подій.
Для опису подій OSSIM використовує схему, що складається з декількох десятків полів, таких як: date, sourceIP, destinationIP, username, userdata1-9 і т. д. Докладно схема наведена в офф. документації OSSIM.
3.2.1 Створення конфігураційного файлу-парсера журналів подій
Файли-парсери розташовуються на сервері OSSIM в директорії /etc/ossim/agent/plugins/
Створимо новий файл з ім'ям bwlistlog.cfg (ім'я можна вибрати довільне, воно ні на що не впливає і більше ніде не фігурує. Однак, ім'я, обов'язково має відповідати формату <букво-цифро поєднання без пробілів>.cfg).
В кожному файлі повинні бути виділені кілька секцій (назви секцій заключаються в квадратні дужки), а саме:
[DEFAULT]
В даній секції присутній номер plugin а. За рекомендацією вендора, номер plugin а необхідно вибирати з діапазону 9000 — 10000. Цей номер повинен бути унікальним для даної інсталяції OSSIM.
З'ясувати зайнятий вибраний Вами номер для plugin а можна наступним чином:
grep "plugin_id=<номер plugin а>" /etc/ossim/agent/plugins/*
Наприклад,
grep "plugin_id=9002". /etc/ossim/agent/plugins/*

[config]
У цій секції вказується:
  • тип plugin а;
  • увімкнуто;
  • тип джерела повідомлень;
  • файл, в якому зберігаються повідомлення;
  • налаштування процесів, генерящих події (це потрібно для plugin ів типу monitor).
[translation]
У цій секції можна задати "переклад" значення певних полів події в числа. Далі ці числа можна використовувати для завдання класів подій, для наочності в графічному інтерфейсі. Детальніше в розділі 3.2.2
Остання секція, звана в прикладі [bwlistlog] є першим правилом розбору повідомлень. Назви секцій — правил можуть носити довільний формат. Рекомендується задавати наступним чином: [ <номер> <ім'я джерела> ], наприклад [ 1 — applog ], [ 2 — applog ] і т. д.
Справа в тому, що в рамках одного plugin а можна задати кілька правил, тобто схем розбору повідомлень. Зроблено це для того, щоб обробляти події, що мають різну структуру (якщо неможливо всі події від джерела розібрати за допомогою одного правила парсинга).
При наявності декількох правил OSSIM порівнює повідомлення з кожним з них по черзі, причому черга вибудовується за алфавітним порядком. Приклад — є 3 правила з іменами [a-rule], [b-rule], [c-rule]. Першим перевіриться відповідність правилу a rule, потім b-rule і т. д. Тому, більш загальні правила краще іменувати таким чином, щоб вони спрацьовували останніми в черзі.
Зміст файлу bwlistlog.cfg з коментарями:
[DEFAULT]
# унікальний номер парсера (в термінології OSSIM - plugin.)
plugin_id=9002 

[config]
# тип plugin а. Вони бувають двох типів - detector і monitor. Для прийому за syslog використовується тип detector
type=detector 
# тумблер включення
enable=yes 

# тип лода. log - текстовий файл. може також бути database (читання даних з БД), sdee (cisco), snortlog (логи snort), wmi (для безагентского збору з машин під управлінням ОС Windows підтримують протокол wmi)
source=log
# розташування файлу з логами, який буде розбирати даний парсер.
location=/var/log/SR/bw-list-log.log 

# повинен OSSIM створити файл у разі його відсутності. Я не міняв цю опцію
create_file=true 

# блок інструкцій з перезапуску сервісів при старті-зупинці агента OSSIM. Для джерел, розташованих на Сервері OSSIM, як у нашому випадку, рекомендується залишити все по-замовчуванню
process= 
start=no
stop=no
startup=
shutdown=

# розділ в якому можна задати "переклад" значень полів
[translation] 
ACCEPT=1
DENY=2

# назва першого (і, в даному випадку, єдиного) правила парсера. 
[bwlistlog] 
# тип події. міняти не потрібно
event_type=event
# регулярний вираз, згідно з яким відбувається парсинг подій
regexp="^((?P<date>\S+\s+\d+\s+\d+:\d+:\d+)\s+(?P<sensor>\S+)\s+bw_lists\[(?P<session>\d+)\]\:\s+user\:(?P<user>\S+)\s+ip\:(?P<sr_node>\S+)\s+ip_tko\:(?P<tko_node>\S+)\s+IN\:(?P<message>.*)\s+OUT\:\s+Res\:\s+(?P<result>\S+).*)"
# далі задається відповідність полів, позначених з допомогою парсера полів, передбаченим для подій у схемі OSSIM. Детальніше в розділі 3.2.3
device={$sr_node}
date={normalize_date($date)}
plugin_sid={translate($result)}
src_ip={$tko_node}
username={$user}
userdata1={$message}
userdata2={$session}

В даному регулярному виразі ми виділяємо (з допомогою круглих дужок) ту інформацію, яку хочемо витягти і призначаємо їй довільний тег (з допомогою знака питання, літери Р і дужок ?P<>), по якому потім можемо до неї звертатися. Приклад:
(?P<date>\S+\s+\d+\s+\d+:\d+:\d+)

означає, що інформація на початку рядка, яка потрапляє під вираз \S+\s+\d+\s+\d+:\d+:\d+ буде адресуватися за тегом "date". Далі ми повідомляємо, що в полі "date" схеми OSSIM ми хочемо покласти значення нашого поля "date" попередньо виконавши його нормалізацію (OSSIM вміє перетворювати дату в різних форматах до свого єдиного):
date={normalize_date($date)}

Для тестування регулярних виразів можна використовувати, наприклад, ось цей інструмент. Майте на увазі, що даний інструмент з тегами працювати не вміє. Тому, протестувавши своє регулярне вираження в ньому, їх потрібно буде додати.
Також необхідно пояснити поле "plugin_sid". Події від одного джерела — з одним і тим же "plugin_id" — можуть належати до різних класів, наприклад "ACCEPT" і "DENY" для нашого прикладу. "plugin_sid" як раз вказує на ідентифікатор класу, а рядок:
plugin_sid={translate($result)}

каже парсеру про те, що потрібно звернутися в розділ [translate] для виконання трансляції інформації, отриманої тегом "result". "ACCEPT" транслюється в одиницю, "DENY" — у двійку. Як і навіщо призначати класи подій — в наступному розділі.
Так, "plugin_sid" можна призначити і вручну для кожного правила парсинга, вказавши, наприклад:
plugin_sid=1

3.2.2 Додавання інформації про парсере і типі(ах) подій в базу даних OSSIM

Після написання конфігураційного файлу парсера необхідно додати інформацію про нього в БД OSSIM.
Це робиться за допомогою написання mysql скрипта і його запуску. Приклади скриптів лежать на Сервері OSSIM в папці:
/usr/share/doc/ossim-mysql/contrib/plugins/
Ім'я скрипта можна вибрати довільне.
Для наочності, відразу наведу скрипт з нашого прикладу:
DELETE FROM plugin WHERE id = "9002";
DELETE FROM plugin_sid where plugin_id = "9002";
INSERT IGNORE INTO plugin (id, type, name, description) VALUES (9002, 1, 'bw-адрес', 'Bash filtering');

INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9002, 1, NULL, NULL, 'Command Accepted');
INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9002, 2, NULL, NULL, 'Command Denied');

Перші три рядки вичищають всі старі згадки про "plugin_id" під номером 9002 з БД і створюють його заново.
Наступні дві якраз описують класи подій.
Як ви пам'ятаєте з попереднього розділу, "plugin_sid" обчислюється шляхом зіставлення інформації, отриманої з події з допомогою парсера під тегом "result" (може бути "ACCEPT" і "DENY") і подальшого перетворення її в секції [translate] (в конфігураційному файлі програми). Таким чином маємо два класи подій 1 — "ACCEPT", 2 — "DENY".
Саме про цих класах подій повідомляють БД OSSIM рядки:
INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9002, 1, NULL, NULL, 'Command Accepted');
INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9002, 2, NULL, NULL, 'Command Denied');

Знайомі з синтаксисом "mysql" з легкістю їх зрозуміють. Для інших поясню, що події, що класифіковані як "ACCEPT" в інтерфейсі OSSIM будуть з'являтися з назвою "Command Accepted", а "DENY" — "Command Denied". Тут також можна задати параметри категорирования подій цього типу джерел (category_id, class_id).
Після створення скрипта необхідно завантажити його в БД OSSIM командою:
# ossim-db < /usr/share/doc/ossim-mysql/contrib/plugins/bw-lists.sql

3.2.3 Включення плагіна

Включити плагін створений можна наступним чином:
1) підключитися до Сервера OSSIM по SSH, зайти в меню: "Configure sensor" — "Configure Data Source Plugins";
2) знайти в списку плагін "bw-lists" і поставити біля нього ".*", натиснути "ОК";
3) повернутися в кореневий меню клавішею "Back";
4) вибрати опцію "Apply all Changes".
Новий плагін готовий до обробки журналів подій.
Однак, якщо події надходять, а в інтерфейсі OSSIM, задавши сортування за типом плагіна, ви їх не бачите, то ....

4. Усунення неполадок

1) перевірте, що лог файл, вказаний в конфігураційному файлі програми існує і в ньому оновлюються запису — тобто журнали надходять;
2) перевірте, що формат подій підходить під написане Вами регулярний вираз;
3) перевірити файл /var/log/alienvault/agent/agent.log на предмет помилок, пов'язаних з Вашим плагіном:
grep ERR /var/log/alienvault/agent/agent.log|grep 9002
grep Discard /var/log/alienvault/agent/agent.log|grep 9002
grep Warn /var/log/alienvault/agent/agent.log|grep 9002

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.