Environment
Overview ... 3
Icons ... 3
Installation Reminders ... 4
A Very Brief Overview of IRIX System auditing... 5
Installing System Auditing ... 5
The System Audit Directories... 6
Additional Reading ... 6
Secure4Audit in an IRIX environment ... 7
Notes on Secure4Audit Usage ... 8
What to Do in Case of System Panic ... 8
Restoring the Audit State ... 9
Recovering from Single-User Mode ... 9
Trusted IRIX/B... 10
Menu Program Hints ... 11
Menu Program Security ... 10
Start auditing at bootup ... 11
Monitoring Audit Events ... 13
Switch System Audit Files Behavior... 14
Auditing Users... 14
Configuration Options ... 15
As Secure4Audit is a software product which is subject to change, S4Software, Inc. reserves the right to make changes in the specifications and other information contained in this document, without prior notice. While S4Software, Inc. has made every effort to ensure the accuracy and completeness of this document, S4Software, Inc. cannot be held liable for any errors or omissions. No information contained in this document shall be deemed to be a warranty for any purpose whatsoever.
Copyright (c) S4Software, Inc. 2008
Secure4Audit is a trademark of S4Software, Inc.
Unix is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.
The X Window System is a trademark of Massachusetts Institute of Technology.
RESTRICTED RIGHTS LEGEND
Use, duplication or disclosure by the Government is subject to restrictions as set forth in subprogram (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at subparagraph DFARS 252.227-7013. S4Software, Inc. 6633 Convoy Ct. San Diego, CA 92111 Phone: (858) 560-8112 Fax: (858) 560-8114 Email: [email protected]
Overview
The intent of this document is to specify how Secure4Audit works in an IRIX 6.5 environment. However, because Secure4Audit requires IRIX system auditing to be installed, it is necessary to understand how IRIX 6.5 auditing works before it is possible to understand how Secure4Audit interacts in that environment. For this reason, the basics of system auditing on an IRIX system are discussed, followed with suggestions on finding additional information. This section can be skipped if the reader is familiar with initializing and configuring auditing on an IRIX system.
Icons
Important
This symbol is placed in the margin with important information, cautions, and warnings
Note
This symbol is placed in the margin with additional, but non-imperative information on that function.
OS Specific
This symbol is used to highlight features that are specific to particular Operating Systems. The notation will include the particular operating systems affected.
Secure4Access
This symbol is used to highlight information that is pertinent to Secure4Access users.
Next Page
This symbol is placed in the bottom margin to indicate more information can be found on the following page.
Documentation
This symbol is placed in the margin when a reference is made to either another section of the current Secure4Audit document or another document.
Installation Reminders
It is important to read the OS specific section of the installation instructions (S4Audit_Install_2.2.pdf) to insure all steps have been taken and that you are aware of changes that were made on your system.
A Very Brief Overview of IRIX 6.5 System Auditing
Installing System Auditing
IRIX system auditing is not installed by default. This must be completed prior to installing the Secure4Audit software. Refer to Enabling Auditing in the IRIX Administration Manual Backup, Security and Accounting. Once the IRIX auditing package has been installed IRIX requires that the system be re-booted. If Secure4Audit will be installed on this system it is NOT necessary to perform any of the other tasks described in the Enabling Auditing document.
The System Audit Daemon
satd, the IRIX system audit daemon, starts on system boot when the
command /etc/chkconfig audit indicates that auditing is on. To check this setting use the command /sbin/chkconfig | grep audit. satd may also be started by calling the /etc/init.d/audit start command. satd is started by the user auditor. When
auditing is on, satd reads the contents of the file
/etc/config/sat_select.options to determine what events are
to be audited (events are such occurrences as user logins, file accesses, process execution and many more). If
/etc/config/sat_select.options does not exist, a default set of audit events are loaded by the audit initialization script (/etc/init.d/audit). Secure4Audit sets these options for the system administrator, so it is not necessary to edit this file directly if Secure4Audit is in use.
NOTE: To stop system auditing use the /etc/init.d/audit stop
command. NEVER kill satd. If satd is inadvertently stopped the
system will switch to Single-User Mode immediately. See the Secure4Audit Notes section later in this document for advice on handling system panic and recovery from Single-User Mode.
The System Audit Files
When satd detects that a selected event has occurred, it writes a record (which includes the event, the date and time of event, the process ID and any other applicable information) to its audit log. By default the audit logs are created in the /var/adm/sat directory and
are named sat_<4 digit year><2 digit month><day of month><24 hour time>. For example, an audit file created by satd
on March 22, 2005 at 4:38 in the afternoon would be named
sat_200503221638. These files are owned by auditor, the account
which starts the auditing process. The auditing system on IRIX provides a utility for viewing these “raw audit files” called
sat_select. If Secure4Audit is in use, this utility is not needed.
The System Audit Directories
The audit directories specified must be owned by auditor, the
account which starts the auditing process.
Once an audit file reaches a size internally defined by IRIX, the current audit file is closed and a new file created in the same directory. It is possible to configure IRIX to recognize alternate directories to which audit files may be written. Normally alternate directories reside on separate filesystems. This provides a method to continue auditing if the current filesystem is full.
IMPORTANT: There are several conditions related to system auditing which cause IRIX to switch to Single-User Mode. One of those conditions is the absence of available filesystem space. It is VERY IMPORTANT to monitor filesystem space usage and move or delete audit files as required, to maintain adequate filesystem space. If Secure4Audit is in use, it monitors filesystem space usage and STOPS auditing before it reaches a critical level to prevent IRIX from switching to Single-User Mode. For information on what to do if IRIX threatens system panic (a message something like the following:
panic 13 Sep 5 10:11:39 <hostname> satd Satd recovery failure! System will probably hang soon.) see the What to
Do in Case of System Panic section later in this document.
Additional Reading
For additional information on IRIX system auditing, refer to the IRIX System Administration Manual Backup, Security and Accounting called Administering the System Audit Trail. Also, the following system man pages may be helpful:
• audit
• audit_filters • satd
Secure4Audit in an IRIX environment
Secure4Audit must be run on IRIX 6.5.22 or above due to some auditing limitations with versions before 6.5.22.
In environments that use Secure4Audit, once IRIX auditing has been installed it is not necessary for the administrator to be concerned with the IRIX configuration files and tools. Secure4Audit acts as an interface for not only setting the requirements for configuring, running and monitoring system auditing, but as a filter, real-time alert mechanism, archiver and reporting tool as well.
The administrator creates an Secure4Audit profile using the Secure4Audit GUI or Character-Based menu program. Auditing is started using this menu program or via an Secure4Audit initialization script. The audit profile is used to load the necessary configurations for satd and the Secure4Audit daemons. The Secure4Audit monitor
daemon (s4auditmon) reads the information written to the IRIX raw audit file (satd_<date/time stamp>) and writes it’s own records to
the Secure4Audit combined log file (secure4.clg.<date/time stamp>). It is this methodology that allows greater flexibility in the
filtration of audit records. Only those records which were deemed important enough in the Secure4Audit audit profile are written to the Secure4Audit combined log file. If a satd file is closed and a new one started, Secure4Audit deletes the old satd file. This helps
maintain the necessary filesystem space required by IRIX If a security policy prohibits deletion of raw audit files, it is possible to configure Secure4Audit to leave old copies intact (see the Trusted IRIX/B section later in this document).
Secure4Audit provides a method to instruct satd to close its current file and start a new one. In this version of Secure4Audit, if alternate raw audit directories are specified in the Secure4Audit audit profile, this causes satd to start the new raw audit log in the next available alternate directory. Requests of this type cause the files to be opened in the alternate directories in a rotation-like manner.
removefile storeall
Notes on Secure4Audit Usage
This section provides helpful information on Secure4Audit behavior on an IRIX system and tips for use in that environment. For more general information on Secure4Audit, refer to S4Audit_Manual_2.2.pdf.
What to Do in Case of System Panic
If Secure4Audit is in use on the system, this situation should not occur, however, if satd or its files are manually changed certain
conditions (listed below) can cause system panic. When the system panics, IRIX sends a message to the console and any terminal windows warning users of the impending switch:
panic 13 Sep 5 10:11:39 <hostname> satd Satd recovery failure! System will probably hang soon
Using Secure4Audit to Stop Auditing
If Secure4Audit is in use on the system, use Secure4Audit to stop system auditing immediately.
/bin/secure4/s4audit -audit -stop
Auditing can also be stopped from the Secure4Audit menu program if it is available. Use System --> Disable Auditing. This will stop
satd if it is running and place auditing in an off state.
Using System Commands to Stop Auditing
If Secure4Audit is not in use, use the system audit start/stop script to halt auditing immediately.
/etc/init.d/audit stop
AND instruct the system to turn auditing off until the cause for the panic is found and corrected:
/etc/chkconfig audit off
It is important to act on the system panic message immediately. IRIX only provides approximately 10 seconds warning before switching into Single-User Mode.
Halting auditing quickly and correctly should be sufficient to prevent the system from switching into Single-User Mode.
Restoring the Audit State
Once auditing has been disabled and the panic stopped, the administrator should determine what caused the panic before attempting to restart auditing. If Secure4Audit is in use, most likely the panic was caused by an inadvertent termination of satd, since Secure4Audit attempts to protect against other possible causes. It may not be possible to prove this to be the case, but other causes can be ruled out.
No available filesystem space
Secure4Audit monitors filesystem space and terminates auditing before satd can panic. By default, Secure4Audit also removes old raw audit files after they have been closed and Secure4Audit has finished scanning them. However, filesystem space checks should be done. If filesystem space is limited, remove old raw audit files if permitted (The possible locations for these files is specified in the audit profile in the Primary audit directory, Second Audit Directory and Third Audit Directory fields) and tar and compress old
secure4.clg files if not needed. Also, any /sat/satd/emergency.<n> file(s) should be removed.
Non-existent or unreachable raw audit file path(s)
If satd cannot determine where to write audit records it panics.
Secure4Audit verifies all path information before passing it to satd. However, the system file /etc/config/satd.options may have
been manually changed. If auditing will be restarted using Secure4Audit, this is not a concern, Secure4Audit overwrites the contents of this file. If system auditing is to be restarted manually, validate path or filenames listed in this file. The paths must exist and be accessible by the auditor account. In addition, the filesystem on which they reside must have adequate space.
Recovering from Single-User Mode
In the event the system panics and enters Single-User Mode, the administrator needs to determine what caused the system to panic before auditing can be restarted. Unfortunately, auditing is normally configured to start on boot, and once the administrator exits Single-User Mode all the system boot scripts are executed. Secure4Audit provides an easy way to change the state of auditing without having to mount filesystems. Note that this is only available if the system /etc/init.d/audit script was altered to use Secure4Audit. Changing the audit state prior to exiting Single-User Mode will prevent any pre-configured Secure4Audit start-up script from being executed. This way the administrator can quickly return the system to multi-user mode and then determine what caused the
system to panic. If Secure4Audit is in use on the system, then the following command should be executed prior to exiting Single-User Mode:
/etc/chkconfig s4audit off
Once this has been done, it should be safe to exit Single-User Mode. Upon return to multi-user, the administrator should determine the cause of system panic prior to attempting to restart auditing. Suggestions on items to investigate are listed in the previous section, Restoring Auditing.
Specific information on operating in Single-User Mode can be found in the IRIX Administration Manual in the System Configuration and Operations chapter.
Trusted IRIX/B
Secure4Audit does not collect Mandatory Access Control Label events (i.e. MAC labels) in an IRIX Trusted environment. The uname -a command indicates whether Trusted Mode is enabled.
Menu Program Security
To run the Secure4Audit menu program the system administrator must have an effective UID of 0 and the Security Manager privilege set in their account profile. In order to allow the user to run the menu program for the first time, S4Software supplies an account profile for the root with the Security Manager privilege set.
To assign the Security manager privilege to non-root administrators, an account profile must be created for them using the Secure4Audit menu program. If you are unable to log in directly as root to run the menu program, contact your S4Software representative for assistance.
From the Accounts menu, select Create an account profile.
Click on the button to view a list of user accounts.
Select the administrator account name from the list. Note the account information is automatically displayed. Click on the box next to Security manager to change the value to Yes.
Click OK to save the profile.
The administrator may now log in as themselves, su (su -) to root, and run the Secure4Audit menu program.
Refer to chapter 6C (GUI) or 8C (character-based menu) of the Secure4Audit reference manual for more information on creating an account profile.
Menu Program Hints
Full on-line help is available with the GUI version. Chapter 5 of the Secure4Audit reference manual (S4Audit_Manual_2.2.pdf) describes the use of the F1 key to access the context sensitive help.
On some keyboards it may be necessary to use the Help key instead
of the F1 key. The Secure4Audit menu program also includes pop-up
help by default that allow you to see help text simply by placing the cursor in a text field.
Start auditing at bootup
To allow Secure4Audit to start auditing at bootup, there are a few system files that will need to be modified. Please read the following instructions carefully and contact your S4Software representative if you have any questions.
An audit profile must be created before auditing may be enabled at bootup on the system. Refer to the S4Audit_GettingStarted document f and the Secure4Audit reference manual or helpful hints on creating an audit profile.
auditGUARD users refer to section labeled auditGUARD Users for
instruction on modifying the audit startup script if it was modified when auditGUARD was installed.
1) Replace the system audit startup script:
% cd /etc/init.d
% cp -p audit audit.pre_s4
% cp -p /bin/secure4/scripts/audit.s4.irix ./audit
guitips
USE COPY TO PRESERVE THE LINKS TO OTHER SYSTEM SCRIPTS!
2) Edit s4audit.cfg to add the defaultprofile configuration
option to specify which audit profile should be loaded at bootup. Format is defaultprofile=<profile name>.
% cd /bin/secure4 % vi s4audit.cfg
% defaultprofile=profile name
Example: defaultprofile=Sys_Audit
3) Ensure the /etc/inittab file contains an entry for the
Secure4Audit monitor (s4auditmon) to allow it to be started
during bootup and to respawn if it terminates.
% cd /etc
% grep s4md inittab
If the /etc/inittab file already contains a valid entry for
s4auditmon, the above command will return:
s4md:1234:respawn:/bin/secure4/s4audit.dir/s4auditon >/bin/secure4/s4auditmon.err 2>&1
Otherwise, add the entry using the text file included with the Secure4Audit release:
% cd /etc
% cp -p inittab inittab.pre_s4
% cat /bin/secure4/s4audit.dir/install/s4am.inittab.txt >> inittab
If the system cannot be rebooted at this time, the inetd process must be notified of the change to the /etc/inittab file to start the s4auditmon process:
% init q
4) Verify the monitor process is now running:
% cd /bin/secure4
If the monitor was started correctly, the above command will return:
Audit monitor active since: date time (dd-mmm-yy hh:mm)
Current audit profile: audit profile
Primary audit log directory: /usr/secure4/secure4.clg
Current audit log file:
/usr/secure4/secure4.clg/secure4.clg.dateTime
Current raw audit file: path to raw audit trail file Audit record archiving status
Level for Store/Fail/Alarm: 5/10/15
5) If the system is not going to be rebooted at this time, enable auditing using Secure4Audit to begin monitoring events. With the defaultprofile defined in the Secure4Audit configuration
file you can use the command line arguments to start auditing without needing to specify an audit profile.
% cd /bin/secure4
% ./s4audit -audit -start
You may also use the GUI or character-based menu to enable auditing.
Refer to the S4Audit_GettingStarted document or the Secure4Audit reference manual for more information on enabling auditing.
Monitoring Audit Events
Because it is not possible to prevent self-auditing on IRIX systems if any of the events under the Object Events tab or the Process Control Events tab of the Secure4Audit profile are selected, there will be a tremendous amount of data generated which will cause excessive CPU usage. As noted in the section of this document on IRIX auditing, this can be a condition that will lead to IRIX switching to Single-User Mode.
Secure4Audit attempts to protect against this be preventing auditing of File write and File read events and only allowing unsuccessful File open events from being monitored. The Secure4Audit monitor (s4auditmon) will also eliminate all audit events which are generated
by itself, which prevents that data from being reported to its audit trail file (secure4.clg). This does not, however, prevent the data from
being written to the system audit files which means there is still a large risk of running out of filesystem space.
logdirprm logdiralt
/bin/secure4/documents: S4Audit_GettingStarted.pdf S4Audit_Manual_2.2.pdf
It is therefore recommended that the items under the Object Events and Process Control Events tabs of the Secure4Audit profile not be selected for auditing.
To monitor password change events you must select the Modify Account event under the Account and group events tab. The level must be set equal to or greater than the appropriate threshold level.
Switch System Audit Files Behavior
The Secure4Audit menu program option, Switch System Audit Files causes a directory change. The current file is closed and a new file started in the next available directory (listed in the Secure4Audit audit profile as the Secondary audit directory or Third audit directory).
Auditing Users
IRIX audits all users. It is not necessary (or possible) to instruct IRIX to only audit specific users. Therefore, the Audit account profile option in the Secure4Audit account profile is not relevant on IRIX systems.
Configuration Options
The following options should be considered when configuring Secure4Audit on an Irix system.
defaultprofile=<audit profile name>
This option specifies the default profile name that may be used when enabling auditing from the command line (/bin/secure4/s4audit -audit -start), or if using a script during bootup that executes the command line -start switch. There is no default value for this
option.
logout=y or n
By default, (n), no event script is executed for log out events when
access methods are being monitored. Setting this option to y will allow the event script for the corresponding login event to be executed when the logout occurs
removefile=y or n
By default, (y), to prevent the system audit trail files from filling up system disk space, s4auditmon will remove the system audit trail file when it has finished processing the information and is ready to process the next file. To prevent the removal of system audit trail files, set this option to n.
Please refer to Appendix A of the Secure4Audit Reference Manual for more information on configuration options.
auditGUARD users
As noted in the installation instructions, if auditGUARD was configured to start auditing at system bootup, the Secure4Audit installation will rename the /etc/config/dlxaudit file to
/etc/config/s4audit. The audit start up script that is included
with the Secure4Audit release was available with auditGUARD on a per-request basis. If you did not install the modified version of the
/etc/init.d/audit start script with auditGUARD, then follow the steps outlined in the section labeled Start auditing at bootup. If there is a modified version of the audit script that was used for auditGUARD, no further action needs to be taken to allow Secure4Audit to now start auditing. The files are the same.
Secure4Access users with invalid login checking enabled should set
removefile to n to prevent any issues that could occur with the server process not being able to read the audit trail file. Caution should be used, however, to monitor the file system space.
