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.