Suppress Default Wazuh Rules Using CDB-Based Custom Rule

[Muhammad Ali Khan]

Dear All

I am working on a use case in Wazuh where I want to implement a custom rule that triggers for a specific agent while suppressing/bypassing all default rules for that agent. The idea is to use a CDB list to maintain agent names. When an agent in this list generates any event, only the custom rule should trigger, and all default Wazuh rules should be bypassed or suppressed. The purpose of using the CDB list is to make this scalable: in the future, we can simply add a new agent name to the list, and the same behavior will apply automatically, without creating new rules for that agent or modifying multiple parent/child default rules. However, in practice, even after adding the agent names to the CDB list and referencing it in the custom rule, the default rules are still being triggered, and the custom rule is not overriding the default rules. What is the best way to implement it in a professional and maintainable manner?  

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

Hi Muhammad,

I think the best approach is to use Wazuh agent grouping and configure the agent.conf file to disable the modules you don't need. After deployment, you can also remove the default localfile configurations from those agents.

Another option would be to overwrite the default rules to include a CDB list, but if your goal is to suppress everything for that specific agent, you'd end up overriding a lot of default rules. That can get difficult to maintain pretty quickly.

Overwrite existing rules

For example, you can use the <hostname> tag to add agent names, or else you can create a CDB list and add the list into hostname tag.
<list field="hostname">etc/lists/list-user</list>

For example:

1. <group name="syslog,sshd,">
2.   ...
3.   <rule id="5710" level="5" overwrite="yes">
4.     <if_sid>5700</if_sid>
5.     <match>illegal user|invalid user</match>
6.     <list field="hostname">etc/lists/list-user</list>
7.     <description>sshd: Attempt to login using a non-existent user</description>
8.     <mitre>
9.       <id>T1110</id>
10.     </mitre>
11.     <group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
12.   </rule>
13.   ...
14. </group>

Then you need to add the CDB list to the Wazuh manager ossec.conf file inside the ruleset tag.

Create a group (example: maintenance) and assign the agents to it. Wazuh supports grouping agents specifically so you can apply group-wide config. 
Wazuh agent grouping

In the group’s centralized config (agent.conf), disable or reduce the modules that produce most alerts (Syscheck, SCA, rootcheck, etc.). Centralized config exists exactly for this use case and scales well.
However, for localfile log collections, you need to remove them from the agent side ossec.conf file.

This way, the “default rules” won’t fire because the default log paths and modules are disabled for those agents. That’s the only truly global, low-effort suppression method.

Let me know the update on this.

[Muhammad Ali Khan]

Thank you dear, i will test it and let you know, 

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/81eec10b-1a76-4fd5-8063-53e07c613824n%40googlegroups.com.

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

Hi Muhammad,

Let me know if you need further assistance on this. So we can check further. Thanks!

[Muhammad Ali Khan]

Dear thank you for your concern 

I tried so much but failed,  So guide me to suppress all default alerts for specific agents during maintenance or other, without disabling or removing the agents. The agents must remain active and continue sending logs, but I want to stop all default rule alerts and related email notifications only for selected agents.

I have already tried both approaches:

• CDB list with custom rules

• Agent group with custom rule overrides

While custom rules are loading correctly but default alerts are still being triggered. Overriding individual rule IDs is not scalable due to the large number of parent and child rules involved.

Is there an officially supported and recommended way to implement maintenance mode for specific agents? If there are any best practices or practical guidance for this scenario, please advise.

To view this discussion visit https://groups.google.com/d/msgid/wazuh/81157c67-4f6b-41db-a187-cf589682320cn%40googlegroups.com.

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

Hi Muhammad Ali

There's no official guide that covers exactly what you're looking for. However, overwriting rules for a specific agent isn't really recommended, as I mentioned earlier, it becomes very difficult to maintain since you'd need to modify a lot of rules.
Here are the two options I mentioned:
Option 1: Overwrite existing rules to exclude specific agents using a CDB list
This isn't recommended because it's really hard to maintain over time.

Option 2: Use agent groups and disable modules, and comment out the log collections

If you have multiple agents that need this setup, create an agent group and add those agents to it. Then, in the group's centralized configuration (agent.conf), you can disable or reduce the modules that generate the most alerts - things like Syscheck, SCA, and Rootcheck.
Keep in mind that even after disabling modules in the agent.conf file, you'll still need to manually comment out the localfile configurations in each agent's local ossec.conf file. You can define localfile configurations in agent.conf, but you can't disable existing localfiles from the group config.
Here's what you'd add to the agent.conf file to disable those modules for the specific agents:

1. <syscheck>
2.     <disabled>yes</disabled>
3. </syscheck>
4.  
5. <sca>
6.     <enabled>no</enabled>
7. </sca>
8.  
9. <rootcheck>
10.     <disabled>yes</disabled>
11. </rootcheck>

Ref: Wazuh agent grouping

After that, comment out the localfile configurations on the agent side ossec.conf file like below.

1. <!--
2.  <localfile>
3.     <log_format>journald</log_format>
4.     <location>journald</location>
5.   </localfile>
6.  
7.   <localfile>
8.     <log_format>syslog</log_format>
9.     <location>/var/ossec/logs/active-responses.log</location>
10.   </localfile>
11.  
12.   <localfile>
13.     <log_format>syslog</log_format>
14.     <location>/var/log/dpkg.log</location>
15.   </localfile>
16. -->

This approach is cleaner and easier to manage than overwriting individual rules.

[Muhammad Ali Khan]

Dear 

Thank you for your guidance, but I have attempted to implement the approaches you suggested for suppressing alerts for specific agents during maintenance. I created a dedicated agent group Maintenance and configured the agent.conf to disable modules (Syscheck, Rootcheck, SCA, Syscollector, Vulnerability Detector) and ignore Windows event channels (Security, System, Application).

Could you please advise on the official recommended approach or any practical guidance to ensure complete suppression of default rules during maintenance?

Practical 


root@cloud-virtual-machine:/var/ossec/etc/shared/Maintenance# ls
agent.conf  merged.mg
root@cloud-virtual-machine:/var/ossec/etc/shared/Maintenance# /var/ossec/bin/agent_groups -l
Groups (2):
  Maintenance (1)
  default (1)
Unassigned agents: 0.
root@cloud-virtual-machine:/var/ossec/etc/shared/Maintenance# cat agent.conf
<agent_config>

  <!-- Disable File Integrity Monitoring -->

  <syscheck>
    <disabled>yes</disabled>
  </syscheck>

  <!-- Disable Rootcheck -->

  <rootcheck>
    <disabled>yes</disabled>
  </rootcheck>

  <!-- Disable SCA -->

  <sca>
    <enabled>no</enabled>
  </sca>

  <!-- Disable Syscollector -->
  <wodle name="syscollector">
    <disabled>yes</disabled>
  </wodle>

  <!-- Disable Vulnerability Detector (causes Rule 220 error) -->
  <wodle name="vulnerability-detector">
    <disabled>yes</disabled>
  </wodle>

  <!-- Windows: Ignore Security events -->
  <localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
    <ignore type="sregex">.*</ignore>
  </localfile>

  <!-- Windows: Ignore System events -->
  <localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
    <ignore type="sregex">.*</ignore>
  </localfile>

  <!-- Windows: Ignore Application events -->
  <localfile>
    <location>Application</location>
    <log_format>eventchannel</log_format>
    <ignore type="sregex">.*</ignore>
  </localfile>

</agent_config>
root@cloud-virtual-machine:/var/ossec/etc/shared/Maintenance# sudo tail -f /var/ossec/logs/alerts/alerts.json | jq 'select(.agent.name=="user-ali")'
{
  "timestamp": "2026-02-19T09:42:14.946+0500",
  "rule": {
    "level": 3,
    "description": "Windows Logon Success",
    "id": "60106",
    "mitre": {
      "id": [
        "T1078"
      ],
      "tactic": [
        "Defense Evasion",
        "Persistence",
        "Privilege Escalation",
        "Initial Access"
      ],
      "technique": [
        "Valid Accounts"
      ]
    },
    "firedtimes": 23,
    "mail": false,
    "groups": [
      "windows",
      "windows_security",
      "authentication_success"
    ],
    "pci_dss": [
      "10.2.5"
    ],

To view this discussion visit https://groups.google.com/d/msgid/wazuh/b3e9e245-a163-4ae9-88be-5613f5dcfc04n%40googlegroups.com.

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

Hi Muhammad

You can exclude all Windows logs. If the agent is a Windows machine, you can comment out the parent Windows rule reference with the decoder so it won't match Windows logs. (This setting is for globally applying for all agents.)

Edit the rule file:

nano /var/ossec/ruleset/rules/0575-win-base_rules.xml

Then modify rule 60000 like this:

1. <rule id="60000" level="0">
2. <!-- <category>ossec</category>
3. <decoded_as>windows_eventchannel</decoded_as> -->
4.  <field name="win.system.providerName">\.+</field>
5.  <options>no_full_log</options>
6.  <description>Group of windows rules.</description>
7. </rule>

Restart the Wazuh manager to apply the changes:

systemctl restart wazuh-manager

Since all Security, Application, and System rules are based on parent rule ID 60000, breaking the condition of this parent rule will ignore all Windows logs. This is probably the cleanest way to exclude Windows logs at the rule level.

Just keep in mind that this exclusion will affect all Windows agents, not just one. Make sure to note the original configuration so you can roll it back if needed.

I also tried adding a configuration in agent.conf to collect Security event channel logs with a dummy query to avoid logs:

1. <localfile>
2.  <location>Security</location>
3.  <log_format>eventchannel</log_format>

1.  <query>Event/System[EventID=0002]</query>
2. </localfile>

However, this didn't work as expected - it showed duplicate log collection warnings and still read the eventchannel logs from the agent's ossec.conf file.

Therefore, for specific hosts, I suggest you comment out the localfile configurations in the Wazuh agent's ossec.conf file as I mentioned above.

Let me know if you need further assistance on this. Thanks!