OSSEC заметка по настройке парсеров (decoders)08.03.2017 10:03

Приветствую уважаемое сообщество. В данной статье я хочу описать несколько важных (на мой взгляд) моментов, которые нужно иметь ввиду при настройке программного обеспечения 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.

1d52540be880489c992c6cf780a840bc.jpg

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

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


  windows
  ^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog:

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

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


  windows
  windows
  Security
  \S+:\s+(\w+)\((\d+)\):\s+(\S+):\s+
  (\S+):\s+\S+:\s+(\S+):\s+
  status, id, extra_data, srcuser, system_name
  name, location, user, system_name

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

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

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


windows
windows
Source\s+IP\s+Address:\s+(\S+)
srcip

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

windows
windows
Client\s+Address:\s+(\S+)
srcip

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

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

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

Комментарии (0)

© Habrahabr.ru