ネットワーク WG
Request for Comments: 2267
分類: 情報提供
P. Ferguson
Cisco Systems, Inc.
D. Senie
BlazeNet, Inc.
1998年 1月

English

ネットワーク境界におけるフィルタリング:
IP ソース アドレスを偽ったサービス妨害攻撃をくじく

(Network Ingress Filtering)

このメモの位置づけ

このメモは、インターネット コミュニティのために情報を提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布は、無制限です。

著作権表記

Copyright (C) The Internet Society (1998). All Rights Reserved.

概要

最近のソース アドレスを偽った様々なサービス妨害攻撃( DoS 攻撃)の発生によって、インターネット サービス プロバイダーや、インターネット コミュニティ全体にとって、困った論点であることが明らかになってきました。この文書では、DoS 攻撃をはばむ、境界でのトラフィック フィルタリングを使用するためのシンプルで、効果的で、単刀直入な手法について検討いたします。DoS 攻撃では、インターネット サービス プロバイダー(ISP)の集合ポイントの「向こう」から発せられたように偽った IP アドレスが使用されます。

目次

1. はじめに
2. 背景
3. 偽ったトラフィックを制限する
4. 他のネットワーク機器について
5. 義務
6. 要約
7. セキュリティに関する考慮事項
8. 注意事項
9. 参考文献
10. 著者のアドレス
11. 著作権表記全文

1. はじめに (English)

インターネット上の様々な標的をねらったサービス妨害攻撃 [1]の再起は、インターネット サービス プロバイダー (ISP) や、ネットワーク セキュリティ コミュニティにおいて、この種の攻撃を鎮静化するための新しく、革新的な手法を発見する、という新たな挑戦の機会を与えました。この目標の達成は極めて困難です。こうした攻撃の有効性や範囲を制限するシンプルなツールは既にありますが、それらは、まだ広く実装されていません。

この攻撃手法は、以前から知られていました。しかし、これを防ぐことは、現在でも関心を集めていることです。Bill Cheswick 氏が、[2] の記事で登場しました。そこで彼は、現状では、攻撃を受けているシステムの管理者が効果的にシステムを防御する方法はないということで、自身の著書である "Firewall and Internet Security" [3] の一節から述べています。彼は、この手法を紹介し、これを使用することを強く薦めようとしていました。

この文書で検討されるフィルタリング手法では、正当なプリフィックス( IP アドレス)からのフラッディング(洪水)攻撃に対しては全く何もしませんが、起点となったネットワークの中にいる攻撃者が、境界でのフィルタリング ルールに合わない偽ったソース アドレスを使用して、この種の攻撃を仕掛けることを防ぎます。攻撃者が、正規に通知されているプリフィックス( IP アドレス)の範囲内にない、偽った発信元アドレスを使用することをはばむために、すべてのインターネット接続プロバイダーには、この文書に記述されたフィルタリングを実装することが強く薦められます。いいかえれば、ISP が、複数のダウンストリーム ネットワークの経路情報を持っている場合には、これらの経路情報以外から来たトラフィックを防ぐために、厳格なトラフィック フィルタリングが使用される必要があります。

この種のフィルタリングを実装することの利点には、他に、発信者の本当の発信元を容易に追跡することができるようになることがあります。それは、攻撃者は、正規の、実在する到達可能な発信元アドレスを使用する必要があるからです。

2. 背景  (English)

TCP SYN フラッディング問題を単純化した図を、下記に示します。
                                                       9.0.0.0/8
    host <----- router <--- Internet <----- router <-- attacker

             TCP/SYN
         <---------------------------------------------
               Source: 192.168.0.4/32
想定:

同様に述べなければならないのは、発信元アドレスが、グローバル ルーティング テーブルにある、他の正規のネットワークの中から来ているかのように偽っている場合です。例えば、正規のネットワーク アドレスを使用している攻撃者は、実際には全く無実の組織体から攻撃しているように見せかけることによって、騒動を浴びさせることができてしまいます。このような場合、攻撃を受けているシステムの管理者は、外見上の攻撃元から来る、すべてのトラフィックをフィルタしようとすることでしょう。このようなフィルタを追加することによって、正規の、悪意のないエンド システムに対して、サービス妨害を行うことになってしまいます。この場合、攻撃を受けているシステムの管理者は、意図的ではなくとも、攻撃の共犯となってしまいます。

さらにややこしいことに、TCP SYN フラッド(洪水)攻撃は、この攻撃とは関係のない、ひとつ、ないし複数のホストに SYN-ACK パケットを送ることになってしまい、2 次的な被害者となります。これによって攻撃者は、複数のシステムを同時に悪用することができてしまいます。

UDP や ICMP フラッディングを使用した同様の攻撃が、試みられてきました。前者の攻撃( UDP フラッディング)は、他のサイトの echo UDP サービスへの chargen UDP サービスを試し、接続する偽造されたパケットを使用します。システム管理者は、決して UDP パケットが、システムの診断( diagnostic )ポートに、管理ドメインの外部から到達することを許してはなりません。後者の攻撃 (ICMP フラッディング)は、IP サブネット ブロードキャスト複製機構にある裏機能を使用します。この攻撃は、ルーターがネットワークに、( 10.255.255.255 宛てのような)IP ブロードキャスト アドレスを第 2 層のブロードキャストのフレーム(イーサーネットの場合 FF:FF:FF:FF:FF:FF )にする、広範なマルチアクセス ブロードキャストを提供することに依拠しています。イーサーネット NIC ハードウェア( MAC 層ハードウェア)は、通常のオペレーションにおいては、そのハードウェア宛てのアドレスをもったパケット選択するために読み取ります。通常の運用において、すべてのデバイスが共有する唯一の MAC アドレスが、メディア ブロードキャスト、もしくは FF:FF:FF:FF:FF:FF です。デバイスがリンク層でブロードキャスト宛てにパケットを受け取った場合、上位層に処理の割り込みを送信するようになっています。それゆえ、こうしたブロード キャスト フレームの洪水は、エンド システムの利用可能な資源をすべて消費し尽くしてしまいます。[9] おそらく、システム管理者は、彼らの境界ルーターが、送られたブロードキャスト パケットが転送されることを許さないようになっていることの確認をするのが賢明といえるでしょう。

TCP SYN 攻撃が、到達不能なソース アドレスを使用して到達した際には、標的とされたホストは、応答を待つために、資源を予約します。攻撃者は、繰り返し、各送信パケット上の偽った発信元アドレスを変更するので、追加的なホスト資源が浪費されるのです。

一方、攻撃者が、他人の正規のホスト アドレスを発信元アドレスとして使用している場合には、攻撃されているシステムは、コネクションを確立するシーケンスの送り元と信じるところに膨大な数の SYN/ACK パケットを送信してしまいます。 このようにして、攻撃者は、宛先の標的システムと、実際にグローバル ルーティング システムに偽ったアドレスを使用しているシステムの 2 つのシステムにダメージを与えるのです。

両方の攻撃手法の結果、パフォーマンスが著しく低下し、さらに悪い場合にはシステムがクラッシュします。

この脅威に対応して、大部分のオペレーティング システム ベンダーは、標的とされたサーバーが、非常に高い頻度でコネクションを試みてくる攻撃を保留できるように自社のソフトウェアを改良しました。これは歓迎すべきことであり、この問題に対する対策として必要なことです。境界でのフィルタリングは、広く実装されて、有効になるまでに時間がかかりますが、オペレーティング システムの拡張は、早急に実装することができます。この組み合わせによって、発信元アドレス スプーフィングに対して効果的に対応することができるはずです。ベンダーやプラットフォーム ソフトウェアのアップ グレード情報については [1] をご覧ください。

3. 偽ったトラフィックを制限する  (English)

この種の攻撃によってもたらされる問題は様々であり、短期的にはホスト ソフトウェア実装、ルーティング方式、そして TCP/IP プロトコル自体などがあげられます。しかし、ダウンストリーム ネットワークから発信され、既知の広告されたプリフィックス( IP アドレス)に送られるトラフィックを制限することによって、机上では、この攻撃のシナリオにおけるソース アドレス スプーフィングの問題は、根絶されることになります。
    SYN/ACK
    no route
             TCP/SYN
         <---------------------------------------------
               Source: 10.0.0.13/32
    SYN/ACK
    no route
             TCP/SYN
         <---------------------------------------------
               Source: 172.16.0.2/32
    SYN/ACK
    no route
  
上記の例で、攻撃者は、9.0.0.0/8 の中におり、そのインターネット接続は、ISP である D によって与えられています。攻撃者のネットワークとの接続を提供する、"router 2"の境界( input ) リンク上のインプット トラフィック フィルタは、9.0.0.0/8 プイフィックスの範囲内の発信元アドレスからのものだけを許すようにトラフィックを制限し、攻撃者が、このプリフィックスの範囲外の「不正な」発信元アドレスを使用することを防ぎます。

言い換えれば、上記の router 2 上の境界フィルタは、下記のチェックを行います。

IF パケットの発信元アドレスが 9.0.0.0/8 の範囲内
THEN 適切に転送する

IF パケットの発信元アドレスが範囲外
THEN パケットを拒絶する

ネットワーク 管理者は、ドロップされたパケットの情報のログをとる必要があります。これによって、疑わしい行為を監視するための基礎を提供します。

4. 他のネットワーキング機器について  (English)

将来のプラットフォーム実装について、追加的な機能も考慮される必要があります。下記のものが注目に値します。

リモートアクセス サーバーへの自動的なフィルタリングの実装があげられます。大部分の場合、アクセス サーバーにダイアルするユーザーは、1 台の PC を使った個人ユーザーです。その PC から来るパケットについて、唯一の正しい発信元ソース IP アドレスは、(静的であれ動的であれ)その ISP によって割り当てられたものです。リモートアクセス サーバーは、ユーザーが、パケット上の発信元アドレスを偽っていないことを確かめるように、すべてのパケットを境界でチェックすることができます。明らかなことですが、顧客が正規にそのネット、もしくはサブネットに接続している場合には、その用意も必要です。しかし、これは、オプションの選択肢として実装することができます。我々は、既に、この機能を実装し始めているベンダーや ISP があるという報告を受けています。

我々は、[8] に述べられているように、ルーターも発信者の発信元 IP アドレスを検証すると想定してきました。しかしその手法は、今日の実際のネットワークでは、うまく働きません。述べた手法とは、そのアドレスへの折り返しの経路は、到着したパケットと同一のインターフェイスを流れると想定して発信元アドレスを読む、というものです。インターネット中には、非対称な経路が数多くあるので、これには、明らかに問題があるといえます。

5. 義務  (English)

フィルタリングには、その性質上、ある種の「特別な」サービスを行えなくする可能性があります。しかし、この種の特別なサービスを提供している ISP にとっては、これらのサービスを実装することの代替手法を検討することが、境界でのトラフィック フィルタリングの影響を受けることを避けるためには最も有益です。

[6] で定義されている Mobile IP は、特に、境界でのトラフィック フィルタリングによって影響を受けます。規定されているように、モバイル ノードへのトラフィックはトンネルされますが、モバイル ノードからのトラフィックはトンネルされません。その結果、モバイル ノードからのパケットは、その発信元アドレスを持っており、そのホストが接続されているネットワークのものと一致しないことになります。Mobile IP ワーキング グループでは、[7] で「リバース トンネル」を定義することによって、この問題に対応しています。この進行中の作業によって、モバイル ノードから転送されたデータがインターネットに転送される前に、ホーム エージェントをトンネルさせられる手法が提供されることになっています。リバース トンネリングのスキームには、マルチキャスト トラフィックのより良い扱い方など、他の利益もあります。Mobile IP システムを実装している方は、このリバース トンネリングの手法を実装することが強く推奨されています。

すでに述べたように、境界トラフィック フィルタリングは、顕著に発信元アドレス スプーフィングの可能性を減らしますが、攻撃者が許されているプリフィックス フィルタの範囲内の、偽った他のホストのソース アドレスを使用することをはばむものではありません。しかし、この種の攻撃が本当に起きた場合、これによってネットワーク管理者は、その攻撃が示しているプリフィックスの範囲内から、実際に行われていることを確信することができます。これによって犯罪者を追跡するのは単純になります。また、最悪の場合、この問題が解決されるまでは、その管理者は、発信元アドレスの範囲をブロックすることができます。

境界でのフィルタリングが DHCP もしくは BOOTP が使用されている環境で使用されている場合、ネットワーク管理者には、0.0.0.0 の発信元アドレスと、255.255.255.255 の到着先アドレスをもったパケットが、ルーターの中のリレー エージェントに到達するのが適切であれば、そのようになっていることを確認することが薦められます。指示されたブロードキャストの複製のスコープは、コントロールする必要がありますが、勝手に転送されてはなりません。

6. 要約  (English)

インターネットに接続されたネットワーク外辺における境界でのトラフィック フィルタリングは、発信元アドレス スプーフィングを行うサービス妨害攻撃の有効性を減らします。ネットワーク サービス プロバイダーや管理者は、既に、外辺のルーターに、この種のフィルタリングを実装し始めています。そして、すべてのサービス プロバイダーには、できるだけ早く、そのようにすることが推奨されます。インターネット コミュニティ全体として、この攻撃手法を撃退することによって救済することに加えて、サービス プロバイダーのネットワークが、既に顧客とのリンクに境界フィルタリングを搭載していることを証明することができる場合には、攻撃元に位置するサービス プロバイダーを支援することもできます。

企業のネットワーク管理者は、彼らの企業ネットワークがそのような問題の起点とならないようにフィルタリングを実装する必要があります。まさに、フィルタリングは、組織体の内部で、ユーザーが不正にシステムをよそのネットワークに接続することによって問題を引き起こさないようにするために使用することができるのです。実践において、フィルタリングは、不満を持った従業員が、匿名の攻撃をすることを防ぐこともできます。

不覚に、この種の攻撃の発信元にならないようにすることは、すべてのネットワーク管理者の責任です。

7. セキュリティ関連の考慮事項  (English)

この文書の主な意図は、性質上、インターネット コミュニティ全体のセキュリティ実践や理解を高めることにあります。というのは、より多くのインターネット プロバイダーや、企業のネットワーク管理者が、境界フィルタリングを実装することによって、攻撃者が攻撃手法として偽ったソース アドレスを使用することを顕著に減少するであろうからです。攻撃の発信元を追跡することは、発信元が「正規」のものであれば、単純になります。インターネット全体として攻撃の件数と頻度を減少させることによって、いつかは起きる重要な攻撃を追跡するための、より多くの資源が留保されることでしょう。

8. 謝辞  (English)

North American Network Operators Group (NANOG) [5] は、これらの論点をオープンに検討する際に、活発に可能な解決策を探求してくださった、信頼に値するグループです。また、コメントし、貢献して下さった、Justin Newton 氏 [Priori Networks] と Steve Bielagus 氏 [OpenROUTE Networks, Inc.] に感謝いたします。

9. 参考文献  (English)

[1] CERT Advisory CA-96.21;
TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996.

[2] B. Ziegler, "Hacker Tangles Panix Web Site",
Wall Street Journal, 12 September 1996.

[3] "Firewalls and Internet Security: Repelling the Wily Hacker";
William R. Cheswick and Steven M. Bellovin,
Addison-Wesley Publishing Company, 1994; ISBN 0-201-63357-4.
「ファイアウォール」;
William R. Cheswick、Steven M. Bellovin, 監訳者 川副 博, 翻訳者 田和 勝、鎌形久美子, ソフトバンク株式会社, 1995; ISBN4-89052-672-2.

[4] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear,
"Address Allocation for Private Internets", RFC 1918, February 1996.

[5] The North American Network Operators Group;
http://www.nanog.org.

[6] Perkins, C., "IP Mobility Support",
RFC 2002, October 1996.

[7] Montenegro, G., "Reverse Tunneling Mobile IP",
Work in Progress.

[8] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.

[9] Thanks to: Craig Huegen;
See: http://www.quadrunner.com/~chuegen/smurf.txt.

10. 著者のアドレス  (English)

Paul Ferguson
cisco Systems, Inc.
400 Herndon Parkway
Herndon, VA USA 20170

EMail: ferguson@cisco.com

Daniel Senie
BlazeNet, Inc.
4 Mechanic Street
Natick, MA USA 01760

EMail: dts@senie.com

翻訳者

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp

11. 著作権表記全文  (English)

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.