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 [email protected]
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
--
Linux-audit mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-audit
