Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2196

Site Security Handbook

Pages: 75
FYI 8
Errata
Obsoletes:  1244
Part 1 of 3 – Pages 1 to 24
None   None   Next

ToP   noToC   RFC2196 - Page 1
Network Working Group                                      B. Fraser
Request for Comments: 2196                                    Editor
FYI: 8                                                       SEI/CMU
Obsoletes: 1244                                       September 1997
Category: Informational


                         Site Security Handbook


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This handbook is a guide to developing computer security policies and
   procedures for sites that have systems on the Internet.  The purpose
   of this handbook is to provide practical guidance to administrators
   trying to secure their information and services.  The subjects
   covered include policy content and formation, a broad range of
   technical system and network security topics, and security incident
   response.


Table of Contents

 1.   Introduction...................................................  2
 1.1  Purpose of this Work...........................................  3
 1.2  Audience.......................................................  3
 1.3  Definitions....................................................  3
 1.4  Related Work...................................................  4
 1.5  Basic Approach.................................................  4
 1.6  Risk Assessment................................................  5
 2.   Security Policies..............................................  6
 2.1  What is a Security Policy and Why Have One?....................  6
 2.2  What Makes a Good Security Policy?.............................  9
 2.3  Keeping the Policy Flexible.................................... 11
 3.   Architecture................................................... 11
 3.1  Objectives..................................................... 11
 3.2  Network and Service Configuration.............................. 14
 3.3  Firewalls...................................................... 20
 4.   Security Services and Procedures............................... 24
 4.1  Authentication................................................. 24
 4.2  Confidentiality................................................ 28
 4.3  Integrity...................................................... 28
ToP   noToC   RFC2196 - Page 2
 4.4  Authorization.................................................. 29
 4.5  Access......................................................... 30
 4.6  Auditing....................................................... 34
 4.7  Securing Backups............................................... 37
 5.   Security Incident Handling..................................... 37
 5.1  Preparing and Planning for Incident Handling................... 39
 5.2  Notification and Points of Contact............................. 42
 5.3  Identifying an Incident........................................ 50
 5.4  Handling an Incident........................................... 52
 5.5  Aftermath of an Incident....................................... 58
 5.6  Responsibilities............................................... 59
 6.   Ongoing Activities............................................. 60
 7.   Tools and Locations............................................ 60
 8.   Mailing Lists and Other Resources.............................. 62
 9.   References..................................................... 64

1.  Introduction

   This document provides guidance to system and network administrators
   on how to address security issues within the Internet community.  It
   builds on the foundation provided in RFC 1244 and is the collective
   work of a number of contributing authors. Those authors include:
   Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee
   (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net),
   Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser
   (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman
   (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus-
   Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone
   (lorna@staff.singnet.com.sg), Edward.P.Lewis
   (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com),
   Russ Mundy (mundy@tis.com), Philip J. Nesser
   (pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey
   (msr@interpath.net).

   In addition to the principle writers, a number of reviewers provided
   valuable comments. Those reviewers include: Eric Luiijf
   (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak
   (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl).

   A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook,
   CICnet, for their vision, leadership, and effort in the creation of
   the first version of this handbook. It is the working group's sincere
   hope that this version will be as helpful to the community as the
   earlier one was.
ToP   noToC   RFC2196 - Page 3
1.1  Purpose of This Work

   This handbook is a guide to setting computer security policies and
   procedures for sites that have systems on the Internet (however, the
   information provided should also be useful to sites not yet connected
   to the Internet).  This guide lists issues and factors that a site
   must consider when setting their own policies.  It makes a number of
   recommendations and provides discussions of relevant areas.

   This guide is only a framework for setting security policies and
   procedures.  In order to have an effective set of policies and
   procedures, a site will have to make many decisions, gain agreement,
   and then communicate and implement these policies.

1.2  Audience

   The audience for this document are system and network administrators,
   and decision makers (typically "middle management") at sites.  For
   brevity, we will use the term "administrator" throughout this
   document to refer to system and network administrators.

   This document is not directed at programmers or those trying to
   create secure programs or systems.  The focus of this document is on
   the policies and procedures that need to be in place to support the
   technical security features that a site may be implementing.

   The primary audience for this work are sites that are members of the
   Internet community.  However, this document should be useful to any
   site that allows communication with other sites.  As a general guide
   to security policies, this document may also be useful to sites with
   isolated systems.

1.3  Definitions

   For the purposes of this guide, a "site" is any organization that
   owns computers or network-related resources. These resources may
   include host computers that users use, routers, terminal servers, PCs
   or other devices that have access to the Internet.  A site may be an
   end user of Internet services or a service provider such as a mid-
   level network.  However, most of the focus of this guide is on those
   end users of Internet services.  We assume that the site has the
   ability to set policies and procedures for itself with the
   concurrence and support from those who actually own the resources. It
   will be assumed that sites that are parts of larger organizations
   will know when they need to consult, collaborate, or take
   recommendations from, the larger entity.
ToP   noToC   RFC2196 - Page 4
   The "Internet" is a collection of thousands of networks linked by a
   common set of technical protocols which make it possible for users of
   any one of the networks to communicate with, or use the services
   located on, any of the other networks (FYI4, RFC 1594).

   The term "administrator" is used to cover all those people who are
   responsible for the day-to-day operation of system and network
   resources.  This may be a number of individuals or an organization.

   The term "security administrator" is used to cover all those people
   who are responsible for the security of information and information
   technology.  At some sites this function may be combined with
   administrator (above); at others, this will be a separate position.

   The term "decision maker" refers to those people at a site who set or
   approve policy.  These are often (but not always) the people who own
   the resources.

1.4  Related Work

   The Site Security Handbook Working Group is working on a User's Guide
   to Internet Security. It will provide practical guidance to end users
   to help them protect their information and the resources they use.

1.5  Basic Approach

   This guide is written to provide basic guidance in developing a
   security plan for your site.  One generally accepted approach to
   follow is suggested by Fites, et. al. [Fites 1989] and includes the
   following steps:

   (1)  Identify what you are trying to protect.
   (2)  Determine what you are trying to protect it from.
   (3)  Determine how likely the threats are.
   (4)  Implement measures which will protect your assets in a cost-
        effective manner.
   (5)  Review the process continuously and make improvements each time
        a weakness is found.

   Most of this document is focused on item 4 above, but the other steps
   cannot be avoided if an effective plan is to be established at your
   site.  One old truism in security is that the cost of protecting
   yourself against a threat should be less than the cost of recovering
   if the threat were to strike you.  Cost in this context should be
   remembered to include losses expressed in real currency, reputation,
   trustworthiness, and other less obvious measures.  Without reasonable
   knowledge of what you are protecting and what the likely threats are,
   following this rule could be difficult.
ToP   noToC   RFC2196 - Page 5
1.6  Risk Assessment

1.6.1  General Discussion

   One of the most important reasons for creating a computer security
   policy is to ensure that efforts spent on security yield cost
   effective benefits.  Although this may seem obvious, it is possible
   to be mislead about where the effort is needed.  As an example, there
   is a great deal of publicity about intruders on computers systems;
   yet most surveys of computer security show that, for most
   organizations, the actual loss from "insiders" is much greater.

   Risk analysis involves determining what you need to protect, what you
   need to protect it from, and how to protect it.  It is the process of
   examining all of your risks, then ranking those risks by level of
   severity.  This process involves making cost-effective decisions on
   what you want to protect.  As mentioned above, you should probably
   not spend more to protect something than it is actually worth.

   A full treatment of risk analysis is outside the scope of this
   document.  [Fites 1989] and [Pfleeger 1989] provide introductions to
   this topic.  However, there are two elements of a risk analysis that
   will be briefly covered in the next two sections:

   (1) Identifying the assets
   (2) Identifying the threats

   For each asset, the basic goals of security are availability,
   confidentiality, and integrity.  Each threat should be examined with
   an eye to how the threat could affect these areas.

1.6.2  Identifying the Assets

   One step in a risk analysis is to identify all the things that need
   to be protected.  Some things are obvious, like valuable proprietary
   information, intellectual property, and all the various pieces of
   hardware; but, some are overlooked, such as the people who actually
   use the systems. The essential point is to list all things that could
   be affected by a security problem.

   One list of categories is suggested by Pfleeger [Pfleeger 1989]; this
   list is adapted from that source:

   (1)  Hardware: CPUs, boards, keyboards, terminals,
        workstations, personal computers, printers, disk
        drives, communication lines, terminal servers, routers.
ToP   noToC   RFC2196 - Page 6
   (2)  Software: source programs, object programs,
        utilities, diagnostic programs, operating systems,
        communication programs.

   (3)  Data: during execution, stored on-line, archived off-line,
        backups, audit logs, databases, in transit over
        communication media.

   (4)  People: users, administrators, hardware maintainers.

   (5)  Documentation: on programs, hardware, systems, local
        administrative procedures.

   (6)  Supplies: paper, forms, ribbons, magnetic media.

1.6.3  Identifying the Threats

   Once the assets requiring protection are identified, it is necessary
   to identify threats to those assets.  The threats can then be
   examined to determine what potential for loss exists.  It helps to
   consider from what threats you are trying to protect your assets.
   The following are classic threats that should be considered.
   Depending on your site, there will be more specific threats that
   should be identified and addressed.

   (1)  Unauthorized access to resources and/or information
   (2)  Unintented and/or unauthorized Disclosure of information
   (3)  Denial of service

2.  Security Policies

   Throughout this document there will be many references to policies.
   Often these references will include recommendations for specific
   policies. Rather than repeat guidance in how to create and
   communicate such a policy, the reader should apply the advice
   presented in this chapter when developing any policy recommended
   later in this book.

2.1  What is a Security Policy and Why Have One?

   The security-related decisions you make, or fail to make, as
   administrator largely determines how secure or insecure your network
   is, how much functionality your network offers, and how easy your
   network is to use.  However, you cannot make good decisions about
   security without first determining what your security goals are.
   Until you determine what your security goals are, you cannot make
   effective use of any collection of security tools because you simply
   will not know what to check for and what restrictions to impose.
ToP   noToC   RFC2196 - Page 7
   For example, your goals will probably be very different from the
   goals of a product vendor.  Vendors are trying to make configuration
   and operation of their products as simple as possible, which implies
   that the default configurations will often be as open (i.e.,
   insecure) as possible.  While this does make it easier to install new
   products, it also leaves access to those systems, and other systems
   through them, open to any user who wanders by.

   Your goals will be largely determined by the following key tradeoffs:

   (1)  services offered versus security provided -
        Each service offered to users carries its own security risks.
        For some services the risk outweighs the benefit of the service
        and the administrator may choose to eliminate the service rather
        than try to secure it.

   (2)  ease of use versus security -
        The easiest system to use would allow access to any user and
        require no passwords; that is, there would be no security.
        Requiring passwords makes the system a little less convenient,
        but more secure.  Requiring device-generated one-time passwords
        makes the system even more difficult to use, but much more
        secure.

   (3)  cost of security versus risk of loss -
        There are many different costs to security: monetary (i.e., the
        cost of purchasing security hardware and software like firewalls
        and one-time password generators), performance (i.e., encryption
        and decryption take time), and ease of use (as mentioned above).
        There are also many levels of risk: loss of privacy (i.e., the
        reading of information by unauthorized individuals), loss of
        data (i.e., the corruption or erasure of information), and the
        loss of service (e.g., the filling of data storage space, usage
        of computational resources, and denial of network access).  Each
        type of cost must be weighed against each type of loss.


   Your goals should be communicated to all users, operations staff, and
   managers through a set of security rules, called a "security policy."
   We are using this term, rather than the narrower "computer security
   policy" since the scope includes all types of information technology
   and the information stored and manipulated by the technology.

2.1.1  Definition of a Security Policy

   A security policy is a formal statement of the rules by which people
   who are given access to an organization's technology and information
   assets must abide.
ToP   noToC   RFC2196 - Page 8
2.1.2  Purposes of a Security Policy

   The main purpose of a security policy is to inform users, staff and
   managers of their obligatory requirements for protecting technology
   and information assets.  The policy should specify the mechanisms
   through which these requirements can be met.  Another purpose is to
   provide a baseline from which to acquire, configure and audit
   computer systems and networks for compliance with the policy.
   Therefore an attempt to use a set of security tools in the absence of
   at least an implied security policy is meaningless.

   An Appropriate Use Policy (AUP) may also be part of a security
   policy.  It should spell out what users shall and shall not do on the
   various components of the system, including the type of traffic
   allowed on the networks.  The AUP should be as explicit as possible
   to avoid ambiguity or misunderstanding.  For example, an AUP might
   list any prohibited USENET newsgroups. (Note: Appropriate Use Policy
   is referred to as Acceptable Use Policy by some sites.)

2.1.3  Who Should be Involved When Forming Policy?

   In order for a security policy to be appropriate and effective, it
   needs to have the acceptance and support of all levels of employees
   within the organization.  It is especially important that corporate
   management fully support the security policy process otherwise there
   is little chance that they will have the intended impact.  The
   following is a list of individuals who should be involved in the
   creation and review of security policy documents:

   (1)  site security administrator
   (2)  information technology technical staff (e.g., staff from
        computing center)
   (3)  administrators of large user groups within the organization
        (e.g., business divisions, computer science department within a
        university, etc.)
   (4)  security incident response team
   (5)  representatives of the user groups affected by the security
        policy
   (6)  responsible management
   (7)  legal counsel (if appropriate)

   The list above is representative of many organizations, but is not
   necessarily comprehensive.  The idea is to bring in representation
   from key stakeholders, management who have budget and policy
   authority, technical staff who know what can and cannot be supported,
   and legal counsel who know the legal ramifications of various policy
ToP   noToC   RFC2196 - Page 9
   choices.  In some organizations, it may be appropriate to include EDP
   audit personnel.  Involving this group is important if resulting
   policy statements are to reach the broadest possible acceptance.  It
   is also relevant to mention that the role of legal counsel will also
   vary from country to country.

2.2  What Makes a Good Security Policy?

   The characteristics of a good security policy are:

   (1)  It must be implementable through system administration
        procedures, publishing of acceptable use guidelines, or other
        appropriate methods.

   (2)  It must be enforcible with security tools, where appropriate,
        and with sanctions, where actual prevention is not technically
        feasible.

   (3)  It must clearly define the areas of responsibility for the
        users, administrators, and management.

   The components of a good security policy include:

   (1)  Computer Technology Purchasing Guidelines which specify
        required, or preferred, security features.  These should
        supplement existing purchasing policies and guidelines.

   (2)  A Privacy Policy which defines reasonable expectations of
        privacy regarding such issues as monitoring of electronic mail,
        logging of keystrokes, and access to users' files.

   (3)  An Access Policy which defines access rights and privileges to
        protect assets from loss or disclosure by specifying acceptable
        use guidelines for users, operations staff, and management.  It
        should provide guidelines for external connections, data
        communications, connecting devices to a network, and adding new
        software to systems.  It should also specify any required
        notification messages (e.g., connect messages should provide
        warnings about authorized usage and line monitoring, and not
        simply say "Welcome").

   (4)  An Accountability Policy which defines the responsibilities of
        users, operations staff, and management.  It should specify an
        audit capability, and provide incident handling guidelines
        (i.e., what to do and who to contact if a possible intrusion is
        detected).
ToP   noToC   RFC2196 - Page 10
   (5)  An Authentication Policy which establishes trust through an
        effective password policy, and by setting guidelines for remote
        location authentication and the use of authentication devices
        (e.g., one-time passwords and the devices that generate them).

   (6)  An Availability statement which sets users' expectations for the
        availability of resources.  It should address redundancy and
        recovery issues, as well as specify operating hours and
        maintenance down-time periods.  It should also include contact
        information for reporting system and network failures.

   (7)  An Information Technology System & Network Maintenance Policy
        which describes how both internal and external maintenance
        people are allowed to handle and access technology. One
        important topic to be addressed here is whether remote
        maintenance is allowed and how such access is controlled.
        Another area for consideration here is outsourcing and how it is
        managed.

   (8)  A Violations Reporting Policy that indicates which types of
        violations (e.g., privacy and security, internal and external)
        must be reported and to whom the reports are made.  A non-
        threatening atmosphere and the possibility of anonymous
        reporting will result in a greater probability that a violation
        will be reported if it is detected.

   (9)  Supporting Information which provides users, staff, and
        management with contact information for each type of policy
        violation; guidelines on how to handle outside queries about a
        security incident, or information which may be considered
        confidential or proprietary; and cross-references to security
        procedures and related information, such as company policies and
        governmental laws and regulations.

   There may be regulatory requirements that affect some aspects of your
   security policy (e.g., line monitoring).  The creators of the
   security policy should consider seeking legal assistance in the
   creation of the policy.  At a minimum, the policy should be reviewed
   by legal counsel.

   Once your security policy has been established it should be clearly
   communicated to users, staff, and management.  Having all personnel
   sign a statement indicating that they have read, understood, and
   agreed to abide by the policy is an important part of the process.
   Finally, your policy should be reviewed on a regular basis to see if
   it is successfully supporting your security needs.
ToP   noToC   RFC2196 - Page 11
2.3  Keeping the Policy Flexible

   In order for a security policy to be viable for the long term, it
   requires a lot of flexibility based upon an architectural security
   concept. A security policy should be (largely) independent from
   specific hardware and software situations (as specific systems tend
   to be replaced or moved overnight).  The mechanisms for updating the
   policy should be clearly spelled out.  This includes the process, the
   people involved, and the people who must sign-off on the changes.

   It is also important to recognize that there are exceptions to every
   rule.  Whenever possible, the policy should spell out what exceptions
   to the general policy exist.  For example, under what conditions is a
   system administrator allowed to go through a user's files.  Also,
   there may be some cases when multiple users will have access to the
   same userid.  For example, on systems with a "root" user, multiple
   system administrators may know the password and use the root account.

   Another consideration is called the "Garbage Truck Syndrome."  This
   refers to what would happen to a site if a key person was suddenly
   unavailable for his/her job function (e.g., was suddenly ill or left
   the company unexpectedly).  While the greatest security resides in
   the minimum dissemination of information, the risk of losing critical
   information increases when that information is not shared.  It is
   important to determine what the proper balance is for your site.

3.  Architecture

3.1  Objectives

3.1.1  Completely Defined Security Plans

   All sites should define a comprehensive security plan.  This plan
   should be at a higher level than the specific policies discussed in
   chapter 2, and it should be crafted as a framework of broad
   guidelines into which specific policies will fit.

   It is important to have this framework in place so that individual
   policies can be consistent with the overall site security
   architecture.  For example, having a strong policy with regard to
   Internet access and having weak restrictions on modem usage is
   inconsistent with an overall philosophy of strong security
   restrictions on external access.

   A security plan should define: the list of network services that will
   be provided; which areas of the organization will provide the
   services; who will have access to those services; how access will be
   provided; who will administer those services; etc.
ToP   noToC   RFC2196 - Page 12
   The plan should also address how incident will be handled.  Chapter 5
   provides an in-depth discussion of this topic, but it is important
   for each site to define classes of incidents and corresponding
   responses.  For example, sites with firewalls should set a threshold
   on the number of attempts made to foil the firewall before triggering
   a response?  Escallation levels should be defined for both attacks
   and responses.  Sites without firewalls will have to determine if a
   single attempt to connect to a host constitutes an incident? What
   about a systematic scan of systems?

   For sites connected to the Internet, the rampant media magnification
   of Internet related security incidents can overshadow a (potentially)
   more serious internal security problem.  Likewise, companies who have
   never been connected to the Internet may have strong, well defined,
   internal policies but fail to adequately address an external
   connection policy.

3.1.2  Separation of Services

   There are many services which a site may wish to provide for its
   users, some of which may be external.  There are a variety of
   security reasons to attempt to isolate services onto dedicated host
   computers.  There are also performance reasons in most cases, but a
   detailed discussion is beyond to scope of this document.

   The services which a site may provide will, in most cases, have
   different levels of access needs and models of trust.  Services which
   are essential to the security or smooth operation of a site would be
   better off being placed on a dedicated machine with very limited
   access (see Section 3.1.3 "deny all" model), rather than on a machine
   that provides a service (or services) which has traditionally been
   less secure, or requires greater accessability by users who may
   accidentally suborn security.

   It is also important to distinguish between hosts which operate
   within different models of trust (e.g., all the hosts inside of a
   firewall and any host on an exposed network).

   Some of the services which should be examined for potential
   separation are outlined in section 3.2.3. It is important to remember
   that security is only as strong as the weakest link in the chain.
   Several of the most publicized penetrations in recent years have been
   through the exploitation of vulnerabilities in electronic mail
   systems.  The intruders were not trying to steal electronic mail, but
   they used the vulnerability in that service to gain access to other
   systems.
ToP   noToC   RFC2196 - Page 13
   If possible, each service should be running on a different machine
   whose only duty is to provide a specific service.  This helps to
   isolate intruders and limit potential harm.

3.1.3  Deny all/ Allow all

   There are two diametrically opposed underlying philosophies which can
   be adopted when defining a security plan.  Both alternatives are
   legitimate models to adopt, and the choice between them will depend
   on the site and its needs for security.

   The first option is to turn off all services and then selectively
   enable services on a case by case basis as they are needed. This can
   be done at the host or network level as appropriate.  This model,
   which will here after be referred to as the "deny all" model, is
   generally more secure than the other model described in the next
   paragraph.  More work is required to successfully implement a "deny
   all" configuration as well as a better understanding of services.
   Allowing only known services provides for a better analysis of a
   particular service/protocol and the design of a security mechanism
   suited to the security level of the site.

   The other model, which will here after be referred to as the "allow
   all" model, is much easier to implement, but is generally less secure
   than the "deny all" model.  Simply turn on all services, usually the
   default at the host level, and allow all protocols to travel across
   network boundaries, usually the default at the router level.  As
   security holes become apparent, they are restricted or patched at
   either the host or network level.

   Each of these models can be applied to different portions of the
   site, depending on functionality requirements, administrative
   control, site policy, etc.  For example, the policy may be to use the
   "allow all" model when setting up workstations for general use, but
   adopt a "deny all" model when setting up information servers, like an
   email hub.  Likewise, an "allow all" policy may be adopted for
   traffic between LAN's internal to the site, but a "deny all" policy
   can be adopted between the site and the Internet.

   Be careful when mixing philosophies as in the examples above.  Many
   sites adopt the theory of a hard "crunchy" shell and a soft "squishy"
   middle.  They are willing to pay the cost of security for their
   external traffic and require strong security measures, but are
   unwilling or unable to provide similar protections internally.  This
   works fine as long as the outer defenses are never breached and the
   internal users can be trusted.  Once the outer shell (firewall) is
   breached, subverting the internal network is trivial.
ToP   noToC   RFC2196 - Page 14
3.1.4  Identify Real Needs for Services

   There is a large variety of services which may be provided, both
   internally and on the Internet at large.  Managing security is, in
   many ways, managing access to services internal to the site and
   managing how internal users access information at remote sites.

   Services tend to rush like waves over the Internet.  Over the years
   many sites have established anonymous FTP servers, gopher servers,
   wais servers, WWW servers, etc. as they became popular, but not
   particularly needed, at all sites.  Evaluate all new services that
   are established with a skeptical attitude to determine if they are
   actually needed or just the current fad sweeping the Internet.

   Bear in mind that security complexity can grow exponentially with the
   number of services provided.  Filtering routers need to be modified
   to support the new protocols.  Some protocols are inherently
   difficult to filter safely (e.g., RPC and UDP services), thus
   providing more openings to the internal network.  Services provided
   on the same machine can interact in catastrophic ways.  For example,
   allowing anonymous FTP on the same machine as the WWW server may
   allow an intruder to place a file in the anonymous FTP area and cause
   the HTTP server to execute it.

3.2  Network and Service Configuration

3.2.1  Protecting the Infrastructure

   Many network administrators go to great lengths to protect the hosts
   on their networks.  Few administrators make any effort to protect the
   networks themselves.  There is some rationale to this.  For example,
   it is far easier to protect a host than a network.  Also, intruders
   are likely to be after data on the hosts; damaging the network would
   not serve their purposes.  That said, there are still reasons to
   protect the networks.  For example, an intruder might divert network
   traffic through an outside host in order to examine the data (i.e.,
   to search for passwords).  Also, infrastructure includes more than
   the networks and the routers which interconnect them.  Infrastructure
   also includes network management (e.g., SNMP), services (e.g., DNS,
   NFS, NTP, WWW), and security (i.e., user authentication and access
   restrictions).

   The infrastructure also needs protection against human error.  When
   an administrator misconfigures a host, that host may offer degraded
   service.  This only affects users who require that host and, unless
ToP   noToC   RFC2196 - Page 15
   that host is a primary server, the number of affected users will
   therefore be limited.  However, if a router is misconfigured, all
   users who require the network will be affected.  Obviously, this is a
   far larger number of users than those depending on any one host.

3.2.2  Protecting the Network

   There are several problems to which networks are vulnerable.  The
   classic problem is a "denial of service" attack.  In this case, the
   network is brought to a state in which it can no longer carry
   legitimate users' data.  There are two common ways this can be done:
   by attacking the routers and by flooding the network with extraneous
   traffic.  Please note that the term "router" in this section is used
   as an example of a larger class of active network interconnection
   components that also includes components like firewalls, proxy-
   servers, etc.

   An attack on the router is designed to cause it to stop forwarding
   packets, or to forward them improperly.  The former case may be due
   to a misconfiguration, the injection of a spurious routing update, or
   a "flood attack" (i.e., the router is bombarded with unroutable
   packets, causing its performance to degrade).  A flood attack on a
   network is similar to a flood attack on a router, except that the
   flood packets are usually broadcast.  An ideal flood attack would be
   the injection of a single packet which exploits some known flaw in
   the network nodes and causes them to retransmit the packet, or
   generate error packets, each of which is picked up and repeated by
   another host.  A well chosen attack packet can even generate an
   exponential explosion of transmissions.

   Another classic problem is "spoofing."  In this case, spurious
   routing updates are sent to one or more routers causing them to
   misroute packets.  This differs from a denial of service attack only
   in the purpose behind the spurious route.  In denial of service, the
   object is to make the router unusable; a state which will be quickly
   detected by network users.  In spoofing, the spurious route will
   cause packets to be routed to a host from which an intruder may
   monitor the data in the packets.  These packets are then re-routed to
   their correct destinations.  However, the intruder may or may not
   have altered the contents of the packets.

   The solution to most of these problems is to protect the routing
   update packets sent by the routing protocols in use (e.g., RIP-2,
   OSPF).  There are three levels of protection: clear-text password,
   cryptographic checksum, and encryption.  Passwords offer only minimal
   protection against intruders who do not have direct access to the
   physical networks.  Passwords also offer some protection against
   misconfigured routers (i.e, routers which, out of the box, attempt to
ToP   noToC   RFC2196 - Page 16
   route packets).  The advantage of passwords is that they have a very
   low overhead, in both bandwidth and CPU consumption.  Checksums
   protect against the injection of spurious packets, even if the
   intruder has direct access to the physical network.  Combined with a
   sequence number, or other unique identifier, a checksum can also
   protect again "replay" attacks, wherein an old (but valid at the
   time) routing update is retransmitted by either an intruder or a
   misbehaving router.  The most security is provided by complete
   encryption of sequenced, or uniquely identified, routing updates.
   This prevents an intruder from determining the topology of the
   network.  The disadvantage to encryption is the overhead involved in
   processing the updates.

   RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text
   passwords in their base design specifications.  In addition, there
   are extensions to each base protocol to support MD5 encryption.

   Unfortunately, there is no adequate protection against a flooding
   attack, or a misbehaving host or router which is flooding the
   network.  Fortunately, this type of attack is obvious when it occurs
   and can usually be terminated relatively simply.

3.2.3  Protecting the Services

   There are many types of services and each has its own security
   requirements.  These requirements will vary based on the intended use
   of the service.  For example, a service which should only be usable
   within a site (e.g., NFS) may require different protection mechanisms
   than a service provided for external use. It may be sufficient to
   protect the internal server from external access.  However, a WWW
   server, which provides a home page intended for viewing by users
   anywhere on the Internet, requires built-in protection.  That is, the
   service/protocol/server must provide whatever security may be
   required to prevent unauthorized access and modification of the Web
   database.

   Internal services (i.e., services meant to be used only by users
   within a site) and external services (i.e., services deliberately
   made available to users outside a site) will, in general, have
   protection requirements which differ as previously described.  It is
   therefore wise to isolate the internal services to one set of server
   host computers and the external services to another set of server
   host computers.  That is, internal and external servers should not be
   co-located on the same host computer.  In fact, many sites go so far
ToP   noToC   RFC2196 - Page 17
   as to have one set of subnets (or even different networks) which are
   accessible from the outside and another set which may be accessed
   only within the site.  Of course, there is usually a firewall which
   connects these partitions.  Great care must be taken to ensure that
   such a firewall is operating properly.

   There is increasing interest in using intranets to connect different
   parts of a organization (e.g., divisions of a company). While this
   document generally differentiates between external and internal
   (public and private), sites using intranets should be aware that they
   will need to consider three separations and take appropriate actions
   when designing and offering services. A service offered to an
   intranet would be neither public, nor as completely private as a
   service to a single organizational subunit. Therefore, the service
   would need its own supporting system, separated from both external
   and internal services and networks.

   One form of external service deserves some special consideration, and
   that is anonymous, or guest, access.  This may be either anonymous
   FTP or guest (unauthenticated) login.  It is extremely important to
   ensure that anonymous FTP servers and guest login userids are
   carefully isolated from any hosts and file systems from which outside
   users should be kept.  Another area to which special attention must
   be paid concerns anonymous, writable access.  A site may be legally
   responsible for the content of publicly available information, so
   careful monitoring of the information deposited by anonymous users is
   advised.

   Now we shall consider some of the most popular services: name
   service, password/key service, authentication/proxy service,
   electronic mail, WWW, file transfer, and NFS.  Since these are the
   most frequently used services, they are the most obvious points of
   attack.  Also, a successful attack on one of these services can
   produce disaster all out of proportion to the innocence of the basic
   service.

3.2.3.1  Name Servers (DNS and NIS(+))

   The Internet uses the Domain Name System (DNS) to perform address
   resolution for host and network names.  The Network Information
   Service (NIS) and NIS+ are not used on the global Internet, but are
   subject to the same risks as a DNS server.  Name-to-address
   resolution is critical to the secure operation of any network.  An
   attacker who can successfully control or impersonate a DNS server can
   re-route traffic to subvert security protections.  For example,
   routine traffic can be diverted to a compromised system to be
   monitored; or, users can be tricked into providing authentication
   secrets.  An organization should create well known, protected sites
ToP   noToC   RFC2196 - Page 18
   to act as secondary name servers and protect their DNS masters from
   denial of service attacks using filtering routers.

   Traditionally, DNS has had no security capabilities. In particular,
   the information returned from a query could not be checked for
   modification or verified that it had come from the name server in
   question.  Work has been done to incorporate digital signatures into
   the protocol which, when deployed, will allow the integrity of the
   information to be cryptographically verified (see RFC 2065).

3.2.3.2  Password/Key Servers (NIS(+) and KDC)

   Password and key servers generally protect their vital information
   (i.e., the passwords and keys) with encryption algorithms.  However,
   even a one-way encrypted password can be determined by a dictionary
   attack (wherein common words are encrypted to see if they match the
   stored encryption).  It is therefore necessary to ensure that these
   servers are not accessable by hosts which do not plan to use them for
   the service, and even those hosts should only be able to access the
   service (i.e., general services, such as Telnet and FTP, should not
   be allowed by anyone other than administrators).

3.2.3.3  Authentication/Proxy Servers (SOCKS, FWTK)

   A proxy server provides a number of security enhancements.  It allows
   sites to concentrate services through a specific host to allow
   monitoring, hiding of internal structure, etc.  This funnelling of
   services creates an attractive target for a potential intruder.  The
   type of protection required for a proxy server depends greatly on the
   proxy protocol in use and the services being proxied.  The general
   rule of limiting access only to those hosts which need the services,
   and limiting access by those hosts to only those services, is a good
   starting point.

3.2.3.4  Electronic Mail

   Electronic mail (email) systems have long been a source for intruder
   break-ins because email protocols are among the oldest and most
   widely deployed services.  Also, by it's very nature, an email server
   requires access to the outside world; most email servers accept input
   from any source.  An email server generally consists of two parts: a
   receiving/sending agent and a processing agent.  Since email is
   delivered to all users, and is usually private, the processing agent
   typically requires system (root) privileges to deliver the mail.
   Most email implementations perform both portions of the service,
   which means the receiving agent also has system privileges.  This
   opens several security holes which this document will not describe.
   There are some implementations available which allow a separation of
ToP   noToC   RFC2196 - Page 19
   the two agents.  Such implementations are generally considered more
   secure, but still require careful installation to avoid creating a
   security problem.

3.2.3.5  World Wide Web (WWW)

   The Web is growing in popularity exponentially because of its ease of
   use and the powerful ability to concentrate information services.
   Most WWW servers accept some type of direction and action from the
   persons accessing their services.  The most common example is taking
   a request from a remote user and passing the provided information to
   a program running on the server to process the request.  Some of
   these programs are not written with security in mind and can create
   security holes.  If a Web server is available to the Internet
   community, it is especially important that confidential information
   not be co-located on the same host as that server.  In fact, it is
   recommended that the server have a dedicated host which is not
   "trusted" by other internal hosts.

   Many sites may want to co-locate FTP service with their WWW service.
   But this should only occur for anon-ftp servers that only provide
   information (ftp-get). Anon-ftp puts, in combination with WWW, might
   be dangerous (e.g., they could result in modifications to the
   information your site is publishing to the web) and in themselves
   make the security considerations for each service different.

3.2.3.6  File Transfer (FTP, TFTP)

   FTP and TFTP both allow users to receive and send electronic files in
   a point-to-point manner.  However, FTP requires authentication while
   TFTP requires none. For this reason, TFTP should be avoided as much
   as possible.

   Improperly configured FTP servers can allow intruders to copy,
   replace and delete files at will, anywhere on a host, so it is very
   important to configure this service correctly.   Access to encrypted
   passwords and proprietary data, and the introduction of Trojan horses
   are just a few of the potential security holes that can occur when
   the service is configured incorrectly. FTP servers should reside on
   their own host.  Some sites choose to co-locate FTP with a Web
   server, since the two protocols share common security considerations
   However, the the practice isn't recommended, especially when the FTP
   service allows the deposit of files (see section on WWW above). As
   mentioned in the opening paragraphs of section 3.2.3, services
   offered internally to your site should not be co-located with
   services offered externally.  Each should have its own host.
ToP   noToC   RFC2196 - Page 20
   TFTP does not support the same range of functions as FTP, and has no
   security whatsoever.  This service should only be considered for
   internal use, and then it should be configured in a restricted way so
   that the server only has access to a set of predetermined files
   (instead of every world-readable file on the system).  Probably the
   most common usage of TFTP is for downloading router configuration
   files to a router.  TFTP should reside on its own host, and should
   not be installed on hosts supporting external FTP or Web access.

3.2.3.7  NFS

   The Network File Service allows hosts to share common disks.  NFS is
   frequently used by diskless hosts who depend on a disk server for all
   of their storage needs.  Unfortunately, NFS has no built-in security.
   It is therefore necessary that the NFS server be accessable only by
   those hosts which are using it for service.  This is achieved by
   specifying which hosts the file system is being exported to and in
   what manner (e.g., read-only, read-write, etc.). Filesystems should
   not be exported to any hosts outside the local network since this
   will require that the NFS service be accessible externally. Ideally,
   external access to NFS service should be stopped by a firewall.

3.2.4  Protecting the Protection

   It is amazing how often a site will overlook the most obvious
   weakness in its security by leaving the security server itself open
   to attack.  Based on considerations previously discussed, it should
   be clear that: the security server should not be accessible from
   off-site; should offer minimum access, except for the authentication
   function, to users on-site; and should not be co-located with any
   other servers.  Further, all access to the node, including access to
   the service itself, should be logged to provide a "paper trail" in
   the event of a security breach.

3.3  Firewalls

   One of the most widely deployed and publicized security measures in
   use on the Internet is a "firewall."  Firewalls have been given the
   reputation of a general panacea for many, if not all, of the Internet
   security issues.  They are not.  Firewalls are just another tool in
   the quest for system security.  They provide a certain level of
   protection and are, in general, a way of implementing security policy
   at the network level.  The level of security that a firewall provides
   can vary as much as the level of security on a particular machine.
   There are the traditional trade-offs between security, ease of use,
   cost, complexity, etc.
ToP   noToC   RFC2196 - Page 21
   A firewall is any one of several mechanisms used to control and watch
   access to and from a network for the purpose of protecting it.  A
   firewall acts as a gateway through which all traffic to and from the
   protected network and/or systems passes.  Firewalls help to place
   limitations on the amount and type of communication that takes place
   between the protected network and the another network (e.g., the
   Internet, or another piece of the site's network).

   A firewall is generally a way to build a wall between one part of a
   network, a company's internal network, for example, and another part,
   the global Internet, for example.  The unique feature about this wall
   is that there needs to be ways for some traffic with particular
   characteristics to pass through carefully monitored doors
   ("gateways").  The difficult part is establishing the criteria by
   which the packets are allowed or denied access through the doors.
   Books written on firewalls use different terminology to describe the
   various forms of firewalls. This can be confusing to system
   administrators who are not familiar with firewalls. The thing to note
   here is that there is no fixed terminology for the description of
   firewalls.

   Firewalls are not always, or even typically, a single machine.
   Rather, firewalls are often a combination of routers, network
   segments, and host computers.  Therefore, for the purposes of this
   discussion, the term "firewall" can consist of more than one physical
   device.  Firewalls are typically built using two different
   components, filtering routers and proxy servers.

   Filtering routers are the easiest component to conceptualize in a
   firewall.  A router moves data back and forth between two (or more)
   different networks.  A "normal" router takes a packet from network A
   and "routes" it to its destination on network B.  A filtering router
   does the same thing but decides not only how to route the packet, but
   whether it should route the packet.  This is done by installing a
   series of filters by which the router decides what to do with any
   given packet of data.

   A discussion concerning capabilities of a particular brand of router,
   running a particular software version is outside the scope of this
   document.  However, when evaluating a router to be used for filtering
   packets, the following criteria can be important when implementing a
   filtering policy:  source and destination IP address, source and
   destination TCP port numbers, state of the TCP "ack" bit, UDP source
   and destination port numbers, and direction of packet flow (i.e.. A-
   >B or B->A).  Other information necessary to construct a secure
   filtering scheme are whether the router reorders filter instructions
   (designed to optimize filters, this can sometimes change the meaning
   and cause unintended access), and whether it is possible to apply
ToP   noToC   RFC2196 - Page 22
   filters for inbound and outbound packets on each interface (if the
   router filters only outbound packets then the router is "outside" of
   its filters and may be more vulnerable to attack).  In addition to
   the router being vulnerable, this distinction between applying
   filters on inbound or outbound packets is especially relevant for
   routers with more than 2 interfaces.  Other important issues are the
   ability to create filters based on IP header options and the fragment
   state of a packet.  Building a good filter can be very difficult and
   requires a good understanding of the type of services (protocols)
   that will be filtered.

   For better security, the filters usually restrict access between the
   two connected nets to just one host, the bastion host.  It is only
   possible to access the other network via this bastion host.  As only
   this host, rather than a few hundred hosts, can get attacked, it is
   easier to maintain a certain level of security because only this host
   has to be protected very carefully.  To make resources available to
   legitimate users across this firewall, services have to be forwarded
   by the bastion host.  Some servers have forwarding built in (like
   DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP,
   etc.), proxy servers can be used to allow access to the resources
   across the firewall in a secure way.

   A proxy server is way to concentrate application services through a
   single machine.  There is typically a single machine (the bastion
   host) that acts as a proxy server for a variety of protocols (Telnet,
   SMTP, FTP, HTTP, etc.) but there can be individual host computers for
   each service.  Instead of connecting directly to an external server,
   the client connects to the proxy server which in turn initiates a
   connection to the requested external server.  Depending on the type
   of proxy server used, it is possible to configure internal clients to
   perform this redirection automatically, without knowledge to the
   user, others might require that the user connect directly to the
   proxy server and then initiate the connection through a specified
   format.

   There are significant security benefits which can be derived from
   using proxy servers.  It is possible to add access control lists to
   protocols, requiring users or systems to provide some level of
   authentication before access is granted.  Smarter proxy servers,
   sometimes called Application Layer Gateways (ALGs), can be written
   which understand specific protocols and can be configured to block
   only subsections of the protocol.  For example, an ALG for FTP can
   tell the difference between the "put" command and the "get" command;
   an organization may wish to allow users to "get" files from the
   Internet, but not be able to "put" internal files on a remote server.
   By contrast, a filtering router could either block all FTP access, or
   none, but not a subset.
ToP   noToC   RFC2196 - Page 23
   Proxy servers can also be configured to encrypt data streams based on
   a variety of parameters.  An organization might use this feature to
   allow encrypted connections between two locations whose sole access
   points are on the Internet.

   Firewalls are typically thought of as a way to keep intruders out,
   but they are also often used as a way to let legitimate users into a
   site.  There are many examples where a valid user might need to
   regularly access the "home" site while on travel to trade shows and
   conferences, etc.  Access to the Internet is often available but may
   be through an untrusted machine or network.  A correctly configured
   proxy server can allow the correct users into the site while still
   denying access to other users.

   The current best effort in firewall techniques is found using a
   combination of a pair of screening routers with one or more proxy
   servers on a network between the two routers.  This setup allows the
   external router to block off any attempts to use the underlying IP
   layer to break security (IP spoofing, source routing, packet
   fragments), while allowing the proxy server to handle potential
   security holes in the higher layer protocols.  The internal router's
   purpose is to block all traffic except to the proxy server.  If this
   setup is rigidly implemented, a high level of security can be
   achieved.

   Most firewalls provide logging which can be tuned to make security
   administration of the network more convenient.  Logging may be
   centralized and the system may be configured to send out alerts for
   abnormal conditions.  It is important to regularly monitor these logs
   for any signs of intrusions or break-in attempts.  Since some
   intruders will attempt to cover their tracks by editing logs, it is
   desirable to protect these logs.  A variety of methods is available,
   including: write once, read many (WORM) drives; papers logs; and
   centralized logging via the "syslog" utility.  Another technique is
   to use a "fake" serial printer, but have the serial port connected to
   an isolated machine or PC which keeps the logs.

   Firewalls are available in a wide range of quality and strengths.
   Commercial packages start at approximately $10,000US and go up to
   over $250,000US.  "Home grown" firewalls can be built for smaller
   amounts of capital.  It should be remembered that the correct setup
   of a firewall (commercial or homegrown) requires a significant amount
   of skill and knowledge of TCP/IP.  Both types require regular
   maintenance, installation of software patches and updates, and
   regular monitoring.  When budgeting for a firewall, these additional
   costs should be considered in addition to the cost of the physical
   elements of the firewall.
ToP   noToC   RFC2196 - Page 24
   As an aside, building a "home grown" firewall requires a significant
   amount of skill and knowledge of TCP/IP.  It should not be trivially
   attempted because a perceived sense of security is worse in the long
   run than knowing that there is no security.  As with all security
   measures, it is important to decide on the threat, the value of the
   assets to be protected, and the costs to implement security.

   A final note about firewalls.  They can be a great aid when
   implementing security for a site and they protect against a large
   variety of attacks.  But it is important to keep in mind that they
   are only one part of the solution.  They cannot protect your site
   against all types of attack.



(page 24 continued on part 2)

Next Section