SLAC Web Security Policies

Last Update: January 1997

SLAC Welcome Highlighted Home Detailed Home What's New Search Phonebook


Why do Users have to Worry about Web Security?

By its nature the pages on the World Wide Web are highly visible to people all over the world including, unfortunately, a small minority of Internet users who might be tempted to exploit the Web to gain unathorized access to SLAC computers or information. The Web has developed very rapidly and partly as a result of this there have been many well publicised cases of security problems with Web browser and server software. Even commercially developed Web software has been prone to serious security problems.

By exploiting such weaknesses, or by exploiting weaknesses in software developed at SLAC and used with the Web, or by exploiting misconfigured Web server or client software at SLAC, it could be possible for someone on the Internet to gain unauthorized access to SLAC computers and/or to information stored on SLAC's computers. In the worst case this could result in destruction of information 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 hackers. 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 manpower 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 using the Web, and we have so far seen no evidence of attempted break-in via the Web, it is to everyone's benefit to take reasonable precautions to prevent such intrusions taking place in the future.

In order to reduce the potential for such break-ins SCS staff monitor security related news groups and official security advisories (CERT) and take steps to prevent the exploitation of known security holes. Due to the widely distributed nature of the Web it is necessary for all Web users, and particularly Web page or cgi-script authors, to be aware of the security problems inherent in the Web, and to take appropriate steps to prevent security breaches.

The policies described below have been developed to minimize the exposure to Web breakins with an acceptable expenditure of effort/resources, while maintaining an environment in which the tremendous potential of the Web 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 this new technology for SLAC's research and adminstrative needs, and limited manpower. Even with the implementation of the policies described here it is not possible to assure 100% the security of SLAC's Web environment. The level of security described here is thought to be adequate for most of SLAC's current requirements, however it is not adequate for applications which may affect personnel safety or for secure personnel records.

Policies

Servers

NOTE The policies concerning web servers at SLAC were updated in January 1997, however not all of the new policies have yet been implemented. For reference the old server policy is still available.

SLAC provides a well maintained central Web server for use by all groups at SLAC. This should minimize the demand for multiple servers.

Access to unregistered web servers will be blocked at the SLAC firewall. This is intended to prevent users outside of SLAC from accessing unregistered or unintentionally installed web servers (many newer software products install web servers on users' PC and MAC machines, possibly without the user even being aware of it).

Web servers which require access from outside of the SLAC firewall must:

Requests for approving a server are made to the Web server registrar by means of a Web Form including the documented need. In simple cases turnaround on approving a new server are expected to be three working days or better. In more complex cases, approval may be required from the WWW-CC which meets monthly. Web servers must be approved before offsite access will be permitted. A list of registered Web servers is maintained.

Access through the firewall to Web servers using the default port(s) will be allowed to only a small number of official SLAC web servers. Unregistered servers must be configured to use the default port and offsite access to them will be blocked at the firewall. Other web servers which require offsite access, but do not qualify as an official SLAC web server, must first be registered and then configured to run on a specific port number*.

It is forbidden to circumvent these security measures by running an unregistered web server on other than the default port. Random monitoring of offsite connections will be made to discover servers violating this policy.

This scheme will allow SLAC to balance the requirements of security, adminstrative overhead, and capacity of the SLAC firewall machine.

After approval access will be permitted only when the following conditions are met:

Servers must be registered (through appropriate WWW form). Required information will be kept in a database and includes:

Administrators will be automatically subscribed to the SLAC Web Adminstrators mailing list, used for distributing important security related information. Adminstrators are expected to read and when appropriate speedily act on information supplied through this mailing list.

In a critical situation (ie suspected security intrusion) it may be necessary to contact the server adminstrator or backup at any time. In the event that they cannot be contacted it may be necessary to power off the server or disconnect it from the network without warning.

For security purposes adminstrators are responsible to:

For servers containing mission critical information we recommend also

CGI Scripts

WWW CGI (Common Gateway Interface) scripts run as an extension of the Web server and thus have the same access rights to hosts/file/network resources that the server has. Such scripts can thus cause damage (such as gain unauthorized access or deny service) if the script is not carefully written. Problems can be either inadvertent -- aka, bugs -- or deliberate if the script has flaws that allow it to be subverted by a remote user/cracker. Experience has shown that most initial versions of CGI scripts written at SLAC have contained security holes. We therefore:

Some support for user-written CGI scripts is provided including:

Should more support be requested, or if there is disagreement as to the importance of the expressed need, then the user will need to document the requirements and bring them to the WWW-CC.

Clients

Note that at the moment these policies do not address client-side security problems such as those associated with ActiveX, Java and Javascript.


Note: * THis page is only accessible from SLAC.
Les Cottrell and Tony Johnson for the WWW-CC