All of the security measures discussed protect the user from making stupid mistakes and protect the legitimate user community from malicious users and hackers. But protection is only the first step. The manager should be monitoring the various OpenVMS reports for security breaches as well. In the case of stupid mistakes, the manager may need to introduce better training directed at the specific user or toward a group of users. In the case of malicious security breach attempts, the manager may need to apprehend the offender or may want to tighten up security in certain areas.
The audit server, AUDIT_SERVER, is started automatically at boot time. It displays alarms on the operator console and records audits in SYS$MANAGER:SECURITY.AUDIT$JOURNAL. More than 20 events can cause an alarm and/or audit event. Alarms and audits can be enabled separately with the SET AUDIT command. To display which alarm and audit events are enabled, use SHOW AUDIT, as follows:
MANAGER> show audit System security alarms currently enabled for: ACL Authorization Breakin: dialup,local,remote,network,detached System security audits currently enabled for: ACL Authorization Breakin: dialup,local,remote,network,detached Logfailure: batch,dialup,local,remote,network, subprocess,detached
The audit information stored on disk is displayed by ANALYZE/AUDIT. The following displays show the same data in two formats. The first is a summary of all possible events, and the second provides more details about the six events. A third format, /FULL, displays even more data about a specific event.
MANAGER> analyze/audit/summary security.audit$journal Total records read: 8 Records selected: 8 Record buffer size: 512 Successful logins: 0 Object creates: 0 Successful logouts: 0 Object accesses: 0 Login failures: 5 Object deaccesses: 0 Breakin attempts: 1 Object deletes: 0 System UAF changes: 0 Volume (dis)mounts: 0 Rights db changes: 0 System time changes: 0 Netproxy changes: 0 Server messages: 0 Audit changes: 2 Connections: 0 Installed db changes: 0 Process control audits: 0 Sysgen changes: 0 Privilege audits: 0 NCP command lines: 0 MANAGER> analyze/audit/brief security.audit$journal Date / Time Type Subtype Node Username ID --------------------------------------------------------------------------------- 9-AUG-2002 00:00:56.17 AUDIT AUDIT_LOG_FIRST BEAVER 00000000 9-AUG-2002 07:39:01.36 LOGFAIL REMOTE CSWWW <login> 208025C0 9-AUG-2002 07:39:05.69 LOGFAIL REMOTE CSWWW <login> 208025C0 9-AUG-2002 07:39:09.99 LOGFAIL REMOTE CSWWW <login> 208025C0 9-AUG-2002 07:39:22.40 LOGFAIL REMOTE CSWWW <login> 20802641 9-AUG-2002 07:39:27.79 LOGFAIL REMOTE CSWWW <login> 20802641 9-AUG-2002 07:39:32.47 BREAKIN REMOTE CSWWW AMGASSER1 20802641 10-AUG-2002 00:00:58.43 AUDIT AUDIT_LOG_FINAL BEAVER 00000000
On the system I help manage, the audit file is restarted daily at midnight with the following command. Thus, the /BRIEF display shows those events as well.
$ set audit/server=new_log
Curiously, at the time I was preparing this example, user AMGASSER1 attempted to use his or her account. We disable student accounts during the summer, a fact the user apparently forgot. He or she tried so many times that a break-in was declared.
In addition to audit reports, the system manager may need to manage login violations. For instance, when a user login attempt reaches a given limit (this is a SYSMAN parameter), the user is prohibited from logging in even if done correctly for a certain time (another SYSMAN parameter). This usually occurs when novices are introduced to OpenVMS. The manager may monitor this action using SHOW INTRUSION.
$ show intrusion Intrusion Type Count Expiration Source ---------- --------- ----- ---------------------- ------------------- TERMINAL SUSPECT 3 2-AUG-2002 11:50:09.07 71.phoenix-13rh15rt- az.dial-access.att.net NETWORK INTRUDER 9 2-AUG-2002 11:58:37.87 LOON::DMILLER
Then the manager, using DELETE/INTRUSION, may remove the offending line, thus permitting the user to log in again without waiting for the timer to run down. For instance:
$ DELETE/INTRUSION LOON::DMILLER