Running an OSSEC server with lots of agents

The default maximum amount of agents an OSSEC server supports is 256. That’s not very much. In order to increase that number, you need to recompile the source code. Instructions for that are in the official documentation

Depending on the defaults of your Linux Distribution, you may start noticing dropped UDP packets (depending on the amount of agents connecting and how much data they are sending to the server). An easy way to check is with  cat /proc/net/snmp | grep Udp\:|column -t  (check if RcvbufErrors or InErrors are increasing).

The following tweaks to the incoming network buffers resolved the situation for me, and can be a good starting point if you are having similar problems and looking at which settings to tweak. Focus on the rmem  buffers first.

 

Granular OSSEC Emails

Occasionally I see questions on the OSSEC mailing list on how to send a bunch of alerts only to a specific email address. An example for a typical use case would be different departments responsible for different groups of servers and having alerts only go to them. OSSEC has a few options for sending Alerts to specific email addresses, but it only adds those email addresses to the alert (meaning it always goes to the global email address). Sometimes this isn’t desirable.

A workaround is setting the global email recipient to a blackhole email address (something that is aliased to /dev/null on the mail server) and only using the granular settings for delivering mail.

You can then use attributes like the rule ID, group names, or event locations to split up alerts to different recipients. The downside is that by doing this, you will miss alerts with  <options>alert_by_email</options> and a low level, unless you add a few granular email alerts. Rule 1002 (catch-all $BAD_WORDS) is a good candidate you will want to keep on receiving. Rules 501-504 (OSSEC agent/master status alerts) could also be interesting; either add an <email_alert>  for each rule individually, or overwrite the rules adding  <group>ossec,</group> to then, so you can add one <email_alert>  for the group of rules.

We use this system pretty extensively assigning alerts to email groups by <event_location>  and/or <group>

An example for the email block could look like this:

 

Updated OSSEC Web UI 0.3 files for OSSEC 2.6

OSSEC is an open source HIDS (Host-based Intrusion Detection System), and a pretty darn good one too. It also has a simple web front-end to view what’s going on, search through alerts and stuff like that  (called OSSEC Web UI, I’ll just call it “WUI” here). Unfortunately the code is a bit outdated (the last official update was from 2008 as far as I can tell) and it doesn’t support newer features of OSSEC like polling data from a database. Something I’d like to tackle if I find the time 😉

The latest version of OSSEC is 2.6, and due to some small changes to the format of the logs WUI no longer works out-of-the-box. I had a look at the code this weekend and am providing patches and downloads of the files needed to change to get everything running again with OSSEC 2.6.

List of changes:

  • Works with the OSSEC 2.6 alert log file format
  • Changed Rule ID Link to better work with the new documentation wiki
  • Added “user” field to alert output
  • Widened the layout by a few pixels (to 1000px) and changed the CSS / alert layout to make the individual alerts better readable
  • Moved some of the hardcoded formatting to CSS

Download Download changed files
Download Patch download