All of this was prior to the latest versions of Security Onion which now run inside docker instances. I’ve not yet looked to see how this would be replicated there. But I’m leaving this up for historical purposes.

Another tool in the arsenal of Security Onion is OSSEC, a “scalable, multi-platform, open source Host-based Intrusion Detection System (HIDS).” OSSEC examines log and alert events and correlates them against pre-built (or custom) rules and sends alerts as configured. When installed on the Security Onion server, OSSEC alerts are logged in the sguil database and managed alongside alerts from the network IDS.

An important aspect of any NIDS/HIDS is the ability to tune out expected traffic, to keep noise to a minimum so that real alerts can be triaged and mitigated. Whitelisting the IP address of known and approved vulnerability scanners can reduce the analyst’s workload tremendously. For the Snort/Suricata NIDS, those IPs can be whitelisted through local rules or even completely ignored via BPF filtering (something I’ll cover another time).

Since OSSEC generates alerts by reviewing log entries, the NIDS filters won’t apply to OSSEC. Instead, a reference list must be created/maintained for OSSEC to utilize.

There is a <white_list> directive in the ossec.conf file, but that directive only controls the Active Response module of OSSEC. Hosts identified in the <white_list> tags will not be blocked by any Active Response script, but alerts may still be generated for activity from those sources.

The procedure documented here instead prevents alerts from being generated by specified IPs.

Creating the list file

Create a file to store the key-value paired IPs and labels in the /var/ossec/lists directory. For my example, I will use approved_scanners_list as the file name.

Reference lists in OSSEC must be entered in the format:

key1:value
key2:value
key3:value

Each key must be unique, but the values can be duplicated.

Individual hosts can be entered like so:

10.5.0.99:KaliScanner
10.15.0.120:NessusScanner

IP ranges that break on classes are also supported, like this:

192.168.23.:SecurityToolNetwork
172.12.:InternalNetwork

CIDR entries are not supported, so ranges that do not end on a class border must be either combined with a class entry or listed individually.

Update OSSEC config to reference the list

Once the list has been created, ossec.conf must be updated to reference the list:

<rules>
   [...trimmed output...]
   <list>lists/approved_scanners_list</list>
</rules>

When the list has been created and referenced in the ossec.conf file, the ossec-makelists command must be run to compile the list into a readable format for OSSEC.

The output below shows the result when a reference list needs to be updated:

root@so-onion:/var/ossec/bin# ./ossec-makelists
 * File lists/ip_list.cdb does not need to be compiled
 * File lists/approved_scanners_list.cdb needs to be updated

The output below shows the result when no lists need to be updated:

root@so-onion:/var/ossec/bin# ./ossec-makelists
 * File lists/ip_list.cdb does not need to be compiled
 * File lists/approved_scanners_list.cdb does not need to be compiled

The OSSEC service should be restarted after adding a completely new list to the configuration, but does not need to be restarted if an existing list has been updated. Restarting the OSSEC service is as simple as:

root@so-onion:/var/ossec/bin# ./ossec-control restart

Referencing a list file in the rules

Whitelisting an IP address in OSSEC is accomplished by setting the alert level to “0” for a given rule. We can piggy back on previous rules that have triggered, so that not all traffic from an IP is whitelisted, but only that traffic that matches expected behavior.

A review of the /var/ossec/rules/web_rules.xml file shows that SID group 31100 indicates web access logs:

<group name="web,accesslog,">
   <rule id="31100" level="0">
    <category>web-log</category>
      <description>Access log messages grouped.</description>
   </rule>

Using that information, we can whitelist the scanners for all web-based traffic like so:

<rule id="131100" level="0">
   <if_sid>31100</if_sid>
   <list field="srcip" lookup="address_match_key">lists/approved_scanners_list</list>
   <description>Quiet: Approved security scanners</description>
</rule>

More than one SID group can be referenced in the same rule by separating them with a comma:

<rule id="131100" level="0">
   <!--
      5706    [OSSEC] SSH insecure connection attempt (scan).
      5710    [OSSEC] Attempt to login using a non-existent user
      5712    [OSSEC] SSHD brute force trying to get access to the system.
      31100   web_rules.xml Alerts
   -->
   <if_sid>5706, 5710, 5712, 31100</if_sid>
   <list field="srcip" lookup="address_match_key">lists/approved_scanners_list</list>
   <description>Quiet: Approved security scanners</description>
</rule>

Further Reading

For more information regarding OSSEC reference lists, please see the full OSSEC documentation page.

OSSEC, in general, has been written about rather extensively in the SANS Reading Room, and my paper can be found there as well.