The operating system provides a number of mechanisms that
allow systematic surveillance of the activity in your system. There
are many mechanisms available for monitoring the system either manually
or by user-written command procedures, for example:
Accounting utility (ACCOUNTING)
Authorize utility (AUTHORIZE)
Install utility (INSTALL)
System Management utility (SYSMAN)
Proper use of such mechanisms should help you verify settings,
alert you to problems, and allow you to intervene. This section
describes the most important system surveillance mechanisms--ACCOUNTING
and ANALYZE/AUDIT.
System Accounting You can learn what the normal pattern of resource use is by
studying reports of the Accounting utility (ACCOUNTING). To obtain
a report, you run the utility image SYS$SYSTEM:ACC.EXE. The resulting
data file is SYS$MANAGER:ACCOUNTNG.DAT. Review ACCOUNTING reports
because they can provide early indications of problems. Check for
the following:
Unfamiliar user names
Unfamiliar patterns of use, such as unusual activity
for a particular time of day or day of week
Use of an unusual amount of resources
Unfamiliar sources of login, such as network nodes
or remote terminals
Security Auditing As the security administrator, you can have the operating
system report on security-related activity by enabling categories
of events for auditing using the DCL command SET AUDIT. Using the
Audit Analysis utility (ANALYZE/AUDIT), you can periodically review
event messages collected in the security audit log file. (See
Security Auditing for a full description
of the process.)
The operating system can send event messages to an audit log
file or to an operator terminal. You define whether events are reported
as audits or alarms in the following way:
Ordinarily, enable audits rather than
alarms for security-related events because the audit records are written
to the system security audit log where you can study them in volume
and archive log files for future reference. While an isolated auditing
message may offer little insight, numerous audit records produce
a pattern of security violations. For example, with auditing of
object access, you can see a pattern of time, types of objects being
accessed, and other system information that, in total, paint a picture
of how the system is being used at different times of day. To enable audits for unsuccessful access to files, devices,
and volumes, enter the following command:
$ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME)
This command records unsuccessful access events in the security
audit log file but sends no alarms to the operator terminal.
Enable security alarms for real-time events or events
that should be reviewed immediately, for example, intrusion attempts
or changes to the system user authorization file (SYSUAF.DAT). For
example, to enable alarms for modification to the known file list
and changes to system time, enter the following command:
$ SET AUDIT/ALARM/ENABLE=(INSTALL,TIME)
This command sends event messages to the operator terminal.
To keep a hardcopy record of these alarms, use a hardcopy operator
terminal, or enable the events as both alarms and audits.
Because security auditing affects system performance, enable
auditing only for the most important events. The following security-auditing
actions are presented in order of decreasing priority and increasing
system cost:
Enable security
auditing for login failures and break-ins. This is the best way
to detect probing by outsiders (and insiders looking for accounts).
All sites needing security should enable alarms for these events.
Enable security auditing for logins. Auditing successful
logins from the more suspicious sources like remote and dialup users
provides the best way to track which
accounts are being used. An audit record is written before users
logging in to a privileged account can disguise their identity.
Enable security auditing for unsuccessful file access
(ACCESS=FAILURE). This technique audits all file-protection violations
and is an excellent method of catching probers.
Apply ACL-based file access auditing to detect write
access to critical system files. The most important files to audit
are shown in
System Files Benefiting from ACL-Based Auditing.
(
Access Control Entries (ACEs) for Security Auditing presents an example
of how to establish security entries in ACLs.)
You
may want to audit only successful access to these files to detect
penetration, or you may want to audit access failures to detect
probing as well. Note that some of the files in
System Files Benefiting from ACL-Based Auditing are written during normal system operation. For
example, SYSUAF.DAT is written during each login, and SYSMGR.DIR
is written when the system boots.
Table 1 System Files Benefiting from ACL-Based Auditing
Device and Directory
File Name
SYS$SYSTEM
AUTHORIZE.EXE
F11BXQP.EXE
LOGINOUT.EXE
DCL.EXE
JOBCTL.EXE
SYSUAF.DAT
NETPROXY.DAT
RIGHTSLIST.DAT
STARTUP.COM
VMS$OBJECTS.DAT
SYS$LIBRARY
SECURESHR.EXE
SECURESHRP.EXE
SYS$MANAGER
VMS$AUDIT_SERVER.DAT
SY*.COM
VMSIMAGES.DAT
SYS$SYSROOT
[000000]SYSEXE.DIR
[000000]SYSLIB.DIR
[000000]SYS$LDR.DIR
[000000]SYSMGR.DIR
Enable security auditing for modifications to system
parameters or the known file list (/ENABLE=(SYSGEN,INSTALL) ).
Audit use of privilege to access files (either write
access or all forms of access). Implement the security audit with
the keywords ACCESS=(SYSPRV,BYPASS,READALL,GRPPRV). Note that this
class of auditing can produce a large volume of output because privileges
are often used in normal system operation for such tasks as mail
delivery and operator backups.
HP OpenVMS Guide to System Security
Security for the System Administrator
