OSSEC Tips and Quirks

OSSEC Tips and Quirks

ossec-hidsOSSEC is a pretty nifty tool to collect, parse and categorize events. Though it sometimes feels like a party entering the second level of the Proving Grounds of the Mad Overlord. You feel like your are getting there but you know some crazy vorpal bunny is out for you. You might not be wrong..

Milwa my Regex

First, the regex library has the bare minimum using the following tricks will help along the way.

  1. Use the after_parent, after_prematch inside your pattern match directives.
  2. Use the your ^ $ anchors
  3. The | (logical OR) is globally scoped and can’t be used within a field extraction ()
  4. If you think of doing anything fancy, think again, it probably isn’t directly supported
  5. If you bother to extract fields, use them in the rules. It is more efficient and readable.

Dialma my Decoder

This is my list to help me get around to making good Decoders. I am by no means an expert in this stuff, but I will add more as I go along. The OSSEC book is great, but lacks in lighting some of the darker halls.

  1. Decoded_as is really nifty, but cannot be used to reference child decoders
  2. More than one child decoder can be defined for the same parent decoder
    1. The child decoders can be used to deal with different events
    2. The child can also be used one after the other to deal with an event that may have different forms. Due to fields may not in the same place depending on the software version or features enabled.
    3. It also may be hard to create a single regex to extract different fields of the same event
    4. Only a single parent level can be used for decoders.
    5. It is first match on a child decoder.
  3. If you have a commonality between events you should structure your decoders in a tree like manner
  4. madirish.net has a great post on writing a new decoder step by step
  5. You cannot arbitrarily create new fields, you have to work with what is there. (If anyone can show me the contrary I will be happy document how to add them (other than hacking the code)

Tiltowait the Rules

  1.  If you wish to monitor a log file for which no decoder exists, add the path to the file in your ossec.conf and simply create a rule that does a <match>blah</match>.  Of course, this means, ALL your logs will hit his rule. So consider this a quick fix for a critical issue, that will need to be addressed down the line.
  2. Use your decoded fields (as mentioned to the regex section)
  3. Note that, not all fields are available to search in atomic rules. In that case you need to fall back on match statements. A partial list is available on page 125 of the OSSEC book, but more fields can be used like “status”, but not “action”. Test your rules, as for example using action will not generate an error.
  4. If you have any rules that need to match against a list of things, use the lookup tables as described in the book and documentation. This comes up a lot on the mailing list, but then again, some people don’t read the documentation.

Dumapic for the human

The OSSEC server is the workhorse, but humans need a method to interact with the data from OSSEC, here are the IMO best choices for doing this at this current time and date. Pre-built dashboards, reports, field extractions, etc.

  1. Splunk with the Splunk for OSSEC application *
  2. OSSEC Web UI

* Some funky splunk field extraction magic needs to be enabled to set correctly the host, reporting_host fields. This is currently NOT documented correctly anywhere. I promise to write a blurb on the Splunk app help and a blog article here to show how to enable it. Exceptions will occur that need to be dealt with, but that is the nature of the beast, I will try to cover these as best I can.

Some parsing and field extractions work may be needed for commercial offerings

  1. Commercial SIEM tools (Batteries not included)

Base building blocks for search and reporting on the collected data, nothing pre-built.

  1. Elastic search + Kibana
  2. Logstash + Kibana

Written by