DEMAR@FNALE.BITNET (11/17/87)
Last week there was an inquiry from BEN@VMSA.TECH.AC.IL about a DCL command procedure that can be used to examine remote DECnet systems. I want to add a word of warning about the use of this type of program. It works by sending a copy of itself into the default account of the remote system, then utilizing task-to-task communication between the two programs. It is a primary weapon of hackers; and, infact, is a form of hacking in its own right, since the user is copying and executing a file on a the remote system without any authorization to do so. I happen to be quite involved in the daily network management of the High Energy Physics DECnet network (HEPnet). The HEPnet network management considers any use of this type of program to constitute hacking, and we agressively pursue people who use it, requesting the facility involved to deal with the situation in a manner "that STRONGLY discourages any future occurrances". We are, infact, willing to involve the FBI and the Justice Department, if necessary. While I can only speak for HEPnet, I know for a fact that the Space Physics Analysis Network (SPAN), another large DECnet network, also aggressively pursues users of this type of program. My advise for anyone thinking about using this type of program across any wide-area is to recognize this as a form of hacking, and to refrain from utilizing it. Either that, or be prepared to have the wrath of the gods or the law descend upon them. -- Phil DeMar DEMAR@FNAL.BITNET
rrk@byuvax.bitnet (11/24/87)
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.
klb@philabs.Philips.Com (Ken Bourque) (11/24/87)
In article <8711231109.AA29035@ucbvax.Berkeley.EDU> DEMAR@FNALE.BITNET writes:
*
* Last week there was an inquiry from BEN@VMSA.TECH.AC.IL about a DCL
* command procedure that can be used to examine remote DECnet systems. I want
* to add a word of warning about the use of this type of program. It works by
* sending a copy of itself into the default account of the remote system, then
* utilizing task-to-task communication between the two programs. It is a
* primary weapon of hackers; and, infact, is a form of hacking in its own right
* since the user is copying and executing a file on a the remote system without
* any authorization to do so.
For this and other reasons, I think that default DECnet access should be
enabled on an object-specific basis (and not for FAL if at all avoidable)
rather than on a system-wide basis.--
Ken Bourque klb@philabs.philips.com ...!{uunet,ihnp4,decvax}!philabs!klb
tedcrane@batcomputer.tn.cornell.edu (Ted Crane) (11/26/87)
In article <28rrk@byuvax.bitnet> rrk@byuvax.bitnet writes: >If you set your print devices spooled, anyone on or off the system can print >for free by copying to node::device:. Only if there is a default DECnet account, proxy logins, or they supply an explicit username/pswd string. Once again, the default DECnet account is the security hole...if a system manager provides it, they are inviting others to use it! >I know of NO reason for ever making a device spooled, but most system managers >do it anyway. Well, in most if not all of the examples they provide, DEC suggests that this be done. I agree with you--there isn't a whole lot of excuse to spool a device (see caveat below), but you've got to argue with Dr.DEC as well as the misguided system managers. Caveat: some applications have a bad habit of printing by opening a file directly to the line printer device (or equivalent). This is not a great idea, really, but is usually the result of ported, updated, or just plain resurrected old code. Sure, someone should rewrite the old code, but who? Until then, spooled devices *sure are handy*! >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). Sure, I agree. But there are problems. First, you should avoid (like the plague) setting proxys to privileged accounts. Do this by adding explicit proxys to the list in addition to the one wildcard entry. Second, this scheme requires that usernames be the same on all machines. Not impossible, but not real likely, either. Clusters with a common SYSUAF help a lot here. Third, *almost any* privileged user on any node can fake this system out. Once again, we are relying on trustworthy users. >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. The default DECnet account is a useful tool. Yes, it opens up a real can of worms. This may be more than a security minded manaager can accept. But the functionality you lose by removing it is significant. The manager should provide replacement tools. Has anyone considered something like this in the SYS$SYLOGIN procedure: $ if <username> .eqs. <Default DECnet account> - then set command/delete=<anything you consider unsafe> Not totally effective, yet worth a try.