Security Alarms and Audits

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