Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVEs alerts inventory for Vulnerability Detector - Vulnerability Detector Integration Tests #1261

Closed
DProvinciani opened this issue Apr 29, 2021 · 3 comments · Fixed by #1496

Comments

@DProvinciani
Copy link
Contributor

DProvinciani commented Apr 29, 2021

Description

As part of the epic wazuh/wazuh#7749, we implemented a mechanism to have an inventory of the CVEs that affect each agent in which the Wazuh agents are installed. This epic changed the way in which the Vulnerability Detector generates alerts as well. Here some key points of the epic:

  • Depending on the trigger of the Vulnerability detector scan, we could have three scan types: BASELINE, PARTIAL_SCAN, and FULL_SCAN.
  • Each scan type will behave in different ways on the alert generation.
  • There is a new alert type generated when a vulnerability no longer affects an agent because of a package upgrade/removal.
  • The vulnerabilities could be in three different states in the inventory: VALID, PENDING, OBSOLETE, and REMOVED.
  • There is a new setting called min_full_scan_interval, and the setting ignore_time was removed.

For details of all these key points to be taken into account in the test design and implementation, check the description section of the epic.

Update 10/28/2021

After discussing with the QA team, and taking into account the new guidelines, we decided to implement the next set of improvements in this set of tests:

It is being evaluated also the possibility of unifying some of the scan results tests that seem to be repeated.

@BraulioV
Copy link
Contributor

BraulioV commented May 13, 2021

Tasks

  • Deprecation of the test_general_settings_ignore_time.py
  • Rework the vulnerability_detector.py module:
    • Run queries to wazuh-db.
    • Mock the new scan types.
  • Rework of the test_scan_results. These tests now must check by running a query to the vuln_cves table if the vulnerability was added to the inventory. These tests must run in a FULL scan scenario.
  • New tests implementation:
    • Configuration test for min_full_scan_interval.
    • BASELINE scans: no alert must be generated.
    • PARTIAL_SCAN: no alert must be generated for already scanned packages.
    • FULL_SCAN: after the database has been updated with new information, the newly detected vulnerabilities and the ones that no longer affect the agent will be alerted.
    • Vulnerability removal: if a vulnerability is removed from the inventory, a new alert must be triggered.

Working branch: 1261-cve-alerts-inventory

@spothound spothound assigned mdengra and spothound and unassigned BraulioV May 17, 2021
@spothound
Copy link
Contributor

spothound commented May 18, 2021

Progress

5/18/21

  • Start working on this. We need to start by reworking vulnerability_detector.py to use queries to wazuh-db instead of to SQLite
  • Minor fixes in test_general_settings_enabled
  • I'm currently exploring with the query_wdb function and making queries to wazuh_db with python sockets to be able to understand how we should approach this rework.
  • I'm improving the query_wdbfunction so it better handles wrong-formated queries or missing/empty responses from the servers.

image

5/19/21

  • Continue testing new database structure and required changes to vulnerability detector database queries

How to make queries to sys_programs tables

This would not work, why?

In [13]: query_wdb('SELECT * FROM SYS_PROGRAMS;')
Out[13]: "err Invalid DB query actor: 'SELECT'"

Example of valid query:

In [17]: query_wdb('global get-agent-info 001;')
Out[17]: 
[{'id': 1,
  'name': 'focala',
  'ip': '10.0.2.15',
  'register_ip': 'any',
  'internal_key': '9c52e922abfc11d4d4492664c41930374eb88ec02151d9d2366f0120d382a399',
  'os_name': 'Ubuntu',
  'os_version': '20.04.2LTS',
  'os_major': '20',
  'os_minor': '04',
  'os_codename': 'FocalFossa',
  'os_platform': 'ubuntu',
  'os_uname': 'Linux|focala|5.4.0-70-generic|#78-UbuntuSMPFriMar1913:29:52UTC2021|x86_64',
  'os_arch': 'x86_64',
  'version': 'Wazuhv4.3.0',
  'config_sum': '317424e6ffbf787d1010ef2f7d141192',
  'merged_sum': '1ef663be907b1c00a8ea0da66223bc25',
  'manager_host': 'focal',
  'node_name': 'node01',
  'date_add': 1621348921,
  'last_keepalive': 1621413924,
  'group': 'default,maintenance',
  'sync_status': 'synced',
  'connection_status': 'active'}]

Reference to #1243 for more info about valid queries.

UPDATE: it seems that the problem is not with the query itself but with the answer length. The answer in some queries is too long to be sent in a single socket message and it is split. We need to modify our query method to handle this.

Testing query: query_wdb('agent 001 sql SELECT * FROM sys_programs')

UPDATE: Wed May 19 11:08:02 UTC 2021
We've experimented with some problem with query answer's pagination. We've been in a meeting with the framework team and they've confirmed that currently, most of the WDB queries are not prepared (at the core side) to chuck messages into TCP-allowed-size messages. If the answer from WDB to a query is bigger than 65K (max TCP message size) it is cropped and the entire answer cannot be retrieved.

We need a way to paginate the queries to the DB but it doesn't make any sense to write such code because this problem has already been handled by the framework team for the Wazuh python framework.

We've been discussing this and we've decided to find a way to install the Wazuh's framework package into our testing environments so we could use all the developed functions from there.

5/21/21

In [2]: from wazuh_testing.wazuh_db import query_wdb
In [3]: query_wdb('agent 001 sql SELECT * FROM sys_programs')

When trying to run this kind of queries there is a problem (described in #1357) with the answer length. We've decided that this is a good moment to start integrating the Wazuh Python framework into our QA tests for some task that has already been coded by our framework team such as retrieval of this kind of information from wazuh_db.

We/'re reviewing the status of those test that doesn't require big changes to keep working, such as general setting tests on the #1360 issue.

We've added some improvements to the wdb query method on this commit 701cddd to avoid errors due to the above-mentioned issue with long answer or responses that are not in JSON format.

TODO

VD module changes

  • clean_vd_tables
  • insert_package
  • insert_vulnerability

@spothound spothound added the Epic label May 21, 2021
@DProvinciani
Copy link
Contributor Author

Closing the issue as the pull #1496 was merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants