セッションハイジャックを防止するための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 が存在しない場合、ローカル サーバーは検証を実行できません。
ただし、リレー エージェントはすでにアドレスを検証しているため、ローカル サーバーはアドレスの不一致を検出することはありません。
以下のシナリオでは、リレーエージェントの設定と、サーバー検証への影響について説明します。
単一の Lightweight 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 クライアントが、既知のクライアントによって確立されたセッションを乗っ取るのを防ぐことができます。DHCPv6 クライアント MAC アドレスは、デュアルスタック環境で DHCPv4 と DHCPv6 クライアントを相関させるのに便利なため、使用量は増加する可能性があります。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。