On Friday 31 October 2008 14:21:12 David Flatley wrote:

>     If you would indulge my simpler in comparison question of the group. I

> am setting up audit on heavy usage systems. I have setup my auditd.conf to

> rotate the files once they get to 70 meg and allow up to 12 rotated files.

You don't need to limit the files to 12 unless you are short on disk space. 

you can use keep_logs as the max_log_file option and one will not be lost.

> I created a cron that runs hourly to look and see if a ninth rotated file

> exists and if so run "ausearch -i" outputted to a file and store the

> file,

You shouldn't need to ausearch the file? Are you doing that to split the file 

on a time hack? In that case you can just about as easily do a "service 

auditd rotate" and force auditd to end at a certain time rather than by size.

Yes and then I could use ausearch -if <file> when I need to look at the logs
after they have been moved to storage. Or apply the ausearch -i when I do the
storage of the file, I do this to convert from numerical to text on the file.

> then remove the rotated files. I run the cron to avoid losing data if 

> there is alot of activity and rotated files are rolled off. I also have to

> balance performance with auditing in this arrangement.

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.

-Steve

On Friday 31 October 2008 14:21:12 David Flatley wrote:

>     If you would indulge my simpler in comparison question of the group. I

> am setting up audit on heavy usage systems. I have setup my auditd.conf to

> rotate the files once they get to 70 meg and allow up to 12 rotated files.

You don't need to limit the files to 12 unless you are short on disk space. 

you can use keep_logs as the max_log_file option and one will not be lost.

> I created a cron that runs hourly to look and see if a ninth rotated file

> exists and if so run "ausearch -i" outputted to a file and store the

> file,

You shouldn't need to ausearch the file? Are you doing that to split the file 

on a time hack? In that case you can just about as easily do a "service 

auditd rotate" and force auditd to end at a certain time rather than by size.

Yes and then I could use ausearch -if <file> when I need to look at the logs

after they have been moved to storage. Or apply the ausearch -i when I do the

storage of the file, I do this to convert from numerical to text on the file.

> then remove the rotated files. I run the cron to avoid losing data if 

> there is alot of activity and rotated files are rolled off. I also have to

> balance performance with auditing in this arrangement.

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.

-Steve
--

Linux-audit mailing list

Linux-audit@redhat.com

https://www.redhat.com/mailman/listinfo/linux-audit

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):
>* 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.

>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?
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.
Yes I am in the process of evaluating rules, using S.T.I.G. recommendations.

>* You mention "balancing performance"  - are you talking about

>per-machine or network (via aggregation)? 
Yes per machine, network is not an issue.
>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?
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

https://www.redhat.com/mailman/listinfo/linux-audit

On Sunday 02 November 2008 21:42:47 David Flatley wrote:

> Presently I am using the S.T.I.G. recommendations but I may

> have to use more extensive rules which I am in the process of test=
ing.

Are you using the stig.rules from the audit package or something else? =
If I 

were you, I'd spend some time making sure your rules are tuned. Assumin=
g that 

you have keys on you rules, you can run a key report to see what is cau=
sing 

you the most events: aureport --start this-week --key --summary. 

Then you'd want to dig into some of those records and see what kinds of=
 things 

are happening. Assuming you have a key of delete and you wanted to see =
what 

syscalls are the most often logged:

ausearch --start this-week -k delete --raw | aureport --syscall --summa=
ry -i

Assuming that shows unlinkat the most prevalent syscall:

ausearch --start this-week -k delete -sc unlinkat --raw | 

aureport --user --summary -i

And so on until you see what is causing so much logging. This doesn't h=
elp 

with the archiving, but could help you get the right audit data recorde=
d.

-Steve