メインコンテンツまでスキップ

9. Security Considerations (セキュリティに関する考慮事項)

セキュリティに関する考慮事項の本体全体をよりアクセスしやすくするために、トランスポート、認証、および接続文書のセキュリティに関する考慮事項がここに集められています。

トランスポートプロトコル [SSH-TRANS] は、安全でないネットワーク上で機密チャネル (Confidential Channel) を提供します。サーバーホスト認証、鍵交換、暗号化、および完全性保護を実行します。また、上位レベルのプロトコルで使用できる一意のセッションID (Session ID) を導出します。

認証プロトコル [SSH-USERAUTH] は、クライアントユーザーをサーバーに対して認証するために使用できるメカニズムのスイートを提供します。認証プロトコルで指定された個々のメカニズムは、トランスポートプロトコルによって提供されるセッションIDを使用し、および/またはトランスポートプロトコルのセキュリティと完全性の保証に依存しています。

接続プロトコル [SSH-CONNECT] は、機密性が保たれ認証されたトランスポート上で、複数のデータストリーム (チャネル) を多重化するメカニズムを指定します。また、対話型シェルへのアクセス、安全なトランスポート上でさまざまな外部プロトコル (任意のTCP/IPプロトコルを含む) をプロキシ転送するためのチャネル、およびサーバーホスト上の安全なサブシステムにアクセスするためのチャネルも指定します。

9.1. Pseudo-Random Number Generation (疑似乱数生成)​

このプロトコルは、セッションキー (Session Key) を生成するために使用されるハッシュにランダムでセッション固有のデータを含めることにより、各セッションキーをセッションにバインドします。すべての乱数が高品質であることを確保するために特別な注意を払う必要があります。ここでの乱数データ (例: Diffie-Hellman (DH) パラメータ) が疑似乱数である場合、疑似乱数生成器 (Pseudo-Random Number Generator) は暗号学的に安全でなければなりません (すなわち、以前のすべての出力を知っていても、次の出力を簡単に推測できない)。さらに、疑似乱数生成器に適切なエントロピー (Entropy) を追加する必要があります。[RFC4086] は、乱数とエントロピーのソースに関する提案を提供しています。実装者は、エントロピーの重要性と、疑似乱数生成関数を適切に実装することの難しさについての善意の、逸話的な警告に注意する必要があります。

特定のクライアントまたはサーバーが利用できるエントロピーの量は、必要な量よりも少ない場合があります。この場合、エントロピーが不十分であるにもかかわらず疑似乱数生成に頼るか、プロトコルの実行を拒否するかのいずれかを選択しなければなりません。後者が望ましいです。

9.2. Control Character Filtering (制御文字のフィルタリング)​

エラーメッセージやデバッグメッセージなど、ユーザーにテキストを表示する場合、クライアントソフトウェアは、端末制御文字を送信することによる攻撃を回避するために、すべての制御文字 (タブ、キャリッジリターン、および改行を除く) を安全なシーケンスに置き換えるべきです (SHOULD)。

9.3. Transport (トランスポート)​

9.3.1. Confidentiality (機密性)​

特定の暗号を分析または推奨することは、本文書およびセキュアシェルワーキンググループの範囲を超えています。本書執筆時点で、一般的に使用される暗号には、3DES、ARCFOUR、twofish、serpent、およびblowfishが含まれます。AESは、米国連邦情報処理標準によって [FIPS-197] として公開されており、暗号学コミュニティもAESを受け入れています。常に、実装者とユーザーは、製品内で使用される暗号に最近の脆弱性が見つかっていないことを確認するために、最新の文献を確認する必要があります。実装者は、どの暗号が他のものよりも比較的強力であると考えられているかを確認し、比較的弱い暗号よりもそれらの使用をユーザーに推奨する必要があります。より弱い暗号が積極的に選択された場合、より強力な暗号が利用可能であり使用すべきであることを、礼儀正しくかつ控えめにユーザーに通知することは、実装にとって良い形式と見なされます。

"none" 暗号はデバッグのために提供されており、その目的以外で使用すべきではありません (SHOULD NOT)。その暗号学的特性は [RFC2410] で十分に説明されており、その使用はこのプロトコルの意図を満たさないことが示されます。

これらおよび他の暗号の相対的なメリットは、現在の文献でも見つけることができます。このテーマに関する情報を提供する可能性のある2つの参考文献は、[SCHNEIER] と [KAUFMAN] です。これら両方は、特定の暗号のCBC動作モード (CBC Mode of Operation) とこのスキームの弱点について説明しています。本質的に、このモードは、パケットシーケンスの開始の高い予測可能性のために、選択暗号文攻撃 (Chosen Cipher-text Attack) に理論的に脆弱です。しかし、この攻撃は困難であると見なされ、特に比較的長いブロックサイズが使用される場合、完全に実行可能とは見なされていません。

9.3.2. Data Integrity (データ完全性)​

データの完全性 (Data Integrity) は、メッセージ認証コード (Message Authentication Code, MAC) によって保護されます。このプロトコルで使用されるMACアルゴリズムの実装は、最新の暗号解読攻撃に対して安全である必要があります。

9.3.3. Replay (リプレイ攻撃)​

このプロトコルは、各セッションにシーケンス番号 (Sequence Number) を使用することにより、リプレイ攻撃 (Replay Attack) から保護します。攻撃者が古いパケットを再送信しようとしても、シーケンス番号が一致しないため、受信者によって検出されます。

9.3.4. Man-in-the-middle (中間者攻撃)​

中間者攻撃 (Man-in-the-middle Attack) は、SSHの主要な脅威の1つです。この攻撃は、攻撃者がクライアントとサーバー間の通信を傍受し、両当事者になりすます場合に発生します。SSHプロトコルは、サーバーホストキーの検証を通じてこの攻撃から保護します。クライアントがサーバーの公開ホストキーを事前に知っている場合、攻撃者が正しいホストキーを提供できない限り、中間者攻撃は検出されます。

9.3.5. Denial of Service (サービス拒否攻撃)​

サービス拒否攻撃 (Denial of Service, DoS) は、正当なユーザーがサービスにアクセスできないようにする攻撃です。SSHプロトコルは、いくつかのDoS攻撃の影響を軽減するメカニズムを提供しますが、すべてのDoS攻撃を防ぐことはできません。実装は、リソース消費の制限、接続レート制限、およびその他の保護メカニズムを実装する必要があります。

9.3.6. Covert Channels (隠れチャネル)​

隠れチャネル (Covert Channel) は、情報を伝達するように設計されていないチャネルを通じて情報が漏洩する可能性があります。SSHプロトコルは、タイミング情報やパケットサイズなどを通じて隠れチャネルの影響を受ける可能性があります。

9.3.7. Forward Secrecy (前方秘匿性)​

前方秘匿性 (Forward Secrecy または Perfect Forward Secrecy, PFS) は、長期秘密鍵が侵害された場合でも、過去のセッションキーが侵害されないという特性です。SSHプロトコルは、Diffie-Hellman鍵交換を使用して前方秘匿性を提供します。

9.3.8. Ordering of Key Exchange Methods (鍵交換方法の順序)​

鍵交換方法の順序は、セキュリティに影響を与える可能性があります。実装は、最も安全な方法を最初にリストする必要があります。

9.3.9. Traffic Analysis (トラフィック分析)​

トラフィック分析 (Traffic Analysis) 攻撃は、暗号化されたトラフィックのパターンを観察することにより、情報を推測しようとします。SSHプロトコルは、パディング (Padding) とダミートラフィックを使用して、トラフィック分析の影響を軽減できます。

9.4. Authentication Protocol (認証プロトコル)​

9.4.1. Weak Transport (弱いトランスポート)​

認証プロトコルは、トランスポートプロトコルのセキュリティに依存しています。トランスポート層が侵害された場合、認証も侵害される可能性があります。

9.4.2. Debug Messages (デバッグメッセージ)​

デバッグメッセージは、攻撃者に有用な情報を提供する可能性があります。実装は、本番環境でデバッグメッセージを無効にする必要があります。

9.4.3. Local Security Policy (ローカルセキュリティポリシー)​

各サーバーは、ユーザーが許可される認証方法を決定するローカルセキュリティポリシー (Local Security Policy) を持つ必要があります。

9.4.4. Public Key Authentication (公開鍵認証)​

公開鍵認証 (Public Key Authentication) は、強力な認証方法ですが、秘密鍵の適切な管理が必要です。秘密鍵は安全に保存され、適切にアクセスが制限される必要があります。

9.4.5. Password Authentication (パスワード認証)​

パスワード認証 (Password Authentication) は、ブルートフォース攻撃 (Brute Force Attack) やパスワード推測に対して脆弱です。強力なパスワードポリシーとレート制限を実装する必要があります。

9.4.6. Host-Based Authentication (ホストベース認証)​

ホストベース認証 (Host-Based Authentication) は、クライアントホスト全体を信頼します。この方法は、クライアントホストのセキュリティに依存するため、慎重に使用する必要があります。

9.5. Connection Protocol (接続プロトコル)​

9.5.1. End Point Security (エンドポイントセキュリティ)​

接続プロトコルは、クライアントとサーバーのエンドポイントのセキュリティに依存しています。エンドポイントが侵害された場合、接続も侵害される可能性があります。

9.5.2. Proxy Forwarding (プロキシ転送)​

プロキシ転送 (Proxy Forwarding) は、ファイアウォールをバイパスする可能性があり、セキュリティリスクをもたらす可能性があります。実装は、プロキシ転送を慎重に制御する必要があります。

9.5.3. X11 Forwarding (X11転送)​

X11転送 (X11 Forwarding) は、セキュリティリスクをもたらす可能性があります。X11プロトコルには、攻撃者が悪用できる多くの機能があります。実装は、X11転送を慎重に制御し、必要な場合にのみ有効にする必要があります。

に最終更新