Use new default_ruleset parameter when reading rules and decoders file content

[davidjiglesias]

Description

As reported in wazuh/wazuh#15994, we did not have an option to select if a rule or decoder belonged to the default or the custom ruleset when reading the file content from the API.

This caused a bug, also affecting our WUI, where an user creates a new rule file, add it to the custom ruleset (with the same name as a default ruleset file) and when you try to access its content from the interface, the content of the other file is read.

Since we have added a new option to select if the file to be read belongs to the default ruleset or not, we should adapt the WUI to properly use this parameter based on the file being selected, for example:

I have created a copy and modified its content for 0010-rules_config.xml:

However, if I click on the custom one, with path etc/rules, I obtain the content for the default one.

We can fix this using the new API parameter default_ruleset, setting it as false when the path starts with etc/

Related issues

• Bug when trying to visualize a custom decoder #3693
• No feedback was given to the user after trying to create an existing rule/decoder #4422

[Desvelao]

Thought

I was starting to work on adding the new parameter default_ruleset to the file content can be retrieved the expected file when I thought that this parameter doesn't cover other cases.

For example, if the user adds a non-default relative path to the ruleset block as:

This addition seems to be legit in Wazuh manager 4.5.

The rule and file are listed in the Wazuh plugin:

In this case, from my knowledge and the current API for 4.5, is not allowed to get the file content of files located in these custom relative directories. So this seems to be a missing feature.

I opened a thread to arise this to know if this is a known issue or not.

[Desvelao]

Work in progress

Meanwhile, I am implementing the initial request of the default_ruselet parameter.

[Desvelao]

Discussion

A meeting will be done in the following days where we could talk about the problem mentioned #5176 (comment).

[Desvelao]

Patch for the initial request

I was working around the initial request done in the issue ignoring the problem found. Depending on the decision taken, the next patch could be useful or we should work on another solution.

5176-get-rule-decoder-file-content-using-default-ruleset-parameter.txt

The patch contains:

• use the default_ruleset query parameter to get the rule or decoder file content
• fixes this problem Decoder information is displayed before closing the flyout with the information #5219

[Desvelao]

Discussion

We had a meeting today. The API colleagues will review the possibility to give support to define the path of the rule/decoder file because the current implementation doesn't support getting the content of the file located in a different path to ruleset/rules or etc/rules (same for decoders).

[Desvelao]

Tracking

Framework reopened the issue wazuh/wazuh#15994 to investigate the discussion of the meeting.

[AlexRuiz7]

Blocked by wazuh/wazuh#15994

[Desvelao]

Research

wazuh/wazuh#15994 was merged.

I built a Wazuh manager in 4.6.0 that has implemented the fix of the issue. I could adapt the API request to get the file content.

But I found other problems that I guess the product should support. Following the approach of the relative_dirname query parameter, I added to the update and delete actions of the Wazuh plugin. When I tried to edit a custom file, the API replied with an error mentioning that the relative_dirname is not in the spec.

How are we supposed to edit or delete a custom file indicating the relative directory name?

API logs:

2023/07/24 09:00:02 INFO: wazuh-wui 172.29.0.8 "PUT /rules/files/local_rules.xml" with parameters {"overwrite": "true", "relative_dirname": "etc/rules/custom_dir"} and body {} done in 0.019s: 400

EDIT: I commented on this with the API co-workers and they reopened the issue again wazuh/wazuh#15994

[Desvelao]

Research

I found something that could be considered a problem.

The Wazuh plugin offers a way to see the custom rules/decoders through the Custom rules and Custom decoders button that adds a filter to the search bar.

If we have configurated rules or decoders in other custom directories, then these files are not displayed due to the filter. So the Custom rules and Custom decoders don't display the expected data.

root@wazuh-manager-master-7102:/var/ossec/etc/rules# ls
custom_dir local_rules.xml
root@wazuh-manager-master-7102:/var/ossec/etc/rules# ls custom_dir/
local_rules.xml

To the local_rules.xml from the etc/rules/custom_dir directory is displayed in the plugin, I had to replace the search by:

relative_dirname:etc/rules/custom_dir

For this case, I don't know if the Custom rules and Custom decoders buttons could give more confusion for these use cases that use other directory names instead of the etc/rules or etc/decoders.

[Desvelao]

Research

I found something that could be considered a problem.

The Wazuh plugin offers a way to see the custom rules/decoders through the Custom rules and Custom decoders button that adds a filter to the search bar.

If we have configurated rules or decoders in other custom directories, then these files are not displayed due to the filter. So the Custom rules and Custom decoders don't display the expected data.

root@wazuh-manager-master-7102:/var/ossec/etc/rules# ls custom_dir local_rules.xml root@wazuh-manager-master-7102:/var/ossec/etc/rules# ls custom_dir/ local_rules.xml

To the local_rules.xml from the etc/rules/custom_dir directory is displayed in the plugin, I had to replace the search by:

relative_dirname:etc/rules/custom_dir

For this case, I don't know if the Custom rules and Custom decoders buttons could give more confusion for these use cases that use other directory names instead of the etc/rules or etc/decoders.

I asked to @Selutario about:

Another topic that I am not sure if this is the expected behavior.
The Wazuh plugin can list the rules and the rules files.
Example:

• 2 custom rule files:
• etc/rules/local_rules.xml
• etc/rules/custom_dir/local_rules.xml

root@wazuh-manager-master-7102:/var/ossec/etc/rules# ls
custom_dir  local_rules.xml
root@wazuh-manager-master-7102:/var/ossec/etc/rules# ls custom_dir/
local_rules.xml```
If we see the rules using the filter relative_dirname=etc/rules, both rules are displayed, despite one of this rule is stored in a file located in a subdirectory of etc/rules (etc/rules/custom_dir ). But when we list the files using the relative_dirname=etc/rules , only is displayed the file etc/rules/local_rules.xml . Is this behavior expected?

and he replied that it does, so this is not considered as a problem.

[Desvelao]

Research

Another question regarding the comment of the pull request: wazuh/wazuh#17206
If the relative path is passed in the filename parameter, it is NOT USED for RBAC validation.
Could you clarify with an example when the RBAC validation is not done?

Reply by @Selutario:

It means that RBAC only applies to the filename field, not to the relative path:
GET /decoders/files/{filename}
For example, if 0005-wazuh_decoders.xml is denied in a RBAC policy, the user won't be able to get said decoder, it doesn't matter what is the full path.
This would be forbidden:
GET /decoders/files/0005-wazuh_decoders.xml?relative_dirname=ruleset%2Fdecoders
And this would also be forbidden, even if they are not the same file:
GET decoders/files/0005-wazuh_decoders.xml?relative_dirname=etc%2Fdecoders%2Fcustom_decoder%2F

@davidjiglesias commented that this was not a requirement when API RBAC was designed in 2019.

For now, we should take into account the plugin RBAC usage.

[Desvelao]

Block

This issue is blocked by wazuh/wazuh#15994 related to this topic: #5176 (comment).

[Desvelao]

Checks

The following checks have to be done to ensure the functionalities are not broken:

• Rules
  • Create new file (in etc/rules)
  • Upload new files (in etc/rules)
    • Overwrite enabled
    • Overwrite disabled
  • Read file
    • ruleset/rules
    • etc/rules
    • etc/rules/custom_directory
  • Update file
    • etc/rules
    • etc/rules/custom_directory
  • Delete file
    • etc/rules
    • etc/rules/custom_directory
• Decoders
  • Create new file (in etc/decoders)
  • Upload new files (in etc/decoders)
    • Overwrite enabled
    • Overwrite disabled
  • Read file
    • ruleset/decoders
    • etc/decoders
    • etc/decoders/custom_directory
  • Update file
    • etc/decoders
    • etc/decoders/custom_directory
  • Delete file
    • etc/decoders
    • etc/decoders/custom_directory

[Desvelao]

Patch to fix the update and delete rule/decoder file.
wka-issue-5176-add-relative-dirname.txt

[Desvelao]

The pull request was recently merged and the issue was closed, so we could continue the work in this issue.

[Desvelao]

Problem

Wazuh server: built from sources branch 4.6.0

Context:

I added custom directories for decoders and rules:

<ruleset>
...
  <!-- User-defined custom directory ruleset -->
  <rule_dir>etc/rules/custom_dir</rule_dir>
  <decoder_dir>etc/decoders/custom_dir</decoder_dir>
</ruleset>

Then I added rule and decoders files to the custom directories:

etc/rules/local_rules.xml
etc/rules/local_rules_custom.xml
etc/rules/custom_dir/local_rules.xml
etc/decoders/local_decoders.xml
etc/decoders/local_decoders_custom.xml
etc/decoders/custom_dir/local_decoders.xml

root@wazuh-manager-460-7102:/var/ossec/etc# tree rules decoders
rules
|-- custom_dir
|   `-- local_rules.xml
|-- local_rules.xml
`-- local_rules_custom.xml
decoders
|-- custom_dir
|   `-- local_decoders.xml
|-- local_decoders.xml
`-- local_decoders_custom.xml

When I edit from the UI the file: etc/decoders/custom_dir/local_decoders.xml and save, the following API request is done: ``

API log:

2023/08/08 13:22:44 INFO: wazuh-wui 172.26.0.7 "GET /decoders/files/local_decoders.xml" with parameters {"raw": "true", "relative_dirname": "etc/decoders/custom_dir"} and body {} done in 0.034s: 200
2023/08/08 13:23:03 INFO: wazuh-wui 172.26.0.7 "PUT /decoders/files/local_decoders.xml" with parameters {"overwrite": "true", "relative_dirname": "etc/decoders/custom_dir"} and body {} done in 0.031s: 200
2023/08/08 13:23:03 INFO: wazuh-wui 172.26.0.7 "GET /cluster/status" with parameters {} and body {} done in 0.021s: 200
2023/08/08 13:23:04 INFO: wazuh-wui 172.26.0.7 "GET /cluster/configuration/validation" with parameters {} and body {} done in 1.250s: 200
2023/08/08 13:23:04 INFO: wazuh-wui 172.26.0.7 "GET /cluster/status" with parameters {} and body {} done in 0.030s: 200

Result:

• file etc/decoders/local_decoders.xml is removed
• file etc/decoderes/custom_dir/local_decoders.xml is edited with the new content

The same problem is happening for rules.

root@wazuh-manager-460-7102:/var/ossec/etc# tree decoders
decoders
|-- custom_dir
|   `-- local_decoders.xml
`-- local_decoders_custom.xml
root@wazuh-manager-460-7102:/var/ossec/etc# cat decoders/custom_dir/local_decoders.xml
<!-- Local Decoders -->

<!-- Modify it at your will. -->
<!-- Copyright (C) 2015, Wazuh Inc. -->

<!--
  - Allowed static fields:
  - location   - where the log came from (only on FTS)
  - srcuser    - extracts the source username
  - dstuser    - extracts the destination (target) username
  - user       - an alias to dstuser (only one of the two can be used)
  - srcip      - source ip
  - dstip      - dst ip
  - srcport    - source port
  - dstport    - destination port
  - protocol   - protocol
  - id         - event id
  - url        - url of the event
  - action     - event action (deny, drop, accept, etc)
  - status     - event status (success, failure, etc)
  - extra_data - Any extra data
-->

<decoder name="local_decoder_example_edited">
    <program_name>local_decoder_example_edited</program_name>
</decoder>

For another hand, if having the same files, and I edit the file etc/decoders/local_decoders.xml,

root@wazuh-manager-460-7102:/var/ossec/etc# tree decoders
decoders
|-- custom_dir
|   `-- local_decoders.xml
|-- local_decoders.xml
`-- local_decoders_custom.xml
root@wazuh-manager-460-7102:/var/ossec/etc# cat decoders/local_decoders.xml 
<!-- Local Decoders -->

<!-- Modify it at your will. -->
<!-- Copyright (C) 2015, Wazuh Inc. -->

<!--
  - Allowed static fields:
  - location   - where the log came from (only on FTS)
  - srcuser    - extracts the source username
  - dstuser    - extracts the destination (target) username
  - user       - an alias to dstuser (only one of the two can be used)
  - srcip      - source ip
  - dstip      - dst ip
  - srcport    - source port
  - dstport    - destination port
  - protocol   - protocol
  - id         - event id
  - url        - url of the event
  - action     - event action (deny, drop, accept, etc)
  - status     - event status (success, failure, etc)
  - extra_data - Any extra data
-->

<decoder name="local_decoder_example_edited_2">
    <program_name>local_decoder_example_edited_2</program_name>
</decoder>

• file etc/decoders/local_decoders.xml is edited with the new content
• file etc/decoders/custom_dir/local_decoders.xml is untouched

root@wazuh-manager-460-7102:/var/ossec/etc# cat decoders/local_decoders.xml 
<!-- Local Decoders -->

<!-- Modify it at your will. -->
<!-- Copyright (C) 2015, Wazuh Inc. -->

<!--
  - Allowed static fields:
  - location   - where the log came from (only on FTS)
  - srcuser    - extracts the source username
  - dstuser    - extracts the destination (target) username
  - user       - an alias to dstuser (only one of the two can be used)
  - srcip      - source ip
  - dstip      - dst ip
  - srcport    - source port
  - dstport    - destination port
  - protocol   - protocol
  - id         - event id
  - url        - url of the event
  - action     - event action (deny, drop, accept, etc)
  - status     - event status (success, failure, etc)
  - extra_data - Any extra data
-->

<decoder name="local_decoder_example_edited_2">
    <program_name>local_decoder_example_edited_2</program_name>
</decoder>
root@wazuh-manager-460-7102:/var/ossec/etc# cat decoders/custom_dir/local_decoders.xml 
<!-- Local Decoders -->

<!-- Modify it at your will. -->
<!-- Copyright (C) 2015, Wazuh Inc. -->

<!--
  - Allowed static fields:
  - location   - where the log came from (only on FTS)
  - srcuser    - extracts the source username
  - dstuser    - extracts the destination (target) username
  - user       - an alias to dstuser (only one of the two can be used)
  - srcip      - source ip
  - dstip      - dst ip
  - srcport    - source port
  - dstport    - destination port
  - protocol   - protocol
  - id         - event id
  - url        - url of the event
  - action     - event action (deny, drop, accept, etc)
  - status     - event status (success, failure, etc)
  - extra_data - Any extra data
-->

<decoder name="local_decoder_example_edited">
    <program_name>local_decoder_example_edited</program_name>
</decoder>

[Desvelao]

The problem commented here #5176 (comment) was confirmed by an API co-worker. They will work in a fix.

For another hand, I added the features to update and delete the files using the relative_dirname query parameter of the endpoints.

We will block the issue until the fix related to the problem found is patched. Then we should check the problem is not happening anymore.

[Tostti]

PR successfully closed