Hi, What you’re seeing is expected behavior: the hostname field shown in the Wazuh dashboard corresponds to the agent name that sent the log, not the hostname decoded by the predecoder.
In your case:
The predecoder correctly extracts the hostname from the log (pfsense.domain.com).
However, since the log file is being monitored locally on the Wazuh server (via localfile), the alert originates from the Wazuh manager itself, so the dashboard displays Wazuh_Server as the hostname.
If you want the decoded hostname (pfsense.domain.com) to appear in the alert, you have two main options:
Add a custom field in the rule’s group or description to include the decoded hostname.
Deploy a Wazuh agent on the pfSense system (if possible) — this way, the alerts will show the correct agent/hostname automatically.
Example of including it in the rule description:
<rule id="883013" level="6">That will display the decoded hostname value in the alert message even though the source agent remains Wazuh_Server.
Hi!
It may be that rsyslog adds a syslog header with the manager’s info, causing the hostname to appear as Wazuh_Server.
Could you share the full_log from one of the affected alerts? That will help confirm if the original pfSense log is being modified before Wazuh processes it
Glad to hear you managed to solve.
However, I’m not fully sure I understand how the change fixed the issue — could you please share the decoder you’re using and the rule snippet where you reference the hostname?
Also, just to confirm, your goal was to show the pfSense hostname in the rule description, similar to how it appears in the agent log, right?
Hi!
Yes, that approach works. By adding the hostname to the log and creating a custom decoder to extract it, you can reference that new field in the rule description instead of using the one from the predecoder.
It’s true that this method slightly modifies the original log, but if that’s acceptable for your setup, it’s a valid workaround. Another option would be to avoid using the hostname in the rule description, since the alert already includes the correct predecoder.hostname value.
Thanks for sharing your solution and for taking the time to test it, it will surely help others facing a similar case.