Open misje opened 1 week ago
Hello @misje , could you tell me if the alert.json file has the missing alerts? only vulnerability detector does not have alerts?
Keep in mind that if you force restarts of your agent so that the inventory information is refreshed, by design we will not alert you.
Wait the time after the fix of that update or lower the time in the configuration of your agents for syscollector.
@sebasfalcone take a look on that.
There are alerts in alerts.json. As far as I know, only the vulnerability detector no longer has alerts. Alerts are produced for older clients, but not for newer clients. This is easy to reproduce by running wazuh-client 4.8.0 in a docker image (I tested ubuntu:22.04). Vulnerabilities are detected, but no events are created for when vulnerabilities are detected, nor when they are resolved. Should not this test (running a new agent) produce any events?
In reference to:
Keep in mind that if you force restarts of your agent so that the inventory information is refreshed, by design we will not alert you.
Does this mean that any time a Wazuh agent restarts between the time that that system's software inventory has changed in a vulnerability-impacting way and the next scheduled syscollector self-inventory, that such changes to the vulnerability state will never be accounted for with a vulnerability event? Even if I:
Those would be very common scenarios we really can't afford to skip making events for if we are to trust the new Wazuh vulnerability detection service.
Hello, I had exactly the same issue after upgrading 4.7.5 to 4.8. So I Reinstalled everything on other computers directly in 4.8 and I compared ossec.conf files. I saw that in the reinstalled version the lines below were added at the very end of the file. So I added them, restarted wazuh-manager and all agents, and after some minutes I started receiving vulnerabilities.
Are you having a different issue, perhaps? dpkg.log is present in all of my agents, including 4.8.0. Vulnerability detection works for all of them, old and new, but alerts are not produced for 4.8.0 agents. Alerts are OpenSearch documents with rule.id 23502–23507. That is this issue I'm having.
Oh sorry for my misunderstanding, unfortunately I don't have them either. My apologies.
Are you having a different issue, perhaps? dpkg.log is present in all of my agents, including 4.8.0. Vulnerability detection works for all of them, old and new, but alerts are not produced for 4.8.0 agents. Alerts are OpenSearch documents with rule.id 23502–23507. That is this issue I'm having.
I have the same issue: Vulnerabilities are only listed in index files wazuh-states-vulnerabilities-*
but not in wazuh-alerts-*
. For that reason, the "Events" tab has "no results match the search criteria".
It does not matter which of my clients (on version 4.8) is used. None of them create alerts (as they should, as described in the documentation: https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html#alert-generation).
could you tell me if the alert.json file has the missing alerts?
@Dwordcito and @sebasfalcone - in my case, the alerts are missing completely: In alert.json and alert.log.
In the old vulnerability detector, the alert rules 23502–23507 were created when vulnerabilities were found, and later resolved. This provided important historical information. For instance, in an investigation, the presence of a vulnerability in a given time frame is very useful along with other events.
In the new module, vulnerability state information is kept in a new index, and as far as I can see, documents are removed when vulnerabilities are resolved. Once a vulnerability is resolved, there is no track of it ever being present in the system, unlike in earlier versions of Wazuh. There are no longer any alerts created in wazuh-alerts-* for 4.8.0 agents. Is this intentional? After all, the new Vulnerability Detection interface still has an "Events" tab, which will no longer have any use.
I hope to see vulnerability events back in the alert index. I would prefer them as they were, with all of the CVE context.