Immutable Security

Are you an OSSEC ninja? Do you dress in orange and red and laugh maniacally at all of the frustrated attackers who have tried to take you down? Do you take medication for that condition? Ok, well, best of luck to you. Back to the topic at hand.

Here are some of my favorite tips and tricks. They promise to elevate you to the next level of OSSEC guru-ness, or maybe they’ll just help you solve a problem. Either way, in no particular order of importance:

1. Log everything. If you have the space, I highly recommend that you add the <logall>yes</logall> element to ossec.conf. After restarting OSSEC, all events will be written to logs/archives/archives.log. By default, OSSEC will discard something that doesn’t match a rule, but if you are ever compromised you really should have all logs to examine.
2. No decoder necessary. Do you need to match on specific text in an unsupported application? While decoders definitely extend the functionality of OSSEC, they are not strictly necessary to get an alert. You can simply create a rule using a simple match. For example: <match>hax0r logged in</match>.
3. Find all alerts above a specific level. I’m stealing this one from a past ossec-users list post of mine. If you have ever wanted to get a list of alerts above a certain level from your alerts log, this will do it. In this example, we look for anything above level 12:

grep -E -B2 -A3 ‘^Rule: [0-9]{1,6} \(level 1[2345]\) -> ‘.*’$’ logs/alerts/alerts.log \

| sed ‘s/^–$/ /’

4. Use OSSEC to monitor OSSEC. Oddly, OSSEC does not monitor itself out of the box. It’s a good idea to monitor your OSSEC instance, if for no other reason than to be confident that you or a trusted colleague are the only ones making production changes. Add this to your ossec.conf (watch for wrapping):

<directories check_all=”yes” realtime=”yes” report_changes=”yes”>/var/ossec</directories>

Now, because certain directories change frequently, you’ll need some exclusions:

<ignore>/var/ossec/queue</ignore>
<ignore>/var/ossec/logs</ignore>
<ignore>/var/ossec/stats</ignore>
<ignore>/var/ossec/var</ignore>

Finally, you’ll want to be careful about the alerts that you receive. One file that is monitored by this is client.keys, which contains, well, your keys. It’s not really a good idea to have OSSEC email you the diff of this file, so I would recommend creating a rule at level 0 to filter it out.

5. Manage centrally. Having only a few agents, it’s not that big of a deal to configure settings locally. When you get into the hundreds or thousands, it becomes very onerous. OSSEC has the ability to centrally manage your agent settings and I highly recommend that you use it. With this feature, all you need in your agent ossec.conf is the destination IP or hostname of the manager. I also like to enable active response locally in the Windows ossec.onf file because it uses active response to restart the agent–which, in turn, can be used to read the new agent.conf.

If you comb through the source code, you might also be able to find some other nuggets worth having. What have you discovered?