On 10/18/2017 11:40 AM, Steve Grubb wrote:
On Wednesday, October 18, 2017 11:14:31 AM EDT Brad Zynda wrote:
> Here is an output from the server with PATH audit type re-allowed
> (everything back to normal):
>
> Key Summary Report
> ===========================
> total key
> ===========================
> 6019 perm_mod
> 3878 delete
> 964 access
> 96 privileged
> 57 time-change
> 51 session
> 41 modules
> 20 logins
> 6 system-locale
> 5 identity
> 2 mounts
> 2 scope
> 2 actions
> 1 MAC-policy
>
> Now this is probably not a peak result but I have come across 2 questions..
>
> 1. I wanted to cron this and email results but get, verified path sbin:
>
> Key Summary Report
> ===========================
> total key
> ===========================
> <no events of interest were found>
This is a well known problem. From aureport man page:
--input-logs
Use the log file location from auditd.conf as input for analy‐
sis. This is needed if you are using aureport from a cron job.
ausearch/report can be piped to by stdin. This takes priority over the logs.
Cron uses pipes for all 3 descriptors. Therefore you have to tell them to
ignore what they are seeing and just use the logs.
> 2. If it ends up being perm_mod as the high count what is the next step
> to identify the rule in question?
grep perm_mod /etc/audit/audit.rules
delete also looks excessive.
-Steve
Yep input-logs fit the bill.
So now you have to comment out a rule at a time and watch for
usage/count to fall?
Also if I wanted to grep and compare those numbers and alert with an
email what would be the magic number to threshold with in a gt statement
(500, 1000, etc.)?
Thanks,
Brad