RE: Linux-audit Digest, Vol 27, Issue 2

RE: Linux-audit Digest, Vol 27, Issue 2

[Thomas, Daniel J.]

I'm new to the audit subsystem.  I need to get it working well under
RHEL4.  The version that comes with Redhat is very old (1.0.14?)  I
noticed if I upgrade to 1.0.14 it pretty much works the same, but if I
upgrade all the way to 1.3.1, file watch functionality has been removed.
How do I handle auditing of access to security files with 1.3?  I assume
it's some kind of system call we're tracking, but I don't know how to
get a list of system calls that I need to know about.

Thanks,

-Dan Thomas 

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of
linux-audit-request@redhat.com
Sent: Monday, December 11, 2006 12:00 PM
To: linux-audit@redhat.com
Subject: Linux-audit Digest, Vol 27, Issue 2

Send Linux-audit mailing list submissions to
	linux-audit@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.redhat.com/mailman/listinfo/linux-audit
or, via email, send a message with subject or body 'help' to
	linux-audit-request@redhat.com

You can reach the person managing the list at
	linux-audit-owner@redhat.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Linux-audit digest..."


Today's Topics:

   1. audit 1.3.1 released (Steve Grubb)


----------------------------------------------------------------------

Message: 1
Date: Mon, 11 Dec 2006 11:05:33 -0500
From: Steve Grubb <sgrubb@redhat.com>
Subject: audit 1.3.1 released
To: Linux Audit <linux-audit@redhat.com>
Message-ID: <200612111105.33708.sgrubb@redhat.com>
Content-Type: text/plain;  charset="us-ascii"

Hi,

I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit  It will also be
in rawhide tomorrow. The Changelog is:

- Fix a couple parsing problems (#217952)
- Add tgkill to S390* syscall tables (#218484)
- Fix error messages in ausearch/aureport command options

Please let me know if there are any problems with this release.

-Steve



------------------------------

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

End of Linux-audit Digest, Vol 27, Issue 2
******************************************

Re: Linux-audit Digest, Vol 27, Issue 2

[Steve Grubb]

On Monday 11 December 2006 12:15, Thomas, Daniel J. wrote:
> I'm new to the audit subsystem.  I need to get it working well under
> RHEL4.  The version that comes with Redhat is very old (1.0.14?)

That is the latest for RHEL4. There is a 1.0.15 in the pipeline that backports 
many features from 1.2.9.

> I noticed if I upgrade to 1.0.14 it pretty much works the same, but if I
> upgrade all the way to 1.3.1, file watch functionality has been removed.

There are differences in the RHEL4 kernel and the current 2.6.19 kernel 
regarding audit that causes them to be incompatible in several ways.

> How do I handle auditing of access to security files with 1.3?

1.3.1 is commandline compatible with 1.0.14. However, you need to be using a 
2.6.19 kernel for it.

-Steve

RE: Linux-audit Digest, Vol 27, Issue 2

[Thomas, Daniel J.]

Looking at Redhat's website, it seems that they have an audit-1.2.9-1.el5.x86_64.rpm available for download.  It's currently listed as beta and it looks like they're rolling it out with EL5, but right now it is listed as a package for EL4.  Is that a possibility?

-Dan

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Monday, December 11, 2006 1:20 PM
To: linux-audit@redhat.com
Cc: Thomas, Daniel J.; Wieprecht, Karen M.
Subject: Re: Linux-audit Digest, Vol 27, Issue 2

On Monday 11 December 2006 12:15, Thomas, Daniel J. wrote:
> I'm new to the audit subsystem.  I need to get it working well under 
> RHEL4.  The version that comes with Redhat is very old (1.0.14?)

That is the latest for RHEL4. There is a 1.0.15 in the pipeline that backports many features from 1.2.9.

> I noticed if I upgrade to 1.0.14 it pretty much works the same, but if 
> I upgrade all the way to 1.3.1, file watch functionality has been removed.

There are differences in the RHEL4 kernel and the current 2.6.19 kernel regarding audit that causes them to be incompatible in several ways.

> How do I handle auditing of access to security files with 1.3?

1.3.1 is commandline compatible with 1.0.14. However, you need to be using a
2.6.19 kernel for it.

-Steve

Re: Linux-audit Digest, Vol 27, Issue 2

[Steve Grubb]

On Monday 11 December 2006 14:20, Thomas, Daniel J. wrote:
> Looking at Redhat's website, it seems that they have an
> audit-1.2.9-1.el5.x86_64.rpm available for download.  It's currently listed
> as beta and it looks like they're rolling it out with EL5, but right now it
> is listed as a package for EL4.  Is that a possibility?

No, the kernels and userspace pieces are incompatible. The transport mechanism 
is different, some operators aren't recognized by old kernels, and resulting 
record formats are slightly different which would cause ausearch/aureport to 
miss things.

1.0.x is for RHEL4
1.3 and higher for RHEL5.

-Steve

RE: Linux-audit Digest, Vol 27, Issue 2

[Wieprecht, Karen M.]

>>  What is the real problem though? You mention that you want to change
versions of audit, but don't really say why...so what's up?

Steve, I'm working with Dan Thomas, and maybe I can give you the big
picture on where we stand. Bear with me, we have been Googling,
rtfm'ing, etc. etc. etc., but are still having trouble getting pointed
to good sources for some of what we are trying to understand, so here's
some of what we've been learning (maybe you can fill in some gaps we've
been unable to fill?):

---

A colleague who uses SuSE made some recommendations about setting up
auditing to collect file access failures (caused by permissions
problems, etc). Not sure his settings should  work on RHEL4, but here's
what he recommended, and the issues we found when trying to use them:

1. Audit Version Differences
-------------------------------  
-  Our SuSE colleague is using the audit 1.2.3 (because his SuSE
kernel-headers and glibc kern-headers aren't new enough to allow him to
use a newer audit package

-  Our RHEL4 system had audit 1.0.14 on it when I was testing before I
went to class last week,  and that could explain why things behave
differently for me than for him ... 

I'm finding it difficult to locate documentation explaining how similar
or different the two are ... The email you  sent Dan sounds like things
get tested in the development path and then get back ported to RHEL4,
so it sounds like version numbers are not necessarily a good indicator
of how similar or different the two might be. If that is correct, then
where might I find more on these differences? 


2. Configuration recommendations:
---------------------------------
Here are my colleague's SuSE audit configurations which I tested on
RHEL4 with audit 1.0.14:

  /etc/audit.rules

	-a exit,always -S all -F exit=-13		(supposed to
catch all failed file accesses)

 /etc/sysconfig/auditd

	AUDITD_DISABLE_CONTEXTS="no"			(supposed to
allow system to do syscall logging so that the above audit.rules setting
will work)

I do know that -13 events get generated when a regular user tries to
mess around with files they do not have privs to access, but I couldn't
get my audit daemon to capture any of the -13 events with these
settings.  

3. Audit data differences on directory watches .vs. file watches :
------------------------------------------------------------------

Since I couldn't get the syscall settings to work, I tested the
following configurations independently:

	/etc/audit.rules
	a.	-w /etc/ -p w
	b.	-w /etc/nsswitch.conf

Then I attempted to do a number of things to /etc/nsswitch.conf as a
regular user to see if the auditing would detect it:

action attempted		general /etc watch		specific
/etc/nsswitch.conf
----------------		------------------
---------------------------
touch				NO
yes
rm				yes
yes
mv				yes
yes
chown				NO
yes
chgrp				NO
yes
vi				yes
yes
nedit				(no because nedit saw that the file did
not have write permission, and opened it read only with no errors)
chmod 777			NO
yes
append (via >>)	  	NO					yes
replace (via > ) 		NO
yes


The generic directory watch isn't going to cut it for us because it
misses a lot of things that should get logged, but it's not practical to
set a specific watch on every file someone might try to mess with where
they don't have permission... 

When I had the specific watch on /etc/nsswitch.conf, I saw that all of
the actions I tested generated a -13 exit code, so I would think that my
colleague's audit rule would work for us as a generic way to watch for
ANY file permission failures rather than having to set a watch on every
single file we want to monitor, so that's what we were working towards.
We thought that our attempt to collect the -13 exit codes might be
failing because of the difference in our audit version from one where we
know this works, and that's why we were trying to test a later version
of audit. 

Perhaps you can lend some insight on some of this? 

-----------------------
Questions and confusion
-----------------------

1. Should we be able to collect -13 exit codes in RHEL4's audit 1.0.14 ?
If so, is there something else we might have to do to get this working
other than the two configuration changes mentioned in Item 2 above?  If
not, what might you recommend?  We have looked at the
/usr/share/doc/audit-1.0.14/capp.rules for guidance,  but it doesn't
help much when trying to determine how to catch file access failures
without specific watched on every file of interest (which I think isn't
very  practical or reliable).  

2. Where might I find out more about the configurable options accepted
by /etc/sysconfig/auditd? A google search on "/etc/sysconfig/auditd"
came up with a lot package information, but not much about its
configuration options, and a search on "AUDITD_DISABLE_CONTEXTS" didn't
really get me anywhere ...

3. If a linux kernel is a Linux kernel,  then what's the scoop on using
Fedora Core (or some other flavor) src rpms on RHEL4 if we can't find a
RHEL4-specific src rpm for something we need (like a newer
kernel-headers)?  Is this a typical practice, or possible but
unsupported, or completely not recommended?

4. If there is no src rpm for something we need, but there IS a tar.gz,
what's involved in building and installing that package, and are there
precautions we need to take,  particularly when it involves things like
glibc-kernheaders or kernel-headers?       


Thanks for any pointers or light you can shed on any of this.

Karen Wieprecht




	

Re: Linux-audit Digest, Vol 27, Issue 2

[Steve Grubb]

On Monday 11 December 2006 15:32, Wieprecht, Karen M. wrote:
> 1. Audit Version Differences
> -------------------------------
> -  Our SuSE colleague is using the audit 1.2.3
> -  Our RHEL4 system had audit 1.0.14
>
> If that is correct, then where might I find more on these differences?

In terms of how they do things, there is a lot of difference between them. 
>From a commandline point of view, they are nearly identical. The development 
process has a lot of co-development between kernel and user space. When I've 
found something useful that people using 1.0.X series might like to have, I 
backport it. I do the same for any bugs I know of.

> 2. Configuration recommendations:
> ---------------------------------
>   /etc/audit.rules
>
> 	-a exit,always -S all -F exit=-13		(supposed to
> catch all failed file accesses)

This catches all syscalls that fail with exit code -13.

>  /etc/sysconfig/auditd
>
> 	AUDITD_DISABLE_CONTEXTS="no"			(supposed to
> allow system to do syscall logging so that the above audit.rules setting
> will work)

This doesn't exist. I don't have any idea where you would have got this from.

> I do know that -13 events get generated when a regular user tries to
> mess around with files they do not have privs to access, but I couldn't
> get my audit daemon to capture any of the -13 events with these
> settings.

It should have. You would also want to strace the program to verify the return 
code. But that would be a bug if it didn't work.


> 3. Audit data differences on directory watches .vs. file watches :
> ------------------------------------------------------------------
>
> Since I couldn't get the syscall settings to work, I tested the
> following configurations independently:
>
> 	/etc/audit.rules
> 	a.	-w /etc/ -p w

This detects changes to the directory inodes

> 	b.	-w /etc/nsswitch.conf

This detects changes to the file's inodes

> Then I attempted to do a number of things to /etc/nsswitch.conf as a
> regular user to see if the auditing would detect it:
>
> action attempted		general /etc watch		specific
> /etc/nsswitch.conf
> ----------------		------------------
> ---------------------------
> touch				NO
> yes
> rm				yes
> yes
> mv				yes
> yes
> chown				NO
> yes
> chgrp				NO
> yes
> vi				yes
> yes
> nedit				(no because nedit saw that the file did
> not have write permission, and opened it read only with no errors)
> chmod 777			NO
> yes
> append (via >>)	  	NO					yes
> replace (via > ) 		NO
> yes
>
>
> The generic directory watch isn't going to cut it for us because it
> misses a lot of things that should get logged,

It only logs changes to that directory's inodes.

> but it's not practical to set a specific watch on every file someone might
> try to mess with where they don't have permission...

If you have all the files that you want to watch on one partition, you can use 
syscall auditing of the open syscall with devmajor and devminor to limit the 
number of hits. On RHEL4, syscall auditing impacts performance since each 
rule gets evaluated for every syscall, but watches do not.

> When I had the specific watch on /etc/nsswitch.conf, I saw that all of
> the actions I tested generated a -13 exit code, so I would think that my
> colleague's audit rule would work for us as a generic way to watch for
> ANY file permission failures rather than having to set a watch on every
> single file we want to monitor,

You'll probably be overwhelmed with stuff you didn't want also. And this could 
consume quite a bit of diskspace.

> We thought that our attempt to collect the -13 exit codes might be
> failing because of the difference in our audit version from one where we
> know this works, and that's why we were trying to test a later version
> of audit.

No, the basic mechanism at work is inode auditing. Because inodes can change 
when the file is being edited, a more general way was created, but at its 
heart is the inode. Watches hide that from you.

> -----------------------
> Questions and confusion
> -----------------------
>
> 1. Should we be able to collect -13 exit codes in RHEL4's audit 1.0.14 ?

Yes.

> If so, is there something else we might have to do to get this working
> other than the two configuration changes mentioned in Item 2 above?

If all you want is exit codes of -13, the audit rule above is all you need. 
(The line about AUDITD_DISABLE_CONTEXTS doesn't exist in any of the code I've 
written.) But you might want to figure out how to limit what you are getting 
exit code -13's on. I'd think about limiting by syscall and devmajor/minor 
for performance and diskspace reasons.

> 2. Where might I find out more about the configurable options accepted
> by /etc/sysconfig/auditd?

There are only 3 options and they are documented in the sysconfig file. The 
EXTRAOPTIONS is what's passed to the audit daemon and it only has foreground 
mode - which is used for debug. So that option would not get used much.

> a search on "AUDITD_DISABLE_CONTEXTS" didn't really get me anywhere ...

Doesn't exist...unless somebody has code they aren't sharing.

> 3. If a linux kernel is a Linux kernel,

They aren't. Sometimes, userspace and kernels go together because of kernel 
changes. Audit in 2.6.16 is different than in 2.6.19. Protocols change and 
evolve. Userspace changes too. The 1.2 series of audit is not binary 
compatible with RHEL4 apps.

> then what's the scoop on using Fedora Core (or some other flavor) src rpms
> on RHEL4 if we can't find a RHEL4-specific src rpm for something we need
> (like a newer kernel-headers)? 

I think this is untested and unsupportable. The RHEL4 stream is tested 
together and can only be guaranteed when packages from its stream are used.

> Is this a typical practice, or possible but unsupported, or completely not
> recommended?

In terms of audit, there is more hidden problems than you want to work on. 
1.0.14 should do what you need.

> 4. If there is no src rpm for something we need, but there IS a tar.gz,

You can make and build anything you want. But as a system admin, you'd only 
want to install via rpm so that you can roll changes back or figure out what 
package owns each file. You'd never want to do "make install".

> what's involved in building and installing that package, and are there
> precautions we need to take,  particularly when it involves things like
> glibc-kernheaders or kernel-headers?

Generally, there be dragons ahead. More than I can write about today.

-Steve

RE: Linux-audit Digest, Vol 27, Issue 2

[Wieprecht, Karen M.]

[-- Attachment #1.1: Type: text/plain, Size: 575 bytes --]

Steve, thank you very much for your in depth reply to my very lengthy email..  I have about a gazillion years of sysadmin experience on various Unix platforms (Solaris, HP-UX, Mac OSX, Irix), but linux is very different with respect to tracking kernel revisions for various flavors, figuring out what can be used with what, etc.  It's quite confusing, and even though I just got back from a week long class (a SuSE class specifically for SGI Altix systems), there are many questions left unanswered.  Your help is **most **appreciated.
 
THanks again,
 
Karen Wieprecht

[-- Attachment #1.2: Type: text/html, Size: 1126 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Tools for reviewing audit logs ?

[Wieprecht, Karen M.]

 
Steve, I'm testing the RHEL4 audit 1.0.14 now with the sample capp.rules
, and I am generating data.  UGLY data.  I am wondering what
tools/GUIs/scripts people are using to look at this data.  I've written
scripts for Solaris and Irix and mac OSX to parse the audit data into a
more English-like format so it helps our admins review the logs.   If I
need to, I can use your faq example and get the audit records to be one
per line and write my own script to parse this,   but I don't want to
reproduce effort if there are nice scripts or  GUIs available already.
My google searches are leading off on lots of tangents, but I can't seem
to find what I'm after (or perhaps stuff just isn't out there?). Any
hints/tips/pointers you can provide would be greatly appreciated.

Thanks,

Karen Wieprecht

Re: Tools for reviewing audit logs ?

[Steve Grubb]

On Tuesday 12 December 2006 17:08, Wieprecht, Karen M. wrote:
> Steve, I'm testing the RHEL4 audit 1.0.14 now with the sample capp.rules
> , and I am generating data.  UGLY data.  I am wondering what
> tools/GUIs/scripts people are using to look at this data.  

Some one published a perl based viewer to this mail list earlier this year. I 
forget when. The aureport program was supposed to fill the immediate role of 
breaking the data down into something a little more useful. My intentions are 
to use that as the basis of a GUI based tool. The work is going slow and I'm 
at the poiint of writing the parser library.

> but I don't want to reproduce effort if there are nice scripts or  GUIs
> available already. 

Aside from that perl based viewer and aureport, nothing I know of. It would be 
helpful to me to know what your use cases/requirements are.

Thanks,
-Steve

Re: Tools for reviewing audit logs ?

[Jonathan Abbey]

[-- Attachment #1.1: Type: text/plain, Size: 2222 bytes --]

On Tue, Dec 12, 2006 at 05:29:03PM -0500, Steve Grubb wrote:
| On Tuesday 12 December 2006 17:08, Wieprecht, Karen M. wrote:
| > Steve, I'm testing the RHEL4 audit 1.0.14 now with the sample capp.rules
| > , and I am generating data.  UGLY data.  I am wondering what
| > tools/GUIs/scripts people are using to look at this data.  
| 
| Some one published a perl based viewer to this mail list earlier this year. I 
| forget when. The aureport program was supposed to fill the immediate role of 
| breaking the data down into something a little more useful. My intentions are 
| to use that as the basis of a GUI based tool. The work is going slow and I'm 
| at the poiint of writing the parser library.

I'm guessing that was Leigh Purdie and the Snare team down at
Intersect Alliance in oz.  They had their own kernel auditing
framework that was hacked into earlier Linux kernels, and they have a
central logging server that provides a nice GUI for reviewing
color-coded audit records, in addition to a micro-web server that can
be hosted on the individual system being audited.

They've continued working on their toolset beyond the early work they
posted here earlier, and you can get it from

  http://www.intersectalliance.com/projects/SnareLinux/index.html

They are providing/recommending 'audit-1.2.1-1.i386.rpm' and
'audit-libs-1.2.1-1.i386.rpm' in addition to their
SnareLinux-1.0b7-1.i386.rpm, which provides the higher level analysis
tools, but I'm not sure why that's necessary, given that RHEL4 should
be providing those pieces (albeit with lower version numbers?) out of
the box.

 Jon

| > but I don't want to reproduce effort if there are nice scripts or  GUIs
| > available already. 
| 
| Aside from that perl based viewer and aureport, nothing I know of. It would be 
| helpful to me to know what your use cases/requirements are.
| 
| Thanks,
| -Steve

-- 
-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Tools for reviewing audit logs ?

[Steve Grubb]

On Wednesday 13 December 2006 11:36, Jonathan Abbey wrote:
> I'm guessing that was Leigh Purdie and the Snare team down at
> Intersect Alliance in oz. 

It wasn't Leigh, it was someone else about a month later.

> They are providing/recommending 'audit-1.2.1-1.i386.rpm' and
> 'audit-libs-1.2.1-1.i386.rpm' in addition to their
> SnareLinux-1.0b7-1.i386.rpm, 

Hopefully that is "or higher".

> but I'm not sure why that's necessary, given that RHEL4 should be providing
> those pieces (albeit with lower version numbers?) out of  the box.

RHEL4 did not have the dispatcher interface in it right away. I wanted to 
study the problem a little more since the API might change based on real use 
scenarios.

I think we've gotten enough runtime now to see how its working out and I've 
backported it - which became the 1.0.15 release. I have another set of 
updates to make and I'll release a 1.0.16 version and that should make it to 
the U5 release. So, that would be the first RHEL4 version that could support 
such a setup.

-Steve

RE: Tools for reviewing audit logs ?

[Wieprecht, Karen M.]

 
I've worked with Leigh before, he's a great guy.  He implemented some
fixes for me with the Irix versions of Snare and posted my sat2text
script on sourceforge
(http://www.intersectalliance.com/projects/SnareIrix/Download/sat2text-1
.1-beta.pl). 

I haven't looked at the Snare Micro Server in  a while.  The last time I
looked at some snapshots of its output, it was collecting logs from
multiple UNIX platforms, but the messages themselves still had pieces
(strings) in the more native/difficult to read format, so I never really
pursued demoing the package. Lots may have changed in recent revisions,
and it might be worth another look.  

Of the GUIs I've seen, many have similar problems, but most of the
issues I have are not in the GUI developer's handling of the audit data,
but in the audit data itself: the number and type of fields in each
record varies greatly depending on the type of record, and this makes it
very difficult to process the data in a human-understandable way.  

Some of the problems I've seen with older GUIs are illustrated by
looking at the old snare GUI from Red Hat 9: 

1. The snare guys handled the varying record field problem by  showing
the common fields in the top level of the GUI. If you wanted to get the
event-specific details from the record though, you had to open every
single one individually which is time consuming.   I don't think there
were any high level AI interfaces for determining if joe-user tried to
break into the machine or was messing around with system confif files, I
think you had to open each record and look at its specific data fields
to determine that type of thing, and isn't very practical if you have a
lot of audit data or a lot of systems to review.  (Again, the snare
microserver may have more analysis capabilities now)

2. You could only look at data from one system at a time (I know that
the Snare microserver can help with this issue).

3. The old SNARE Gui would also only show you the audit file  that was
currently being written.  If you wanted to go back and look at old audit
data that you had archived, you couldn't open it with the GUI, you had
to look at the audit data in its native format which is very difficult
to interpret.   (Leigh told me a while back that he would take a look at
writing something for the next release that would allow you to open
older audit files with the GUI, but I haven't checked in a while to see
if that's available). 

I should really take a look at the Snare micro server and see what
current versions can do for me. I imagine lots of cool features have
been added since my last look.

So, what would I want in a tool or GUI?
--------------------------------------

I'm not sure I could come up with a great way to display/analyze this
data, but as a user and as someone who is required to determine if
someone is doing something nasty on my systems, I do know that the tools
need to be easy to use.  Sometimes we configure machines for a facility,
but then  a not-necessarily savvy  facility administrator may be the one
doing the weekly audit log reviews.  Most wouldn't take the time to
learn how to manipulate the data with aureport (or comparable tools)  to
really understand what's happening on their machines, so the more
user-friendly the tool, the better.  

It's also a big help to review data from multiple systems at a time (and
there don't necessarily need to be agents out there doing a central
collection,  I may simply have set up the log rotation to stash the
rotated logs in a central place with names like audit.daterange.system1,
audit.daterange.system2, etc.).  

The Bottom line?  The basic minimum is that I'd to be able to display
audit records in some sort of language-like format. It might be nice to
sort/group data so we can look at big chunks of similar events  at a
time (makes the review process go faster). Another nice to have would be
the ability to do this for multiple systems at once, and  even better
would be to have some analysis/filtering capability to reduce some of
the noise on harmless audit records, allow us to take a closer look at
the more interesting stuff, and to ultimately help determine whether
someone is doing something bad on the machine.   

Thanks a million for listening,  you have been very patient and helpful.
I greatly appreciate it.

Karen Wieprecht

RE: Tools for reviewing audit logs ?

[Wieprecht, Karen M.]

>> It would be helpful to me to know what your use cases/requirements
are.

I guess the main thing we want is to make the audit data easier to
understand when we are reviewing it, and I'd rather not have to issue
multiple ausearch commands per machine times n systems to get an
overview of possible wrongdoing on the machine ... Certainly I can use
those tools to investigate further if I see something suspicious.  

I'll have to see if I can find the script you mentioned online somewhere
and see if it's close to what I want.  If not, here's a feel for what
we'd be interested in as a bare minimum,  and certainly any improvements
would be even better.

Here is a sample of what I did with some test audit output on Solaris
10.  The perl scripts that I have written for Irix, Solaris, and Mac OSX
aren't super savvy, but they pull the data into a key value hash table
so I can reformat it into a more english-like format (and I throw out
stuff my site doesn't care about like file access failures that are
caused by  "file not found" rather than permission problems).  Except
for irix (where I shoot converted stuff to a central host via the syslog
facility), my scripts also manage the audit data to keep it to a
manageable size, move it to a central place where I can keep straight
which data has or has not already been reviewed, and let me review audit
logs on multiple machines all at once.  I wrote these scripts for
Solaris 8 before I knew about snare, then I ported them to mac OSX
(again, snare wasn't available on that platform), and  then ported them
again to Solaris 10 before a snare version was available there.  I use
my scripts in conjuntion with snare on Irix to make the audit data
easier to read.   Here is a samplae of the converted solaris 10 output:


------------------------------------------------------------------- 
 (invalid user)  FAILED to      telnet     into oldpatton from
oldzumwalt:       No account present for user             on 2005-09-28
15:41:29.608 -04:00
 rick  FAILED to      ftp     into oldpatton from oldzumwalt:    bad
password            on 2005-09-28 15:42:00.448 -04:00
 rick  FAILED to      ftp     into oldpatton from oldzumwalt:    misc
failure            on 2005-09-28 15:42:00.451 -04:00
 root  successful     rlogin     into oldpatton from oldzumwalt
on 2005-09-28 15:42:06.297 -04:00
 root  logged out of oldpatton    on 2005-09-28 15:42:15.065 -04:00
 karen  successful     rlogin     into oldpatton from oldzumwalt
on 2005-09-28 15:42:25.127 -04:00
 karen as root  on oldpatton ran     setaudit_addr(2)    on 2005-09-28
15:42:30.905 -04:00 ****
 karen as root  on oldpatton ran     su root     on 2005-09-28
15:42:30.908 -04:00
 karen as root  on oldpatton ran     setaudit_addr(2)    on 2005-09-28
15:42:35.190 -04:00 ****
 karen as root  on oldpatton ran     su rick     on 2005-09-28
15:42:35.193 -04:00
 karen as rick  on oldpatton FAILED to     modify time on   /etc/shadow:
Permission denied        on 2005-09-28 15:42:40.262 -04:00
 karen as rick  on oldpatton FAILED to     remove /etc/shadow:
Permission denied        on 2005-09-28 15:42:46.506 -04:00
 karen as root  on oldpatton FAILED to     su thomas:   bad username
on 2005-09-28 15:44:05.870 -04:00
 karen as root  on oldpatton FAILED to     su dan:      bad auth.
on 2005-09-28 15:44:15.811 -04:00
 (invalid user)  FAILED to      ftp     into oldpatton from oldpatton:
bad password            on 2005-09-28 15:45:03.703 -04:00
 (invalid user)  FAILED to      ftp     into oldpatton from oldpatton:
misc failure            on 2005-09-28 15:45:03.705 -04:00
 rick  FAILED to      ftp     into oldpatton from oldpatton:     bad
password            on 2005-09-28 15:45:15.391 -04:00
 rick  FAILED to      ftp     into oldpatton from oldpatton:     misc
failure            on 2005-09-28 15:45:15.394 -04:00
 dan  FAILED to      telnet     into oldpatton from oldpatton:
Authentication failed           on 2005-09-28 15:45:26.661 -04:00
 karen  on oldpatton FAILED to     open   /etc/security/policy.conf:
Permission denied        on 2005-09-28 15:45:38.063 -04:00
 karen  on oldpatton FAILED to     rmdir
/home/karen/.sunw/pkcs11_softtoken:     File exists      on 2005-09-28
15:45:38.112 -04:00
 karen  on oldpatton FAILED to     open
/dev/devices/pseudo/random@0:urandom:          Permission denied
on 2005-09-28 15:45:38.148 -04:00
 (invalid user)  FAILED to      ssh     into oldpatton from oldpatton:
Authentication failed           on 2005-09-28 15:45:48.094 -04:00
 karen  on oldpatton FAILED to     mkdir
/home/karen/.sunw/pkcs11_softtoken:     File exists      on 2005-09-28
15:46:07.587 -04:00
 karen  on oldpatton FAILED to     open
/dev/devices/pseudo/random@0:urandom:          Permission denied
on 2005-09-28 15:46:07.602 -04:00
 (invalid user)  FAILED to      ssh     into oldpatton from oldpatton:
Authentication failed           on 2005-09-28 15:46:13.153 -04:00
 karen  on oldpatton FAILED to     modify time on   /var/audit:
Permission denied        on 2005-09-28 15:46:22.179 -04:00
 karen  on oldpatton FAILED to     modify time on   /etc/shadow:
Permission denied        on 2005-09-28 15:46:29.514 -04:00
 karen  on oldpatton FAILED to     open   /etc/shadow:   Permission
denied        on 2005-09-28 15:46:47.469 -04:00
 karen  on oldpatton FAILED to     create /etc/shadow:   Permission
denied        on 2005-09-28 15:47:10.423 -04:00
 karen  logged out of oldpatton           on 2005-09-28 15:47:32.486
-04:00

---------------------------------------------------------------- 
I realize that the tabs/spaces don't line up,  but I sort the output,
and even though the entries are no longer in chronological order,
similar records are grouped, the sentences read like english instead of
scrambled garbage, and it's pretty easy to visually scan through the
data.   Savvy programmers might do something better than this, but it's
simple and it beats the pants of off looking at the raw Solaris audit
data:
---------------------------------------------------------------- 

# << --- *snip* ---->>
header,95,2,getaudit_addr(2),,oldpatton,2005-09-28 15:42:35.191
-04:00,subject,karen,root,root,root,root,10377,3015119284,242 513
oldzumwalt,use of privilege,successful use of
priv,sys_audit,return,success,0
header,94,2,su,,oldpatton,2005-09-28 15:42:35.193
-04:00,subject,karen,root,root,root,root,10377,3015119284,242 513
oldzumwalt,text,success for user rick,return,success,0
header,137,2,utimes(2),fe,oldpatton,2005-09-28 15:42:40.262
-04:00,path,/etc/shadow,attribute,100400,root,sys,32,50382,0,subject,kar
en,rick,users,rick,users,10381,3015119284,242 513 oldzumwalt,use of
privilege,failed use of priv,ALL,return,failure: Permission denied,-1
header,137,2,unlink(2),fe,oldpatton,2005-09-28 15:42:46.506
-04:00,path,/etc/shadow,attribute,100400,root,sys,32,50382,0,subject,kar
en,rick,users,rick,users,10382,3015119284,242 513 oldzumwalt,use of
privilege,failed use of priv,ALL,return,failure: Permission denied,-1
header,166,2,symlink(2),fe,oldpatton,2005-09-28 15:43:39.253
-04:00,path,/var/audit/fileshouldntbeallowedindirwhereuserhasnopermissio
n,subject,karen,rick,users,rick,users,10383,3015119284,242 513
oldzumwalt,use of privilege,failed use of
priv,file_dac_search,return,failure: Permission denied,-1
header,214,2,link(2),fe,oldpatton,2005-09-28 15:43:55.986
-04:00,path,/etc/passwd,attribute,100644,root,sys,32,50381,0,path,/var/a
udit/fileshouldntbeallowedindirwhereuserhasnopermission,subject,karen,ri
ck,users,rick,users,10384,3015119284,242 513 oldzumwalt,use of
privilege,failed use of priv,file_dac_search,return,failure: Permission
denied,-1
header,81,2,auditon(2) - get audit state,,oldpatton,2005-09-28
15:44:05.859
-04:00,subject,karen,root,users,rick,users,10385,3015119284,242 513
oldzumwalt,return,success,0
header,95,2,getaudit_addr(2),,oldpatton,2005-09-28 15:44:05.866
-04:00,subject,karen,root,users,rick,users,10385,3015119284,242 513
oldzumwalt,use of privilege,successful use of
priv,sys_audit,return,success,0
header,95,2,getaudit_addr(2),,oldpatton,2005-09-28 15:44:05.866
-04:00,subject,karen,root,users,rick,users,10385,3015119284,242 513
oldzumwalt,use of privilege,successful use of
priv,sys_audit,return,success,0
header,95,2,getaudit_addr(2),,oldpatton,2005-09-28 15:44:05.868
-04:00,subject,karen,root,users,rick,users,10385,3015119284,242 513
oldzumwalt,use of privilege,successful use of
priv,sys_audit,return,success,0
# << --- *snip* ---->>


 Thanks,

Karen Wieprecht


-Steve

Re: Tools for reviewing audit logs ?

[Steve Grubb]

On Wednesday 13 December 2006 11:45, Wieprecht, Karen M. wrote:
> I guess the main thing we want is to make the audit data easier to
> understand when we are reviewing it, and I'd rather not have to issue
> multiple ausearch commands per machine times n systems to get an
> overview of possible wrongdoing on the machine ... Certainly I can use
> those tools to investigate further if I see something suspicious.  

That was the intent of the aureport program. An example running the report
at a remote machine:

[root@discovery ~]# ssh spirit aureport -ts 12/1/2006
root@spirit's password: 

Summary Report
======================
Range of time in logs: 09/05/2006 17:07:44.602 - 12/13/2006 11:59:14.425
Selected time for report: 12/01/2006 00:00:01 - 12/13/2006 11:59:14.425
Number of changes in configuration: 47
Number of changes to accounts, groups, or roles: 4
Number of logins: 10
Number of failed logins: 1
Number of users: 2
Number of terminals: 11
Number of host names: 5
Number of executables: 15
Number of files: 44
Number of AVC denials: 114
Number of MAC events: 4
Number of failed syscalls: 68
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of process IDs: 201
Number of events: 879

Hmm, failed login? Need more details...

[root@discovery ~]# ssh spirit aureport -ts 12/01/2006 -l -i
root@spirit's password: 

Login Report
============================================
# date time auid host term exe success event
============================================
1. 12/01/2006 08:35:03 sgrubb discovery /dev/pts/0 /usr/sbin/sshd yes 35
2. 12/01/2006 08:40:26 root ? tty1 /bin/login yes 45
3. 12/04/2006 13:44:58 sgrubb spirit :0 /usr/sbin/gdm-binary yes 35
4. 12/12/2006 09:41:03 root ? tty1 /bin/login yes 23
5. 12/12/2006 11:11:09 root ? tty1 /bin/login yes 15
6. 12/12/2006 11:16:29 root ? tty2 /bin/login yes 35
7. 12/12/2006 11:23:22 root ? tty1 /bin/login yes 15
8. 12/12/2006 13:02:00 root 192.168.1.200 sshd /usr/sbin/sshd no 43
9. 12/12/2006 13:19:00 root ? tty1 /bin/login yes 15
10. 12/12/2006 14:43:21 sgrubb ? tty2 /bin/login yes 27
11. 12/12/2006 16:16:36 root ? tty1 /bin/login yes 1

Let's see the actual event that failed:

[root@discovery ~]# ssh spirit ausearch -ts 12/12/2006 13:02:00 -sv no -a 43 -i
root@spirit's password: 
----
type=USER_LOGIN msg=audit(12/12/2006 13:02:00.400:43) : user pid=10118 uid=root auid=root
 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 msg='acct=sgrubb: exe=/usr/sbin/sshd 
(hostname=?, addr=192.168.1.200, terminal=sshd res=failed)' 

Does the above not look better than just reviewing the audit logs directly?

> If not, here's a feel for what we'd be interested in as a bare minimum,  and 
> certainly any improvements would be even better.

I do plan to write the audit transport mechanism so that we can have 
centralized audit logs in the near future. But the parser library is first
order of business. After that, there are plans to build a GUI that can 
review the logs. I have a documented road map in the TODO file of the
audit source code.

-Steve