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