DEV Community: Nguyen Dong

What tells you a Wazuh rule has gone quiet?

Nguyen Dong — Fri, 06 Nov 2026 03:30:01 +0000

What tells you a Wazuh rule has gone quiet?

An MSSP detection lead described a gap to us this week. Use cases are validated before go-live and re-tested by a BAS tool every six months. In between, a log source changes. A parser update renames a field, or someone switches off command-line auditing on a group of Windows hosts, and a production rule stops firing. Nothing reports an error.

We measured what that looks like on a Wazuh 4.14.7 manager, and what can tell you it happened. Everything ran in disposable Docker containers with no network. Each claim is tagged [MEASURED] (we ran it, raw output kept) or [NOT MEASURED].

Setup, and a first surprise

We pushed Windows events into wazuh-analysisd's input queue the way the agent forwards them: JSON whose Event key holds the EventChannel XML, which the windows_eventchannel decoder consumes.

Our first try was wazuh-logtest -l EventChannel. [MEASURED] For the same 4688 event, logtest reported decoder json, and no rule matched in Phase 3. The Windows chain starts at rule 60000, which requires decoded_as windows_eventchannel. If your pre-go-live check for Windows rules is "paste it into logtest", it may test nothing.

Test 1: the command line disappears

This is a lab use case. It flags PowerShell started with -EncodedCommand, keyed on the 4688 command line. The payload in our events is the harmless placeholder ATK_LAB_HARMLESS_PLACEHOLDER_0000.

<rule id="100200" level="10">
  <if_sid>67027</if_sid>
  <field name="win.eventdata.newProcessName" type="pcre2">(?i)\\powershell\.exe$</field>
  <field name="win.eventdata.commandLine" type="pcre2">(?i)\s-EncodedCommand\s</field>
  <description>UC-PS-ENC: PowerShell started with -EncodedCommand (lab use case)</description>
</rule>

(The parent is 67027 on purpose: it is already a child of 60103 and loads first, so a sibling under 60103 would never be evaluated.)

We replayed the same event three ways. First with CommandLine. Then with the element missing. Then with it present but empty, which is what you see when "Include command line in process creation events" is off.

Event	Rule that fired	Level
with `CommandLine`	100200	10
`CommandLine` missing	67027 "A process was created."	3
`CommandLine` empty	67027	3

[MEASURED] wazuh-analysisd -t exited 0. Each of the three replays added 0 lines to ossec.log. The decoder drops the empty field rather than keeping an empty string: 13 eventdata fields with the command line, 12 for both other variants. Downstream, "auditing off" and "field never sent" look the same.

The event still produces an alert, just a level 3 one, so a dashboard counting Windows events sees no dip.

Test 2: a parser update renames a field

This is a custom decoder and rule for a simple app log. The "parser update" changes one word:

-  <order>app.user, srcip</order>
+  <order>app.username, srcip</order>

The rule keys on <field name="app.user">^svc_lab_backup$</field> under a level-0 grouping rule 100299. We replayed the same 3 lines before and after the change.

[MEASURED]

Decoder v1: 3 of 3 lines raised rule 100300, and wazuh-analysisd -t exited 0.
Decoder v2: 0 of 3 lines raised an alert, and wazuh-analysisd -t still exited 0. All 3 events were still decoded by labapp and reached the archives. wazuh-logtest showed rule 100299 at level 0.
wazuh-analysisd logged 0 warnings or errors after either restart.

The log was not quiet, though: [MEASURED] the v1 restart wrote 18 WARNING/ERROR lines, all about our container having no network. A real ossec.log has noise; a rule that matches nothing adds none.

So neither the config check nor ossec.log tells you. Here are two things that can.

Option A: compare today's count with the rule's own baseline

We indexed synthetic alerts into the wazuh-indexer:4.14.7 image. It contains OpenSearch with plugin version 2.19.5, and we ran it with the security plugin disabled. [MEASURED] We loaded 381 alerts over 8 days for 3 rule IDs. 100300 went from a daily 34, 34, 49, 33, 43, 49, 50 to 0 on the last day.

The obvious query, "alerts per rule today", returns only rule 100200 [MEASURED]. The silent rule is not a zero row. It is simply absent. You have to ask over a window where the rule still exists:

{"size": 0,
 "query": {"range": {"timestamp": {"gte": "2026-10-29T00:00:00Z", "lt": "2026-11-06T00:00:00Z"}}},
 "aggs": {"by_rule": {"terms": {"field": "rule.id", "size": 1000},
   "aggs": {
     "today": {"filter": {"range": {"timestamp": {"gte": "2026-11-05T00:00:00Z", "lt": "2026-11-06T00:00:00Z"}}}},
     "baseline": {"filter": {"range": {"timestamp": {"gte": "2026-10-29T00:00:00Z", "lt": "2026-11-05T00:00:00Z"}}},
       "aggs": {
         "per_day": {"date_histogram": {"field": "timestamp", "calendar_interval": "1d", "time_zone": "UTC",
             "min_doc_count": 0,
             "extended_bounds": {"min": "2026-10-29T00:00:00Z", "max": "2026-11-04T00:00:00Z"}}},
         "median_per_day": {"percentiles_bucket": {"buckets_path": "per_day>_count", "percents": [50]}}}},
     "gone_quiet": {"bucket_selector": {
         "buckets_path": {"today": "today>_count", "median": "baseline>median_per_day[50.0]"},
         "script": "params.today == 0 && params.median >= 5"}}
   }}}}

The dates are the ones from our lab. To run it on your own indexer, change all four date ranges: the outer range to your last 8 days, today to the current day, and both baseline and the histogram's extended_bounds to the 7 days before it. Miss extended_bounds and the median can drop to 0, so a silent rule is not flagged. Run it against your alerts index (wazuh-alerts-* by default).

[MEASURED] Output: exactly one bucket, 100300 with today 0 and median 43.0. The query took 14 ms. Rule 100200 (today 10, median 11) was not flagged. Neither was the rare rule 100401, whose median is 0. We also wrapped the query in an Alerting plugin query monitor and ran _execute?dryrun=true: it triggered and listed [100300].

Two honest notes. We needed 3 failed attempts to get here [MEASURED]: Painless rejected Arrays.copyOf, then moving_fn plus bucket_selector inside the date_histogram returned no buckets with either gap policy. And the median >= 5 floor that keeps rare rules from paging you also means this method cannot watch rare rules, often the ones that matter most.

Option B: a heartbeat per use case

[NOT MEASURED, documented] Wazuh 4.x rules cannot fire on the absence of an event. The rules XML reference gives frequency as "Any number from 2 to 9999": it counts up, and we found no option that fires when a count stays below a threshold. So the "missing" logic lives outside the rule engine and comes back in as a normal log line.

Three pieces, all in our container [MEASURED]:

A heartbeat writes one harmless canary line every 60 s into the same file, through the same decoder and rule. On a real estate this belongs on the log source, as a cron job or systemd timer.

   echo "$(date '+%b %e %H:%M:%S') lab-srv01 labapp[4242]: login_failed user=svc_lab_backup src=192.0.2.250" >> /var/log/labapp.log

A child rule turns the canary into a low-level heartbeat alert:

   <rule id="100301" level="3">
     <if_sid>100300</if_sid>
     <srcip>192.0.2.250</srcip>
     <description>UC-SVC-LOGIN heartbeat: use case still fires</description>
   </rule>

A watchdog runs every 60 s as a wodle name="command". It finds the newest 100301 in alerts.json and writes OK or MISSING to a log that Wazuh reads. Rule 100310 (level 12) alerts on MISSING. The threshold is 180 s.

The timeline we recorded [MEASURED]:

Healthy: the watchdog reported heartbeat ages of 57, 59 and 59 s.
09:39:29 UTC: we deployed decoder v2. wazuh-analysisd -t returned 0, and analysisd logged 0 warnings.
The canary kept arriving and kept being decoded, 5 times, but raised nothing. The watchdog still said OK at ages 26, 86 and 146 s.
The first MISSING line came at age 206 s. Rule 100310 fired 180.0 s after the first canary that no longer matched.

One false alarm [MEASURED]: on startup the watchdog ran before the first heartbeat arrived and raised 100310 with last_seen=never. Give it a grace period.

The same failure mode in Wazuh 5.0

We published the upgrade version of this problem on our Wazuh 5.0 Migration page. [NOT MEASURED today, quoted] "Our 4.x local_rules.xml and local_decoder.xml, dropped into etc/rules and etc/decoders: of the new log lines after restart (124 on rc1, 116 on rc2), not one mentioned them, and the config check still returned success." The cause is different, since 5.0 replaces the rule engine rather than changing a log source. The symptom is the same: success from the config check, silence from the rule. The baseline and heartbeat checks above look at output rather than configuration, so they should catch both. We have not run them on 5.0.

What we did not test

Real Windows hosts or a real agent: our 4688 events were hand-built XML in the agent's forwarding format. Side observation: our own malformed test events (double-quoted XML attributes) warned twice, and five more decoded with zero eventdata fields and no warning.
Sysmon EID 1. We used Security 4688 only.
A real BAS tool, or a production-sized index. The baseline ran on 381 synthetic alerts.
A watchdog querying the indexer instead of alerts.json, or a cluster.
Seasonality: weekends and maintenance windows will break a plain 7-day median.
Wazuh 5.0 for either option.

Neither option proves a use case catches the attack it was written for. They answer something smaller and more urgent: does the rule still fire at all?

If you want a second pair of eyes, run the query without the gone_quiet block, so it returns every rule rather than only the silent ones, and send the output to support@atkvn.com: rule IDs and daily counts only, no hostnames, no logs. We reply within 24 hours, at no charge, with the rules that look silent or are dropping sharply, and the causes worth checking first, and delete the table once we have answered.

Wazuh snort decoder cuts the last octet off srcip and dstip (4.14.x)

Nguyen Dong — Thu, 05 Nov 2026 07:07:13 +0000

If a snort alert has no source port, Wazuh 4.14.x stores srcip without its last octet: 10.4.12.26 becomes 10.4.12. When the destination has a port, the port stays glued to dstip. Anything keyed on those fields, such as active response, CDB lists or correlation by IP, then works on the wrong value.

Everything below was measured with wazuh-logtest on wazuh-manager 4.14.9, syslog snort: form only. The problem is tracked upstream as #39989, with a fix in #40521 for 4.14.11.

Check it in one minute

Paste a snort line into wazuh-logtest and read the decoding phase. Take the samples below, without the syslog prefix, starting at the priority. For the first one, {ICMP} 10.4.12.26 -> 10.4.10.231, stock 4.14.9 gives srcip 10.4.12; with the merged fix from #40521, srcip is right but dstip becomes 10.4.10. (with a trailing dot).

Why it happens

Stock is ruleset/decoders/0285-snort_decoders.xml as shipped in 4.14.9. Its snort2 decoder has three regex lines that capture the source and destination addresses, and those are the lines the fix below changes.

We ran eight samples through three decoders: the stock file, the three regex lines from PR #40521 (merged for 4.14.11, not released), and the same lines with one more change, shown below.

Sample (after the priority)	Stock 4.14.9	Merged fix	With the change below
`{ICMP} 10.4.12.26 -> 10.4.10.231`	srcip 10.4.12	dstip 10.4.10.	both correct
`{TCP} 10.4.12.26:37020 -> 10.4.10.231:162`	dstip 10.4.10.231:162	correct	correct
`{UDP} 192.168.20.32 -> 192.168.20.2`	srcip 192.168.20	correct	correct
`{TCP} 10.4.12.26:5000 -> 10.4.10.7`	correct	correct	correct
`{UDP} 10.4.12.26 -> 10.4.10.7:53`	srcip 10.4.12, dstip 10.4.10.7:53	correct	correct
`{ICMP} 203.113.100.250 -> 198.51.100.200`	srcip 203.113.100	dstip 198.51.100.	correct
`{TCP} 203.113.100.250:44321 -> 198.51.100.200:443`	dstip 198.51.100.200:443	correct	correct
`[**]` multi-line form from the file header	no fields	no fields	no fields

The merged fix still loses the last octet of dstip when there is no destination port and that octet has three digits. We reported that measurement on the PR before 4.14.11 ships: https://github.com/wazuh/wazuh/pull/40521#issuecomment-6343969794 The [**] form is assembled by the snort-full reader across several lines, which a single logtest line does not reproduce, so it is out of scope here.

Fix on 4.14.x today

Copy the stock file and change its three regex lines in the snort2 decoder to:

<regex>^[**] [(\d+:\d+:\d+)] \.+ (\d+.\d+.\d+.\d+)\p*\d* -> </regex>
<regex>(\d+.\d+.\d+.\d+)\p*\d*|^[(\d+:\d+:\d+)] \.+ </regex>
<regex>(\d+.\d+.\d+.\d+)\p*\d* -> (\d+.\d+.\d+.\d+)</regex>

Save it as /var/ossec/etc/decoders/0285-snort_decoders-fixed.xml, owner wazuh:wazuh.

Then, in /var/ossec/etc/ossec.conf, inside the ruleset block, stop the stock file from loading so the two copies do not compete:

<decoder_exclude>ruleset/decoders/0285-snort_decoders.xml</decoder_exclude>

Restart the manager. A new wazuh-logtest session picks the change up without a restart, so you can check first; live analysis needs the restart.

Confirm it worked

Run the same eight lines again and compare with the last column of the table: srcip and dstip should be whole addresses, with the port gone from dstip.

After upgrading to 4.14.11 or later, remove both the local file and the exclude line, and re-run your samples. The shipped decoder may or may not include the dstip change above.

Limits of what we measured

Measured with the logtest engine on 4.14.9, syslog snort: form only. Your snort output may differ (unified2 via barnyard, alert_fast, IPv6), so run your own lines before you rely on it.

Full write-up with the lab output: https://atkvn.com/fix-wazuh-snort-srcip-truncated-last-octet.html

Wazuh 5.0 rc2: eight things that still change for your 4.x custom rules

Nguyen Dong — Wed, 04 Nov 2026 07:06:04 +0000

Wazuh 5.0.0-rc2 was published on 30 October 2026. If you maintain custom 4.x rules and decoders, the question is whether anything we measured on rc1 moved. We re-ran all eight of those checks on rc2 in a lab with Docker, one manager, one indexer and one 4.14.7 agent. All eight came out the same. GA has not been released, so treat this as a release candidate and not a verdict.

1. The analysis binary has no 4.x rule keywords

We counted occurrences of if_sid, if_matched_sid, same_srcip and frequency in the rc2 wazuh-manager-analysisd binary with grep -a -o piped to wc -l. All four were 0. We also searched the rest of the rc2 bin and lib directories: if_sid, if_matched_sid and same_srcip appear in no file. The 4.14.7 binary contains all of them. We are not quoting its exact counts, because our counting method was not the same across runs.

2. Your XML files load without a word

We dropped 4.x rule, decoder and list XML into both the old etc directories and the new /etc/wazuh-manager, then restarted. The restart produced 116 new log lines (124 on rc1). Zero of them mentioned rules, decoders, lists or xml. wazuh-manager-analysisd -t returned 0 and wazuh-manager-conf validate returned 0. A passing config check does not tell you the rules are doing anything.

3. srcip is rejected as a field

Posting content that uses srcip to the content manager rules endpoint returned HTTP 400: "Error in Security Analytics. The following fields are not part of the Wazuh Common Schema (WCS): [srcip]". Same body, same message as rc1.

4. Unparsed lines are not indexed by default

index_unclassified_events is false in all four spaces (standard, custom, draft, test). We sent 16 log lines: 12 documents were indexed, and the 4 lines from our home-made app, which had no rewritten decoder, were in no index. On rc1 it was also 4 of 16.

5. Indexer flush is 20 seconds

From the binary, the default analysisd.indexer_flush_interval is 20 s, allowed range 1 to 3600. Measured delay from event to visible document was at most 20.2 s, with the sawtooth about 20 s apart. Setting it to 0 is now refused at config load ("Allowed range: 1 to 3600"), and afterwards the manager still listed analysisd as running; on rc1 the same setting stopped analysisd. The "5 s flush gives 7.1 s worst case" figure is from rc1 only. We did not re-run it on rc2.

6. Active response does not reach a 4.14.7 agent

A 4.14.7 agent enrolled and its events were indexed. We then triggered an active response through an indexer monitor. The manager created the task, and remoted logged: "task type 'active_response' not supported for legacy agents, not delivered". The agent's active-responses.log had no active response line. The rc2 release notes add an active response allowlist, which we did not test.

7. Frequency rules have no working replacement yet

Our 4.x frequency rule, rewritten as a Sigma aggregation rule, saved without complaint (HTTP 201). Creating a detector for it returned HTTP 500: "Cannot invoke "java.util.Map.containsKey(Object)" because "this.fieldMappings" is null", a NullPointerException. We tried three times, once after an attempt to add a field mapping, and got the same error each time, so the rule never ran. Two correlation rules also saved (HTTP 201), but after sending our 16 log lines three times and waiting 200 s there were zero correlation alerts. With the ruleset served on 2 November, the stock ruleset raised no finding for our nine pre-auth SSH disconnects from one IP. (Updated 6 Nov: with the ruleset served on 5 November, a new stock rule raises one low-severity finding for every disconnect event, still with no brute-force or frequency finding.) All of this matches rc1. One small difference: the field-mapping request itself now returns HTTP 500, where rc1 returned 200; the detector fails either way.

8. A rewritten child rule fires next to its parent

In 4.x our child rule raised only the child alert for the root-login line. Rewritten in Sigma, with the parent's condition copied into the child, both matched: logtest on that line listed parent-100510 and child-of-100510-user-root, and the detector produced a finding for each on the same event. Same as rc1. In our runs that meant two findings for one event; we have not yet tested excluding the child's case from the parent.

What this does not cover

The "5 s flush gives 7.1 s worst case" figure in item 5 is from rc1 only. Untested on either release candidate: TLS with the security plugin on, multiple nodes, a 5.x agent, CDB lists in the new key-value store, and whether Sigma timeframe is honoured.

One change that will break lab scripts: the rc2 notes say manager configuration moved from /var/wazuh-manager/etc to /etc/wazuh-manager with no symlink, which broke our rc1 lab scripts until we fixed the paths.

What we can run for you and what it costs is on one page: https://vct.atkvn.com/wazuh-5-migration.html

Wazuh active response: Cannot read 'srcip' from data

Nguyen Dong — Tue, 03 Nov 2026 07:04:02 +0000

The rule fired, the alert is in alerts.json, and the block did not happen. This line is written by a Wazuh active response, not by the rule engine. There are two different cases. In the first, the alert had no usable source IP in the places the script reads. In the second, on Windows agents, measured on 4.14.7, netsh.exe and route-null.exe wrote this line for every alert we sent, including one with a valid data.srcip: the IP was there and was still rejected.

Case 1 below is built from reading the Wazuh 4.14.7 source and the public documentation. The Windows case was measured on a Windows 11 agent.

Check it in one minute

The message goes to the active response log of the host where the response ran, the agent or the manager depending on location:

grep "Cannot read 'srcip'" /var/ossec/logs/active-responses.log | tail -n 5

Then look at what triggers the response. On the manager:

grep -A8 '<active-response>' /var/ossec/etc/ossec.conf

If it is bound by level or rules_group, it runs for every matching rule, including rules whose events carry no IP.

To test the response directly, with an address you control (we used the documentation range), call it through the manager API:

curl -k -X PUT "https://<manager>:55000/active-response?agents_list=<agent id>" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"command":"!netsh.exe","alert":{"data":{"srcip":"203.0.113.78"}}}'

The leading ! runs the executable by name. With "command":"netsh" the 4.14.7 API answered "The command used is not defined in the configuration." (error 1652) because no active-response block used that command yet. On Windows the log is C:\Program Files (x86)\ossec-agent\active-response\active-responses.log.

Why it happens (case 1)

In 4.14.7 the response reads the source IP with get_srcip_from_json() in src/active-response/active_responses.c. Reading the code, it does this, in order:

It needs parameters.alert.data in its input to be an object. If not, there is no IP.
If data.win.eventdata.ipAddress is a string, that is the candidate. If not, it tries data.win.eventdata.destinationIp.
Only if neither Windows field is a string does it read data.srcip.
The candidate must parse as an IPv4 or IPv6 address. If it does not, there is no IP. There is no fall-back to the next field.

When nothing comes back, firewalls/default-firewall-drop.c writes this line to logs/active-responses.log and exits with an error:

Cannot read 'srcip' from data or invalid IP format

So there are three practical causes. The event has no srcip: the decoder for that source does not extract one, or it lands under another name. The JSON decoder keeps the key's own name (we saw this in wazuh-logtest on 4.14.7 with Nextcloud and Office 365 events), so an address under a key such as src_ip becomes data.src_ip, which this function does not read. The field exists but is not an IP address, for example a host name. Or, on Windows events, win.eventdata.ipAddress is present as a string but is not a valid address, and the function returns nothing without trying destinationIp or data.srcip.

The message does not mean your rule failed. The rule matched, the alert was written, and only the response step found nothing to act on.

Fix (case 1)

Bind the response only to rules whose events carry an address. Use rules_id, which the documentation describes as limiting the command to when the listed rules fire, instead of a level or group that also catches rules without an IP:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100100</rules_id>  <!-- your rule ID(s) -->
  <timeout>600</timeout>
</active-response>

Then make the decoder name the field srcip for the sources you want to block on. For a regex decoder, order maps each capture group to a field name, and srcip is one of the names it accepts. Test the decoder with wazuh-logtest and confirm srcip appears in the decoding phase before relying on the response. Finally, check the value is an address: if the field holds a host name or a placeholder, the response cannot use it, whatever the binding.

Windows agents (4.14.7, measured): every IP fails

From a 4.14.7 manager we sent active responses to a Windows 11 agent running 4.14.7, through the API as shown above, and read the agent's active-responses.log. For both netsh.exe and route-null.exe, an alert carrying only data.win.eventdata.ipAddress = 203.0.113.77 gave "Cannot read 'srcip' from data", and so did an alert carrying only data.srcip = 203.0.113.78. Word for word, from the agent:

2026/10/03 19:51:29 active-response/bin/netsh.exe: Cannot read 'srcip' from data
2026/10/03 19:51:39 active-response/bin/route-null.exe: Cannot read 'srcip' from data

The data.srcip row rules out the field name: a plain, valid address was rejected too. Afterwards there was no Wazuh firewall rule and no route for either address on the machine. The Windows responses print the short form of the message, without "or invalid IP format".

Why, from the code: at v4.14.7, netsh.c (line 76) and route-null.c (line 29) both call get_srcip_from_json(), which checks the address with get_ip_version(), which calls getaddrinfo() (active_responses.c, line 576). We found no WSAStartup call in active_responses.c, netsh.c or route-null.c; on Windows, the socket functions need it first. That fits the cause proposed in wazuh/wazuh issue 38739, still open. This is our reading of the code plus the result above, not a debugger run.

Workaround: we found no central workaround you can apply from the manager. The check fails before netsh runs, whatever field carries the IP, and the binding and decoder fixes above do not change that on Windows.

Limits of what we measured

For case 1 we have not triggered the message on a running Linux agent or manager, and have not measured which releases print the shorter text. The Windows case was measured on one Windows 11 Pro agent running 4.14.7 with a 4.14.7 manager, by calling the responses through the API; we did not measure 4.14.8 or earlier releases, and the WSAStartup explanation is from reading the code, not a debugger.

Full write-up with the lab output: https://atkvn.com/fix-cannot-read-srcip-from-data.html

Wazuh: wazuh-analysisd segfault after a ruleset reload (4.13 and later)

Nguyen Dong — Mon, 02 Nov 2026 07:05:17 +0000

You edit rules, save, reload the ruleset from the dashboard or the API, and shortly afterwards wazuh-analysisd dies with a segmentation fault. A full restart with the same rules is fine.

Check if it is this

The kernel saw a segfault in analysisd:

journalctl -k | grep 'wazuh-analysisd.*segfault'
# or
dmesg -T | grep 'wazuh-analysisd.*segfault'

The reporter on wazuh/wazuh issue 39928 (4.14.5-1) saw lines like wazuh-analysisd[...]: segfault at ... error 6 in wazuh-analysisd[...], with three of four crashes at the same instruction pointer. The address will differ between builds. What matters is that it is wazuh-analysisd and that it repeats.

Then compare the crash time with when rules were saved and reloaded. A crash a few seconds to minutes after a reload, and none after a full restart, is the pattern in the issue. Your version should be 4.13.0 or later; /var/ossec/bin/wazuh-control info prints it.

Why it happens

According to the Wazuh maintainer who analysed the reporter's core dump, on 28 October 2026, this is "a race condition in the ruleset hot reload, introduced in 4.13.0". As they describe it, w_hotreload_reload() takes the ruleset lock as writer, switches the global ruleset pointers, releases the lock, and then frees the old ruleset. The event processing threads never take that lock, so events already in flight keep being matched against the old ruleset. os_remove_eventlist() frees that list without taking its mutex and dereferences an event that is no longer valid. The more events in flight during a reload, the wider the window.

This is the maintainer's analysis, quoted from the issue. We have not verified it against the source.

Which reload

Per the same comment, only the API path reaches the hot reload: PUT /manager/analysisd/reload and PUT /cluster/analysisd/reload, which the dashboard uses. wazuh-control reload does not hot reload; it restarts the services.

We measured this on the wazuh-manager 4.14.8 Docker image, which reports revision rc2. After PUT /manager/analysisd/reload, wazuh-analysisd kept the same PID and ossec.log showed "Reloading ruleset" followed by "Ruleset reloaded successfully". After wazuh-control reload, every daemon we checked except wazuh-execd came back with a new PID, and analysisd was down for about 9 seconds. If your crashes line up with the dashboard or the API, it is the hot reload path. If you only ever use wazuh-control reload, it is probably something else.

Fix status

Pull request 40907, "Fix analysisd crash when reloading the ruleset under load", was merged on 30 October into the 4.14.11 branch and the issue was closed. According to the pull request, the rule matching threads now take a lock that the reload waits for, so the old ruleset is freed only when no event is still using it. We have not tested the fixed build. The merge commit is not in v4.14.10-rc2, and 4.14.11 has no release yet.

What to do until then

Before the fix, the maintainer wrote: "We'll work on a fix for 4.14.x. Until then, apply ruleset changes with a full restart (systemctl restart wazuh-manager) instead of a reload."

/var/ossec/bin/wazuh-analysisd -t && systemctl restart wazuh-manager

The -t test first means a broken rule file stops you before the restart, not after. We changed a custom rule from level 5 to 12, wazuh-analysisd -t printed nothing and exited 0, we restarted, and wazuh-logtest matched the edited rule at level 12. Our lab container has no systemd, so we restarted with /var/ossec/bin/wazuh-control restart.

Avoid the dashboard and API reload on affected nodes until you run a release that contains the fix. On a cluster, that includes PUT /cluster/analysisd/reload.

To bring a dead daemon back automatically, a cron entry running /var/ossec/bin/wazuh-control start every minute is meant to do that. With analysisd killed, wazuh-control start started only analysisd, with a new PID, and left every other daemon on its existing PID. We tested this after one simulated crash, not over days. Pause it during planned maintenance, or it will start daemons you stopped on purpose.

A crash is silent

We killed wazuh-analysisd with kill -SEGV in the lab to see what a crash looks like from the outside. In the next 20 seconds ossec.log got no line at all, nothing restarted it, and every other daemon kept running with the same PID. Only wazuh-control status showed that analysisd was gone. The manager looks alive while no rule is being evaluated, and nothing in the log says so. If you cannot avoid reloads yet, alert on analysisd being down.

We did not reproduce the crash

We ran 20 API reloads, about 5 seconds apart, while the manager processed about 470 events per second of syslog, measured from wazuh-analysisd.state, with 0 events dropped. analysisd survived all 20. That does not mean your node is safe. The maintainer's analysis says the window grows with the number of events in flight, and our lab was small: one manager, no agents, the default ruleset plus one custom rule. We did not test large rulesets or many CDB lists, more event threads, reloads less than a second apart, more than 500 events per second, a cluster, or events arriving from agents. The crash in the silent-crash test is simulated with kill -SEGV, not the race itself.

Full write-up, including the fix status as read from GitHub on 31 October 2026: https://atkvn.com/fix-wazuh-analysisd-segfault-after-rule-reload.html

Wazuh custom rule never fires: shadowed by a sibling rule (and analysisd -t exits 0)

Nguyen Dong — Sun, 01 Nov 2026 07:18:02 +0000

You wrote a custom rule. wazuh-analysisd -t exits 0, a one-line logtest even shows it matching, and in production it never fires. One cause: another child of the same parent matched the event first.

When several children of one parent can match an event, one of them takes it. In our measurements, on Wazuh 4.14.7, the higher level went first, and at equal level the rule loaded first went first. If a sibling with a higher level matches your event, your rule never fires, and neither the config check nor a one-line logtest shows it.

Why it happens

We placed one rule in local_rules.xml and changed only its parent and level between runs:

<group name="local,syslog,sshd,">
  <rule id="100080" level="$LEVEL">
    <if_sid>$PARENT</if_sid>
    <match>Accepted password</match>
    <description>probe</description>
  </rule>
</group>

Two inputs through wazuh-logtest: S1, one Accepted password line; S2, 8 Failed password lines from the same IP within 8 seconds, then the same Accepted password line.

Case	Parent	Level	-T	S1 lands on	S2 lands on
A	5715	9	exit 0, no warning	100080 (ours)	40112 level 12, ours loses
B	5715	13	exit 0, no warning	100080	100080 level 13, ours wins
C	5700	9	exit 0, no warning	100080	100080
D	40112	12	exit 0, no warning	5715 level 3, ours does not fire	100080
control	no custom rule			5715 level 3	40112 level 12

We ran the matrix twice; all 8 verdicts matched. Four things follow.

A against B: same parent, only the level changed from 9 to 13, and the outcome of S2 flipped. Level decides the order among siblings, not if_sid and not the file.

At equal level, load order decides. On a test ruleset on a throwaway 4.14.7 manager, a sibling at the same level that was loaded earlier took the event. This matches a reading of the loader source: a new child is inserted in front of the first sibling with a lower level, and behind siblings with the same level.

The config check says nothing about this. wazuh-analysisd -t exited 0 with no warning in all four cases, including the one where our rule lost.

One line in logtest is not enough. In case A, a one-line test passes. Only the sequence shows the loss.

Check it in one minute

Feed wazuh-logtest the real sequence of events, not one line, and read which rule took the last one:

/var/ossec/bin/wazuh-logtest < sequence.log 2>&1 | grep -E "^[[:space:]]+(id|level|description): " | tail -3

If the ID is a sibling's rather than yours, your rule is shadowed on that sequence. Keep the 2>&1: logtest on 4.14 prints its results to stderr.

To find the sequence, look at alerts from siblings of your rule, meaning other children of the same parent. Their full_log is the event that sibling took.

Confirm before you fix

A sibling that fired proves only that the sibling matched something. It does not prove your rule would have matched the same event. On a test ruleset we built three candidates this way; one of them, a rule on a user name that none of the events had, looked shadowed and was not.

The check that separated them: on a throwaway manager with a copy of the rules, raise your rule's level to 15, replay the full_log of the sibling's alerts through wazuh-logtest, and see whether any of them flips to your rule. If some flip, the rule is shadowed on those events. If none flip, your rule does not match them, and the problem is the rule's own conditions. In our test, the two real cases flipped (2 of 2 and 1 of 2 samples) and the false one flipped 0 times.

Fix

Each of these was measured on the same pair of rules (the table above). Which one is right depends on what you want the rule to mean.

Rank above the sibling. Case B: level 13 over the sibling's 12 won both inputs. This also raises the severity of your alert, which may not be what you want.

Hang the rule higher in the tree. Case C: with parent 5700 at level 9, our rule took both inputs.

Hang the rule on the sibling. Case D: with parent 40112, the rule fires only after the burst of failures, and a lone login falls back to 5715. Use this when the correlated case is the one you care about.

At equal level, the rule loaded first wins. Moving your rule earlier can fix it, but a file that sorts before the parent's file gets your rule dropped at load. Check for 7617/7619 after any rename.

In B and C, 40112 no longer fires on S2: your rule takes the event instead. If you rely on 40112 as a brute-force alert, use D. After the change, feed the same sequence through logtest again and confirm the last line lands on your rule ID.

Limits of what we measured

One release (4.14.7), one single-node manager, one parent (5715) and one higher-level sibling (40112) for the level test, replayed through wazuh-logtest. The equal-level case and the replay check ran on test rules we wrote, on a throwaway 4.14.7 manager. We have not measured if_matched_sid or if_group chains, clusters, or live traffic. The replay check needs the full_log of the sibling's alerts; we have not measured it on Windows eventchannel or JSON events. Wazuh 4.14.8 (released 25 September 2026) ships byte-identical source files for rule loading and matching (rules-config.c, rules.c, cleanevent.c, logmsg.h, list_op.c); we compared the files, we did not rerun the tests on 4.14.8.

Full write-up with the lab output: https://atkvn.com/fix-rule-shadowed-by-sibling.html

Wazuh alert is in alerts.json but missing from the dashboard: mapper_parsing_exception

Nguyen Dong — Sat, 31 Oct 2026 12:41:41 +0000

You grep alerts.json and the alert is there. You open the dashboard and it is not. The manager looks healthy, the rule fired, and nothing in the UI says anything went wrong.

The alert was rejected by the indexer. The manager only writes alerts.json. Filebeat then sends each alert through an ingest pipeline into an index whose mapping comes from the Wazuh index template, and the mapping allows one type per field path. When a document carries a different shape at that path, the indexer answers with mapper_parsing_exception and does not store the document. Because the alert is already on disk, everything on the manager side looks normal.

Why it happens

Two things make a clash likely.

The stock template maps many fields as keyword. In the 4.14.7 template we counted 609 leaf fields, 486 of them keyword, 409 of those under data.*. Directly under data there are 21 scalar fields, among them data.data, data.srcip, data.url and data.id. A log source that sends an object under one of those names can be rejected.

The JSON decoder also changes shape with the input. In wazuh-logtest on 4.14.7, an object is expanded into subfields, while an array, empty or not, is packed into a single string such as '[]'. We saw this on two integrations, Nextcloud and Office 365. So the same path can be an object in one event and a string in the next.

Check it in one minute

Take one alert that is in /var/ossec/logs/alerts/alerts.json but missing from the dashboard, and note the field paths it carries under data. Then ask the indexer how it mapped them. For Microsoft Graph sign-ins the two fields are:

curl -sk -u '<user>:<password>' \
  "https://<indexer>:9200/wazuh-alerts-*,wazuh-archives-*/_mapping/field/data.ms-graph.status,data.ms-graph.appliedConditionalAccessPolicies?pretty"

If a field comes back "type" : "keyword" and the missing alert has an object, or a list of objects, at that path, the indexer rejects it. For any other field, put its path in place of the two above.

If your Filebeat writes its own log, this counts which fields fail:

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

We have not run a real Filebeat in our tests, so we have not seen that log line ourselves. The mapping query does not depend on it.

Case 1: Microsoft Graph sign-ins, data.ms-graph.status

The template maps data.ms-graph.status and data.ms-graph.appliedConditionalAccessPolicies as keyword. We checked the template at release tags v4.8.0, v4.10.0, v4.12.0, v4.14.0, v4.14.3, v4.14.7 and v4.14.8: the same in all seven. Alerts and incidents send status as a string such as "resolved". Sign-ins send it as an object, and send the policies as a list of objects. On a test indexer every sign-in was rejected, in both arrival orders:

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

The error names only the first field it trips on. A sign-in with a Conditional Access policy fails on appliedConditionalAccessPolicies; one with an empty policy list fails on status. When we fixed status alone, sign-ins that had a policy applied were still rejected.

A related detail: the stock 4.14.7 ruleset (0995-microsoft-graph_rules.xml, 99 rules) has no rule for relationship: signIns. A sign-in only matches 99500 at level 0, so it reaches the indexer through the archives, or through alerts once you write your own sign-in rule.

Fix: move the object shape to a new field, in the pipeline

Keep the string status of alerts and incidents where it is, because dashboards and saved searches expect it, and move only the sign-in shapes. One script processor, placed right after the json processor, in both the alerts and the archives pipeline:

{"script": {
  "lang": "painless",
  "ignore_failure": true,
  "description": "ms-graph signIns fix",
  "source": "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')); }"
}}

Two details matter. ignore_failure: true, because the stock pipelines end with on_failure: drop, so a processor that throws would drop the whole event. With this flag the worst case is an event indexed unchanged. And d.get('ms-graph') rather than 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. We hit this ourselves.

What we measured: every sign-in and the alert indexed, in both orders, in a new index and in an index that already existed, so the fix works on today's index. data.ms-graph.status stays keyword and still aggregates.

Case 2: a field that is sometimes an object, sometimes a string, data.data

Nextcloud events can carry data as an object or as an array. Our three test lines differed only in that, and all three matched rule 88207. With the stock template, where data.data is keyword, the object shape fails with failed to parse field [data.data] of type [keyword]. A separate template that makes data.data an object accepts those, and rejects the string shape instead. Changing the template alone only moves which shape fails.

Fix: a separate template plus a rename by type

Two changes that only work together. First, a separate legacy template with a higher order that keeps the field an object:

PUT _template/fixpack-data-data
{"order": 1,
 "index_patterns": ["wazuh-alerts-4.x-*"],
 "mappings": {"properties": {"data": {"properties": {"data": {"type": "object"}}}}}}

Second, one rename processor right after the json processor, which moves the field only when it arrives as a string, so the new field only ever receives strings:

{"rename": {"field": "data.data", "target_field": "data.data_raw",
            "ignore_missing": true, "if": "ctx.data?.data instanceof String"}}

What we measured: every order of object, "[]" and "[{..}]" indexed cleanly, 4 of 4 in two separate orders. The template alone, the rename alone, and a rename by location each still failed. A template only applies when an index is created, so this fix takes effect on the next daily index. Note the side effect: the rename moves every string data.data, from every source, into data.data_raw, so searches and dashboards that read data.data as a string need to follow it.

Limits of what we measured

All of this was measured on a throwaway wazuh-indexer 4.14.7 with the stock template and the stock pipelines taken from the wazuh-manager 4.14.7 image. We sent events through the pipeline in the form Filebeat sends them, but not through a real Filebeat and not from a real manager. The sign-ins were built from the Graph v1.0 schema, not taken from a live tenant, and we have not checked fields that only the Graph beta API sends. We did not measure whether a patched pipeline survives a restart or an upgrade, or how any of this behaves on a multi-node cluster. The decoder behaviour was measured on two integrations. For the 21 scalar fields under data, we can say a clash is possible, not that it will happen. The fix template above covers wazuh-alerts-4.x-* only: we measured the alerts index, not the archives index, which the stock template also covers.

Full write-up with the lab output: https://atkvn.com/fix-mapper-parsing-exception.html

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.

DEV Community: Nguyen Dong

What tells you a Wazuh rule has gone quiet?

What tells you a Wazuh rule has gone quiet?

Setup, and a first surprise

Test 1: the command line disappears

Test 2: a parser update renames a field

Option A: compare today's count with the rule's own baseline

Option B: a heartbeat per use case

The same failure mode in Wazuh 5.0

What we did not test

Wazuh snort decoder cuts the last octet off srcip and dstip (4.14.x)

Check it in one minute

Why it happens

Fix on 4.14.x today

Confirm it worked

Limits of what we measured

Wazuh 5.0 rc2: eight things that still change for your 4.x custom rules

1. The analysis binary has no 4.x rule keywords

2. Your XML files load without a word

3. srcip is rejected as a field

4. Unparsed lines are not indexed by default

5. Indexer flush is 20 seconds

6. Active response does not reach a 4.14.7 agent

7. Frequency rules have no working replacement yet

8. A rewritten child rule fires next to its parent

What this does not cover

Wazuh active response: Cannot read 'srcip' from data

Check it in one minute

Why it happens (case 1)

Fix (case 1)

Windows agents (4.14.7, measured): every IP fails

Limits of what we measured

Wazuh: wazuh-analysisd segfault after a ruleset reload (4.13 and later)

Check if it is this

Why it happens

Which reload

Fix status

What to do until then

A crash is silent

We did not reproduce the crash

Wazuh custom rule never fires: shadowed by a sibling rule (and analysisd -t exits 0)

Why it happens

Check it in one minute

Confirm before you fix

Fix

Limits of what we measured

Wazuh alert is in alerts.json but missing from the dashboard: mapper_parsing_exception

Why it happens

Check it in one minute

Case 1: Microsoft Graph sign-ins, data.ms-graph.status

Fix: move the object shape to a new field, in the pipeline

Case 2: a field that is sometimes an object, sometimes a string, data.data

Fix: a separate template plus a rename by type

Limits of what we measured

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

Reason 2: CSV format corrupts `srcip`

Reason 1: rule 87701 carries `no_log`