rfc3013.txt

RFC 的详细文档！

   indeed from those addresses that are allocated for private Internets
   [RFC1918].  In addition, forged source addresses are frequently used
   in spoof-based attacks in order to exploit a trust relationship
   between hosts.

   To reduce the incidence of attacks that rely on forged source
   addresses ISPs should do the following.  At the boundary router with
   each of their customers they should proactively filter all traffic
   coming from the customer that has a source address of something other
   than the addresses that have been assigned to that customer.  For a
   more detailed discussion of this topic see [RFC2827].

   There are (rare) circumstances where ingress filtering is not
   currently possible, for example on large aggregation routers that
   cannot take the additional load of applying packet filters.  In
   addition, such filtering can cause difficulty for mobile users.
   Hence, while the use of this technique to prevent spoofing is
   strongly encouraged, it may not always be feasible.

   In these rare cases where ingress filtering at the interface between
   the customer and the ISP is not possible, the customer should be
   encouraged to implement ingress filtering within their networks.  In
   general filtering should be done as close to the actual hosts as
   possible.



Killalea                 Best Current Practice                  [Page 7]

RFC 3013                Recommended ISP Security           November 2000


4.4 Egress Filtering on Source Address

   The direction of such filtering is from the Internet to the edge site
   (customer).

   There are many applications in widespread use on the Internet today
   that grant trust to other hosts based only on ip address (e.g., the
   Berkeley 'r' commands).  These are susceptible to IP spoofing, as
   described in [CA-95.01.IP.spoofing].  In addition, there are
   vulnerabilities that depend on the misuse of supposedly local
   addresses, such as 'land' as described in [CA-97.28.Teardrop_Land].

   To reduce the exposure of their customers to attacks that rely on
   forged source addresses ISPs should do the following.  At the
   boundary router with each of their customers they should proactively
   filter all traffic going to the customer that has a source address of
   any of the addresses that have been assigned to that customer.

   The circumstances described in 4.3 in which ingress filtering isn't
   feasible apply similarly to egress filtering.

4.5 Route Filtering

   Excessive routing updates can be leveraged by an attacker as a base
   load on which to build a Denial of Service attack.  At the very least
   they will result in performance degradation.

   ISPs should filter the routing announcements they hear, for example
   to ignore routes to addresses allocated for private Internets, to
   avoid bogus routes and to implement "BGP Route Flap Dampening"
   [RFC2439] and aggregation policy.

   ISPs should implement techniques that reduce the risk of putting
   excessive load on routing in other parts of the network.  These
   include 'nailed up' routes, aggressive aggregation and route
   dampening, all of which lower the impact on others when your internal
   routing changes in a way that isn't relevant to them.

4.6 Directed Broadcast

   The IP protocol allows for directed broadcast, the sending of a
   packet across the network to be broadcast on to a specific subnet.
   Very few practical uses for this feature exist, but several different
   security attacks (primarily Denial of Service attacks making use of
   the packet multiplication effect of the broadcast) use it.
   Therefore, routers connected to a broadcast medium MUST NOT be
   configured to allow directed broadcasts onto that medium [RFC2644].




Killalea                 Best Current Practice                  [Page 8]

RFC 3013                Recommended ISP Security           November 2000


5 Systems Infrastructure

   The way an ISP manages their systems is crucial to the security and
   reliability of their network.  A breach of their systems may
   minimally lead to degraded performance or functionality, but could
   lead to loss of data or the risk of traffic being eavesdropped (thus
   leading to 'man-in-the-middle' attacks).

   It's widely accepted that it's easier to build secure systems if
   different services (such as mail, news and web-hosting) are kept on
   separate systems.

5.1 System Management

   All systems that perform critical ISP functions such as mail, news
   and web-hosting, should be restricted such that access to them is
   only available to the administrators of those services.  That access
   should be granted only following strong authentication, and should
   take place over an encrypted link.  Only the ports on which those
   services listen should be reachable from outside of the ISP's systems
   networks.

   ISPs should stay up to date for more secure methods of providing
   services as they become available (e.g., IMAP/POP AUTHorize Extension
   for Simple Challenge/Response, [RFC2195]).

5.2 No Systems on Transit Networks

   Systems should not be attached to transit network segments.

5.3 Open Mail Relay

   ISPs should take active steps to prevent their mail infrastructure
   from being used by 'spammers' to inject Unsolicited Bulk E-mail (UBE)
   while hiding the sender's identity [RFC2505].  While not all
   preventive steps are appropriate for every site, the most effective
   site-appropriate methods should be used.

   ISPs should also strongly encourage their customers to take the
   necessary steps to prevent this activity on their own systems.

5.4 Message Submission

   Message submissions should be authenticated using the AUTH SMTP
   service extension as described in the "SMTP Service Extension for
   Authentication" [RFC2554].





Killalea                 Best Current Practice                  [Page 9]

RFC 3013                Recommended ISP Security           November 2000


   SMTP AUTH is preferred over IP address-based submission restrictions
   in that it gives the ISP's customers the flexibility of being able to
   submit mail even when not connected through the ISP's network (for
   example, while at work), is more resistant to spoofing, and can be
   upgraded to newer authentication mechanisms as they become available.

   In addition, to facilitate the enforcement of security policy, it is
   strongly recommended that messages be submitted using the MAIL SUBMIT
   port (587) as discussed in "Message Submission" [RFC2476], rather
   than through the SMTP port (25).  In this way the SMTP port (25) can
   be restricted to local delivery only.

   The reason for this is to be able to differentiate between inbound
   local delivery and relay (i.e., allow customers to send email via the
   ISP's SMTP service to arbitrary receivers on the Internet).  Non-
   authenticated SMTP should only be allowed for local delivery.

   As more and more mail clients support both SMTP AUTH and the message
   submission port (either explicitly or by configuring the SMTP port),
   ISPs may find it useful to require that customers submit messages
   using both the submission port and SMTP AUTH; permitting only inbound
   mail on port 25.

   These measures (SMTP AUTH and the submission port) not only protect
   the ISP from serving as a UBE injection point via third-party relay,
   but also help in tracking accountability for message submission in
   the case where a customer sends UBE.

6 References

   [CA-95.01.IP.spoofing]   "IP Spoofing Attacks and Hijacked Terminal
                            Connections",
                            ftp://info.cert.org/pub/cert_advisories/

   [CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks",
                            ftp://info.cert.org/pub/cert_advisories/

   [DPR1998]                The UK "Data Protection Act 1998 (c. 29)",
                            http://www.hmso.gov.uk/acts/acts1998/
                            19980029.htm

   [RFC1786]                Bates, T., Gerich, E., Joncheray, L.,
                            Jouanigot, J., Karrenberg, D., Terpstra, M.
                            and J. Yu, "Representation of IP Routing
                            Policies in a Routing Registry (ripe-81++)",
                            RFC 1786, March 1995.





Killalea                 Best Current Practice                 [Page 10]

RFC 3013                Recommended ISP Security           November 2000


   [RFC1834]                Gargano, J. and K. Weiss, "Whois and Network
                            Information Lookup Service", RFC 1834,
                            August 1995.

   [RFC1835]                Deutsch, P., Schoultz, R., Faltstrom, P. and
                            C. Weider, "Architecture of the WHOIS++
                            service", RFC 1835, August 1995.

   [RFC1918]                Rekhter, Y., Moskowitz, B., Karrenberg, D.,
                            de Groot, G. J. and E. Lear, "Address
                            Allocation for Private Internets", BCP 5,
                            RFC 1918, February 1996.

   [RFC2119]                Bradner, S., "Key words for use in RFCs to
                            Indicate Requirement Levels", BCP 14, RFC
                            2119, March 1997.

   [RFC2142]                Crocker, D., "Mailbox Names for Common
                            Services, Roles and Functions", RFC 2142,
                            May 1997.

   [RFC2195]                Klensin, J., Catoe, R. and P. Krumviede,
                            "IMAP/POP AUTHorize Extension for Simple
                            Challenge/Response", RFC 2195, September
                            1997.

   [RFC2196]                Fraser, B., "Site Security Handbook", FYI 8,
                            RFC 2196, September 1997.

   [RFC2350]                Brownlee, N. and  E. Guttman, "Expectations
                            for Computer Security Incident Response",
                            BCP 21, RFC 2350, June 1998.

   [RFC2385]                Heffernan, A., "Protection of BGP Sessions
                            via the TCP MD5 Signature Option", RFC 2385,
                            August 1998.

   [RFC2439]                Chandra R., Govindan R. and C. Villamizar,
                            "BGP Route Flap Damping", RFC 2439, November
                            1998.

   [RFC2476]                Gellens R. and J. Klensin, "Message
                            Submission", RFC 2476, December 1998.

   [RFC2505]                Lindberg, G., "Anti-Spam Recommendations for
                            SMTP MTAs", BCP 30, RFC 2505, February 1999.





Killalea                 Best Current Practice                 [Page 11]

RFC 3013                Recommended ISP Security           November 2000


   [RFC2554]                Myers, J., "SMTP Service Extension for
                            Authentication", RFC 2554, March 1999.

   [RFC2644]                Senie, D., "Changing the Default for
                            Directed Broadcasts in Routers", BCP 34, RFC
                            2644, August 1999.

   [RFC2827]                Ferguson, P. and D. Senie, "Network Ingress
                            Filtering: Defeating Denial of Service
                            Attacks which employ IP Source Address
                            Spoofing", BCP 38, RFC 2827, May 2000.

7 Acknowledgements

   I gratefully acknowledge the constructive comments received from
   Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall
   Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski,
   Michael A. Patton, Don Stikvoort and Bill Woodcock.

8 Security Considerations

   This entire document discusses security issues.

9 Author's Address

   Tom Killalea
   Lisi/n na Bro/n
   Be/al A/tha na Muice
   Co. Mhaigh Eo
   IRELAND

   Phone: [phone]
   EMail: [e-mail]


















Killalea                 Best Current Practice                 [Page 12]

RFC 3013                Recommended ISP Security           November 2000


10 Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Killalea                 Best Current Practice                 [Page 13]