Decoders

In OSSEC decoders are an attempt to parse a log message, extracting important information for use elsewhere. Information like user names or IP addresses can be passed to rules for comparison or differentiated from other information in the final log. This can make importing the log messages into a SIEM or log management system easier.

decoder

Each decoder starts by labeling it as a decoder and giving it a name. The name must be unique.

<decoder name="widget-processor">
  ...
</decoder>

parent

A decoder may build on the parsing done by a previous decoder. This is defined by setting a parent for the second decoder, using the parent’s name.

<decoder name="widget-auth">
  <parent>widget-processor</parent>
  ...
</decoder>

accumulate

A number of programs will log a single event over multiple messages, using a unique identifier to link them together. The accumulate option will allow OSSEC to track events over multiple log messages based on a “decoded ID” within the log message. The accumulate option requires an id field as seen in the example below.

 <decoder name="widget-transaction">
   <parent>widget-processor</parent>
   <regex>ID: (\d+) </regex>
   <order>id</order>
   <accumulate />
</decoder>

program_name

This compares the defined value to the program_name the pre-decoder assigns to a log message. This uses the simple regex syntax.

program_name_pcre2

This compares the defined value to the pre-decoded program_name using the pcre2 syntax.

prematch

A search string that must match for the decoder to continue evaluation. This uses the simple regex syntax.

prematch_pcre2

A search string that must match for the decoder to continue evaluation. This option uses the pcre2 syntax.

regex

An OSSEC regex formatted search string. Parts of the log message may be extracted into fields named in order.

pcre2

A pcre2 regex formatted search string. Parts of the log message may be extracted into fields namd in order.

order

This option names the fields created by pcre2 or regex. The field names are comma separated.

Historically there were only a few field names available for the order option, but as of version 3.3 any names may be used.

The historical order list:

  • location - where the log came from (only on FTS)
  • srcuser - extracts the source username
  • dstuser - extracts the destination (target) username
  • user - an alias to dstuser (only one of the two can be used)
  • srcip - source ip
  • dstip - dst ip
  • srcport - source port
  • dstport - destination port
  • protocol - protocol
  • id - event id
  • url - url of the event
  • action - event action (deny, drop, accept, etc)
  • status - event status (success, failure, etc)
  • extra_data - Any extra data

The following fields may be used in active response configurations:

  • user
  • srcip
  • filename (syscheck file name?)
<decoder name="widget-reg">
  <pcre2>widget id: (\S+), name: (\w+)$</pcre2>
  <order>widget_id, widget_name</order>
</decoder>

fts

OSSEC is able to create alerts based on First Time Seen events. This option enables the fts tracking for the specified fields.

<decoder name="widget-fts">
  <fts>name, user, location</fts>

type

Categorize log messages into different groups. This could include firewall, windows, ids, web-log, etc.