図5　ログの出力形式

システム・ログの見方

　では，ログを見ていこう。前述の通り，syslogはログを/var/log/messagesに追記していく。ログは図5[拡大表示]のような書式で出力される。

　ログを全部見ていくと，システム起動時のサービス開始のメッセージなどの情報が蓄積されているのがわかる。リアルタイムに出力されるコマンドを見るには，tailコマンドを使えばよい。tailコマンドはファイルの末尾を表示するプログラムで，-fオプションを指定すればファイルの末尾まで読み出しても終了しないで読み続ける。よって，発生するイベントをリアルタイムに表示させることができる。具体的には，

# tail -f /var/log/messages

とコマンド実行すればよい。

表5　syslogの出力結果例
　tailコマンドを打った後に，さまざまなコマンドを入力して，syslogの出力を採取したのが表5[拡大表示]である。順次解説する。

(1)sshでのパスワード入力間違い

　サーバsectest上から，自分自身にssh接続し，わざとパスワードを間違えたのがこの結果である。/var/log/messagesファイルに，アプリケーションがsshであること，イベントとして認証の失敗である「authentication failure」を示すメッセージが出力される。また，その時に接続したリモート・ホストは「sectest」，ユーザ名は「hamamoto」だとわかる。sshの認証失敗のメッセージがこのパターンだと理解していれば，このメッセージが多発している場合，不正アクセスの兆候があると疑うことができる。

(2)sshによる接続成功

　sshによる認証にhamamotoユーザが成功したことが，「session opened for user hamamoto by（uid=0）」というメッセージからわかる。

(3)一般ユーザ権限でのsyslogd再起動

　このコマンドでは，一般ユーザ権限でsyslogdの再起動を試みている。一般ユーザはsyslogd再起動の権限を持っていない。このため，「syslog：syslogd停止 failed」という失敗のメッセージが出ている。

(4)suのパスワード入力間違い

　suコマンドでパスワードを入力する場合，パスワードを間違うと，ここでも「authentication failure」というメッセージが記録される。この行為を行ったユーザIDが「hamamoto」で，スイッチしようとしたユーザ（権限）がrootだとわかる。

(5)suの成功

　ユーザhamamotoがrootになったと記録される。

(6)root権限でのsyslogd再起動

　メッセージから，正常にsyslogdが再起動しているのがわかる。

　syslogが出力する内容を理解するには，このようにさまざまなイベントをわざと起こし，その反応を見るのがよい。最初，これらのメッセージが何を意味しているか，さっぱりわからないことが多い。ただ，慣れてくるとログに一定の法則性があることがわかってくる。また，これらのログのどこを調べればよいかがわかってくる。このためには，より多くのイベントを起こして，いろいろな種類のログに親しむことが重要だ。試行錯誤してみるとよいだろう。

swatchによるログの自動監視

　ログを見ることが重要だと説いたが，ログを見るのに慣れてくると，ログを自動で処理できるツールを導入して，ログ管理の労力を減らしたくなるものだ。ログ監視を人力に頼るには限界がある。そんな労力を低減してくれるのにぴったりのフリー・ツールが「The Simple WATCHer（通称swatch）」である。swatchはhttp://www.engr.ucsb.edu/~eta/swatch/から入手できる。

　最新版は3.0.4である。監視対象としているログに特定の文字列が現れた時に，さまざまな動作をさせることが可能だ。swatchは，ますます巨大になる傾向にあるログの中から，重要なキーワードを漏れのないように拾ってくれる。キーワードを発見した時の動作も，メールを送信したり，音を鳴らすなど多彩だ。障害検知や侵入検知システムとしても使える便利なツールである。

図6　swatchをインストールする手順
図7　適切なPerlモジュールをインストールしていないと表示される警告
図8　Perlモジュールを入手可能なサイト
図9　Perlモジュールをインストールする手順
　swatchはPerlプログラムだ。このため，稼働するには(1)Time::HiRes，(2)Date::Calc，(3)Date::Format，(4)File::TailのPerlモジュールが必要である。これらのモジュールがすでにインストールされている場合は，図6[拡大表示]に示すコマンドを順に打てばインストールが完了する。Perlモジュールがきちんとインストールされていない場合は，図7[拡大表示]のような警告（Warning）が出る。

　インストールされていないPerlモジュールは，CPAN（http://www.cpan.org/）から入手が可能だ。このサイトの検索ページSearch.CPAN.ORG（http://search.cpan.org/）から探すのが楽だろう。例えば，Time::HiResならキーワード「Time HiRes」で探せば，図8[拡大表示]のようにすぐに見つかる。

　これらのモジュールのインストールは，すべて同じ手順である。例として，Time-HiRes-1.36.tar.gzをインストールする場合を図9[拡大表示]に示しておく。これを参考に必要なモジュールをインストールしてほしい。

　ここまでがswatchを起動する直前までだ。次に，監視する情報のレベルを確認しよう。例えば，/var/log/messagesを監視するとしよう。図1のようにRed Hat Linux 7.3では，/var/log/messagesをデフォルトで「＊.info」のレベルで保存するようになっている。このデフォルト設定の情報量で十分な監視が可能である。そのまま監視に入ろう。

設定ファイルの作成

　swatchを起動するには，swatchの動作ルールを記述した設定ファイルを作る必要がある。これはswatch-3.0.4/examples/swatchrc.＊を参考に作ればよいだろう。今回は，サンプルとしてswatchrc.personalを/etc/swatchrcにコピーしてそのまま利用する。なお，/etcの下に置かないでswatchをrootで起動するなら，/root/.swatchrcというファイル名にすればよい。swatch起動時に設定ファイル名を指定しなくても自動で読み出される。好きな方式で設定ファイルの保存位置を決めればよい。

図10　swatchの設定ファイルの書式
表6　swatchで指定できる動作一覧
図11　swatchを起動するコマンド
図12　swatchをで認証失敗ログを検知し，その旨をrootにメール，writeコマンドでrootとhamamotユーザにメッセージを送る例
図13　swatchを図12の設定で動かした場合にrootに届くメール
　swatchの設定ファイルの書式ルールは非常に簡単だ。図10[拡大表示]の2パターンだけである。「ignore」を指定した場合は何の動作もせず，「watchfor」を指定した場合は特定パターンが現れた際に，指定の動作を行う。動作は複数を指定できる。

　では，なぜignoreのように何も動作しない指定があるのか。これは危険だと思われる特定文字列パターンでも，別の文字列と組み合わされた場合，問題ないと考えてもよいケースがあるからだ。この場合，watchforとignoreを組み合わせてルールを記述する。なお，指定できる動作は表6[拡大表示]にまとめた。

swatchの適切な運用法

　swatchの起動は，図11[拡大表示]のコマンド形式で行う。これでswatchが起動する。このまま運用に入ってもよいし，システム起動時に自動的に立ち上がるように/etc/rc.d/rc.localファイルに記述してもよい。基本的に，swatchは一つのプロセスで一つのログ・ファイルしか監視できない。複数のログ・ファイルを監視したい場合は，それぞれのファイルを指定して複数のプロセスを起動するようにしよう。

　swatchを応用的に使うと，簡易的なIDS（不正侵入検知システム）のような運用も十分に可能だ。例えば，図12[拡大表示]は認証失敗時に出力される「authentication failure」をパターンとして指定し，検知した際はその旨を標準出力に表示し，かつrootにメール，writeコマンドでrootとhamamotユーザにメッセージを送る例である。この場合，suのパスワード入力に失敗すると，syslogdの出力内容が図13[拡大表示]のような形式でメールに届く。

　このように，swatchを使えばログに異常が発見された場合，あらかじめ取り決めた手順で通知したり，アラートを出すことができる。単純な動作だが，ディスクが一杯になった場合に通知させるなどの障害対策にも使える。応用範囲は広い。

　ただ，注意が必要な点もある。swatchはバージョン3以降，syslogにログが出力されてから，swatchが動作するまでに数十秒から1分近いタイム・ラグが発生する。本当の意味でのIDSとして使うには，このタイム・ラグはいかんともしがたい。

　タイム・ラグをなくしたいなら，swatchのバージョン2を使うのも一つの手だ。機能的にあまり違わず，リアル・タイムに近いアクションを設定できる。そこまでのシビアな運用を望まないならバージョン3以降で問題ない。

濱本　常義
筆者は中国情報システムサービスに勤務。ソリューション事業本部システム営業部で，セキュリティ対策関連事業に従事している。現在は，主にセキュリティ・ポリシ策定事業に携わっている。セキュリティ関連のメーリング・リスト「connect24h」を運営している。本稿に関する質問や要望はhamamoto@hicat.ne.jpまで。