Rule only works for limited number of events

[Roman]

Hello!

I have linux server with auditd configured, and I have alerts, that I want to lower, because they are related to scheduled backup task. Launch of backup task is in different event.

Main rule is 110070. It's quite simply relates to audit key susp_activity.

  <rule id="110070" level="12">
    <if_sid>80700</if_sid>
    <field name="audit.key">susp_activity</field>
    <description>Possible suspicious activity - $(audit.command) executed</description>
    <group>audit_command,</group>
  </rule>

Then I have a rule to detect launch of rsync task

  <rule id="120034" level="3">
    <if_sid>80792</if_sid>
    <field name="audit.execve.a1">^/home/backup/rsync-incremental-backup-remote.sh$</field>
    <description>Backup task. Not a threat.</description>
  </rule>

And then I try to lower all events in 20 minute (1200 seconds) window
  <rule id="120035" level="5" timeframe="1200">
    <if_sid>110070</if_sid>
    <if_matched_sid>120034</if_matched_sid>
    <field name="audit.euid_name">^backup$</field>
    <description>Backup task. Not a threat.</description>
  </rule>

But for some reason it works only with the first 7 events and then stops.

Is this expected behavior? Could you please help us with setting up the rule?

[Stuti Gupta]

Hi @roman

The rule you created with id 120035 is a correlation rule with a timeframe. This means Wazuh will try to link events from rule 110070 with the last event that matched rule 120034 within the 1200-second. However, Wazuh does not keep reusing the same 120034 event for the entire 20 minutes.
After a few matches, the stored correlation not work and new 110070 events no longer meet the correlation condition. That is why this works only for the first several alerts, and then it stops.

If you want all 110070 alerts generated during the backup period to be lowered for the full 20 minutes, you need a different approach. We can either rewrite the rule so it continues matching for the whole window or adjust the logic so it does not rely on if_matched_sid.

To know more about the custom rules, please refer to https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

I can help you create a corrected rule if you share the exact matching pattern you want to apply to all backup-related events.

[Roman]

Hi, thank you for quick response

> If you want all 110070 alerts generated during the backup period to be lowered for the full 20 minutes

Yes, I would like to lower all events if possible.

>  We can either rewrite the rule so it continues matching for the whole window or adjust the logic so it does not rely on if_matched_sid.

Please explain both, I'm new to wazuh and this was the only pattern I could see. If you see other approach, I'm open to suggestions. 

>  share the exact matching pattern you want to apply to all backup-related events

Not quite clear what you mean. 

Current pattern (as I see it): 

- Detect event with argument "/home/backup/rsync-incremental-backup-remote.sh" (it's usually comes in 'audit.execve.a1' field) in event 'audit-wazuh-c' (event 80792);

- Since sh-script contains ssh/scp commands, lower all events related to that key (event 110070).

- It's scheduled task, so it happens from 22:00 and ends roughly at 22:15, so I chose 20 minute window.

I couldn't find any markers in 110070 event to lower it.

[Stuti Gupta]

Hi Roman,

I tested a correlation setup similar to yours, and I can now explain clearly why your rule works for the first several events and then stops.

Wazuh correlation rules do not maintain a continuous “session” for the entire timeframe. The timeframe only defines how long a previous matching event is considered valid when evaluating each new event. The correlation is event-driven, not persistent. If any other rule or unrelated event is processed between your correlated events, or the expected rule won't trigger for a few minitues the original matched SID is no longer considered part of the active chain, and the correlation logic breaks. This is why the first few occurrences of rule 110070 match rule 120035, but once other logs appear, the chain resets and 110070 events no longer meet the correlation conditions, even if that happens inside the 20-minute timeframe.

Based on this behavior, there are only a few practical options:

Ensure that no other events are processed between the correlated events so that the chain is not broken. In most real environments, this is not feasible because any additional alert can interrupt the correlation flow.

Reduce the correlation timeframe to a much smaller value. This only works if the backup script runs for a short. 

If the backup always runs at a fixed time, you can avoid correlation entirely and instead create time-based rules that lower the severity of rule 110070 during that specific window. Like :
<rule id="170030" level="3">
   <if_sid>110070</if_sid>
  <time>18:00-18:20</time>

   <description>Backup task. Not a threat.</description>
</rule>

Note: Make sure server time is synced with the system time.

Refer to https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#time

[Roman]

Hi, 

Thank you for detailed answer. 

As you said, in a real environment, it is not possible to ensure, that the chain is not broken. 

I like the idea with time window. Could you please tell me which time should we use in the rule? Wazuh server is working in UTC, but server with auditd is in GMT +3 (and we can't use UTC there). Should we use time on Wazuh or time on the server? 

Also, is it possible to link correlation to the event 120034(launch of backup script)? Using just the time window seems a bit vague for the exception, in my opinion. 

[Stuti Gupta]

Hi Roman,

You need to use the time of the Wazuh manager, not the time of the auditd server.

The <time> tag in Wazuh rules is evaluated based on the manager’s local system time at the moment the event is processed. It does not use the timestamp inside the log, and it does not use the timezone of the monitored server.

Since your Wazuh server is running in UTC, the time window in the rule must also be written in UTC.

First, make sure the Wazuh manager is using the correct system timezone configuration. You can align it with the system timezone using:

mv /var/ossec/etc/localtime /var/ossec/etc/localtime.BACKUP
cp /etc/localtime /var/ossec/etc/localtime
chown root:wazuh /var/ossec/etc/localtime
service wazuh-manager restart

After that, define the rule using the UTC that corresponds to your backup window.

For example, if the backup runs from 04:48 to 05:10 UTC, the rule should be:

<rule id="120035" level="5">

    <if_sid>110070</if_sid>
    <time>04:48-05:10</time>

    <description>Backup task. Not a threat.</description>
</rule>

If your backup runs in GMT+3, you must convert that time to UTC before writing it in the rule.

Regarding linking the exception to event 120034: In practice, correlation based on a triggering event is not reliable in busy environments because other alerts can interrupt the correlation chain. A fixed time window is more stable and predictable, especially for scheduled tasks like backups.

Refer to https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#time

[Roman]

Hi,

Ok. Got it, will try to use <time>

One more question. If backup task is happening once a week or once in a 6 days, can we write a rule to exclude events in that time window?

[Stuti Gupta]

You can use the <weekday> syntax as described here:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#weekday

You can create the rule like this:

<rule id="120035" level="5">
    <if_sid>110070</if_sid>
    <time>04:48-05:10</time>

    <weekday>monday</weekday>

    <description>Backup task. Not a threat.</description>
</rule>

[Roman]

Hi,

Yes, for once a week its good, but what if we have a task with period in days: once in 2 days, once in 6 days? Do we have a solution for that in syntax?

[Stuti Gupta]

Hi Roman,

Wazuh rules only support two types of time conditions. You can define a time with the <time> tag, and you can specify days of the week with the <weekday> tag.

No rule syntax in Wazuh allows schedules like “every 2 days”, “every 6 days”, or any other interval-based schedule. 

Because of this limitation, if a task runs every few days but not on fixed days, Wazuh cannot represent that schedule directly in a rule. In those cases, you usually need to rely on a fixed time window or handle the exception outside of the ruleset.