RFC3871 日本語訳
3871 Operational Security Requirements for Large Internet ServiceProvider (ISP) IP Network Infrastructure. G. Jones, Ed.. September 2004. (Format: TXT=151101 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Jones, Ed. Request for Comments: 3871 The MITRE Corporation Category: Informational September 2004
ワーキンググループのG.ジョーンズ、エドをネットワークでつないでください。コメントのために以下を要求してください。 3871 斜め継ぎ社のカテゴリ: 情報の2004年9月
Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Infrastructure
大きいインターネットサービスプロバイダ(ISP)IPネットワークインフラのための操作上のセキュリティ要件
Status of this Memo
この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).
Copyright(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ネットワーク(ルータとスイッチ)のインフラストラクチャのための操作上のセキュリティ要件のリストを定義します。 フレームワークは、「プロフィール」を指定するために定義されます(あるネットワーク形態文脈(コアだけ、縁専用)に適切な要件の収集です)。 目標は彼らのセキュリティ要件をベンダーに伝える明確で、簡潔な方法をネットワーク・オペレータに提供することです。
Jones Informational [Page 1] RFC 3871 Operational Security Requirements September 2004
操作上の[1ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1。 目標。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. 動機. . . . . . . . . . . . . . . . . . . . . . . 5 1.3。 範囲。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. 安全なネットワーク. . . . . . . . . . . . . 6 1.5の定義。 対象とする訪問者。 . . . . . . . . . . . . . . . . . . . 6 1.6. .61.7をフォーマットしてください。 意図している使用. . . . . . . . . . . . . . . . . . . . . . 7 1.8。 定義。 . . . . . . . . . . . . . . . . . . . . . . 7 2. 機能条件書. . . . . . . . . . . . . . . . . . . 11 2.1。 デバイス管理要件. . . . . . . . . . . . . 11 2.1.1。 管理のための安全なチャンネルを支えてください。 . . . . 11 2.2. バンドにおける管理要件。 . . . . . . . . . . . . 12 2.2.1. 公開審査. . . . . . . . . . . . . . . . . . 12 2.2.2を条件として暗号アルゴリズムを使用してください。 強い暗号. . . . . . . . . . . . 13 2.2.3を使用してください。 管理のための公開審査を条件としてプロトコルを使用してください。 . . . . . . . . . . . . . . . . . . 14 2.2.4. 暗号のパラメタ. . 15 2.2.5の選択を許してください。 管理機能は優先権を増強するべきでした。 . . . . . . . . . . . . . . . . . . . 16 2.3. バンドで出ている(OoB)管理要件. . . . . . . 16 2.3.1。 'コンソール'インタフェース. . . . . . . . . 17 2.3が.2であるとサポートしてください。 'コンソール'というコミュニケーションプロフィールは、リセット. . . . . . . . . . . . . . . . . . . . . 19 2.3が.3であるとサポートしなければなりません。 'コンソール'は付属デバイスの最小量の機能性を必要とします。 . . . . . . . . . . . . . . . 19 2.3.4. 'コンソール'は、後退認証. . 20 2.3が.5であるとサポートします。 別々の管理飛行機IPがインタフェースであるとサポートしてください。 . . . . . . . . . . . . . . . . . . 21 2.3.6. 管理飛行機と他のインタフェースの間の進めないこと。 . . . . . . . . . . . . . . . . . . 21 2.4. 構成と経営者側は要件を連結します。 . . 22 2.4.1. 'CLI'はすべての構成と管理機能へのアクセスを提供します。 . . . . . . . . . . . . . 22 2.4.2. 'CLI'は構成. . . 23 2.4.3のスクリプティングをサポートします。 'CLI'は'遅くなってください'の上の管理にリンクス. . 24 2.4.4をサポートします。 'CLI'は、活動していないセッションタイムアウト. . . . . . 25 2.4が.5であるとサポートします。 ソフトウェアインストール. . . . . . . . . 25 2.4が.6であるとサポートしてください。 リモート構成バックアップ. . . . . . 27 2.4.7をサポートしてください。 リモート構成が復元するサポート。 . . . . . 27 2.4.8. テキストが構成ファイルであるとサポートしてください。 . . . . . . . 28 2.5. IPスタック要件。 . . . . . . . . . . . . . . . . . 29 2.5.1. すべてを特定するサービスを聴く能力。 . . 29 2.5.2. ありとあらゆるサービス. . . . 30を無効にする能力
Jones Informational [Page 2] RFC 3871 Operational Security Requirements September 2004
操作上の[2ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.5.3. サービスを聴くためのサービス結合を制御する能力。 . . . . . . . . . . . . . . 30 2.5.4. サービスソースアドレス. . 31 2.5.5を制御する能力。 自動反スプーフィングをサポートする、シングル家へ帰る、.6に.322.5をネットワークでつなぎます。 Bogonsと火星人を自動捨てることをサポートしてください。 . . . . . . . . . . . . . . . . . . . 33 2.5.7. 下げられたパケットのためにカウンタをサポートしてください。 . . . . . 34 2.6. 要件. . . . . . . . . . . . . . . 35 2.6.1を制限して、評価してください。 レート制限. . . . . . . . . . . . . 35 2.6が.2であるとサポートしてください。 1インタフェースあたりのレート制限の方向のアプリケーションをサポートしてください。 . . . . . . . . . . . . 36 2.6.3. 状態に基づくレート制限をサポートしてください。 . . . . . 36 2.7. 基本的なフィルタリング能力. . . . . . . . . . . . . . 37 2.7.1。 トラフィック. . . . . . . . . . . 37 2.7.2をフィルターにかける能力。 デバイス. . . . 37 2.7.3にトラフィックをフィルターにかける能力。 デバイスを通してトラフィックをフィルターにかける能力。 . 38 2.7.4. 重要なパフォーマンス退行. . . . . . . . . . . . 38 2.7.5なしでフィルターにかける能力。 ルートフィルタリング. . . . . . . . . . . . 39 2.7が.6であるとサポートしてください。 フィルタ動作. . . . . . . 40 2.7.7を指定する能力。 フィルタ動作. . . . . . . . . 40 2.8を登録する能力。 パケットフィルタリング評価基準。 . . . . . . . . . . . . . . . 41 2.8.1. プロトコルでフィルターにかける能力。 . . . . . . . . 41 2.8.2. アドレスでフィルターにかける能力。 . . . . . . . . 42 2.8.3. プロトコルでヘッダーフィールド. . 42 2.8.4をフィルターにかける能力。 フィルタ本国行きと外国行きへの能力。 . . . . 43 2.9. パケットフィルタリングカウンタ要件。 . . . . . . . . . 43 2.9.1. 正確に.2にフィルタヒット. . . . 43 2.9を数える能力 表示フィルタへの能力は反対します。 . . . . . . 44 2.9.3. 表示フィルタへの能力は規則. . 45 2.9.4単位で反対します。 表示フィルタへの能力はフィルタアプリケーション. . . . . . . . . . . . . . . . . . 45 2.9.5単位で反対します。 フィルタをリセットする能力は反対します。 . . . . . . . 46 2.9.6. フィルタカウンタは正確でなければなりません。 . . . . . . . 47 2.10. 他のパケットフィルタリング要件. . . . . . . . . . 47 2.10.1。 フィルタログ粒状. . . 47 2.11を指定する能力。 イベント伐採要件. . . . . . . . . . . . . . . 48 2.11.1。 伐採施設は公開審査. . . . . . . . . . . . . . . . . . 48 2.11.2を条件としてプロトコルを使用します。 ログはリモートサーバ. . . . . . . . . . 49 2.11.3に発信しました。 信頼できる配信. . . . . . 49 2.11.4を選択する能力。 局所的に登録する能力。 . . . . . . . . . . . . 50 2.11.5. 正確なシステム時間を維持する能力。 . . . 50 2.11.6. タイムゾーンとUTCオフセット. . . . . . . . 51 2.11.7を表示してください。 デフォルトタイムゾーンはUTCであるべきです。 . . . . . . . . 52 2.11.8. ログはTimestampedであるに違いありません。 . . . . . . . . . . . 52 2.11.9. ログはUntranslated IPアドレスを含んでいます。 . . . . 53
Jones Informational [Page 3] RFC 3871 Operational Security Requirements September 2004
操作上の[3ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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
2.11.10. ログはセキュリティイベント. . . . 54 2.11.11に関する記録を含んでいます。 ログはパスワード. . . . . . . . . 55 2.12を含んでいません。 認証、承認、および会計(AAA)要件. . . . . . . . . . . . . . . . . . . . . . 55 2.12.1。 すべてのユーザアクセサリーを認証してください。 . . . . . . . . . 55 2.12.2. 個々のユーザの認証をサポートしてください。 . . 56 2.12.3. 同時接続をサポートしてください。 . . . . . . . 56 2.12.4. すべてのローカルのアカウント. . . . . 57 2.12が.5であると無効にする能力。 サポートはユーザー認証メソッド. . . . . . . . . . . . . . . . . . . . 57 2.12.6を集結しました。 ローカルユーザー認証がメソッドであるとサポートしてください。 . . . 58 2.12.7. 認証方法. . . . . . . . . . . . 59 2.12.8の注文の構成をサポートしてください。 平文パスワード. . . . . . . . . . . . . . . . . . . 59 2.12.9なしで認証する能力。 デフォルトパスワードがありません。 . . . . . . . . . . . . . 60 2.12.10. 使用の前に明らかにパスワードを構成しなければなりません。 . . . . . . . . . . . . . . . . . . . . 60 2.12.11. 特権レベルを定義する能力。 . . . . . . 61 2.12.12. ユーザ. . 62 2.12.13に特権レベルを割り当てる能力。 デフォルト特権レベルは'なにも'であるに違いありません。 . . . . 62 2.12.14. 特権レベルにおける変化は.15に再認証.63 2.12を必要とします。 特権的アクセス. . . . . 64 2.13の回復をサポートしてください。 層2のデバイスは、より高い層の必要条件を満たさなければなりません。 . . 65 2.14. セキュリティ機能は運転上の問題65 2.15を引き起こしてはいけません。 セキュリティ機能には、最小量のパフォーマンス影響力. . . . . . . . . . . . . . . . . . . . . . . . . 66 3があるべきです。 ドキュメンテーション要件. . . . . . . . . . . . . . . . . . 67 3.1。 聴かれているかもしれないサービスを特定してください。 . . . . . . . . 67 3.2. ドキュメントサービスはデフォルトとします。 . . . . . . . . . . . . . . . 67 3.3. サービス活性化過程を記録してください。 . . . . . . . . . . 68 3.4. コマンドラインインタフェースを記録してください。 . . . . . . . . . . . . 68 3.5. 'コンソール'というデフォルトコミュニケーションプロフィールは.694を記録しました。 保証要件. . . . . . . . . . . . . . . . . . . . 69 4.1。 IPスタックの発生源を特定してください。 . . . . . . . . . . . . . . 70 4.2. オペレーティングシステムの発生源を特定してください。 . . . . . . . . . . 70 5. セキュリティ問題. . . . . . . . . . . . . . . . . . . 71 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.1。 引用規格. . . . . . . . . . . . . . . . . . 71 6.2。 有益な参照. . . . . . . . . . . . . . . . . 74付録A.要件は.75A.1の輪郭を描きます。 必要最小限は.75A.2の輪郭を描きます。 層3のネットワーク縁のプロフィール. . . . . . . . . . . . . . 78B.承認. . . . . . . . . . . . . . . . . . . . . . . 79作者のアドレスの.80の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 81
Jones Informational [Page 4] RFC 3871 Operational Security Requirements September 2004
操作上の[4ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
1. Introduction
1. 序論
1.1. Goals
1.1. 目標
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ネットワーク(ルータとスイッチ)のインフラストラクチャのための操作上のセキュリティ要件のリストを定義します。 目標は彼らのセキュリティ要件を設備ベンダーに伝える明確で、簡潔な方法をネットワーク・オペレータに提供することです。
1.2. Motivation
1.2. 動機
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]を見てください。
1.3. Scope
1.3. 範囲
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.,
o 名前/時間/ログ/AAAサーバなどのインフラストラクチャホストを含むトラフィックをトランジットでないのにする汎用のホスト
o unmanaged devices,
o デバイスを非管理しました。
o customer managed devices (e.g., firewalls, Intrusion Detection
System, dedicated VPN devices, etc.),
o 顧客はデバイスを管理しました(例えば、ファイアウォール(Intrusion Detection System)はVPNデバイスなどを捧げました)。
o SOHO (Small Office, Home Office) devices (e.g., personal
firewalls, Wireless Access Points, Cable Modems, etc.),
o ソーホー(小さいオフィス、内務省)デバイス(例えば、パーソナルファイアウォール、Wireless Access Points、Cable Modemsなど)
o confidentiality of customer data,
o 顧客データの秘密性
o integrity of customer data,
o 顧客データの保全
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.
これは、最小のプロフィール(そして、他のもの)の要件が適用されているかもしれない間追加要件が彼らのユニークな必要性を説明するために加えられていないことを意味します。
Jones Informational [Page 5] RFC 3871 Operational Security Requirements September 2004
操作上の[5ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
While the examples given are written with IPv4 in mind, most of the requirements are general enough to apply to IPv6.
出された例はIPv4と共に念頭に書かれていますが、要件の大部分はIPv6に適用するほど一般的です。
1.4. Definition of a Secure Network
1.4. 安全なネットワークの定義
For the purposes of this document, a secure network is one in which:
安全なネットワークがこのドキュメントの目的のための、あるコネである、どれ、:
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 ネットワーク・オペレータには、違法なトラフィックに検出して、反応させる必要なツールがあります。
1.5. Intended Audience
1.5. 対象とする訪問者
There are two intended audiences: the network operator who selects, purchases, and operates IP network equipment, and the vendors who create them.
2人の対象とする訪問者がいます: IPネットワーク装置を選択して、購入して、操作するネットワーク・オペレータ、およびそれらを作成するベンダー。
1.6. Format
1.6. 形式
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 例(どのように)
Jones Informational [Page 6] RFC 3871 Operational Security Requirements September 2004
操作上の[6ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
方針と他の要素によって、セキュリティ要件は異なった装置タイプと異なった組織の向こう側に異なるでしょう。 1つの環境における必要な特徴は別のものの要件であるかもしれません。 地方の必要性に従って分類をしなければなりません。
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.
分類を助けるために、Appendix Aは異なったタイプのデバイスのための数個の要件「プロフィール」を定義します。 プロフィールはあるクラスのデバイスに適用される要件の簡潔なリストです。 プロフィールは、それらが地方の環境に適切であるかどうか決定するために本書では再検討されるべきです。
1.7. Intended Use
1.7. 意図している使用
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 高いレベルとして、詳細試験の作成のための指導は計画されています。
1.8. Definitions
1.8. 定義
RFC 2119 Keywords
RFC2119キーワード
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Jones Informational [Page 7] RFC 3871 Operational Security Requirements September 2004
操作上の[7ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
2119年のRFCキーワードの使用は、正しい要件レベル(“MUST"、“SHOULD"、「5月」…)を割り当てるためにはエディタによる試みです。 異なった組織、運用環境、方針、および法的環境が異なった要件レベルを生成することに注意しなければなりません。 オペレータとベンダーは慎重にここ、それら自身の文脈にリストアップされた個々の要件を考えるべきです。 1つのサイズはすべてに合いません。
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")はIPソースアドレスがIANAによってまだ割り当てられていなかったあて先ブロックかRegionalインターネットRegistries(ARIN、RIPE、APNIC…)にあって、すべてのアドレスが個人的であるか特別な使用のためにRFCsによって予約されているパケットです。 [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".
いくつかの要件がCommand線Interface(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を使用するのを含んでいるでしょう。
Jones Informational [Page 8] RFC 3871 Operational Security Requirements September 2004
操作上の[8ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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]、「火星人:」 にせのルーティングエントリーのために間違ったネットワークで転がり込むパケットに適用されたユーモラスな用語。 また「全体でにせ(非登録されたか不適格な)のインターネット・アドレスを持っているパケットのための名前として、また中古でもあります」。 このドキュメントの目的のために、火星人は「現在の推進テーブルのアプリケーションでリターントラフィックを送付者に発送して戻さないソースアドレスを持っているパケット」と定義されます。 「パケットであると偽造されます」はmartiansの共通ソースです。
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.
「バンドで出ている管理」はユーザ/顧客データに使用されるものから別々のチャンネルとインタフェースの上に行われたどんな管理とも定義されます。 例は顧客トラフィックを運ぶのに使用されない専用マネジメント・ネットワークに関連づけられたシリアルコンソールインタフェースかネットワーク・インターフェースを含んでいるでしょう。
Jones Informational [Page 9] RFC 3871 Operational Security Requirements September 2004
操作上の[9ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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
* 1つの上流だけの接続があります。
Jones Informational [Page 10] RFC 3871 Operational Security Requirements September 2004
操作上の[10ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
* 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」か「martians」です。
2. Functional Requirements
2. 機能条件書
The requirements in this section are intended to list testable, functional requirements that are needed to operate devices securely.
このセクションの要件がしっかりとデバイスを操作するのに必要である試験できて、機能的な要件をリストアップすることを意図します。
2.1. Device Management Requirements
2.1. デバイス管理要件
2.1.1. Support Secure Channels For Management
2.1.1. 管理のための安全なチャンネルを支えてください。
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)は与えられた状況に適切です。
Jones Informational [Page 11] RFC 3871 Operational Security Requirements September 2004
操作上の[11ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Warnings.
警告。
None.
なし。
2.2. In-Band Management Requirements
2.2. バンドにおける管理要件
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.
多くの状況がバンドにおける管理が理解できて、使用されている、そして/または、唯一のオプションであるところにあります。 以下の要件はバンドにおける管理がトラフィックであると機密保護する手段を提供することになっています。
2.2.1. Use Cryptographic Algorithms Subject To Open Review
2.2.1. 公開審査を条件として暗号アルゴリズムを使用してください。
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で定義されるように「公開審査」を受けることがあるアルゴリズムを使用するオプションがあるに違いありません。 これらのSHOULD、デフォルトで使用されてください。 デバイスは任意に見直すために開いていないアルゴリズムをサポートするかもしれません。
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
オープンスタンダードと公的に見直されたアルゴリズムネットワーク・オペレータが、必要性を持っているか、または持っていることを望むかもしれないより広範囲の、そして、拡張している公衆/同輩レビューにかけられていない暗号アルゴリズムは未知の弱点か欠点を持っていそうです。
Jones Informational [Page 12] RFC 3871 Operational Security Requirements September 2004
操作上の[12ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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]。 アプリケーションのためのSHA-1[RFC3174]がメッセージ検証を必要とすることのHMAC[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は公開審査必要条件を満たしますが、今日、弱過ぎると考えられて、したがって、推薦されません。
2.2.2. Use Strong Cryptography
2.2.2. 強い暗号を使用してください。
Requirement.
要件。
If cryptography is used to meet the secure management channel
requirements, then the key lengths and algorithms SHOULD be
"strong".
暗号がそうであるなら、安全な管理チャンネル要件、次に、キー長、およびアルゴリズムSHOULDを満たすのにおいて使用されているのは、「強い」です。
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]。 アプリケーションのためのSHA-1[RFC3174]がメッセージ検証を必要とすることのHMAC[RFC2401]。
Jones Informational [Page 13] RFC 3871 Operational Security Requirements September 2004
操作上の[13ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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[シュナイアー]章を見てください。
2.2.3. Use Protocols Subject To Open Review For Management
2.2.3. 管理のための公開審査を条件としてプロトコルを使用してください。
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で定義されるように「公開審査」を受けることがあるプロトコルで使用をサポートしなければなりません。 これらのSHOULD、デフォルトで使用されてください。 デバイスは、論評するために任意に開いていないプロトコルにおける暗号の使用をサポートするかもしれません。
Jones Informational [Page 14] RFC 3871 Operational Security Requirements September 2004
操作上の[14ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
非オープン・プロトコルTheyを使用する願望は、戸外と非オープン・プロトコルの間で広範囲の、そして、拡張している公衆/同輩レビューにかけられていないプロトコルが未知の弱点か欠点を極めて持つべきでありそうですか、トレードオフを評価して、またはインフォームド・チョイスをすることができるべきです。
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.
公開審査が必要ですが、十分でないかもしれないことに注意してください。 オープンに見直されたプロトコルに、それは誤用(または、使用でない)暗号に完全に可能です。
2.2.4. Allow Selection of Cryptographic Parameters
2.2.4. 暗号のパラメタの品揃えを許容してください。
Requirement.
要件。
The device SHOULD allow the operator to select cryptographic
parameters. This SHOULD include key lengths and algorithms.
デバイスSHOULDはオペレータに暗号のパラメタを選択させます。 このSHOULDはキー長とアルゴリズムを含んでいます。
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.
あるアルゴリズムとキー長を使用する暗号は時間内にの1ポイントで「強いのです」が、別のもので「弱い」と考えられるかもしれません。 一定の増加は中でパワーを計算します。ある強さに関する暗号を知らせるのが必要であることで、絶えず時間を短縮します。 弱点はアルゴリズムで発見されるかもしれません。異なったアルゴリズムを選択する能力は、そのような発見に直面して警備を維持するための有益な手段です。
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.
なし。
Jones Informational [Page 15] RFC 3871 Operational Security Requirements September 2004
操作上の[15ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.2.5. Management Functions Should Have Increased Priority
2.2.5. 管理機能は優先権を増強するべきでした。
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.
管理機能SHOULD、非管理トラフィックより高い優先度では、処理されてください。 このSHOULDはイングレス、出口、内部のトランスミッション、および処理を含んでいます。 このSHOULDは少なくとも構成、モニター、構成バックアップ、伐採、時間同期化、認証、およびルーティングに使用されるプロトコルを含んでいます。
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.
100万人の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.
優先順位づけは万能薬ではありません。 ルート設定アップデートパケットは飽和したリンクの向こう側にそれを作らないかもしれません。 この要件は、デバイスが見える範囲の中で管理機能を最優先させるはずであると単に言います(例えば、イングレス、出口、内部のトランジットが処理されて)。 総合的な効果はネットワークが処理しやすいままで残っているのを保証する全体のネットワークの向こう側にこれをするという範囲への、ことになるでしょう。
2.3. Out-of-Band (OoB) Management Requirements
2.3. バンドで出ている(OoB)管理要件
See Section 2.2 for a discussion of the advantages and disadvantages of In-band vs. Out-of-Band management.
利点とIn-バンド対バンドのOut管理の損失の議論に関してセクション2.2を見てください。
Jones Informational [Page 16] RFC 3871 Operational Security Requirements September 2004
操作上の[16ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
These requirements assume two different possible Out-of-Band topologies:
これらの要件は、バンドの2の異なった可能なOutがtopologiesであると仮定します:
o serial line (or equivalent) console connections using a CLI,
o CLIを使用しているシリアル・ライン(または、同等物)コンソール接続
o network interfaces connected to a separate network dedicated to
management.
o ネットワーク・インターフェースは管理に捧げられた別々のネットワークに接続しました。
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.
これらの仮定が成立しても、バンドの外へのバンドにおける要件(例えば、暗号化)インタフェースを適用するために縦深防御の応用として賢明でしょう。
2.3.1. Support a 'Console' Interface
2.3.1. 'コンソール'インタフェースをサポートしてください。
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スタック、そして/または、オペレーティングシステムが扱っていないかもしれませんか(または、彼らの使用を不可能であるか勧められなくする最近発見された功績に被害を受け易いかもしれません)、またはデバイスへの高帯域経路は入手できません)は、管理か構成のためにすぐに、容易にデバイスにアクセスできるのが操作上必要である回があります、ネットワークが入手できないときにさえ不当に構成されます。 そのような状況に、コンソールインタフェースはデバイスを管理して、構成する方法を提供できます。
Jones Informational [Page 17] RFC 3871 Operational Security Requirements September 2004
操作上の[17ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
他のインタフェースを供給しているかもしれない間、上に記載された特性を考えるべきです。 これらの特性を持っていないインタフェースは使いやすさ、統合または採用で挑戦を提示するかもしれません。 これらの領域のどれかの問題には、否定的セキュリティ影響力があるかもしれません、特にすばやくインシデントに応じるのにコンソールを使用しなければならない状況で。
Jones Informational [Page 18] RFC 3871 Operational Security Requirements September 2004
操作上の[18ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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を通してだけ利用可能なパスワード回収機構は、ルータを完全に再構成するためにリモートハッカーに与えるかもしれません。 操作手順はこのドキュメントの範囲を超えていますが、ここで強い注意がコンソールポートへのアクセスを治める方針、手順、アクセス機構、および物理的なセキュリティに与えられるべきであることに注意するのは重要です。
2.3.2. 'Console' Communication Profile Must Support Reset
2.3.2. 'コンソール'というコミュニケーションプロフィールはリセットをサポートしなければなりません。
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.
1つのメソッドは中断をシリアル・ラインに送ることであるかもしれません。
Warnings.
警告。
None.
なし。
2.3.3. 'Console' Requires Minimal Functionality of Attached Devices
2.3.3. 'コンソール'は付属デバイスの最小量の機能性を必要とします。
Requirement.
要件。
The use of the 'console' interface MUST NOT require proprietary
devices, protocol extensions or specific client software.
'コンソール'インタフェースの使用は独占デバイス、プロトコル拡大または特定のクライアントソフトウェアを必要としてはいけません。
Jones Informational [Page 19] RFC 3871 Operational Security Requirements September 2004
操作上の[19ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
2.3.4. 'Console' Supports Fall-back Authentication
2.3.4. 'コンソール'は後退認証をサポートします。
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.
'コンソール'SHOULDは機能的な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
この要件はデバイス(機能性)とセキュリティに対処できることの間のトレードオフを表します。 これを実装するデバイス(例えば、不正アクセスのための裏口)に減少しているセキュリティを供給する多くの方法があります。 ローカルの方針は、「戸外に失敗してください」という確認するために相談されて、ことであるか「失敗するべきです」。
Jones Informational [Page 20] RFC 3871 Operational Security Requirements September 2004
操作上の[20ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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のベースの認証機構の失敗が確かに検出されるのが、重要であり、後退メカニズムは自動的に可能にされます…さもなければ、手段なしでオペレータが認証するのが残されるかもしれません。
2.3.5. Support Separate Management Plane IP Interfaces
2.3.5. 別々の管理飛行機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スタック、および良くて、知られている構成の両方の適切な機能であることによります。
2.3.6. No Forwarding Between Management Plane And Other Interfaces
2.3.6. 管理飛行機と他のインタフェースの間の進めないこと
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あたりの管理飛行機のための(s)であると実装するなら、デバイスは管理飛行機と非管理飛行機インタフェースの間にトラフィックを送ってはいけません。
Jones Informational [Page 21] RFC 3871 Operational Security Requirements September 2004
操作上の[21ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
2.4. Configuration and Management Interface Requirements
2.4. 構成と管理インターフェース要件
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.
Command線Interface(CLI)か同等物がすべての構成と管理機能への完全なアクセスを許さなければなりません。 コンソールの上にサポートされてください。CLI MUST、(セクション2.3の.1と)SHOULDが管理に使用される他のすべてのインタフェースでサポートされるのを見てください。
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])を言っています。 そのような状況は帯域幅ベースのサービス不能攻撃などのセキュリティインシデントの間、しばしば起こります。
Jones Informational [Page 22] RFC 3871 Operational Security Requirements September 2004
操作上の[22ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
2.4.2. 'CLI' Supports Scripting of Configuration
2.4.2. 'CLI'は構成のスクリプティングをサポートします。
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 SHOULDはセクション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.
スクリプトへの能力を高めるコマンド言語のいくつかの特性は以下の通りです。 簡単さ、規則性、および一貫性。 スクリプティングを難しいか不可能にするいくつかの実装は: 「テキストメニュー」スタイルはCLIに基づかない独占であるか正式書類のないプロトコルを使用することで交信する(例えば、UNIXの「呪い」)か一生懸命コード化されたGUIインタフェース(例えば、固有のWindowsかマッキントッシュGUIアプリケーション)を連結します。
Jones Informational [Page 23] RFC 3871 Operational Security Requirements September 2004
操作上の[23ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.4.3. 'CLI' Supports Management Over 'Slow' Links
2.4.3. '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管理インタフェースは複数の回をスクリーンに描き直しています…ゆっくり、… 9600年のビーピーエスで。
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パイプ施設と「grep」コマンドと何か同様のもので実装されるかもしれません。
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| more
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インタフェースを必要とするのが容認できないということであるかもしれません。
Jones Informational [Page 24] RFC 3871 Operational Security Requirements September 2004
操作上の[24ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.4.4. 'CLI' Supports Idle Session Timeout
2.4.4. 'CLI'は活動していないセッションタイムアウトをサポートします。
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.
なし。
2.4.5. Support Software Installation
2.4.5. ソフトウェアがインストールであるとサポートしてください。
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など)だけに頼らなければなりません。 インストール手順SHOULDは、信頼性とデータの完全性に転送を確実にするためにメカニズムをサポートします。
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
* 脆弱性はベンダーによって出荷された基本ソフトウェア(オペレーティングシステムなど)でしばしば発見されます。 しばしば、ベンダーの供給されたソフトウェアへのアップデートでこれらの脆弱性によって提示された危険の緩和を実行できるだけである、(例えば、急いで去ってください。
Jones Informational [Page 25] RFC 3871 Operational Security Requirements September 2004
操作上の[25ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
* また、ハッカー側の悪意のある態度かオペレータ側の意図的でない振舞いが、デバイスの上のソフトウェアが崩壊するか、または消されることを引き起こす場合があったのが想像できます。 これらの状況で、(re)への手段に正しい機能を回復するためにデバイスにソフトウェアをロードさせるのが必要です。
* 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:
デバイスは対向機器からの1セットの新しいオペレーティングシステムコードをロードできるくらいのコマンドとコンフィギュレーション・データをサポートした簡単な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スタックをブートできると仮定して。
Jones Informational [Page 26] RFC 3871 Operational Security Requirements September 2004
操作上の[26ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
2.4.6. Support Remote Configuration Backup
2.4.6. リモート構成バックアップを支えてください。
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.
リモートサーバのセキュリティはこのドキュメントの範囲の外にある穏当な処置で想定されます。
2.4.7. Support Remote Configuration Restore
2.4.7. リモート構成が復元するサポート
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で説明されるように節約された構成を回復する手段を提供しなければなりません。 構成が節約されたとき、操作上の状態にシステムを復旧しなければなりません。
Jones Informational [Page 27] RFC 3871 Operational Security Requirements September 2004
操作上の[27ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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許容されているように、そして回復、完全でないかもしれません。 オペレータは、新しいパスワードを設定しなければならないか、または保存されなかった他の情報を提供しなければならないかもしれません。
2.4.8. Support Text Configuration Files
2.4.8. テキストが構成ファイルであるとサポートしてください。
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構成ファイルは要件を満たすでしょう、ユニコード構成やいかなる他の「原文」の表現であるだろうことのようにも。 消費だけでプログラムで意図する構造化されたバイナリフォーマットは許容できないでしょう。
Jones Informational [Page 28] RFC 3871 Operational Security Requirements September 2004
操作上の[28ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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のベースの構成などの今後のオプションは条件を満たすかもしれません。 これを決定するのは上に記載された正当化に対して評価を必要とするでしょう。
2.5. IP Stack Requirements
2.5. IPスタック要件
2.5.1. Ability to Identify All Listening Services
2.5.1. すべてを特定するサービスを聴く能力
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 ?")
この情報が、デバイスの操作に関連しているセキュリティリスクの徹底的な査定を可能にするのに必要です(例えば、「また、認証、承認、または会計を必要としないで、このプロトコルはデバイスの完全な管理を許しますか?」)。 また、情報は、どんな方法が危険を緩和するために取られるべきであるかを決定するのを助けます。(例えば、「私はこのサービスをオフにするべきですか?」)
Jones Informational [Page 29] RFC 3871 Operational Security Requirements September 2004
操作上の[29ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
2.5.2. Ability to Disable Any and All Services
2.5.2. ありとあらゆるサービスを無効にする能力
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.
なし。
2.5.3. Ability to Control Service Bindings for Listening Services
2.5.3. サービスを聴くためのサービス結合を制御する能力
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
管理トラフィックのソースと目的地として使用する「ループバック」疑似インタフェースを構成するのは、オペレータの中の一般的な習慣です。 これらは物理インターフェースより好まれます。
Jones Informational [Page 30] RFC 3871 Operational Security Requirements September 2004
操作上の[30ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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はデバイスで構成されたあらゆるアドレスを聞いているというわけではありません。 「受信してください」か「ループバック」ACLs(すべてのインタフェースのデバイス自体のために運命づけられたそのフィルタトラフィック)が、時々同様の効果がグローバルなフィルタの使用によって達成されるかもしれないと呼びました。
Warnings.
警告。
None.
なし。
2.5.4. Ability to Control Service Source Addresses
2.5.4. サービスソースアドレスを制御する能力
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.
デバイスはユーザがすべての外国行きの接続に使用されるソースアドレスかデバイスから発するトランスミッションを指定できる手段を提供しなければなりません。 それ、SHOULD、独自にそれぞれのタイプの外国行きの接続かトランスミッションにソースアドレスを指定するのにおいて、可能であってください。 ソースアドレスをデバイスへの地方のインタフェース(ループバックを含んでいる)に割り当てられるアドレスに制限しなければなりません。
Jones Informational [Page 31] RFC 3871 Operational Security Requirements September 2004
操作上の[31ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
これで、接続かトランスミッションを受ける遠隔装置は1として認証の手段をフィルターにかけるソースを使用できます。 例えば、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.
オペレータはすべてのループバックが番号付であるアドレスの異なったブロックを割り当てるかもしれません。 ソースとしてそれらのループバックアドレスを使用するためにNTPとsyslogを構成できます、SNMPとBGPは特定の物理インターフェースアドレスを使用するために構成されるかもしれませんが。 これは、同輩/サーバに接続する権限のない試みを拒絶することにおける一方通行としてのソースアドレスに基づいてフィルターにかけるのを容易にするでしょう。
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).
選ばれたアドレスが送受信デバイスの間で発送可能であることを保証するために注意するべきである、(例えば、SSHに10.1に関するループバックアドレスを使用するように設定する、.1、ルータとすべてに間意図している目的地が問題を引き起こす場合があった発送されない.1)
Note that some protocols, such as SCTP [RFC3309], can use more
than one IP address as the endpoint of a single connection.
SCTPなどのいくつかのプロトコル[RFC3309]が単独結合の終点として1つ以上の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]が「不安定メカニズム」にアドレスベースの認証について記載することに注意してください。 アドレスは取り替えるべきであるか、またはどこでも、可能であるところで他のメカニズムで増大させる認証を基礎づけました。
2.5.5. Support Automatic Anti-spoofing for Single-Homed Networks
2.5.5. 自動反スプーフィングをサポートする、シングル家へ帰る、ネットワーク
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)を現在の推進テーブルのアプリケーションが同じインタフェースを通してリターントラフィックを発送して戻さないところに下げるためにオプションを提供しなければなりません。 このオプションはダイナミックルーティングとダイナミックに割り当てられたアドレスがあるとき働かなければなりません。
Jones Informational [Page 32] RFC 3871 Operational Security Requirements September 2004
操作上の[32ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Justification.
正当化。
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
[RFC1812], and [RFC2827].
セクション5.3 セクション3の[RFC1918]、.7、および5.3を見てください。.8[RFC1812]、および[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.
この要件が成立するだけである、シングル家へ帰る、ネットワーク。 または、簡単な推進テーブルチェックが、より複雑なシナリオで十分でないことに注意してください、マルチ、家へ帰り、すなわち、トラフィックが非対称であるかもしれないところのマルチ付属しているネットワーク。 これらの場合では、Feasible Path RPFなどの、より大規模なチェックは非常に役に立つかもしれません。
2.5.6. Support Automatic Discarding Of Bogons and Martians
2.5.6. Bogonsと火星人を自動捨てることをサポートしてください。
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)と"martians"(セクション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].
セクション5.3 セクション3の[RFC1918]、.7、および5.3を見てください。.8[RFC1812]、および[RFC2827。]
Jones Informational [Page 33] RFC 3871 Operational Security Requirements September 2004
操作上の[33ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
この要件が成立するだけである、シングル家へ帰る、ネットワーク。 または、簡単な推進テーブルチェックが、より複雑なシナリオで十分でないことに注意してください、マルチ、家へ帰り、すなわち、トラフィックが非対称であるかもしれないところのマルチ付属しているネットワーク。 これらの場合では、Feasible Path RPFなどの、より大規模なチェックは非常に役に立つかもしれません。
2.5.7. Support Counters For Dropped Packets
2.5.7. 下げられたパケットのためにカウンタをサポートしてください。
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に従って、偽造しているパケットの1インタフェースあたりのカウントは低下しました。
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.
なし。
Jones Informational [Page 34] RFC 3871 Operational Security Requirements September 2004
操作上の[34ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.6. Rate Limiting Requirements
2.6. 要件を制限して、評価してください。
2.6.1. Support Rate Limiting
2.6.1. 支持率制限
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を含まなければなりません、そして、SHOULDはどんなプロトコルも含んでいます。
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トラフィックでウェブサーバーをあふれさせると決めるネットワーク利用者のある要素に不人気になる会社へのデータセンターにスペースを提供すると仮定してください。 そのような状況で、データセンターの境界ルータでレートフィルタの本国行きのICMPトラフィックにできるのは役に立つでしょう。 反対側の上では、次に、TCPポート1433の上でトラフィックを吐き始めるように被害を受け易いデータベースサーバーを感染させる新しいワームがリリースされると仮定してください。感染したサーバのインタフェースがシステムとネットワークとして速くできるので、無作為に送付先アドレスを目指しました。 データセンターには感染して、同時に多量のトラフィックを送る多くの被害を受け易いサーバがあって、その結果、すべてのアウトバウンドリンクが飽和していると、さらに仮定してください。 この要件の実装、他の正統の顧客/トラフィックのために攻撃に応じて、サービスレベルを維持するためにネットワーク・オペレータが、限界が本国行きの、そして/または、外国行きのTCP1433トラフィック(ことによると1秒あたり0パケット/バイトのレートへの)であると評定するのを許容するでしょう。
Warnings.
警告。
None.
なし。
Jones Informational [Page 35] RFC 3871 Operational Security Requirements September 2004
操作上の[35ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.6.2. Support Directional Application Of Rate Limiting Per Interface
2.6.2. 1インタフェースあたりのレート制限の方向のアプリケーションをサポートしてください。
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洪水が縁のルータの指示されたa独身の顧客であるなら、その顧客インタフェースだけのレート限界の外国行きのICMPに適切であるかもしれません。
Warnings.
警告。
None.
なし。
2.6.3. Support Rate Limiting Based on State
2.6.3. 状態に基づく支持率制限
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コントロールフラグビットに基づく限界を評定できなければなりません。 デバイスSHOULDはプロトコルの正常処理が状態について議定書の中で述べるためにデバイスアクセスを与える他のstatefulプロトコルのレート制限をサポートします。
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.
なし。
Jones Informational [Page 36] RFC 3871 Operational Security Requirements September 2004
操作上の[36ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.7. Basic Filtering Capabilities
2.7. 基本的なフィルタリング能力
2.7.1. Ability to Filter Traffic
2.7.1. トラフィックをフィルターにかける能力
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.
なし。
2.7.2. Ability to Filter Traffic TO the Device
2.7.2. デバイスにトラフィックをフィルターにかける能力
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だけを可能にするフィルタを含むかもしれません。
Jones Informational [Page 37] RFC 3871 Operational Security Requirements September 2004
操作上の[37ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Warnings.
警告。
None.
なし。
2.7.3. Ability to Filter Traffic THROUGH the Device
2.7.3. デバイスを通してトラフィックをフィルターにかける能力
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.
この必要条件を満たす1つの簡単で一般的な方法は各インタフェースへの本国行きの、そして/または、各インタフェースからの外国行きのトラフィックをフィルターにかける能力を提供することです。 [RFC2827]で説明されるイングレスフィルタリングはこの能力の使用に関する1つの例を提供します。
Warnings.
警告。
None.
なし。
2.7.4. Ability to Filter Without Significant Performance Degradation
2.7.4. 重要なパフォーマンス退行なしでフィルターにかける能力
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).
デバイスが同時のすべてのインタフェース(可能な最大数までの)と複数の1インタフェースあたりのフィルタで状態がないパケットフィルタを適用できなければならない、(例えば、本国行きと外国行き、)
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.
必要であるときに、これはフィルタリングの実装を可能にします。 フィルタリングが退行を引き起こすという範囲には、適切な政策を実施するフィルタを適用するのが可能でないかもしれません。
Jones Informational [Page 38] RFC 3871 Operational Security Requirements September 2004
操作上の[38ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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].
テストデータが影響を与えるのをフィルター性能に示すRepeatableはこの要件で順応を評価する際に非常に役に立つでしょう。 テストがパケットサイズ、パケットレートのような情報を含むべきであるので、インタフェースの数は(ソース/目的地)をテストしました、インタフェースのタイプ、経路指定テーブルサイズ、使用中のプロトコル、ルーティングアップデートの頻度などを発送して [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個のヘッダーをフィルターにかけて、この要件がstatefulフィルタリングを扱わないか、または他の、より高度なタイプについてそれをフィルターにかけるのはある運用環境で重要であるかもしれません。
2.7.5. Support Route Filtering
2.7.5. サポートルートフィルタリング
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].
[RFC2196]の[RFC3013]とセクション3.2を見てください。
Examples.
例。
Operators may wish to ignore advertisements for routes to
addresses allocated for private internets. See eBGP.
オペレータは個人的なインターネットのために割り当てられたアドレスへのルートに広告を無視したがっているかもしれません。 eBGPを見てください。
Warnings.
警告。
None.
なし。
Jones Informational [Page 39] RFC 3871 Operational Security Requirements September 2004
操作上の[39ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.7.6. Ability to Specify Filter Actions
2.7.6. フィルタ動作を指定する能力
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を移植してください。 他のすべてのアドレスからのポート22トラフィックは送付者へのICMPメッセージをもたらします。 わずかにパラノイアであることのそれらのために、あなたは、「廃棄物」トラフィックの代わりに*が返送される何も権限のないアドレスからソースにその*である結果で「下げないこと」を選ぶかもしれません。
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.
セキュリティ用語で静かに通告を送らないでトラフィックを下げるのが、正しい動作であるかもしれない間、操作上の含意に対して考慮を払うべきです。 潜在的な問題の考慮のための[RFC3360]が送付の不適当なTCP Resetsによって引き起こされるのを見てください。
2.7.7. Ability to Log Filter Actions
2.7.7. フィルタ動作を登録する能力
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),
* ソースと仕向港(プロトコルに適切であるなら)
Jones Informational [Page 40] RFC 3871 Operational Security Requirements September 2004
操作上の[40ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
* 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.
なし。
2.8. Packet Filtering Criteria
2.8. パケットフィルタリング評価基準
2.8.1. Ability to Filter on Protocols
2.8.1. プロトコルでフィルターにかける能力
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トラフィックで犠牲者をあふれさせる能力に基づいています。 そのような攻撃の効果を緩和する1つの迅速な方法(明白ないくつかの有害な副作用がある)は犠牲者に向かって率いられたすべてのICMPトラフィックを下げることです。
Warnings.
警告。
None.
なし。
Jones Informational [Page 41] RFC 3871 Operational Security Requirements September 2004
操作上の[41ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.8.2. Ability to Filter on Addresses
2.8.2. アドレスでフィルターにかける能力
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アドレスの流れかClassless Inter-ドメインルート設定(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].
フィルターにかけながら基づくアドレスの使用に関する1つの例は[RFC2827]あたりイングレスがフィルタリングであると実装することです。
Warnings.
警告。
None.
なし。
2.8.3. Ability to Filter on Protocol Header Fields
2.8.3. プロトコルでヘッダーフィールドをフィルターにかける能力
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のためにプロトコルヘッダーのどんな部分の値にも基づくフィルタリングをサポートしなければなりません。 それ、SHOULDは層3と4でサポートされた他のすべてのプロトコルのフィルタリングをサポートします。 それは、より高い平らなプロトコルのヘッダーに基づくフィルタリングをサポートするかもしれません。 それ、SHOULD、ビットオフセット/長さ/数値(例えば、72: 8 = 1)よりむしろ名前(例えば、「プロトコル=ICMP」)の分野を指定するのにおいて、可能であってください。
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
この要件が、それがTCPかUDPポートナンバーに基づくフィルタ、SYNなどのTCP旗、ACKとRSTビットに可能であることを含意して、ICMPは分野をタイプして、コード化します。 1つの一般的な例は「本国行き」のTCP接続試みを拒絶する(TCP、SYNがはっきりと噛み付かれたセット+ACKに噛み付いたか、またはSYNははっきりとセット+ACK、FIN、およびRSTビットに噛み付きました)ことです。 別のコモン
Jones Informational [Page 42] RFC 3871 Operational Security Requirements September 2004
操作上の[42ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
例はどんなサービスが/でネットワークから許されているかを制御する能力です。 ポート80(HTTP)と443(HTTPS)でウェブサーバーをホスティングするネットワークに本国行きの接続を許すだけが望ましいかもしれません。
Warnings.
警告。
None.
なし。
2.8.4. Ability to Filter Inbound and Outbound
2.8.4. フィルタ本国行きと外国行きへの能力
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.
なし。
2.9. Packet Filtering Counter Requirements
2.9. パケットフィルタリングカウンタ要件
2.9.1. Ability to Accurately Count Filter Hits
2.9.1. 正確にフィルタヒットを数える能力
Requirement.
要件。
The device MUST supply a facility for accurately counting all
filter hits.
デバイスは正確にすべてのフィルタヒットを数えるのに施設を供給しなければなりません。
Jones Informational [Page 43] RFC 3871 Operational Security Requirements September 2004
操作上の[43ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
例えば、ISPネットワーク道具反スプーフィング出口が、縁のルータのインタフェースでサポートがシングル家へ帰ったのをフィルターにかけるのが([RFC2827]を見ます)ネットワークを引き抜くと仮定してください。 カウンタは、ISPが多くの偽造しているパケットが送られるケースを検出するのを可能にするかもしれません。 これが、顧客が潜在的に悪意がある行為(ことによるとISP Acceptable Use Policyを違反した)を実行しているのを示すかもしれないか、ネットワークにはいる顧客の上のそのシステムがハッカーによって「所有され」て、存在である、(誤、)、攻撃に着手するのにおいて、使用されています。
Warnings.
警告。
None.
なし。
2.9.2. Ability to Display Filter Counters
2.9.2. フィルタカウンタを表示する能力
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つのインタフェースがあるルータがあると仮定してください。 1つはルートをインターネットに提供するISPへのアップリンクです。 他の3は、内部のネットワークを切り離すために接続します。 内部のネットワークの1つのホストがハッカーによって感染されて、にせのソースアドレスと共にトラフィックを送ると仮定してください。 そのような状況で、それぞれの内部のインタフェースにイングレスフィルタを付けるのは望ましいかもしれません。 フィルタが適所にいったんあると、にせのパケットの源(本国行きのインタフェース)を決定するためにカウンタを調べることができます。
Warnings.
警告。
None.
なし。
Jones Informational [Page 44] RFC 3871 Operational Security Requirements September 2004
操作上の[44ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.9.3. Ability to Display Filter Counters per Rule
2.9.3. 1規則あたりのフィルタカウンタを表示する能力
Requirement.
要件。
The device MUST provide a mechanism to display filter counters per
rule.
デバイスは、1規則あたりのフィルタカウンタを表示するためにメカニズムを提供しなければなりません。
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.
トラフィックのままですべて残りながら2つの規則、すべてのSSHが取引するある可能にすること(tcp/22)および第2低下を持っているフィルタが定義されたと仮定してください。 3つのパケットがフィルタが適用されているポイント、22、他のものを異なったポートに移植して、次に統治する反対のディスプレイが、許可証tcp/22に合っている1つのパケットを示しているべきである1、および2パケットマッチングで/に向けられるかどうか、すべての他のもの規則を否定してください。
Warnings.
警告。
None.
なし。
2.9.4. Ability to Display Filter Counters per Filter Application
2.9.4. フィルタアプリケーションあたりのフィルタカウンタを表示する能力
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つの方法はカウンター・ディスプレイメカニズムにフィルタが付けられたインタフェース(または、他の実体)を示させるだろうことです、フィルタのための名前(または、他の指示子)と共に。 例えば、aフィルタ名前付です。
Jones Informational [Page 45] RFC 3871 Operational Security Requirements September 2004
操作上の[45ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
"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 ..."
2つの適用された異なった「デスクトップ_外国行き」のインタフェースとたとえば、「ethernet0"と「ethernet1"、ディスプレイはethernet1で「'ethernet0」の外国行きのフィルタ'デスクトップ_のマッチ、および「フィルタのマッチ'デスクトップ_外国行きであること'のように何かを示すべきです」。
Warnings.
警告。
None.
なし。
2.9.5. Ability to Reset Filter Counters
2.9.5. フィルタカウンタをリセットする能力
Requirement.
要件。
It MUST be possible to reset counters to zero on a per filter
basis.
フィルタ基礎あたりのaにゼロにカウンタをリセットするのは可能であるに違いありません。
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.
フィルタカウンタが新しいワームに感染している内部のホストを検出するのに使用されていると仮定してください。 いったんすべての感染宿主がきれいにされたと信じられていて、ワームが取り外されると、次のステップはそれについて確かめることでしょうに。 そうする1つの方法はワームを暗示したトラフィックがやんだならゼロに合わせて、見るフィルタカウンタをリセットするだろうことです。
Warnings.
警告。
None.
なし。
Jones Informational [Page 46] RFC 3871 Operational Security Requirements September 2004
操作上の[46ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.9.6. Filter Counters Must Be Accurate
2.9.6. フィルタカウンタは正確でなければなりません。
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.
フィルタカウンタは正確でなければなりません。 彼らは最後のカウンタリセット以来の合っているパケットの実数を反映しなければなりません。 フィルタカウンタはオーバフローとSHOULDなしで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.
なし。
2.10. Other Packet Filtering Requirements
2.10. 他のパケットフィルタリング要件
2.10.1. Ability to Specify Filter Log Granularity
2.10.1. フィルタログ粒状を指定する能力
Requirement.
要件。
It MUST be possible to enable/disable logging on a per rule basis.
規則基礎あたりのaにログオンして、それは可能にするか、または無効にするのにおいて可能であるに違いありません。
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を否定する規則のマッチだけがログメッセージを生成するはずであると指定するのは可能であるべきです。
Jones Informational [Page 47] RFC 3871 Operational Security Requirements September 2004
操作上の[47ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Warnings.
警告。
None.
なし。
2.11. Event Logging Requirements
2.11. イベント伐採要件
2.11.1. Logging Facility Uses Protocols Subject To Open Review
2.11.1. 開くためになることがあるプロトコルが見直す伐採施設用途
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].
この要件はsyslog[RFC3164]の1つ以上、信頼できる配信があるsyslog[RFC3195]、TACACS+[RFC1492]またはRADIUS[RFC2865]の使用で満たされるかもしれません。
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]を実装すると考えてください。
Jones Informational [Page 48] RFC 3871 Operational Security Requirements September 2004
操作上の[48ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.11.2. Logs Sent To Remote Servers
2.11.2. リモートサーバに送られたログ
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].
この要件は1つか、より多くの使用で満たされるかもしれません: syslog[RFC3164]、信頼できる配信があるsyslog[RFC3195]、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リソースを競争するかもしれません。
2.11.3. Ability to Select Reliable Delivery
2.11.3. 信頼できる配信を選択する能力
Requirement.
要件。
It SHOULD be possible to select reliable delivery of log messages.
それはログの選んだ信頼できる配信へ通信しますSHOULDが可能である。
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.
信頼できるsyslog配送に関する1つの例が[RFC3195]で定義されます。 プロトコルは標準化されていませんが、Syslog-ngは別の例を提供します。
Jones Informational [Page 49] RFC 3871 Operational Security Requirements September 2004
操作上の[49ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Warnings.
警告。
None.
なし。
2.11.4. Ability to Log Locally
2.11.4. 局所的に登録する能力
Requirement.
要件。
It SHOULD be possible to log locally on the device itself. Local
logging SHOULD be written to non-volatile storage.
それ、SHOULD、局所的にデバイス自体にログオンするのにおいて、可能であってください。 書かれていて、非揮発性記憶装置にSHOULDを登録するローカル。
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.
デバイスに接続されると情報を見るのに、地方の伐採は重要です。 リモート伐採が失敗するといけないので、それはログデータのバックアップを提供します。 それは対向機器からことによると大きいセットのログを分類する必要はなくて1台のデバイスに関連しているログを見る方法を提供します。
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).
地方の伐採に関する1つの例がリモートログサーバに送られたメッセージのコピーを受けるメモリ・バッファでしょう。別の例はローカルのsyslogサーバであるかもしれません(デバイスを仮定すると、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.
デバイスにおけるストレージは制限されるかもしれません。 伐採の高いボリュームはすぐに利用可能なストレージをいっぱいにするかもしれません、その場合、2つのオプションがあります: 新しいログが古いログ(ことによると円形のメモリ・バッファかログファイル回転の使用を通した)を上書きするか、または伐採は止まります。
2.11.5. Ability to Maintain Accurate System Time
2.11.5. 正確なシステム時間を維持する能力
Requirement.
要件。
The device MUST maintain accurate, "high resolution" (see
definition in Section 1.8) system time.
デバイスは正確な「高画質」(セクション1.8との定義を見る)システム時間を維持しなければなりません。
Jones Informational [Page 50] RFC 3871 Operational Security Requirements September 2004
操作上の[50ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
この要件はNetwork Timeがプロトコル(NTP)、Simple Network Timeプロトコル(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サーバなどの)にそれを定期的にチェックして、連動させない場合、システム時に当てにするべきではありません。 また、ネットワーク時間同期化が使用されていて、暗号の認証が使用されていない場合攻撃者が時計を操作できるかもしれないことに注意してください。
2.11.6. Display Timezone And UTC Offset
2.11.6. ディスプレイタイムゾーンとUTCは相殺します。
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.
ボブはUTC-3であるニューファンドランド(カナダ)にいます: 30。 アリスはインディアナ(米国)のどこかにいます。 インディアナのいくつかの地域が他のものが切り替わっていない間、日光貯蓄時間に切り替わります。 ボブのネットワークのユーザはアリスのネットワークでユーザを攻撃します。 両方がローカルのタイムゾーンがあるログを使用しています、そして、UTCのしるしは全く相殺されませんでした。 これらのログを関連させるのは、難しくて、誤り傾向があるようになるでしょう。 タイムゾーン、または、より良いUTCオフセットを含んでいると、これらの困難は排除されます。
Warnings.
警告。
None.
なし。
Jones Informational [Page 51] RFC 3871 Operational Security Requirements September 2004
操作上の[51ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.11.7. Default Timezone Should Be UTC
2.11.7. デフォルトタイムゾーンはUTCであるべきです。
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.
デフォルトタイムゾーン、ディスプレイとSHOULDを登録するための、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.
なし。
2.11.8. Logs Must Be Timestamped
2.11.8. ログはTimestampedであるに違いありません。
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.
デフォルトで、デバイスはすべてのログが通信させるタイムスタンプがそうしなければなりません。 タイムスタンプは1秒以下に正確でなければなりません。 タイムスタンプはタイムゾーンを含まなければなりません。 タイムスタンプの世代を無効にするメカニズムがあるかもしれません。
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メッセージにタイムスタンプを書くことによって、満たされるかもしれません。
Jones Informational [Page 52] RFC 3871 Operational Security Requirements September 2004
操作上の[52ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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は等しい都合のよくて、他のものです。
2.11.9. Logs Contain Untranslated IP Addresses
2.11.9. ログはUntranslated IPアドレスを含んでいます。
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を使用することで再選任されるかもしれません。 そのような場合この要件によって提供された個々の責任は弱いです。 ログで正確な時間を過すと、アドレスの使用が個人に関連できるという可能性は増強されます。
Jones Informational [Page 53] RFC 3871 Operational Security Requirements September 2004
操作上の[53ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
* 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.
* ネットワークトポロジーは変化するかもしれません。 ダイナミックなアドレス課題がないときでさえ、ネットワークtopologiesとアドレスブロック課題は変化します。 1カ月前の攻撃に関するログはどのホスト、ネットワークまたは組織が当時、問題のシステムを所有したか正確なしるしを与えないかもしれません。
2.11.10. Logs Contain Records Of Security Events
2.11.10. ログはセキュリティイベントに関する記録を含んでいます。
Requirement.
要件。
The device MUST be able to send a record of at least the following
events:
デバイスは少なくとも以下のイベントに関する記録を送ることができなければなりません:
* authentication successes,
* 認証成功
* authentication failures,
* 認証失敗
* session Termination,
* セッションTermination
* authorization changes,
* 承認は変化します。
* configuration changes,
* 構成は変化します。
* device status changes.
* デバイス状態は変化します。
The device SHOULD be able to send a record of all other security
related events.
デバイスSHOULD、すべての他のセキュリティ関連するイベントに関する記録を送ることができてください。
Justification.
正当化。
This is important because it supports individual accountability.
See section 4.5.4.4 of [RFC2196].
個々の責任をサポートするので、これは重要です。 セクション4.5を見てください。.4 .4[RFC2196。]
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.
ユーザ活動を登録するか、またはモニターするとき、プライバシーか法的な問題があるかもしれないことに注意してください。
Jones Informational [Page 54] RFC 3871 Operational Security Requirements September 2004
操作上の[54ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.11.11. Logs Do Not Contain Passwords
2.11.11. ログはパスワードを含んでいません。
Requirement.
要件。
Passwords SHOULD be excluded from all audit records, including
records of successful or failed authentication attempts.
パスワードSHOULDがすべての監査記録から除かれて、包含はうまくいっているか失敗した認証試みを記録します。
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].
アクセスコントロールと承認要件は会計帳簿(ログ)と承認データベース(パスワード)のために異なります。 伐採パスワードは個人へのログへのアクセスによる不正アクセスを承諾するかもしれません。 失敗したパスワードを登録すると、ヒントは実際のパスワードに関して与えられるかもしれません。 セクション4.5を見てください。.4 .4[RFC2196。]
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.
状況がパスワードを登録するのが適切であるか、または必要であるところにあるかもしれません。
2.12. Authentication, Authorization, and Accounting (AAA) Requirements
2.12. 認証、承認、および会計(AAA)要件
2.12.1. Authenticate All User Access
2.12.1. すべてのユーザアクセスを認証してください。
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.
なし。
Jones Informational [Page 55] RFC 3871 Operational Security Requirements September 2004
操作上の[55ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.12.2. Support Authentication of Individual Users
2.12.2. 個々のユーザのサポート認証
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.12.15のセクション2.4.5か回復であるとサポートするためにリラックスするかもしれません。
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.
これは、個々のユーザをサポートするメカニズムが存在しているのを単に必要とします。 また、しかし、方針(例えば、険しい共有されたグループアカウント)と実施がこのドキュメントの範囲を超えて必要です。
2.12.3. Support Simultaneous Connections
2.12.3. サポート同時接続
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.
これで、複数人は同時に、認可された管理機能を実行できます。 また、これは、権限のないユーザによる試みられた接続が自動的に認定ユーザを締め出さないことを意味します。
Jones Informational [Page 56] RFC 3871 Operational Security Requirements September 2004
操作上の[56ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Examples.
例。
None.
なし。
Warnings.
警告。
None.
なし。
2.12.4. Ability to Disable All Local Accounts
2.12.4. すべてのローカルのアカウントを無効にする能力
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.
ローカルのアカウントは、ユーザー認証に必要なすべての情報がデバイスにどこに保存されるかを1つと定義しました。
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.
なし。
2.12.5. Support Centralized User Authentication Methods
2.12.5. サポートはユーザー認証メソッドを集結しました。
Requirement.
要件。
The device MUST support a method of centralized authentication of
all user access via standard authentication protocols.
デバイスは標準の認証プロトコルですべてのユーザアクセスの集結された認証のメソッドをサポートしなければなりません。
Jones Informational [Page 57] RFC 3871 Operational Security Requirements September 2004
操作上の[57ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
2.12.6. Support Local User Authentication Method
2.12.6. ローカルユーザー認証がメソッドであるとサポートしてください。
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).
デバイスSHOULDは、地方の認証がメソッドであるとサポートします。 実装されるなら、メソッドは、デバイス(リモートAAAサーバなどの)に何も外部であることのもので相互作用を必要としてはいけなくて、セクション2.3.1('コンソール'Interfaceをサポートする)とセクション2.12.7に関連して利かなければなりません(Authentication MethodsのOrderのConfigurationをサポートしてください)。
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つの方法を提供します。
Jones Informational [Page 58] RFC 3871 Operational Security Requirements September 2004
操作上の[58ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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のネットワークデバイス手段に例えばローカルのユーザ名とパスワードを保存させると、サーバは集中しました。(それは、潜在的ポイントの失敗をサーバの数に減少させて、保護取り組み(システム硬化剤、監査など)が大部分のいくつかのサーバに焦点を合わせられるのを許容するでしょう)。
2.12.7. Support Configuration of Order of Authentication Methods
2.12.7. 認証方法の注文のサポート構成
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.
デバイスはサポートしている認証方法が試みられるオーダーを構成する能力をサポートしなければなりません。 認証SHOULDは「閉じられた状態で失敗します」、すなわち、記載された認証方法のいずれも成功しないなら、アクセスが拒絶されるべきです。
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.
なし。
2.12.8. Ability To Authenticate Without Plaintext Passwords
2.12.8. 平文パスワードなしで認証する能力
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.
デバイスはネットワークの向こう側に認証情報の伝達を必要とするすべての場合における、平文パスワードの伝達を必要としないメカニズムをサポートしなければなりません。
Jones Informational [Page 59] RFC 3871 Operational Security Requirements September 2004
操作上の[59ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
Justification.
正当化。
Plaintext passwords can be easily observed using packet sniffers
on shared networks. See [RFC1704] and [RFC3631] for a through
discussion.
共用回線網のパケットスニッファーを使用しているのを容易に平文パスワードを観測できます。 aのために議論で[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.
なし。
2.12.9. No Default Passwords
2.12.9. デフォルトパスワードがありません。
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.
様々なデバイスのためのデフォルトパスワードのリストは多数のウェブサイトで容易に利用可能です。
2.12.10. Passwords Must Be Explicitly Configured Prior To Use
2.12.10. 使用の前に明らかにパスワードを構成しなければなりません。
Requirement.
要件。
The device MUST require the operator to explicitly configure
"passwords" prior to use.
デバイスは、オペレータが使用の前に明らかに「パスワード」を構成するのを必要としなければなりません。
Jones Informational [Page 60] RFC 3871 Operational Security Requirements September 2004
操作上の[60ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
コンソールポートがデバイスには管理とデフォルトの管理アカウントのためについて来ると仮定してください。 Default Passwordsがないのに伴うこの要件は、パスワードが全く構成されていなく管理アカウントが来るべきであると言います。 この必要条件を満たす1つの方法はデバイスにデバイスが初めて構成されるときオペレータが管理アカウントのために対話の一部としてパスワードを選ぶのを必要とさせるだろうことです。
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.
このデバイスが、オペレータがパスワードを設定するのを必要としている間、それは、それらが同じ容易に推測されたパスワードで何百台ものデバイスを構成するスクリプトを使用などなどのことをするのを防ぎません。
2.12.11. Ability to Define Privilege Levels
2.12.11. 特権レベルを定義する能力
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あたりのユーザに割り当てることができる「特権レベル」にそれらを配属するのは可能であるに違いありません。 少なくとも3つの可能な特権レベルがあるに違いありません。
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
力のインクルード「ユーザ」という特権レベルに関する制限されたa、設定していた状態で定義されたユーザへのどれがPPPかtelnetセッションの開始、デバイス構成と操作上の統計へのリード・オンリー・アクセスを許容する「書き込み禁止」を許容するだけであるか、そして、すべての構成可能なパラメタへのアップデートアクセスを許す「根/「スーパー-ユーザ」/管理者」、およびアップデートを許す「オペレータ」という例
Jones Informational [Page 61] RFC 3871 Operational Security Requirements September 2004
操作上の[61ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
parameters. Note that privilege levels may be defined locally on
the device or on centralized authentication servers.
パラメタ。 特権レベルがデバイスの上、または、集結された認証サーバの上で局所的に定義されるかもしれないことに注意してください。
Warnings.
警告。
None.
なし。
2.12.12. Ability to Assign Privilege Levels to Users
2.12.12. 特権レベルをユーザに割り当てる能力
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が使用されているなら、使用できるユーザのRADIUSプロフィールに属性が、ある特権レベルにIDを写像するように設定されるかもしれません。
Warnings.
警告。
None.
なし。
2.12.13. Default Privilege Level Must Be 'None'
2.12.13. デフォルト特権レベルは'なにも'であるに違いありません。
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.
デフォルト特権レベルSHOULD NOTは管理か構成機能へのどんなアクセスも許します。 それはユーザレベル機能(例えば、始めのPPPかtelnet)へのアクセスを許すかもしれません。 それはデフォルトとしてレベルに特権を与えさせますSHOULDがa案配に異なった状態で可能である。 この要件は、セクション2.4あたりのシステムインストールを.5か認可されたアクセスについてセクション2.12.15あたり回復してサポートするためにリラックスするかもしれません。
Jones Informational [Page 62] RFC 3871 Operational Security Requirements September 2004
操作上の[62ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
力のインクルード「ユーザ」という特権レベルに関する制限されたaへのどれが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、そして/または、構成がどうにか不正になったなら、物理的なアクセスの認可された個人は、「根」にインストールを実行するためにアクセスを平らにさせる必要があるかもしれません。
2.12.14. Change in Privilege Levels Requires Re-Authentication
2.12.14. 特権レベルにおける変化は再認証を必要とします。
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.
なし。
Jones Informational [Page 63] RFC 3871 Operational Security Requirements September 2004
操作上の[63ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.12.15. Support Recovery Of Privileged Access
2.12.15. 特権的アクセスのサポート回復
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における警告を見てください('コンソール'Interfaceをサポートしてください)。
Jones Informational [Page 64] RFC 3871 Operational Security Requirements September 2004
操作上の[64ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
2.13. Layer 2 Devices Must Meet Higher Layer Requirements
2.13. 層2のデバイスは、より高い層の必要条件を満たさなければなりません。
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.
デバイスが層に依存する層2のサービスに3つ以上のサービスを提供するなら、層において、または、層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.
対向機器が層3のコミュニケーションを使用している状態で、層2の切り換えに必要であるシグナリングプロトコルは情報交換するかもしれません。 そのような場合、デバイスは3施設を安全な層に供給しなければなりません。 また、より高い層の能力(たとえば、SSHかSNMP)が層の2デバイスを管理するのに使用されるなら、要件の残りは本書ではそれらの能力に適用されます。
Warnings.
警告。
None.
なし。
2.14. Security Features Must Not Cause Operational Problems
2.14. セキュリティ機能は運転上の問題を引き起こしてはいけません。
Requirement.
要件。
The use of security features specified by the requirements in this
document SHOULD NOT cause severe operational problems.
このドキュメントSHOULD NOTで要件によって指定されたセキュリティ機能の使用は厳しい運転上の問題を引き起こします。
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.
* データは無くなっています。
Jones Informational [Page 65] RFC 3871 Operational Security Requirements September 2004
操作上の[65ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
* 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の損失はどうですか? また、リンクの総容積などの避けられない物理的な制限があるかもしれないことに注意されるべきです。
2.15. Security Features Should Have Minimal Performance Impact
2.15. セキュリティ機能には、最小量のパフォーマンス影響力があるべきです。
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).
セキュリティ機能は要件で本書ではSHOULDを指定しました。性能の最小量の影響で、実装されます。 このドキュメントの他のセクションは異なった性能要件(例えば、“MUST"s)を指定するかもしれません。
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.
性能が特別の心配である要件は: フィルターにかけることの、そして、レートを制限するカウンタ、伐採、および反スプーフィング。
Jones Informational [Page 66] RFC 3871 Operational Security Requirements September 2004
操作上の[66ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
3. Documentation Requirements
3. ドキュメンテーション要件
The requirements in this section are intended to list information that will assist operators in evaluating and securely operating a device.
このセクションの要件がデバイスを評価して、しっかりと操作するのにオペレータを助ける情報をリストアップすることを意図します。
3.1. Identify Services That May Be Listening
3.1. 聴かれているかもしれないサービスを特定してください。
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.
ベンダーはデバイスで活発であるかもしれなくすべてのサービスのリストを提供しなければなりません。 リストはサービスが聴かれるプロトコルとデフォルトポート(適切であるなら)を特定しなければなりません。 それ、SHOULDは、サービスについて説明するドキュメンテーションを完成するために参照を提供します。
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.
リストは、おそらくネットワークを含んでいて、IPなどのプロトコルを輸送するでしょう、ICMP、TCP、UDP、BGPやOSPFなどのプロトコル、RFCsの参照に伴うSSHやSNMPなどのアプリケーション・プロトコルまたはプロトコルのバージョンが実装した他のドキュメンテーション説明を発送して。
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の上で聴かれます。 デバイスのデフォルト設定では、それはポート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).
固有のプロトコルの仕様を明らかにしない有効で、非技術系の理由があるかもしれません。 そのような場合、明らかにされる必要があるすべてがサービスとデフォルトポートの存在(適切であるなら)です。
3.2. Document Service Defaults
3.2. ドキュメントサービスはデフォルトとします。
Requirement.
要件。
The vendor MUST provide a list of the default state of all
services.
ベンダーはすべてのサービスのデフォルト状態のリストを提供しなければなりません。
Jones Informational [Page 67] RFC 3871 Operational Security Requirements September 2004
操作上の[67ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
3.3. Document Service Activation Process
3.3. ドキュメントサービス活性化過程
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.
なし。
3.4. Document Command Line Interface
3.4. ドキュメントコマンドラインインタフェース
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.
ベンダーはコマンドラインインタフェースの完全なドキュメンテーションにそれぞれのソフトウェアリリースを提供しなければなりません。 ドキュメンテーションSHOULDは旧バージョンからの変化に関するハイライトを含んでいます。 ドキュメンテーションSHOULDは各コマンドのための潜在的生産量を記載します。
Jones Informational [Page 68] RFC 3871 Operational Security Requirements September 2004
操作上の[68ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
なし。
3.5. 'Console' Default Communication Profile Documented
3.5. コミュニケーションプロフィールが記録した'コンソール'デフォルト
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.
なし。
4. Assurance Requirements
4. 保証要件
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 機密保護評価の性能を助ける情報を提供してください。
Jones Informational [Page 69] RFC 3871 Operational Security Requirements September 2004
操作上の[69ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
4.1. Identify Origin of IP Stack
4.1. IPスタックの発生源を特定してください。
Requirement.
要件。
The vendor SHOULD disclose the origin or basis of the IP stack
used on the system.
ベンダーSHOULDはシステムの上で使用される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."
「BSDからIPスタックを何4.4インチも得たか、または「IPスタックは最初から、実装されました」。」
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パケットがどう形成されるべきであるかに関する簡素化仮定をします。 誤った形式のパケットはデバイスで予期していなかった振舞いを引き起こす場合があります、システムへの不正アクセスをもたらすことができたシステムクラッシュやバッファオーバーフローのように。
4.2. Identify Origin of Operating System
4.2. オペレーティングシステムの発生源を特定してください。
Requirement.
要件。
The vendor SHOULD disclose the origin or basis of the operating
system (OS).
ベンダーSHOULDはオペレーティングシステム(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."
「オペレーティングシステムはリナックスカーネル2.4.18に基づいています。」
Warnings.
警告。
None.
なし。
Jones Informational [Page 70] RFC 3871 Operational Security Requirements September 2004
操作上の[70ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
5. Security Considerations
5. セキュリティ問題
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を使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが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フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、お勧めです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
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バージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、MIBオブジェクトへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[ANSI.X9-52.1998] American National Standards Institute, "Triple Data
Encryption Algorithm Modes of Operation", ANSI
X9.52, 1998.
[ANSI.X9-52.1998]American National Standards Institut、「三重のデータ暗号化アルゴリズム運転モード」、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 PUB197、2001年11月、<http://csrc.nist.gov/刊行物/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研究所、「標準のディフィー-ヘルマン主要な協定バージョン1.4インチ、PKCS3、1993年11月。」
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking
terms", RFC 1208, March 1991.
[RFC1208] ジェイコブセンとO.とD.リンチ、「ネットワーク用語の用語集」、RFC1208、1991年3月。
Jones Informational [Page 71] RFC 3871 Operational Security Requirements September 2004
操作上の[71ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes
Called TACACS", RFC 1492, July 1993.
[RFC1492]Finseth、1993年7月のC.、「時々TACACSと呼ばれるアクセス制御プロトコル」RFC1492
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September
1993.
[RFC1510]コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC1704] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[RFC1704] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
[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.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC
2196, September 1997.
[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", RFC 2401, November
1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement
Method", RFC 2631, June 1999.
[RFC2631] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、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を使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
Jones Informational [Page 72] RFC 3871 Operational Security Requirements September 2004
操作上の[72ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
[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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3013] Killalea, T., "Recommended Internet Service
Provider Security Services and Procedures", BCP 46,
RFC 3013, November 2000.
T. [RFC3013]Killalea、BCP46、RFC3013、11月2000日「インターネットサービスプロバイダセキュリティー・サービスと手順は推薦され」て、
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
[RFC3164]Lonvick、2001年8月のC.、「BSD Syslogプロトコル」RFC3164。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash
Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
[RFC3195] New, D. and M. Rose, "Reliable Delivery for
syslog", RFC 3195, November 2001.
2001年11月の新しい[RFC3195]のD.とM.ローズ、「syslogのための信頼できるDelivery」RFC3195。
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC
3309, September 2002.
[RFC3309] ストーン、J.、スチュワート、研究開発オーティス、「ストリーム制御伝動プロトコル(SCTP)チェックサム変化」、RFC3309、2002年9月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered
Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360] フロイド、S.、「有害であると考えられた不適当なTCPリセット」、BCP60、RFC3360、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.スチュワート、「インターネット標準の管理フレームワークのための序論と適用性声明」RFC3410(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)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(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インチ、RFC3447、2月2003日
[RFC3562] Leech, M., "Key Management Considerations for the
TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] ヒル、M.、「TCP MD5署名オプションのためのKey Management問題」、RFC3562、2003年7月。
Jones Informational [Page 73] RFC 3871 Operational Security Requirements September 2004
操作上の[73ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
[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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(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.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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.コーフマン、Eds、「インターネットへのセキュリティー対策」、RFC3631、12月2003日
6.2. Informative References
6.2. 有益な参照
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths
For Public Keys Used For Exchanging Symmetric
Keys", BCP 86, RFC 3766, April 2004.
[RFC3766] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[bmwg-acc-bench] Poretsky, S., "Framework for Accelerated Stress
Benchmarking", Work in Progress, October 2003.
S.、「加速している圧力ベンチマーキングのためのフレームワーク」という[bmwg-acc-ベンチ]Poretskyは進歩、2003年10月に働いています。
[Schneier] Schneier, B., "Applied Cryptography, 2nd Ed.,
Publisher John Wiley & Sons, Inc.", 1996.
[シュナイアー]シュナイアー、B.、「適用された暗号、第2エド、出版社のジョン・ワイリーと息子Inc.、」、1996
Jones Informational [Page 74] RFC 3871 Operational Security Requirements September 2004
操作上の[74ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
このAppendixは異なったプロフィールをリストアップします。 プロフィールは特定のクラスのデバイスに適用される要件のリストのリストです。 必要最小限プロフィールはすべてのデバイスに適用されます。
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'は構成のスクリプティングをサポートします。
Jones Informational [Page 75] RFC 3871 Operational Security Requirements September 2004
操作上の[75ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
o 'CLI' Supports Management Over 'Slow' Links
o '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 1規則あたりのフィルタカウンタを表示する能力
Jones Informational [Page 76] RFC 3871 Operational Security Requirements September 2004
操作上の[76ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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 ログはTimestampedであるに違いありません。
o Logs Contain Untranslated IP Addresses
o ログはUntranslated 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 特権レベルをユーザに割り当てる能力
Jones Informational [Page 77] RFC 3871 Operational Security Requirements September 2004
操作上の[77ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
o Default Privilege Level Must Be 'None'
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
o Bogonsと火星人を自動捨てることをサポートしてください。
o Support Counters For Dropped Packets
o 下げられたパケットのためにカウンタをサポートしてください。
o Support Rate Limiting
o 支持率制限
Jones Informational [Page 78] RFC 3871 Operational Security Requirements September 2004
操作上の[78ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
o Support Directional Application Of Rate Limiting Per Interface
o 1インタフェースあたりのレート制限の方向のアプリケーションをサポートしてください。
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.
o サポートするMITRE社はこのドキュメントの開発を続けていました。 以下に注意してください。 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.
o 前のUUNETネットワークセキュリティは組になります: ジャレッド・アリソン、エリックBrandwine、Clarissaは料理します、デーヴGarn、多英・キム、ケントキング、ニールKirr、マーククラウジー、マイケル・ラムルー、モーリーン・リー、トッドMacDermid、クリスMorrow、アラン・ピッツ、グレッグSayadian、ブルースSnow、ロバート・ストーン、アン・ウィリアムズ、ピートホワイト。
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.Behringer、マット司教、スコット・ブレーク、ランディ・ブッシュ、パット・カイン、ロスCallon、スティーブンChristey、オーエンDelong、ショーンDonelan、ロバート・エルモア、バーバラ・フレーザ、Barryグリーン、ジェフリー・ハース、デヴィッド・ハリントン、ダン・ホリス、ジェフリーHutzelman、Merike Kaeo、ジェームス・コー、ジョンKristoff、クリスLonvick、クリスLiljenstolpe、ジェームスWを車で送りました; Laferriere、ジャレッド・マウフ、ペリーE.メッツガー、マイク・オコナー、アラン・パラー、ロブ・ピカリング、ペッカ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 個人か組織がこのドキュメントの中身を承認するのを含意するのではなく、このリストが貢献を承諾することを意図します。
Jones Informational [Page 79] RFC 3871 Operational Security Requirements September 2004
操作上の[79ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.ジョーンズ、斜め継ぎ社7515のColshireが運転するエディタ、M/S西洋マクリーン、ヴァージニア22102-7508米国
Phone: +1 703 488 9740 EMail: gmj3871@pobox.com
以下に電話をしてください。 +1 9740年の703 488メール: gmj3871@pobox.com
Jones Informational [Page 80] RFC 3871 Operational Security Requirements September 2004
操作上の[80ページ]RFC3871セキュリティ要件2004年9月の情報のジョーンズ
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Jones Informational [Page 81]
ジョーンズInformationalです。[81ページ]
一覧
スポンサーリンク
