現在地 HOME > 掲示板
> ＩＴ１ > 420.html
★阿修羅♪
|
現在地 HOME > 掲示板
> ＩＴ１ > 420.html
★阿修羅♪
|
|
ログ解析をマスターする方法、不正侵入を調査する、ログを“再生”できるツール、複数のツールのログから“総合的に”解析、その他。
ログ解析をマスターする方法〜意図的にイベントを発生させて，ログ出力
を確認する〜
http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20020823/1/
今週のSecurity Check [一般編] （第80回，2002年8月26日）
システムのセキュリティ・レベルを維持するためには，サーバーやファ
イアウオールなどのログ収集とその解析が不可欠である。しかし，ログ解
析にはある程度の経験を必要とする。経験を積むためには，意図的にイベ
ントを発生させて，ログを調べてみるのが一番の近道である。どういった
イベントが発生した場合に，どのようなログが出力されるのかを把握して
いれば，実際にセキュリティ・インシデントが発生した場合にも，あわて
ることなく，適切に解析および対処することができる。
ログ解析には経験が必要
セキュリティ・インシデントの発生を事前に察知したり，発生直後に適
切な対処を施したりするためには，日ごろから各種のログを収集し，解析
する必要がある。このコラムでもその必要性については何度か解説してい
る。しかし，実践するのはそれほど容易ではない。ログの解析にはある程
度の経験が必要だからだ。
ログを解析するためには，あらかじめシステムがログを出力するように
設定しなければならない。この設定一つとっても，ログ解析の経験がない
と適切に行うことは難しい。システムによって異なるが，出力されるログ
にはさまざまな種類がある。管理者としては，解析に必要なログだけを保
存しておきたいが，解析の経験がなければ，どのログを保存しておくべき
かが分からない。
また，システムによってログの出力形式や種類が異なることがある。そ
のため，あるシステムについて適切な設定方法を覚えたとしても，別のシ
ステムではその知識が役に立たなくなる可能性がある。別のシステムでも
適切に設定するためには，ログ解析の経験が不可欠だ。実際に解析した経
験があれば，別のシステムにおいても，どのログを保存すればよいのかな
どが分かるが，解析した経験がなければ，設定方法を機械的に覚えている
だけなので，応用が利かない。
そして最も重要なことは，解析の経験がなければ，適切に解析すること
が難しいということだ。解析ができなければ，セキュリティ・インシデン
トが発生した場合に適切な対応を採ることはできない。
例えば「process failed」という文字列がシステムのログに記録されて
いたとしよう。このログを解析する場合，以下のような判断を行う必要が
ある。
これが何のイベントのログであるのか？
どのプロセスが“fail”したログなのか？
なぜこのログが出力されたのか？
ログに記録されたこのイベントは，注意すべきイベントなのか？
そして，「このイベントは問題がないので無視できる」あるいは「緊急
に対処する必要がある」などを決定しなければならないのだ。
以上のことは，ログ解析の経験を積んだ管理者ならば容易なことだろう。
実際にセキュリティ・インシデントに遭遇し，“苦い”経験をしたことが
ある管理者ならば，どういったログ出力に注意しなければならないのかな
どを，身をもって覚えているはずだ。
しかし，今までログ解析の経験を積んでいない管理者はどうすればよい
だろうか。管理しているシステム用のログ解析マニュアルが用意されてい
れば問題はないが，そのようなマニュアルが必ず用意されているとは限ら
ない。経験を積むには，自分が管理するシステムで，実際にセキュリティ
・インシデントが発生するのを待っていなければならないのだろうか――。
そこで提案したいのが，意図的にイベントを発生させて，経験を積む方法
である。
イベントを発生させた場合に，どのようなログが出力されるのかをあら
かじめ試しておけば，実際にセキュリティ・インシデントが発生した場合
にも，適切に解析および対応することが可能となる。以下，意図的にイベ
ントを発生させる場合の手順やポイントを簡単に説明する。
意図的にイベントを発生させる
意図的にイベントを発生させる際にまず注意しなければいけないのは，
そのイベントが現在提供中のサービスに異常をもたらす可能性があるとい
うことである。そのため，イベントを発生させるシステムの管理者や責任
者に無断で実行してはならない。必ず了解を取ってから実行しなければな
らない。
了解を取ったら，以下のような流れで意図的にイベントを発生させ，ロ
グを確認する。
（1）すべてのログを出力する
まず，すべてのログが出力されるようにシステムを設定する。加えて，
すべてのログを一つのファイルに記録するように設定したい。通常の運用
では望ましくない設定だが，ログを確認する上では，作業をスムーズに行
えるので望ましい。なお，実際の設定方法については，OSやアプリケーシ
ョンによって異なるため，ここでは省略する。
（2）ログを画面に表示し続ける
次に，ログの内容をリアルタイムで見られるように，ログを画面に表示
し続ける設定にする。複数種類のログを同時に画面表示させることが難し
い環境では，（1）で説明したように，一度一つのログ・ファイルにして
から，それを画面表示する手もある。
（3）イベントを起こす
そして実際にイベントを起こす。経験を積むことが目的なので，できる
だけ様々なイベントを起こしたい。例として，以下では「コンソールから
システムへ，一般ユーザー権限でログインする」といったイベントを起こ
した場合を考える。
（4）ログを確認する
多くの場合，イベントを起こした瞬間にログが出力されるので，（2）
を行っていればすぐに画面表示される。出力されたログを確認することで，
どのようなイベントが起きればどのようなログが発生するのかを把握でき
る。
確認すべき内容はイベントによって異なるが，「コンソールからシステ
ムへ，一般ユーザー権限でログインする」場合には，以下の項目を確認す
る必要がある。
「ユーザがログインに成功しました」のような意味のログが記録されてい
るか？
何度か実行した場合，いずれの場合でも同じログが出力されているか？
ログインに成功した場合だけでなく，失敗した場合はどのようなログが出
力されているか？
リモートにログ・サーバーがある場合に，そのサーバーにも画面と同じ内
容のログが出力されているか？
ログ解析ツールを利用して，内容を調べることができるか？
ログイン対象のシステム以外（ファイアウオールや侵入検知システムなど）
からも，同様のログが出力されているか？
（5）イベントとログをドキュメントとして残す
単に“生ログ”を残すだけではなく，イベントとログの関係をドキュメ
ント化しておくことも重要だ。“実験”を実施した本人以外も，イベント
とログの関係を後日参照できるからだ。具体的には，「誰が」「いつ」
「どのようなサービスに」「どのようなイベントを起こし」「どうなった
のか」ということを明記した上で，そのとき出力されたログを残しておく。
チェック・リストを作成する
意図的にイベントを起こす際には，あらかじめ以下のようなチェック・
リストを作成しておくと便利だ。対象とする環境を明記しておくとともに，
どういったイベントを発生させるのかをリストアップしておく。“実験”
をスムーズに進められるし，後でドキュメントを作成する際にも役立つ。
以下では，インターネット向けにサービスを提供しているWeb サーバー用
のチェック・リストを例として示す。
【インターネット向けにサービスを提供しているWeb サーバーのチェック
・リスト】
○使用環境
・OS名とバージョン
・Webサーバーのアプリケーション名とバージョン
・登録されているユーザー情報
・ネットワーク設定に関する情報
○メンテナンス作業で生じるイベント
・一般ユーザーのログイン(成功 or 失敗)
・管理者権限を持つユーザーのログイン(成功 or 失敗)
・管理者権限を必要とするコマンドの実行(成功 or 失敗)
・ファイルの追加/変更/消去(成功 or 失敗)
・OSやサービスを再起動させたときのログ
○提供しているサービスに対するイベント
・提供しているコンテンツへのアクセス(成功 or 失敗)
・提供していないコンテンツへのアクセス(成功 or 失敗)
○通常発生しないと思われるイベント
・ポート・スキャンを対象システムに実行
・ぜい弱性スキャナを対象システムに実行
◇ ◇ ◇ ◇ ◇ ◇
以上はあくまでも一例である。運用しているシステムによってチェック
するべき項目――すなわち，発生させるべきイベント――は異なるので，
それぞれの環境に合わせて作成する必要がある。
また，ログの確認は一度やればよいというわけではない。OSやアプリケ
ーションがバージョン・アップした際には，ログの形式などが変わる場合
もあるので，そういった場合には改めて確認する必要がある。
以上のようなチェックリストとログをドキュメントとして作成しておけ
ば，その過程でログ解析の経験を積めるとともに，日々のログ解析の手間
を軽減できる。
ただし，作業はこれで終わらないことに注意しなければならない。チェ
ックリストにはないログが出力される場合もあるからだ。その場合には，
想定していないイベントが発生した可能性があるので，ただちに調査する
必要がある。
調査の結果，ログの原因となるイベントが判明した場合には，そのイベ
ントもチェックリストに追加し，対応するログと併せてまとめておく。こ
のように，
チェックリストの作成→ログの確認→チェックリストの修正
を繰り返すことで，さらにログ解析の経験を積むことができる。
不正侵入を調査する――ログ解析だけではなく，“からめ手”からの調査も重要
http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20020405/1/
今週のSecurity Check [一般編] （第68回，2002年4月8日）
過去のコラムでは，不正侵入をはじめとするセキュリティ・インシデン
ト*の証拠を保存する手順やツールを紹介した。今回はその続編として，
セキュリティ・インシデントの調査方法について解説したい。ログの解析
などはもちろん重要だが，管理者などからの聞き取り調査も重要だ。いわ
ば“からめ手”ともいえる，人物相手の調査が有効である場合も少なくな
い。
* セキュリティ・インシデントとは，コンピュータ・セキュリティに関係
する人為的事象（incident）のことで，意図的および偶発的に発生する。
具体的には，不正侵入に限らず，弱点探索 （ポート・スキャン）や リソ
ースの不正使用，サービス妨害（DoS：Denial of Service）などが含まれ
る。
調査はインシデント対応の一部
セキュリティ・インシデント対応は，多くの場合以下に示す 1 から 5
までの手順で行われる。今回紹介する「調査（セキュリティ・インシデン
ト調査）」は，インシデント対応の一部に過ぎない。
セキュリティ・インシデントの検出
証拠の保存
調査
対応策の検討
対応策の実施
もちろん，以上を速やかに実施するためには，事前の準備が不可欠だ。
そこで，
セキュリティ・インシデント発生前の準備
も，インシデント対応の一部と考えたい。
インシデントを断定する前に十分な調査を
セキュリティ・インシデント調査は，「どのようなインシデントが発生
した可能性が高いのか」を明らかにすることが目的である。調査を行うこ
とで，次の段階である「対応策の検討」，つまり「採るべき最善の対応策
は何か」を決めることができる。
ここで注意したいのは，十分な調査時間がないうちには，調査者は発生
したインシデントを断定するべきではないということだ。あるインシデン
トが発生した可能性が高いと思っても，それは「可能性」として伝えるべ
きで，事実として報告してはならない。さもないと，その後の調査や対応
策をミスリードすることになりかねない。可能性があるインシデントはす
べてリストアップし，そのすべてについての対応策を考えておく必要があ
る。
もちろん，調査が進むにつれて，実際に発生したと思われるインシデン
トの候補は絞られていくだろう。しかし，調査が十分ではない段階では，
調査者の主観で選択肢を狭めてしまうのは危険である。
まずは通報者からの聞き取りを
次に，実際の調査手順について考えてみたい。ここでは，インシデント
を発見して通報したユーザーと，調査に当たるユーザー（管理者）が別で
ある場合を想定する。前者を「通報者」，後者を調査者として話を進める。
調査者の役目は文字通りインシデントの調査である。調査のためには，
以前のコラムで書いたように，インシデントが発生したと思われるコンピ
ュータのハードディスク内容を保存し，解析する必要がある。しかし，そ
れだけでは不十分である。やるべきことを，順を追って説明していこう。
まずは，インシデントを発見した通報者から様々な情報を聞き出す必要
がある。インシデントの発生状況はもちろんのこと，通報者の氏名や連絡
先も聞いておく必要がある。後々連絡を取る必要が生じるからだ。
少なくとも，以下の項目については聞いておきたい。
通報者氏名
通報時刻
通報者の連絡先（メール・アドレスや電話番号など）
インシデントの疑いがある現象の特徴
インシデントの疑いがある現象の発生時刻
インシデントの疑いがある現象の検出手段
現時点で想定できる被害範囲
インシデントの痕跡を探せ
当然，インシデントが検出されたコンピュータ（システム）の情報収集
も不可欠である。
コンピュータの現在の状態
コンピュータが接続されているネットワークの状況
コンピュータが他のユーザー（システム）に対して施しているアクセス・
コントロール
インストールされている OS やソフトウエアの種類
コンピュータの重要度（ネットワーク運用や業務に寄与している度合い）
ログの有無
コンピュータの管理者および主なユーザーの氏名と連絡先
以上のような周辺情報を押さえた上で，適切な方法とツールで保存した，
対象コンピュータのハードディスク内容などを詳細に調査する。通報され
たインシデントやコンピュータの種類などによって，調べるべき内容は変
わってくるが，以下の項目は不可欠だろう。
不自然なコンピュータ（ホスト）からの接続の有無
（上記接続がある場合）その接続元IPアドレス
不正なプログラムの有無
DoS攻撃の有無
破壊行為の有無
アクセス・コントロール・リストの変更の有無
その他不自然な動作の有無
ネットワーク構成図からも有用な情報が
インシデントが報告されたコンピュータだけではなく，ネットワーク構
成に基づいた調査も必要だ。組織に正確なネットワーク構成図が存在する
場合には，それだけである程度のことを推測できる。
例えば，インシデントが報告されたコンピュータがインターネットに接
続していない場合，内部犯罪の可能性が高いと推測できる。その場合には，
特定の部署にはインシデントについて調査していることを隠す必要がある
かもしれない。
インシデントが報告されたコンピュータが，インターネットに接続して
いるネットワークに存在する場合，そのコンピュータはもちろんのこと，
同じネットワークの別コンピュータも踏み台として悪用されている可能性
がある。
また，インシデントが報告されたコンピュータが最初に攻撃されたとは
限らない。組織内の別のコンピュータがまず攻撃（侵入）されて，その後
に攻撃された可能性もある。最初に影響が及んだコンピュータを特定する
ためにも，ネットワーク構成図は有用である。構成図には，外部への接続
性（インターネット，他の組織への専用線，ダイアルアップ接続など）が
記されているはずだからだ。外部に直接接続しているコンピュータ（シス
テム）が最初に攻撃された可能性は高い。
ネットワーク構成図には，ルーターやファイアウオール，NIDS（ネット
ワーク型侵入検知システム）といったネットワーク機器も記載されている
はずだ。構成図からは，インシデントが報告されたコンピュータと，ネッ
トワーク機器との相対的な位置関係をつかめるだろう。位置関係が分かれ
ば，どの機器のログが助けとなるかが分かる。その機器のログを合わせて
解析することで，より詳細な情報を得られる。
なお，ネットワーク構成図に基づいて調査する際には，物理的な接続だ
けではなく，コンピュータや機器それぞれが施しているアクセス・コント
ロールも考慮しなくてはならない。
例えば，インシデントが報告されたコンピュータが，パートナ企業との
専用線とインターネットの両方に接続されているとしよう。ただし，イン
ターネットとコンピュータの間にはネットワーク機器（ルーターやファイ
アウオールなど）が設置されていて，インターネット側からはアクセスで
きないように設定されているとする。
この場合には，おそらく組織内（ローカル・ネットワーク）あるいはパ
ートナ企業のネットワークのいずれかから攻撃されたと推測できる。たと
え接続されているとしても，インターネット側からの攻撃を考慮する必要
はない（もちろん，アクセス・コントロールが適切に設定されていること
を確認する必要はある）。
管理者などへの聞き取り調査も不可欠
上記のような手順で，コンピュータやネットワークの調査を進めれば，
すぐに状況についての理解をある程度得られるだろう。おのずと必要な対
応策も決まってくる。しかし，対応策を決定する前に，さらなる調査が必
要だ。対象となるコンピュータの管理者およびユーザーからの聞き取り調
査である。
ただし，ここまでの調査で，管理者やユーザーが“容疑者”の可能性が
あると判断した場合には，十分注意しなくてはならない。管理者やユーザ
ーの“証言”をうのみにすると，調査がかく乱される恐れがある。煙に巻
かれることがないように，相手と議論することなく，こちら側から一方的
に質問のみを行うなどの工夫が必要だ。
管理者が容疑者でない場合には，聞き取り調査はとても重要である。イ
ンシデントの通報者とは異なり，そのコンピュータに精通している管理者
ならば，発生している現象が本当にセキュリティ・インシデントなのかど
うかを判断できる“はず”だからだ。特に，通報者がインシデントと判断
した根拠が，ファイアウオールのログやIDS（侵入検知システム）のアラ
ートであった場合には，実際にはインシデントでない場合も多いので，管
理者への聞き取り調査は有効だ。
管理者への質問としては，以下が考えられる。
通常の運用状態と異なる点が見られるかどうか
管理者以外にroot 権限で対象コンピュータにアクセスできるユーザーが
いるかどうか
対象コンピュータではどのようにログを採取しているか
対象コンピュータではどのようなセキュリティ対策を施しているのか
管理者への聞き取り調査が終わったら，管理者を“管理”する人物（管
理者の所属長などが該当するだろう）にも聞き取り調査したい。管理者が
疑わしい場合はもちろん，そうでない場合にも実施したい。この種の人物
は，管理者や調査者が知らない情報を持っている場合がある。
例えば，最近組織を離れた人物や，不平不満をこぼしている人物などを
知っている場合がある。彼らがただちに容疑者になるわけではないが，調
査を進める上では有用な情報だ。ハードディスクの中身の解析も重要だが，
こういった情報を入手することも重要であると覚えておいてほしい。
ログを“再生”できるツール「NetPoke」を活用する
http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20020329/1/
今週のSecurity Check [一般編] （第67回，2002年4月1日）
システムやネットワークの記録（ログ）を残すことの重要性については，
このコラムで何度も強調している。システムやネットワークで不測の事態
が発生した場合，その原因究明のために不可欠だからだ。現在では多くの
ログ解析ツールが存在する。その中には，「NetPoke」というツールのよ
うに，ログに従ってパケットを送出できるものも存在する。NetPokeを使
えばネットワークの状況を再現できるので，IDS（侵入検知システム）な
どで後日改めて詳細な調査をすることができる。
パケット・ログは「tcpdump形式」が標準
今回紹介するNetPokeが“再生”するログは，tcpdump形式のログ（パケ
ット・ログ）である。「tcpdump」 *とは，ネットワーク上を流れるパケ
ットを収集するツールの一つ。tcpdump形式とは，文字通りtcpdumpが出力
するファイルの形式である。
* 同様のツールに「tcpslice」などある。tcpsliceを利用すれば，
tcpdump形式のパケット・ログから特定の時間帯のログのみを抽出できる。
tcpdumpやそのライブラリが広く使われているために，ネットワーク・
トラフィックを記録するファイル形式としては，事実上「tcpdump形式」
が標準形式となっており，商用/フリーを問わずさまざまなツールがサポ
ートしている。tcpdump形式のファイルを読み込んで解析できるネットワ
ーク・アナライザや，異常を検知したパケットをtcpdump形式で出力でき
るIDSは多い。
パケット・ログを“再生”する
NetPokeは，IDSを評価するためのツールとして，DARPA Projectの下，
MIT Lincoln Laboratoryにより開発された。
詳細な情報---例えば，パケットの到着順やTCPパケットのヘッダー情報
など---までを考慮して，ネットワークのトラフィックを再現することは
極めて難しい。しかしNetPokeを使えば，パケット・ログに記録された状
況を，望みの環境で何度でも再現することができる。
単にパケット・ログを再生するだけではない。（1）NetPokeからのパケ
ットであることを判別できるように，送信元MACアドレスをゼロにセット
できる，（2）再生速度を指定できる，（3）あて先ごとにネットワーク・
インタフェースを選択できる---といった，調査に便利な機能を備えてい
る。
では，NetPokeの簡単な実行例を見てみよう。以下は，あらかじめ
tcpdumpで記録したパケット・ログを再生し，オリジナルのパケットのタ
イム・スタンプと再生時のタイムスタンプを表示させた結果である。
# ./netpoke -T dumplog
orig: 14:25:08.984939 loc: 18:33:07.204336
orig: 14:25:09.000172 loc: 18:33:07.218935
orig: 14:25:09.000261 loc: 18:33:07.219422
orig: 14:25:09.000905 loc: 18:33:07.219851
orig: 14:25:09.208225 loc: 18:33:07.427056
orig: 14:25:09.301387 loc: 18:33:07.520152
orig: 14:25:09.301438 loc: 18:33:07.520644
sent 7 packets, missed 0 packets
この例で分かるように，パケットの送出タイミングがオリジナルとは異
なる。残念ながら，NetPokeではパケット送出のタイミングを完全に再生
することはできない。そのため，タイミングに依存する攻撃は再現できな
い可能性がある。
IDSと組み合わせて効果を発揮
NetPokeはIDSと組み合わせることでさらに効果を発揮する。パケット・
ログ解析の手間を大幅に軽減できるのだ。
パケット・ログを手動で解析しようとしたら，「Ethereal」などのツー
ルを用いて，膨大なパケット・ログの中から，目的のパケットを探索する
必要がある。しかし，少しでも疑いがあれば検知するよう，“敏感”に設
定したIDSと組み合わせれば，詳細に調べる必要がないパケットと注目す
べきパケットを振り分けることができる。
IDSを使用する上では，通常すべてのルールを適用することはない。適
用すると，怪しくないパケットにまでアラートを発する可能性が増え，誤
検知の件数が膨大になるからだ。ほとんどの場合，ルールの“刈り込み”
を行い，誤検知を減らす。しかしこのことは，検知対象とならないルール
があることを意味する。
そこで，NetPokeでログを再生し，通常は削っているルールを有効にし
たIDSで再度検知するのである。そうすれば，“グレー”なパケットはす
べて検知できる。検知した結果についてのみ解析対象とすれば，まず問題
がないと思われるパケットの情報をフィルタリングできることになる。
もちろん最終的には，手動で解析する必要があるだろうが，フィルタリ
ングしない場合に比べれば，解析の手間は大幅に軽減できるだろう。
パケット・ログの解析は，上手に活用すれば細部まで出来事を調査でき
るが，極めて下位のレベルで調査するために有効なツールが少なく，また
高度な知識を必要とする。今回紹介したNetPokeはその一助になるだろう。
もちろん，いざという時にパケット・レベルの解析ができるように，普段
からログを収集しておくことが不可欠である。
複数のツールのログから“総合的に”解析して不正なアクセスを見つけ出す
http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20010824/1/
今週のSecurity Check [一般編] （第44回，2001年8月27日）
現在では，インターネットにサービスを公開しているサイトのほとんど
が，ファイアウオールを使用して不正アクセスに備えている。しかし，設
定の不備などによって不正なトラフィックを通過させてしまう可能性は否
定できない。また，通過を許可しているプロトコルを使用した不正アクセ
スもありうる。そこで今回は，ファイアウオールで通過を許可してしまっ
た不正なアクセスを，ファイアウオールや IDS（侵入検知システム）, 各
ホストのログ（syslog やアプリケーションが出力するログ）などから探
る方法について解説したいと思う。ポイントは，1つのログから判断する
のではなく，複数のログから“総合的に”判断することである。
複数のログから判断する
IDS のアラート（警告）あるいはファイアウオールのログなどから，
「不正なアクセスを受けているらしい」と感じた場合には，それら以外の
ログ（例えば，各ホストから出力されるログなど）を参照して，本当に不
正なアクセスなのかどうかを調べることが重要である。誤報あるいは誤解
である場合があるからだ。IDS やファイアウオールを過信せず，十分に調
査すべきである。
例えばホスト型 IDS（HIDS）*1 から，「brute force」*2 がアラート
として検知された場合を考える。まずは，（1）何時何分に，（2）どのサ
ービスに対して，（3）どのIPアドレスから，brute force が行われたの
かを調べなければならない。
*1 Host-based Intrusion Detection System。文字通りホスト（マシン）
ごとにインストールして，OS やアプリケーション，監視プログラムなど
が出力するログ・ファイルを監視する。
*2 総当り攻撃のこと。パスワードなどを破るために，可能性がある文字
列すべてを次から次へと送信する攻撃方法。
そして，ファイアウオールのログをチェックし，IDSと同様のアクセス
が記録されているかどうかを調べる。記録されている場合には，実際にそ
の送信元IPアドレスから brute force が行われた可能性は高い。
しかし，対応する記録が存在しない場合，その可能性は低くなる。この
場合，アラートの原因は，対象ホストにインストールされているアプリケ
ーションの設定不備や不具合など，他の要因が考えられる。その際には，
対象ホスト内のログを調べて原因を突き止める。
このように，IDS がアラートを発しても，それだけで「不正なアクセス
を受けた」と判断せずに，それ以外の情報を参照して，総合的に判断する
のである。では次に，総合的に判断するためのポイントについて解説しよ
う。
ホスト型 IDS を重視する
総合的に判断する際の“トリガー”，すなわち第一報は何に求めればよ
いだろうか。言うまでもなく，IDS のアラートである。IDS には HIDS と
NIDS（ネットワーク型IDS)*3が存在するが，特に HIDS のアラートを重
視する。HIDS に比べて NIDS のアラートは誤報である可能性が高いから
だ。
*3 Network-based Intrusion Detection System。保護すべきネットワー
ク上の通信を監視し，攻撃などの特定の通信で発生する異常なパターンを
発見したら，ユーザーに通知する。異常なパターンの発見には，あらかじ
めそれらを登録した「シグネチャ（ルール・セット）」と呼ばれるデータ
ベースと，通信内容（トラフィック）の比較により行う。
誤報の可能性は，NIDS 製品の種類や，検知されるアラートの内容によ
って異なってくるが，どの製品であろうと誤報が混在してしまうのが現状
である。その理由の一つは，NIDS では攻撃パターンを“シグネチャ化”
して，パターン・マッチングにより侵入検知を行っているからである。つ
まり，ある攻撃に含まれるであろうトラフィックのパターン（文字列）を
あらかじめ登録しておき，同じパターンが現れた場合には，不正なアクセ
スであるとみなす。そのため，正規なトラフィックでも同じパターンが含
まれていれば，アラートを発してしまう。
それに対して，HIDS は syslog やシステム・コール・レベルのログを
直接監視しており，NIDS と比較すると誤報は少ない。そのため，不正な
アクセスを受けたかどうかを判断するには，HIDS のアラートを重視した
ほうがよい。
ただし，誤解しないでほしいのは，HIDS のほうが NIDS よりも優れて
いるというわけではないということである。それぞれ役割が異なるのだ。
NIDS は「攻撃の予兆を監視する」ためであり，HIDS は「侵入の事実を監
視する」ためのツールである。その性質上，NIDS に誤報が多くなるのは
仕方のないことなのである。
時刻を同期させておく
総合的なログ解析を行うためには，各ホスト間で時刻の同期がとれてい
なければならない。それぞれのログを比較参照する際には，時刻が頼りに
なるからだ。実際，IDS を導入しているあるサイトでは，各ホスト間で最
大20分以上も時刻がずれていたことがあったという。これでは，せっかく
コストをかけて IDS を導入していても，総合的なログ解析はできない。
上述の brute force の例で考える。実際に攻撃を受けたとしても，時
刻がずれていると，HIDS では brute force を検知したものの，同時刻の
ファイアウオールのログには該当する記録が存在しないことになる。その
結果，「原因は不明だが，ファイアウオール には該当する記録が見当た
らないので，問題なし」---として処理してしまうことがある。。マシン
間で時刻が合っていないことが原因の“ありがちな”パターンである。こ
のようなことを避けるため，各ホスト間で時刻の同期をとることは最低限
の必要な条件である。なお，ログ解析を行わない場合でも，各ホスト間で
時刻同期は，システム運用上は必須の事項である。
◇ ◇ ◇ ◇ ◇ ◇
以上のように，総合的にログを解析することによって，不正なアクセス
か誤報かの判断が可能になる。加えて，ログを消されたり改ざんされた場
合にも，他システムのログから不正なアクセスの追跡が行える。ファイア
ウオールや IDS を導入した際には，各システムのログを総合的に解析し
て，正しい情報を得るようにしたい。
ログの中から不正なアクセスを見つける
http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20010629/1/
〜最小の労力で最大の効果を得るためにポイントを絞れ〜
今週のSecurity Check [一般編] （第37回，2001年7月2日）
システムを運用管理していく上で，ログは非常に重要な役割を果たして
いる。アプリケーションのメンテナンスや不正なアクセスの調査などには，
ログの解析は不可欠だ。システム管理者ならば，このことは十分ご存知だ
ろう。たとえ管理者でなくても，ログの重要性について，一度は耳にした
ことがあるだろう。
とはいえ，ログ解析は容易な作業ではない。特に，管理するシステムの
規模が大きければ大きいほど，ログの量もぼう大なものとなり，管理者の
負担は大きくなる。出力されたログをすべて解析するとなれば，相当な時
間と労力が必要になる。日常業務に追われる中で，ログ解析に何時間も費
やすことはできない。
そのため，ログ解析では“ポイントを絞る”ことが重要である。実際に
は，すべてのログに目を通す必要はない。出力されたログの中から注目す
べき情報だけを抽出して，最終的に残った情報だけを解析すればよい。こ
うすれば，最小の時間と労力で最大の効果を得られる。
問題は，“注目すべき情報”がどんなものなのか，ということだ。ぼう
大なログをどのように絞り込んでいけばよいのか。今回のコラムでは，フ
ァイアウオールのログに焦点を当てて解説したい。
ログ収集の3つのポイント
ファイアウオールは，設置しただけでは有効に活用しているとは言えな
い。正しく設定することはもちろんのこと，ログを定期的に解析してこそ，
その真価を発揮できる。これは， IDS（侵入検知システム）も同様である。
解析するためには，当然ログを収集する必要がある。そこでまず，ログ
を収集する際のポイントを解説しよう。
第1のポイントは，システムの物理的な構成が許す限り，できるだけ多
くのログを収集することである。不正なアクセスを検知した場合，そのア
クセスがどのようなものなのかを知るためには，できるだけ詳細な情報が
必要だからだ。調査を始めてから詳細なログを欲しがっても手遅れである。
第2のポイントとして，出きる限りログ収集用ホストを設置すべきであ
る。ログ収集用のホストを設置することで，管理しているシステムで出力
される複数のログを1台のホストにまとめることができ，管理の負担を軽
減できる。また，システムに侵入されてしまった場合でも，ログの改ざん
を防止できる。
そして第3のポイントは，定期的に収集したログを何かのバックアップ
・メディアに残しておくことである。メディアとして，個人的には CD-R
がよいと思う。（1）一度書き込んでしまえば改ざんが不可能なことや，
（2）作業が容易であること，（3）メディアが安価であること---などが
理由である。
ファイアウオールの設定ミスを突き止める
では，収集したログを解析する際には，どのような情報に注目すればよ
いだろうか。まず注目すべきは，ファイアウオールに許可されたアクセス
の記録である。許可されてインターネット側から内部セグメントに入って
きたアクセスに，筆者は特に注目する。通過を許可されたアクセスのログ
は，その量がぼう大なこともあって解析しないことが多いようだが，その
中には管理者が意図せず許可してしまったアクセスが含まれている可能性
がある。
しかし，許可されたアクセスのログの量はぼう大だ。そのため，正規の
サービスに対するアクセス，およびファイアウオールのログからは不正か
どうかを判断できないアクセスの情報をフィルタリングする必要がある。
具体的には，まず「あて先ポート番号がDMZの各ホストで提供されてい
るサービスであるアクセス」を取り除く。各システムの構成によって異な
るが，DMZにWebサーバーやメール・サーバーを設置している場合には，
HTTP や SMTPが対応することになる。あて先のサービスが HTTP や SMTP
の場合でも，パケット中に悪意のあるコードが含まれている可能性は否定
できない。しかし，ファイアウオールのログだけではそれを検知できない
ので，ここでは取り除く。
また，「ICMP によるアクセス」も取り除く。これは，ルーターなどの
機器間でネットワークの状態を通知している場合などがほとんどだからで
ある。
これらをログから除くことで，ぼう大なオリジナルのログがかなり少な
くなっているはずである。
もし，ログに何も残っていない場合は，問題が見当たらないことになる。
しかし，ログに情報が残っている場合には，そのログを詳細にチェックす
る必要がある。ファイアウオールの設定ミスなどにより，本来は拒否すべ
きアクセスを無意識に許してしまっている可能性があるからだ。
こういった場合には，すぐにサイトの公開を一時的に停止するなどして
対応する必要がある。そして，ファイアウオールのアクセス・コントロー
ル・リスト（ACL）を確認し直さなければならない。
実際，ある企業のファイアウオールを調べてみたら，その企業とはまっ
たく関係のないISPに割り当てられているIPアドレスからのFTPアクセスを，
なぜか許可する設定になっていたことがあった。そのような状態を放置し
ておくと深刻な事態を招く可能性がある。
攻撃元と不正なアクセスの傾向を知る
次に，ファイアウオールの通過を許可されなかったアクセスの解析であ
る。これも重要な作業である。不正なアクセスやその試みの多くがこの中
に見られるからだ。
この場合も，許可されたアクセスのログ解析同様，いきなりオリジナル
のログにあたるのではなく，不要な情報をまずフィルタリングする。具体
的には，「送信元のサービスが HTTP や SMTP であるアクセス（すなわち，
Webサーバーやメール・サーバーからのアクセス）」や，「あて先のサー
ビスが ident や auth であるアクセス」を取り除く。また，「ICMP によ
るアクセス」も除く。
そうして残った情報の中に，不正なアクセスと思われるものが含まれて
いる。DMZ の各ホストへ FTP や DNS，SunRPC で接続を試みるものが見ら
れ，中には Telnet で接続しようとしているものすら見かけることがある。
このような情報は，攻撃元へ連絡する際の証拠となるばかりではなく，
現在どういった不正なアクセスの予兆があるのか，その傾向を知る手がか
りとなる。
実際，不正なアクセスには流行がある。例えば，FTPサーバー「wu-ftp」
のぜい弱性が公表された後には FTP のアクセスが増え，DNSサーバー
「BIND」のぜい弱性が公表された後には DNS へのアクセスが増えた。こ
うしてみると，ある特定のサービスへのアクセスが増えたときは，そのサ
ービスを提供しているアプリケーションのぜい弱性が発見されている可能
性が高いようだ。
◇ ◇ ◇ ◇ ◇ ◇
このように，毎日大量に出力されるファイアウオールのログも，ポイン
トを絞って解析すれば，より効率的に結果を得ることができる。不正なア
クセスやその予兆を検知するために，ログ解析は重要な作業であることを，
特に管理者には認識していただきたい。
◎参考資料
◆「ログの活用方法に関する調査」（情報処理振興事業協会）
◆「FAQ : Firewall Forensics (What am I seeing?)」
（RobertGraham.com）
題名には必ず「阿修羅さんへ」と記述してください。