Vulnerability Detection is not working as expected in Demo environment #23322
Comments
Rebits
changed the title
T1: Basic Vulnerability Detection
DescriptionInitially, the Demo environment comprised a RHEL and a Debian agent. Vulnerability scans on these agents did not detect any vulnerabilities. However, the remaining agents exhibited triggered vulnerabilities.
Note No vulnerabilities were detected for RHEL agent Upon assessing the current status of the manager, it was observed that removing and re-registering the agents resolved the issue.
It's likely that the reported errors are specifically related to the re-scan mechanism. This will be further investigated in the T2 cases. After a few hours, after restraint manager and worker several times for other tests cases, vulnerabilities were detected for RHEL but not for Debian agent:
|
T2: Assess Vulnerability Detection Re-Scan Behavior 🔴
DescriptionIn an environment where all agents are linked and Vulnerability Detection is actively running, our next steps involve disabling the Vulnerability Detection module. We'll initiate this process via the dashboard, starting with the worker nodes and then proceeding to the master node. Subsequently, we'll undertake the crucial task of backing up agents's client keys and then removing them from both Debian and RHEL agents. Before removal, we'll ensure to rename them within the configuration settings as 'RHEL-4' and 'Debian-4' respectively. Once the client keys are secured and renamed, we'll proceed to register the agents in the environment with the Vulnerability Detection disabled. Following this, as the agents reconnect, we'll re-enable the Vulnerability Detection module seamlessly ResultsAfter enabling the vulnerability detector module again, after 1:30 hours, vulnerabilities of new agents appear: Debian
RHEL
However several issues were detected:
|
No existing agent's vulnerabilities found in index 🔴DescriptionAfter registering new agents in the environment, we observed the following list of agents registered:
However, upon removing the default wazuh.cluster.name filter, vulnerabilities were detected for a non-existing Ubuntu agent with wazuh.cluster.name value set to 2:
The exact registration time of this old agent cannot be provided due to the previous use of a Demo instance. However, it has been more than 1 day since registration. Steps to ReproduceNo steps to reproduce can be provided for now due this agent was already present in the environment Expected BehaviorNo vulnerabilities should be detected for non-existing agents. |
Vulnerabilities of some agents disappear suddely 🔴Note After researching this issue, it seems directly related to #23322 (comment) DescriptionNo vulnerabilities were detected in Debian and RHEL9 agents during testing. These agents were initially deployed in the environment and replicating the same conditions with new agents proved unsuccessful, suggesting a unique setup at the environment's inception. Various scenarios were tested, including:
Despite these efforts, the absence of vulnerabilities remains consistent, hinting at specific conditions present at the environment's outset After toggling the vulnerability detection module on both the master and worker nodes, please allow approximately 30 minutes for the expected vulnerabilities to manifest.
Few minutes later, vulnerabilities were automatically deleted Steps to ReproduceNo steps to reproduce can be provided for now due this agent was already present in the environment Expected behaviourVulnerability scan should detect vulnerabilities for all agents without the need of disabling and enabling vulnerability detection module. |
Index unstable when vulnerability detection module is disabled and enabled again 🔴DescriptionThe vulnerabilities index seems to be unstable after enabling and disabling the vulnerability detection module in master and worker nodes.
Videovuln_dissapear.webmSteps to reproduce
Expected behaviorVulnerability index should be stable in case of enabling and disabling the vulnerability detection module. It is expected the removal of the index, although this should be produced only one time, generating vulnerabilities for all the agents. |
Inconsistent wazuh.cluster.name filter 🔴DescriptionThe default setting for the vulnerability detection dashboard incorporates a filter labeled wazuh.cluster.name set to the value "wazuh1". Initially, it appears this filter is not intended for modification. However, it is possible to deactivate this filter and apply negation by accessing the "Change all filters" menu.
Videofilter_inconsistent.webmSteps to reproduce
|
Debian agent includes Windows agent syscheck events 🔴DescriptionDifficult to replicate error appear in the Debian endpoint menu. In the FIM recent events menu appear some Windows agent events
Steps to reproduceNo steps to reproduce can be provided because this issue was impossible to reproduce |
|
LGTM |
1 similar comment
|
LGTM |
Test information
Description
This issue addresses concerns regarding vulnerability detection in the Demo environment. It has been observed that vulnerability detection is not functioning correctly for Debian agents, and there are unexpected behaviors when toggling the vulnerability detection feature. Further investigation is necessary to identify the root causes of these issues.
Problem Statement
Test Requirements
Environment
Access to the Demo environment is necessary. Credentials can be obtained from the devops team .
Configuration
The environment should have enabled the wazuh-modulesd debug mode. This will provide more detailed logs for analysis.
Tests Cases
T1: Basic Vulnerability Detection
Description: Verify if vulnerability detection triggers vulnerabilities for all agents of the Demo Environment, having the vulnerability detection module enabled when agents were registered.
Initial conditions: Initially, vulnerability detection is enabled, and all agents are registered while this module remains active.
T2: Assess Vulnerability Detection Re-Scan Behavior
Description: Verify if re-scan mechanism works as expected when a vulnerability detection is enabled once agents have been already registered.
Initial conditions: At the outset, vulnerability detection remains disabled, and all agents are registered while this module remains in its deactivated state.
Conclusion 🔴
Multiple issues were detected in the demo environment
The text was updated successfully, but these errors were encountered: