<html><body> <img width="16" height="16" src="cid:1__=0ABBFE65DF8371CF8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for LC Bruzenak <lenny@magitekltd.com>">LC Bruzenak <lenny@magitekltd.com> <tt> On Fri, 2008-10-31 at 15:50 -0400, Steve Grubb wrote: >> On Friday 31 October 2008 14:21:12 David Flatley wrote: > ... > >> Perhaps we need the capability of switching out partitions used for logging? >> Maybe that could be solved by using the space left action exec capability to >> run a custom program that re-writes the audit config file or changes a >> symlink to point to another config file to point to a new dir and then sends >> sighup to the parent (auditd). >> >> Maybe some others have ideas about how they solve the same problem. If we need >> to make changes to the audit daemon to make this smoother, let me know what's >> needed. >David, I will have similar requirements and I've been thinking about >this also. Not sure about you, but my audit data has the following >requirements (and others):</tt> <tt>>* archive to off-site storage >* restore from archive >* search capabilities (mostly covered in ausearch and audit-viewer) >* robust (cannot lose any data received) >* etc. Yes my requirements are very similar.</tt> <tt> >Like you, I'm planning a periodic shift. This enables straightforward >time-based restore/search for humans. Ideally, it would be totally >automated, as in: >1: shift auditing to a new R/W partition each month. >2: Make the previous month audit data RO. >3: archive the previous month to tape/DVD >4: put the RO partition back into the "available" queue >5: ensure the current audit is also mirrored over to a big storage area >with all the past data on it. >6: Send an email to the administrator that all the above has >successfully occurred. >Steve, as my testing progresses I'll add comments in this area. I had >thought a cron-activated logrotate on the month would cover this, but it >means 2 admin areas; if there is a way to do it inside the audit >structure, that would be preferable to me. It would simplify/consolidate >the config rpm(s) I create. Anything you could do to help facilitate a >scheme as described above would be welcome. >David, a couple of questions for you: >* Have you looked at the audit-viewer, and do you intend to use this?</tt> <tt>No, have not looked at it, really would like to use Tivoli compliance insight manager. >* I assume "heavy usage systems" means lots of audit data...are your >rules tuned appropriately? This is critical for me - one over-zealous >rule will add a flood of unhelpful info.</tt> <tt>Yes I am in the process of evaluating rules, using S.T.I.G. recommendations.</tt> <tt> >* You mention "balancing performance" - are you talking about >per-machine or network (via aggregation)? </tt> <tt>Yes per machine, network is not an issue.</tt> <tt>>When reading your post I >assumed aggregation from my own perspective but you didn't actually >specify so I thought maybe I should ask. I'm aggregating all audit from >several machines to a single audit machine for >storage/review/administration. You?</tt> <tt>I remove the logs daily per machine and store them per system. >Thx, >LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com -- Linux-audit mailing list Linux-audit@redhat.com </tt><tt><a href="https://www.redhat.com/mailman/listinfo/linux-audit">https://www.redhat.com/mailman/listinfo/linux-audit</a></tt><tt> </tt> </body></html>