[SUMMARY]: auditd output analysis?

From: Craig Makin <Craig_Makin.DOLA_at_notes.dola.wa.gov.au>
Date: 12 Dec 96 11:58:31

Thanks to the following people for responding:

 Eric.Rostetter _at_ utoledo.edu (Eric)
 marblek _at_ city.ci.worcester.ma.us (Karl Marble)

My original post was :

>G'day Sysadmin'ers
>
>We currently have 2 alphas running V3.2D-1 with enhanced C2 security enabled.
>"auditd" is running and creating lots of output (std options via audit_setup).
Our
>security administrator tried using the tool to analyse this output and wasn't
>impressed (to put it politely).
>
>Q: Are there any tools for analysing and reporting auditd information
>
>Q: Any recommended suggestions of "calls" to be ignored etc?
>
>Is there a whitepaper somewhere ??
>
> Ta,
> Craig Makin
> Ferntree Computer Corp.

Responses:

From: Eric.Rostetter _at_ utoledo.edu (Eric) _at_ SMTP

> We currently have 2 alphas running V3.2D-1 with enhanced C2 security enabled.
> "auditd" is running and creating lots of output (std options via
audit_setup).

Boy, I hope you have lots of disk space!

> Our
> security administrator tried using the tool to analyse this output and wasn't
> impressed (to put it politely).

There is probably a two fold problem:

1) Too much data being collected, making it hard to analyze
2) The tools are pretty bad

> Q: Are there any tools for analysing and reporting auditd information

Not that I know of. Although there have been promises of such on this list
before, I have yet to see any.

> Q: Any recommended suggestions of "calls" to be ignored etc?

Most of them should be ignored. Audit anything that is critical, like
chroot, setuid, reboot, shutdown, acct, etc. I also audit things that
shouldn't happen much, like mount, unmount, adjtime, swapon, etc.
Avoid the normal system calls that every program calls, like fork,
vfork, exit, close, link, chdir, etc.

> Is there a whitepaper somewhere ??

Not that I know of, but there probably is.

Eric Jon ROSTETTER
Eric.Rostetter_at_utoledo.edu

Espresso est, ergo cogito... Cogito, ergo disclaimum...

The above views belonged to me at the time I wrote this message. My
views may have changed since that time. Your mileage may vary... ;)


From: marblek _at_ city.ci.worcester.ma.us (Karl Marble) _at_ SMTP
At 02:42 PM 12/4/96, you wrote:
>G'day Sysadmin'ers
>
>We currently have 2 alphas running V3.2D-1 with enhanced C2 security enabled.
>"auditd" is running and creating lots of output (std options via audit_setup).
>Our
>security administrator tried using the tool to analyse this output and wasn't
>impressed (to put it politely).
>
>Q: Are there any tools for analysing and reporting auditd information

XIsso has audit record analysis things built into it. For some things, it's
easier to use than audit_tool, but sometimes I use audit_tool because I
don't always understand what XIsso is doing.

>Q: Any recommended suggestions of "calls" to be ignored etc?

It depends how paranoid you are. I use auditing to keep track of when
people creat/modify/delete files, login, logout, su, and such. It's very
handy when a file disappers, and the user says 'I didn't do anything.' The
aliases that come with the system are what I use to turn these audit flags on.

File creation,modification,deletion correspond to the object_creat,
object_modify, and object_delete event aliases (I specifically look for
unlink, which is what the kernel does when you do rm in any way).

Login, logout, and su are covered by the trusted_event alias. You also want
to turn on the audstyle flag for login_uname. This will tell you what
people type in for unsuccessful logins.

If your auditlog files are getting too big, you're probably auditing
processes and system calls. The information might be good for tracking down
a VERY clever hacker who could otherwise erase their audit trail, but the
disk space used by it and the possibility of slowing down the system don't
make it seem worthwhile to me, you might want to just have these flags set
for certain users. You can change the audit flags for a specific user with
XIsso.

whew!

Karl
Received on Thu Dec 12 1996 - 05:17:23 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:47 NZDT