監視と検知が可能にする迅速なインシデント対応：ネットワーク運用におけるセキュリティ（3/4 ページ）

[佐藤功陛，ITmedia]

●ファイアウォールの通信ログ

　ファイアウォールのログに関しては、「何を取得対象とするか」「どのように事後分析の準備を行うか」の2点を重要なポイントとして挙げることができる。ファイアウォールログは膨大な量になることが多く、事後解析が困難になる場合が少なくない。最悪のケースでは、ログが大量に発生した結果、システム運用が止まってしまう場合もある。

　ファイアウォールの通信ログでは、まず「何をログ取得の対象とするか」が重要となる。また、ログを記録するデバイス間でのカバレージを考慮することも重要だ。たとえば、サーバ上により詳細なログが残ることが期待できる環境ならば、必ずしもファイアウォールのログを収集する必要はない場合も想定される。ログそのものが通信帯域やサーバ性能を圧迫し、結果としてシステム停止に追い込んでしまう場合を避けるためには、そうした設定も考慮すべきだ。

　簡単な事例を紹介しよう。

　リモートサイトのDMZで公開されているWebサーバがDoS攻撃を受けたことがある。この際、ファイアウォールからsyslogホストへ大量のログが送りこまれた。リモートサイトを結ぶ回線の帯域は1Mbps程度だったため、そのほとんどがログで消費されてしまい、他の通信が使えなくなり、結果としてサイト自体が利用できない状況となった。この教訓を生かしてこのサーバでは現在、帯域制御の設定でファイアウォールログの送付の優先順位を下げ、運用を行っている。

　また同時に、たとえば外部からの攻撃や作業ミスなどにより、本来のWebサーバ以外のサーバにWebサービスが立ち上がり、それに対して通信が行われるような場合、これを確実に検出し、記録できるよう設計する必要がある。

ログのバックアップ

　通信ログのリアルタイムでの閲覧ならば、各ファイアウォールや機器が備えるWebユーザーインタフェースや専用ユーティリティによって可能だ。しかし過去にさかのぼっての閲覧となると、意外に手間がかかる場合が多い。

　たとえば、あなたが管理しているネットワークやサーバで不正アクセスが発見され、上司からいつから不正アクセスされていたか、過去90日以内のログを確認するよう指示を受けたとする。いったいどれくらいの時間で確認できるだろうか？

　通信ログが独自形式の場合は、過去の通信ログをリストアするだけでは閲覧が行えず、専用のユーティリティや環境を必要とする場合が多い。さらに、ディスク／メモリなどのリソースに影響を与える可能性があるため、本番環境では展開できない場合もある。このため、可能であればリストア／閲覧専用の環境を用意した上で、過去半年分程度の通信ログをCSVなどのテキストファイルにエクスポートする。事前にリハーサルを行って、作業手順とログの量に応じたおおよその作業終了時間を確認しておくことも重要である。

　また、ログをCD-R/DVD-Rのように変更／改ざんすることができないメディアに記録し、安全な場所に保管しておくことも重要だ。

　syslog形式のログやCSV化したログであっても、ファイルサイズが大きくなることから、Microsoft Excelや通常のデータベースでは処理できない場合が多い。このため、grepやsed、awkといったテキスト処理系ツールが利用されることが多い。Windows環境であれば「Cygwin」を入れるケースが多いと思われるが、筆者はバイナリをフォルダにコピーしてパスを通すだけで動作する「GNU utilities for Win32」を好んで使っている。

フィルタリングと通知――フィルタリングの重要性

　各種ログを収集するに当たり、できるだけ多くのデータを取得しておきたいのが心情である。しかし、本当にクリティカルな問題が大量の情報の中に埋もれてしまうことも警戒する必要がある。

　経験上、一番怖いのは「慣れ」だ。メールでも専用コンソールでも、大量のイベントが通知されると、（トラブルの可能性を含んだ）イベントそのものに慣れてしまい、「あぁ、またいつものイベントか」と、何も考えずに「削除」「OK」ボタンを押してしまう場合がある。こうして重要な通知を見逃してしまわないようにするには、本当に重要なイベントだけを通知するよう、適切なフィルタを設定することが重要になる。

　では、どうやってフィルタの精度を上げていけばいいのだろうか。