The tl;dr of this article is: It shows how to configure OSSEC, a host-based intrusion detection system, to not send email alerts whenever IPTables rejects or denies a traffic source.

The more detailed form follows.

So I use OSSEC to monitor and protect my cloud servers, which gives me a lot of confidence because OSSEC keeps me informed about what’s hitting my servers and what’s happening inside them.

In my setup, keeps me informed means that OSSEC sends me email alerts whenever something it’s been configured to monitor is triggered. And because I have active response enabled, with IPTables as the firewall application, OSSEC, by default, sends out alerts whenever IPTables denies a traffic source.

The content of such alerts, which are OSSEC level 2 alerts, take this form:


OSSEC HIDS Notification.
2015 Feb 26 20:33:35

Received From: container->/var/log/syslog
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Feb 26 20:33:34 container kernel: [455208.047536] iptables denied: IN=eth0 OUT= MAC=04:01:3f:81:38:01:.....:08:30:08:00 SRC=111.111.111.111 DST=222.222.222.222 LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=54321 PROTO=TCP SPT=51660 DPT=11211 WINDOW=65535 RES=0x00 SYN URGP=0

 --END OF NOTIFICATION

That, in a nut shell, is OSSEC informing me that the firewall denied a (potentially) bad guy. The problem: There can be at least a hundred of such alerts daily. And that’s from one server. From more than one server, it can get overwhelming. If I were using a web interface to manage the alerts, there’d be nothing to worry about, but I’m not.

Ideally in OSSEC, a rule like 1002, which has a level set to 2, will not result in an email alert being sent. That’s because of this default settings in ossec.conf, OSSEC’s configuration file. 



    1
    7

email_alert_level is the “inimum alert level to send e-mail notifications”. However, rule 1002 has an email alert override in its definition, which goes like this: 


    $BAD_WORDS
    alert_by_email
    Unknown problem somewhere in the system.

So because of the alert_by_email option, OSSEC will alert when rule 1002 is triggered, even though its level is lower than the default email alert level. In its rule definition, $BAD_WORDS is a variable which contains this listing:



core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted

The presence of denied in that variable is the reason OSSEC sends an alert when IPTables denies a traffic source with bad intentions. There are more than one solution to prevent OSSEC from alerting on IPTables denied messages but the best (I think) is to create a rule based on 1002 that does not send email alerts on such messages.

And here’s how it’s done: Define a custom rule that overrides part of rule 1002 that’s of interest.

In OSSEC, custom rules are defined in local_rules.xml (in /var/ossec/rules directory). So the plan is to create a variable in that file that contains the word(s) that I want to pass to my custom rule. Here’s the variable definition.


denied

Yep, just one word. And the custom rule it’s used in is:


        1002
        $IGNORED_WORD
        Ignored IPTables deny messages.

After the variable and the custom rule are in place, a restart of OSSEC is, of course, required. Once that final step of the process is completed, no more level 2 alerts related to IPTables denied messages.