Custom decoder not working | wazuh-manager-4.3.6-1.x86_64

[Atul Chadha]

I have setup a few custom decoders earlier and have a fair idea how it works. We have created a log file with data similar to shown below

wzh-inventory Hostname: XXXXX IPV4: 0.0.0.0 Serial:  VMware-42 04  Make:  VMware, Inc. Model:  VMware Virtual Platform OS: CentOS Linux release 7.9.2009 (Core) Kernel: 3.10.0-1160.76.1.el7.x86_64 Function: Production Product: PROD Type: APP CPU: 4 Memory: 7

For some weird reason, the log only shows in the kibana UI when i remove the custom decoder and stops working as soon as put the decoder code back in /var/ossec/etc/decoders/local_decoder.xml

The decoder and associated rule work fine in the logtest , i am out of ideas whats going on

Decoder:

<decoder name="infra_inventory">
  <prematch>wzh-inventory</prematch>
  <regex type="pcre2">^wzh-inventory Hostname: (\w+) IPV4: (\d+.\d+.\d+.\d+) Serial: (\s.*) Make: (\s.*) Model: (\s.*) OS: ((?s).*) Kernel: (?s).* Function: (?s).* Type: (\w+) CPU: (\d+) Memory: (\d+)</regex>
 <order>INF.INV_HOSTNAME,INF.INV_IPv4,INF.INV_SERIAL,INF.INV_MAKE,INF.INV_MODEL,INF.INV_OS_NAME,INF.INV_KERNEL,INF.INV_FUNCTIONALITY,INF.PRODUCT,INF.TYPE,INF.CPUCORE,INF.MEMORY</order>
</decoder>

[Selu López]

Hi Atul,

Did you create a custom rule in addition to the decoder? In that case, could you please share the rule too so that I can test the same use case?

Best regards,

Selu.

[Atul Chadha]

I created a placeholder rule and it works ( at least in logtest )

Code below

<group name="infra_inventory,">
  <rule id="100014" level="3">
          <regex type="pcre2">wzh-inventory</regex>
          <description>infra inventory ran </description>
   </rule>

[Selu López]

Hi Atul,

It is quite strange, using both your decoder and your rule, in my environment the alerts are generated fine and are appearing on the dashboard. In fact, I am attaching a couple of screenshots where you can see the alerts, one using the decoder and the other without it:

What I did is:

1. Add the decoder to /var/ossec/etc/decoders/local_decoder.xml
2. Add the rule to /var/ossec/etc/rules/local_rules.xml
3. Restart the manager: service wazuh-manager restart
4. For testing purposes, I created this file in an agent: /test.log
5. Added this to agent's conf (/var/ossec/etc/ossec.conf) so the log file is monitored:
     <localfile>
       <log_format>syslog</log_format>
       <location>/test.log</location>
     </localfile>
6. Restart the agent: service wazuh-agent restart
7. Added log lines to the monitored file: 
   echo "wzh-inventory Hostname: XXXXX IPV4: 0.0.0.0 Serial:  VMware-42 04  Make:  VMware, Inc. Model:  VMware Virtual Platform OS: CentOS Linux release 7.9.2009 (Core) Kernel: 3.10.0-1160.76.1.el7.x86_64 Function: Production Product: PROD Type: APP CPU: 4 Memory: 7" >> /test.log
   

If this isn't working, check your manager's ossec.log (/var/ossec/logs/ossec.log) in case you're getting any related errors and let me know.

Regards,

Selu.

[Atul Chadha]

Appreciate your efforts and time to replicate this!

I have exact same steps as you ( except for a different file location for localfile )

What baffles me is the fact that the log entry shows up instantly on kibana as soon as i remove the custom decoder which makes me believe that something is wrong with the decoder which may be stopping the further processing of the log.

The irony is the logtest is able to break the log entry clearly and the rule shows as firing. I checked the ossec log and can see the entry being picked up from the custom file location. Its getting lost somewhere between.

What config are you on, i am using wazuh-manager-4.3.6 paired with elasticsearch  7.17.4. I can use any help possible to fix this

[Selu López]

Hello Atul,

In my case I am using wazuh-docker, where there is a manager, Wazuh Indexer and Wazuh Dashboard, all of them in version 4.4.1. However, I have tried to reproduce the behavior in a v4.3.6 standalone manager without success, so possibly this is not the problem.

Regardless of the indexer and dashboard used, the alert (if generated) should be appearing in the /var/ossec/logs/alerts/alerts.log file. Could you check its content when the log is processed?

Regards,

Selu.

​

[Atul Chadha]

Thank you so much for debugging this, i was able to find out the root cause. The doc was getting dropped due to mapping related error. I have fixed and its all good now!

Appreciate the support..

[Selu López]

Thank you for letting us know. I'm glad you were able to fix the problem.

Best regards,

Selu.

[Striker__ 1]

I have the same problem my decoder and the rule is just working fine i tested in the log test with the raw log I captured from the archives 

**Messages:
WARNING: (7003): 'da91b134' token expires
INFO: (7202): Session initialized with token '04565d0d'

**Phase 1: Completed pre-decoding.
full event: 'Multiline Oracle Audit Log Thu Mar 28 07:03:32 2024 -04:00'

**Phase 2: Completed decoding.
name: 'OracleAudit'

**Phase 3: Completed filtering (rules).
id: '100094'
level: '5'
description: 'Oracle audit event'
groups: '["oracle"]'
firedtimes: '1'
mail: 'false'
**Alert to be generated.

could you please explain further the matter you have of the doc mapping maybe i have the same problem
best regards,

[Matskoow]

I have the same issue.

Op woensdag 3 april 2024 om 12:19:14 UTC+2 schreef Striker__ 1: