セキュリティインシデント対応(草案)

Last Up ： 2003/10/17 (森川靖大)  <<  Orginal : 2003/09/29 (森川 靖大)

この文書は、 専攻サーバにおいて何らかのセキュリティインシデントが発生した場合、 具体的にどのような対応を行うべきかを記した手引である。 なお、以下の対応手順は原則的に 専攻サーバのセキュリティポリシー に従うものとする。

下記で想定されない事態が起こり、 セキュリティポリシー と対応手順とが食い違う場合も起こりうる。 このような場合には、 セキュリティポリシーを優先し、 臨機応変に行動せよ。

1. インシデント情報の受信

専攻のインシデント情報の受信窓口として以下のものが用いられている。 (これらが用いられなければならないというわけではない。 ただ、現在受信窓口として用いられ得るものを列挙した。)

epcore-ml@ep.sci.hokudai.ac.jp --

専攻サーバ技術支援グループのメーリングリスト。
インシデントがこのグループ内で見つかった場合にはここに情報が送られる場合が多い。

epnetfan-ml@ep.sci.hokudai.ac.jp --

EPnetFaNのメーリングリスト。
インシデントがこのグループ内で見つかった場合にはここに情報が送られる場合が多い。

netcom@ep.sci.hokudai.ac.jp、
netcom-query@ep.sci.hokudai.ac.jp		 --

ネットワーク委員会のメーリングリスト。
外部からのインシデント情報はここに送られる場合が多い。 (どうも、個人的にネットワーク委員に HINES から連絡が行く場合も多いようだが…)

(報告者への返答)

外部の報告によってインシデントが発覚した場合、 願わくば事態が収集した後、概要と謝意を報告者に伝えるべきである。 しかし、インシデントの解決に時間がかかりそうな場合には、 とりあえず報告者に現状を連絡すべきであろう。

2. インシデント情報の共有

専攻サーバのインシデント情報を入手した者は epcore-ml@ep.sci.hokudai.ac.jp にこの情報を送り、 専攻サーバ技術支援グループ内で情報を共有するようにすること。 単独での判断、行動はミスを生じやすい。 また、メーリングリストに情報を送っておくことは情報の記録にもなる。

3. インシデントの確認

インシデント情報を元に、インシデントが本当に専攻サーバにおいて生じているのか確認する。

まずは、インシデントの対象と目されるホストに触れず、 報告されたインシデント情報から分かる範囲でインシデントの状況を考察する。 たいていは以下の事柄についての判断はつくであろう。 (つかないかもしれないが)。

この情報は次の4. 対応策の検討にて用いられるのでメモしておくこと。

繰り返すが、現段階では インシデントの対象と目されるホストに触れないこと。 場当たり的な作業を行うと、 データやシステム、ネットワークに対するダメージを更に広げたり、 起こってもいないインシデントに振り回される危険性が高い。 まずは周辺情報を元に何を探査すべきか考慮すること。

4. 対応策の検討

3. インシデントの確認において得られた情報から、 対応策を考える。 以下にいくつかの例を示す。 なお、以下で用いられる当該ホストとは、 報告された情報において、 インシデントの発生が示唆されているホスト (複数もありうる) である。

ここで想定されないような場合もあるだろう。 その場合にはセキュリティポリシーに従い、 適切な対応を試みて欲しい。 でき得るならば、その際の対応を以下に加えて欲しい。

[4.1]   専攻内 (専攻サーバや専攻内の他のホスト) でインシデントが発生していないことが明白である場合
[4.2]   専攻内のその他のホストによるインシデントであることが明白な場合
[4.3]   専攻の当該ホストに原因があることが否定しきれない場合

[4.1] 専攻内 (専攻サーバや専攻内の他のホスト) でインシデントが発生していないことが明白である場合

1) その旨と 2) 証拠 を a) 技術支援グループ (epcore-ml@ep.sci.hokudai.ac.jp)、 b) 報告者 へ連絡すること。 これにて今回のインシデント対応は完了となる。

※ インシデント対応が完了したかどうかは当該サーバの管理者だけでなく、 技術支援グループ全体で判断すること。 単独での判断は、重大なインシデントを見逃す可能性が高い。

[4.2] 専攻内のその他のホストによるインシデントであることが明白な場合

技術支援グループで対処できる問題であれば対処し、その後、 1) インシデントのあったホストの情報 2) 作業報告 3) 現状 を a) 技術支援グループ (epcore-ml@ep.sci.hokudai.ac.jp)、 b) 報告者 へ連絡すること。

(当該ホストが技術支援グループ管轄でない場合等) 技術支援グループによる対処が無理ならば、 ネットワーク委員会に対処の依頼を行う。 その際にもネットワーク委員会 (netcom@ep.sci.hokudai.ac.jp) に 1) インシデントのあったホストの情報 2) 具体的な対処法 を提示すること。 対処された後、報告者 への連絡も忘れないこと。

これにて今回のインシデント対応は完了となる。

※ この場合も、最終的には技術支援グループ全体で判断すること。 なお、「明白」な場合のみこの方法をとること。 「可能性がある」ような場合に関しては [4.3] 専攻の当該ホストに原因があることが否定しきれない場合 の対処法を選択せよ。

[4.3] 専攻の当該ホストに原因があることが否定しきれない場合

当該ホストに原因が無いと言い切れない場合、まずは 5. ネットワークからの隔離・データの退避 を行う。

ここで、原因がある場合と言っていないのは、 実際に当該ホストを調べても不正侵入等の痕跡を見付ける事が難しいからである。

人によっては不正侵入の証拠を探したくなるかも知れない。 しかし、それはデータの保護や他者への不正アクセスの防止、 専攻サーバとしてサービスを行う事よりも優先されるべきものではない。 どうしても不正侵入の探査がしたいのであれば、 それらを優先しつつ実行すること。

5. ネットワークからの隔離・データの退避

インシデントの可能性が否定できない場合 (もしくは明らかにインシデントが当該サーバに発生している場合)、 できるだけ速やかにシステムを復旧する必要がある。 しかしその前に、セキュリティポリシーに従い、 ネットワークからの隔離、及び専攻のオリジナルデータの退避を行う。

なお、この作業によって実質的にサービスは停止される。

この作業は当該サーバの管理者が行うべきだが、なんらかの事情によりそれが不可能な場合、 当該サーバのチュータや epcore マネージャなど、当該サーバの root 権限を持つユーザが行う。 もしも root 権限を持つユーザが全くいない場合、ネットワークからの隔離だけでもおこなうこと。

  1. ネットワークからの隔離
  2. データの退避

セキュリティポリシー に従えば、データの退避の方がネットワークからの隔離よりも優先される。 しかし大抵の場合、ネットワークから隔離させた後の方が、 データを安全に退避させられる。 つまり、データの退避を優先する観点から、 ネットワークからの隔離が先に行われる作業として記されているわけである。

6. 関係各所への連絡

サーバの停止後、関係各所へ必要事項を連絡すること。

なお、専攻ユーザへはネットワーク委員会から連絡が行われる。

7. インシデント停止を確認

1. インシデント情報の受信 におけるインシデント情報の報告者に、 インシデントが停止したかどうかを確認する。

もしも、インシデントが停止していなければ、 インシデントの発生しているホストは当該サーバだけではないことになる。 この場合には再び 3. インシデントの確認 に戻り、さらにインシデント元を探査すること。

原因が他にあるからといって、ここまでインシデントが発生していると考えていたサーバをすぐに復帰させないこと。 なぜならば、そのサーバは複数あるインシデント発生ホストの一つかもしれないからである。

8. システム復旧

データの退避、およびネットワークからの隔離が完了したら、システムの復旧を行う。 ここでの「復旧」とは最も確実な方法である「システムの再構築」を指す。 専攻サーバの再構築マニュアルを元に、システムの再構築をおこなう。

汚染箇所を探査し、システムから全ての汚染箇所を取り除くことも不可能では無い。 しかし、おそらくはシステムの再構築が最も効率的で確実な方法である。

なお、この段階で既にインシデントの原因が分かっており、 さらに対応がとれる場合には、それを実行すること。

例えば、インストールしていたソフトウェアにセキュリティホールがあった場合等がこれにあたる。 このような場合にはすぐにパッチをあてるなどしてしてセキュリティホールをふさぐこと。 もしもソフトウェアのセキュリティホールが防げない等の事情があるならば、 そのソフトウェアをアンインストールする等の選択肢もあり得るだろう。

9. データへのダメージの把握

復旧したシステムを用い、できる範囲でデータへのダメージを把握する。 具体的には、インシデント発生前と後、 もしくはサーバ停止前と起動後でデータの内容を比較し、 データに損失が無いのか、もし損失があるのならば どれくらいの損失なのかを確認するということである。

確認した事項はメモしておくこと。 復旧後の報告にて関係各所に連絡する。

10. サービス再開

システムの復旧が完了したら、サービスを再開する。

11. 関係各所への報告

サービスの再開後、関係各所へサービスの再開を連絡すること。 また、データに損失 や 停止することにしたサービス がある場合には、その内容も報告すること。

なお、専攻ユーザへはネットワーク委員会から連絡が行われる。

12. インシデント対応のレポート

サービスが再開され、復旧作業が一段落したら、 今回のインシデントに関するレポートをまとめる。

なお、このレポートを epcore トラブルカルテ に置いておくことを忘れずに.

13. 原因の究明・改善策の検討と実施

レポートを元に (できる範囲内で) 原因を究明し、 再び同じ事故や被害が発生しないように セキュリティポリシー やサーバの構成の見直し行う。 インシデントの対応手順 (要するに本文書) に不備があった場合はそれらの改善を行う必要もあるだろう。

ただし、忘れないで欲しいのが、常に 損失のリスク と セキュリティのコスト を天秤にかけて考慮するということである。 専攻サーバの管理を直接的に行っているのは (原則的に) ボランティアの学生であり、本業として研究等々の仕事を多く抱えている。 また、サーバ管理の経験もほとんど無く、 管理しながら勉強しているのが現状である。 よって、セキュリティ対策を行う場合には、 サーバ管理している各々の学生が本業を全うでき、 その技術レベルは未熟、 であることを前提としなければならない。

・参考 >> サイトセキュリティハンドブック (Site Security Handbook): [2.1 セキュリティポリシーは、なぜ必要か？]

この判断はかなり微妙なところがあり、 どこまでが許されるかというのははっきり線引きできない。 管理する学生の数、個々人の特性、 能力によっても行える対策に違いが出るだろう。

だが、例えば (極端な例ではあるが) 24時間体制でサーバの面倒を見なければならない、 といった無茶な対策や、 管理者がサーバに侵入を試みるクラッカーと同等な技術力を持っていると仮定するような実行不能なインシデント対策計画を立てるのはさすがに勘弁して頂きたい。

場合によっては、 「何もしない」という対策が最も妥当な場合もあるだろう。

14. その他のサーバのチェック

専攻サーバではそのユーザ管理に gate-toroku-system を用い、全サーバでユーザを共通化している。 そのため、一つのサーバにインシデントが発生した場合、 その他のサーバにもインシデントが飛び火する可能性がある。

よって、発生したインシデントに応じて、 その他のサーバのチェックを行うのが望ましい。

…とはいえ、実際に完全にチェックしきるのは不可能であるし、 何よりチェックにはコストがかかる。 インシデントの程度によってはチェックを行わないという選択肢もあり得る。

ちなみ、rootkit の簡易検出ツールとして chkrootkit というツールが存在する。 余計なお節介だが、この chkrootkit による探査マニュアルとして chkrootkit CD の作成と使い方 を作成した。使用に耐え得るのであれば使って頂きたい。

15. 経過を見守る

上記までの作業が完了したら、 今回のインシデントへの対応は終了となる。 後は主に以下のことに注意し、経過を見守ることとなる。

◆ 参考資料

Copyright © 2003 epcore