Приветствую уважаемое сообщество. В данной статье я хочу описать несколько важных (на мой взгляд) моментов, которые нужно иметь ввиду при настройке программного обеспечения OSSEC (HIDS, SIEM система). Официальная документация по системе представлена в достаточно большом объеме на просторах сети, однако некоторые важные моменты абсолютно нигде не описываются. В качестве «путевых заметок» приведу их ниже. Сразу оговорюсь, что описывать установку системы, развертывание агентов, первичную настройку я не буду. Т.е. предполагаю, что читатель уже знает, что такое decoder и rule в контексте OSSEC. Все нижеперечисленное было проверено на версии по 2.8.1, возможно в будущих версиях это пофиксят. Итак, в бой.

При разработке парсеров, или как OSSEC их именует, «decoder» есть возможность использования нескольких уровней, т.е. родительский decoder (parent) и дочерние.

Родительский описывает общий вид, под который подпадают все события определенного класса (например, все события event log'а ОС Windows). Дочерние же парсеры могут в зависимости от определенных параметров исходного сообщения (а именно параметр prematch) применяться к нему или не применяться и таким образом из разных типов сообщений можно получать (парсить) разную информацию. Здесь нужно иметь ввиду, следующие моменты, не описанные в документации:

1 — дочерние decoder'ы полностью перезатирают все данные, которые были получены из исходного «сырого» сообщения (с помощью его парсинга);

2 — следствие пункта 1 — в родительском decoder'е не нужно выполнять парсинг, т.е. использовать директиву «regex» (кто знаком с контекстом OSSEC, тот поймет). Все, что в нем следует сделать — это определять по заданному шаблону ВСЕ события от данного источника. Но не указывать поля для парсинга. Весь парсинг будет выполняться дочерними парсерами;

3 — regex, используемый в OSSEC, не умеет обрабатывать записи вида " .* " внутри выражений. Пример. Если Вам нужно из строки вида:

2017 Mar 05 19:45:26 WinEvtLog: Security: AUDIT_SUCCESS(4634): Microsoft-Windows-Security-Auditing: DOM_WINSRV-DC$: DOMAIN: nsrv_WinSRV-DC.domain.test: An account was logged off. Subject: Security ID: S-1-5-18 Account Name: DOM_WINSRV-DC$ Account Domain: DOMAIN Logon ID: 0x6dd15b4 Logon Type: 3 This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer." 4646,1

Получить, например, только временную метку и Logon type, то с помощью регулярного выражения:

(\d\d\d\d\s+\w\w\w\s+\d\d\s+\d\d:\d\d:\d\d)\s+.*?Logon\s+Type:\s+(\d+)

сделать это не удастся. OSSEC просто не обработает его. Без сообщений об ошибках. Что же делать? А об этом читайте чуть ниже. Да, кстати, конструкции типа \d{3} заложенный в OSSEC регексп тоже не понимает, т.е. если нужно ровно три цифры подряд — изволь писать \d\d\d. Жуть-жуть-жуть.

4 — Возможность одновременного использования нескольких decoder'ов

Итак, вопрос получения данных из «сырых» событий имеющих разный формат можно решить следующим образом (рассмотрю на примере лога ОС Windws, с которым и работал). Решение данное почерпнул отсюда. Дело в том, что OSSEC может применять сразу несколько decoder'ов к одному сырому сообщению одновременно и не в иерархическом порядке (т.к. если строить иерархию, то последний в иерархии decoder перезатрет все данные, полученные родительскими, как мы помним из пункта 1 данной статьи).

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

В примере ниже выстроена двухуровневая иерархия decoder'ов. Первый уровень просто отыскивает все события Windows Event Log'а, а дочерний уровень decoder'ов выполняет парсинг. В наглядной форме показано ниже на рисунке 1.



Рисунок 1 — Иерархия decoder'ов наглядно

Родительский (parent) decoder выглядит следующим образом:

<decoder name="windows">
  <type>windows</type>
  <prematch>^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: </prematch>
</decoder>

На втором уровне иерархии у нас присутствуют сразу 3 decoder'а, которые имеют одно и то же имя — «windows-generic».

Первый decoder получает из «сырого» сообщения лога windows данные, которые помещает в следующие поля схемы (описывающей событие внутри OSSEC): status, id, extra_data, srcuser, system_name

<decoder name="windows-generic">
  <type>windows</type>
  <parent>windows</parent>
  <prematch offset="after_parent">Security</prematch>
  <regex offset="after_parent">\S+:\s+(\w+)\((\d+)\):\s+(\S+):\s+</regex>
  <regex>(\.+):\s+\.+:\s+(\S+):\s+</regex>
  <order>status, id, extra_data, srcuser, system_name</order>
  <fts>name, location, user, system_name</fts>
</decoder>

Два других decoder'а служат для выделения IP адреса источника из лога Windows. Сперва я пытался решить эту задачу написав regexp с " .* " в середине. Однако, как я писал раньше, OSSEC такие regexp'ы не обрабатывает. Поэтому я решил создать отдельные decoder'ы для получения IP источника из «сырого» лога windows.

Т.к. IP адрес источника может встречаться в логе Windows в разном виде (например, после выражения «Source IP address:» или после выражения «Client Address»), то я создал два decoder'а — каждый для своей конструкции. Они приведены ниже.

decoder для получения IP из конструкции вида «Source IP Address: <IP адрес>»:

<decoder name="windows-generic">
<type>windows</type>
<parent>windows</parent>
<regex offset="after_regex">Source\s+IP\s+Address:\s+(\S+)</regex>
<order>srcip</order>
</decoder>

decoder для получения IP из конструкции вида «Client Address: <IP адрес>»:

<decoder name="windows-generic">
<type>windows</type>
<parent>windows</parent>
<regex offset="after_regex">Client\s+Address:\s+(\S+)</regex>
<order>srcip</order>
</decoder>

Обратите внимание, что в обоих decoder'ах, которые получают IP источника в директиве regex стоит offset=after_regex. Это не опечатка. Дело в том, что данный тип offset срабатывает только в том случае, если уже есть другой decoder с таким же именем, но у которого в параметре regex offset стоит одно из стандартных значений (after_prematch, after_parent или offset восе отсутствует). И, соответственно, decoder с after_regex срабатывает после decoder'а со стандартным значением.

Как вы понимаете, аналогичные конструкции можно создать и для получения других данных из лога windows.

На этом у меня все, спасибо за прочтение. И удачи в познании не познанного!