App crashes with large rules files

[Deblintrake09]

Wazuh	Elastic	Rev	Security
4.3.6 /4.3.7-2		v4.3.6	Basic

Browser
Chrome

Description
During testing for Issue wazuh/wazuh #3192 related to PR #4405, it was found that when in a cluster environment, when inserting big rules files (~10Mb) on a manager, and trying to restart the cluster the app will go to healthcheck and crash with a Timeout from the API even though the API is still working and responding through console.

Steps to reproduce

1. Navigate to Management/Rules
2. Click Custom rules
3. Modify the local_rules.xml file and save to show restart button.
4. from the console execute the copy.sh bash script provided in the auxiliary files section.
5. Restart the cluster from the restart button on the application
6. Wait for the cluster restarted pop-up
7. Navigate to Management/Rules

Expected Result

1. Cluster should restart and when navigating to the rules section, the rules should be shown and the app work normally

Actual Result

1. The culster restarted pop up appears, and when going to rules it hangs as if loading, and after about 15-20 seconds goes to healthcheck screen, where it tries to load the API and gives a Timeout error. After this, the Application does not work unless the rule files are removed.

Video Evidence

10 Megabytes file with no overwrite in 4.3.6 - 3 copies 🔴

Timeout.436.big.file.mp4

10 Megabytes file with no overwrite in 4.3.7 - 3 copies 🔴

Timeout.437.big.file.-.no.overwrite.mp4

100 Kilobytes file with no overwrite in 4.3.7 - 100 copies 🟢

Timeout.437.small.file.-.no.overwrite.mp4

Auxiliary files

In the linked zip file, you will find:

• copy.sh - bash script used to create copies of the rules file.
• test_rules_file.xml - 10Mb file with no overwrite tag
• test_rules_file_100k.xml - 100Kb file with no overwrite tag
• test_rules_file_100k_overwrite.xml - 100Kb file with overwrite tag

The copy.sh file can be modified to select the rules file source as well as the amount of copies to generate.

Considerations

This has been tested using either a relatively small file ~100Kb with multiple copies (100) where it did not fail, and a big file, with a low amount of copies (3 copies).

• It seems that a big file is causing the issue instead of multiple small files.
• It would be advisable that it is tested in a way to find the exact size where the app breaks, and if adding more small files break the app as well.
• This should be tested to confirm if this also happens with decoders/lists and other files that can be added to the manager.
• This has been tested on the Wazuh-Dashboard. It should be tested on the kibana app as well.