Данный материал будет полезен начинающим администраторам, проявляющим интерес к системе OSSIM.
Установка системы уже была подробно описана на хабре, поэтому на данном моменте я останавливаться не буду.
В статье описана процедура написания плагина для обработки журналов событий, получаемых системой OSSIM по протоколу syslog от приложения, работающего на удаленной машине. Здесь следует отметить, что данное приложение не поддерживается OSSIM "из коробки". Таким образом, данная инструкция подойдет для разработки плагина для любого Вашего приложения, которое для передачи журналов событий использует протокол syslog.
В качестве основы использовались документы вендора:
Alienvault. Building collector Plugins
Alienvault. How to create a data source plugin Сервер с установленным OSSIM (далее — Сервер OSSIM), имеющий IP адрес 192.168.0.111 и имя alienvault.
Сервер под управлением CentOS 6.6 (далее — Сервер) c IP адресом 192.168.0.54 и именем cnc-2. На Сервере установлено приложение (условно назовем его bw_lists), которое отправляет журналы событий в режиме реального времени по протоколу syslog на Сервер OSSIM.
Приложение является некой модификацией стандартного шелла, выполняющего фильтрацию вводимых пользователем команд.  Рисунок 1 – Архитектура решения Формат события:
<дата в формате 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")
Пример событий, полученных от приложения: 1) Настроить на Сервере OSSIM прием журналов событий по протоколу syslog от Сервера и запись их в файл;
2) Настроить разбор (парсинг) полученных журналов событий в системе OSSIM. Необходимо извлечь из них следующую информацию: В рамках выполнения этой задачи на Сервере OSSIM будет настроен rsyslog для приема журналов событий, приходящих от Сервера по протоколу syslog.
Для этого отредактируем файл /etc/rsyslog.conf и добавим в него строку: И перезапустим rsyslog, чтобы изменения вступили в силу: Таким образом, события, полученные Сервером OSSIM от Сервера и содержащие "bw_lists" будут записаны в файл /var/log/SR/bw-list-log.log. Далее настроим разбор событий из этого файла самим OSSIM. Процесс настройки разбора событий в OSSIM разделяется на два этапа: Первый файл отвечает за парсинг самого журнала и распределение полученной информации по полям схемы описания событий, используемой OSSIM, второй — для отображения типов и классов событий в интерфейсе OSSIM, а также для назначения приоритетов событиям.
Для описания событий OSSIM использует схему, состоящую из нескольких десятков полей, таких как: date, sourceIP, destinationIP, username, userdata1-9 и т.д. Подробно схема приведена в офф. документации OSSIM. Файлы-парсеры располагаются на сервере OSSIM в директории /etc/ossim/agent/plugins/
Создадим новый файл с именем bwlistlog.cfg (имя можно выбрать произвольное, оно ни на что не влияет и более нигде не фигурирует. Однако, имя обязательно должно соответствовать формату <букво-цифро сочетание без пробелов>.cfg).
В каждом файле должны быть выделены несколько секций (названия секций заключаются в квадратные скобки), а именно: 
В данной секции присутствует номер plugin'а. По рекомендации вендора, номер plugin'а необходимо выбирать из диапазона 9000 — 10000. Данный номер должен быть уникальным для данной инсталляции OSSIM.
Выяснить занят ли выбранный Вами номер для plugin'а можно следующим образом:
grep "plugin_id=<номер plugin'а>" /etc/ossim/agent/plugins/*
Например 
В этой секции указывается:  [translation] 
В этой секции можно задать "перевод" значений определенных полей события в числа. Далее эти числа можно использовать для задания классов событий, для наглядности в графическом интерфейсе. Подробнее в разделе 3.2.2 Последняя секция, называемая в примере  является первым правилом разбора сообщений. Названия секций — правил могут носить произвольный формат. Рекомендуется задавать его следующим образом: [ <номер> — <имя источника> ], например [ 1 — applog ], [ 2 — applog ] и т.д.
Дело в том, что в рамках одного plugin'а можно задать несколько правил, т.е. схем разбора сообщений. Сделано это для того, чтобы обрабатывать события, имеющие разную структуру (если невозможно все события от источника разобрать с помощью одного правила парсинга).
При наличии нескольких правил OSSIM сравнивает сообщение с каждым из них по-очереди, причем очередь выстраивается по алфавитному порядку. Пример — есть 3 правила с именами [a-rule], [b-rule], [c-rule]. Первым проверится соответствие правилу a-rule, затем b-rule и т.д. Поэтому, более общие правила лучше именовать таким образом, чтобы они срабатывали последними в очереди.
Содержание файла bwlistlog.cfg с комментариями: В данном регулярном выражении мы выделяем (с помощью круглых скобок) ту информацию, которую хотим извлечь и назначаем ей произвольный тег (с помощью знака вопроса, буквы Р и скобок ?P<>), по которому потом можем к ней обращаться. Пример: означает, что информация в начале строки, которая попадает под выражение \S+\s+\d+\s+\d+:\d+:\d+ будет адресоваться по тегу "date". Далее мы сообщаем, что в поле "date" схемы OSSIM мы хотим положить значение нашего поля "date" предварительно выполнив его нормализацию (OSSIM умеет преобразовывать дату в разных форматах к своему единому): Для тестирования регулярных выражений можно использовать, например, вот этот инструмент. Имейте ввиду, что данный инструмент с тегами работать не умеет. Поэтому, оттестировав свое регулярное выражение в нем, их нужно будет добавить.
Также необходимо пояснить поле "plugin_sid". События от одного источника — с одним и тем же "plugin_id" — могут принадлежать разным классам, например "ACCEPT" и "DENY" для нашего примера. "plugin_sid" как раз указывает на идентификатор класса, а строка: говорит парсеру о том, что нужно обратиться в раздел [translate] для выполнения трансляции информации, полученной тегом "result". "ACCEPT" транслируется в единицу, "DENY" — в двойку. Как и зачем назначать классы событий — в следующем разделе.
Да, "plugin_sid" можно назначить и вручную для каждого правила парсинга, указав, например:   После написания конфигурационного файла парсера необходимо добавить информацию о нем в БД OSSIM.
Это делается посредством написания mysql скрипта и его запуска. Примеры скриптов лежат на Сервере OSSIM в папке:
/usr/share/doc/ossim-mysql/contrib/plugins/
Имя скрипта можно выбирать произвольное.
Для наглядности, сразу приведу скрипт из нашего примера: Первые три строки вычищают все старые упоминания о "plugin_id" под номером 9002 из БД и создают его заново.
Следующие две как раз описывают классы событий.
Как вы помните из предыдущего раздела, "plugin_sid" вычисляется посредством соотнесения информации, полученной из события с помощью парсера под тегом "result" (может быть "ACCEPT" и "DENY") и последующего преобразования ее в секции [translate] (в конфигурационном файле парсера). Таким образом имеем два класса событий 1 — "ACCEPT", 2 — "DENY".
Именно об этих классах событий сообщают БД OSSIM строки: Знакомые с синтаксисом "mysql" с легкостью их поймут. Для остальных поясню, что события, классифицированные как "ACCEPT" в интерфейсе OSSIM будут появляться с названием "Command Accepted", а "DENY", соответственно — "Command Denied". Здесь также можно задать параметры категорирования событий этого типа источников (category_id, class_id).
После создания скрипта необходимо загрузить его в БД OSSIM командой:   1) проверьте, что лог файл, указанный в конфигурационном файле парсера существует и в нем обновляются записи — т.е. журналы поступают;
2) проверьте, что формат событий подходит под написанное Вами регулярное выражение;
3) проверьте файл /var/log/alienvault/agent/agent.log на предмет ошибок, связанных с Вашим плагином: