Network Working Group T. Killalea
Request for Comments: 3013 neart.org
BCP: 46 November 2000
Category: Best Current Practice
Network Working Group T. Killalea
Request for Comments: 3013 neart.org
BCP: 46 November 2000
Category: Best Current Practice
Recommended Internet Service Provider Security Services and Procedures
推荐的Internet服务提供商安全服务和程序
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security.
本文件旨在表达IETF代表的工程界对互联网服务提供商（ISP）在安全方面的期望。
It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers.
本文件的目的不是定义一套适用于所有ISP的要求，而是提高ISP对社区期望的认识，并为社区提供一个与当前和潜在服务提供商讨论安全期望的框架。
Table of Contents
目录
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions Used in this Document. . . . . . . . . . . . . . 3
2 Communication. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Contact Information. . . . . . . . . . . . . . . . . . . . . 3
2.2 Information Sharing. . . . . . . . . . . . . . . . . . . . . 4
2.3 Secure Channels. . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Notification of Vulnerabilities and Reporting Incidents. . . 4
2.5 ISPs and Computer Security Incident Response Teams (CSIRTs). 5
3 Appropriate Use Policy . . . . . . . . . . . . . . . . . . . . . 5
3.1 Announcement of Policy . . . . . . . . . . . . . . . . . . . 6
3.2 Sanctions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Data Protection. . . . . . . . . . . . . . . . . . . . . . . 6
4 Network Infrastructure . . . . . . . . . . . . . . . . . . . . . 6
4.1 Registry Data Maintenance. . . . . . . . . . . . . . . . . . 6
4.2 Routing Infrastructure . . . . . . . . . . . . . . . . . . . 7
4.3 Ingress Filtering on Source Address. . . . . . . . . . . . . 7
4.4 Egress Filtering on Source Address . . . . . . . . . . . . . 8
4.5 Route Filtering. . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Directed Broadcast . . . . . . . . . . . . . . . . . . . . . 8
5 Systems Infrastructure . . . . . . . . . . . . . . . . . . . . . 9
5.1 System Management. . . . . . . . . . . . . . . . . . . . . . 9
5.2 No Systems on Transit Networks . . . . . . . . . . . . . . . 9
5.3 Open Mail Relay. . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Message Submission . . . . . . . . . . . . . . . . . . . . . 9
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . .10
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .12
8 Security Considerations. . . . . . . . . . . . . . . . . . . . .12
9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .12
10 Full Copyright Statement. . . . . . . . . . . . . . . . . . . .13
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions Used in this Document. . . . . . . . . . . . . . 3
2 Communication. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Contact Information. . . . . . . . . . . . . . . . . . . . . 3
2.2 Information Sharing. . . . . . . . . . . . . . . . . . . . . 4
2.3 Secure Channels. . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Notification of Vulnerabilities and Reporting Incidents. . . 4
2.5 ISPs and Computer Security Incident Response Teams (CSIRTs). 5
3 Appropriate Use Policy . . . . . . . . . . . . . . . . . . . . . 5
3.1 Announcement of Policy . . . . . . . . . . . . . . . . . . . 6
3.2 Sanctions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Data Protection. . . . . . . . . . . . . . . . . . . . . . . 6
4 Network Infrastructure . . . . . . . . . . . . . . . . . . . . . 6
4.1 Registry Data Maintenance. . . . . . . . . . . . . . . . . . 6
4.2 Routing Infrastructure . . . . . . . . . . . . . . . . . . . 7
4.3 Ingress Filtering on Source Address. . . . . . . . . . . . . 7
4.4 Egress Filtering on Source Address . . . . . . . . . . . . . 8
4.5 Route Filtering. . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Directed Broadcast . . . . . . . . . . . . . . . . . . . . . 8
5 Systems Infrastructure . . . . . . . . . . . . . . . . . . . . . 9
5.1 System Management. . . . . . . . . . . . . . . . . . . . . . 9
5.2 No Systems on Transit Networks . . . . . . . . . . . . . . . 9
5.3 Open Mail Relay. . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Message Submission . . . . . . . . . . . . . . . . . . . . . 9
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . .10
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .12
8 Security Considerations. . . . . . . . . . . . . . . . . . . . .12
9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .12
10 Full Copyright Statement. . . . . . . . . . . . . . . . . . . .13
1 Introduction
1导言
The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document is addressed to ISPs.
本文件旨在表达IETF代表的工程界对互联网服务提供商（ISP）在安全方面的期望。本文件寄往ISP。
By informing ISPs of what this community hopes and expects of them, the community hopes to encourage ISPs to become proactive in making security not only a priority, but something to which they point with pride when selling their services.
通过告知ISP社区对他们的希望和期望，社区希望鼓励ISP积极主动地将安全性不仅作为优先事项，而且是他们在销售服务时引以为豪的事情。
Under no circumstances is it the intention of this document to dictate business practices.
在任何情况下，本文件均无意规定商业惯例。
In this document we define ISPs to include organisations in the business of providing Internet connectivity or other Internet services including but not restricted to web hosting services, content providers and e-mail services. We do not include in our definition of an ISP organisations providing those services for their own purposes.
在本文件中，我们将ISP定义为包括提供互联网连接或其他互联网服务的组织，包括但不限于网站托管服务、内容提供商和电子邮件服务。我们对ISP的定义中不包括为其自身目的提供这些服务的组织。
This document is offered as a set of recommendations to ISPs regarding what security and attack management arrangements should be supported, and as advice to users regarding what they should expect from a high quality service provider. It is in no sense normative in its own right. In time it is likely to become dated, and other expectations may arise. However, it does represent a snapshot of the recommendations of a set of professionals in the field at a given point in the development of the Internet and its technology.
本文件作为一套建议提供给ISP，说明应支持什么样的安全和攻击管理安排，并作为建议提供给用户，说明他们应该从高质量服务提供商那里得到什么。它本身并不是规范性的。随着时间的推移，它可能会过时，并可能出现其他预期。然而，它确实代表了在互联网及其技术发展的特定阶段，该领域的一组专业人士的建议。
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必需”、“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于表示需求水平的关键词”中的描述进行解释[RFC2119]。
2 Communication
2通信
The community's most significant security-related expectations of ISPs relate to the availability of communication channels for dealing with security incidents.
社区对ISP最重要的安全相关期望与处理安全事件的通信渠道的可用性有关。
ISPs SHOULD adhere to [RFC2142], which defines the mailbox SECURITY for network security issues, ABUSE for issues relating to inappropriate public behaviour and NOC for issues relating to network infrastructure. It also lists additional mailboxes that are defined for receiving queries and reports relating to specific services.
ISP应遵守[RFC2142]，其中定义了网络安全问题的邮箱安全、不当公共行为相关问题的滥用以及网络基础设施相关问题的NOC。它还列出了为接收与特定服务相关的查询和报告而定义的其他邮箱。
ISPs may consider using common URLs for expanded details on the above (e.g., http://www.ISP-name-here.net/security/).
ISPS可以考虑使用普通URL来扩展上面的细节（例如，http://www.ISP-name-here.net/security/).
In addition, ISPs have a duty to make sure that their contact information, in Whois, in routing registries [RFC1786] or in any other repository, is complete, accurate and reachable.
此外，ISP有责任确保其在Whois、路由注册中心[RFC1786]或任何其他存储库中的联系信息完整、准确且可访问。
ISPs SHOULD have clear policies and procedures on the sharing of information about a security incident with their customers, with other ISPs, with Incident Response Teams, with law enforcement or with the press and general public.
ISP应制定明确的政策和程序，与客户、其他ISP、事件响应团队、执法部门或媒体和公众共享安全事件信息。
ISPs should have processes in place to deal with security incidents that traverse the boundaries between them and other ISPs.
ISP应该有适当的流程来处理跨越其与其他ISP之间边界的安全事件。
ISPs SHOULD be able to conduct such communication over a secure channel. Note, however, that in some jurisdictions secure channels might not be permitted.
ISP应能够通过安全通道进行此类通信。但是，请注意，在某些司法管辖区，可能不允许使用安全通道。
ISPs SHOULD be proactive in notifying customers of security vulnerabilities in the services they provide. In addition, as new vulnerabilities in systems and software are discovered they should indicate whether their services are threatened by these risks.
ISP应主动通知客户其提供的服务存在安全漏洞。此外，当系统和软件中发现新的漏洞时，他们应指出其服务是否受到这些风险的威胁。
When security incidents occur that affect components of an ISP's infrastructure the ISP should promptly report to their customers
当发生影响ISP基础设施组件的安全事件时，ISP应立即向其客户报告
- who is coordinating response to the incident
- 谁在协调对这一事件的反应
- the vulnerability
- 脆弱性
- how service was affected
- 服务如何受到影响
- what is being done to respond to the incident
- 正在采取什么措施来应对这一事件
- whether customer data may have been compromised
- 客户数据是否可能已被泄露
- what is being done to eliminate the vulnerability
- 正在采取哪些措施消除该漏洞
- the expected schedule for response, assuming it can be predicted
- 响应的预期时间表，假设可以预测
Many ISPs have established procedures for notifying customers of outages and service degradation. It is reasonable for the ISP to use these channels for reporting security-related incidents. In such cases, the customer's security point of contact might not be the person notified. Rather, the normal point of contact will receive the report. Customers should be aware of this and make sure to route such notifications appropriately.
许多ISP都建立了通知客户停机和服务降级的程序。ISP使用这些渠道报告安全相关事件是合理的。在这种情况下，客户的安全联系人可能不是被通知的人。相反，正常的联络点将收到报告。客户应意识到这一点，并确保适当发送此类通知。
2.5 Incident Response and Computer Security Incident Response Teams (CSIRTs)
2.5 事件响应和计算机安全事件响应团队（CSIRT）
A Computer Security Incident Response Team (CSIRT) is a team that performs, coordinates, and supports the response to security incidents that involve sites within a defined constituency. The Internet community's expectations of CSIRTs are described in "Expectations for Computer Security Incident Response" [RFC2350].
计算机安全事件响应团队（CSIRT）是一个执行、协调和支持对涉及定义选区内站点的安全事件的响应的团队。互联网社区对CSIRT的期望见“计算机安全事件响应的期望”[RFC2350]。
Whether or not an ISP has a CSIRT, they should have a well-advertised way to receive and handle reported incidents from their customers. In addition, they should clearly document their capability to respond to reported incidents, and should indicate if there is any CSIRT whose constituency would include the customer and to whom incidents could be reported.
无论ISP是否拥有CSIRT，他们都应该有一种广为人知的方式来接收和处理客户报告的事件。此外，他们应清楚地记录其对报告的事件作出响应的能力，并应说明是否存在任何CSIRT，其服务对象将包括客户以及可以向谁报告事件。
Some ISPs have CSIRTs. However it should not be assumed that either the ISP's connectivity customers or a site being attacked by a customer of that ISP can automatically avail themselves of the services of the ISP's CSIRT. ISP CSIRTs are frequently provided as an added-cost service, with the team defining as their constituency only those who specifically subscribe to (and perhaps pay for) Incident Response services.
一些ISP有CSIRT。但是，不应假设ISP的连接客户或受到该ISP客户攻击的站点能够自动利用ISP的CSIRT服务。ISP CSIRT通常作为附加成本服务提供，团队只将那些专门订阅（或者付费）事件响应服务的人定义为他们的支持者。
Thus it's important for ISPs to publish what incident response and security resources they make available to customers, so that the customers can define their incident response escalation chain BEFORE an incident occurs.
因此，ISP必须公布向客户提供的事件响应和安全资源，以便客户能够在事件发生之前定义其事件响应升级链。
Customers should find out whether their ISP has a CSIRT, and if so what the charter, policies and services of that team are. This information is best expressed using the CSIRT template as shown in Appendix D of "Expectations for Computer Security Incident Response" [RFC2350].
客户应该了解他们的ISP是否有CSIRT，如果有，该团队的章程、政策和服务是什么。该信息最好使用CSIRT模板表达，如“计算机安全事件响应预期”[RFC2350]附录D所示。
3 Appropriate Use Policy
3适当使用政策
Every ISP SHOULD have an Appropriate Use Policy (AUP).
每个ISP都应该有一个适当的使用策略（AUP）。
Whenever an ISP contracts with a customer to provide connectivity to the Internet that contract should be governed by an AUP. The AUP should be reviewed each time the contract is up for renewal, and in addition the ISP should proactively notify customers as policies are updated.
每当ISP与客户签订合同以提供互联网连接时，该合同应由AUP管理。每次合同续签时都应审查AUP，此外，ISP应在更新策略时主动通知客户。
An AUP should clearly identify what customers shall and shall not do on the various components of a system or network, including the type
AUP应清楚地确定客户应在系统或网络的各个组件上做什么和不应做什么，包括类型
of traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. For example, an AUP might prohibit IP spoofing.
网络上允许的通信量。AUP应尽可能明确，以避免歧义或误解。例如，AUP可能禁止IP欺骗。
In addition to communicating their AUP to their customers ISPs should publish their policy in a public place such as their web site so that the community can be aware of what the ISP considers appropriate and can know what action to expect in the event of inappropriate behaviour.
除了向客户传达其AUP外，ISP还应在其网站等公共场所发布其政策，以便社区了解ISP认为合适的内容，并知道在发生不当行为时应采取的行动。
An AUP should be clear in stating what sanctions will be enforced in the event of inappropriate behaviour.
AUP应明确说明在发生不当行为时将实施何种制裁。
Many jurisdictions have Data Protection Legislation. Where such legislation applies, ISPs should consider the personal data they hold and, if necessary, register themselves as Data Controllers and be prepared to only use the data in accordance with the terms of the legislation. Given the global nature of the Internet ISPs that are located where no such legislation exists should at least familiarise themselves with the idea of Data Protection by reading a typical Data Protection Act (e.g., [DPR1998]).
许多司法管辖区都有数据保护立法。在此类立法适用的情况下，ISP应考虑其持有的个人资料，必要时，将其登记为数据控制器，并准备按照立法条款仅使用数据。鉴于互联网ISP的全球性质，在没有此类立法的情况下，他们至少应该通过阅读典型的数据保护法案（例如[DPR1998]）来熟悉数据保护的概念。
4 Network Infrastructure
4网络基础设施
ISPs are responsible for managing the network infrastructure of the Internet in such a way that it is
ISP负责管理互联网的网络基础设施，使其
- reasonably resistant to known security vulnerabilities
- 合理抵抗已知的安全漏洞
- not easily hijacked by attackers for use in subsequent attacks
- 不易被攻击者劫持以用于后续攻击
ISPs are commonly responsible for maintaining the data that is stored in global repositories such as the Internet Routing Registry (IRR) and the APNIC, ARIN and RIPE databases. Updates to this data should only be possible using strong authentication.
ISP通常负责维护存储在全球存储库中的数据，如Internet路由注册表（IRR）和APNIC、ARIN和RIME数据库。只有使用强身份验证才能更新此数据。
ISPs should publicly register the address space that they assign to their customers so that there is more specific contact information for the delegated space.
ISP应公开注册其分配给客户的地址空间，以便为委托空间提供更具体的联系信息。
An ISP's ability to route traffic to the correct destination may depend on routing policy as configured in routing registries [RFC1786]. If so, and if the registry supports it, they should ensure that the registry information that they maintain can only be updated using strong authentication, and that the authority to make updates is appropriately restricted.
ISP将流量路由到正确目的地的能力可能取决于路由注册表[RFC1786]中配置的路由策略。如果是，并且注册中心支持，他们应该确保他们维护的注册中心信息只能使用强身份验证进行更新，并且进行更新的权限受到适当限制。
Due care should also be taken in determining in whose routing announcements you place greater trust when a choice of routes are available to a destination. In the past bogus announcements have resulted in traffic being 'black holed', or worse, hijacked.
当一个目的地可以选择一条路线时，在确定您对谁的路线公告信任度更高时，也应格外小心。在过去，虚假公告导致交通被“黑洞”，或者更糟的是，被劫持。
BGP authentication [RFC2385] SHOULD be used with routing peers.
BGP身份验证[RFC2385]应与路由对等方一起使用。
The direction of such filtering is from the edge site (customer) to the Internet.
这种过滤的方向是从边缘站点（客户）到互联网。
Attackers frequently cover their tracks by using forged source addresses. To divert attention from their own site the source address they choose will generally be from an innocent remote site or 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.
攻击者经常使用伪造的源地址来掩盖其踪迹。为了转移他们自己站点的注意力，他们选择的源地址通常来自一个无辜的远程站点，或者实际上来自那些分配给私人互联网的地址[RFC1918]。此外，伪造的源地址经常用于基于欺骗的攻击，以利用主机之间的信任关系。
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].
为了减少依赖伪造源地址的攻击的发生率，ISP应执行以下操作。在与每个客户的边界路由器上，他们应该主动过滤来自客户的所有流量，这些流量的源地址不是分配给该客户的地址。有关此主题的更详细讨论，请参见[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.
在这些罕见的情况下，如果无法在客户和ISP之间的接口进行入口过滤，则应鼓励客户在其网络内实施入口过滤。一般来说，过滤应尽可能接近实际主机。
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].
如今，互联网上广泛使用的许多应用程序仅基于ip地址（例如Berkeley'r'命令）向其他主机授予信任。如[CA-95.01.IP.Spooking]所述，它们容易受到IP欺骗的影响。此外，还存在依赖于误用假定本地地址的漏洞，如[CA-97.28.Teardrop_land]中所述的“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.
为了减少客户受到依赖伪造源地址的攻击，ISP应采取以下措施。在与每个客户的边界路由器上，他们应主动过滤到客户的所有流量，该客户的源地址为已分配给该客户的任何地址。
The circumstances described in 4.3 in which ingress filtering isn't feasible apply similarly to egress filtering.
4.3中描述的进入过滤不可行的情况同样适用于出口过滤。
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.
ISP应该过滤他们听到的路由通知，例如忽略分配给私人互联网地址的路由，避免虚假路由，并实施“BGP路由抖动抑制”[RFC2439]和聚合策略。
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.
ISP应实施技术，以降低在网络其他部分的路由上施加过度负载的风险。这些包括“固定”路由、积极聚合和路由抑制，所有这些都可以降低内部路由以与其他路由无关的方式更改时对其他路由的影响。
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].
IP协议允许定向广播，即通过网络向特定子网发送要广播的数据包。此功能的实际用途很少，但有几种不同的安全攻击（主要是利用广播的数据包倍增效应进行的拒绝服务攻击）使用它。因此，连接到广播媒体的路由器不得配置为允许在该媒体上进行定向广播[RFC2644]。
5 Systems Infrastructure
5系统基础设施
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).
ISP管理其系统的方式对其网络的安全性和可靠性至关重要。对其系统的破坏可能会最低限度地导致性能或功能降级，但可能会导致数据丢失或流量被窃听的风险（从而导致“中间人”攻击）。
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.
人们普遍认为，如果不同的服务（如邮件、新闻和网络托管）保存在不同的系统上，那么构建安全系统就更容易了。
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.
所有执行关键ISP功能（如邮件、新闻和web托管）的系统都应受到限制，以便只有这些服务的管理员才能访问这些系统。只有在强身份验证之后才应授予该访问权限，并应通过加密链接进行访问。只能从ISP系统网络外部访问这些服务侦听的端口。
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]).
ISP应随时更新提供服务的更安全的方法（例如，简单质询/响应的IMAP/POP授权扩展[RFC2195]）。
Systems should not be attached to transit network segments.
系统不应连接到公交网段。
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.
ISP应采取积极措施，防止其邮件基础设施被“垃圾邮件发送者”用于注入未经请求的批量电子邮件（UBE），同时隐藏发件人的身份[RFC2505]。虽然并非所有预防措施都适用于每个现场，但应使用最有效的现场适用方法。
ISPs should also strongly encourage their customers to take the necessary steps to prevent this activity on their own systems.
ISP还应大力鼓励其客户采取必要措施，在其自己的系统上防止此类活动。
Message submissions should be authenticated using the AUTH SMTP service extension as described in the "SMTP Service Extension for Authentication" [RFC2554].
应使用“用于身份验证的SMTP服务扩展”[RFC2554]中所述的身份验证SMTP服务扩展对邮件提交进行身份验证。
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.
SMTP身份验证优先于基于IP地址的提交限制，因为它使ISP的客户能够灵活地提交邮件，即使没有通过ISP的网络连接（例如，在工作时），更能抵抗欺骗，并且可以在新的身份验证机制可用时升级到新的身份验证机制。
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.
此外，为了促进安全策略的实施，强烈建议使用“邮件提交”[RFC2476]中讨论的邮件提交端口（587）而不是通过SMTP端口（25）提交邮件。这样，SMTP端口（25）可以仅限于本地传递。
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.
这样做的原因是为了能够区分入站本地传递和中继（即，允许客户通过ISP的SMTP服务向Internet上的任意接收者发送电子邮件）。只有本地传递才允许使用未经身份验证的SMTP。
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.
随着越来越多的邮件客户端同时支持SMTP身份验证和邮件提交端口（无论是显式还是通过配置SMTP端口），ISP可能会发现，要求客户同时使用提交端口和SMTP身份验证提交邮件很有用；仅允许端口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.
这些措施（SMTP认证和提交端口）不仅可以保护ISP不通过第三方中继充当UBE注入点，还可以帮助跟踪客户发送UBE时邮件提交的责任。
6 References
6参考文献
[CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal
Connections",
ftp://info.cert.org/pub/cert_advisories/
[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/
[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
[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.
[RFC1786]Bates，T.，Gerich，E.，Joncheray，L.，Jouanigot，J.，Karrenberg，D.，Terpstra，M.和J.Yu，“路由注册表中IP路由策略的表示（RIME-81++）”，RFC 1786，1995年3月。
[RFC1834] Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service", RFC 1834, August 1995.
[RFC1834]Gargano，J.和K.Weiss，“Whois和网络信息查找服务”，RFC 18341995年8月。
[RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[RFC1835]Deutsch，P.，Schoultz，R.，Faltstrom，P.和C.Weider，“WHOIS++服务的体系结构”，RFC 18351995年8月。
[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.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.J.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.
[RFC2142]Crocker，D.，“公共服务、角色和功能的邮箱名称”，RFC 2142，1997年5月。
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[RFC2195]Klensin，J.，Catoe，R.和P.Krumviede，“简单质询/响应的IMAP/POP授权扩展”，RFC 21951997年9月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998.
[RFC2350]Brownlee，N.和E.Guttman，“对计算机安全事件响应的期望”，BCP 21，RFC 23501998年6月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2439] Chandra R., Govindan R. and C. Villamizar, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439]Chandra R.，Govindan R.和C.Villamizar，“BGP路线襟翼阻尼”，RFC 2439，1998年11月。
[RFC2476] Gellens R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2476]Gellens R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505]Lindberg，G.，“SMTP MTA的反垃圾邮件建议”，BCP 30，RFC 2505，1999年2月。
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC2554]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，1999年8月。
[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.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
7 Acknowledgements
7致谢
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.
我衷心感谢内维尔·布朗利、兰迪·布什、比尔·切斯维克、芭芭拉·弗雷泽、兰德尔·盖伦斯、埃里克·古特曼、拉里·J·休斯、克劳斯·彼得·科萨科夫斯基、迈克尔·巴顿、唐·斯蒂克沃特和比尔·伍德科克提出的建设性意见。
8 Security Considerations
8安全考虑
This entire document discusses security issues.
整个文档讨论了安全问题。
9 Author's Address
9作者地址
Tom Killalea Lisi/n na Bro/n Be/al A/tha na Muice Co. Mhaigh Eo IRELAND
Tom Killalea Lisi/n na Bro/n Be/al A/tha na Muice Co.Mhaigh Eo IRELAND
Phone: +1 206 266-2196
EMail: tomk@neart.org
Phone: +1 206 266-2196
EMail: tomk@neart.org
10 Full Copyright Statement
10完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。