Tuning OSSEC Email Notifications

One of the common complaints you will encounter while working with Intrusion Detection Systems (IDSs) are about false positives and continuos notifications. OSSEC is no different, despite a global upper rule for email notifications, it continues to bombard emails for events with lower severity ratings.

Although the documentation of OSSEC states this explicitly , it does not mention which exact rules can trigger these email notifications:

“Some rules have an option set to force OSSEC into sending an alert email. This option is <options>alert_by_email</options>. One of these rules is 1002. To ignore these rules you will have to create a rule to specifically ignore it, or overwrite the rule without the alert_by_emailoption.

I sifted through the OSSEC configurations to list out the rules generating email notifications lower than the threshold limit(which is level 7 by default):

If you want to disable the email alerts, you would need to edit one or more of the above rules. I have provided the line numbers so that you can quickly refer them. I had difficulty in embedding the table above so its a screenshot (I did try airtable, but didn’t quite like it to be using here). You can download the .csv files for reference from here —

https://github.com/gravityfuel/ossec-tuning

Let’s take syslog_rules.xml as an example. As per the configuration, this is a level 2 rule and implying that it should not trigger any email notifications for the events if the global configuration for email notifications is set to Level 7 and above. But in reality, this particular rule triggers a lot of notifications if the server is public facing and the corresponding syslog entry contains any of the preconfigured key words:

Rule:

<rule id=”1002" level=”2">

<match>$BAD_WORDS</match>

<options>alert_by_email</options>

<description>Unknown problem somewhere in the system.</description>

</rule>

Trigger Condition:

<var name=”BAD_WORDS”>core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted</var>

Based on your environment, you can tune this further by either deleting some of the bad words or prevent this rule from triggering email alert by adding no_email_alert options

<options>no_email_alert</options>

or by commenting the default rule

<! — <options>alert_by_email</options> →

Once modified, the rule would look something like this:

<rule id=”1002" level=”2">

<match>$BAD_WORDS</match>

<options>no_email_alert</options>

<description>Unknown problem somewhere in the system.</description>

Ofcourse, above is only one of the many ways of minimizing notifications. Do comment on how you deal with incessant and false positive notifications.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.