To understand what the aureport utility does, it is vital to know how the logs generated by the audit daemon are structured, and what exactly is recorded for an event. Only then can you decide which report types are most appropriate for your needs.
The following examples highlight two typical events that are logged by
audit and how their trails in the audit log are read. The audit log or
logs (if log rotation is enabled) are stored in the
/var/log/audit
directory. The first example is a
simple less command. The second example covers a
great deal of PAM activity in the logs when a user tries to remotely log
in to a machine running audit.
Example 29.7. A Simple Audit Event—Viewing the Audit Log
type=SYSCALL msg=audit(1234874638.599:5207): arch=c000003e syscall=2 success=yes exit=4 a0=62fb60 a1=0 a2=31 a3=0 items=1 ppid=25400 pid =25616 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="less" exe="/usr/bin/less" key="doc_log" type=CWD msg=audit(1234874638.599:5207): cwd="/root" type=PATH msg=audit(1234874638.599:5207): item=0 name="/var/log/audit/audit.log" inode=1219041 dev=08:06 mode=0100644 ouid=0 ogid=0 rdev=00:00
The above event, a simple less /var/log/audit/audit.log, wrote three messages to the log. All of them are closely linked together and you would not be able to make sense of one of them without the others. The first message reveals the following information:
type
The type of event recorded. In this case, it assigns the
SYSCALL
type to an event triggered by a system
call (less or rather the underlying open). The CWD
event was recorded to record the current working directory at the
time of the syscall. A PATH
event is generated for
each path passed to the system call. The open system call takes only
one path argument, so only generates one PATH
event. It is important to understand that the PATH
event reports the pathname string argument without any further
interpretation, so a relative path requires manual combination with
the path reported by the CWD
event to determine
the object accessed.
msg
A message ID enclosed in brackets. The ID splits into two parts. All
characters before the :
represent a UNIX epoch
time stamp. The number after the colon represents the actual event
ID. All events that are logged from one application's system call
have the same event ID. If the application makes a second system
call, it gets another event ID.
arch
References the CPU architecture of the system call. Decode this
information using the -i
option on any of your
ausearch commands when searching the logs.
syscall
The type of system call as it would have been printed by an strace on
this particular system call. This data is taken from the list of
system calls under /usr/include/asm/unistd.h
and
may vary depending on the architecture. In this case,
syscall=2
refers to the open system call (see
man open(2)) invoked by the less application.
success
Whether the system call succeeded or failed.
exit
The exit value returned by the system call. For the open system call used in this example, this is the file descriptor number. This varies by system call.
a0
to a3
The first four arguments to the system call in numeric form. The values of these are totally system call dependent. In this example (an open system call), the following are used:
a0=62fb60 a1=0 a2=31 a3=0
a0
is the start address of the passed pathname.
a1
is the flags. 8000
in hex
notation translates to 100000
in octal notation,
which in turn translates to O_LARGEFILE
.
a2
is the mode, which, because
O_CREAT
was not specified, is unused.
a3
is not passed by the open
system call. Check the manual page of the relevant system call to
find out which arguments are used with it.
items
The number of strings passed to the application.
ppid
The process ID of the parent of the process analyzed.
pid
The process ID of the process analyzed.
auid
The audit ID. A process is given an audit ID on user login. This ID
is then handed down to any child process started by the initial
process of the user. Even if the user changes his identity (for
example, becomes root
), the audit ID stays the same. Thus you
can always trace actions to the original user who logged in.
uid
The user ID of the user who started the process. In this case,
0
for root
.
gid
The group ID of the user who started the process. In this case,
0
for root
.
euid
, suid
, fsuid
Effective user ID, set user ID, and file system user ID of the user that started the process.
egid
, sgid
, fsgid
Effective group ID, set group ID, and file system group ID of the user that started the process.
tty
The terminal from which the application is started. In this case, a pseudoterminal used in an SSH session.
ses
The login session ID. This process attribute is set when a user logs in and can tie any process to a particular user login.
comm
The application name under which it appears in the task list.
exe
The resolved pathname to the binary program.
subj
auditd records whether the process is subject to any security
context, such as AppArmor. unconstrained
, as in this
case, means that the process is not confined with AppArmor. If the
process had been confined, the binary pathname plus the AppArmor profile
mode would have been logged.
key
If you are auditing a large number of directories or files, assign key strings each of these watches. You can use these keys with ausearch to search the logs for events of this type only.
The second message triggered by the example less call does not reveal anything apart from just the current working directory when the less command was executed.
The third message reveals the following (the type
and
message
flags have already been introduced):
item
In this example, item
references the
a0
argument—a path—that is associated
with the original SYSCALL
message. Had the
original call had more than one path argument (such as a
cp or mv command), an
additional PATH
event would have been logged for
the second path argument.
name
Refers to the pathname passed as an argument to the less (or open) call.
inode
Refers to the inode number corresponding to name
.
dev
Specifies the device on which the file is stored. In this case,
03:01
, which stands for
/dev/sda1
or “first partition on the first
IDE device.”
mode
Numerical representation of the file's access permissions. In this
case, root
has read and write permissions and his group
(root
) has read access while the entire rest of the world
cannot access the file at all.
ouid
and ogid
Refer to the UID and GID of the inode itself.
rdev
Not applicable for this example. The rdev
entry
only applies to block or character devices, not to files.
Example 29.8, “An Advanced Audit Event—Login via SSH” highlights the audit events triggered by an incoming SSH connection. Most of the messages are related to the PAM stack and reflect the different stages of the SSH PAM process. Several of the audit messages carry nested PAM messages in them that signify that a particular stage of the PAM process has been reached. Although the PAM messages are logged by audit, audit assigns its own message type to each event:
Example 29.8. An Advanced Audit Event—Login via SSH
type=USER_AUTH msg=audit(1234877011.791:7731): user pid=26127 uid=0auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=ssh res=success)' type=USER_ACCT msg=audit(1234877011.795:7732): user pid=26127 uid=0
auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=ssh res=success)' type=CRED_ACQ msg=audit(1234877011.799:7733): user pid=26125 uid=0
auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)' type=LOGIN msg=audit(1234877011.799:7734): login pid=26125 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=1172 type=USER_START msg=audit(1234877011.799:7735): user pid=26125 uid=0
auid=0 ses=1172 msg='op=PAM:session_open acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)' type=USER_LOGIN msg=audit(1234877011.823:7736): user pid=26128 uid=0
auid=0 ses=1172 msg='uid=0: exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)' type=CRED_REFR msg=audit(1234877011.828:7737): user pid=26128 uid=0
auid=0 ses=1172 msg='op=PAM:setcred acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)'
PAM reports that is has successfully requested user authentication for
| |
PAM reports that it has successfully determined whether the user is authorized to log in at all. | |
PAM reports that the appropriate credentials to log in have been
acquired and that the terminal changed to a normal terminal
( | |
The user has successfully logged in. This event is the one used by
aureport | |
PAM reports that it has successfully opened a session for | |
PAM reports that the credentials have been successfully reacquired. |
The raw audit reports stored in the /var/log/audit
directory tend to become very bulky and hard to understand. To find
individual events of interest, you might have to read through thousands
of other events before you locate the one that you want. To avoid this,
use the aureport utility and create custom reports.
The following use cases highlight just a few of the possible report types that you can generate with aureport:
When the audit logs have moved to another machine or when you want to analyze the logs of a number of machines on your local machine without wanting to connect to each of these individually, move the logs to a local file and have aureport analyze them locally:
aureport -if myfile
Summary Report
======================
Range of time in logs: 03/02/09 14:13:38.225 - 17/02/09 14:52:27.971
Selected time for report: 03/02/09 14:13:38 - 17/02/09 14:52:27.971
Number of changes in configuration: 13
Number of changes to accounts, groups, or roles: 0
Number of logins: 6
Number of failed logins: 13
Number of authentications: 7
Number of failed authentications: 573
Number of users: 1
Number of terminals: 9
Number of host names: 4
Number of executables: 17
Number of files: 279
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 994
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 1211
Number of events: 5320
The above command, aureport without any arguments,
provides just the standard general summary report generated from the
logs contained in myfile
. To create more
detailed reports, combine the -if
option with any of
the options below. For example, generate a login report that is
limited to a certain time frame:
aureport -l -ts 14:00 -te 15:00 -if myfile
Login Report
============================================
# date time auid host term exe success event
============================================
1. 17/02/09 14:21:09 root: 192.168.2.100 sshd /usr/sbin/sshd no 7718
2. 17/02/09 14:21:15 0 jupiter /dev/pts/3 /usr/sbin/sshd yes 7724
Some information, such as user IDs, are printed in numeric form. To
convert these into a human-readable text format, add the
-i
option to your aureport
command.
If you are just interested in the current audit statistics (events, logins, processes, etc.), run aureport without any other option.
If you want to break down the overall statistics of plain
aureport to the statistics of failed events, use
aureport --failed
:
aureport --failed
Failed Summary Report
======================
Range of time in logs: 03/02/09 14:13:38.225 - 17/02/09 14:57:35.183
Selected time for report: 03/02/09 14:13:38 - 17/02/09 14:57:35.183
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 13
Number of authentications: 0
Number of failed authentications: 574
Number of users: 1
Number of terminals: 5
Number of host names: 4
Number of executables: 11
Number of files: 77
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 994
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 708
Number of events: 1583
If you want to break down the overall statistics of a plain
aureport to the statistics of successful events,
use aureport --success
:
aureport --success
Success Summary Report
======================
Range of time in logs: 03/02/09 14:13:38.225 - 17/02/09 15:00:01.535
Selected time for report: 03/02/09 14:13:38 - 17/02/09 15:00:01.535
Number of changes in configuration: 13
Number of changes to accounts, groups, or roles: 0
Number of logins: 6
Number of failed logins: 0
Number of authentications: 7
Number of failed authentications: 0
Number of users: 1
Number of terminals: 7
Number of host names: 3
Number of executables: 16
Number of files: 215
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 0
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 558
Number of events: 3739
In addition to the dedicated summary reports (main summary and failed
and success summary), use the --summary
option with
most of the other options to create summary reports for a particular
area of interest only. Not all reports support this option, however.
This example creates a summary report for user login events:
aureport -u -i --summary
User Summary Report
===========================
total auid
===========================
5640 root
13 tux
3 wilber
To get an overview of the events logged by audit, use the
aureport -e
command. This command
generates a numbered list of all events including date, time, event
number, event type, and audit ID.
aureport -e -ts 14:00 -te 14:21 Event Report =================================== # date time event type auid success =================================== 1. 17/02/09 14:20:27 7462 DAEMON_START 0 yes 2. 17/02/09 14:20:27 7715 CONFIG_CHANGE 0 yes 3. 17/02/09 14:20:57 7716 USER_END 0 yes 4. 17/02/09 14:20:57 7717 CRED_DISP 0 yes 5. 17/02/09 14:21:09 7718 USER_LOGIN -1 no 6. 17/02/09 14:21:15 7719 USER_AUTH -1 yes 7. 17/02/09 14:21:15 7720 USER_ACCT -1 yes 8. 17/02/09 14:21:15 7721 CRED_ACQ -1 yes 9. 17/02/09 14:21:15 7722 LOGIN 0 yes 10. 17/02/09 14:21:15 7723 USER_START 0 yes 11. 17/02/09 14:21:15 7724 USER_LOGIN 0 yes 12. 17/02/09 14:21:15 7725 CRED_REFR 0 yes
To analyze the log from a process's point of view, use the
aureport -p
command. This command
generates a numbered list of all process events including date, time,
process ID, name of the executable, system call, audit ID, and event
number.
aureport -p
Process ID Report
======================================
# date time pid exe syscall auid event
======================================
1. 13/02/09 15:30:01 32742 /usr/sbin/cron 0 0 35
2. 13/02/09 15:30:01 32742 /usr/sbin/cron 0 0 36
3. 13/02/09 15:38:34 32734 /usr/lib/gdm/gdm-session-worker 0 -1 37
To analyze the audit log from a system call's point of view, use the
aureport -s
command. This command
generates a numbered list of all system call events including date,
time, number of the system call, process ID, name of the command that
used this call, audit ID, and event number.
aureport -s
Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
1. 16/02/09 17:45:01 2 20343 cron -1 2279
2. 16/02/09 17:45:02 83 20350 mktemp 0 2284
3. 16/02/09 17:45:02 83 20351 mkdir 0 2285
To analyze the audit log from an executable's point of view, use the
aureport -x
command. This command
generates a numbered list of all executable events including date,
time, name of the executable, the terminal it is run in, the host
executing it, the audit ID, and event number.
aureport -x
Executable Report
====================================
# date time exe term host auid event
====================================
1. 13/02/09 15:08:26 /usr/sbin/sshd sshd 192.168.2.100 -1 12
2. 13/02/09 15:08:28 /usr/lib/gdm/gdm-session-worker :0 ? -1 13
3. 13/02/09 15:08:28 /usr/sbin/sshd ssh 192.168.2.100 -1 14
To generate a report from the audit log that focuses on file access,
use the aureport -f
command. This
command generates a numbered list of all file-related events
including date, time, name of the accessed file, number of the system
call accessing it, success or failure of the command, the executable
accessing the file, audit ID, and event number.
aureport -f
File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 16/02/09 17:45:01 /etc/shadow 2 yes /usr/sbin/cron -1 2279
2. 16/02/09 17:45:02 /tmp/ 83 yes /bin/mktemp 0 2284
3. 16/02/09 17:45:02 /var 83 no /bin/mkdir 0 2285
To generate a report from the audit log that illustrates which users
are running what executables on your system, use the
aureport -u
command. This command
generates a numbered list of all user-related events including date,
time, audit ID, terminal used, host, name of the executable, and an
event ID.
aureport -u
User ID Report
====================================
# date time auid term host exe event
====================================
1. 13/02/09 15:08:26 -1 sshd 192.168.2.100 /usr/sbin/sshd 12
2. 13/02/09 15:08:28 -1 :0 ? /usr/lib/gdm/gdm-session-worker 13
3. 14/02/09 08:25:39 -1 ssh 192.168.2.101 /usr/sbin/sshd 14
To create a report that focuses on login attempts to your machine,
run the aureport -l
command. This
command generates a numbered list of all login-related events
including date, time, audit ID, host and terminal used, name of the
executable, success or failure of the attempt, and an event ID.
aureport -l -i
Login Report
============================================
# date time auid host term exe success event
============================================
1. 13/02/09 15:08:31 tux: 192.168.2.100 sshd /usr/sbin/sshd no 19
2. 16/02/09 12:39:05 root: 192.168.2.101 sshd /usr/sbin/sshd no 2108
3. 17/02/09 15:29:07 geeko: ? tty3 /bin/login yes 7809
To analyze the logs for a particular time frame, such as only the
working hours of Feb 16, 2009, first find out whether this data is
contained in the the current audit.log
or
whether the logs have been rotated in by running aureport
-t
:
aureport -t
Log Time Range Report
=====================
/var/log/audit/audit.log: 03/02/09 14:13:38.225 - 17/02/09 15:30:01.636
The current audit.log
contains all the desired
data. Otherwise, use the -if
option to point the
aureport commands to the log file that contains the needed data.
Then, specify the start date and time and the end date and time of the desired time frame and combine it with the report option needed. This example focuses on login attempts:
aureport -ts 02/16/09 8:00 -te 02/16/09 18:00 -l
Login Report
============================================
# date time auid host term exe success event
============================================
1. 16/02/09 12:39:05 root: 192.168.2.100 sshd /usr/sbin/sshd no 2108
2. 16/02/09 12:39:12 0 192.168.2.100 /dev/pts/1 /usr/sbin/sshd yes 2114
3. 16/02/09 13:09:28 root: 192.168.2.100 sshd /usr/sbin/sshd no 2131
4. 16/02/09 13:09:32 root: 192.168.2.100 sshd /usr/sbin/sshd no 2133
5. 16/02/09 13:09:37 0 192.168.2.100 /dev/pts/2 /usr/sbin/sshd yes 2139
The start date and time are specified with the -ts
option. Any event that has a time stamp equal to or after your given
start time appears in the report. If you omit the date,
aureport assumes that you meant
today. If you omit the time, it assumes that the
start time should be midnight of the date specified. Use the 24 clock
notation rather than the 12 hour one and adjust the date format to
your locale (specified in /etc/sysconfig/audit
under AUDITD_LANG
, default is
en_US
).
Specify the end date and time with the -te
option.
Any event that has a time stamp equal to or before your given event
time appears in the report. If you omit the date,
aureport assumes that you meant today. If you omit
the time, it assumes that the end time should be now. Use a similar
format for the date and time as for -ts
.
All reports except the summary ones are printed in column format and sent to STDOUT, which means that this data can be piped to other commands very easily. The visualization scripts introduced in Section 29.8, “Visualizing Audit Data” are just one example of how to further process the data generated by audit.