Network Working Group P. Ferguson Request for Comments: 2267 Cisco Systems, Inc. Category: Informational D. Senie BlazeNet, Inc. January 1998 ネットワークの進入フィルタリング： IP 始点アドレスを偽装したサービス妨害攻撃を阻止する このメモの位置付け このメモは，インターネット共同体への情報提供である．インターネット の標準等を定めようとするものでは無い．このメモの配付は無制限に行っ て良い． 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. 概要 始点アドレスの偽装による，最近の様々なサービス妨害攻撃（Denial of Service (DoS) attacks）は，インターネット・サービス・プロバイダやイ ンターネット社会全体の頭痛の種となっている．この文書では，進入トラ フィックをフィルタリングすることで， DoS 攻撃を阻止するための，単純・ 効果的かつ直接的な方法を論じる．この DoS 攻撃は，インターネット・サー ビス・プロバイダ (ISP) 接続点の「背後」から IP アドレスを偽装して侵 入してくるものである． 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 2. 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. 偽装トラフィックの制限 . . . . . . . . . . . . . . . . . . 4. ネットワーク装置に関する今後の機能 . . . . . . . . . . . . 5. 責任 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. 要約 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. 安全性に関する考察 . . . . . . . . . . . . . . . . . . . . 8. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . 9. 参照文献 . . . . . . . . . . . . . . . . . . . . . . . . . 10. 著者の住所 . . . . . . . . . . . . . . . . . . . . . . . . 11. 著作権表示全文 . . . . . . . . . . . . . . . . . . . . . . 1. はじめに インターネット上の様々な標的に向けられるサービス妨害攻撃の復活 [1] により，インターネット・サービス・プロバイダ (ISP) やネットワークの 安全性を求める共同体内に，この種の攻撃を鎮静するための，新しい革新 的な方法の発見に挑戦する人々が増えている．この目的を達するには多く の困難がある．これらの攻撃の効果や範囲を小さくするツールは，すでに いくつか出ているが，それを実装している機器は少ない． 攻撃方法はすでに知られてきている．しかし，防御対策については，まだ 懸念が続いている．[2] で引用されている Bill Cheswick は，彼の著書で ある "Firewalls and Internet Security" [3] のある章を引いて，攻撃に さらされているシステムの管理者が，有効に防御する対策に尽きた時にど うするかを述べている．彼は上記の攻撃方法に言及して，攻撃が実行され ることを懸念している． 本文書で議論するフィルタリング方法は，正当なプレフィックス（ IP ア ドレス）から発信される攻撃に対しては何の防御もできない．しかし，偽 装始点アドレスを使うこの種の攻撃を，別の発信源ネットワークにいる攻 撃者が行うことについては，進入フィルタリング・ルールで阻止できるだ ろう．インターネットに接続する全プロバイダが，本文書で説明するフィ ルタリングを実装することを推奨する．これにより，正当なプレフィック スを逸脱した，偽装始点アドレスを使う攻撃者を阻止できる．別な言い方 をすれば，複数の downstream ネットワークからルーティング情報を集め ている ISP の場合は，これらのルーティング情報から逸脱したアドレスか らのトラフィックを禁止するために，厳密なトラフィック・フィルタリン グを用いるべきである． この種のフィルタリングを実装するもう一つの利点は，攻撃者は適切な， 合法的に reachable である始点アドレスを使わざるを得ないので，その発 信者の真の発信源を簡単に追跡できることである． 2. 背景 TCP SYN flooding 問題の簡略化した図を以下にあげる： 9.0.0.0/8 host <----- router <--- Internet <----- router <-- attacker 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.] 仮定： o "host" は標的にされたマシン． o 攻撃者は「正当な」プレフィックス 9.0.0.0/8 内にいる． o 攻撃者は始点アドレスをランダムに変化させて攻撃する．上の例では， 始点アドレスは [4] の中から抜き出しており，通常のグローバル・イ ンターネット・ルーティング・テーブルには存在しないアドレスなので， unreachable になる．しかし，この攻撃を実行するためには，どんな unreachable なプレフィックスも使うことができる． グローバル・ルーティング・テーブルにある別の正当なネットワークから 発信されたように，始点アドレスを偽装した場合も述べておく必要がある だろう．たとえば，攻撃者は，実際には攻撃の発信源ではない無実な組織 から攻撃が発信されたように見せ掛けることで，正当なネットワークアド レスを使って混乱をひき起こすことができるだろう．この場合，攻撃にさ らされているシステムの管理者は，見せかけの攻撃源から来る全てのトラ フィックをフィルタしようとするかも知れない．このフィルタを付け加え ると，正当な，真の敵ではない末端システムが，サービスを拒否されてし まうことになる．つまり，攻撃にさらされているシステムの管理者は，知 らない内に攻撃の共犯者になってしまう． さらに複雑なことに， TCP SYN flood 攻撃では，この攻撃とは何の関係も ない，一つないしは多くのホストに SYN-ACK パケットが送られることにな る．これらのホストは二次的な被害者である．攻撃者は，２つ以上のシス テムを一度に混乱させたことになる． 同様な攻撃は UDP や ICMP flooding を使って試みられている．前者の攻 撃 (UDP flooding) は， UDP サービスに接続する偽装パケットを使い，別 のサイトに UDP サービスのエコーを投げ付けさせようとするものである． システム管理者は，管理ドメイン外から，システム診断用のポートに向け た UDP パケットを，＊決して＊システムに到達させてはならない．後者の 攻撃 (ICMP flooding) は， IP サブネット・ブロードキャスト複製機能を 巧妙に利用する．この攻撃は，大きなマルチ・アクセス・ブロードキャス ト・ネットワークを受け持っているルータが， IP ブロードキャスト・ア ドレス（ 10.255.255.255 宛てのような）を第二層のブロードキャスト・ フレーム（イーサネットでは FF:FF:FF:FF:FF:FF ）に組み直す働きを利用 している．イーサネットの NIC ハードウェア（特に MAC 層のハードウェ ア）は，通常の動作では特定の番号のみを聞くようになっている．通常の 動作で，全ての装置が共有する MAC アドレスは，メディア・ブロードキャ スト，つまり FF:FF:FF:FF:FF:FF である．この場合，装置はそのパケット を受け取り，処理プログラムにインタラプト・シグナルを送る．ゆえに， これらブロードキャスト・フレームの flood は，末端システムの全リソー スを浪費させてしまう [9]．システム管理者は，デフォルトでは境界ルー タは directed ブロードキャストをフォワードしないように設定しておく のが賢明だろう． TCP SYN 攻撃の始点アドレスが unreachable であった場合，標的になった ホストはレスポンスを待つためのシステム・リソースを確保しようとする． 攻撃者は連続してパケットを送る度に始点アドレスを変更し，ホストのリ ソースを食い潰してしまう． また，攻撃者が始点アドレスとして，別の実際にあるホストのものを使う と，攻撃にさらされているシステムは，コネクション確立シーケンスの送 信元だと思い込まされているホストに，大量の SYN/ACK パケットを送ろう とする．このようにして，攻撃者は２つのシステム，すなわち攻撃対象の システムと，グローバル・ルーティング・システムにある偽装アドレスを 実際に使っているシステム，に被害を与える． 上記の攻撃方法により，システムはパフォーマンスの深刻な低下を招くか， もしくはクラッシュしてしまう． 攻撃の脅威に対応して，ほとんどのオペレーティング・システム・ベンダ は，高頻度の攻撃ににも持ちこたえることができるようにソフトウェアを 変更している．問題を解決するための一部としては，有効で歓迎すべきこ とである．進入フィルタリングは，実装が普及し，十分な効果を得るため には時間がかかるが，オペレーティング・システムの機能拡張はすぐにで きる．両者の対策をあわせて，始点アドレス偽装攻撃対策として効果があ がるはずである．ベンダとプラットフォーム・ソフトウェアのアップグレー ド情報については [1] を参照されたい． 3. 偽装トラフィックの制限 この種の攻撃で浮かび上がる問題は多く，ホスト上のソフトウェアの欠陥 から，ルーティング方法， TCP/IP プロトコル自体の問題まである．しか し， downstream ネットワークから，既知のプレフィックスへ送信される 通過トラフィックを制限することにより，攻撃で始点アドレス偽装を使う ことは，実質的に不可能になるだろう． 11.0.0.0/8 / router 1 / / / 9.0.0.0/8 ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker A B C D 2 / / / router 3 / 12.0.0.0/8 上記の例では，攻撃者は 9.0.0.0/8 にいて， ISP D を通じてインターネッ トに接続している．攻撃者の属するネットワークからの接続がある「ルー タ 2 」の進入（入力）リンク上での入力トラフィック・フィルタは， 9.0.0.0/8 の範囲内の始点アドレスをもつトラフィックのみ通過を許し， 攻撃者が，範囲外の始点アドレスを使えないようにする． つまり，上の例の「ルータ 2 」の進入フィルタは以下のチェックを行う： もし　　　パケットの始点アドレスが 9.0.0.0/8 の範囲内 ならば　　適切なパケットとしてフォワードする もし　　　パケットの始点アドレスがそれ以外 ならば　　拒否する ネットワーク管理者は，拒否したパケットの記録を残しておくべきである． この記録は，疑わしい活動をモニタする基礎資料となる． 4. ネットワーク装置に関する今後の機能 将来の装置実装では，更に以下の機能を考慮すべきである．これは，注目 しておく価値がある． o リモート・アクセス・サーバ上での自動フィルタリングの実装．アク セス・サーバには，大抵の場合，一台の PC から一人の利用者が電話 接続してくる．当該 PC から出されるパケットの，ただ一つの IP ア ドレスは，（それが静的でも，動的でも） ISP から割り当てられる ものの一つである．リモート・アクセス・サーバは，全ての進入パケッ トをチェックし，彼が送信するパケットが始点アドレスを偽装してい ないか，確かめることができる．もちろん利用者がリモート・ルータ を使って正式にネット，サブネットとして接続してきた場合の対応も 準備しておくべきだが，これについては，オプションのパラメータと して実装した方が良いだろう．我々は，いくつかのベンダと ISP が， この機能をすでに実装し始めているとの報告を受けている． 我々は， [8] の提案のように，ルータが送信者の始点 IP アドレスの認証 をするよう提案しようとも考えたが，この方法は，現実のネットワークで はうまく機能しないだろう．その方法とは，始点アドレスを参照して，当 該アドレスの戻り経路が，パケットが届いたのと同じインターフェースを 通ることを確かめる，というものである．しかし，複数の経路が存在する 現在のインターネットにおいては，明らかに問題が多い． 5. 責任 このフィルタリングで，ある種の「特別な」サービスが使えなくなるかも 知れない． しかし， ISP がこの特別なサービス機能をを使いたいと思う なら，進入トラフィック・フィルタリングに影響を受けないような，別の 実装を考えた方が良い． [6] で定義されているモービル IP は，進入トラフィック・フィルタリン グに特に影響を受ける．仕様では，モービル・ノードへのトラフィックは トンネルされるが，モービル・ノードからのトラフィックはトンネルされ ない．その結果，モービル・ノードからのパケットは，基地局に割り当て られているアドレスとは異なった始点アドレスを持つことになる． Mobile IP Working Group は，この問題の解決策として， [7] で「逆トンネル ("reverse tunnels") 」を仕様化している．進行中のこの作業は，モービ ル・ノードから送られてくるデータが，インターネットに出る前に home agent へトンネルされる方法を提供する．逆トンネリング法のもう一つの 利点は，マルチキャスト・トラフィックをうまく扱えることである．モー ビル IP システムの実装では，この逆トンネリング方を実装することが推 奨される． 先に記したように，進入トラフィック・フィルタリングは，始点アドレス 偽装攻撃をかなり有効に防ぐことができるが，フィルタで許可した範囲内 ではあるが別のホストと同じ始点アドレスを，攻撃者が偽装することにつ いては排除できない．しかし，この種の攻撃があった場合，ネットワーク 管理者は，その攻撃が，実際にそのプレフィックス内から出されたもので あることは確信できる．そして，犯人を追い詰めることができるし，最悪 の場合でも，問題のかたがつくまで始点アドレスのある範囲をブロックす れば良い． 進入フィルタリングが DHCP ないし BOOTP の環境で使われる場合，必要で あれば，始点アドレスが 0.0.0.0 で，終点アドレスが 255.255.255.255 のパケットがルータの relay agent に届くことを確認することを，ネット ワーク管理者に助言しておく．しかし， directed ブロードキャスト複製 の範囲は限定し，無闇にフォワードしてはならない． 6. 要約 インターネットに接続するネットワークの末端境界 (periphery) で，進入 トラフィック・フィルタリングを行うことにより，始点アドレス偽装を用 いるサービス妨害攻撃を効果的に抑止できる．ネットワーク・サービス・ プロバイダおよび管理者は，境界ルータ上でこの種のフィルタリングを実 装し始めており，全てのサービスプロバイダが，できるだけ早く実装する ことが求められる．この攻撃方法を根絶することで，インターネット共同 体全体の助力になるとともに，利用者からのリンク上ですでに進入フィル タリングをしていることを示すことで，攻撃源を追っている他のサービス・ プロバイダの助けにもなる． 集合ネットワークの管理者たちは，集合ネットワークがそのような問題の 源にならないようにしておくべきである．フィルタリングは，一つの組織 内でシステムを不適切にネットワーク接続しようとする利用者に，問題を おこさせないために使うものではある．しかし，実際には，不満分子が無 闇に攻撃することを阻止するためにも使えるのである． 知らない内に，この種の攻撃源にならないようにしておくことは，全ネッ トワーク管理者の責任である． 7. 安全性に関する考察 本文書の主要な目的は，安全対策能力と，インターネット共同体全体への 配慮を習慣づけることである．より多くのインターネット・プロバイダ， 集合ネットワークの管理者が進入フィルタリングを実装し，攻撃者が始点 アドレスを偽装して攻撃を仕掛ける機会を著しく減少させる．攻撃源がよ り「正当」になるほど，攻撃源を追いかけることが簡単になる．インター ネットで攻撃の数や頻度が全体として減少することで，実際の攻撃源を追 いかけるのに，より多くのリソースが使えることになる． 8. 謝辞 この文書に関連して，広く議論し，可能な解決策を積極的に探してくれた ことにより， The North American Network Operators Group (NANOG) [5] グループは全員が賞賛を受けるに値するものである．また， Justin Newton [Priori Networks] と Steve Bielagus [OpenROUTE Networks, Inc.] の助 言と貢献に感謝する． 9. 参照文献 [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. [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. 著者の住所 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 11. 著作権表示全文 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. （翻訳　篠田伸夫　福島大学）