Migrating to Netware 4.1

- 17 -

NetWare 4.x Auditing

Reasons for AUDITCON
NetWare 4.x Auditing Features
Using the AUDITCON Tool
Using the Audit Files
Enabling Auditing
Changing the Audit Password
Auditing Configuration Options
- Audit By Event
- Audit By File/Directory
- Audit By User
- Audit Configuration
Auditing a Network User for a Specific Directory
Auditing a Specific File
Auditing a Volume for Directory Creations and Deletions
Auditing the NDS
Generating Audit Reports
Creating a Report Filter
Managing Audit Reports
Maintaining Audit Files

NetWare 4.x includes a powerful auditing feature that can be used to augment NetWare security. Under NetWare 4, the auditor can obtain information on individual files and directories. The auditor can also audit changes in the NDS tree, server events, and the creation or deletion of queues. Moreover, the auditor is independent of the system administrator. This avoids the concentration of power in a single individual.

In this chapter you will learn about NetWare 4's AUDITCON tool and how you can use it to audit your network.

Reasons for AUDITCON

NetWare 3's SYSCON utility could track the number of blocks read or written, the services requested from the NetWare server, and the number of blocks of storage utilized by users over a period of time. These statistics were interesting, but their value was somewhat limited, and most system administrators did not use these functions in any serious way.

What would have been more useful was a means for tracking the usage of individual files and directories. Knowing the number of times an application is accessed, for example, would enable an administrator to determine if the license for that application is appropriate for its level of usage. Or, an audit of what users are accessing specific system administrator tools such as NETADMIN and RCONSOLE could uncover a breach in network security. NetWare 4's AUDITCON tool can track the usage of individual files.

AUDITCON also enables the auditor to act independently of the network administrator. On most networks, the administrator is all-powerful. The administrator can access all resources on the network without any restrictions. Such unrestricted power is necessary if the network adminstrator is to effectively support the users. It also means the administrator can access sensitive and classified data on the network without any checks. From a practical and political viewpoint, it might be desirable to have a deterrence against a dishonest network administrator. This deterrence can be implemented using auditing.

Sensitive files can be audited for events that perform an operation on those files, such as a read and write. Anytime a user, including the network administrator, accesses the audited file, that action is recorded in an audit log, which can be used to discover the users who access the audited file. The network administrator is unlikely to surreptitiously access classified files if he or she knows the file is audited. Auditing cannot prevent a network administrator from accessing a file, but should such an access occur, the event will be recorded in the audit log and will be discovered by the auditor.

One reason for monitoring the network administrator's activities is actually to protect the administrator. In the normal course of maintaining files and directories, the administrator often has the power to access confidential, highly sensitive corporate information. Because of this power, the administrator is often the target of suspicion if there is a breach of security. AUDITCON can exonerate an honest administrator by clearly documenting the administrator's access to sensitive files.

NetWare 4.x Auditing Features

NetWare 4.x auditing enables the auditor to act independently of the network supervisor to perform the following functions:

1. Keep track of file system events such as changes and access to files and directories.

2. Track events such as changes and access to NDS objects.

The auditor does not have to be a specially created user. Any existing user can be set up to perform the role of an auditor.

The network supervisor must designate a network user to be an auditor. In other words, only the network supervisor can empower a user to be an auditor. The network supervisor performs this by:

1. Enabling auditing on volumes or containers. For file system events, auditing is enabled at the volume level. For NDS events, auditing is enabled at the container level.

2. Creating an auditor password and notifying a designated user (the auditor) of the password.

3. Training the auditor on the use of the AUDITCON utility, and how it can be used to change the password.

The auditor performs auditing functions using the AUDITCON utility that can be found in SYS:PUBLIC. Because most users have Read and File Scan trustee rights to this directory, no special trustee rights assignment has to be made for the auditor to access these files. The auditor should not have access to the SYS:SYSTEM directory; the network supervisor and auditor tasks need to be kept separate.

Even though the auditor does not have full access to a directory or a file, the auditor can audit file/directory events.

The first function the auditor must perform is to assign a new auditor password that the network supervisor does not have knowledge of. This is a very crucial step in maintaining the independence of the auditor from the network supervisor. If the network supervisor knows the audit password, he or she can perform auditing functions.

It is important for the auditor to track the right kinds of events. A common mistake is to flag too many events that are not of consequence to network security. This causes voluminous audit reports, which often go unread and therefore are ignored.

After the audit events have been identified, the auditor can generate an audit report and either view the audit report on-screen or print the audit report. These steps are described in detail in the sections that follow. The steps needed for auditing are shown in figure 17.1.

Figure 17.1 Setting up auditing roles.

Using the AUDITCON Tool

AUDITCON.EXE is the primary tool for performing network auditing. Figure 17.2 shows the main menu for the AUDITCON tool; it shows that one of the options is "Enable volume auditing." The presence of this option in the main AUDITCON screen indicates that auditing has not been enabled for this volume. This option should be selected to enable auditing for the volume.

Figure 17.2 The AUDITCON Main Screen when auditing has not been enabled.

When the Audit directory services option is selected (see fig. 17.3), you have a choice of selecting the NDS sub-tree starting from a particular container that should be audited (option Audit directory tree). There is also an option to change the context for the session (option Change session context). The session context is displayed at the top of the screen. In the example in figure 17.3, the session context is [Root].

Figure 17.3 The Audit directory services screen.

The option Change Current Server enables you to log in to other servers for the purpose of auditing volumes on other servers.

The option Display Audit Status shows the status of audit files on the current volume. For the example in figure 17.3, where auditing has not been enabled, selection of this option should indicate an auditing status of Off (see fig. 17.4).

Figure 17.4 Display audit status when auditing is disabled.

Using the Audit Files

When an audit event occurs, it is logged in a file named NET$AUDT.DAT. This file is kept at the root of each volume and is flagged "Open." Flagging this file Open ensures that non-auditors on the network cannot access this file. The NET$AUDT.DAT file only contains auditing information for volume auditing for this volume. NDS auditing data is stored in the NDS DATABASE.

It may be desirable on some networks to keep track of the auditor's activities. The purpose of this is to have a deterrence against abuse of the auditor's power. For example, it would be useful to know which auditor accessed the audit log file NET$AUDT.DAT. NetWare 4.x solves this problem by keeping an audit history file called AUD$HIST.DAT that is also kept in the root of a volume and is flagged "Open." This audit history file keeps track of the auditor's access to the audit log file NET$AUDT.DAT. AUD$HIST.DAT records the date, time, and name of the auditor who accessed the audit log file NET$AUDT.DAT. Any enabling or disabling of monitor functions on the volume is also kept in the audit history file. If the auditor clears the history file to "hide" a questionable event, the first entry in the new history file will record the fact that the history file was cleared.

NOTE: If there is more than one auditor on the network, they should be given separate user accounts. This is so their auditing activities are recorded under their respective user names.

The information in the NET$AUDT.DAT file is kept in a binary form. The auditor uses the binary audit files to generate an audit report. The audit report is a text file that is stored on the network. Because a text report file can be read by anyone, it must be guarded to ensure that an ordinary user does not have access to it. Otherwise, any user who has Read access rights to this file will become privy to its contents. The audit report can also be viewed on-screen. This process creates a temporary file that is deleted upon exiting the view.

Enabling Auditing

The first steps in figure 17.1 were for the network supervisor to enable auditing for a volume or container and select an audit password. These steps are described in this section.

1. You must determine the volume to be audited. This decision is based on which volumes contain sensitive data and which contain program files whose usage you want to monitor.

2. Log in to the network as an Admin user and run AUDITCON.

3. From the main menu option select Enable Volume Auditing.

4. Enter the volume password (see fig. 17.5). You will be asked to retype the password for verification purposes. If there is an audit data file on the volume, it will be moved to an old audit data file. If there was an old data file that already exists, it will be deleted.

After enabling the volume, the main screen of AUDITCON will change (see fig. 17.6). The Enable Audit Status option will be missing from the Available Audit Options.

If you select the Display Audit Status option, you will see that volume auditing has been enabled (see fig. 17.7).

5. Exit AUDITCON.

6. Give the audit password to the auditor and instruct the auditor to change the password immediately.

Figure 17.5 Enable volume auditing screen.

Figure 17.6 The AUDITCON main screen with volume auditing enabled.

Figure 17.7 Display audit status when auditing is enabled.

Changing the Audit Password

The network supervisor empowers a user to be an auditor by informing the user about the volume password. The auditor must change the password at the earliest opportunity to maintain independence from the network supervisor. The auditor password must be guarded with care to maintain the independence of the auditor. If the auditor password is forgotten, it cannot be recovered. Disabling of auditing requires knowledge of the auditor password and can only be done using AUDITCON. If this password is forgotten, the only way to disable auditing would be to delete the volume and re-create it.

The following steps guide you through the process of changing the auditor password.

1. Log in to the network as an auditor user and run AUDITCON.

2. From the main menu of the AUDITCON utility, select Auditor Volume Login. You should be prompted for a password (see fig. 17.8).

3. Enter the password that was initially defined by the network supervisor. This password is needed to gain access to the AUDITCON functions. You should see that the main AUDITCON screen changes (see fig. 17.9) with the following new options:

Audit files maintenance
Auditing configuration
Auditing reports

TIP: Once AUDITCON validates the volume login password, the additional options that are available on the AUDITCON main screen are Audit Files Maintenance, Auditing Configuration, and Auditing Reports.

4. Select Auditing Configuration from Available Audit Options. You should see a list of Auditing configuration options (see fig. 17.10).

5. Select Change Audit Password from Auditing Configuration.

6. You will be presented with a screen to enter the current volume password (see fig. 17.11). This is to validate the auditor.

7. You will then be asked to enter a new audit password. You should enter a new password. AUDITCON does not check to see if the password you entered is different from the initial password given to you by the network supervisor.

8. Exit AUDITCON.

Use the new password with AUDITCON.

Figure 17.8 The AUDITCON Auditor volume login option.

Figure 17.9 The AUDITCON main screen after volume login.

Figure 17.10 The AUDITCON Auditing Configuration options.

Figure 17.11 The AUDITCON Change audit password option.

After the auditor password has been changed, the auditing functions can be performed. Some of the common auditing functions are outlined in the following sections.

Auditing Configuration Options

The screen for Auditing Configuration options is presented to an auditor (see fig. 17.10) when the auditor is authenticated by supplying the correct Audit volume login password. This menu option presents a number of interesting choices:

Audit By Event
Audit By File/Directory
Audit By User
Audit Options Configuration
Change Audit Password
Disable Volume Auditing
Display Audit Status

The most important of these configuration options are explained in the following sections.

Audit By Event

The Audit By Event option enables you to select among four different types of events (see fig. 17.12) to be audited. These events are

File events
QMS events
Server events
User events

Figure 17.12 The Audit By Event option.

Audit by File Events

The File Events option audits file and directory operations such as open/read/write file, create file/directory, and delete file/directory. These events can be monitored on a global basis, by user or file, and by user and file. Global auditing means that the operations will cause the event to be logged, regardless of the user, file, or directory name on the audited volume. Auditing on a user or file basis means that the event will be recorded if it applies to an audited user or an audited file. Auditing on a user and file basis means that the event will be recorded if it applies to an audited user and an audited file or directory.

The "or" and "and" in these options act as the Boolean logical "or" and "and" operators. These options act as filters and control the amount of audit data that goes into the audit files.

Audit by QMS Events

The QMS Events option allows auditing of operations that affect the printer queue such as creating and deleting of print queues.

Audit by Server Events

Server Events enables you to monitor events such as bringing down the server, restarting the server, or mounting a volume attached to the server. All server events are recorded globally.

Audit By User Events

User Events refers to the creation or deletion of user objects and user logins and logouts. Trustee assignment changes affecting users are also audited by this event type.

Table 17.1 summarizes the Audit By Event types.

TABLE 17.1 Audit By Event Types

Event Type	Description
File events	Audits file and directory operations such as open/read/write file, create file/directory, delete file/directory.
QMS events	Audits operations such as creating and deleting print queues.
Server events	Audits events such as bringing down the server, restarting the server, or mounting a volume.
User events	Audits creation/deletion of user objects, user logins and logouts, and trustee assignment changes.

Audit By File/Directory

When this option is selected, you are presented with a list of files and directories (see fig. 17.13) in the current directory that can be audited. You can select any of the files and directories in the list. A column next to the file or directory contains the audit status (OFF or AUDITED). If a file or directory is selected for auditing, an audit record is entered in the NET$AUDT.DAT file whenever an operation is performed on the selected file or directory.

The F10 key can be used to switch the audit status. A dot-dot (..) symbol indicates the parent directory and can be used to "move up" one directory level. In general, pressing Enter when any directory is highlighted allows you to examine the contents of that directory.

Figure 17.13 The Audit by File/Directory option.

Audit By User

Audit By User gives you a list of users who can be audited (see fig. 17.14). You can select any of the users whom you want to audit. A column next to the user name contains the audit status (Off or Audited) for that user. If a user is selected for auditing, an audit record is entered in the NET$AUDT.DAT file whenever that user performs an audited operation. The users in figure 17.14 are bindery emulation users. To audit other users outside the file server's bindery context you will have to use NDS auditing. When you do volume auditing by user, it offsets only bindery-emulated users, and the events are stored in the NET$AUDT.DAT file. When you select NDS auditing, any user can be audited regardless of the context in which he is defined.

The F10 key can be used to toggle the audit status for the user.

Figure 17.14 The Audit by User option.

Audit Configuration

Audit configuration can be selected from the Available configuration options (see fig. 17.15). This option enables the auditor to configure auditing parameters. The auditing parameters are kept in the NET$AUDT.CFG file on the root of the audited volume.

The following parameters can be changed:

Audit file maximum size
Audit file threshold size
Allow concurrent auditor logins
Broadcast errors to all users
Force dual-level audit passwords
Error recovery options for audit file full or unrecoverable write error follow:
- Dismount volume
- Disable event recording
- Minutes between warning messages

Figure 17.15 The Audit Configuration option screen.

Audit File Maximum Size

The "Audit file maximum size" parameter enables you to enter the NET$AUDT.DAT audit log file size in bytes. The default file size is 1,024,000 bytes. When the file size is full, it must be reset or deleted. Certain recovery options such as dismounting a volume or disabling event recording can also be triggered when the audit log file gets full. If you want to increase the audit log file size, you should consult with the network administrator; this will affect available disk space on a volume.

Audit File Threshold Size

The "Audit file threshold size" parameter is used to specify the audit log file size at which the system will start sending warning messages. The warning messages are sent at a default interval of three minutes, but this interval can be changed by the "Minutes between warning messages" field. The default value is set to about 90 percent of the Audit file maximum size.

Allow Concurrent Auditor Logins

The "Allow concurrent auditor logins" parameter, when set to Yes, can be used to enable more than one auditor access to a volume or container. Because audit access is allowed by password, auditors must share the same password. If this value is set to its default value of No, an attempt by a second auditor to log in to a volume or container that is already in use will produce the error in figure 17.16.

Figure 17.16 Audit error disallowing concurrent usage when Allow concurrent auditor logins is set to No.

Broadcast Errors to All Users

The "Broadcast errors to all users" parameter sends a message to all attached work-stations when the NET$AUDT.DAT file reaches its threshold value defined in "Audit file threshold size."

Force Dual-Level Audit Passwords

The "Force dual-level audit passwords" parameter implements a second password that must be entered to save configuration or change settings. This second password is in addition to entering the first password for volume or container login for auditing purposes. By default, the "Force dual-level audit passwords" field is set to No.

When the audit log is full, certain recovery options such as dismounting a volume or disabling event recording can be triggered. If the "Dismount volume" field is set to Yes, the volume is automatically dismounted when the audit file is full. The network supervisor will have to remount the volume, at which point you can take actions such as deleting/saving the audit log file and resetting it. Before setting this option to Yes, the auditor should consult the network supervisor because it can cause a serious disruption to users on the network. Unless applications running at the client workstations are written in a robust manner, they can get locked if the volume is dismounted. This option must only be selected if the security requirements of maintaining a complete audit log are more important than the disruption of network applications. By default the value of the "Dismount volume" field is set to No.

Alternatively, if the audit log file is full, you can set the "Disable event recording" to Yes to stop the recording of any additional audit events. By default the value of this parameter is set to Yes.

An even better option is the "Archive audit file" option. With this option enabled (set to Yes), if the audit log file is full, the audit file is closed, archived, and replaced by a new audit file. The "Number of old audit files to keep" can be set to control the number of archived audit files to keep. This parameter's value can range from 1 to 15 and has a default value of 2.

The "Minutes before warning messages" is the time in minutes before a warning message is sent to the server console (and also attached workstations if "Broadcast errors to all users" is set to Yes) when the audit file size reaches the "Audit file threshold size."

Auditing a Network User for a Specific Directory

It is sometimes useful to audit the actions a user can perform. Examples of these operations can be file creation/deletion/read or directory creation and deletion. The following steps outline how a network user can be audited for file read operations in a specific directory called SYS:PAYROLL.

1. Log in to the network as an auditor user and run AUDITCON.

2. From the main menu of the AUDITCON utility, select Auditor Volume Login.

3. From the main menu select Auditing Configuration.

4. From the Auditing configuration (refer to fig. 17.10) select Audit By Event.

5. From the Audit By Event menu, select Audit By File Events. You should see a screen similar to that in figure 17.17.

The screen does not show all the operations that can be audited for files and directories. You can use the cursor keys or the PgDn or PgUp keys to examine other entries. Using the PgDn key, you can see the other entries for operations that can be audited (see fig. 17.18). The second screen shows an entry for "File Read - User and File." This is the entry you must select for auditing a specified user for reading a file in a specified directory. It means that the system will track events that apply to an audited user and an audited file/directory.

6. Selecting "File Read - User and File" can be accomplished by using the F10 key (see fig. 17.19). Answer Yes to save changes.

Up to this point, you have only turned on auditing for a file event of the type "File Read - User and File." You must next specify the directory and the user to be audited.

7. Press Esc a few times to go back to the Auditing configuration menu.

8. From the Auditing configuration menu, select Audit By File/Directory. You should see a screen similar to that in figure 17.20.

9. Use the cursor keys and the Enter key to select the directory to be audited. Use the F10 key to switch the audit on and off. Figure 17.21 shows the screen after selecting SYS:PAYROLL directory to be audited.

Press Esc and answer Yes to save changes.

10. Press Esc to go back to the Auditing configuration menu.

11. From the Auditing configuration menu, select Audit By User. You should see a screen similar to that in figure 17.22.

12. Use the F10 key to mark a user for auditing, and answer Yes to save changes. Figure 17.23 shows the screen after selecting user HACKER to be audited.

Figure 17.17 The Audit By File Events screen.

Figure 17.18 The Audit By File Events Screen--second screen.

Figure 17.19 Auditing File Read - User and File.

Figure 17.20 The Audit by File/Directory for directory selection.

Figure 17.21 An audited directory.

Figure 17.22 A user selection in the Audit by User screen.

Figure 17.23 An audited user.

Auditing a Specific File

The auditor can flag files and directories to be audited. This is done by performing the steps that follow. The steps show how a particular file can be audited. An example of auditing a file could be to audit all attempts to access an application program's executable file, such as NETADMIN.EXE, to find out the frequency of access to this file. This knowledge could be used to determine all users who attempted to access this program file.

1. Log in to the network as an auditor user and run AUDITCON.

2. From the main menu of the AUDITCON utility, select Auditor Volume Login.

3. You must specify the password for the volume. Select Audit Configuration

Migrating to Netware 4.1 -- Ch 17 -- NetWare 4.x Auditing