Hi Thomas,
I have replicated this issue on my end and found that the log should be starting from
192.168.201.17 1 2025-01-15T19:05:45+01:00 firewall.xxx-yyyyyy.local ulogdThis part is from agent header seems to be.
2025 Jan 15 19:05:49 TESTWAZUH->
Kindly confirm that you have integrated these logs directly or through an agent.
If yes then remodify the first two decoders. You can replace your initial two decoders with this.
<decoder name="utm-syslog-parent">
<prematch>^\d+.\d+.\d+.\d+\s\d+\s\d+-\d+-\S+</prematch>
</decoder>
<decoder name="utm-syslog-child">
<parent>utm-syslog-parent</parent>
<regex>\d+.\d+.\d+.\d+\s\d+\s(\d+-\d+-\S+)\s(\S+)\s(\S+)\s(\d+)\s-\s-\s(\S+):</regex>
<order>log_time,Host,service,logID,FWaction</order>
</decoder>
Then restart the Wazuh manager
systemctl restart wazuh-manager
I have increased the rule level 3 for the first rule to test. It was worked. You can reduce to 0 after testing to avoid the parent rule.
You can check the the archives.json log if the logs reach the manager.
You can enable the archive log by editing the
/var/ossec/etc/ossec.conf file.
<ossec_config>
<global>
----
<logall>no</logall>
<logall_json>yes</logall_json>
-----
</global>
-----
</ossec_config>
Then restart the manager to apply changes.
systemctl restart wazuh-manager
Then check if you receive any logs from that file to archive log.
cat /var/ossec/logs/archives/archives.json | grep -i -E "<part_of_your_log>"
Remember to disable the archive log, after the testing.
You can check logs writing to the alerts.json file, if yes it should be receiving.
cat /var/ossec/logs/alerts/alerts.json | grep "firewall.xxx-yyyyyy.local"
Regards,
Hasitha Upekshitha