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