インシデントを発見する方法（1）- インシデントを的確に発見する方法 -：管理者のためのセキュリティ推進室〜インシデントレスポンス入門〜（2）

　インシデントレスポンスで最も重要な点の1つは、インシデントが起こっている、または起こってしまったということをいかに素早く的確に察知するかである。今回と次回の2回にわたり、インシデントを発見する具体的な方法について解説していく。発見した後の具体的な対応方法については、その後に解説する。

ログの取り扱い

　インシデントにはさまざまな種類があり、具体的な発見方法はそれぞれ異なる。また必ずしもログの内容さえ確認していれば十分というわけではないが、それでも、まずログに記録された内容を確認することはインシデントレスポンスの第一歩である。

　従って、ログに記録されている項目がそれぞれ何を意味しているのかを事前に理解しておく必要があるのはいうまでもないが、もしログの内容をカスタマイズできる場合には、“どういった項目をログに記録するか”を事前に検討しておくことが重要なポイントとなってくる。

　ここでログの内容をカスタマイズする方法として、syslog機能を紹介する。

　The BSD syslog Protocol（http://www.ietf.org/rfc/rfc3164.txt）

　これはUNIX系のOSでは古くから標準で存在する機能であるが、ルータなどの多くのネットワーク機器やWindowsでも用いられている機能である。このsyslog機能を使ってログ（メッセージ）を出力するソフトウェアは、多くの場合、priority（またはseverity）と呼ばれる“レベル”によって、ログに記録する内容をカスタマイズできる。

　UNIX系OSのカーネルやsendmail、named（BIND）、tcpd（tcp_wrappers）など、syslog機能を使っているものは多いが、ではどの“レベル”までログを取得すればよいのだろうか？

　もちろん、最も低いレベル（LOG_DEBUG）からすべて取得するという方法もあるであろう。しかしこの場合は、インシデントを発見するという点ではほとんど意味のない情報が大量に保存される可能性が高く、結果として、真に重要な情報を見落としてしまう危険性がある。一方、深刻なレベルだけを保存している場合は、インシデントの“兆候”、さらにいうとスキャンやプローブのような“弱点探索”といった、現時点では実害はないが今後の対応を検討するのに有益と考えられる情報が保存されない可能性もある。

　重要な点は、各ソフトウェアがsyslog機能のおのおののレベルでどういった情報を記録するのかを事前に確認したうえで、実運用に合ったレベルを選択するということである。

　またsyslog機能以外にも、WebサーバのApacheのように独自の方法でログに記録する内容をカスタマイズできるソフトウェアが存在する。そのようなソフトウェアを使う場合は、使用するソフトウェアのマニュアルをよく読み、ログにどのような（またはどの程度の）情報を記録すべきかについて、十分に検討しておくことをお勧めする。

　次に検討しておく必要があるのは、ログの保存期間である。

　極端に古い情報まですべて保存しておくというのは現実的ではないが、それでも過去にさかのぼって何らかのインシデントについて確認を迫られる場合もあり得る。ある程度の期間は保存しておくべきであろう。しかし、適切な保存期間というものは、ソフトウェアの使用環境や使用状況、設定内容などによって異なってくるので、ただやみくもに“何カ月”と決めることはできない。この点についても実際にログに保存される内容（情報）を吟味して、十分に検討することをお勧めする。

ログやシステムの状態からインシデントを発見

　管理すべきOSやサーバプログラムなどのログがそれぞれどのファイルにあるのかを整理しておくことはいうまでもないが、さらにそれらのログには、正常な状態であればどのような情報がどのような形式で保存されるのかをあらかじめ整理し、記録しておく。そのうえでログの内容を定期的にチェックし、通常とは異なる内容の記録が保存されていないかどうかを確認する。

　また、ログの中にはテキスト形式ではなく、バイナリ形式で保存されるものもある。この場合は、そのログを読むためのコマンドが存在するので、そのコマンドの使い方をあらかじめ整理しておく。特にそのようなコマンドの多くは実行時のオプションで表示内容を変えることができるので、必要な情報を得るためにはどのようなオプションで実行すべきかも整理しておく必要がある。

　ログのような“履歴”ではなく、“現在”のシステムの状態を確認するには、そのために用意されたコマンドを用いる。これらのコマンドについても、表示内容やオプションなどを整理しておく。

　ログを確認したり、システムの状態を確認する際の例を、インシデントを発見するという視点で、以下にいくつか紹介する。

（1）tcp_wrappersによるアクセス制限

　tcp_wrappersのtcpdやlibwrapなどを使ってアクセス制限をしている場合、アクセスを許可していないホストからアクセスがあると、次のような記録がログ（OSによってファイル名は異なる）に残される。

Jul 1 13:50:41 svr sshd[6241]: refused connect from src.jpcert.or.jp

　これは、アクセスを許可していないsrc.jpcert.or.jpというホストから、svrというサーバのsshd（22/tcp）へのアクセスをsvrのtcp_wrappersが拒否していることを意味している。このアクセスが弱点探索を意図しているものか、単純に操作ミスによるものかは、この記録だけでは分からない。しかし管理者の意図しないアクセス（の試み）が行われたことだけは明らかである。

　ただし、アクセス元として記録されているsrc.jpcert.or.jpというホスト名が詐称されていたり、また詐称されていなくても、「踏み台」として悪用されている可能性もあるので、アクセス元へ通知連絡などを行う場合には十分に注意してほしい。

（2）メールの中継の拒否

　メールサーバを、管理者の意図しないメールの中継（relay）点として使われ、SPAMメールの送信元にされてしまうインシデントがある。

　例えばメールサーバのログに次のような記録が残っているとする。

Jul 1 14:14:48 mx postfix/smtpd[12801]: reject: RCPT from src.jpcert.or.jp[172.16.0.10]: 554 <foo@example.co.jp>: Recipient address rejected: Relay access denied; from=<bar@example.com> to=<foo@example.co.jp>

　これはsrc.jpcert.or.jp（IPアドレス：172.16.0.10）から、mxというメールサーバにSMTPで接続し、bar@example.comから foo@example.co.jpあてのメールを中継させようとしたが、mxのSMTP サーバ（この例ではpostfix）に拒否されたということを意味している。この場合は、特に被害は受けていないが、中継点として使えるかどうかチェックされた可能性がある。

　ここで注意しなくてはいけないのは、アクセス元として記録されているsrc.jpcert.or.jpというホスト名や172.16.0.10というIPアドレスが詐称されている可能性もあり得るという点である。特にこのようなメールの中継に関しては、DNSの逆引きが詐称されている場合が多いため、アクセス元へ通知連絡などを行う場合には十分に注意する必要がある。

（3）ログイン履歴、コマンド履歴

　最も単純な侵入手法として古くから使われているのは、何らかの（技術的または非技術的な）手法で正規のユーザーのパスワードを取得し、正規の認証を経てログインする方法である。このようなインシデントは、ログインの履歴を調べて、想定しない時間帯に想定しないホストからログインが行われていないかを確認することで発見できることがある（もちろん必ず発見できるとは限らない）。

　一般にUNIX系のOSの場合はログイン履歴のログがバイナリデータ（OSによってファイル名は異なる）として保存されており、それらの閲覧にはlastコマンドなどの専用のコマンドを用いる。

　また、~/.bash_historyや~/.historyなどの、シェルの機能によって保存されたコマンド履歴のデータから、管理者や正規のユーザーが意図しないログインや意図しないコマンドの実行がなかったかどうかを確認する方法がある。

　さらに、ユーザーの実行したすべてのコマンド履歴を保存する方法として、多くの UNIX系OSにはacct（accounting）と呼ばれる機能がある。またacct以外にも同様の機能を有しているOSが存在するので、詳細は各OSのマニュアルを参照してほしい。

（4）OSの起動時刻

　侵入やサービス運用妨害攻撃などのインシデントが発生した後に、システムが再起動する場合がある。これは攻撃者が意図的に行う場合もあれば、攻撃の副次的な作用として起こる場合もある。

　システムの起動時刻はUNIX系のOSの場合、uptimeコマンドを実行することで確認できる。

9:41AM up 3 days, 21:48, 1 user, load averages: 0.15, 0.13, 0.09

　このうち「up 3 days, 21:48」が意味するのは、最後にシステムが起動してから「3日と21時間48分」が経過しているという意味である。

　しかしシステムが想定外の時刻に起動していることが、直ちに何らかの攻撃の結果であるとは限らないことに注意してほしい。OSのバグなどが原因で自動的に再起動することもあるので、この場合はOSのカーネルから出されているメッセージのログなども併せて確認することを強くお勧めする。

　攻撃者が意図的にシステムを再起動させた場合、再起動後のシステムでは、管理者の意図しないプロセスが実行されていたり、カーネルモジュールが組み込まれている可能性がある。プロセスの確認については次項「5.プロセステーブル」を、またカーネルモジュールの確認については「7.カーネルモジュール」を参照してほしい。

（5）プロセステーブル

　侵入が行われた後に、バックドアと呼ばれる「裏口」が設置されたり、「踏み台」として別のホストを攻撃するツールが設置されることがある。この場合は、そのシステムおいて不審なプロセスが稼働している可能性が高い。現在実行中のすべてのプロセスは、UNIX系のOSならばpsコマンドを以下のように実行することで、確認できる。

　まず事前に正常に動作している状態でのプロセステーブル（上記psコマンドの出力結果）を保存しておく。そしてそれと現在のプロセステーブルを比較し、何か必要なプロセスが停止していないか、もしくは不要な（不審な）プロセスが動作していないかを確認する。またプロセスの中でシステムの起動以後の、意図しない時刻に再起動しているものがないか、おのおののプロセスの開始時刻なども確認する。

　またプロセステーブル上では特に不審なプロセスが存在しないにもかかわらず、通常よりもシステム負荷が高い場合は、正常なプロセスに偽装した不審なプロセスが何らかの処理を行っている可能性がある。

　しかし正常と異なる状態が、必ずしも何らかの攻撃を受けた結果とは限らないことに注意してほしい。正規ユーザーが起動したプログラムが誤動作をしているなど、さまざまな原因が考えられるので、何らかの不審な動きをしているプロセスがある場合は、その実行ユーザーや起動時刻などを確認してほしい。

（6）通信状況

　侵入が行われた後にバックドアなどが設置された場合には、そのシステムにおいて何らかの不審な通信が行われている、もしくは何らかのポート番号でクライアントからの接続を待ち受けている可能性がある。このようなシステムの通信の状況は、UNIX系OSやWindowsならば、netstatコマンドを「-a」オプションを付けて実行することで確認できる。

　通信状況についても、プロセステーブルと同様に、事前に正常に動作している状態での「netstat -a」の出力結果を保存しておく。そしてそれと現在の「netstat -a」の出力結果を比較し、正常な状態では使われないポート番号を使用した通信が行われていないかなどを確認する。

　しかし正常と異なる状態が、必ずしも何らかの攻撃を受けた結果とは限らないことに注意してほしい。正規ユーザーが起動したプログラムが誤動作をしているなど、さまざまな原因が考えられるので、何らかの不審な通信が見られる場合は、プロセステーブルなどと照らし合わせて、どのプロセスによって行われている通信か、またそのプロセスを実行しているユーザーはだれかなどを確認してほしい。

　またinetdのようなサーバプログラムの待ち受け部分だけを担うプログラムの設定が改ざんされている場合は、「netstat -a」の出力から、管理者の意図しないポート番号を使ってクライアントからの接続を待ち受けていることは分かるのだが、プロセスとしてはinetdが動作しているだけで、特に不審なプロセスが見当たらないことがある。その場合はinetdなどの設定ファイル（一般に/etc/inetd.confなど）の内容を確認して、設定が追加されているなどの改ざんが行われていないかどうかを確認する。

（7）カーネルモジュール

　侵入が行われた後には、バックドアの設置や通信データの盗聴などのさまざまな目的で、管理者の意図しないモジュールがカーネルに組み込まれていることがある。

　カーネルモジュールの状態は、OSに付属のコマンドを使って確認することができる。

　カーネルモジュールについても、プロセステーブルと同様に、事前に正常に動作している状態でのモジュール一覧を保存しておく。そして現在のモジュール一覧と比較し、意図しないモジュールが組み込まれていないかどうかを確認する。

（8）ユーザー登録

　侵入が行われた後には、ユーザーが新規に登録されていたり、ユーザー（管理者を含む）のパスワードが変更されていることがある。

　一般に、UNIX系OSの場合は/etc/passwdファイルなどを見ることで現在登録されているユーザーを確認することができる。

　プロセステーブルなどと同様に、正常な状態でのユーザー一覧をあらかじめ保存しておく。そして現在のユーザー一覧と比較し、不審なユーザーが登録されていないかどうかを確認する。また（可能ならば）おのおののユーザーのパスワードが変更された時刻を保存し、管理者やユーザーの意図しないパスワードの変更が行われていないかを確認する。

（9）サーバプログラムの異常終了

　侵入に悪用される弱点として最も多いのが、プログラムのミスによるバッファオーバーフローの脆弱性である。通常、この弱点を悪用されたサーバプログラムは異常終了するが、サーバプログラムの設定によっては異常終了しても自動的に再起動する場合がある。そのため、実行中のプロセステーブルを見たり、待ち受けポートの様子を観察しているだけでは気が付かないことがある。しかしその場合もログに「Segmentation fault」のような記録が残っていれば、そのプログラムが異常終了していることが確認できる。

　例えば、Web サーバプログラムとして広く使われているApacheの場合、error_logに次のような記録が残っている場合は、何らかの原因で異常終了が起こっていることを意味する。

[Mon Jul 1 13:54:23 2002] [notice] child pid 11219 exit signal Segmentation fault （11）

　しかし、この記録が直ちに何らかの攻撃を受けた、もしくは侵入が行われたということを意味するのではないことに注意してほしい。この記録自体はあくまでApacheの子プロセスが異常終了したということを示しているにすぎない。しかしながら何らかのインシデントが発生した可能性がないとはいえない。むしろその可能性は増しているといえる。まずこの記録に残っている時刻「Mon Jul 1 13:54:23 2002」前後に何らかの不審なアクセスがなかったかどうか、またシステム上のファイルが改ざんされていないかどうかをほかのログを見るなどの方法で確認する必要がある。なお、ファイルの改ざんを発見および確認する方法については、次回で詳細に解説する。

　今回は、ログやシステムの状態を見ることで、何らかのインシデントが発生していないかどうかを確認するという、最も簡単な方法を紹介した。

　しかし最近のインシデント、特に「侵入」においては、「痕跡」を消すことで、インシデントが発生したことを管理者に気付かせにくくする手法が広く使われてきている。そこで次回は、システム上のファイルなどが改ざんされるなどして、インシデントの痕跡が消されてしまっている場合のインシデントの発見方法について紹介する。