【特集】 続 不正侵入対策最前線
〜IDS機能の問題点とその解決法および最新動向〜

丸山 龍一郎
ストーンソフト・ジャパン
ネットワークセキュリティーマネージャー
2002/7/3

　以前に掲載した「不正侵入対策最前線（前後編）」では、IDS（Intrusion Detection System：侵入検知システム）の基本的な動作原理や、ネットワーク型、ホスト型、ハイブリッド型といったIDSの特徴、実際にIDSを運用する場合の留意点やIDSの機能面の問題点について記述した。筆者としては、掲載時点のIDSのマーケットはちょうど第1世代から次の世代への移行期であったと感じている。実際記事を掲載した後、IDSマーケットには多くの新規ベンダの参入や新機能を持ったIDS製品が数多く紹介されてきている。今回の記事では、前回指摘したIDSの機能面の問題点について、特にネットワーク型IDSについて復習し、その問題点を最近のソリューションがどのようなアプローチで解決しようとしているのか、その最新のIDSの動向について記述する。

　なお、IDSに関する基本的な用語や機能説明に関しては、「不正侵入対策最前線（前後編）」を参照していただきたい。

ネットワーク型IDSが抱える問題点

　では、「不正侵入対策最前線（前後編）」の記事で指摘したネットワーク型IDSの問題点をいま一度以下に示す。

• スイッチングネットワーク環境での運用
• 高速ネットワークおよび高トラフィック環境での運用
• シグネチャベースの検知方法の限界
• 暗号化されたパケット
• IDS自体に対する攻撃
• IDSを回避する攻撃
• 検知された事象に対する解析作業が大変

　スイッチングネットワーク環境での導入や暗号化パケットへの対応に関しては、IDS自体の機能というよりはむしろIDSの周辺の環境の問題であったり、ネットワーク型IDSが最初から対応不可能であったりする問題であるので今回の対象からは除外する。

　今回は特にIDSの機能面で前回の掲載から改善された点について記述する。

高速ネットワークおよび高トラフィック環境下での運用

　第1世代のIDSでは、100Mbits/sのスピードのネットワークでさえも監視対象のパケットを取りこぼすような事態が発生していた。また、ネットワークのトラフィックが増大し、帯域が限界に近づいた場合にも同様な事態が発生していた。IDSを導入する目的が、常時ネットワークを監視して、不正あるいは攻撃と考えられる事象を検知することであるため、監視パケットを取りこぼすことは製品としては致命的な問題である。

　この問題点が、トータルセキュリティシステムを構築するうえでIDSは必須のコンポーネントであるにもかかわらず、導入効果が不透明という結論を導き、結果としてマーケットにおいて積極的に導入されなかった一番の原因である。これはネットワーク型IDSのアーキテクチャに起因している。ネットワーク型IDSは、不正パケットや攻撃パケットの指紋データ（シグネチャ）を参照しながら動作している。つまり、監視しているネットワーク上をパケットが通過すると、そのパケットと自身が管理しているシグネチャ・データベースのマッチング処理を実行することでそのパケットが不正か否かを判断しているのである。高速ネットワークや高トラフィックの環境では、ネットワーク型IDSが監視する対象のパケット数は膨大な量となる。膨大な監視対象パケットを処理できないことがパケットの取りこぼしにつながるのである。

　この問題を解消するためのアプローチを以下に紹介する。

1. IDSをアプライアンス化する効果
   
   従来のIDSソリューションは一般のハードウェア（オンボードのネットワークインターフェイスを使用して）に汎用のオペレーティングシステムをインストールし、その上にIDSソフトウェアをインストールして構築するのが通常であった。しかし、このようなシステムでは、ネットワークインターフェイスカード（NIC）自体の性能やシステムのPCIバス速度の性能、IDSにはまったく必要のないサービスの稼働などIDSの動作に影響を与える要因を管理者がすべて把握し、解決する必要があった。特にハードウェアのマザーボード上のNICの場合、データを一時保存するためのバッファサイズが十分でないものが多い。そのため、IDSの本来の性能を引き出すためにはNICの選定作業に時間を要する。
   
   このような導入までの機器選定の手間と導入作業自体を容易にしたIDSアプライアンス製品がある。アプライアンスは、IDS専用のNICとカスタマイズされたドライバを搭載し、チューニングされたオペレーティングシステムを使用して実現されている。
   
   最近では、ギガビットネットワーク対応をセールスポイントとしている製品がある。ギガビットネットワークの実際のワイヤスピード（最大パケット転送能力）は最大で800Mbits/s程度と想定される。従って、IDSとしてはワイヤスピード程度のトラフィックを取りこぼしなく検出できれば、ギガビット対応製品ということが可能であるが、実際のところ検出率が98％を維持する場合の環境は300〜600Mbits/s程度と考えられる。ワイヤスピードでは50％程度の検出率にとどまる。ギガビット対応IDSベンダの中には、ベンチマークテストの結果を公開しているところもあるのでその結果を参考にするとよい。もし、IDSがカバーする範囲を超えるようなトラフィックを処理する必要がある場合は、以下のようなアプローチも考えられる。
   
   
2. IDSが監視するトラフィックフローの分割
   
   IDSの処理の対象となるトラフィック自体を削減して監視処理がオーバーロードにならないように運用する方法がある。特別なスイッチ装置を使用することで監視対象となるネットワークを流れるトラフィックをIPアドレスやアプリケーション（ポート番号）によってスイッチ装置の特定のポートに転送する。各ポートには、転送されてくるトラフィックのみを専用に監視するように設定されたIDSを接続する。図1のように、パケットのペイロードとしてSMTP（ポート番号25）を含むパケットはすべてSMTP専用IDSグループが担当し、HTTP（ポート番号80）を含むパケットはすべてHTTP専用IDSグループが担当するといったことが可能である。
   
   

   図1 IDSが監視するトラフィックフローの分割

   
   しかし、このアプローチで実際の運用をしていくためにはコスト面が無視できない。監視対象を複数に分割することで高価なIDSが複数必要となる。IDSを導入するためのライセンス費用やサポート費用、ハードウェア（アプライアンス機器）費用が膨大になってしまう。ギガビットのネットワークを監視するために、いまだIDSの導入効果も明確となっていないソリューションに対して予算を捻出できるかということである。さらに、トラフィックを複数に細分化する際に、現状どの程度のトラフィックがあり、IDSが確実に処理できるトラフィック量はどの程度かを調査するために十分な時間を費やして分析する必要がある。
   
   
3. IDSが監視対象とするシグネチャの削減
   
   IDSのオーバーロードを回避するためのもう1つのアプローチは、IDSが監視対象とするシグネチャ自体の数を減らす方法である。
   
   IDSは管理するアタックシグネチャに基づいて監視を実行する。製品によっては、DMZ（非武装地帯）上を監視するシグネチャセットや攻撃の検知を最優先にしたシグネチャセットなどをあらかじめグルーピングして提供しているものもあるが、メールサーバやWebサーバなどの特定のアプリケーションサーバを監視する場合には、製品が提供しているすべてのシグネチャを使用して監視する必要はない。つまり、Webサーバであればそれに関するシグネチャのみを対象とすればよい。公開を目的として設置されるアプリケーションサーバは、当然セキュリティ対策は考慮されているはずである。最初に、アプリケーションサーバに対して脆弱性検査を実施して、どこにリスクを抱えているかを調査し、解決可能な項目については対応する。
   
   費用対効果や技術的に解決不可能であるリスクに対しては、IDSを使用してその項目に関連するシグネチャおよびしきい値を定義して、実際にオープンのままとなっている脆弱点に対する攻撃のみを監視する。図2のようにいままでは独立した管理体系を持った製品であった脆弱点検査システム（スキャナ）とIDSが、脆弱点に関する情報を共有して動作するようなアプローチもある。スキャナがシステムの脆弱点検査を実行した結果をデータベースに記録する。当該システムを監視するIDSは、スキャナが作成したデータベースを参照して、自身の監視対象とするシグネチャを決定する。これにより、現時点で監視が必要な攻撃のみを対象とすることでIDSの処理負荷を軽減することが可能である。
   
   しかし、このアプローチで攻撃検知の精度を維持していくためには、脆弱点検査をいかに定期的に実施し、その結果をタイムリーにIDSのシグネチャに反映させることが必要になる。

図2 IDSのオーバーロードを回避するためのもう1つのアプローチ

未知の攻撃パターンへの対応

　IDSは、シグネチャに基づいてネットワークを監視していることは前にも述べた。シグネチャベースのIDSは、既知の攻撃に対しては自身が管理するデータベースに基づいて攻撃を検知することが可能であるが、新しい攻撃に対してはまったく無防備ということである。

　新しい攻撃が認識された場合、各IDSベンダは独自に研究機関を持っているため、攻撃パターンに関する詳細な調査を行い、その結果IDSがその攻撃を検知できるようにするための追加版のシグネチャをリリースする。これが、一般的なシグネチャのアップデートの流れである。

　しかし、ベンダによっては、緊急性を要する攻撃以外はひと月に1回しかシグネチャが更新されない場合がある。このような状況では、ユーザーは新しい攻撃の標的に自分のシステムがならないことを祈るだけである。シグネチャの更新に関しては、ウイルスのパターン更新と同様な運用を筆者は希望する。また、シグネチャを更新した後にIDSサービスの再起動が必要な場合もあり、24時間365日の継続的な監視を可能とするまでには至っていない。

　最近では、このようなシグネチャベースの欠点を克服するためのアプローチも考案されてきている。未知の攻撃に対するアプローチとして、TCP/IP自身のプロトコルや各アプリケーションプロトコルの状態遷移を監視することで異常なパケットを検出するものである。

　例えば、TCP/IPの場合の状態遷移表の一部を図3に示す。

図3 TCP/IP自身のプロトコルや各アプリケーションプロトコルの状態遷移を監視することで異常なパケットを検出

　ネットワークプロトコルを理解するためには、状態（State）と事象（Event）に基づいた状態遷移図や表の作成が不可欠である。例として、TCP/IPの場合、LISTEN状態（リクエスト待ち）にあるとき、他システムから“SYNフラグ”が立ったパケットを受信すると、SYN_RCVD状態に移行する。このように、ある状態のとき、ある特定の事象が発生すると、次にどのような状態になるという動作はプロトコルの仕様として決まっているのである。従って、ある状態のときには、ある事象しか受け付けないのである。仕様上規定されていない事象が発生した場合、それはプロトコル異常として通知される。未知の攻撃の対応策の1つがこのようにプロコトルの異常に着目するアプローチである。

　しかし、実際のところこのアプローチもシグネチャベースと同様な問題を持つことになる。新しいアプリケーションが登場した場合、そのアプリケーションプロトコルの状態遷移情報をIDSに組込む必要がある。この開発およびインテグレーションプロセスがどのくらい迅速に実施できるかが再び課題となる。

解析作業の負荷軽減

　IDS導入後によくいわれるのは、検出したイベントの真偽性である。ネットワークを監視し、攻撃と思われる振る舞いを示したパケットを検知し、ログとして記録するわけであるが、それを確かに攻撃であると判断を下すのはあくまでもシステム管理者である。高速なネットワークやトラフィックの多い環境に限らず、複数のIDSを監視センターで管理している場合でも、IDSの管理コンソールに蓄積されるイベントは膨大な数となる。個々のイベントを分析する場合、イベントに関連する情報の収集方法やトレース（追跡）作業方法のすべては管理者のスキルに依存してきた。また、危険性が高いイベントの調査作業については、その範囲がとかく自身の組織だけにとどまらず、他組織にまたがった調査をする必要がある。さらに黒か白かの結果が明らかになるまで（なかなか明らかにはならないが）時間がかかる。中でも最も困難な作業は、管理コンソールに表示されているイベント間の関連付け作業である。このような、“調査時間がかかる”、“技術・知識を要する”という2つの大きな壁が、一般的にIDSの導入をちゅうちょさせてきた大きな理由である。結局、導入はしたが、検出したイベントも攻撃か否かを明確にできず、エグゼクティブからは、導入効果がないという判断をされてしまうのである。

　IDSとしてログの解析作業にどのような機能が必要となるのか？ 最近のIDS製品の中には、IDSが検知したイベントを基に、そのイベントに関係するほかのイベントを含めて分析を行う機能を持つものがある。同じような攻撃パケットを抽出して解析したり、1つの攻撃先のシステムに関するイベントのみを抽出して解析したり、いままでシステム管理者が手作業で実行していたイベント間の相関関係を決定する作業も自動的に行う。

　攻撃者は、いきなり目的のシステムに攻撃を試みるわけではなく、最初は情報の収集作業から進める。pingスイープ（pingを指定した範囲のIPアドレスに対して行う偵察スキャンの一種）やポートスキャンといったツールを使用して、稼働しているシステムの探索やシステム内で有効となっているアプリケーションなどを探索する。その結果、そのシステムの脆弱点を突いた次の攻撃に移るのである。このような、攻撃の初期行動から実際の攻撃までの一連の行動は、図4のような形でIDSのログに記録される。解析作業の成果物に関しても、このインテリジェンスなログ解析機能は、従来の個々に発生したイベントに基づくレポートでなく、インシデントに基づいた集約されたレポートを提供する。ログ解析にかかる労力が大幅に削減できることは、システム管理者にとっても朗報である。

図4 攻撃の初期行動から実際の攻撃までをIDSのログに記録し、解析をする

　しかし、管理者はそのレポートに基づいた攻撃元の追跡作業が残されていることを忘れてはならない。攻撃元の追跡に関しても、IDSが攻撃と認識した時点でリアルタイムに攻撃元を追跡する機能を持つ製品もある。この機能は、攻撃元自体を突き止めることができるわけでなく、どのISPから攻撃パケットが送信されたかといった程度で自動的に追跡するようである。実際は追跡に使用するツール（例えば、tracerouteなど）で使用しているプロトコルがファイアウォールなどで止められたりするケースもあるので、この機能がどこまで有効なのかは未知数である。

　解析作業とは少し内容が異なるが、IDSが検知したイベントの管理に関連した機能を紹介する。ネットワーク上に複数のIDSが配置されているような環境において、IDS間で検知したイベント情報を共有して攻撃に備えることができる。従来の管理方法は、複数台のIDSからのイベントを中央の管理ステーションが収集する、いわゆるIDSからコンソールへの一方通行であった。検知情報の共有は、1台のIDSが検知した攻撃情報をほかのIDSへ送信することで行われる。従来の方法は静的な監視であり、この方法は動的な監視といえる。

　図5は、ある企業のネットワークが複数の回線でインターネットと接続する、マルチホーミングの環境を例としている。このような環境に対して、攻撃者が外部からDos攻撃を仕掛けるとすると、DNSの公開情報などから1つ目のネットワークアドレス（ファイアウォールのアドレス）が既知となり、そこに対して攻撃が行われる。その後、別のネットワークアドレス情報が既知となり、そこに対して攻撃が開始されることとなる。このような場合、最初に攻撃されたネットワークを監視しているIDSがDos攻撃を検知し、その情報を別のネットワークを監視するIDSに通知すれば、あらかじめDos攻撃に対応することが可能である。しかし、この攻撃情報の共有もその攻撃に対するカウンターアクションが取れない場合は意味がなくなってしまう。

図5 マルチホーミングの環境を例とした既知の攻撃に対する対応

IDS自体に対する攻撃

　ネットワーク型IDSは通常、ステルスモード（IPアドレスを割り当てないため外部から存在が分からない）で運用するため直接攻撃対象とはならないが、最初に記述した高速ネットワークや高トラフィック環境で処理がオーバーロードした場合にIDS自体がハングアップしてしまう場合がある。従来のネットワーク型IDSは、監視台から下を通過するパケットを監視しているようなイメージである。極端な話、IDSが稼働していても、停止していても保護すべきサーバ群に対してはアクセスすることが可能である。裏を返せば、IDSが機能を停止するほど大量なパケットを送りつければ、攻撃者は無防備なサーバ群を攻撃することが可能である。

　仮にIDSが停止に追い込まれてもサーバ群に対するセキュリティを維持するためのアプローチがインライン型IDSである。インライン型IDSは、2つのセグメントの間に配置される。イメージ的にはファイアウォールと同様であり、両セグメントから入出力されるパケットに対しては、自身が保持するシグネチャを基に監視し、問題があるパケットはドロップ（破棄）する。ネットワーク型IDSとの大きな違いは、仮にIDS自体が攻撃されるような事態になり、停止に追い込まれても、ネットワーク的にIDSの背後のネットワークやサーバ群に到達することができない、いわゆるフェイルセーフが実現されているということである。図6、図7にネットワーク型IDSとインライン型IDSの動作の違いをまとめてみた。

図6 ネットワーク型IDSとインライン型IDSの動作の違い（IDS稼働時）

図7 ネットワーク型IDSとインライン型IDSの動作の違い（IDS停止時）

　「不正侵入対策最前線（前後編）」の記事の中で、重要なサーバを防御するためには、ホスト型IDSを導入することでより詳細に対象ホストを防御することができるという記述をした。ホスト型IDSの場合には、サーバが動作するシステム上で稼働するためさまざまなオペレーティングシステムをサポートする必要がある。さらに重要なサーバには余計なソフトウェアは導入したくないというエンドユーザー心理もある。このように、本来はホスト型IDSで対応すべき部分にもかかわらず、上記のような問題で導入することができなかった環境に対してもインライン型IDSを導入してセキュリティ対策を取ることが可能となった。

まとめ

　今回は、主にネットワーク型IDSに関して第1世代の問題点が最近のソリューションでどのように改良されてきているかについて記述した。監視能力に対する信頼性も向上し、検知された事象に対する解析作業の負荷を軽減するような高度な解析機能を所有するなど、第1世代のソリューションと比較するとかなり導入しやすいものになっている。IDSを導入する目的は攻撃の兆候の検知、攻撃自体の検知およびそれに対する防御があるが、攻撃元を追跡し、法的措置を取るために必要な情報を収集する目的もある。攻撃を検知した際に自動的に攻撃元を追跡する機能をもつ製品もあるが、最終ターゲットにはなかなかたどり着けないのは事実である。これらの作業はいままでどおり管理者が手作業で実施しなければならない点に変わりはないのである。結果として、管理者の負荷軽減は解決できないことになってしまう。

　この問題を解決するためには、インターネットからの攻撃に対してはISPが責任を持って管理すべきと考える。つまり、ISP内にIDSを設置し、顧客ネットワークを監視するのである。ISPでは、ネットワークセキュリティの専門家を用意してIDSが検知した事象に対してアクションを検討する。管理者の負荷の問題だけでなく、ISPで監視を実施する利点は、攻撃の兆候を検知した場合、ほかの顧客のネットワークに対してもISP全体で警戒態勢をしくことが可能となるのである。従来は、各組織で実施していたセキュリティ対策がISP内で統一されたポリシーの下で運用されることはネットワーク全体のセキュリティレベルの向上につながる。インターネットからの攻撃に対する監視をISPに移管した管理者は、社内からの攻撃に対してのみ注意することになる。不特定多数のユーザーが利用するインターネットと異なり、イントラネットは利用するユーザーも明確であり、追跡作業も可能となる。

　IDSの導入効果についてはなかなか目に見える形で理解されるものではない。しかし、導入、運用してその時々で問題点を解決していかない限りソリューションとしては成長することができない。筆者としてはIDSがファイアウォールと同程度の認知度を実現するまで動向に注目していこうと思う。

Security&Trust記事一覧

関連記事 連載：不正侵入対策最前線 前編 不正侵入の現状とトータルセキュリティのススメ 後編 侵入検知システムでのトータルセキュリティの構築

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）