Security Auditing - How to log user logins for accounts that have SYSPRV.

[djk]

I would like to create an Audit log record when high-privilege accounts (SYSPRV, BYPASS, etc) login. This would enable me to see how frequently these accounts are being used.

I don't see how to do this with SET AUDIT/AUDIT. Can it be done?

[Joseph Huber_1]

probably not directly via SEt AUDIT.
Two possibilities:
(1) audit all (interactive,batch) logins.
Then use analyze/audit to select all logins, and check the users against sysuaf for elevated prvileges.

(2) set audit/audit/enable=(ACCESS=SYSPRV,ACCESS=BYPASS)
to audit all accesses due to those privileges.
See HELp SET AUDIT /ENABLE for details.

[RBrown_1]

There is likely no way that is safe against being disabled, since the high-privilege guys can probably defeat it.

All I know is what I read in HELP just now.

I would look into putting an AUDIT ACE on the LOGIN.COM files for these accounts. SET AUDIT/ENABLE=ACCESS for these files to audit EXECUTE and MANAGE access to this file.

I think that the EXECUTE auditing would tell you when LOGIN.COM is executed (mostly only when the user logs on) and when the user tries to modify the ACE (to stop the logging).

[Joseph Huber_1]

Sorry, the correct set audit is:
set audit/audit/enable=(ACCESS=(SYSPRV,BYPASS))

[Hoff]

Use the list of the users with ALL-class privileges or with system UIC settings, and you can then use accounting, or the audit logs, to search for the usernames of interest. You probably already have this enabled.

This query sequence isn't a single step, but it's quite simple to brute-force the necessary solution with some DCL-level queries into accounting or auditing.

The other traditional sequence available here is to add the necessary auditing into SYLOGIN using explicit DCL-level tests.

And the usual and long-standing recommendation: remove the privileges from the users, as impolitic as that can be.

[John Gillings]

djk,

Auditing /ENABLE=(ACCESS=(SYSPRV,BYPASS)) tracks every USE of the privilege, which may be too fine grained for what you want.

It may be simpler to audit all logins and filter them for the usernames you're interested in:

$ SET AUDIT/AUDIT/ENABLE=LOGIN=ALL

Login audits are a fairly useful thing to have anyway.

There's a fairly general approach to generating audits for arbitrary events which allows you to be highly specific, using files with audit ACLs which generated audits when touched in various ways. In this case, here's a possibility:

First create a file with a distinctive name to identify the event you're auditing. Leave the file empty.

$ CREATE SYS$MANANGER:SYSPRV_BYPASS_LOGIN.AUDIT

Apply security and ACE which will audit SUCCESSFUL access to that file:

$ SET SECURITY /PROTECTION=(S:R,O,G,W) -
SYS$MANANGER:SYSPRV_BYPASS_LOGIN.AUDIT -
/ACL=(AUDIT=SECURITY,ACCESS=READ+SUCCESS)

Since it's protected S:R, only users with SYSPRV and BYPASS can access the file.

Now, plant an access to the file in SYLOGIN.COM in a path that's executed by everyone. Since non-privileged users will get an error, use PIPE output redirection to block the message

$ SET NOON ! Don't exit on error
$ PIPE TYPE SYS$MANANGER:SYSPRV_BYPASS_LOGIN.AUDIT >nl: 2>nl:

Make sure ACL audits are enabled:

$ SET AUDIT/AUDIT/ENABLE=ACL

You can now search the audit journal for audit records with filename = SYS$MANANGER:SYSPRV_BYPASS_LOGIN.AUDIT these will identify the users and times they executed SYLOGIN (note that anyone can execute SYLOGIN at any time!).

As others have stated, privileged users can do anything, so this won't necessarily work if they're hostile (but if that's the case they shouldn't have privileges!).

[labadie_1]

As Rbrown and John Gillings have already stated, this is nonsense, as users with this type of privilege can do anything (like stop or freeze the Audit Server).

[Craig A]

I don't think it is nonsense at all.

For me, the number 1 priority here is to ensure that only those people who really need BYPASS, actually have it.

Under 8.3 you also need SECURITY privilege to fiddle with the audit server. It is perfectly possible for users to hold SYSPRV and still be denied access to the SYSUAF (assuming they haven't got BYPASS).

Craig

[tsgdavid]

Just another thought, but you could enter some commands in the system login file to check the authorized privileges of any user logging in and log the information in any way that you like (including something that goes to the audit log).

f$getjpi(0,"AUTHPRIV") will return the list of all authorized privileges for the current process.

Dave

[B Novak]

How about some simple DCL that pulls the username and checks it against a list of users that have high privilege? You could then write login information to include whatever stats you wish to a flat file for reference. (username, login date/time, etc.) This DCL could be placed in SYLOGIN.COM. Something similar to the below. It's simple and "ugly" but it works well.
.
.
.
$ pid = f$getjpi("","PID")
$ username = f$getjpi("''pid'","USERNAME")
$ username = f$edit("''username'","TRIM,UPCASE")
$ if username.eqs."WHOEVER" THEN ...

Instead of the last IF check, you could also maintain a simple flat file of the users that have high privileges and check that file with a SEARCH checking the status of the search results.

Just another way to skin the cat.

Cheers,
Bob

[Hoff]

>Under 8.3 you also need SECURITY privilege to fiddle with the audit server. It is perfectly possible for users to hold SYSPRV and still be denied access to the SYSUAF (assuming they haven't got BYPASS).

Only if they don't know what they're doing.

[Craig A Berry]

There are multiple ways to approach this, and the best approach will depend on what you mean by "how frequently" and what action you intend to take based on whatever definition of frequent or infrequent you're using.

If you just want to find privileged accounts that haven't been used in awhile, grab Joe Meadows' UAF utility:

http://code.google.com/p/jmuaf/

and simply scan to see when users with privileges last logged in:

$ uaf/select=(flags=nodisuser,priv=(bypass,sysprv))/match=and/display=(user,inter,noninter)


But if you really need timestamps for each and every access, uaf won't do it.

You could use JUMP:

http://vms.process.com/scripts/fileserv/fileserv.com?JUMP

and set things up such that the users don't actually have privileges on their own accounts, but jump to another account that does. There are various extensive logging operations available (opcom, mail, log files, etc.).

[The Brit]

I have a similar requirement where I have to have a specific log showing when user with privilege higher than SYSPRV log in and out.

I use a variation on the suggestion of Bob and Dave above. See Attachment.

Dave.

[Robert Gezelter]

djk,

Personally, I would probably go with ensuring that ACCOUNTING was enabled, and using the accounting report utility (or scanning the account log file myself with a custom program).

As Hoff and others have noted, a user with elevated privileges can generally find a way around the SECURITY privilege, it is just more involved. (CMKRNL trumps just about everything!)

- Bob Gezelter, http://www.rlgsc.com

[Joseph Huber_1]

Dave,
this does not catch users with SETPRV, but no sysprv or bypass enabled by default.
One would have to set an ACL allowing write access on priv_logins.dat for each such user.

[The Brit]

Thank you for pointing that out Joseph. I must admit that I had missed that.

(In mitigation, SETPRV is not a privilege that we would normally grant in isolation, it is usually only granted as part of a "system-level" account set-up. i.e. a user with SETPRV (in our environment) would normally have SYSPRV.)

In any case, I will re-examine my procedure to try to close this loop-hole.

thanks

Dave.

[Joseph Huber_1]

Just to explain my policy:
Having SETPRV as the only enabled DEFAULT privilege forces me to explicitly enable any other elevated privilege when needed, so I can't do any unintended damage.

Just a suggestion:
On my system I have a resource identifier "SYSMGR" granted to all users with elevated privileges.
making Your priv_login.dat owned by SYSMGR or attaching an ACL allowing write access for SYSMGR would make the logging possible to all users in this group, not only for SYSPRV and BYPASS users.

[RBrown_1]

My personal policy is similar to Joseph's. I generally work with only TMPMBX and NETMBX, but have SETPRV. I never change my privilege with SET PROCESS/PRIVILEGE. Instead I use my PRIV command file which removes the extra privileges I previously gave myself, and then adds the ones I am requesting this time.

See attached.