{"id":408,"date":"2025-03-20T20:56:17","date_gmt":"2025-03-20T20:56:17","guid":{"rendered":"https:\/\/blog.lottabytes.com\/?p=408"},"modified":"2025-03-20T20:56:17","modified_gmt":"2025-03-20T20:56:17","slug":"wazuh-alerts-hierarchy-and-custom-rules","status":"publish","type":"post","link":"https:\/\/blog.lottabytes.com\/index.php\/2025\/03\/20\/wazuh-alerts-hierarchy-and-custom-rules\/","title":{"rendered":"Wazuh Alerts – Hierarchy and Custom Rules"},"content":{"rendered":"\n

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<\/a> 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.<\/p>\n\n\n\n

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<\/em> and \/usr\/bin\/kill<\/em>. 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?<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Entire Rule Modifications<\/h2>\n\n\n\n

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<\/a> on the Wazuh site are perfect. The workflow goes like this:<\/p>\n\n\n\n