Wazuh + pfsense

[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).

[Olamilekan Abdullateef Ajani]

Hello,

That rule, 100034, will trigger when it sees 5 events in 1 second as it should per what you configured, but it does not actually stop or suppress rule 100030. Wazuh keeps processing incoming logs normally, so it just keeps counting again and firing more alerts just as you have seen.

If your goal is to reduce the noise during those bursts (like when IPsec restarts), what you can do is to use the ignore option on your base rule.

For example:

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

    <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>

This means the rule with ID 100034 triggers a level 1 alert if rule 100030 matches 5 times within 3 seconds. To prevent floods, it is ignored for 20 seconds after triggering.

Please let me know if this works for you.
Ref:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#rule:~:text=the%20rule%20matches.-,Example%3A,-%3Crule%20id%3D

[Brenno Garcia]

Hello,

This rule didn't work for me

The alert for connection 'con4' was suppressed, but the rest was not.
Does the ignore not apply to rule 100034 itself? That is, rule 100034 itself was disabled by the ignore. However, without ignore, it is only triggered when the frequency drops 5 times, then it goes to 0 and needs to drop another 5 times.

[Brenno Garcia]

hello

any help?

[Olamilekan Abdullateef Ajani]

Hello Brenno,

Apologies for the delayed response. Yes, that is correct. The ignore applies only to rule 100034 itself. What happens is that rule 100034 detects the burst of events coming from 100030, triggers once based on the configured frequency/timeframe, and then ignores additional matches for itself during the ignore period.

However, rule 100030 continues to fire independently, as you already noticed. The ignore does not suppress or mute the parent/base rule.

What you can do instead is make the base rule 100030 silent by setting it to level="0" that way, 100030 still exists for correlation purposes, but it no longer generates visible alerts on its own. Then 100034 becomes the main visible alert whenever 5 or more tunnels are detected within the timeframe.

The challenge with this is that you lose the individual tunnel alerts during normal activity as well, not only during bursts. The limitation here is that correlation rules cannot dynamically mute another rule stream after a threshold is reached. Once the correlation rule triggers, processing goes back to the base rule again for subsequent events.

So in this case, I would suggest redesigning the logic around a silent base rule and building the correlation alerts from there.

Regards,