HOME情報セキュリティ資料・報告書・出版物調査・研究報告書情報セキュリティ技術動向調査(2009 年下期)

本文を印刷する

情報セキュリティ

情報セキュリティ技術動向調査(2009 年下期)

4 IPv6セキュリティ

馬場 達也

1. はじめに

  2011年から2012年にIPv4グローバルアドレスが枯渇するとの予測があり、それまでに、インターネットを介してサービスを提供しているシステムはIPv6に対応させる必要がある。しかし、IPv6環境におけるセキュリティ上の問題についてはあまり整理がされていないのが現状である。本稿ではIPv6の導入によって生じるセキュリティ問題について整理する。

2. IPv6への取り組みの必要性

  世界的にIPアドレスを管理するIANA(Internet Assigned Numbers Authority)のIPv4グローバルアドレスの在庫が枯渇するのは2011年9月頃、地域のIPアドレス管理団体であるRIR(Regional Internet Registry)の在庫が枯渇するのは2012年10月頃と予測されている(2010年2月3日現在)。IPv4を延命させるための取り組みもされているが、根本的な解決法はIPv6への対応であると言われている。

3. IPv4とIPv6の違い

  IPv4とIPv6の主な違いは以下の4点である。

(1) アドレスの長さと表記方法が異なる。
  IPアドレスの長さは、IPv4の場合は32ビットであったが、IPv6では4倍の128ビットとなる。これにより、アドレス空間を増やし、アドレス枯渇問題を根本的に解決している。また、表記方法も変更され、IPv4では、”163.135.10.10”のように「ドット区切り10進数表記」であったのが、IPv6では、” 2001:db8:615:10::1”のように、「コロン区切り16進数表記」となっている。

(2) リンクローカルアドレスが追加された
  IPv6では、インターネット上で利用可能な「グローバルアドレス」や、従来のプライベートアドレスに該当する「ユニークローカルアドレス」に加えて、同一セグメント内でのみ利用可能な「リンクローカルアドレス」が追加された。

(3) 拡張ヘッダの概念が追加された
  ソースルーティングやフラグメントなど、通常あまり使用することのないIPの機能は、拡張ヘッダで対応するように変更された。拡張ヘッダには、ルーティングヘッダや、フラグメントヘッダ、IPsecで使用するAHヘッダやESPヘッダなどが存在する。

(4) ステートレスアドレス自動設定が追加された
  IPv6では、DHCPv6によるアドレスの割り当て(ステートフルアドレス自動設定)以外に、ルータが配下のホストにネットワーク部(上位64ビット)を通知し、ホスト側がホスト部(下位64ビット)を自動生成してIPv6アドレスを構成する「ステートレスアドレス自動設定」が追加された。

4. IPv6環境におけるセキュリティ面での誤解

  IPv4とIPv6の主な違いは以下の4点である。

  IPv6環境におけるセキュリティ面の誤解として一番多いのが、「グローバルアドレスを持つと、外部から攻撃されてしまうのは?」ということである。IPv4の場合は、通常はPCにはプライベートアドレスを付与し、インターネットとの接続点でNAPT(Network Address Port Translation)によってグローバルアドレスに変換をしているため、外部からはアクセスすることができない。しかし、IPv6の場合においても、NAPTは使わないものの、ルータのファイアウォール機能で適切に設定すれば問題ない。
  2番目として「IPv6は攻撃が少ないから安全」という誤解もある。現在は、IPv6ユーザが少ないため、IPv6ネットワーク上で動作するワームなどは発見されていないが、IPv6が普及するにつれて、IPv6を使用した攻撃やワームは増加すると考えられる。このため、IPv6環境においてもセキュリティ対策は万全にしておく必要がある。
  そして、3番目として、「IPv6通信はIPsecによって暗号化されるので安全」という誤解もある。これは、IPv4の仕様ではIPsecの実装はオプションであったが、IPv6の仕様では実装必須とされていることに起因する。しかし、実装必須とされているからといって、IPv6通信にIPsecが使われるとは限らない。実際、多くのOSでは、IPv4でもIPsecが利用できるように実装されているが、エンド・ツー・エンドの通信にIPsecを使うことはあまりなのが現状である。IPv6のIPsecもIPv4と基本的に変わらないため、IPv6であるからといって、IPsecが使われるということはない。ただし、IPv6の場合は、組織内のネットワークにおいてもグローバルアドレスが使用されるため、IPv4の場合に問題となることの多かった、「NAT越え」の問題は発生しない。このため、IPsecを利用しやすい環境には近づいているとはいえる。しかし、IPsecの鍵管理の煩雑さを解消しないと、エンド・ツー・エンドの通信にIPsecを使うのは難しいだろう。

5. IPv6環境におけるプライバシー問題

  IPv6で問題となるのが、IPv6アドレスによって行動をトレースできてしまうという、プライバシーに関する問題である。基本的に、IPv6アドレスの下位64ビットは、EUI-64フォーマットに従って、48ビットのMACアドレスから生成される。つまり、同じ端末であれば、ネットワークを移動しても、IPv6アドレスの下位64ビットは同じになるということである。このため、サーバ側でアクセスログを取っていれば、ログ中のIPv6アドレスの下位64ビットを突き合わせることで、行動履歴が取れてしまう。この問題に対する解決策として、IPv6アドレスの生成にMACアドレスを使用せず、ランダムに生成するという以下の仕様が存在する。

  • RFC 3041, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”
  • RFC 4941, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”

  Windows XP SP2ではRFC 3041、Windows Vista/Windows 7ではRFC 4941を採用しているが、その他のOSでは採用されていない。
  ただし、WindowsであってもリンクローカルアドレスにはRFC 3041/4941は適用されないという問題がある。リンクローカルアドレスの上位64ビットは「fe80::」に固定されているため、どの環境にいても、MACアドレスが同じであれば、リンクローカルアドレスは同一となる。このため、セミナ会場の無線LAN環境などで、参加者が同じセグメントに接続している場合に、事前に相手のマシンのMACアドレスが分かっていれば、リンクローカルアドレスを得ることができるため、IPレベルでアクセスできてしまうという問題がある。

6. IPv6環境でのネットワークスキャン

  ワームなどは、攻撃対象を見つけるために、IPアドレスを変えながら順次アクセスを行う、いわゆるネットワークスキャン(ポートスキャン)を行う。IPv6はアドレス空間が広大なため、IPv4環境よりネットワークスキャンが困難となっている。しかし、RFC 5157 “IPv6 Implications for Network Scanning”でも指摘されているように、MACアドレスからIPv6アドレスを生成する仕組みの場合はスキャンが容易になってしまうという問題がある。これは、MACアドレスの上位24ビットはベンダIDとなっているため、広く流通しているNICのベンダIDを調べてスキャンすれば、IPv6アドレスの128ビット中40ビット分を固定にしてスキャンすることができるからである。また、Windowsでは、RFC 4941の仕組みにより、IPv6アドレスの下位64ビットをランダムに生成しているが、MACアドレスから生成したアドレスも付与されて応答ができるようになっているため、この手法を回避することができない。

7. IPv6環境での不正アクセス

  アプリケーションレベルやTCPレベルの攻撃など、レイヤ4以上の攻撃はIPv6でもIPv4と同じ手法で行うことが可能である。IPv6でアクセス可能なサイトにおいて、IPv6に対応していないIDS(Intrusion Detection System)やIPS(Intrusion Prevention System)を使用している場合は、プロトコルをIPv6にして攻撃すれば、攻撃を検知されずにIPv4と同様の攻撃を行うことが可能となってしまう。このため、サーバをIPv6に対応する場合には、同時にIDSやIPSなどのセキュリティ機器もIPv6に対応しなければならない。
  また、マルウェア(ウイルス、ワーム、スパイウェアなど)については、現在のところIPv6対応のものは発見されていない。しかし、マルウェアの駆除は、ファイルベースで行われるため、従来通りウイルス対策ソフトなどによって検知・駆除することが可能である。
  セキュリティ製品としては、ファイアウォール、IDS/IPS、アンチウイルスゲートウェイ、URLフィルタリング、WAF(Web Application Firewall)などが存在するが、全体的にIPv6への対応が遅れており、早急な対応が求められる。

8. ステートレスアドレス自動設定のセキュリティ問題

  IPv6で追加されたステートレスアドレス自動設定には、DHCPによる方法と比較して、(1)アドレス割り当て時にDHCP認証(MACアドレス認証)ができない、(2)割り当てのログが残らない、(3)RA(Router Advertisement)の機能を悪用して盗聴することができてしまう、という問題がある。
  しかし、(1)の問題については、そもそも、MACアドレスは偽ることが可能であり、認証を行いたい場合には、IEEE802.1X認証を利用すべきである。また、(2)の問題については、確かに、割り当てのログは残らないが、DHCP環境であっても、勝手にアドレスを設定してしまえば、DHCPによって割り当てられなくても通信できてしまうという問題は依然として残る。(3)の問題については、次に詳しく述べることとする。
  (3)の問題は、攻撃者が不正にRAを送出することによって、デフォルトゲートウェイに成りすますことで、通信の内容を盗聴するというものである(図 1)。


図 1 不正RAによる盗聴

 

  draft-ietf-v6ops-ra-guard-04.txt “IPv6 RA-Guard” に対策が列挙されており、SEND(RFC 3971)というRAの認証の仕組みを利用するか、レイヤ2スイッチで、ルータ接続ポート以外からのRAをフィルタリングするようにするという方法がある。しかし、SENDについては、Cisco社のルータでは実装されているものの、まだあまり普及していないという問題がある。また、レイヤ2スイッチでRAをフィルタリングする方法については、対応しているスイッチが少ないという問題がある。このため、当面の対策として、正規のルータからのRAの優先度(Router Preference)をHighに設定しておき、デフォルトの優先度(Medium)のRAが送信されてきた場合は端末側が無視するようにしておくことが良い。しかし、攻撃者がRAの優先度をHighにした場合には効果がないという問題がある。

9. トランスレータ利用時のセキュリティの考慮事項

  サービス提供者側のシステムがIPv6への対応ができない場合、トランスレータと呼ばれる機器によって、ユーザからのIPv6アクセスをIPv4に変換してシステム側に中継する場面が想定される(図2)。この場合、ユーザのIPv6アドレスがトランスレータのIPv4アドレスに変換されるため、インシデントが発生した場合に発信元を追うためには、システム側のアクセスログとトランスレータでの変換ログを付き合わせる必要がある。これを実現するためには、システム側では、送信元IPv4アドレス(トランスレータのIPv4アドレス)とともに、送信元ポート番号も取得する必要がある。ロードバランサの製品によっては、HTTPヘッダに変換前のIPv6アドレスを埋め込むことができる製品がある。システム側でこのHTTPヘッダを見ることによって送信元IPv6アドレスが判明する。


図 2 トランスレータによるIPv6/IPv4変換

 

10. 拡張ヘッダに起因するセキュリティ問題

  大量のType 0 ルーティングヘッダ(ソースルーティング)を付加したIPv6パケットを送信することにより、DoS攻撃が可能となってしまうという「Type 0 ルーティングヘッダの問題」が存在したが、RFC 5095の”Deprecation of Type 0 Routing Headers in IPv6”にて、Type 0 ルーティングヘッダは廃止になった。また、フラグメントを悪用した攻撃など、IPv4にて問題となっていた攻撃は、IPv6でも問題となっている。

11. まとめと今後の展開

  IPv6には、IPv4のセキュリティ問題に加えて、IPv6で追加された機能に起因するセキュリティ問題が追加されており、その問題を理解してIPv6対応する必要がある。また、セキュリティ関連機器はIPv6対応が遅れている場合が多いが、サイトがIPv6対応した場合にはIPv6のセキュリティも万全にしておく必要があり、ベンダに対応を急がせる必要がある。
  現在、IPv6普及・高度化推進協議会やJNSAにてIPv6セキュリティについて議論をしているが、議論を加速させ、成果を広く周知することが望まれる。

以上

参考文献

  • RFC 4942 “IPv6 Transition/Coexistence Security Considerations”
  • RFC 4943 “IPv6 Neighbor Discovery On-Link Assumption Considered Harmful”
  • RFC 5095 “Deprecation of Type 0 Routing Headers in IPv6”
  • RFC 5157 “IPv6 Implications for Network Scanning”
  • draft-ietf-v6ops-ra-guard-04.txt “IPv6 RA-Guard”
  • draft-ietf-v6ops-cpe-simple-security-08.txt “Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service”

 

目次へ 次へ