Offline vulnerability detection - Disk Space and where can i see Update Condition

[MaP]

Hi everbody,

I use Wazuh version 4.9.0 and, since the server has no direct connection to the Internet, I use the offline vulnerability function.

Now the storage space consumption has increased significantly. 

This is understandable, as Wazuh certainly has to keep the information from the update feed in a database.
However, the *json files in /var/ossec/queue/vd_updater/tmp/contents do not seem to be deleted. Is that correct?
I currently see 3 json files there.Since the files there are all about 3GB in size, the space consumption is of course quite high.

Ich habe in der Doku dazu nichts gefunden lediglich diesen Issue Artikel in Git https://github.com/wazuh/wazuh/issues/24243 which sys, that old files "should be deleted automatically after being processed".  

How do I find out what's going wrong?

I also have another question that might help me understand the above problem.
How can I check what update status the vulnerability signatures on my system are on?

Thank you in advance for your support

Greetings

MaP

[hasitha.u...@wazuh.com]

Hi MaP,

The Vulnerability Detection module generates alerts when it detects new vulnerabilities or when a vulnerability is fixed due to a package update, removal, or system upgrade.
Ref: https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html

The vulnerability index (wazuh-vulnerabilities) typically contains less data compared to the alerts.json index (wazuh-alerts-*), because it primarily stores information about detected vulnerabilities, which is not as frequent or voluminous as alert data.
The wazuh-vulnerabilities index is typically a single index rather than a time-series index like wazuh-alerts-*

Regarding /var/ossec/queue/vd_updater/tmp/contents,  It should be deleted automatically after being processed. But yes, it can be removed once the manager is stopped.

Regarding your last query, you can find active vulnerabilities by navigating to Threat Intelligence -> Vulnerability Detection -> - Inventory.
To update the vulnerability information on the Wazuh server, the vulnerability detection module queries the CTI API or an offline local repository. It retrieves new documents and compares them to the existing ones to identify any differences.

Next, the module scans the software inventory of the endpoints using the latest available vulnerability information. The detection process looks for vulnerable packages in the inventory databases. These inventories are unique to each agent.

A package is marked as vulnerable when its version falls within the affected range of a CVE. The module generates alerts to display the results, and the findings are stored in a general vulnerability inventory. This inventory is filterable by agent and contains only unresolved vulnerabilities. Users can query the inventory to review alerts and details about vulnerabilities.
The Vulnerability Detection module generates alerts when it detects new vulnerabilities or when a vulnerability is fixed due to a package update, removal, or system upgrade.

Regards,
Hasitha Upekshitha

[Gabriel Emanuel Valenzuela]

Hi MaP! Hope you're doing well.

Could you let me know the steps you’re following for the offline update? Has this behavior started happening recently?

Additionally, could you share the ossec.log file with me so I can review it? Please make sure to hide any sensitive information before sharing.

Have a great day!

[MaP]

Hi Hasitha,

ok, thanks so far.

My actual question is/was, can I see what status the vulnerability module or the downloaded CVE information is at? In other words, when were vulnerability updates last downloaded? Can I see the snapshot version or snapshot date of the vulnerability signature somewhere in the dashboard??

Then the problem with the files in /var/ossec/queue/vd_updater/tmp/contents. How can I find out why the files are not deleted automatically?

It doesn't seem to make much sense to me to always delete them by hand.

Regards

MaP

[Gabriel Emanuel Valenzuela]

Hi MaP! Hope you're doing well.

My actual question is/was, can I see what status the vulnerability module or the downloaded CVE information is at? In other words, when were vulnerability updates last downloaded?

This information should be available in the ossec.log. Each time a content update is performed, the ossec.log records the current offset. To check this more effectively, we can enable debug mode (Addig wazuh_modules.debug=2 on /var/ossec/etc/internal_options.conf), restart the manager, and then look for the relevant entries in the log.

---

Can I see the snapshot version or snapshot date of the vulnerability signature somewhere in the dashboard?

Unfortunately, this is not currently possible through the dashboard. However, we can use the ldb tool (RocksDB’s database access utility) to explore the local database and retrieve the current offset information for the vulnerability signature.

---

Then the problem with the files in /var/ossec/queue/vd_updater/tmp/contents. How can I find out why the files are not deleted automatically?

Is the module functioning as expected? Have you checked for any errors or warnings in the ossec.log? These logs can provide insights into why the files may not be deleted automatically.

---

Let me know if you need further assistance or clarification!

Nice day!

[MaP]

Hello Gabriel,

Unfortunately, I replied to your first post privately and then our replies overlapped.

In the end, I replied that I couldn't see any errors in the ossec.log. The vulnerability module reports that everything is OK when it is updated.

We use a distributed system and I checked all Wazuh managers/worker nodes.
My question is, I entered the following on all worker nodes and the manager:

 <vulnerability-detection>
   <enabled>yes</enabled>
   <index-status>yes</index-status>
   <feed-update-interval>2h</feed-update-interval>
   <offline-url>https://internal-server-which-has-the-cve-img</offline-url>
  </vulnerability-detection>

Is that correct or do I just have to enter it in the manager?

at this point thanks for the great support here in the mail group!

Regards 

MaP

Gabriel Emanuel Valenzuela schrieb am Dienstag, 7. Januar 2025 um 17:42:25 UTC+1:

Hi MaP! Hope you're doing well.

[Gabriel Emanuel Valenzuela]

Hi MaP! Hope you're doing well.

The configuration needs to be applied to all nodes, including both workers and the master. Since the databases are not part of a distributed system, if an agent connects to a worker with an outdated database offset, it will be scanned using old information.

To ensure everything works correctly, please make sure the configuration follows the steps outlined here (https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/offline-update.html).

Let me know if you have any questions or need further assistance!

[MaP]

Hi Gabriel,

i have to reopen my Thread.

I can now confirm once again that vulnerability update files do not appear to be deleted cleanly.
I now have two update files on all servers in the cluster under /var/ossec/queue/vd_updater/tmp/contents directory
The ossec.log for the corresponding day does not show any errors:

2025/01/13 14:20:08 wazuh-modulesd:syscollector: INFO: Evaluation finished.
2025/01/13 14:26:35 wazuh-modulesd:vulnerability-scanner: INFO: Initiating update feed process.
2025/01/13 14:47:46 wazuh-modulesd:vulnerability-scanner: INFO: Triggered a re-scan after content update.
2025/01/13 14:47:46 wazuh-modulesd:vulnerability-scanner: INFO: Feed update process completed.
2025/01/13 15:20:09 wazuh-modulesd:syscollector: INFO: Starting evaluation.
2025/01/13 15:20:18 wazuh-modulesd:syscollector: INFO: Evaluation finished.

This is what it looks like on all servers in the cluster.

I am currently working on wazuh version 4.9.0 and could currently upgrade to 4.9.2. The question is, is the behavior better there or will it stay the same.

I'll have to see if I can try it out with a test machine. Maybe you have the option of testing it?

Regards

MaP

[Gabriel Emanuel Valenzuela]

Hi MaP!

Let me do some tests and I'll be back ASAP :) 

[Gabriel Emanuel Valenzuela]

Hi MaP! Hope you're doing well.

Apologies for the delay. I conducted some tests and was able to confirm this behavior. We’ve created an issue for further research: Wazuh Issue #27691.

As a temporary solution, you can avoid restarting the manager and manually delete the file inside the tmp/content directory.

Please let me know if this workaround resolves the issue for you!

[MaP]

hi Gabriel,

 that sounds good! 

Until the changes are implemented in the system, the workaround of a manager restart is enough for me! 

thanks and best regards

MaP