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

本文を印刷する

情報セキュリティ

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

9 トンネリング技術のセキュリティ上の弊害とIPv6移行技術における経路ループの危険性

太田 耕平、キニ グレン マンスフィールド

1. はじめに

  インターネットの拡大に伴って必要にせまられて登場したNAT(Network Address Translation)技術は、技術的には不十分であるにもかかわらずセキュリティ装置としても期待され、当初の想定を越えて広くいきわたっている。その結果本来NAT技術を不要にすることを期待されて登場したIPv6ネットワークにおいても、その必要性が議論されている[1][2]
  限られた数のグローバルアドレスを共有するNAT技術は、インターネットに実用的な拡張性をもたらした。しかし、その代償として、見かけ上ネットワークを分割することがフィルタ機能を提供しているように見え、セキュリティに対する誤解と過信の温床となるとともに、一方では次世代のIPv6においても本来の理念であるEnd-to-Endの接続性を阻害するものとして大きな懸念事項となっている[3]
  NAT技術によって分断されたEnd-to-Endの接続性は、理念だけではなく実際の利便性にも悪影響をもたらしており、如何にNATを越えて通信できるようにするかが課題になっている。このような背景の下、数多くのトンネリング技術が開発されている。Teredo [4]、L2TPv2 [5]、L2TPv3 [6]などのトンネリングプロトコルのほか、最近増加しているSSL(Secure Socket Layer)ベースのVPN(Virtual Private Network)ソリューションもトンネリング技術を利用している。多くのトンネリング技術は、既存のコネクション管理を避けるためにUDPのようなコネクションレスのプロトコル上に実装されるか、最も広い範囲で通信が確保されているHTTPを利用することで接続性を高めている。
  しかし、トンネリング技術は経路上のなんらかの障壁を越えて通信を確立する技術であるため、現在一般的に用いられているネットワークベースの侵入検知システムやファイアウォール等のセキュリティシステムと極めて相性が悪い。また、トンネリング技術のいくつかはNATによって分断されたEnd-to-Endの接続性を新たに確保するために、不完全ながらも一定の役割を果たしているNATのフィルタ機能をさらに低下させており、NATのフィルタ機能への過信をより深刻な問題としている。
  トンネリングによるセキュリティへの脅威については、認知が進んでおらず、十分な対策がとられているとはいえない。特に明示的な設定を必要としない自動トンネリング技術は、ネットワーク管理者が気づかないうちに新たなネットワーク接続点を作り出し、潜在的なセキュリティ上の脆弱点となりえる。
  そのような中、IPv4アドレスの枯渇[7]に伴いIPv6への移行が急務となっている。この変更はこれまでのインターネットを置き換える大規模なものであるため、段階的な措置が不可欠であり、IPv4ネットワークの中に段階的にIPv6ネットワークを構築し、相互に接続できるトンネリング技術は重要な役割を果たすことが期待されている。
  本稿では、NATを跨いで機能するトンネリング技術がもたらすセキュリティ上の脅威についてのIETFの動向と、IPv6への移行技術としてのトンネリングで、具体的に危険性が指摘されている経路ループについて述べる。

2. トンネリング技術の利用に伴うセキュリティ上の問題点

  まもなくRFCとして発行される見込みの[8]では、トンネリング技術と既存のセキュリティ対策との親和性の問題、トンネリング技術がNATにもたらす影響、および、トンネリング技術の悪用の観点からトンネリング技術のセキュリティ問題を論じている。[8]は、Teredoプロトコルのセキュリティ上の懸念をとりまとめたI-D(Internet-Draft)[9]として起草されたが、その後、一般的なトンネリングプロトコルに対するものとして改められた。

3. トンネリング技術と既存のセキュリティ対策との親和性

  トンネリング技術は、ネットワーク上のなんらかの障壁を越えて通信を確保する技術であるため、現在一般的に使われている境界型のセキュリティシステムとは本質的な矛盾がある。特にパケットを監視、解析するネットワークベースの侵入検知システムやファイアウォールとの相性は悪く、これらに依存した管理には大きな危険性がある。

3.1 トンネルパケットの検査とフィルタリングの困難

  ネットワークベースのセキュリティシステムは、ネットワークを通過するパケットを監視・解析することで通信を分類し、ポリシにしたがって不正な通信を検知、フィルタする。しかし、トンネル通信のパケットは一般のUDPパケットやHTTPパケットなど、既存のパケットのペイロードとしてカプセル化されているため、従来のアドレスやポートといったインターネットで広く公開、標準化されているパラメータでフィルタすることができない。
  この問題は、システムの負荷とも密接な関係がある。現在標準化されているパケット構造にはトンネルパケットを特定する一般的な仕組みがなく、IPv6移行のための6to4 [10]がIPヘッダ内のプロトコルフィールドで41を指定するなど、ごく限られた対応となっている。そのため各トンネル通信を解析する前に、トンネル通信そのものを特定することも困難である。しかし、全てのパケットに対してペイロードを検査し、トンネル通信があるかどうかを確認するのは明らかに非現実的である。
  また、このことは、トンネリングプロトコル毎に個別の解析ロジックを追加する必要があることも意味している。トンネリングプロトコルの設計に一般的な仕組みがないため、IETF等で標準化されたプロトコル以外にも多くの詳細が公開されていないプロトコルも存在している。したがって、対象のトンネリングプロトコルに対応するロジックが実装されるまで、対象の通信の解析ができないというシグネチャ型のウイルス対策と同様の問題をもたらす。現在これらのセキュリティシステムを頻繁に更新するような運用は一般的ではなく、このセキュリティ上の空白は長期にわたることもあり得る。さらにはトンネリングプロトコルがパケットペイロードを利用するため、ペイロードが暗号化された場合にはネットワークベースのセキュリティシステムにできることは、ほとんどない。

3.2 トンネリング通信の監視・管理の課題

  ネットワークベースのセキュリティシステムは集中管理が容易であるため、広く利用されているが、トンネル通信に対しては前節で述べた理由により本質的に適用が難しい。また、トンネリング技術は、ネットワークへの出入り口を新たに設置することと同義となるため、原則としてトンネルの終端地点には、セキュリティ対策が必要となる。
  例えば、今日、ネットワークの境界では入ってくるパケットの宛先アドレス、出て行くパケットの発信元アドレスを確認して無関係なパケットの出入りをフィルタする(Ingress/Egressフィルタ)ことが、基本的なセキュリティ対策の一環として一般化している[11]。しかし、トンネルの内部で利用されているアドレスはその外部からは隠蔽されており、これに対してフィルタを適用できるのはトンネルの終端があるサーバ上となる。Teredoを規定している[4]でもローカルファイアウォールの利用を推奨している。
  つまり、前節で指摘した様々なトンネリングプロトコルへの対応、暗号化に対する問題など、トンネリング技術に対するセキュリティ対策には、トンネルの終端地点の管理とそこへのセキュリティ対策が重要となる。組織内でトンネリング技術を利用する際にはネットワーク境界をまたぐようなトンネルではなく、セキュリティ境界でトンネルを終端させるような手法が望ましい。
  例えば、IPv6への移行技術としてトンネリングを利用する場合は、ネットワーク内ではトンネルを利用せずネイティブのIPv6を利用することでトンネルがセキュリティ境界を跨がないようにするか、もしくはトンネルを利用する場合でも(IPv6アクセスのある)組織内のルータで終端させ既存のセキュリティ境界と整合させることが望ましい。
  一方でトンネルの終端地点の管理は大きな課題である。トンネリング技術は容易に利用でき、構築に特別な機器や技術を必要としない。そのためネットワーク管理者がその存在をすべて知ることが困難であり、さらにそれらすべてに適切なポリシを適用することは困難である。

4. トンネリング技術がNATにもたらす影響

  トンネリング技術の多くは、コネクションを持たないUDPを基盤にするなど、NATを通過することを前提とし、いくつかはさらに積極的な機能も備えている。このことは元々十分ではないNATのフィルリング機能をより脆弱にする結果となっている。

4.1 NATを越えるトンネリングによる曝露領域の拡大

  トンネリング技術が開けるNATの穴によって、攻撃にさらされる部分が広がる。特にインターネットからのアクセスを受け入れるトンネリングは、恒常的にNATに開けられた穴から攻撃をうける可能性がある。このとき、通常のTCP/IPスタックとインタフェース以外にトンネルインタフェースおよびトンネルの内部ネットワークの実装の脆弱性も攻撃対象となりえる。例えばIPv4によるIPv6のトンネリングでは、両バージョンのIPプロトコルスタックの脆弱性が攻撃の対象となりえる。

4.2 NATフィルタ効果の脆弱化

  NATによるフィルタリング効果は見かけ上のものであるため、NATが外部と内部をつなぐために管理している対応関係の情報があれば、外部から内部に対してもパケットを送信することが可能となる。
  そしてトンネリングによるNATの穴は、他の一般的な通信があける穴よりも知られ易い。トンネル通信は通信の維持時間が長く、その分使われているポート情報が発見される危険性が高くなる。また、Teredoなどいくつかのプロトコルでは、クライアントのIPv6アドレスがNATの外側のIPv4アドレスとポート番号を含んでいる。そのためIPヘッダによってNATの利用状況が漏洩する危険性がある。
  さらにTeredoではNATを超える通信を確立するために、Bubbleパケットと呼ばれる手法を利用してある種の成りすましを実行することで、NATを越えて任意の相手との通信を可能としている。これはIPアドレスによる接続制限を無効にし、外部からのアクセスを可能とできることを意味している。

5. トンネリング技術の悪用

  6to4やTeredoなどのトンネリングプロトコルにおいては、使用するアドレスが定義されているため、そのアドレスの利用から、トンネルの存在と、そのプロトコル種別を類推することが可能となる。また、トンネリング技術は特定のプラットフォームだけで利用できるものもあり、例えばTeredoを利用していることが特定されれば、そのプラットフォームがWindowsであることなどが実際にアクセスすることなく特定できる。
  一方で、利用者にとっては、トンネルサーバを全面的に信用することは様々なフィッシングのリスクにさらされることを意味している。トンネル通信を利用しているかどうかはアプリケーションレベルではわからないため、DNS Spoofなどの方法で、クライアントのサーバ設定アドレスを変更できたとすれば、man-in-the-middle(中間者による)攻撃が成立しえる。

6. IPv6配備におけるトンネリング技術の問題点

  本章では、普及が急がれるIPv6への移行に利用されるトンネリング技術の危険性、具体的にはDoS(サービス妨害)攻撃に利用される危険性がある経路ループの問題を分析したI-D [12]を概説する。本問題は、Protocol番号41として定義されているカプセル化を利用するすべての自動トンネル技術が影響を受け、ISATAP [13]、6to4 [14]および6rd [15]を含んでいる。なお、前章までに多くの例示があるTeredoについては別のI-D [16]で論じられている。
  本攻撃は次の条件で可能になる。ふたつのルータR1とR2はそれぞれprotocol-41カプセル化を利用するトンネルインタフェースを有している。それぞれのインタフェースにはIPv4アドレスとしてIP1、IP2が割り当てられている。そして、それぞれのルータはIPv6のネイティブインタフェースを持ち、IPv6パケットを適切にフォワードする。それぞれのルータのトンネルに割り当てられたIPv4アドレスは、同じアドレスグループ(どちらもパブリック、どちらも同じ内部ネットワークのプライベートなど)に属している。言い換えればふたつのトンネルを持つIPv4ネットワークでこの攻撃が成立する。
  本攻撃は、IPv6パケットの発信元と宛先アドレスを偽装することで、IPv6ネットワーク上ではR1からR2へルーティングされるパケットが、それをカプセル化したIPv4のトンネル上では逆にR2からR1へルーティングされるようにすることで成立する。自動トンネルではトンネル用のIPv4アドレスがIPv6アドレス内に埋め込まれているため、これが可能となっている。
  本攻撃のメカニズムは下記の通り。

(1) 攻撃者は自動トンネルパケットを生成しR2が接続されているIPv6ネットワークに送信する。このパケットはIPv6の宛先をR2のトンネルインタフェースの先に相当する架空のアドレスとし、自動トンネルのためのIPv4の宛先アドレスをR1のトンネルインタフェースアドレス(IP1)とする。このとき、IPv6発信元アドレスはR1のトンネルインタフェースの先に相当する架空のアドレスとし、自動トンネルのためのIPv4の発信元アドレスをR2のトンネルインタフェースアドレス(IP2)とする。ここで意図的に偽装されているのはIPv6の宛先アドレスと発信元アドレスである。
(2) このパケットは宛先がR2のトンネルの先であると偽装されたIPv6パケットなので、IPv6ネットワーク上でR2に経路制御される。受け取ったR2はそれをトンネルインタフェースに転送し、対応するIPv4アドレスであるIP1を宛先とするIPv4パケットでカプセル化する。このときカプセル化しているIPv4パケットの発信元はIP2となる。
(3) カプセル化しているIPv4パケットはIPv4ネットワーク上で経路制御され、R1のIPv4インタフェースに到着する。そしてトンネル経由のパケットとして処理される。
(4) IPv4パケットの発信元アドレスがIPv6の発信元アドレスに関連付けられているため、R1はそれを非カプセル化する。取り出されたIPv6パケットの宛先はR1のトンネルインタフェースの先には存在しないため、R1はそれをIPv6のネイティブインタフェースに転送する。このパケットはステップ1で攻撃者が送信したパケットなので、R2に転送される。

  上記のステップによってステップ1で生成されたパケットはR1-R2間をループし、それはIPv6パケットヘッダのHop Limitが0になるまで継続する。この攻撃は、R2はR1がIP2に関連していることがわからず、逆にR1はR2がIP1に関連していることがわからないことを利用している。なお、この攻撃はR1とR2がIPv6のネイティブインタフェースを持たず、別のトンネル経由でIPv6ネットワークに接続している場合にも成立する。これらの問題に対応するためにはIngress/Egressの運用、全トンネルインタフェースの存在の把握と管理など、セキュリティ境界としての適切な運用が必要である。

図:IPv6配備におけるトンネリング技術の問題点

7. まとめ

  本稿では、トンネリング技術のセキュリティ上の課題についての最新動向について概観するとともに、具体的な問題点の一つとして、IPv6への移行時に起こりえるトンネリング技術を利用したDoS攻撃の危険性を解説した。本格的なIPv6への移行期を迎え、トンネリング技術は強力なツールであるが、その運用にはNATへの過信も含めたセキュリティ体制の見直しが不可欠であるといえる。

以上

参考文献

[1]

太田 耕平, Glenn Mansfield, KEENI, 「IPv6ネットワークにおけるローカルネットワークの保護」,IPA 情報セキュリティ技術動向調査(2010 年上期),2010年9月.
  http://www.ipa.go.jp/security/fy22/reports/tech1-tg/a_06.html

[2]

G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, “Local Network Protection“, RFC 4864, May 2007.
  http://tools.ietf.org/html/rfc4864

[3]

D. Thaler, G. Lebovitz, “IAB Thoughts on IPv6 Network Address Translation”, RFC 5902, July 2010.
  http://tools.ietf.org/html/rfc5902

[4]

Huitema, C., "Teredo: Tunneling IPv6 over UDP through, Network Address Translations (NATs)", RFC 4380, February 2006.
  http://tools.ietf.org/html/rfc4380

[5]

Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
  http://tools.ietf.org/html/rfc2661

[6]

Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling, Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
  http://tools.ietf.org/html/rfc3931

[7]

社団法人日本ネットワークインフォメーションセンター,「IPv4アドレスの在庫枯渇に関して」,2011年2月3日.
  http://www.nic.ad.jp/ja/ip/ipv4pool/

[8]

S. Krishnan, D. Thaler, J. Hoagland, “Security Concerns With IP Tunneling”, Internet-Draft, October 25, 2010.
  http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-security-concerns-04

[9]

J. Hoagland, S. Krishnan, “Teredo Security Concerns”, Internet-Draft, February 25, 2008.
  http://tools.ietf.org/html/draft-ietf-v6ops-teredo-security-concerns-02

[10]

B. Carpenter, K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, February 2001.
  http://tools.ietf.org/html/rfc3056

[11]

P. Ferguson, D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”, RFC 2267, BCP 38, May 2000.
  http://tools.ietf.org/html/rfc2267
日本語訳:「ネットワーク境界におけるフィルタリング:IP ソース アドレスを偽ったサービス妨害攻撃をくじく」,RFC 2267.
  http://www.ipa.go.jp/security/rfc/RFC2267JA.html

[12]

G. Nakibly, F. Templin, “Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations”, Internet-Draft, February 04, 2011.
  http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops-03

[13]

Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
  http://tools.ietf.org/html/rfc5214

[14]

Carpenter, B. and K. Moore, "Connection of IPv6 Domains, via IPv4 Clouds", RFC 3056, February 2001.
  http://tools.ietf.org/html/rfc3056

[15]

Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
  http://tools.ietf.org/html/rfc5969

[16]

F. Gont, “Mitigating Teredo Rooting Loop Attacks”, Internet-Draft, September 8, 2010.
  http://tools.ietf.org/html/draft-gont-6man-teredo-loops-00

 

目次へ