Terminal Servers and Network Security C.E. Bemis and Lynn Hyman December 12, 1990 Network terminal servers provide a very useful function in local area networks and we are most familiar with LAT (Local Area Transport) type terminal servers. Here, LAT refers to a LAN (Local Area Network) protocol developed by Digital Equipment Corporation and now is used by many vendors including Able Communications, Datability, Emulex, Xyplex, Racal-Milgo and others. LAT is designed to efficiently concentrate terminal type traffic on a broadcasting medium like an Ethernet. The protocol does not have a network layer and as such, LAT traffic is local. Some vendors have developed a VAN (Value Added Network) feature for LAT where LAT packets can be routed encapsulated in other routable protocols, IP for example, but the encapsulation is proprietary to that vendor. Cisco Systems, Network Systems and others have developed and used "routable LAT" as a VAN feature. It is noteworthy that the developers of LAT, Digital Equipment Corporation, do not provide "routable LAT" because the protocol was designed to be a Local Protocol to use the Ethernet efficiently with optimal sized data packets up to the Ethernet maximum of 1518 bytes. The value of terminal servers are many and varied: 1. they concentrate terminal traffic for ethernet efficiency, 2. they provide a mechanism referred to as "reverse LAT" where dumb devices like terminals, printers etc. may be attached to the Ethernet via a terminal server, 3. they keep the backplane of computers clean of the many and varied RS-232 type cables and connectors that are required for directly attached dumb devices, 4. they provide a convienent connection for dial in/out modems and 5. network security aspects are quite simple. LAT Servers, either for terminals, printers or whatever, may be partitioned into various "LAT Groups", 255 total, which can serve as a network partitioning mechanism. By default, all LAT terminal servers function in LAT Group 0. Hosts, to which LAT servers are connected over the Ethernet, may be set up to listen to particular LAT Group numbers and ignore all others. LAT Services, host and Server alike, may also use particular LAT Group numbers, for example a print service located off one particular Server port, to partition a network. LAT terminal servers are easily managed, the TSM (Terminal Server Manager) software from DEC is an example, and the LAT devices are easily secured with password access. Passwords for priveleged access, either over the network via LAT, over the network via a Remote Console Connetion (MOPRC), or directly from an attached terminal or other device, should always be set and protected like other priveleged functions that are Password protected. Services defined on a server may also be individually password protected, a password being required for access into or out of a particular port on a server and the password are defined on a service by service, or port by port basis. Network security for servers is a LAN function, inside the broadcasting medium only, because LAT never enters into or out of the local broadcasting network unless a proprietary VAN feature might be implemented. If "routed LAT" has been implemented, it is usually a point-to-point implementation between two routers. Here the security envelope has been extended to the remote location, but not to the entire WAN, only to those routers from a specific vendor that participate in that set up of "routed LAT". Fairly recent changes in terminal servers have occured and the complexity of the network security aspects has increased which may pose some unrecognized risks. Terminal servers are now offered that communicate over X.25 networks via modems as well as communicating on an ethernet; terminal servers are now offered that communicate via the TCP/IP suite thus offering a Telnet server. TCP/IP may be a part of the server in addition to LAT, and/or in addition to X.25 access, all in addition to the connection to the local ethernet or LAN. It is easy to see that the security envelope has been extended to the WAN, at least as far as the X.25 network will reach, and as far as the IP network reaches. The very nature of a terminal server, without an operating system like a computer and without elaborate mechanisms to limit, audit and otherwise provide a secure environment, is the reason for additional concern. Terminal servers, multiprotocol servers, are a favorite stepping stone for would be hackers and crackers because they provide no audit trail. Once on a server, your packets can then go anywhere that the multiprotocol functions will let them. For LAT, this is local, for IP, this is anywhere IP can take them, LAN or WAN and, similarly for X.25/X.129. Multiprotocol terminal servers have been implicated in many of the recent well publicised hacker/cracker episodes and they continue to pose risks-- unless they are properly protected!! Of particular interest is the "firewall" protected network where a router/gateway would separate the WAN from the local (LAN) environment. This arrangement is most useful for the control of WAN routing messages which would never then enter the LAN environment, and for control of WAN traffic by providing filter mechanisms. Such filters might be based on network addresses, IP or DECnet, by protocol or IP port/server, or on other flags in incoming/outgoing packets. Usually, such filter mechanisms are inclusive, rather than exclusive, where everything is allowed except those specifically identified and filtered. Exclusive filtering is network management intensive and unless the situation, usually a paranoid one, warrants it, exclusive filtering is not widely used. The massive application of inclusive filtering is usually not performed either in an unclassified network environment and protection is usually a host based function. Terminal servers of the multiprotocol type may easily defeat the most carefully designed network implementation and "firewall" implementations!! Suppose you have LAT hosts not permitted by any routable protocol to communicate to any WAN host and your network design and possibly "firewall" inclusive filtering would prevent it. A bypass, where incoming/outgoing traffic, in a step-stone fashion via your multiprotocol terminal server can defeat your implementation. An outsider, otherwise not permitted to communicate via any mechanism with certain of your internal hosts may simply set up a session on a multiprotocol server, usually not protected like full function computers, and complete the connection. What to do ?-- Network access, in contrast to direct physical Port based access, must be protected on multiprotocol terminal servers!! Usually, IP terminal servers implement a "virtual" Telnet server on virtual port 2048. I have seen this implementation on two different vendors servers. This feature is usually not even noticed by the installer. Once on the server via a Telnet connect to "virtual port" 2048, a user may enter the default access password and gain access to all the services and connections that any non-priv'd direct user of the server would normally have access to. In some cases, on servers that I have noticed, network access may even allow priv'd access just by using the default. Audit features/trails are not possible, security and network implementations are bypassed. Use the mechanisms inherent on each of the various manufacturers multiprotocol servers, and the mechanisms are different on each manufacturers server, to Password protect the server from network access. Certain manufacturers servers, depending on the software revision level, offer no protection at all!!! Seriously consider restricting multi-protocol terminal servers from any WAN access if the need for direct WAN access is not needed. Why use a terminal server when a REAL host can be used with all the bells and whistles like a real operating system, audit trails, security features etc. WAN restrictions on multi-protocol terminal servers may be accomplished by an IP address filter on a site firewall router. Some servers may allow the use of IP address masks directly on the server. Servers may also be configured without any default metwork gateway being defined which would then allow the server to only be used in its own broadcasting environment. In this case, the server has no knowledge, nor can it "learn", anything about routes to hosts not part of its broadcasting domain. Last corrected/modified by C.E. Bemis, Jr., 12/7/89@8:00AM EDT ESnet/DECnet Security Revised Draft, 12/89 page i GA-A19829(revised) ESNET/DECNET SECURITY POLICY, PROCEDURES AND GUIDELINES by * D.T. CARUSO and C. E. BEMIS, JR. This is a preprint of a document presented at the ESnet/DECnet Working Group Meeting (EDWG), held at the Stanford Linear Accelerator Center, Stanford, CA, on September 7-8, 1989 GENERAL ATOMICS PROJECT 3468 SEPTEMBER 1989 Work supported by U.S. Department of Energy Contracts DE-AC03-89ER53277 and DE-AC05-84OR21400 *Oak Ridge National Laboratory, Oak Ridge, Tennessee Caruso & Bemis ESNET/DECNET SECURITY POLICY, PROCEDURES AND GUIDELINES Version 1.0, September 11, 1989 ESnet/DECnet Security Revised Draft, 12/89 page ii Status This document, ESnet/DECnet Security Policy, Procedures and Guidelines, is an assemblage of separate documents related to these topics which have been discussed and collected by the Energy Sciences Network (ESnet), DECnet Working Group (EDWG) since the formation of the EDWG in March 1988. Network security in the ESnet, and in associated interconnected networks, has been a topic of importance to the EDWG since its inception. As is usually the case with documents such as this one, no person wishes to write it, nor edit it, nor incorporate the many different opinions, thoughts and approaches that may be used. This document is therefore a collection of written material, mostly by the EDWG membership and, it incorporates those aspects related to security and policy from a draft of the ESnet Policy Document. A written document describing the security policy and suggestions for network security is of importance to the ESnet. To fill a void in the ESnet, particularly the DECnet portion of the ESnet, we offer this draft document as a positive constructive step to assure that the Energy Sciences Network is used and maintained for its intended purposes, ie. the conduct of scientific research. ESnet/DECnet Security Revised Draft, 12/89 page iii ESnet/DECnet Security Policy, Procedures and Guidelines D.T. Caruso and C. E. Bemis, Jr. Abstract This paper presents a draft of a proposed ESnet-DECnet security manual which outlines policy and procedures as they relate to DECnet security, identifies and discusses contemporary DECnet security issues and, includes guidelines and outlines measures that may be used to improve DECnet security posture. ______________________________ This is a report of work sponsored by the U.S. Department of Energy under Contract Nos. DE-AC03-89ER53277 and DE-AC05-84OR21400. ESnet/DECnet Security Revised Draft, 12/89 page iv Contents Status....................................................... ii Abstract..................................................... iii I. Energy Sciences Network Introduction........................ 1 I.A.Description and Overview.............................. 1 I.B. Purposes and Goals................................... 1 I.C. Access Policy and Control............................ 2 II. ESnet Security Policy and Statements....................... 3 II.A. Security Policy and Procedures...................... 3 II.B. Penalties for Network Abuse......................... 3 II.C. ESnet/DECnet Policy................................. 3 II.C.1. Site Responsibility.......................... 3 II.C.2. End-Node Responsibility...................... 3 II.C.3. Security Problem Structure................... 4 III. ESnet Security Procedures................................. 6 III.A. Distribution of Security Related Information ...... 6 III.A.1. DEC's Patch Distribution Procedures......... 6 III.A.2. Proposed Method of Patch Distribution....... 6 III.B. Network Security Procedures........................ 7 III.C. Security Breach Procedures......................... 8 III.C.1. Unsuccessful Break-in Attempt............... 8 III.C.2. Successful Break-in Attempt................. 9 IV. Bibliography/References................................ 10 Appendix A: EDWG Roster....................................... 11 Appendix B: Networking Ethics (CCIRN)......................... 14 Appendix C: End Node Network Security Measures................ 16 ESnet/DECnet Security Revised Draft, 12/89 page 1 I. Energy Sciences Network Introduction I.A. Description and Overview The DOE/OER wide-area computer network called the Energy Sciences Network (ESnet) is an "umbrella" network backbone to support the many and varied wide-area computer network needs of the activities supported by the Office of Energy Research (OER). One portion of the ESnet is a large DECnet network and it now incorporates the original DECnet network, often referred to as HEPnet or PHYSnet, originated by the High Energy Physics program. Other OER programs now participate in the DECnet portion of the ESnet and it includes nodes from Nuclear Physics (NP), Basic Energy Sciences (BES), Magnetic Fusion Energy (MFE), and others. The extended DECnet network reaches about 30,000 nodes worldwide as it co-exists with other large DECnet entities which include, among many others, NASA's Space Physics and Analysis Network (SPAN). The DECnet network reaches all DOE National Laboratories in some form, although perhaps not to all computer nodes at each site, and it includes many U.S. and foreign university sites and facilities. The Energy Research DECnet Working Group (EDWG) is composed of technical representatives from various sites which will participate in the initial ESnet implementation. The role of the EDWG is to provide a forum for the discussion and solution of the DECnet technical problems and DECnet issues relating to the migration and implementation of the ESnet backbone and site connections. The EDWG membership roster, circa September 1989,is listed in Appendix A. I.B. Network Purposes and Goals The ESnet is a computer data communications network managed and funded by the Department of Energy Office of Energy Research (DOE/OER) for the purpose of supporting multiple program, open scientific research. ESnet is intended to facilitate access to energy research (ER) scientific facilities and distributed ER computational resources, provide needed information dissemination among scientific collaborators throughout all ER programs, and to provide widespread access to existing supercomputer facilities. ESnet is not available for use by the general public, nor is it intended to compete with comparable commercial network services. Usage of ESnet shall not violate privacy or other applicable laws. The network shall not be used for advertising or other promotional purposes without the express permission of the OER Scientific Computing Office. Network and computer ethics must be adhered to by all associated network members. Appendix B is a recommendation of policy by the Coordination Committee for Intercontinental Research Networking that must be understood by all networking personnel and systems users. ESnet/DECnet Security Revised Draft, 12/89 page 2 I.C. Access Policy and Control It is the responsibility of the ESnet Steering Committee (ESSC) and the ESnet implementors to ensure that the use of ESnet by any individual researcher is accomplished in a manner which does not unduly affect other network users. Any restriction for use of the network contained herein is intended to protect this ER resource for its intended use. ESnet policy is guided by the ESnet Steering Committee, appointed by the DOE Office of Scientific Computing, with representatives from each of the Energy Research Programs. For the purpose of the establishment of ESnet policy, network traffic is categorized into various classes as follows: CLASS 1: Traffic generated by usage in support of ER programs. Network activity related to U.S. DOE/Office of Energy Research supported programs constitutes authorized use of ESnet and is considered to be Class 1 usage. CLASS 2: Traffic generated by usage in support of either DOE non-ER programs or DOE authorized work for others. Network activity related to DOE activities, including work for others, but not included in Class 1 usage is considered to be Class 2 usage. CLASS 3: Traffic generated by all other usage. ESnet will provide additional connectivity through interagency gateways and will participate in the evolution of the National Research Network. This is an example of allowed Class 3 usage. Access to ESnet for Class 1 usage may be authorized by the ESnet Site Coordinating Committee member for that site. Access for usage of ESnet that will adversely affect the network may be denied, even though the application would constitute legitimate usage as defined heretofore. Requests for access that will require new physical facilities or will significantly impact existing network facilities should be made to the ESnet Steering Committee member representing that program. The Steering Committee will prioritize all such requests, and forward their recommendations to the OER/SCS. Access to ESnet for Class 2 and 3 usage shall be authorized by the OER/SCS. ESnet/DECnet Security Revised Draft, 12/89 page 3 II. ESnet Security Policy and Statements II.A. ESnet Policy and Procedures The ESnet POLICY AND PROCEDURES, Draft 2.1 dated September 2,1988 and subsequent revisions, will be adhered to in its entirety. A copy of the current ESnet POLICY AND PROCEDURES can be obtained from the U.S. DOE, Office of Energy Research, Scientific Computing Staff (OER/SCS), from the Energy Sciences ESnet Steering Committee (Esnet ESSC), or from the ESnet implementors at Lawrence Livermore National Laboratory, Livermore, California. II.B. Penalties for Network Abuse Persons who abuse or misuse government networks or, who use government computing resources without authorization, may be prosecuted. Hosts/nodes or sites that, either knowingly or through negligence, permit this type of usage may be disconnected from the network. II.C. ESnet/DECnet Policy II.C.1. Site Responsibility Each site will be responsible for all systems and nodes accessing the network from their facility. This includes systems and end nodes that have direct or indirect network access. Questionable activities originating from any of the facilities' systems or end nodes can result in disconnection of the entire facility from the network. Therefore, it is imperative that appropriate network monitoring, auditing, and security measures be implemented at the site on all systems and end nodes. II.C.2. End Node Responsibility The network is NOT responsible for implementing nor enhancing end-node security. Although the network will provide access to a much wider user base, the network is not responsible for any additional end-node security which may be required in this environment. The network will be responsible for providing reasonable tools and capabilities to allow the network operations staff to aid end-nodes during periods of access intrusion. ESnet/DECnet Security Revised Draft, 12/89 page 4 A network is only as secure as its least secure node. Therefore, any end-node or computer that does not conform to ESnet's security measures will be considered for disconnection from the network if security policies and procedures are considered inadequate. This disconnection policy will also hold true for those network nodes that are not DOE/OER administered. Network Security: The network is recognized as a costly resource that must be protected from unauthorized usage. Access to network control and operation functions must be protected to allow use only by authorized users. This includes, but is not limited to, network routing nodes and hosts, network name and file servers, network communication equipment, and communication lines. End-node administrators are responsible for ensuring that network access and usage allowed through that end-node meet the constraints and requirements of this document. Any suspicious network activity, believed to be hostile or not, must be reported, especially if the suspicious activity is in progress. II.C.3. Security Problem Structure Unacceptable network behavior can range from obvious security violations (e.g. password guessing, worm/virus planting, etc.) to "harmless" perusing of files/directories a network user is not explicitly authorized to access. Some of the more obvious network violations can be summarized as follows: Use of network task-to-task DECnet procedures to perform operations on a remote node/host where a network user has not been given permission to access that remote node. Often, a remote node may allow "default access" which may bypass access control mechanisms for various types of DECnet network connections. Most often, network abuse occurs via automated DCL procedures copied to a remote node/host and then executed over the network. A variety of these automated DCL and other procedures, primary tools used by hacker/crackers in DECnet networks, have been seen such as TELL and NETDCL. The introduction of software that is intended to steal system files or passwords, modify the operating system and operating characteristics, or to do damage to the system structure. Scavenging and hunting system or user disk areas for information. Using a network node as a gateway without authority. ESnet/DECnet Security Revised Draft, 12/89 page 5 Introduction of "worm or trojan horse" software to gain access to privileged accounts or systems. Modifying or creating system or UAF files and records. Disruptive network use, authorized or unauthorized, which results in denial of service or access by authorized ESnet users and sites attempting to conduct and perform normally permitted networking functions. Modification or alteration of network control or monitoring parameters, routing algorithms and software, and modification of network hardware, communication lines, etc., without authorization. Global probing of the ESnet structure via automated NCP or DCL procedures to survey the networks, network nodes and network paths. In general, unacceptable network behavior is simply, unauthorized use of network and network computing resources. Just because a node or host, local or remote, may be attached to the ESnet networking infrastructure, it does not imply open trusted access to any network user not otherwise authorized, to use or abuse that network resource. ESnet/DECnet Security Revised Draft, 12/89 page 6 III. ESnet/DECnet Security Procedures III.A. Distribution of Security Related Information III.A.1. Digital Equipment Corporation's Patch Distribution Procedures Digital Equipment Corporation (DEC) has in the past become aware of potential problems in DEC supplied software, which includes the VMS operating system, DECnet or other layered software, that may affect individual host integrity/security. DEC then will supply a fix or "Patch" to be applied to the operating system or layered software to eliminate the problem. To reduce the problem of "reverse engineering" by an infiltrator or hacker, which is a serious security problem, DEC supplies, by prior arrangement, advance "Patch" information to trusted agencies such as NASA, DOE, DOD and others, along with some corporations. This advance information allows those agencies and corporations time to install the required changes before general world-wide distribution is made by DEC. For the ESnet DECnet, such prior information is deemed ABSOLUTELY ESSENTIAL because of the ESnet's exposure to the entire world, as is usually the case in open unclassified research networks like NASA's SPAN, DOE's ESnet, and the Internet (DDN and the NSF regionals). These are the very hosts that are most deserving of this information, not to the exclusion of hosts that do process classified information. DOE does receive this advance "Patch" information but the extended bureaucracy, and the "sensitive" nature of this advance information, often means that DOE computing resources that are non sensitive and unclassified and, may participate in wide-area networks, do not get this needed advance information until DEC makes its general release. This is an untenable situation and DOE computing resources are incurring unnecessary risk. III.A.2. Proposed Method of Patch Distribution The EDWG has worked out a scheme by which advance information may be distributed in a "semi-secure" fashion to those approved sites on the ESnet/DECnet. Upon receipt of such advance information, from Digital Equipment Corporation to the Department of Energy, the information required to make the necessary Patch, but without the descriptive material indicating the particular weakness or vulnerability, would be encrypted using a software implementation of the NBS-DES algorithm. The algorithm is symmetric and the same KEY is used to crypt and decrypt messages. Encrypted messages are transformed into hexadecimal equivalents suitable for inclusion into normal Mail messages which then may be transmitted over the ESnet structure. The KEY is secure and the ability to de-crypt is an authenticator. ESnet/DECnet Security Revised Draft, 12/89 page 7 A Utility to perform the DES encryption/hexadecimal conversion and File record manipulation, and the inverse, has been developed and tested and found suitable for these purposes. The utilities are operating system independant and are encoded in the C Source language. A method to distribute KEYs, similar to that for the distribution of generated Passwords in non-sensitive unclassified environments, has also been developed. The overall method described here is similar to that used by large financial institutions for the network transmission of financial information. Permission to use this technique in the DOE unclassified environment has not been obtained at this time (12/89), nor have any changes in the current DOE procedures been made. III.B. Site Network Security Procedures Appendix C contains a list of measures that should be incorporated into the ESnet/ DECnet site (end node) procedures and will provide enhanced security and monitoring. Recommendations for protection against infiltration and/or abuse should also include any local end node security measures. Local site specific protection includes but is not limited to: Password generation and password expiration procedures, User, network and system auditing and monitoring procedures, and System and user backup procedures The recommendations may assist the system manager of a DECnet node that participates in a wide-area network. Nodes outside the LAN are not subject to the usual kinds of ``Management Controls'' in place for local nodes, which could cause some difficulty. The wide-area network might include, for example, an outside node where all users on that node have elevated privileges. Wide-area networks pose some special concerns as individual nodes may come under attack by hackers. In such cases, the site system manager will be required to be aware of some of the methods that hackers use to gain access, and of the methods of protecting the nodes and detecting unauthorized access attempts. ESnet/DECnet Security Revised Draft, 12/89 page 8 III.C. Security Breach Procedures Network security breaches can be summarized as two distinct possibilities: unsuccessful break-in or, successful break-in attempts. The two break-in situations will require the responsible site personnel to take immediate actions on the successful or unsuccessful breach. If you feel that your node is being tweaked, probed or that someone is attempting to access your system in a manner that concerns you, DO NOT ATTEMPT to contact that User on the remote node yourself!!! The established procedure is for you to contact the local Computer Security manager and give him the details. He will contact the appropriate network representative, ESnet site coordinator, ESnet implementers, or DECnet area manager and give details. They might use the utility NCP to deny any further access to the local network from the remote node until the matter is cleared up. In the wide-area network, there are ``Area Managers'' that handle such matters and they will investigate the infraction. If you attempt to do it yourself, for example by sending Mail to SYSTEM on that remote node, it very well might be the Manager of that remote node that is the culprit of the infraction. Use the internal method of reporting and the established mechanisms already in place. Access attempts and ``break-ins'' over the wide-area network are Federal Crimes and will be investigated if sufficiently serious. In most cases, the remote user is contacted by the appropriate representatives at the remote site and such activity ceases. The remote user is sufficiently embarrassed by the event, and, learns that such activity is not allowed. The measures to be taken during the course of a break-in will be coordinated and directed by the local Security Administrator. A site system manager might be ablet to ``capture'' transactions using ``peek'' or ``observe'' type programs to assist these efforts. The following two sections summarize the procedures that will be followed by all participants: III.C.1. Unsuccessful Breach Attempt If it has been established through monitoring methods or logs, that an unsuccessful break-in attempt was made, gather all logs, user and network information. If the network source of the node has been established, enable auditing to provide more information in the event the intruder succeeds in logging into the local node. Contact the local Computer Security Administrator and be prepared to provide details. The local Computer Security Administrator will contact the appropriate network representative to investigate the infraction. The Administrator will also contact you on the course of action to be taken locally and remotely. Types of actions that may be taken include taking preventative measures on the remote node, by including or excluding the source node from DECnet and SYSUAF records. ESnet/DECnet Security Revised Draft, 12/89 page 9 III.C.2. Successful Breach Attempt If it has been established through monitoring methods that a successful break-in by an unauthorized user has been made, begin by monitoring the users' process and any files that may be opened for user access. Audit logs and accounting data should be protected and preserved for later detailed examination as this informaiton may be used in legal proceedings. Also try to establish and log the network source of the infiltrating user's network point-of-origin using NCP and any local network software that may be available. Contact the local Computer Security Administrator and be prepared to provide details. The local Computer Security Administrator will contact the appropriate network representative to investigate the infraction. The Administrator will also contact you on the course of action to be taken locally and remotely. ESnet/DECnet Security Revised Draft, 12/89 page 10 IV. Bibliography/References Various sources were accumulated for information required to create this document. VAX/VMS security and network security information and guidelines are contained in DEC's ``Guide to VAX/VMS System Security,'' which is part of the VAX/VMS document set. The VAX/VMS document set for VMS Version 5.2, in particular, has more extensive security information than previous versions. Also of particular interest are ``SPAN Network Security Guide,'' written for NASA's SPAN network, and ``Recommendations for Security Policy for All Networked Computers at LBL,'' LBL-23303, dated April 1987. The various implementations that are suggested in these documents are not necessarily recommended for our particular network setup, but the discussions in these documents can provide some insight. Other sources have included an article, originally written by C.E. Bemis, called ``Recommendations for DECnet Node Security.'' This is a report of work supported by the U.S. Department of Energy under Contract Nos. DE-AC03-89ER53277 and DE-AC05-84OR21400. ESnet/DECnet Security Revised Draft, 12/89 page 11 Appendix A: EDWG Roster EDWG Members Curtis E. Bemis, Jr. Senior Research Staff Physics Division, Bldg. 6000, MS-6371 Oak Ridge National Laboratory P.O. Box 2008 Oak Ridge, TN 37831-6371 (615) 574-4769, ORPH01::BEMIS or BEMIS@ORPH01.BITNET David Caruso System Analyst General Atomics P.O. Box 85608, MS 15/003A San Diego, CA 92138-5608 (619) 455-3659, SDSC::CARUSOD Philip DeMar Network Analyst Fermilab P.O. 500, M.S. 120 Batavia, IL 60510 (312) 840-3678, DEMAR@FNAL.BITNET Charles Granieri Computer Systems Specialist Stanford Linear Accelerator Center 2575 Sand Hill Road Mail Bin 97 Menlo Park, CA 94025 (415) 926-2844, CXG@SLACVM.BITNET Darren Griffiths Staff Scientist Mail Stop 50F Lawrence Berkeley Labs Berkeley, CA 94720 (415) 486-6966, DAGG@LBL.GOV Douglas Lee, System Manager Supercomputer Computations Research Institute Florida State University 400 Science Center Library Tallahassee, FL 32306-4052 (904) 644-4275, SCRI::DOUG or DOUG@SCRI1.SCRI.FSU.EDU ESnet/DECnet Security Revised Draft, 12/89 page 12 Frank Lepera Computer Analyst Computing and Communications Division Brookhaven National Laboratory Upton, NY 11973 (516) 282-4183, HEPNET (BNLCL1::FLEP) BITNET (FLEP@BNLCL1) Alan B. Macmahon Research Project Manager Fusion Research Center 11.222 RLM Hall University of Texas Austin, TX 78712 (512) 471-3182, MACMAHON@FUSION.PH.UTEXAS.EDU, MACMAHON@UTADNX(BITNET) Robert J. McMahon Computer Scientist Argonne National Laboratory 9700 South Cass Ave. Argonne, IL 60439 (312) 972-7270, B17385@ANLVM.BITNET Don Nelson MIT Plasma Fusion Center 175 Albany Street, NW17-248 Cambridge, MA 02139 (617) 253-7616, NELSON@mitpfC.HEPNET (Node 43.358,44390) R. Kevin Oberman Engineering Network Manager Lawrence Livermore National Laboratory P.O. Box 808, L-156 Livermore, CA 94550 (415) 422-6955, OBERMAN@ICDC.LLNL.GOV Steve E. Turpin MS B255, C-5 Los Alamos National Laboratory Los Alamos, NM 87545 (505) 667-0750, STEVE\ BETA@LANL.GOV ESnet/DECnet Security Revised Draft, 12/89 page 13 EDWG Liaison Members Tony Hain (EDWG liaison from NMFECC) Associate Network Manager ESnet / NMFECC P.O. Box 5509, L-561 Livermore, CA 94550 (415) 422-4200, HAIN@NMFECC.ARPA Denise Heagerty (EDWG liaison from CERN) DECnet Coordinator, CERN DD Division, CERN CH-1211 Geneve 23, Switzerland Tel: +41 (022) 83 49 75; Fax: +41 (022) 83 71 55; Telex: 419000 CER CH EAN: DENISE@PRIAM.CERN UUCP:CERNVAX!DENISE EARN: DENISE@CERNVAXDECnet: VXCERN::DENISE (22718::DENISE) ARPA: DENISE@PRIAM.CERN.CH; JANET: DENISE\ CERN.PRIAM@UK.AC.EAN-RELAY Dave Peters (EDWG liaison from SPAN) SPAN Internet Manager NASA/Goddard Space Flight Center Code 630.2 NASA/GSFC Greenbelt, MD 20771 (301) 286-2990, NSSDCA::PETERS, PETERS@NSSDCA.GSFC.NASA.GOV Linda Porter (EDWG liaison from SPAN) SPAN/Marshall Routing Center Manager Code ES01 NASA/Marshall Space Flight Center Huntsville, AL 35812 (205) 544-7588 FTS 824-7588; SSL::PORTERL (SSL is node 7.39) Lester Welch (EDWG liaison from DOE/SCS) DOE/SCS (Scientific Computing Staff) Department of Energy, ER-7 Washington, DC 20545 (301) 353-5800, ANLPHY::WELCH or WELCH@ANLPHY.BITNET} ESnet/DECnet Security Revised Draft, 12/89 page 14 Appendix B: Networking Ethics (CCIRN, April 1989) Status of this Memo This memo is a recommendation of policy by the Co-ordination Committee for Intercontinental Research Networking (CCIRN) concerning the proper use of resources in research networks (referred to as `the networks'). At great human and economic cost, resources drawn from government, industry and the academic community have been assembled into a global collection of interconnected networks. The networks have become an important international infrastructure supporting an increasingly widespread, multi-disciplinary community of researchers ranging, inter alia, from computer scientists and electrical engineers to mathematicians, physicists, medical researchers, chemists, astronomers and space scientists. As is true of other common infrastructures (e.g. roads, water reservoirs and delivery systems, and the power generation and distribution network), there is widespread dependence on the networks by its users for the support of day-to-day research activities. The reliable operation of the networks and the responsible use of their resources is of common interest and concern for their users, operators and sponsors. Recent events involving the hosts on the networks underscore the need to reiterate the professional responsibility every user bears to colleagues and to the sponsors of the system. Many of the resources are provided by government; abuse of the system thus becomes a legal matter above and beyond simple professional ethics. Statement of Policy The networks form an international facility whose utility is largely a consequence of its wide availability and accessibility. Irresponsible use of this critical resource poses an enormous threat to its continued availability to the technical community. The governments sponsoring these systems have a responsibility to the public to allocate government resources wisely and effectively. Justification for the support of these systems suffers when highly disruptive abuses occur. Access to and use of the networks is a privilege and should be treated as such by all users of these systems. ESnet/DECnet Security Revised Draft, 12/89 page 15 The CCIRN strongly endorses the following as unethical and unacceptable. Any activity which purposely: (a) Seeks to gain unauthorized access to the resources of the networks, (b) Disrupts the intended use of the networks, (c) Wastes resources (people, capacity, computer) through such actions, (d) Destroys the integrity of computer-based information, and/or (e) Compromises the privacy of users. The networks exist in the general research milieu. Portions of them continue to be used to support research and experimentation on networking. Because experimentation on the networks has the potential to affect all of their components and users, researchers have the responsibility to exercise great caution in the conduct of their work. Negligence in the conduct of such experiments is both irresponsible and unacceptable. The CCIRN plans to initiate whatever actions it can, through the appropriate agencies and other interested parties, to identify and to have set up technical and procedural mechanisms to make the networks more resistant to disruption. Such security, however, may be extremely expensive and may be counterproductive if it inhibits the free flow of information which makes the networks so valuable. In the final analysis, the health and well-being of the networks is the responsibility of its users who must, uniformly, guard against abuses which disrupt the system and threaten its long-term viability. Acknowledgement This statement was developed from one prepared by the Internet Activities Board which in turn followed from work undertaken by the Division Advisory Panel of the National Science Foundation Division of Networking and Communications Research and Infrastructure. ESnet/DECnet Security Revised Draft, 12/89 page 16 Appendix C: End Node Network Security Measures End Node Network Security Measures The following are recommendations for increasing the security methods and monitoring for ESnet/ DECnet nodes. 1. Create a more secure DECnet account by modifying the default DECnet account parameters using the following: A. Run AUTHORIZE UAF> Modify DECNET/PASSWORD= (make it non-trivial) B. Run NCP, ie. $ mcr ncp, or $ Run Sys$System:ncp NCP> SET EXECUTOR NONPRIV USER DECNET - PASSWORD xxxxxx (where xxxxxx is the same as in step 1.) NCP> DEFINE EXEC NONPRIV USER DECNET - PASSWORD xxxxxx NCP> SET OBJECT FAL USER zzzzzz PASSWORD zzzzzz NCP> DEFINE OBJECT FAL USER zzzzzz PASSWORD zzzzzz (Here, zzzzzz is anything that you choose it to be since it makes absolutely no difference) NCP> SET OBJECT TASK USER zzzzzz PASSWORD zzzzzz NCP> DEFINE OBJECT TASK USER zzzzzz PASSWORD zzzzzz (You must be sure that zzzzzz does NOT have an entry in your SYSUAF.DAT!!!! Do not create an account for User zzzzzz !!!!!) 2. Use DECnet proxy access to allow/ disallow remote node entry into the local node by using the following: $ RUN SYS$SYSTEM:AUTHORIZE (with SYSPRV) UAF> add/proxy REMOTE::* * (REMOTE is nodename of remote) UAF> sho/proxy *::* ---output--- UAF> exit DECnet proxy access SHOULD NOT be allowed for any user on any remote node not under your control. A remote user with the CMKRNL privilege on any particular remote node with DECnet proxy can get access to your node thereby compromising your network security. ESnet/DECnet Security Revised Draft, 12/89 page 17 3. Disable Poor Man's Routing (PMR), and enable logging of all network logins through FAL by defining FAL$LOG. This will isolate an internal network from the outside world where internal nodes, that are otherwise unreachable on the network can be accessed thru your node (e.g. SET HOST yournode::othernode). Mail will work however, but FAL, NML, etc., will not. An example of disabling PMR: $DEFINE/SYS/EXEC FAL$LOG "1/DISABLE=8". (A complete description of the entire FAL$LOG mechanisms that may provide additional security may be obtained from Digital Equipment Corporation. Some descriptive information is given in Appendix D) 4. Install VMS with the SECUREUSER environment. This establishes user accounts with passwords. It will also enable accounting measures and mechanisms that will allow the tracing, logging, and auditing of system and user activities on the local nodes. In conjunction with the accounting mechanism, the OPERATOR process should be enabled to allow auditing. In the system startup procedures, use SET AUDIT to Alarm for Log Failure, both Interactive and Network, access to SYSUAF.DAT and any other sensitive system file. Security Alarms will be written to OPERATOR.LOG and may be processed with the SECAUDIT.COM in the System Manager's Account. This will provide informational records to allow the tracing and monitoring of local and remote access. The records in ACCOUNTING have similar, but not all of the Security Alarm information. Accounting may not be practical to implement on a single user Vaxstation, for example, but then it might be practical to ask if that particular Vaxstation absolutely needs direct access to the outside network rather than access thru a local, centrally managed node with the appropriate resources. ESnet/DECnet Security Revised Draft, 12/89 page 18 5. Set up file protections with ACLs, Access Control Lists on sensitive files. Files to be restricted to local access only and not available to network access can be controlled with ACLs. As an example, a file with the name NET_ACL.EXM, can be created with a ACL using the Identifier REMOTE. This Identifier is automatically attached to a process by the system when a network connection has been made to your node. The ACE will then restrict the file or any file from NETWORK access. The following commands will set up the ACL: $ SET FILE/ACL=(IDENTIFIER=REMOTE,ACCESS=NONE,OPTIONS=PROTECTED) NET_ACL.EXM It may be ``copied'' to another File via $ SET FILE/ACL/LIKE=NET_ACL.EXM YourFile.Ext The ACE restricts any file access from NETWORK access via the Identifier `REMOTE'. This ACE is useful to limit NETWORK terminal sessions to 1 if it is put on SYS$SYSTEM:RTPAD.EXE. If a User has logged into your machine over the Network, (via SET HOST Yournode), the ACE on RTPAD.EXE will not let the User do a SET HOST from Yournode. This will keep your node ``free'' from the additional network overhead of having to process all the `Terminal Stuff' in `pass-thru' mode. It could be of value on CI type clustered machines where not all software is available on all clustered nodes. Users who have logged on to one node over the network may just do an additional SET HOST in the absence of this ACL. This would force them to log out first. The ACL on RTPAD may also may be a Security implementation where a node can only be reached in the interactive sense via a succession of SET HOSTs. 6. Use the undocumented VMS Utility CHECKSUM (DCL Verb CHECKSUM) that is normally used during software (VMSINSTAL) operations. CHECKSUM reads a file and calculates a 32 bit checksum. The Qualifier, /IMAGE, is used for .EXE type files and the default Qualifier, /FILE, is used for all others. The following is an example use of CHECKSUM: $ CHECKSUM filename (or CHECKSUM/IMAGE filename for .EXEs) $ SHOW SYMBOL CHECKSUM$CHECKSUM Along with the ANALYZE Utility (ANALYZE/IMAGE), these can provide the System Manager with sufficient input to verify node integrity. An example for use would be an automated procedure run every night, or week, to compare the CHECKSUM of files in SYS$SYSTEM or any other sensitive area to verify the integrity of files. Note: the file SYS$SYSTEM:SYSUAF.DAT is not directly amenable to the CHECKSUM verification technique because the file is updated with time stamps and other items on access. All processes use SYSUAF.DAT for access control information. SYSUAF modifications may be easily verified with indirect methods including the AUDIT feature. ESnet/DECnet Security Revised Draft, 12/89 page 19 7. If necessary, selectively block access to the local node from any remote node that is defined in the locally defined database. If, for example, users on remote node HAXVAX (defined DECnet database) continually probe over the network, access of any kind from HAXVAX (MAIL, PHONE, etc.) can be denied using: NCP> SET (and/or DEFINE) NODE HAXVAX ADDRESS 12.345 ACCESS NONE Implementing this type of restriction should be done carefully as the DECnet functionality in the network can be disabled, especially if your node is a Router, for example, as the local node will longer perform the DECnet Routing function for HAXVAX. 8. Another method for restricting access from incoming nodes is to include in the system login procedure (SYLOGIN), checks for valid nodenames that will deny access to all but certain trusted remote nodes. In order for this method to work, SYS$SYLOGIN must be defined in the system logical name table and, the flag DISCTLY (disable the use of Control Y aborting) must be added to all accounts in SYSUAF. The following is a sample of this procedure: $ VERIFY_FLAG = 'F$VERIFY("NO")' $ SET NOON $ MODEVAX = F$MODE() $ NODE = F$TRNLNM("SYS$NODE")-"::" $ REMNODE=F$TRNLNM("SYS$REM_NODE")-"::" $ REMID=F$TRNLNM("SYS$REM_ID") $ IF MODEVAX .EQS. "NETWORK" THEN GOTO CHKNOD $ IF REMID .EQS. "" THEN GOTO NODEOK $ CHKNOD: $ IF REMNODE .NES. "" THEN GOTO CHKNAM $ IF F$GETJPI("","PRCNAM") .EQS. "EVL" THEN GOTO NODEOK $ CHKNAM: $ IF REMNODE .EQS. "node_name_with_access" THEN GOTO NODEOK $ IF REMNODE .EQS. "node_name_with_access" THEN GOTO NODEOK $ IF REMNODE .EQS. "node_name_with_access" THEN GOTO NODEOK $ IF REMNODE .EQS. "node_name_with_access" THEN GOTO NODEOK $ REQUEST "*ILLEGAL ACCESS FROM NODE -''REMNODE'::''REMID'*" $ STOP/ID=0 $ NODEOK: $ IF F$ENVIRONMENT("CAPTIVE") THEN EXIT $ SET CONTROL=Y ESnet/DECnet Security Revised Draft, 12/89 page 20 9. Regularly check your node's network activity via the NCP command utility. You may check current active links via the NCP command, SHO KNOWN LINKS. Network links showing the process CTERM are local users who have invoked a network virtual terminal process to a remote node (ie. SET HOST remote). The process REMACP is the process that remote users invoke when they have done a network terminal connection to the local node. The SHO KNOWN LINKS command will show the Remote Node Name (if defined in your Tables), the remote node DECnet address, the UserName on the Remote node, the PID on the Remote, and similar info on the corresponding process on your local node. NCP will also allow the system manager to sever any connection, using: NCP> DISCONNECT LINK xxxxxxx (where xxxxxxx is the identifying Link number from the SHO KNOWN LINKS command). 10. Regularly check the [DECNET] account and the NETSERVER.LOGs. If the DECNET Account has been given a non-trivial password, all MAIL, PHONE, NML connects will be logged in the NETSERVER.LOGs. Other files should not exist in the DECNET Account unless the password has been given out or compromised. Individual users will also have NETSERVER.LOGs in their SYS$LOGIN area which details activity over the network to their account. Since the logical FAL$LOG is defined as a system logical on your node, all file access is detailed in that particular user's NETSERVER.LOGs. 11. Disable default VMS accounts, including Field and Systest. Other Accounts to be checked and disabled if present are USER and USERP, which were included as part of the VMS operating system in some earlier versions and these may have carried over to your current version. With the Authorize utility, a copy of the System account should be made to another account name, thus keeping the account intact with its default privileges and quotas. This new account will be used for all system functions. Although no OPER account is included with the default accounts provided with VMS, it is a very common account on VAX nodes and should also be disabled. In general, any account that you don't understand, know about or what the account is used for, especially those with elevated privileges, should be DISUSER'd and/or removed. There are several helpful Utility programs that may be used to assist the SysMgr in the examination of SYSUAF information for these purposes. 12. File protections schemes should used on system files and other crucial files in order to invoke security alarms if unauthorized users attempt to view or modify the file. These include File Protections and ACLs used together with SET AUDIT. ESnet/DECnet Security Revised Draft, 12/89 page 21 13. Educate the local users of their responsibility to not ``probe'' over the network. Hacker tools such things as NETDCL, TELL, etc., are primarily for infiltration of network nodes, and if they are found in any outside nodes default network account, it could be cause for a security investigation. If users do not have an account on an node, they have no business on that node! 14. Third party software (such as `Contrl' and `Audit' from Clyde Digital Systems) can be used if additional auditing is desired. Monitoring software such as these will log every keystroke for dynamic or archiving playback of an interactive process, either on an individual basis, or for every interactive process that runs on that system. Auditing software such as these do require a great deal of online space, so procedures for daily backup/ delete will be necessary. 15. Set Sysgen login security (LGI) parameters to values which reflect the local sites requirements for login failures. Set LGI_BRK_TERM to 0 so the system will not associate terminal names with usernames when detecting break-ins. This association is not desired at sites where physical terminal names are created dynamically upon login. Set LGI_BRK_LIM to 2 or 3. This specifies the number of failures that are allowed at login time before the system will take action against a possible break-in attempt. If LGI_BRK_LIM unsuccessful attempts to login occur, the system then takes evasive action. Even though the proper password is entered in successive login attempts, the user is not allowed to log in for LGI_HID_TIM seconds. A value of at least 300 seconds is recommended. This keeps password-guessing programs from working effectively. Other LGI_parameters may be used in conjunction with the above and these include LGI_RETRY_LIM (suggest value=3), LGI_RETRY_TMO (suggest value=20), LGI_BRK_TERM (suggest=0). 16. Captive accounts are deserving of special attention if they are used for network access to your node. The UAF Flag DISCTLY must be set on captive accounts and special consideration and design of Menu driven procedures must be used on such accounts. Batch access to captive accounts should be disabled and perhaps the UAF Flag, DISMAIL, should also be set. ESnet/DECnet Security Revised Draft, 12/89 page 22 17. Log network return paths that result in a network ``connect initiate'' to your node through your DECnet account if the remote node is not defined in your node's remote node name database. Often, as has been the case in the past, new unauthorized nodes often appear somewhere in the extended world-wide DECnet INTERnet and attempt to ``crack'' and access nodes. If you have set up your DECnet account as previously mentioned, you can include the following file as the LOGIN.COM for the DECnet account (use Authorize, MODIFY DECNET/LGICMD=UNKNOWN.COM). The following is an example of UNKNOWN.COM, located in the SYS$LOGIN for the DECnet account. If a node is unknown to you, the return path from your node to the remote will be logged in the file AUDIT.LOG. ESnet/DECnet Security Revised Draft, 12/89 page 23 $!******************UNKNOWN.COM ******************* $ set noverify $!************************************* $! login command file to record the connect path from the remote decnet node. $! For the particular DECnet object (e.g. NML,PHONE etc.), create an account $! like the default DECNET account. (copy the decnet account) $! Using AUTHORIZE and the /lgicmd FLAG, point the account to this command $! file and a separate directory for this account(e.g. [sys0.decnet.nml]). $! For example, this could be the LOGIN.COM for the DECnet Account, and, $! if all of the Connect requests to your node that arrive without $! explicit access control, or without a proxy, get pointed to the $! DECNET Account, ie. "default", this .COM has to be executed $! Example: If this .COM is called UNKNOWN.COM, Run AUTHORIZE and change $! lgicmd to point to UNKNOWN.COM $!************************************************ $ set on $ on error then log $ on warning then log $ remote=f$element(0,":",f$trnlnm("sys$net")) ! We EXTRACT the remote $ if f$integer(remote).eq.0 then goto known !If NOT an Integer,we know it $ area=remote/1024 !We do not have this node defined,so track it $ node=remote-(area*1024) !We get the conventional AREA.NODE $ remote="''area'.''node'" ! We got AREA.NODE $ tell="" $ temp=f$pid(tell)+"." $ tell="" $!************************************************** $! Start "tracing" the bastard rogue AREA and NODE that we do not know $! We do it by "back-tracing" the link, and we log it $! We are going to trace his path before we allow the connection, and $! he won't even know it, unless he is watching his own links at the $! same time. His connect might take a bit longer, but what the hell $!*********************************************** $ open/write out audit.log !We open a special log for this $ max=20 !This keeps us from "stupid" DECSA Loops $ loop:max=max-1 $ if max.eq.0 then log !We quit this if >MAX hops $ mcr ncp 'tell' show node 'remote' to 'temp'1 $ search 'temp'1 "''remote'"/output='temp' $ delete/noconfirm/nolog 'temp'1;1 $ open/read chan 'temp' $ read/end=end chan rec $ close chan $ write out rec $ node=f$element(0," ",f$edit("''f$extract(59,f$length(rec),rec)'", - "trim,compress")) $ tell="tell "+node $ if node.nes.remote then goto loop $ end:if f$search(temp).nes."" then delete/nolog/noconfirm 'temp';* $ close out $ known: $ run sys$system:netserver $ log $!***********************************************************************