SLAC Remote Access Server Security Policies
ADCC: August 9, 1996
Why do we need to Worry about Remote Access Security?
From time to time, SLAC users have expressed interest in setting up their
own SLIP/PPP service or other remote access service (such as
the Windows NT Remote Access Server)
on one of their machines on the SLAC network in
order to provide access to an offsite machine such as a home computer.
This would allow
a dialin connection directly to a server on the SLAC network,
protective Internet firewall screen and not subject to the normal
SLAC firewall protections. Such a server could be a potential back door
to the entire SLAC network. If not carefully configured, an onsite remote
access server would be a serious security risk to all of SLAC's distributed
Currently, SCS does not have the expertise or resources to
configure, check, or otherwise manage such remote access servers, and
we feel that it is better to put our resources into bringing up
the new ISDN service, continuing to support Appletalk Remote Access (ARA),
and providing pointers on how to use external SLIP/PPP services, e.g.
Those who wish to set up remote access servers
must obtain prior approval from the Security Committee and meet
Such servers must be carefully administered, otherwise
crackers may exploit weaknesses
to gain unauthorized access to SLAC computers, networks, and/or file systems.
In the worst case this could
result in the
release of sensitive information, modification or
destruction of data stored on SLAC's computers, or even
damage to apparatus controlled by these computers.
Government laboratories such as SLAC have proven to be tempting targets
for crackers. In 1995 an intrusion into SLAC's network from the Internet
resulted in SLAC having to sever its connection to the Internet for
several days, inconveniencing many remote collaborators who were prevented
from performing their normal work at SLAC. In addition considerable time
had to be expended checking for and removing effects of the break-in and
beefing up security to prevent similar intrusions in the future. Although
this attack was probably not performed via a remote access server, it is
to everyone's benefit to take reasonable precautions to prevent such
intrusions taking place in the future.
The policies described below have been developed to minimize the exposure
to remote access server breakins with an acceptable expenditure of
maintaining an environment in which the potential of remote access servers
can be effectively exploited by SLAC groups. It must be understood that
there is an implicit conflict between the requirements of security,
the desire to exploit new technology for SLAC's research and adminstrative
needs, and the
limited manpower to support new technologies.
Even with the implementation of the policies
described here, it is not possible to completely assure the security of SLAC's
network environment. The level of security described here is thought to be
adequate for most of SLAC's current requirements, however it is
probably not adequate
for applications which deal with highly sensitive information
or where human safety may be affected.
In order to provide reasonable security and availability,
we recommend that:
If an unauthorized
remote access server is discovered, an attempt will be made to contact
the owner(s) via phone and Email. If successful the owner will be
appraised of the policies on remote access servers and requested
to disable the remote access pending authorization. If the attempt to
reach the owner(s) is unsuccessful or the user does not disable
remote access, then measures will be undertaken to
limit the effect (e.g. the server will be barred from the network
pending authorization), and the Security Committee will be notified.
- SCS provides support for a few ways to access nodes at SLAC via
dialin. This should minimize the demand for non-SCS remote access
servers. Currently this includes:
- An Appletalk Remote Access (ARA) server within the firewall which
requires username and password and in some cases dial back.
- Documentation and/or pointers on how to access SLAC via SLIP/PPP services
or Internet service Providers all outside the firewall.
- An ISDN pilot with dialback where the "servers" are inside the
- Requirements for additional remote access servers should be
documented and brought to the
Security Committee for discussion and approval if appropriate. Guidelines for
appropriateness will need to be worked out based on experience.
- No new remote access servers
should be set up at SLAC without review and approval
by the Security Committee
and/or some higher authority.
- Any SLAC remote access server will be maintained by staff who will:
- keep the operating system at a level supported by the vendor;
- keep current with security patches, evaluate and expeditiously apply
- have a thorough understanding of the vendor's remote access server
system, and particularly those aspects which affect security;
- ensure that the remote access server can be used only by persons authorized
to use SLAC's computer and network resources;
- ensure that the server properly restricts access to information;
- ensure the administrator of the server, or a designate, will be available
during working hours to expeditiously resolve problems;
- keep and make available a current list of phone numbers where administrators
or designates may be reached in a critical situation outside normal hours;
- provide the ability to audit use via logs and to monitor exceptions;
- If account/passwords are the chosen method of enhancing security then
the user accounts and passwords must be well managed, this includes:
- keeping a time stamped permanent record of all the accounts that have been
created, together with access priviledges if appropriate
- ensuring an account is removed or disabled when the owner should no longer
have access to it (e.g. the owner is no longer associated with SLAC);
- ensuring accounts are not shared by multiple users;
- ensuring the passwords meet good practices.
- If dialback is the chosen method of improving security, then the
number to be dialed should be removed when a user should no longer have access.
- If all the remote accesses to a server are guaranteed to be
restricted to the server itself (i.e. users
connecting to the remote access server cannot access any other part of the
SLAC network or the Internet by any means (e.g. FTP, finger, telnet, NFS))
then some of the above restrictions may be eased as we understand the
Much of the first section was derived from a similar section authored
by Tony Johnson in the Web Security Document. We have had useful
discussions with Dennis Wisinski on Windows NT Remote Access Services.
Les Cottrell and