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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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
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].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、要件レベルを示すためにRFCで使用するためのキーワード」で説明したように、この文書に解釈されるべきである「MAY」 "[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は、ネットワークセキュリティの問題、ネットワークインフラストラクチャに関連する問題のために不適切な公共挙動とNOCに関連する問題のために乱用のメールボックスのセキュリティを定義する[RFC2142]に準拠すべきです。また、特定のサービスに関連するクエリとレポートを受信するために定義されている追加のメールボックスを示しています。
ISPs may consider using common URLs for expanded details on the above (e.g., http://www.ISP-name-here.net/security/).
ISPは、（例えば、http://www.ISP-name-here.net/security/）上に展開詳細については共通のURLを使用して検討してもよいです。
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はルーティングレジストリ[RFC1786]や他のリポジトリ内のWhoisでの連絡先情報は、、、完全、正確かつ到達可能であることを確認する義務があります。
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と、インシデント対応チームと、法執行機関とか、マスコミや一般市民で、顧客とセキュリティインシデントに関する情報の共有に関する明確な方針と手順を持つべきである（SHOULD）。
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を持っているかどうかを調べる必要があり、そのチームの憲章、ポリシーとサービスがあるので、どのような場合。 「コンピュータセキュリティインシデント対応への期待」の付録D [RFC2350]に示すように、この情報は最良の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.
たびの契約は、AUPによって支配されなければならない、インターネットへの接続性を提供するために、顧客とISPとの契約。 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.
コミュニティは、ISPが適切と考えると不適切な行動が発生した場合に期待するのはどのような行動を知ることができるものを知ることができるように、顧客のISPに自分のAUPを伝達することに加えて、そのような彼らのウェブサイトなどの公共の場所で彼らの方針を公表すべきです。
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は、彼らが保有する個人データを検討し、必要に応じて、データコントローラとして自身を登録し、唯一の立法の条項に従ってデータを使用するに準備する必要があります。そのような法律は、少なくとも一般的なデータ保護法（例えば、[DPR1998]）を読み取ることにより、データ保護の考え方に慣れる必要があります存在しない場所に配置されているインターネットのISPのグローバルな性質を考えます。
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].
次のことを行う必要があります偽造ソースアドレスの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アドレス（例えば、バークレー「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プロトコルは、特定のサブネットへ放送されるネットワークを介したパケットの送信、ダイレクトブロードキャストを可能にします。この機能のための非常に少数の実用的な用途が存在するが、いくつかの異なるセキュリティ攻撃は、（主にDoS攻撃は、ブロードキャストのパケット乗算効果を利用して）それを使用しています。したがって、ブロードキャスト媒体に接続されたルータは、その培地[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が自社のシステムの管理方法は、ネットワークのセキュリティと信頼性にとって非常に重要です。彼らのシステムの違反が（したがって「のman-in-the-middle」攻撃につながる）最小限の性能劣化や機能につながる可能性がありますが、盗聴されているデータの損失やトラフィックのリスクにつながる可能性があります。
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は、送信者の身元[RFC2505]を隠しながら、迷惑メール（UBE）を注入する「スパマー」により使用されているから自分のメールインフラストラクチャを防止するための積極的措置をとる必要があります。必ずしもすべての予防の手順は、すべてのサイトに適していますが、最も効果的なサイトの適切な方法を使用する必要があります。
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.
また、セキュリティポリシーの施行を容易にするために、強く、「メッセージ送信」[RFC2476]で議論するようにメッセージがなく、SMTPポート（25）を介してメールを使用して送信ポート（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とサブミッションポート）のみ、サードパーティ製のリレーを経由してUBE注入点となるからISPを保護するだけでなく、顧客が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サービス拒否攻撃"、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]ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、J.、Karrenberg、D.、テルプストラ、M.及びJ.優、「ルーティングレジストリにIPルーティングポリシーの表現（ripe- 81 ++）」、RFC 1786、1995年3月。
[RFC1834] Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service", RFC 1834, August 1995.
[RFC1834]ガルガーノ、J.およびK.ワイス、 "Whoisのとネットワーク情報検索サービス"、RFC 1834、1995年8月。
[RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[RFC1835]ドイツ語、さらにP.、Schoultz、R.、FALT電気、P.とC.、 "WHOIS ++サービスのアーキテクチャ"、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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G. J.およびE.リアド、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.
[RFC2142]クロッカー、D.、 "Common Servicesのためのメールボックス名、役割と機能"、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]フレイザー、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]ブラウンリー、N.とE.グットマン、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]チャンドラR.、ゴヴィンダン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 2476、1998年12月。
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505]リンドバーグ、G.、 "SMTP MTAのアンチスパムの提言"、BCP 30、RFC 2505、1999年2月。
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC2554]マイヤーズ、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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、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.
私は感謝Nevilブラウンリー、ランディブッシュ、ビルチェスウィック、バーバラY.フレイザー、ランドールGellens、エリック・ガットマン、ラリー・J・ヒューズ・ジュニア、クラウス・ペーター・Kossakowski、マイケルA.パットン、ドンStikvoortとビル・ウッドコックから受信した建設的なコメントを認めます。
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
トムKillaleaリージ/ Nブロ/ Nと/アルA /ある豚株式会社メイヨーアイルランド
Phone: +1 206 266-2196 EMail: tomk@neart.org
電話：+1 206 266-2196 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。