セッションハイジャックを防止するためのDHCPv6クライアントMACアドレス検証
Junos OSリリース18.2R1以降、DHCPv6ローカルサーバーとリレーエージェントが、悪意のあるクライアントによるセッションの乗っ取りを防ぐために、不明なMACアドレスを持つクライアントからパケットをドロップする設定不可能なメカニズムが存在します。DHCPv6ローカルサーバーまたはリレーエージェントは、クライアントからセッションを確立するための要請メッセージを受信すると、メッセージからクライアントMACアドレス(リンクレイヤーアドレス)を抽出し、MACアドレスをクライアントIPv6アドレスまたはプレフィックスにマッピングするローカルテーブルに追加します。サーバーまたはリレー エージェントは、このテーブルを使用して、クライアントから後続のメッセージで受信した MAC アドレスを比較し、クライアントが既知であるかどうかを検証します。そうでない場合、悪意があるとみなされ、制御パケットは破棄されます。パケットがMAC検証に失敗したため、クライアントMAC検証カウンターがインクリメントされます。
ここでは、最初の要請メッセージを送信するクライアントが無害であると仮定しています。この場合、クライアントMACアドレス検証は、すでに確立されている、または確立中のクライアントセッションを乗っ取ろうとする悪意のあるクライアントから保護します。クライアントMACアドレス検証は、最初の要請メッセージを送信する悪意のあるクライアントから保護するものではありません。
リレーエージェントが存在しない場合。ローカルサーバーは、リンクまたはアクセスノードをクライアントと共有します。この場合、ローカルサーバーはDHCPv6制御パケットのレイヤー2ヘッダーから直接クライアントMACアドレスを抽出し、テーブルに対してアドレスを検証します。
リレーエージェントが存在する場合、リレーエージェントによって検証が実行されます。 RFC 6939、DHCPv6のクライアントリンク層アドレスオプションにより、DHCPv6クライアントと同じリンクに接続されているDHCPv6リレーエージェントが、受信したDHCPv6制御パケットのイーサネット(レイヤー2)ヘッダーからクライアントMACアドレスを抽出できます。パケットには、イーサネットヘッダーの送信元MACアドレスとしてクライアントリンク層アドレスが含まれています。リレーエージェントは、ローカルテーブルに格納されているこのクライアントの値に対してMACアドレスを検証します。アドレスが一致しない場合、パケットをドロップします。
アドレスがリレーエージェントによって検証され、パケットがドロップされない場合、リレーエージェントは、リレーエージェントがローカルサーバーに送信するDHCPv6リレーフォワードメッセージのヘッダーに、オプション79(クライアントリンクレイヤーアドレス)のMACアドレスも含めます。DHCPv6ローカルサーバーがリレーエージェントからリレーフォワードメッセージを受信すると、サーバーはオプション79の存在についてメッセージを自動的に調べます。オプションが存在する場合、ローカルサーバーはMACアドレスを抽出し、このクライアントのテーブルに保存されている値と照合して検証します。オプション79がない場合、ローカルサーバーは検証を実行できません。
ただし、リレーエージェントはすでにアドレスを検証しているため、ローカルサーバーはアドレスの不一致を検出することはありません。
以下のシナリオでは、可能なリレーエージェントの設定と、サーバー検証への影響について説明します。
単一の軽量DHCPv6リレーエージェント(LDRA;レイヤー2)はクライアントとサーバー間に接続されます。LDRA がヘッダーにオプション 79 を追加していない場合、ローカル サーバーは DHCPv6 制御パケットのレイヤー 2 ヘッダーから直接クライアント MACアドレスを抽出し、テーブルに対してアドレスを検証します。
1 つ以上のレイヤー 3 DHCPv6 リレー エージェントがクライアントとサーバー間に接続されています。この場合、サーバーはリレーエージェントから送信された最も内側のリレーフォワードメッセージのヘッダーでオプション79をチェックします。最も内側のヘッダーは、クライアントが最初に到達したリレーエージェントによって変更されたヘッダーであるために表示されます。その他のヘッダーは、パス内の後続のリレー エージェントによって追加されます。これらのエージェントはオプション79を追加せず、最初のリレーエージェントのレイヤー2ヘッダーからMACアドレスを抽出することはできません。これは、後続の各リレーエージェントと同様に、最初のリレーエージェントがアドレスを独自のアドレスに変更するためです。
クライアントとサーバー間には、クライアント向けのレイヤー 2(LDRA)リレー エージェントと、それに続く 1 つ以上のレイヤー 3 DHCPv6 リレー エージェントの組み合わせが接続されます。サーバーは、リレーエージェントから送信されたリレーフォワードメッセージの最も内側のヘッダーでオプション79を確認します。LDRA がヘッダーにオプション 79 を追加していない場合、ヘッダー内の MACアドレスを独自のアドレスに変更することはできない可能性があります。その結果、最初のレイヤー3リレーエージェントがMACアドレスを抽出し、アドレスを伝えるためにオプション79を追加した可能性があるため、サーバーは次に、オプションの2番目の最も内側のヘッダーをチェックします。
クライアントMACアドレスの検証を有効にするための設定は必要ありません。 show dhcpv6 server statistics コマンドを発行することで、検証失敗によりドロップされた制御パケットの数を確認できます。
クライアントMACアドレス検証のメリット
クライアントMACアドレスの検証により、不明なMACアドレスを持つDHCPv6クライアントが既知のクライアントによって確立されたセッションをハイジャックするのを防ぐMACアドレスを防止できます。DHCPv6クライアントMACアドレスは、デュアルスタック環境でDHCPv4とDHCPv6クライアントを関連付けるのに便利なため、使用量が増加する可能性があります。
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。