-----BEGIN PGP SIGNED MESSAGE----- ====================================================================== JPCERT-ED-2001-0005 JPCERT/CC 技術メモ - サービス運用妨害攻撃に対する防衛 初 版: 2000-02-28 (Ver.01: JPCERT-ED-2000-0002) 発 行 日: 2001-12-27 (Ver.03) 最新情報: http://www.jpcert.or.jp/ed/2001/ed010005.txt ====================================================================== 本文書では、サービス運用妨害 (denial of service, DoS) 攻撃がどのよう にして起こるか、どのように防衛するかについて一般的に説明します。 I. どのようにサービス運用妨害が起こるか サービス運用妨害とは、主に以下のような状況により、システムに本来期待 されている可用性が損なわれることを言います。 - ネットワークの輻輳 (ホスト又はネットワークへのアクセスの集中によるネットワークの混雑) - システムのクラッシュ これらが (サイト外部の) 悪意によって引き起こされる場合、たとえば以下 のようなインシデントが発生します。 a) リモートから、処理能力を越えるパケット (リクエスト) を大量に送信 され、サービスの運用が妨げられた。 b) リモートから、システムの弱点を攻撃するパケットを(少量)送信され、 サービスの運用が妨げられた。 c) システムに侵入を受け、他のサイトに対してサービス運用妨害を行なう プログラムを実行された。 d) 他のサイトへのサービス運用妨害を中継するために、リモートからシス テムのサービスが悪用された。 e) システムに侵入を受け、他のサイトへのサービス運用妨害を中継するた めのサービスを (不正に) 起動された。 f) システムに侵入を受け、そのシステムのサービスを妨げるプログラムを 実行された。 g) 他の攻撃の副作用として、サービスの運用も(が)妨げられた。 ここで、a) のようなインシデントでは、一つ一つは正当と判断されるアク セスであっても、大量に受ければサービスの妨げになりうることに注目してく ださい。この場合には、攻撃を受けるサイトにおいてアクセスを拒否すること は難しくなります。よって、各サイトが自衛するだけでなく、特にサービス運 用妨害については、攻撃の中継地点として c) d) e) のように悪用されないよ う、各サイトが足並みを揃えることも重要となってきます。 また、OS のネットワークサービスプログラムの既知の弱点を悪用して感染・ 増殖するワームの感染の試みにより、ネットワーク帯域が大幅に消費され、結 果として、ネットワークが DoS 攻撃を受けた状態になるケースもあります。 このようなワームの影響を最小限にするためには、下記 II.(1) ソフトウェア の更新 を常に心掛け、ワームの感染拡大を防ぐことも要求されます。 II. 対策 本節では、自衛のための対策、攻撃の中継地点として悪用されないための対 策、両方の意味合いを持つ対策をとりまぜ、サービス運用妨害への一般的な対 策を紹介します。緊急の対策として (1) 〜 (6) を、中長期的な対策として (5) 〜 (8) を検討することをお勧めします。 (1) ソフトウェアの更新 システムのクラッシュにつながるような問題や、システムへの侵入を許すよ うな問題については、セキュリティ対策用のパッチや更新モジュールが提供さ れたり、より新しいリリースにおいて対処されていたりすることが期待できま す。OS および各サーバプログラムの更新状況を確認し、適宜必要な更新を行 ないます。 より新しい版のソフトウェアでは、より高い負荷に対応できるように、バッ ファ領域の取り扱いや、サービスの処理方法が改善されている場合もあります (ただし、実際には、必ずしも新しい版のソフトウェアのほうがより高い負荷 に耐えるとは限りません。たとえば、実装方法の変更に伴ない、既存の機能に おける性能が低下する場合もあります。定常的に特に高い処理能力を必要とす るシステムにおいては、更新を行なう前に十分な検討を行なうことが望まれま す)。 (2) ディレクティドブロードキャスト (directed broadcast) の無効化 特に Smurf 攻撃 [2] への対策として、中継地点としての悪用を防止する観 点から、ディレクティドブロードキャストを無効化する措置が推奨されていま す。一般的なサイトでは、外界からサイト内部のネットワークに宛てたディレ クティドブロードキャストを処理しなくとも差し支えないと考えられます。自 サイトのルータの設定を確認し、ディレクティドブロードキャストに関する処 理を無効化します (パケットフィルタリングにより対処する選択肢もあります)。 ディレクティドブロードキャストとは、ルータなどの機器が、自ネットワー ク外部からのパケットを、自ネットワーク内部のブロードキャストアドレスへ 転送することを意味します。RFC 1812 [1] (もしくは、それ以前の RFC) の規 定により、伝統的なルータでは、ルータが直接接続されているネットワークに 宛てたディレクティドブロードキャストを受けると、原則としてそれを処理す る (下位層のブロードキャスト機能を用いて送信する) ように実装されていま す。しかしながら、この処理には Smurf のようなリスクを伴ないます。 1999年8月には、[1] を更新する RFC 2644 [3] が公開され、ルータに対し ては、ユーザが明示的に設定しない限り (ユーザが明示的にリスクを取らない 限り) ディレクティドブロードキャストの処理を行なわないことが求められて います。 (3) 始点アドレスが詐称されたパケットの流入防止 攻撃対象システムのアドレスを詐称するパケットを用いた攻撃手法がありま す (例えば [4] や [5])。該当する攻撃への対策として、外界からのパケット について、始点アドレスが自サイトに割り当てられたアドレスであるパケット を破棄するように、パケットをフィルタリングします。 (4) 始点アドレスが詐称されたパケットの流出防止 自サイトが (3) で挙げた攻撃に悪用されないようにするためには、外界に 送出するパケットについて、始点アドレスが自サイトに割り当てられていない アドレスであるパケットを破棄するように、パケットをフィルタリングします。 (5) 不要なサービスの停止 たとえば、UDP による ECHO や CHARGEN などのサービスは、いくつかの攻 撃手法 (例えば [4]) において悪用されるおそれがあります。これに限らず、 潜在的な攻撃、悪用を回避するため、システムにおいて使用していないサービ スをすべて停止します。 担当者がそれと意識していなくとも、導入時において起動されているサービ スがある場合も多く、注意が必要です。 (6) アクセス制御の実施 潜在的な攻撃、悪用を回避するため、外界に対してサービスを提供すること を意図していないサービス、特に、各種アプリケーション層ゲートウェイ (プ ロキシサーバや、SOCKS 等) について、サイト外部からのアクセスを禁止する よう、アクセス制御の設定を行ないます。 (7) パケットのフィルタリング (3) (4) で挙げた自サイトのアドレスについてのフィルタリングの他にも、 外界から自サイト内部へのパケットをフィルタリングし、他の潜在的な攻撃を 回避することや、自サイト内部から外界へのパケットをフィルタリングし、攻 撃の中継地点としての悪用をより困難にしておくことが考えられます。 例えば、以下のネットワークアドレスはサイト内部でのみ使用されるアドレ スであり、通常ネットワークを越えて使用されることはありません。これらネッ トワークからのパケットが送出されないようにアクセス制御を行うこともサイ トの悪用を防ぐ対策の一つです[15]。 0.0.0.0/8 - Historical Broadcast 10.0.0.0/8 - RFC 1918 Private Network 127.0.0.0/8 - Loopback 169.254.0.0/16 - Link Local Networks 172.16.0.0/12 - RFC 1918 Private Network 192.0.2.0/24 - TEST-NET 192.168.0.0/16 - RFC 1918 Private Network 224.0.0.0/4 - Class D Multicast 240.0.0.0/5 - Class E Reserved 248.0.0.0/5 - Unallocated 255.255.255.255/32 - Broadcast 理論的には、(双方向において) サイトのサービスに必要なパケットだけを 通過させ、他はすべて破棄することが考えられます。しかし、実際のシステム においては、性能上の問題や維持管理上の問題が発生するおそれもあります。 サービスの要件、ホスト毎でも可能なセキュリティ対策、フィルタリングを実 装する機器の性能、利用できる支援ツール等を勘案のうえ、維持管理が可能な 内容で設定することも重要です。 (8) システム構成の見直し 高い可用性を必要とするサービスを運用している場合には、適切な機会にシ ステム構成全体を見直し、サービス運用妨害を受けた際の影響を最小の範囲に 留めるように設計しなおすことも考えられます。 可用性に対する要求によってサービスをクラス分けし、各サービスクラスに 対して余裕を持ってリソース (CPU、メモリ領域、ディスク領域、ネットワー ク帯域、等々) を割り当てます。また、あるサービスクラスに対するサービス 運用妨害攻撃の影響が他のサービスクラスに及ばないようにシステムを設計し ます。サービスクラスの分類に際しては、サービスの内容の他、サービスの対 象範囲等についても検討すると良いでしょう。 III. サービス運用妨害を受けた際の対応 コンピュータセキュリティインシデントに関する対応一般については、参考 資料 [6] で述べています。ここでは、サービス運用妨害に関して、同文書を 補足します。 (1) 事実関係の確認について 外界からのパケットが原因である場合、始点アドレスが偽造されている場合 が多く、配慮が必要です。また、アクセスの繰り返しは、サービス運用妨害を 意図しなくとも、アクセス元システムの予想外の挙動や、設定ミス、操作ミス 等々により発生する可能性もあるため、注意が必要です。 (2) 回避策について 一時的な回避策として、特定の攻撃に対してパケットのフィルタリングを実 施することも有効な場合があります。始点アドレスや宛先アドレス、パケット の内容 (プロトコル種別やポート番号等) により、可用性を回復/維持すべき サービスに注目してフィルタリングの内容を定めます。WAN 回線に輻輳が発生 している場合には、ローカル側でのフィルタリングでは対処できない場合もあ りますが、その場合には WAN 回線の対向側 (上流の ISP 等) にも対処を依頼 します。 IV. (付録) ISP におけるフィルタリング 例えば、RFC 2267 [7] では、IP アドレスの詐称を防止するため、ISP にお けるパケットフィルタリングに関する提案が行なわれています。すなわち、 ISP の側で、ある顧客に割り当てられていないアドレスを詐称するパケットの 受け入れを拒否するという考え方です。 V. 参考資料 (注) [8]〜[14][16][17] については本文からの参照はありませんが、具体的 な攻撃の例としてあわせてご参照ください。 [1] "Requirements for IP Version 4 Routers", RFC 1812, F. Baker http:/www.ietf.org/rfc/rfc1812.txt [2] CA-98.01.smurf http://www.cert.org/advisories/CA-1998-01.html [3] "Changing the Default for Directed Broadcasts in Routers", RFC 2644, D. Senie http:/www.ietf.org/rfc/rfc2644.txt [4] CA-96.01.UDP_service_denial http://www.cert.org/advisories/CA-1996-01.html (日本語訳) http://www.jpcert.or.jp/tr/cert_advisories/CA-96.01.txt [5] CA-97.28.Teardrop_Land http://www.cert.org/advisories/CA-1997-28.html [6] コンピュータセキュリティインシデントへの対応 http://www.jpcert.or.jp/ed/2000/ed000007.txt [7] "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, P. Ferguson, D. Senie http:/www.ietf.org/rfc/rfc2267.txt [8] Denial of Service Attacks http://www.cert.org/tech_tips/denial_of_service.html [9] CA-96.21.tcp_syn_flooding http://www.cert.org/advisories/CA-1996-21.html [10] CA-96.26.ping http://www.cert.org/advisories/CA-1996-26.html [11] CA-98-13 tcp denial of service http://www.cert.org/advisories/CA-1998-13.html [12] CA-99-17 Denial-of-Service Tools http://www.cert.org/advisories/CA-1999-17.html [13] CA-2000-01 Denial-of-Service Developments http://www.cert.org/advisories/CA-2000-01.html [14] IN-99-07: Distributed Denial of Service Tools http://www.cert.org/incident_notes/IN-99-07.html [15] Help Defeat Denial of Service Attacks: Step-by-Step http://www.sans.org/dosstep/ [16] Trends in Denial of Service Attack Technology http://www.cert.org/archive/pdf/DoS_trends.pdf [17] Results of the Distributed-Systems Intruder Tools Workshop http://www.cert.org/reports/dsit_workshop-final.html __________ 注: JPCERT/CC の活動は、特定の個人や組織の利益を保障することを目的とし たものではありません。個別の問題に関するお問い合わせ等に対して必ずお答 えできるとは限らないことをあらかじめご了承ください。また、本件に関する ものも含め、JPCERT/CC へのお問い合わせ等が増加することが予想されるため、 お答えできる場合でもご回答が遅れる可能性があることを何卒ご承知おきくだ さい。 注: この文書は、コンピュータセキュリティインシデントに関する一般的な情 報提供を目的とするものであり、特定の個人や組織に対する、個別のコンサル ティングを目的としたものではありません。また JPCERT/CC は、この文書に 記載された情報の内容が正確であることに努めておりますが、正確性を含め一 切の品質についてこれを保証するものではありません。この文書に記載された 情報に基づいて、貴方あるいは貴組織がとられる行動 / あるいはとられなかっ た行動によって引き起こされる結果に対して、JPCERT/CC は何ら保障を与える ものではありません。 __________ 2000-2001 (C) JPCERT/CC この文書を転載する際には、全文を転載してください。情報は更新されてい る可能性がありますので、最新情報については http://www.jpcert.or.jp/ed/ を参照してください。やむを得ない理由で全文を転載できない場合は、必ず原 典としてこの URL および JPCERT/CC の連絡先を記すようにしてください。 JPCERT/CC の PGP 公開鍵は以下の URL から入手できます。 http://www.jpcert.or.jp/jpcert.asc __________ 改訂履歴 2001-12-27 参照 URL 及び文面の更新、追加 ファイル名変更 2000-08-25 参照 URL の更新 2000-02-28 初版 (JPCERT-ED-2000-0002) -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBPCqINYx1ay4slNTtAQGBSgP+Ob2uUxrCvR2bNDs2BnyNSSlP13bHav9X aWpfEsqTN0ViYg4MbsBg2bdAvZjQElssAH1Nf3ItECXgFACbZEBArCxDxxogmliz sxpb+/ubZstdzIVbFLbl38POu5yBkGTS2TcWhWZY6bjbrHlOzrf/6ZTiw6Q+OsZ8 7BXJzglw9wE= =MDJi -----END PGP SIGNATURE-----