RFC3013 日本語訳

Network Working Group                                       T. Killalea
Request for Comments: 3013                                    neart.org
BCP: 46                                                   November 2000
Category: Best Current Practice

Killaleaがコメントのために要求するワーキンググループT.をネットワークでつないでください: 3013neart.org BCP: 11月46日の2000カテゴリ: 最も良い現在の習慣

 Recommended Internet Service Provider Security Services and Procedures

お勧めのインターネットサービスプロバイダセキュリティー・サービスと手順

Status of this Memo

この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.

Copyright(C)インターネット協会(2000)。 All rights reserved。

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に適切ですが、むしろ昇給認識に適切である1セットの要件を定義して、現在の、そして、将来のサービスプロバイダーとのセキュリティ期待の議論のためにフレームワークを共同体に提供するのは、このドキュメントの意図ではありません。

Killalea                 Best Current Practice                  [Page 1]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[1ページ]RFC3013

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 このDocumentの序論. . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1Conventions Used。 . . . . . . . . . . . . . 3 2コミュニケーション。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 問い合わせ先。 . . . . . . . . . . . . . . . . . . . . 3 2.2 情報共有。 . . . . . . . . . . . . . . . . . . . . 4 2.3はチャンネルを固定します。 . . . . . . . . . . . . . . . . . . . . . . 4 2.4 脆弱性と報告インシデントの通知。 . . 4 2.5のISPとコンピュータセキュリティ事件対応チーム(CSIRTs)。 5 3は方針. . . . . . . . . . . . . . . . . . . 6 3.2の方針. . . . . . . . . . . . . . . . . . . . . 5 3.1発表が認可する使用を当てます。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3データ保護。 . . . . . . . . . . . . . . . . . . . . . . 6 4はインフラストラクチャ. . . . . . . . . . . . . . . . . . . . . 6 4.1登録データ保守をネットワークでつなぎます。 . . . . . . . . . . . . . . . . . 6 4.2 ソースアドレスでインフラストラクチャ. . . . . . . . . . . . . . . . . . . 7 4.3イングレスフィルタリングを発送します。 . . . . . . . . . . . . 7 4.4 ソースの上でアドレス. . . . . . . . . . . . . 8 4.5ルートフィルタリングをフィルターにかける出口。 . . . . . . . . . . . . . . . . . . . . . . 4.6は.95.1に放送. . . . . . . . . . . . . . . . . . . . . 8 5システムインフラストラクチャを指示しました。8 システム管理。 . . . . . . . . . . . . . . . . . . . . . 9 5.2 輸送網. . . . . . . . . . . . . . . 9 5.3でどんなシステムもメール中継を開けません。 . . . . . . . . . . . . . . . . . . . . . . 9 5.4 メッセージ提案. . . . . . . . . . . . . . . . . . . . . 9 6参照. . . . . . . . . . . . . . . . . . . . . . . . . . .10 7承認. . . . . . . . . . . . . . . . . . . . . . . .12 8セキュリティ問題。 . . . . . . . . . . . . . . . . . . . .12 9作者のアドレスの.12 10の完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . .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.

それは決して、このドキュメントが商習慣を決めるという意志ではありません。

Killalea                 Best Current Practice                  [Page 2]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[2ページ]RFC3013

   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への1セットの推薦として彼らが高い質の高いサービスから予想するべきであることに関するユーザへのアドバイスとしてこのドキュメントを提供します。 それ自身の権利における標準のどんな意味でもそれがありません。 時間内に、それは時代遅れになりそうです、そして、他の期待は起こるかもしれません。 しかしながら、それはインターネットの発展とその技術で与えられたポイントの分野での1セットの専門家の推薦のスナップを表します。

1.1 Conventions Used in this Document

1.1 このDocumentのコンベンションUsed

   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].

“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」 「5月」は「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への共同体の最も重要なセキュリティ関連の期待はセキュリティインシデントに対処するための通信チャネルの有用性に関連します。

2.1 Contact Information

2.1 問い合わせ先

   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 SHOULDは[RFC2142]を固く守ります。(それは、ネットワーク安全保障問題のためのメールボックスSECURITY、問題のための不適当な公共のふるまいに関連するABUSE、および問題のためのネットワークインフラに関連するNOCを定義します)。 また、それは特定のサービスに関連する質問とレポートを受け取るために定義される追加メールボックスを記載します。

   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には、それらの問い合わせ先がWhois、ルーティング登録[RFC1786]またはいかなる他の倉庫でも完全で、正確で届いているのを確実にする義務があります。

Killalea                 Best Current Practice                  [Page 3]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[3ページ]RFC3013

2.2 Information Sharing

2.2 情報共有

   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 SHOULDは彼らの顧客と共に情報の共有にセキュリティインシデントに関して明確な方針と手順を持っています、他のISPで、法施行かプレスと一般がいるIncident Response Teamsと共に。

   ISPs should have processes in place to deal with security incidents
   that traverse the boundaries between them and other ISPs.

ISPは、それらと他のISPの間の境界を横断するセキュリティインシデントに対処するために適所にプロセスを持つべきです。

2.3 Secure Channels

2.3 安全なチャンネル

   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 SHOULD、安全なチャンネルの上にそのようなコミュニケーションを行うことができてください。 しかしながら、何人かの司法権の安全なチャンネルによるそれが受入れられないかもしれないことに注意してください。

2.4 Notification of Vulnerabilities and Reporting of Incidents

2.4 脆弱性の通知とインシデントの報告

   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 SHOULD、それらが提供するサービスにおけるセキュリティの脆弱性について顧客に通知する際に、先を見越してください。 さらに、システムとソフトウェアの新しい脆弱性が発見されるように、それらは、彼らのサービスがこれらのリスクによって脅かされるかどうかを示すべきです。

   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がセキュリティ関連のインシデントを報告するのにこれらのチャンネルを使用するのは、妥当です。 そのような場合、顧客のセキュリティ連絡先は通知された人でないかもしれません。 むしろ、正常な連絡先はレポートを受け取るでしょう。 顧客は、これを意識していて、適切にそのような通知を発送するのを確実にするべきです。

Killalea                 Best Current Practice                  [Page 4]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[4ページ]RFC3013

2.5 Incident Response and Computer Security Incident Response Teams
   (CSIRTs)

2.5 インシデントレスポンスとコンピュータセキュリティ事件対応チーム(CSIRTs)

   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].

コンピュータSecurity Incident Response Team(CSIRT)は定義された選挙民の中でサイトにかかわるセキュリティインシデントへの応答を実行して、調整して、サポートするチームです。 インターネットコミュニティの期待は「コンピュータセキュリティインシデント応答への期待」[RFC2350]でCSIRTsに説明されます。

   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には、CSIRTsがあります。 しかしながら、そのISPの顧客によって攻撃されるISPの接続性顧客かサイトのどちらかが自動的にISPのCSIRTのサービスを自分たちに利用できると思うべきではありません。 加えられた費用サービスとして頻繁にISP CSIRTsを提供します、彼らの選挙民の唯一のそれらとだれかを定義するのが明確に加入するチームと共に(恐らく有料)、付随しているResponseサービス。

   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に、それらが顧客にとって利用可能にするすべてのインシデントレスポンスとセキュリティリソースを発表するのが重要である、顧客が彼らのインシデントレスポンス増大チェーンBEFOREを定義できるように、インシデントは起こります。

   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]のAppendix Dに示されるようにCSIRTテンプレートを使用することでこの情報を言い表すのは最も良いです。

3 Appropriate Use Policy

3、適切な使用方針

   Every ISP SHOULD have an Appropriate Use Policy (AUP).

あらゆるISP SHOULDには、Appropriate Use Policy(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は明確に、顧客がして、システムかネットワークの様々な成分でしないものとすることは特定するはずです、タイプを含んでいて

Killalea                 Best Current Practice                  [Page 5]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[5ページ]RFC3013

   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スプーフィングを禁止するかもしれません。

3.1 Announcement of Policy

3.1 方針の発表

   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が適切であると考えることを意識している場合があって、不適当なふるまいの場合、どんな動作を予想したらよいかを知ることができるように、公開の場所でそれらのウェブサイトなどのそれらの方針を発行するべきです。

3.2 Sanctions

3.2 制裁措置

   An AUP should be clear in stating what sanctions will be enforced in
   the event of inappropriate behaviour.

どんな制裁が不適当なふるまいの場合励行されるかを述べるのにおいてAUPは明確であるはずです。

3.3 Data Protection

3.3データ保護

   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]).

多くの管内には、Data Protection Legislationがあります。 そのような法律が適用されるところでは、ISPは、それらが保持する個人的なデータを考えて、必要なら、Data Controllersとして自分たちを登録して、法律に関する諸条件通りに単にデータを使用するように準備されるべきです。 インターネットのグローバルな本質を考えて、どんなそのような法律も存在しないところに位置しているISPは、Data Protectionの考えに典型的なData Protection条例(例えば、[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

- その後の攻撃における使用のために攻撃者によって容易にハイジャックされません。

4.1 Registry Data Maintenance

4.1 登録データ保守

   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は一般的にインターネットルート設定Registry(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は、代表として派遣されたスペースのための、より特定の問い合わせ先があるように、公的に、それらが彼らの顧客に割り当てるアドレス空間を示すべきです。

Killalea                 Best Current Practice                  [Page 6]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[6ページ]RFC3013

4.2 Routing Infrastructure

4.2 ルート設定インフラストラクチャ

   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]SHOULD、ルーティング同輩と共に使用されてください。

4.3 Ingress Filtering on Source Address

4.3 ソースの上でアドレスをフィルターにかけるイングレス

   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.

攻撃者は、偽造ソースアドレスを使用することによって、頻繁に証拠を隠します。 一般に、それら自身のサイトから注意を転換するために、彼らが選ぶソースアドレスは潔白なリモートサイト、または、本当に、個人的なInternets[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とのインタフェースのイングレスフィルタリングが可能でないこれらのまれなケースの中では、顧客が、それらのネットワークの中でイングレスがフィルタリングであると実装するよう奨励されるべきです。 一般に、可能であるとしての実際のホストの近くようにフィルタリングをするべきです。

Killalea                 Best Current Practice                  [Page 7]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[7ページ]RFC3013

4.4 Egress Filtering on Source Address

4.4 ソースの上でアドレスをフィルターにかける出口

   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'コマンド)だけに基礎づけた普及使用における多くの利用があります。 これらは[カリフォルニア-95.01.IP.spoofing]で説明されるようにIPスプーフィングに影響されやすいです。 さらに、推定上ローカルのアドレスの誤用による脆弱性があります、[カリフォルニア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で説明された事情は同様に出口フィルタリングに適用されます。

4.5 Route Filtering

4.5 ルートフィルタリング

   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]と集合が方針であると例えば個人的なInternetsのために割り当てられたアドレスにルートを無視して、にせのルートを避けて、実装するために、彼らが聞くルーティング発表をフィルターにかけるべきです。

   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はネットワークの他の部分に負担過重をルーティングに置く危険を減少させるテクニックを実装するべきです。 これらは'釘でとどめられて'ルート、攻撃的な集合、およびルートの湿りを含んでいます。あなたの内部のルーティングが彼らに関連していない方法で変化するとき、そのすべてが他のものの上に影響を下ろします。

4.6 Directed Broadcast

4.6 指示された放送

   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]に指示された放送を許すために放送媒体に接されたルータを構成してはいけません。

Killalea                 Best Current Practice                  [Page 8]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[8ページ]RFC3013

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.

異なったサービス(メールや、ニュースやウェブホスティングなどの)が別々のシステムの上に保たれるなら、それは、安全なシステムを構築するのが、より簡単であると広く受け入れました。

5.1 System Management

5.1 システム管理

   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機能を実行するすべてのシステム、制限されるべきであるので、それらのサービスの管理者だけに、それらへのアクセスは利用可能です。 そのアクセスは、強い認証に続くだけであって、承諾されるべきであり、暗号化されたリンクの上に行われるべきです。 それらのサービスが聴かれるポートだけが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は利用可能になるのでサービスを提供するより安全なメソッド(例えば、Simple Challenge/応答のためのIMAP/POP AUTHorize Extension、[RFC2195])に最新の状態で残るべきです。

5.2 No Systems on Transit Networks

5.2 輸送網でシステムがありません。

   Systems should not be attached to transit network segments.

トランジットネットワークセグメントにシステムを取り付けるべきではありません。

5.3 Open Mail Relay

5.3 開いているメール中継

   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]を隠している間、Unsolicited Bulkメール(UBE)を注入するのに'スパマー'によって使用されるのを防ぐために積極的な手段を取るべきです。 あらゆるサイトに、すべての予防手段がどんな適切であるというわけではない間、最も効果的なサイト適切なメソッドは使用されるべきです。

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

また、ISPは、彼らの顧客がそれら自身のシステムの上でこの活動を防ぐために必要な措置を取るよう強く奨励するべきです。

5.4 Message Submission

5.4 メッセージ提案

   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サービス拡張子を使用することで認証されるべきです。

Killalea                 Best Current Practice                  [Page 9]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[9ページ]RFC3013

   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.

さらに、安全保障政策の実施を容易にするために、(587) SMTPポート(25)を通してというよりむしろ「メッセージ提案」[RFC2476]で議論するようにMAIL SUBMITポートを使用することでメッセージを提出することが強く勧められます。 このように、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/

[カリフォルニア-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/

[カリフォルニア97.28.Teardrop_陸] 「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.ユー、「ルート設定登録(熟している81++)のIPルート設定方針の表現」RFC1786、1995年3月。

Killalea                 Best Current Practice                 [Page 10]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[10ページ]RFC3013

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

[RFC1834] ガルガノ、J.、K.ウィス、および「Whoisとネットワーク情報ルックアップサービス」、RFC1834、8月1995日

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

[RFC1835] ドイツ語とP.とSchoultzとR.とFaltstromとP.とC.ワイダー、「WHOIS++サービスのアーキテクチャ」、RFC1835、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.、deグルート、G.J.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC2142]クロッカー(D.、「共益サービス、役割、および機能のためのメールボックス名」、RFC2142)は1997がそうするかもしれません。

   [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は簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。

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

[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。

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

[RFC2350]ブラウンリー、N.とE.Guttman、「コンピュータセキュリティインシデント応答への期待」BCP21、1998年6月のRFC2350。

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

[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。

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

[RFC2439] チャンドラR.とGovindan R.とC.Villamizar、「BGPルートフラップ湿気」、RFC2439、1998年11月。

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

[RFC2476] Gellens R.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。

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

[RFC2505] リンドバーグ、G.、「SMTP MTAsのための反スパム推薦」、BCP30、RFC2505、1999年2月。

Killalea                 Best Current Practice                 [Page 11]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[11ページ]RFC3013

   [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.、「ルータにおける指示された放送のためのデフォルトを変えます」、BCP34、RFC2644、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を使うサービス妨害Attacksを破ります」、BCP38、RFC2827、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.フレーザ、ランドルGellens、エリックGuttman、ラリーJ.ヒューズJr.、クラウス-ピーターKossakowski、マイケル・A.パットン、ドンStikvoort、およびビルWoodcockから受けられた建設的なコメントを承諾します。

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 Na Bro/n Be/アルA/tha Na Muice社のMhaigh Eoアイルランド

   Phone: +1 206 266-2196
   EMail: tomk@neart.org

以下に電話をしてください。 +1 206 266-2196 メールしてください: tomk@neart.org

Killalea                 Best Current Practice                 [Page 12]

RFC 3013                Recommended ISP Security           November 2000

ISPセキュリティ2000年11月のお勧めのKillaleaの最も良い現在の習慣[12ページ]RFC3013

10 Full Copyright Statement

10 完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 All rights reserved。

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

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Killalea                 Best Current Practice                 [Page 13]

Killaleaの最も良い現在の習慣[13ページ]