A user of mine took a provided auditbeat.yml config file and converted it into something that included:
- module: auditd
enabled: true
audit_rules: "-a always,exit -F arch=b32 -S all -k 32bit-abi"
user.detect_password_changes: false
scan_at_start: false
recursive: true
- module: auditd
enabled: true
audit_rules: "-a always,exit -F arch=b64 -S execve,execveat -k exec"
user.detect_password_changes: false
scan_at_start: false
recursive: true
If you start auditbeat using this, you'll see output along these lines from auditbeat show auditd-status:
enabled 1
failure 0
pid 0
rate_limit 0
backlog_limit 8192
lost 381
backlog 0
backlog_wait_time 0
features 0xf
The pid value is 0. To the kernel, that means there is no user-space audit listener. When the linux kernel sees a pid value of 0 here and auditing is still enabled, it will printk the audit record into the kernel message buffer leading to journald spamming various logs in /var/log.
It looks to me like auditbeat is trying to instantiate two modules:
2021... INFO instance/beat.go:299 Setup Beat: auditbeat; Version: 7.10.2
2021... INFO [publisher] pipeline/module.go:113 Beat name: dca1-security-prod-intel01
2021... INFO [auditd] auditd/audit_linux.go:106 auditd module is running as euid=0 on kernel=4.9.0-16-amd64
2021... INFO [auditd] auditd/audit_linux.go:133 socket_type=unicast will be used.
2021... INFO [auditd] auditd/audit_linux.go:106 auditd module is running as euid=0 on kernel=4.9.0-16-amd64
2021... INFO [auditd] auditd/audit_linux.go:133 socket_type=unicast will be used.
The second instantiation steps on the first leading to pid == 0.
I don't think this is what is expected. Either it is a syntax error to have two "module: auditd" clauses, or auditbeat should cleanly have the second clause supersede the first or both should be able to happily coexist.
Worth a bug report?