OSSEC 2.5 was released, and 2.5.1 is almost there

So here is the official release announcement of OSSEC 2.5. There are some neat new features in this version:

1. Added support for “report_changes” on syscheck to show what was changed in the file modification alert.
2. Added support for cdb lists inside the rules.
3. Added support for drop-in rules and decoders directory.
4. Added a Rule unit testing framework (in python) and inside logtest
5. Added support for a generic multi-line log reader.
6. Added granular Windows rules.
7. Added option to restrict integrity checking to a set of files.
8. Added alias option to the command monitoring.
9. Added silent switch for windows installer.
10. Added variable expansion in command output monitoring.
11. Fixed several windows installer bugs.

There are some known bugs in 2.5 that 2.5.1 fixes (including bumping the version number from 2.4.1). OSSEC 2.5.1 is almost released. It's available, but hasn't been signed just yet.
Get the source here: ossec-hids-2.5.1.tar.gz
Windows version here: ossec-win32-2.5.1.exe

I'd recommend using 2.5.1, or waiting for it to be signed and whatnot before upgrading from 2.4.1.

Anyhow, back to the new features list. There are some really great features available in the new version. A few of my favorites are at the top of the list above.

Added support for “report_changes” on syscheck to show what was changed in the file modification alert.

Using the report_changes option gives users something they've been asking for, diffs are now sent along with the alert email for modified text files. I've added the following option to all of my OpenBSD systems:
<directories check_all="yes" report_changes="yes">/etc</directories>

Depending on the system's function, I may also include other directories like "/var/www/conf and "/var/named/etc." It's good to know what has changed, along with the fact that it has changed. I don't seem to get a diff for every change to the file though. I'm not sure why not yet, but I am looking into it.

Added support for cdb lists inside the rules.

This is an awesome feature that I didn't think I'd use as much as I do. CDB lists are a fast, compiled key/value store. I currently have a list of over 100,000 suspicious domains. I want to know when I, or someone else on my network, perform a dns lookup on one of these domains. I can do this in a number of ways, but the easiest is to turn on more logging in named and match domains in the lookups with domains on the list.

I think this required an addition to the named decoders, creating/configuring the list, and creating a rule to utilize the list. My list is simple, the domains are the keys, the values don't matter. It's a simple text file with keys and values separated by a colon (:).

I add the list to ossec.conf with the following in the rules section:

<ossec_config> <!-- rules global entry -->
   <rules>
     <include>rules_config.xml</include>
     ...
     <include>attack_rules.xml</include>
     <include>local_rules.xml</include>
     <list>rules/list/blocked.txt.cdb</list>
   </rules>
</ossec_config> <!-- rules global entry -->

And the rule to do the lookup is pretty simple:
<rule id="510005" level="10">
   <if_sid>12100</if_sid>
   <match>: query: </match>
   <list field="url">rules/list/blocked.txt</list>
   <description>DNS query on a potentially malicious domain.</description>
</rule>


More advanced options are available, and I hope to explain them a bit in the future. I'll include other list ideas when I do.

Added support for drop-in rules and decoders directory.

This is the last new feature I'll comment on right now. Instead of including each rule or decoder file individually in the ossec.conf a whole directory can now be added. You'll have to be careful when using this option, because the order files are added may be important. If a rule in local_rules.xml relies on something in sshd_rules.xml (perhaps the local rule uses an <if_sid>5700</if_sid>), the sshd_rules.xml must be loaded first. I've changed the names for the rule files on my own system. Base rule rules are appended with "10_" at the beginning, rule files that require other rule files to be loaded first are appended with "20_." My local_rules.xml is now 90_local_rules.xml.

Decoders can be loaded in the same way, and I actually change the names in the same way.


<decoder_dir>loadables/decoders</decoder_dir>
<rule_dir pattern="_rules.xml">loadables/rules</rule_dir>

The 2 lines above load all files in /var/ossec/loadables/decoders as decoders, and all files ending in "_rules.xml" in /var/ossec/loadables/rules as rule files.