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

本文を印刷する

情報セキュリティ

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

3. IPv6の配備におけるイントラネットセキュリティ

太田 耕平

3.1. はじめに

 2011年2月のIANA(Internet Assigned Numbers Authority)におけるIPv4アドレスの枯渇[1]に続き、4月には国内の割り当てを担っているJPNIC(Japan Network Information Center)でも新たなIPv4アドレスの割り当てがなくなったことが周知され[2]、IPv6の利用が喫緊の課題となった。現在各組織が留保しているアドレスがなくなり次第IPv6への移行が必要となる。一方で、近年では端末やサーバに加え、スマートフォンやタブレット端末でも既にIPv6接続に対応しており、初期状態で利用可能となっている。結果として、これまで移行の努力が続けられてきたバックボーンだけではなく企業、家庭等あらゆる場面で急速にIPv6の利用が始まっている。
 IPv6は、IPv4ではアドレスが不足するという1992年の調査結果[3]をうけて検討が始まり、1995年に最初の標準化文書[4]が発行されて以来、長きにわたって開発と普及の努力が続けられてきた。IPv6はIPv4での経験を踏まえ、アドレス空間の拡大の他にセキュリティの強化、プラグアンドプレイによる設定の自動化等を大きな課題として開発された。また同時にインターネットプロトコルの根幹となる部分の置き換えとなるため、移行のためのシナリオと技術にも大きな努力がなされてきた。具体的にはIPv4とIPv6の両方に対応するデュアルスタック、点在するIPv6ネットワークをつなぐトンネル技術、およびそれらを意識することなく利用可能とする自動化技術などである。これらは明示的な手間やコストをかけることなくIPv6技術を段階的に浸透させる、という目的に沿ったものであり、今日までの普及に大きな役割を果たしているが、一方でIPv6の利用を管理者が把握していない要因の一つともなっている。このことは本格的な利用が始まりつつある現在「リスクを適切に把握する」というセキュリティの根幹を脅かしている。
 インターネット技術は、その普及につれてセキュリティに関する考え方が大きく変化した。当初はセキュリティに関する関心は希薄であったため、IAB(Internet Architecture Board)は1998年にインターネットにおけるセキュリティのあり方を議論したRFC(Request For Comments)を発行し[5]、IETF(Internet Engineering Task Force)でもRFCに義務付けられているセキュリティに関する考察の記載を強化するためのRFCを発行した[6]。市場においてもファイアウォールの配備は常識となり、攻撃を検知する侵入検知システム等のネットワーク境界での保護技術の利用が進んでいる。IPv6においてもIPパケットの認証と暗号化を実現するIPsecがそのセキュリティ強化の大きな柱となっている。
 しかし、これらのセキュリティ対策の主要な観点は対外接続からの攻撃に焦点をあてたものであり、イントラネット(=内部ネットワーク)の保護については十分に検討されていない。現実的なセキュリティの脅威は外部からの攻撃よりも内部の問題に起因しており、近年の情報漏えい事故等の多くはイントラネットでの対策が不十分なことによるものである。イントラネットの保護には、外部との境界の他に、その反対側の境界=端末の接続についても併せて考える必要がある。本稿ではIPv6、特に端末接続の問題と移行技術に起因するセキュリティ上の課題、および標準化の場での議論を紹介し、これからのイントラネット管理で検討すべきポイントを述べる。

3.2. 外部接続からの保護

 IPv6を前提とするネットワーク保護についてはRFC 4864 [7]で議論され、IPv4で一般化しているNAT(Network Address Translation)技術の功罪をセキュリティ及び運用の両面から再検討している。IPv6では十分なアドレス数を確保することでNATを不要とし、インターネット本来の理念であるEnd-to-Endの接続性を取り戻すことが大きな目的のひとつとなっている。しかし、今日のセキュリティ、およびネットワーク運用環境を考慮するとNATに「期待されている」セキュリティ上の役割、およびアドレスのポータビリティ等、結果的に恩恵をうけている効果についても無視することはできない。一方でNATが「提供しているようにみえる」フィルタ機能は、技術的には十分ではないことが改めて示されており、IPv6に限らず既存のIPv4でも境界での明示的なフィルタリングは欠かせない要素であることが議論されている[8]
 一方で、外部との境界という観点では、近年広く使われるようになっているトンネリング技術が挙げられる。トンネリング技術は、パケットのカプセル化によってネットワーク上の2点間を論理的につなぐ技術であり、カプセル化によって本来ネットワーク境界で適用されるべき様々な検査が無効化される危険性が指摘されている[16]。IPv6では、IPv4ネットワーク中に点在するIPv6ネットワークをつなぎ、スムーズな移行をサポートするための技術にトンネリングが多く用いられている。これらのトンネルはIPv6へ移行するための障壁をできるだけ下げるために、自動で構築するものもあり、結果として管理者の認識していない(=ネットワーク境界のフィルタで保護されていない)形の外部との接続となることがある。さらにはIPv4とIPv6という独立した経路体系を自動的につなぐトンネル技術を悪用した攻撃の可能性も指摘されており[9]、移行技術によって新たに発生する脅威がある。トンネリング技術は原則として対外アクセスであり一般的なネットワーク境界と同等のセキュリティ対策の適用が求められる。

3.3. 内部接続からの保護

 IPv6の設計にあたっては、IPv4では外付けのDHCPに頼らざるを得なかった端末のネットワーク接続をより簡素化、自動化するためにMACアドレスとIPアドレスを関連付けるプロトコルが全面的に再設計された。しかしその基本原理に変更はなく、以下のようなIPv4 と同様の脆弱性を有している。

  • なりすまし可能なアドレス解決
  • なりすまし可能なネットワーク設定

(1) IPv6でのアドレス解決
 インターネットプロトコルでは、接続機器に固有の物理アドレスであるMACアドレスとインターネットアクセスのための論理プロトコルであるIPアドレスをARP(Address Resolution Protocol)によって動的に関連付ける(アドレス解決)ことで、任意の機器を任意のネットワークで利用することを可能としている。この柔軟性によって特定のIPアドレスを複数の機器でシェアする負荷分散、Proxy ARP技術等の応用が可能となっているが、一方ではアドレスの所有者についての認証等の機能がないため、なりすましと区別がつかない。IPv6では、ARPに相当する機能はNDP(Neighbor Discovery Protocol)として設計、実装されているが、そのメカニズムは本質的に同じである。IPv6ではIPv4でのARPの問題を踏まえ、認証の概念を備えたSEND(SEcure Neighbor Discovery)[10]が標準化されている。しかし、正しいアドレスを確認できる、ということを基本としているため、不正利用を防ぐためには管理対象の全機器がこの技術に対応している必要がある。このことは認証システムの運用につきものの鍵管理、トラストチェーンの管理といった煩雑で普及の壁となる問題に直結する。そのため管理対象の数が非常に多くなりえるIPv6では今後の普及の見通しもたっていない。


(2) IPv6での基本設定
 IPv4ではネットワーク接続のための基本設定にはDHCP(Dynamic Host Configuration Protocol)が使用され、事実上必須要素となっている。しかしARP同様DHCPにも認証の概念がないため、不正なDHCPによってにせの設定を送り込むことができる。実際に多くのネットワークで勝手に運用されるDHCPサーバによってネットワークの混乱が起こっている。IPv6でもまったく同様のリスクがあるが、IPv6ではNDPによってローカルな通信のための設定は端末自身で解決され、外部アクセスについてもルータとの連携で設定されるため、基本的な接続にDHCPが不要であり、DHCPに依存することによるリスクは軽減されている。しかし、NDPの一部であるルータ設定のためのRA(Router Advertisement)はアドレス解決と同様の認証の問題がありやはりなりすましの危険性がある[11]

3.4. まとめと現状の対策

 IPv6ではIPv4での経験を踏まえ、インターネットの当初の理念であるEnd-to-Endの原則[12]を再び実現し、今後の発展を長く支えるべく設計されている。IPv6の導入と利用は必須の課題であり、主に移行をスムーズにするために準備された各種の技術と、Dualスタック戦略によって実質的な導入は既に始まっている。ネットワークの管理者は特に以下の項目に留意して運用・管理計画を見直す必要がある。これらの各要素は[13]でも議論されている。

  • 既存のネットワーク境界でのIPv6対応フィルタリング
  • 移行(トンネリング)技術によって新たに構築されるネットワーク境界の管理とフィルタリング
  • 不正な端末の接続および不正なRAに対応するNDP対応フィルタリング

 現状で、IPv6のLANに接続する際に考慮すべき標準化文書を表1 に、ネットワークとして検討すべきフィルタ等のセキュリティ対策を図1 にまとめる。


表1:IPv6によるネットワーク構築で考慮すべき標準
RFC 議論している内容

RFC 6105 [14]
IPv6 Router Advertisement Guard

不正なRAを流通させないためのフィルタ

RFC 4864 [7]
Local Network protection

境界でのNATに依存しないフィルタの必要性

RFC 6092 [15]
Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service

IPv6接続機器が備えるべきセキュリティ機能

RFC 6169 [16]
Security Concerns with IP Tunneling

IPv6への移行技術に広く用いられているトンネリング技術へのセキュリティ対策

RFC 6324 [17]
Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations

IPv6への移行技術に広く用いられている自動トンネル技術の問題と対策

 

図1:IPv6 LANをとりまくセキュリティ対策の現状


 上記のような対策のほかに、近年では、端末接続管理の必要性が浸透し、企業等のイントラネットでの普及が進んでいる。接続管理には、[18]でも紹介されている通り、市場にも複数の方式があるが、ARPおよびNDPを応用した通信遮断技術も実用的なソリューションのひとつとして利用されている[19]。そのため現実的な導入と接続の制御性を踏まえると、プロトコル内部のセキュリティ機構ではなく、802.1X等の認証や、上記の応用技術のような外部から制御できる機構を利用することに大きな価値もある。
 IPv6ネットワークには大きな期待が寄せられているが、その導入にあたってはアクセス範囲を慎重に設計することが重要となる。IPv6では豊富なアドレス空間を活用したLink-Local Address、ULA: Unique Local Addressといったアドレス体系があり、それらを複数割り当てることができる。内部サーバや、クライアント、対外サービスサーバ、外部アクセスクライアントなど、役割に応じてわりあてるアドレスを使い分けることで、より確実で明確なアクセス制御を実現することが可能であり、IPv4とは異なるより構造化されたフィルリング体系の構築も可能となるため、今後はIPv6での適切なフィルタ設計、構築、運用に関するノウハウの構築が、イントラネット設計の重要な要素となる。

以上

参考文献

[1] 社団法人日本ネットワークインフォメーションセンター,「IPv4アドレスの在庫枯渇に関して」,2011年2月3日.
http://www.nic.ad.jp/ja/ip/ipv4pool/
[2] APNICにおけるIPv4アドレス在庫枯渇のお知らせおよび枯渇後のJPNICにおけるアドレス管理ポリシーのご案内, 15th, April,
http://www.nic.ad.jp/ja/topics/2011/20110415-01.html
[3] P. Gross, P. Almquist, “IESG Deliberations on Routing and Addressing”, RFC 1380, November 1992
[4] R. Hinden, S. Deering, “IP Version 6 Addressing Architecture”, RFC 1884, December 1995
[5] S. Bellovin, “Report of the IAB Security Architecture Workshop”, RFC 2316, April 1998
(日本語訳:http://www.ipa.go.jp/security/rfc/RFC2316JA.html
[6] E. Rescorla、B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, RFC 3552, July 2003
[7] G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, “Local Network Protection“, RFC 4864, May 2007
[8] 太田 耕平, Glenn Mansfield, KEENI, 「IPv6ネットワークにおけるローカルネットワークの保護」,IPA 情報セキュリティ技術動向調査(2010 年上期),2010年9月.
http://www.ipa.go.jp/security/fy22/reports/tech1-tg/a_06.html
[9] 太田 耕平, Glenn Mansfield, KEENI, 「トンネリング技術のセキュリティ上の弊害とIPv6移行技術における経路ループの危険性」,IPA 情報セキュリティ技術動向調査(2010 年下期),2011年3月.
http://www.ipa.go.jp/security/fy22/reports/tech1-tg/b_09.html
[10] J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander, “SEcure Neighbor Discovery (SEND)”, RFC 3971, March 2005
[11] T. Chown, S. Venaas, “Rogue IPv6 Router Advertisement Problem Statement”, RFC 6104, February 2011
[12] Aboba, B. and E. Davies, “Reflections on Internet Transparency”, RFC 4924, July 2007
[13] Enno Rey, Christopher Werny, “IPv6 Security in Enterprise LANs”, IPv6 Kongress, Frankfurt, 12-13 May 2011
[14] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi, “IPv6 Router Advertisement Guard”, RFC 6105, February 2011
[15] J. Woodyatt, Ed., “Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service”, RFC 6092, January 2011
[16] S. Krishnan, D. Thaler, J. Hoagland, “Security Concerns with IP Tunneling”, RFC 6169, April 2011
[17] G. Nakibly, F. Templin, “Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations”, RFC6324, August 2011
[18] 馬場 達也, 「検疫ネットワーク技術の標準化動向」,IPA 情報セキュリティ技術動向調査(2008 年上期),2008年9月.
http://www.ipa.go.jp/security/fy20/reports/tech1-tg/1_03.html
[19] 太田 耕平, 「イントラネットセキュリティをめぐる技術動向」,IPA 情報セキュリティ技術動向調査(2008 年上期),2008年9月.
http://www.ipa.go.jp/security/fy20/reports/tech1-tg/1_02.html

 

目次へ 次へ