Karen,
Quite simply, just monitor execve (in addition to targeted/mandated monitoring) as
per
# Process execution
-a always,exit -F arch=b64 -S execve -F auid!=unset -F key=cmds
And within /etc/audit/auditd.conf change
max_log_file = 8 num_logs = 5to max_log_file = 32 num_logs = 9
Which caters for an expanded set of /var/log/audit/audit.log files (32 x 9 =
288MB).You would need to send your logs to a central SIEM say every 10-15 minutes.
Burn AltingPS. I know I have identified b32 arch but the best b32 arch rule now for
most modern (and supported Linux) is-a always,exit -F arch=b32 -S all -F key=32bit-
abi
On Fri, 2023-01-13 at 22:47 +0000, Wieprecht, Karen M. wrote:
Steve, Audit team,
My colleagues and I were discussing ways we might better monitor for potential
insider threat. We can easily see the commands our SAs run when they use sudo in
front of the command, but if the sysadmin uses "sudo su -", then we
don't have
good visibility into the commands they perform while they are su'd unless there
happens to be an audit rule monitoring the specific files/commands they are
accessing/running.
We've talked about possible way to improve our visibility in this situation, but
most of the options we came up with are easily thwarted and/or would cause the
logs to blow up to the point that it's difficult to spot nefarious
activity. Some options we considered included having splunk monitor the shell
history files, and possibly enabling ps auditing.
Can you recommend any audit rules that would audit the interactive commands being
issued by a sysadmin who is su'd as root without causing the logs to blow up?
Any assistance you can provide would be much appreciated.
Thank you,Karen Wieprecht The Johns Hopkins Applied Physics Laboratory--Linux-
audit mailing listLinux-audit(a)redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit