noalert question

[Ronald Simmons]

I have written what I thought was a simple rule 

<group name="juniper,rtflow,firewall,">
  <rule id="100010" level="3">
    <field name="policy-name">DENY_ALL</field>
    <field name="reason">Denied by policy</field>
    <description>Juniper RT_FLOW session denied $(srcip):$(source-port) to $(destination-address):$(destination-port) policy $(policy-name)</description>
  </rule>

  <rule id="100011" level="10" frequency="8" timeframe="120" ignore="60">
    <if_matched_sid>100010</if_matched_sid>
    <description>RTFLOW DENY Policy: 8 Registered Events in 2 Minutes</description>
  </rule>

  <rule id="100012" level="3">
    <field name="sub-category">Shopping</field>
    <description>User Shopping $(srcip):$(source-port) to $(destination-address):$(destination-port) Site $(nested-application)</description>
  </rule>
 
  <rule id="100013" level="3">
    <field name="nested-application">EVASIVE-PROTOCOL</field>
    <description>Evasive Protocol Detected $(srcip):$(source-port) to $(destination-address):$(destination-port) Method $(nested-application)</description>
  </rule>

  <rule id="100014" level="3">
    <field name="nested-application">CHROME-REMOTE-DESKTOP</field>
    <description>Remote Desktop Site Detected $(srcip):$(source-port) to $(destination-address):$(destination-port) Method $(nested-application)</description>
  </rule>
 
  <rule id="100011" level="10" frequency="8" timeframe="120" ignore="60">
    <if_matched_sid>100010</if_matched_sid>
    <description>RTFLOW DENY Policy: 8 Registered Events in 2 Minutes</description>
  </rule>
</group>

as written all rule id's generate alerts but what I would like to do is suppress alerts for rule id="100010" and still get alerts for rule id="100011" but when I use noalert="1" on 100010 it also stops 100011. I'm trying to clean up the alerts because 100010 generates thousands of alerts per hour.

Any help would be greatly appreciated

[hasitha.u...@wazuh.com]

Hi Ronald,

Please allow me some time; I’m currently looking into this and will get back to you with an update as soon as possible.

[hasitha.u...@wazuh.com]

It seems the real issue isn't how noalert behaves; it's actually in the rule file itself.

You've got rule 100011 written twice (it's pasted in there identically). When Wazuh loads rules and finds two with the same ID, it doesn't merge them, it just creates a conflict, and that's almost certainly what's messing with the if_matched_sid correlation once you add noalert to 100010. So first thing, just remove that duplicate block:

1. <group name="juniper,rtflow,firewall,">
2.   <rule id="100010" level="3" noalert="1">

1.     <field name="policy-name">DENY_ALL</field>
2.     <field name="reason">Denied by policy</field>
3.     <description>Juniper RT_FLOW session denied $(srcip):$(source-port) to $(destination-address):$(destination-port) policy $(policy-name)</description>
4.   </rule>
5.  
6.   <rule id="100011" level="10" frequency="8" timeframe="120" ignore="60">
7.     <if_matched_sid>100010</if_matched_sid>
8.     <description>RTFLOW DENY Policy: 8 Registered Events in 2 Minutes</description>
9.   </rule>
10.  
11.   <rule id="100012" level="3">
12.     <field name="sub-category">Shopping</field>
13.     <description>User Shopping $(srcip):$(source-port) to $(destination-address):$(destination-port) Site $(nested-application)</description>
14.   </rule>
15.  
16.   <rule id="100013" level="3">
17.     <field name="nested-application">EVASIVE-PROTOCOL</field>
18.     <description>Evasive Protocol Detected $(srcip):$(source-port) to $(destination-address):$(destination-port) Method $(nested-application)</description>
19.   </rule>
20.  
21.   <rule id="100014" level="3">
22.     <field name="nested-application">CHROME-REMOTE-DESKTOP</field>
23.     <description>Remote Desktop Site Detected $(srcip):$(source-port) to $(destination-address):$(destination-port) Method $(nested-application)</description>
24.   </rule>

1. </group>
   

Rule tag usage

Quick note on why noalert should still let if_matched_sid work fine. noalert just stops the rule from getting written into alerts.log or alerts.json. It doesn't stop the rule from matching behind the scenes, and that internal match is what if_matched_sid actually relies on, not whether it alerted. So once the duplicate is gone, 100010 should stay silent while 100011 keeps triggering normally off it.

Another option is to drop the rule level below 3 on 100010; that way it still won't show up on the dashboard since anything under level 3 gets ignored by default.

Rule classification

If 100011 is still not firing properly after adding noalert to 100010, go ahead and share some sample logs with me so I can replicate it on my end and put together more accurate rules for you. Let me know how it goes.

[Ronald Simmons]

I apologize the rule isn't actually written twice I was trying something when I posted and accidentally had it pasted at the bottom when I posted I was moving it to the bottom to see if the order made a difference, it didn't. Since I couldn't update my post I had to wait for a reply to explain. It realy looks like this

<group name="juniper,rtflow,firewall,">
  <rule id="100010" level="3">
    <field name="policy-name">DENY_ALL</field>
    <field name="reason">Denied by policy</field>
    <description>Juniper RT_FLOW session denied $(srcip):$(source-port) to $(destination-address):$(destination-port) policy $(policy-name)</description>
  </rule>

  <rule id="100011" level="10" frequency="8" timeframe="120" ignore="60">
    <if_matched_sid>100010</if_matched_sid>
    <description>RTFLOW DENY Policy: 8 Registered Events in 2 Minutes</description>
  </rule>

  <rule id="100012" level="3">
    <field name="sub-category">Shopping</field>

    <description>User Shopping $(srcip):$(source-port) to $(destination-address):$(destination-port) Nested Application $(nested-application)</description>

  </rule>
 
  <rule id="100013" level="3">
    <field name="nested-application">EVASIVE-PROTOCOL</field>
    <description>Evasive Protocol Detected $(srcip):$(source-port) to $(destination-address):$(destination-port) Method $(nested-application)</description>
  </rule>

  <rule id="100014" level="3">
    <field name="nested-application">CHROME-REMOTE-DESKTOP</field>
    <description>Remote Desktop Site Detected $(srcip):$(source-port) to $(destination-address):$(destination-port) Method $(nested-application)</description>
  </rule>
</group>

[Ronald Simmons]

I'm Sorry I replied to soon without reading the bottom

I tried theses settings in 100010

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

<rule id="100010" level="1">

<rule id="100010" level="2">
<rule id="100010" level="0" noalert="1">

They all have the same result 100011 produces no alerts

On Tuesday, June 30, 2026 at 12:44:51 AM UTC-5 hasitha.u...@wazuh.com wrote:

[hasitha.u...@wazuh.com]

Hi Ronald,

Apologies for the delay. I wanted to correct my previous statement after performing some additional testing.

I replicated the behavior using different log samples with the same rule logic and found that when noalert is set to 1, the rule does not generate an alert and is also not processed for rule correlation. As a result, a child rule using if_matched_sid will not be triggered because the parent rule is not considered during correlation.

For this scenario, instead of using noalert="1", you can configure the parent rule with level="2". This allows the rule to be processed for correlation while preventing it from generating a visible alert, and the second rule will continue to work as expected. I tested this configuration, and it works correctly.

1. <rule id="100010" level="2">

1.  <field name="policy-name">DENY_ALL</field>
2.  <field name="reason">Denied by policy</field>
3.  <description>Juniper RT_FLOW session denied $(srcip):$(source-port) to $(destination-address):$(destination-port) policy $(policy-name)</description>
4. </rule>
5.  
6.  <rule id="100011" level="10" frequency="8" timeframe="120" ignore="60">
7.  <if_matched_sid>100010</if_matched_sid>
8.  <description>RTFLOW DENY Policy: 8 Registered Events in 2 Minutes</description>
9. </rule>

Please let me know if you need any further assistance.

[Ronald Simmons]

Setting it to level="2" also stops it from processing 100011 do I need to adjust my ossec.conf ?

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>12</email_alert_level>
  </alerts>