Repeated Triggering of Same Rule, Multiple Machines

[J Stein]

Hi Everyone,

I have a fresh wazuh setup, with two agents: one Deb11, one RHEL.

For reasons I am unable to work out, rule 80705​​​: "Auditd: Configuration Changed"​​​ triggers repeatedly, about every two minutes, across both machines.

I've tried checking the logs on both machines, the details on each event, and I'm all out of ideas. Here's what the details of one of those events looks like:

I've attached a json file of one of those events to this message as well.

Any ideas on what's causing this, and what I can do to prevent this from showing up so much? I don't want to hide auditd config changes entirely in case their modification becomes relevant in case of an intrusion, but there's so many of them flooding the alerts as to make the alerts menu unusable.

Thanks!

Jason

[Christian Bassey]

Hi J Stein,

Thank you for using Wazuh!

From the screenshot, it looks like a scheduled process (/opt/osquery/bin/osqueryd) is running frequently with an unset AUID. The AUID is typically set when a user logs into an endpoint. This means that the events generating these alerts are not caused by user-generated events, but by a scheduled process like a cronjob or service. 

Can you share the steps/guide you followed to configure auditd rules?

To suppress these alerts, add the following rule in your local_rules.xml file:

<rule id="100305" level="2">
    <if_sid>80705</if_sid>
    <match>AUID=\"unset\"</match>
    <description>Suppressed configuration change alert.</description>
</rule>

The rule above suppresses alerts done by cron jobs where the AUID is unset.

Please let me know if this helps. Best.

[J Stein]

Hi,

Unfortunately, I don't think muting the alert will work for my use case. I want to know if changes are being made to the audit configuration (the rules being changed or turned off for example), so while I could just overwrite the rule and set "level=0" that's not exactly desired for my use case.

The guide I followed to set up auditd is this one, from the wazuh docs:

https://documentation.wazuh.com/current/learning-wazuh/audit-commands.html

The wazuh install I'm testing this on is a fresh one, with auditd installed almost exactly following what that guide describes, with very minor changes (that shouldn't affect this error).

But, the alert that's showing up in the event map doesn't show up in my audit.rules, and isn't a rule I'm currently overwriting/changing.

Any ideas on what service could be triggering that alert, and how I could prevent it? When I created this exact same setup a few months ago (we install the agents & configure them using a script), I wasn't running into this kind of log flooding, but for some reason it's showed up in the last 3 lab installs I've made of wazuh.

Thanks,

Jason

------- Original Message -------

--
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 on the web visit https://groups.google.com/d/msgid/wazuh/f0774835-69da-4910-b3cf-a3c06f810eabn%40googlegroups.com.

[Christian Bassey]

Hi J Stein,

From the logs you shared, the service triggering the alert is  /opt/osquery/bin/osqueryd. 

The rule I provided above would not mute all audit alerts. It would only mute alerts where the auid=unset (these alerts are caused by cronjobs, scheduled processes, and services). So, you would still get audit alerts for all other auid's you are monitoring.

Is it possible that in the audit rules the auid is set to -1? Please share the output of the command below:

auditctl -l

NB: You can mask any auids that are not -1 or  4294967295 before sending me the output as this is a public forum.

[J Stein]

The rules I have are all public anyways, so I see no need to sensor them; especially in the case that it ends up being helpful for someone from search results at a later date :)​.

The top few are from the wazuh guides on auditd setup, and the bottom ones are obviously for syscheck stuff.

# auditctl -l

-w /etc/passwd -p wa -k passwd_changes

-w /sbin/insmod -p x -k module_insertion

-a always,exit -F arch=b32 -S unlink,rename,unlinkat,renameat -F auid>=500 -F auid!=-1 -F key=delete

-a always,exit -F arch=b64 -S rename,unlink,unlinkat,renameat -F auid>=500 -F auid!=-1 -F key=delete

-a always,exit -S setresuid -F euid=0 -F key=audit-wazuh-c

-a always,exit -F arch=b32 -S execve -F egid!=994 -F auid!=-1 -F key=audit-wazuh-c

-a always,exit -F arch=b64 -S execve -F egid!=994 -F auid!=-1 -F key=audit-wazuh-c

-w /bin -p wa -k wazuh_fim

-w /boot -p wa -k wazuh_fim

-w /etc -p wa -k wazuh_fim

-w /etc/cron.d -p wa -k wazuh_fim

-w /etc/cron.daily -p wa -k wazuh_fim

-w /etc/cron.hourly -p wa -k wazuh_fim

-w /etc/cron.monthly -p wa -k wazuh_fim

-w /etc/cron.weekly -p wa -k wazuh_fim

-w /etc/crontab -p wa -k wazuh_fim

-w /home -p wa -k wazuh_fim

-w /root -p wa -k wazuh_fim

-w /sbin -p wa -k wazuh_fim

-w /usr/bin -p wa -k wazuh_fim

-w /usr/sbin -p wa -k wazuh_fim

auditd itself is in mode 1, if that matters at all to this. From what I can see, the rules themselves are checking to make sure the auid isn't -1, so I'm honestly not sure what the issue could be.

If you see anything I'm missing, please let me know. Thanks!

Jason

------- Original Message -------

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/f852526e-b861-44d5-a240-5208abcc0d59n%40googlegroups.com.

[Christian Bassey]

Hi J Stein, 

I just tried these audit rules in my lab (1 Ubuntu 22.04 agent and 1 Wazuh manager). I did not get these alerts flood.

Do you have osquery installed? The event you provided showed that some of the alerts were being generated by an osquery daemon.

Please provide more alert samples so we can dig deeper.

[J Stein]

Hi Christian,

Thanks for all your help so far, I really appreciate it. I'm going to provide as much relevant info as I can, and we'll see what we need from here.

(sidenote: this is an entirely new wazuh lab installation from the one I started this thread with, so I'm guessing (?) that the issue is somewhere in my configuration, which has stayed the same).

I have the rule loaded into my local_rules.xml​, as seen here:

(sidenote: do you need to reload the wazuh-manager service before you can test rule changes using wazuh-logtest? I've been restarting it but I'm not sure if it's needed). 

Here's the wazuh-logtest​ output from me trying to trigger that rule:

Starting wazuh-logtest v4.3.9

Type one log per line

type=CONFIG_CHANGE msg=audit(1667871080.337:40052): op=set audit_pid=19778 old=16601 auid=4294967295 ses=4294967295 subj==unconfined res=0^]AUID="unset"

**Phase 1: Completed pre-decoding.

        full event: 'type=CONFIG_CHANGE msg=audit(1667871080.337:40052): op=set audit_pid=19778 old=16601 auid=4294967295 ses=4294967295 subj==unconfined res=0AUID="unset"'

**Phase 2: Completed decoding.

        name: 'auditd'

        parent: 'auditd'

        audit.id: '40052'

        audit.res: '0AUID="unset"'

        audit.type: 'CONFIG_CHANGE'

**Phase 3: Completed filtering (rules).

        id: '80705'

        level: '3'

        description: 'Auditd: Configuration changed.'

        groups: '['audit', 'audit_configuration']'

        firedtimes: '1'

        gdpr: '['IV_30.1.g']'

        gpg13: '['10.1']'

        mail: 'False'

**Alert to be generated.

​

As you can see, I've made some modifications of my own to try and get the rule to work; unfortunately, neither trying it in it's original form nor with the modifications I've tried have yielded any success.

I've also attached several json events to this email in a txt file. These are all different events, but despite that look very similar.

You mentioned osquery, so I went and dug through my osquery config file.

The only lines with relevance to auditd were in the "options" section, and for reference I've just included that entire section.

{

    "options": {

        "config_plugin": "filesystem",

        "logger_plugin": "filesystem",

        "logger_path": "/var/log/osquery",

        "disable_logging": "false",

        "pidfile": "/var/osquery/osquery.pidfile",

        "disable_events": "false",

        "disable_audit": "false",

        "audit_allow_config": "true",

    "audit_persist": "true",

    "audit_allow_process_events": "true",

    "audit_allow_fim_events": "true",

    "audit_allow_user_events": "true",

    "audit_allow_sockets": "true",

        "schedule_splay_percent": "10",

        "database_path": "/var/osquery/osquery.db",

        "utc": "true",

        "worker_threads": "3"

    },

​

I've sent my entire audit.rules file in this thread already, so I won't include that again.

Let me know if you see anything that might be causing the issue, and have any idea why I might be getting that same "configuration changed" error every 2 minutes.

Best,

Jason

------- Original Message -------

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/CAKVKe60D%3DA-m%3DoFCpp-MdKM%3DbDtGidvOmx5YxwsoFky6wYeOyw%40mail.gmail.com.

[Christian Bassey]

Hi J Stein,

Do you have another rule 10305? Why are you overwriting it?

You can use the rule below to suppress the alerts:

<rule id="100305" level="2">
    <if_sid>80705</if_sid>
    <match>AUID=\"unset\"</match>
    <description>Suppressed configuration change alert.</description>
</rule>

(sidenote: do you need to reload the wazuh-manager service before you can test rule changes using wazuh-logtest? I've been restarting it but I'm not sure if it's needed). 

Yes, you need to restart the manager before testing rule changes. 

I am looking at your osquery audit configuration and would provide you with feedback shortly.

[Christian Bassey]

Hi J Stein,

Can you disable audit_allow_process_events https://osquery.readthedocs.io/en/stable/deployment/process-auditing/ and let me know if you still have this large amount of logs.

[J Stein]

Hi Christian,

As far as overwriting the rule goes, I was trying a multitude of different things trying to get it to work - the rule I sent was with some of those modifications I made. I (obviously) tried it exactly as you sent it, and it unfortunately didn't work in that form either. For the record, there is no other rule 10305.

I tried disabling audit_allow_process_events in the osquery.conf, unfortunately no luck there either.

Any other ideas?

Best,

Jason

------- Original Message -------

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/CAKVKe636wLi%3DJBvW9PZQ-UqzEZQoYgUjuwE9CC-OvgxgzyHbpg%40mail.gmail.com.

[Christian Bassey]

Hi J Stein, 

As we discussed, using the default Wazuh configurations for osquery in the link below stops the log flood:
- https://documentation.wazuh.com/current/user-manual/capabilities/osquery.html?highlight=osquery
- https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/wodle-osquery.html

I would try to troubleshoot with your setup and let you know what I find.