OS: CentOS 7
Încerc să îmi dau seama cum auditez (kaudit) evenimentele sunt conectate /var/log/messages.
Am activat audit=1 în grub, ceea ce înseamnă că atunci când serverul pornește, auditarea nucleului este activată. Aceasta este starea dorită pentru sistemul particular, iar dezactivarea auditului este în afara ecuației. Ale mele audit configurația este după cum urmează
# auditctl -s
activat 1
eșec 1
pid 0
rate_limit 0
backlog_limit 64
a pierdut 7452643
restanță 0
loginuid_immutable 0 deblocat
Auditd pe de altă parte este dezactivat/oprit deoarece folosesc un alt instrument pentru a colecta/consuma acele evenimente generate de auditul kernel-ului.
Problema mea este că am observat că acele evenimente de audit sunt conectate /var/log/messages:
2021-11-25T00:35:09.490607-08:00 myserver.local kernel: [4272426.343673] audit: type=1110 audit(1637829309.455:7426414): pid=2396414: pid=239426.343674: pid=239426749674964967496496754949696967 PAM:setcred grantors=pam_env,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? adresa=? terminal=? res=succes
Încerc să-mi dau seama cum ajung aceste mesaje /var/log/messages și singurul lucru de care sunt sigur este că syslog va face asta.
De fapt, încerc să urmăresc cum se termină evenimentele de audit rsyslog si pana acum nu am avut noroc. Am o presupunere că journald preia acele evenimente de audit care, la rândul lor, le transmite către rsyslog cu toate acestea, nu sunt în măsură să clarific acest lucru.
Journald poate stabili o priza netlink cu nucleul pentru a obține evenimente de audit, cu toate acestea, nu văd un astfel de socket prezent în systemd.
# systemctl list-units --type=socket
SUBDESCRIERE ACTIVĂ DE ÎNCĂRCARE UNITĂ
dbus.socket încărcat activ rulând D-Bus System Message Bus Socket
dm-event.socket a încărcat ascultare activă FIFO-uri demonul evenimentelor mapper-dispozitiv
iscsid.socket încărcat activ rulând Open-iSCSI iscsid Socket
iscsiuio.socket încărcat ascultare activă Open-iSCSI iscsiuio Socket
lvm2-lvmetad.socket a încărcat soclul demonului de metadate LVM2 cu ascultare activă
lvm2-lvmpolld.socket a încărcat soclul demon de sondaj LVM2 cu ascultare activă
nscd.socket încărcat activ rulând Name Service Cache Daemon Socket
rpcbind.socket încărcat activ rulând RPCbind Server Activation Socket
systemd-initctl.socket încărcat ascultare activă /dev/initctl Compatibilitate Named Pipe
systemd-journald.socket încărcat activ rulând Journal Socket
systemd-shutdownd.socket încărcat ascultare activă Socket de oprire întârziată
systemd-udevd-control.socket încărcat activ rulând udev Control Socket
systemd-udevd-kernel.socket încărcat activ rulând udev Kernel Socket
# starea systemctl systemd-journald-audit.socket
Unitatea systemd-journald-audit.socket nu a putut fi găsită.
Acum, lucru ciudat este că dacă aș enumera netlink prize din sistem, pot vedea unul legat de audit și 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 *
Orice idee cum ajung aceste jurnale în syslog și ce/cum asta audit:systemd socket-ul este creat?
Cel mai important, cum să te oprești journald adunarea evenimentelor de audit?
