侵入検知システム（IDS：Intrusion Detection System）が注目されるようになって久しい。一口にIDSといっても，「ネットワーク型IDS」と「ホスト型IDS」があるが，一般にIDSというと前者を指す場合が多いようだ。しかし，システムのセキュリティを高めるためにはホスト型IDSも非常に有効である。そこで今回のコラムでは，ホスト型IDSのメリットと運用のポイントを，筆者が体験した事例を交えて解説したい。

注目されないホスト型IDS

　当初は“コア”な管理者のためのツールと考えられてきたIDSだが，最近では一般の管理者にもその有用性が認知されるようになってきた。市販およびフリーのIDS製品も数多く登場している。

　IDSは，その設置場所や監視対象などから，大きく2つのタイプに分けることができる（関連記事「IDSの概要と導入のポイント」）。

  • ネットワーク型IDS
  • ホスト型IDS

　その名の通り，ネットワーク型IDSはネットワークを監視し，ホスト型IDSはそれが導入されたホスト（サーバーやクライアント）を監視する。IDSといえば，一般的にはネットワーク型IDSを想像するユーザーが多いのではないだろうか。メディアなどに取り上げられる機会も，個人的な印象ではネットワーク型IDSのほうが多いと感じる。

　しかしネットワーク型IDSとホスト型IDSにはそれぞれ一長一短があり，どちらか一方のみでは万全とはいえない。そこで今回のコラムでは，日ごろあまり注目されないホスト型IDSに焦点を当てて，その機能やメリット，運用のポイントなどを紹介していく。

ホスト型IDSの機能

　ホスト型IDSは，監視の対象とするホストに直接導入して利用する。そして，以下を監視する機能を主に備える。

  • 監視対象ホストが受信したパケット
  • 監視対象ホストが出力するイベントやログ
  • 監視対象ホストのファイルの変更
  • 監視対象ホストのシステム・コール

　これらを監視し，あらかじめ設定された特定の変化やイベントを検知すると，管理者への通知といった特定の動作を行う。検知後の動作についてはネットワーク型IDSとほとんど同じである。

ホスト型IDSを導入するメリット

　次に，ホスト型IDSを導入および運用するメリットを考えてみよう。ネットワーク型IDSと比較した場合のメリットを，筆者は以下のように考える。

　(1) 検知したイベントの信頼性が高い
　(2) 暗号化通信へ対応できる
　(3) 不正アクセス以外のイベントも検知できる

　ネットワーク型IDSは，ネットワークに流れているパケットを監視する。そして“疑わしい”パケットを検知した場合に警告などを発する。あくまでも疑わしいパケットを検知するだけなので，そのパケットが受信ホストにどういった影響を与えるのか，本当に悪影響を与えるのか――までを確認することはできない。例えば，ネットワーク型IDSが多数の警告を発しても，パケットを受信したホストには何の影響もないことがありうる。

　それに対して，ホスト型IDSは監視対象ホストのイベントを監視するので，警告が発せられた場合には，そのホストが影響を受けている可能性は非常に高い。つまり，ネットワーク型IDSは，影響の“可能性”を警告するのに対して，ホスト型では“結果”を警告するので，検知したイベントの信頼性が高いのだ。

　とはいえ，これをもって「ホスト型のほうがネットワーク型よりも優れている」とはいえないことに注意してほしい。「検知したイベントの信頼性が高い」ことを示すだけで，トータルの有用性についてネットワーク型が劣っていることを示しているわけではない。

　さらに，ホスト型IDSで検知したイベントの信頼性は，監視対象ホストの信頼性に比例することにも注意しなくてはならない（これについては“運用のポイント”の部分でも述べる）。対象ホストが“健全”な状態では，確かに検知されたイベントの信頼性は高いが，IDS導入前に既に侵入を許しているホストにおいては，検知されたイベントの信頼性はゼロに等しい。

暗号化通信にも対応

　最近では，重要な情報をやり取りする際には SSLや SSH ，VPN といった暗号化通信を利用するケースが増えている。暗号化された通信に含まれる疑わしいパケットについては，ネットワーク型IDSでは検知できない場合が多い。しかし，ネットワーク上では暗号化されていても，ホスト内部では暗号化されていない状態でデータやイベントがやり取りされるので，ホスト型では検知できるのだ。

　不正アクセス以外の，ホストの異常を検知できることもホスト型IDSのメリットである。具体的には，オペレーション・ミスや特定のアプリケーションのエラーなどを検知できる。ホスト型IDSの設定によっては，ユーザーが誤ってファイルを消した場合や，設定を変更した場合にも検知し，復旧することが可能である。

ホスト型IDSの運用上のポイント

　では次に，ホスト型IDSの運用上のポイントについて考える。筆者は業務でホスト型IDSを扱うことが少なくない。いろいろ“泣かされた”こともある。そういった体験を踏まえたポイントを紹介するので，これから運用しようという管理者の助けになれば幸いである。

　ホスト型IDSを導入および運用する上では，以下の5点を考慮する必要がある。

　(a) 導入対象の範囲
　(b) 導入に伴うホストへの影響
　(c) ホストへの負荷
　(d) 出力されるイベントの信頼性
　(e) ネットワーク型IDSやファイアウオールとの連携

　まず考慮すべきは，ホスト型IDSを導入する範囲（台数）である。一般的に，ネットワーク型IDSの場合には，監視したいネットワークに一台用意すればよい。しかし，ホスト型IDSは監視対象のホストごとに導入する必要があるので，対象を範囲を広げれば，当然導入コストは高くなる。さらに見逃せないのが運用コストである。監視すべきホスト数が多くなれば，運用コストも高くなる。運用が重要なIDSでは，この運用コストが重くのしかかる場合が多い。

　実際筆者も経験がある。以前，ホストが20数台のネットワークを管理していたときに，ホスト型IDSをすべてのホストに導入したことがある。導入自体は問題なかったが，いざ運用を開始すると，バージョン・アップやパッチの適用といったメンテナンスにかかるコストが膨大になり，結局運用をあきらめた経験がある。

　できるだけ多数のホストに導入すれば，システム全体のセキュリティ・レベルは向上するが，運用できなければ意味はない。複数のホストへIDSを導入する際には，導入時にかかるコストだけではなく，運用にかかるコストも検討した上で，導入範囲を決めることが重要なのだ。

ホストへの影響も考慮

　（b）「導入に伴うホストへの影響」も十分考慮しなければならない。ホスト型IDSを導入することで，対象ホストが提供するサービスに支障が出る可能性があるからだ。ファイルの改ざんやログ・ファイルの監視を行うような場合には，ホストの既存機能を利用できるので，ホストへ特別な変更を施すことなく行える。このような場合には導入が与える影響はほとんどない。

　問題は，対象ホストへ変更を加えなければならない場合だ。例えば，OSのカーネルのシステム・コールを監視したいような場合には，カーネル自身を変更する必要がある。このような場合には，その変更に伴って従来のサービスを提供できなくなる恐れがある。

　実際，数カ月前に筆者はそのような“症状”を目の当たりにした。あるホスト型IDSを導入した直後に，そのホストに全くログインできなくなってしまった。いろいろ調べたが，その原因がOSにあるのか，ホスト型IDSにあるのかを突き止めることはできなかった。

　「ホスト型IDSの導入が危険」ということを言いたいのではない。「十分に検証した上で導入してほしい」ということである。可能ならば，現在既にサービスを提供しているサーバーなどに導入するのではなく，サーバーの構築時に検証した上で導入するようにしたい。

IDSにより増大するホストの負荷

　（c）「ホストへの負荷」が増加することも軽視できない。監視対象となるホストの多くは日常的にクライアントとして利用されているか，サーバーとしてサービスを提供している。IDSの導入により，日常的にかかっている負荷にIDSの負荷が加わることになる。その結果，通常のサービスを提供できなくなる恐れがある。

　例えば，ファイルの改ざんをチェックするホスト型IDSは，指定されたファイルを定期的にチェックする。このチェックの間隔を非常に短く設定してしまうと，チェック作業にホストの資源を大きく割くことになり，今まで提供していたサービスを正常に提供できない状態になる可能性がある。

　IDSが出力するログ・ファイルなどにも要注意だ。イベントが頻繁に検出されるような状況になると，ホストのCPU負荷が高まるとともに，ログ・ファイルがストレージに収まらなくなり，通常のサービスを継続することができなくなってしまう。

　以前，ホスト型IDSを導入していたホストに対してポート・スキャンを実行した際に，まさに上記のような状況に陥った。数分間で100Mバイトを超えるログ・ファイルが作成され，対象ホストのCPUの負荷が急激に増大してしまった。もっともこのときには，開発バージョンのホスト型IDSを利用していたことが原因だった。ホスト型IDSが暴走してしまい，膨大な量のログが出力され続けた。

　市販あるいは安定版のIDSを使う上では，筆者が経験したような極端な状況に陥ることはまずないだろう。しかしながら，どのようなIDSを導入する上でも，ホストへの負荷や発生するイベントの数，出力されるログのサイズなどを確認しておくことが重要である。

IDSの信頼性はホストの信頼性に比例

　（d）「出力されるイベントの信頼性」は，ホスト型IDSのメリットの部分でも述べたことと関係する。メリットの部分で述べたことと重複するが，ホスト型IDSが検出するイベントの信頼性は高い半面，対象ホストが既に侵入されている場合には，イベントやログの信頼性はゼロになってしまうのだ。

　例えば，侵入後「rootkit」と呼ばれるツールを仕掛けられた場合，特定のイベントのみが出力されないような状態にされることもありうる（関連記事「不正侵入後に仕掛けられる『rootkit』の脅威」）。

　そのようなrootkitは実際に存在する。以前筆者は，当時管理していたネットワークのあるホストが侵入されていることを発見した。そのホストに仕掛けられていたツールが偶然にも残っていたので解析したところ，ある特定の文字列がログに記録されないようにする機能を備えていることが分かった。実際そのホストを検査してみると，その文字列が出力されない状態になっていた。

　このような状態のホストに，ホスト型IDSを導入したとしても検知されるイベントは全く信頼できない。ホスト型IDSの信頼性は対象ホストの信頼性に比例することに注意し，セキュアなホストを構築した上で，ホスト型IDSを導入してほしい。

連携機能は両刃の剣

　（e）「ネットワーク型IDSやファイアウオールとの連携」も要注意である。これらの連携機能は，適切に設定することでセキュアなネットワークを維持することができる半面，不適切な設定をした場合や装置（ソフトウエア）が誤動作した場合などには正常な通信などを妨げる恐れがある。

　最近のホスト型IDSには，他のIDSやファイアウオールなどと連携する機能を備えるものがある。例えば，あるホストからのログインの試みをホスト型IDSが検知した際に，ファイアウオールでそのホストからのアクセスを遮断する――といった機能を備える。

　自動的に対応してくれるので管理者にとっては有用な機能ではあるが，一つ設定を間違えれば，正規の通信を遮断することになる恐れがあることに注意しなければならない。

　ネットワーク型IDSとホスト型IDSが出力したログを自動的に相関分析できる製品もある。そして，相関分析の結果をファイアウオールなどに反映して，対象とする通信を遮断できる。こうすることで，より一層精度の高い監視を実現できるとともに，対応を自動化できる。

　しかしこの場合も，設定ミスや誤検知により正常な通信を遮断してしまう可能性がある。便利な機能は，うまく働けば大きなメリットをもたらすが，うまく動作しなかったときにはリスクが大きい。このことを十分認識した上で，有効活用してほしい。

　ちなみに筆者は，自宅のネットワークでネットワーク型IDSとホスト型IDSを導入しているが，これらを連携させてはいない。普段はホスト型のIDSのログをほとんど参照せず，ネットワーク型のIDSで不審なログが出力された場合のみ，ホスト型のIDSのログを確認している。つまり，手動で相関分析しているのだ。自動化していないので手間はかかるが，正常な通信を遮断するようなリスクはない。

◇　　　　　◇　　　　　◇　　　　　◇　　　　　◇　　　　　◇

　今回はホスト型IDSのメリットと運用上のポイントについて述べたが，ネットワーク型IDSとホスト型IDSはお互いに補完的な関係にある。繰り返しになるが，どちらか一方だけでは万全ではないのである。両方を適切に利用することで，ネットワークのセキュリティ・レベルをより高めることができる。

　また，運用上のポイントで説明したように，便利な機能は“両刃の剣”であることも肝に銘じておきたい。便利な機能をうまく使いこなせば，それに超したことはないが，「うまく機能しなかった場合にどういった状況になるのか」を把握しておかないと，導入によって今まで利用できたサービスが利用できなくなる事態に陥ってしまう。もっともこのことは，IDS製品に限らず，どのような製品でもいえるだろう。

川口 洋 (KAWAGUCHI Hiroshi) hiroshi.kawaguchi@lac.co.jp
株式会社ラック セキュアネットサービス事業本部

　IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。