 |
||
|
|
ホワイト ペーパー
IDSでの攻撃の識別方法
イントロダクション
A. ネットワークの侵入について、多くのベンダーがIntrusion Detection System（IDS;侵入検知システム）を開発していますが、そこにはさまざまな要素が関連しています。そのため、最良の方法や解決策をめぐって、各IDSベンダーの主張も大きく分かれています。ここでは、各種侵入検知方法の長所および短所について検討し、IDS製品に関するシスコのアプローチを説明します。ここで扱う検知方法は、シンプル パターン照合、ステートフル パターン照合、プロトコル デコードベース シグニチャ、学習ベース シグニチャ、異常検出です。ここではそれぞれの分析手法について詳細に検討することはできないため、基本概念と各アプローチの違いに重点を置いて説明します。
ここでは、「シグニチャ」という用語は、侵入イベントのタイプを示す一連の条件という意味で使用します。シグニチャで使用されるアルゴリズムは、ここで説明する5種類の方法のいずれか（「異常検出シグニチャ」など）に基づいています。シグニチャという用語は、とりわけパターン照合に密接に関連しているため、この定義を明確に理解しておく必要があります。シグニチャベースのIDSはパターン照合にしか使用されないと誤解されることがありますが、この定義を理解しておけば、こうした誤解がなくなります。
パターン照合
パターン照合では基本的に、単一パケット内で、固定シーケンスのバイトを検出します。その名の示すとおり、柔軟性に欠けることはありますが、展開の容易な方法です。多くの場合、パターンの照合が行われるのは、比較対象となるパケットが特定のサービスに関連付けられている（つまり、特定のポートで送受信される）場合のみです。そのため、各パケットに対して行われる検査の量は軽減されます。ただし、特定のポートを使用しないプロトコル、特にトロイの木馬およびそれに関連するトラフィックは、通常任意にポートを変更することが可能で、処理が難しくなる傾向があります。
シンプル パターン照合におけるシグニチャの構造は、次のようになります。
パケットがIPv4のTCPで、宛先ポートが2222、ペイロードに文字列「foo」が含まれる場合アラームが発行される、とします。
この例のパターン照合はもちろん非常に単純なものですが、ここから派生する照合方法も単純なものです。パケット内で検査する開始点および終了点を規定したり、検査対象のパケットのTCPフラグを指定したりすることもできます。ただし、この方法は侵入検知の最も単純で原始的な基本要素です。
長所
短所
ステートフル パターン照合
より高度な方法は、ステートフル パターン照合ベースの分析です。このシグニチャ開発方法では、「ネットワーク ストリームは単一パケットだけで構成されているわけではないので、ストリームのステート内のコンテキストに合わせて照合を行う必要がある」という概念が追加されています。そのため、このようなシグニチャ分析を行うシステムでは、TCPストリーム内のパケットの到着順序を考慮し、パケットの境界を越えてパターン照合を行う必要があります。
このシナリオを、シンプル パターン照合で紹介した例に当てはめるとどうなるでしょうか。この場合、パケットごとにパターンを探すのではなく、まず監視対象のTCPストリームでステート情報を維持する必要があります。この違いを理解するため、次のシナリオを考えてみてください。検出対象の攻撃がサーバに接続されたクライアントから実行され、パターン照合メソッドがIDSに設定されているとします。攻撃により、ポート2222を宛先とする特定の単一TCPパケットに文字列「foo」が設定されている場合、アラームが発行されます。しかし、攻撃者が文字列の設定方法を変更し、最初のパケットで「fo」がサーバに送信され、次のパケットで「o」が送信されるようにした場合、アラームは発行されません。これに対して、ステートフル パターン照合アルゴリズムを使用した場合、センサに文字列の「fo」の部分がまず格納され、「.o」の部分がクライアントから転送された時点で照合を完了することができます。
長所
短所
プロトコル デコードベースの分析
プロトコル デコードベース シグニチャは、ステートフル パターン照合をさまざまな点で高度に拡張したものです。このクラスのシグニチャは、クライアントやサーバでのやりとりと同じ方法で各種エレメントをデコードして実装されます。プロトコルのエレメントを識別する際、IDSでは、RFCによって定義された規則を適用して違反を検出します。こうした違反は、特定のプロトコル フィールド内でのパターン照合によって検出される場合もあれば、フィールドの長さや引数の多さなどの変数を利用した高度な手法が必要となる場合もあります。誤解されがちですが、パターン照合とプロトコル デコーディングは、相互に排他的なものではありません。
理解を深めるため、もう一度abc攻撃の例を考えてみましょう。攻撃の行われる基本プロトコルを架空のBGSプロトコルとし、攻撃では不正な引数「foo」がBGS Typeフィールドに設定されるとします。さらに複雑にするため、Typeフィールドの前にはBGS Optionという可変長のフィールドがあるとします。オプションの有効な一覧は、fooh、mooh、tormer、buildoとします。この場合にシンプル パターン照合またはステートフル パターン照合アルゴリズムを使用すると、オプション「fooh」に検索対象のパターンが含まれているため、フォールス ポジティブが発生します。また、フィールドが可変長であるため、検索の開始位置と終了位置の指定によってフォールス ポジティブを制限することはできません。BGS Type引数として「foo」が設定されていることを確認するには、プロトコルを完全にデコードするしかありません。
プロトコルを完全にデコードしていない場合、パターン照合アルゴリズムでの対処が難しい動作をプロトコルで許可すると、フォールス ネガティブが発生することがあります。たとえば、BGSヘッダーへの値の設定時に、BGSプロトコルで1バイトおきにNULLの設定を許可している場合、パターン照合では、fx00ox00ox00は検出されません。プロトコル デコード対応の分析エンジンでは、NULLが無視されるため、Typeフィールドに「foo」が設定されているとみなされ、アラームが発行されます。
長所
短所
学習ベースの分析
学習ベース シグニチャでは、アラーム決定の基礎となるアルゴリズム ロジックを使用します。このアルゴリズムには、送信されるトラフィック タイプの統計評価がよく使用されます。このタイプのシグニチャの例としては、ポートのスウィープの検出に使用されるシグニチャがあります。このシグニチャは、特定のマシンに接続される固有ポートのスレッシュホールド値があるかどうかを探します。対象となるパケットのタイプ（SYNパケットなど）を指定することにより、このシグニチャをさらに絞り込むことができます。また、プローブがすべて単一の送信元で生成されている必要があるという要件を設けることもできます。このタイプのシグニチャの場合、監視するネットワークの利用パターンに合わせるため、スレッシュホールドを一部変更する必要があります。このタイプのシグニチャを使用すると、単純な統計例だけでなく、非常に複雑な関係も検出することができます。
長所
短所
異常ベースの分析
異常ベース シグニチャは基本的に、「正常」とみなされるものから逸脱したネットワーク トラフィックを検出します。この方法の最大の問題は、「正常」とするものを最初に定義しなければならないことです。システムによっては、「正常」の定義がハードコーディングされているものもありますが、この場合、学習ベースのシステムと考えることができます。「正常」を学習するよう構築されているシステムもありますが、こうしたシステムでの課題は、「異常」動作を誤って「正常」として分類してしまう可能性を低減することです。また、学習するトラフィック パターンを「正常」とみなすには、許容可能な逸脱と、許容できない逸脱や攻撃ベースのトラフィックを示す逸脱とをシステムでどう区別するかが課題となります。異常ベースの検出メソッドの使用を謳った製品も一部市販されていますが、この領域の開発は主に学究的な世界を中心に進められてきました。このタイプの検出のサブカテゴリとして、プロファイルベースの検出メソッドがあります。このようなシステムでは、ネットワーク上でのユーザやシステムのやりとりの変化をもとに警報が発行されます。ここでも、メイン カテゴリで動作の変更の意味を推測する上で障害となる制限や問題が同様に存在します。
データを調べることにより、興味深い事実を明らかにできます。それに基づいて、このアルゴリズムを使用し、実行中の攻撃を検出することができます。ただし、システムによって提供される情報は、一般的に特異性が非常に低く、コンテキストを適切に判断するには詳細な調査が必要になります。
異常ベースの検出には、プロトコルベース異常検出という検出方法もあります。この方法は、前述のプロトコル デコード メソッドと密接に関連しています。プロトコル定義でプロトコル検出が適切に定義されているため、異常の学習は不要です。プロトコル異常の一例は、プロトコル内のフィールドに予期しない値が設定されている場合です。多くのプロトコル デコード分析エンジンでは、既知の攻撃に直接関連するものではないが、「異常」（長さに基づくバッファのオーバーフロー検出など）とみなされるプロトコル異常があった場合に警報が発行されるため、どの方法で検出が行われたかはっきり分類できない場合もあります。そのため、この例では、エンジンは異常ベース システムの属性を持ちます。
統計異常についても、トラフィックの種類ごとに定められた統計基準を学習または通知することにより、ネットワーク上で特定することができます。たとえば、UDPフラッド、TCPフラッド、ICMPフラッドなどのトラフィック フラッドの検出が可能です。これらのアルゴリズムでは、現在のトラフィック受信レートと履歴参照値が比較され、それに基づいて、履歴の平均から統計的に大きく逸脱したものが警報されます。警報の統計スレッシュホールドをユーザが設定できるものもあります。
こうしたシステムは、一般的にIDSのソリューションとして製品化されていますが、同様の手法を利用したシステムの学究的な研究も盛んに行われています。ある程度の成果は出ていますが、製品として実用化に耐えるものとはなっていません。学究的研究分野における成果の少なさは、「夢のような話は所詮夢でしかない」という言葉を裏付けるものとなっています。
長所
短所
結論
では、最良の方法はどれでしょうか。答えは、実現しようとしている機能によって異なるとしか言えません。Network IDS（NIDS）に対するシスコの方針は、パターン照合、ステートフル パターン照合、プロトコル デコード、学習ベース シグニチャを組み合わせて使用することです。解決しようとしている問題、つまり、検出しようとしている攻撃に合わせて、適切なツールを使用することをお勧めします。組み合せの比重としては、プロトコル デコードの占める割合が大きくなります。シスコのシグニチャの大部分がこの方法で実装されているためです。その次によく使用されるのは学習ベース シグニチャ、次がパターン照合となり、最後が、プロトコルおよび統計の各種異常ベース メソッドとなります。シスコは、今後もIDS分野の研究と開発の監視を継続し、新しい手法の効率性、実践性、コスト効率、商業上の実現可能性が実証された時点で、製品に組み込んでいきます。