OSSEC – Ryan Schulze

Running an OSSEC server with lots of agents

August 7, 2017August 7, 2017RyanOSSEC

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.

net.core.rmem_max=33554432
net.core.rmem_default=33554432
net.ipv4.udp_mem='192576 256768 385152'
net.core.somaxconn=256
net.core.netdev_max_backlog=2000
net.ipv4.udp_rmem_min=8192

net.core.rmem_max=33554432

net.core.rmem_default=33554432

net.ipv4.udp_mem='192576 256768 385152'

net.core.somaxconn=256

net.core.netdev_max_backlog=2000

net.ipv4.udp_rmem_min=8192

Granular OSSEC Emails

February 25, 2016February 25, 2016RyanOSSEC

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.

<ossec_config>
  <global>
    <email_notification>yes</email_notification>
    <smtp_server>127.0.0.1</smtp_server>
    <email_to>dev-null@email.domain</email_to>
    <email_from>ossec@ossec.server</email_from>
  </global>

  <email_alerts>
    <email_to>ossec-admins@email.domain</email_to>
    <level>7</level>
  </email_alerts>
</ossec_config>

<ossec_config>

<email_notification>yes</email_notification>

<smtp_server>127.0.0.1</smtp_server>

<email_to>dev-null@email.domain</email_to>

<email_from>ossec@ossec.server</email_from>

</global>

<email_alerts>

<email_to>ossec-admins@email.domain</email_to>

</email_alerts>

</ossec_config>

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:

<ossec_config>
  <global>
    <email_notification>yes</email_notification>
    <smtp_server>127.0.0.1</smtp_server>
    <email_to>dev-null@email.domain</email_to>
    <email_from>ossec@ossec.server</email_from>
  </global>

  <alerts>
    <log_alert_level>1</log_alert_level>
    <email_alert_level>7</email_alert_level>
  </alerts>

  <email_alerts>
    <email_to>ossec-admins@email.domain</email_to>
    <level>7</level>
  </email_alerts>

  <email_alerts>
    <email_to>ossec-admins@email.domain</email_to>
    <rule_id>1002</rule_id>
  </email_alerts>

  <email_alerts>
    <email_to>ossec-admins@email.domain</email_to>
    <group>ossec</group>
  </email_alerts>

  <email_alerts>
    <email_to>serverA-admins@email.domain</email_to>
    <group>servergroupA</group>
  </email_alerts>

  <email_alerts>
    <email_to>serverB-admins@email.domain</email_to>
    <group>servergroupB</group>
  </email_alerts>

</ossec_config>

<ossec_config>

<email_notification>yes</email_notification>

<smtp_server>127.0.0.1</smtp_server>

<email_to>dev-null@email.domain</email_to>

<email_from>ossec@ossec.server</email_from>

</global>

<log_alert_level>1</log_alert_level>

<email_alert_level>7</email_alert_level>

</alerts>

<email_alerts>

<email_to>ossec-admins@email.domain</email_to>

</email_alerts>

<email_alerts>

<email_to>ossec-admins@email.domain</email_to>

<rule_id>1002</rule_id>

</email_alerts>

<email_alerts>

<email_to>ossec-admins@email.domain</email_to>

<group>ossec</group>

</email_alerts>

<email_alerts>

<email_to>serverA-admins@email.domain</email_to>

<group>servergroupA</group>

</email_alerts>

<email_alerts>

<email_to>serverB-admins@email.domain</email_to>

<group>servergroupB</group>

</email_alerts>

</ossec_config>

Updated OSSEC Web UI 0.3 files for OSSEC 2.6

June 24, 2012May 13, 2013RyanOSSEC, OSWUI, php, security

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 changed files
Patch download