Log keystokes for the SYSTEM account

[Melinda Chan]

Hello
as part of an audit requirement, I need to log the keystrokes entered for the SYSTEM account.

They do not want me to $set host 0/log=[filename]. They want an automated solution.

Suggestions anyone? Much appreciated.

[labadie_1]

there is a commercial tool called peek and spy, see at

http://www.networkingdynamics.com/Peek.htm

[Karl Rohwedder]

I use an (very) old utility called LOGGER, which creates a subprocess and logs everything in a file SESSION.LOG.

Perhaps your audit people are satisfied, if you put a call into LOGIN.COM for the system account for interactive logins.

You can find LOGGER e.g. here

http://ftp.uma.es/Vms/Wku/logger.zip

[Melinda Chan]

thanks to Labadie and Karl for their pointers. You've answered my question. I've looked into both options and they do, do the job.

However a lot of other questions as to the feasibility of logging the SYSTEM a/c has come up. eg. cause & affect to system performance, system startup etc. which I need to work through...

again, thanks for you help MC

[Stanley F Quayle]

You may find some useful stuff here:

http://h71000.www7.hp.com/wizard/wiz_9607.html
http://h71000.www7.hp.com/wizard/wiz_4920.html

http://h71000.www7.hp.com/wizard/openvms_faq.html
(especially topic 5.2, but it's all good stuff)

You'll also want to refer to the Guide to OpenVMS System Security manual, available off of the Documentation link at http://www.hp.com/go/openvms

You will want to secure physical access to the system console, since that can be used to bypass security.

I have written a script that logs access to the SYSTEM account. Run it from SYS$MANAGER:SYLOGIN.COM. It's attached.

[Wim Van den Wyngaert]

If you setup proxy for rlogin, you can add to login.com

$ if (f$mode() .eqs. "INTERACTIVE") .and. -
f$getdvi("TT","TRM")
$ then
$ rlogin/log=xxx localhost
$ logout
$ endif

[Keith Parris]

PointSecure's System Detective also seems to be able record session activity. See http://www.pointsecure.com/products/sys_det.asp

[John Gillings · Accepted solution]

Melinda,

Auditors can be rather silly at times. This request is a bit like a bank giving tellers a special ledger to record the amounts they embezzle ;-)

Since this is the SYSTEM account, there is simply NO WAY to guarantee a high integrity log on the same host. The SYSTEM account has several "ALL" class privileges, so would be able to bypass or censor any mechanism you implement.

It would be possible to make a log on a different host (on which the users of the target SYSTEM account have no privileged access). You then need to force all logins to the secure system through the gatekeeper system.

Please log a call with the CSC. I have some sample code which may help. We can also discuss performance and management.

[Martin P.J. Zinser]

Hello,

if there is really a good need for it, there
is always the solution of secondary passwords for the system account. If you make sure that every person only knows one of the two passwords, you can be pretty sure that no >>single<< person can tamper with the system, you need at least two to do so ;-). This does assume physical access to the console is secured.

Greetings, Martin

[Jan van den Ende]

Martin,

and then you still must be able to guarantee that there is no other way to tweak the double password requirement.
How do you enforce the permanent presence of two people at the logged-on session, and simultaniously have each one of them have his/her own password regularly changed without the other being aware?
And if you want to show real paranoia, how do you guarantee those two will not form a conspiracy?
Somewhere on the line you will hit the point where you just plainly HAVE to rely on some amount of trust...

Jan

[Willem Grooters]

You most definitely need some trust.

"If you don't trust anyone, don't allow anyone even near your machine and unplug all network connections"
I would add: "and if you're really paranoid, disconnect it from the main power as well, there might be nerds out there trying to break in along THAT way"

Ridiculous, of course. ;-))
Audit is fine. Being suspicious is Ok in some degree put paranoia tends to drift off into the blue. This type of audit logs tend to get quite unworkable

Best way to secure the system and keep a _workable_ audit log, just use some common sense. Of course you may run into exceptions, but these should be very rare (that means: exceptional).

1. NEVER use SYSTEM login, except when really required (typically installation) and then only from the console. A secondary (SYSTEM) password can be an extra barrier. Limit this to just a few people.
Diasllow interactive login, normally.
Have a password lifetime long enough to login and finish the intended activity, but as short as possible.

2. Strip authorized privileges to the bare bones to what a person REALLY needs. Same for default - being a (minimal) subset of authorized privileges.
Those that require access conform SYSTEM would need just enough privileges as well.
NEVER GIVE OUT SETPRV or BYPASS. These are 'never' needed.

3. That means that people that really need SYSTEM-like access can do with just their needs - normally a subset of the whole bunch. They can always set their level of privilege to match their need (BTW - kan SET PROC/PRIV be audited). One possibility they will need is to generate a new SYSTEM password and change other attributes when needed (this can be audited!).

4. If you do your SYSTEM work, keep away as far as you can from using arrowkeys (buffer recall), fullscreen editor....It makes the log quite unreadble.

The _easiest_ way for audit log is a plain-ASCII teletype terminal as I used to have them on PDP's. If you have a VT terminal hookedup as a console, you could think of attaching a printer to it and set it to follow in- and output.

Willem