1

We have an audit.rules defined and things in rules.d. Many of these are for RHEL CIS compliance and others are more specific for Docker CIS compliance.

One problem we are having is that certain rules (i.e. docker file system rules) account for TBs of monthly logs as we have some servers that are extremely active docker worker nodes. This is blowing up the costs of ingesting these audit logs. We wanted to find a way to separate the auditd logs produced by docker rules into a different file and all of the other CIS RHEL rules that are in place so that we can use our log aggregation agent to forward the dockerd logs to a lower cost solution.

Another approach I considered was since the audit.rules for docker each have a k=docker I could filter the logs out using that key but the problem is that that key is only associated with one of the audit components (i.e. SYSCALL) but the other logs that correspond to the SYSCALL, like PATH and PROCTITLE don't have this key directly on the record so it's not "easy" to filter them out.

I haven't been able to figure out a way to do this. Anyone have any recommendations for how to separate audit logs from different rules out?

JD D
  • 151
  • 5

1 Answers1

1

If your log records have keys, you can use ausearch -k <keyname> to get all events with that key associated. If you combine it with --checkpoint you can read the log incrementally. However, you will need separate checkpoint-files for every key you're filtering for, of course.

Andreas Rogge
  • 2,853
  • 11
  • 24
  • thanks, this would help searching the file but we have agents that ingest that audit.log file directly and am looking for a way to prevent certain rule output from hitting the audit.log and being put into a different audit log – JD D Sep 11 '20 at 14:08
  • AFAICT your best bet is to `sesearch` the exisiting log into splitted logs and ingest these instead of the original ones. – Andreas Rogge Sep 13 '20 at 11:05