VMS Workstation Security Monitoring

[mfstephens]

Can someone give me direction on how VMS Workstation logs security events?

I'm hoping it is to syslog and can be configured to redirect syslog to a syslog host.

Please Help.. Thanks...

M

[Joseph Huber_1]

VMS has its own AUDIT facility, not compatible with Unixs syslog.
The process in VMS is AUDIT_SERVER, and the datafile is by default
sys$common:[sysmgr]SECURITY.AUDIT$JOURNAL
The commands to set parameters for audit are SET AUDIT,
and analysis of the audit data:
ANALYZE/AUDIT.
See HELP SET AUDIT and HELP ANALYZE /AUDIT,
and read the VMS system manager manual.

As far I know, there is no implementation of a syslog client for VMS. Somewhere on a freeware archive I saw a syslogd for VMS, i.e. sending syslog entries from other systems to VMS should be possible.

The VMS audit server can be asked to send its events down a listener mailbox. This would be the place to plugin a syslog client: reading the listener mailbox, format and write to the remote syslogd.

[mfstephens]

Thanks...

Great.......

M

[David Jones_21]

I'm sure the OpenVMS security people at HP would blanche at a proposal to use syslog for a security audit log. Not only is it insecure, the protocol uses UDP, so you can't garantee the remote system actually logged your message.

[Peter Quodling]

Amen, I constantly battle with supposed Industry experts who insist that the "UNix" way on this and many other issues is the best approach. I refer to it as "Lowest common denominator computing... You may want to talk to your local OpenView geek to see what they can do, as well.

Security in VMS was designed sometime back by some very clever people. Bear in Mind, that when it was the "thing to do" VMS was consistently getting the US DOD NCSC C2 tick of approval, and there was a product (SEVMS) that was B1 rated. (And even an internal project that had a working A1 secure system, but that's a story for beer-o-clock).


q

[Wim Van den Wyngaert]

If you have the time you can write a program to process the audit alarms yourself too.

set aud/list will enable that audit_server writes all audit messages to a mailbox.

Your program reads this and passes the info to whatever you want.

Wim

[Willem Grooters]

The type of system doesn't matter. VMS on a workstation does not differ from VMS on a server. It's not Unix nor is it like Windows. It has it's own ways of logging all kinds of events, and audit is no different.
You can set audit for logging, which is logged in SYS$MANAGER:SECURITY.AUDIT$JOURNAL, or for alarm, which is logged there as well, and on OPERATOR.LOG.
However, audit on VMS is (by design?) something node-local.
If your workstation boots from a common system disk, it will have it's own SYS$SYSTEM and, quite likely, it's own SYS$MANAGER, so it's own security and (if enabled) operator.log. Be sure to have this closed for unauthorized access. (which is a general recommendation).

If the system has it's own systemdisk, these files will normally reside on it as well. OPEARTOR.LOG may be disabled, but OPCOM will try to send it;s messages to other clusternodes as well. Have big systems set to handle all messages (from itself and all incoming ones) and the small ones (that have no OPERATOR.LOG locally) to disallow incoming messages, but allow sending them.
By that, the bigger hosts will function as loghost - not the Unix way since messages will be sent by the cluster communication protocol (which is (AFAIK) secure).

If your workstation is stand-alone, it will audit on it's own system disk - or, if you define so, to a security mailbox. AYou have to create a listener that reads this mailbox, and handles the message - but you will be able to specify what it will do: sending it to another host, for example, for further processing.

Bear in mind however, that is that case you have to add the nodename to the message, before storing. Since Audit is local, there is no nodename mentioned in the audit message.

Willem

[Joseph Huber_1]

em Willem,
by default, the audit log file is
SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL

So on cluster with a common system disk, there is one common audit log.

In a cluster with several system disks, one can use SET AUDIT/DESTINATION to have a common file.(Although one has to take care using /SERVER=NEW_LOG).
In addition there is the AUDIT/ARCHIVE feature to send all or selected (like security only) events to a common log file.

[Willem Grooters]

Sorry, my mistake. Looked on a single (non-clustered) node. Also saw this moring that Audit does indeed show the nodename, so in a cluster, there is centralized logging possible.
Just curious on this:
In a NON-clustered environment, would /DESTINATION=node::disk:[dirpath] be possible (assuming DECNet installed and running)? Accoring HELP SET AUDIT /DESTINATION, it must be a disk, but it doesn't state whether it must be local or can be remote.

Willem

[Willem Grooters]

One more remark - for clustered systems, just to be complete.
It is possible to route all messages to bigger machine(s) and not log events on the workstation. On that bigger machine, one terminal (CRT of hardcopy) can be designated as OPER console for class SECURITY only, and all security-related messages will be signalled on that terminal - virtually real-time.

Willem

[Joseph Huber_1]

To "route to a bigger machine", You mean just have the audit event sent, not written to a journal on that machine ? I doubt it is possible, except the documented /listener mailbox.

The operator messages are independent of audit journal or archive, they always are sent clusterwise from opcom.
Just don't have an operator log file started on all other nodes (the default anyway on workstations), and no OPCOM enabled terminals except the one wanted.

Setting the audit journal destination to a decnet address: I doubt it is possible, but hey : why don't You just test it and report what happens ?

[Ian Miller.]

If you want the audit information to go to another file in addition the audit log the look at HELP SET AUDIT/ARCHIVE

[Willem Grooters]

Indeed, all OPCOM will be sent, but enable just ONE OPER termnal for class SECURITY. No experience, just deducting: it will show security-related messages. /ARCHIVE could filter. Someting I CAN test (and will report upon).



I would if I had two (non-clustered) systems communicating via DECNet (I have plans to create such a network but time is limited)

Willem