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.