Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ukma!psuvm.bitnet!cunyvm!unknown From: rrk@byuvax.bitnet Newsgroups: comp.os.vms Subject: re: DCL DECnet command procedure Message-ID: <28rrk@byuvax.bitnet> Date: Tue, 24-Nov-87 11:32:10 EST Article-I.D.: byuvax.28rrk Posted: Tue Nov 24 11:32:10 1987 Date-Received: Sun, 29-Nov-87 13:55:24 EST Lines: 26 A system manager who knows anything about DECNet can disable such command procedures. If a system manager understands the security "hole" and does nothing about it, he's stupid. DECnet is, in my opinion, the biggest potential security problem in a VMS environment, because unlike most VMS security, it doesn't mostly take care of itself, so all the system managers who get by in most other areas without really knowing much can open big holes in a hurry. Another thing people should watch for: If you set your print devices spooled, anyone on or off the system can print for free by copying to node::device:. I know of NO reason for ever making a device spooled, but most system managers do it anyway. Another good idea is probably to enter a proxy for node::* to * so that all local users cannot access the local system via the DECNet account. (It is a very BAD idea to do such a wildcard proxy between two systems not managed by the same person, as it allows "superusers" of one system to exploit the other system by changing username). I would disallow all access for the DECNET username except for mail (possibly). Why allow remote users to see all your directorys, to execute com procedures, print files, see who's on the system, etc. If a manager doesn't worry about his network--I won't go so far as to say that he deserves to have his security compromised; noone deserves that--he can expect to have his security compromised.