
Betriebssystem: CentOS 7
Ich versuche herauszufinden, wie Audit( kaudit
)-Ereignisse protokolliert werden /var/log/messages
.
Ich habe es audit=1
in Grub aktiviert, was bedeutet, dass beim Booten des Servers die Kernel-Überwachung aktiviert ist. Dies ist der gewünschte Zustand für das jeweilige System und die Deaktivierung der Überwachung kommt nicht in Frage. Meine audit
Konfiguration ist wie folgt
# auditctl -s
enabled 1
failure 1
pid 0
rate_limit 0
backlog_limit 64
lost 7452643
backlog 0
loginuid_immutable 0 unlocked
Auditd
auf der anderen Seite ist es deaktiviert/gestoppt, weil ich ein anderes Tool verwende, um die vom Kernel-Audit generierten Ereignisse zu sammeln/verwenden.
Mein Problem ist, dass mir aufgefallen ist, dass diese Überwachungsereignisse protokolliert werden /var/log/messages
:
2021-11-25T00:35:09.490607-08:00 myserver.local kernel: [4272426.343673] audit: type=1110 audit(1637829309.455:7426414): pid=2361 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success
Ich versuche herauszufinden, wie diese Nachrichten landen, /var/log/messages
und das Einzige, worüber ich mir sicher bin, ist, dass das Syslog dies tun wird.
Eigentlich versuche ich herauszufinden, wo die Audit-Ereignisse landen, rsyslog
und bisher hatte ich kein Glück. Ich gehe davon aus, dass journald
diese Audit-Ereignisse abgeholt werden und diese wiederum weitergeleitet werden rsyslog
, aber ich kann das nicht klären.
Journald
kann eine Verbindung mit dem Kernel herstellen, netlink socket
um Audit-Ereignisse abzurufen, allerdings sehe ich in systemd keinen solchen Socket.
# systemctl list-units --type=socket
UNIT LOAD ACTIVE SUB DESCRIPTION
dbus.socket loaded active running D-Bus System Message Bus Socket
dm-event.socket loaded active listening Device-mapper event daemon FIFOs
iscsid.socket loaded active running Open-iSCSI iscsid Socket
iscsiuio.socket loaded active listening Open-iSCSI iscsiuio Socket
lvm2-lvmetad.socket loaded active listening LVM2 metadata daemon socket
lvm2-lvmpolld.socket loaded active listening LVM2 poll daemon socket
nscd.socket loaded active running Name Service Cache Daemon Socket
rpcbind.socket loaded active running RPCbind Server Activation Socket
systemd-initctl.socket loaded active listening /dev/initctl Compatibility Named Pipe
systemd-journald.socket loaded active running Journal Socket
systemd-shutdownd.socket loaded active listening Delayed Shutdown Socket
systemd-udevd-control.socket loaded active running udev Control Socket
systemd-udevd-kernel.socket loaded active running udev Kernel Socket
# systemctl status systemd-journald-audit.socket
Unit systemd-journald-audit.socket could not be found.
Das Merkwürdige ist nun, dass ich, wenn ich netlink
Sockets im System aufliste, einen sehe, der mit audit
und verknüpft ist systemd
:
# ss -a -f netlink|grep audit
UNCONN 0 0 audit:systemd/1 *
UNCONN 0 0 audit:sudo/3144 *
UNCONN 0 0 audit:kernel *
UNCONN 0 0 audit:sudo/14889 *
Irgendeine Idee, wie diese Protokolle im Syslog landen und was/wie dieser audit:systemd
Socket erstellt wird?
Und vor allem: Wie kann journald
die Erfassung von Prüfereignissen beendet werden?