System Auditing with AIX

Learn how to use classes and objects to monitor events

AIX Audit is the built-in audit subsystem that monitors and records file and command activities. It isn’t an intrusion detection system (IDS); instead, it detects writes, reads, and executions of files and their processes as well as the users that invoked them. In this article, I’ll explain how AIX Audit works, and then I’ll demonstrate how to use it.

Understanding AIX Audit

AIX Audit monitors and records events on your system. The events are grouped into classes. For example, you might want a class that contains events related to logins, logouts, and su command usage. You might also decide that you want another class that includes events related to creating and removing file systems or devices. These classes can be assigned to the auditclass attribute of users. You can have more than one audit class associated with a user. If the events are triggered by that user, they’ll be reported in the audit log.

AIX Audit also lets you monitor read, write, and execution operations for individual files, which are referred to as audit objects. Audit objects aren’t assigned to a class because they’re global objects. That means if any user triggers these objects, the event is reported in the audit log. Events that are written to the audit log are written as audit records.

So, in a nutshell, you can use the following to monitor events:

• One or more classes that are assigned on a per-user basis
• Global objects that can’t be assigned to individual users

You can use either the bin mode or the stream mode to capture audit events. The bin mode records and writes to circular log files, so it’s a good mode to use when you need to keep the audit history over a long period and when you’re required to do ad hoc extracts from the audit logs. The stream mode provides real-time audit processing and the flexibility to generate daily audit reports. This mode is used by most systems admins, so I’ll concentrate on it.

When using the stream mode, the audit log is named /audit/stream.out. All of the configuration files you need to alter are in the /etc/security/audit folder. One of the configuration files is config, which contains predefined classes that haven’t been assigned to users. There are quite a few classes, and it would take too long to explain them all in this article. However, the class names and events are pretty self-explanatory. The code below shows an excerpt from a config file. As you can see, the classes contain a variety of events.
 

1. # cat config
2. start:
3.         binmode = on
4.         streammode = off
5.  
6. bin:
7.         bincompact = off
8.         trail = /audit/trail
9.         bin1 = /audit/bin1
10.         bin2 = /audit/bin2
11.         binsize = 10240
12.         cmds = /etc/security/audit/bincmds
13.         freespace = 65536
14.         backuppath = /audit
15.         backupsize = 0
16.  
17. stream:
18.         cmds = /etc/security/audit/streamcmds
19.  
20. classes:
21.         general = USER_SU,PASSWORD_Change,FILE_Unlink,FILE_Link,FILE_Rename,FS_C
22.         hdir,FS_Chroot,PORT_Locked,PORT_Change,FS_Mkdir,FS_Rmdir
23.         objects = S_ENVIRON_WRITE,S_GROUP_WRITE,S_LIMITS_WRITE,S_LOGIN_WRITE,
24.         S_PASSWD_READ,S_PASSWD_WRITE,S_USER_WRITE,AUD_CONFIG_WR
25.         SRC = SRC_Start,SRC_Stop,SRC_Addssys,SRC_Chssys,SRC_Delssys,
26.         SRC_Addserver,SRC_Chserver,SRC_Delserver
27.         kernel = PROC_Create,PROC_Delete,PROC_Execute,PROC_RealUID,PROC_AuditID,
28.         PROC_RealGID,PROC_Environ,PROC_Limits,PROC_SetPri,PROC_Setpri,PROC_Privilege,
29.         PROC_Settimer
30.         files = FILE_Open,FILE_Read,FILE_Write,FILE_Close,FILE_Link,FILE_Unlink,
31.         FILE_Rename,FILE_Owner,FILE_Mode,FILE_Acl,FILE_Privilege,DEV_Create
32.         ...
33.  
34. users:
35.         root = general

On a fresh AIX 7.1 installation, only the user root is assigned an audit class. Generally, that class is:

1. # lsuser -a auditclasses ALL |grep general
2. root auditclasses=general

You can audit a Workload Partition (WPAR), Logical Partition (LPAR), or standalone box. Plus, AIX Audit isn’t tied down to local systems; you can also use it to monitor files residing on NFS-mounted file systems. If you’ve set roles for users, they won’t be able to escape the audit. All you need to do is make sure you add the audit class when you create the role.

Now that you know how AIX Audit works, I’ll demonstrate how to create a new class, assign the class to users, and run an audit. I’ll also show you how to add and use objects.

Creating a Class

If you don’t want to use a predefined class, you can create your own. For example, suppose you need a class to monitor the account changes that your systems admins would make during a typical day. To meet this need, your class could monitor the following events:

• File writes
• Password changes
• chuser command usage
• Group account changes
• User account changes
• su command usage

Note that the audit won’t be fooled by the use of su or sudo commands. It will report the user ID (UID) of the actual user, not the switched or aliased user.

By default, AIX Audit writes all logs to /audit. To avoid filling up the root file system, you should create a file system to hold all of the audit logs. I recommend creating a file system named audit whose size is 5GB.

Next, you need to configure AIX Audit to use the stream mode by editing the /etc/security/config file. In the start stanza (i.e., section), change the following entries to:

1. binmode=off
2. streammode=on

In the classes stanza, add the following line to create a class named basic:

1. basic = File_Write,PASSWORD_Change,USER_Change,
2.   USER_Remove,USER_Create,GROUP_Change,GROUP_Create,
3.   GROUP_Remove,USER_SU,PASSWORD_Flags

Adding Users to a Class

At this point, you can add the users you want to monitor to your class. For example, to add the users dxtans and root to the basic class, you need to modify the users stanza in the config file so that it looks like this:

1. users:
2.   dxtans = basic
3.   root = general, basic

Notice that I didn’t remove the general class from the user root.

If you want all users included in a class, you can use the reserved word default. For example, if you want all users included the basic class, you’d edit the users stanza so that it looks like this:

1. users:
2.   default = basic

However, don’t make that change here. Instead, save and exit the config file. The auditclasses attribute for the users dxtans and root will then be updated. Although the AIX man page states that you should use the chuser command to add the classes to the users, this isn’t required in AIX 7.1. Saving and exiting the config file will automatically do this for you.

The next file that needs to be edited is /etc/security/streamcmds. Change the current entry to:

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

Notice that -v has been added. This needs to be included to get a full record of the triggered event. If it’s not, only some of the details about the event will get reported. For example, AIX Audit won’t record any extra flags used in a command that’s being monitored.

Running Audits

After you’ve assigned your new class to users, you’re ready to run an audit. To do so, use the command:

1. # audit start

You’ll immediately get some results in the audit log (i.e., stream.out), courtesy of thegeneral class that the user root is tied to. The log will include the following details:

• Audit event
• Login name
• Status of command execution
• Date and time
• Command executed (with any flags)
• WPAR name (if applicable)

The following code shows an excerpt from my audit log, which I formatted for easier reading.
 

1. S_PASSWD_READ   root  OK  Mon Jul 02 17:55:00 2012 cron  Global  audit object read event detected /etc/security/passwd
2.  
3. S_PASSWD_READ   root  OK  Mon Jul 02 17:55:00 2012 cron  Global  audit object read event detected /etc/security/passwd

At this point, you should review what was logged with the general class in your audit log.

Now, let’s see what happens when only events from the basic class are monitored. Stop the audit using the command:

1. # audit shutdown

Open the /etc/security/config file and remove the general class from the user root so that the users stanza looks like this:

1. users:
2.   dxtans = basic
3.   root = basic

Save and exit the config file.

Note that every time you restart an audit, the audit log will be overwritten. So, if you want to keep the existing contents, you’ll need to move them into a different file.

Start the audit again. Let’s see what gets audited when user dxtans runs the following commands, putting in the appropriate passwords when prompted:

1. $ whoami
2. dxtans
3. $ passwd
4. Changing password for "dxtans"
5. dxtans's Old password:
6. dxtans's New password:
7. Enter the new password again:
8. $ su -
9. root's Password:
10. # passwd echo
11. Changing password for "echo"
12. echo's New password:
13. Enter the new password again:
14. # pwdadm -c echo

If you look at the audit log, you’ll now see a trail of events for user dxtans. The code below shows an excerpt (formatted for readability). Although the su command was used to switch to the user root, the log still reports the top-level user, which is dxtans.
 

1. PASSWORD_Change dxtans  OK  Mon Jul 02 18:16:42 2012 passwd  Global  dxtans
2. S_PASSWD_READ   dxtans  OK  Mon Jul 02 18:16:45 2012 su      Global  audit object read event detected /etc/security/passwd
3. S_PASSWD_READ   dxtans  OK  Mon Jul 02 18:16:45 2012 su      Global  audit object read event detected /etc/security/passwd
4. S_PASSWD_READ   dxtans  OK  Mon Jul 02 18:16:49 2012 su      Global  audit object read event detected /etc/security/passwd
5. S_PASSWD_READ   dxtans  OK  Mon Jul 02 18:16:49 2012 su      Global  audit object read event detected /etc/security/passwd
6. USER_SU         dxtans  OK  Mon Jul 02 18:16:49 2012 su      Global  root
7. PASSWORD_Change dxtans  OK  Mon Jul 02 18:17:00 2012 passwd  Global  echo
8. PASSWORD_Flags  dxtans  OK  Mon Jul 02 18:17:04 2012 pwdadm  Global  echo -c

Although it’s not shown above, your log will show an event for when you edited the config file, even though it’s not in the basic or general class. This is because it’s been defined as an object. Similarly, the /etc/security/passwd file has been defined as an object.

Defining Objects

The /etc/security/audit/objects file is used for objects (i.e., individual files) that aren’t covered by the built-in events provided by AIX. In general, the objects file contains system configuration objects and your own custom objects, such as scripts. When adding an object to the objects file, you follow the format:

1. full_path_to_file:
2. access_mode="audit_name"

where:

• full_path_to_file is the path and filename of the object you want to monitor
• access_mode is the mode you want to monitor, which can be r (read), w (write), or x (execute)
• audit_name is a meaningful name for the object you want to monitor

For example, if you want to monitor the file /etc/ssh/sshd_conf for writes, you would enter:

1. /etc/ssh/sshd_conf:
2. w="SSHD_CONF_W"

Notice that I appended _W to the audit_name SSHD_CONF to easily identify this entry as a write command. Although I used all uppercase letters, you can use lowercase letters if desired.

If you want to monitor more than one access mode for the same file, you need to have a separate entry for each mode. For example, if you want to monitor the file /usr/local/bin/myscript for write and execute operations, you'd enter:

1. /usr/local/bin/myscript:
2. w="MYSCRIPT_W"
3.  
4. /usr/local/bin/myscript:
5. x="MYSCRIPT_X"

Now that some objects have been defined in the objects file, you need to let AIX Audit know how to print them. The /etc/security/audit/ events file controls how the audited events get printed. To enter an object in the events file, you follow the format:

1. *   full_path_to_file
2. audit_name=printf "%s"

where:

• full_path_to_file is the path and filename of the object you want to monitor
• audit_name is a meaningful name you gave to the object in the objects file

For example, if you want to print the SSHD_CONF_W object, you would enter:

1. *   /etc/ssh/sshd_conf
2. SSHD_CONF_W=printf "%s"

If a user edits a file that’s defined as an object (e.g., /etc/ssh/sshd_ conf) and keeps that file open in the editor for 30 seconds, you’ll see a few entries of the same record in the audit log stating that the file has been written to. Although these aren’t duplicate entries, you might want to run the uniq command prior to viewing the audit log.

Looking at the Evidence

To see how object-triggered events appear in the audit log, let’s add the following objects, then edit them so that they get monitored and printed:

• /usr/local/bin/get_config (monitor for executions)
• /etc/inetd.conf (monitor for writes)
• /etc/syslog.conf (monitor for writes)

To begin, add the following entries to the objects file:

1. /usr/local/bin/get_config:
2. x = "GET_CONFIG_X"
3.  
4. /etc/inetd.conf:
5. w = "INETD_CONF_W"
6.  
7. /etc/syslog.conf:
8. w = "SYSLOG_W"

Next, add the following entries to the events file:

1. *   /usr/local/bin/get_config
2. GET_CONFIG_X = printf "%s"
3.  
4. *   /etc/inetd.conf
5. INETD_CONF_W = printf "%s"
6.  
7. *   /etc/syslog.conf
8. SYSLOG_W = printf "%s"

For the changes to take effect, you’ll need to stop and restart AIX Audit using the commands:

1. # audit shutdown
2. # audit start

Finally, have user dxtans perform the following actions:

• Execute the script /usr/local/bin/get_config.
• Use the su command to switch to the user root.
• Edit the /etc/inetd.conf file.
• Edit the /etc/syslog.conf file.

To view the auditing results, run the command:

1. # tail -f /audit/stream.out

The code below shows an excerpt from the results, formatted for easier reading.
 

1. GET_CONFIG_X  dxtans  OK  Wed Jul 04 04:28:04 2012 get_config  Global  audit object exec event detected /usr/local/bin/get_config
2. USER_SU       dxtans  OK  Wed Jul 04 04:28:19 2012 su          Global  root
3. INETD_CONF_W  dxtans  OK  Wed Jul 04 04:29:21 2012 vi          Global  audit object write event detected /etc/inetd.conf
4. SYSLOG_W      dxtans  OK  Wed Jul 04 04:29:35 2012 vi          Global  audit object write event detected /etc/syslog.conf

An Excellent Tool

AIX Audit is an excellent tool for gathering events on your system. If you want to keep a daily audit log, I recommend that you stop the audit once a day, move the contents of the stream.log file to a file whose name includes a date stamp, then restart the audit. This process will ensure that you have an audit report for each day.