Wazuh provides and extremely valuable view into the security health of your systems. However, there are times where the default, out-of-the-box rules don’t work well for you. There’s a nice tutorial on custom rules in the Wazuh documentation, however, it wasn’t apparently clear to me the hierarchical nature of these rules. As a consequence, when you create a custom rule, you might inadvertently cause a logging blindspot.
I’ll use the two below alerts as an example to show this hierarchical nature. As you can see, my test box has two generic detections for a possible trojan in both /bin/kill and /usr/bin/kill. Both of these are known to be false positives, due to the presence of the /tmp string in the binary, which is expected. So, how do I disable this alert, just for these binaries?
Entire Rule Modifications
Let’s say that you have a rule that needs to be entirely updated, perhaps to be muted across the environment. In this case, the instructions on the Wazuh site are perfect. The workflow goes like this:
- Copy rule definition to /var/ossec/etc/rules/local_rules.xml, retaining the Rule ID.
- Update definition of the rule, possibly to change the level.
- Add the tag overwrite=”yes” to save this new configuration.
This activity will effectively nullify the previous rule using that ID. While you “might” want to do this based on your circumstances, you cannot do something like the below as an update operation. The below will entirely overwrite the existing configuration for Rule 510, effectively nullifying it.
Rule Hierarchy and Updates
There is however, a better way to make these sort of additive changes by creating a new rule that inherits the configuration of a previous rule. As shown below, I’m going to create a new Rule with ID 100002, that only applies to alerts that are generated by Source ID 510. It will then run a match validation against by new strings to see if this particular alert should be muted.
To test this theory, I’m only going to mute the alerts for /usr/bin/kill, which should mean that /bin/kill alerts are still delivered. This will prove that Rule ID 510 is still functioning, while also demonstrating that I have successfully muted it on /ust/bin/kill.
As you can see from the logs, that is exactly what happens!
