DEV Community: Nguyen Dong

Wazuh FIM "not detecting" a changed file usually means it has not looked yet

Nguyen Dong — Wed, 07 Oct 2026 03:46:49 +0000

You add a directory to Wazuh file integrity monitoring, change a file, and nothing happens. On Wazuh 4.14.7 the usual reason is the schedule, not a bug. We measured it on a manager container.

The defaults

The <syscheck> block in the 4.14.7 manager image's default ossec.conf:

<frequency>43200</frequency>
<scan_on_start>yes</scan_on_start>
<alert_new_files>yes</alert_new_files>
<directories>/etc,/usr/bin,/usr/sbin</directories>
<directories>/bin,/sbin,/boot</directories>

43200 seconds is 12 hours. No directory has realtime or whodata. So a changed file is reported at the next scheduled scan, up to 12 hours later.

What we measured

Two test directories, one plain and one with realtime="yes", files changed after the first scan:

What we did	Alert
first scan after start, files already present	none: the first scan only records a baseline
changed a file in the plain directory, default 12 h interval, waited 25 s	none
same, with `<frequency>60</frequency>`	rule 550, level 7, mode `scheduled`, after about 64 s
changed a file in the `realtime` directory	rule 550, level 7, mode `realtime`, within seconds
created a new file there	rule 554, level 5, mode `realtime`

How to check in a minute

grep '(6003)' /var/ossec/logs/ossec.log | tail -n 20     # monitored paths and their options
grep -E '\(600[89]\)' /var/ossec/logs/ossec.log | tail -n 4   # last scan start (6008) and end (6009)

If your path's (6003) line does not end in realtime (or whodata), changes wait for the next scan. If the path is not listed at all, it is not monitored.

The fix

Real-time on the paths you would actually act on, on the agent or in the group's agent.conf:

<syscheck>
  <directories realtime="yes" check_all="yes">/etc/nginx,/var/www/app/config</directories>
</syscheck>

After the restart, the (6003) line for that path ends in realtime, followed by (6012): Real-time file integrity monitoring started.

Keep real-time to small, meaningful directories: real-time on large or busy trees is how FIM turns into noise. And when you test, wait for the (6009) scan-ended line before changing a file, because changes before the baseline exists are not alerts.

Limits

Measured on a Wazuh 4.14.7 manager container, with wazuh-syscheckd monitoring its own Linux filesystem; agents use the same module, but we did not run a separate agent. Not measured: whodata, Windows, network shares, inotify limits on very large directories, real-time noise on a busy server.

Full note: https://atkvn.com/fix-wazuh-fim-not-detecting-file-changes.html

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

Sophos Firewall logs and Wazuh: the newer syslog layout matches no decoder

Nguyen Dong — Tue, 06 Oct 2026 05:03:50 +0000

Sophos Firewall can send syslog in two layouts. Wazuh 4.14.7 reads one of them. If your firewall uses the other, the logs arrive and nothing alerts, ever. We measured both, and tested two fixes.

The two layouts

Sophos's own syslog guide documents both. The legacy one, which Sophos calls Device standard:

device="SFW" date=2018-05-30 time=13:14:26 timezone="IST" device_name="XG125w" device_id=SFDemo-763180a log_id=010102600002 log_type="Firewall" log_component="Firewall Rule" log_subtype="Denied" status="Deny" ...

And Central reporting:

device_name="SFW" timestamp="2023-12-11T09:02:50-0500" device_model="SF01V" device_serial_id="SFDemo-c07-gl-vm-01" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" ...

What Wazuh does with each

The stock decoder in ruleset/decoders/0510-sophos_fw_decoders.xml is anchored on the legacy start of line:

<prematch>^device="\w*"\s+date=\d+-\d+-\d+\s+time=</prematch>

We sent a denied-traffic line in each layout over UDP syslog to a Wazuh 4.14.7 manager:

Layout	Result
legacy (`device="SFW" date=…`)	decoded as `sophos-fw` → rule 70021, level 5, Traffic Denied
Central reporting (`device_name="SFW" timestamp=…`)	No decoder matched → generic rule 1002, level 2 → no alert

The stock rules key on the decoded status field, and the Central reporting layout has no status at all; it carries log_subtype instead. So a Central reporting line has neither the decoder nor the field the rules need.

Fix 1: send the legacy layout

If your firewall's syslog server settings let you pick the format, choose the device-standard one and the stock decoder and rules apply unchanged. Check first whether anything else reading the same stream expects the new layout.

Fix 2: decode the Central reporting layout

A parent decoder anchored on the new start of line, then one child per field:

<decoder name="sophos-fw-crf">
  <prematch>^device_name="\S+" timestamp="</prematch>
</decoder>

<decoder name="sophos-fw-crf-fields">
  <parent>sophos-fw-crf</parent>
  <regex type="pcre2">log_type="([^"]*)" log_component="([^"]*)" log_subtype="([^"]*)"</regex>
  <order>log_type, log_component, log_subtype</order>
</decoder>

<decoder name="sophos-fw-crf-fields">
  <parent>sophos-fw-crf</parent>
  <regex type="pcre2">\bsrc_ip="([^"]*)"</regex>
  <order>srcip</order>
</decoder>

(and the same pattern for dst_ip, src_port, dst_port, protocol, fw_rule_id). Rules on log_type = Firewall and log_subtype = Denied / Allowed, plus an 18-in-45-seconds rule with <same_source_ip />.

Writing the address as srcip (the stock decoder uses src_ip) matters: <same_source_ip> and the firewall-drop active response only read srcip.

What we measured with it on 4.14.7:

Sent	Before	After
1 Central reporting denied line	0 alerts	level 5, srcip/dstip/dstport read
the same, 18 times in a few seconds	no alert	17 × level 5, then the level 10 rule
Sophos's own Allowed example	no decoder	level 3
1 legacy denied line	70021	70021, untouched

wazuh-analysisd -t: no warnings.

Limits

Measured on a Wazuh 4.14.7 manager container with syslog over UDP and in wazuh-logtest. We did not run a Sophos Firewall. The Allowed line is Sophos's published example; the Denied lines were written by us in the same layout. The decoder covers firewall-rule events only, not admin login, IPS, web filter or VPN. We have not checked which SFOS release made Central reporting the default, or the exact menu name for the format setting.

The full decoder and rule files, with the one-minute checks: https://atkvn.com/fix-sophos-firewall-logs-not-showing-in-wazuh.html

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

FortiGate denied traffic never reaches the Wazuh dashboard. Rule 81618 is level 1.

Nguyen Dong — Mon, 05 Oct 2026 07:02:34 +0000

FortiGate sends its logs to Wazuh, failed admin logins show up, and denied traffic does not. On Wazuh 4.14.7 that is the stock ruleset working as written. We measured it, plus a second problem that only shows up with CSV syslog.

Setup: FortiOS-style key=value lines sent over UDP syslog to a Wazuh 4.14.7 manager container; we read alerts.json.

Reason 1: every traffic log stops at level 1

In ruleset/rules/0391-fortigate_rules.xml, rule 81618 matches any FortiGate log with type=traffic at level 1. It does not look at action, so denied and allowed sessions land on the same rule. The default <log_alert_level> in ossec.conf is 3, and nothing below it is written to alerts.json. The only traffic rule above the line is 81619, level 3, after 18 traffic events from one source within 45 seconds.

We sent one denied forward session (action="deny", SSH from outside to an internal host) and one Admin login failed event:

Event	Rule	Level	In `alerts.json`?
traffic, `action="deny"`	81618	1	no
admin login failed	81606	4	yes

Reason 2: CSV format corrupts `srcip`

The stock decoder reads key=value pairs separated by spaces. In CSV format the separator is a comma, so the capture for srcip runs to the next space. The same login-failed event in CSV produced an alert whose data.srcip was:

203.0.113.5,dstip=192.168.1.99,action="login",status="failed",...

The rule still fires, but GeoIP, <same_source_ip> correlation and the firewall-drop active response all read that field.

The fix

Send the default format for the syslog server Wazuh listens on:

config log syslogd setting
    set format default
end

Raise denied traffic to an alert in /var/ossec/etc/rules/local_rules.xml:

<group name="local,fortigate,">
  <rule id="100210" level="5">
    <if_sid>81618</if_sid>
    <action>deny</action>
    <description>FortiGate: traffic denied by policy.</description>
    <group>firewall_block,</group>
  </rule>
</group>

On 4.14.7 the same denied line that produced nothing produced a level 5 alert with srcip and dstport intact. Narrow it (interface, port, destination) if an internet-facing firewall makes it too loud.

Use the <action> tag, not <field name="action">. action is a static field. With the <field> form, 4.14.7 logged ERROR: Failure to read rule 100210. Field 'action' is static. and the manager did not start, so there were no alerts at all, not only for FortiGate.

Limits

Measured on a Wazuh 4.14.7 manager container (syslog over UDP 514, and wazuh-logtest). We did not run a FortiGate: the lines were written in the FortiOS key=value layout and converted to CSV by changing the separator. Not measured: cef and rfc5424 formats, UTM/VPN/IPS logs, other versions. The CLI syntax is from Fortinet's config log syslogd setting reference, not run on a device.

Full note with the one-minute checks: https://atkvn.com/fix-fortigate-logs-not-showing-in-wazuh.html

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

A single pfSense block never becomes a Wazuh alert. Here is why, measured.

Nguyen Dong — Sun, 04 Oct 2026 01:08:44 +0000

You point pfSense at Wazuh, the logs arrive, and the dashboard stays empty. Most people assume the integration is broken. On Wazuh 4.14.7 it usually is not: there are two separate reasons, and one of them is by design.

We sent pfSense filterlog lines over UDP syslog to a Wazuh 4.14.7 manager container and read archives.log and alerts.json.

Reason 1: rule 87701 carries `no_log`

The stock pfSense rules live in ruleset/rules/0540-pfsense_rules.xml:

Rule	Level	Matches	Becomes an alert?
87700	0	any `filterlog` event decoded as `pf`	no (level 0)
87701	5	`action` = block	no: it has `<options>no_log</options>`
87702	10	18 × 87701 from one source IP within 45 s	yes

The comment above 87701 says: "We don't log firewall events, because they go to their own log file." Pass events stop at 87700.

What we measured:

One block line over UDP 514: it reached archives.log; alerts.json stayed empty.
18 block lines from one address within the window: the 18th came back as 87702, level 10.

So a working integration shows nothing until one address is blocked 18 times in 45 seconds.

One trap while testing: wazuh-logtest prints "Alert to be generated" for 87701 anyway. Logtest does not apply no_log. Check alerts.json, not logtest.

Reason 2: RFC 5424 lines match no decoder

pfSense can log in BSD (RFC 3164) or RFC 5424 format. The stock decoder is keyed on <program_name>filterlog</program_name>, which Wazuh's pre-decoder reads from a BSD-style header. Over UDP on 4.14.7:

Line sent	Decoder
`Oct 2 15:00:01 pfSense filterlog[12345]: 5,,,1000000103,igb1,match,block,…`	`pf`: srcip, dstip, action read
`2026-10-02T15:00:01.123456+07:00 pfSense.home.arpa filterlog[12345]: …`	`pf`: read
`<134>1 2026-10-02T15:00:01.123456+07:00 pfSense.home.arpa filterlog 12345 - - …`	No decoder matched

With RFC 5424, archives.log even shows the manager's own host name instead of the firewall's: the header was never parsed.

The fix

Send BSD format. In pfSense, Status → System Logs → Settings, set the log message format to BSD (RFC 3164).
Decide which blocks you want as alerts. To alert on every block, overwrite 87701 without no_log in /var/ossec/etc/rules/local_rules.xml:

<group name="local,pfsense,">
  <rule id="87701" level="5" overwrite="yes">
    <if_sid>87700</if_sid>
    <action>block</action>
    <description>pfSense firewall drop event.</description>
    <group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
  </rule>
</group>

On 4.14.7 this loaded with no warnings, and the same single block line that produced nothing produced one 87701 alert. An internet-facing firewall blocks a lot, so many people prefer a narrower child rule (one interface, one port) and leave 87701 alone.

Limits

Measured on a Wazuh 4.14.7 manager container, with syslog over UDP from 127.0.0.1 and in wazuh-logtest. We did not run a pfSense box: the lines were written in the filterlog format for one IPv4 TCP block and one pass. Not measured: IPv6, other pfSense programs, OPNsense, other Wazuh versions.

Full note with the one-minute checks: https://atkvn.com/fix-pfsense-logs-not-showing-in-wazuh.html

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

Wazuh 5.0 will not load your custom XML rules. 82% of one public pack depends on what it drops.

Nguyen Dong — Sat, 03 Oct 2026 08:58:04 +0000

If you run Wazuh 4.x with your own rules and decoders, the 5.0 release changes more than the version number. We read the migration guides that ship with the latest 5.0 pre-release (v5.0.0-beta5) and ran the numbers on a public community ruleset. Here is what applies to custom content, with the source for each point.

What changes

Custom XML files are not loaded at all. From docs/guide/migration/manager-configuration-migration.md at v5.0.0-beta5:

Custom rules and decoders from 4.x cannot be migrated by copying XML files to the manager.

The same table lists <ruleset> as a startup error and says etc/rules/, etc/decoders/ and etc/lists/ "do not exist in 5.0". Decoders become YAML assets run by the new engine; rules become Sigma-style YAML documents stored in the indexer and managed through its content API.

There is no converter. From docs/guide/migration/rules-4x-to-5x.md:

There is no automatic conversion tool. Rules must be manually rewritten following this guide.

The manager migration issue (#39109, closed 28 September) states the scope plainly: "rules, decoders, CDB lists and anything the engine changed structurally" are out of scope, and "the translation is the user's responsibility". The tool merged for it (PR #39197) moves agent keys, groups and API users, not content.

Rules no longer chain. The rules guide marks these as not supported:

4.x	5.0 (per the guide)
`<if_sid>`, `<if_group>`, `<if_level>`	not supported; "rules are self-contained"
`<if_matched_sid>`, `frequency`/`timeframe`, `<same_>`/`<different_>`, `<if_fts>`	not supported in rules; "correlation handled separately"
`<list>` (CDB lookups)	not supported in rules; move to KVDBs at the decoder level
`<time>`, `<weekday>`, `<check_diff>`	not supported
`<options>` (`no_log`, `no_full_log`, …), `<var>`	no direct equivalent

And <match>/<regex> no longer search the raw log: 5.0 rules match fields of the normalized event, with event.original as the fallback.

Decoders lose some elements. The decoder guide lists <plugin_decoder>, <accumulate/>, <fts>, <json_null_field>, <type>, <use_own_name> and the pcre2/offset options as unsupported: 5.0 parses with its own field-extraction language, not regex.

How much of a real ruleset is affected

We took the public SOCFortress Wazuh-Rules set (75 XML files, 2,211 rules, 105 decoders) and counted, rule by rule, the elements the 5.0 guide marks as unsupported:

	Rules	Share
Use rule chaining (`if_sid`, `if_group` or `if_level`)	1,804	82%
Use correlation (`frequency`, `if_matched_`, `same_`)	8	<1%
Use CDB lookups or `check_diff`	3	<1%
None of the above (only a rewrite to the new format)	399	18%

Chaining is how most 4.x content is written: a child rule refines a stock parent. In 5.0 each of those rules has to carry its own full condition, written against normalized field names instead of a parent's decoded fields.

Where things stand

v5.0.0-beta5 (1 September) is the latest 5.0 tag. The 5.0.0 branch already reads "stage": "rc1". No GA date has been announced.
There is no in-place upgrade from a 4.x manager; the configuration guide says 5.0 is a fresh install.
Until you move, 4.x keeps loading XML as before, including its quirks: if you are still writing 4.x rules, check them before restarting (one quirk we measured: wazuh-analysisd shows at most 50 load warnings).

Measure your own

The free checker at https://atkvn.com/wazuh-rule-precheck.html runs in the browser and checks 4.x load problems. The counts above came from the same code with a 5.0 mode that lists, per rule, the elements the 5.0 guide marks as unsupported. If you want that list for your own rules before planning a move, send them and your Wazuh version to the address on the checker page and we will send it back, free.

Limits

Everything about 5.0 here comes from the migration guides at v5.0.0-beta5 and the linked issue and PR, not from running a 5.0 engine. A pre-release can change before GA. The counts are a static reading of the XML.

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

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

Nguyen Dong — Fri, 02 Oct 2026 09:57:22 +0000

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 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.

Three reasons a custom Wazuh rule stays silent after a clean config check, measured on 4.14.7

Nguyen Dong — Thu, 01 Oct 2026 14:59:26 +0000

A custom Wazuh rule that never fires rarely has a broken regex. In our lab the usual story is quieter: wazuh-analysisd -t exits 0, the manager restarts cleanly, and the rule still never produces an alert.

We measured three ways this happens on Wazuh 4.14.7. None of them is visible from the exit code of the config check.

1. Wazuh dropped the rule while loading it

If a rule's if_sid parent does not exist at the moment the rule is read, Wazuh ignores the rule, prints two warnings, and carries on. We wrote up the file-name case in an earlier post: a child of 5715 in 0094-test.xml is dropped, the same rule in 0096-test.xml fires.

This week someone running Wazuh in production described two cases that happen inside a single file, so we measured those too:

<group name="test,">
  <!-- case A: the parent is defined later in the same file -->
  <rule id="999910" level="8">
    <if_sid>999911</if_sid>
    <match>RDTEST_FWD_CHILD</match>
    <description>child, written before its parent</description>
  </rule>
  <rule id="999911" level="3">
    <match>RDTEST_FWD</match>
    <description>parent</description>
  </rule>

  <!-- case B: if_sid points to the rule itself -->
  <rule id="999920" level="8">
    <if_sid>999920</if_sid>
    <match>RDTEST_SELF</match>
    <description>self-reference</description>
  </rule>
</group>

case	`-t` exit	warnings	renamed to `9999_...xml`	logtest and live events
A: parent later in the same file	0	7617 + 7619 for `999910`	same result	only the parent `999911` matched
B: `if_sid` points to itself	0	7617 + 7619 for `999920`	same result	the rule never fired

The warnings for case A, word for word:

WARNING: (7617): Signature ID '999911' was not found and will be ignored in the 'if_sid' option of rule '999910'.
WARNING: (7619): Empty 'if_sid' value. Rule '999910' will be ignored.

The rule count agrees. Our test files held 7 rules in total: the three above and four others that load normally. With them in place the manager logged Total rules enabled: '8468'; after we removed them, '8463'. That is 5 more, not 7: the 2 missing are 999910 and 999920.

Renaming the file so it loads last does not help here, because the problem is not the order between files. Wazuh reads a file top to bottom, so a parent must come before its children in the same file, and a rule cannot be its own parent.

2. A sibling rule takes the event

Rules that hang off the same parent are tried in order of level, highest first. "Hang off" includes more than if_sid: the stock rule 40112 (level 12, failures followed by a success) is attached to 5715 through <if_group>authentication_success</if_group>, a group that 5715 carries. We put one child of the stock sshd rule 5715 in local_rules.xml (<if_sid>5715</if_sid>, <match>Accepted password</match>) and sent two sequences through wazuh-logtest:

S1: one Accepted password line on its own
S2: eight Failed password lines from the same IP within eight seconds, then the same Accepted password line

our rule	`-t`	S1 lands on	S2 lands on
level 9	exit 0, no warnings	ours	`40112` (level 12), ours loses
level 13	exit 0, no warnings	ours	ours

The rule and the parent are the same in both rows. Only the level changed, and that decided who got the event after a burst of failures. -t said nothing in either case, because nothing is wrong with the rule. It loaded, and a sibling won.

3. It passes logtest because logtest saw one line

One line through wazuh-logtest tests a decoder and a match. It does not test what happened before that line. We measured three things a one-line test cannot show.

Counting. A composite rule with <if_matched_sid> and frequency="5" timeframe="60", fed twelve matching events in one logtest session, fired on the 5th and the 10th. The 6th did not fire again: after an alert the count starts from zero. With <same_source_ip/>, events from two IPs alternating fired on the 9th and 10th event, the 5th from each IP. Each IP is counted on its own.

Restarts. Rule changes are usually applied with a manager restart, and a restart resets these counts. With frequency="4" on real log lines read by logcollector: 2 failures, restart, 2 more failures gave no alert. All 4 events reached the manager; the count simply began again after the restart.

Events that never arrive. Logtest only sees what you paste into it. On a real manager, events can be lost before analysis. We flooded one agent with 900,000 lines with its client buffer turned off. 57,047 arrived, and about 94% were lost at the agent, with one warning in the agent's own ossec.log as the only trace. Full write-up.

Check yours

Rules dropped at load, before a restart (read the output, not the exit code):

/var/ossec/bin/wazuh-analysisd -t 2>&1 | grep -E '\((7617|7619)\)'

After a restart, the same warnings are in the manager log:

grep -E '\((7617|7619)\)' /var/ossec/logs/ossec.log

Every rule id in a 7619 line is a rule that is not running.

Siblings that might take your event. Look up the parent's groups, then list the rules attached to the parent by id or by one of those groups, and compare levels:

grep -rn -A8 'id="5715"' /var/ossec/ruleset/rules | grep '<group>'
grep -rnE '<if_sid>([^<]*[ ,])?5715([ ,][^<]*)?</if_sid>|<if_group>authentication_success</if_group>' \
  /var/ossec/ruleset/rules /var/ossec/etc/rules

Replace 5715 and authentication_success with your rule's parent and its groups. On our 4.14.7 lab the second command prints six lines for 5715, including 40112 at line 102 of 0280-attack_rules.xml. A sibling at a higher level that also matches your event will win it.

Sequences, not lines. Paste the real sequence into one wazuh-logtest session (the failures and then the success, or the five events a composite rule needs), not only the last line.

What we did not measure

One version (4.14.7), a single-node manager, and mostly if_sid. Not measured: if_group, decoders, clusters, reloading rules through the API, or how often restarts happen on a real system. The logtest counts in reason 3 come from one session per case. The flood numbers come from one agent reading a file, not syslog over the network.

Free: Rule Doctor Lite, a read-only script that lists the custom rules that never fired and the likely reason. Run after a restart, it reads the 7617/7619 warnings in ossec.log, and on our lab it flagged both in-file cases above.

If a rule loads and never fires and you would rather not dig into it yourself, send us the rule, your Wazuh version and a sample event: we find why, then write and test the fix on that version. USD 490 per rule case, paid only after it runs clean on your side. vct.atkvn.com/#fix-pack

Dong Nguyen, ATK New Technology

Hybrid post-quantum key exchange at the front door went from 50% to 86%. It says nothing about your VPN.

Nguyen Dong — Wed, 30 Sep 2026 13:04:27 +0000

We run a small public index of post-quantum adoption: one TLS 1.3 handshake per host, against the same list of 350 public front doors, repeated over time. Three runs so far, April, May and September 2026.

On the 293 hosts that answered in every run:

	April	May	September
hybrid post-quantum key exchange	50.2%	51.2%	86.0%

105 hosts moved from classical to hybrid (X25519MLKEM768). Across all three runs, zero moved back. Banking moved the furthest of any sector, 28.0% to 94.0% on 50 hosts. A re-run on 14 September reproduced the cohort (293) and the headline (252 of 293) exactly.

That is real movement. It is also a much narrower fact than it sounds.

What the number measures

One handshake, from outside, to one public hostname. It tells you what the internet-facing TLS terminator of that host negotiates today with a client that offers a hybrid group.

What it cannot see

Everything behind that terminator:

VPN. IPsec, OpenVPN and WireGuard tunnels negotiate their own keys. A hybrid front door says nothing about them.
Internal TLS. Service-to-service traffic, load balancer to backend, database connections. Often older libraries, often pinned versions.
SSH. Its key exchange is configured separately on every server.
Signatures and certificates. In a 40-host run on 1 September (16 banks plus internet infrastructure and a control group), 0 of 40 carried a post-quantum signature. That is expected: no public CA can issue one yet. Key exchange is migrating; authentication is not, in any sample we have run.
Code. Hard-coded RSA or ECDH in your own applications doesn't change when a vendor updates a default.
Traffic already recorded. A front door that went hybrid in August protects sessions from August on, not the ones before.

The index says this about itself, and it is worth repeating: a front door isn't an estate, and a vendor default isn't a migration programme. We also do not know what changed over the northern summer, and we don't guess.

What to do with it

If your public front door already negotiates hybrid, good, and that is probably not where your exposure is. The questions that matter are the ones the index cannot answer from outside:

Which of your tunnels, internal links and SSH servers still negotiate classical-only key exchange?
Which data crossing them has to stay confidential for longer than your migration plan takes?
Where is classical crypto hard-coded, so a library update won't fix it?

Those need a look inside the estate: TLS and server configs, SSH, VPN configs, certificates, code, and, if you can share one, a packet capture, which shows exposure per flow rather than per host.

Limits of the numbers above

57 of the 350 hosts did not answer in every run; they are the weakest part of the dataset, and every percentage above is on the 293 that did.
Public front doors only, one handshake per host, no retries. It measures what a host negotiates, not what it could negotiate with a different client.

Two ways we can help. **PQ Front Door Check, free: send one hostname you own and we send back one page on what it negotiates. **PQC Readiness Audit, USD 4,900: the inside view above, across seven surfaces (TLS, server config, SSH, VPN, certificates, code, packet capture), with no agent on your systems. Message Dong Nguyen on LinkedIn.

Dong Nguyen, ATK New Technology

Wazuh loses events three ways under load, and only one of them raises an alert

Nguyen Dong — Mon, 28 Sep 2026 13:01:05 +0000

A question we got on LinkedIn: one Wazuh agent reads the logs of 1,600 firewalls, the dashboard shows gaps, and nothing fired. No rule, no alarm. Is that possible?

It is. We flooded a Wazuh 4.14.7 setup three different ways and counted what arrived, what was dropped, and which of the stock "agent buffer" rules fired.

The stock rules you would expect to fire

In 0016-wazuh_rules.xml (4.14.7), rule 201 is the level 0 parent for wazuh: Agent buffer: messages, with these children:

rule	level	meaning
`202`	7	agent queue is X% full
`203`	9	agent queue is full, events may be lost
`204`	12	agent queue is flooded
`205`	3	back to normal

The default log_alert_level is 3, so all four are high enough to become alerts.

What we measured

Throwaway containers, wazuh-manager:4.14.7 and wazuh-agent:4.14.7 on an internal network, no indexer: we read alerts.json, archives.json, ossec.log and the state files directly. The agent read one syslog-style file with fake lines from 1,600 "firewalls", each tagged so we could count them. A sanity run of 3 lines gave 3 of 3 in both alerts.json and archives.json, so zero below means zero.

case	setup	sent	reached the manager	buffer alerts
1	agent defaults (client buffer on, 500 EPS)	900,000 lines at 10,000/s for 90 s	45,493 (5%)	`202` ×1, `203` ×44, `205` ×1, `204` ×0
2	client buffer disabled	same	57,047 (6.3%)	none
3	manager overloaded (`<limits><eps>` at 100), manager reads the file itself	120,000 at 2,000/s for 60 s	22,391 (18.7%)	none

Case 1 is the only loss path with an alarm. The client buffer drops what exceeds its rate (500 EPS over about 91 seconds matches the 45,493 that arrived), and 203 fires every couple of seconds while it happens. But 204, the level 12 "flooded" rule, did not fire once in 90 seconds of a full buffer.

Case 2 lost 842,953 lines at the agent's internal queue between logcollector and the agent (1,024 entries). The only trace was a single warning in the agent's own ossec.log:

'agent' message queue is full (1024). Log lines may be lost.

Case 3 lost events in two places on the manager: 73,433 in the manager's logcollector and 24,176 in analysisd. The only traces were warnings in the manager's ossec.log ("Input queue is full", "Queues are full and no EPS credits, dropping events") and a non-zero events_dropped in wazuh-analysisd.state.

In all three cases the dashboard looks the same: data thins out and has gaps. Only one of them tells you.

Check yours

On the agents (this is the case with no alert at all):

grep "message queue is full" /var/ossec/logs/ossec.log

On the manager:

grep -E "Input queue is full|dropping events" /var/ossec/logs/ossec.log
grep events_dropped /var/ossec/var/run/wazuh-analysisd.state

In the alerts index, look for rule 203 rather than 204: in our run, 203 is what fired.

What to take from it

Keep the agent's client buffer on. It is the only one of the three paths that raises an alert, and it is on by default; turning it off to "stop the warnings" removes the only alarm.
Do not rely on 204 to tell you an agent is flooded. Alert on 203.
The other two paths are only visible in ossec.log and the state file. If nothing reads those, a busy agent or an overloaded manager loses data in silence.

What we did not measure

One version (4.14.7), one agent, a file read by logcollector. Not measured: agents receiving syslog over the network, the manager receiving syslog directly (<remote>), clusters, other kinds of manager overload (CPU, disk), or the real load of 1,600 firewalls. We do not know which of the three cases the original question was.

Thanks to the Wazuh ambassador whose question on LinkedIn started this.

Free: Rule Doctor Lite, a read-only script that lists the custom rules that never fired and the likely reason, including rules dropped at load. It only sees event loss when 203/204 fired, which above is case 1.

We sell fixes for two silent-loss cases we can test end to end: custom rules that load but never fire, and alerts the indexer rejects. USD 490 per case, paid only after the fix runs clean on your side. vct.atkvn.com/#fix-pack

Dong Nguyen, ATK New Technology

Wazuh custom rule never fires, and analysisd -t still exits 0: the file name decides

Nguyen Dong — Sat, 26 Sep 2026 06:21:21 +0000

You write a child rule for a stock Wazuh rule, drop it into /var/ossec/etc/rules/, and run the config check. wazuh-analysisd -t exits 0. You restart the manager. The rule never fires, and wazuh-logtest shows the event landing on the parent instead.

One common cause has nothing to do with the rule itself. It is the name of the file you put it in.

What we measured

On a throwaway wazuh-manager:4.14.7 container we used one test rule, a child of the stock sshd rule 5715:

<group name="test,">
  <rule id="100080" level="9">
    <if_sid>5715</if_sid>
    <match>Accepted password</match>
    <description>test child of 5715</description>
  </rule>
</group>

5715 lives in /var/ossec/ruleset/rules/0095-sshd_rules.xml. We put the same rule in five differently named files in /var/ossec/etc/rules/, ran wazuh-analysisd -t, restarted, and sent one line through wazuh-logtest:

Sep 26 10:00:00 host1 sshd[1234]: Accepted password for root from 203.0.113.5 port 22 ssh2

file	7617 / 7619 warnings	logtest lands on
`0094-test.xml`	yes	`5715` (our rule ignored)
`0096-test.xml`	no	`100080` (fires)
`local_rules.xml`	no	`100080` (fires)
`0095-aaa.xml`	yes	`5715` (our rule ignored)
`0095-zzz.xml`	no	`100080` (fires)

The two warnings, word for word:

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

What it means

Files in etc/rules are not loaded after the stock ruleset. They are merged with ruleset/rules and loaded in order of the full file name. The last two rows show it: 0095-aaa.xml sorts before 0095-sshd_rules.xml, so when our rule is read, 5715 does not exist yet and the rule is dropped. 0095-zzz.xml sorts after it, and the same rule fires.

local_rules.xml is safe for this reason: letters sort after digits, and all 168 stock rule files in 4.14.7 start with a digit (0010 to 0999), so it loads after every one of them.

The trap is the config check. wazuh-analysisd -t exits 0 in all five cases. It prints the two warnings, but a warning is not a failure, and nothing in a deploy script that checks the exit code will stop. The manager then starts cleanly with one rule fewer than you think.

Check yours in a minute

After a restart, the warnings are also in the manager log:

grep -E '\((7617|7619)\)' /var/ossec/logs/ossec.log

Every rule id you see in a 7619 line is a rule that is not running. The 7617 line on the same second tells you which parent it was waiting for.

Before a restart, run the check yourself and read its output instead of trusting the exit code:

/var/ossec/bin/wazuh-analysisd -t 2>&1 | grep -E '\((7617|7619)\)'

For a single rule, wazuh-logtest with a real sample line is the final word: if the output shows the parent's id and not yours, your rule did not load or did not match.

The fix

Move the child rule into a file whose name sorts after the file that holds its parent:

put it in local_rules.xml, or
give your file a prefix above the parent's file (0096-... or higher for children of sshd rules), or a name that starts with a letter.

To find the parent's file:

grep -l 'id="5715"' /var/ossec/ruleset/rules/*.xml /var/ossec/etc/rules/*.xml

Then run the check again and confirm the 7619 line is gone, and that logtest lands on your rule.

What we did not measure

One Wazuh version (4.14.7), a single manager, one parent rule, and only if_sid. We did not test if_matched_sid, if_group, decoders, or a cluster. If you run a cluster, check the warnings on every node.

Credit to Francisco Sousa, who found the file name half of this in his own container before we did.

If one of your rules loads and never fires and you would rather not dig into it yourself, send us the rule, your Wazuh version and a sample event: we find why, then write and test the fix on that version. USD 490 per rule case, paid only after it runs clean on your side. vct.atkvn.com/#fix-pack

Dong Nguyen, ATK New Technology

Wazuh ms-graph: why Entra ID sign-ins never reach the indexer, and a one-processor fix

Nguyen Dong — Sat, 26 Sep 2026 02:58:36 +0000

You enable the Wazuh ms-graph module for auditLogs/signIns. The module logs clean scans. With wazuh_modules.debug=2 it even logs Sending log: {"integration":"ms-graph", ... "relationship":"signIns"}. And yet there is not a single sign-in in wazuh-alerts-* or wazuh-archives-*.

There are two separate reasons, and on a stock install you hit both.

1. The stock ruleset has no rule for sign-ins

0995-microsoft-graph_rules.xml in 4.14.7 has 99 rules. The parent rule 99500 (level 0) catches every ms-graph event. Its children cover alerts, incidents, audit events, devices, apps and risk detections. None matches relationship: signIns.

So on the stock ruleset a sign-in stops at level 0 and never becomes an alert. It can only reach the indexer through the archives (<logall_json>yes</logall_json>). That is where the second problem waits.

2. The stock template rejects every sign-in

wazuh-template.json applies to both wazuh-alerts-4.x-* and wazuh-archives-4.x-*. It maps two ms-graph fields as keyword:

field	template	alerts_v2 / incidents send	signIns send
`data.ms-graph.status`	`keyword`	a string (`"resolved"`)	an object (`{errorCode, failureReason, additionalDetails}`)
`data.ms-graph.appliedConditionalAccessPolicies`	`keyword`	not sent	a list of objects

A keyword field cannot hold an object, so the indexer rejects the document:

mapper_parsing_exception: failed to parse field [data.ms-graph.status] of type [keyword] ...
caused_by: illegal_state_exception: Can't get text on a START_OBJECT

Three details that make this harder to see than it should be:

It does not depend on which event arrives first. "First shape wins" only holds for unmapped fields. These two are mapped explicitly, so every object-shaped sign-in is rejected, in any order, even if signIns is the only relationship you enabled. We checked the template at tags v4.8.0, v4.10.0, v4.12.0, v4.14.0, v4.14.3 and v4.14.7: the same in all six.
The error names only the first bad field. A sign-in with at least one Conditional Access policy fails on appliedConditionalAccessPolicies. One with an empty policy list fails on status. Fix status alone and the sign-ins that had a policy applied are still rejected.
Nothing on the manager says so. ossec.log is clean and archives.json has the event. The rejection happens inside the indexer, after Filebeat has shipped the event. One of the reporters found nothing in the Filebeat log either.

If the sign-in is missing from archives.json itself, you have a different problem, upstream of the indexer. Look at time_delay first: sign-in records show up in Graph with a delay, and a scan window that closes at "now" can miss them. Issue 39460 in wazuh/wazuh has both problems, one after the other.

Check yours in a minute

On the stock template timing does not matter, so the mapping tells you:

GET wazuh-archives-*,wazuh-alerts-*/_mapping/field/data.ms-graph.status,data.ms-graph.appliedConditionalAccessPolicies

If either field comes back "type": "keyword" and you have signIns enabled, every sign-in that reaches the indexer is rejected: through the archives, or through the alerts index once you add your own sign-in rule.

The fix: one `script` processor, by type

The idea is to leave the string status of alerts and incidents where it is, because dashboards and saved searches on data.ms-graph.status expect that string. Only the sign-in shapes move to new fields. The rules are not affected either way: they run on the manager, before the indexer.

status, when it is an object → data.ms-graph.signInStatus
appliedConditionalAccessPolicies, when it is a list of objects → data.ms-graph.conditionalAccessPolicies

It is one script processor (FIX in the script at the end), right after the json processor, in the alerts and the archives pipeline. Two details matter:

ignore_failure: true. The stock Wazuh pipelines end with on_failure: drop, so a processor that throws does not just skip its own step; the whole event is dropped. With ignore_failure, the worst case is an event indexed unchanged.
d.get('ms-graph'), not ctx.data?.ms-graph. Painless reads the hyphen as a minus sign, the dotted form does not compile, and the indexer refuses the whole pipeline.

The two new fields get a dynamic mapping on first use (signInStatus.errorCode becomes long, the text fields keyword). No template change is needed, and the fix works on today's index too; you do not wait for the next daily index.

The script at the end of this post does this for you, with a backup and a rollback:

export URL=https://<indexer>:9200 AUTH='<user>:<password>'
python3 msgraph_signins_fix.py verify     # 4 test events through your live pipelines
python3 msgraph_signins_fix.py apply      # saves both pipelines to ./backup, installs the processor
python3 msgraph_signins_fix.py verify     # expect 0 problems
python3 msgraph_signins_fix.py rollback   # restores ./backup

What we measured, and what we did not

Measured on a throwaway wazuh-indexer:4.14.7 with the stock template and both stock pipelines, taken from the wazuh-manager:4.14.7 image. We sent Graph v1.0-shaped sign-ins, with and without a Conditional Access policy, plus an alerts_v2 alert, the way Filebeat sends them:

stock: every sign-in rejected, in both pipelines and in both arrival orders; the alert indexes fine
status fixed alone: sign-ins that had a policy applied still rejected, now on the second field
the processor: every sign-in and the alert indexed, in both orders, in a fresh index and in an index that already existed; data.ms-graph.status stays keyword and still aggregates; events without data are untouched
the script: verify 4 errors → apply → verify 0 of 8 (including a non-ms-graph event) → a second apply skips → rollback restores both pipelines byte for byte → verify 4 errors again

Not measured: a real tenant, the Graph beta API (it adds sign-in fields we have not checked against the template), a real Filebeat in the path, and whether the patch survives a restart or upgrade. Two things to check on your side:

If your filebeat.yml sets filebeat.overwrite_pipelines: true, Filebeat reloads the pipeline from disk and the patch has to go into the pipeline file instead.
After a Wazuh upgrade, the pipeline id can change. Run verify again.

And to get sign-in alerts rather than archives only, you still need your own rule on ms-graph.relationship = signIns. The stock ruleset does not ship one.

Credit to the reporters of wazuh/wazuh issues 38330 and 39460: the first described the collision, the second narrowed the loss down to the indexer.

The script

Save it as msgraph_signins_fix.py. Standard library only; it changes nothing but the two pipelines, and verify writes only to indices dated 2099.01.01, then deletes them.

#!/usr/bin/env python3
# Wazuh ms-graph sign-in fix: verify | apply | rollback. ATK New Technology, vct.atkvn.com/#fix-pack
import base64, json, os, ssl, sys, urllib.error, urllib.request

URL, AUTH, BK = os.environ.get("URL", "").rstrip("/"), os.environ.get("AUTH", ""), "backup"
TAG = "ms-graph signIns fix"
SRC = ("def d = ctx.get('data'); if (!(d instanceof Map)) { return; } "
       "def g = d.get('ms-graph'); if (!(g instanceof Map)) { return; } "
       "if (g.get('status') instanceof Map) { g.put('signInStatus', g.remove('status')); } "
       "def p = g.get('appliedConditionalAccessPolicies'); "
       "if (p instanceof List && !p.isEmpty() && p.get(0) instanceof Map) "
       "{ g.put('conditionalAccessPolicies', g.remove('appliedConditionalAccessPolicies')); }")
FIX = {"script": {"lang": "painless", "source": SRC, "ignore_failure": True, "description": TAG}}


def es(method, path, body=None):
    req = urllib.request.Request(URL + path, method=method, headers={"Content-Type": "application/json"},
                                 data=None if body is None else json.dumps(body).encode())
    if AUTH:
        req.add_header("Authorization", "Basic " + base64.b64encode(AUTH.encode()).decode())
    try:  # stock Wazuh indexers use self-signed certificates
        with urllib.request.urlopen(req, context=ssl._create_unverified_context(), timeout=30) as r:
            return r.status, json.loads(r.read() or b"{}")
    except urllib.error.HTTPError as e:
        return e.code, json.loads(e.read() or b"{}")


def pipelines():
    code, allp = es("GET", "/_ingest/pipeline")
    if code != 200:
        sys.exit("cannot list pipelines: HTTP %s" % code)
    out = {}
    for kind in ("alerts", "archives"):
        ids = sorted(p for p in allp if p.startswith("filebeat-") and p.endswith("-wazuh-%s-pipeline" % kind))
        if not ids:
            sys.exit("no filebeat-*-wazuh-%s-pipeline found" % kind)
        out[kind] = (ids[-1], allp[ids[-1]])
    return out


def apply():
    os.makedirs(BK, exist_ok=True)
    for kind, (pid, body) in pipelines().items():
        procs = body["processors"]
        if any(TAG in str(p.get("script", {}).get("description", "")) for p in procs):
            print(kind, pid, "already patched")
            continue
        i = next((i for i, p in enumerate(procs) if "json" in p), None)
        if i is None:
            sys.exit("%s has no json processor" % pid)
        path = os.path.join(BK, pid + ".json")
        if not os.path.exists(path):
            json.dump(body, open(path, "w"))
        code, r = es("PUT", "/_ingest/pipeline/" + pid, dict(body, processors=procs[:i + 1] + [FIX] + procs[i + 1:]))
        print(kind, pid, "HTTP", code, "backup", path)
        if code != 200:
            sys.exit(json.dumps(r)[:300])


def rollback():
    for kind, (pid, _) in pipelines().items():
        path = os.path.join(BK, pid + ".json")
        if os.path.exists(path):
            print(kind, pid, "restored, HTTP", es("PUT", "/_ingest/pipeline/" + pid, json.load(open(path)))[0])
        else:
            print(kind, pid, "no backup, left as is")


def verify():  # writes only to indices dated 2099.01.01, then deletes them
    ms = lambda **m: {"integration": "ms-graph", "ms-graph": m}
    st = {"errorCode": 50126, "failureReason": "Invalid username or password."}
    pol = [{"id": "0", "displayName": "verify", "result": "notApplied"}]
    cases = [("other event", {"srcip": "203.0.113.7"}),
             ("alerts_v2, string status", ms(status="resolved", relationship="alerts_v2")),
             ("signIns + policies", ms(status=st, appliedConditionalAccessPolicies=pol, relationship="signIns")),
             ("signIns, no policies", ms(status=st, appliedConditionalAccessPolicies=[], relationship="signIns"))]
    bad = 0
    for kind, (pid, _) in pipelines().items():
        pre = "wazuh-%s-4.x-" % kind
        for name, data in cases:
            a = {"timestamp": "2099-01-01T00:00:00.000+0000", "rule": {"id": "99500", "level": 0}, "data": data}
            code, r = es("POST", "/%sverify/_doc?pipeline=%s&refresh=true" % (pre, pid),
                         {"message": json.dumps(a), "fields": {"index_prefix": pre}})
            ok = r.get("result") == "created" and r.get("_index", "").endswith("2099.01.01")
            err = r.get("error")
            bad += not ok
            print("%-8s %-26s %s" % (kind, name, "OK" if ok else "ERROR %s" % (
                err.get("reason") if isinstance(err, dict) else r)[:160]))
        es("DELETE", "/%s2099.01.01" % pre)
    print(bad, "problem(s)")
    sys.exit(1 if bad else 0)


if __name__ == "__main__":
    cmd = sys.argv[1] if len(sys.argv) > 1 else ""
    if not URL or cmd not in ("verify", "apply", "rollback"):
        sys.exit("usage: URL=https://<indexer>:9200 AUTH='<user>:<password>' %s verify|apply|rollback" % sys.argv[0])
    globals()[cmd]()

If you would rather not patch this yourself, we write and test the fix for your exact Wazuh version and send you the files: USD 490, paid only after it runs clean on your side. vct.atkvn.com/#fix-pack

Dong Nguyen, ATK New Technology

One field path, two shapes: how Wazuh alerts get dropped with a 400 nobody sees

Nguyen Dong — Thu, 24 Sep 2026 11:12:36 +0000

In the last 24 hours, two people running Wazuh 4.14.7 in production hit the same defect from different directions, and neither of them saw it on a dashboard. They found it by going looking in a log.

The defect is simple to state. The alerts index template gives each field path one type. Some integrations send more than one shape of data under the same path. When an event arrives in the shape the template did not expect, the indexer rejects that document with mapper_parsing_exception, Filebeat gets a 400 back, and a 400 is not the kind of error a shipper retries. The event is gone. Nothing alerts on it, because the thing that would alert is the thing that never got stored.

Three paths so far. data.ms-graph.status is mapped as keyword, and some Microsoft Graph events send an object there. data.office365.ModifiedProperties is also keyword, and some Office 365 events send an object; one operator counted 35 of those in a single Filebeat log. The third runs the other way: an override that mapped data.data as an object then met events that send the string "[]" in the same place.

The useful part is that this is one class of bug, not three. Any path that can carry two shapes will drop the minority shape silently, so the audit is a count of failures by field name, not a hunt for a specific field:

grep -o 'failed to parse field \[[^]]*\]' /var/log/filebeat/filebeat* | sort | uniq -c | sort -rn

An empty result is only meaningful if Filebeat logs at a level that records the rejection, so check that one known-bad event shows up before trusting a zero.

On the fix, put the override in a template of its own with a higher order instead of editing the wazuh template, which the documented upgrade procedure reinstalls. On 4.14.7 two legacy templates with the same pattern merge and the higher order wins the field; that part I measured. Remember a template only applies when an index is created, so today's index keeps the old mapping and keeps dropping until tomorrow's index exists. And before you flip a path from keyword to object, run an exists query on it: every hit is an event that indexed fine as a string, and flipping the type moves the 400s onto those. If both shapes are real, enabled: false accepts both (one of the two operators measured this on status), at the price of not being able to query inside that field.

If you run the grep and get a path that is not on this list, I'd like to hear which one.

DEV Community: Nguyen Dong

Wazuh FIM "not detecting" a changed file usually means it has not looked yet

The defaults

What we measured

How to check in a minute

The fix

Limits

Sophos Firewall logs and Wazuh: the newer syslog layout matches no decoder

The two layouts

What Wazuh does with each

Fix 1: send the legacy layout

Fix 2: decode the Central reporting layout

Limits

FortiGate denied traffic never reaches the Wazuh dashboard. Rule 81618 is level 1.

Reason 1: every traffic log stops at level 1

Reason 2: CSV format corrupts srcip

The fix

Limits

A single pfSense block never becomes a Wazuh alert. Here is why, measured.

Reason 1: rule 87701 carries no_log

Reason 2: RFC 5424 lines match no decoder

The fix

Limits

Wazuh 5.0 will not load your custom XML rules. 82% of one public pack depends on what it drops.

What changes

How much of a real ruleset is affected

Where things stand

Measure your own

Limits

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

The measurement

Where the 50 comes from

On a real ruleset

Why a rule gets ignored in the first place

How to check without trusting the 50 lines

Limits

Three reasons a custom Wazuh rule stays silent after a clean config check, measured on 4.14.7

1. Wazuh dropped the rule while loading it

2. A sibling rule takes the event

3. It passes logtest because logtest saw one line

Check yours

What we did not measure

Hybrid post-quantum key exchange at the front door went from 50% to 86%. It says nothing about your VPN.

What the number measures

What it cannot see

What to do with it

Limits of the numbers above

Wazuh loses events three ways under load, and only one of them raises an alert

The stock rules you would expect to fire

What we measured

Check yours

What to take from it

What we did not measure

Wazuh custom rule never fires, and analysisd -t still exits 0: the file name decides

What we measured

What it means

Check yours in a minute

The fix

What we did not measure

Wazuh ms-graph: why Entra ID sign-ins never reach the indexer, and a one-processor fix

1. The stock ruleset has no rule for sign-ins

2. The stock template rejects every sign-in

Check yours in a minute

The fix: one script processor, by type

What we measured, and what we did not

The script

One field path, two shapes: how Wazuh alerts get dropped with a 400 nobody sees

Reason 2: CSV format corrupts `srcip`

Reason 1: rule 87701 carries `no_log`

The fix: one `script` processor, by type