ケーススタディ:MicrosoftとCisco環境におけるSyslog

ケーススタディ

MicrosoftとCiscoベースの環境におけるsyslogを使ったロギング基盤の開発例です。
技術上の主要な部分はWindows用のKiwi Syslog Server(旧 Kiwi Syslog Daemon)です。

Kiwiは、SANSのBrian Wilkinsの論文で取り上げられおり、その議論をもとに製品機能を拡張し実際に使用できるシステムを構築するためのプロジェクトです。
プロジェクトには以下のものを含みました

  • syslog採用前後のコンピュータ環境
  • 設計と製品選択の議論
  • 集中サーバーへの Kiwi Syslog Server(旧 Kiwi Syslog Daemon)の採用
  • syslogクライアントとしてのデバイスネットワーク構築
  • ログデータ保全を強化するのためのアーカイビング

Kiwi Syslog Server製品ページへ

評価版ダウンロードへ


詳細

問題の定義

多くの会社ではより良い情報セキュリティを構築するために最新技術を採用していますが、時間とコストがかかります。これらの決定はしばしば業界のニュースレポートや他のメディアによるヒステリーのようなものによって決定されています。

わが社も、その他の多くの会社のように、ネットワークのデータのセキュリティとパフォーマンスをどのようにすれば良いのか悩んでいました。
それぞれ固有のログデータを持つ世界中の数100台の異機種デバイスの管理が必要でした。
問題が発生しない限りこれらのログデータを分析することはなく、セキュリティに対する姿勢は結果的に受身でした。明らかにこのような基本的なレベルの改良が必要でした。

情報セキュリティの基礎作りのため、この集中ログ管理システムを設計し構築しました。
最終目標はログデータを集中化し、機密性、完全性、可用性を向上することです。

このような仕事はあまり楽しいものではありません。
ログファイルの分析は退屈であり、そこに価値をみつけるのは大変です。
この仕事のせめてもの良い点はあまり多くの費用がかからないということです。
あまり良くない経済状況の中でこの仕事の優先度を最高にできた理由はそこにあります。

成功は複数の技術的な要素に依存します。
多くのデバイスははじめからあるいはユーティリティプログラムでsyslogを出力します。
syslogサーバーに対する要求はそれほど高くないため、既存のハードウェアを使いました。
組織の予算の多くは構築のための人件費でした。
これらのソフトコストは容易に承認されました。

ページトップへ↑

設計上の留意点と製品選択

この計画におけるいくつかの設計上の目標があります。
すべてのデバイスのログデータを常時受信し、さらに情報を安全に保存するための場所は一箇所にしたい。
これは複数のデバイスにわたるイベントを関連付けるためには重要なことです。
このような理由により共通タイムソースとログフォーマットが望ましいわけです。

さらにログデータを以前のものにさかのぼってアクセスすることも必要です。
ログを何らかの証拠として使用するには完全性が必要です。
このためにはよく設計されたアーカイブプロセスと処理手続きが必要です。

使いやすさの観点からは、ログデータのレポートや操作が容易にできるように汎用データベースのを採用を考えました。
究極の要件はログに興味深い項目があらわれるとシステムが即座に管理者にアラート通知を送信することでした。

わが社においてはLinuxの経験が豊富でないためWindowsベースのソリューションが望ましく思われました。
しかしこの分野でもっとも機能が豊富なものはUNIXベースのように思えましたので、この点では落胆しました。

syslogそのものがUNIXにネイティブなものでありWindowsプラットホームでは多くの機能が犠牲になると思われました。
しかしKiwi Syslog Server(旧 Kiwi Syslog Daemon)には興奮しました。

Kiwi製品は基準に準拠しており、安定している上、直感的なインターフェイスを持っています。
ログデータを複数の異なるフォーマットで保存できるばかりでなく、目的に応じたカスタムフォーマットを作成することもできます。
すべてのフィールドのテキストを検索しアクションを実行する、すばらしいしアラート機能があります。
可能なアクションにはemail送信、SNMPトラップ、ICQインスタントメッセージ、音を鳴らしたり、さらにスクリプトや外部プログラムの実行などがあります。

最後の二つはKiwiの最も優れた機能であり、外部プログラムによりKiwi本来の機能をさらに拡張するものです。

KiwiはWindowsで実行するため我社でも十分管理できます。
ベースのOSを堅固にすればログデータのセキュアで集中保管という目的に合致します。
Kiwiの採用により成功への問題点は払拭されました。


Kiwi Syslog Server製品ページへ

評価版ダウンロードへ


ページトップへ↑

ネットワークデバイスを構成する

わが社のネットワークにはにはsyslogを監視したいデバイスが数100台接続されています。
まず監視対象としてデスクトップPCをはずし、サーバー、ルーター、スイッチ、プリンタなどのぺリメータを選択しました。
これでsyslogサーバーの性能にたいする負荷を減少できます。
Kiwiは1時間50万件のログ処理が可能ですのでソフトウェアの問題はありません。

この計画は草の根のようなものであり、既設のハードウェアを利用しました。
集中サーバーにはPentium IIマシンを使用しました。
このサーバーでは1時間7万件のログ処理が可能です。大量のログメッセージを受信しても問題ないこともわかりました。

syslogサーバーのOSはWindows2000 Professionalをインストールしました。
Windows2000 Serverの機能を必要としませんので費用を節約しました。
OSのインストール後サービスパックとHotfixを適用しました。
Microsoft Network Security Hotfix Checkerによりセキュリティパッチを確認し適用しました。

サーバーは十分、堅固になりました。
わが社ではセキュアなマシンにはThe Center For Internet Security's Win2K Professional Gold Standaard Security Templateを使っています。
このテンプレートで効果的にマシンをロックできます。
テンプレートを使うときは内容を完全に理解し、わからないまま使わないようにしてください。
そのような構成を選択するのはなぜかをよく理解してください。
失敗するとその結果に驚かされることがあります。

Kiwiのインストールは実に簡単です。
サービスとしてインストールし、希望すればシステムトレイを最小化できます。
デフォルトコンフィグレーションのままでもすぐにsyslogサーバーとして使えます。

Kiwi Syslog Server(旧 Kiwi Syslog Daemon)のマニュアルによれば受信メッセージをユーザーが構成可能なルールで処理することが可能です。
各ルールは1以上のフィルターと1以上のアクションで構成されます。
受信ログメッセージはルールエンジンで処理され、各ルールと比較されます。
すべてのフィルター条件に合致すると指定された1以上のアクションを登録順に実行します。

この処理は十分強力な最大100のルールで完了します。
各ルールには最大100のフィルターと100のアクションまで定義できます。
アラート機能は非常に柔軟であり、安定性は想像できないくらいです。(以下、略)


Kiwi Syslog Server製品ページへ

評価版ダウンロードへ


ページトップへ↑

ログデータの保全

いったん集めたログデータは、MS AccessやSQLのようなデータベースを使って分析され処理されます。
どの様な方法が最適かはコンピュータの環境に大きく依存しますので議論を避けます。

時刻の同期

すべての環境にとって重要なことを説明します。
それはネットワークの時刻と日付の同期に関することです。
この問題に関する優れた議論は"Forensic impact of Network Time Synchronization by Belinda Brockman"に見ることができます。
同期された時刻がログデータの解析にどのようなメリットをもたらすかを考えます。

複数のタイムソースを採用したり、あるいは各デバイスが自分自身の時刻を持っているとはなはだしい混乱が生じます。
複数のデバイスからのログデータの関連付けが困難になります。
それぞれ独立したタイムソースが存在するとインシデントの発生中の出来事の正確な時刻がわかりません。
ネットワークの時刻を同期することでログファイルの優れた解析が可能になります。

わが社ではNTPを使ってネットワークのすべてのデバイスを一つのタイムソースに同期しました。
採用したデバイスのほとんどはネイティブなNTPサポート機能がありました。
ネイティブな機能がないものにはユーティリティプログラムがあります。
これはプロジェクトにとって易しい部分でした。
自分でsyslogシステムを設計する場合はこの点を考慮してください。

アーカイビング

他の考慮すべき事項はログデータの完全性の確保です。
ログの情報が信頼できるものであるためにはログデータのアーカイビングと取り扱いの手続きが必要です。
幸運にもSANSのトレーニングはこの要求に必要な知識を与えてくれました。

毎日ユニークなログファイルができるようKiwi Syslog Server(旧 Kiwi Syslog Daemon)を設定しました。
そのログファイルを毎夜アーカイブするようにも設定しました。
Kiwiのアーカイブで提供する機能の一つはアーカイブ終了後、外部プログラムを実行できることです。
この拡張性はわが社には非常に価値がありました。

われわれはKiwiによって実行されるバッチファイルを作成しました。
これはいくつかのユーティリティプログラムを実行します。
これらのプログラムはログデータのMD5ハッシュを生成し、一度だけ書き込み可能なメディア(CDROM)にログデータとハッシュを書きます。
このバッチファイルはアーカイブ終了後数秒以内人実行されます。
その結果ログデータの可安全性が確立されます。
MD5ハッシュ値をCDROMに保存された値と性格に比較するとログデータが改ざんされていないことが証明できます。

毎夜CDROMにアーカイブすることに加え、週に一度はDLTにバックアップします。
バックアップは一週間分のログデータとMD5ハッシュをテープに書きます。
テープは離れた場所の安全な格納庫に保管されます。
これでCDROMディスクに万一のことが起きても保存の冗長性ができることになります。

ページトップへ↑

興味深いアプリケーション

Kiwi Syslog Server(旧 Kiwi Syslog Daemon)のアラート機能が非常に役立つことがわかりました。
全体の機能の一部を使い始めたばかりですが、いくつかの成功例を説明します。

"Syslogサーバーの展開"で説明したようにKiwiサーバーのデフォルトルールは各受信ログメッセージについて2つのアクションを実行します。
1つのアクションは各メッセージのファイルへの書き込み、もう1つは各メッセージの画面への表示です。
表示メッセージの多さに困るようになるまでには時間はかかりません。
何もしないと表示が速すぎ、役に立ちません。

受信メッセージをSyslogファシリティを基準にソートして表示することが一つの解決だということがわかりました。
KiwiはDisplay00からDisplay09までのユーザー定義可能な10種類の表示が可能です。
この機能を使ってすべてのLocal0をDisplay00に、Local2をDisplay02に表示するようにしました。
その他も同様です。その結果、重要度の高くない多くのメッセージに邪魔されずにプライオリティの高いメッセージの確認に集中できるようになりました。
さらにルータのトラブルシュートにはDisplay07を選んで見つめていれば良いことがわかりました。
メッセージのソートにより表示速度は十分読めるまでに遅くなり、メッセージ表示の意味が出てきました。

我々が作成したもう一つの興味深いルールはWindows Updateファイルがサーバーに到着したことを管理者に知らせるアラートです。
フィルターで受信メッセージ中の"Automatic Updates"文字列を検索すると、ソフトウェアパッチの到着を知らせるメッセージが取り出せます。
そのときルールは管理者に適用の必要を知らせるEmailアラートを送信します。アップデートのタイムリーな適用に大変有効です。

性能の管理ツールとして、問題のあるホストに一時的なルールを作成します。問題のあるホストからの全メッセージをEmailで送信するだけですが、特定の問題の原因の調査に非常に役立ちます。


Kiwi Syslog Server製品ページへ

評価版ダウンロードへ


ページトップへ↑

結論

この計画を実行したことにより直面していた問題を正すことができました。

多くのホストでsyslogを採用すればするほど問題の解決容易になり、ネットワーク環境全体に良い効果を与えました。
今やネットワークに接続されたすべてのデバイスを定期的に監視し、適切に管理することができるようになりました。
技術的にはまだ受身ですがその対応は非常に速やかになりました。
性能の問題はユーザーによって教えられることなく、ホスト自身から見つけられることを学びました。

設計の要件はほぼ満足されました。
今やすべてのデバイスのログデータは一箇所に格納されるようになり、データは安全に保存され高レベルの完全性でアーカイブされています。
複数デバイスにわたるログの関連付けは共通タイムソースとわれわれが確立したログフォーマットで可能になりました。
ほとんどリアルタイムといえるアラート機能はわれわれの期待を超えており、セキュリティを向上させ、ダウンタイムを減少させるのに大きな効果がありました。

初期の設計は完全に実現できましたがさらに改良されるべき項目を明らかにします。
下記は将来取り入れたい機能のリストです。

  • システム障害や高可用性のためにsyslogサーバーを二重化したい
  • ホストのsyslogサービス機能を信頼できるものにしたい。この目的にはServersAliveやNagiosを採用したい
  • 受信専用ホストのセキュリティを増すにはイーサネットケーブルの転送ワイヤを分割すると良いと聞いたのでそれを考慮したい

ページトップへ↑