Setting up and configuring the AIX audit subsystem
BIN mode collection is the recommended method when auditing a
production system.
BIN mode
The BIN mode collection method is batch oriented and is used for longtime storage of large
amounts of audit data. In BIN mode, audit records are alternately collected in two temporary files
called bin files. When one bin file is full (size is specified in /etc/security/audit/config) the audit
logger switches to the other bin file. The auditbin daemon is responsible for flushing the full bin to
an audit trail. The data in the bin is flushed to the trail according to the backend commands that
reside in the /etc/security/audit/bincmds file.
Audit subsystem commands
Audit subsystem commands control the AIX® audit subsystems and its output. The
/usr/sbin/audit command enables you to start, shutdown, suspend, and inquire the audit
subsystem. This command has the following variations:
audit start
Starts the audit subsystem.
audit shutdown
Ends the audit subsystem; when BIN mode collection is used the bin files are
flushed.
audit off
Suspends the audit subsystem temporarily.
audit on
Restarts the audit subsystem when it has been suspended.
audit query
Displays the current status of the auditing system, and list all audit classes and
selected objects.
Important:
To enable the audit subsystem to start each time the system is started, the following line must be
added to the /etc/rc file:
/usr/sbin/audit start
The Control Files
The following files control the auditing subsystem:
/etc/security/audit/config
/etc/security/audit/bincmds
/etc/security/audit/events
/etc/security/audit/objects
/etc/security/audit/streamcmds
Audit Configuration Requirements
Please refer to chapter 2.1.1, AIX Platforms, section 6, Activity Auditing of ITXC104 for
configuration requirements. Chapter 2.1.1, AIX platforms can be found at the following URL:
http://w3-03.ibm.com/transform/sas/as-web.nsf/ContentDocsByTitle/AIX+Platforms
In addition to requirements specified in ITCS104, the following
configuration settings must be in place.
The security administrator must add the following lines at the end of the /etc/security/audit/events
file:
* Object Audit Event definitions needed
* for Tivoli Compliance Insight Manager
Obj_READ = printf "%s"
Obj_WRITE = printf "%s"
Obj_EXECUTE = printf "%s"
The objects that need to be monitored for auditing must be present in the
/etc/security/audit/objects file. Each object has a stanza that defines one or more access modes
(read, write, or execute). The access modes are associated with the object audit event types that
were defined earlier in the /etc/security/audit/events file. The following stanzas must be included
in the /etc/security/audit/objects file.
/etc/sudoers:
r = "Obj_READ"
w = "Obj_WRITE"
/usr/local/bin/pbrun:
x = "Obj_EXECUTE"
/var/adm/syslog-00-00-00.log:
r = "Obj_READ"
w = "Obj_WRITE"
Instructions for adding sudo logs to syslog for collection by TCIM:
1. Edit the sudoers file to add the following line under #Defaults. Example
# Defaults specification
Defaults syslog=local2
2. If there is already a Defaults entry in the file you can merge the two settings like this:
# Defaults specification
Defaults syslog=local2,log_year,logfile=/var/log/sudo.log
3. Create the log file by using touch:
$ touch /var/adm/syslog-00-00-00.log
4. Edit the syslog.conf file and add the following at the bottom:
local2.debug /var/adm/syslog-00-00-00.log rotate files 3 time 1m
5. Restart the syslog deamon:
# stopsrc -s syslogd
0513-044 The syslogd Subsystem was requested to stop.
# startsrc -s syslogd
0513-059 The syslogd Subsystem has been started. Subsystem PID is 168102.
Run the following two commands in sequence to restart the auditing subsystem:
# audit shutdown
# audit start
You may use the following command to query the audit subsystem for the list of defined objects:
# audit query
You should see something like the following;
auditing on
audit bin manager is process 10114
audit events:
objects
S_ENVIRON_WRITE,S_GROUP_WRITE,S_LIMITS_WRITE,S_LOGIN_WRITE,
S_PASSWD_READ,S_PASSWD_WRITE,S_USER_WRITE,AUD_CONFIG_WR
itcs104
USER_SU,PASSWORD_Change,PROC_Reboot,USER_Reboot,DEV_Change,
DEV_Configure,DEV_Create,DEV_Remove,DEV_Start,DEV_Stop,
DEV_UnConfigure,ACCT_Disable,ACCT_Enable,PORT_Change,
PORT_Locked,TCPIP_config,TCPIP_kconfig,TCPIP_kroute,TCPIP_route,
ENQUE_exec,FS_Extend,FS_Mount,FS_Umount,FS_Chroot,
RESTORE_Import,AUD_Events,AUD_Objects,AUD_Proc,AUD_It,
INSTALLP_Inst,TCPIP_set_time,PROC_Adjtime,PROC_Sysconfig,
PROC_LoadError,TCPIP_host_id
audit objects:
/etc/security/audit/config:
w = AUD_CONFIG_WR
/etc/security/environ:
w = S_ENVIRON_WRITE
/etc/security/group:
w = S_GROUP_WRITE
/etc/security/limits:
w = S_LIMITS_WRITE
/etc/security/login.cfg:
w = S_LOGIN_WRITE
/etc/security/passwd:
r = S_PASSWD_READ
w = S_PASSWD_WRITE
/etc/security/user:
w = S_USER_WRITE
/etc/sudoers:
r = Obj_READ
w = Obj_WRITE
/usr/local/bin/pbrun:
x = Obj_EXECUTE
/var/adm/syslog-00-00-00.log:
r = Obj_READ
w = Obj_WRITE
#
#
The object audit events are written to the audit bins in the same manner as the events generated
from the standard event auditing. The following are two commands that can be used together to
view the object audit events. The auditpr command is used to convert the binary audit records
into a readable format. It is assumed that the audit bins are defined in the /audit folder and bin1
is the current active bin.
# auditcat /audit/bin1 | auditpr -v
event login status time command
--------------- -------- ----------- ------------------------ --------
Obj_READ root OK Tue Dec 06 17:08:21 2005 vi
audit object read event detected /etc/sudoers
Obj_WRITE root OK Tue Dec 06 17:08:26 2005 vi
audit object write event detected /etc/sudoers
Obj_EXECUTE root OK Tue Dec 06 17:09:09 2005 pbrun
audit object exec event detected /usr/local/bin/pbrun
#
#
The Event column shows the AIX® event name as defined in the /etc/security/audit/events file.
The Login column displays the user ID that performed the action. The Status column indicates a
success or failure of the action. The Command column shows the command or the program
name that wrote the audit event. The three object audit events shown in the example indicate
read and write actions on the /etc/sudoers file and execute action on the /usr/local/bin/pbrun file.
create an id “insight” that has permission to the following:
The SSH collect process does not require Actuator installation on an audited system. However,
the correct Tivoli Compliance Insight Manager user must be created on the audited system and
included in the following standard groups: security, system, and audit. You must also add groupwrite
permissions for the /var/log/eprise directory. The Tivoli Compliance Insight Manager user
must have the following rights:
• Read permissions for the failedlogin file (/etc/security/failedlogin), and rx permissions on
the /etc and /etc/security directories.
• Read permissions for the wtmp file (/var/adm/wtmp), and rx permissions on the /var and
/var/adm directories.
• Full access (rwx) to /var/log/eprise, and rx permissions on /var and /var/log.
• Read and write access to the files created in /var/log/eprise.
• Read permissions for the /var/adm/syslog-00-00-00.log file
Setting up the SSH user on AIX systems
Use this procedure to create a user account on a to-be-audited AIX® system and to set it up so
that it can be used by Tivoli Compliance Insight Manager to remotely collect log data:
1. Log in to the audited system as the root user.
2. To create a Tivoli Compliance Insight Manager user, type the following command: mkuser
username
where username is the user ID you want to use. Your system might have requirements
for valid passwords. If the mkuser utility returns a message saying the username is not
valid, try another combination until the value is accepted.
3. To set the user password:
a. At the command prompt, type passwd username, where username is the user
ID you just created.
b. When prompted, enter the new password. Then, enter it again to confirm.
4. Change the login shell to /bin/sh:
a. Type passwd -s username.
5.
a. At the prompt, type Y to change the login shell.
b. Type the directory you want to change to as illustrated in the following example:
c. Change (yes) or (no)? >y
d. To ?>/bin/sh
crme 12:/#
6. After you change the login shell, the Tivoli Compliance Insight Manager user should be
able to run tar and gzip utilities without specifying the full path to them.
7. To verify that the tar and gzip utilities are accessible to the Tivoli Compliance Insight
Manager user from the shell:
a. Log in as the root user.
b. To locate the utilities, run the following command: which tar gzip
8.
a. At the prompt, type Y to change the login shell.
b. Type the directory you want to change to as illustrated in the following example:
c. Change (yes) or (no)? >y
d. To ?>/bin/sh
crme 12:/#
9. After you change the login shell, the Tivoli Compliance Insight Manager user should be
able to run tar and gzip utilities without specifying the full path to them.
10. To verify that the tar and gzip utilities are accessible to the Tivoli Compliance Insight
Manager user from the shell:
a. Log in as the root user.
b. To locate the utilities, run the following command:
which tar gzip
11.
a. Figure 4. Editing the SSH user group file to add the Tivoli Compliance Insight
Manager user
b. Save the edited file.
i. If you are using the vi text editor, press Esc, or type wq to exit. You
should see the following command after typing this:
Figure 5. Command output after adding the Tivoli Compliance Insight
Manager user to the SSH user group
ii. Press Enter to save the file.
c. Then remove write access to file group for the owner.
chmod u-w group
Attention:
The AIX system might have a specific configuration where these steps do not apply. In that case,
check the group ownership and group permissions of the files that are collected, and verify that
the Tivoli Compliance Insight Manager has the required authorizations to access the files for
collection.
POST
These steps to be completed after the machine has been setup and configured in TCIM server:
The public key is sent to the admin and the admin needs to follow the following steps :
Installing the public key using OpenSSH
1. Create a hidden .ssh directory in the home directory of the Tivoli Compliance Insight
Manager user if it does not already exist. Type the following command, for example:
mkdir $HOME/.ssh
2. In the ssh directory, create or edit a file called authorized_keys. Then, paste the contents
of the temporary public key file, which was created on the point of presence and
transferred to the audited system, into the file as a single line. Delete the temporary key
file when done. Use any text editor or use the following commands on the command line:
touch $HOME/.ssh/authorized_keys
cat tempkey >> $HOME/.ssh/authorized_keys
rm tempkey
3. Set the permissions on the .ssh directory and the authorized_keys file so that the insight
user is the owner with read access. Type the following commands to set the ownership
and permissions correctly:
cd $HOME
chown insight .ssh .ssh/*
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
4. After you set the permissions, review the ssh directory listing. The listing should be
similar to the following:
total 56
drwx------ 2 insight users 4096 Dec 18 02:51 .
drwx------ 47 insight users 4096 Jan 4 17:24 ..
-rw------- 1 insight users 452 Apr 8 2005
authorized_keys
Note:
After the connection between the point or presence and the audited system has been
established for the first time, the SSH daemon creates and stores additional files, which
are required for normal functioning of the SSH connection, in the .ssh directory.
BIN mode collection is the recommended method when auditing a
production system.
BIN mode
The BIN mode collection method is batch oriented and is used for longtime storage of large
amounts of audit data. In BIN mode, audit records are alternately collected in two temporary files
called bin files. When one bin file is full (size is specified in /etc/security/audit/config) the audit
logger switches to the other bin file. The auditbin daemon is responsible for flushing the full bin to
an audit trail. The data in the bin is flushed to the trail according to the backend commands that
reside in the /etc/security/audit/bincmds file.
Audit subsystem commands
Audit subsystem commands control the AIX® audit subsystems and its output. The
/usr/sbin/audit command enables you to start, shutdown, suspend, and inquire the audit
subsystem. This command has the following variations:
audit start
Starts the audit subsystem.
audit shutdown
Ends the audit subsystem; when BIN mode collection is used the bin files are
flushed.
audit off
Suspends the audit subsystem temporarily.
audit on
Restarts the audit subsystem when it has been suspended.
audit query
Displays the current status of the auditing system, and list all audit classes and
selected objects.
Important:
To enable the audit subsystem to start each time the system is started, the following line must be
added to the /etc/rc file:
/usr/sbin/audit start
The Control Files
The following files control the auditing subsystem:
/etc/security/audit/config
/etc/security/audit/bincmds
/etc/security/audit/events
/etc/security/audit/objects
/etc/security/audit/streamcmds
Audit Configuration Requirements
Please refer to chapter 2.1.1, AIX Platforms, section 6, Activity Auditing of ITXC104 for
configuration requirements. Chapter 2.1.1, AIX platforms can be found at the following URL:
http://w3-03.ibm.com/transform/sas/as-web.nsf/ContentDocsByTitle/AIX+Platforms
In addition to requirements specified in ITCS104, the following
configuration settings must be in place.
The security administrator must add the following lines at the end of the /etc/security/audit/events
file:
* Object Audit Event definitions needed
* for Tivoli Compliance Insight Manager
Obj_READ = printf "%s"
Obj_WRITE = printf "%s"
Obj_EXECUTE = printf "%s"
The objects that need to be monitored for auditing must be present in the
/etc/security/audit/objects file. Each object has a stanza that defines one or more access modes
(read, write, or execute). The access modes are associated with the object audit event types that
were defined earlier in the /etc/security/audit/events file. The following stanzas must be included
in the /etc/security/audit/objects file.
/etc/sudoers:
r = "Obj_READ"
w = "Obj_WRITE"
/usr/local/bin/pbrun:
x = "Obj_EXECUTE"
/var/adm/syslog-00-00-00.log:
r = "Obj_READ"
w = "Obj_WRITE"
Instructions for adding sudo logs to syslog for collection by TCIM:
1. Edit the sudoers file to add the following line under #Defaults. Example
# Defaults specification
Defaults syslog=local2
2. If there is already a Defaults entry in the file you can merge the two settings like this:
# Defaults specification
Defaults syslog=local2,log_year,logfile=/var/log/sudo.log
3. Create the log file by using touch:
$ touch /var/adm/syslog-00-00-00.log
4. Edit the syslog.conf file and add the following at the bottom:
local2.debug /var/adm/syslog-00-00-00.log rotate files 3 time 1m
5. Restart the syslog deamon:
# stopsrc -s syslogd
0513-044 The syslogd Subsystem was requested to stop.
# startsrc -s syslogd
0513-059 The syslogd Subsystem has been started. Subsystem PID is 168102.
Run the following two commands in sequence to restart the auditing subsystem:
# audit shutdown
# audit start
You may use the following command to query the audit subsystem for the list of defined objects:
# audit query
You should see something like the following;
auditing on
audit bin manager is process 10114
audit events:
objects
S_ENVIRON_WRITE,S_GROUP_WRITE,S_LIMITS_WRITE,S_LOGIN_WRITE,
S_PASSWD_READ,S_PASSWD_WRITE,S_USER_WRITE,AUD_CONFIG_WR
itcs104
USER_SU,PASSWORD_Change,PROC_Reboot,USER_Reboot,DEV_Change,
DEV_Configure,DEV_Create,DEV_Remove,DEV_Start,DEV_Stop,
DEV_UnConfigure,ACCT_Disable,ACCT_Enable,PORT_Change,
PORT_Locked,TCPIP_config,TCPIP_kconfig,TCPIP_kroute,TCPIP_route,
ENQUE_exec,FS_Extend,FS_Mount,FS_Umount,FS_Chroot,
RESTORE_Import,AUD_Events,AUD_Objects,AUD_Proc,AUD_It,
INSTALLP_Inst,TCPIP_set_time,PROC_Adjtime,PROC_Sysconfig,
PROC_LoadError,TCPIP_host_id
audit objects:
/etc/security/audit/config:
w = AUD_CONFIG_WR
/etc/security/environ:
w = S_ENVIRON_WRITE
/etc/security/group:
w = S_GROUP_WRITE
/etc/security/limits:
w = S_LIMITS_WRITE
/etc/security/login.cfg:
w = S_LOGIN_WRITE
/etc/security/passwd:
r = S_PASSWD_READ
w = S_PASSWD_WRITE
/etc/security/user:
w = S_USER_WRITE
/etc/sudoers:
r = Obj_READ
w = Obj_WRITE
/usr/local/bin/pbrun:
x = Obj_EXECUTE
/var/adm/syslog-00-00-00.log:
r = Obj_READ
w = Obj_WRITE
#
#
The object audit events are written to the audit bins in the same manner as the events generated
from the standard event auditing. The following are two commands that can be used together to
view the object audit events. The auditpr command is used to convert the binary audit records
into a readable format. It is assumed that the audit bins are defined in the /audit folder and bin1
is the current active bin.
# auditcat /audit/bin1 | auditpr -v
event login status time command
--------------- -------- ----------- ------------------------ --------
Obj_READ root OK Tue Dec 06 17:08:21 2005 vi
audit object read event detected /etc/sudoers
Obj_WRITE root OK Tue Dec 06 17:08:26 2005 vi
audit object write event detected /etc/sudoers
Obj_EXECUTE root OK Tue Dec 06 17:09:09 2005 pbrun
audit object exec event detected /usr/local/bin/pbrun
#
#
The Event column shows the AIX® event name as defined in the /etc/security/audit/events file.
The Login column displays the user ID that performed the action. The Status column indicates a
success or failure of the action. The Command column shows the command or the program
name that wrote the audit event. The three object audit events shown in the example indicate
read and write actions on the /etc/sudoers file and execute action on the /usr/local/bin/pbrun file.
create an id “insight” that has permission to the following:
The SSH collect process does not require Actuator installation on an audited system. However,
the correct Tivoli Compliance Insight Manager user must be created on the audited system and
included in the following standard groups: security, system, and audit. You must also add groupwrite
permissions for the /var/log/eprise directory. The Tivoli Compliance Insight Manager user
must have the following rights:
• Read permissions for the failedlogin file (/etc/security/failedlogin), and rx permissions on
the /etc and /etc/security directories.
• Read permissions for the wtmp file (/var/adm/wtmp), and rx permissions on the /var and
/var/adm directories.
• Full access (rwx) to /var/log/eprise, and rx permissions on /var and /var/log.
• Read and write access to the files created in /var/log/eprise.
• Read permissions for the /var/adm/syslog-00-00-00.log file
Setting up the SSH user on AIX systems
Use this procedure to create a user account on a to-be-audited AIX® system and to set it up so
that it can be used by Tivoli Compliance Insight Manager to remotely collect log data:
1. Log in to the audited system as the root user.
2. To create a Tivoli Compliance Insight Manager user, type the following command: mkuser
username
where username is the user ID you want to use. Your system might have requirements
for valid passwords. If the mkuser utility returns a message saying the username is not
valid, try another combination until the value is accepted.
3. To set the user password:
a. At the command prompt, type passwd username, where username is the user
ID you just created.
b. When prompted, enter the new password. Then, enter it again to confirm.
4. Change the login shell to /bin/sh:
a. Type passwd -s username.
5.
a. At the prompt, type Y to change the login shell.
b. Type the directory you want to change to as illustrated in the following example:
c. Change (yes) or (no)? >y
d. To ?>/bin/sh
crme 12:/#
6. After you change the login shell, the Tivoli Compliance Insight Manager user should be
able to run tar and gzip utilities without specifying the full path to them.
7. To verify that the tar and gzip utilities are accessible to the Tivoli Compliance Insight
Manager user from the shell:
a. Log in as the root user.
b. To locate the utilities, run the following command: which tar gzip
8.
a. At the prompt, type Y to change the login shell.
b. Type the directory you want to change to as illustrated in the following example:
c. Change (yes) or (no)? >y
d. To ?>/bin/sh
crme 12:/#
9. After you change the login shell, the Tivoli Compliance Insight Manager user should be
able to run tar and gzip utilities without specifying the full path to them.
10. To verify that the tar and gzip utilities are accessible to the Tivoli Compliance Insight
Manager user from the shell:
a. Log in as the root user.
b. To locate the utilities, run the following command:
which tar gzip
11.
a. Figure 4. Editing the SSH user group file to add the Tivoli Compliance Insight
Manager user
b. Save the edited file.
i. If you are using the vi text editor, press Esc, or type wq to exit. You
should see the following command after typing this:
Figure 5. Command output after adding the Tivoli Compliance Insight
Manager user to the SSH user group
ii. Press Enter to save the file.
c. Then remove write access to file group for the owner.
chmod u-w group
Attention:
The AIX system might have a specific configuration where these steps do not apply. In that case,
check the group ownership and group permissions of the files that are collected, and verify that
the Tivoli Compliance Insight Manager has the required authorizations to access the files for
collection.
POST
These steps to be completed after the machine has been setup and configured in TCIM server:
The public key is sent to the admin and the admin needs to follow the following steps :
Installing the public key using OpenSSH
1. Create a hidden .ssh directory in the home directory of the Tivoli Compliance Insight
Manager user if it does not already exist. Type the following command, for example:
mkdir $HOME/.ssh
2. In the ssh directory, create or edit a file called authorized_keys. Then, paste the contents
of the temporary public key file, which was created on the point of presence and
transferred to the audited system, into the file as a single line. Delete the temporary key
file when done. Use any text editor or use the following commands on the command line:
touch $HOME/.ssh/authorized_keys
cat tempkey >> $HOME/.ssh/authorized_keys
rm tempkey
3. Set the permissions on the .ssh directory and the authorized_keys file so that the insight
user is the owner with read access. Type the following commands to set the ownership
and permissions correctly:
cd $HOME
chown insight .ssh .ssh/*
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
4. After you set the permissions, review the ssh directory listing. The listing should be
similar to the following:
total 56
drwx------ 2 insight users 4096 Dec 18 02:51 .
drwx------ 47 insight users 4096 Jan 4 17:24 ..
-rw------- 1 insight users 452 Apr 8 2005
authorized_keys
Note:
After the connection between the point or presence and the audited system has been
established for the first time, the SSH daemon creates and stores additional files, which
are required for normal functioning of the SSH connection, in the .ssh directory.