NTT情報流通プラットフォーム研究所
前回は、IPv6の大きな特徴の1つとされているIPsecの状況について概観した。今回は、IPv6自体のセキュリティについて考えてみる。
IPv6は現在インターネットで広く利用されているIPv4の後継プロトコルであり、IPv4の持つセキュリティ的な問題については、概念的にはほぼ同じことが言え、同じ手法での対応が可能である。しかしながら、具体的な問題として、IPv6によって緩和されるもの、IPv6において特に起こりうるもの、IPv6とIPv4の共存によって新たに起こりうるものが存在する。
IPv6によって緩和されるセキュリティ上の脅威
IPv6によって緩和されると言われている脅威の1つに、ネットワークノードのスキャニングが挙げられる。インターネットにつながっている機器のセキュリティ上の弱点を探す等を目的として、ネットワーク上のノードを探し、動いているサービスを調べるということは、現在頻繁に繰り返されている。
ファイアウォールに守られていたとしても、こうした脅威の対象外になるというわけではない。特に昨今は、ウィルスに感染したネットワークノード(PCなど)が、感染を広げるために、同一ネットワーク内にある他のノードを検索する、といったことが発生している。IPv4では、自ノードのIPアドレスとネットワークプレフィックスから、同一サブネット上や隣接したサブネット上に存在しうる他ノードのIPアドレスを容易に推測できる(自分のIPアドレスの番号近辺のアドレスを手当たり次第に狙い打ちしても、それほど膨大な数にはならない)。
これに対し、IPv6のネットワークプレフィックスは64ビット固定で、同一サブネット上のホストは64ビットの空間のどこかにいることになる。また、隣接サブネットも現在の仕様では、16ビットの空間の中のどれかになる。ノードを発見するために、この空間中のアドレスを単純にすべてスキャンする、ということはほぼ不可能といえる。
このようなノードのスキャンに関して興味深い報告がある(*1)。これはIPv6ネットワーク内でなるべく早くウィルスを伝搬させる手段についての研究だが、この報告によると、単純なIPアドレスランダム選択によるウィルス伝搬を利用した場合、IPv4では8秒程度でほとんどのノードに感染できるのに比較してIPv6では3万年かかる、と計算しており(前提条件等については文献を参照されたい)、理論上、IPv6ネットワークでランダムにアドレスを選択してウィルス伝搬を実施することは困難である、としている。
ただし、この報告には先がある。IPv6を実際に利用する際に、
- サブネットサイズは64ビットではあるが、ステートレスアドレス自動設定ではMACアドレスのビット幅である48ビット分を対象とすればよい。
- アドレスとして、覚えやすい番号を選んでいることが多い。
- アドレスを覚えることが困難なため、DNSなどIPアドレスと名前を変換するシステムを利用することが多いが、この変換テーブルの一部(感染ホストの持つアドレスリスト)が参照できてしまう可能性がある。
IPv6では、IPアドレススキャニングによるノードの発見は確かに困難にはなっているが、こういった特徴に依存しないようなネットワーク運用が必要であろう。
IPv6に特化したセキュリティ上の脅威
IPv6で新たに発生すると思われるセキュリティ上の脅威も存在する。これには、IPv6特有の機能に関連して発生するものが多い。
実際にイベントで運用されるネットワークなどで発生している問題として、IPv6のステートレスアドレス自動機構に関するものは顕著である。ステートレスアドレス自動設定とは、ルータがネットワークアドレスをクライアントノードがつながるネットワークセグメントに広報し、クライアントノードは広報されたネットワークアドレスから独自のIPv6アドレスを生成する機能であり、現在のIPv6ネットワークでは広く使われているアドレス設定手法である。
この手法は、設定の手間が少なく非常に便利である反面、セキュリティ的に弱く、ネットワーク上に故意に別アドレスを広報する機器や、ルータを語る装置を設置することで、そのIPv6ネットワークを動作不全に追い込む、他ノードの通信を傍受する、といったことが可能である。ユーザ機器の設定ミスによりネットワークが混乱するといった例が多く報告されているが、故意かどうかの判断は難しい。このアドレス設定をセキュアにするSEND技術(RFC3971 Secure Neighbor Discovery)も存在するが、利用に関する権利上の問題や、設定が複雑になるといった問題から、普及には至っていない。
IPv6のマルチキャストに関する以下のような問題も提起されている。
- マルチキャストが利用可能なネットワークにおける、組織スコープのマルチキャストが悪用される可能性がある。マルチキャストアドレスには、「すべてのルータ宛」や「すべてのDHCPサーバ宛」といった、ネットワーク中のサービス提供ノード向けのものが定義されており、このアドレス宛にパケットを送ると、サイト中の当該ノードから返答を得ることができるため、サイト内の全サービスノードのIPv6アドレスを知ることができる。このアドレスリストを、攻撃に利用される可能性がある。
- IPv4のICMPとは違い、ICMPv6は、マルチキャスト宛のパケットについてもエラーを返すことが許されている。このため、エラーを引き起こすようなパケットをマルチキャストアドレス宛に送信すると、大量のICMPv6トラフィックが発生する可能性がある。このような不正パケットの始点アドレスを詐称することで、特定のホストに対して容易にDoS攻撃を実施できる。
IPv6の特徴の1つである拡張ヘッダに関する問題も多く挙げられている。
- 経路制御ヘッダを利用することで、終点アドレスによるアクセスフィルタが回避されてしまう(経路制御ヘッダは終点アドレスを順次書き換えるため)。
- 中継点オプションヘッダにより、パケット転送経路途中のルータすべてに負荷をかけられる。特に、中継点オプションヘッダにはオプション数に上限がないため、中継点オプションを多数付加することも可能となっている。
- プライバシー確保のために用意されているテンポラリアドレス機構(RFC3041)を悪用したDoSパケット送出では、発信元の特定が難しくなり、トラブルシューティングが困難になる。
IPv6とIPv4の共存によって新たに起こりうるセキュリティ上の脅威
既存のIPv4ネットワークに、IPv6を導入することによって、起こりうる問題も存在する。
今日では、IPv6のネイティブ接続サービスや、IPv6/IPv4が同時に利用できる接続サービス(デュアルスタックサービス)も一般的になってきたが、IPv6を手っ取り早く導入するための外部接続の方法として、IPv6 over IPv4トンネルを利用することも多い。また、組織内でも一部のルータがIPv6に未対応であるなどの理由から、トンネルを利用している例も多いと思われる。この場合、トンネルの終端点の設置場所にも依存するが、IPv4を前提に構築したネットワークセキュリティモデルがうまく機能しなくなる可能性がある。すなわち、IPv4では強固なセキュリティポリシー下にあったセグメントが、IPv6では緩いセキュリティになっていることや、場合によってはIPv6インターネットから素通しになってしまっていることもありうる。特に、組織ネットワーク内でトンネルを利用した場合や、ネットワークに部分的にIPv6を導入した場合などは、IPv4のネットワークトポロジーとIPv6のネットワークトポロジーが一致せず、結果としてセキュリティ問題を引き起こす可能性がある。これは、トンネルを利用したIPv6利用手段である 6to4や、Teredoなどにも通じる問題で、たとえば6to4の利用を許していると、IPv4的にはファイアウォール内部のノードだとしても、IPv6的には世界中からアクセスフリーになっているようなことが実際に起こっている(6to4については、http://www.ipv6style.jp/jp/building/20030820/2.htmlを参照)。
その他にもいくつかのIPv6特有のセキュリティ上の問題と解決方法が(*2)に述べられているので、参照いただきたい。
以上のように、IPv6を利用することによるセキュリティ上の脅威については、数多く問題が提起されており、また、その対策に関する技術開発や運用対処方法の検討も実施されている。問題のいくつかは、IPv6によって便利になった部分に起因しており、例えばステートレスアドレス自動設定における脅威の対処などは、便利さをとるか、セキュリティをとるか、といったトレードオフの問題になる。従来のIPv4においても、現在利用されているようなセキュリティモデルの確立に至るまでには長い時間がかかっているが、IPv6の利用においては、IPv4での経験を生かし、便利さと安全さが両立するネットワークの構築・運用を進めていくことが重要である。
参考文献
*1 Fast Worm Propagation In IPv6 Networks
http://www.cs.virginia.edu/malware/
*2 IPv6 Transition/Co-existence Security Considerations
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-02.txt
この記事のトラックバックURL
http://www.ipv6style.jp/trackback/231





