New rules that use the same <if_sid> of pre-defined rules don't trigger

[Joaquim António]

Hello Wazuh team, 

I noticed 2 situations where I made a new rule using the same <if_sid> of others, and only the pre-defined rule triggered, For example, there was this postfix rule:

<rule id="3351" level="6" frequency="$POSTFIX_FREQ" timeframe="90">
    <if_matched_sid>3301</if_matched_sid>
    <same_source_ip />
    <description>Postfix: Multiple relaying attempts of spam.</description>
    <mitre>
      <id>T1114</id>
      <id>T1499</id>
    </mitre>
    <group>multiple_spam,pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,nist_800_53_SI.4,tsc_CC7.2,tsc_CC7.3,tsc_CC6.1,tsc_CC6.8,</group>
  </rule>

And I created the following new rule:

<rule id="100010" level="11" frequency="15" timeframe="900">
    <if_matched_sid>3301</if_matched_sid>
    <description>Postfix - A possible security threat detected (554)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failures,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

The latter rule should have been triggered because there were 22 alerts of rule 3301 in under 5mins. A similar problem occurred with another firewall rule we created. Is there anything wrong with the rule, or is this a limitation and we should just override rule 3351 ?

[diego...@wazuh.com]

Hi Joaquim

I see you're experiencing an issue where your custom rule isn't triggering despite meeting the frequency conditions. Let me analyze this situation for you.

In the meantime - which version of Wazuh are you using? Also, could you confirm if both rules are in the same rule file or separate files?

[Joaquim António]

Hello Diego,

Thank you for your help! We are using version 4.12.0-1, and the rules are in separate files (on in the ruleset directory, the other in the etc directory)

[diego...@wazuh.com]

Joaquin thanks for confirming those details!

So you're on version 4.12.0-1 and have the rules in separate files - that's perfect actually, as it confirms exactly what's happening here. The rule in the ruleset directory (3351) loads before your custom rule in the etc directory, which is why it's winning the race every time.

The Root Cause

In Wazuh 4.12, the loading order is:

1. First, all rules from /var/ossec/ruleset/rules/ (where rule 3351 lives)
2. Then your custom rules from /var/ossec/etc/rules/ (where your rule 100010 is)
   
   

But here's the kicker - even though your rule loads after, when Wazuh evaluates frequency rules, it doesn't matter what the loading order is. Once events are counted for one frequency rule (3351 with its 8 events in 90 seconds), those same events won't be counted again for another frequency rule watching the same base rule (3301)

Option 1: Override in local_rules.xml

Since you want stricter thresholds (15 events in 900 seconds vs the default 8 in 90), just override it in your /var/ossec/etc/rules/local_rules.xml:

<rule id="3351" level="6" frequency="$POSTFIX_FREQ" timeframe="90" overwrite="yes">

    <if_matched_sid>3301</if_matched_sid>
    <same_source_ip />
    <description>Postfix: Multiple relaying attempts of spam.</description>
    <mitre>
      <id>T1114</id>
      <id>T1499</id>
    </mitre>
    <group>multiple_spam,pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,nist_800_53_SI.4,tsc_CC7.2,tsc_CC7.3,tsc_CC6.1,tsc_CC6.8,</group>
  </rule>

The beauty of this approach is that you keep the same rule ID (3351), so any dashboards or alerts you have configured won't break.

Option 2: Two-Tier Alerting

Maybe you want a warning at 8 events and a critical alert at 15? You could keep both:

<!-- Let the original 3351 fire at its threshold (8 events in 90 seconds) -->
<!-- Then add your rule watching for multiple 3351 triggers -->

<rule id="100010" level="11" frequency="2" timeframe="900">
    <if_matched_sid>3351</if_matched_sid>
    <same_source_ip />
    <description>Postfix - Critical: Sustained spam relay attempts (Multiple violations)</description>

    <mitre>
        <id>T1110</id>
    </mitre>

    <group>authentication_failures,critical_alert,</group>
</rule>

This gives you escalating alerts

Option 3: Complete Replacement

If you don't need the original logic at all:

<!-- In your local_rules.xml -->
<!-- First, disable the original -->

<rule id="3351" level="0" overwrite="yes">
    <if_matched_sid>3301</if_matched_sid>
    <description>Disabled - Using custom rule 100010 instead</description>
</rule>

<!-- Then your custom rule takes over completely -->

<rule id="100010" level="11" frequency="15" timeframe="900">
    <if_matched_sid>3301</if_matched_sid>

    <same_source_ip />

    <description>Postfix - A possible security threat detected (554)</description>
    <mitre>
        <id>T1110</id>
    </mitre>
    <group>authentication_failures,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

Remember:

After making changes, restart the Wazuh manager:

systemctl restart wazuh-manager

And you can verify your rules loaded correctly:

/var/ossec/bin/wazuh-logtest -v

Then test with actual log samples to see the rule triggering.

Official Documentation for 4.12

Here are the specific docs for your version:

• Wazuh 4.12 Custom Rules - explains the override mechanism
• Understanding Rule Matching in 4.12 - details on how frequency rules work

[Joaquim António]

Hello,

That answers it, thank you!

Best regards,

Joaquim Antonio