When you invoke satconfig, a new window opens on your screen. The main body of the window has a list of all the available event types. Next to each event type name is a button. At any time, each button is either up or down. If the button is down, the event type is selected for auditing. If the button is up, the event type is not audited. Use your mouse and the left mouse button to select whether you want the event type in question to be on or off.

At the bottom of the satconfig screen there are three buttons. These buttons are labeled Apply, Revert, and Quit. When you have made your auditing selections, use the left mouse button to press the Apply button on the screen to activate the auditing selections. If you change your mind while making audit selections, you can use the Revert button to reset the individual event type buttons to the selections currently in use. The third button is labeled Quit and closes the satconfig window. If you have made selections that have not been applied, satconfig asks you if you really want to quit and discard the changes you have made without applying them.

For complete information on using sat_select, consult the sat_select(1M) reference page, but in general, the syntax most often used is

sat_select -on event 

and

sat_select -off event 

sat_select -on event directs the system audit trail to collect records describing the given event. If “all” is given as the event string, all event types are collected.

sat_select -off event directs the system to stop collecting information on that event type. If “all” is given as the event string, all event types are ignored.

With no arguments, sat_select lists the audit events currently being collected. The effect of subsequent sat_select programs is cumulative. Help is available with the -h option.

If the user in question is being audited to determine if attempted security violations are taking place, use the command line:

sat_reduce -P satfile | sat_summarize -u user_name

This command line selects only the audit records that represent attempted violations. The -P flag to sat_reduce selects for attempted violations. The -u flag to the sat_summarize command lists the number of records generated by the user.

It is vitally important to remember that not every record of an attempted violation really represents malicious intent on the part of the user! Most of these records are generated in the course of normal work. The auditor should be looking for a trend, such as repeated attempts to access information unnecessary in the course of normal work (for example, a programmer attempting to access salary or hiring information).

In the second scenario, where the employee is leaving the project, the auditor is looking for a comprehensive list of files used by that employee so that the correct files and directories may be assigned a new owner who is remaining on the project.

The above listed command line provides a basic look at the user's activity. Next, to more closely examine the user's activities, issue the following command:

sat_reduce -u user_name satfile | sat_interpret | more

The sat_reduce command selects all of the audit records generated by the user. Then, the sat_interpret command puts the records into human readable form. The output of sat_interpret is very large. If it is impractical to direct this output to a file, you should direct the output to your screen and view it with a screen paging program such as more.

Using these two command lines, you should be able to view a user's activities and come to a reasonable knowledge of the types of actions the user is taking on the system. You can also generate a specific record, in human-readable form, of all security violations or files and resources accessed.

All attempts at unauthorized entry generate audit records of the sat_ae_identity event type. (Use sat_select, sat_reduce, and sat_interpret to collect and view these records.) The interpreted output of these events contains a text string that describes the attempt at entry. Intruders from outside your organization have a much higher instance of failed login attempts than your authorized users.

Three interesting text strings reveal attempts at unauthorized entry:

Here is an example of an interpreted audit record of an unsuccessful login attempt:

Event type = sat_ae_identity 
Outcome = Failure 
Sequence number = 1 
Time of event = Mon Mar 11 12:45:40.34 PST 1991 
System call = syssgi,SGI_SATWRITE 
Error status = 0 (No error) 
SAT ID = anamaria 
Identity event = LOGIN|-|/dev/ttyq4|guest|Unsuccessful login attempt.

Usage of your system outside of normal working hours or, if your system maintains physical security of terminals, from unusual locations, is a matter of interest. In most cases, the usage of the system is legitimate, but each instance certainly bears notation and examination. Many potential violations of security from outside your user community happen during nonpeak hours, and rarely from within your physical site.

To observe activity at odd hours, enter the following commands in order:

If your site assigns a terminal to each user and maintains reasonable physical security for each terminal, you can monitor logins from unusual locations. For example, if a user normally working in a group computer lab makes a login attempt from a private office, this event may be cause for interest. To get a list of login events, enter the following command:

sat_reduce -e sat_ae_identity sat_file | sat_interpret | grep LOGIN

Bear in mind that it does not necessarily represent a violation of security if a user is working at an unusual terminal or even if a user is logged on at two or more terminals at once. For instance, the user may be correcting a mistake and may have logged in elsewhere explicitly for the purpose of terminating unwanted processes. You should be looking for instances where the user is not genuinely logged in twice, but where one instance of the login is an intruder.

Whenever a user connects to a machine outside your trusted local network, an audit record should be generated. A connection to a host outside of the local network is worthy of notice but not necessarily a violation of security. You should be on the lookout for trojan horse programs that cause your system to make an outward connection at a later time. You can identify outward connections with the following command sequence:

The above command sequence is dependent on the specific implementation of your networking software. You may need to modify commands to reflect your networking situation. For example, if the software you are using does not generate the sat_bsdipc_addr auditing event type, you should search for another event type that is generated.

Although the system records each instance where access to a file or resource is denied, the information contained in these audit records is rarely indicative of a security violation. Many applications and utilities operate on a principle of access denial as part of normal operation. These events are always logged, but only in rare cases do they indicate a violation. For example, the library function getutent always tries to open /etc/utmp for read-write access. If this action fails, getutent immediately tries again, but requesting read-only access. Permissions on /etc/utmp prohibit all users except root from opening this file for reading and writing. When an unprivileged user runs a program that calls getutent(), a sat_access_denied record is generated, and it is immediately followed in the audit trail by a sat_open_ro record, indicating that access was granted. The lesson in this example is that access denial is usually not indicative of a security violation.

The sat_access_failed event is often confused with the denial event. The event type is completely different and is even more rarely a cause for concern than access denial. When a user enters a command to an interactive shell (such as /bin/csh), the shell tries to execute the command in each directory in the user's search path, failing at each attempt until it finds a directory that actually contains the command. Suppose a user enters xterm and his or her path variable contains

/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/bin/X11:~/bin

A sat_access_failed record is generated for each directory in the path until the command is found and executed. In this scenario, a record of failed access is generated for each of the following nonexistent programs: /bin/xterm, /usr/bin/xterm, /usr/sbin/xterm, /usr/local/bin/xterm and a successful sat_file_exec record for the real program: /usr/bin/X11/xterm.

Every interpreted audit record contains a line beginning with the keyword Outcome. The field following this keyword can be equal to one of Success, Failure, or Success due to privilege. The last case indicates that the user made a system call that would have failed except that superuser privilege was invoked to assure its successful completion. This is not necessarily a security violation or an unexpected use of root privilege. It is perfectly normal to see these outcomes. Any time an ordinary user runs a program that contains code that uses root privilege, Success due to privilege outcomes are generated. A good example of this kind of program is passwd. An ordinary user generates a record of this type simply by changing the password on his or her account.

What you should be looking for is an instance where the SAT ID or Effective ID field is different from the “User ID” field. This occurs when a user executes /bin/su to gain root privileges or otherwise promotes the privilege level of a session. In most cases, this is not a security violation, since the root password is necessary to successfully complete the /bin/su command.

An instance of using superuser privilege, though, is always worth examination in the audit trail. When you encounter an instance where a user has promoted his or her login session to root, you should check to see that the user is authorized to know the root password. If not, check whether the user indeed executed the /bin/su command, or if he or she promoted the privilege of the session by some other means, such as a Trojan horse setuid shell command.

Whenever a user runs /bin/su and thereby promotes the privilege of his or her login session, the auditor should also make a routine check of what actions the user took while the privilege was promoted.

Sometimes a particular user is under official scrutiny by the management of a site. He or she may be on probation or may have just left employment under less than ideal circumstances. The auditor can choose to look at the records describing that user's behavior just by directing the audit trail through the sat_reduce command as follows:

Rarely should any user be subjected to this kind of accounting, and this feature should be used carefully and with consideration of the individuals involved.

Sometimes a particular file or resource is of special interest. An information leak may have occurred and an investigation is proceeding into how the leak took place. Or a special file or resource may have been created as bait to trap browsing intruders. In either case, the file or resource should be closely accounted by the auditor.

sat_reduce -n interesting_file -e sat_open -e sat_open_ro sat_filename | sat_interpret

Every modification of system data files is of interest to the auditor. Since these data files are not only under system security but in fact define system security, any unauthorized access can result in a total breach of security.

Each site has individual policies on how users are added to or removed from the system, how access control of files and hardware is administered, how network connectivity is maintained and administered, and a host of other issues. It is the responsibility of the auditor at each site to enforce the policies of the site and to use the auditing tool effectively to exercise that responsibility.

If you are running Trusted IRIX/B, system data files should be modified only with the dedicated editing tool, dbedit, and never with general-purpose text editors. Only privileged users can use the dbedit tool, and only privileged users have permission to alter the contents of the system data files. Any use of any other editor on a system data file is a violation of security policy and should be noticed by the auditor. If your interpreted audit trail contains sat_open records where the Actual name field contains the string “/secadm,” check that the Process ID field (which gives both the PID and the name of the program being executed) does not contain “vi,” “ex,” “emacs” or any other commonly available text editor. This field should contain only the name “dbedit.”

The Administrator should never modify permissions, ownership, or labels of system programs. If your audit trail contains evidence that the administrator has attempted to change attributes of system programs, you should investigate and find the reason for the change. Again, the explanation given is likely to be valid, and this is not good cause to suspect your Administrator of subterfuge; however, you may want to examine your system's security policies and make certain that neither the users nor the administrators take a cavalier attitude toward the security policies.

The following command searches your audit trail for the type of records that can indicate this problem:

sat_reduce -e sat_file_attr_write -e sat_fd_attr_write < satfile

In the interpreted output, look for lines with the Actual name field. Any audit record showing modified attributes for resources in /bin, /sbin, /etc, /lib, /var, /usr/bin, /usr/lib, /usr/share, /usr/bsd, /usr/sbin, or /usr/bin/X11 is an audit record deserving follow-up.

The auditor should be the only person to access the audit trail. No other users should read from it, write to it, remove files, or modify file attributes. Look at all records generated by people other than the one who knows the auditor account password, and check that none of those records refer to files in /var/adm/sat or in any other directory you use to store audit trail information.

To make space on the disk for your audit trail, first boot the system into single-user mode. No audit records are generated in this mode. Once in single-user mode, archive your audit files and remove them from the disk. Once at least 10 percent of the filesystem is free, you may boot into multiuser mode without difficulty.

If your auditing system directs the audit files to the / (root) filesystem or the /usr file system and either filesystem becomes full, you will not be able to bring the system to single-user mode to archive and remove your old audit files. If you find yourself in this situation, perform the following procedures to remove old audit files: