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.