311 lines
15 KiB
Plaintext
311 lines
15 KiB
Plaintext
|
||
CSL BULLETIN
|
||
July 1993
|
||
|
||
|
||
CONNECTING TO THE INTERNET: SECURITY CONSIDERATIONS
|
||
|
||
This bulletin focuses on security considerations for organizations
|
||
considering Internet connections. Spurred by developments in high-
|
||
speed networking technology and the National Research and Education
|
||
Network (NREN), many organizations and individuals are looking at
|
||
the Internet as a means for expanding their research interests and
|
||
communications. Consequently, the Internet is now growing faster
|
||
than any telecommunications system thus far, including the
|
||
telephone system.
|
||
|
||
New users of the Internet may fail to realize, however, that their
|
||
sites could be at risk to threats such as intruders who use the
|
||
Internet as a means for attacking systems and causing various forms
|
||
of computer security incidents. Consequently, new Internet sites
|
||
are often prime targets for malicious activity, including break-
|
||
ins, file tampering, and service disruptions. Such activity may be
|
||
difficult to discover and correct, may be highly embarrassing to
|
||
the organization, and can be very costly in terms of lost
|
||
productivity and damage to data.
|
||
|
||
New and existing Internet users need to be aware of the high
|
||
potential for computer security incidents from the Internet and the
|
||
steps they should take to secure their sites. Many tools and
|
||
techniques now exist to provide sites with a higher level of
|
||
assurance and protection.
|
||
|
||
The Internet
|
||
The Internet is a world-wide "network of networks" that use the
|
||
TCP/IP protocol suite for communications. The component networks
|
||
are interconnected at various points to provide multiple routes to
|
||
destinations and a high level of overall service to users. Many
|
||
academic, business, and government organizations are connected to
|
||
the Internet. In 1993, over five million users were connected,
|
||
with roughly half being business users.
|
||
|
||
The Internet provides several types of services, including terminal
|
||
emulation and remote system access (telnet), file exchange (ftp),
|
||
electronic mail (smtp), and a number of other services for
|
||
information exchange.
|
||
|
||
As outlined in CSL Bulletin TCP/IP or OSI? Choosing a Strategy for
|
||
Open Systems, NIST advises that agencies procure Open Systems
|
||
Interconnect (OSI) networking products for new network
|
||
implementations and for multivendor information exchange. At the
|
||
same time, it is practical for agencies to consider connections to
|
||
the Internet for the purpose of exchanging e-mail and files with
|
||
the large number of existing Internet sites.
|
||
|
||
Security Problems on the Internet
|
||
In recent years, a number of security problems with the Internet
|
||
have become apparent. Newspapers have carried stories of high-
|
||
profile "cracker" attacks via the Internet against government,
|
||
business, and academic sites. Crackers often roam the Internet
|
||
with impunity, covering their tracks by moving from system to
|
||
system. Intruders have been known to use systems illegally to
|
||
exchange copyrighted software, to obtain sensitive information such
|
||
as business secrets, and in general to cause mischief. System
|
||
administrators are often unaware of break-ins and unauthorized
|
||
users until they learn by accident. A number of factors have
|
||
contributed to this state of affairs.
|
||
|
||
Complexity of Configuration: Many sites connect systems to the
|
||
Internet with little thought to the complexity of system
|
||
administration and the increased potential for abuse from the
|
||
Internet. New systems often arrive "out of the box" with network
|
||
access controls configured for maximum, i.e., least secure, access.
|
||
The access controls are usually complex to configure and monitor.
|
||
As a result, controls that are accidentally misconfigured can
|
||
result in unauthorized access.
|
||
|
||
Ease of Spying and Spoofing: The vast majority of Internet traffic
|
||
is unencrypted and therefore easily readable. As a result, e-mail,
|
||
passwords, and file transfers can be monitored and captured using
|
||
readily available software. Intruders have been known to monitor
|
||
connections to well-known Internet sites for the purpose of gaining
|
||
information that would allow them to crack security or to steal
|
||
valuable information. This information sometimes permits intruders
|
||
to spoof legitimate connections, i.e., trick system security into
|
||
permitting normally disallowed network connections.
|
||
|
||
Inherent Problems with TCP/IP Protocols: The TCP/IP protocol
|
||
suite, as implemented in the Internet, does not contain provisions
|
||
for network security. A number of the TCP/IP services, e.g.,
|
||
rlogin, rsh, etc., rely on mutually trusting systems and are
|
||
inherently vulnerable to misuse and spoofing. Ironically, some of
|
||
these services, e.g., nis and nfs, are widely used to coordinate
|
||
local area network security and to distribute system resources
|
||
among other local systems. If the vulnerabilities in these
|
||
services are exploited, security on the local area network could be
|
||
badly compromised.
|
||
|
||
Wide-Open Network Policies: Many sites are configured
|
||
unintentionally for wide-open Internet access without regard to the
|
||
potential for abuse from the Internet. Some systems still employ
|
||
password-less guest accounts or anonymous ftp accounts that can be
|
||
written to without restriction. Others keep sensitive information
|
||
on network-accessible systems where it can be easily read. The
|
||
vast majority of sites permit more TCP/IP services than they
|
||
require for their operations and do not attempt to limit access to
|
||
information about their computers that could prove valuable to
|
||
intruders.
|
||
|
||
Recommendations for New and Existing Internet Connections
|
||
New and existing Internet sites need to take strong and specific
|
||
measures to improve computer security. These measures include
|
||
creating a TCP/IP service access policy, using strong
|
||
authentication, and using a secure Internet gateway that can imple-
|
||
ment network access policies.
|
||
|
||
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Service Access Policy<63><79><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ͻ
|
||
<20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ <20>
|
||
<20> <20> <20> <20>
|
||
<20> <20> Local <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ <20>
|
||
<20> <20> Area <20> strong <20> Secure <20><><EFBFBD><EFBFBD><EFBFBD> INTERNET
|
||
<20> <20> Network <20>authentication<6F> Gateway <20><><EFBFBD><EFBFBD><EFBFBD> OSI WANs
|
||
<20> <20> Systems <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20>
|
||
<20> <20> <20> <20>
|
||
<20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20>
|
||
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ͼ
|
||
|
||
Network Service Policy: The first step is to create a policy that
|
||
details what types of connectivity will be permitted. If, for
|
||
example, e-mail is the only service required, then other forms of
|
||
access such as telnet and ftp can be restricted and overall risks
|
||
reduced. Eliminating the TCP/IP services that are not needed will
|
||
help to provide a simpler, more manageable network environment.
|
||
The following figure is a partial list of TCP/IP services that
|
||
should be restricted or blocked from passing through a site's
|
||
Internet gateway:
|
||
|
||
High-Risk TCP/IP Services
|
||
DNS zone transfers leaks names of internal
|
||
systems tftp intruders can read
|
||
password file RPC (eg., NIS,
|
||
NFS) intruders can read/write
|
||
files rlogin, rsh, etc. relies on mutually
|
||
trusting systems X windows,
|
||
OpenWindows intruders can monitor
|
||
users' sessions telnet, ftp, smtp can be abused, access
|
||
should be re-
|
||
stricted to selected
|
||
systems
|
||
Strong Authentication: Systems that can be accessed from the
|
||
Internet or via modem should require strong authentication such as
|
||
provided by smart cards and authentication tokens. These systems
|
||
use one-time passwords that cannot be spoofed, regardless of
|
||
whether the passwords are monitored. CSL Bulletin Advanced
|
||
Authentication Technology contains more information on strong
|
||
authentication techniques.
|
||
|
||
Secure Gateways: Secure gateways, or firewalls, are highly
|
||
effective for improving site network security. A secure gateway is
|
||
a collection of systems and routers placed at a site's central
|
||
connection to a network whose main purpose is to restrict access to
|
||
internal systems. A secure gateway forces all network connections
|
||
to pass through the gateway where they can be examined and
|
||
evaluated. The secure gateway may then restrict access to or from
|
||
selected systems or block certain TCP/IP services or provide other
|
||
security features. A simple network usage policy that can be
|
||
implemented by a secure gateway is to provide access from internal
|
||
to external systems, but little or no access from external to
|
||
internal systems (except perhaps for e-mail).
|
||
|
||
For small sites, a simple router with packet-filtering capability
|
||
may serve as an effective gateway. This type of router can
|
||
typically restrict access to selected systems and services by
|
||
examining each packet according to a sequence of filtering rules.
|
||
A more flexible and robust approach is to combine the router with
|
||
other systems capable of logging network access and restricting
|
||
access and services on a finer basis. Some secure gateways
|
||
implement proxy services that require all ftp or telnet connections
|
||
to be first authenticated at the gateway before being allowed to
|
||
continue.
|
||
|
||
Without a secure gateway, a site's security depends entirely on the
|
||
collective security of its individual systems. As the number of
|
||
systems increases, it becomes more difficult to ensure that network
|
||
security policies are enforced. Errors and simple mistakes in one
|
||
system's configuration can cause problems for other interconnected
|
||
systems.
|
||
|
||
Securing Modem Pools: Unrestricted incoming and outgoing modem
|
||
pools (including PABX systems) can create backdoors that would let
|
||
intruders get around the access controls of secure gateways. Modem
|
||
pools need to be configured to deny access to unauthorized users.
|
||
Systems that can be accessed from modem pools should require strong
|
||
authentication such as one-time passwords. Modem pools should not
|
||
be configured for outgoing connections unless access can be
|
||
carefully controlled.
|
||
|
||
Securing Public Access Systems: Public access systems such as
|
||
anonymous ftp archives are often prime targets for abuse. Such
|
||
systems, if misconfigured to allow writing, can permit intruders to
|
||
destroy or alter data or software, which can prove highly
|
||
embarrassing to the organization. CSL Bulletin Security Issues in
|
||
Public Access Systems provides guidance on securing public access
|
||
systems.
|
||
|
||
System Security Tools: The existence of a secure gateway does not
|
||
negate the need for stronger system security. Many tools are
|
||
available for system administrators to enhance system security and
|
||
provide additional audit capability. Such tools can check for
|
||
strong passwords, log connection information, detect changes in
|
||
system files, and provide other features that will help
|
||
administrators to detect signs of intruders and break-ins.
|
||
|
||
Keeping Up-to-Date
|
||
Sites need to be aware of other resources and information that will
|
||
permit them to update site security as new vulnerabilities are
|
||
discovered and as new tools and techniques to improve security
|
||
become available. In particular, sites need to know who to contact
|
||
when trouble arises.
|
||
|
||
Vendor Support: Several system vendors now regularly distribute
|
||
software update notifications and related security information via
|
||
e-mail. Customers need to contact vendors and determine whether
|
||
they can receive such information.
|
||
|
||
Incident Handling Teams: A number of vendors, other businesses,
|
||
and government-affiliated organizations have created computer
|
||
security incident handling teams. These groups typically provide
|
||
assistance in determining whether an incident has occurred and how
|
||
to correct any vulnerabilities that were exploited. NIST helps to
|
||
coordinate the Forum of Incident Response and Security Teams
|
||
(FIRST). FIRST provides guidance and overall coordination of teams
|
||
and incident handling information. For more information about
|
||
incident response teams and FIRST, contact NIST (see below).
|
||
|
||
For More Information
|
||
NIST will be issuing more guidance on open systems security and on
|
||
secure gateways. For more information on Internet security and
|
||
other computer security issues, contact the National Institute of
|
||
Standards and Technology at the following address: NIST, Building
|
||
225, Room A-216, Gaithersburg, MD 20899-0001; telephone (301) 975-
|
||
3359; fax (301) 948-0279.
|
||
|
||
NIST also maintains a computer security bulletin board system (BBS)
|
||
and Internet-accessible site for computer security information open
|
||
to the public at all times. These resources provide information on
|
||
computer security publications, CSL Bulletins, alert notices,
|
||
information about viruses and anti-virus tools, a security events
|
||
calendar, and sources for more information.
|
||
|
||
To access the BBS, you need a computer with communications
|
||
capability and a modem. For modems at 2400 bits per second (BPS)
|
||
or less, dial (301) 948-5717. For 9600 BPS, dial (301) 948-5140.
|
||
Modem settings for all speeds are 8 data bits, no parity, 1 stop
|
||
bit.
|
||
|
||
Internet users with telnet or ftp capability may telnet to the BBS
|
||
at cs-bbs.nist.gov (129.6.54.30). To download files, users need to
|
||
use ftp as follows: ftp to csrc.nist.gov (129.6.54.11), log into
|
||
account anonymous, use your Internet address as the password, and
|
||
locate files in directory pub; an index of all files is available
|
||
for download. For users with Internet-accessible e-mail
|
||
capability, send e-mail to docserver@csrc.nist.gov with the
|
||
following message: send filename, where filename is the name of
|
||
the file you wish to retrieve. send index will return an index of
|
||
available files.
|
||
|
||
References
|
||
The sources used to develop this bulletin provide excellent
|
||
resources for further information on Internet security and related
|
||
topics. Ordering information is provided when appropriate. All
|
||
references except [1] and [6] are available from the NIST BBS or
|
||
via ftp.
|
||
|
||
[1] Cerf, Vinton, "A National Information Infrastructure,"
|
||
Connexions, June 1993.
|
||
|
||
[2] "TCP/IP or OSI? Choosing a Strategy for Open Systems," CSL
|
||
Bulletin, National Institute of Standards and Technology, June
|
||
1992.
|
||
|
||
[3] Bellovin, Steve, "Security Problems in the TCP/IP Protocol
|
||
Suite," Computer Communication Review, April 1989.
|
||
|
||
[4] Holbrook, Paul, and Joyce Reynolds, "Site Security Handbook,"
|
||
RFC 1244 prepared for the Internet Engineering Task Force,
|
||
1991.
|
||
|
||
[5] "Advanced Authentication Technology," CSL Bulletin, National
|
||
Institute of Standards and Technology, November 1991.
|
||
|
||
[6] Curry, David, Unix System Security, Addison Wesley, 1992.
|
||
|
||
[7] Ranum, Marcus, "Thinking About Firewalls," Proceedings of
|
||
Second International Conference on System and Network
|
||
Security, April 1993.
|
||
|
||
[8] "Security Issues in Public Access Systems," CSL Bulletin,
|
||
National Institute of Standards and Technology, May 1993.
|
||
|
||
[9] Polk, W. Timothy, Automated Tools for Testing Computer System
|
||
Vulnerability, NIST Special Publication 800-6, National
|
||
Institute of Standards and Technology, December 1992. Order
|
||
from GPO, 202-783-3238, SN003-003-03189-9, or NTIS, 703-487-
|
||
4650, PB93-146025.
|
||
|
||
[10] Wack, John, Establishing A Computer Security Incident Response
|
||
Capability, NIST Special Publication 800-3, National Institute
|
||
of Standards and Technology, November 1991. Order from NTIS,
|
||
703-487-4650, PB92-123140.
|
||
|