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