調査と解説

ネイティブ IPv6 における問題と対策

IPv6 によってネイティブに接続する場合のセキュリティ上の問題点についてのべる．

公開鍵基盤 (PKI)

IPv6 の IPsec において鍵をどのようにして交換するべきかは，RFC 4301 においては規定されていない． 鍵交換のためにつぎの方法がかんがえられる．

事前共有鍵の手作業による設定

これはとくに大規模なネットワークにおいてはめんどうな作業である．

証明書サーバによる設定

最近まで IPv6 の集中証明書サーバは入手できなかった． しかし，この状況は RFC 4306 によって規定されている IKEv2 プロトコルを基本にしたサーバの登場によって変化した．

IKEv2 の利点は IPv4 と IPv6 両方においてつかいやすく，実装も単純だという点にある．

ファイアウォールと IDS / IPS

エンド・ツー・エンド (end-to-end) の IPsec がつかえることは IPv6 のおもな利点のひとつだが，とくに暗号化をおこなう ESP を使用するとき，既存のファイアウォールや IDS / IPS においてあらたな問題が生じる． すなわち，これらの機器は暗号化されたパケットをうけとるので，それを検査することができない．

この問題に対する解として，IDS / IPS にクライアント-サーバ・モデルを適用するアイデアが提唱されている． この方法は企業レベルのウィルス防衛の方法に似ている． すなわち，中央のサーバに侵入検知パターンやネットワーク上の異常の解析結果のデータベースを用意する． クライアント・コンピュータはこのパターンなどをダウンロードして保持し，そこでパケットを検査する． パターンとマッチするものがあればサーバに報告する． IPv6 に関するパターン例がすくないことが弱点だともいえるが，これは IPv6 の普及にともなって解決するはずである．

実装上の問題

いくつかの最近の IPv6 実装においては ESP の null 暗号化または AH を利用した認証と完全性機能しか利用できない． すべての ESP 実装が守秘性機能をサポートしているとはかぎらない．　 実装がどのようなものであるかを，よく確認する必要がある．

IPv6 の実装は最近おこなわれたものがほとんどであるため，つぎのようなセキュリティ上の問題点がある可能性がある．

セキュリティ評価ツールの不足

IPv6 ネットワークのセキュリティを評価するツールがまだほとんどない． 情報セキュリティの分野では実績のあるセキュリティ監査ツールを使用してネットワークを監査するのが一般的だが，IPv6 ネットワークにおいては適用可能なツールがまだない．

試験されていないコードの存在

IPv6 のコードはまだ過酷な試練をへていないため，つかいこまれた IPv4 のコードとくらべるとセキュリティ上の欠陥をよりおおくかかえているとかんがえられる．

近隣者発見における問題

近隣者発見は IPv6 固有の機構だが，これに関してつぎのような問題点がある．

複数アドレス付与を悪用した DoS 攻撃

攻撃者のノードに何千ものアドレスを付与すれば，他のノードのリンクローカル・アドレス取得を阻害することができる． また，アドレスがすでに付与されていると常に応答するプログラムをつかえば，より容易に攻撃が可能になる．

リンクローカル・アドレスが事前の設定なしに取得できることを悪用した攻撃

攻撃者はネットワークに関する知識をまったくもたずにリンクにアクセスし，そのリンクに接続した他のノードを攻撃することができる． この問題に対する防御策としては，リンク層の認証や暗号的に生成されたアドレスを使用することがあげられる．

ルータ広告のスプーフィング

ひとつのインタフェースに付与した複数のアドレスによって複数の経路を構成できるようになる． ブート中のノードは全ルータ・マルチキャスト・アドレス (FF02::2) にあててルータ要請を送信する． そのリンク上の各ルータはそのノードが使用する設定情報をルータ広告に格納して応答する． このとき，ルータをこえて，送信するべきでない方向へもその情報を送信してしまう可能性がある． IPsec の AH やセキュア近隣者発見 (SEND) がこのようなリスクの回避のために使用できる．

近隣者発見の仕様には IPsec を使用して攻撃を回避せよと書かれているが，その方法の詳細は記述されていない． ほとんどの場合は IPsec において使用される鍵管理は複雑すぎて実用的ではない． とくに公衆ネットワークや無線ネットワークにおいてはそうである． IPsec を使用せずに近隣者発見を保護する方法がセキュア近隣者発見 (SEND) である．

IPv4 における ARP と同様に近隣者発見においてもリダイレクト攻撃 (redirect attack)，DoS 攻撃，フラディング攻撃 (flooding attack) などの脅威が存在しうる．

ポート・スキャン

IPv6 においては IPv4 よりアドレス空間がはるかにひろいため，ポート・スキャンはかなり困難になっている． しかし，それでも番号順や容易に類推されるアドレス体系をさけるべきである．

マルチキャスト関連の問題

IPv6 にはサイトスコープのマルチキャスト・アドレス (たとえば全ルータ・アドレス (FF05::2) や全 DHCP サーバアドレス (FF05::1:3)) があるため，使用法をあやまると，攻撃者がサイト内の重要な資源を同定するのをゆるしてしまう危険がある．

対策としてはつぎのようなことがかんがえられる．

• すべてのファイアウォールとサイト境界のルータにおいてサイトスコープの宛先アドレスをもつパケットを廃棄するように設定することによって，このようなリスクを最小化することができる．
• 正当な利用目的がないサイト内のマルチキャスト・グループにノードが参加しないようにして，こういう未使用のアドレスにあてたパケットはルータにおいて廃棄するように設定すればよい．

IPv6 への移行に関連する問題と対策

IPv6 への移行の過程においては移行のための機構やトンネリング機構が必要である． これらの機構はネットワークを複雑化させるため問題がおこりやすいとかんがえられる． とくに，これらの機構はバックドアとしてつかわれる危険がある．

この方法によってすでに 2002 年 12 月 17 日には HoneyNet プロジェクト (http://www.honeynet.org/) の Solaris 8 サーバの 1 台が侵入された． 攻撃者は第 3 国への IPv6 トンネルを鶏栖子，ぬすみだしたデータをそこから転送していた． 当時の IDS の多くはバイパスされていたが，この状況は現在でもあまり変化していないとかんがえられる． この手口は NAT の内側から IPv6 を通過させることを目的として設計された UDP を使用したトンネル技術 (Teredo と TSP (トンネル設定プロトコル)) の登場によって比較的容易になった (この機構がなければ侵入できなかっただろう)．

トンネリングに関する一般的な対策として，このような侵入を防ぐためには，トンネル終点においては追加のフィルタ機構を導入する必要がある． この問題については “Using IPsec to Secure IPv6-in-IPv4 Tunnels” [RFC 4891] に詳細な説明がある．

また，6to4 トンネル [RFC 3056] に固有の問題に関しては “Security Considerations for 6to4” [RFC 3964] がとくに注意するべき点についてのべている．

参考文献

• [Hag 07] Silvia hagen, “IPv6Essentials, Second Edition”, O'Reilly, 2007. (邦訳: 市原 英也 監訳, “IPv6 エッセンシャルズ 第 2 版”, オライリー・ジャパン, 2007).
• [RFC 3056] B. Carpenter and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, IETF, February 2001.
• [RFC 3964] P. Savola and C. Patel, “Security Considerations for 6to4”, RFC 3964, IETF, December 2004.
• [RFC 4891] R. Graveman, M. Parthasarathy, P. Savola, and H. Tschofenig, “Using IPsec to Secure IPv6-in-IPv4 Tunnels”, RFC 4891, IETF, May 2007.