- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Setting the SYSTEM a/c to DISUSER
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 12:12 PM
тАО12-15-2009 12:12 PM
Setting the SYSTEM a/c 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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 01:43 PM
тАО12-15-2009 01:43 PM
Re: Setting the SYSTEM a/c to DISUSER
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 03:32 PM
тАО12-15-2009 03:32 PM
Re: Setting the SYSTEM a/c to DISUSER
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 10:50 PM
тАО12-15-2009 10:50 PM
Re: Setting the SYSTEM a/c to DISUSER
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 03:11 AM
тАО12-16-2009 03:11 AM
Re: Setting the SYSTEM a/c to DISUSER
Yes, the SYSTEM account was a captive account :-)
Added to the setup offered by John Gillings, should this secure enough your site ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 03:51 AM
тАО12-16-2009 03:51 AM
Re: Setting the SYSTEM a/c to DISUSER
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 05:20 AM
тАО12-16-2009 05:20 AM
Re: Setting the SYSTEM a/c to DISUSER
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 06:42 AM
тАО12-16-2009 06:42 AM
Re: Setting the SYSTEM a/c to DISUSER
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 06:53 AM
тАО12-16-2009 06:53 AM
Re: Setting the SYSTEM a/c to DISUSER
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 06:58 AM
тАО12-16-2009 06:58 AM
Re: Setting the SYSTEM a/c to DISUSER
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