Whodata stops working on +3.1 audit versions #19585
Comments
Further analysis:
Wazuh agent is installed following official documentation Configuration is default, and whodata is install following official documentation. ossec.log file indicates some error, but it is not clear: 2023/10/24 20:16:14 wazuh-syscheckd: ERROR: (6636): Cannot connect to socket 'queue/sockets/audit'.
2023/10/24 20:16:14 wazuh-syscheckd: ERROR: Can't init auditd socket in 'init_auditd_socket()'
2023/10/24 20:16:14 wazuh-syscheckd: WARNING: (6913): Who-data engine could not start. Switching who-data to real-time.auditd status does show more information: auditd status
[root@fedora39 logs]# systemctl status auditd
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Tue 2023-10-24 20:16:14 -03; 1min 24s ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 5365 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
Process: 5369 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Main PID: 5366 (auditd)
Tasks: 2 (limit: 2310)
Memory: 1004.0K
CPU: 34ms
CGroup: /system.slice/auditd.service
└─5366 /sbin/auditd
oct 24 20:16:14 fedora39 systemd[1]: Starting auditd.service - Security Auditing Service...
oct 24 20:16:14 fedora39 auditd[5366]: Option builtin_af_unix line 3 is obsolete using /sbin/audisp-af_unix
oct 24 20:16:14 fedora39 auditd[5366]: Option builtin line 4 is obsolete - update it
oct 24 20:16:14 fedora39 auditd[5366]: Unable to stat /sbin/audisp-af_unix (No such file or directory)
oct 24 20:16:14 fedora39 auditd[5366]: Skipping af_wazuh.conf plugin due to errors
oct 24 20:16:14 fedora39 auditd[5366]: No plugins found, not dispatching events
oct 24 20:16:14 fedora39 auditd[5366]: Init complete, auditd 3.1.2 listening for events (startup state enable)
oct 24 20:16:14 fedora39 augenrules[5369]: /sbin/augenrules: No change
oct 24 20:16:14 fedora39 augenrules[5380]: No rules
oct 24 20:16:14 fedora39 systemd[1]: Started auditd.service - Security Auditing Service.It indicates that lines 3 and 4 of wazuh's rule file is using obsolete options. wazuh pluing conf file: active = yes
direction = out
path = builtin_af_unix
type = builtin
args = 0640 /var/ossec/queue/sockets/audit
format = stringApparently, Fedora 39 deprecated builin_af_unix, and when Wazuh's trying to use it, it tries to use Installing audispd-plugins: yum install audispd-pluginsAfter rebooting, promising but still failing output is observed: root@fedora39 wazuh]# systemctl status auditd
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Tue 2023-10-24 21:05:10 -03; 8min ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 575 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
Process: 587 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Main PID: 581 (auditd)
Tasks: 4 (limit: 2310)
Memory: 6.5M
CPU: 57ms
CGroup: /system.slice/auditd.service
├─581 /sbin/auditd
└─583 /sbin/audisp-af_unix 0640 /var/ossec/queue/sockets/audit
oct 24 21:05:10 fedora39 systemd[1]: Starting auditd.service - Security Auditing Service...
oct 24 21:05:10 fedora39 auditd[581]: Option builtin_af_unix line 3 is obsolete - using /sbin/audisp-af_unix
oct 24 21:05:10 fedora39 auditd[581]: Option builtin line 4 is obsolete - update it
oct 24 21:05:10 fedora39 auditd[581]: audit dispatcher initialized with q_depth=2000 and 1 active plugins
oct 24 21:05:10 fedora39 auditd[581]: Init complete, auditd 3.1.2 listening for events (startup state enable)
oct 24 21:05:10 fedora39 audisp-af_unix[583]: audisp-af_unix plugin is listening for events
oct 24 21:05:10 fedora39 augenrules[587]: /sbin/augenrules: No change
oct 24 21:05:10 fedora39 augenrules[605]: No rules
oct 24 21:05:10 fedora39 systemd[1]: Started auditd.service - Security Auditing Service.
oct 24 21:05:14 fedora39 audisp-af_unix[583]: Client connectedoosec.log file: but ossec.log still shows errors with audit:
2023/10/24 21:12:03 wazuh-syscheckd: ERROR: (6642): Audit health check couldn't be completed correctly.
2023/10/24 21:12:03 wazuh-syscheckd: WARNING: (6913): Who-data engine could not start. Switching who-data to real-time.
This is a different behaviour. Now wazuh's FIM module is connecting to auditd, but heath check failsauditctl still shows an empty response: syscheck.debug2 is set at /var/ossec/etc/local_internal_options.conf and ossec.log shows: 2023/10/24 21:22:46 wazuh-syscheckd[6630] audit_healthcheck.c:41 at audit_health_check(): DEBUG: (6279): Whodata health-check: Starting.
2023/10/24 21:22:46 wazuh-syscheckd[6630] pthreads_op.c:45 at CreateThreadJoinable(): DEBUG: Thread stack size set to: 8192 KiB
2023/10/24 21:22:46 wazuh-syscheckd[6630] audit_healthcheck.c:102 at audit_healthcheck_thread(): DEBUG: (6255): Whodata health-check: Reading thread active.
2023/10/24 21:22:47 wazuh-syscheckd[6630] audit_parse.c:326 at filterkey_audit_events(): DEBUG: (6251): Match audit_key: 'wazuh_hc'
2023/10/24 21:22:56 wazuh-syscheckd[6630] audit_healthcheck.c:70 at audit_health_check(): DEBUG: (6257): Whodata health-check: Failed to receive creation event.
2023/10/24 21:22:57 wazuh-syscheckd[6630] audit_parse.c:326 at filterkey_audit_events(): DEBUG: (6251): Match audit_key: 'wazuh_hc'
2023/10/24 21:22:57 wazuh-syscheckd[6630] audit_healthcheck.c:106 at audit_healthcheck_thread(): DEBUG: (6256): Whodata health-check: Reading thread finished.
2023/10/24 21:22:57 wazuh-syscheckd[6630] syscheck_audit.c:365 at audit_init(): ERROR: (6642): Audit health check couldn't be completed correctly.
2023/10/24 21:22:57 wazuh-syscheckd[6630] main.c:286 at main(): WARNING: (6913): Who-data engine could not start. Switching who-data to real-time.
|
|
This issue seems to have become more critical and seems to be bigger than it looked at first. Will move its ETA and change its size to accommodate. Will also block 2 other issues regarding whodata on newer OSs. |
ncvicchi
changed the title
|
ETA delayed and on hold status due to higher priority issues coming: |
UpdateHello team, Fedora 39, comes with auditd 3.1.2 installed. When trying to configure a directory in whodata, we found this error in the log: And this error in auditd: For centos 9 stream, the version that comes with auditd installed is 3.0.6 (everything works correctly here), but upgrading to version 3.1.2, we find the same error as with fedora 39. For Ubuntu 23, the latest available version of auditd is 3.1.1, and here, although we see some similar problems in auditd, whodata works correctly without problems. With all this, reviewing the changelog of auditd, between version 3.1.1 and 3.1.2 we find: Additional problemIn addition, we have detected a problem that was already reported a long time ago, and that seems that it could be a problem again. Some systems have a rule in auditd that prevents the monitoring of certain syscall events, and makes the whodata function impossible: This rule must be removed for use. We will delay the ETA for another week for further investigation. |
|
Changing the status to |
-a never,taskHello team, on the subject of the audit
This prevents the whodata healthcheck from proceeding as it should, and therefore whodata is disabled by default on these systems (there may be more). |
Problem SummaryFIM uses an integration with Audit to capture who-data on Linux. From version 3.1 of Audit, FIM/who-data stops working, switching to real-time. CauseThis version of Audit introduces a default rule: Which completely disables the system call auditing. History and contextIn 3.4.0 we introduced who-data in FIM (#756). However, when were reported that a customer installed it on their systems, nothing worked and we set up a troubleshooting meeting. @albertomn86 found the cause: they had the In the following days, we did a development to solve this problem: remove the damn rule (47bc125). However, we then regretted it: we considered that FIM should not modify a rule set by the user, and PR #1929 did not reach a release. Instead, in 3.7.0 we implemented a health-check (#2057) that would check if who-data works well and would act accordingly: continue or switch to real-time. Now, the Solutions (to discuss)
StatusThis issue will remain blocked until the management team approves a solution. |
|
We have divided the problems encountered with auditd into two different issues, on the one hand, this issue will correspond to the error related to the creation of the af_unix socket. For the problems related to the |
ConclusionsWe have finally detected that to fix this type of error when the audit version is |
|
Entending ETA due to blocked until management decissions |
1 similar comment
|
Entending ETA due to blocked until management decissions |
|
This issue is closed by 6871
|
|
Merged! |
Closed by 6871
This issue is derived from #18727 as a result of tests performed.
Steps to reproduce:
<directories whodata="yes">/testwhodata</directories>/var/ossec/etc/local_internal_options.confsyscheck.debug=2Result
** Alert 1696903437.18696: - ossec,syscheck,syscheck_entry_added,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2023 Oct 10 02:03:57 (fedora39) any->syscheck
Rule: 554 (level 5) -> 'File added to the system.'
File '/testwhodata/test' added
Mode: realtime
Attributes:
** Alert 1696903442.19375: - ossec,syscheck,syscheck_entry_deleted,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2023 Oct 10 02:04:02 (fedora39) any->syscheck
Rule: 553 (level 7) -> 'File deleted.'
File '/testwhodata/test' deleted
Mode: realtime
Attributes:
By executing
systemctl status auditdthe following output is observed:The text was updated successfully, but these errors were encountered: