------------------------------- Title : ログ情報調査を支援する視覚化システム「見えログ」 Time : 14:10〜14:45 Presenter : 高田 哲司 (電気通信大学) Logger : 国武 功一 (株式会社ドリーム・トレイン・インターネット) ------------------------------- ログをチェックすることは管理者にとって大切なことである。稼働状況、 異常検出、不正侵入された、また不正侵入を試みられたといったことを知る ための唯一の情報源として、ログは非常に重要である。この重要性を示す事 例として、近年、不正アクセスの禁止に対する法案で、ログ情報の保存につ いて議論されたことが挙げられる。 しかし、ログ情報の調査作業が重要なのにもかかわらず為されないことが 多い。実際に私が管理している計算機があるが、１日たかだか１００〜３００ 行程度のログを調べることでさえ面倒だと感じている。なぜだろうかと考え ると、２つの大きな理由が考えられる。 〜ログ調査の問題点〜 １．ログ情報の特性 ログは文字情報として記録されるため、そのログを実際に読み、それがお かしいか、そうでないかを判断しなくてはならない。にもかかわらず、ログ 情報は往々にして膨大な量となり、人間の手作業では処理しきれなくなって しまう。更には注目すべき情報の不明さ。ログ情報というのはすべてが疑わ しく調査すべき内容というわけではない。問題がないことを知らせるために 記録されている情報もある。また、ログのフォーマットには様々な形式があ り、いろいろなディレクトリに偏在している。このため、ログ調査を行う人 は、ログのあるディレクトリを予め把握していなくてはならない。 ２．作業形態の問題 これは私が知っている範囲の情報だが、ログ調査というのはまず、手作業 であるということ。人間は異常判断や、パターンから判断するのは得意だが、 長時間の単純作業に正確性を求めるのは無理である。また、私はログ調査の 自動化は難しいのではないかと思ってる。なぜなら、知識を持った管理者の 多くは、キーワードによる抽出を行うようなスクリプトを書き、それをログ ファイルに適用し、ある程度疑わしいログを抽出して調査しているから問題 ないと言うが、実際に異常だといわれるログメッセージを全て知っている人 などはいないと思うからだ。 〜ログ調査の現状〜 現状では、皆さんはどうやって調査しているのだろうか？私の推測だが、 1)やっていない 不正アクセス禁止法案の時に、無作為に抽出したプロバイダに対してア ンケートが行われた。その結果によると、定期的にログファイルを調査し ている所は、全体の４４％。やっているところは半分にも満たない。 2)地道に手作業 ISP でアルバイトをしている知人の話だと、作業の半分がログ調査に費 されているとのこと。 3)既成／独自のスクリプトで処理 コーディング能力のある熟練管理者が、既成なり独自のスクリプトによ って処理。 4)既成のシステムを利用 swatch , syslog-ng , xlogmasterなどを使用。 〜見えログ：その特徴〜 これらの状況を踏まえて、どうすれば作業が楽になるかを考え、私達は「 見えログ」、図的にログ情報が見れるツールを作ってみようと考えた。その 特徴だが、３つの仕組みを導入した。 １．情報視覚化 この「情報視覚化」によって、ログの特徴情報を見て取れるようにする。 これにより、情報把握の容易化を可能にし、文字で見るよりも多くの情報を １つの図として提示し、図に対してさまざまなアクションを施すことによっ て、対話的な作業を可能とした。これらにより、ログ情報の認識負荷を軽減 する。 ２．疑わしいログの抽出 一つには「既知のキーワードによる抽出」で、既知の疑わしいキーワードを 利用して調査すべき情報を抽出する。これは当然として行なわれている方法。 ２つ目は「統計処理による方法」先程も述べたように正規表現だけではよ くないと考えたとき、正常な状態を表すログファイルの中に、極少量、異常 を表すログファイルが存在しているだろうという仮定を用いてログ情報に対 し統計処理を行ってやる。この統計情報から得られる頻度情報を用いて疑わ しいログ情報を自動的に叩き出してやろうという方法。 ＜頻度情報を得る具体的な方法について＞ connect from tokyo connect from ueno connect from tokyo connect from tokyo connect from ueno connect refused ito 上記のようなログ情報があった場合、単語別による頻度情報と、２単語連結 に対しての頻度情報を取り出す。このログをこの２つの方法をつかって処理 してやると下のようなデータを得る(左の数字は出現回数) 単語別頻度 二連結単語別頻度 6 connect 5 connect from 5 from 3 from tokyo 3 tokyo 2 from ueno 1 ito 1 connect refused 1 refused 1 refused ito 単語別頻度によれば、'ito' と 'refused' が疑わしい情報として挙げられ る。二連結単語別頻度では 'connect refused' , 'refused ito' が疑わしい 情報として抽出される。 ３．ログの統合 先程も述べたように、ログの形式はさまざま。また、色々なディレクトリ に散らばっているので、これらの情報をある１つの汎用ログフォーマットを 使って統合し、一つのファイルにして調査する。この際に、汎用ログフォー マットというものを考えた。とはいうものの私が考えたものではなく、これ はほぼ syslog のフォーマットと同じである。３つの情報をコンポーネント としていて、左から時刻、タグ情報。元のログファイルではこの間にホスト 名が入るが、それはここでは無視している。タグ情報とはログを書いた主体 (Daemon名など)、記録されたログ情報をメッセージとして定義している。 ＜汎用ログフォーマットへの変換例＞ Nov 2 00:35:36 milan.ac.jp Xsession:root login ↓ +-----------------------------------+ |時刻 |タグ情報 ｜メッセージ | +-----------------------------------+ | 941470546 | Xsession | root login | +-----------------------------------+ このようにログ情報を統合すると２つうれしいことがある。１つは、いろん なフォーマットの、いろんな場所にあるログを１つにまとめることで、調査 負担が減るということ。２つめは、時間情報をもとにして統合するため、複 数のログに含まれている情報を、時間的な関係で簡単に見ることができるで あろうということ。 〜「見えログ」の画面構成〜 画面は横に４つに分けられている。 １.タグ格子領域＜カラーになっている格子上の領域＞ 先程説明した、汎用ログフォーマットのタグ情報の頻度情報についてだけ 表示している。タグ情報を基に頻度情報を抽出してやり、その頻度に応じて 色付をしている。上にいけばいくほど出現頻度が高く、下に行けばいくほど 出現頻度は低くなる(青 --> 黄 --> 赤)それぞれの格子が、どんなタグ名の ものを表しているのかといった具体的なタグ名については、あとから説明す る文字表示領域にて表示することにしている。 ２.時間別頻度領域 ＜白黒の格子領域２本と、横方向の棒グラフからなる＞ これには３つの表示領域がある。左側に格子状の細い帯が２つあるが、左 からそれぞれ、週格子(７分割されている)、日格子(２４分割されている)と なっており、それぞれの時間ごとにログの数をカウントし、その統計情報を 白とグレーで表している。また右側の棒グラフは、現在は基本時間を半日( １２時間)として、１２時間毎にログをカウントし、ヒストグラムとして表 示したものを表している。 ３.アウトライン領域＜横方向の棒グラフ＞ 文字情報を実際に遠目から見たときの、ログ情報の個々の長さを線で表し ている。色づけは、先に述べたタグ表示領域のものと同じようになっている。 ここで気を付けて欲しいのだが、ログを調査しているユーザは、ある一つの ログに注目していると仮定して、注目ログというのを定義している。絵の左 側に「注目ログ」という矢印があるが、いまユーザが注目しているログは緑 のラインの所だということを表していて、その緑の周りの白い枠は、同一時 間帯に表示されたログがそれだけの幅だけあるということを表している。ま た、下の方にグレーで反転されている領域があるが、このグレーで反転され た領域部分のログが、次で説明する文字表示領域に表示されている。 ４.文字表示領域＜ログ情報を文字として表示＞ 先程説明した汎用ログフォーマットのメッセージ部分を単に文字として表 示した部分。この領域の一番下に、注目しているログの詳細情報を表示して いる。この例では、in.ftpd について注目していることがわかる。また赤の ハイライトで表示された部分があるが、これは既知のキーワードで疑わしい とされたログ。青のハイライトで表示されたものは、統計情報によって疑わ しいとされたログである。 〜ビデオによる「見えログ」のデモ〜 左のタグ格子領域を見ると、青の格子は１つだけで、下に赤い格子が沢山 あるのが見てとれる。つまり、１つだけ出現頻度の高いログ情報があり、他 のログ情報は出現頻度が低いということがわかる。 次に時間表示領域に注目すると、ある時間帯に非常に多くのログ情報が吐 かれており、他の時間帯はあまりログが吐き出されていないということがヒ ストグラムより見てとれる。 ログ情報の１行あたりの長さによってフィルタリングすることも可能とな っており、フォントも簡単に変えられるようになっている。また、瀕出頻度 の低いものだけを調査することも可能。出現頻度での切り分けの閾値をマウ スで変更することもできる。 wtmp の解析例(汎用ログフォーマットへ変換することのメリット) これをやるとなにが嬉しいか？telnetd において疑わしい情報を調べると、 それとは別に wtmp を調べなくてはいけなかったが、ログを統合したことに よって、同時に調べてやることが出来る(時間系列で統合されているため) 〜これからの課題〜 これまで述べたように、統計情報から出現頻度の低いログは、疑わしいも のと仮定して、話を進めて来たが、実際に抽出されたログが本当に調査すべ き情報なのかという評価は、まだなされていない。 実際に私が使ってみた感想としてはどっちつかず？といった感触。確かに 出現頻度の低いものが叩き出されるが、その弊害として、ログにプロセスID が含まれているものなどが抽出されてしまう。また、決まったキーワードの あとに滅多に付かないキーワード、例えばユーザIDが付いたりといった場合 にも抽出されてしまう。これら数字関係のものは、疑わしいログとして抽出 されてしまうので、これらをどうやって排除していくかを考えなくてはいけ ない。２つめは作業における自由度の高さ。自由度の高さというと語弊があ るかもしれないが、いろんな処理をつかって疑わしいログを抽出することは できるが、実際にどうやって調査するのか？といった定型処理が全くない。 自分でどうにかして下さい、といった状況。また自動化できることがあれば 自動化しておく必要もある。 〜最後に〜 果してこれは使えるのでしょうか？といった疑問がある。まだこのツールを 使っている人は少ないので、是非プロの意見をお聞きしたい。後程 source code を公開したいと考えているので評価に加わって頂けると嬉しい。 -------------------------------------- 質疑応答 -------------------------------------- 質問者：汎用ログフォーマットからホスト名を弾くということは、単一ホス トを念頭においている？ 発表者：そうです 質問者：port scan には 複数ホスト対応だと嬉しい。また port scan のよ うに、疑わしいログばっかりの時には頻度情報は役に立たないので、 そのあたりも考慮してもらえると嬉しい。 質問者：疑わしいキーワード以外にも、疑わしいサイト、IPアドレスなども 登録できますか？ 発表者：単なるキーワード抽出なので可能です。 質問者：疑わしいものがあれば、こちらからその疑わしいサイトへアタック... というと語弊があるが、調査してくれる機能があれば、個人的には 嬉しい。 発表者：不正検知システムがありますので、私はそちらには注視していませ んが、要望があれば検討します。 質問者：ttyで使えませんか？ 発表者：Xでないといまは使えないです 質問者：中間データ(汎用ログフォーマット)へ変換するスクリプトは公開さ れないのですか？ 発表者：残念ながら、それを用意しておらず公開できるものがない。皆さん で是非作って欲しい。 質問者：ログをちゃんと調査している立場からすれば、推論できる機能があ れば嬉しい。(こういうログが吐かれれば、次にはこんなログが吐か れるだろう....というもの) 発表者：時系列によるパターンマッチングというのはすでに指摘されていて、 現在考案中。期待していて欲しい。 質問者：ログのフォーマットを統一しようという話がIETFでもなされていて、 Draftも出ているので、それも参照するといいかもしれません。 発表者：ありがとうございます。 質問者：syslog などにはファシリティの設定でなどがあるが、その情報も汲 み取ってやるという機能は組み込まれていない？ 発表者：いまは組み込まれていません。そもそもの動機が、沢山あるログファ イルを一つ一つ調べるのがめんどくさいというのがあって、とりあえ ずログファイルを１つにまとめて楽にしようというもの。今後の案件 として考えてみようと思います。 質問者：個人的には結構役にたっている思うので、よろしくお願いします。 司会 ：JANOG MLで議論していただき、改良していければいいですね。 以上。