realert setting seems to send two alerts

[roman-tasi]

It seems to omit the alerts it should but sends two when it should send one. For example if I get 5 hits in the docker logs, it will send 2 alerts instead of 1 (but did successfully not send all 5). I notice this behavior quite frequently, any idea how to fix it? Also I can confirm the timeframe for the realert setting is encompassing all the logs/alerts (so like the extra alert being sent isn't out of the scope of the specified time).

[jertel]

If you can attach some sanitized debug logs showing it sending both, that might help in tracking down why it's sending two.

[roman-tasi]

Unfortunately I'm not getting much help out of those logs, unless you spot something that I can't.

[jertel]

It looks like it is silencing at least some of the matches during the second rule run (we observe the "Ignoring match..." line prior to the line stating that an alert was sent), but then it still shows alerts being sent. This could happen if you're using query_keys, since it will silence the matches per query-key within the rule, rather than by overall rule. Check your rule configuration for that setting.

[roman-tasi]

This is the portion of the rule that may be relevant to this. Can you review it?

filter:
- query:
    bool:
      must:
      - term:
          winlog.event_id: 4624
      - term:
          winlog.event_data.LogonType: 7
index: account-access-*
realert:
 seconds: 5
query_key: winlog.event_data.TargetUserName

Also I get that it is silencing the match, but that's what I want anyway. I don't get why I'm getting the second alert though in some cases.

It seems to be corresponding to this from the logs:
6 query hits (4 already seen), 2 matches, 1 alerts sent
8 query hits (6 already seen), 2 matches, 1 alerts sent

So like it successfully sent only 1 alert for the 2 matches, but it did this two times thus resulting in two alerts? Is my line of thought correct here?

[jertel]

That's correct. And since you are using a query_key it will only silence the alert for that query_key value. So if another username appears a minute later, yes it will send another alert, since that username hasn't been silenced yet.