-----BEGIN PGP SIGNED MESSAGE----- ====================================================================== JPCERT-ED-2002-0002 JPCERT/CC 技術メモ - コンピュータセキュリティインシデントへの対応 初 版: 1999-12-09 (Ver.01: JPCERT-E-TEC-99-0002-01) 発 行 日: 2002-06-06 (Ver.04) 最新情報: http://www.jpcert.or.jp/ed/2002/ed020002.txt ====================================================================== 本文書では、コンピュータセキュリティインシデントへの一般的な対処方法 について概説します。 一般的に、(インターネットに接続された) システムの運用に際しては、セ キュリティ上の問題として捉えられる事象 (コンピュータセキュリティインシ デント) が発生する可能性があります。コンピュータセキュリティインシデン トに対して適切な対応を行なうためには、事前の準備が望まれます。本文書を 事前に通読され、システム運用の一環としてその発生に備えることを推奨しま す。 I. インシデント対応の概要 コンピュータセキュリティインシデント (以下単にインシデントと表記) の 典型的な例としては、侵入、サービス妨害、破壊、データの盗用や、それらの 準備段階と推測されるアクセス、そのほか他サイト/システムからの原因不明 のアクセスなどが挙げられます。また、サイト外部から、自サイトの関与する (疑いのある)インシデントについての情報提供を受ける可能性もあります。 実際のインシデントの形態は多岐に渡ります。サイト固有の事情を考慮の上、 いくつかの類型を想定し、類型毎にあらかじめ対応を検討しておくことを推奨 します。 インシデントの一般的な類型としては、以下のような例が挙げられます。 (a) システムのアクセス権限に対する影響 - 特権 (サーバプログラムの権限、管理者権限) の盗用 - 一般ユーザ権限の盗用 - サービスの盗用、悪用 - アクセス拒否の記録 - その他の不審な事象 (b) システムの可用性、サイトの業務に対する影響 - 許容できる遅延、停止 - 許容できない遅延、停止 (断続的ないし短期) - 許容できない遅延、停止 (継続的ないし長期) (c) 外部への影響 - 外部からのインシデントレポートの受領 - 外部への予期しないアクセスの検出 この他、顧客のプライバシーや組織の信用に対する影響などの尺度も考えら れます。サイト固有の諸事情を勘案し、適切な類型を想定する必要があります。 一見して具体的な影響がないと考えられる事象であっても、実際にはサイト のセキュリティに対する脅威の端緒であるような場合もあります。不明、不審 な事象に対しても、油断なく対応することが望まれます。 以下、対応における一般的な作業項目の例を挙げます。 - 手順の確認 - 作業記録の作成 - 責任者、担当者への連絡 - 事実の確認 - スナップショットの保存 - ネットワーク接続やシステムの遮断もしくは停止 - 影響範囲の特定 - 渉外、関係サイトへの連絡 - 要因の特定 - システムの復旧 - 再発防止策の実施 - 監視体制の強化 - 作業結果の報告 - 作業の評価、ポリシー・運用体制・運用手順の見直し これらの作業項目については、次節以下で説明します。まず II. 章では、 これらの作業項目全般について説明しています。次に、III. 章から V. 章で は、いくつか典型的な状況について、より詳細に説明していきます。最後に、 VI. 章では Unix 系のシステムにおける侵入発見チェックリストを紹介してい ます。 ※ Microsoft Windows に関しては、参考資料 [5] [13] を参照してください。 これらの作業には、必ずしもシステム運用管理の範疇ではない作業も含まれ ます。また、調査、復旧や再発防止に要する費用、人員、機材の確保や、ある いは警察への捜査要請、弁護士への支援依頼、顧客、出資者などへの報告、メ ディアなど外部への情報開示、損失の評価など、組織全体にかかわる重大な判 断が必要となる局面も予想されます。サイト内各部署を交え、サイトの危機管 理の一環として、事前に調整しておくことが望まれます。 II. 一般的な作業手順 (1) 手順の確認 サイトにおけるインシデント対応手順が予め定められている場合には、その 内容を確認します。非常時に備えて、セキュリティポリシーや作業マニュアル、 その他必要な資料などは、予めすぐに参照できる場所に用意しておきます。 不幸にして事前に定められた手順がない場合、もしくは、想定されていない 事態が発生した場合には、責任者、担当者と調整を図りつつ、本文書や参考資 料 [1] [2] [3] [4] [5] などの手順を参考に対応を検討します。あるいは、 外部のコンサルタントの助力を得るという選択肢も考えられます。 (2) 作業記録の作成 インシデント対応作業について記録を作成します。これは、作業手順を後日 評価する際の資料として有効なほか、作業自体により副次的な問題を生じた際 には、対応を検討する上で重要な資料となる場合があります。 (3) 責任者、担当者への連絡 発見者がインシデント対応の担当者でない場合には、サイトにおいて事前に 定義された連絡先 (たとえば組織内のインシデント対応チーム、セキュリティ 管理者や情報システム部門のインシデント対応担当者など) に連絡し、指示を 仰ぎます。 実際にインシデントが発生した場合には、その内容や程度により、組織内の 他の部署とも協調して対応する必要があるかもしれません。その場合には、事 前に定義された各々の責任者、担当者に遅滞なく連絡を行います。 想定されるインシデントの類型に応じて責任者および担当者を事前に決定し、 連絡網を整備しておくことが望まれます。 (4) 事実の確認 サイト内外からインシデントに関する報告を受けたときには、また、自ら発 見したインシデントであっても、冷静に、インシデントの内容、状況について の事実を確認します。 不審なアクセスが観測されたとしても、それは必ずしも悪意によるアクセス とは限りません。自らの操作ミス、他のシステム管理者の作業などが原因でな いか、あるいは、システム自体の問題 (仕様、実装上の誤り) ではないか、念 のため確認することが重要です。 例えば、自サイトに侵入され、その侵入者が外部へのアクセスを行なった結 果として、アクセス先システムから自サイトの Ident [6] サーバなどに対し アクセスを受けることがあります。また、自サイト (の正規の利用者) が外部 のサービスに対して通常のアクセスを行なったところ、アクセス先システムの 予想外の挙動によって自サイトへのアクセスを受ける場合もあります。 このように、自サイトから外部へのアクセスを行った波及効果として、外部 から自サイトに対するアクセスを受けたという状況においては、後者のアクセ スを外部からのアタックであると誤解する可能性があり注意が必要です。 他にも、他のサイトで検出されたインシデントについて、自サイトがそれに 関係する可能性があるという連絡を受ける可能性があります (たとえば、自サ イトのアドレスから先方に対して不審なアクセスが行なわれているという指摘、 先方のシステムが自サイトへの攻撃元として悪用されたという事情説明など)。 この場合、連絡元において何らかの誤解があるか、最悪の場合、詐欺的手法に よる攻撃を意図した欺瞞情報であるとも考えられます。冷静に事実確認を行な うことが重要です。 (5) スナップショットの保存 システムに対して一定の影響が想定される場合には、後日の調査に備え、イ ンシデント発生時のシステムのスナップショットを保存します。保存すべき項 目や範囲は、想定されるインシデントにより異なります。例えばログイン状況、 ネットワーク接続やプロセスの稼働状況に関する記録の作成、バックアップデー タの作成、ハードディスクのイメージの保存などが挙げられます。 (6) ネットワーク接続やシステムの遮断もしくは停止 自システムを介したサイト内外の他のシステムへの攻撃が想定される場合や、 その他影響が拡大するおそれのある場合には、ネットワークやシステムの全部 もしくは一部を遮断ないし停止し、影響範囲の拡大の防止を図ることを検討し ます。 ただし、システムによっては、それを遮断、停止した結果、甚大な二次イン シデントが生じるおそれのあるものもあるかもしれません。また、不適切な手 順で遮断や停止を行なうと、他のインシデント対応作業の妨げとなったり、シ ステムの復旧が困難になるおそれもあります。逆に、予想される影響によって は、他の作業項目に優先して遮断や停止を行なうほうがよい場合もあるかもし れません。 遮断や停止が必要な場合、あるいは、遮断や停止を行なって差し支えない場 合について、意思決定プロセスや判断基準、具体的な作業手順などを予め定めて おくことを推奨します。 (7) 影響範囲の特定 以後の対応を判断する前提として、どのような種類の影響が、サイト内外の どの範囲に対して、どの程度生じたか調査します。 具体的には、他のシステムとの通信の状況、ファイルのアクセス状況を確認 します。サイトの機密情報や、システムのセキュリティ上重要なファイルが参 照されたり、改ざん、消去、持ち出しされている可能性がある場合には、ファ イルやデータの位置付け (文書管理規定上の機密管理レベルなど) を確認し、 以後の対応を検討します。また、他のシステムへのアクセス元として悪用され た可能性がある場合には、ログなどを参照し、その日時やアクセス内容を確認 します。 (8) 渉外、関係サイトへの連絡 インシデントの発生に際しては、その影響の程度により、サイト内外への事 情説明や謝罪などが必要とされる場合があります。広報や渉外などの担当と調 整し、適切な情報提供を行ないます。 何らかの形で他のサイトがインシデントに関係している可能性がある場合に は、それらのサイトにインシデントに関する情報を提供し、協調して解決に取 り組むことができないか検討します。ただし、連絡を行なうことにはリスクも 伴なうため、注意が必要です。詳しくは参考資料 [1] をご参照ください。 (9) 要因の特定 要因を特定し、それに対して適切な再発防止策を実施しない限り、インシデ ントが再発するおそれがあります。 外部からのアクセスにより一定の影響を被った場合には、インシデントを発 見するきっかけとなったシステムのほか、外部から (インターネット、電話回 線などを通じて) 直接アクセスできるシステムに関して、何か問題がないか検 討します。 個別のセキュリティ上の弱点については、JPCERT/CC の公開文書 [7] [8] や、参考資料 [9] [10] などの各種セキュリティ勧告文書などを随時参照する ことを推奨します。また、弱点の特定にあたっては、参考資料 [11] [12] [13] も参考になります。 (10) システムの復旧 システムが改ざんや破壊などを受けた場合には、バックアップメディアある いは配布メディアからシステムを復旧します。 バックアップデータを記録した時点において、既にシステムが改ざんされて いるおそれがある場合には、予期しない設定やプログラムが記録されていると 考えられます。バックアップメディアからの復旧に際しては、それら予期しな い情報をも書き戻してしまわないように留意します。 最悪の場合には、バックアップメディアに記録したデータの復旧を一部諦め、 配布メディアによる復旧が必要となる場合もあります。 (11) 再発防止策の実施 インシデントの再発を防止するため、要因となったシステム上の問題や運用 上の問題を除去します。あわせて、他にもセキュリティ上の問題がある場合に は、それについても対処しておくことが望まれます。 時間経過に伴ない、システムの構成要素 (特にソフトウェア) に関してセキュ リティ上の問題が新しく発見されている可能性があります。問題点を解決せず、 単に再インストールを行なうだけ、単に復旧するだけ、という対応を続けてい ると、インシデントが再発するおそれがあります。 また、アタックを受けた結果、例えばパスワードデータベースの情報が盗ま れた可能性が否定できない場合には、管理用アカウントのパスワードも含め、 すべてのパスワードを変更しておきます。 (12) 監視体制の強化 インシデントの再発に備え、漸時監視体制を強化することが望まれます。 特にアタックを受けた場合には、同一サイト内の他のシステムを対象とした ものも含め、同種もしくは別種のアタック (の試み) が継続する可能性があり ます。また、一度アタックに成功され、脆弱なサイトのひとつとして情報が流 されると、引き続き同種もしくは別種のアタックを受けるおそれがあります。 (13) 作業結果の報告 作業が終了したら、記録に基づいて作業内容や、作業に要したコスト、確認 された損失をまとめ、責任者に報告します。 (14) 作業の評価、ポリシー・運用体制・運用手順の見直し 作業報告を元に、セキュリティポリシーに定められた手順が十分であったか を見直し、必要であればポリシーの見直しを行います。また、システムや運用 体制、運用手順、インシデントに対して実際に実施した対応に問題がないか、 適宜検討する機会を設定します。セキュリティ上改善すべき事項があれば、計 画を立案し、順次改善を図ります。 III. 不審なアクセスを検出した場合の対応 システムの稼働状況を継続的に監視していると、時折外部から不審なアクセ スが観測される場合があります。ここでは、その場合の対応について補足しま す。 このような不審なアクセスについては、一般的に以下の可能性が考えられま す。 (a) 攻撃対象の探索を意図したアクセス、または、アタックそのもの (b) 設定ミス、操作ミスによるアクセス (c) システムの予想外の挙動によるアクセス 一般的に、(a) と思われる場合には、前後して複数種のアクセスが行われて いる可能性があります。あるアクセスについてそれを拒否した記録があったと しても、それだけで他のすべてのアクセスが不成功に終わったとは断言できま せん。すべてのアタックについて防御に成功したと判断できない場合には、念 のためシステムの稼働状況を調査し、不審な点がないか確認します。 以下、(b) (c) について、JPCERT/CC の過去の対応に基き、いくつか類型を 紹介します。 (1) 類似のドメイン、類似のアドレスに対するアクセス 自サイトのドメイン名と見かけ上類似のドメインがある場合、それらのドメ インへのアクセスを意図したアクセスを受ける可能性があります。また、IP アドレスの入力ミスにより、自サイトに見かけ上類似のアドレスへのアクセス を意図したアクセスを受ける可能性があります。 (2) UDP 137 番ポート (NETBIOS-NS) へのパケット このパケットだけでは一概にアタックを意図したものと断定することができ ません。広く用いられている実装の中に、NETBIOS サービスとは一見無関係な サーバへのアクセスであっても、その際に UDP 137 番ポートに対して NETBIOS 名の問い合わせを行なうものがあるためです。一方で、NETBIOS サー ビスの稼働状況やその他攻撃のための参考情報を入手しようとするアクセスや、 あるいは NETBIOS サービスへのアタックが行なわれた可能性も考えられます。 システムの他のサービスへのアクセス状況についても参照し、総合的な状況 に不審な点がある場合には、送出元アドレスの管理者に対して調査を依頼する ことが考えられます (IP アドレスの設定誤りないし IP アドレス偽造の可能 性も考えられるため、連絡に際しては配慮が必要です)。 (3) UDP 161 番ポート (SNMP) へのパケット 攻撃のための参考情報を SNMP 経由で入手しようとするアクセスとも考えら れますが、ネットワーク監視ツールの設定ミスなどによりパケットが送出され た可能性もあり、単なるパケットの監視記録だけでは一般的には攻撃との判断 はできません。 この場合の対応としては、送出元アドレスの管理者に対して事実関係の確認 を依頼することが考えられます (IP アドレスの設定誤りないし IP アドレス 偽造の可能性も考えられるため、連絡に際しては配慮が必要です)。また、自 サイトの管理下にないネットワークからの SNMP によるアクセスを拒否する設 定になっているか、容易に推測可能なコミュニティ名を使用していなかったか を確認します。 外部からの SNMP によるアクセスに応答した(疑いがある)場合には、監視体 制をしばらく強化することを検討します。 (4) UDP の連続するポート番号へのパケット traceroute コマンドの実装には、UDP パケットを利用するものが多く見受 けられます。番号が連続した UDP のポート (多くの場合は 33??? 番台) に対 して、短時間の間に (数秒間程度) 比較的少ないパケット (通常は 10 個以内 程度) が送信されている場合には、traceroute コマンドによるアクセスとの 推測も有力です。 アタックの参考とするために経路情報を探索されたなどの可能性も完全には 否定できませんが、一方で、少数回の traceroute は一般的に許容される行為 であるとするユーザも少なくありません。 そこで、この場合の対応としては、他に不審な点があれば (継続的に/大量 に行なわれている、他にも不審なアクセスが観測されているなど)、監視体制 を強化する、送出元アドレスの管理者に照会してみるなどの対応が考えられま す。 IV. 外部からインシデントについての連絡を受けた場合 インターネットに接続されたシステムを運用していると、国内外を問わず外 部から自サイトに関係するインシデントについて連絡を受ける場合があります。 苦情、苦言が寄せられる場合もあります。ここでは、その場合の対応について 補足します。 (1) サイト内での調整 連絡を受けた内容によっては、必ずしも情報システム運用管理の範疇に留ま らず、広報、渉外、法務などからの対応が望まれる場合があります。他の担当 者や他の部署と協調して対応することが必要であれば、それら担当者、責任者 に対して連絡をとります。 (2) 事実関係の確認 まずは、連絡元の主張する内容を落ち付いて確認します。例えば、自サイト についての問題か否か、アクセスの内容、アクセスの方向、日時などを確認し ます。次に、その内容が自サイトのシステムに関係する場合には、システムの ログなどを確認し、事実関係を確認します (ただし、先方の主張する内容が事 実であると仮定した場合に、それがきわめて甚大な影響を及ぼすおそれがある ような場合には、ネットワーク接続やシステムの遮断、停止を優先するほうが、 かえって適切な場合も考えられます)。 一般的に、このような連絡については、因果関係の取り違い、勘違い、表記 ミスなどの誤報である可能性があります。最悪の場合には、詐欺的手法による 攻撃を意図した欺瞞情報であるとも考えられるため、冷静沈着に対処すること が重要です。 また、特に ISP, ICP 各位においては、インターネットレジストリ機関への 登録状況などにより、自サイトの顧客に関する連絡を受ける場合も多いと考え られます。顧客への情報の転送などをご検討ください。また、顧客のプライバ シーに関する情報の取り扱いに留意することが望まれます。 (3) 連絡元への対応 善意の連絡に対しては、事情説明を含め、礼を逸しない対応が望まれます。 また、自システムが原因で先方に一定の影響が及んだ場合には、謝罪などの対 応が望まれる場合も考えられます。あるいは、悪意の連絡に対しては、あえて 回答を避けることも含め、特別な対応が必要な場合もあるかも知れません。 いずれにしても、不適切な対応は、それ自体が影響範囲の拡大や、先方との 間の紛争などを招くリスクともなりえるので注意が必要です。渉外に関する担 当者や手順などに関しての規定がある場合には、それに従います。 もしも然るべき手順が確立されていない場合には、一例としてですが、責任 者や担当者と調整しつつ、返信文案などは内部で事前にレビューを行ない、ま た記録を残しながら対応を進めることが考えられます。 関連サイトとの情報交換についての詳細は、参考資料 [1] を参考にしてく ださい。 V. 侵入への対応 システムへの侵入を受けた場合には、一般的に侵入経路の特定が難しく、ま た、侵入者の行為に伴なう影響の範囲も大きいことから、迅速かつ注意深い対 応が望まれます。ここでは、システムに侵入された (疑いがある) 場合の対応 について補足します。 (1) ネットワークの遮断、システムの停止 システムに侵入されると、ログの消去、改ざんを受けるおそれがあります。 ログを消去されると、侵入経路や影響範囲の特定に支障を生じます。また、他 システムへの攻撃元として悪用されたり、パケット盗聴プログラムの設置、情 報の持ち出しなど予期される影響も甚大となります。 よって、既に侵入されていることが明らかな場合には、ネットワークの遮断 やシステムの停止について優先的に検討することを推奨します。 (2) スナップショットの保存 可能であれば、システムの停止や再起動の前に、影響を受けた可能性のある すべてのマシンについて、プロセスの稼働状況やネットワークの利用状況を日 時と共に記録します。 続いて、ファイルシステムの状況を保存します。ファイルの最終参照時刻、 最終更新時刻や、所有者、アクセス権などの状況も重要な情報となります。理 想的には、単純なファイルの複写やアーカイブよりも、ディスクイメージを複 写するか、もしくは、ディスクをそのまま保管することが良いとされています。 (3) 被侵入システムにおける調査 侵入されたシステムにおいては、設定ファイルやプログラムが改ざんを受け たり、パケット盗聴プログラムや各種サーバなどの予期しないプログラムが起 動されている可能性があります。これらを放置すると、調査・復旧の妨げや、 影響の拡大、再侵入の原因となるおそれがあります。そこで、ファイルシステ ムの内容や、稼働中のプロセス (サーバプログラム) を正常な状態と比較し、 相違の有無を確認します。 典型的な改ざんの例としては、以下のようなものが挙げられます。 - アカウント情報の追加、変更 - ユーザ認証機構の改ざん - プログラムのインストール、起動 - セキュリティ上の弱点を含むソフトウェアへのダウングレード - 侵入者に関する情報を出力から除外するコマンドへの置換 調査にあたっては、改ざんを受けていないことが保障されているソフトウェ ア (コマンド) を使うことが重要です。システムによっては、書き込み禁止状 態の起動媒体 (CD-ROM, フロッピーディスクなど) が提供されており、このよ うな調査に利用できる場合もあります。 また、侵入者がファイルを残していった場合には、サイトに対する影響を調 査する際の参考となります。このようなファイルは、典型的には、隠しファイ ルとされたり、あるいは、標準的なファイルと紛らわしい場所や、一時ファイ ル領域、隠しディレクトリなどに作成されます。またアカウントが偽造 / 盗 用されている場合には、そのアカウントのホームディレクトリも調査します。 なお、被侵入システムから、侵入者が残したファイル類が発見された場合、 その内容から侵入経路などの内容を推測できる場合もあります。 (4) 他のシステムに対する影響の調査 侵入者によって、システムがさらにサイト内外の他のシステムにアクセスす る際のアクセス元として悪用された場合には、そのアクセスを記録したログが 残されている場合があります。そのようなログは、アクセスを受けた(可能性 のある) システムとアクセスの内容を特定するための重要な資料であり、それ らシステムの管理者各位がインシデントに対処するために役立ちます。 典型的には、攻撃用ツールの出力を保存したファイルが放置されていないか 確認します。また、侵入者が他のシステムに TCP 接続を行なった際に、接続 先システムから接続元の Ident [6] サーバに対して問い合わせが行なわれる 場合もあり、その記録が残っている可能性もあります。あるいは、ルータやファ イアウォールなどにおいて、自サイトのネットワーク利用状況のログを保存し ている場合には、そのログが利用できる場合もあります。 (5) 侵入経路の特定 侵入された要因を特定し、適切な対策を実施しない限り、再侵入を受ける可 能性があり、危険です。 被侵入システムのほか、外部から (インターネット、電話回線などを通じて) 直接にアクセスできるマシン上に弱点がないか検討します。例えば、 ・放置していたセキュリティ上の問題、弱点はなかったか ・パスワードファイルや設定ファイル類が盗まれた形跡はないか ・見破られやすいパスワードがなかったか ・HTTP や FTP など、公開しているサービスに設定の誤りがなかったか などをチェックします。 VI. Unix 系システムにおける侵入発見チェックリスト 以下に、Unix 系システムへの侵入を発見するための一般的なチェックリス トを紹介します。これは一般例として紹介したものですので、ご使用になられ ているシステムに応じてパス名やファイル名、コマンド名などを適宜読み替え てください。 * 侵入者によってシステムが再起動させられていないか、uptime コマンドな どでシステムの起動時刻を確認してください。ただし uptime などのシステ ムの起動時刻を表示するコマンドや、そのコマンドに関連したファイル (/var/run/utmp など) が、侵入者による操作を隠蔽するために置き換えら れている可能性もあるので、まず使用するコマンドやファイルが置き換えら れていないことを確認してください。詳細は「VII. (付録) 置き換えの有無 をチェックする方法」をご参照ください。 * /tmp や /var、/dev 以下などに不審なファイルがないかを調べます。侵入 者は、これらの場所にファイルを残す場合が多くあります。ただし ls コマ ンドなどの、ファイル名やディレクトリ名を表示するコマンドが、不審なファ イルを隠蔽するために置き換えられている可能性もあるので、まずコマンド が置き換えられていないことを確認してください。詳細は「VII. (付録) 置 き換えの有無をチェックする方法」をご参照ください。 * syslog が出力するログ、last ログ (ログイン履歴)、その他アカウンティ ング情報などに不審な形跡や普段の使用状況と異なる記録が残されていない かを調べます。 syslog は、典型的な環境では /etc/syslog.conf に記載された場所に出力 されます。 last コマンドやその他のアカウンティング情報を表示するためのコマンド、 更にそれらが使用するファイル (/var/log/wtmp, /var/account/* など) が、 侵入を隠蔽するために置き換えられている可能性もあるので、まずそれらの コマンドやファイルが置き換えられていないことを確認してください。詳細 は「VII. (付録) 置き換えの有無をチェックする方法」をご参照ください。 * FTP サーバや HTTP サーバなどが動いており、ファイル転送状況などのログ を保存している場合には、そのログファイルを調査します。 * 調査したい機器以外に、ルータやファイアウォールなどの機器が出力するロ グが残されていれば、それらも利用して不審な形跡や普段の使用状況と異な る記録がないかを確認します。 * setuid/setgid された不審なファイルが残されていないかを調査します。具 体的には下記のコマンドなどで出力されるファイルをチェックし、それらが 侵入者によって置き換えられたものでないかを確認します。 # find / -user root -perm -4000 -print # find / -group kmem -perm -2000 -print # find / \( -perm -004000 -o -perm -002000 \) -type f -print ただし find コマンドが、不審なファイルを隠蔽するために置き換えられて いる可能性もあるので、まず find コマンドが置き換えられていないことを 確認してください。詳細は「VII. (付録) 置き換えの有無をチェックする方 法」をご参照ください。 * 不審なアカウント情報やネットワークサービス定義、その他の不審な設定が 残されていないかを調べます。 具体的には、下記に列挙したようなファイル自体が書き換えられていないか、 あるいは、それらのファイルのうちシステム起動時や終了時に実行されるファ イル (/etc/rc*, /etc/init.d ディレクトリの下にあるファイルなど) とそ れらのファイルの中から実行される全てのファイルに、不審なコマンドが含 まれていないか、実行される全てのプログラムが改ざんされていないか、そ れらのプログラムの設定ファイルに不審な設定内容が含まれていないかなど を確認します。 /etc/passwd, /etc/shadow, /etc/inetd.conf, /etc/services, /etc/ttys, /etc/ttytab, /etc/hosts.equiv, ~/.rhosts, ~/.shosts, /etc/rc*, /etc/rc?.d/*, /etc/init.d/*, /etc/syslog.conf, /etc/crontab, /etc/aliases, /etc/hosts.deny, /etc/hosts.allow など * 不審な隠しファイル (例えば、"..."、".. " など) が残されていない かを確認します。 # find / -name ".*" -print | cat -v ただし find コマンドが、不審なファイルを隠蔽するために置き換えられて いる可能性もあるので、まず find コマンドが置き換えられていないことを 確認してください。詳細は「VII. (付録) 置き換えの有無をチェックする方 法」をご参照ください。 * ps や netstat コマンドなどにより、見知らぬプロセスが存在していたり、 LISTEN している (接続を待ち受けている) 見知らぬポートや不審な接続が 存在していないかを確認します。あらかじめ、汚染されていないことが保証 されている状態でのプロセスの一覧や LISTEN しているポートの一覧などを 別のシステム上に保存しておくことをお勧めします。 ただし ps や netstat コマンドなどが、侵入者によるプロセスやネットワー ク接続などを隠蔽するために置き換えられている可能性もあるので、まずこ れらのコマンドが置き換えられていないことを確認してください。詳細は 「VII. (付録) 置き換えの有無をチェックする方法」をご参照ください。 * 使用しているプログラムの最新バージョンや関連するセキュリティ文書を参 照して弱点を放置していないかを確認します。 個別のセキュリティ上の弱点については、JPCERT/CC の公開文書 [7] [8] や、参考資料 [9] [10] などの各種セキュリティ勧告文書などを随時参照し てください。また、参考資料 [11] [12] もご参照ください。 VII. (付録) 置き換えの有無をチェックする方法 「VI. Unix 系システムにおける侵入発見チェックリスト」で紹介したリス トの各項目に関連して、チェック作業に用いるコマンドやそのコマンドに関連 したログファイルなど (特にバイナリ形式のファイル) が侵入者によって置き 換えられていないことを確認する方法について説明します。 コマンドが置き換えられていないことを確認する方法にはいくつかの方法が ありますが、最もシンプルな方法は、事前に汚染されていない状態で保存して おいたシステムの情報と比較する方法です。まずあらかじめ、新規に OS がイ ンストールされた、もしくはパッチが適用された直後などの、汚染されていな いことが確実に保証されている状態において、各コマンドファイルに対して MD5 などでチェックサムを計算し、その結果を別のシステム上に保存しておき ます。そしてチェックの対象となるコマンドファイルに対して同様にチェック サムを計算し、出力された文字列をあらかじめ保存しておいた文字列と比較し ます。もし 1文字でも違いがあれば、それは何らかの置き換えが行なわれたこ とを示しています。また、コマンドファイルだけでなく、そのコマンドが動作 する際にリンクする動的リンクライブラリ (dynamic link library) に対して も、同様の手順で置き換えが行なわれていないかどうかを確認する必要があり ます。どの動的リンクライブラリをリンクするかは ldd などのコマンドを、 そのコマンドファイルに対して実行することで調べることができます。 コマンドに関連したバイナリ形式のログファイルが置き換えられていないこ とを確認するための一般的な方法はありませんが、少なくともそれらのファイ ルの最終更新時刻だけはまず最初に確認すべき点です。それらのファイルが更 新されるべき時刻以外の時刻に更新されている場合は、何らかの置き換えや書 き換えが行なわれている可能性があります。また、strings コマンドなどを用 いて、ファイルの中に不審な文字列が含まれていないかどうかを確認すること も必要です。 VIII. 参考資料 [1] 関係サイトとの情報交換 http://www.jpcert.or.jp/ed/2002/ed020001.txt [2] Intruder Detection Checklist http://www.cert.org/tech_tips/intruder_detection_checklist.html [3] Steps for Recovering from a UNIX or NT System Compromise http://www.cert.org/tech_tips/win-UNIX-system_compromise.html http://www.auscert.org.au/Information/Auscert_info/Papers/win-UNIX-system_compromise.html [4] CIAC-2305 Unix Incident Guide: How to Detect an Intrusion ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2305.pdf ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2305.txt [5] Windows NT Intruder Detection Checklist http://www.auscert.org.au/Information/Auscert_info/Papers/win_intruder_detection_checklist.html [6] "Identification Protocol", RFC 1413, M. St. Johns http://www.ietf.org/rfc/rfc1413.txt [7] JPCERT/CC 発行の緊急報告・注意喚起 http://www.jpcert.or.jp/at/ [8] JPCERT/CC レポート http://www.jpcert.or.jp/wr/ [9] CERT(R) Advisory http://www.cert.org/advisories/ [10] Vulnerability Notes Database http://www.kb.cert.org/vuls/ [11] UNIX Computer Security Checklist http://www.cert.org/tech_tips/AUSCERT_checklist2.0.html http://www.auscert.org.au/Information/Auscert_info/Papers/usc20.html [12] UNIX Configuration Guidelines http://www.cert.org/tech_tips/unix_configuration_guidelines.html [13] Windows NT Configuration Guidelines http://www.auscert.org.au/Information/Auscert_info/Papers/win_configuration_guidelines.html __________ 注: JPCERT/CC の活動は、特定の個人や組織の利益を保障することを目的とし たものではありません。個別の問題に関するお問い合わせ等に対して必ずお答 えできるとは限らないことをあらかじめご了承ください。また、本件に関する ものも含め、JPCERT/CC へのお問い合わせ等が増加することが予想されるため、 お答えできる場合でもご回答が遅れる可能性があることを何卒ご承知おきくだ さい。 注: この文書は、コンピュータセキュリティインシデントに関する一般的な情 報提供を目的とするものであり、特定の個人や組織に対する、個別のコンサル ティングを目的としたものではありません。また JPCERT/CC は、この文書に 記載された情報の内容が正確であることに努めておりますが、正確性を含め一 切の品質についてこれを保証するものではありません。この文書に記載された 情報に基づいて、貴方あるいは貴組織がとられる行動 / あるいはとられなかっ た行動によって引き起こされる結果に対して、JPCERT/CC は何ら保障を与える ものではありません。 __________ 1999-2002 (C) JPCERT/CC この文書を転載する際には、全文を転載してください。情報は更新されてい る可能性がありますので、最新情報については http://www.jpcert.or.jp/ed/ を参照してください。やむを得ない理由で全文を転載できない場合は、必ず原 典としてこの URL および JPCERT/CC の連絡先を記すようにしてください。 JPCERT/CC の PGP 公開鍵は以下の URL から入手できます。 http://www.jpcert.or.jp/jpcert.asc __________ 改訂履歴 2002-06-06 参照 URL の更新 「VI. Unix 系システムにおける侵入発見チェックリスト」の更新 「VII. (付録) 置き換えの有無をチェックする方法」の追加 2001-12-27 参照 URL の更新と Microsoft Windows 関連の参考資料の追加 2000-08-25 参照 URL の更新 1999-12-09 初版 -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBPP6qrox1ay4slNTtAQFcLgP+NVN/wveqBEezDUnmlfUy4FdmtQX3tovr fQNcL6fWcH7J+jgUhO/ZHrCeuiGOE/BIODgXcHkhNb264o/CiaKMWl+mJAZL7Ip+ TVXnBNsTg2w7htd1ydFTx3uZF+xjzO6wulAc8koGIPOmsFZcEp93nRssByk+5Vjb 1re2R6TxD4g= =H3/N -----END PGP SIGNATURE-----