Supress rule wazuh

[Brenno Garcia]

Hello,
I would like to create a suppression rule even if pfSense sends many enabled IPSec tunnels.

My actual rules:

<rule id="100030" level="3">
    <decoded_as>openvpn-pfsense-ipsec</decoded_as>
    <status>^installing</status>
    <description>IPSec Tunel $(tunel) enabled on PfSense $(hostname)</description>
</rule>

<rule id="100031" level="3">
    <decoded_as>openvpn-pfsense-ipsec</decoded_as>
    <status>uninstalling</status>
    <description>IPSec Tunel $(tunel) disabled on PfSense $(hostname)</description>
</rule>

<rule id="100032" level="3" timeframe="1">
    <if_matched_sid>100030</if_matched_sid>
    <same_field>tunel</same_field>
    <description>multiplos logs do tunel $(tunel) IPSec habilitado</description>
</rule>

<rule id="100033" level="3" timeframe="1">
    <if_matched_sid>100031</if_matched_sid>
    <same_field>tunel</same_field>
    <description>multiplos logs do tunel $(tunel) IPSec desabilitado</description>
</rule>

<rule id="100034" level="0" frequency="5" timeframe="1">
    <if_matched_sid>100030</if_matched_sid>
    <same_field>host</same_field>
    <description>5 ou mais Túneis IPSec habilitados em 1 segundo no PfSense $(host) — possível restart do serviço IPsec</description>
</rule>

Everything works perfectly, except for rule '100034'.
When rule 100030 is triggered 5 times, rule 100034, which should suppress the alerts, is activated. However, this rule does not maintain suppression for subsequent alerts. Therefore, if 20 IPsec tunnel alerts are dropped, the suppression rule will only be triggered 4 times and rule 100030 will be triggered 16 times.

I would like to suppress the alerts after 5 drops on the same host in 1 second (which likely means an IPsec restart).

I created another rule to trigger based on
if_sid -> 100034

if_matched_sid ->100030

but still doesnt work

[Eli Josue Rodriguez]

Hi, what you are seeing is expected behavior in Wazuh’s rule engine.

The rule 100034 is not actually “suppressing” subsequent alerts, it is only generating a new alert (with lvl 0) when the frequency condition is met.

Wazuh does not maintain a suppression state after a correlation rule fires. The frequency + timeframe logic only controls when the rule itself triggers, but it does not block or silence future matches of 100030.

That iss why:

• After 5 events -> 100034 fires once
• But 100030 continues triggering for the remaining events

Your approach with chaining (if_sid / if_matched_sid) won’t work either, because Wazuh rules are stateless beyond the aggregation window,  there is no concept of “mute after trigger”.

A cleaner way to handle burst scenarios (like IPsec restarts) is to invert the logic: make the base rule silent and only alert on the aggregated condition.

For example:

<rule id="100030" level="0">

    <decoded_as>openvpn-pfsense-ipsec</decoded_as>
    <status>^installing</status>

</rule>

<rule id="100034" level="5" frequency="5" timeframe="1">

    <if_matched_sid>100030</if_matched_sid>
    <same_field>host</same_field>

    <description>Possible IPsec restart detected on $(host)</description>
</rule>

With this approach, the individual tunnel events won’t generate alerts and a burst of 5+ events in 1 second will generate a single meaningful alert.

Of course, this depends on whether that behavior fits your use case. If you still need visibility on individual events, then you’ll probably need to rethink the rule design, since Wazuh doesn’t support true post-trigger suppression.