informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
278a90f7ce219e36e5de0a80b540e469a9bce912
textfiles/hacking/INTERNET/esnet.txt
T
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

1413 lines
57 KiB
Plaintext
Raw Blame History

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
$!***********************************************************************
Reference in New Issue View Git Blame Copy Permalink