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

1.5. Protection against Message Replay, Delay and Redirection (メッセージリプレイ、遅延、リダイレクトに対する保護)

1.5. Protection against Message Replay, Delay and Redirection (メッセージリプレイ、遅延、リダイレクトに対する保護)​

ユーザーベースセキュリティモデルは、複数のタイプのメッセージベースの攻撃に対する保護を提供します。

Message Replay (メッセージリプレイ)​

脅威 (Threat): 攻撃者が有効な認証済み SNMP メッセージをキャプチャし、後で再送信して不正な効果を達成します。

保護メカニズム (Protection Mechanism): USM は時間ベースのメカニズムを使用して、リプレイされたメッセージを検出および拒否します。各 SNMP エンジンは以下を維持します:

  1. snmpEngineBoots: SNMP エンジンが再初期化するたびに増分するカウンター
  2. snmpEngineTime: 最後のエンジン再起動からの秒数のカウンター

これらの値は、認証済みメッセージの msgAuthoritativeEngineBoots および msgAuthoritativeEngineTime フィールドに含まれています。受信エンジンは、これらの値が許容可能なタイムウィンドウ内に収まることを検証します。

タイムウィンドウ (Time Window): 次の条件を満たす場合、メッセージは真正であると見なされます:

|msgAuthoritativeEngineTime - snmpEngineTime| ≤ 150 秒

かつ:

msgAuthoritativeEngineBoots = snmpEngineBoots

このウィンドウの外側のメッセージは、潜在的なリプレイとして拒否されます。

Message Delay (メッセージ遅延)​

脅威 (Threat): 攻撃者が有効なメッセージの配信を遅延させて、不適切な時刻に処理されるようにします。

保護メカニズム (Protection Mechanism): リプレイに対する保護に使用されるのと同じタイムウィンドウメカニズムが、重大なメッセージ遅延に対しても保護します。150 秒以上遅延したメッセージは拒否されます。

制限 (Limitations):

  • 150 秒のウィンドウ内の遅延は検出できません
  • これはほとんどのネットワーク管理アプリケーションにとって許容できると考えられています
  • より厳密なタイミングを必要とするアプリケーションは、追加のメカニズムを実装する必要があります

Message Redirection (メッセージリダイレクト)​

脅威 (Threat): 攻撃者が 1 つの SNMP エンジン宛てのメッセージを傍受し、別の SNMP エンジンにリダイレクトします。

保護メカニズム (Protection Mechanism): USM はメッセージの認証済み部分に msgAuthoritativeEngineID を含めます。この値は意図された受信エンジンを識別します。受信エンジンは次の場合にメッセージを拒否します:

msgAuthoritativeEngineID ≠ snmpEngineID (受信エンジンの)

追加の保護 (Additional Protection): engineID、engineBoots、engineTime の組み合わせは強力な保護を提供します。なぜなら:

  1. 各エンジンには固有の snmpEngineID があります
  2. 鍵は特定のエンジンにローカライズされています (セクション 2.6 を参照)
  3. 認証ダイジェストは engineID をカバーしているため、検出されずに変更することは不可能です

Interaction of Protection Mechanisms (保護メカニズムの相互作用)​

3 つの値 (msgAuthoritativeEngineID、msgAuthoritativeEngineBoots、msgAuthoritativeEngineTime) は連携して包括的な保護を提供します:

  1. engineID は異なるエンジンへのリダイレクトを防ぎます
  2. engineBoots は最後のエンジン再起動前のメッセージのリプレイを防ぎます
  3. engineTime は最近のメッセージのリプレイを防ぎ、重大な遅延を検出します

Limitations and Considerations (制限と考慮事項)​

Clock Synchronization (クロック同期)​

タイムウィンドウメカニズムには以下が必要です:

  • SNMP エンジンが合理的に正確なクロックを持つこと
  • クロックが時間とともに大幅にドリフトしないこと
  • 通信エンジン間で時刻同期が維持されること

クロック問題の影響 (Impact of Clock Issues):

  • 速いクロック: 有効なメッセージが拒否される可能性があります
  • 遅いクロック: リプレイされたメッセージが受け入れられる可能性があります
  • クロックの後退リセット: snmpEngineBoots の増分が必要です

Time Window Size (タイムウィンドウサイズ)​

150 秒のウィンドウは以下の間のバランスを表します:

  • セキュリティ: より小さいウィンドウ = リプレイの機会が少ない
  • 運用の柔軟性: より大きいウィンドウ = クロックドリフトとネットワーク遅延に対する許容度が高い

150 秒の根拠 (Rationale for 150 seconds):

  • 典型的なネットワークレイテンシーに対応します
  • 適度なクロックドリフトを許容します
  • 管理トラフィックに対して合理的なリプレイ保護を提供します

Notification Messages (通知メッセージ)​

通知メッセージ (トラップとインフォーム) の場合:

  • 権威あるエンジンは通知発信者です
  • 通知受信者は発信者の時刻と同期する必要があります
  • これはコマンドレスポンダーモデルとは逆です

Discovery and Time Synchronization (ディスカバリーと時刻同期)​

安全な通信が発生する前に:

  1. 非権威あるエンジンは権威あるエンジンの snmpEngineID を発見する必要があります
  2. 非権威あるエンジンはキャッシュされた時刻値を権威あるエンジンと同期する必要があります

これらのプロセスは、セクション 4 (ディスカバリー) とセクション 2.3 (時刻同期) で詳しく説明されています。

Security Analysis (セキュリティ分析)​

USM の時間ベースのリプレイ保護は以下を提供します:

強力な保護 (Strong Protection Against):

  • 古いメッセージの正確なリプレイ
  • 異なるエンジンへのリダイレクト
  • 長期保存とリプレイ攻撃

限定的な保護 (Limited Protection Against):

  • 150 秒のウィンドウ内のリプレイ
  • 両方のエンドポイントのクロックを操作できる攻撃者

保護されない (Not Protected):

  • リアルタイムメッセージ複製 (ウィンドウ内で同じメッセージを 2 回送信)
  • アプリケーション層のリプレイ (攻撃者が同じ内容の正当な新しいリクエストを開始)

これらの制限は、SNMP の意図されたユースケースでは許容されます。管理操作は通常冪等であるか、アプリケーション層のメカニズムで重複を検出できます。

に最終更新