Fix limit parameter in GET sca check endpoint and Fix odd offset issue when paginating wdb queries

[mcarmona99]

Related issue
#5878

Hi team,

The next changes were also posted in the PR #6064, but it needed to be closed due to a change on the base branch. Due to the odd offset issue when paginating, these changes are going to be merged into 4.0.

This PR is related to the issue #5878 . This PR is solving the limit parameter problem as well as the odd offset issue when paginating wdb queries (last commit).

For the first problem, I have changed the limit parameter behavior in GET /sca/{agent_id}/checks/{policy_id} endpoint.

Before the changes, the limit parameter was not working as expected, when you set the limit to 3 (as an instance), the rules and compliances of every check were counted to reach to that limit.

New behavior, different than the one proposed in the issue, when you set the limit to 3, you will get 3 different checks and all the rules and compliances corresponding to these 3 checks.

CHANGES:

• API integration test cases added/updated. File field in the json response for sca check test had to be removed because it is not always returned. After the changes to the endpoint, for agent 001, policy_id cis_debian9_L1 and limit 1, File is not returned, as an instance.

• Function descriptions adapted to numpydoc format.

• In wdb.py, I have used wildcards in order to know where are the limit and offset parameter. This change will make future queries easier to do as wdb.py used to add limit and offset parameters at the end of the query, which could be wrong sometimes (in this case, for instance).

• Limit and offset parameters were deleted when removing where keyword in query -> updated regex in wdb.py in order to make it more appropriate.

Test results:

• API integration tests:

test_rbac_black_sca_endpoints.tavern.yaml 
	 2 passed, 4 warnings

test_rbac_white_sca_endpoints.tavern.yaml 
	 2 passed, 4 warnings

test_sca_endpoints.tavern.yaml 
	 6 passed, 8 warnings

• Unit tests, all core and SDK tests are passing, showing test_sca.py:

pytest framework/wazuh/tests/test_sca.py 
============================== 7 passed in 0.31s ===============================

Example of the new behavior:

• Request:
  curl -X GET "https://localhost:55000/sca/000/checks/cis_debian9_L2?limit=3" -H "accept: application/json" -H "Authorization: Bearer $TOKEN" -k

• Response:

{
   "data": {
      "affected_items": [
         {
            "reason": "",
            "file": "/etc/ssh/sshd_config",
            "result": "failed",
            "description": "The X11Forwarding parameter provides the ability to tunnel X11 traffic through the connection to enable remote graphic connections.",
            "title": "Ensure SSH X11 forwarding is disabled",
            "condition": "all",
            "remediation": "Disable X11 forwarding unless there is an operational requirement to use X11 applications directly. There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server. Note that even if X11 forwarding is disabled, users can always install their own forwarders.",
            "id": 3528,
            "policy_id": "cis_debian9_L2",
            "status": "",
            "rationale": "Disable X11 forwarding unless there is an operational requirement to use X11 applications directly. There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server. Note that even if X11 forwarding is disabled, users can always install their own forwarders.",
            "compliance": [
               {
                  "key": "cis_csc",
                  "value": "9.2"
               },
               {
                  "key": "cis",
                  "value": "5.2.6"
               }
            ],
            "rules": [
               {
                  "type": "file",
                  "rule": "f:/etc/ssh/sshd_config -> !r:^# && r:X11Forwarding\\s+no"
               }
            ]
         },
         {
            "reason": "",
            "result": "failed",
            "description": "Set system audit so that audit rules cannot be modified with auditctl. Setting the flag \"-e 2\" forces audit to be put in immutable mode. Audit changes can only be made on system reboot.",
            "title": "Ensure the audit configuration is immutable",
            "directory": "/etc/audit",
            "condition": "all",
            "remediation": "Add the following line to the end of the /etc/audit/audit.rules file: -e 2. Notes: This setting will ensure reloading the auditd config to set active settings requires a system reboot.",
            "id": 3527,
            "policy_id": "cis_debian9_L2",
            "status": "",
            "rationale": "In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. Users would most likely notice a system reboot and that could alert administrators of an attempt to make unauthorized audit changes.",
            "compliance": [
               {
                  "key": "cis_csc",
                  "value": "6.2,6.3"
               },
               {
                  "key": "cis",
                  "value": "4.1.18"
               }
            ],
            "rules": [
               {
                  "type": "directory",
                  "rule": "d:/etc/audit"
               },
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules -> r:^\\s*\\t*-e 2$"
               },
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules"
               }
            ]
         },
         {
            "reason": "",
            "result": "failed",
            "description": "Monitor the loading and unloading of kernel modules. The programs insmod (install a kernel module), rmmod (remove a kernel module), and modprobe (a more sophisticated program to load and unload modules, as well as some other features) control loading and unloading of modules. The init_module (load a module) and delete_module (delete a module) system calls control loading and unloading of modules. Any execution of the loading and unloading module programs and system calls will trigger an audit record with an identifier of \"modules\".",
            "title": "Ensure kernel module loading and unloading is collected",
            "directory": "/etc/audit",
            "condition": "all",
            "remediation": "For 32 bit systems add the following lines to the /etc/audit/audit.rules file: -w /sbin/insmod -p x -k modules | -w /sbin/rmmod -p x -k modules | -w /sbin/modprobe -p x -k modules | -a always,exit -F arch=b32 -S init_module -S delete_module -k modules. For 64 bit systems add the following lines to the /etc/audit/audit.rules file: -w /sbin/insmod -p x -k modules | -w /sbin/rmmod -p x -k modules | -w /sbin/modprobe -p x -k modules | -a always,exit -F arch=b64 -S init_module -S delete_module -k modules. Notes: Reloading the auditd config to set active settings may require a system reboot.",
            "id": 3526,
            "policy_id": "cis_debian9_L2",
            "status": "",
            "rationale": "Monitoring the use of insmod, rmmod and modprobe could provide system administrators with evidence that an unauthorized user loaded or unloaded a kernel module, possibly compromising the security of the system. Monitoring of the init_module and delete_module system calls would reflect an unauthorized user attempting to use a different program to load and unload modules.",
            "compliance": [
               {
                  "key": "cis",
                  "value": "4.1.17"
               },
               {
                  "key": "cis_csc",
                  "value": "5.1"
               }
            ],
            "rules": [
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules -> r:^-a && r:always,exit|exit,always && r:-F arch=b64 && r:-S init_module && r:-S delete_module && r:-k modules"
               },
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules -> r:^-w && r:/sbin/modprobe && r:-p x && r:-k modules"
               },
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules -> r:^-w && r:/sbin/insmod && r:-p x && r:-k modules"
               },
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules -> r:^-w && r:/sbin/rmmod && r:-p x && r:-k modules"
               },
               {
                  "type": "directory",
                  "rule": "d:/etc/audit"
               },
               {
                  "type": "file",
                  "rule": "f:/etc/audit/audit.rules"
               }
            ]
         }
      ],
      "total_affected_items": 29,
      "total_failed_items": 0,
      "failed_items": []
   },
   "message": "All selected sca/policy information was returned"
}

Regards,
Manuel.