Setting the SYSTEM a/c to DISUSER

[John A. Beard]

Question about the issues of setting the SYSTEM account to /DISUSER.

Our auditors are requesting that we modify the SYSTEM account with the /DISUSER flag set (they are concerned about possible external attacks, etc...too well known a username...)

We do have a number of alternate fully privileged accounts running under [10,*].My questions here is if we do disuser the SYSTEM account will that have any effect on areas such as booting the VMS boxes or any other non-site independant startup procedures. All our 3rd party products are started via alternate privileged accounts so I am not concerned about them at this point.

No doubt I have left a million and one things out of this scenario, but if there was a "show stopper" from the word go then that will suffice for the immediate future.

Thanks in advance...

[John Gillings]

John,

In general, I don't think this is a good idea. I'd expect the assumption that SYSTEM is not DISUSERed to be all over the place. In particular, it would seriously constrain your startup procedure, as you couldn't SUBMIT any jobs.

If the concern is external attacks, there are several defences, especially if you don't use the account for interactive logins. Start with a completely random, 32 character password that even you don't know. First line in LOGIN.COM:

$ IF F$MODE().EQS."INTERACTIVE" THEN LOGOUT

Maybe add UAF/INTERACTIVE and /NETWORK access restrictions. If the auditors trust the DISUSER bit in the UAF, they should also trust access restrictions.

If you want to go further, jack up LGI_HID_TIM from 5 minutes to a few hours. Then you can DELIBERATELY feed in login attempts with invalid passwords at regular intervals to keep SYSTEM in INTRUSION state. That way even if some external hacker manages to guess your 32 character random password, they STILL won't get as far as the LOGOUT command, but network and batch jobs will still work.

On the other hand, you could just try it and see what breaks ;-)

Check with HP. I think it's still recommended that patches be installed from SYSTEM, and it's possibly mandatory for OS upgrades (though that can be dealt with by temporarily enabling the account).

The big question you need to sort out with the auditors: does the (arguable) decreased risk from external penetration balance the increased risk and cost resulting from running a non-standard (and possibly unsupported) configuration?

(I've been in plenty of places with very high audit standards, and can't remember ever going as far as DISUSERing SYSTEM).

[Hoff]

Your auditors have just proved themselves to be somewhere between ignorant and idiot; this'll disable your server.

[Steve Reece_3]

This was certainly possible, though not recommended, with v5.5-2 on VAX. I've not tested it on any other versions, whether VAX, Alpha or IA64.
All of the startup jobs that aren't run directly as part of the startup process will have to be submitted as a different user (one of your priv'ed accounts) and you'll have to test it to see what breaks. Most patches rely on being a privileged account, not the SYSTEM account.
Do bear in mind though that the SYSTEM account can still login on OPA0: even if it is disusered. Also bear in mind that disks need to be owned by someone and that's usually the SYSTEM account. You can get some odd results if a different account initializes a disk and you then remove that priv'ed account.
Steve

[labadie_1]

I once worked at a site where in order to log in with the SYSTEM account, after having correctly entered the 2 passwords (generated by VMS, with at least 10 characters), you had to be authorized by somebody on OPA0:.
Yes, the SYSTEM account was a captive account :-)

Added to the setup offered by John Gillings, should this secure enough your site ?

[Jan van den Ende]

John,

I completelely agree with Hoff.

Way back when (VMS 5.x; Vax) we got the same request. We complied, but at the next reboot we were in deep s**t!! It happened to by on my day-off, but eventually they tracked me and I had to drive up (ca 100KM!)
Only remedy was SYSBOOT, console-only change-back of SYSTEM account.

And thereafter trying to explain to noncompos auditors WHY we did undo what they requested... :-(

Save yourself the trouble: DO NOT DO THIS!!

Proost.

Have one on me.

jpe

[John A. Beard]

Thanks to one and all for your responses.

There is a possibility that I may be moving to a different organization within the next couple of months, and if so I may well leave it untill my final day to post the auditors a copy of Hoff's reply :) .... thanks again folks.

[Hoff]

If you're feeling more charitable toward these auditing folks than I, you could pass along the NIST or other security review procedures to them; I have links to these documents posted.

As for the SYSTEM /FLAG=DISUSER suggestion, these auditing folks didn't research their suggestion and they also didn't try their recommendation on their own server.

They look to be experimenting on your servers, and on your production environment. I'd be correspondingly skeptical around their other suggestions, too; there's _way_ too much security theater around for my preferences.

[Hoff]

ps: the two-password stuff is intended so that two people each with half of the login necessary for access to SYSTEM or another user so configured; so that two folks must be present to log in as SYSTEM or other such user. Having one person possess both passwords isn't particularly beneficial.

Two-password access does block stuff like DECnet FAL access via that username; there's deliberately no provision to pass both passwords over the link.

[John A. Beard]

Thanks Hoff,

I think I have been well armed with the all the advice give in this thread, but at the same time I would appreciate knowing what the links were that you referred to about NIST