Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!unisoft!dual!ucbvax!HI-MULTICS.ARPA!MHJohnson From: MHJohnson@HI-MULTICS.ARPA (Mark Johnson) Newsgroups: mod.computers.vax Subject: DECNET Security Questions Message-ID: <861109175720.777844@HI-MULTICS.ARPA> Date: Sun, 9-Nov-86 12:57:00 EST Article-I.D.: HI-MULTI.861109175720.777844 Posted: Sun Nov 9 12:57:00 1986 Date-Received: Tue, 11-Nov-86 06:21:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: info-vax@sri-kl.arpa 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