連載
» 2002年07月31日 10時00分 UPDATE

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

本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント(不正アクセス)に関する情報を紹介する。(編集局)

[JPCERT/CC,@IT]

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

ログの取り扱い

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

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

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

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

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

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

※ ログやシステムの状態を確認するためのコマンドが、“信用できる”コマンドであるか、つまり改ざんされていないかどうかについても、そのコマンドを実行する前に確認しておく必要がある。この点については次回で詳細に解説する。以降の内容は、これらのコマンドの“integrity(完全性)”は保証されているものとして読み進めてほしい。


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

(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メールの送信元にされてしまうインシデントがある。

※ 最近のSMTPサーバプログラムの多くは標準で中継を拒否する設定になっている。


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

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コマンドを以下のように実行することで、確認できる。

BSD系 ps aux
System V系 ps -ef

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

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

※ システム負荷(load average)は、UNIX系のOSの場合、uptimeコマンドやtopコマンドなどを使うことで確認できる。


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

(6)通信状況

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

※ 表示内容の詳細については、netstatコマンドのマニュアルを参照してほしい。


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

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

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

(7)カーネルモジュール

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

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

※ Linuxの場合はlsmodコマンド、BSD系のOSの場合はkldstat(FreeBSD)、modstat(NetBSD、OpenBSD)、kmodstat(Darwin)などのコマンドがある。詳細は各OSのマニュアルを参照してほしい。


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

(8)ユーザー登録

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

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

※ MacOSXのNetInfoなどを使ってユーザーを管理している場合は、/etc/passwdにユーザーの情報が記載されないことがある。そのような場合、登録されているユーザーを確認するために専用のコマンドやツールが用意されている。詳細は各OSのマニュアルを参照してほしい。


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

※ パスワードなどの、ユーザーに関する情報が保存されるファイルやログはOSによって異なる。詳細は各OSのマニュアルを参照してほしい。


(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」前後に何らかの不審なアクセスがなかったかどうか、またシステム上のファイルが改ざんされていないかどうかをほかのログを見るなどの方法で確認する必要がある。なお、ファイルの改ざんを発見および確認する方法については、次回で詳細に解説する。


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

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


■コラム 〜JPCERT/CCによるインシデントレスポンス〜

 JPCERT/CCが行うインシデントレスポンス業務には、大きく分けて以下の3つがある。

(1) 情報提供の受付

 インシデントの被害を受けたサイトの管理者などから提供された、被害の状況や(技術的な)対応内容などの情報を受け付ける。それらの情報は統計データとして蓄積されるだけでなく、同様の被害が多発している、または多発が予想される場合には、対策方法などを整理し、「緊急報告」という形で文書を公開する。

(2) 質問への回答

 インシデントの被害を受けたサイトの管理者などから、対策についての質問を受けた場合に「一般的な対策方法」を伝える。具体的にどのようなインシデントが起こっているかについて、報告された情報から考えられる可能性を列挙したり、関連すると思われるWebページのURLを紹介するなどの対応をしている。

※ JPCERT/CCでは、被害を受けたサイトにエンジニアを派遣するなどの対応は行っていない。


(3) 連絡の仲介

 インシデントに関連するサイト(主にアクセス元)への連絡を仲介する。

 JPCERT/CCの業務のうち、現在最も多くを占めているのが連絡の仲介である。特に海外のサイトからの仲介依頼が大半を占めている。具体的には、海外のサイトにおいて何らかのインシデント(主にスキャンなどの弱点探索と思われるアクセス)が発生し、そのインシデントに関連するサイト(主にアクセス元など)が日本のサイトである場合に、その日本のサイトの「管理者」に日本語で連絡するように、海外のサイトの管理者などから依頼される。またその海外のサイトを顧客とするCSIRTから依頼を受けることも多い。

 連絡先の「管理者」として、JPCERT/CCは主にJPNIC(またはJPRS)のwhoisデータベースに登録された「技術連絡担当者」を使う。連絡方法は基本的に電子メールであるが、必要に応じてFAXも用いる。

 多くの場合、JPCERT/CCから日本のサイトの管理者に連絡することにより、その日本のサイトが何らかの「踏み台」として使用されていることが判明し、対策を施してもらうことにより、インシデントの再発が防がれている。また、対策が施されたか否かにかかわらず、状況については、報告元(海外のサイト)に伝えている。

※ このような海外からの仲介依頼だけでなく、日本国内からの仲介依頼もある。


 このようなインシデントに関連するサイトへの連絡を自ら行う場合には、JPCERT/CCが公開している以下の文書を参考にしてほしい。

 技術メモ - 関係サイトとの情報交換http://www.jpcert.or.jp/ed/2002/ed020001.txt

 なお、関連サイトに連絡する際には、Cc(Carbon Copy)にinfo@jpcert.or.jpを指定することで、JPCERT/CCにも併せて連絡をいただきたい。この場合、JPCERT/CCは特に対応は行わないが、「情報提供」していただいたものと判断し、統計データとして蓄積するとともに、JPCERT/CCが公開するさまざまな文書を作成する際の重要な参考データとして使わせていただく。

 上記(1)、(2)、(3)のいずれの場合も、JPCERT/CCあてに直接連絡する際は、以下のWebページにある「報告様式」を使っていただければ幸いである。

 JPCERT/CCへの連絡方法http://www.jpcert.or.jp/form/

※JPCERT/CCでは、電子メールとFAX以外による報告は受け付けていない。


 なお、インシデントに関連するサイト名そのものや、そのサイトが類推される可能性のある情報が外部に漏れることがないように、JPCERT/CCに送付された電子メールやFAXの内容は厳重に管理している。

 次回のコラムでは、JPCERT/CCの最近の国際的な活動について紹介する予定である。


Profile

JPCERT/CC

JPCERT/CCとは、Japan Computer Emergency Response Team/Coordination Center(コンピュータ緊急対応センター)の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティインシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに加盟している日本唯一のCSIRT。


[an error occurred while processing this directive]

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。