Closed rafabailon closed 3 days ago
I have done some first tests to check the functionality of the new logic. The results seem as expected and without errors in the logs.
To use the new simulator class, you must add the -m vulnerability
parameter. Additionally, I have added the following parameters: --vulnerability-legacy-messages
, --vulnerability-batch-size
and --vulnerability-packages-list-file
.
The code is similar to that used for syscollector
with changes to adapt the logic to generate vulnerability events and not use anything that is not necessary.
The tests have been done locally. I have used the generator locally and a Ubuntu 22.04 VM with 2 cores and 4GB of RAM for the tests. I have enabled logall
and have reviewed the ossec logs and archives, the simulator's own logs, and the simulated agent databases to ensure that all information appears as it should.
Note: there is the possibility of adding a parameter to decide if the events should be INSERTED or DELETED. It currently uses the syscollector functionality but a parameter can be added to choose one or both of the options. If you choose both, you could alternate or distribute the number of events between the two options (all INSERTED are sent and then all DELETED).
For the parameter with the vulnerabilities file, it is necessary to leave it as "default=None" since the path depends on where the simulator is being used. In the vulnerability generating class, the correct path is obtained in case of not receiving any file by parameter.
I have also refactored the entire code. I have created a Generator
class with all the common functionality of the syscollector and vulnerability generator. Now the two classes inherit from Generator
, thus avoiding duplicate code.
I have carried out tests for both generators and have been able to verify that they work correctly. In some cases I have detected an error. If this is the first time you run the simulator, you may get an error as if the osinfo
was not sent. This does not happen in successive tests. I need to do more tests in case the problem is due to the simulation time (which needs to be longer) or there is a problem after the refactoring.
After several tests, I have been able to verify that the errors I detect when using the simulator are caused by the simulation time. The default value of -t
is 60. If we modify this value, depending on the number of agents, some agents may fail. I have tried different combinations of -n
and -t
. With a -t
of between 40 and 60 seconds, I have found no problems.
Currently testing in real environment
I have made the suggested changes. I have also fixed some errors in the code comments to avoid confusion. I have repeated all the tests to make sure it is still working correctly.
Description
When using the class to generate syscollector packages, no vulnerabilities are generated since the class is not intended for this use. It is possible to make vulnerabilities work by using the agent simulator parameters.
To avoid misusing the syscollector generator, the
GeneratorVulnerabilityEvents
class has been created. This class generates syscollector packets for the purpose of generating vulnerabilities.Related to https://github.com/wazuh/wazuh-qa/issues/5222
Testing Performed
For testing, it is possible to use the agent simulator locally using the command
simulate-agents -a xxx.xx.x.xx -n 1 -m vulnerability -s 5 -t 12 -o debian10 -v 4.8.0 --debug
. The logs corresponding to the vulnerabilities that the simulator generates using the new class should appear in the Wazuh manager.