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.
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
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>
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.
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 ignoredline, 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/7619and7620, 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 againstwazuh-analysisd -t4.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)