mapper_parsing_exception on data.service field

[Stefan Ondrejovic]

Hello,

We are experiencing a long-term issue where new indices for wazuh-status-inventory-* and wazuh-status-vulnerabilities-* are failing to be created.

Our Filebeat logs are consistently flooded with the following warning regarding a mapping conflict:

WARN:... (status=400): {"type":"mapper_parsing_exception","reason":"failed to parse field [data.service] of type [keyword] in document with id..."}

1. Mapping Conflict: In our current wazuh-archives-4.x-* indices, the field data.service is explicitly mapped and stored as a keyword type. However, the system inventory and vulnerability modules seem to expect a different structure (object) for this field, causing the parsing exception.

2. Root Cause Suspicion: We suspect this conflict is triggered by the official Fortigate decoder (0100-fortigate_decoders.xml). Specifically, the following section extracts the service name directly into the service field:

<decoder name="fortinet-fortigate-fields-v7"> <parent>fortinet-fortigate-firewall</parent> <regex>\s+service="(\.*)"|\s+service=(\.*)\s|\s+service=(\.*)$</regex> <order>service</order> </decoder>

When these firewall logs are processed, they populate data.service as a simple string (keyword), which collides with the index templates of the IT Hygiene / Vulnerability modules.

We want to fully utilize the Vulnerability Detector and IT Hygiene features without losing the ability to send logs from Fortigate to archive

1. What is the recommended best practice to resolve this naming collision between the official Fortigate decoder and the internal Wazuh status/inventory mappings?

2. Should we implement a custom decoder/rule to map the Fortigate service field to a custom variable (e.g., data.fg.service), or is there an official index template workaround/reindexing strategy you recommend?

Thank you for your assistance.

Best regards

Stefan O.

[Matias Ezequiel Latorre]

Hi Stefan,

  Your diagnosis is correct. The issue is caused by a mapping collision between Fortigate archive events and the inventory/vulnerability documents.

  The Fortigate decoder populates data.service as a string/keyword field, while the Vulnerability Detector and IT Hygiene modules expect data.service to behave as an object structure. Since
  OpenSearch does not allow the same field to be mapped simultaneously as both keyword and object, the indexing operation fails with mapper_parsing_exception.
  Recommended solution: override the Fortigate decoder
 
  Create a custom decoder file under /var/ossec/etc/decoders/ (e.g., fortinet-custom-override.xml) with the following content:

  <decoder name="fortinet-fortigate-fields-v7">
    <parent>fortinet-fortigate-firewall</parent>

    <regex>\s+service="(.*)"|\s+service=(.*)\s|\s+service=(.*)$</regex>
    <order>fg.service</order>
  </decoder>
 
  Since custom decoders are loaded after the system ones, using the same decoder name (fortinet-fortigate-fields-v7) ensures this definition overrides the official one. The Fortigate service
  field will now be stored as data.fg.service, which no longer conflicts with the internal Wazuh inventory and vulnerability mappings.

  After applying the decoder, restart the Wazuh manager:

  /var/ossec/bin/wazuh-control restart

  You can validate the decoder is working correctly using the Wazuh ruleset testing tool before restarting in production.

  Note on existing indices
 
  Existing active indices may still contain the previous conflicting mapping. Even after the decoder fix, currently active indices may continue generating errors until rollover or new index
  creation occurs, since mappings already written to an index do not change retroactively. No action is needed — the issue will resolve itself as indices rotate.
 

  References
 
  - Custom decoders: https://documentation.wazuh.com/current/user-manual/ruleset/decoders/custom.html
  - Decoder XML syntax (<order> field): https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html
  - Custom rules and decoders overview: https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
  - Testing decoders and rules: https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

  Best regards,