ネットワーク WG
Request for Comments: 2827
廃止: 2267
BCP: 38
分類: ベストカレントプラクティス

P. Ferguson
Cisco Systems, Inc.
D. Senie
Amaranth Networks Inc.
2000年 5月

English

ネットワークのイングレスフィルタリング:
(Network Ingress Filtering:)

 発信元 IP アドレスを偽ったサービス妨害攻撃をくじく
(
Defeating Denial of Service Attacks which employ IP Source Address Spoofing)

このメモの位置づけ

本書は、インターネットの「現時点における最善の実践( Best Current Practices )」をインターネットコミュニティのために規定し、改善のために議論や示唆を要求するものです。このメモの配布に制限はありません。

著作権表記

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

要旨

最近のソースアドレスを偽った様々なサービス妨害攻撃(DoS 攻撃)の発生によって、インターネットサービスプロバイダー(ISP)や、インターネットコミュニティ全体にとって、困った論点であることが明らかになってきました。 本書では、サービス妨害攻撃をはばむ、境界における トラフィックフィルタリングを使用するための単純で、効果的かつ単刀直入な手法について検討します。サービス妨害攻撃においては、インターネットサービスプロバイダー(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 フラッディング問題を単純化した図を、次に示します。:

                                                    204.69.207.0/24
    ホスト <----- router <--- Internet <----- router <-- 攻撃者

             TCP/SYN
         <---------------------------------------------
               Source: 192.168.0.4/32
    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

[etc.]

想定:

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

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

DP や 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 アドレス)に送られるトラフィックを制限することによって、机上では、この攻撃のシナリオにおけるソースアドレススプーフィングの問題は、根絶されることになります。


                               11.0.0.0/8
                                   /
                               router 1
                                 /
                                /
                               /                        204.69.207.0/24
         ISP <----- ISP <---- ISP <--- ISP <-- router <-- 攻撃者
          A           B          C         D          2
                    /
                   /
                  /
              router 3
                /
            12.0.0.0/8

上記の例で、攻撃者は、204.69.207.0/24 の中におり、そのインターネット接続は、ISP である D によって与えられています。攻撃者のネットワークとの接続を提供する、"router 2"の境界( input ) リンク上のインプット トラフィック フィルタは、204.69.207.0/24 プリ フィックスの範囲内の発信元アドレスからのものだけを許すように トラフィックを制限し、攻撃者が、このプリフィックスの範囲外の 「不正な」発信元アドレスを使用することを防ぎます。

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

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

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

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

 

4. ネットワーキング機器について他の可能性 English

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

我々は、[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

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

 

9. 参考文献

[1] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks
1996年 9月24日.
 
[2] B. Ziegler,
"Hacker Tangles Panix Web Site",
Wall Street Journal, 1996年 9月12日.
 
[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.
Second Edition が出版されている。)
「ファイアウォール」;
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, 1996年 2月.
 
[5] The North American Network Operators Group;
http://www.nanog.org.
 
[6] Perkins, C.,
"IP Mobility Support",
RFC 2002, 1996年10月.
 
[7] Montenegro, G.,
"Reverse Tunneling for Mobile IP",
RFC 2344, 1998年 5月.
 
[8] Baker, F.,
"Requirements for IP Version 4 Routers",
RFC 1812(English), 1995年 6月.
 
[9] Craig Huegen 氏に感謝。; 次を見よ。
http://www.quadrunner.com/~chuegen/smurf.txt. (現在リンク切れ)

10. 著者のアドレス

Paul Ferguson
Cisco Systems, Inc.
13625 Dulles Technology Dr.
Herndon, Virginia 20170 USA

EMail: ferguson@cisco.com

Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740 USA

EMail: dts@senie.com

翻訳者のアドレス

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

EMail: miyakawa@ipa.go.jp

 

11. 著作権表記全文

Copyright (C) The Internet Society (2000). 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.

謝辞

RFC 編集者のための資金は現在、Internet Society によって提供されています。