Network Working Group G. Jones, Ed.
Request for Comments: 3871 The MITRE Corporation
Category: Informational September 2004
Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Infrastructure
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.
この文書では、大規模なインターネットサービスプロバイダ（ISP）IPネットワーク（ルータやスイッチ）のインフラのための運用上のセキュリティ要件のリストを定義します。フレームワークは、特定のネットワーク・トポロジ・コンテキスト（すべて、コアのみ、エッジのみ...）に適用される要件の集合である「プロファイル」を特定するために定義されています。目標は、ネットワークオペレータにベンダーに彼らのセキュリティ要件を伝えるの明確、簡潔な方法を提供することです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Definition of a Secure Network . . . . . . . . . . . . . 6
1.5. Intended Audience. . . . . . . . . . . . . . . . . . . . 6
1.6. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Intended Use . . . . . . . . . . . . . . . . . . . . . . 7
1.8. Definitions. . . . . . . . . . . . . . . . . . . . . . . 7
2. Functional Requirements . . . . . . . . . . . . . . . . . . . 11
2.1. Device Management Requirements . . . . . . . . . . . . . 11
2.1.1. Support Secure Channels For Management. . . . . 11
2.2. In-Band Management Requirements. . . . . . . . . . . . . 12
2.2.1. Use Cryptographic Algorithms Subject To
Open Review . . . . . . . . . . . . . . . . . . 12
2.2.2. Use Strong Cryptography . . . . . . . . . . . . 13
2.2.3. Use Protocols Subject To Open Review For
Management. . . . . . . . . . . . . . . . . . . 14
2.2.4. Allow Selection of Cryptographic Parameters . . 15
2.2.5. Management Functions Should Have Increased
Priority. . . . . . . . . . . . . . . . . . . . 16
2.3. Out-of-Band (OoB) Management Requirements . . . . . . . 16
2.3.1. Support a 'Console' Interface . . . . . . . . . 17
2.3.2. 'Console' Communication Profile Must Support
Reset . . . . . . . . . . . . . . . . . . . . . 19
2.3.3. 'Console' Requires Minimal Functionality of
Attached Devices. . . . . . . . . . . . . . . . 19
2.3.4. 'Console' Supports Fall-back Authentication . . 20
2.3.5. Support Separate Management Plane IP
Interfaces. . . . . . . . . . . . . . . . . . . 21
2.3.6. No Forwarding Between Management Plane And Other
Interfaces. . . . . . . . . . . . . . . . . . . 21
2.4. Configuration and Management Interface Requirements. . . 22
2.4.1. 'CLI' Provides Access to All Configuration and
Management Functions. . . . . . . . . . . . . . 22
2.4.2. 'CLI' Supports Scripting of Configuration . . . 23
2.4.3. 'CLI' Supports Management Over 'Slow' Links . . 24
2.4.4. 'CLI' Supports Idle Session Timeout . . . . . . 25
2.4.5. Support Software Installation . . . . . . . . . 25
2.4.6. Support Remote Configuration Backup . . . . . . 27
2.4.7. Support Remote Configuration Restore. . . . . . 27
2.4.8. Support Text Configuration Files. . . . . . . . 28
2.5. IP Stack Requirements. . . . . . . . . . . . . . . . . . 29
2.5.1. Ability to Identify All Listening Services. . . 29
2.5.2. Ability to Disable Any and All Services . . . . 30
2.5.3. Ability to Control Service Bindings for
Listening Services. . . . . . . . . . . . . . . 30
2.5.4. Ability to Control Service Source Addresses . . 31
2.5.5. Support Automatic Anti-spoofing for
Single-Homed Networks . . . . . . . . . . . . . 32
2.5.6. Support Automatic Discarding Of Bogons and
Martians. . . . . . . . . . . . . . . . . . . . 33
2.5.7. Support Counters For Dropped Packets. . . . . . 34
2.6. Rate Limiting Requirements . . . . . . . . . . . . . . . 35
2.6.1. Support Rate Limiting . . . . . . . . . . . . . 35
2.6.2. Support Directional Application Of Rate
Limiting Per Interface. . . . . . . . . . . . . 36
2.6.3. Support Rate Limiting Based on State. . . . . . 36
2.7. Basic Filtering Capabilities . . . . . . . . . . . . . . 37
2.7.1. Ability to Filter Traffic . . . . . . . . . . . 37
2.7.2. Ability to Filter Traffic TO the Device . . . . 37
2.7.3. Ability to Filter Traffic THROUGH the Device. . 38
2.7.4. Ability to Filter Without Significant
Performance Degradation . . . . . . . . . . . . 38
2.7.5. Support Route Filtering . . . . . . . . . . . . 39
2.7.6. Ability to Specify Filter Actions . . . . . . . 40
2.7.7. Ability to Log Filter Actions . . . . . . . . . 40
2.8. Packet Filtering Criteria. . . . . . . . . . . . . . . . 41
2.8.1. Ability to Filter on Protocols. . . . . . . . . 41
2.8.2. Ability to Filter on Addresses. . . . . . . . . 42
2.8.3. Ability to Filter on Protocol Header Fields . . 42
2.8.4. Ability to Filter Inbound and Outbound. . . . . 43
2.9. Packet Filtering Counter Requirements. . . . . . . . . . 43
2.9.1. Ability to Accurately Count Filter Hits . . . . 43
2.9.2. Ability to Display Filter Counters. . . . . . . 44
2.9.3. Ability to Display Filter Counters per Rule . . 45
2.9.4. Ability to Display Filter Counters per Filter
Application . . . . . . . . . . . . . . . . . . 45
2.9.5. Ability to Reset Filter Counters. . . . . . . . 46
2.9.6. Filter Counters Must Be Accurate. . . . . . . . 47
2.10. Other Packet Filtering Requirements . . . . . . . . . . 47
2.10.1. Ability to Specify Filter Log Granularity . . . 47
2.11. Event Logging Requirements . . . . . . . . . . . . . . . 48
2.11.1. Logging Facility Uses Protocols Subject To
Open Review . . . . . . . . . . . . . . . . . . 48
2.11.2. Logs Sent To Remote Servers . . . . . . . . . . 49
2.11.3. Ability to Select Reliable Delivery . . . . . . 49
2.11.4. Ability to Log Locally. . . . . . . . . . . . . 50
2.11.5. Ability to Maintain Accurate System Time. . . . 50
2.11.6. Display Timezone And UTC Offset . . . . . . . . 51
2.11.7. Default Timezone Should Be UTC. . . . . . . . . 52
2.11.8. Logs Must Be Timestamped. . . . . . . . . . . . 52
2.11.9. Logs Contain Untranslated IP Addresses. . . . . 53
2.11.10. Logs Contain Records Of Security Events . . . . 54
2.11.11. Logs Do Not Contain Passwords . . . . . . . . . 55
2.12. Authentication, Authorization, and Accounting (AAA)
Requirements . . . . . . . . . . . . . . . . . . . . . . 55
2.12.1. Authenticate All User Access. . . . . . . . . . 55
2.12.2. Support Authentication of Individual Users. . . 56
2.12.3. Support Simultaneous Connections. . . . . . . . 56
2.12.4. Ability to Disable All Local Accounts . . . . . 57
2.12.5. Support Centralized User Authentication
Methods . . . . . . . . . . . . . . . . . . . . 57
2.12.6. Support Local User Authentication Method. . . . 58
2.12.7. Support Configuration of Order of
Authentication Methods . . . . . . . . . . . . 59
2.12.8. Ability To Authenticate Without Plaintext
Passwords . . . . . . . . . . . . . . . . . . . 59
2.12.9. No Default Passwords. . . . . . . . . . . . . . 60
2.12.10. Passwords Must Be Explicitly Configured Prior
To Use. . . . . . . . . . . . . . . . . . . . . 60
2.12.11. Ability to Define Privilege Levels. . . . . . . 61
2.12.12. Ability to Assign Privilege Levels to Users . . 62
2.12.13. Default Privilege Level Must Be 'None'. . . . . 62
2.12.14. Change in Privilege Levels Requires
Re-Authentication . . . . . . . . . . . . . . . 63
2.12.15. Support Recovery Of Privileged Access . . . . . 64
2.13. Layer 2 Devices Must Meet Higher Layer Requirements. . . 65
2.14. Security Features Must Not Cause Operational Problems. . 65
2.15. Security Features Should Have Minimal Performance
Impact . . . . . . . . . . . . . . . . . . . . . . . . . 66
3. Documentation Requirements . . . . . . . . . . . . . . . . . . 67
3.1. Identify Services That May Be Listening. . . . . . . . . 67
3.2. Document Service Defaults. . . . . . . . . . . . . . . . 67
3.3. Document Service Activation Process. . . . . . . . . . . 68
3.4. Document Command Line Interface. . . . . . . . . . . . . 68
3.5. 'Console' Default Communication Profile Documented . . . 69
4. Assurance Requirements . . . . . . . . . . . . . . . . . . . . 69
4.1. Identify Origin of IP Stack. . . . . . . . . . . . . . . 70
4.2. Identify Origin of Operating System. . . . . . . . . . . 70
5. Security Considerations . . . . . . . . . . . . . . . . . . . 71
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1. Normative References . . . . . . . . . . . . . . . . . . 71
6.2. Informative References . . . . . . . . . . . . . . . . . 74
Appendices
A. Requirement Profiles . . . . . . . . . . . . . . . . . . . . . 75
A.1. Minimum Requirements Profile . . . . . . . . . . . . . . 75
A.2. Layer 3 Network Edge Profile . . . . . . . . . . . . . . 78
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 81
This document defines a list of operational security requirements for the infrastructure of large IP networks (routers and switches). The goal is to provide network operators a clear, concise way of communicating their security requirements to equipment vendors.
この文書では、大規模IPネットワーク（ルータやスイッチ）のインフラのための運用上のセキュリティ要件のリストを定義します。目標は、ネットワークオペレータに機器ベンダーへのセキュリティ要件を伝えるの明確、簡潔な方法を提供することです。
Network operators need tools to ensure that they are able to manage their networks securely and to insure that they maintain the ability to provide service to their customers. Some of the threats are outlined in section 3.2 of [RFC2196]. This document enumerates features which are required to implement many of the policies and procedures suggested by [RFC2196] in the context of the infrastructure of large IP-based networks. Also see [RFC3013].
ネットワークオペレータは、彼らが安全にネットワークを管理することが可能であることを確認するために、彼らは彼らの顧客にサービスを提供する能力を維持することを保証するためのツールが必要です。脅威のいくつかは、[RFC2196]のセクション3.2に概説されています。この文書では、大規模なIPベースのネットワークのインフラストラクチャのコンテキストで[RFC2196]によって提案されたポリシーや手順の多くを実装するために必要とされる機能を列挙します。また、[RFC3013]を参照してください。
The scope of these requirements is intended to cover the managed infrastructure of large ISP IP networks (e.g., routers and switches). Certain groups (or "profiles", see below) apply only in specific situations (e.g., edge-only).
これらの要件の範囲は大きいISP IPネットワーク（例えば、ルータやスイッチ）の管理インフラストラクチャをカバーすることを意図しています。特定のグループ（又は「プロファイル」、下記を参照）は、特定の状況（例えば、エッジのみ）にのみ適用されます。
The following are explicitly out of scope:
以下は、スコープの外に明示されています。
o general purpose hosts that do not transit traffic including infrastructure hosts such as name/time/log/AAA servers, etc.,
、などの名前/時間/ログ/ AAAサーバーなどのインフラのホストを含むトランジットトラフィックをない汎用ホストO
o unmanaged devices,
非管理デバイスO、
o customer managed devices (e.g., firewalls, Intrusion Detection System, dedicated VPN devices, etc.),
O顧客管理装置（例えば、ファイアウォール、侵入検知システム、専用のVPN装置、等）、
o SOHO (Small Office, Home Office) devices (e.g., personal firewalls, Wireless Access Points, Cable Modems, etc.),
O SOHO（スモールオフィス、ホームオフィス）機器（例えば、パーソナルファイアウォール、無線アクセスポイント、ケーブルモデムなど）、
o confidentiality of customer data,
顧客データの入出力機密性、
o integrity of customer data,
顧客データの入出力整合性、
o physical security.
O物理的なセキュリティ。
This means that while the requirements in the minimum profile (and others) may apply, additional requirements have not be added to account for their unique needs.
これは、最小プロファイル（およびその他）の要求事項が適用される場合がありますが、追加の要件が自分の固有のニーズを考慮して追加されていないことを意味します。
While the examples given are written with IPv4 in mind, most of the requirements are general enough to apply to IPv6.
心の中ではIPv4と書かれている与えられた例が、要件のほとんどは、IPv6への適用には十分一般的です。
For the purposes of this document, a secure network is one in which:
このドキュメントの目的のために、安全なネットワークは1つです。
o The network keeps passing legitimate customer traffic (availability).
Oネットワークは、正当な顧客のトラフィック（可用性）を通過し続けます。
o Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality).
Oトラフィックは行くことになっている場合になり、（可用性、機密性を）行くことになっている場合のみ。
o The network elements remain manageable (availability).
Oネットワーク要素は（可用性）管理残ります。
o Only authorized users can manage network elements (authorization).
Oのみ許可されたユーザーは、ネットワーク要素（承認）を管理することができます。
o There is a record of all security related events (accountability).
Oすべてのセキュリティ関連のイベント（説明責任）のレコードがあります。
o The network operator has the necessary tools to detect and respond to illegitimate traffic.
Oネットワークオペレータは、検出し、違法なトラフィックに対応するために必要なツールを持っています。
There are two intended audiences: the network operator who selects, purchases, and operates IP network equipment, and the vendors who create them.
、購入を選択し、IPネットワーク機器を動作させるネットワークオペレータ、およびそれらを作成ベンダー：2人の所期の観客があります。
The individual requirements are listed in the three sections below.
個々の要件は、次の3つのセクションに記載されています。
o Section 2 lists functional requirements.
O部2つのリスト機能要件。
o Section 3 lists documentation requirements.
O部3つのリストの文書化要件。
o Section 4 lists assurance requirements.
O部4つのリストの保証要件。
Within these areas, requirements are grouped in major functional areas (e.g., logging, authentication, filtering, etc.)
これらの領域内で、要件は、主要機能領域（例えば、ロギング、認証、フィルタリング、等）にグループ化され
Each requirement has the following subsections:
各要件は、次のサブセクションがあります。
o Requirement (what)
O要件（何）
o Justification (why)
O正当化（なぜ）
o Examples (how) o Warnings (if applicable)
警告へのOの例（方法）（該当する場合）
The requirement describes a policy to be supported by the device. The justification tells why and in what context the requirement is important. The examples section is intended to give examples of implementations that may meet the requirement. Examples cite technology and standards current at the time of this writing. See [RFC3631]. It is expected that the choice of implementations to meet the requirements will change over time. The warnings list operational concerns, deviation from standards, caveats, etc.
要件は、デバイスによってサポートされるポリシーについて説明します。要件が重要である理由、どのような文脈で正当化を指示します。実施例のセクションは、要件を満たすことができる実装の例を与えることを意図しています。例としては、この記事の執筆時点での技術や基準電流を引用します。 [RFC3631]を参照してください。要件を満たすための実装の選択は、時間の経過とともに変化することが予想されます。警告は、運用の懸念、基準からの逸脱、注意事項などを一覧表示します
Security requirements will vary across different device types and different organizations, depending on policy and other factors. A desired feature in one environment may be a requirement in another. Classifications must be made according to local need.
セキュリティ要件は、ポリシーおよび他の要因に応じて、異なるデバイスタイプと異なる組織間で変化します。ある環境において所望の特徴は、他に要求してもよいです。分類は、地元の必要に応じて行われなければなりません。
In order to assist in classification, Appendix A defines several requirement "profiles" for different types of devices. Profiles are concise lists of requirements that apply to certain classes of devices. The profiles in this document should be reviewed to determine if they are appropriate to the local environment.
分類を支援するためには、付録Aには、異なるタイプの装置のためのいくつかの要件「プロファイル」を定義します。プロファイルは、デバイスの特定のクラスに適用される要件の簡潔なリストです。この文書に記載されているプロファイルは、彼らが地元の環境に適しているかどうかを判断するために見直されるべきです。
It is anticipated that the requirements in this document will be used for the following purposes:
この文書の要件は次の目的で使用されることが予想されます。
o as a checklist when evaluating networked products,
ネットワーク接続された製品を評価するチェックリストとしてO、
o to create profiles of different subsets of the requirements which describe the needs of different devices, organizations, and operating environments,
oは、異なるデバイス、組織、およびオペレーティング環境のニーズを記述要件の異なるサブセットのプロファイルを作成するには
o to assist operators in clearly communicating their security requirements,
oが明確にセキュリティ要件を伝えるにオペレータを支援するため、
o as high level guidance for the creation of detailed test plans.
詳細なテスト計画を作成するためのOのような高レベルの指導。
RFC 2119 Keywords
RFC 2119のキーワード
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The use of the RFC 2119 keywords is an attempt, by the editor, to assign the correct requirement levels ("MUST", "SHOULD", "MAY"...). It must be noted that different organizations, operational environments, policies and legal environments will generate different requirement levels. Operators and vendors should carefully consider the individual requirements listed here in their own context. One size does not fit all.
RFC 2119個のキーワードを使用すると、正しい要件レベルを割り当てるために、エディタの試み、（「MUST」は、「SHOULD」、...「MAY」）です。異なる組織、運用環境、政策や法的環境が異なる要件レベルを生成することに留意しなければなりません。事業者やベンダーは慎重に、独自の文脈でここに記載されている個々の要件を考慮する必要があります。ワンサイズは、すべてに適合していません。
Bogon.
Bogon。
A "Bogon" (plural: "bogons") is a packet with an IP source address in an address block not yet allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...) as well as all addresses reserved for private or special use by RFCs. See [RFC3330] and [RFC1918].
「Bogon」（複数：「bogons」）はまだIANAまたは地域インターネットレジストリ（ARIN、RIPE、APNIC ...）によって割り当てられていないアドレスブロック内のIP送信元アドレスを持つパケットだけでなく、ために予約すべてのアドレスでありますRFCでプライベートまたは特殊な使用。 [RFC3330]と[RFC1918]を参照してください。
CLI.
CLI。
Several requirements refer to a Command Line Interface (CLI). While this refers at present to a classic text oriented command interface, it is not intended to preclude other mechanisms which may meet all the requirements that reference "CLI".
いくつかの要件は、コマンドラインインタフェース（CLI）を参照してください。これは古典的なテキスト指向のコマンドインターフェイスに現時点で言及するが、「CLI」を参照するすべての要件を満たすことができる他の機構を排除するものではありません。
Console.
コンソール。
Several requirements refer to a "Console". The model for this is the classic RS232 serial port which has, for the past 30 or more years, provided a simple, stable, reliable, well-understood and nearly ubiquitous management interface to network devices. Again, these requirements are intended primarily to codify the benefits provided by that venerable interface, not to preclude other mechanisms that meet all the same requirements.
いくつかの要件は、「コンソール」を参照してください。このためのモデルは、過去30年以上、ネットワーク装置への単純な、安定した、信頼性の高い、十分に理解され、ほぼユビキタス管理インターフェイスを提供している古典的なRS232シリアルポートです。ここでも、これらの要件は、主に、すべて同じ要件を満たす他のメカニズムを排除するために、その由緒あるインタフェースによって提供される利点をない成文化することを意図しています。
Filter.
フィルタ。
In this document, a "filter" is defined as a group of one or more rules where each rule specifies one or more match criteria as specified in Section 2.8.
この文書では、「フィルタ」は、セクション2.8で指定されるように各ルールは、1つまたは複数の一致基準を指定する1つまたは複数のルールの集合として定義されます。
In-Band management.
インバンド管理。
"In-Band management" is defined as any management done over the same channels and interfaces used for user/customer data. Examples would include using SSH for management via customer or Internet facing network interfaces.
「インバンド管理」は、ユーザ/顧客データのために使用されるのと同じチャネルおよびインターフェイス上で行わ任意管理として定義されます。例としては、顧客またはインターネットに面したネットワークインタフェースを介して管理用のSSHを使用して含まれるであろう。
High Resolution Time.
高解像度の時間。
"High resolution time" is defined in this document as "time having a resolution greater than one second" (e.g., milliseconds).
「高解像度の時間」（例えば、ミリ秒）、「1秒よりも大きい解像度を有する時間」として本書で定義されています。
IP.
IP。
Unless otherwise indicated, "IP" refers to IPv4.
特に断りのない限り、「IPは、」IPv4のを指します。
Management.
管理。
This document uses a broad definition of the term "management". In this document, "management" refers to any authorized interaction with the device intended to change its operational state or configuration. Data/Forwarding plane functions (e.g., the transit of customer traffic) are not considered management. Control plane functions such as routing, signaling and link management protocols and management plane functions such as remote access, configuration and authentication are considered to be management.
この文書では、用語「経営」の広義の定義を使用しています。この文書では、「管理」は、動作状態や構成を変更することを目的とデバイスとの任意の認可の相互作用を指します。データ/転送プレーン機能（例えば、顧客トラフィックの通過）を管理考慮されません。そのようなルーティング、シグナリング、およびリンク管理プロトコルと、リモートアクセス、構成、および認証などの管理プレーン機能として制御プレーン機能は、管理であると考えられます。
Martian.
火星。
Per [RFC1208] "Martian: Humorous term applied to packets that turn up unexpectedly on the wrong network because of bogus routing entries. Also used as a name for a packet which has an altogether bogus (non-registered or ill-formed) Internet address." For the purposes of this document Martians are defined as "packets having a source address that, by application of the current forwarding tables, would not have its return traffic routed back to the sender." "Spoofed packets" are a common source of martians.
パー[RFC1208]「火星：理由は偽のルーティングエントリの間違ったネットワーク上で予想外に上げパケットに適用ユーモラスな用語も全くにせ（非登録または病気に形成された）のインターネットアドレスを持つパケットの名前として使用。 。」このドキュメントの目的のために火星人は次のように定義されている「パケットが現在の転送テーブルを適用することにより、そのリターントラフィックが送信者にルーティングされていないと、送信元アドレスを持ちます。」 「なりすましパケットは、」火星人の共通のソースです。
Note that in some cases, the traffic may be asymmetric, and a simple forwarding table check might produce false positives. See [RFC3704]
いくつかのケースでは、トラフィックが非対称であってもよいことに注意してください、とシンプルな転送テーブルのチェックは偽陽性を生じる可能性があります。 [RFC3704]を参照してください。
Out-of-Band (OoB) management.
アウトオブバンド（OOB）管理。
"Out-of-Band management" is defined as any management done over channels and interfaces that are separate from those used for user/customer data. Examples would include a serial console interface or a network interface connected to a dedicated management network that is not used to carry customer traffic.
「アウトオブバンド管理は」チャネルおよびユーザー/顧客データのために使用されるものとは別のインターフェースを介して行わ任意管理として定義されます。例としては、シリアルコンソールインターフェースまたは顧客トラフィックを運ぶために使用されない専用の管理ネットワークに接続されたネットワークインターフェースを含むであろう。
Open Review.
レビューを開きます。
"Open review" refers to processes designed to generate public discussion and review of proposed technical solutions such as data communications protocols and cryptographic algorithms with the goals of improving and building confidence in the final solutions.
「オープン・レビュー」は、データの通信プロトコルと、最終的なソリューションの信頼性を向上し、建物の目標と暗号化アルゴリズムとして提案された技術的な解決策の公開議論と検討を生成するように設計プロセスを指します。
For the purposes of this document "open review" is defined by [RFC2026]. All standards track documents are considered to have been through an open review process.
このドキュメントの目的のために「オープン件の口コミ」[RFC2026]で定義されています。すべての標準トラック文書がオープンレビュープロセスをしてきたと考えられています。
It should be noted that organizations may have local requirements that define what they view as acceptable "open review". For example, they may be required to adhere to certain national or international standards. Such modifications of the definition of the term "open review", while important, are considered local issues that should be discussed between the organization and the vendor.
組織が許容される「公開審査」として見るものを定義する地域の要件を持っていることに留意すべきです。例えば、彼らは、特定の国や国際基準を遵守するために必要な場合があります。用語「オープン・レビュー」の定義のような修飾は、重要ながら、組織とベンダーの間で議論されるべきである地域の問題と考えられています。
It should also be noted that section 7 of [RFC2026] permits standards track documents to incorporate other "external standards and specifications".
また、[RFC2026]のセクション7は、他の「外部標準と仕様」を組み込むための標準トラック文書を許可することに留意すべきです。
Service.
サービス。
A number of requirements refer to "services". For the purposes of this document a "service" is defined as "any process or protocol running in the control or management planes to which non-transit packets may be delivered". Examples might include an SSH server, a BGP process or an NTP server. It would also include the transport, network and link layer protocols since, for example, a TCP packet addressed to a port on which no service is listening will be "delivered" to the IP stack, and possibly result in an ICMP message being sent back.
多くの要件は、「サービス」を参照してください。本文書の目的のための「サービス」は、「非トランジットパケットが送達されてもよいれる制御又は管理プレーン内の任意のプロセス又はプロトコル実行」として定義されます。例としては、SSHサーバ、BGPプロセスまたはNTPサーバーが含まれる場合があります。また、例えば、TCPパケットが何のサービスがリッスンしていないIPスタックに「配信」されるポート宛の、以来、輸送、ネットワークおよびリンク層プロトコルが含まれ、そしておそらく戻って送信されるICMPメッセージにつながります。
Secure Channel.
セキュリティで保護されたチャネル。
A "secure channel" is a mechanism that ensures end-to-end integrity and confidentiality of communications. Examples include TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a console port using physically secure, shielded cable would provide confidentiality but possibly not integrity.
「安全なチャネルは、」通信のエンドツーエンドの完全性と機密性を保証するためのメカニズムです。例としては、TLS [RFC2246]とIPsec [RFC2401]を含みます。守秘義務はなく、おそらくないの整合性を提供する物理的に安全、シールドケーブルを使用してコンソールポートに端末を接続します。
Single-Homed Network.
シングルホームネットワーク。
A "single-homed network" is defined as one for which
「シングルホームネットワークが」のための1つとして定義されています
* There is only one upstream connection
*一つだけのアップストリーム接続があります
* Routing is symmetric.
*ルーティングが対称です。
See [RFC3704] for a discussion of related issues and mechanisms for multihomed networks.
マルチホームネットワークのための関連の問題やメカニズムの議論のための[RFC3704]を参照してください。
Spoofed Packet.
偽装されたパケット。
A "spoofed packet" is defined as a packet that has a source address that does not correspond to any address assigned to the system which sent the packet. Spoofed packets are often "bogons" or "martians".
「スプーフィングされたパケットは、」パケットを送信したシステムに割り当てられたアドレスに対応していない送信元アドレスを有するパケットとして定義されます。偽装されたパケットは、しばしば「bogons」または「火星人」です。
The requirements in this section are intended to list testable, functional requirements that are needed to operate devices securely.
このセクションの要件が確実にデバイスを動作させるために必要とされているテスト可能な、機能要件をリストアップすることを意図しています。
Requirement.
要求。
The device MUST provide mechanisms to ensure end-to-end integrity and confidentiality for all network traffic and protocols used to support management functions. This MUST include at least protocols used for configuration, monitoring, configuration backup and restore, logging, time synchronization, authentication, and routing.
デバイスは、すべてのネットワークトラフィックと管理機能をサポートするために使用されるプロトコルのためのエンドツーエンドの完全性と機密性を確保するためのメカニズムを提供しなければなりません。これは、設定、監視、設定のバックアップとリストア、ログ、時刻同期、認証、およびルーティングに使用される少なくともプロトコルを含まなければなりません。
Justification.
正当化。
Integrity protection is required to ensure that unauthorized users cannot manage the device or alter log data or the results of management commands. Confidentiality is required so that unauthorized users cannot view sensitive information, such as keys, passwords, or the identity of users.
完全性保護は、権限のないユーザーがデバイスを管理したり、ログデータや管理コマンドの結果を変えることができないことを保証するために必要とされます。権限のないユーザーは、このようなキー、パスワード、またはユーザの身元などの機密情報を、閲覧できないように機密性が要求されます。
Examples.
例。
See [RFC3631] for a current list of mechanisms that can be used to support secure management.
安全な管理をサポートするために使用することができるメカニズムの現在のリストについては、[RFC3631]を参照してください。
Later sections list requirements for supporting in-band management (Section 2.2) and out-of-band management (Section 2.3) as well as trade-offs that must be weighed in considering which is appropriate to a given situation.
インバンド管理（2.2節）とアウトオブバンド管理（2.3節）だけでなく、与えられた状況に適切である考慮して検討しなければならないトレードオフをサポートするため、後のセクションのリストの要件。
Warnings.
警告。
None.
無し。
This section lists security requirements that support secure in-band management. In-band management has the advantage of lower cost (no extra interfaces or lines), but has significant security disadvantages:
このセクションでは、安全なインバンド管理をサポートするセキュリティ要件を示しています。帯域内管理は、より低いコスト（余分なインターフェイスまたはライン）の利点を有するが、重大なセキュリティ上の欠点を有します。
o Saturation of customer lines or interfaces can make the device unmanageable unless out-of-band management resources have been reserved.
帯域外管理リソースが予約されていない限り、O、顧客の回線またはインターフェイスの飽和は、デバイスが管理不能にすることができます。
o Since public interfaces/channels are used, it is possible for attackers to directly address and reach the device and to attempt management functions.
パブリックインターフェイス/チャネルが使用されるので、攻撃者が直接対処し、到達装置と管理機能を試みるするO、それが可能です。
o In-band management traffic on public interfaces may be intercepted, however this would typically require a significant compromise in the routing system.
パブリックインターフェイス上のOインバンド管理トラフィックは、しかし、これは、典型的には、ルーティングシステムの大幅な妥協を必要とするであろう、傍受されてもよいです。
o Public interfaces used for in-band management may become unavailable due to bugs (e.g., buffer overflows being exploited) while out-of-band interfaces (such as a serial console device) remain available.
（シリアルコンソールデバイスなど）の帯域外インタフェースが利用可能なままO帯域内管理に使用されるパブリックインターフェイス（例えば、バッファが利用されるオーバーフロー）によるバグに使用できなくなることがあります。
There are many situations where in-band management makes sense, is used, and/or is the only option. The following requirements are meant to provide means of securing in-band management traffic.
インバンド管理は、理にかなって使用され、および/または唯一のオプションである多くの状況があります。次の要件は、インバンド管理トラフィックを保護する手段を提供することを意図しています。
Requirement.
要求。
If cryptography is used to provide secure management functions, then there MUST be an option to use algorithms that are subject to "open review" as defined in Section 1.8 to provide these functions. These SHOULD be used by default. The device MAY optionally support algorithms that are not open to review.
暗号は安全な管理機能を提供するために使用されている場合は、これらの機能を提供するために、1.8節で定義された「オープン見直し」の対象となっているアルゴリズムを使用するオプションがあるに違いありません。これらは、デフォルトで使用されるべきです。デバイスは、クチコミを開いていないサポートアルゴリズムを、任意に。
Justification.
正当化。
Cryptographic algorithms that have not been subjected to widespread, extended public/peer review are more likely to have undiscovered weaknesses or flaws than open standards and publicly reviewed algorithms. Network operators may have need or desire to use non-open cryptographic algorithms. They should be allowed to evaluate the trade-offs and make an informed choice between open and non-open cryptography. See [Schneier] for further discussion.
広範囲に、拡張されたパブリック/ピアレビューを受けていない暗号化アルゴリズムは、未知の弱点やオープンな標準よりも欠陥や公的審査のアルゴリズムを持っている可能性があります。ネットワークオペレータは非オープン暗号化アルゴリズムを使用する必要性や欲求を持っていることがあります。彼らは、トレードオフを評価し、オープンと非オープン暗号間の情報に基づいた選択をすることを許可する必要があります。さらなる議論のために[シュナイアー]を参照してください。
Examples.
例。
The following are some algorithms that satisfy the requirement at the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for applications requiring symmetric encryption; RSA [RFC3447] and Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications requiring message verification.
対称暗号化を必要とする用途のためのAES [FIPS.197]、および3DES [ANSI.X9-52.1998];以下は、書き込み時に要求を満たすいくつかのアルゴリズムでありますRSA [RFC3447]及び鍵交換を必要とするアプリケーションにディフィー - ヘルマン[PKCS.3.1993]、[RFC2631]。 HMACメッセージ認証を必要とするアプリケーションのためのSHA-1 [RFC3174]と[RFC2401]。
Warnings.
警告。
This list is not exhaustive. Other strong, well-reviewed algorithms may meet the requirement. The dynamic nature of the field means that what is good enough today may not be in the future.
このリストは網羅的なものではありません。他の強力な、よく検討アルゴリズムが要件を満たすことがあります。フィールドの動的な性質は、良いものを十分に今日は、将来的にではないかもしれないということを意味します。
Open review is necessary but not sufficient. The strength of the algorithm and key length must also be considered. For example, 56-bit DES meets the open review requirement, but is today considered too weak and is therefore not recommended.
オープン見直しは必要であるが十分ではありません。アルゴリズムと鍵の長さの強度も考慮しなければなりません。例えば、56ビットDESは公開審査の要件を満たしているが、今日は弱すぎると考えられているため、推奨されません。
Requirement.
要求。
If cryptography is used to meet the secure management channel requirements, then the key lengths and algorithms SHOULD be "strong".
暗号は安全な管理チャネルの要件を満たすために使用されている場合は、鍵長とアルゴリズムは、「強い」である必要があります。
Justification.
正当化。
Short keys and weak algorithms threaten the confidentiality and integrity of communications.
ショートキーと弱いアルゴリズムは、通信の機密性と完全性を脅かします。
Examples.
例。
The following algorithms satisfy the requirement at the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for applications requiring symmetric encryption; RSA [RFC3447] and Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications requiring message verification.
対称暗号化を必要とする用途のためのAES [FIPS.197]、および3DES [ANSI.X9-52.1998];次のアルゴリズムは、書き込み時の要件を満たしますRSA [RFC3447]及び鍵交換を必要とするアプリケーションにディフィー - ヘルマン[PKCS.3.1993]、[RFC2631]。 HMACメッセージ認証を必要とするアプリケーションのためのSHA-1 [RFC3174]と[RFC2401]。
Note that for *new protocols* [RFC3631] says the following: "Simple keyed hashes based on MD5 [RFC1321], such as that used in the BGP session security mechanism [RFC2385], are especially to be avoided in new protocols, given the hints of weakness in MD5." While use of such hashes in deployed products and protocols is preferable to a complete lack of integrity and authentication checks, this document concurs with the recommendation that new products and protocols strongly consider alternatives.
*新しいプロトコル* [RFC3631]のためのそれは、次の言う注意：「なBGPセッションセキュリティ・メカニズム[RFC2385]で使用したものとMD5 [RFC1321]に基づいて、簡単なキー付きハッシュを、特に与えられ、新しいプロトコルで回避されるべきですMD5の弱点のヒント。」展開された製品とプロトコルで、このようなハッシュの使用は整合性と認証チェックの完全な欠如に好ましいが、この文書は、新しい製品やプロトコルが強く代替案を検討する勧告に同意します。
Warnings.
警告。
This list is not exhaustive. Other strong, well-reviewed algorithms may meet the requirement. The dynamic nature of the field means that what is good enough today may not be in the future.
このリストは網羅的なものではありません。他の強力な、よく検討アルゴリズムが要件を満たすことがあります。フィールドの動的な性質は、良いものを十分に今日は、将来的にではないかもしれないということを意味します。
Strength is relative. Long keys and strong algorithms are intended to increase the work factor required to compromise the security of the data protected. Over time, as processing power increases, the security provided by a given algorithm and key length will degrade. The definition of "Strong" must be constantly reevaluated.
強度は相対的です。長いキーと強力なアルゴリズムが保護されたデータのセキュリティを侵害するために必要な作業率を高めることを意図しています。時間が経つにつれて、電力増加の処理として、与えられたアルゴリズムと鍵の長さによって提供されるセキュリティは低下します。 「強い」の定義は常に再評価されなければなりません。
There may be legal issues governing the use of cryptography and the strength of cryptography used.
暗号の使用及び使用暗号化の強度を規定する法的な問題があるかもしれません。
This document explicitly does not attempt to make any authoritative statement about what key lengths constitute "strong" cryptography. See [RFC3562] and [RFC3766] for help in determining appropriate key lengths. Also see [Schneier] chapter 7 for a discussion of key lengths.
この文書は、明示的にキーの長さは、「強い」暗号を構成するかについていかなる権威声明を作るしようとしません。適切なキーの長さを決定する際に役立つための[RFC3562]と[RFC3766]を参照してください。また、キーの長さの議論のための[シュナイアー]第7章を参照してください。
Requirement.
要求。
If cryptography is used to provide secure management channels, then its use MUST be supported in protocols that are subject to "open review" as defined in Section 1.8. These SHOULD be used by default. The device MAY optionally support the use of cryptography in protocols that are not open to review.
暗号は安全な管理チャネルを提供するために使用されている場合は、その使用は、セクション1.8で定義されている「公開審査」の対象となるプロトコルでサポートしなければなりません。これらは、デフォルトで使用されるべきです。デバイスは、必要に応じて見直すために開いていないプロトコルにおける暗号の使用をサポートするかもしれません。
Justification.
正当化。
Protocols that have not been subjected to widespread, extended public/peer review are more likely to have undiscovered weaknesses or flaws than open standards and publicly reviewed protocols Network operators may have need or desire to use non-open protocols They should be allowed to evaluate the trade-offs and make an informed choice between open and non-open protocols.
ネットワークオペレータは、非オープンプロトコルを使用する必要性や欲求を持っているかもしれ彼らは評価するために許されるべき広範な、拡張されたパブリック/ピアレビューを受けていないプロトコルはオープンな標準よりも未知の弱点や欠陥を持っている可能性があり、公表見直しプロトコルトレードオフとオープンと非オープンプロトコル間の情報に基づいた選択をします。
Examples.
例。
See TLS [RFC2246] and IPsec [RFC2401].
TLS [RFC2246]とIPsec [RFC2401]を参照してください。
Warnings.
警告。
Note that open review is necessary but may not be sufficient. It is perfectly possible for an openly reviewed protocol to misuse (or not use) cryptography.
公開審査が必要であるが、十分ではないかもしれないことに注意してください。公然レビュープロトコルは、暗号化を誤用（または使用しない）することは完全に可能です。
Requirement.
要求。
The device SHOULD allow the operator to select cryptographic parameters. This SHOULD include key lengths and algorithms.
デバイスは、オペレータが、暗号化パラメータを選択できるようにする必要があります。これは、鍵長とアルゴリズムを含むべきです。
Justification.
正当化。
Cryptography using certain algorithms and key lengths may be considered "strong" at one point in time, but "weak" at another. The constant increase in compute power continually reduces the time needed to break cryptography of a certain strength. Weaknesses may be discovered in algorithms. The ability to select a different algorithm is a useful tool for maintaining security in the face of such discoveries.
特定のアルゴリズムおよび鍵長を使用して暗号化は、他の時刻における一点で「強い」が、「弱い」と考えることができます。コンピューティングパワーの一定の増加が継続的に一定の強度の暗号を破るために必要な時間を短縮します。弱点はアルゴリズムで発見することができます。異なるアルゴリズムを選択する能力は、このような発見の面でセキュリティを維持するための有用なツールです。
Examples.
例。
56-bit DES was once considered secure. In 1998 it was cracked by custom built machine in under 3 days. The ability to select algorithms and key lengths would give the operator options (different algorithms, longer keys) in the face of such developments.
56ビットDESを一旦安全であると考えられました。 1998年に、それは3日の下に特注機でひび割れました。アルゴリズムと鍵の長さを選択する能力は、そのような開発の面におけるオペレータのオプション（異なるアルゴリズム、より長い鍵）を与えるだろう。
Warnings.
警告。
None.
無し。
Requirement.
要求。
Management functions SHOULD be processed at higher priority than non-management traffic. This SHOULD include ingress, egress, internal transmission, and processing. This SHOULD include at least protocols used for configuration, monitoring, configuration backup, logging, time synchronization, authentication, and routing.
管理機能は非管理トラフィックよりも高い優先度で処理されるべきです。これは、入口、出口、内部透過率、および処理が含まれるべきです。これは、設定、監視、構成、バックアップ、ロギング、時間同期、認証、ルーティングに使用される少なくともプロトコルを含むべきです。
Justification.
正当化。
Certain attacks (and normal operation) can cause resource saturation such as link congestion, memory exhaustion or CPU overload. In these cases it is important that management functions be prioritized to ensure that operators have the tools needed to recover from the attack.
特定の攻撃（通常動作）は、このようなリンクの混雑、メモリの枯渇やCPUの過負荷などのリソースの飽和を引き起こす可能性があります。これらの場合には、管理機能は、オペレーターが攻撃から回復するために必要なツールを持っていることを確認するために優先順位をつけておくことが重要です。
Examples.
例。
Imagine a service provider with 1,000,000 DSL subscribers, most of whom have no firewall protection. Imagine that a large portion of these subscribers machines were infected with a new worm that enabled them to be used in coordinated fashion as part of large denial of service attack that involved flooding. It is entirely possible that without prioritization such an attack would cause link congestion resulting in routing adjacencies being lost. A DoS attack against hosts has just become a DoS attack against the network.
ファイアウォール保護を持っていないほとんどの人の1,000,000 DSL加入者とサービスプロバイダを想像してみてください。これらの加入者のマシンの大部分が浸水を関与サービス攻撃の大拒否の一環として、協調方式で使用するためにそれらを有効に新しいワームに感染していたことを想像してみてください。優先順位付けすることなく、このような攻撃は、ルーティング隣接関係が得られたリンクの輻輳が失われてしまうということは完全に可能です。ホストに対するDoS攻撃は、ちょうどネットワークに対するDoS攻撃となっています。
Warnings.
警告。
Prioritization is not a panacea. Routing update packets may not make it across a saturated link. This requirement simply says that the device should prioritize management functions within its scope of control (e.g., ingress, egress, internal transit, processing). To the extent that this is done across an entire network, the overall effect will be to ensure that the network remains manageable.
優先順位付けは万能薬ではありません。ルーティングアップデートパケットは、飽和リンクを渡ってそれをしないことがあります。この要件は、単にデバイスを制御（例えば、入口、出口、内部輸送、処理）のその範囲内に管理機能を優先すべきであると述べています。これは、ネットワーク全体に行われる程度に、全体的な効果は、ネットワークを管理ままであることを確実にするであろう。
See Section 2.2 for a discussion of the advantages and disadvantages of In-band vs. Out-of-Band management.
インバンド対アウトオブバンド管理の長所と短所についての議論については、セクション2.2を参照してください。
These requirements assume two different possible Out-of-Band topologies:
これらの要件は、二つの異なる可能アウトオブバンドトポロジを前提としています。
o serial line (or equivalent) console connections using a CLI,
シリアルライン（または同等の）CLIを使用して、コンソール接続O、
o network interfaces connected to a separate network dedicated to management.
管理専用の別個のネットワークに接続された入出力ネットワークインタフェース。
The following assumptions are made about out-of-band management:
以下の仮定は、アウトオブバンド管理について行われます。
o The out-of-band management network is secure.
Oアウトオブバンド管理ネットワークは安全です。
o Communications beyond the management interface (e.g., console port, management network interface) is secure.
管理インターフェイス（例えば、コンソールポート、管理ネットワークインターフェイス）を越えて通信が安全で、O。
o There is no need for encryption of communication on out-of-band management interfaces, (e.g., on a serial connection between a terminal server and a device's console port).
Oアウトオブバンド管理インターフェイス上の通信を暗号化する必要は（例えば、ターミナルサーバとデバイスのコンソールポートとの間のシリアル接続で）、存在しません。
o Security measures are in place to prevent unauthorized physical access.
Oセキュリティ対策は、不正な物理的なアクセスを防止するための場所です。
Even if these assumptions hold it would be wise, as an application of defense-in-depth, to apply the in-band requirements (e.g., encryption) to out-of-band interfaces.
これらの仮定が成立する場合でも、それがアウトオブバンドインターフェイスに帯域要求（例えば、暗号化）を適用するために、多層防御のアプリケーションとして、賢明であろう。
Requirement.
要求。
The device MUST support complete configuration and management via a 'console' interface that functions independently from the forwarding and IP control planes.
デバイスは、「コンソール」インターフェースを介して完全な構成および管理をサポートしなければならないこと転送およびIP制御プレーンから独立して機能します。
Justification.
正当化。
There are times when it is operationally necessary to be able to immediately and easily access a device for management or configuration, even when the network is unavailable, routing and network interfaces are incorrectly configured, the IP stack and/or operating system may not be working (or may be vulnerable to recently discovered exploits that make their use impossible/ inadvisable), or when high bandwidth paths to the device are unavailable. In such situations, a console interface can provide a way to manage and configure the device.
そこには、直ちにかつ容易に管理や構成のデバイスにアクセスできるように動作が必要である場合が、ネットワークが利用できない場合でも、ルーティングおよびネットワークインターフェイスが正しく構成されているIPスタック及び/又はオペレーティングシステムが動作していないかもしれデバイスへの高帯域幅パスが利用できない場合（または、それらの使用は/不可能得策する最近発見された攻撃に対して脆弱であってもよい）、又は。そのような状況では、コンソール・インターフェースは、デバイスを管理し、設定する方法を提供することができます。
Examples.
例。
An RS232 (EIA232) interface that provides the capability to load new versions of the system software and to perform configuration via a command line interface. RS232 interfaces are ubiquitous and well understood.
システムソフトウェアの新しいバージョンをロードすると、コマンドラインインターフェイスを介して設定を実行する能力を提供するRS232（EIA232）インターフェース。 RS232インタフェースは、ユビキタスとよく理解されています。
A simple embedded device that provides management and configuration access via an Ethernet or USB interface.
イーサネットまたはUSBインタフェースを介して管理およびコンフィギュレーションアクセスを提供する単純な組み込み機器。
As of this writing, RS232 is still strongly recommended as it provides the following benefits:
それは次のような利点を提供するので、これを書いている時点で、RS232はまだ強くお勧めします：
* Simplicity. RS232 is far simpler than the alternatives. It is simply a hardware specification. By contrast an Ethernet based solution might require an ethernet interface, an operating system, an IP stack and an HTTP server all to be functioning and properly configured.
*シンプル。 RS232は、代替案よりもはるかに簡単です。これは、単にハードウェアの仕様です。これとは対照的に、イーサネットベースのソリューションは、イーサネットインターフェース、オペレーティングシステム、IPスタックおよびHTTPサーバのすべてが機能して適切に設定することが必要な場合があります。
* Proven. RS232 has more than 30 years of use.
*実績。 RS232は、使用の30年以上を持っています。
* Well-Understood. Operators have a great deal of experience with RS232.
* 十分に理解。オペレータはRS232と多くの経験を持っています。
* Availability. It works even in the presence of network failure.
*空。それも、ネットワーク障害の存在下で動作します。
* Ubiquity. It is very widely deployed in mid to high end network infrastructure.
*ユビキタス。それは非常に広く、ハイエンドのネットワークインフラストラクチャへの半ばに配備されています。
* Low-Cost. The cost of adding a RS232 port to a device is small.
* 低価格。デバイスにRS232ポートを追加するコストは小さいです。
* CLI-Friendly. An RS232 interface and a CLI are sufficient in most cases to manage a device. No additional software is required.
* CLIフレンドリー。 RS232インターフェイスとCLIは、デバイスを管理するために、ほとんどのケースで十分です。追加のソフトウェアは必要ありません。
* Integrated. Operators have many solutions (terminal servers, etc.) currently deployed to support management via RS232.
*統合されました。オペレータは、多くのソリューション（ターミナル・サーバなど）は、現在、RS232を介して管理をサポートするために展開しています。
While other interfaces may be supplied, the properties listed above should be considered. Interfaces not having these properties may present challenges in terms of ease of use, integration or adoption. Problems in any of these areas could have negative security impacts, particularly in situations where the console must be used to quickly respond to incidents.
他のインターフェイスを供給することができるが、上記の特性が考慮されるべきです。インタフェースは、これらの特性は、使用、統合や採用の容易さの点で課題を提示することができる持っていません。これらの領域のいずれかの問題点は、特に、コンソールがすばやくインシデントに対応するために使用されなければならない状況では、負のセキュリティへの影響を持つことができます。
Warnings.
警告。
It is common practice is to connect RS232 ports to terminal servers that permit networked access for convenience. This increases the potential security exposure of mechanisms available only via RS232 ports. For example, a password recovery mechanism that is available only via RS232 might give a remote hacker to completely reconfigure a router. While operational procedures are beyond the scope of this document, it is important to note here that strong attention should be given to policies, procedures, access mechanisms and physical security governing access to console ports.
これは、一般的な方法は、利便性のために、ネットワークアクセスを許可するターミナルサーバーにRS232ポートを接続することです。これはRS232ポートを介して利用可能なメカニズムの潜在的なセキュリティリスクを増加させます。たとえば、唯一のRS232経由で利用できるパスワード回復メカニズムは完全にルータを再設定するために、リモートハッカーを与えるかもしれません。操作手順は、このドキュメントの範囲を超えていますが、強い関心が方針、手順、アクセス機構およびコンソールポートへのアクセスを管理する物理的なセキュリティに与えられるべきであることをここで注意することは重要です。
Requirement.
要求。
There MUST be a method defined and published for returning the console communication parameters to their default settings. This method must not require the current settings to be known.
デフォルト設定にコンソール通信パラメータを返すために定義されたと発表された方法があるに違いありません。この方法は、知られるように、現在の設定を要求してはなりません。
Justification.
正当化。
Having to guess at communications settings can waste time. In a crisis situation, the operator may need to get on the console of a device quickly.
時間を無駄にすることができ、通信の設定を推測しました。危機的状況では、オペレータはすぐにデバイスのコンソールに取得する必要があるかもしれません。
Examples.
例。
One method might be to send a break on a serial line.
一つの方法は、シリアルライン上のブレークを送信することかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The use of the 'console' interface MUST NOT require proprietary devices, protocol extensions or specific client software.
「コンソール」インターフェースの使用は、独自のデバイス、プロトコル拡張または特定のクライアントソフトウェアを要求することはできません。
Justification.
正当化。
The purpose of having the console interface is to have a management interface that can be made to work quickly at all times. Requiring complex or nonstandard behavior on the part of attached devices reduces the likelihood that the console will work without hassles.
コンソールインターフェイスを持つことの目的は、すべての回ですぐに動作させることができ、管理インターフェースを持つことです。接続されたデバイスの一部の複雑なまたは非標準の動作を要求することは、コンソールが口論なしで動作する可能性が低くなります。
Examples.
例。
If the console is supplied via an RS232 interface, then it should function with an attached device that only implements a "dumb" terminal. Support of "advanced" terminal features/types should be optional.
コンソールは、RS232インターフェースを介して供給される場合、それは唯一の「ダム」端末を実現する接続装置で機能すべきです。 「高度な」端末機能/タイプのサポートはオプションでなければなりません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The 'console' SHOULD support an authentication mechanism which does not require functional IP or depend on external services. This authentication mechanism MAY be disabled until a failure of other preferred mechanisms is detected.
「コンソール」は、機能IPを必要とするか、または外部サービスに依存しない認証機構をサポートする必要があります。他の好適なメカニズムの故障が検出されるまで、この認証機構が無効になることがあります。
Justification.
正当化。
It does little good to have a console interface on a device if you cannot get into the device with it when the network is not working.
これは、ネットワークが機能していないとき、あなたはそれを持つデバイスに入ることができない場合は、デバイス上のコンソールインタフェースを持つように少し良いを行います。
Examples.
例。
Some devices which use TACACS or RADIUS for authentication will fall back to a local account if the TACACS or RADIUS server does not reply to an authentication request.
TACACSまたはRADIUSサーバが認証要求に応答しない場合、認証にTACACSまたはRADIUSを使用する一部のデバイスには、背面ローカルアカウントに分類されます。
Warnings.
警告。
This requirement represents a trade-off between being able to manage the device (functionality) and security. There are many ways to implement this which would provide reduced security for the device, (e.g., a back door for unauthorized access). Local policy should be consulted to determine if "fail open" or "fail closed" is the correct stance. The implications of "fail closed" (e.g., not being able to manage a device) should be fully considered.
この要件は、デバイス（機能）とセキュリティを管理することができるとの間のトレードオフを表します。デバイスのため減少したセキュリティ、（例えば、不正アクセスのためのバックドア）を提供するこれを実装するための多くの方法があります。ローカルポリシーは、「フェールクローズ」「フェールオープン」またはかどうかを判断するために相談する必要があります正しい姿勢です。 （例えば、デバイスを管理することができない）「フェールクローズ」の意味は、完全に考慮されるべきです。
If the fall-back mechanism is disabled, it is important that the failure of IP based authentication mechanism be reliably detected and the fall-back mechanism automatically enabled...otherwise the operator may be left with no means to authenticate.
フォールバックメカニズムが無効になっている場合、そうでない場合、オペレータが認証する手段が残されて... IPベースの認証メカニズムの故障を確実に検出することと、フォールバックメカニズムが自動的に有効にすることが重要です。
Requirement.
要求。
The device MAY provide designated network interface(s) that are used for management plane traffic.
デバイスは、管理プレーントラフィックのために使用される指定されたネットワークインターフェース（単数または複数）を提供することができます。
Justification.
正当化。
A separate management plane interface allows management traffic to be segregated from other traffic (data/forwarding plane, control plane). This reduces the risk that unauthorized individuals will be able to observe management traffic and/or compromise the device.
別の管理プレーンインターフェイスは、管理トラフィックを他のトラフィック（データ/転送プレーン、制御プレーン）から分離することを可能にします。これは、不正な個人が管理トラフィックを観察および/またはデバイスを妥協することができるようになりますリスクを低減します。
This requirement applies in situations where a separate OoB management network exists.
この要件は、個別のOOB管理ネットワークが存在する状況で適用されます。
Examples.
例。
Ethernet port dedicated to management and isolated from customer traffic satisfies this requirement.
イーサネットポートの管理に特化し、顧客のトラフィックこの要件を満たしから分離されました。
Warnings.
警告。
The use of this type of interface depends on proper functioning of both the operating system and the IP stack, as well as good, known configuration at least on the portions of the device dedicated to management.
インターフェースのこの種の使用は、少なくとも管理専用装置の一部のオペレーティングシステムとIPスタックの両方の適切な機能、ならびに良好な、既知の構成に依存します。
Requirement.
要求。
If the device implements separate network interface(s) for the management plane per Section 2.3.5 then the device MUST NOT forward traffic between the management plane and non-management plane interfaces.
デバイスは、セクション2.3.5あたり管理プレーンのための別個のネットワークインターフェース（単数または複数）を実装する場合、デバイスは、管理プレーンと非管理プレーンインターフェイス間でトラフィックを転送してはいけません。
Justification.
正当化。
This prevents the flow, intentional or unintentional, of management traffic to/from places that it should not be originating/terminating (e.g., anything beyond the customer-facing interfaces).
これはに/それは（例えば、カスタマー側のインターフェイスを超えたもの）終端/発信されるべきではない場所からの管理トラフィックの、故意または意図しない、流れを阻止します。
Examples.
例。
Implementing separate forwarding tables for management plane and non-management plane interfaces that do not propagate routes to each other satisfies this requirement.
管理プレーンと、この要件互いに満足へのルートを伝播しない非管理プレーンインターフェイスのための別個の転送テーブルを実装します。
Warnings.
警告。
None.
無し。
This section lists requirements that support secure device configuration and management methods. In most cases, this currently involves some sort of command line interface (CLI) and configuration files. It may be possible to meet these requirements with other mechanisms, for instance SNMP or a script-able HTML interface that provides full access to management and configuration functions. In the future, there may be others (e.g., XML based configuration).
このセクションでは、セキュアデバイスの構成および管理方法をサポート要件を示します。ほとんどの場合、これは現在のコマンドラインインターフェイス（CLI）およびコンフィギュレーションファイルのいくつかの並べ替えを必要とします。例えばSNMPや管理および設定機能へのフルアクセスを提供するスクリプト可能なHTMLインターフェイスのために、他のメカニズムと、これらの要件を満たすことも可能です。将来的には、他の（例えば、XMLベースの構成）が存在してもよいです。
2.4.1. 'CLI' Provides Access to All Configuration and Management Functions
2.4.1. 「CLIは、」すべての構成と管理機能へのアクセスを提供します
Requirement.
要求。
The Command Line Interface (CLI) or equivalent MUST allow complete access to all configuration and management functions. The CLI MUST be supported on the console (see Section 2.3.1) and SHOULD be supported on all other interfaces used for management.
コマンドラインインタフェース（CLI）または同等のは、すべての設定と管理機能への完全なアクセスを許可する必要があります。 CLIは、コンソール上でサポートされなければならない（セクション2.3.1を参照）、管理に使用される他のすべてのインターフェイス上でサポートされてください。
Justification.
正当化。
The CLI (or equivalent) is needed to provide the ability to do reliable, fast, direct, local management and monitoring of a device. It is particularly useful in situations where it is not possible to manage and monitor the device in-band via "normal" means (e.g., SSH or SNMP [RFC3410], [RFC3411]) that depend on functional networking. Such situations often occur during security incidents such as bandwidth-based denial of service attacks.
CLI（または同等の）は、デバイスの信頼性の高い、高速で、直接、地元の管理と監視を行う能力を提供するために必要とされます。機能的なネットワークに依存し、「正常な」手段（例えば、SSHまたはSNMP [RFC3410]、[RFC3411]）を介して帯域内デバイスを管理および監視することができない状況で特に有用です。このような状況は、多くの場合、このようなサービス攻撃の帯域幅ベースの拒否などのセキュリティインシデント中に発生します。
Examples.
例。
Examples of configuration include setting interface addresses, defining and applying filters, configuring logging and authentication, etc. Examples of management functions include displaying dynamic state information such as CPU load, memory utilization, packet processing statistics, etc.
コンフィギュレーションの例には、管理機能など、インターフェイスアドレスを設定するフィルタを定義し、適用、ロギングおよび認証の構成としては、例えば、CPU等の負荷、メモリ使用率、パケット処理統計などの動的状態情報を表示含める含みます
Warnings.
警告。
None.
無し。
Requirement.
要求。
The CLI or equivalent MUST support external scripting of configuration functions. This CLI SHOULD support the same command set and syntax as that in Section 2.4.1.
CLIまたは同等の構成機能の外部スクリプトをサポートしなければなりません。このCLIは、2.4.1項と同様のコマンドセットと構文をサポートする必要があります。
Justification.
正当化。
During the handling of security incidents, it is often necessary to quickly make configuration changes on large numbers of devices. Doing so manually is error prone and slow. Vendor supplied management solutions do not always foresee or address the type or scale of solutions that are required. The ability to script provides a solution to these problems.
セキュリティインシデントの取り扱いの際、すぐに多数のデバイス上で設定変更を行うことがしばしば必要です。手動で行うと、エラーが発生しやすく、遅いです。ベンダー供給管理ソリューションは、常に必要とされているソリューションの種類や規模を予測したり対処しません。スクリプトへの能力は、これらの問題に対する解決策を提供します。
Examples.
例。
Example uses of scripting include: tracking an attack across a large network, updating authentication parameters, updating logging parameters, updating filters, configuration fetching/ auditing, etc. Some languages that are currently used for scripting include expect, Perl and TCL.
例は、スクリプトの使用を含む：現在のスクリプトのために使用されている一部の言語は、PerlやTCLを期待含めるなど、大規模なネットワークを介した攻撃を追跡する認証パラメータを更新し、ロギングパラメータを更新し、フィルタを更新し、コンフィギュレーション・フェッチ/監査。
Warnings.
警告。
Some properties of the command language that enhance the ability to script are: simplicity, regularity and consistency. Some implementations that would make scripting difficult or impossible include: "text menu" style interfaces (e.g., "curses" on UNIX) or a hard-coded GUI interfaces (e.g., a native Windows or Macintosh GUI application) that communicate using a proprietary or undocumented protocol not based on a CLI.
スクリプトの能力を高めるコマンド言語のいくつかのプロパティは次のとおりです。シンプルさ、規則性と一貫性。スクリプトが困難または不可能になるだろういくつかの実装が含まれます：「テキストメニュー」スタイル・インタフェース（例えば、UNIX上の「呪い」）、または独自のを使用して通信ハードコード化されたGUIインターフェース（例えば、ネイティブのWindowsやMacintoshのGUIアプリケーション）または文書化されていないプロトコルは、CLIに基づいていません。
Requirement.
要求。
The device MUST support a command line interface (CLI) or equivalent mechanism that works over low bandwidth connections.
デバイスは、低帯域幅接続で動作するコマンドラインインタフェース（CLI）または同等の機構をサポートしなければなりません。
Justification.
正当化。
There are situations where high bandwidth for management is not available, for example when in-band connections are overloaded during an attack or when low-bandwidth, out-of-band connections such as modems must be used. It is often under these conditions that it is most crucial to be able to perform management and configuration functions.
インバンド接続が攻撃時や低帯域幅は、アウトオブバンドモデムなどの接続を使用しなければならない時に、オーバーロードされたときに管理用の高帯域幅は、例えば、利用できない状況があります。管理と構成機能を実行できるようにするために最も重要であることこれらの条件の下で、多くの場合です。
Examples.
例。
The network is down. The network engineer just disabled routing by mistake on the sole gateway router in a remote unmanned data center. The only access to the device is over a modem connected to a console port. The data center customers are starting to call the support line. The GUI management interface is redrawing the screen multiple times...slowly... at 9600bps.
ネットワークがダウンしています。ネットワークエンジニアは、単にリモートの無人データセンター内で唯一のゲートウェイルータに誤ってルーティングを無効に。デバイスへのアクセスのみ、コンソールポートに接続されたモデムです。データセンターの顧客は、サポートラインを呼び出すために始めています。 GUI管理インターフェイスは、9600bpsにで...ゆっくりと...画面を複数回再描画されます。
One mechanism that supports operation over slow links is the ability to apply filters to the output of CLI commands which have potentially large output. This may be implemented with something similar to the UNIX pipe facility and "grep" command.
低速リンク上での動作をサポートして1つの機構は、潜在的に大きな出力を持っているCLIコマンドの出力にフィルタを適用する機能です。これは、UNIXのパイプ機能および「グレップ」コマンドに似た何かを実現することができます。
For example,
例えば、
cat largefile.txt | grep interesting-string
猫largefile.txt | grepの興味深い文字列
Another is the ability to "page" through large command output, e.g., the UNIX "more" command:
もう一つは、大規模なコマンドの出力、例えば、UNIX「より」コマンドを使用して能力を「ページ」です。
For example,
例えば、
cat largefile.txt | more
猫largefile.txt |もっと
Warnings.
警告。
One consequence of this requirement may be that requiring a GUI interface for management is unacceptable unless it can be shown to work acceptably over slow links.
この要件の1つの結果は、低速リンク上許容動作を示すことができる場合を除き、管理するためのGUIインタフェースを必要とすることは受け入れられないことであってもよいです。
Requirement.
要求。
The command line interface (CLI) or equivalent mechanism MUST support a configurable idle timeout value.
コマンドラインインタフェース（CLI）または同等の機構が設定アイドルタイムアウト値をサポートしなければなりません。
Justification.
正当化。
Network administrators go to lunch. They leave themselves logged in with administrative privileges. They forget to use screen-savers with password protection. They do this while at conferences and in other public places. This behavior presents opportunity for unauthorized access. Idle timeouts reduce the window of exposure.
ネットワーク管理者は、昼食に行きます。彼らは、自身が管理者権限でログインしたままにします。彼らは、パスワード保護されたスクリーンセーバーを使用することを忘れ。彼らは、会議やその他の公共の場所で、この中に操作を行います。この動作は、不正アクセスの機会を提供します。アイドルタイムアウトは、露出の窓を減らします。
Examples.
例。
The CLI may provide a configuration command that allows an idle timeout to be set. If the operator does not enter commands for that amount of time, the login session will be automatically terminated.
CLIは、アイドルタイムアウトを設定することを可能にするコンフィギュレーションコマンドを提供することができます。オペレータは、その時間のためのコマンドを入力しない場合は、ログインセッションが自動的に終了します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means to install new software versions. It MUST be possible to install new software while the device is disconnected from all public IP networks. This MUST NOT rely on previous installation and/or configuration. While new software MAY be loaded from writable media (disk, flash, etc.), the capability to load new software MUST depend only on non-writable media (ROM, etc.). The installation procedures SHOULD support mechanisms to ensure reliability and integrity of data transfers.
デバイスは、新しいソフトウェアバージョンをインストールするための手段を提供しなければなりません。デバイスがすべてのパブリックIPネットワークから切断されている間に、新しいソフトウェアをインストールすることは可能でなければなりません。これは、以前のインストールおよび/または構成に依存してはなりません。新しいソフトウェアは、書き込み可能なメディア（ディスク、フラッシュなど）からロードすることができるが、機能は非書き込み可能なメディア（ROMなど）にのみ依存しなければならない新しいソフトウェアをロードします。インストール手順は、データ転送の信頼性と整合性を確保するためのメカニズムをサポートする必要があります。
Justification.
正当化。
* Vulnerabilities are often discovered in the base software (operating systems, etc.) shipped by vendors. Often mitigation of the risk presented by these vulnerabilities can only be accomplished by updates to the vendor supplied software (e.g., bug fixes, new versions of code, etc.). Without a mechanism to load new vendor supplied code, it may not be possible to mitigate the risk posed by these vulnerabilities.
*脆弱性は、多くの場合、ベンダーが出荷された基本ソフトウェア（オペレーティングシステムなど）で発見されています。多くの場合、これらの脆弱性が提示するリスクの軽減が唯一のベンダー提供のソフトウェアにアップデートすることによって達成することができる（例えば、バグ修正、コードの新バージョン、など）。新しいベンダーが提供するコードをロードするメカニズムがなければ、これらの脆弱性によるリスクを軽減することは可能ではないかもしれません。
* It is also conceivable that malicious behavior on the part of hackers or unintentional behaviors on the part of operators could cause software on devices to be corrupted or erased. In these situations, it is necessary to have a means to (re)load software onto the device to restore correct functioning.
*ハッカーや事業者の一部に意図しない行動の一部の悪意のある動作がデバイス上のソフトウェアが破損または消去される可能性がありますということも考えられます。これらの状況では、正しい機能を復元するデバイスに（再）ロードソフトウェアの手段を有することが必要です。
* It is important to be able to load new software while disconnected from all public IP networks because the device may be vulnerable to old attacks before the update is complete.
アップデートが完了する前に、デバイスが古いの攻撃に対して脆弱である可能性があるので、*すべてのパブリックIPネットワークから切断しながら、新しいソフトウェアをロードできることが重要です。
* One has to assume that hackers, operators, etc. may erase or corrupt all writable media (disks, flash, etc.). In such situations, it is necessary to be able to recover starting with only non-writable media (e.g., CD-ROM, a true ROM-based monitor).
*一つは、ハッカーが、事業者は、などが破損しているすべての書き込み可能なメディア（ディスク、フラッシュなど）を消去したりすることを想定しています。そのような状況では、唯一の非書き込み可能な媒体（例えば、CD-ROM、真ROMベースモニタ）から始まる回復できることが必要です。
* System images may be corrupted in transit (from vendor to customer, or during the loading process) or in storage (bit rot, defective media, etc.). Failure to reliably load a new image, for example after a hacker deletes or corrupts the installed image, could result in extended loss of availability.
*システムのイメージが転送中に破損している可能性があり（仕入先から顧客に、又はロードプロセス中に）又は貯蔵中に（ビット腐敗、欠陥のあるメディア、等）。ハッカーがインストールされたイメージを削除または破損した後に確実に新しいイメージをロードする障害は、例えば、利用可能性の拡張損失をもたらす可能性があります。
Examples.
例。
The device could support booting into a simple ROM-based monitor that supported a set of commands sufficient to load new operating system code and configuration data from other devices. The operating system and configuration might be loaded from:
デバイスが他のデバイスからの新しいオペレーティング・システム・コードおよび構成データをロードするのに十分なコマンドのセットをサポート簡単なROMベースのモニタにブートサポートすることができます。オペレーティングシステムと構成がからロードされることがあります。
RS232. The device could support uploading new code via an RS232 console port.
RS232。デバイスは、RS232コンソールポート経由で新しいコードをアップロードしてサポートすることができました。
CD-ROM. The device could support installing new code from a locally attached CD-ROM drive.
のCD-ROM。デバイスは、ローカルに接続されたCD-ROMドライブから新しいコードをインストールサポートすることができました。
NETWORK. The device could support installing new code via a network interface, assuming that (a) it is disconnected from all public networks and (b) the device can boot an OS and IP stack from some read-only media with sufficient capabilities to load new code from the network.
通信網。デバイスは、（A）は、すべてのパブリックネットワークから切断され、（b）は、デバイスが新しいコードをロードするために十分な機能を持ついくつかの読み取り専用メディアからOSとIPスタックを起動することができると仮定し、ネットワークインターフェースを介して新たなコードをインストールするサポートすることができますネットワークから。
FLASH. The device could support booting from flash memory cards.
閃光。デバイスは、フラッシュメモリカードからのブートをサポートすることができます。
Simple mechanisms currently in use to protect the integrity of system images and data transfer include image checksums and simple serial file transfer protocols such as XMODEM and Kermit.
システムイメージとのデータ転送の整合性を保護するために現在使用されている単純なメカニズムは、画像チェックサムなどXMODEMとカーミットのような単純なシリアルファイル転送プロトコルを含みます。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means to store the system configuration to a remote server. The stored configuration MUST have sufficient information to restore the device to its operational state at the time the configuration is saved. Stored versions of the configuration MAY be compressed using an algorithm which is subject to open review, as long as the fact is clearly identified and the compression can be disabled. Sensitive information such as passwords that could be used to compromise the security of the device MAY be excluded from the saved configuration.
デバイスは、リモートサーバにシステム構成を格納するための手段を提供しなければなりません。保存された設定は、設定が保存された時点でその動作状態にデバイスを復元するために十分な情報を持っていなければなりません。コンフィギュレーションの保存されたバージョンは限り事実が明確に識別され、圧縮を無効にすることができるよう、見直しを開くことが課題であるアルゴリズムを用いて圧縮することができます。このようなデバイスのセキュリティを侵害するために使用することができ、パスワードなどの機密情報が保存された設定から除外することができます。
Justification.
正当化。
Archived configurations are essential to enable auditing and recovery.
アーカイブされた構成は、監査と回復を可能にするために不可欠です。
Examples.
例。
Possible implementations include SCP, SFTP or FTP over a secure channel. See Section 2.1.1 for requirements related to secure communication channels for management protocols and data.
可能な実装は、安全なチャネルを介してSCP、SFTPまたはFTPが含まれます。管理プロトコルとデータの通信チャネルを確保するために関連する要件については、セクション2.1.1を参照してください。
Warnings.
警告。
The security of the remote server is assumed, with appropriate measures being outside the scope of this document.
リモートサーバのセキュリティは、この文書の範囲外にある適切な措置と、想定されます。
Requirement.
要求。
The device MUST provide a means to restore a configuration that was saved as described in Section 2.4.6. The system MUST be restored to its operational state at the time the configuration was saved.
デバイスは、セクション2.4.6に記載されるように保存された設定を復元するための手段を提供しなければなりません。システムは、設定が保存された時点でその動作状態に復元する必要があります。
Justification.
正当化。
Restoration of archived configurations allows quick restoration of service following an outage (security related as well as from other causes).
アーカイブされたコンフィギュレーションの復元は、停止（他の原因からのセキュリティ関連など）次のサービスの迅速な復旧を可能にします。
Examples.
例。
Configurations may be restored using SCP, SFTP or FTP over a secure channel. See Section 2.1.1 for requirements related to secure communication channels for management protocols and data.
構成は、安全なチャネルを介してSCP、SFTPまたはFTPを使用して復元することができます。管理プロトコルとデータの通信チャネルを確保するために関連する要件については、セクション2.1.1を参照してください。
Warnings.
警告。
The security of the remote server is assumed, with appropriate measures being outside the scope of this document.
リモートサーバのセキュリティは、この文書の範囲外にある適切な措置と、想定されます。
Note that if passwords or other sensitive information are excluded from the saved copy of the configuration, as allowed by Section 2.4.6, then the restore may not be complete. The operator may have to set new passwords or supply other information that was not saved.
2.4.6項で許可されたとして、パスワードやその他の機密情報は、コンフィギュレーションの保存されたコピーから除外されている場合は、完全ではないかもしれない復元することに注意してください。オペレータは、新しいパスワードを設定したり、保存されなかった他の情報を提供する必要があります。
Requirement.
要求。
The device MUST support display, backup and restore of system configuration in a simple well defined textual format. The configuration MUST also be viewable as text on the device itself. It MUST NOT be necessary to use a proprietary program to view the configuration.
デバイスは、ディスプレイ、バックアップをサポートし、簡単な明確に定義されたテキスト形式のシステム構成を復元する必要があります。コンフィギュレーションは、デバイス自体のテキストとして閲覧可能でなければなりません。コンフィギュレーションを表示するには、独自のプログラムを使用する必要がてはなりません。
Justification.
正当化。
Simple, well-defined textual configurations facilitate human understanding of the operational state of the device, enable off-line audits, and facilitate automation. Requiring the use of a proprietary program to access the configuration inhibits these goals.
シンプルで、明確に定義されたテキストの構成は、デバイスの動作状態の人間の理解を容易にし、オフラインで監査を有効にし、自動化を促進します。設定にアクセスするために、独自のプログラムを使用することを要求することは、これらの目標を阻害します。
Examples.
例。
A 7-bit ASCII configuration file that shows the current settings of the various configuration options would satisfy the requirement, as would a Unicode configuration or any other "textual" representation. A structured binary format intended only for consumption by programs would not be acceptable.
ユニコード構成または任意の他の「テキスト」表現と同じようにさまざまな構成オプションの現在の設定を示す7ビットのASCII構成ファイルには、要件を満たすことになります。プログラムによってのみ消費のために意図され構造化されたバイナリ形式は受け入れられません。
Warnings.
警告。
Offline copies of configurations should be well protected as they often contain sensitive information such as SNMP community strings, passwords, network blocks, customer information, etc.
彼らはしばしばなどのSNMPコミュニティストリング、パスワード、ネットワークブロック、顧客情報などの機密情報が含まれているような構成のオフラインコピーが十分に保護されなければなりません
"Well defined" and "textual" are open to interpretation. Clearly an ASCII configuration file with a regular, documented command oriented-syntax would meet the definition. These are currently in wide use. Future options, such as XML based configuration may meet the requirement. Determining this will require evaluation against the justifications listed above.
「まあ定義された」と「原文は」解釈に開いています。明らかに定期的に、文書化コマンド指向構文を持つASCII設定ファイルは、定義を満たしています。これらは、現在広く用いられています。こうしたXMLベースの設定など、将来のオプションは、要件を満たすことがあります。これを決定することは、上記の正当性に対する評価が必要になります。
Requirement.
要求。
The vendor MUST:
ベンダーする必要があります。
* Provide a means to display all services that are listening for network traffic directed at the device from any external source.
*任意の外部ソースからデバイスに向けたネットワークトラフィックをリッスンしているすべてのサービスを表示するための手段を提供します。
* Display the addresses to which each service is bound.
※各サービスがバインドされているアドレスを表示します。
* Display the addresses assigned to each interface.
*各インターフェイスに割り当てられたアドレスを表示します。
* Display any and all port(s) on which the service is listing.
*サービスが一覧表示されている任意のおよびすべてのポートを表示します。
* Include both open standard and vendor proprietary services.
*オープンスタンダードとベンダー独自のサービスの両方を含めます。
Justification.
正当化。
This information is necessary to enable a thorough assessment of the security risks associated with the operation of the device (e.g., "does this protocol allow complete management of the device without also requiring authentication, authorization, or accounting?"). The information also assists in determining what steps should be taken to mitigate risk (e.g., "should I turn this service off ?")
この情報は、（例えば、「このプロトコルは、認証、許可、またはアカウンティングを必要とせずに、デバイスの完全な管理を許可しますか？」）、デバイスの動作に関連するセキュリティリスクの徹底的な評価を可能にするために必要です。情報は、（例えば、「私はこのサービスを無効にする必要がありますか？」）リスクを軽減するために取られるべきであるどのような手順を決定するのを助けます
Examples.
例。
If the device is listening for SNMP traffic from any source directed to the IP addresses of any of its local interfaces, then this requirement could be met by the provision of a command which displays that fact.
デバイスはそのローカルインターフェースのいずれかのIPアドレスに向けあらゆるソースからのSNMPトラフィックをリッスンしている場合、この要件は、その事実を表示するコマンドの提供によって満たすことができました。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means to turn off any "services" (see Section 1.8).
デバイスは、（1.8項を参照してください）すべての「サービス」をオフにする手段を提供しなければなりません。
Justification.
正当化。
The ability to disable services for which there is no operational need will allow administrators to reduce the overall risk posed to the device.
何も操作する必要はありませんそのためのサービスを無効にする機能は、管理者がデバイスにもたらされる全体的なリスクを軽減することができます。
Examples.
例。
Processes that listen on TCP and UDP ports would be prime examples of services that it must be possible to disable.
TCPおよびUDPポートをリッスンプロセスは、無効にすることが可能でなければならないサービスの主な例だろう。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means for the user to specify the bindings used for all listening services. It MUST support binding to any address or net-block associated with any interface local to the device. This must include addresses bound to physical or non-physical (e.g., loopback) interfaces.
デバイスは、すべてのリスニングサービスに使用されるバインディングを指定するためのユーザのための手段を提供しなければなりません。これは、デバイスにローカルの任意のインターフェイスに関連付けられた任意のアドレスまたはネットブロックへの結合をサポートしなければなりません。これは物理的または非物理的（例えば、ループバック）インターフェイスにバインドアドレスを含まなければなりません。
Justification.
正当化。
It is a common practice among operators to configure "loopback" pseudo-interfaces to use as the source and destination of management traffic. These are preferred to physical interfaces because they provide a stable, routable address. Services bound to the addresses of physical interface addresses might become unreachable if the associated hardware goes down, is removed, etc.
管理トラフィックの送信元および宛先として使用する「ループバック」疑似インターフェイスを設定する事業者の間で一般的です。彼らは安定して、ルーティング可能なアドレスを提供するので、これらは、物理インターフェイスに好まれます。関連するハードウェアがダウンした場合、到達不能になる可能性がある物理インターフェイスアドレスのアドレスにバインドされたサービスは、など、削除されます
This requirement makes it possible to restrict access to management services using routing. Management services may be bound only to the addresses of loopback interfaces. The loopback interfaces may be addressed out of net-blocks that are only routed between the managed devices and the authorized management networks/hosts. This has the effect of making it impossible for anyone to connect to (or attempt to DoS) management services from anywhere but the authorized management networks/hosts.
この要件は、ルーティングを使用して管理サービスへのアクセスを制限することが可能となります。管理サービスは、専用のループバックインタフェースのアドレスにバインドすることができます。ループバックインターフェイスは、管理対象デバイスと認可の管理ネットワーク/ホスト間でルーティングされ、ネットブロックの外に対処することができます。これは不可能誰でもどこからでも（または試みDoS攻撃への）管理サービスが、許可された管理ネットワーク/ホストに接続できるようにすることの効果があります。
It also greatly reduces the need for complex filters. It reduces the number of ports listening, and thus the number of potential avenues of attack. It ensures that only traffic arriving from legitimate addresses and/or on designated interfaces can access services on the device.
また、大幅に複雑なフィルタの必要性を低減します。これは、リスニングポートの数、ひいては攻撃の潜在的な道の数を減らすことができます。それは正当なアドレスからおよび/または指定されたインターフェイスに着信するトラフィックのみがデバイス上のサービスにアクセスできるようになります。
Examples.
例。
If the device listens for inbound SSH connections, this requirement means that it should be possible to specify that the device will only listen to connections destined to specific addresses (e.g., the address of the loopback interface) or received on certain interfaces (e.g., an Ethernet interface designated as the "management" interface). It should be possible in this example to configure the device such that the SSH is NOT listening to every address configured on the device. Similar effects may be achieved with the use of global filters, sometimes called "receive" or "loopback" ACLs, that filter traffic destined for the device itself on all interfaces.
デバイスは、着信SSH接続をリッスンする場合、この要件は、デバイスは、特定のアドレス（例えば、ループバックインタフェースのアドレス）宛の接続を聴いたり（特定のインターフェイス上で受信するように指定することが可能でなければならないことを意味し、例えば、 「管理」インターフェイスとして指定されたイーサネットインターフェイス）。これは、SSHは、デバイス上で設定されたすべてのアドレスを聞いされていないようにデバイスを設定するには、この例では可能なはずです。同様の効果は、時々、「受信」または「ループバック」のACLと呼ばれ、グローバルフィルタを使用して、すべてのインタフェース上のデバイス自体に宛てそのフィルタトラフィックを達成することができます。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means that allows the user to specify the source addresses used for all outbound connections or transmissions originating from the device. It SHOULD be possible to specify source addresses independently for each type of outbound connection or transmission. Source addresses MUST be limited to addresses that are assigned to interfaces (including loopbacks) local to the device.
装置は、ユーザがデバイスから発信されるすべての発信接続または送信のために使用されるソースアドレスを指定することを可能にする手段を提供しなければなりません。アウトバウンド接続または伝送のタイプごとに独立して送信元アドレスを指定することが可能であるべきです。送信元アドレスは、デバイスにローカル（ループバックを含む）インターフェースに割り当てられたアドレスに制限されなければなりません。
Justification.
正当化。
This allows remote devices receiving connections or transmissions to use source filtering as one means of authentication. For example, if SNMP traps were configured to use a known loopback address as their source, the SNMP workstation receiving the traps (or a firewall in front of it) could be configured to receive SNMP packets only from that address.
これは、リモートデバイスが認証の一の手段として、ソースフィルタリングを使用する接続または送信を受信することができます。 SNMPトラップがそのソースとして知られているループバックアドレスを使用するように構成された場合、例えば、トラップ（またはそれの前にファイアウォール）を受けるSNMPワークステーションは、そのアドレスからSNMPパケットを受信するように構成することができます。
Examples.
例。
The operator may allocate a distinct block of addresses from which all loopbacks are numbered. NTP and syslog can be configured to use those loopback addresses as source, while SNMP and BGP may be configured to use specific physical interface addresses. This would facilitate filtering based on source address as one way of rejecting unauthorized attempts to connect to peers/servers.
オペレータは、すべてのループバックが番号付けされ、そこからアドレスの異なるブロックを割り当てることができます。 SNMPとBGPは、特定の物理インターフェイスアドレスを使用するように構成されてもよいNTPとsyslogは、ソースとしてそれらのループバックアドレスを使用するように構成することができます。これは、ピア/サーバに接続する権限のない試みを拒絶する一つの方法として、送信元アドレスに基づいてフィルタリングを促進するであろう。
Warnings.
警告。
Care should be taken to assure that the addresses chosen are routable between the sending and receiving devices, (e.g., setting SSH to use a loopback address of 10.1.1.1 which is not routed between a router and all intended destinations could cause problems).
ケアは、選択されたアドレス（例えば、ルータとすべての目的の宛先の間でルーティングされていない10.1.1.1のループバックアドレスを使用するようにSSHを設定すると、問題を引き起こす可能性が）、送信側と受信側のデバイス間でルーティング可能であることを保証するために取られるべきです。
Note that some protocols, such as SCTP [RFC3309], can use more than one IP address as the endpoint of a single connection.
そのようなSCTP [RFC3309]などの一部のプロトコルは、単一の接続のエンドポイントとして複数のIPアドレスを使用することができることに留意されたいです。
Also note that [RFC3631] lists address-based authentication as an "insecurity mechanism". Address based authentication should be replaced or augmented by other mechanisms wherever possible.
また、[RFC3631]は「不安のメカニズム」などのアドレスベースの認証を示していますことに注意してください。アドレスベースの認証は、他のメカニズム、可能な限りに置き換えたり、拡張する必要があります。
Requirement.
要求。
The device MUST provide a means to designate particular interfaces as servicing "single-homed networks" (see Section 1.8) and MUST provide an option to automatically drop "spoofed packets" (Section 1.8) received on such interfaces where application of the current forwarding table would not route return traffic back through the same interface. This option MUST work in the presence of dynamic routing and dynamically assigned addresses.
装置は、インターフェイス上で受信された（セクション1.8）（セクション1.8参照）、自動的に「スプーフィングされたパケットを」ドロップするためのオプションを提供しなければなりません「とは、単一のホームネットワークを」保守のような特定のインターフェースを指定する手段を提供しなければならない場合、現在の転送テーブルの応用バックと同じインターフェイスを介してルートリターントラフィックではないだろう。このオプションは、ダイナミックルーティングとダイナミックに割り当てられたアドレスの存在下で働かなければなりません。
Justification.
正当化。
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of [RFC1812], and [RFC2827].
、[RFC1918]のセクション3を参照のセクション5.3.7及び[RFC1812]の5.3.8、および[RFC2827]。
Examples.
例。
This requirement could be satisfied in several ways. It could be satisfied by the provision of a single command that automatically generates and applies filters to an interface that implements anti-spoofing. It could be satisfied by the provision of a command that causes the return path for packets received to be checked against the current forwarding tables and dropped if they would not be forwarded back through the interface on which they were received.
この要件は、いくつかの方法で満たすことができました。それは、自動的に生成し、アンチスプーフィングを実装インタフェースにフィルタを適用する単一のコマンドを提供することによって満たすことができました。それは、彼らは、これが受信されたインタフェースを介して返送されない場合は、パケットが現在の転送テーブルに照らしてチェックされるように受け取られ、ドロップされたためにリターンパスを起こしコマンドの提供によって満たすことができます。
See [RFC3704].
[RFC3704]を参照してください。
Warnings.
警告。
This requirement only holds for single-homed networks. Note that a simple forwarding table check is not sufficient in the more complex scenarios of multi-homed or multi-attached networks, i.e., where the traffic may be asymmetric. In these cases, a more extensive check such as Feasible Path RPF could be very useful.
この要件は、唯一のシングルホームネットワークのために保持しています。単純な転送テーブルチェックがトラフィックが非対称であってもよい、すなわち、マルチホームまたはマルチ接続されたネットワークのより複雑なシナリオでは十分ではないことに留意されたいです。これらのケースでは、実行可能なパスRPFなどのより広範なチェックは非常に有用である可能性があります。
Requirement.
要求。
The device MUST provide a means to automatically drop all "bogons" (Section 1.8) and "martians" (Section 1.8). This option MUST work in the presence of dynamic routing and dynamically assigned addresses.
デバイスは自動的にすべての「bogons」（1.8項）と「火星人」（1.8項）をドロップする手段を提供しなければなりません。このオプションは、ダイナミックルーティングとダイナミックに割り当てられたアドレスの存在下で働かなければなりません。
Justification.
正当化。
These sorts of packets have little (no?) legitimate use and are used primarily to allow individuals and organization to avoid identification (and thus accountability) and appear to be most often used for DoS attacks, email abuse, hacking, etc. In addition, transiting these packets needlessly consumes resources and may lead to capacity and performance problems for customers.
パケットのこれらの種類は、さらになど、少し（なし？）合法的な使用を持っている個人や組織が識別（ひいては説明責任）を回避し、ほとんどの場合、DoS攻撃に使用されるように見えることができるように主に使用され、電子メールの乱用、ハッキングこれらのパケットを通過することは不必要なリソースを消費し、顧客のためのキャパシティとパフォーマンスの問題につながる可能性があります。
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of [RFC1812], and [RFC2827].
、[RFC1918]のセクション3を参照のセクション5.3.7及び[RFC1812]の5.3.8、および[RFC2827]。
Examples.
例。
This requirement could be satisfied by the provision of a command that causes the return path for packets received to be checked against the current forwarding tables and dropped if no viable return path exists. This assumes that steps are taken to assure that no bogon entries are present in the forwarding tables (for example filtering routing updates per Section 2.7.5 to reject advertisements of unassigned addresses).
この要件は、パケットのためのリターンパスは、現在の転送テーブルに照らしてチェックされるように受け取られ、何も実行可能なリターンパスが存在しない場合は廃棄させるコマンドの提供によって満たすことができます。これは、ステップがないbogonエントリが（例えば、割り当てられていないアドレスの広告を拒否するセクション2.7.5あたりの更新をルーティングフィルタリング）転送テーブルに存在しないことを保証するために取られることを前提としています。
See [RFC3704].
[RFC3704]を参照してください。
Warnings.
警告。
This requirement only holds for single-homed networks. Note that a simple forwarding table check is not sufficient in the more complex scenarios of multi-homed or multi-attached networks, i.e., where the traffic may be asymmetric. In these cases, a more extensive check such as Feasible Path RPF could be very useful.
この要件は、唯一のシングルホームネットワークのために保持しています。単純な転送テーブルチェックがトラフィックが非対称であってもよい、すなわち、マルチホームまたはマルチ接続されたネットワークのより複雑なシナリオでは十分ではないことに留意されたいです。これらのケースでは、実行可能なパスRPFなどのより広範なチェックは非常に有用である可能性があります。
Requirement.
要求。
The device MUST provide accurate, per-interface counts of spoofed packets dropped in accordance with Section 2.5.5 and Section 2.5.6.
デバイスは正確な提供しなければならない、偽装されたパケットのインターフェイス単位の数は、セクション2.5.5と2.5.6に従って低下しました。
Justification.
正当化。
Counters can help in identifying the source of spoofed traffic.
カウンタは、偽装されたトラフィックの送信元を識別するのに役立ちます。
Examples.
例。
An edge router may have several single-homed customers attached. When an attack using spoofed packets is detected, a quick check of counters may be able to identify which customer is attempting to send spoofed traffic.
エッジルータは、付属のいくつかのシングルホームの顧客を有していても良いです。偽装されたパケットを使用して、攻撃が検出されると、カウンタの簡単なチェックは、偽装されたトラフィックを送信しようとしている顧客を識別することができるかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide the capability to limit the rate at which it will pass traffic based on protocol, source and destination IP address or CIDR block, source and destination port, and interface. Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD include any protocol.
デバイスは、プロトコル、送信元および宛先IPアドレスまたはCIDRブロック、送信元および宛先ポート、およびインターフェイスに基づいてトラフィックを通過する速度を制限する能力を提供しなければなりません。プロトコルは、少なくともIP、ICMP、UDP、およびTCPを含まなければならないし、任意のプロトコルを含むべきです。
Justification.
正当化。
This requirement provides a means of reducing or eliminating the impact of certain types of attacks. Also, rate limiting has the advantage that in some cases it can be turned on a priori, thereby offering some ability to mitigate the effect of future attacks prior to any explicit operator reaction to the attacks.
この要件は、攻撃の特定の種類の影響を低減または除去する手段を提供します。また、レート制限は、いくつかのケースでは、それによって攻撃への明示的なオペレータの反応の前に将来の攻撃の影響を緩和するためにいくつかの機能を提供し、先験的に回すことができるという利点を有します。
Examples.
例。
Assume that a web hosting company provides space in its data-center to a company that becomes unpopular with a certain element of network users, who then decide to flood the web server with inbound ICMP traffic. It would be useful in such a situation to be able to rate-filter inbound ICMP traffic at the data-center's border routers. On the other side, assume that a new worm is released that infects vulnerable database servers such that they then start spewing traffic on TCP port 1433 aimed at random destination addresses as fast as the system and network interface of the infected server is capable. Further assume that a data center has many vulnerable servers that are infected and simultaneously sending large amounts of traffic with the result that all outbound links are saturated. Implementation of this requirement, would allow the network operator to rate limit inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0 packets/bytes per second) to respond to the attack and maintain service levels for other legitimate customers/traffic.
ウェブホスティング会社は、その後の着信ICMPトラフィックを持つWebサーバをあふれさせることにしたネットワークユーザの特定の要素に不人気になっ会社にそのデータセンター内のスペースを提供することを前提としています。データセンターの境界ルータで着信ICMPトラフィックフィルタを評価できるようにするには、このような状況で有用であろう。他の側では、新しいワームは、彼らはその後、早く感染したサーバーのシステムおよびネットワークインタフェースが可能であるようなランダム宛先アドレスに向けたTCPポート1433上のトラフィックを吐き出す開始するように、脆弱なデータベースサーバに感染がリリースされていることを前提としています。また、データセンターが感染したと同時に、すべてのアウトバウンドリンクが飽和している結果に大量のトラフィックを送信している多くの脆弱なサーバを持っていることを前提としています。この要件の実装は、ネットワークオペレータは攻撃に反応し、他の正当な顧客/交通のサービスレベルを維持するために制限インバウンドおよび/またはアウトバウンドTCPに（おそらく毎秒/バイト0のパケットのレートに）1433のトラフィックを評価することが可能になります。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide support to rate-limit input and/or output separately on each interface.
装置は、各インターフェイスで個別に速度制限入力及び/又は出力に支持を提供しなければなりません。
Justification.
正当化。
This level of granular control allows appropriately targeted controls that minimize the impact on third parties.
粒状このレベルの制御は、第三者への影響を最小限に抑える適切ターゲットコントロールを可能にします。
Examples.
例。
If an ICMP flood is directed a single customer on an edge router, it may be appropriate to rate-limit outbound ICMP only on that customers interface.
ICMPフラッドは、エッジルータ上の単一の顧客を向けられている場合は、それだけでその顧客のインターフェイス上での発信ICMP制限を評価することが適切であろう。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST be able to rate limit based on all TCP control flag bits. The device SHOULD support rate limiting of other stateful protocols where the normal processing of the protocol gives the device access to protocol state.
デバイスは、すべてのTCPコントロールフラグビットに基づいて限界を評価することができなければなりません。デバイスは、プロトコルの通常の処理は、プロトコル状態へのデバイスのアクセスを与える他のステートフルプロトコルのレート制限をサポートしなければなりません。
Justification.
正当化。
This allows appropriate response to certain classes of attack.
これは攻撃の特定のクラスに適切な対応を可能にします。
Examples.
例。
For example, for TCP sessions, it should be possible to rate limit based on the SYN, SYN-ACK, RST, or other bit state.
例えば、TCPセッションのために、SYN、SYN-ACK、RST、または他のビットの状態に基づいて、限界を評価することが可能であるべきです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means to filter IP packets on any interface implementing IP.
デバイスは、IPを実装する任意のインターフェイス上でIPパケットをフィルタリングするための手段を提供しなければなりません。
Justification.
正当化。
Packet filtering is important because it provides a basic means of implementing policies that specify which traffic is allowed and which is not. It also provides a basic tool for responding to malicious traffic.
それが許可されているトラフィックを指定政策を実現するための基本的な手段を提供されていないため、パケットフィルタリングは重要です。また、悪質なトラフィックに対応するための基本的なツールを提供しています。
Examples.
例。
Access control lists that allow filtering based on protocol and/or source/destination address and or source/destination port would be one example.
プロトコルおよび/またはソース/宛先アドレスと、ソース/宛先ポートに基づいてフィルタリングを可能にするアクセス制御リストは、一例であろう。
Warnings.
警告。
None.
無し。
Requirement.
要求。
It MUST be possible to apply the filtering mechanism to traffic that is addressed directly to the device via any of its interfaces - including loopback interfaces.
ループバックインターフェイスを含む - そのインターフェイスのいずれかを介してデバイスに直接アドレス指定されたトラフィックにフィルタリングメカニズムを適用することが可能でなければなりません。
Justification.
正当化。
This allows the operator to apply filters that protect the device itself from attacks and unauthorized access.
これにより、オペレータは、攻撃や不正アクセスからデバイス自体を保護するフィルタを適用することができます。
Examples.
例。
Examples of this might include filters that permit only BGP from peers and SNMP and SSH from an authorized management segment and directed to the device itself, while dropping all other traffic addressed to the device.
この例は、他のすべてのトラフィックがデバイスに宛て滴下しながら、認可管理セグメントから仲間とSNMPおよびSSHからのみBGPを許可し、デバイス自体に向けフィルタが含まれる場合があります。
Warnings.
警告。
None.
無し。
Requirement.
要求。
It MUST be possible to apply the filtering mechanism to traffic that is being routed (switched) through the device.
デバイスを介してルーティング（交換）されているトラフィックにフィルタリングメカニズムを適用することが可能でなければなりません。
Justification.
正当化。
This permits implementation of basic policies on devices that carry transit traffic (routers, switches, etc.).
これはトランジットトラフィック（ルータ、スイッチなど）を運ぶデバイス上の基本的な政策の実施が可能となります。
Examples.
例。
One simple and common way to meet this requirement is to provide the ability to filter traffic inbound to each interface and/or outbound from each interface. Ingress filtering as described in [RFC2827] provides one example of the use of this capability.
この要件を満たすための一つの簡単かつ一般的な方法は、各インターフェイスから各インターフェイスおよび/またはアウトバウンドのトラフィックの着信をフィルタリングする機能を提供することです。 [RFC2827]に記載されているようにイングレスフィルタリングは、この機能の使用の一例を提供します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means to filter packets without significant performance degradation. This specifically applies to stateless packet filtering operating on layer 3 (IP) and layer 4 (TCP or UDP) headers, as well as normal packet forwarding information such as incoming and outgoing interfaces.
デバイスは、パフォーマンスが大幅に低下することなく、パケットをフィルタリングするための手段を提供しなければなりません。これは、具体的にはレイヤ3（IP）およびレイヤ4（TCPまたはUDP）ヘッダ上で動作するステートレスパケットフィルタリング、ならびにそのような着信および発信インターフェイスなどの通常のパケット転送情報に適用されます。
The device MUST be able to apply stateless packet filters on ALL interfaces (up to the maximum number possible) simultaneously and with multiple filters per interface (e.g., inbound and outbound).
デバイスは、同時に（可能な最大数まで）と（例えば、インバウンド及びアウトバウンド）インタフェースごとに複数のフィルタがすべてのインターフェイスでステートレスパケットフィルタを適用することができなければなりません。
Justification.
正当化。
This enables the implementation of filtering wherever and whenever needed. To the extent that filtering causes degradation, it may not be possible to apply filters that implement the appropriate policies.
これは、いつでもどこでも必要なフィルタリングの実装を可能にします。フィルタリングは劣化を引き起こすことを限り、適切な政策を実施し、フィルタを適用することが可能ではないかもしれません。
Examples.
例。
Another way of stating the requirement is that filter performance should not be the limiting factor in device throughput. If a device is capable of forwarding 30Mb/sec without filtering, then it should be able to forward the same amount with filtering in place.
要件を述べる別の方法は、フィルタ性能は、デバイスのスループットを制限する要因であってはならないということです。デバイスは、フィルタリングなしで30MB /秒を転送することが可能である場合、代わりに、フィルタリングと同じ量を転送することができなければなりません。
Warnings.
警告。
The definition of "significant" is subjective. At one end of the spectrum it might mean "the application of filters may cause the box to crash". At the other end would be a throughput loss of less than one percent with tens of thousands of filters applied. The level of performance degradation that is acceptable will have to be determined by the operator.
「重要」の定義は主観的なものです。スペクトルの一方の端には、それは「フィルタの適用は、箱がクラッシュする可能性があります」という意味かもしれません。もう一方の端で適用されるフィルタの数万と1％未満のスループット損失になります。許容できる性能劣化のレベルは、オペレータによって決定されなければなりません。
Repeatable test data showing filter performance impact would be very useful in evaluating conformance with this requirement. Tests should include such information as packet size, packet rate, number of interfaces tested (source/destination), types of interfaces, routing table size, routing protocols in use, frequency of routing updates, etc. See [bmwg-acc-bench].
フィルタ性能への影響を示す反復試験データは、この要件への適合を評価するのに非常に有用であろう。試験は、等、パケットサイズ、パケットレート、（ソース/宛先）試験インタフェースの数、インターフェイスのタイプ、ルーティングテーブルのサイズ、使用中のルーティングプロトコル、ルーティングアップデートの頻度、などの情報を含むべきで見る[bmwg-ACC-ベンチ] 。
This requirement does not address stateful filtering, filtering above layer 4 headers or other more advanced types of filtering that may be important in certain operational environments.
この要件は、層の上方に特定の動作環境において重要であり得る4つのヘッダまたはフィルタリングの他のより高度なタイプのフィルタリング、ステートフルフィルタに対処していません。
Requirement.
要求。
The device MUST provide a means to filter routing updates for all protocols used to exchange external routing information.
デバイスは、外部のルーティング情報を交換するために使用されるすべてのプロトコルのためのルーティングアップデートをフィルタリングする手段を提供しなければなりません。
Justification.
正当化。
See [RFC3013] and section 3.2 of [RFC2196].
[RFC3013]と[RFC2196]のセクション3.2を参照してください。
Examples.
例。
Operators may wish to ignore advertisements for routes to addresses allocated for private internets. See eBGP.
オペレータはプライベートなインターネットのために割り当てられたアドレスへのルートの広告を無視することもできます。 eBGPを参照してください。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a mechanism to allow the specification of the action to be taken when a filter rule matches. Actions MUST include "permit" (allow the traffic), "reject" (drop with appropriate notification to sender), and "drop" (drop with no notification to sender). Also see Section 2.7.7 and Section 2.9
デバイスは、フィルタルールが一致したときのアクションの指定をとることを可能にするメカニズムを提供しなければなりません。アクション（トラフィックを許可）「許可」を含まなければならない、「拒絶」（送信者に適切な通知をドロップする）、及び（送信者に通知なしでドロップ）「ドロップ」。また、セクション2.7.7と2.9節をご覧ください
Justification.
正当化。
This capability is essential to the use of filters to enforce policy.
この機能は、ポリシーを適用するフィルタを使用するために不可欠です。
Examples.
例。
Assume that you have a small DMZ network connected to the Internet. You want to allow management using SSH coming from your corporate office. In this case, you might "permit" all traffic to port 22 in the DMZ from your corporate network, "rejecting" all others. Port 22 traffic from the corporate network is allowed through. Port 22 traffic from all other addresses results in an ICMP message to the sender. For those who are slightly more paranoid, you might choose to "drop" instead of "reject" traffic from unauthorized addresses, with the result being that *nothing* is sent back to the source.
あなたがインターネットに接続されている小規模なDMZネットワークを持っていることを前提としています。あなたの企業のオフィスからのSSHを使用して管理できるようにしたいです。このケースでは、他のすべてを「拒否」「許可」企業ネットワークからDMZ内のポート22へのすべてのトラフィック、かもしれません。企業ネットワークからポート22のトラフィックが通過を許可されます。送信者にICMPメッセージ内の他のすべてのアドレスの結果から、ポート22トラフィック。やや偏執ある人のために、あなたの代わりに、結果は*何も*が送信元に送信されていないことであることで、不正なアドレスからのトラフィックを「拒否」の「ドロップ」することを選択するかもしれません。
Warnings.
警告。
While silently dropping traffic without sending notification may be the correct action in security terms, consideration should be given to operational implications. See [RFC3360] for consideration of potential problems caused by sending inappropriate TCP Resets.
静かに通知を送信せずにトラフィックをドロップすることは、セキュリティの面で正しい行動かもしれないが、考慮すべき点は、動作の影響を考慮すべきです。不適切なTCPリセットを送信することにより引き起こされる潜在的な問題の検討のための[RFC3360]を参照してください。
Requirement.
要求。
It MUST be possible to log all filter actions. The logging capability MUST be able to capture at least the following data:
すべてのフィルタアクションをログに記録することも可能でなければなりません。ログ機能は、少なくとも以下のデータを取り込むことができなければなりません。
* permit/deny/drop status,
*許可/拒否/ドロップ状態、
* source and destination IP address,
*送信元と宛先のIPアドレス、
* source and destination ports (if applicable to the protocol),
*送信元ポートと宛先ポート（プロトコルに該当する場合）、
* which network element received the packet (interface, MAC address or other layer 2 information that identifies the previous hop source of the packet).
*どのネットワーク要素（パケットの前のホップ・ソースを識別するインターフェイス、MACアドレスまたは他のレイヤ2情報）パケットを受信しました。
Logging of filter actions is subject to the requirements of Section 2.11.
フィルタアクションのロギングは2.11の要件の対象です。
Justification.
正当化。
Logging is essential for auditing, incident response, and operations. Examples.
ログは、監査、インシデント対応、および操作のために必須です。例。
A desktop network may not provide any services that should be accessible from "outside." In such cases, all inbound connection attempts should be logged as possible intrusion attempts.
デスクトップのネットワークはからアクセスする必要があります任意のサービス提供することはできません「の外に。」このような場合には、すべての着信接続の試みは、可能な侵入の試みとしてログインする必要があります。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means to filter traffic based on the value of the protocol field in the IP header.
デバイスは、IPヘッダのプロトコルフィールドの値に基づいてトラフィックをフィルタリングするための手段を提供しなければなりません。
Justification.
正当化。
Being able to filter on protocol is necessary to allow implementation of policy, secure operations and for support of incident response.
プロトコルでフィルタリングすることができるということは、ポリシーの実施、安全な操作とインシデント対応の支援のためのを可能にするために必要です。
Examples.
例。
Some denial of service attacks are based on the ability to flood the victim with ICMP traffic. One quick way (admittedly with some negative side effects) to mitigate the effects of such attacks is to drop all ICMP traffic headed toward the victim.
サービス攻撃のいくつかの拒否は、ICMPトラフィックを犠牲者にあふれるする能力に基づいています。このような攻撃の影響を緩和するために（確かにいくつかのマイナスの副作用を持つ）一つの簡単な方法は、被害者の方へ向かったすべてのICMPトラフィックをドロップすることです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The function MUST be able to control the flow of traffic based on source and/or destination IP address or blocks of addresses such as Classless Inter-Domain Routing (CIDR) blocks.
機能はソースおよび/または宛先IPアドレス、またはそのようなクラスレスドメイン間ルーティング（CIDR）ブロックとしてアドレスのブロックに基づいてトラフィックの流れを制御することができなければなりません。
Justification.
正当化。
The capability to filter on addresses and address blocks is a fundamental tool for establishing boundaries between different networks.
アドレスとアドレスブロックにフィルタする機能は、異なるネットワーク間の境界を確立するための基本的なツールです。
Examples.
例。
One example of the use of address based filtering is to implement ingress filtering per [RFC2827].
アドレスベースのフィルタリングの使用の一例は、[RFC2827]あたりのイングレスフィルタリングを実施することです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The filtering mechanism MUST support filtering based on the value(s) of any portion of the protocol headers for IP, ICMP, UDP and TCP. It SHOULD support filtering of all other protocols supported at layer 3 and 4. It MAY support filtering based on the headers of higher level protocols. It SHOULD be possible to specify fields by name (e.g., "protocol = ICMP") rather than bit-offset/length/numeric value (e.g., 72:8 = 1).
フィルタリング機構は、IP、ICMP、UDPおよびTCPのプロトコルヘッダの任意の部分の値（複数可）に基づいて、フィルタリングをサポートしなければなりません。それは、より高いレベルのプロトコルのヘッダーに基づいてフィルタリングをサポートする可能性のあるすべての他の層3でサポートされるプロトコルおよび4のフィルタリングをサポートしなければなりません。それは名前によってフィールドを指定することが可能であるべきである（例えば、「プロトコル= ICMP」）というビットオフセット/長さ/数値以上（例えば、72：8 = 1）。
Justification.
正当化。
Being able to filter on portions of the header is necessary to allow implementation of policy, secure operations, and support incident response.
ヘッダの部分にフィルタリングすることができるということは、ポリシー、安全な操作の実施を可能にし、インシデント対応をサポートする必要があります。
Examples.
例。
This requirement implies that it is possible to filter based on TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and ICMP type and code fields. One common example is to reject "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit set+ACK,FIN and RST bits clear). Another common example is the ability to control what services are allowed in/out of a network. It may be desirable to only allow inbound connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting web servers.
この要件は、TCPまたはUDPポート番号、例えばSYN、ACKとRSTビットとしてTCPフラグ、およびICMPタイプとコードフィールドに基づいてフィルタリングすることが可能であることを意味します。一つの一般的な例は、「インバウンド」TCP接続試行拒否することである（TCPは、SYN + ACKは、FINおよびクリアRSTビットを設定ビットACKビットをクリアまたはSYN +設定ビット）。他の一般的な例としては、サービス中/ネットワークのうち許可されるかを制御する機能です。それだけでWebサーバをホスティングしているネットワークへのインバウンドポート80（HTTP）の接続および443（HTTPS）を許可することが望ましいかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
It MUST be possible to filter both incoming and outgoing traffic on any interface.
任意のインターフェイス上の着信と発信の両方のトラフィックをフィルタリングすることも可能でなければなりません。
Justification.
正当化。
This requirement allows flexibility in applying filters at the place that makes the most sense. It allows invalid or malicious traffic to be dropped as close to the source as possible.
この要件は、最も理にかなっている場所でフィルタを適用する際の柔軟性を可能にします。これは、無効または悪意のあるトラフィックを可能な限りソースの近くに落下することができます。
Examples.
例。
It might be desirable on a border router, for example, to apply an egress filter outbound on the interface that connects a site to its external ISP to drop outbound traffic that does not have a valid internal source address. Inbound, it might be desirable to apply a filter that blocks all traffic from a site that is known to forward or originate lots of junk mail.
これは、有効な内部送信元アドレスを持っていないアウトバウンドトラフィックをドロップするようにその外部のISPにサイトを接続するインターフェイス上の出力フィルタの発信を適用するには、例えば、境界ルータ上で望ましいかもしれません。インバウンドは、ジャンクメールの多くを転送したり、発信することが知られているサイトからのブロックのすべてのトラフィックフィルタを適用することが望ましいかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST supply a facility for accurately counting all filter hits.
デバイスは正確にすべてのフィルタヒットを数えるための機能を提供しなければなりません。
Justification.
正当化。
Accurate counting of filter rule matches is important because it shows the frequency of attempts to violate policy. This enables resources to be focused on areas of greatest need.
それがポリシーに違反しようとする試みの周波数を示しているため、フィルタルールの試合の正確なカウントが重要です。これは、リソースが最も必要の分野に焦点を当てたことができます。
Examples.
例。
Assume, for example, that a ISP network implements anti-spoofing egress filters (see [RFC2827]) on interfaces of its edge routers that support single-homed stub networks. Counters could enable the ISP to detect cases where large numbers of spoofed packets are being sent. This may indicate that the customer is performing potentially malicious actions (possibly in violation of the ISPs Acceptable Use Policy), or that system(s) on the customers network have been "owned" by hackers and are being (mis)used to launch attacks.
シングルホームスタブネットワークをサポートし、そのエッジルータのインターフェイス上（[RFC2827]を参照）ISPネットワークがスプーフィング防止出口フィルタを実装することは、例えば、想定。カウンタは、スプーフィングされたパケットの多数が送信されている場合を検出するためにISPを可能にすることができます。これは、ハッカーによって「所有」されていると（誤って）攻撃を開始するために使用されている顧客のネットワーク上で顧客が（おそらくのISPの違反利用規定内）潜在的な不正行為を行っていることを示している、またはそのシステム（複数可）があり。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a mechanism to display filter counters.
デバイスは、フィルタカウンタを表示する機構を提供しなければなりません。
Justification.
正当化。
Information that is collected is not useful unless it can be displayed in a useful manner.
それは便利な方法で表示することができない限り、収集された情報は有用ではありません。
Examples.
例。
Assume there is a router with four interfaces. One is an up-link to an ISP providing routes to the Internet. The other three connect to separate internal networks. Assume that a host on one of the internal networks has been compromised by a hacker and is sending traffic with bogus source addresses. In such a situation, it might be desirable to apply ingress filters to each of the internal interfaces. Once the filters are in place, the counters can be examined to determine the source (inbound interface) of the bogus packets.
4つのインタフェースを持つルータがあると仮定します。一つは、インターネットへのルートを提供するISPへのアップリンクです。他の3つは内部ネットワークを分離するために接続します。内部ネットワークの一つ上のホストがハッカーによって侵害されたと偽の送信元アドレスを持つトラフィックを送信していることを前提としています。そのような状況では、内部インターフェースのそれぞれに入口フィルタを適用することが望ましいかもしれません。フィルタが所定の位置にあるならば、カウンタは偽のパケットの送信元（着信インターフェイス）を決定するために調べることができます。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a mechanism to display filter counters per rule.
デバイスは、ルールごとのフィルタカウンタを表示するためのメカニズムを提供しなければなりません。
Justification.
正当化。
This makes it possible to see which rules are matching and how frequently.
これは、ルールが一致し、どのように頻繁にされているかを確認することが可能となります。
Examples.
例。
Assume that a filter has been defined that has two rules, one permitting all SSH traffic (tcp/22) and the second dropping all remaining traffic. If three packets are directed toward/through the point at which the filter is applied, one to port 22, the others to different ports, then the counter display should show 1 packet matching the permit tcp/22 rule and 2 packets matching the deny all others rule.
フィルタは、一方が、残りのすべてのトラフィックすべてのSSHトラフィック（TCP / 22）と第二の滴下を可能にする、2つのルールを有するように定義されていると仮定する。 3つのパケットフィルタを1つのポート22に印加される点を通って/に向けられている場合は、異なるポートに他のものは、カウンタ表示が許可TCP / 22ルールに一致する1つのパケットを示すべきであり、2つのパケットはすべて拒否一致します他の人が支配します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
If it is possible for a filter to be applied more than once at the same time, then the device MUST provide a mechanism to display filter counters per filter application.
フィルタは、同時に複数回適用することが可能である場合、デバイスは、フィルタアプリケーションごとにフィルタカウンタを表示する機構を提供しなければなりません。
Justification.
正当化。
It may make sense to apply the same filter definition simultaneously more than one time (to different interfaces, etc.). If so, it would be much more useful to know which instance of a filter is matching than to know that some instance was matching somewhere.
これは、（異なるインターフェイス、等に）同時に回以上同じフィルタ定義を適用するために意味をなすことができます。もしそうなら、それはいくつかのインスタンスがどこかに一致していることを知っているよりも、マッチングされたフィルタのどのインスタンスを知るためにはるかに有用であろう。
Examples.
例。
One way to implement this requirement would be to have the counter display mechanism show the interface (or other entity) to which the filter has been applied, along with the name (or other designator) for the filter. For example if a filter named
この要件は、カウンタ表示機構を有することであろう実装する1つの方法は、フィルタは、フィルタの名前（または他の指示）とともに、印加されたインターフェース（または他のエンティティ）を示します。例えば、フィルタは、名前の場合
"desktop_outbound" applied two different interfaces, say, "ethernet0" and "ethernet1", the display should indicate something like "matches of filter 'desktop_outbound' on ethernet0 ..." and "matches of filter 'desktop_outbound' on ethernet1 ..."
「desktop_outbound」は、2つの異なるインタフェース、たとえば、「Ethernet0に」を適用し、「ethernet1を」、ディスプレイは「...はEthernet0上のフィルタのマッチ 『desktop_outbound』」のようなものを示す必要がありますし、ethernet1を上の「フィルタのマッチ 『desktop_outbound』 ... "
Warnings.
警告。
None.
無し。
Requirement.
要求。
It MUST be possible to reset counters to zero on a per filter basis.
フィルタごとに、カウンタをゼロにリセットすることは可能でなければなりません。
For the purposes of this requirement it would be acceptable for the system to maintain two counters: an "absolute counter", C[now], and a "reset" counter, C[reset]. The absolute counter would maintain counts that increase monotonically until they wrap or overflow the counter. The reset counter would receive a copy of the current value of the absolute counter when the reset function was issued for that counter. Functions that display or retrieve the counter could then display the delta (C[now] - C[reset]).
この要件の目的のためには、2つのカウンタを維持するためのシステムのために許容されるであろう：「絶対カウンター」、C [今]、及び「リセット」カウンタ、Cは、[リセット]。彼らはラップやカウンタをオーバーフローするまで絶対カウンタは単調に増加カウントを維持するであろう。リセット機能は、そのカウンターのために発行されたとき、リセットカウンタは絶対カウンタの現在値のコピーを受け取ることになります。表示またはカウンタを取得する機能は、デルタ（ - C [リセット] C [今]）を表示することができます。
Justification.
正当化。
This allows operators to get a current picture of the traffic matching particular rules/filters.
これは、事業者は、特定のルール/フィルタに一致するトラフィックの現在の画像を取得することができます。
Examples.
例。
Assume that filter counters are being used to detect internal hosts that are infected with a new worm. Once it is believed that all infected hosts have been cleaned up and the worm removed, the next step would be to verify that. One way of doing so would be to reset the filter counters to zero and see if traffic indicative of the worm has ceased.
フィルタカウンタが新しいワームに感染している内部ホストを検出するために使用されていることを前提としています。すべての感染したホストがクリーンアップされていると、ワームが削除されると考えられるならば、次のステップは、それを確認することです。そうすることの一つの方法は、ゼロにフィルタカウンタをリセットし、ワームを示すトラフィックが停止したかどうかを確認することです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
Filter counters MUST be accurate. They MUST reflect the actual number of matching packets since the last counter reset. Filter counters MUST be capable of holding up to 2^32 - 1 values without overflowing and SHOULD be capable of holding up to 2^64 - 1 values.
フィルタカウンタは正確でなければなりません。彼らは最後のカウンタリセット以降に一致するパケットの実際の数を反映しなければなりません。フィルタカウンタは2 ^ 32のまで保持することができなければなりません - オーバーフローせずに1の値および2 ^ 64のまで保持することができなければならない - 1値。
Justification.
正当化。
Inaccurate data can not be relied on as the basis for action. Underreported data can conceal the magnitude of a problem.
不正確なデータは、アクションのための基礎として依拠することはできません。過少報告のデータは、問題の大きさを隠すことができます。
Examples.
例。
If N packets matching a filter are sent to/through a device, then the counter should show N matches.
フィルタに一致するNパケットがデバイスを通って/に送信される場合、カウンタは、N個の一致を示すべきです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
It MUST be possible to enable/disable logging on a per rule basis.
有効/ルールごとにログを無効にすることは可能でなければなりません。
Justification.
正当化。
The ability to tune the granularity of logging allows the operator to log only the information that is desired. Without this capability, it is possible that extra data (or none at all) would be logged, making it more difficult to find relevant information.
調整する能力は、ログの粒度はオペレータが所望される情報のみを記録することを可能にします。この能力がなければ、余分なデータ（またはまったくなし）が、それはより困難の関連情報を検索すること、ログに記録されることも可能です。
Examples.
例。
If a filter is defined that has several rules, and one of the rules denies telnet (tcp/23) connections, then it should be possible to specify that only matches on the rule that denies telnet should generate a log message.
フィルタは、いくつかのルールがあり、その定義され、ルールのいずれかがTelnet（TCP / 23）の接続を拒否した場合、それだけにはTelnetがログメッセージを生成する必要が拒否ルールに一致するように指定することが可能であるべきです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a logging facility that is based on protocols subject to open review. See Section 1.8. Custom or proprietary logging protocols MAY be implemented provided the same information is made available.
デバイスは、審査を開く対象のプロトコルに基づいているロギング機能を提供しなければなりません。 1.8節を参照してください。カスタムまたは独自のロギング・プロトコルは、同じ情報が利用可能にされて実装されてもよいです。
Justification.
正当化。
The use of logging based on protocols subject to open review permits the operator to perform archival and analysis of logs without relying on vendor-supplied software and servers.
レビューを開き、対象プロトコルに基づく伐採の使用はベンダー提供のソフトウェアとサーバに依存せずにアーカイブし、ログの分析を実行するためにオペレータが可能になります。
Examples.
例。
This requirement may be satisfied by the use of one or more of syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ [RFC1492] or RADIUS [RFC2865].
この要件は、システムログのうちの1つまたは複数の使用[RFC3164]で信頼性の高い配信[RFC3195]、TACACS + [RFC1492]またはRADIUS [RFC2865]とのsyslogを満足することができます。
Warnings.
警告。
While [RFC3164] meets this requirement, it has many security issues and by itself does not meet the requirements of Section 2.1.1. See the security considerations section of [RFC3164] for a list of issues. [RFC3195] provides solutions to most/all of these issues....however at the time of this writing there are few implementations. Other possible solutions might be to tunnel syslog over a secure transport...but this often raises difficult key management and scalability issues.
[RFC3164]はこの要件を満たしているが、それは多くのセキュリティ上の問題があり、それ自体で、セクション2.1.1の要件を満たしていません。問題のリストについては、[RFC3164]のセキュリティの考慮事項のセクションを参照してください。 [RFC3195]はしかし、これを書いている時点で、いくつかの実装があります....これらの問題のほとんど/すべてのソリューションを提供しています。他の可能な解決策は、安全な輸送の上にトンネルsyslogにあるかもしれない...しかし、これはしばしば困難鍵の管理とスケーラビリティの問題を提起します。
The current best solution seems to be the following:
現在の最善の解決策は、以下のようです：
* Implement [RFC3164].
* [RFC3164]を実装します。
* Consider implementing [RFC3195].
* [RFC3195]を実装することを検討してください。
Requirement.
要求。
The device MUST support transmission of records of security related events to one or more remote devices. There MUST be configuration settings on the device that allow selection of servers.
デバイスは、1つのまたは複数のリモートデバイスへのセキュリティ関連イベントの記録の送信をサポートしなければなりません。サーバの選択を可能デバイス上のコンフィギュレーション設定があるに違いありません。
Justification.
正当化。
This is important because it supports individual accountability. It is important to store them on a separate server to preserve them in case of failure or compromise of the managed device.
それは個々の責任をサポートしているため、これは重要です。障害または管理対象デバイスの妥協のケースでそれらを保持するために別のサーバーに保管しておくことが重要です。
Examples.
例。
This requirement may be satisfied by the use of one or more of: syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ [RFC1492] or RADIUS [RFC2865].
この要件は、の一つ以上を使用することによって満たすことができる：シスログ[RFC3164]、信頼性の高い配信[RFC3195]でのsyslog、TACACS + [RFC1492]またはRADIUS [RFC2865]。
Warnings.
警告。
Note that there may be privacy or legal considerations when logging/monitoring user activity.
ユーザのアクティビティを監視/ログインする際にプライバシーや法的な考慮事項があるかもしれないことに注意してください。
High volumes of logging may generate excessive network traffic and/or compete for scarce memory and CPU resources on the device.
伐採の高いボリュームは、過剰なネットワークトラフィックを生成および/またはデバイス上で不足メモリやCPUリソースの競合があります。
Requirement.
要求。
It SHOULD be possible to select reliable delivery of log messages.
ログメッセージの信頼性の高い配信を選択することが可能です。
Justification.
正当化。
Reliable delivery is important to the extent that log data is depended upon to make operational decisions and forensic analysis. Without reliable delivery, log data becomes a collection of hints.
信頼性の高い配信は、データが運用の意思決定および法医学的分析を行うことに依存しているログ範囲に重要です。信頼性の高い配信がなければ、ログデータは、ヒントのコレクションになります。
Examples.
例。
One example of reliable syslog delivery is defined in [RFC3195]. Syslog-ng provides another example, although the protocol has not been standardized.
信頼シスログ送達の一例は、[RFC3195]で定義されています。プロトコルが標準化されていないけれどものsyslog-ngが、別の例を提供します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
It SHOULD be possible to log locally on the device itself. Local logging SHOULD be written to non-volatile storage.
デバイス自体にローカルにログオンすることが可能なはずです。ローカルログは、不揮発性ストレージに書き込む必要があります。
Justification.
正当化。
Local logging of failed authentication attempts to non-volatile storage is critical. It provides a means of detecting attacks where the device is isolated from its authentication interfaces and attacked at the console.
不揮発性ストレージに失敗した認証試行のローカルログが重要です。これは、デバイスがその認証インターフェースから単離され、コンソールで攻撃された攻撃を検出する手段を提供します。
Local logging is important for viewing information when connected to the device. It provides some backup of log data in case remote logging fails. It provides a way to view logs relevant to one device without having to sort through a possibly large set of logs from other devices.
ローカルログ記録は、デバイスに接続したときに情報を表示するために重要です。リモートロギングが失敗した場合には、ログデータのいくつかのバックアップを提供します。これは、他のデバイスからのログの可能性が大きいセットをソートすることなく、一つのデバイスに関連するログを表示する方法を提供します。
Examples.
例。
One example of local logging would be a memory buffer that receives copies of messages sent to the remote log server. Another example might be a local syslog server (assuming the device is capable of running syslog and has some local storage).
ローカルログ記録の一例は、リモートログサーバーに送信されたメッセージのコピーを受け取り、メモリバッファになります。別の例は、（デバイスを仮定すると、シスログを実行することが可能であり、いくつかのローカルストレージを有する）ローカルsyslogサーバかもしれません。
Warnings.
警告。
Storage on the device may be limited. High volumes of logging may quickly fill available storage, in which case there are two options: new logs overwrite old logs (possibly via the use of a circular memory buffer or log file rotation), or logging stops.
デバイス上のストレージが制限される場合があります。新しいログが（おそらく循環メモリバッファの使用を介して、またはファイルのローテーションをログ）古いログを上書きする、またはログ記録停止：伐採の高いボリュームはすぐに二つの選択肢があり、その場合には、使用可能なストレージを満たしてもよいです。
Requirement.
要求。
The device MUST maintain accurate, "high resolution" (see definition in Section 1.8) system time.
デバイスは、（セクション1.8で定義を参照）システム時刻を正確に、「高解像度」を維持しなければなりません。
Justification.
正当化。
Accurate time is important to the generation of reliable log data. Accurate time is also important to the correct operation of some authentication mechanisms.
正確な時間は、信頼性の高い、ログデータの生成に重要です。正確な時間はまた、いくつかの認証メカニズムの正しい操作に重要です。
Examples.
例。
This requirement may be satisfied by supporting Network Time Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct connection to an accurate time source.
この要件は、ネットワークタイムプロトコル（NTP）、簡易ネットワークタイムプロトコル（SNTP）、または正確な時間ソースへの直接接続を介してをサポートすることによって満たすことができます。
Warnings.
警告。
System clock chips are inaccurate to varying degrees. System time should not be relied upon unless it is regularly checked and synchronized with a known, accurate external time source (such as an NTP stratum-1 server). Also note that if network time synchronization is used, an attacker may be able to manipulate the clock unless cryptographic authentication is used.
システムクロックチップは、様々な程度に不正確です。システム時間は、それが定期的にチェックして（例えばNTPストラタム1サーバとして）既知の、正確な外部タイムソースと同期されない限り、依拠すべきではありません。また、ネットワークの時刻同期が使用されている場合、攻撃者が暗号認証が使用されていない限り、クロックを操作することができる可能性があることに注意。
Requirement.
要求。
All displays and logs of system time MUST include a timezone or offset from UTC.
すべてのディスプレイとシステム時間のログは、タイムゾーンまたはUTCからのオフセットを含まなければなりません。
Justification.
正当化。
Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible.
タイムゾーンのオフセットまたはUTCを知ることは、データや可能性、他のタイムゾーン内のデータとの連携の相関関係を作ります。
Examples.
例。
Bob is in Newfoundland, Canada which is UTC -3:30. Alice is somewhere in Indiana, USA. Some parts of Indiana switch to daylight savings time while others do not. A user on Bob's network attacks a user on Alice's network. Both are using logs with local timezones and no indication of UTC offset. Correlating these logs will be difficult and error prone. Including timezone, or better, UTC offset, eliminates these difficulties.
30：ボブはUTC -3であるニューファンドランド、カナダです。アリスはインディアナ州、米国のどこかにあります。他の人がいない間インディアナ州のいくつかの部分は夏時間に切り替えます。ボブのネットワーク上のユーザはアリスのネットワーク上のユーザーを攻撃します。どちらも、ローカルタイムゾーンとUTCオフセットの表示なしでログを使用しています。これらのログを相関させること起こしやすい難しいとエラーになります。タイムゾーンを含む、またはそれ以上、UTCオフセット、これらの困難を排除します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The default timezone for display and logging SHOULD be UTC. The device MAY support a mechanism to allow the operator to specify the display and logging of times in a timezone other than UTC.
ディスプレイおよびロギングのデフォルトのタイムゾーンはUTCであるべきです。デバイスは、オペレータがUTC以外のタイムゾーンで時間の表示とログを指定できるようにするメカニズムをサポートするかもしれません。
Justification.
正当化。
Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible.
タイムゾーンのオフセットまたはUTCを知ることは、データや可能性、他のタイムゾーン内のデータとの連携の相関関係を作ります。
Examples.
例。
Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or UTC -6 depending on the time of year and exact county in Indiana) are working an incident together using their logs. Both left the default settings, which was UTC, so there was no translation of time necessary to correlate the logs.
ニューファンドランドにボブ（UTC -3：30）およびインディアナアリス（UTC -5 UTC -6インディアナ年正確な郡の時間に依存する）は、それらのログを使用して一緒に入射する作業しています。どちらも、UTCたデフォルト設定を、左、そのログを相関させるのに必要な時間のない翻訳はありませんでした。
Warnings.
警告。
None.
無し。
Requirement.
要求。
By default, the device MUST timestamp all log messages. The timestamp MUST be accurate to within a second or less. The timestamp MUST include a timezone. There MAY be a mechanism to disable the generation of timestamps.
デフォルトでは、デバイスは、すべてのログメッセージにタイムスタンプをしなければなりません。タイムスタンプは秒以内に正確でなければなりません。タイムスタンプは、タイムゾーンを含まなければなりません。タイムスタンプの生成を無効にするためのメカニズムがあるかもしれません。
Justification.
正当化。
Accurate timestamps are necessary for correlating events, particularly across multiple devices or with other organizations. This applies when it is necessary to analyze logs.
正確なタイムスタンプは、特に複数のデバイス間や他の組織と、イベントを相関するために必要です。ログを分析する必要がある場合に適用されます。
Examples.
例。
This requirement MAY be satisfied by writing timestamps into syslog messages.
この要件は、syslogメッセージにタイムスタンプを書き込むことによって満たすことができます。
Warnings.
警告。
It is difficult to correlate logs from different time zones. Security events on the Internet often involve machines and logs from a variety of physical locations. For that reason, UTC is preferred, all other things being equal.
異なるタイムゾーンからログを相関させることは難しいです。インターネット上のセキュリティイベントは、多くの場合、物理的な場所の様々な機械やログを伴います。そのため、UTCは、他のすべてのものが等しい、好ましいです。
Requirement.
要求。
Log messages MUST NOT list translated addresses (DNS names) associated with the address without listing the untranslated IP address where the IP address is available to the device generating the log message.
メッセージはIPアドレスがログメッセージを生成するデバイスに利用可能である非翻訳IPアドレスをリストすることなく、アドレスに関連付けられている翻訳されたアドレス（DNS名）をリストてはなりませんログインしてください。
Justification.
正当化。
Including IP address of access list violations authentication attempts, address lease assignments and similar events in logs enables a level of individual and organizational accountability and is necessary to enable analysis of network events, incidents, policy violations, etc.
アクセスリスト違反の認証試行、アドレスのリース割り当てとログに同様のイベントの含むIPアドレスは、個人と組織の責任のレベルを可能にし、ネットワークイベント、インシデント、ポリシー違反などの分析を有効にする必要があります
DNS entries tend to change more quickly than IP block assignments. This makes the address more reliable for data forensics.
DNSエントリは、IPブロックの割り当てよりも迅速に変更する傾向があります。これは、データフォレンジックのためのアドレスは、より信頼性の高いことができます。
DNS lookups can be slow and consume resources.
DNSルックアップが遅くなるとリソースを消費することができます。
Examples.
例。
A failed network login should generate a record with the source address of the login attempt.
失敗したネットワークログインは、ログイン試行の送信元アドレスを持つレコードを生成する必要があります。
Warnings.
警告。
* Source addresses may be spoofed. Network-based attacks often use spoofed source addresses. Source addresses should not be completely trusted unless verified by other means.
*ソースアドレスが偽装されていてもよいです。ネットワークベースの攻撃は、多くの場合、偽装された送信元アドレスを使用しています。他の手段によって検証されない限り、送信元アドレスは、完全に信頼されるべきではありません。
* Addresses may be reassigned to different individual, for example, in a desktop environment using DHCP. In such cases the individual accountability afforded by this requirement is weak. Having accurate time in the logs increases the chances that the use of an address can be correlated to an individual.
*アドレスはDHCPを使用してデスクトップ環境で、例えば、異なる個別に再割り当てすることができます。このような場合には、この要件によって与えられる個々の責任が弱いです。ログの正確な時間を有するアドレスの使用は、個々に相関させることができる可能性を増加させます。
* Network topologies may change. Even in the absence of dynamic address assignment, network topologies and address block assignments do change. Logs of an attack one month ago may not give an accurate indication of which host, network or organization owned the system(s) in question at the time.
*ネットワークトポロジが変更されることがあります。でも、動的なアドレス割り当てが存在しない場合に、ネットワークトポロジとアドレスブロックの割り当ては変更を行います。 1ヶ月前の攻撃のログは、ホスト、ネットワークや組織が一度に問題のシステム（複数可）を所有しているの正確な表示を得られない場合があります。
Requirement.
要求。
The device MUST be able to send a record of at least the following events:
デバイスは、少なくとも次のイベントの記録を送ることができなければなりません。
* authentication successes,
*認証成功、
* authentication failures,
*認証の失敗、
* session Termination,
*セッションの終了、
* authorization changes,
*許可の変更、
* configuration changes,
*構成の変更、
* device status changes.
*デバイスのステータスが変化します。
The device SHOULD be able to send a record of all other security related events.
デバイスは、他のすべてのセキュリティ関連イベントの記録を送信できるようにすべきです。
Justification.
正当化。
This is important because it supports individual accountability. See section 4.5.4.4 of [RFC2196].
それは個々の責任をサポートしているため、これは重要です。 [RFC2196]のセクション4.5.4.4を参照してください。
Examples.
例。
Examples of events for which there must be a record include: user logins, bad login attempts, logouts, user privilege level changes, individual configuration commands issued by users and system startup/shutdown events.
記録がなければならないするイベントの例としては、ユーザのログイン、不正なログイン試行、ログアウト、ユーザーの特権レベルの変更、ユーザーとシステムの起動/シャットダウン・イベントによって発行された個々の構成コマンドを。
Warnings.
警告。
This list is far from complete.
このリストは完全にはほど遠いです。
Note that there may be privacy or legal considerations when logging/monitoring user activity.
ユーザのアクティビティを監視/ログインする際にプライバシーや法的な考慮事項があるかもしれないことに注意してください。
Requirement.
要求。
Passwords SHOULD be excluded from all audit records, including records of successful or failed authentication attempts.
パスワードは、成功または失敗した認証試行の記録を含む、すべての監査レコードから除外すべきです。
Justification.
正当化。
Access control and authorization requirements differ for accounting records (logs) and authorization databases (passwords). Logging passwords may grant unauthorized access to individuals with access to the logs. Logging failed passwords may give hints about actual passwords. See section 4.5.4.4 of [RFC2196].
アクセス制御と承認の要件は、会計記録（ログ）と承認データベース（パスワード）のために異なります。ログインパスワードは、ログへのアクセスを持つ個人への不正アクセスを許可することができます。ロギングはパスワードが実際のパスワードについてのヒントを与えることができませんでした。 [RFC2196]のセクション4.5.4.4を参照してください。
Examples.
例。
A user may make small mistakes in entering a password such as using incorrect capitalization ("my password" vs. "My Password").
ユーザーは、このような間違った総額（「マイパスワード」対「パスワード」）を使用してパスワードを入力することで小さなミスをすることができます。
Warnings.
警告。
There may be situations where it is appropriate/required to log passwords.
パスワードを記録するために必要な/適切である状況があるかもしれません。
Requirement.
要求。
The device MUST provide a facility to perform authentication of all user access to the system.
デバイスは、システムへのすべてのユーザアクセスの認証を実行する機能を提供しなければなりません。
Justification.
正当化。
This functionality is required so that access to the system can be restricted to authorized personnel.
システムへのアクセスが許可された担当者に制限することができるように、この機能が必要です。
Examples.
例。
This requirement MAY be satisfied by implementing a centralized authentication system. See Section 2.12.5. It MAY also be satisfied using local authentication. See Section 2.12.6.
この要件は、集中認証システムを実装することによって満たすことができます。セクション2.12.5を参照してください。また、ローカル認証を使用して満たすことができます。セクション2.12.6を参照してください。
Warnings.
警告。
None.
無し。
Requirement.
要求。
Mechanisms used to authenticate interactive access for configuration and management MUST support the authentication of distinct, individual users. This requirement MAY be relaxed to support system installation Section 2.4.5 or recovery of authorized access Section 2.12.15.
設定と管理のためのインタラクティブなアクセスを認証するために使用されるメカニズムは明確な、個々のユーザの認証をサポートしなければなりません。この要件は、システムのインストール2.4.5または認可されたアクセスセクション2.12.15の回復をサポートするために緩和されます。
Justification.
正当化。
The use of individual accounts, in conjunction with logging, promotes accountability. The use of group or default accounts undermines individual accountability.
個々のアカウントの使用は、ログ機能と連動して、説明責任を促進します。グループまたはデフォルトのアカウントを使用すると、個々の責任を損ないます。
Examples.
例。
A user may need to log in to the device to access CLI functions for management. Individual user authentication could be provided by a centralized authentication server or a username/password database stored on the device. It would be a violation of this rule for the device to only support a single "account" (with or without a username) and a single password shared by all users to gain administrative access.
ユーザーは、管理用のCLI機能にアクセスするには、デバイスにログインする必要があります。個々のユーザ認証は、集中認証サーバまたはデバイスに保存されたユーザ名/パスワードデータベースによって提供することができます。それだけで（ユーザー名の有無にかかわらず）、単一の「アカウント」と行政のアクセスを得るために、すべてのユーザーが共有する単一のパスワードをサポートするデバイスのためにこのルールの違反となります。
Warnings.
警告。
This simply requires that the mechanism to support individual users be present. Policy (e.g., forbidding shared group accounts) and enforcement are also needed but beyond the scope of this document.
これは、単にメカニズムは、個々のユーザーが存在することをサポートすることが必要です。ポリシー（例えば、共有グループアカウントを禁止）と執行もなく、この文書の範囲を超えて必要とされています。
Requirement.
要求。
The device MUST support multiple simultaneous connections by distinct users, possibly at different authorization levels.
デバイスは、おそらく異なる権限レベルで、異なるユーザーによる複数同時接続をサポートしなければなりません。
Justification.
正当化。
This allows multiple people to perform authorized management functions simultaneously. This also means that attempted connections by unauthorized users do not automatically lock out authorized users.
これは、複数の人が同時に許可された管理機能を実行することができます。また、これは、不正ユーザーによる接続試行が自動的に許可されたユーザをロックアウトしていないことを意味します。
Examples.
例。
None.
無し。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST provide a means of disabling all local accounts including:
デバイスは、以下を含むすべてのローカルアカウントを無効にする手段を提供する必要があります。
* local users,
*ローカルユーザー、
* default accounts (vendor, maintenance, guest, etc.),
*デフォルト・アカウント（ベンダー、メンテナンス、ゲストなど）、
* privileged and unprivileged accounts.
*特権と非特権アカウント。
A local account defined as one where all information necessary for user authentication is stored on the device.
ローカルアカウントは、ユーザ認証に必要なすべての情報がデバイスに保存されているものとして定義されます。
Justification.
正当化。
Default accounts, well-known accounts, and old accounts provide easy targets for someone attempting to gain access to a device. It must be possible to disable them to reduce the potential vulnerability.
デフォルトのアカウントは、よく知られたアカウント、および古いアカウントは、デバイスにアクセスしようとする誰かのための簡単な標的を提供します。潜在的な脆弱性を軽減するためにそれらを無効にすることが可能でなければなりません。
Examples.
例。
The implementation depends on the types of authentication supported by the device.
実装は、デバイスによってサポートされる認証の種類に依存します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST support a method of centralized authentication of all user access via standard authentication protocols.
デバイスは、標準の認証プロトコルを介してすべてのユーザアクセスの集中認証方法をサポートしなければなりません。
Justification.
正当化。
Support for centralized authentication is particularly important in large environments where the network devices are widely distributed and where many people have access to them. This reduces the effort needed to effectively restrict and track access to the system by authorized personnel.
集中認証のサポートは、ネットワークデバイスが広く分布し、多くの人々がそれらへのアクセスを持っている大規模な環境では特に重要です。これは、事実関係者によってシステムへのアクセスを制限し、追跡するために必要な労力を削減します。
Examples.
例。
This requirement can be satisfied through the use of DIAMETER [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos [RFC1510].
この要求は、Diameter [RFC3588]、TACACS + [RFC1492]、RADIUS [RFC2865]、又はケルベロス[RFC1510]を使用することによって満たすことができます。
The secure management requirements (Section 2.1.1) apply to AAA.
セキュアな管理要件（セクション2.1.1）はAAAに適用されます。
See [RFC3579] for a discussion security issues related to RADIUS.
RADIUSに関連した議論のセキュリティ問題のために[RFC3579]を参照してください。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device SHOULD support a local authentication method. If implemented, the method MUST NOT require interaction with anything external to the device (such as remote AAA servers), and MUST work in conjunction with Section 2.3.1 (Support a 'Console' Interface) and Section 2.12.7 (Support Configuration of Order of Authentication Methods).
デバイスは、ローカル認証方式をサポートする必要があります。実装されていれば、この方法は、（例えば、リモートAAAサーバなどの）デバイス外部のものとの対話を要求してはなりませんし、2.3.1項（「コンソール」インターフェースをサポートしています）、セクション2.12.7（のサポート設定と連動して動作しなければなりません。認証方法の順）。
Justification.
正当化。
Support for local authentication may be required in smaller environments where there may be only a few devices and a limited number of people with access. The overhead of maintaining centralized authentication servers may not be justified.
ローカル認証のサポートは、わずか数のデバイスとアクセス権を持つ人々の限られた数があるかもしれない小規模な環境で必要とすることができます。集中型の認証サーバを維持するためのオーバーヘッドは正当化されない場合があります。
Examples.
例。
The use of local, per-device usernames and passwords provides one way to implement this requirement.
地元、デバイスごとのユーザ名とパスワードを使用することは、この要件を実装する1つの方法を提供します。
Warnings.
警告。
Authentication information must be protected wherever it resides. Having, for instance, local usernames and passwords stored on 100 network devices means that there are 100 potential points of failure where the information could be compromised vs. storing authentication data centralized server(s), which would reduce the potential points of failure to the number of servers and allow protection efforts (system hardening, audits, etc.) to be focused on, at most, a few servers.
それが存在どこ認証情報は保護されなければなりません。例えば、有する、100のネットワーク装置上に格納されたローカルユーザ名とパスワード情報が格納認証データ集中型サーバ（複数可）対危険にさらされる可能性が不良の100個の電位点がに故障の可能性のある点を低下させるであろう、があることを意味しますサーバーの数と許可保護の取り組み（システムの強化、監査など）は、最大で、上のいくつかのサーバーを集中します。
Requirement.
要求。
The device MUST support the ability to configure the order in which supported authentication methods are attempted. Authentication SHOULD "fail closed", i.e., access should be denied if none of the listed authentication methods succeeds.
デバイスは、認証方式が試行されているサポートされる順番を設定する機能をサポートしなければなりません。認証は、リストされている認証方法のいずれも成功しない場合、すなわち、アクセスが拒否されなければならない、「フェールクローズ」すべきです。
Justification.
正当化。
This allows the operator flexibility in implementing appropriate security policies that balance operational and security needs.
これは、運用とセキュリティのニーズのバランスをとる適切なセキュリティ・ポリシーを実装する際のオペレータの柔軟性を可能にします。
Examples.
例。
If, for example, a device supports RADIUS authentication and local usernames and passwords, it should be possible to specify that RADIUS authentication should be attempted if the servers are available, and that local usernames and passwords should be used for authentication only if the RADIUS servers are not available. Similarly, it should be possible to specify that only RADIUS or only local authentication be used.
例えば、デバイスがRADIUS認証とローカルのユーザ名とパスワードをサポートしている場合、サーバが利用可能な場合にRADIUS認証を試みるべきで指定することは可能であるべきであり、そのローカルユーザ名とパスワードを認証に使用する必要がある場合にのみ、RADIUSサーバ利用できません。同様に、それだけRADIUSまたは唯一のローカル認証を使用するように指定することが可能であるべきです。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST support mechanisms that do not require the transmission of plaintext passwords in all cases that require the transmission of authentication information across networks.
デバイスは、ネットワークを介した認証情報の伝送を必要とするすべてのケースでは平文パスワードの送信を必要としないメカニズムをサポートしなければなりません。
Justification.
正当化。
Plaintext passwords can be easily observed using packet sniffers on shared networks. See [RFC1704] and [RFC3631] for a through discussion.
平文パスワードは簡単に共有ネットワーク上のパケットスニファを使用して観察することができます。議論のための[RFC1704]と[RFC3631]を参照してください。
Examples.
例。
Remote login requires the transmission of authentication information across networks. Telnet transmits plaintext passwords. SSH does not. Telnet fails this requirement. SSH passes.
リモートログインはネットワーク全体での認証情報の送信を要求します。 Telnetは、平文パスワードを送信します。 SSHはしていません。 Telnetは、この要件を失敗しました。 SSHを渡します。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The initial configuration of the device MUST NOT contain any default passwords or other authentication tokens.
デバイスの初期設定は、デフォルトのパスワードやその他の認証トークンを含めることはできません。
Justification.
正当化。
Default passwords provide an easy way for attackers to gain unauthorized access to the device.
デフォルトのパスワードは、攻撃者が、デバイスへの不正アクセスを獲得するための簡単な方法を提供します。
Examples.
例。
Passwords such as the name of the vendor, device, "default", etc. are easily guessed. The SNMP community strings "public" and "private" are well known defaults that provide read and write access to devices.
こうしたベンダー、デバイス、「デフォルト」などの名前とパスワードは容易に推測されています。 「パブリック」と「プライベート」SNMPコミュニティストリングを読んで、デバイスへの書き込みアクセスを提供よく知らデフォルトです。
Warnings.
警告。
Lists of default passwords for various devices are readily available at numerous websites.
様々なデバイスのためのデフォルトのパスワードのリストは、多くのウェブサイトで容易に入手可能です。
Requirement.
要求。
The device MUST require the operator to explicitly configure "passwords" prior to use.
デバイスは、明示的に使用する前に「パスワード」を設定するには、オペレータが必要としなければなりません。
Justification.
正当化。
This requirement is intended to prevent unauthorized management access. Requiring the operator to explicitly configure passwords will tend to have the effect of ensuring a diversity of passwords. It also shifts the responsibility for password selection to the user.
この要件は、不正な管理アクセスを防止することを目的とします。明示的にパスワードを設定するには、オペレータを要求することは、パスワードの多様性を確保する効果を持っている傾向があります。また、ユーザーにパスワードの選択のための責任をシフトします。
Examples.
例。
Assume that a device comes with console port for management and a default administrative account. This requirement together with No Default Passwords says that the administrative account should come with no password configured. One way of meeting this requirement would be to have the device require the operator to choose a password for the administrative account as part of a dialog the first time the device is configured.
デバイスは管理用のコンソールポートおよびデフォルトの管理アカウントが付属していることを前提としています。 Noデフォルトパスワードと一緒にこの要件は、管理者アカウントが設定されていないパスワードが付属していなければならないと述べています。この要件は、デバイスを持っていることであろう会議の一つの方法は、ダイアログの一部として、デバイスが設定されている最初の時間を、管理者アカウントのパスワードを選択するオペレータを必要としています。
Warnings.
警告。
While this device requires operators to set passwords, it does not prevent them from doing things such as using scripts to configure hundreds of devices with the same easily guessed passwords.
このデバイスは、パスワードを設定するには、オペレータが必要ですが、それは、このような同じ簡単に推測パスワードで数百のデバイスを設定するには、スクリプトを使用するなどのことをやってからそれらを防ぐことはできません。
Requirement.
要求。
It MUST be possible to define arbitrary subsets of all management and configuration functions and assign them to groups or "privilege levels", which can be assigned to users per Section 2.12.12. There MUST be at least three possible privilege levels.
すべての管理および設定機能の任意のサブセットを定義し、セクション2.12.12あたりのユーザに割り当てることができるグループまたは「特権レベル」に割り当てることができなければなりません。少なくとも三つの可能な特権レベルがあるに違いありません。
Justification.
正当化。
This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
この要件は、個人が彼だけ/彼女が実行するために必要な操作を実行するのに必要な権限を持っているべきであると述べ、「最小特権」の校長の実装をサポートしています。
Examples.
例。
Examples of privilege levels might include "user" which only allows the initiation of a PPP or telnet session, "read only", which allows read-only access to device configuration and operational statistics, "root/superuser/administrator" which allows update access to all configurable parameters, and "operator" which allows updates to a limited, user defined set of parameters. Note that privilege levels may be defined locally on the device or on centralized authentication servers.
特権レベルの例としては、デバイスの設定および運用統計への読み取り専用アクセスを許可する唯一のPPPまたはtelnetセッションの開始を可能にする「ユーザー」、「読み取り専用」、更新アクセスを可能にする、「ルート/スーパーユーザ/管理者」を含めることができますすべての設定可能なパラメータ、およびパラメータの限定された、ユーザ定義セットの更新を可能にする「オペレータ」に。なお、特権レベルは、デバイス上または集中認証サーバー上でローカルに定義することができます。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST be able to assign a defined set of authorized functions, or "privilege level", to each user once they have authenticated themselves to the device. Privilege level determines which functions a user is allowed to execute. Also see Section 2.12.11.
それらはデバイスに自分自身を認証した後、デバイスは、ユーザ毎に、定義された承認機能のセット、または「特権レベル」を割り当てることができなければなりません。特権レベルは、ユーザが実行を許可されて機能するかを判断します。また、第2.12.11を参照してください。
Justification.
正当化。
This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
この要件は、個人が彼だけ/彼女が実行するために必要な操作を実行するのに必要な権限を持っているべきであると述べ、「最小特権」の校長の実装をサポートしています。
Examples.
例。
The implementation of this requirement will obviously be closely coupled with the authentication mechanism. If RADIUS is used, an attribute could be set in the user's RADIUS profile that can be used to map the ID to a certain privilege level.
この要件の実装は、明らかに密接に認証機構と結合されます。 RADIUSを使用する場合、属性は、特定の特権レベルにIDをマップするために使用することができ、ユーザのRADIUSプロファイルで設定することができます。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The default privilege level SHOULD NOT allow any access to management or configuration functions. It MAY allow access to user-level functions (e.g., starting PPP or telnet). It SHOULD be possible to assign a different privilege level as the default. This requirement MAY be relaxed to support system installation per Section 2.4.5 or recovery of authorized access per Section 2.12.15.
デフォルトの特権レベルは、管理や設定機能へのアクセスを許可しません。これは、（例えば、PPPまたはtelnetを開始する）ユーザレベルの機能へのアクセスを可能にすることができます。デフォルトとして別の権限レベルを割り当てることが可能であるべきです。この要件は、セクション2.4.5またはセクション2.12.15あたりの許可されたアクセスの回復あたりのシステムのインストールをサポートするために緩和されます。
Justification.
正当化。
This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
この要件は、個人が彼だけ/彼女が実行するために必要な操作を実行するのに必要な権限を持っているべきであると述べ、「最小特権」の校長の実装をサポートしています。
Examples.
例。
Examples of privilege levels might include "user" which only allows the initiation of a PPP or telnet session, "read-only", which allows read-only access to device configuration and operational statistics, "root/superuser/administrator" which allows update access to all configurable parameters, and "operator" which allows updates to a limited, user defined set of parameters. Note that privilege levels may be defined locally on the device or on centralized authentication servers.
特権レベルの例としては、デバイスの設定および運用統計への読み取り専用アクセスを許可する唯一のPPPまたはtelnetセッションの開始を可能にする「ユーザー」、「読み取り専用」、更新することができ、「ルート/スーパーユーザ/管理者」を含めることができますすべての設定可能なパラメータへのアクセス、およびパラメータの限定された、ユーザ定義セットの更新を可能にする「オペレータ」。なお、特権レベルは、デバイス上または集中認証サーバー上でローカルに定義することができます。
Warnings.
警告。
It may be required to provide exceptions to support the requirements to support recovery of privileged access (Section 2.12.15) and to support OS installation and configuration (Section 2.4.5). For example, if the OS and/or configuration has somehow become corrupt an authorized individual with physical access may need to have "root" level access to perform an install.
特権アクセス（節2.12.15）の回復をサポートし、OSのインストールと設定（セクション2.4.5）をサポートするための要件をサポートするための例外を提供するために必要な場合があります。 OSおよび/または構成が何らかの形で破損した場合たとえば、物理的にアクセスできる権限のある個人がインストールを実行するには、「ルート」レベルのアクセス権を持っている必要があるかもしれません。
Requirement.
要求。
The device MUST re-authenticate a user prior to granting any change in user authorizations.
デバイスは、ユーザの権限の変更を許可する前にユーザを再認証しなければなりません。
Justification.
正当化。
This requirement ensures that users are able to perform only authorized actions.
この要件は、ユーザーが唯一の認可アクションを実行できることを保証します。
Examples.
例。
This requirement might be implemented by assigning base privilege levels to all users and allowing the user to request additional privileges, with the requests validated by the AAA server.
この要件は、すべてのユーザーにベースの特権レベルを割り当て、ユーザーがAAAサーバによって検証を要求して、追加の権限を要求することを可能にすることによって実装されるかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The device MUST support a mechanism to allow authorized individuals to recover full privileged administrative access in the event that access is lost. Use of the mechanism MUST require physical access to the device. There MAY be a mechanism for disabling the recovery feature.
デバイスは、許可された個人は、アクセスが失われた場合には、完全な特権管理アクセスを回復できるようにするメカニズムをサポートしなければなりません。メカニズムの使用は、デバイスへの物理的アクセスを必要としなければなりません。回復機能を無効にするためのメカニズムがあるかもしれません。
Justification.
正当化。
There are times when local administrative passwords are forgotten, when the only person who knows them leaves the company, or when hackers set or change the password. In all these cases, legitimate administrative access to the device is lost. There should be a way to recover access. Requiring physical access to invoke the procedure makes it less likely that it will be abused. Some organizations may want an even higher level of security and be willing to risk total loss of authorized access by disabling the recovery feature, even for those with physical access.
それらを知っている人だけが会社を去るときに、ローカルの管理者パスワードは、忘れられている、またはハッカーが設定されたときやパスワードを変更する時間があります。これらすべての例では、デバイスへの正当な管理アクセスが失われます。アクセスを回復する方法があるはずです。プロシージャを呼び出すために物理的なアクセスを要求することは、それが悪用されます可能性が低くなります。一部の組織では、セキュリティのさらに高いレベルを必要としても物理的なアクセスとのそれらのため、リカバリ機能を無効にすることで、許可されたアクセスの全損失の危険を冒すことをいとわないことがあります。
Examples.
例。
Some examples of ways to satisfy this requirement are to have the device give the user the chance to set a new administrative password when:
この要件を満たすための方法のいくつかの例は、デバイスがユーザーに新しい管理者パスワードを設定する機会を与える持っています：
* The user sets a jumper on the system board to a particular position.
*ユーザは、特定の位置へのシステムボード上のジャンパーを設定します。
* The user sends a special sequence to the RS232 console port during the initial boot sequence.
*ユーザーは、最初のブートシーケンス中にRS232コンソールポートに特別なシーケンスを送信します。
* The user sets a "boot register" to a particular value.
*ユーザーが特定の値に「ブート・レジスタ」を設定します。
Warnings.
警告。
This mechanism, by design, provides a "back door" to complete administrative control of the device and may not be appropriate for environments where those with physical access to the device can not be trusted.
このメカニズムは、設計によって、デバイスの管理制御を完了するために「バックドア」を提供し、デバイスに物理的にアクセスを持つものは信用できない環境のために適切でないかもしれません。
Also see the warnings in Section 2.3.1 (Support a 'Console' Interface).
また、セクション2.3.1で警告を（「コンソール」インタフェースをサポートしています）を参照してください。
Requirement.
要求。
If a device provides layer 2 services that are dependent on layer 3 or greater services, then the portions that operate at or above layer 3 MUST conform to the requirements listed in this document.
デバイスがレイヤ3以上のサービスに依存しているレイヤ2サービスを提供する場合、レイヤ3で以上動作部分は、本文書に記載されている要件に適合しなければなりません。
Justification.
正当化。
All layer 3 devices have similar security needs and should be subject to similar requirements.
すべてのレイヤ3つのデバイスは類似のセキュリティニーズを持っており、同様の要件の対象とすべきです。
Examples.
例。
Signaling protocols required for layer 2 switching may exchange information with other devices using layer 3 communications. In such cases, the device must provide a secure layer 3 facility. Also, if higher layer capabilities (say, SSH or SNMP) are used to manage a layer 2 device, then the rest of the requirements in this document apply to those capabilities.
レイヤ2スイッチングレイヤ3つの通信を用いて他の装置と情報を交換することができるために必要なシグナリングプロトコル。このような場合、デバイスは、セキュアレイヤ3機能を提供しなければなりません。上位レイヤ機能（たとえば、SSHまたはSNMP）はレイヤ2デバイスを管理するために使用されている場合も、この文書の要件の残りの部分は、それらの機能に適用されます。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The use of security features specified by the requirements in this document SHOULD NOT cause severe operational problems.
この文書の要件によって指定されたセキュリティ機能を使用すると、深刻な操作上の問題が発生することはありません。
Justification.
正当化。
Security features which cause operational problems are not useful and may leave the operator with no mechanism for enforcing appropriate policy.
操作上の問題を引き起こすセキュリティ機能は有用ではない、適切なポリシーを適用するためのメカニズムをオペレータに残すことができます。
Examples.
例。
Some examples of severe operational problems include:
深刻な操作上の問題のいくつかの例は次のとおりです。
* The device crashes.
*デバイスがクラッシュします。
* The device becomes unmanageable.
*デバイスが管理不能になります。
* Data is lost.
*データが失われます。
* Use of the security feature consumes excessive resources (CPU, memory, bandwidth).
*セキュリティ機能の使用は、過剰なリソース（CPU、メモリ、帯域幅）を消費します。
Warnings.
警告。
Determination of compliance with this requirement involves a level of judgement. What is "severe"? Certainly crashing is severe, but what about a %5 loss in throughput when logging is enabled? It should also be noted that there may be unavoidable physical limitations such as the total capacity of a link.
この要件の遵守の決意は、判断のレベルを必要とします。 「厳しい」とは何ですか？確かにクラッシュは厳しいですが、どのようなログを有効にするスループットの5％の損失についてはどうですか？また、そのようなリンクの総容量と不可避物理的な制限が存在し得ることに留意すべきです。
Requirement.
要求。
Security features specified by the requirements in this document SHOULD be implemented with minimal impact on performance. Other sections of this document may specify different performance requirements (e.g., "MUST"s).
この文書の要件によって指定されたセキュリティ機能は、パフォーマンスへの影響を最小限に抑えて実装する必要があります。本文書の他のセクションは、異なる性能要件（例えば、「MUST」単数または複数）を指定することができます。
Justification.
正当化。
Security features which significantly impact performance may leave the operator with no mechanism for enforcing appropriate policy.
大幅にパフォーマンスに影響を与えるセキュリティ機能は、適切なポリシーを適用するためのメカニズムをオペレータに残すことができます。
Examples.
例。
If the application of filters is known to have the potential to significantly reduce throughput for non-filtered traffic, there will be a tendency, or in some cases a policy, not to use filters.
フィルタの適用が大幅に非フィルタリングしたトラフィックのスループットを削減する可能性があることが知られている場合は、フィルタを使用しないように、傾向、またはいくつかのケースでポリシーが存在します。
Assume, for example, that a new worm is released that scans random IP addresses looking for services listening on TCP port 1433. An operator might want to investigate to see if any of the hosts on their networks were infected and trying to spread the worm. One way to do this would be to put up non-blocking filters counting and logging the number of outbound connection 1433, and then to block the requests that are determined to be from infected hosts. If any of these capabilities (filtering, counting, logging) have the potential to impose severe performance penalties, then this otherwise rational course of action might not be possible.
新しいワームは、オペレータがそのネットワーク上のホストのいずれかが感染し、ワームを広めるためにしようとしていたかどうかを確認するために調査したいかもしれないTCPポート1433でリッスンしてサービスを探して、ランダムなIPアドレスをスキャンがリリースされていること、例えば、想定しています。これを行う1つの方法は、アウトバウンド接続1433の数をカウントし、ログインする非ブロックフィルタを設置し、その後、感染したホストからであると判断された要求をブロックすることです。これらの機能（フィルタリング、集計、伐採）のいずれかが、深刻なパフォーマンスの低下を課す可能性を持っている場合、アクションのこのそうでない場合は、合理的なコースができない場合があります。
Warnings.
警告。
Requirements for which performance is a particular concern include: filtering, rate-limiting, counters, logging and anti-spoofing.
パフォーマンスが特に懸念されている要件は、次のとおりです。フィルタリング、速度制限、カウンタ、ロギングおよびアンチスプーフィングを。
The requirements in this section are intended to list information that will assist operators in evaluating and securely operating a device.
このセクションの要件は、評価と安全に機器を操作中にオペレータを支援する情報を一覧表示することを意図しています。
Requirement.
要求。
The vendor MUST provide a list of all services that may be active on the device. The list MUST identify the protocols and default ports (if applicable) on which the services listen. It SHOULD provide references to complete documentation describing the service.
ベンダーは、デバイス上でアクティブにできるすべてのサービスのリストを提供しなければなりません。リストには、プロトコルとサービスが聞きするデフォルトポート（該当する場合）を特定しなければなりません。これは、サービスを記述した文書を完了するために、参照を提供する必要があります。
Justification.
正当化。
This information is necessary to enable a thorough assessment of the potential security risks associated with the operation of each service.
この情報は、各サービスの動作に関連する潜在的なセキュリティリスクの徹底的な評価を有効にする必要があります。
Examples.
例。
The list will likely contain network and transport protocols such as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF, application protocols such as SSH and SNMP along with references to the RFCs or other documentation describing the versions of the protocols implemented.
リストには、おそらく、このような実装プロトコルのバージョンを記述するRFCや他のドキュメントへの参照とともに、このようなSSHやSNMPなどのアプリケーション・プロトコルIP、ICMP、TCP、UDP、などBGPやOSPFなどのルーティングプロトコルなどのネットワークおよびトランスポートプロトコルが含まれています。
Web servers "usually" listen on port 80. In the default configuration of the device, it may have a web server listening on port 8080. In the context of this requirement "identify ... default port" would mean "port 8080".
ウェブサーバは、「通常」のデバイスのデフォルトの設定ではポート80でリッスン、それはWebサーバがこの要件の文脈ではポート8080でリッスンしている可能性があり、「識別...デフォルトポートは」「ポート8080」を意味します。
Warnings.
警告。
There may be valid, non-technical reasons for not disclosing the specifications of proprietary protocols. In such cases, all that needs to be disclosed is the existence of the service and the default ports (if applicable).
独自のプロトコルの仕様を開示していないために有効な、非技術的な理由があるかもしれません。このような場合には、開示される必要があることを、すべてのサービスとデフォルトポート（該当する場合）の存在です。
Requirement.
要求。
The vendor MUST provide a list of the default state of all services.
ベンダーは、すべてのサービスのデフォルト状態のリストを提供しなければなりません。
Justification.
正当化。
Understanding risk requires understanding exposure. Each service that is enabled presents a certain level of exposure. Having a list of the services that is enabled by default makes it possible to perform meaningful risk analysis.
リスクを理解することは理解曝露を必要とします。有効になっている各サービスは、露出の一定のレベルを示しています。デフォルトで有効になっているサービスのリストを持つことは意味のあるリスク分析を実行することが可能となります。
Examples.
例。
The list may be no more than the output of a command that implements Section 2.5.1.
リストには、セクション2.5.1を実装して、コマンドの出力以下でないかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The vendor MUST concisely document which features enable and disable services.
ベンダーは、簡潔なサービスを有効または無効に備えている文書化する必要があります。
Justification.
正当化。
Once risk has been assessed, this list provides the operator a quick means of understanding how to disable (or enable) undesired (or desired) services.
リスクが評価された後、このリストは、オペレータに無効（または有効）にする方法を理解する迅速な手段望ましくない（または所望の）サービスを提供しています。
Examples.
例。
This may be a list of commands to enable/disable services one by one or a single command which enables/disables "standard" groups of commands.
これは、/無効にサービスを一つずつか/可能なコマンドの「標準」のグループを無効に単一のコマンドを有効にするには、コマンドのリストかもしれません。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The vendor MUST provide complete documentation of the command line interface with each software release. The documentation SHOULD include highlights of changes from previous versions. The documentation SHOULD list potential output for each command.
ベンダーは、各ソフトウェアリリースのコマンドライン・インタフェースの完全なドキュメントを提供しなければなりません。ドキュメントは、以前のバージョンからの変更のハイライトを含むべきです。ドキュメントには、各コマンドの電位出力をリストする必要があります。
Justification.
正当化。
Understanding of inputs and outputs is necessary to support scripting. See Section 2.4.2.
入力と出力の理解がスクリプトをサポートするために必要です。 2.4.2項を参照してください。
Examples.
例。
Separate documentation should be provided for each command listing the syntax, parameters, options, etc. as well as expected output (status, tables, etc.).
別々のドキュメントが構文を一覧各コマンドのために提供されなければならない、パラメータ、オプションなどだけでなく、予想される出力（ステータス、テーブルなど）。
Warnings.
警告。
None.
無し。
Requirement.
要求。
The console default profile of communications parameters MUST be published in the system documentation.
通信パラメータのコンソールデフォルトのプロファイルは、システムのマニュアルで公開する必要があります。
Justification.
正当化。
Publication in the system documentation makes the settings accessible. Failure to publish them could leave the operator having to guess.
システムのマニュアルの出版は、設定にアクセスできるようになります。それらを公開しないと、推測したオペレータを残すことができます。
Examples.
例。
None.
無し。
Warnings.
警告。
None.
無し。
The requirements in this section are intended to
このセクションの要件をすることを意図しています
o identify behaviors and information that will increase confidence that the device will meet the security functional requirements.
Oデバイスがセキュリティ機能要件を満たす信頼性を高めるだろう行動や情報を特定します。
o Provide information that will assist in the performance of security evaluations.
Oセキュリティ評価のパフォーマンスに支援する情報を提供します。
Requirement.
要求。
The vendor SHOULD disclose the origin or basis of the IP stack used on the system.
ベンダーは、システム上で使用されるIPスタックの起源や根拠を開示すべきです。
Justification.
正当化。
This information is required to better understand the possible security vulnerabilities that may be inherent in the IP stack.
この情報は、より良いIPスタックに内在する可能性のあるセキュリティの脆弱性を理解することが必要です。
Examples.
例。
"The IP stack was derived from BSD 4.4", or "The IP stack was implemented from scratch."
「IPスタックが最初から実装されました。」「IPスタックはBSD 4.4から誘導された」、または
Warnings.
警告。
Many IP stacks make simplifying assumptions about how an IP packet should be formed. A malformed packet can cause unexpected behavior in the device, such as a system crash or buffer overflow which could result in unauthorized access to the system.
多くのIPスタックは、IPパケットが形成されるべきかについての単純化仮定を行います。不正なパケットは、そのようなシステムへの不正アクセスにつながる可能性があり、システムのクラッシュやバッファオーバーフローなどのデバイス、で予期しない動作を引き起こす可能性があります。
Requirement.
要求。
The vendor SHOULD disclose the origin or basis of the operating system (OS).
ベンダーは、オペレーティングシステム（OS）の起源や根拠を開示すべきです。
Justification.
正当化。
This information is required to better understand the security vulnerabilities that may be inherent to the OS based on its origin.
この情報は、より良い、その起源に基づいて、OSに固有であり、セキュリティの脆弱性を理解することが必要です。
Examples.
例。
"The operating system is based on Linux kernel 2.4.18."
「オペレーティングシステムはLinuxカーネル2.4.18に基づいています。」
Warnings.
警告。
None.
無し。
General
一般的な
Security is the subject matter of this entire memo. The justification section of each individual requirement lists the security implications of meeting or not meeting the requirement.
セキュリティは、この全体のメモの主題です。個々の要件の正当化セクションは、ミーティングや要件を満たしていないのセキュリティへの影響を示しています。
SNMP
SNMP
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in the MIB.
SNMPv3の前のSNMPバージョンは十分なセキュリティを含んでいませんでした。ネットワーク自体が（IPSecを使用することにより、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）内のオブジェクトが存在しませんMIB。
It is recommended that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
実装者がSNMPv3フレームワークで提供するようにセキュリティ機能を考えることをお勧めします（認証とプライバシーのため）SNMPv3の暗号のメカニズムのためのフルサポートを含む、（、[RFC3410]のセクション8を参照）。
Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to MIB objects is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はお勧めしません。代わりに、SNMPv3を展開すると、暗号化セキュリティを有効にすることをお勧めします。 （変更/作成/削除MIBオブジェクトへのアクセスを与えるSNMP実体が適切にのみ実際に取得または設定する正当な権利を持っているそれらのプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/オペレータ責任です）それらを。
[ANSI.X9-52.1998] American National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52, 1998.
[ANSI.X9-52.1998]米国規格協会、「操作のトリプルデータ暗号化アルゴリズムモード」、ANSI X9.52、1998。
[FIPS.197] National Institute of Standards and Technology, "Advanced Encryption Standard", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.ps>.
[FIPS.197]米国国立標準技術研究所、 "高度暗号化規格"、FIPS PUBの197、2001年11月、<http://csrc.nist.gov/publications/fips/fips197/ fips-197.ps>。
[PKCS.3.1993] RSA Laboratories, "Diffie-Hellman Key-Agreement Standard, Version 1.4", PKCS 3, November 1993.
[PKCS.3.1993] RSA Laboratories社、 "のDiffie-Hellman鍵合意規格、バージョン1.4"、PKCS 3、1993年11月。
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991.
[RFC1208]ヤコブセン、O.およびD.リンチ、 "ネットワーク用語集"、RFC 1208、1991年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[RFC1492] Finseth、C.、 "時々TACACS呼び出さアンアクセス制御プロトコル"、RFC 1492、1993年7月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
"インターネット認証について" [RFC1704]ハラー、N.とR.アトキンソン、RFC 1704、1994年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[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月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]フレイザー、B.、 "サイトセキュリティハンドブック"、FYI 8、RFC 2196、1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、RFC 2631、1999年6月。
[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月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013] Killalea、T.、 "推奨インターネットサービスプロバイダのセキュリティサービスと手続き"、BCP 46、RFC 3013、2000年11月。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164] Lonvick、C.、 "BSDシスログプロトコル"、RFC 3164、2001年8月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレイク、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム1（SHA1）を確保"、RFC 3174、2001年9月。
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.
[RFC3195]新しい、D.とM.ローズ、 "syslogのための信頼性の高い配信"、RFC 3195、2001年11月。
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]ストーン、J.、スチュワート、R.とD.オーティス、 "ストリーム制御伝送プロトコル（SCTP）チェックサムの変更"、RFC 3309、2002年9月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、S.、 "有害考慮不適切なTCPリセット"、BCP 60、RFC 3360、2002年8月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.とB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、M.、 "TCP MD5署名オプションのためのキー管理の考慮事項"、RFC 3562、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, Eds., "Security Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3631] Bellovin氏、S.、シラー、J.、およびC.カウフマン編、 "インターネットのセキュリティメカニズム"、RFC 3631、2003年12月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[bmwg-acc-bench] Poretsky, S., "Framework for Accelerated Stress Benchmarking", Work in Progress, October 2003.
[bmwg-ACC-ベンチ] Poretsky、S.、 "ベンチマーク加速ストレスのための枠組み"、進歩、2003年10月に作業。
[Schneier] Schneier, B., "Applied Cryptography, 2nd Ed., Publisher John Wiley & Sons, Inc.", 1996.
[シュナイアー]シュナイアー、B.、「応用暗号、第2版、出版社ジョン・ワイリー・アンド・サンズ社」、1996年。
Appendix A. Requirement Profiles
付録A.要件プロファイル
This Appendix lists different profiles. A profile is a list of list of requirements that apply to a particular class of devices. The minimum requirements profile applies to all devices.
この付録では、異なるプロファイルを示しています。プロファイルは、デバイスの特定のクラスに適用される要件のリストのリストです。最小要件プロファイルは、すべてのデバイスに適用されます。
A.1. Minimum Requirements Profile
A.1。最小要件プロフィール
The functionality listed here represents a minimum set of requirements to which managed infrastructure of large IP networks should adhere.
ここに記載されている機能が遵守すべき大規模なIPネットワークのインフラストラクチャを管理するための要件の最小セットを表します。
The minimal requirements profile addresses functionality which will provide reasonable capabilities to manage the devices in the event of attacks, simplify troubleshooting, keep track of events which affect system integrity, help analyze causes of attacks, as well as provide administrators control over IP addresses and protocols to help mitigate the most common attacks and exploits.
管理者は、IPアドレスやプロトコルを介して制御し、攻撃のイベントでデバイスを管理、トラブルシューティングを簡素化し、システムの整合性に影響を与えるイベントを追跡、攻撃の原因を分析するのに役立つだけでなく、提供するために、合理的な機能を提供します最低限の要件プロファイルアドレス機能最も一般的な攻撃や悪用を軽減します。
o Support Secure Channels For Management
O管理のための安全なチャネルをサポート
o Use Protocols Subject To Open Review For Management
管理のためのオープンレビューにO使用するプロトコルの件名
o Use Cryptographic Algorithms Subject To Open Review
レビューを開くために使用暗号アルゴリズムは、件名O
o Use Strong Cryptography
O強力な暗号化を使用します
o Allow Selection of Cryptographic Parameters
O暗号パラメータの選択を可能に
o Management Functions Should Have Increased Priority
O管理機能は、優先順位を高めている必要があります
o Support a 'Console' Interface
O「コンソール」インタフェースをサポート
o 'Console' Communication Profile Must Support Reset
O「コンソール」通信プロファイルはリセットサポートしている必要があります
o 'Console' Default Communication Profile Documented
O「コンソール」デフォルトの通信プロファイルは、文書化
o 'Console' Requires Minimal Functionality of Attached Devices.
O「コンソールは、」接続デバイスの最小限の機能が必要です。
o Support Separate Management Plane IP Interfaces
O個別の管理プレーンIPインタフェースをサポートしています
o No Forwarding Between Management Plane And Other Interfaces
管理プレーンおよびその他のインタフェースとの間で転送O
o 'CLI' Provides Access to All Configuration and Management Functions
O「CLIは、」すべての構成と管理機能へのアクセスを提供します
o 'CLI' Supports Scripting of Configuration o 'CLI' Supports Management Over 'Slow' Links
「CLI」は「遅い」リンク上での管理をサポート〇〇「CLIは、」構成のスクリプトをサポートします
o Document Command Line Interface
Oドキュメントコマンドラインインタフェース
o Support Software Installation
Oサポート・ソフトウェアのインストール
o Support Remote Configuration Backup
Oリモート構成のバックアップをサポートしています
o Support Remote Configuration Restore
Oの復元リモート設定をサポートしています
o Support Text Configuration Files
Oテキストコンフィギュレーションファイルをサポート
o Ability to Identify All Listening Services
すべてのリスニングサービスを識別するためにO機能
o Ability to Disable Any and All Services
O能力は、任意およびすべてのサービスを無効にします
o Ability to Control Service Bindings for Listening Services
サービスを聴くためのサービスバインディングを制御する機能をO
o Ability to Control Service Source Addresses
O能力は、サービスソースアドレスを制御するには
o Ability to Filter Traffic
Oトラフィックをフィルタリングする機能
o Ability to Filter Traffic TO the Device
デバイスへのトラフィックをフィルタリングするO能力
o Support Route Filtering
Oサポートルートフィルタリング
o Ability to Specify Filter Actions
フィルタアクションを指定するには、O能力
o Ability to Log Filter Actions
フィルタのアクションをログにO機能
o Ability to Filter Without Significant Performance Degradation
O能力は、パフォーマンスを大幅に低下させることなく、フィルタします
o Ability to Specify Filter Log Granularity
フィルターログの粒度を指定する機能をO
o Ability to Filter on Protocols
プロトコルにフィルタする機能をO
o Ability to Filter on Addresses
アドレスに基づいてフィルタリングする機能をO
o Ability to Filter on Protocol Header Fields
プロトコルヘッダフィールドにフィルターする機能をO
o Ability to Filter Inbound and Outbound
O能力は、インバウンドとアウトバウンドのフィルタリング
o Packet Filtering Counter Requirements
Oパケットフィルタリングカウンタ要件
o Ability to Display Filter Counters
フィルタカウンタを表示するO機能
o Ability to Display Filter Counters per Rule o Ability to Display Filter Counters per Filter Application
フィルタアプリケーションあたりのフィルタカウンタを表示する能力のルールあたりのフィルタカウンタを表示する能力をO
o Ability to Reset Filter Counters
フィルタのカウンタをリセットするには、O能力
o Filter Counters Must Be Accurate
Oフィルタカウンタは正確でなければなりません
o Logging Facility Uses Protocols Subject To Open Review
Oログ機能は、レビューを開くには、件名プロトコルを使用します
o Logs Sent To Remote Servers
Oログはリモートサーバーに送信します
o Ability to Log Locally
ローカルでログオンする機能O
o Ability to Maintain Accurate System Time
正確なシステム時刻を維持する能力をO
o Display Timezone And UTC Offset
OディスプレイのタイムゾーンとUTCオフセット
o Default Timezone Should Be UTC
OデフォルトのタイムゾーンはUTCをする必要があります。
o Logs Must Be Timestamped
Oログはタイムスタンプする必要が
o Logs Contain Untranslated IP Addresses
Oログが翻訳されていないIPアドレスを含みます
o Logs Contain Records Of Security Events
Oログは、セキュリティイベントのレコードが含まれています
o Authenticate All User Access
Oすべてのユーザーアクセスを認証
o Support Authentication of Individual Users
個々のユーザのサポート認証O
o Support Simultaneous Connections
O同時接続をサポートしています
o Ability to Disable All Local Accounts
O能力は、すべてのローカルアカウントを無効にします
o Support Centralized User Authentication Methods
Oの集中ユーザー認証方法をサポート
o Support Local User Authentication Method
Oローカルユーザ認証方式をサポートしています
o Support Configuration of Order of Authentication Methods
認証方法の順序のOサポート構成
o Ability To Authenticate Without Plaintext Passwords
平文パスワードなしで認証する機能をO
o Passwords Must Be Explicitly Configured Prior To Use
Oパスワードが明示的に設定する必要があり、使用する前
o No Default Passwords
デフォルトのパスワードO
o Ability to Define Privilege Levels
特権レベルを定義するには、O能力
o Ability to Assign Privilege Levels to Users o Default Privilege Level Must Be 'None'
Oデフォルトの特権レベルOユーザーへの特権レベルを割り当てる機能は「なし」である必要があります
o Change in Privilege Levels Requires Re-Authentication
O特権レベルの変更は、再認証が必要です
o Support Recovery Of Privileged Access
特権アクセスをサポートする回復O
o Logs Do Not Contain Passwords
Oのログはパスワードを含んでいません
o Security Features Must Not Cause Operational Problems
Oセキュリティ機能は、操作上の問題を引き起こしてはなりません
o Security Features Should Have Minimal Performance Impact
Oセキュリティ機能は、パフォーマンスへの影響を最小限に抑えるを持つべきです
o Identify Services That May Be Listening
Oリスニングされることがあるサービスを識別
o Document Service Defaults
ドキュメントサービスの既定値O
o Document Service Activation Process
Oドキュメントサービスアクティベーションプロセス
o Identify Origin of IP Stack
O IPスタックの起源を特定します
o Identify Origin of Operating System
Oオペレーティングシステムの起源を特定します
o Identify Origin of IP Stack
O IPスタックの起源を特定します
o Identify Origin of Operating System
Oオペレーティングシステムの起源を特定します
o Layer 2 Devices Must Meet Higher Layer Requirements
Oレイヤ2つのデバイスは、上位層の要件を満たす必要があります。
A.2. Layer 3 Network Edge Profile
A.2。レイヤ3ネットワークのエッジプロファイル
This section builds on the minimal requirements listed in A.1 and adds more stringent security functionality specific to layer 3 devices which are part of the network edge. The network edge is typically where much of the filtering and traffic control policies are implemented.
このセクションでは、A.1に記載されている最小要件に構築され、ネットワークエッジの一部である3つのデバイス層に特定のより厳格なセキュリティ機能を追加します。フィルタリングおよびトラフィック制御ポリシーの多くが実現されるだけで、ネットワークエッジは典型的です。
An edge device is defined as a device that makes up the network infrastructure and connects directly to customers or peers. This would include routers connected to peering points, switches connecting customer hosts, etc.
エッジデバイスは、ネットワーク・インフラストラクチャを構成する顧客又はピアに直接接続デバイスとして定義されます。これは、顧客のホストなどを接続するスイッチ、ピアリング・ポイントに接続されたルータを含むであろう
o Support Automatic Anti-spoofing for Single-Homed Networks
シングルホームネットワークのOサポート自動アンチスプーフィング
o Support Automatic Discarding Of Bogons and Martians
Bogonsと火星人を支援する自動廃棄O
o Support Counters For Dropped Packets
パケットの欠落Oサポートカウンター
o Support Rate Limiting o Support Directional Application Of Rate Limiting Per Interface
Oサポートレートは、インターフェイスごとのレート制限をサポートする方向性アプリケーションoを制限します
o Support Rate Limiting Based on State
Oサポートレートは国家に基づいて制限します
o Ability to Filter Traffic THROUGH the Device
デバイスを介してトラフィックをフィルタリングするO能力
Appendix B. Acknowledgments
付録B.謝辞
This document grew out of an internal security requirements document used by UUNET for testing devices that were being proposed for connection to the backbone.
この文書では、バックボーンに接続するために提案された試験装置のためにUUNETが使用する内部セキュリティ要件の文書から生まれました。
The editor gratefully acknowledges the contributions of: o Greg Sayadian, author of a predecessor of this document.
OグレッグSayadian、本書の前身の著者：編集者は感謝の貢献を認めています。
o Eric Brandwine, a major source of ideas/critiques.
OエリックBrandwine、アイデア/批判の主な原因。
o The MITRE Corporation for supporting continued development of this document. NOTE: The editor's affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed by the editor.
このドキュメントの継続的な開発を支援するためのMITRE社O。注：MITRE社で編集者の所属は、唯一の識別目的のために提供され、そして伝えるか、MITREのと並行し、またはエディタで表現位置、意見や視点、のサポートを暗示するものではありません。
o The former UUNET network security team: Jared Allison, Eric Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent King, Neil Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd MacDermid, Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow, Robert Stone, Anne Williams, Pete White.
かつてのUUNETネットワークセキュリティチームO：ジャレッド・アリソン、エリックBrandwine、クラリッサ・クック、デイヴ・ガーン、妙キム、ケント王、ニールKirr、マーク・クラウス、マイケル・ラムルー、モーリーン・リー、トッド・マクダーミド、クリス・モロー、アラン・ピッツ、グレッグSayadian、ブルース雪、ロバート・ストーン、アン・ウィリアムズ、ピートホワイト。
o Others who have provided significant feedback at various stages of the life of this document are: Ran Atkinson, Fred Baker, Steve Bellovin, David L. Black, Michael H. Behringer, Matt Bishop, Scott Blake, Randy Bush, Pat Cain, Ross Callon, Steven Christey, Owen Delong, Sean Donelan, Robert Elmore, Barbara Fraser, Barry Greene, Jeffrey Haas, David Harrington, Dan Hollis, Jeffrey Hutzelman, Merike Kaeo, James Ko, John Kristoff, Chris Lonvick, Chris Liljenstolpe, James W. Laferriere, Jared Mauch, Perry E. Metzger, Mike O'Connor, Alan Paller, Rob Pickering, Pekka Savola, Gregg Schudel, Juergen Schoenwaelder, Don Smith, Rodney Thayer, David Walters, Joel N. Weber II, Russ White, Anthony Williams, Neal Ziring.
Oこの文書の人生の様々な段階で重要なフィードバックを提供している他のものはされていますアトキンソン、フレッド・ベイカー、スティーブBellovin氏、デビッドL.ブラック、マイケル・H.ベリンガー、マット・ビショップ、スコット・ブレイク、ランディブッシュ、パットカイン、ロス蘭Callon、スティーブンChristey、オーウェン・デロング、ショーンDonelan、ロバートエルモア、バーバラ・フレイザー、バリー・グリーン、ジェフリーハース、デヴィッド・ハリントン、ダン・ホリス、ジェフリーHutzelman、Merike Kaeoの、ジェームズ・コー、ジョンKristoff、クリスLonvick、クリスLiljenstolpe、ジェームズ・W. Laferriere、ジャレッドMauch、ペリーE.メッツガー、マイク・オコナー、アラン・Paller、ロブ・ピカリング、ペッカSavola、グレッグSchudel、ユルゲンSchoenwaelder、ドン・スミス、ロドニーセイヤー、デビッド・ウォルターズ、ジョエル・N.ウェーバーII、ラスホワイト、アンソニー・ウィリアムズ、ニールZiring。
o Madge B. Harrison and Patricia L. Jones, technical writing review.
OマッジB.ハリソンとパトリシア・L.ジョーンズ、テクニカルライティングのレビュー。
o This listing is intended to acknowledge contributions, not to imply that the individual or organizations approve the content of this document.
Oこのリストは、個人または組織が、この文書の内容を承認することを意味するものでないこと、貢献を認めることを目的としています。
o Apologies to those who commented on/contributed to the document and were not listed.
O /コメントした者への謝罪は、ドキュメントに貢献し、リストされていませんでした。
Author's Address
著者のアドレス
George M. Jones, Editor The MITRE Corporation 7515 Colshire Drive, M/S WEST McLean, Virginia 22102-7508 U.S.A.
ジョージ・M・ジョーンズ、エディタMITRE社7515 Colshireドライブ、M / S WESTマクリーン、バージニア州22102から7508 U.S.A.
Phone: +1 703 488 9740 EMail: gmj3871@pobox.com
電話：+1 703 488 9740 Eメール：gmj3871@pobox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。