EPNetFan 的管理者への路シリーズ(??)

■□■ログの管理とセキュリティ■□■

〜〜楽しい??ログの見方 〜〜
2002/02/01 Manabu YAMADA

●目次

0. はじめに

近年 Redcode,, Redcode II, W32.nimda, Badtrance などなど 様々なワーム, トロイの木馬が出現し, 北大ネットワーク内でも 攻撃を受けたり, 不正にアカウントを奪われるなどの被害が報告されています. 幸いなことに今の所は EPNetFan に 関係したホストは直接の被害は経験していませんが (気づいていないだけかもしれない ), インターネットにいる限り耐えず外部からの攻撃を受けています. 本ドキュメントは, 自分の管理するUNIX系ホストのシステム状態, 提供サービスの状態などを調べるために必須となる 『log を見る』ためのポイントをまとめたものです. log の見方に関するドキュメントは(私が調べた限りで)以外に少ないようです. したがって以下の記述は私の経験に基づく部分も多く, 誤った記述がある可能性も大ですが, それに関して起きたトラブルに対して一切の保証は致しません. 御容赦ください.

1. ログ(log)ってなぁに??

1.1 ログの定義

(本ドキュメントで)ログというのは以下のような情報をいいます.
ログ:
なんらかのプログラム(オペレーティングシステム, アプリケーション) で実行したイベントあるいは内部状態を出力/記録し, 後で詳しく調べられるように保存しておく手続き, あるいはその診断情報.
プログラムにこのような出力をさせることは特殊なことでなく, 我々がつくるモデル計算プログラムでのチェック用の出力もログの一種です.

1.2 ログに書き出す情報

  1. プログラムが期待した通りの処理を実行しているか.
  2. プログラムが異常な動作をしたかどうか. またその理由はなにか.
  3. 誰が何時プログラムを実行したか.
  4. プログラムの実行UID, PID.

我々が普段つかうのは プログラムのコンパイルがうまく出来たかのチェック(コンパイラの出力を保存)や, 自作のプログラムの動作確認などです.

一方, OS やサーバプログラムは C),D) の様な情報も書き出しすことで 管理者が以下の項目をチェック出来るようにするのが普通です.

  1. プログラムの動作の状態.
  2. ハードウェアの状態.
  3. ユーザの使用状況.
  4. ネットワークからのアクセス状況.
そしてセキュリティ面からみると クラッカーの悪行の証拠を残すという 重要な目的があります. これより, システム保護のためのログに焦点をあて, 監視,監査,保守の仕方を述べていきます.

2. システムセキュリティにおけるログ

多くの UNIX 系 OS には次に示す3つのログサブシシテムがあります.
●接続時間ログ:
login(1)などのプログラムが書き出すログ. 誰が何時システムにログインしたかなどを追跡するために使用される.
●プロセスアカウンティングログ:
プロセスの終了毎に記録されるシステムカーネルが書き出すログ. システムの使用料金を決める際などに コマンド使用統計を作成するために使用される.
●エラーログ:
syslogd(8)を通して書き出されるログ 様々なシステムデーモン, ユーザプログラム, カーネルからの 状態報告を記録するために使用される.
このほか, 独自のログを書き出すプログラムあります. 特にネットワークサーバプログラムは 監査がし易いように個別のログを書き出す場合が多いようです. 以下ではこれらについて, 制御ファイル, ログファイル置場, 監査方法について順に説明していきます.

なお, ファイルの置かれるディレクトリは Debian GNU/Linux 2.2(potato)の 例です. システムによって/var/log/ディレクトリは /var/adm/, /usr/adm などである場合があります.

2.1 接続時間ログ

ログイン/ログアウトの情報は utmp, wtmp などのファイルに出力されます. utmp はログイン中のユーザに関する記録, wtmp はログイン/ログアウトの記録です. wtmp情報はひたすらファイルに書き出されるので, 定期的にファイル名を変更し, あらたなものに置き換える必要があります (3.1 logrotate 参照).

 制御ファイル

なし.

 関連ファイル置場

/var/run/utmp, /var/log/wtmp, /var/log/lastlog, /var/log/faillog

 監査方法

utmp, wtmp 共にバイナリ形式のファイルなので, 以下のツールを使って記録を調べます.
who(1), whoami(1), w(1), users(1), finger(1), last(1), lastb(1), ac(1)
一方, lastlog, faillog などは utmp, wtmp をもとに作られた テキストファイルで lastlog(8), faillog(8) コマンドを使用します. 詳細は man ページを参照してください.

 注意

wtmp(5)より抜粋

wtmp ファ イ ルにはすべてのログインとログアウトが記録され る。そのフォーマットはログアウトした端末ではユーザー名がヌ ルであることを除きまったく同じである。それに加え、ユーザー 名として"shutdown" もしくは "reboot" を持っ て い る 端 末 名"~"はシステムの停止(shutdown)または再起動(reboot) を意味 している。またその端末名 が"|"と"}"の 対 で あ る 場 合 は date(1)コ マンドで変更した新/旧のシステム時間を記録してい る。 wtmp ファイルはlogin(1)、init(1)やいくつかのバー ジョ ンのgetty(1)により維持されている。これらのプログラムはいず れもファイルを新たに作成したりしないので、ファイルを削除す る事で情報の記録(record-keeping)を止める事ができる。

last(1)より抜粋

wtmp及びbtmpファイルが存在しない可能性もある. システムはこ れらのファイルが存在する場合のみ情報を書き留める. 上 記 の ファイルが存在するか否かは各サイトの設定の問題である。これ らのファイルを使いたい場合は、touchコマンドを使って簡単 に 作る事が出来る(例えば、touch /var/log/wtmp) .

2.2 プロセスアカウンティングログ

ユーザが実行した全てのコマンドを追跡する場合出力させます. 非常にファイルサイズが大きくなるため, 普通は使いません.

 制御ファイル

特になし.

 関連ファイル置場

/var/account/pacct

 監査方法

lastcomm(1), sa(8), accton(8) コマンドを使用する. 詳細は man ページを参照してください.

 注意

Debian GNU/Linux 2.2 (potato)で使用するには kernel を再構築し (General setup の "BSD Process Accounting" を有効にする) acct(2) が使えるようにならなくてはなしません. また acct パッケージが必要です.

2.3 エラーログ

エラーログには多くのプログラムからの情報が記録されており, システムの監査に不可欠です. エラーログは汎用ログ採取プログラム syslogd を介して行われ, 記録されるメッセージは少くとも時間の情報とホスト名を持ます. 通常はそれらに加えてプログラム名のフィールドも記録されますが その内容の信頼性はそれぞれのプログラムに依存します. したがって臨機応変にログを見なくてはなりません.

 制御ファイル

/etc/syslog.conf (syslog.conf(5) 参照)
ログをどこに記録するか種類と優先順位によって選択する 決まり事を記述したファイル.

 関連ファイル置場

/var/log/  (制御ファイルに記述された場所)

 監査方法

出力されるログはテキストファイルなので, ページャプログラム, grep, などを駆使して 監査します.

 注意

どのようなプログラムでも syslogd を介してイベントの記録が可能です. シェルコマンドインターフェイスとして logger(1) があり, 誰でも syslog に書き込む事ができます. したがって, エラーログに記録された内容を鵜のみにすることは できません.

2.4 アプリケーションログ

   制御ファイル&関連ファイル置場

アプリケーション名 制御ファイル名 Log 置場を決める変数名 ログのあるディレクトリ(Debian 2.2)
apache httpd.conf CustomLog, ErrorLog /var/log/apache/

 監査方法

アプリケーションによって監査様のツールがあるかもしれません. ネットワークサービスを行う場合, 該当するプロトコルの エラーコードを適度に知っていることが要求されます.


3. ログ管理ツール

3.1 logrotate:   必要パッケージ logrotate パッケージ

多くのログは放っておくといくらでも大きくなる. したがって定期的にログをリセットする必要があるが, 少しまえのログは取っておきたいものです.

logrotate はログファイルを定期的に更新し, ログが溜らないようにするために 使用するツール. 更新時に古いファイルを番号付きのファイル名に変え, 決まり(いろいろ設定でる)にしたがってある程度古いものを消去していきます. これを cron を使って定期的に起動することで自動的にログを管理します.

 制御ファイル

/etc/logrotate.conf, /etclogrotate.d, (logrotate(8) 参照)
logrotate の回転時間間隔や破棄するまでの時間などをこのファイルで 決定します. ファイルサイズの上限で回転させることも可能. Debian パッケージの場合 wtmp 等接続時間ログに関するものは logrotate.conf に書かれており, その他は個々の設定ファイルを作成し /etc/logrotate.d の下に置く設定に成っています.

3.2 Swatch:   プログラム取得先 Swatch 本家

Perl で書かれたログの監査あるいはリアルタイム監視を行うプログラム. 監査すべき文字列は perl 式の正規表現で表せ, マッチした場合 通知するためのアクション(メッセージ表示や他のプログラムにパイプ) を起こす.

 制御ファイル

.swatchrc

 注意

最新の swatch は Perl 5 で書かれており, 以下のモジュールが 必要となります. CPAN


4. ログ監査

ログを監査する際の注意点

  • 見落としするな!!
    せっかくログがあっても見落としてはログの意味はありません. 当然のことですが難しいものです.
  • 本当に不正なものであるのかの判断は慎重・冷静に.
    誤判断をせぬよう出来るだけ多くの情報を収集しましょう (判断材料をそろえるのには時間がかかるが怠ってはいけません).
  • ログは万能ではないゾ.
    ログファイル自体がシステム上で記録されるため クラッカーの変更, 消去の対象となります. このことは何時も頭の片隅にいれておきましょう. 回避方法としてログファイルを他のホストに保管する, あるいはプリントアウトするといった手段があります.

4.0 どんなときに監査するの??

4.1 接続時間ログ監査

コマンドは実際に実行してみればわかるでしょう (時間を見付けて更新する予定).

チェックすべき点はあるユーザに対して,

といったところです.

lastlogファイル, などテキストログを参照しているコマンドと wtmp を直に参照しているコマンドが出す内容を比較してみるのも重要です.

4.2 プロセスアカウンティングログ監査

略(kernel 再構築が必要. 時間を見付けて更新する予定).

4.3, 4.4 エラーログ & サーバプログラムログ監査

チェックすべきポイント(もちろん時と場合により臨機応変に!!).
EPNetFan 的自力更生への路
○プログラムに異変があったら先ずエラー出力やログを調べましょう!! .
×プログラムに異変があったらすぐ誰かに聞く, 騒ぐ, 慌てふためく .

httpd ステータスコードと Netscape でのエラー表示
コード 説明 Netscape エラー表示
200 すべて正常. 転送は正常に実行され, エラーは起こらなかった.  
201 POST コマンドが実行され, イベントなしで正常に完了した.  
202 POST コマンドが実行され, イベントなしで正常に完了した.  
301 クライアントの要求したデータが 一時的に変更された別のURLにあることがわかった Moved Permanently The document has moved here.
(本来は"here"から変更されたURLへリンクされる)
400 クライアントからの要求が不正だったため, 処理は行われなかった. Bad Request
Your browser sent a request that this server could not understand.
401 アクセスする権限のないデータに対してクライアントが アクセスを要求した.  
402 支払方式の調整が行われている.  
403 アクセスが全面的に禁止されている.(パーミッションが出ていない) Forbidden
You don't have permission to access /~hoge/access.log on this server.
404 要求した文書が存在しない. Not Found
The requested URL /~hoge/index.html was not found on this server.
405 要求したメソッドは許されていない. Method Not Allowed
The requested method POST is not allowed for the URL /index.html.
500 修復できない内部サーバーエラーが発生した (クライアントが呼び出したCGIスクリプトにバグがある場合に起こるエラー). Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@hoge.ep.sci.hokudai.ac.jp and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
501 サーバーで実行できない(あるいはサポートされていない) 操作をクライアントが要求した.  
502 サーバに過大な負荷がかかっている.  

参考文献