MHJohnson@HI-MULTICS.ARPA (Mark Johnson) (11/09/86)
I have a series of questions about DECNET security. Our customer would like to have our system be a part of their corporate DECNET network and questions have been raised about how the systems should be secured. We are concerned that proprietary information might be moved from system to system w/o being detected (1) Should I disable the default DECNET account completely or is there a way to properly restrict access to files and other resources instead? (2) Can I reject SET HOST commands from some nodes? I would like to implicitly reject all nodes & then allow access from some. (3) Should I add a proxy entry of *::* -> XXX, where XXX is a username that is disabled from network operations? Does this gain me anything? (4) Should I dedicate a MicroVAX for this link & control access at that point or does it make any difference? (5) Must all systems on the network be protected or can a `fire wall' be set up (like on the system described in 4) instead? The reason we wish to do this is for electronic mail, updates of documentation and source, and other data transfer. We will have some of our people at their site for several months and they will need access to some of our stuff on a regular basis. If you have any suggestions on this, please let me know. I doubt that this is the only customer we wish to do this for, so if we don't find out now, we will have to find out later. I'll summarize the responses in a week or so. --Mark <MHJohnson @ HI-MULTICS.ARPA>
LEICHTER-JERRY@YALE.ARPA (11/14/86)
I have a series of questions about DECNET security. Our customer
would like to have our system be a part of their corporate DECNET
network and questions have been raised about how the systems should be
secured. We are concerned that proprietary information might be moved
from system to system w/o being detected.
There are many different notions of "security". You've described one: You
want to DETECT violations. Detection does not necessarily imply PREVENTION.
Is that what you have in mind?
There are also related questions. For example, who do you want to protect
against? Unprivileged users at terminals on the remote machine? PRIVILEGED
users? Users who can physically play around with a remote machine? Users
who can tap the phone lines connecting the machines? All of these require
different amounts of effort to deal with; I've ordered them in order of
increasing difficulty. (Protecting against wire tappers is quite difficult,
given the present state of the art.)
Similarly, the amount and kind of access you want to provide to remote users
makes a big difference.
(1) Should I disable the default DECNET account completely or is there
a way to properly restrict access to files and other resources instead?
You can restrict access in various ways, at a lot of "grains of coarseness".
The UIC protection scheme is enough, if the UIC of the DECnet account puts it
in a unique group of its own, to ensure that only files that are accessible to
WORLD could be accessed via the default DECnet account. With ACL's, you could
go further and explicitly exclude access by the default DECnet account, or
any network access (even using an explicit username/password or proxy, but not
a SET HOST remote process) by excluding all holders of the NETWORK identifier.
(The SET HOST processes have REMOTE rather than NETWORK.) Note that all of
this can be done even while leaving the files accessible to the "world" on the
local machine. (However, watch out for SUBMIT/REMOTE; I don't know what
characterizes such jobs off hand.)
(2) Can I reject SET HOST commands from some nodes? I would like to
implicitly reject all nodes & then allow access from some.
I don't think you can do this with NCP directly. However, if you define a
system-wide SYS$SYLOGIN file, it will ALWAYS execute. Within that file,
you can check the logicals SYS$REM_NODE and SYS$REM_ID to determine where the
connection is coming from, and from whom, and then act accordingly. (Note
that these logicals are new in VMS V4.4.)
Note that you can restrict access with the ACCESS parameter of the SET EXEC
and SET NODE NCP commands. However, be aware that a remote user with SYSPRV
is allowed in despite such access restrictions.
(3) Should I add a proxy entry of *::* -> XXX, where XXX is a username
that is disabled from network operations? Does this gain me anything?
I can't think of anything at all that this gains; it's more or less like
disabling the default DECnet account, except that if the default account is
still there, a remote user can always get to it (by using the NODE"":: form,
which specifies explicitly null access control, thus overriding any proxies).
(4) Should I dedicate a MicroVAX for this link & control access at
that point or does it make any difference?
It all depends on what it is you are trying to accomplish. You haven't been
clear enough on this for me to be able to answer. It might.
(5) Must all systems on the network be protected or can a `fire wall'
be set up (like on the system described in 4) instead?
Again, it depends on what threats you are concerned about, and on what kinds
of access you want to allow.
Given the state of the art, I would be very hesitant about relying completely
on a "fire wall", unless that fire wall was simple and "thick", allowing very
little through at all (i.e., the ALLOWED accesses were very limited).
The reason we wish to do this is for electronic mail, updates of
documentation and source, and other data transfer.
Still not enough information to be sure. Do you need on-line access, or
just the ability to transfer files? Could you live with nothing but MAIL
access? (That could be made highly secure by having an intermediate node, as
in (4), with "mail drops" - there is no direct DECnet connection "across" the
MicroVAX; it talks to one network at a time, picking up mail and forwarding
it. This would obviously require some hacking to set up.)
We will have some of
our people at their site for several months and they will need access to
some of our stuff on a regular basis. If you have any suggestions on
this, please let me know. I doubt that this is the only customer we
wish to do this for, so if we don't find out now, we will have to find
out later. I'll summarize the responses in a week or so.
-- Jerry
-------