|
ネットワーク WG Request for Comments： 2827 廃止： 2267 BCP： 38 分類： ベストカレントプラクティス |
P. Ferguson Cisco Systems, Inc. D. Senie Amaranth Networks Inc. 2000年5月 |
本書は、 インターネットの「現時点における最善の実践( Best Current Practices )」をインターネットコミュニティのために規定し、 改善のために議論や示唆を要求するものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2000). All Rights Reserved.
最近のソースアドレスを偽った様々なサービス妨害攻撃(DoS攻撃)の発生によって、 インターネットサービスプロバイダー(ISP)や、 インターネットコミュニティ全体にとって、 困った論点であることが明らかになってきました。 本書では、サービス妨害攻撃をはばむ、 境界におけるトラフィックフィルタリングを使用するための単純で、 効果的かつ単刀直入な手法について検討します。 サービス妨害攻撃においては、 インターネットサービスプロバイダー(ISP)の集合ポイントの「向こう」から発せられたように偽ったIPアドレスが使用されます。
インターネット上の様々な標的を狙ったサービス妨害攻撃[1]の再起は、 インターネットサービスプロバイダー(ISP)や、 ネットワークセキュリティコミュニティにおいて、 この種の攻撃を鎮静化するための新しく、革新的な手法を発見する、 という新たな挑戦の機会を与えました。 この目標の達成は、極めて困難です。 こうした攻撃の有効性や範囲を制限する単純なツールは既にありますが、 それらは、まだ広く実装されていません。
この攻撃手法は、以前から知られていました。 しかし、これを防ぐことは、現在でも関心を集めていることです。 Bill Cheswick 氏が、[2] の記事で登場しました。 そこで彼は、現状では、 攻撃を受けているシステムの管理者が効果的にシステムを防御する方法はないということで、 自身の著書である "Firewall and Internet Security" [3] の一節から述べています。 彼は、この手法を紹介し、これを使用することを強く薦めようとしていました。
本書において検討されるフィルタリング手法では、 正当なプリフィックス(IPアドレス)からのフラッディング(洪水)攻撃に対しては全く何もしませんが、 起点となったネットワークの中にいる攻撃者が、 境界におけるフィルタリングルールに合わない偽ったソースアドレスを使用して、 この種の攻撃を仕掛けることを防ぎます。 攻撃者が、正規に通知されているプリフィックス(IPアドレス)の範囲内にない、 偽った発信元アドレスを使用することをはばむために、 すべてのインターネット接続プロバイダーには、 この文書に記述されたフィルタリングを実装することが強く薦められます。 いいかえれば、ISPが、 複数のダウンストリームネットワークの経路情報を持っている場合、 これらの経路情報以外から来たトラフィックを防ぐために、 厳格なトラフィックフィルタリングが使用される必要があります。
この種のフィルタリングを実装することの利点には、他に、 「発信者の本当の発信元を容易に追跡することができるようになること」があります。 それは、攻撃者は、正規の、 実在する到達可能な発信元アドレスを使用する必要があるからです。
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] をご覧ください。
この種の攻撃によってもたらされる問題は様々であり、 短期的にはホストソフトウェア実装、ルーティング方式、 そして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 パケットを拒絶する
ネットワーク管理者は、 棄却されたパケットの情報のログをとる必要があります。 これによって、疑わしい行為を監視するための基礎を提供します。
将来のプラットフォーム実装について、 追加的な機能も考慮される必要があります。 下記のものが注目に値します。：
我々は、[8] に述べられているように、 ルーターも発信者の発信元IPアドレスを検証すると想定してきました。 しかしその手法は、今日の実際のネットワークでは、うまく働きません。 述べた手法とは、そのアドレスへの折り返しの経路は、 到着したパケットと同一のインターフェイスを流れると想定して発信元アドレスを読む、 というものです。 インターネット中には、非対称な経路が数多くあるので、これには、 明らかに問題があるといえます。
フィルタリングには、その性質上、 ある種の「特別な」サービスを行えなくする可能性があります。 しかし、この種の特別なサービスを提供しているISPにとっては、 これらのサービスを実装することの代替手法を検討することが、 境界でのトラフィックフィルタリングの影響を受けることを避けるためには最も有益です。
[6] で定義されているMobile IPは、特に、 境界でのトラフィックフィルタリングによって影響を受けます。 規定されているように、 モバイルノードへのトラフィックはトンネルされますが、 モバイルノードからのトラフィックはトンネルされません。 その結果、モバイルノードからのパケットは、 その発信元アドレスを持っており、 そのホストが接続されているネットワークのものと一致しないことになります。 Mobile IPワーキンググループでは、 [7] で「リバーストンネル」を定義することによって、 この問題に対応しています。 この進行中の作業によって、 モバイルノードから転送されたデータがインターネットに転送される前に、 ホームエージェントをトンネルさせられる手法が提供されることになっています。 リバーストンネリングのスキームには、 マルチキャストトラフィックのより良い扱い方など、他の利益もあります。 Mobile IPシステムを実装している方は、 このリバーストンネリングの手法を実装することが強く推奨されています。
既に述べたように、境界トラフィックフィルタリングは、 顕著に発信元アドレススプーフィングの可能性を減らしますが、 攻撃者が許されているプリフィックスフィルタの範囲内の、 偽った他のホストのソースアドレスを使用することをはばむものではありません。 しかし、この種の攻撃が本当に起きた場合、 これによってネットワーク管理者は、 その攻撃が示しているプリフィックスの範囲内から、 実際に行われていることを確信することができます。 これによって犯罪者を追跡するのは単純になります。 また、最悪の場合、この問題が解決されるまでは、その管理者は、 発信元アドレスの範囲をブロックすることができます。
境界におけるフィルタリングが、 DHCPもしくはBOOTPが使用されている環境で使用されている場合、 ネットワーク管理者には、0.0.0.0の発信元アドレスと、 255.255.255.255の到着先アドレスをもったパケットが、 ルーターの中のリレーエージェントに到達するのが適切であれば、 そのようになっていることを確認することが薦められます。 指示されたブロードキャストの複製のスコープは、 コントロールする必要がありますが、勝手に転送されてはなりません。
インターネットに接続されたネットワーク外辺における境界におけるトラフィックフィルタリングは、 発信元アドレススプーフィングを行うサービス妨害攻撃の有効性を減らします。 ネットワークサービスプロバイダーや管理者は、既に、 外辺のルーターに、この種のフィルタリングを実装し始めています。 そして、すべてのサービスプロバイダーには、できるだけ早く、 そのようにすることが推奨されます。 インターネットコミュニティ全体として、 この攻撃手法を撃退することによって救済することに加えて、 サービスプロバイダーのネットワークが、 既に顧客とのリンクに境界フィルタリングを搭載していることを証明することができる場合には、 攻撃元に位置するサービスプロバイダーを支援することもできます。
企業のネットワーク管理者は、 彼らの企業ネットワークがそのような問題の起点とならないようにフィルタリングを実装する必要があります。 まさに、フィルタリングは、組織体の内部で、 ユーザが不正にシステムをよそのネットワークに接続することによって問題を引き起こさないようにするために使用することができるのです。
実践において、フィルタリングは、不満を持った従業員が、 匿名の攻撃をすることを防ぐこともできます。
不覚に、この種の攻撃の発信元にならないようにすることは、 すべてのネットワーク管理者の責任です。
本書の主な意図は、性質上、 インターネットコミュニティ全体のセキュリティ実践や理解を高めることにあります。 なぜならば、より多くのインターネットプロバイダーや、 企業のネットワーク管理者が、境界フィルタリングを実装することによって、 攻撃者が攻撃手法として偽ったソースアドレスを使用することを顕著に減少するであろうからです。 攻撃の発信元を追跡することは、発信元が「正規」のものであれば、 単純になります。 インターネット全体として攻撃の件数と頻度を減少させることによって、 いつかは起きる重要な攻撃を追跡するための、 より多くの資源が留保されることでしょう。
NANOG (North American Network Operators Group) [5] は、 これらの論点をオープンに検討する際に、 活発に可能な解決策を探求してくださった信頼に値するグループです。 また、コメントし、貢献して下さった、 Justin Newton 氏 [Priori Networks] と Steve Bielagus 氏 [OpenROUTE Networks, Inc.] に感謝します。
| [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. (現在リンク切れ) |
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
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によって提供されています。