OSSEC creating ‘ignore’ rules

For automated log monitoring and alerting, several years ago I decided to start using OSSEC. The nice thing about OSSEC is that it is primarily a host-based IDS, but also contains a centralized server for gathering the alerts and doing some smart analysis over them.

It also can provide you with e-mail warnings, for instance when new files are added to the filesystem, such as displayed below (hostnames and IP addresses removed)

OSSEC HIDS Notification.
2019 Jul 05 10:21:14

Received From: (<host>.<domain>) <internal_IP>->syscheck
Rule: 554 fired (level 7) -> "File added to the system."
Portion of the log(s):

New file '/etc/letsencrypt/csr/0113_csr-certbot.pem' added to the file system.

However, since a few months, on regular basis, my file server started complaining about an unexpected disconnect from its controller.

OSSEC HIDS Notification.
2019 Jul 05 07:07:37

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

Jul 5 07:07:35 <host> kernel: [15804505.723965] ata1: SError: { PHYRdyChg 10B8B DevExch }

This was something that eventually led me to replace the entire disk, but still the issue persisted, and started to give several warnings each day, sometimes even multiple per hour. This might be because the controller itself is faulty or just a bug somewhere in the system. However, the system still works without any apparent issues, and in some cases ignorance is bliss. Also, if push comes to shove, I will be able to replace the system in the blink of an eye, so this is a typical warning I do not want to be bothered with. After some online research, I came to a stackoverflow post which provided the answer I was looking for.

The ignore rule

Essentially it comes down to analyzing which rule provides the alerts you want to ignore, Rule 1002 in this case on the syslog ruleset. Next, you need to see if there is anything specific that you want to ignore which has triggered the rule. So first we should analyze rule 1002 in the Syslog ruleset which can be found in /var/ossec/rules/syslog_rules.xml. In this rule we can see that it triggers for specific bad words and, looking back at the alert, we see that the word error is actually part of the provided logline.

<var name="BAD_WORDS">core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted</var>
-----snip------
<rule id="1002" level="2">
<match>$BAD_WORDS</match>
<options>alert_by_email</options>
<description>Unknown problem somewhere in the system.</description>
</rule>
-----snip------

The provided solution on stackoverflow is to write a rule to ignore that a specific part of the logline, which I have narrowed down to the value PHYRdyChg. This can be done by adding the following new rule to /var/ossec/rules/local_rules.xml:

<rule id="100002" level="0">
  <if_sid>1002</if_sid>
  <match>PHYRdyChg</match>
  <description>Ignore PHYRdyChg error.</description>
</rule>

Now that this rule is added, I should no longer get any e-mails about the faulty controller or bug.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.