From: HENRY::IN%"JSPEAR%AI.AI.MIT.EDU%SRI-KL.ARPA%relay.cs.net@rca.com" 16-NOV-1986 10:54 To: MHJohnson@HI-MULTICS.ARPA Subj: RE: DECNET Security Questions (LONG) >Date: Sun, 9 Nov 86 11:57 CST >From: Mark Johnson >Subject: DECNET Security Questions >To: info-vax@SRI-KL.ARPA >Message-ID: <861109175720.777844@HI-MULTICS.ARPA> > >... We are concerned that proprietary information might be moved >from system to system w/o being detected I run a VAX on a DECnet network (nowhere near MIT) and we are concerned about similar problems. Computer and network security is a complex issue that most organizations have yet to come to grips with. Here are a few things to look at and think about. I'd be interested in hearing what you come up with on your own and/or suggestions you get from others. Before addressing your specific questions, let me climb on my soapbox and spout some applehood and mother pie on information security that you might not have heard before. -- Decide what you are protecting and why. You must assess the value and quantity of information, software, and hardware you are trying to protect. What is the impact if this falls into the hands (electronically or otherwise) of an unauthorized person? What if it is altered or corrupted? What if legitimate users are denied access? -- Know your vulnerabilities, your weaknesses that could be exploited. These probably include potential attacks against physical security, computer hardware and software, personnel, administrative procedures, accidents, compromising emanations, and natural (?) disasters to name a few. What is the value lost if each of these happens? -- Look at your environment and determine how likely each type of attack is. Could it ever happen? How often could it happen? -- Now that you have assessed your current level of risk, decide on an acceptable level you are willing to live with. Realize that you can never elimanate all risks, but you can reduce most risks if you are willing to expend the resources. The level of resources committed to countering a specific vulnerability should be commensurate with its likelihood and its cost should it happen. Remember that security is only as good as your weakest link. If you have done everything you can think of but someone can walk away with your backup tapes or tap your ethernet, you still have a major problem. -- Plan and implement countermeasures. Test them initially to verify they work, and periodically retest to make sure they still work. Make sure you understand the residual level of risk you still take. -- Any time there is any change to anything that might affect security, review everything again from step one above. Since you carefully documented all of the above, it won't be as much work the second time around. Starting to step down from the soapbox, the point of all this is that security is a broad area that encompasses many disciplines. If you are only looking at network security or physical security, you're probably leaving yourself wide open somewhere else. Depending on what you're protecting from who, it may be very foolish to connect to a network at all. There, my feet are back on the ground. I'll now assume you have already gone though some analysis like I discussed above and your only problem is that you are now considering a DECnet connection to a customer's computer. Of course you have already eliminated or secured all dialup lines since they pose a risk that is in some ways larger than the contemplated network link. > (1) Should I disable the default DECNET account completely or is there >a way to properly restrict access to files and other resources instead? Carefully read the Networking Manual and the Guide to VAX/VMS System Security! Briefly, the default DECNET account is used only when the remote node does not supply login information (either from its NCP data base or a user-supplied access control string), no proxy account matches, and no account has been specified in the executor NCP database for the network object being requested. I have (only) MAIL, PHONE, and NML tied to a default account, so anyone can use them remotely. Our biggest worry was remote users using FAL, the File Access Listener, to poke around on our system and copy files they might find, so I have put several (redundant) restrictions on FAL. (FAL restrictions also prevent use of SUBMIT/REMOTE and things like the TELL command files sent to the net a few months ago.) The system-wide login command file checks to see if this is a default account, and if it is, sets FAL$COMMAND :== $LOGOUT. SYS$SYSTEM:FAL.COM and FAL.EXE have an ACL denying access to the default accounts. (Each precaution is equal in power, but they make it a little harder for them to be accidentally disabled.) To use FAL now, a remote user must use an access control string (NODE"Username password"::), but even then some files are protected with an ACL denying NETWORK access. Similarly, if the user SETs HOST, some files are protected with an ACL denying REMOTE access. Remember that with access control strings the Username and Password show up on the screen, in the recall buffer, may show up in command files, and will get transmitted over the net. Proxy accounts are intended to fix these problems, but proxies require you to trust all other system managers on the net. Of course you should take the usual precautions with the default account(s): Put them in a group by themselves, captive, LGICMD pointing to a command file not in the default directly that has W:E protection and is owned by the system UIC, lockpwd, only network access, on a device with quota's enabled and a moderate quota set. > (2) Can I reject SET HOST commands from some nodes? I would like to >implicitly reject all nodes & then allow access from some. There is currently no way within NCP to allow a node to access certain objects while restricting access to others. Within NCP, the closest you can come is to allow only incoming or only outgoing access for a particular node. One way to restrict SET HOST is to put some checks in my system-wide login command file to check the job logical names SYS$REM_NODE and/or SYS$REM_ID (new for VMS 4.4), and take appropriate action. I have also added a system logical name that controls whether a remote login is allowed at all, and have a recurring batch job to reset this logical every evening. The main weakness here is that these checks can't be made until after the user has successfully logged in with a valid username and password. To address that problem, we also enable security alarms for remote logins and breakin detection with evasive action, so we know who is diddling with the system, successfully or otherwise. Finally, I don't allow any privileged or otherwise sensitive accounts to have REMOTE (or NETWORK) access enabled in the UAF. Be aware that it is fairly easy for a system to masquerade with another node's name and for any account name to be created on that node. One additional precaution I have contemplated is to require an algorithmic password to be entered for all remote logins (e.g. the current day of the week spelled backwards) at what looks like a DCL $ prompt. > (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? No. This is nearly equivalent to having no default DECnet account(s) and no proxies, and would still allow incoming access via SET HOST. It would, of course, prevent incoming MAIL, PHONE or NML requests/messages which you may want to allow. It would affect users on both trusted and untrusted machines. One reasonable measure along these lines might be to disable communications to the untrusted node (physically disconnect or at least $MC NCP SET CIRC (and line) xxxx STATE OFF) during times when legitimate network access is not needed. > (4) Should I dedicate a MicroVAX for this link & control access at >that point or does it make any difference? If all nodes are in the same DECnet area, simply adding another routing node in the middle won't make any difference other than slowing down the traffic and loading the MicroVAX with transit packets. If, however, the MicroVAX is an area router, it makes it more difficult for a casual user in the untrusted area to find out the names and addresses of nodes in the trusted area. > (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? I don't know of any easy way to do this. I am sure that if you were willing to muck around with the internals of DECnet routing mechanisms, or would allow only task-task communications using protocols of your own creation, you could get almost any software strength of "firewall" you might want. There are some sticky problems in deciding what modes of access to allow, and what sort of authentication to require of users. It is also hard to verify that these measures are adequate, correctly implemented, and can't be bypassed. A restricted access router or gateway like this seems like something that might have wide applicability, so there might be commercial products addressing this need. One simple scheme that is relatively easy to implement but hard to use and manage is to use the MicroVAX as a buffer machine that may be connected to only one side of the network at a time and checking information that has been added before allowing it to change sides. Of course this will slow down traffic and won't allow PHONE or SET HOST through it. > ... > --Mark One final note. If, as you stated initally, your only concern is detecting access to proprietary information, maybe all you need are ACLs on all such files that cause an ALARM any time they are accessed. Hope this helps, - Jon Spear (505)844-0107