DEV Community

Nguyen Dong
Nguyen Dong

Posted on

wazuh-analysisd shows at most 50 load warnings. The rest of your ignored rules are silent.

If you load a large set of custom Wazuh rules, wazuh-analysisd -t and ossec.log can tell you that some of them will be ignored. What they don't tell you is that they stop counting at 50 messages. On Wazuh 4.14.7, anything beyond that is dropped, oldest first, with no line anywhere.

We measured it, found where it comes from in the source, and checked a public community ruleset.

The measurement

One file, etc/rules/local_rules.xml, with 60 rules. Each one has an if_sid pointing at an ID that does not exist, so Wazuh must ignore all 60. Each ignored rule produces two warnings:

WARNING: (7617): Signature ID '990000' was not found and will be ignored in the 'if_sid' option of rule '100800'.
WARNING: (7619): Empty 'if_sid' value. Rule '100800' will be ignored.
Enter fullscreen mode Exit fullscreen mode

That is 120 warnings. Here is what Wazuh 4.14.7 actually printed:

Where Warnings printed Rules named Rules never mentioned
wazuh-analysisd -t 50 (25 × 7617, 25 × 7619) 100835 to 100859 100800 to 100834 (35 rules)
ossec.log at a real start starts at 100835 100835 to 100859 100800 to 100834

The last 25 rules are reported. The first 35 are ignored exactly the same way, and nothing says so.

Where the 50 comes from

In the 4.14.7 source, the load messages go into a list created with a size limit:

// src/analysisd/logmsg.h
#define ERRORLIST_MAXSIZE   50 ///< Max size of log messages list
Enter fullscreen mode Exit fullscreen mode

analysisd.c and testrule.c call OSList_SetMaxSize(list_msg, ERRORLIST_MAXSIZE), and OSList_AddData in src/shared/list_op.c removes the first node when the list grows past its maximum. So the list keeps the newest 50 messages and silently drops the rest.

That design is reasonable for a log. It is a problem when the log is the only place you learn that a rule you wrote will never fire.

On a real ruleset

We loaded the public SOCFortress Wazuh-Rules set (69 rule files, 6 decoder files) into a clean 4.14.7 manager. wazuh-analysisd -t printed 52 warnings about ignored rules (50 × 7610 for a missing if_group, one 7617/7619 pair). A static check of the same files found 55. The three extra rules, 900123 to 900125, have the same missing if_group as the 50 that were reported. They fell off the front of the list.

Why a rule gets ignored in the first place

Missing parents are not only typos. Wazuh loads the stock rule files and your files from etc/rules together, sorted by file name, and a rule's if_sid must already be loaded when the rule is read. So this file:

<!-- etc/rules/0010-my_rules.xml -->
<group name="local,">
  <rule id="100714" level="9">
    <if_sid>5715</if_sid>
    <match>Accepted</match>
    <description>...</description>
  </rule>
</group>
Enter fullscreen mode Exit fullscreen mode

is ignored on 4.14.7, because 0010-my_rules.xml sorts before 0095-sshd_rules.xml, where 5715 lives:

WARNING: (7617): Signature ID '5715' was not found and will be ignored in the 'if_sid' option of rule '100714'.
WARNING: (7619): Empty 'if_sid' value. Rule '100714' will be ignored.
Enter fullscreen mode Exit fullscreen mode

wazuh-analysisd -t still exits 0. The manager starts. The rule never fires. Rename the file to something that sorts after the parent (local_rules.xml does) and it loads. The same applies inside one file: a child above its parent is ignored.

How to check without trusting the 50 lines

  • Check in small batches. Test one custom file at a time with wazuh-analysisd -t, so no single run produces more than 50 messages.
  • Count, don't scan. For each custom rule ID you expect, confirm it is not named in a will be ignored line, and treat a run that printed exactly 50 load warnings as incomplete.
  • Check statically before you restart. We built a free checker that runs in the browser and reports every predicted 7610, 7612, 7613, 7617/7619 and 7620, plus the mistakes that stop the manager (static fields used as <field name="srcip">, broken XML, missing decoder parents). It was calibrated case by case against wazuh-analysisd -t 4.14.7 (15 of 15) and does not upload anything: https://atkvn.com/wazuh-rule-precheck.html

Limits

Measured on Wazuh 4.14.7 manager containers. We did not test other versions. The checker only sees the files you give it and the stock 4.14.7 ruleset; it does not run your rules against events.

Dong Nguyen, ATK New Technology. We check and fix Wazuh rules for people who run it.

Top comments (0)