rfc2267.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                        P. Ferguson
Request for Comments: 2267                           Cisco Systems, Inc.
Category: Informational                                         D. Senie
                                                          BlazeNet, Inc.
                                                            January 1998


                       Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ
                       IP Source Address Spoofing

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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   Recent occurrences of various Denial of Service (DoS) attacks which
   have employed forged source addresses have proven to be a troublesome
   issue for Internet Service Providers and the Internet community
   overall.  This paper discusses a simple, effective, and
   straightforward method for using ingress traffic filtering to
   prohibit DoS attacks which use forged IP addresses to be propagated
   from 'behind' an Internet Service Provider's (ISP) aggregation point.

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  2
    2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  2
    3.  Restricting forged traffic . . . . . . . . . . . . . . . .  5
    4.  Further capabilities for networking equipment. . . . . . .  6
    5.  Liabilities. . . . . . . . . . . . . . . . . . . . . . . .  6
    6.  Summary. . . . . . . . . . . . . . . . . . . . . . . . . .  7
    7.  Security Considerations. . . . . . . . . . . . . . . . . .  7
    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  8
    9.  References . . . . . . . . . . . . . . . . . . . . . . . .  8
   10.  Authors' Addresses . . . . . . . . . . . . . . . . . . . .  9
   11.  Full Copyright Statement . . . . . . . . . . . . . . . . . 10







Ferguson & Senie             Informational                      [Page 1]

RFC 2267               Network Ingress Filtering            January 1998


1. Introduction

   A resurgence of Denial of Service Attacks [1] aimed at various
   targets in the Internet have produced new challenges within the
   Internet Service Provider (ISP) and network security communities to
   find new and innovative methods to mitigate these types of attacks.
   The difficulties in reaching this goal are numerous; some simple
   tools already exist to limit the effectiveness and scope of these
   attacks, but they have not been widely implemented.

   This method of attack has been known for some time. Defending against
   it, however, has been an ongoing concern. Bill Cheswick is quoted in
   [2] as saying that he pulled a chapter from his book, "Firewalls and
   Internet Security" [3], at the last minute because there was no way
   for an administrator of the system under attack to effectively defend
   the system. By mentioning the method, he was concerned about
   encouraging it's use.

   While the filtering method discussed in this document does
   absolutely nothing to protect against flooding attacks which
   originate from valid prefixes (IP addresses), it will prohibit an
   attacker within the originating network from launching an attack of
   this nature using forged source addresses that do not conform to
   ingress filtering rules. All providers of Internet connectivity are
   urged to implement filtering described in this document to prohibit
   attackers from  using forged source addresses which do not reside
   within a range of legitimately advertised prefixes.  In other words,
   if an ISP is aggregating routing announcements for multiple
   downstream networks, strict traffic filtering should be used to
   prohibit traffic which claims to have originated from outside of
   these aggregated announcements.

   An additional benefit of implementing this type of filtering is that
   it enables the originator to be easily traced to it's true source,
   since the attacker would have to use a valid, and legitimately
   reachable, source address.

2. Background

   A simplified diagram of the TCP SYN flooding problem is depicted
   below:

                                                       9.0.0.0/8
    host <----- router <--- Internet <----- router <-- attacker

             TCP/SYN
         <---------------------------------------------
               Source: 192.168.0.4/32



Ferguson & Senie             Informational                      [Page 2]

RFC 2267               Network Ingress Filtering            January 1998


    SYN/ACK
    no route
             TCP/SYN
         <---------------------------------------------
               Source: 10.0.0.13/32
    SYN/ACK
    no route
             TCP/SYN
         <---------------------------------------------
               Source: 172.16.0.2/32
    SYN/ACK
    no route

    [etc.]

    Assume:

    o The "host" is the targeted machine.

    o The attacker resides within the "valid" prefix, 9.0.0.0/8.

    o The attacker launches the attack using randomly changing source
      addresses; in this example, the source addresses are depicted as
      from within [4], which are not generally present in the global
      Internet routing tables, and therefore, unreachable. However, any
      unreachable prefix could be used to perpetrate this attack
      method.

   Also worthy of mention is a case wherein the source address is forged
   to appear to have originated from within another legitimate network
   which appears in the global routing table(s). For example, an
   attacker using a valid network address could wreak havoc by  making
   the attack appear to come from an organization which did not, in
   fact, originate the attack and was completely innocent. In such
   cases, the administrator of a system under attack may be inclined to
   filter all traffic coming from the apparent attack source. Adding
   such a filter would then result in a denial of service to
   legitimate, non-hostile end-systems. In this case, the administrator
   of the system under attack unwittingly becomes an accomplice of the
   attacker.

   Further complicating matters, TCP SYN flood attacks will result in
   SYN-ACK packets being sent to one or many hosts which have no
   involvement in the attack, but which become secondary victims. This
   allows the attacker to abuse two or more systems at once.






Ferguson & Senie             Informational                      [Page 3]

RFC 2267               Network Ingress Filtering            January 1998


   Similar attacks have been attempted using UDP and ICMP flooding.
   The former attack (UDP flooding) uses forged packets to try and
   connect the chargen UDP service to the echo UDP service at another
   site.  Systems administrators should NEVER allow UDP packets destined
   for system diagnostic ports from outside of their administrative
   domain to reach their systems. The latter attack (ICMP flooding),
   uses an insidious feature in IP subnet broadcast replication
   mechanics. This attack relies on a router serving a large multi-
   access broadcast network to frame an IP broadcast address (such as
   one destined for 10.255.255.255) into a Layer 2 broadcast frame (for
   ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-layer
   hardware, specifically) will only listen to a select number of
   addresses in normal operation.  The one MAC address that all devices
   share in common in normal operation is the media broadcast, or
   FF:FF:FF:FF:FF:FF.  In this case, a device will take the packet and
   send an interrupt for processing. Thus, a flood of these broadcast
   frames will consume all available resources on an end-system [9]. It
   is perhaps prudent that system administrators should consider
   ensuring that their border routers do not allow directed broadcast
   packets to be forwarded through their routers as a default.

   When an TCP SYN attack is launched using unreachable source address,
   the target host attempts to reserve resources waiting for a
   response.  The attacker repeatedly changes the bogus source address
   on each new packet sent, thus exhausting additional host resources.

   Alternatively, if the attacker uses someone else's valid host
   address as the source address, the system under attack will send a
   large number of SYN/ACK packets to what it believes is the originator
   of the connection establishment sequence. In this fashion, the
   attacker does damage to two systems: the destination target system,
   as well  as the system which is actually using the spoofed address in
   the global routing system.

   The result of both attack methods is extremely degraded performance,
   or worse, a system crash.

   In response to this threat, most operating system vendors have
   modified their software to allow the targeted servers to sustain
   attacks with very high connection attempt rates. This is a welcome
   and necessary part of the solution to the problem. Ingress filtering
   will take time to be implemented pervasively and be fully effective,
   but the extensions to the operating systems can be implemented
   quickly. This combination should prove effective against source
   address spoofing. See [1] for vendor and platform software upgrade
   information.





Ferguson & Senie             Informational                      [Page 4]

RFC 2267               Network Ingress Filtering            January 1998


3. Restricting forged traffic

   The problems encountered with this type of attack are numerous, and
   involve shortcomings in host software implementations, routing
   methodologies, and the TCP/IP protocols themselves.  However, by
   restricting transit traffic which originates from a downstream
   network to known, and intentionally advertised, prefix(es), the
   problem of source address spoofing can be virtually eliminated in
   this attack scenario.

                               11.0.0.0/8
                                   /
                               router 1
                                 /
                                /
                               /                          9.0.0.0/8
         ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
          A          B         C        D         2
                    /
                   /
                  /
              router 3
                /
            12.0.0.0/8


   In the example above, the attacker resides within 9.0.0.0/8, which is
   provided Internet connectivity by ISP D.  An input traffic filter on
   the ingress (input) link of "router 2", which provides connectivity
   to the attacker's network, restricts traffic to allow only traffic
   originating from source addresses within the 9.0.0.0/8 prefix, and
   prohibits an attacker from using "invalid" source addresses which
   reside outside of this prefix range.

   In other words, the ingress filter on "router 2" above would check:

    IF    packet's source address from within 9.0.0.0/8
    THEN  forward as appropriate

    IF    packet's source address is anything else
    THEN  deny packet

   Network administrators should log information on packets which are
   dropped. This then provides a basis for monitoring any suspicious
   activity.






Ferguson & Senie             Informational                      [Page 5]