Wazuh rule with <hostname> matches in wazuh-logtest but never fires for agent events

/var/ossec/bin/wazuh-logtest -l '[002] (cae) 192.168.8.28->journald'

Why it happens

Every event reaches analysisd with a location. A local event has a location like stdin or a file path; an event from an agent has one that starts with the agent ID, like [002] (cae) 192.168.8.28->journald. In the 4.14.7 source (src/analysisd/cleanevent.c, around lines 543–584), a location that starts with [ makes analysisd take the text between the parentheses, the agent name, as the event's host name. For a local event it keeps the host name read from the syslog header.

<hostname> in a rule is compared with that value (rules.c, around lines 2875–2880), as an OS_Match expression by default. The predecoder.hostname in the alert JSON is parsed again from full_log when the alert is written (json_extended.c), so it shows the syslog host even when the rule compared against the agent name.

We checked it on a 4.14.7 manager with one su line whose syslog host is DN4, a parent rule reached on every run, and two children: one with <hostname>DN4</hostname>, one with <hostname>^cae$</hostname>.

In all three runs logtest printed hostname: 'DN4' in its decoding phase. The value it prints is not the value the rule compares.

Fix

• Match the agent name, anchored: <hostname>^cae$</hostname>. Without ^ and $, cae also matches an agent called caesar (third row above).
• Know what it costs: if the agent is renamed, the rule stops matching and nothing tells you. Keep the agent name in the rule's description so a rename is easy to trace.
• Test the way production runs: always pass the agent-style location to wazuh-logtest for rules meant for agent events.
• <location> is not a shortcut: reading the same source, for agent events it is compared with the whole (cae) 192.168.8.28->journald string, not the journald the alert shows. We have not measured it.