[要約] RFC 3013は、インターネットサービスプロバイダ（ISP）のセキュリティサービスと手順に関する推奨事項を提供しています。このRFCの目的は、ISPが顧客のデータとネットワークを保護するための最善の方法を示すことです。
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
推奨されるインターネットサービスプロバイダーセキュリティサービスと手順
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.
Copyright（c）The Internet Society（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
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.
このドキュメントでは、Webホスティングサービス、コンテンツプロバイダー、電子メールサービスを含むが制限されていないが、インターネット接続またはその他のインターネットサービスを提供するビジネスに組織を含めるように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.
このドキュメントは、セキュリティと攻撃管理の取り決めをサポートするべきものに関する一連の推奨事項として、また高品質のサービスプロバイダーに期待すべきことに関するユーザーへのアドバイスとして提供されます。それ自体が決して規範的ではありません。やがて日付が付けられる可能性が高く、他の期待が生じる可能性があります。ただし、インターネットとそのテクノロジーの開発の特定の時点で、分野の一連の専門家の推奨事項のスナップショットを表しています。
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].
このドキュメントの「必須」、「必須」、「必要はない」、「そうでなければ」、「そうでない」、「必要はない」、「必要はない」というキーワードは、「RFCSで使用するためのキーワードで要件レベルを示すように解釈されるべきです。「[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/).
ISPは、上記の拡張された詳細に共通の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がこれらのチャネルを使用して、セキュリティ関連のインシデントを報告することは合理的です。そのような場合、顧客の連絡先は通知された人ではないかもしれません。むしろ、通常の連絡先はレポートを受け取ります。顧客はこれに注意し、そのような通知を適切にルーティングするようにする必要があります。
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があり、事件を報告できる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を持っているかどうかを調べる必要があります。そうであれば、そのチームのチャーター、ポリシー、サービスが何であるかを確認する必要があります。この情報は、「コンピューターセキュリティインシデント応答に対する期待」[RFC2350]の付録Dに示すように、CSIRTテンプレートを使用して最もよく表現されています。
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 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は、あいまいさや誤解を避けるために、できるだけ明確にする必要があります。たとえば、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はWebサイトなどの公共の場でポリシーを公開する必要があります。これにより、コミュニティは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は一般に、インターネットルーティングレジストリ（IRR）やAPNIC、ARIN、RIPEデータベースなどのグローバルリポジトリに保存されているデータを維持する責任があります。このデータの更新は、強力な認証を使用してのみ可能です。
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].
鍛造されたソースアドレスに依存する攻撃の発生率を減らすには、ISPSを使用する必要があります。各顧客との境界ルーターでは、その顧客に割り当てられたアドレス以外の何かのソースアドレスを持っている顧客からのすべてのトラフィックを積極的にフィルタリングする必要があります。このトピックの詳細については、[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).
このようなフィルタリングの方向は、インターネットからEdgeサイト（顧客）までです。
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.spoofing]で説明されているように、IPスプーフィングの影響を受けやすい。さらに、[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.
偽造されたソースアドレスに依存する攻撃への顧客の露出を減らすには、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.
メール、ニュース、Webホスティングなどの重要なISP関数を実行するすべてのシステムは、それらへのアクセスがこれらのサービスの管理者のみが利用できるように制限する必要があります。そのアクセスは、強力な認証後にのみ付与され、暗号化されたリンクを介して行われる必要があります。これらのサービスが聴くポートのみが、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]で説明されているように、AUTH 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 AUTHは、ISPの顧客にISPのネットワークを介して接続されていない場合でもメールを送信できるという柔軟性を提供するという点で、IPアドレスベースの提出制限よりも優先されます。利用可能になると、新しい認証メカニズムにアップグレードできます。
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.
さらに、セキュリティポリシーの施行を促進するために、SMTPポート（25）ではなく、「メッセージ送信」[RFC2476]で説明されているように、メール送信ポート（587）を使用してメッセージを送信することを強くお勧めします。このようにして、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サービスを介して電子メールを送信できるようにします）。非認識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 AUTHとメッセージ送信ポートの両方（明示的またはSMTPポートの構成のいずれか）をサポートするため、ISPは、顧客が提出ポートとSMTP AUTHの両方を使用してメッセージを送信することを要求することが有用であると判断する場合があります。ポート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 AUTHおよび提出ポート）は、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スプーフィング攻撃とハイジャックされたターミナル接続」、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 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]英国「データ保護法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.、Terpsstra、M。and J. Yu、「RutingレジストリにおけるIPルーティングポリシーの表現（Ripe- Ripe-」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 and Network Information Lookup Service」、RFC 1834、1995年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 Serviceの建築」、RFC 1835、1995年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、「Private Internetsのアドレス割り当て」、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 2195、1997年9月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] Fraser、B。、「サイトセキュリティハンドブック」、FYI 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 2350、1998年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 Route Flap Damping」、RFC 2439、1998年11月。
[RFC2476] Gellens R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2476] Gellens R.およびJ. Klensin、「Message Submission」、RFC 2476、1998年12月。
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505] Lindberg、G。、「SMTP MTASのアンチスパム推奨」、BCP 30、RFC 2505、1999年2月。
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC2554] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、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.
ネヴィル・ブラウンリー、ランディ・ブッシュ、ビル・チェスウィック、バーバラ・Y・フレイザー、ランドール・ゲレンズ、エリック・ガットマン、ラリー・J・ヒューズ・ジュニア、クラウス・ピーター・コッサコフスキ、マイケル・A・パットン、ドン・スティックヴォート、ビル・ウッドコッククックスキーから受け取った建設的なコメントに感謝します。
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
Phone: +1 206 266-2196
EMail: tomk@neart.org
10 Full Copyright Statement
10完全な著作権ステートメント
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。