IBM Support

AIX Auditing Best Practices

Question & Answer


Question

I'd like to run auditing on AIX, what are some of the recommendations or best practices?

Answer

This document shows some configuration suggestions for customers using the auditing subsystem in AIX.


Use a separate filesystem for audit data

By default the data collected by auditing goes in a directory called /audit in the root filesystem. Typically the root filesystem is very small, serving mainly as an attachment point to other filesystems, and storage for configuration files (/etc) and device nodes (/dev). Rather than increasing the root filesystem, a better idea is to create a separate filesystem for the audit logs. This way we also avoid the risk of filling up the root filesystem.

If audit checking is enabled by the AIXpert tool it also will create a /audit filesystem, but only uses one of 100MB size. Our recommendation is to use a 2GB filesystem for /audit.

First check to see if auditing is currently running:

# audit query

If auditing is running, decide on a time to stop it, then after it's shut down move the audit files temporarily while you make and mount the dedicated filesystem for it.

# audit shutdown
# mkdir /tmp/oldaudit
# cd /audit
# mv * /tmp/oldaudit

Create and mount the new /audit filesystem. We'll make it in rootvg, 2GB in size using the default JFS2 log logical volume. Also set it to automatically mount at boot time.

# mklv -t jfs2 -y auditlv rootvg 2G
# crfs -v jfs2 -m /audit -Ay -d /dev/auditlv

# cd /
# mount /audit

Now put your audit files back into the new filesystem:
# cd /tmp/oldaudit
# mv * /audit
# cd /tmp
# rmdir oldaudit



Using bin vs stream auditing

Using binary (bin) auditing creates 3 binary files containing the audit trail data: two temporary bin files of a maximum size, and a trail file that the bin files dump into.

Bin mode auditing is going to gather the most information for each record, and store them in a binary record format. Later the auditpr command can be used on the trail to provide readable ASCII output, and searched by the auditselect command. Using auditpr and auditselect on the binary files means you can create sets of audit commands to search or list specific information.

Stream mode, on the other hand, is put into ASCII output according to the commands listed in the /etc/security/audit/streamcmds file. So any customization of audit record output or filtering on the output has to be done by the streamcmds file, or else it will be lost.


Which mode do I use?

  • Because of these features binmode is best for audit records that will be retained for a long period of time. If backups of the trail files are kept, any information that is logged by the audit system can be retrieved using the trail file.
  • The data in the bin files is not deposited immediately into the trail file, so bin mode is not as useful for live system monitoring of events.
  • Stream mode is best for seeing immediate results from audit events, because the data goes directly from auditing through auditpr to the stream output file. For example debugging something on the system, or watching processes or users for only a day or two would give immediate output in stream mode.
  • Multiple streams can be captured in the streamcmds file, each with different filters or output files.
  • The size of binary output is approximately 20-30% of the size of the ASCII stream output when capturing the same events.


Stream auditing output hints

1. The default output for stream ASCII output in the /etc/security/audit/streamcmds is very simple:

/usr/sbin/auditstream | auditpr > /audit/stream.out &

This will give the output from the audit event (audit header), but no further information.

PROC_Execute root OK Mon Jul 11 15:00:20 2016 varyonvg Global

2. Notice that the shell redirection of STDOUT in the default streamcmds file is to have auditpr overwrite the output file /audit/stream.out every time auditing is shut down and restarted. If you wish to append to the same audit output file each time, use the append redirection instead:

/usr/sbin/auditstream | auditpr >> /audit/stream.out &

3. To print the information in the /etc/security/audit/events file printf() statement (the trail), the -v flag is needed. This will print that information on a second line in the stream output file.

Entry in /etc/security/audit/events for this event:

PROC_Execute = printf "euid: %d egid: %d epriv: %x:%x name %s"

so the second line for this output provides information from that printf() statement:

PROC_Execute root OK Mon Jul 11 15:05:49 2016 varyonvg Global
euid: 0 egid: 0 epriv: ffffffff:ffffffff name varyonvg testvg

This can be helpful when wanting to see the arguments given by a command, such as a filename to be used by the command.

4. Extremely verbose output can be printed using the -h flag to auditpr to select addtional fields.

-h field[,field]*
Selects the fields to display and the order in which to display them, by default
e, l, R, t, and c. You can specify the following values:
e The audit event.
l The login name of the user.
R The audit status.
t The time the record was written.
c The command name.
r The real user name.
p The process ID.
P The ID of the parent process.
T The kernel thread ID, local to the process.
h The name of the host or CPU ID that generated the audit record.
i The IDs or the names of roles of the audited process.
E The effective privilege.
S The effective sensitivity label (SL).
I The effective integrity label (TL).
W The workload partition name.

So for a very verbose example, with headers

/usr/sbin/auditstream | auditpr -v -t1 -herlRtcpP > /audit/stream.out &

event real login status time command process parent
--------------- -------- -------- ----------- ------------------------ ------------------------------- -------- --------
PROC_Execute root bob OK Mon Jul 11 15:10:39 2016 varyonvg 7209108 8388706
euid: 0 egid: 0 epriv: ffffffff:ffffffff name varyonvg testvg

Now we know the parent's process ID as well as the varyonvg, and we know it was run by user "bob" who was su'ed to root at the time.


You cannot audit a symbolic link

Trying to audit a symbolic link as an object will cause auditing to fail when started. For example if you audit the /bin link as an object to see if it is read or written to in this configuration:

# ls -ld /bin
lrwxrwxrwx 1 bin bin 8 Jul 28 2015 /bin -> /usr/bin

At the end of the objects file, add a stanza to monitor the link for reading or writing:

/bin:
w = "BIN_W"
r = "BIN_R"

# audit start
** failed setting kernel audit objects

Once this stanza is removed from the objects file auditing will start successfully.


References
auditbin daemon
http://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.cmds1/auditbin.htm

Short page about configuring auditing
http://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/setting_up_auditing.htm

[{"Product":{"code":"SWG10","label":"AIX"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Not Applicable","Platform":[{"code":"PF002","label":"AIX"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]

Document Information

Modified date:
17 June 2018

UID

isg3T1023926