rfc2196.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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



Fraser, Ed.                Informational                       [Page 15]

RFC 2196              Site Security Handbook              September 1997


   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







Fraser, Ed.                Informational                       [Page 16]

RFC 2196              Site Security Handbook              September 1997


   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



Fraser, Ed.                Informational                       [Page 17]

RFC 2196              Site Security Handbook              September 1997


   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



Fraser, Ed.                Informational                       [Page 18]

RFC 2196              Site Security Handbook              September 1997


   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.





Fraser, Ed.                Informational                       [Page 19]

RFC 2196              Site Security Handbook              September 1997


   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