security-auditlog rules

[German DiCasas]

Hi team,

I just added the index  security-auditlog* to see events related to the users that log over web interace of wazuh. I can see the logs right now but at the moment to do a rule It is not working, is not generating the rule id event. The variable to find it is the audit_category that have the FAILED_LOGIN.

<group name= "WEB,">

  <rule id="900050" level="15">
    <field name="audit_category">FAILED_LOGIN</field>
    <description>The user "$(audit_request_effective_user)" FAILED to login</description>
    <group>web-fail,</group>
  </rule>

</group>

What am I missing?

[Felix Bocco]

Hi German,

This is because the security-auditlog-* index pattern is unrelated to the wazuh-alerts-* index pattern. The Wazuh alerts are generated when an event coming from different Wazuh capabilities, is ingested into the manager and then decoded and caught by a rule that generates an alert (according to the minimum log rule level).

Because the security-auditlog-* is generated directly from the OpenSearch engine (built-in the Indexer), it will never pass through the manager. Thus, they won't generate an alert as you expect.

What you can do from the ☰ → Explore → Discover dashboard is select this index pattern, filter by what you want to see (for example, the FAILED_LOGIN) and save the query for future references.

Hope that this approach helps you.

[German DiCasas]

Thanks

There are any way to eleveate any of those event to a rule id? or sent it to the manager (pass through the manager).

Regards,

German

[Felix Bocco]

Hi German,

Consider that the regular way for processing data is MANAGER (Filebeat) → INDEXER (OpenSearch) → DASHBOARD. The audit logs are specific from OpenSearch (because the only way to log who accesses the dashboard is from the indexer that holds users' credentials, etc.), which is part of the Indexer component. The data moves from the manager to the dashboard and not the opposite. Considering this is an OpenSearch option that is created in the indexer stage and that the data flow doesn't go backward, it's hardly possible to do this.

The only way that might work is by retrieving the data through an OpenSearch API call and pasting it into a file. Using a localfile block in the manager /var/ossec/etc/ossec.conf file and then ingest that data. The problem here is that it could be necessary to parse the data first before ingesting it in the manager. Being this the case, you will also need a script to do this after obtaining these events and then it's also possible that you should create decoders and rules. Hence, this is really a complex process.

Additionally, it depends on what you are planning to do with these events. If you need to send them through email, for example, you can use the OpenSearch Alerting module. Maybe, as explained before, with a custom query created, you can monitor what you need. It's important to focus on the objective of the request.