Predecoder Hostname field

83 views
Skip to first unread message

Brenno Garcia

unread,
Oct 10, 2025, 12:27:33 PM (9 days ago) Oct 10
to Wazuh | Mailing List
Hello, can anyone help me?

I'm trying to use hostname field decoded by predecoder, for a pfsense log.
Pfsense logs are forwarded by rsyslog to a file .log and monitored by wazuh.
But the hostname field isn't working correctly (idk).
Screenshot_4.png

So, im using the hostname in a rule:
Screenshot_5.png

But the same alert on wazuh dashboard shows Wazuh_Server as the hostname.Screenshot_6.png

Juan Felipe González Ortiz

unread,
Oct 10, 2025, 2:29:39 PM (9 days ago) Oct 10
to Wazuh | Mailing List

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:

  1. Add a custom field in the rule’s group or description to include the decoded hostname.

  2. 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">
  <decoded_as>php-fpm</decoded_as>
  <description>pfSense login failed (host: $(hostname))</description>
  <group>pfsense,auth,failed,guid</group>
</rule>

That will display the decoded hostname value in the alert message even though the source agent remains Wazuh_Server.

Brenno Garcia

unread,
Oct 13, 2025, 8:23:16 AM (6 days ago) Oct 13
to Wazuh | Mailing List
Hello, I'm opening this chat precisely because I'm doing option 1. I included $(hostname) in the rule description, and it works in wazuh-logtest. However, the alert on the dashboard displays $(hostname) as Wazuh_Server in the rule description.

Juan Felipe González Ortiz

unread,
Oct 14, 2025, 3:54:37 PM (5 days ago) Oct 14
to Wazuh | Mailing List

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

Brenno Garcia

unread,
Oct 15, 2025, 9:15:54 AM (4 days ago) Oct 15
to Wazuh | Mailing List
The log on archives.log is
2025 Oct 12 13:58:18 wazuh ->172.18.0.1 Oct 12 13:58:18 pfsense.hostname sshd[14249] error: PAM: Authentication error for admin from x.x.x.x

but the pfsense log that is decoded by the pre-decoder is
Oct 12 13:58:18 pfsense.hostname sshd[14249] error: PAM: Authentication error for admin from x.x.x.x

I think I solved it by using rsyslog to rewrite the log, including the hostname at the end of the log
so the phase 2 is able to extract hostname from the full log
Oct 12 13:58:18 pfsense.hostname sshd[14249] error: PAM: Authentication error for admin from x.x.x.x pfsense.hostname

Juan Felipe González Ortiz

unread,
Oct 15, 2025, 12:46:26 PM (4 days ago) Oct 15
to Wazuh | Mailing List

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?

Brenno Garcia

unread,
Oct 15, 2025, 4:39:13 PM (4 days ago) Oct 15
to Wazuh | Mailing List

The intention was to use the hostname field within the rule description.
However, the predecoder, despite extracting the hostname correctly, was not displayed in the rule on the dashboard.

the old decoder was able to extract user and ip, since hostname 
log: 
Oct 10 13:44:17 pfsense.domain php-fpm[20405] /index.php: webConfigurator authentication error for user 'admin' from: x.x.x.x 
<decoder name="pfsense-webconfig-fail">
  <program_name>php-fpm</program_name>
  <prematch>webConfigurator authentication error for user</prematch>
  <regex type="pcre2">webConfigurator authentication error for user (\S+) from: (\S+)</regex>
  <order>user, srcip</order>
</decoder>

The old decoder was able to retrieve the IP address and username, since the predecoder already retrieved the hostname.
But the dashboard alert, despite displaying the hostname field correctly, didn't insert it into the rule description.

Screenshot_12.png

The other way around, I added the hostname back to the syslog log because I couldn't get the hostname field with a custom decoder. I believe this wouldn't be possible if a predecoder extracts it first.
So, with the duplicate hostname, one was captured by the predecoder and the other by my custom decoder and stored in $host.

log: 
Oct 10 13:44:17 pfsense.domain php-fpm[20405] /index.php: webConfigurator authentication error for user 'admin' from: x.x.x.x pfsense.domain
<decoder name="pfsense-webconfig-fail">
  <program_name>php-fpm</program_name>
  <prematch>webConfigurator authentication error for user</prematch>
  <regex type="pcre2">webConfigurator authentication error for user (\S+) from: (\S+) (\S+)</regex>
  <order>user, srcip, host</order>
</decoder>


This way, the rule correctly interpreted the data.host variable name as different from the predecoder.hostname in the previous method.

Screenshot_10.png


Screenshot_11.png

Brenno Garcia

unread,
Oct 15, 2025, 4:39:15 PM (4 days ago) Oct 15
to Wazuh | Mailing List
How it was before:
The log was:
Oct 10 13:44:17 pfsense.domain php-fpm[20405] /index.php: webConfigurator authentication error for user 'admin' from: x.x.x.x

I dont have the exact values**
but  the decoder was able to extract user and srcip, since the predecoder extracts hostname.

<decoder name="pfsense-webconfig-fail">
  <program_name>php-fpm</program_name>
  <prematch>webConfigurator authentication error for user</prematch>
  <regex type="pcre2">webConfigurator authentication error for user (\S+) from: (\S+)</regex>
  <order>user, srcip</order>
</decoder>

The predecoder extracts the fields, including the hostname.
Logtest worked correctly, including displaying the hostname in the triggered rule.
However, when I actually triggered the rule and checked the dashboard, the predecoder.hostname field had the correct value, but the description always received the name of Wazuh_Server.

Screenshot_9.png

So i modified the log and include the hostname at the end of the log to be able to extract by the same decoder with one more field
Oct 10 13:44:17 pfsense.domain php-fpm[20405] /index.php: webConfigurator authentication error for user 'admin' from: x.x.x.x pfsense.domain

<decoder name="pfsense-webconfig-fail">
  <program_name>php-fpm</program_name>
  <prematch>webConfigurator authentication error for user</prematch>
  <regex type="pcre2">webConfigurator authentication error for user (\S+) from: (\S+) (\S+)</regex>
  <order>user, srcip, host</order>
</decoder>

Screenshot_7.png

new field data.host
Screenshot_10.png
Screenshot_11.png
So in this case it works.

before:
rule description -> $(hostname)  GUI Failed login... -> hostname was decoded by predecoder

after:
rule description -> $(host) GUI Failed login... -> host was decoded by custom decoder

Why duplicate the hostname in logs?
I did because i dont think its possible a custom decoder extracts a field which already was decoded by predecoder (at least for me, it doesnt work)

Juan Felipe González Ortiz

unread,
Oct 16, 2025, 11:31:52 AM (3 days ago) Oct 16
to Wazuh | Mailing List

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.

Reply all
Reply to author
Forward
0 new messages