You are here

Tuning Alienvault-HIDS: Part 1

Submitted by kgeil on Mon, 09/12/2016 - 13:29

Today, I'm going to demonstrate how to drop unnecessary HIDS events from an Alienvault system. Most Alienvault plugins work by parsing syslog messages being appended to one of the logs in #/var/log.  Usually, rsyslog rules are created so that each type of device sends its log to a unique file.  While the Alienvault HIDS plugins work in a similar fashion, they are a bit different  in that Alienvault isn't just collecting logs that are being sent to the sensor, but instead, runs OSSEC, a server application which collects logs from agents installed on clients, does some parsing, and generates alerts (based on a large, mature ruleset).  These alerts are stored in #/var/ossec/logs/alerts/alerts.log.  This log is then read by one or more of the OSSEC plugins using the same process as other plugins.  An important note: OSSEC does not write everything it receives from the client by default.  It can be configured this way (by adding <logall>yes</logall> line to #/var/ossec/etc/ossec.conf), but that's quite noisy;   some administrators feel pressured by compliance needs to log everything, but compliance standards don't often dictate exactly what to audit, making the whole thing a bit gray.  Since PCI compliance is my main concern, I look to the PCI-DSS section 10, which tells me:  "Implement audit trails to link all access to system components to each individual user(10.1)", and "All actions taken by any individual with root or administrative privileges (10.2.2)."  Alienvault HIDS/OSSEC does provide this capability (with some tuning), and I am comfortable (and my QSA is as well), that my logging is sufficient.  Another QSA might beg to differ, so please do not take my word as authority on this. Since the PCI-DSS does not tell me what audit policies on my machines to enable, offering only the advice above, using the <logall> option will burden your siem with a great deal of extra data that you are unlikely to look at. Ossec diagram

As for today's problem, I'm getting thousands of Alienvault-Hids "service type changed" messages, and the overwhelming majority are from Microsoft's BITS, the Background intelligent transfer service, and the Windows Modules Installer service. From the reading I've done on this topic,  on a domain with SCCM and WSUS, the startup type of these two services seems to change very frequently, and it's normal behavior related to updates installation and SCCM management. If anyone has evidence to the contrary, please leave a comment below.  The bottom line is, I need to discard them so that I can alert on events which are service type changes that I care about.  

The details of what we're about to do are described in the OSSEC book, in chapter 4.  It's available online for free: http://www.ossec.net/ossec-docs/OSSEC-book-ch4.pdf

In a nutshell, we need to do the following:


  1. Find a unique string in the log lines we want to drop.
  2. Grep through OSSEC's alerts.log file to get these events as plain text without carriage returns, etc.
  3. Copy some sample events into a temporary file in notepad.
  4. Create an OSSEC rule to discard the unwanted events by setting the level to "0".
  5. Run ossec-logtest to make sure our rules are working as expected.

In the screenshot below, you  can see the grep criteria I used, and the search string highlighted in red.   I use tac for 2 reasons: A. it finds the most recent lines first, and B. the first time I discovered the tac command, I thought it was so clever to just name it the opposite of cat, it has stuck with me, and is one of my favorite commands :)

Alienvault screenshot

A sample of each of one of these is here:
AV - Alert - "1473357373" --> RID: "18145"; RL: "3"; RG: "windows,policy_changed,"; RC: "Service startup type was changed."; USER: "SYSTEM";SRCIP: "None"; HOSTNAME: "(MyHost11) 192.168.1.111->WinEvtLog"; LOCATION: "(MyHost11) 192.168.1.111->WinEvtLog"; EVENT: "[INIT]WinEvtLog: System: INFORMATION(7040): Service Control Manager: SYSTEM: NT AUTHORITY: MyHost11.MyDomain.local: The start type of the Background Intelligent Transfer Service service was changed from auto start to demand start.  [END]";

And here:

AV - Alert - "1473337799" --> RID: "18145"; RL: "3"; RG: "windows,policy_changed,"; RC: "Service startup type was changed."; USER: "SYSTEM";SRCIP: "None"; HOSTNAME: "(MyHost14) 192.168.1.114->WinEvtLog"; LOCATION: "(MyHost14) 192.168.1.114->WinEvtLog"; EVENT: "[INIT]WinEvtLog: System: INFORMATION(7040): Service Control Manager: SYSTEM: NT AUTHORITY: MyHost14.MyDomain.local: The start type of the Windows Modules Installer service was changed from auto start to demand start.  [END]";

Once you confirm that the events you're looking at are the ones you want to discard,  copy them, and paste them into a text document, and keep it open for later use.  The information between "AV - Alert" and "[INIT]" is added by ossec when the alerts are generated, so for our rule creation and testing, we're only concerned with the information that follows the [INIT] tag.  I have also seen ossec sometimes add a date string between [INIT] and WinEvtLog, and this has gotten in the way of my rule testing and regex parsing.  Keep in mind that you may need to adjust for that.

Now to add some local OSSEC rules to your Alienvault system.  If you have never used local rules, or aren't certain if they are enabled, you should check in /var/ossec/etc/ossec.conf, to make sure that you have local rules enabled.  The convention is to use a file called local_rules.xml.  You need to make sure that file name is included in the section of /var/etc/ossec/ossec.conf labeled: <ossec_config>  <!-- rules global entry -->.  In my implementation, local_rules.xml was not included  by default, so I had to add the line:     <include>local_rules.xml</include>    at the bottom of the section.

local_rules.xml should exist already, with some examples to get you started.  It is well worth reading chapter 4 of the ossec book from the link above, but I'll explain as well as I can for our simple scenario here.

The minimum requirements for a local rule are that it must:

  • Exist within a group
  • Have a unique id between 100,000, and 119,999 (to prevent collisions with official rules) **Alienvault recently used rule numbers 102002 and 102003 (for alienvault-windows-logon-logoff_rules.xml  and 100051 (for alienvault-windows-USB_rules.xml) without much announcement.  It broke my HIDS parsing, and that of some others.  I will say that the new rules from Alienvault improve the parsing of windows events dramatically, but  consider it wise to avoid rules in these ranges too (102200x and 10005x)
  • Assign a severity level to the event in question: To simply weed out noise, we will set our severity  level to zero, which tells OSSEC to ignore the event.


Below is an excerpt from my local_rules.xml file, with my comments added in yellow.  Reading chapter 4 in the OSSEC book for syntax rules is helpful, and the local_rules.xml file has enough examples to get you started as well.
Ossec local rules screenshot

The text for Rule 110064 is below:
<rule id="110064" level="0">
    <if_sid>18145</if_sid>
    <match>Windows Modules Installer service was changed</match>
    <description>Discard Modules Installer Service Change</description>
    </rule>

Considering the fact that Alienvault has begun taking some of rule IDs starting with 110051, I will say that 10006x is not a good range, and I'll be changing this in the near future, to some range a few thousand away from any of the Alienvault custom rules.

Once your local rules are in place, you'll need to restart ossec by invoking:
sensor#/etc/init.d/ossec restart
Now for the fun part: Testing your new rules.

Navigate to /var/ossec/bin, and invoke:
sensor#./ossec-logtest
You should see the ossec-logtest application running, waiting for you to paste a log line in.  Hopefully, you still have that text document open, and you can just paste in some lines for testing.  so, from our example above, copy the text after the [INIT] tag to the end.  Remember that in some cases, you may need to also omit any date string between [INIT] and WinEvtLog. Hit enter, and hopefully, you'll see some output like this:
ossec-logtest screenshot

if you don't get a match for your rule, make sure that:
You have local_rules.xml included in /var/ossec/etc/ossec.conf file
You don't have any syntax errors in your rule.
You have restarted the ossec service:  /etc/init.d/ossec restart

There you have it, no more noise, and I'm only getting the service startup type changes I'm looking for: The ones that involved a human hand. This brings me one step closer to compliance with PCI-DSS, SOX,HIPAA,ISO27002, and other compliance frameworks.  You can also check my favorite:  SANS MOACL 7.3.0 (more on the MOACL later).

For part 2, I will describe the process involved in parsing events that are not currently showing up in your Alienvault GUI.

Enjoy!

Kevin