この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
シグニチャ エンジンは、特定のカテゴリの多数のシグニチャをサポートするように設計された Cisco IPS のコンポーネントです。エンジンは、パーサーとインスペクタから構成されます。各エンジンにはパラメータのセットがあり、パラメータには使用可能な範囲や値のセットがあります。
(注) 5.1 エンジンは、標準化された正規表現をサポートします。
IPS 5.1 には次のシグニチャ エンジンが搭載されています。
HTTP プロトコルの不正利用を防止するために、HTTP セッションを精密に制御します。これは、インスタント メッセージや、gotomypc など、特定のポート上でトンネリングを試行するアプリケーションに対する管理制御を可能にします。AIC を使用して、FTP トラフィックを検査し、発行されるコマンドを制御することもできます。
AIC FTP と AIC HTTP の 2 つの AIC エンジンがあります。
AIC エンジン シグニチャの設定の詳細については、「アプリケーション ポリシーの設定」を参照してください。
• Atomic:Atomic エンジンは、現在、2 つのエンジンが組み合され、マルチレベルで選択できます。たとえば、IP + TCP のように、レイヤ 3 およびレイヤ 4 のアトリビュートを組み合せて 1 つのシグニチャを作成できます。Atomic エンジンは標準化された正規表現をサポートします。
–Atomic IP:IP プロトコル パケットと関連付けられたレイヤ 4 転送プロトコルを検査します。
このエンジンでは、IP ヘッダーとレイヤ 4 ヘッダー内のフィールドと照合する値を入力し、正規表現を使用してレイヤ 4 ペイロードを検査できます。
(注) すべての IP パケットが Atomic IP エンジンによって検査されます。このエンジンは、4.x Atomic ICMP、Atomic IP Options、Atomic L3 IP、Atomic TCP、および Atomic UDP エンジンに取って代わります。
–Atomic ARP:レイヤ 2 ARP プロトコルを検査します。ほとんどのエンジンはレイヤ 3 IP に基づいているため、Atomic ARP エンジンはその他の大半のエンジンとは異なっています。
• Flood:ホストおよびネットワークを宛先とする ICMP および UDP フラッドを検出します。
Flood HOST と Flood NET の 2 つの Flood エンジンがあります。
• Meta:スライドする時間間隔内で、関連する方法で発生するイベントを定義します。このエンジンは、パケットではなくイベントを処理します。
• Multi String:複数の文字列を 1 つのシグニチャに対して照合し、レイヤ 4 転送プロトコルとペイロードを検査します。
このエンジンは、ストリームベースの TCP と、単一の UDP および ICMP パケットを検査します。
(注) Multi String エンジンは、IPS 5.1 からの新機能です。
• Normalizer:IP および TCP の正規化エンジンがどのように機能するかを設定し、IP および TCP の正規化エンジンに関連するシグニチャ イベントの設定を行います。RFC に準拠させることができます。
• Service:特定のプロトコルを処理します。Service エンジンは、次のプロトコル タイプがあります。
–DNS:DNS(TCPおよびUDP)トラフィックを検査します。
–GENERIC:カスタム サービスとペイロードをデコードします。
ネットワーク管理者は、VoIP ネットワークに入力された SETUP メッセージが有効であり、ポリシーの規定範囲内であることを確認できます。また、url-ids、email-ids、および表示情報などのアドレス フィールドや Q.931 文字列フィールドが固有の長さであり、考えられる攻撃パターンは含まれていないことを確認できます。
WEBPORTS 変数が HTTP トラフィックの検査ポートを定義します。
–IDENT:IDENT(クライアントとサーバ)トラフィックを検査します。
–MSSQL:Microsoft SQL トラフィックを検査します。
• State:SMTP などのプロトコル内の文字列をステートフル検索を行います。
State エンジンには現在、非表示の設定ファイルがあります。これは、シグニチャ アップデートで新しい状態定義を配信できるように状態遷移を定義するために使用されます。
• String:ICMP、TCP、または UDP プロトコルに基づいて正規表現文字列を検索します。
String ICMP、String TCP、および String UDP の 3 つの String エンジンがあります。
• Sweep:1 つのホスト(ICMP および TCP)、宛先ポート(TCP および UDP)、および 2 つのノード間で RPC 要求を送受信する複数のポートからのスイープを分析します。
• Traffic ICMP:TFN2K、LOKI、および DDOS など、非標準のプロトコルを分析します。パラメータを設定できるのは 2 つのシグニチャだけです。
• Trojan:BO2K および TFN2K などの非標準のプロトコルからのトラフィックを分析します。
Bo2k、Tfn2k、および UDP の 3 つの Trojan エンジンがあります。これらのエンジンには、ユーザ設定可能なパラメータはありません。
Master エンジンは、その他のエンジンに構造とメソッドを提供し、設定からの入力とアラート出力を処理します。この項では、Master エンジンについて説明します。取り上げる事項は次のとおりです。
次のパラメータは Master エンジンの一部であり、すべてのシグニチャに適用されます。
表B-1 に、Master エンジンの汎用パラメータを示します。
|
|
|
---|---|---|
混合モードでは、混合デルタは特定のアラートの RR より小さくなります。センサーはターゲット システムのアトリビュートを認識しませんが、混合モードではパケットを拒否できないため、混合アラートの優先順位を(優先順位の低いリスク評価より)低く設定しておくと役立ちます。このように設定すると、管理者は優先順位の高いリスク評価アラートの調査に集中できます。
インライン モードでは、センサーが違反パケットを拒否することができます。その場合、違反パケットがターゲット ホストに到達することはないので、ターゲットが脆弱であっても問題になりません。攻撃はネットワーク上で許されなかったため、リスク評価値は下げません。
サービス、OS、およびアプリケーションに固有のもの以外のシグニチャの混合デルタは 0 です。シグニチャが OS、サービス、またはアプリケーションに固有のものである場合は、5、10、または 15 の混合デルタがカテゴリごとに 5 つのポイントから計算されます。
アラート頻度パラメータの目的は、stick などの IDS DoS ツールに対抗するために、イベント ストアに書き込まれるアラートの量を削減することです。Fire All、Fire Once、Summarize、および Global Summarizeの 4 つのモードがあります。サマリー モードは、現在のアラート量に応じて動的に変わります。たとえば、シグニチャを Fire All に設定できますが、一定のしきい値に達すると要約が開始されます。
表B-2 にアラート頻度パラメータを示します。
|
|
|
---|---|---|
次のほとんどのイベント アクションは、特定のエンジンに特化していない限り、各シグニチャに属しています。
表B-3 は、イベント アクションについて説明しています。
|
|
---|---|
(インライン モードのみ)指定された期間、攻撃者アドレスから発信されたこのパケットおよび将来のパケットを送信しません。1 (注) これは、拒否アクションの中で最も重大です。これは、単一の攻撃者アドレスからの現在および将来のパケットを拒否します。拒否された攻撃者のエントリをすべてクリアするには、Monitoring > Denied Attackers > Clear List をクリックします。これによって、これらのアドレスのネットワークへの再接続が許可されます。手順については、「拒否された攻撃者リストの監視」を参照してください。 |
|
(インライン モードのみ)指定された期間、攻撃者アドレスと被害先ポートのペアで、このパケットおよび将来のパケットを送信しません。 |
|
(インライン モードのみ)指定された期間、攻撃者と被害先のアドレスのペアで、このパケットおよび将来のパケットを送信しません。 (注) 拒否アクションの場合、指定された期間と拒否された攻撃者の最大数を指定するには、Configuration > Event Action Rules > General Settings をクリックします。手順については、「一般的な設定値の設定」を参照してください。 |
|
攻撃者アドレスを含む IP ロギング パケットを開始します。 (注) このアクションを実行すると、Produce Alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。 |
|
攻撃者と被害先のアドレスのペアを含む IP ロギング パケットを開始します。 (注) このアクションを実行すると、Produce Alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。 |
|
パケット データを変更して、エンドポイントでパケットがどう処理されるかに関してあいまいな部分を除去します。 (注) Modify Packet Inline は、Add Event Action Filter または Add Event Action Override のオプションではありません。 |
|
(注) このアクションを実行すると、Produce Alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。 |
|
(注) ブロッキング デバイスは、このアクションを実装するよう設定されている必要があります。詳細については、第8章「ブロッキングとレート制限のための ARC の設定」を参照してください。 |
|
この攻撃者ホストをブロックする要求を ARC に送信します。 (注) ブロッキング デバイスは、このアクションを実装するよう設定されている必要があります。詳細については、第8章「ブロッキングとレート制限のための ARC の設定」を参照してください。 (注) ブロック アクションの場合、ブロックの期間を設定するには、Configuration > Event Action Rules > General Settings をクリックします。手順については、「一般的な設定値の設定」を参照してください。 |
|
レート制限を実行するレート制限要求を ARC に送信します。レート制限デバイスは、このアクションを実装するよう設定されている必要があります。詳細については、 第8章「ブロッキングとレート制限のための ARC の設定」 を参照してください。 (注) Request Rate Limit は、選ばれたシグニチャのセットに適用されます。レート制限を要求できるシグニチャのリストについては、「レート制限について」を参照してください。 |
|
SNMP 通知を実行する要求を NotificationApp に送信します。 (注) このアクションを実行すると、Produce Alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。SNMP は、このアクションを実装するようセンサーで設定されている必要があります。詳細については、第9章「SNMP の設定」を参照してください。 |
|
TCP リセットを送信し、TCP フローを乗っ取って終了します。 (注) Reset TCP Connection は、単一の接続を分析する TCP シグニチャでのみ機能します。スイープやフラッドに対しては機能しません。 |
AIC エンジンは、HTTP Web トラフィックを検査し、FTP コマンドを実行します。この項では、AIC エンジンとそのパラメータについて説明します。取り上げる事項は次のとおりです。
• 「概要」
AIC エンジンは、Web トラフィックを詳細に検査するためのシグニチャを定義します。また、FTP コマンドの実行権限を持ちそれを実行するシグニチャも定義します。
AIC HTTP と AIC FTP の 2 つの AIC エンジンがあります。
–転送されるメッセージのコンテンツとデータのタイプに基づくコンテンツ制御
–設定されたポリシーとヘッダーに応じたメッセージ サイズの指定
–トンネリング、P2P およびインスタント メッセージの実施
AIC は Web トラフィックの徹底的な分析を行います。HTTP プロトコルの不正利用を防止するために、HTTP セッションを精密に制御します。これは、インスタント メッセージや、gotomypc など、特定のポート上でトンネリングを試行するアプリケーションに対する管理制御を可能にします。これらのアプリケーションが HTTP を介して稼働している場合は、P2P およびインスタント メッセージの検査とポリシー チェックを実行できます。
AIC は、FTP トラフィックを検査し、発行されるコマンドを制御する方法を提供します。
事前定義されたシグニチャをイネーブルまたはディセーブルにすることもできますし、カスタム シグニチャでポリシーを作成することもできます。
(注) AIC エンジンは、HTTP トラフィックが AIC Web ポートで受信されたときに実行されます。トラフィックが Web トラフィックであっても、AIC Web ポートで受信されない場合は、Service HTTP エンジンが実行されます。AIC 検査は、AIC Web ポートとして設定されている任意のポートで実行できます。検査されるトラフィックは HTTP トラフィックです。
AIC エンジン シグニチャの設定の詳細については、「アプリケーション ポリシーの設定」を参照してください。カスタム AIC シグニチャの例は、「認識済みの定義コンテンツ タイプ(MIME)シグニチャの例」を参照してください。
表B-4 は、AIC HTTP エンジンに固有のパラメータを示しています。
表B-5 は、AIC FTP エンジンに固有のパラメータを示しています。
|
|
---|---|
Atomic エンジンには、アラートの生成を引き起こす単純な単一のパケットの条件に対応するシグニチャが含まれます。この項では、Atomic エンジンについて説明します。取り上げる事項は次のとおりです。
Atomic ARP エンジンは、基本レイヤ 2 ARP シグニチャを定義し、ARP スプーフィング ツールの dsniff および ettercap の高度な検出も実行します。
表B-6 は、Atomic ARP エンジンに固有のパラメータを示しています。
Atomic IP エンジンは、IP プロトコル ヘッダー、および関連付けられたレイヤ 4 転送プロトコル(TCP、UDP、および ICMP)とペイロードを検査するシグニチャを定義します。
(注) Atomic エンジンは複数のパケットにまたがって固定データを保存しません。その代わりに、1 つのパケットの解析からアラートを発生できます。
表B-7 は、Atomic IP エンジンに固有のパラメータを示しています。
|
|
---|---|
Flood エンジンは、複数のパケットを単一のホストまたはネットワークに送信しているホストまたはネットワークを監視するシグニチャを定義します。たとえば、1 秒あたりに(特定タイプの) 150 以上のパケットが被害先のホストに送信されていることを検出した場合に生成されるシグニチャを作成できます。
Flood Host と Flood Net の 2 つの Flood エンジンがあります。
表B-8 は、Flood Host エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 655352 |
||
0 ~ 655353 |
||
0 ~ 655354 |
2.秒あたりのパケットよりもレートが大きくなると、アラートが起動します。 |
表B-9 は、Flood Net エンジン固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 655355 |
||
Meta エンジンは、スライドする時間間隔内で、関連する方法で発生するイベントを定義します。このエンジンは、パケットではなくイベントを処理します。シグニチャ イベントが生成されると、Meta エンジンがそれらを検査して、1 つまたはいくつかの Meta 定義と一致するかどうかを判別します。Meta エンジンは、このイベントに対するすべての要件が満たされた後に、シグニチャ イベントを生成します。
シグニチャ イベントはすべて SEAP によって Meta エンジンに渡されます。SEAP は、minimum hits オプションを処理した後で、イベントを渡します。要約とイベント アクションは、Meta エンジンがコンポーネント イベントを処理した後に処理されます。SEAP の詳細については、 「Signature Event Action Processor」 を参照してください。
表B-10 は、Meta エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
–begin:エントリをアクティブ リストの先頭に配置します。 –end:エントリをアクティブ リストの終わりに配置します。 –inactive:エントリを非アクティブ リストに入れます。 –before:エントリを指定したエントリの前に配置します。 |
||
カスタム Meta エンジン シグニチャの例は、「MEG シグニチャの例」を参照してください。
Multi String エンジンでは、1 つのシグニチャに対して複数の文字列を照合することでレイヤ 4 転送プロトコル(ICMP、TCP、および UDP)のペイロードを検査するシグニチャを定義します。シグニチャを生成するために一致している必要のある一連の正規表現パターンを指定できます。たとえば、UDP サービスで regex 1 とそれに続く regex 2 を検索するシグニチャを定義できます。UDP および TCP の場合は、ポート番号と方向を指定できます。単一の送信元ポート、単一の宛先ポート、または両方のポートを指定できます。文字列の照合は両方の方向で実行されます。
1 つ以上の正規表現パターンを指定する必要がある場合に Multi String エンジンを使用します。それ以外の場合は、String ICMP、String TCP、または String UDP エンジンを使用して、該当するプロトコルに対応した単一の正規表現パターンを指定できます。
表B-11 は、Multi String エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
• spacing-type:前回の一致箇所から、またはそれがリストの最初のエントリの場合はストリームまたはパケットの先頭から空ける必要のあるスペーシングのタイプ。 |
||
• both-ports:送信元ポートと宛先ポートの両方を指定します。 • source-ports:送信元ポートの範囲を指定します。6 |
0 ~ 655357 |
|
この正規表現文字列と直前の正規表現文字列との間、またはそれがリスト内の最初のエントリである場合にはストリームまたはパケットの先頭から空ける必要のある正確なバイト数。 |
||
この正規表現文字列と直前の正規表現文字列との間、またはそれがリスト内の最初のエントリである場合にはストリームまたはパケットの先頭から空ける必要のある最小バイト数。 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
Normalizer エンジンは、IP フラグメンテーションと TCP 正規化を処理します。この項では、Normalizer エンジンについて説明します。取り上げる事項は次のとおりです。
• 「概要」
Normalizer エンジンは、IP フラグメント再構成および TCP ストリーム再構成を処理します。Normalizer エンジンでは、たとえば、センサーが同時に追跡するフラグメントの最大数など、システム リソースの使用状況に関する制限を設定できます。
(注) Normalizer エンジンに、カスタム シグニチャを追加することはできません。既存のシグニチャはチューニングできます。
意図的または意図しない IP データグラムのフラグメンテーションは、不正利用を隠し、それらの検出を困難または不可能にしてしまうことがあります。フラグメント化は、ファイアウォールやルータにあるようなアクセス コントロール ポリシーを回避するために使用することもできます。また、さまざまなオペレーティング システムがさまざまなメソッドを使用して、フラグメント化されたデータグラムをキューに入れたり送出したりします。センサーがエンド ホストでデータグラムを再構成するために考えられる方法をすべてチェックする必要がある場合は、センサーが DoS 攻撃(サービス拒絶攻撃)を受ける可能性があります。フラグメント化されたデータグラムをすべてインラインで再構成し、完全なデータグラムだけを転送し、必要に応じてそのデータグラムを再度フラグメント化すれば、これを防ぐことができます。IP フラグメント化の正規化の装置は、この機能を実行します。
意図的または意図しない TCP セッション セグメンテーションによって、いくつかの攻撃クラスが非表示になることもあります。ポリシーが false positive や false negative なしに実施されるようにするには、2 つの TCP エンドポイントの状態が追跡され、実際のホスト エンドポイントによって処理されたデータだけが渡される必要があります。TCP ストリームで重複が発生する可能性がありますが、TCP セグメントの再転送以外は、非常にまれです。TCP セッションでの上書きは発生しません。上書きが発生する場合は、誰かがセキュリティ ポリシーを意図的に回避しようとしているか、TCP スタックの実装が破損しています。センサーが TCP プロキシとして動作していない限り、両方のエンドポイントの状態について完全な情報を保持することはできません。センサーが TCP プロキシとして動作する代わりに、セグメントが適切に並べられ、正規化エンジンによって回避や攻撃に関係する異常なパケットが検索されます。
混合モードのセンサーは、違反を検出するとアラートを報告します。インライン モードのセンサーは、produce-alert、deny-packet-inline、modify-packet-inline などの event-action パラメータに指定したアクションを実行します。
Normalizer エンジンでシグニチャを設定する手順については、「IP フラグメント再構成の設定」および 「TCP ストリーム再構成の設定」を参照してください。
表B-12 は、Normalizer エンジンに固有のパラメータを示しています。
|
|
---|---|
Service エンジンは、2 つのホスト間で L5+ トラフィックを解析します。これらは、固定データを追跡する 1 対 1 シグニチャです。このエンジンは、ライブ サービスに似た方法で L5+ ペイロードを解析します。
Service エンジンには共通の特性があります。ただし、各エンジンには、検査対象のサービスに関する固有の情報があります。Service エンジンは、文字列エンジンの使用が不適切または望ましくない場合に、アルゴリズム向けの汎用文字列エンジンの機能を補足します。
Service DNS エンジンは高度な DNS デコード専用です。これには次の複数のジャンプのような反回避技術が含まれています。長さ、命令コード、文字列などの多数のパラメータがあります。Service DNS エンジンは、TCP ポート 53 と UDP ポート 53 の両方で稼働し、2 つのプロトコルに対応するインスペクタです。TCP ではストリーム、UDP ではクワッドが使用されます。
表B-13 は、Service DNS エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
Service FTP エンジンは、FTP ポートのコマンド デコード専用です。無効な port コマンドと PASV ポート スプーフィングをトラップします。これは、String エンジンが検出に適さない場合のギャップを埋めます。パラメータは、 port コマンドのデコードで、さまざまなエラー トラップ条件に割り当てられるブール値です。Service FTP エンジンは TCP ポート 20 および 21 で稼働します。ポート 20 はデータ用で、Service FTP エンジンはこのポートを検査しません。ポート 21 の制御トランザクションを検査します。
表B-14 は、Service FTP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 655358 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
Service Generic エンジンでは、設定ファイルのみのシグニチャ アップデートで、プログラム シグニチャを発行できます。設定ファイルで定義された簡易マシンおよびアセンブリ言語を持っています。仮想マシンを通じて(アセンブリ言語から導出された)マシン コードを実行します。仮想マシンは、命令を処理し、パケットから重要な情報を引き出して、マシン コードで指定された比較および演算を実行します。
これは、String エンジンと State エンジンを補足する迅速なシグニチャ応答エンジンとして設計されています。
(注) カスタム シグニチャを作成するために、Service Generic エンジンを使用することはできません。
表B-15 は、Service Generic エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
この項では、Service H225 エンジンについて説明します。取り上げる事項は次のとおりです。
• 「概要」
Service H225 エンジンは、H225.0 プロトコルを分析します。このプロトコルは、多数のサブプロトコルから構成されており、H.323 スイートの一部です。H.323 は、パケットベースのネットワーク上での会議開催を実現するために連携して動作する複数のプロトコルとその他の標準の集まりです。
H.225.0 コール シグナリングとステータス メッセージは、H.323 コール セットアップの一部です。ゲートキーパーやエンドポイント端末などのネットワーク内のさまざまな H.323 エンティティが、H.225.0 プロトコル スタックの実装を稼働しています。Service H225 エンジンは、H.255.0 プロトコルを分析して、複数の H.323 ゲートキーパー、VoIP ゲートウェイ、およびエンドポイント端末への攻撃を検出します。また、TCP PDU を介して交換されるコール シグナリング メッセージについてパケットを詳細に検査します。さらに、Service H225 エンジンは H.225.0 プロトコルを分析することで、無効な H.255.0 メッセージ、およびこれらのメッセージのさまざまなプロトコル フィールドの悪用やそれらに対するオーバーフロー攻撃を検出します。
H.225.0 コール シグナリング メッセージは Q.931 プロトコルに基づいています。発信側エンドポイントは、Q.931 SETUP メッセージを着信側となるエンドポイントに送信します。着信側エンドポイントのアドレスは、許可手順またはいくつかのルックアップ手法を通じて取得します。着信側エンドポイントは、Q.931 CONNECT メッセージを送信して接続を受け入れるか、または接続を拒否します。H.225.0 接続が確立されると、発信側エンドポイントまたは着信側エンドポイントのどちらかが H.245 アドレスを提供します。このアドレスは、制御プロトコル(H.245)チャネルの確立に使用されます。
SETUP コール シグナリング メッセージは特に重要です。これが、コール セットアップの一部として H.323 エンティティ間で交換される最初のメッセージとなるからです。SETUP メッセージはコール シグナリング メッセージでよく見られるフィールドの多くを使用しており、攻撃に晒される可能性のある実装ではほとんど SETUP メッセージのセキュリティ チェックに失敗します。そのため、H.225.0 SETUP メッセージの妥当性をチェックし、ネットワーク境界に対してもチェックを実施することが非常に重要となります。
Service H225エンジンには、H225 SETUP メッセージのTPKT 検証、Q.931 プロトコル検証、および ASN.1PER 検証を実行するためのシグニチャが組み込まれています。ASN.1 は、データ構造を記述するための表記法です。PER は異なる形式の符号化を使用します。PER は、データ タイプに基づいて符号化し、よりコンパクトな表現を生成することに特化しています。
Q.931 および TPKT 長さシグニチャをチューニングし、より細分化されたシグニチャを特定の H.225 プロトコル フィールドに追加および適用し、Q.931 または H.225 プロトコルの単一のフィールドに複数のパターン検索シグニチャを適用できます。
Service H225 エンジンは、次の機能をサポートします。
• Q.931 情報要素のテキスト フィールドの正規表現シグニチャ
• ULR-ID、E-mail-ID、h323-id などのフィールドの正規表現と長さの両方に対応する設定シグニチャ
TPKT および ASN.1 シグニチャの数は固定です。これらのタイプのカスタム シグニチャは作成できません。TPKT シグニチャの場合は、長さシグニチャの値範囲のみ変更する必要があります。ASN.1 の場合、パラメータは一切変更しないでください。Q.931 シグニチャでは、テキスト フィールドの新しい正規表現シグニチャを追加できます。SETUP シグニチャの場合は、各種の SETUP メッセージ フィールドの長さおよび正規表現をチェックするためのシグニチャを追加できます。
表B-16 は、Service H225 エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
(オプション)使用するフィールド名をイネーブルにします。SETUP および Q.931 メッセージ タイプの場合のみ有効です。シグニチャを適用するフィールド名のドット付き表記を指定します。 |
||
(オプション)ASN と TPKT 固有のエラー、および固定マッピングを持つその他のエラーで使用する無効なパケット索引をイネーブルにします。 |
||
ポリシー タイプが regex の場合に検索する正規表現。TPKT シグニチャには設定しないでください。 • (オプション)使用する最小一致長をイネーブルにします。一致と見なされるために必要な正規表現の最小一致長。TPKT シグニチャには設定しないでください。 |
||
length または value ポリシー タイプの場合に有効です(0x00 ~ 6535)。その他のポリシー タイプの場合は無効です。 |
0 ~ 655359 |
この項では、Service HTTP エンジンについて説明します。取り上げる事項は次のとおりです。
• 「概要」
Service HTTP エンジンは、サービス固有で文字列ベースのパターン マッチング検査エンジンです。HTTP プロトコルは、今日のネットワークで最もよく使用されているプロトコルです。また、これには最も長い事前処理時間が必要であり、検査を必要とする最大数のシグニチャを持つため、システムのパフォーマンス全体にとって重大となります。
Service HTTP エンジンは、複数のパターンを結合して単一のパターン マッチング テーブルにし、単一のデータ検索を可能にする、正規表現ライブラリを使用します。このエンジンは、Web サービスだけに送られるトラフィック、または HTTP 要求を検索します。このエンジンでリターン トラフィックを検査することはできません。このエンジンの各シグニチャで、該当する個別の Web ポートを指定できます。
HTTP 解読は、符号化された文字を ASCII 対応文字に正規化することによって、HTTP メッセージをデコードするプロセスです。これは、ASCII 正規化とも呼ばれます。
HTTP パケットを検査するには、まずデータを、ターゲット システムでデータの処理時に表示されるものと同じ表記に解読または正規化する必要があります。どのオペレーティング システムおよび Web サーバ バージョンがターゲットで動作しているかを認識している、カスタマイズされたデコード技術をホスト ターゲット タイプごとに用意することを推奨します。Service HTTP エンジンには、Microsoft IIS Web サーバに対するデフォルトの解読動作があります。
Service HTTP のカスタム シグニチャの例は、「Service HTTP シグニチャの例」を参照してください。
表B-17 は、 Service HTTP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
(オプション)特定の正規表現の引数フィールドの検索をイネーブルにします。 • arg-name-regex:HTTP 引数フィールド(Content-Length で定義されているとおり、? の後ろのエンティティ本体の中)で検索する正規表現 |
||
(オプション)特定の正規表現のヘッダー フィールドの検索をイネーブルにします。 • header-regex:HTTP ヘッダー フィールドで検索する正規表現。ヘッダーは、最初の CRLF の後ろから定義され、CRLFCRLF まで続きます。 |
||
(オプション)特定の正規表現の要求フィールドの検索をイネーブルにします。 |
||
(オプション)HTTP URI フィールドで検索する正規表現。URI フィールドは、HTTP メソッド(たとえば、GET)の後ろで、最初の CRLF の前まで定義されます。正規表現は保護されています。つまり、値は変更できません。 |
[/\\][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][.]jpeg |
|
0 ~ 6553510 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
Service IDENT エンジンは、TCP ポート 113 のトラフィックを検査します。基本デコードと、長さのオーバーフローを指定するパラメータを提供します。
表B-18 は、Service IDENT エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 6553511 |
||
この項では、Service MSRPC エンジンについて説明します。取り上げる事項は次のとおりです。
• 「概要」
Service MSRPC エンジンは、MSRPC パケットを処理します。MSRPC によって、ネットワーク環境内の複数のコンポーネントとそれらのアプリケーション ソフトウェアとの間の連携処理が可能になります。これは、トランザクションベースのプロトコルです。つまり、チャネルを確立するために一連の通信が行われ、処理要求と応答が渡されます。
MSRPC は、ISO レイヤ 5 ~ 6 プロトコルで、UDP、TCP、SMB などのその他の転送プロトコルの上層にあたります。MSRPC エンジンには、MSRPC PDU のフラグメンテーションと再構成に対応したファシリティが組み込まれています。
この通信チャネルが、最近の Windows NT、Windows 2000、および Window XP のセキュリティ上の弱点の原因です。
Service MSRPC エンジンは、最も一般的なトランザクション タイプに対応し DCE および RPC プロトコルだけをデコードします。
表B-19 は、Service MSRPC エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
• operation:要求された MSRPC 動作。SMB_COM_TRANSACTION コマンドに必要です。完全一致。 |
||
• specify-exact-match-offset:完全一致オフセットをイネーブルにします。 –exact-match-offset:一致を有効にするために正規表現文字列が報告する必要のある実際のストリーム オフセット。 |
||
Service MSSQL エンジンは、Microsoft の SQL server (MSSQL)によって使用されるプロトコルを検査します。
1 つの MSSQL シグニチャがあります。デフォルトの sa アカウントを使用した MSSQL へのログイン試行を検出すると、アラートを生成します。
ログイン ユーザ名や、パスワードが使用されたかどうかなどの MSSQL プロトコル値に基づいてカスタム シグニチャを追加できます。
表B-20 は、Service MSSQL エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
Service NTP エンジンは、NTP プロトコルを検査します。1 つの NTP シグニチャ(NTPd readvar オーバーフロー シグニチャ)があります。これは、readvar コマンドに NTP サービスが取り込むには大き過ぎる NTP データが指定されていることを検出した場合にアラートを生成します。
モードや制御パケットのサイズなどの NTP プロトコルの値に基づいて、シグニチャのチューニングやカスタム シグニチャの作成を行えます。
表B-21 は、Service NTP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
• control-opcode:RFC1305、付録 B に基づく NTP 制御パケットの命令コード番号 |
||
Service RPC エンジンは、RPC プロトコル専用で、反回避方式としてフル デコードが含まれています。この方式によって、断片化メッセージ(複数のパケット内の 1 つのメッセージ)およびバッチ メッセージ(1 つのパケット内の複数のメッセージ)を処理できます。
RPC ポートマッパーは、ポート 111 で動作します。正規の RPC メッセージは番号が 551 以上の任意のポートでやり取りできます。RPC スイープは、有効な RPC メッセージが送信されたときに一意のポートだけをカウントする点を除けば、TCP ポート スイープと同様です。RPC は UDP 上でも稼働します。
表B-22 は、Service RPC エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 6553512 |
||
Service SMB エンジンは、SMB パケットを検査します。SMB 制御トランザクション交換および SMB NT_Create_AndX 交換に基づいて、SMB シグニチャのチューニングやカスタム SMB シグニチャの作成を行えます。
表B-23 は、Service SMB エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 65535 |
||
(オプション)MSRPC 割り当てのヒントをイネーブルにします。 • allocation-hint:MSRPC 割り当てヒント。SMB_COM_TRANSACTION コマンドの解析で使用されます。14 |
||
• byte-count:SMB_COM_TRANSACTION 構造からのバイト カウント15 |
||
• command:SMB コマンド値16 |
||
(オプション)トランザクション ファイル ID の使用をイネーブルにします。 • file-id:トランザクション ファイル ID17 (注) このパラメータはシグニチャを特定の不正利用インスタンスだけに制限することがあるため、使用する場合は慎重に検討する必要があります。 |
||
• function:名前付きパイプ機能18 |
||
• hit-count:スキャン間隔の間の発生数のしきい値。この値を超えるとアラートを生成します。19 |
||
• operation:要求された MSRPC 動作。SMB_COM_TRANSACTION コマンドに必要です。完全一致は必須です。 |
||
• resource:アラートを制限するために使用するパイプまたは SMB ファイル名を指定します。ASCII 形式です。完全一致は必須です。 |
||
• scan-interval:アラート率を計算するために使用する間隔(秒単位)20 |
||
(オプション)セットアップ ワードのカウントをイネーブルにします。 • set-count:セットアップ ワードの数21 |
||
(オプション)MSRPC パケットのタイプ フィールドの検索をイネーブルにします。 • type:MSRPC パケットのタイプ フィールド。0 = Request、2 = Response、11 = Bind、12 = Bind Ack |
||
(オプション)コマンド パラメータのワード カウントをイネーブルにします。 • word-count:SMB_COM_TRANSACTION コマンド パラメータのワード カウント22 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
Service SNMP エンジンは、ポート 161 宛てのすべての SNMP パケットを検査します。特定のコミュニティ名とオブジェクト ID に基づいて、SNMP シグニチャのチューニングやカスタム SNMP シグニチャの作成を行えます。
コミュニティ名とオブジェクト ID を照合するために、文字列比較や正規表現演算を使用する代わりに、整数を使用してすべての比較を実行し、プロトコル デコードを高速化しストレージ要件を削減します。
表B-24 は、Service SNMP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
• specify-community-name [yes | no]: –community-name:SNMP コミュニティ名、つまり SNMP パスワードを検索します。 |
Service SSH エンジンはポート 22 の SSH トラフィック専用です。SSH セッションのセットアップを除いてすべてが暗号化されるため、エンジンはセットアップのフィールドのみを監視します。SSH には 2 つのデフォルト シグニチャがあります。これらのシグニチャはチューニングできますが、カスタム シグニチャは作成できません。
表B-25 は、Service SSH エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 6553523 |
||
State エンジンは、TCP ストリームに対して状態ベースで、正規表現ベースのパターン検査を行います。State エンジンとは、何らかの状態を保存するデバイスで、特定の時に入力に基づいて 1 つの状態から別の状態に移行したり、処理または出力を発生させることができます。ステート マシンは、出力またはアラームの原因となる特定のイベントを記述するために使用します。
State エンジンには、SMTP、Cisco Login、および LPR Format String の 3 つのステート マシンがあります。
表B-26 は、State エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
LPR Format String の弱点を検査するステート マシンを指定します。 • state-name:シグニチャがアラートを起動する前に必要な状態の名前。 |
||
• state-name:シグニチャがアラートを起動する前に必要な状態の名前。 |
||
0 ~ 65535 |
||
• exact-match-offset:一致を有効にするために正規表現文字列が報告する必要のある実際のストリーム オフセット。 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
この項では、String エンジンについて説明します。取り上げる事項は次のとおりです。
• 「概要」
String エンジンは、ICMP、TCP、および UDP の各プロトコル用の汎用のパターン マッチング検査エンジンです。String エンジンは、複数のパターンを結合して単一のパターン マッチング テーブルにし、単一のデータ検索を可能にする、正規表現エンジンを使用します。
String ICMP、String TCP、および String UDP の 3 つの String エンジンがあります。
カスタム String エンジン シグニチャの例は、「String TCP シグニチャの例」を参照してください。
表B-27 は、String ICMP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 1825 |
||
• exact-match-offset:一致を有効にするために正規表現文字列が報告する必要のある実際のストリーム オフセット。 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
カスタム String エンジン シグニチャの例は、「String TCP シグニチャの例」を参照してください。
表B-28 は、String TCP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 6553526 |
||
• exact-match-offset:一致を有効にするために正規表現文字列が報告する必要のある実際のストリーム オフセット。 |
||
パターンを検索する前に、データから Telnet オプション文字を削除します。27 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
カスタム String エンジン シグニチャの例は、「String TCP シグニチャの例」を参照してください。
表B-29 は、String UDP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
0 ~ 6553528 |
||
• exact-match-offset:一致を有効にするために正規表現文字列が報告する必要のある実際のストリーム オフセット。 |
||
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
Sweep エンジンは、2 つのホスト間または 1 つのホストから多数のホストへのトラフィックを解析します。既存のシグニチャをチューニングするか、またはカスタム シグニチャを作成できます。Sweep エンジンには、ICMP、UDP、および TCP のプロトコル固有のパラメータがあります。
Sweep エンジンのアラート条件は、根本的に一意のパラメータのカウントに基づいています。一意のパラメータとは、スイープのタイプに応じて明確に特定されたホスト数またはポート数のしきい値です。一意のパラメータは、一定の間隔内にアドレス セット上で一意の数を超えるポートまたはホストが検出された場合に、アラームをトリガーします。一意のポートおよびホスト トラッキング処理はカウンティングと呼ばれます。
一意のパラメータは、Sweep エンジンのすべてのシグニチャに対して指定する必要があります。スイープに適用される制限は 2 ~ 40(包含)です。2 はスイープの絶対最小数です。2 未満の場合は、スイープではありません(1 つのホストまたはポート)。40 は実際の最大値で、スイープが過剰にメモリを消費しないように適用する必要があります。さらに現実的な一意の値範囲は、5 ~ 15 です。
TCP スイープには、どのスイープ インスペクタ スロットで特定の接続をカウントするか決定するために、TCP フラグとマスクを指定する必要があります。
ICMP スイープでは、さまざまなタイプの ICMP パケットを識別するために、ICMP タイプを指定する必要があります。
表B-30 は、Sweep エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
アドレス(およびポート)の送信元と宛先がアラート メッセージでスワップされる場合は、true。スワップされない場合は false(デフォルト)。 |
||
Traffic ICMP エンジンは、TFN2K、LOKI、および DDOS などの非標準プロトコルを解析します。ユーザ設定可能なパラメータを持つ 2 つのシグニチャ(LOKI プロトコルに基づく)のみがあります
Tribe Flood Net 2000(TFN2K)は比較的新しいバージョンの TFN です。これは感染したコンピュータ(ゾンビ)による調整された攻撃を制御して、無数の未確認の攻撃ホストから偽のトラフィック フラッドで 1 つのコンピュータ(またはドメイン)をターゲットとするために使用される Distributed DOS(DDoS)エージェントです。TFN2K はランダムに抽出されたパケット ヘッダー情報を送信しますが、それにはシグニチャの定義に使用できる 2 つの識別子が付いています。1 つは L3 チェックサムが不正かどうかを示し、もう 1 つはペイロードの末尾にキャラクタ 64「A」が検出されたかどうかを示しています。TFN2K は、任意のポートで実行可能で、ICMP、TCP、UDP、またはこれらのプロトコルの組み合せで通信できます。
LOKI は、バック ドア型トロイの木馬タイプです。コンピュータが感染すると、悪意のあるコードが ICMP 応答で小さなペイロードを送信するために使用できる「ICMP トンネル」を作成します(ICMP をブロックするように設定していない場合、この応答はファイアウォールを通過できます)。LOKI シグニチャは、応答に対する ICMP エコー要求のアンバランス、簡易 ICMP コードおよびペイロード識別子を監視します。
(TFN2K を除く)DDOS カテゴリは、ICMP ベースの DDOS エージェントを対象とします。ここで使用する主なツールは、TFN(Tribe Flood Net)と Stacheldraht です。これらは TFN2K と同様に動作しますが、ICMP のみに依存し、固定コマンド(整数および文字列)があります。
表B-31 は、Traffic ICMP エンジンに固有のパラメータを示しています。
|
|
|
---|---|---|
Trojan エンジンは、BO2K および TFN2K などの非標準プロトコルを解析します。Trojan BO2K、Trojan TFN2K、および Trojan UDP の 3 つの Trojan エンジンがあります。
BackOrifice(BO)は、UDP 上でのみ実行された最初の Windows のバック ドア型トロイの木馬でした。すぐに BackOrifice 2000(BO2K)がそれに取って代わりました。BO2K は、基本的な XOR 暗号化された UDP および TCP の両方に対応しています。それらには、特定のクロスパケット特性を持つプレーンな BO ヘッダーがあります。
また、BO2K には、BO ヘッダーを暗号化し、ほとんど認知できないクロスパケット パターンを作成するように設計された隠れた TCP モジュールもあります。
UDP モードの BO および BO2K は、Trojan UDP エンジンによって処理されます。TCP モードは Trojan BO2K エンジンによって処理されます。
Trojan UDP エンジンの swap-attacker-victimngine を除き、Trojan エンジンに固有のパラメータはありません。