Cisco ASA with FirePOWER Services ローカル管理設定ガ イ ド 6.0

ルール アクションの指定

ライセンス： Protection

各ルール ヘッダーには、パケットがルールをトリガーとして使用したときにシステムで行われるアクションを指定するパラメータが 1 つ含まれています。アクションが alert に設定されたルールは、それをトリガーとして使用したパケットに関する侵入イベントを生成し、そのパケットの詳細をログに記録します。アクションが pass に設定されたルールは、それをトリガーとして使用したパケットに関するイベントを生成せず、そのパケットの詳細も記録しません。

（注） インライン展開において、ルール状態が [ドロップしてイベントを生成する（Drop and Generate Events）] に設定されたルールは、それをトリガーとして使用したパケットに関する侵入イベントを生成します。また、パッシブ展開で廃棄ルールを適用した場合は、ルールがアラート ルールとして機能します。廃棄ルールの詳細については、ルール状態の設定を参照してください。

デフォルトでは、パス ルールがアラート ルールをオーバーライドします。パス ルールを作成することで、アラート ルールを無効にする代わりに、パス ルールで定義された基準を満たすパケットが特定の状況でアラート ルールをトリガーとして使用しないことを指定できます。たとえば、ユーザ "anonymous" として FTP サーバにログインする試行を検索するルールをアクティブのままにする必要があるとします。ただし、1 つ以上の正式な匿名 FTP サーバがネットワークに存在する場合、そのような特定のサーバで匿名ユーザにより最初のルールがトリガーとして使用されないことを指定するパス ルールを作成し、アクティブにすることができます。

ルール エディタで、[アクション（Action）] リストからルール タイプを選択します。ルール エディタを使ってルール ヘッダーを作成する手順の詳細については、ルールの構築を参照してください。

プロトコルの指定

ライセンス： Protection

各ルール ヘッダーで、ルールにより検査されるトラフィックのプロトコルを指定する必要があります。次のネットワーク プロトコルを分析対象として指定できます。

• ICMP（Internet Control Message Protocol）
• インターネット プロトコル（IP）

（注） プロトコルが ip に設定されている場合、システムは侵入ルール ヘッダー内のポート定義を無視します。詳細については、侵入ルールでのポートの定義を参照してください。

• 伝送制御プロトコル（TCP）
• ユーザ データグラム プロトコル（UDP）

TCP、UDP、ICMP、IGMP など、IANA によって割り当てられたすべてのプロトコルを検査するには、プロトコル タイプとして IP を使用します。IANA によって割り当てられたプロトコルの完全なリストについては、 http://www.iana.org/assignments/protocol-numbers を参照してください。

（注） 現在のところ、IP ペイロード内の次のヘッダー（TCP ヘッダーなど）でパターンを照合するルールを作成することはできません。代わりに、最後にデコードされたプロトコルからコンテンツ照合が始まります。次善策として、ルール オプションを使用して TCP ヘッダー内のパターンを照合できます。

ルール エディタで、[プロトコル（Protocol）] リストからプロトコル タイプを選択します。ルール エディタを使用してルール ヘッダーを作成する手順の詳細については、ルールの構築を参照してください。

侵入ルールでの IP アドレスの指定

ライセンス： Protection

パケット検査の対象を、特定の IP アドレスから発信されたパケットまたは特定の IP アドレスに向かうパケットに制限すると、システムが実行しなければならないパケット検査の量が減ります。さらに、ルールをより具体化し、送信元および宛先 IP アドレスが疑わしい動作を示していないパケットに対してルールがトリガーとして使用される可能性をなくすと、誤検出も減ります。

ヒント システムは IP アドレスのみを認識し、送信元/宛先 IP アドレスのホスト名を受け入れません。

ルール エディタの [Source IPs] フィールドと [Destination IPs] フィールドで、送信元および宛先の IP アドレスを指定します。ルール エディタを使用してルール ヘッダーを作成する手順の詳細については、ルールの構築を参照してください。

標準テキスト ルール の作成時には、必要に応じて、さまざまな方法で IPv4 アドレスと IPv6 アドレスを指定できます。単一の IP アドレス、 any 、IP アドレス リスト、CIDR 表記、プレフィクス長、ネットワーク変数、またはネットワーク オブジェクトあるいはネットワーク オブジェクト グループを指定できます。加えて、1 つの特定の IP アドレスまたは IP アドレスのセットを除外するよう指定できます。IPv6 アドレスを指定するときには、RFC 4291 で定義された任意のアドレス指定規則を使用できます。

次の表では、送信元と宛先の IP アドレスを指定するさまざまな方法を要約します。

送信元および宛先の IP アドレスを指定するために使用可能な構文の詳細と、変数を使って IP アドレスを指定する方法については、以下の項を参照してください。

• IP アドレスの表記規則。
• 変数セットの使用
• 任意の IP アドレスの指定
• 複数の IP アドレスの指定
• ネットワーク オブジェクトの指定
• 侵入ルールで IP アドレスを除外する

任意の IP アドレスの指定

ライセンス： Protection

任意の IPv4 または IPv6 アドレスを示す「 any 」という単語を、ルールの送信元 IP アドレスまたは宛先 IP アドレスとして指定できます。

たとえば、次のルールでは [Source IPs] フィールドと [Destination IPs] フィールドで引数 any を使用して、任意の IPv4 または IPv6 の送信元または宛先アドレスを持つパケットを評価します。

また、任意の IPv6 アドレスを示すために :: を指定することもできます。

複数の IP アドレスの指定

ライセンス： Protection

次の例に示すように、カンマを使って複数の IP アドレスを区切り、オプションで、非拒否リストを大カッコで囲むことにより、個別の IP アドレスを列挙できます。

IPv4 アドレスと IPv6 アドレスのいずれかだけを列挙することも、任意に組み合わせて列挙することもできます（次の例を参照）。

以前のソフトウェア リリースでは IP アドレス リストを大カッコで囲む必要がありましたが、現在ではこれが必須でないことに注意してください。また、オプションで、リストを入力するときに各カンマの前または後にスペースを含めることができます。

（注） 否定リストは、大カッコで囲む必要があります。詳細については、侵入ルールで IP アドレスを除外するを参照してください。

また、IPv4 クラスレス ドメイン間ルーティング（CIDR）表記または IPv6 プレフィクス長を使用してアドレス ブロックを指定することもできます。次に例を示します。

• 192.168.1.0/24 は、サブネット マスク 255.255.255.0 の 192.168.1.0 ネットワーク内の IPv4 アドレス、つまり 192.168.1.0 ～ 192.168.1.255 を指定します。詳細については、IP アドレスの表記規則を参照してください。
• 2001:db8::/32 は、プレフィクス長 32 ビットの 2001:db8:: ネットワーク内の IPv6 アドレス、つまり 2001:db8:: ～ 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff を指定します。

ヒント IP アドレスのブロックを指定する必要があるが、CIDR またはプレフィクス長表記を単独で使ってそれを表現できない場合は、1 つの IP アドレス リスト内でいくつかの CIDR ブロックとプレフィクス長を使用できます。

ネットワーク オブジェクトの指定

ライセンス： Protection

次の構文を使用して、ネットワーク オブジェクトまたはネットワーク オブジェクト グループを指定できます。

引数の説明

• object_name はネットワーク オブジェクトの名前です
• group_name はネットワーク オブジェクト グループの名前です

ネットワーク オブジェクトとネットワーク オブジェクト グループの作成方法については、ネットワーク オブジェクトの操作を参照してください。

192.168sub16 という名前のネットワーク オブジェクトと all_subnets という名前のネットワーク オブジェクト グループをすでに作成済みであるとします。ネットワーク オブジェクトを使用して IP アドレスを特定するには、たとえば次のように指定できます。

ネットワーク オブジェクト グループを使用するには、次のように指定できます。

さらに、ネットワーク オブジェクトとネットワーク オブジェクト グループで否定を使用することもできます。次に例を示します。

詳細については、侵入ルールで IP アドレスを除外するを参照してください。

侵入ルールで IP アドレスを除外する

ライセンス： Protection

感嘆符（ ! ）を使用すると、指定した IP アドレスを否定できます。つまり、1 つ以上の特定の IP アドレスを除く、すべての IP アドレスに一致させることができます。たとえば、 !192.168.1.1 は、192.168.1.1 以外の任意の IP アドレスを指定し、 !2001:db8:ca2e::fa4c は、2001:db8:ca2e::fa4c 以外の任意の IP アドレスを指定します。

IP アドレスのリストを否定するには、 ! を大カッコで囲んだ IP アドレスのリストの前に置きます。たとえば、 ![192.168.1.1,192.168.1.5] は、192.168.1.1 または 192.168.1.5 を除く任意の IP アドレスを定義します。

（注） IP アドレスのリストを否定するには、大カッコを使用する必要があります。

否定文字と一緒に IP アドレス リストを使用する場合は注意が必要です。たとえば、 [!192.168.1.1,!192.168.1.5] を使用して 192.168.1.1 と 192.168.1.5 を除く任意のアドレスに一致させると、システムはこの構文を「192.168.1.1 以外のすべて、 または 192.168.1.5 以外のすべて」と解釈します。

192.168.1.5 は 192.168.1.1 ではなく、192.168.1.1 は 192.168.1.5 ではないため、この両方の IP アドレスが [!192.168.1.1,!192.168.1.5] という IP アドレス値に一致します。つまり、実質的に「 any 」を使用するのと同じです。

代わりに、 ![192.168.1.1,192.168.1.5] を使用してください。システムはこの構文を「 192.168.1.1 でなく 、しかも 192.168.1.5 でない」と解釈し、大カッコ内に列挙されたものを除くすべての IP アドレスに一致します。

論理的に言って、 any と一緒に否定を使用できないことに注意してください。any を否定すると「アドレスなし」を意味することになります。

侵入ルールでのポートの定義

ライセンス： Protection

ルール エディタの [Source Port] フィールドと [Destination Port] フィールドで、送信元および宛先ポートを指定します。ルール エディタを使用してルール ヘッダーを作成する手順の詳細については、ルールの構築を参照してください。

ルール ヘッダー内で使われるポート番号を定義するために、ASA FirePOWER モジュールは特殊なタイプの構文を使用します。

（注） プロトコルが ip に設定されている場合、システムは侵入ルール ヘッダー内のポート定義を無視します。詳細については、プロトコルの指定を参照してください。

次の例に示すように、カンマでポートを区切ることによって、ポートのリストを指定できます。

オプションで、次の例に示すように、ポート リストを大カッコで囲むこともできます（以前のソフトウェア バージョンではこれが必須でしたが、現在は必須ではありません）。

なお、次の例に示すように、ポート リストの否定を大カッコで囲む 必要がある ことに注意してください。

また、侵入ルール内の送信元ポートや宛先ポートのリストには最大で 64 文字を含めることができます。

次の表に、使用可能な構文を要約します。

方向の指定

ライセンス： Protection

ルールによる検査対象となるパケットが進むべき方向を、ルール ヘッダー内で指定できます。以下の表は、それらのオプションを示しています。

ルール エディタを使用してルール ヘッダーを作成する手順の詳細については、ルールの構築を参照してください。

侵入イベント詳細の定義

ライセンス： Protection

標準テキスト ルール を作成するときには、ルールで攻撃試行を検出する対象となる脆弱性についてのコンテキスト情報を含めることができます。また、脆弱性データベースへの外部参照を含めたり、組織内でイベントに設定するプライオリティを定義したりすることもできます。アナリストがイベントを認識すると、そのプライオリティ、エクスプロイト、および既知の対策についての情報をすぐに入手できます。

イベント関連のキーワードに関する詳細は、以下の項を参照してください。

• イベント メッセージの定義
• イベント プライオリティの定義
• 侵入イベント分類の定義
• イベント参照の定義

イベント メッセージの定義

ライセンス： Protection

ルールのトリガー時にメッセージとして表示される、意味のあるテキストを指定できます。メッセージを読むと、ルールで攻撃試行を検出する対象となった脆弱性の特性をすぐに理解できます。中カッコ（ {} ）を除く、印字可能な任意の標準 ASCII 文字を使用できます。システムは、メッセージ全体を囲んでいる引用符を取り除きます。

ヒント ルール メッセージの指定は必須です。また、空白文字のみ、1 つ以上の引用符のみ、1 つ以上のアポストロフィのみ、あるいは空白文字/引用符/アポストロフィだけの組み合わせでメッセージを構成することはできません。

ルール エディタでイベント メッセージを定義するには、[メッセージ（Message）] フィールドにイベント メッセージを入力します。ルール エディタを使用してルールを作成する方法については、ルールの構築を参照してください。

イベント プライオリティの定義

ライセンス： Protection

デフォルトでは、ルールのイベント分類からルールのプライオリティが派生します。ただし、 priority キーワードをルールに追加すると、ルールの分類プライオリティをオーバーライドできます。

ルール エディタを使ってプライオリティを指定するには、[検出オプション（Detection Options）] リストから [priority] を選択して、ドロップダウンリストから [high]、[medium]、または [low] を選択します。たとえば、Web アプリケーション攻撃を検出するルールに high プライオリティを割り当てるには、 priority キーワードをルールに追加して、プライオリティとして [high] を選択します。ルール エディタを使用してルールを作成する方法については、ルールの構築を参照してください。

侵入イベント分類の定義

ライセンス： Protection

ルールごとに、イベントのパケット表示に含める攻撃分類を指定できます。次の表に、それぞれの分類の名前と番号を示します。

ルール エディタで分類を指定するには、[分類（Classification）] リストから分類を 1 つ選択します。ルール エディタの詳細については、新しいルールの作成を参照してください。

カスタム分類の追加

ライセンス： Protection

定義したルールによって生成されるイベントのパケット表示記述の内容をもっとカスタマイズする必要がある場合には、カスタム分類を作成します。

[分類（Classification）] リストに分類を追加するには、次の手順を実行します。

ステップ 1 [設定（Configuration）] > [ASA FirePOWER 設定（ASA FirePOWER Configuration）] > [ポリシー（Policies）] > [侵入ポリシー（Intrusion Policy）] > [ルール エディタ（Rule Editor）] の順に選択します。

[ルール エディタ（Rule Editor）] ページが表示されます。

ステップ 2 [ルールの作成（Create Rule）] をクリックします。

[ルールの作成（Create Rule）] ページが表示されます。

ステップ 3 [分類（Classification）] ドロップダウンリストで、[分類の編集（Edit Classifications）] をクリックします。

ポップアップ ウィンドウが表示されます。

ステップ 4 [分類名（Classification Name）] フィールドに分類の名前を入力します。

最大で 255 文字の英数字を使用できますが、40 文字を超えるとページが読みにくくなります。 <>()\\\q"&$; 文字および空白文字はサポートされていません。

ステップ 5 [分類の説明（Classification Description）] フィールドに、分類の説明を入力します。

最大 255 文字の英数字およびスペースを使用できます。 <>()\\\q"&$; 文字はサポートされていません。

ステップ 6 [プライオリティ（Priority）] リストからプライオリティを選択します。

[high]、[medium]、または [low] を選択できます。

ステップ 7 [追加（Add）] をクリックします。

新しい分類がリストに追加され、ルール エディタで使用できるようになります。

ステップ 8 [完了（Done）] をクリックします。

イベント参照の定義

ライセンス： Protection

reference キーワードを使用すると、イベントに関する外部 Web サイトや追加情報への参照を追加できます。参照を追加すると、アナリストは参照情報をすぐに利用できるため、パケットがルールをトリガーとして使用した理由を特定するのに役立ちます。次の表に、既知のエクスプロイトや攻撃についてのデータを提供する外部システムをいくつか示します。

ルール エディタを使用して参照を指定するには、[検出オプション（Detection Options）] リストから [参照（reference）] を選択し、対応するフィールドに次のように値を入力します。

ここで、 id_system はプレフィクスとして使用されるシステム、 id は Bugtraq ID、CVE 番号、Arachnids ID、または URL（ http:// なし）です。

たとえば、Bugtraq ID 17134 に記載されている Microsoft Commerce Server 2002 サーバ上の認証バイパス脆弱性を指定するには、[参照（reference）] フィールドに次のように入力します。

参照をルールに追加するときには、次の点に注意してください。

• カンマの後ろにスペースを入力しないでください。
• システム ID に大文字を使用しないでください。

ルール エディタを使用してルールを作成する方法については、ルールの構築を参照してください。

コンテンツ一致の検索

ライセンス： Protection

content キーワードまたは protected_content キーワードを使用すると、パケット内で検出すべき内容（コンテンツ）を指定できます。詳細については、次の各項を参照してください。

• content キーワードの使用
• protected_content キーワードの使用
• コンテンツ マッチングの設定

content キーワードの使用

content キーワードを使用すると、ルール エンジンはパケット ペイロードまたはストリームの中でその文字列を検索します。たとえば、いずれかの content キーワードの値として /bin/sh と入力した場合、ルール エンジンはパケット ペイロード内で文字列 /bin/sh を検索します。

ASCII 文字列、16 進コンテンツ（バイナリ バイト コード）、またはその両方の組み合わせを使用してコンテンツを照合できます。キーワード値の中で 16 進コンテンツをパイプ文字（|）で囲みます。たとえば、 |90C8 C0FF FFFF|/bin/sh のように 16 進コンテンツと ASCII コンテンツを混在させることができます。

1 つのルール内で複数のコンテンツ マッチングを指定できます。これを行うには、 content キーワードの追加のインスタンスを使用します。コンテンツ マッチングごとに、ルールをトリガーとして使用させるにはパケット ペイロードまたはストリームでコンテンツ一致が見つからなければならないことを指定できます。

protected_content キーワードの使用

protected_content キーワードを使用すると、ルール引数を設定する前に、検索コンテンツ文字列をエンコードすることができます。キーワードを設定する前に、ルール作成者がハッシュ関数（SHA-512、SHA-256、または MD5）を使用して文字列をエンコードします。

content キーワードの代わりに protected_content キーワードを使用した場合でも、ルール エンジンがパケット ペイロードまたはストリームの中で文字列を検索する方法に違いはなく、ほとんどのキーワード オプションが想定どおりに機能します。次の表は、 protected_content キーワード オプションと content キーワード オプションの間の例外的な相違点を要約しています。

シスコ では、 protected_content キーワードを含むルールに 1 つ以上の content キーワードを含めることを推奨しています。こうすると、ルール エンジンが常に高速パターン マッチ機能を使用することで処理速度が上がり、パフォーマンスが向上します。ルール内の protected_content キーワードの前に content キーワード を配置します。ルールに 1 つ以上の content キーワードが含まれている場合は、 content キーワードの Use Fast Pattern Matcher 引数が有効になっているかどうかに関係なく、ルール エンジンが高速パターン マッチ機能を使用することに注意してください。

コンテンツ マッチングの設定

ほとんどの場合、 content または protected_content キーワードの後ろに修飾子を付けることによって、コンテンツを検索すべき位置、検索で大文字/小文字を区別するかどうか、その他のオプションを指定する必要があります。 content および protected_content キーワードの修飾子の詳細については、コンテンツ一致の制約を参照してください。

ルールでイベントがトリガーとして使用されるためには、すべてのコンテンツ マッチングが真でなければならないことに注意してください。つまり、各コンテンツ マッチングは相互に AND 関係にあります。

また、インライン展開では、有害なコンテンツを照合した後でそれを同じ長さの独自のテキスト文字列に置き換えるルールをセットアップできることにも注意してください。詳細については、インライン展開でのコンテンツの置換を参照してください。

照合するコンテンツを入力するには、次の手順を実行します。

ステップ 1 [コンテンツ（content）] フィールドに、検索する内容を入力します（たとえば |90C8 C0FF FFFF|/bin/sh ）。

指定したコンテンツ 以外の コンテンツを検索するには、[一致しない（Not）] チェック ボックスをオンにします。

注意 [一致しない（Not）] オプションが選択された 1 つの content キーワードだけを含むルールを作成した場合、侵入ポリシーの効果がなくなる可能性があります。詳細については、 注を参照してください。

---

ステップ 2 オプションで、 content キーワードを変更したり、キーワードの制約を追加したりするキーワードを追加します。

他のキーワードの詳細については、ルールでのキーワードと引数についてを参照してください。 content キーワードの制約の詳細については、コンテンツ一致の制約を参照してください。

ステップ 3 ルールの作成または編集を続けます。

詳細については、新しいルールの作成または既存のルールの変更を参照してください。

照合する保護されたコンテンツを入力するには、次の手順を実行します。

ステップ 1 SHA-512、SHA-256、または MD5 ハッシュ ジェネレータを使用して、検索するコンテンツをエンコードします（たとえば SHA-512 ハッシュ ジェネレータを使って文字列 Sample1 に対して実行します）。

ジェネレータが文字列のハッシュを出力します。

ステップ 2 [protected_content] フィールドに、ステップ 1 で生成したハッシュを入力します（たとえば B20AABAF59605118593404BD42FE69BD8D6506EE7F1A71CE6BB470B1DF848C814BC5DBEC2081999F15691A71FAECA5FBA4A3F8B8AB56B7F04585DA6D73E5DD15 ）。

指定したコンテンツ 以外の コンテンツを検索するには、[一致しない（Not）] チェック ボックスをオンにします。

注意 [一致しない（Not）] オプションが選択された 1 つの protected_content キーワードだけを含むルールを作成した場合、侵入ポリシーの効果がなくなる可能性があります。詳細については、 注を参照してください。

---

ステップ 3 [Hash Type] ドロップダウンリストから、ステップ 1 で使用したハッシュ関数（例えば SHA-512 ）を選択します。なお、ステップ 2 で入力されたハッシュ内のビット数がハッシュ タイプと一致する 必要があります 。一致しない場合、システムはルールを保存しません。詳細については、Hash Typeを参照してください。

ヒント シスコ設定の Default を選択した場合、システムはハッシュ関数として SHA-512 を想定します。

ステップ 4 必須の [長さ（Length）] フィールドに値を入力します。この値は、元の（ハッシュされていない）検索文字列の長さに対応する 必要があります （たとえば、ステップ 2 の文字列 Sample1 の長さは 7 です）。

詳細については、長さ（Length）を参照してください。

ステップ 5 [オフセット（Offset）] フィールドまたは [距離（Distance）] フィールドに値を入力します。1 つのキーワード設定内に [オフセット（Offset）] オプションと [距離（Distance）] オプションを混在させることはできません。

詳細については、protected_content キーワードでの検索位置オプションの使用を参照してください。

ステップ 6 オプションで、 protected_content キーワードを変更する制約オプションを追加します。

詳細については、コンテンツ一致の制約を参照してください。

ステップ 7 オプションで、 protected_content キーワードを変更する追加のキーワードを指定します。

詳細については、ルールでのキーワードと引数についてを参照してください。

ステップ 8 ルールの作成または編集を続けます。

詳細については、新しいルールの作成または既存のルールの変更を参照してください。

コンテンツ一致の制約

ライセンス： Protection

content または protected_content キーワードを変更するパラメータを使用すると、コンテンツ検索の位置や大文字/小文字の区別を制約できます。 content または protected_content キーワードを変更するオプションを設定して、検索対象となるコンテンツを指定します。

詳細については、次の項を参照してください。

• [大文字小文字の区別なし（Case Insensitive）]
• Hash Type
• 生データ（Raw Data）
• 注
• 検索位置オプション
• HTTP コンテンツ オプション
• 高速パターン マッチ機能を使用（Use Fast Pattern Matcher）

[大文字小文字の区別なし（Case Insensitive）]

ライセンス： Protection

（注） このオプションは protected_content キーワードの設定ではサポートされません。詳細については、protected_content キーワードの使用を参照してください。

ASCII 文字列でコンテンツ一致を検索するときに大文字/小文字の区別を無視するようルール エンジンに指示できます。検索で大文字/小文字を区別しないようにするには、コンテンツ検索の指定で [大文字小文字の区別なし（Case Insensitive）] をオンにします。

コンテンツ検索時に [大文字小文字の区別なし（Case Insensitive）] を指定するには、次の手順を実行します。

ステップ 1 追加する content キーワードに関して [大文字小文字の区別なし（Case Insensitive）] を選択します。

ステップ 2 ルールの作成または編集を続けます。

詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または 既存のルールの変更を参照してください。

Hash Type

ライセンス： Protection

（注） このオプションは protected_content キーワードでのみ設定できます。詳細については、protected_content キーワードの使用を参照してください。

[Hash Type] ドロップダウンを使用して、検索文字列のエンコードに使われたハッシュ関数を特定します。システムは、 protected_content 検索文字列のハッシュ方式として SHA-512、SHA-256、および MD5 をサポートしています。選択したハッシュ タイプとハッシュされたコンテンツの長さが一致しない場合、システムはルールを保存 しません 。

システムは自動的に、シスコ設定のデフォルト値を選択します。[デフォルト（Default）] が選択される場合、ルールには具体的なハッシュ関数が含まれず、システムはハッシュ関数として SHA-512 を想定します。

保護されたコンテンツ検索の実行時にハッシュ関数を指定するには、次の手順を実行します。

ステップ 1 [Hash Type] ドロップダウンリストから、追加する protected_content キーワードのハッシュとして [デフォルト（Default）]、[SHA-512]、[SHA-256]、または [MD5] を選択します。

ヒント シスコ設定の Default を選択した場合、システムはハッシュ関数として SHA-512 を想定します。詳細については、Hash Typeを参照してください。

ステップ 2 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または 既存のルールの変更を参照してください。

生データ（Raw Data）

ライセンス： Protection

[生データ（Raw Data）] オプションを使用すると、ルール エンジンは、正規化されたペイロード データ（ネットワーク分析ポリシーによってデコードされたデータ）を分析する前にオリジナルのパケット ペイロードを分析します。引数値は使用されません。正規化の前に、ペイロード内の Telnet ネゴシエーション オプションを検査するために Telnet トラフィックを分析する場合に、このキーワードを使用できます。

同じ content または protected_content キーワードの中で、[生データ（Raw Data）] オプションを HTTP コンテンツ オプションと一緒に使用することはできません。詳細については、HTTP コンテンツ オプションを参照してください。

ヒント HTTP トラフィック内で raw データを検査するかどうか、および検査される raw データの量を決定するために HTTP Inspect プリプロセッサの [クライアントフローの深さ（Client Flow Depth）] オプションと [サーバフローの深さ（Server Flow Depth）] オプションを設定できます。詳細については、サーバレベル HTTP 正規化オプションの選択を参照してください。

raw データを分析するには、次の手順を実行します。

ステップ 1 追加する content または protected_content キーワードの [生データ（Raw Data）] チェック ボックスを選択します。

ステップ 2 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または 既存のルールの変更を参照してください。

注

ライセンス： Protection

指定したコンテンツと一致しないコンテンツを検索するには、[一致しない（Not）] オプションを選択します。[一致しない（Not）] オプションが選択された content または protected_content キーワードを含むルールを作成する場合には、そのルール内に、[一致しない（Not）] オプションが選択されていない別の content または protected_content キーワードを 1 つ以上含める必要があります。

注意 content または protected_content キーワードの [一致しない（Not）] オプションを選択する場合は、その 1 つのキーワードだけ含むルールを作成しないでください。侵入ポリシーの効果がなくなる可能性があります。

---

たとえば、SMTP ルール 1:2541: 9 に 3 つの content キーワードが含まれており、そのうち 1 つで [一致しない（Not）] オプションが選択されているとします。[一致しない（Not）] オプションが選択されたキーワード以外のすべての content キーワードを仮に削除すると、このルールに基づくカスタム ルールが無効になります。このようなルールを侵入ポリシーに追加すると、そのポリシーの効果がなくなる可能性があります。

指定したコンテンツに一致しないコンテンツを検索するには、次の手順を実行します。

ステップ 1 追加する content または protected_content キーワードの [一致しない（Not）] チェック ボックスを選択します。

ヒント 同じ content キーワードで、[一致しない（Not）] チェック ボックスと [高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] チェック ボックスを同時に選択することはできません。

ステップ 2 [一致しない（Not）] オプションが選択されていない他の 1 つ以上の content または protected_content キーワードをルールに含めます。

ステップ 3 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または 既存のルールの変更を参照してください。

検索位置オプション

ライセンス： Protection

検索位置オプションを使用すると、指定したコンテンツの検索をどこから開始するか、どこまで検索するかを指定できます。各オプションの詳細については、以下を参照してください。

• 奥行き（Depth）
• 距離（Distance）
• 長さ（Length）
• オフセット（Offset）
• 次の範囲内（Within）

content または protected_content キーワード内で検索位置オプションを使用する方法については、以下を参照してください。

• content キーワードでの検索位置オプションの使用
• protected_content キーワードでの検索位置オプションの使用

奥行き（Depth）

（注） このオプションは、content キーワードを設定する場合にのみサポートされます。詳細については、content キーワードの使用を参照してください。

オフセット値の先頭からの（またはオフセットが設定されていない場合はパケット ペイロード先頭からの）コンテンツ検索の最大の深さをバイト単位で指定します。

たとえば、ルールのコンテンツ値が cgi-bin/phf 、 offset 値が 3 、 depth 値が 22 である場合、ルール ヘッダーで指定されたパラメータを満たすパケット内で、 cgi-bin/phf 文字列との一致の検索がバイト位置 3 から始まり、22 バイト処理した後（バイト 25）停止します。

指定したコンテンツの長さ以上の、最大 65535 バイトまでの値を指定する必要があります。値 0 は指定できません。

デフォルトの深さは、「パケットの末尾まで検索」です。

距離（Distance）

以前に見つかったコンテンツ一致から数えて、指定されたバイト数の後に出現する後続のコンテンツ一致を見つけるようルール エンジンに指示します。

Distance（距離）カウンタはバイト 0 から始まるため、最後に見つかったコンテンツ一致から順方向に移動すべきバイト数よりも 1 つ少ない数値を指定してください。たとえば 4 を指定した場合、5 番目のバイトから検索が始まります。

-65535 ～ 65535 バイトを値として指定できます。負の Distance 値を指定した場合は、検索を開始するバイト位置がパケットの先頭から外れる可能性があります。実際にはパケットの第 1 バイトから検索が開始されますが、計算ではパケットの外側のバイトも考慮されます。たとえば、パケット内の現在の位置が第 5 バイトで、次のコンテンツ ルール オプションで Distance 値 -10 および Within 値 20 が指定された場合、検索はペイロードの先頭から開始され、[Within] オプションが 15 に調整されます。

デフォルトの距離は 0 で、これは最後のコンテンツ一致の後のパケット内の現在位置という意味です。

長さ（Length）

（注） このオプションは、protected_content キーワードを設定する場合にのみサポートされます。詳細については、protected_content キーワードの使用を参照してください。

Length protected_content キーワード オプションは、ハッシュされていない検索文字列の長さをバイト単位で示します。

たとえば、コンテンツ Sample1 を使ってセキュア ハッシュを生成した場合には、 Length 値として 7 を使用します。このフィールドに値を入力することは 必須 です。

オフセット（Offset）

パケット ペイロードの先頭を基準とする、コンテンツの検索を開始するパケット ペイロード内の位置をバイト単位で指定します。-65535 ～ 65535 バイトを値として指定できます。

オフセット カウンタはバイト 0 から始まるため、パケット ペイロードの先頭から順方向に移動すべきバイト数よりも 1 つ少ない数値を指定してください。たとえば 7 を指定した場合は、8 番目のバイトから検索が始まります。

デフォルトのオフセットは 0 で、これはパケットの先頭を意味します。

次の範囲内（Within）

（注） このオプションは、content キーワードを設定する場合にのみサポートされます。詳細については、content キーワードの使用を参照してください。

[次の範囲内（Within）] オプションを使用すると、ルールをトリガーとして使用させるには、最後に見つかったコンテンツ一致の末尾以降、指定のバイト数以内に次のコンテンツ一致が発生する必要があることを指示できます。たとえば Within 値として 8 を指定した場合、次のコンテンツ一致がパケット ペイロードの次の 8 バイト以内に発生する必要があります。発生しない場合は、ルールをトリガーとして使用する基準が満たされません。

指定したコンテンツの長さ以上の、最大 65535 バイトまでの値を指定できます。

[次の範囲内（Within）] のデフォルトは「パケットの末尾まで検索」です。

content キーワードでの検索位置オプションの使用

次のように、2 つの content 位置ペアのいずれかを使用すると、指定したコンテンツの検索をどこから開始するか、どこまで検索するかを指定できます。

• パケット ペイロードの先頭を基準にして検索する場合は、[オフセット（Offset）] と [奥行き（Depth）] を一緒に使用します。
• 現在の検索位置を基準にして検索する場合は、[距離（Distance）] と [次の範囲内（Within）] を一緒に使用します。

ペアに含まれるオプションのどちらか 1 つだけを指定した場合は、そのペアのもう 1 つのオプションのデフォルトが想定されます。

[オフセット（Offset）] および [奥行き（Depth）] オプションと、[距離（Distance）] および [次の範囲内（Within）] オプションを混合することはできません。たとえば、[オフセット（Offset）] と [次の範囲内（Within）] をペアにすることはできません。1 つのルール内で任意の数の位置オプションを使用できます。

位置が指定されない場合は、[オフセット（Offset）] と [奥行き（Depth）] のデフォルトが想定されます。つまり、コンテンツ検索はパケット ペイロードの先頭から始まってパケットの末尾まで続きます。

また、既存の byte_extract 変数を使用して位置オプションの値を指定することもできます。詳細については、パケット データをキーワード引数の中に読み込むを参照してください。

ステップ 1 Web インターフェイスを使用して content keyword追加する content キーワードのフィールドに値を入力します。次の選択肢があります。

• オフセット（Offset）
• 奥行き（Depth）
• 距離（Distance）
• 次の範囲内（Within）

1 つのルール内で任意の数の位置オプションを使用できます。

ステップ 2 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または既存のルールの変更を参照してください。

protected_content キーワードでの検索位置オプションの使用

次のように、必須の [長さ（Length）] protected_content 位置オプションを [オフセット（Offset）] または [距離（Distance）] 位置オプションと組み合わせて使用すると、指定されたコンテンツの検索をどこから開始するか、どこまで検索するかを指定できます。

• パケット ペイロードの先頭を基準にして、保護された文字列を検索するには、[長さ（Length）] と [オフセット（Offset）] を一緒に使用します。
• 現在の検索位置を基準にして、保護された文字列を検索するには、[長さ（Length）] と [距離（Distance）] を一緒に使用します。

ヒント 1 つのキーワード設定内で [オフセット（Offset）] オプションと [距離（Distance）] オプションを混合することはできませんが、1 つのルール内では任意の数の位置オプションを使用できます。

位置が指定されない場合は、デフォルトが想定されます。つまり、コンテンツ検索はパケット ペイロードの先頭から始まってパケットの末尾まで続きます。

また、既存の byte_extract 変数を使用して位置オプションの値を指定することもできます。詳細については、パケット データをキーワード引数の中に読み込むを参照してください。

protected_content キーワードの中で検索位置の値を指定するには、次の手順を実行します。

ステップ 1 追加する protected_content キーワードのフィールドに値を入力します。次の選択肢があります。

• 長さ（Length） （必須）
• オフセット（Offset）
• 距離（Distance）

1 つの protected_content キーワード内で [オフセット（Offset）] オプションと [距離（Distance）] オプションを混合することはできませんが、1 つのルール内では任意の数の位置オプションを使用できます。

ステップ 2 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または既存のルールの変更を参照してください。

HTTP コンテンツ オプション

ライセンス： Protection

HTTP content または protected_content キーワード オプションを使用すると、HTTP Inspect プリプロセッサによってデコードされた HTTP メッセージ内でコンテンツ一致を検索する位置を指定できます。

次の 2 つのオプションは、HTTP 応答内のステータス フィールドを検索します。

• HTTP ステータス コード（HTTP Status Code）
• HTTP ステータス メッセージ（HTTP Status Message）

ルール エンジンは未加工の正規化されていないステータス フィールドを検索しますが、ここでは、他の raw HTTP フィールドと正規化された HTTP フィールドを併用する際に考慮すべき制限についての説明を簡略化するために、これらのオプションが別個に列挙されていることに注意してください。

次の 5 つのオプションは、必要に応じて HTTP 要求、応答、またはその両方の中で正規化フィールドを検索します（詳細については、HTTP コンテンツ オプションを参照してください）。

• HTTP URI
• HTTP メソッド（HTTP Method）
• HTTP ヘッダー（HTTP Header）
• HTTP Cookie
• HTTP クライアント ボディ（HTTP Client Body）

次の 3 つのオプションは、必要に応じて HTTP 要求、応答、またはその両方の中で未加工の（正規化されていない）非ステータス フィールドを検索します（詳細については、HTTP コンテンツ オプションを参照してください）。

• HTTP Raw URI
• HTTP raw ヘッダー（HTTP Raw Header）
• HTTP Raw Cookie

HTTP content オプションを選択する場合は、次のガイドラインに従ってください。

• HTTP content オプションは TCP トラフィックにのみ適用されます。
• パフォーマンスへの悪影響を避けるために、指定したコンテンツが出現する可能性のあるメッセージ部分だけを選択してください。

たとえば、ショッピング カート メッセージの場合のように大きな cookie がトラフィックに含まれている可能性がある場合は、HTTP cookie ではなく HTTP ヘッダーの中で指定のコンテンツを検索することができます。

• HTTP Inspect プリプロセッサの正規化機能を活用し、パフォーマンスを向上させるには、作成するすべての HTTP 関連ルールの中に、[HTTP URI]、[ HTTP メソッド（HTTP Method）]、[HTTP ヘッダー（HTTP Header）]、または [HTTP クライアント ボディ（HTTP Client Body）] オプションが選択された少なくとも 1 つの content または protected_content キーワードを含めてください。
• HTTP content または protected_content キーワード オプションと組み合わせて replace キーワードを使用することはできません。

単一の正規化された HTTP オプションまたはステータス フィールドを指定できます。または、複数の正規化 HTTP オプションとステータス フィールドを任意に組み合わせて、コンテンツ領域をマッチング対象にすることもできます。ただし、HTTP フィールド オプションを使用する場合には次の制限事項に注意してください。

• 同じ content または protected_content キーワードの中で、[生データ（Raw Data）] オプションを HTTP オプションと一緒に使用することはできません。
• raw HTTP フィールド オプション（[HTTP Raw URI]、[HTTP raw ヘッダー（HTTP Raw Header）]、または [HTTP Raw Cookie]）と、それぞれに対応する正規化されたオプション（[HTTP URI]、[HTTP ヘッダー（HTTP Header）]、または [HTTP Cookie]）を同じ content または protected_content キーワード内で一緒に使用することはできません。
• [高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] を、次の 1 つ以上の HTTP フィールド オプションと組み合わせて選択することはできません。

[HTTP Raw URI] 、[HTTP raw ヘッダー（HTTP Raw Header）]、[HTTP Raw Cookie]、[HTTP Cookie]、[HTTP メソッド（HTTP Method）]、[ HTTP ステータス メッセージ（HTTP Status Message）]、または [ HTTP ステータス コード（HTTP Status Code）]

ただし、次のいずれかの正規化フィールドを検索するために高速パターン マッチ機能を使用する content または protected_content キーワードでは、上記のオプションを含めることができます。

[HTTP URI]、[HTTP ヘッダー（HTTP Header）]、または [ HTTP クライアント ボディ（HTTP Client Body）]

たとえば、[HTTP Cookie]、[HTTP ヘッダー（HTTP Header）]、および [高速パターン マッチ機能を使用（Use Fast Pattern Matcher） ] を選択した場合、ルール エンジンは HTTP cookie と HTTP ヘッダーの両方でコンテンツを検索しますが、高速パターン マッチ機能は HTTP cookie ではなく、HTTP ヘッダーにのみ適用されます。

• 制限付きオプションと制限なしオプションを併用した場合、高速パターン マッチ機能は、指定された制限なしフィールドのみを検索することで、ルール エディタにルールを渡して（制限付きフィールドの評価を含む）完全な評価を行うべきかどうかを検査します。詳細については、高速パターン マッチ機能を使用（Use Fast Pattern Matcher）を参照してください。

HTTP content および protected_content キーワード オプションに関する以下のリストでは、前述した制限事項が各オプションの説明に反映されています。

HTTP URI

正規化された要求 URI フィールド内でコンテンツ一致を検索するには、このオプションを選択します。

このオプションと pcre キーワードの HTTP URI（U）オプションを一緒に使用して、同じコンテンツを検索できないことに注意してください。詳細については、 Snort 固有の正規表現後の修飾子 の表を参照してください。

（注） パイプライン処理された HTTP 要求パケットには複数の URI が含まれています。[HTTP URI] が選択されている場合、パイプライン処理された HTTP 要求パケットをルール エンジンが検出すると、そのパケット内のすべての URI でコンテンツ一致が検索されます。

HTTP Raw URI

正規化された要求 URI フィールド内でコンテンツ一致を検索するには、このオプションを選択します。

このオプションと pcre キーワードの HTTP URI（U）オプションを一緒に使用して、同じコンテンツを検索できないことに注意してください。詳細については、 Snort 固有の正規表現後の修飾子 の表を参照してください。

（注） パイプライン処理された HTTP 要求パケットには複数の URI が含まれています。[HTTP URI] が選択されている場合、パイプライン処理された HTTP 要求パケットをルール エンジンが検出すると、そのパケット内のすべての URI でコンテンツ一致が検索されます。

HTTPメソッド（HTTP Method）

（URI で識別されるリソースに対して行う GET や POST などのアクションを特定する）要求メソッド フィールド内のコンテンツ一致を検索するには、このオプションを選択します。

HTTP ヘッダー（HTTP Header）

HTTP 要求内の（cookie を除く）正規化されたヘッダー フィールドでコンテンツ一致を検索するには、このオプションを選択します。また、HTTP Inspect プリプロセッサの [HTTP 応答の検査（Inspect HTTP Responses）] オプションが有効になっている場合は応答内でも検索されます。

このオプションと pcre キーワードの HTTP ヘッダー（H）オプションを一緒に使用して、同じコンテンツを検索できないことに注意してください。詳細については、 Snort 固有の正規表現後の修飾子 の表を参照してください。

HTTP raw ヘッダー（HTTP Raw Header）

HTTP 要求内の（cookie を除く）raw ヘッダー フィールドでコンテンツ一致を検索するには、このオプションを選択します。また、HTTP Inspect プリプロセッサの [HTTP 応答の検査（Inspect HTTP Responses）] オプションが有効になっている場合は応答内でも検索されます。

このオプションと pcre キーワードの HTTP raw ヘッダー（D）オプションを一緒に使用して、同じコンテンツを検索できないことに注意してください。詳細については、 Snort 固有の正規表現後の修飾子 の表を参照してください。

HTTP Cookie

正規化された HTTP クライアント要求ヘッダー内で識別される cookie でコンテンツ一致を検索するには、このオプションを選択します。また、HTTP Inspect プリプロセッサの [HTTP 応答の検査（Inspect HTTP Responses）] オプションが有効になっている場合は応答 set-cookie データ内でも検索されます。システムは、メッセージ本文に含まれる cookie を本文の内容として扱うことに注意してください。

cookie 内だけで一致を検索するには、HTTP Inspect プリプロセッサの [HTTP Cookie の検査（Inspect HTTP Cookies）] オプションを有効にする必要があります。これを有効にしない場合、ルール エンジンは cookie を含むヘッダー全体を検索します。詳細については、サーバレベル HTTP 正規化オプションの選択を参照してください。

次の点に注意してください。

– このオプションと pcre キーワードの HTTP cookie（C）オプションを一緒に使用して、同じコンテンツを検索することはできません。詳細については、 Snort 固有の正規表現後の修飾子 の表を参照してください。

– Cookie: ヘッダー名と Set-Cookie: ヘッダー名、ヘッダー行の先行スペース、およびヘッダー行の終わりを示す CRLF は cookie の一部としてではなく、ヘッダーの一部として検査されます。

HTTP Raw Cookie

raw HTTP クライアント要求ヘッダー内で識別される cookie でコンテンツ一致を検索するには、このオプションを選択します。また、HTTP Inspect プリプロセッサの [HTTP 応答の検査（Inspect HTTP Responses）] オプションが有効になっている場合は応答 set-cookie データ内でも検索されます。システムは、メッセージ本文に含まれる cookie を本文の内容として扱うことに注意してください。

cookie 内だけで一致を検索するには、HTTP Inspect プリプロセッサの [HTTP Cookie の検査（Inspect HTTP Cookies）] オプションを有効にする必要があります。これを有効にしない場合、ルール エンジンは cookie を含むヘッダー全体を検索します。詳細については、サーバレベル HTTP 正規化オプションの選択を参照してください。

次の点に注意してください。

– このオプションと pcre キーワードの HTTP raw cookie（K）オプションを一緒に使用して同じコンテンツを検索することはできません。詳細については、 Snort 固有の正規表現後の修飾子 の表を参照してください。

– Cookie: ヘッダー名と Set-Cookie: ヘッダー名、ヘッダー行の先行スペース、およびヘッダー行の終わりを示す CRLF は cookie の一部としてではなく、ヘッダーの一部として検査されます。

HTTP クライアント ボディ（HTTP Client Body）

HTTP クライアント要求内のメッセージ本文でコンテンツ一致を検索するには、このオプションを選択します。

このオプションが機能するためには、HTTP Inspect プリプロセッサの [HTTP クライアント ボディ（HTTP Client Body） Extraction Depth] オプションで 0 ～ 65535 の値を指定する必要があることに注意してください。詳細については、サーバレベル HTTP 正規化オプションの選択を参照してください。

HTTP ステータス コード（HTTP Status Code）

HTTP 応答内の 3 桁のステータス コードでコンテンツ一致を検索するには、このオプションを選択します。

このオプションで一致が返されるようにするには、HTTP Inspect プリプロセッサの [HTTP 応答の検査（Inspect HTTP Responses）] オプションを有効にする必要があります。詳細については、サーバレベル HTTP 正規化オプションの選択を参照してください。

HTTP ステータス メッセージ（HTTP Status Message）

HTTP 応答のステータス コードに付加されるテキスト記述の中でコンテンツ一致を検索するには、このオプションを選択します。

このオプションで一致が返されるようにするには、HTTP Inspect プリプロセッサの [HTTP 応答の検査（Inspect HTTP Responses）] オプションを有効にする必要があります。詳細については、サーバレベル HTTP 正規化オプションの選択を参照してください。

TCP トラフィックのコンテンツ検索を実行する場合に HTTP content オプションを指定するには、次の手順を実行します。

ステップ 1 オプションで、HTTP Inspect プリプロセッサの正規化を活用して、パフォーマンスを向上させるには、以下のように選択します。

• 追加する content または protected_content キーワードの [HTTP URI]、[HTTP Raw URI]、[HTTP メソッド（HTTP Method）]、[HTTP ヘッダー（HTTP Header）]、[HTTP raw ヘッダー（HTTP Raw Header）]、または [HTTP クライアント ボディ（HTTP Client Body）] オプションから少なくとも 1 つ
• [HTTP Cookie] または [HTTP Raw Cookie] オプション

ステップ 2 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、コンテンツ一致の検索、新しいルールの作成、または 既存のルールの変更を参照してください。

高速パターン マッチ機能を使用（Use Fast Pattern Matcher）

ライセンス： Protection

（注） これらのオプションは、protected_content キーワードの設定ではサポートされません。詳細については、protected_content キーワードの使用を参照してください。

高速パターン マッチ機能は、パケットをルール エンジンに渡す前に、評価するルールをすばやく決定します。この初期決定により、パケット評価で使用されるルール数が大幅に減るため、パフォーマンスが向上します。

デフォルトで、高速パターン マッチ機能は、ルールで指定された最長のコンテンツをパケットで検索します。これは、不必要なルール評価をできるだけ減らすためです。次の例のようなルール フラグメントがあるとします。

ほとんどすべての HTTP クライアント要求にはコンテンツ GET が含まれていますが、コンテンツ /exploit.cgi を含む要求は稀です。 GET を高速パターン コンテンツとして使用した場合、ルール エンジンはほとんどのケースでこのルールを評価し、一致はほとんど検出されないでしょう。しかし、 /exploit.cgi を使用するとほとんどのクライアントの GET 要求は評価されないため、パフォーマンスが向上します。

指定されたコンテンツが高速パターン マッチ機能で検出された場合にのみ、ルール エンジンはパケットをルールに照らして評価します。たとえば、ルール内の 1 つの content キーワードでコンテンツ short を指定し、別のキーワードで longer 、さらに 3 番目のキーワードで longest を指定した場合、高速パターン マッチ機能はコンテンツ longest を使用し、ルール エンジンがペイロード内で longest を検出した場合にのみ、ルールが評価されます。

より短い検索パターンを高速パターン マッチ機能で使用するよう指定するには、[高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] オプションを使用できます。理論的には、指定したパターンの方が最長パターンよりもパケット内で見つかる可能性が低いため、より的を絞って対象のエクスプロイトを識別できます。

[高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] と他のオプションを同じ content キーワード内で選択する場合は、次の制限事項に注意してください。

• ルールごとに 1 回だけ、[高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] を指定できます。
• [高速パターン マッチ機能を使用（Use Fast Pattern Matcher） ] と [一致しない（Not）] を組み合わせて選択した場合は、[距離（Distance）]、[次の範囲内（Within）]、[オフセット（Offset）]、または [奥行き（Depth）] を使用できません。
• [高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] を、次のいずれかの HTTP フィールド オプションと組み合わせて選択することはできません。

[HTTP Raw URI] 、[HTTP raw ヘッダー（HTTP Raw Header）]、[HTTP Raw Cookie]、[HTTP Cookie]、[HTTP メソッド（HTTP Method）]、[ HTTP ステータス メッセージ（HTTP Status Message）]、または [ HTTP ステータス コード（HTTP Status Code）]

ただし、次のいずれかの正規化フィールドを検索するために高速パターン マッチ機能を使用する content キーワードでは、上記のオプションを含めることができます。

[HTTP URI]、[HTTP ヘッダー（HTTP Header）]、または [ HTTP クライアント ボディ（HTTP Client Body）]

たとえば、[HTTP Cookie]、[HTTP ヘッダー（HTTP Header）]、および [高速パターン マッチ機能を使用（Use Fast Pattern Matcher） ] を選択した場合、ルール エンジンは HTTP cookie と HTTP ヘッダーの両方でコンテンツを検索しますが、高速パターン マッチ機能は HTTP cookie ではなく、HTTP ヘッダーにのみ適用されます。

raw HTTP フィールド オプション（[HTTP Raw URI]、[HTTP raw ヘッダー（HTTP Raw Header）]、または [HTTP Raw Cookie]）と、それぞれに対応する正規化されたオプション（[HTTP URI]、[HTTP ヘッダー（HTTP Header）]、または [HTTP Cookie]）を同じ content キーワード内で一緒に使用することはできないことに注意してください。詳細については、HTTP コンテンツ オプションを参照してください。

制限付きオプションと制限なしオプションを併用した場合、高速パターン マッチ機能は、指定された制限なしフィールドのみを検索することで、ルール エンジンにパケットを渡して（制限付きフィールドの評価を含む）完全な評価を行うべきかどうかを検査します。

• オプションで、[高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] を選択した場合には [高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] または [高速パターン マッチ機能オフセットおよび長さ（Fast Pattern Matcher Offset and Length）] を選択することもできますが、この両方は選択できません。
• Base64 データの検査時には高速パターン マッチ機能を使用できません（詳細については、Base64 データのデコードと検査を参照してください）。

[高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] の使用

[高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] オプションを使用すると、 content キーワードをルール オプションとしてではなく、高速パターン マッチ機能オプションとしてのみ使用できます。指定したコンテンツをルール エンジンで評価する必要がない場合、このオプションを使ってリソースを節約できます。たとえば、ペイロード内のいずれかの場所にコンテンツ 12345 が存在することだけを必要とするルールがあるとします。高速パターン マッチ機能でパターンが検出された場合に、ルール内の追加のキーワードに照らしてパケットを評価できます。パターン 12345 が含まれているかどうかを判断するために、ルール エンジンがパケットを再評価する必要はありません。

指定されたコンテンツに関連する他の条件がルールに含まれている場合は、このオプションを使用しないでください。たとえば、別のルール条件で abcd が 1234 の前に出現するかどうかを判断する場合には、このオプションを使ってコンテンツ 1234 を検索しないでください。[高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] を指定すると、指定されたコンテンツがルール エンジンによって検索されないため、このケースではルール エンジンが相対的な位置を判断できません。

このオプションを使用するときには、次の条件に注意してください。

• 指定されたコンテンツは位置に依存しない、つまり、ペイロードのどこにでも出現する可能性があるため、位置オプション（[距離（Distance）]、[次の範囲内（Within）]、[オフセット（Offset）]、[奥行き（Depth）]、[高速パターン マッチ機能オフセットおよび長さ（Fast Pattern Matcher Offset and Length）]）を使用することはできません。
• このオプションを [一致しない（Not）] と組み合わせて使用することはできません。
• このオプションを [高速パターン マッチ機能オフセットおよび長さ（Fast Pattern Matcher Offset and Length）] と組み合わせて使用することはできません。
• 大文字/小文字を区別しない方法ですべてのパターンが高速パターン マッチ機能に挿入されるため、指定したコンテンツは「大文字/小文字の区別なし」として扱われます。これは自動的に処理されるため、このオプションの選択時に [大文字小文字の区別なし（Case Insensitive）] を選択する必要はありません。
• [高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] オプションを使用する content キーワードの直後に、現在の検索位置を基準にして検索位置を設定する次のキーワードを続けないようにしてください。
• isdataat
• pcre
• content （[距離（Distance）] または [次の範囲内（Within）] が選択されている場合）
• content （[HTTP URI] が選択されている場合）
• asn1
• byte_jump
• byte_test
• byte_extract
• base64_decode

[高速パターン マッチ機能オフセットおよび長さ（Fast Pattern Matcher Offset and Length）] の指定

[高速パターン マッチ機能オフセットおよび長さ（Fast Pattern Matcher Offset and Length）] オプションを使用すると、検索するコンテンツの一部分を指定できます。これにより、パターンが非常に長く、ルールの一致の可能性を判断するのにパターンの一部分だけで十分な場合に、メモリ消費を抑えることができます。高速パターン マッチ機能によってルールが選択されたときに、パターン全体がルールに照らして評価されます。

次の構文に従い、検索を開始する位置（オフセット）およびコンテンツ内をどれほど検索するか（長さ）をバイト単位で指定することにより、高速パターン マッチ機能で使用する部分を決定します。

たとえば、次のコンテンツに対して

次のようにオフセットと長さのバイト数を指定した場合、

高速パターン マッチ機能はコンテンツ 23456 のみを検索します。

このオプションを [高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] と一緒に使用できないことに注意してください。

高速パターン マッチ機能で検索されるコンテンツを指定するには、次の手順を実行します。

ステップ 1 追加する content キーワードに関して [高速パターン マッチ機能を使用（Use Fast Pattern Matcher）] を選択します。

ステップ 2 オプションで、指定したパターンがパケット内に存在するかどうかをルール エンジン評価なしで判断するには [高速パターン マッチ機能のみ（Fast Pattern Matcher Only）] を選択します。

指定されたコンテンツが高速パターン マッチ機能で検出された場合にのみ、評価が開始されます。

ステップ 3 オプションで、次の構文に従い、コンテンツの検索場所となるパターンの部分を [高速パターン マッチ機能オフセットおよび長さ（Fast Pattern Matcher Offset and Length）] で指定します。

ここで、 offset は検索の開始場所となるコンテンツ先頭からのバイト数を指定し、 length は検索を続けるバイト数を指定します。

ステップ 4 ルールの作成または編集を続けます。詳細については、コンテンツ一致の制約、PCRE を使用したコンテンツの検索、新しいルールの作成、または既存のルールの変更を参照してください。

インライン展開でのコンテンツの置換

ライセンス： Protection

インライン展開で replace キーワードを使用すると、指定したコンテンツを置き換えることができます。

replace キーワードを使用するには、 content キーワードを使って特定の文字列を検索するカスタム 標準テキスト ルール を作成します。その後、 replace キーワードを使用して、コンテンツを置き換える文字列を指定します。置換値とコンテンツ値は同じ長さである必要があります。

（注） protected_content キーワード内でハッシュされたコンテンツを置き換えるために replace キーワードを使用することはできません。詳細については、protected_content キーワードの使用を参照してください。

オプションで、以前の ASA FirePOWER モジュール ソフトウェア バージョンとの下位互換性を維持するために、置換文字列を引用符で囲むことができます。引用符を含めない場合は、それらが自動的にルールに追加されるため、構文的に正しいルールになります。置換テキストの一部として先行引用符または後続引用符を含めるには、次の例に示すように、バックスラッシュを使ってエスケープする必要があります。

1 つのルール内に複数の replace キーワードを含めることができますが、 content キーワードごとに 1 つずつしか含めることができません。ルールによって検出されたコンテンツの最初のインスタンスだけが置き換えられます。

次に、 replace キーワードの使用例を示します。

• エクスプロイトを含んでいる着信パケットをシステムが検出した場合、有害な文字列を無害な文字列に置き換えることができます。このテクニックは、有害なパケットを単に破棄するよりも効果的である場合があります。破棄されたパケットを攻撃者が単に再送信し続け、やがてネットワーク防御を通り抜けるか、ネットワークを氾濫させるという攻撃シナリオがあります。パケットを破棄する代わりに別の文字列に置き換えることで、脆弱ではないターゲットに対して攻撃が実行されたと攻撃者に思い込ませることができます。
• （たとえば Web サーバの）脆弱なバージョンが稼働しているかどうかを調べる偵察攻撃が懸念される場合は、発信パケットを検出して、バナーを独自のテキストに置き換えることができます。

（注） 置換ルールを使用するインライン侵入ポリシー内でルール状態が [イベントを生成する（Generate Events）] に設定されていることを確認してください。ルールを [ドロップしてイベントを生成する（Drop and Generate Events）] に設定した場合はパケットが破棄され、コンテンツが置き換えられません。

文字列置換プロセスでは、宛先ホストがエラーなしでパケットを受信できるように、パケット チェックサムがシステムによって自動的に更新されます。

replace キーワードを HTTP 要求メッセージ content キーワード オプションと組み合わせて使用できないことに注意してください。詳細については、「コンテンツ一致の検索」と「HTTP コンテンツ オプション」を参照してください。

インライン展開でコンテンツを置き換えるには、次の手順を実行します。

ステップ 1 [ルールの作成（Create Rule）] ページで、ドロップダウンリストから [コンテンツ（content）] を選択して、 [オプションを追加（Add Option）] をクリックします。

content キーワードが表示されます。

ステップ 2 [コンテンツ（content）] フィールドで、検出するコンテンツを指定します。オプションで、該当する引数を選択します。HTTP 要求メッセージ content キーワード オプションを replace キーワードと一緒に使用できないことに注意してください。

ステップ 3 ドロップダウンリストで [replace] を選択して、 [オプションを追加（Add Option）] をクリックします。

replace キーワードが content キーワードの下に表示されます。

ステップ 4 [replace:] フィールドで、指定したコンテンツに対する置換文字列を指定します。

Byte_Jump と Byte_Test の使用

ライセンス： Protection

byte_jump と byte_test を使用すると、パケット内のどの位置でルール エンジンがデータ マッチング検査を開始すべきか、どのバイトを評価すべきかを計算できます。

また、 byte_jump および byte_test DCE/RPC 引数を使用すると、DCE/RPC プリプロセッサで処理されるトラフィック用にいずれかのキーワードを調整できます。 DCE/RPC 引数を使用するときには、他の特定の DCE/RPC キーワードと組み合わせて byte_jump と byte_test を使用することもできます。詳細については、「DCE/RPC トラフィックのデコード」と「DCE/RPC キーワード」を参照してください。

詳細については、次の各項を参照してください。

• byte_jump
• byte_test

byte_jump

ライセンス： Protection

byte_jump キーワードは、指定されたバイト セグメントで定義されるバイト数を計算し、指定したオプションに応じて、指定されたバイト セグメントの末尾から順方向に、またはパケット ペイロードの先頭から、パケット内でそのバイト数だけスキップします。パケットの特定のバイト セグメントが、パケット内の可変データに含まれるバイト数を示す場合には、これが役立ちます。

次の表では、 byte_jump キーワードで必要な引数を説明します。

次の表で説明するオプションを使用すると、必須の引数に指定された値をシステムがどのように解釈するかを定義できます。

DCE/RPC 、 Endian 、または Number Type のうち 1 つだけを指定できます。

byte_jump キーワードでどのようにバイト数を計算するかを定義するには、次の表に示す引数から選択できます（どの引数も指定されない場合は、ネットワーク バイト順が使用されます）。

次の表に示すいずれか 1 つの引数を使用して、パケット内のストリング データをシステムがどのように表示するかを定義します。

たとえば、次のような値を byte_jump に設定した場合、

• Bytes = 4
• Offset = 12
• Relative enabled
• Align enabled

ルール エンジンは、最後に見つかったコンテンツ一致から 13 バイト後に出現する 4 つのバイトで記述される数値を計算して、そのバイト数だけパケット内を順方向にスキップします。たとえば、ある特定のパケット内で計算される 4 つのバイトが 00 00 00 1F である場合、ルール エンジンはこれを 31 に変換します。 align が指定されている（次の 32 ビット境界まで移動するようエンジンに指示する）ため、ルール エンジンはパケット内を 32 バイト先までスキップします。

あるいは、次のような値を byte_jump に設定した場合、

• Bytes = 4
• Offset = 12
• From Beginning enabled
• Multiplier = 2

ルール エンジンは、パケットの先頭から 13 バイト後に出現する 4 つのバイトで記述される数値を計算します。その後、その数値に 2 を掛けてスキップする総バイト数を計算します。たとえば、ある特定のパケット内で計算される 4 つのバイトが 00 00 00 1F である場合、ルール エンジンはこれを 31 に変換し、それに 2 を掛けて 62 にします。[From Beginning] が有効になっているため、ルール エンジンはパケット内の最初の 63 バイトをスキップします。

byte_jump を使用するには、次の手順を実行します。

ステップ 1 ドロップダウンリストで [byte_jump] を選択して、[オプションを追加（Add Option）] をクリックします。

[byte_jump] セクションが、選択された最後のキーワードの下に表示されます。

byte_test

ライセンス： Protection

byte_test キーワードは、指定されたバイト セグメント内のバイト数を計算し、指定した演算子と値に基づいてそれらを比較します。

次の表に、 byte_test キーワードで必要な引数を説明します。

次の表に示す引数を使用すると、システムで byte_test 引数がどのように使用されるかをさらに定義できます。

DCE/RPC 、 Endian 、または Number Type のうち 1 つだけを指定できます。

検査対象となるバイトを byte_test キーワードでどのように計算するか定義するには、次の表の中から引数を選択します。どの引数も指定しない場合は、ネットワーク バイト順が使用されます。

次の表に示すいずれか 1 つの引数を使用して、パケット内のストリング データをシステムがどのように表示するかを定義できます。

たとえば、次のような値を byte_test に指定した場合、

• Bytes = 4
• Operator and Value > 128
• Offset = 8
• Relative enabled

ルール エンジンは、最後に見つかったコンテンツ一致から（それを基準にして）9 バイト後に出現する 4 つのバイトで記述される数値を計算し、その計算値が 128 バイトを超えた場合に、ルールがトリガーとして使用されます。

byte_test を使用するには、次の手順を実行します。

ステップ 1 [ルールの作成（Create Rule）] ページで、ドロップダウンリストから [byte_test] を選択して、[オプションを追加（Add Option）] をクリックします。

[byte_test] セクションが、選択された最後のキーワードの下に表示されます。

PCRE を使用したコンテンツの検索

ライセンス： Protection

pcre キーワードを使用すると、指定されたコンテンツをパケット ペイロード内で検査するために Perl 互換正規表現（PCRE）を使用できます。PCRE を使用すると、同じ内容のわずかなバリエーションにそれぞれ一致する複数のルールを作成する手間が省けます。

正規表現は、さまざまな方法で表現されることのあるコンテンツを検索する場合に役立ちます。パケットのペイロード内でコンテンツを検索するときには、コンテンツがさまざまな属性を持つ可能性があることを考慮すべき場合があります。

侵入ルールで使われる正規表現構文は完全な正規表現ライブラリのサブセットであり、完全なライブラリ内のコマンドで使用される構文とはいくつかの点で異なることに注意してください。ルール エディタを使用して pcre キーワードを追加するときには、次の形式で完全な値を入力します。

引数の説明

• ! はオプションの否定です（正規表現に一致 しない パターンを照合する場合にこれを使用します）。
• / pcre / は Perl 互換正規表現です。
• ismxAEGRBUIPHDMCKSY は修飾子オプションの任意の組み合わせです。

また、次の表に示す文字をエスケープする必要があることに注意してください。これにより、パケット ペイロード内で特定のコンテンツを検索するために PCRE でこれらの文字を使用した場合、ルール エンジンがそれを正しく解釈するようになります。

ヒント オプションで、Perl 互換正規表現を引用符で囲むことができます。たとえば、pcre_expression は "pcre_expression" となります。引用符が任意ではなく必須であった旧バージョンに慣れている経験豊富なユーザのために、引用符を使用するオプションが提供されています。保存後のルールをルール エディタで表示すると、引用符が表示されません。

また、 m?regex? を使用することもできます。ここで、 ? は / 以外の区切り文字です。正規表現内でスラッシュと一致させる必要があり、バックスラッシュを使ってそれをエスケープしたくない場合には、これを使用できます。たとえば、 m? regex ? ismxAEGRBUIPHDMCKSY を使用できます。ここで regex は Perl 互換正規表現、 ismxAEGRBUIPHDMCKSY は修飾子オプションの任意の組み合わせです。正規表現の構文の詳細については、Perl 互換正規表現の基本を参照してください。

以下の項では、有効な pcre キーワードの値を作成する方法について詳しく説明します。

• Perl 互換正規表現の基本では、Perl 互換正規表現で使われる一般的な構文について説明します。
• PCRE 修飾子のオプションでは、正規表現を変更するために使用できるオプションについて説明します。
• PCRE キーワード値の例では、ルールにおける pcre キーワードの使用例を示します。

Perl 互換正規表現の基本

ライセンス： Protection

pcre キーワードでは、標準の Perl 互換正規表現（PCRE）構文を使用できます。以下の項では、この構文について説明します。

ヒント ここでは PCRE で使用可能な基本的な構文について説明しますが、Perl および PCRE 専用のオンライン リファレンスやブックで、さらに詳しい情報を参照することもできます。

メタ文字

ライセンス： Protection

メタ文字は正規表現内で特別な意味を持つリテラル文字です。メタ文字を正規表現内で使用するときには、その前にバックスラッシュを付けて「エスケープする」必要があります。

次の表に、PCRE で使用可能なメタ文字について説明し、それぞれの例を示します。

文字クラス

ライセンス： Protection

文字クラスには、英字、数字、英数字、および空白文字があります。大カッコで囲んで独自の文字クラスを作成できます（メタ文字を参照）。また、事前定義のクラスをさまざまな文字タイプのショートカットとして使用することもできます。追加の修飾子なしで文字クラスを使用すると、1 つの文字クラスは 1 桁または 1 文字に一致します。

次の表に、PCRE で使用できる事前定義の文字クラスの説明と例を示します。

PCRE 修飾子のオプション

ライセンス： Protection

pcre キーワードの値の中で正規表現構文を指定した後、修飾オプションを使用できます。これらの修飾子は、Perl、PCRE、および Snort 固有の処理機能を実行します。修飾子は、常に PCRE 値の末尾に、次の形式で出現します。

ここで、 ismxAEGRBUPHMC には、次の表に示す任意の修飾オプションを含めることができます。

ヒント オプションで、正規表現と修飾オプションを引用符で囲むことができます（たとえば "/pcre/ismxAEGRBUIPHDMCKSY"）。引用符が任意ではなく必須であった旧バージョンに慣れている経験豊富なユーザのために、引用符を使用するオプションが提供されています。保存後のルールをルール エディタで表示すると、引用符が表示されません。

次の表に、Perl 処理機能を実行するために使用できるオプションを説明します。

次の表に、正規表現の後ろに使用できる PCRE 修飾子の説明を示します。

次の表に、正規表現の後ろに使用できる Snort 固有の修飾子の説明を示します。

（注） U オプションと R オプションを組み合わせて使用しないでください。パフォーマンスの問題が発生する可能性があります。また、他の HTTP コンテンツ オプション（I、P、H、D、M、C、K、S または Y）と組み合わせて U オプションを使用しないでください。

PCRE キーワード値の例

ライセンス： Protection

次に、 pcre で入力できる値の例を示し、それぞれの例で何が一致するかを説明します。

• /feedback[(\\d{0,1})]?\\.cgi/U

この例では、URI データにのみ配置された、 feedback の後に 0 個または 1 個の数字、さらに .cgi が続くインスタンスをパケット ペイロード内で検索します。

この例は以下のものと一致します。

• feedback.cgi
• feedback1.cgi
• feedback2.cgi
• feedback3.cgi

この例は、以下のものとは一致 しません 。

• feedbacka.cgi
• feedback11.cgi
• feedback21.cgi
• feedbackzb.cgi
• /^ez(\\w{3,5})\\.cgi/iU

この例では、先頭の ez の後に 3 ～ 5 文字の単語、さらに .cgi が続く文字列をパケット ペイロード内で検索します。この検索では大文字と小文字を区別せず、URI データだけを検索します。

この例は以下のものと一致します。

• EZBoard.cgi
• ezman.cgi
• ezadmin.cgi
• EZAdmin.cgi

この例は、以下のものとは一致 しません 。

• ezez.cgi
• fez.cgi
• abcezboard.cgi
• ezboardman.cgi
• /mail(file|seek)\\.cgi/U

この例では、URI データ内の mail の後に file と seek のどちらかが続く文字列をパケット ペイロードで検索します。

この例は以下のものと一致します。

• mailfile.cgi
• mailseek.cgi

この例は、以下のものとは一致 しません 。

• MailFile.cgi
• mailfilefile.cgi
• m?http\\\\x3a\\x2f\\x2f.*(\\n|\\t)+?U

この例では、任意の数の文字の後ろにある、HTTP 要求内のタブまたは改行文字を示す URI コンテンツをパケット ペイロード内で検索します。この例では、 m? regex ? を使用して、式で http\\:\\/\\/ を使用しないようにしています。コロンの前にバックスラッシュがあることに注意してください。

この例は以下のものと一致します。

• http://www.example.com?scriptvar=x&othervar=\\n\\..\\..
• http://www.example.com?scriptvar=\\t

この例は、以下のものとは一致 しません 。

• ftp://ftp.example.com?scriptvar=&othervar=\\n\\..\\..
• http://www.example.com?scriptvar=|/bin/sh -i|
• m?http\\\\x3a\\x2f\\x2f.*=\\|.*\\|+?sU

この例では、（改行を含む）任意の数の文字の後に 1 つの等号、さらに任意の数の文字または空白を含むパイプ文字が続くという構成の URL をパケット ペイロード内で検索します。この例では、 m? regex ? を使用して、式で http\\:\\/\\/ を使用しないようにしています。

この例は以下のものと一致します。

• http://www.example.com?value=|/bin/sh/ -i|
• http://www.example.com?input=|cat /etc/passwd|

この例は、以下のものとは一致 しません 。

• ftp://ftp.example.com?value=|/bin/sh/ -i|
• http://www.example.com?value=x&input?|cat /etc/passwd|
• /[0-9a-f]{2}\\:[0-9a-f]{2}\\:[0-9a-f]{2}\\:[0-9a-f]{2}\\:[0-9a-f]{2}\\:[0-9a-f]{2}/i

この例では、MAC アドレスをパケット ペイロード内で検索します。コロン文字がバックスラッシュでエスケープされていることに注意してください。

ルールにメタデータを追加する

ライセンス： Protection

metadata キーワードを使用すると、記述情報をルールに追加できます。追加した情報を使用して、ニーズに合う方法でルールを整理/識別したり、ルールを検索したりできます。

システムは次の形式に基づいてメタデータを検証します。

ここで、 key と value は、スペースで区切られた記述の組み合わせです。これは、シスコ 提供のルールにメタデータを追加するために シスコ VRT で使用されている形式です。

または、次の形式を使用することもできます。

たとえば、 key value 形式で次のようにカテゴリとサブカテゴリを使用して、作成者と日付によってルールを識別できます。

1 つのルール内で複数の metadata キーワードを使用できます。また、以下の例に示すように、単一の metadata キーワード内で複数の key value ステートメントをカンマで区切ることもできます。

使用できる形式は key value と key = value だけに限定されません。ただし、これらの形式に基づく検証に起因する制限事項を知っておく必要があります。

制限されている文字の回避

ライセンス： Protection

次の文字制限に注意してください。

• metadata キーワード内でセミコロン（;）やコロン（:）を使用しないでください。
• カンマを使用する場合には、複数の key value または key = value ステートメントの区切り文字としてカンマが解釈されることに注意してください。次に例を示します。

• 等号（=）または空白文字を使用する場合には、それらの文字が key と value の間の区切り文字として解釈されることに注意してください。次に例を示します。

その他のすべての文字が使用可能です。

service メタデータの追加

ライセンス： Protection

ルール エンジンは、トラフィックを分析して処理するために、パケット内のホストに関するアプリケーション プロトコル情報を照合する service メタデータ付きのアクティブ ルールを適用します。これが一致しない場合、システムはルールをトラフィックに適用しません。ホストにアプリケーション プロトコル情報が存在しない場合、またはルールに service メタデータが含まれない場合、システムはルール内のポートに照らしてトラフィック内のポートを検査し、ルールをトラフィックに適用するかどうかを判断します。

次の図は、アプリケーション情報に基づくトラフィックとルールの照合を示しています。

アプリケーション プロトコルの識別によってルールを照合するには、 metadata キーワードと key value ステートメントを定義する必要があります。その際、 key として service 、および value としてアプリケーションを指定します。たとえば、次に示す metadata キーワード内の key value ステートメントは、ルールを HTTP トラフィックに関連付けます。

次の表では、最も一般的なアプリケーション値について説明します。

（注） 表に含まれないアプリケーションを定義するために支援が必要な場合は、サポート担当にお問い合わせください。

予約済みメタデータの回避

ライセンス： Protection

metadata キーワードでは、次の単語を単一の引数として、または key value ステートメント内のキーとして使用しないでください。これらは VRT 用に予約されています。

（注） ローカル ルールを適切に機能させるために制限付きメタデータをどうしても追加する必要がある場合は、サポート担当にお問い合わせください。詳細については、ローカル ルール ファイルのインポートを参照してください。

IP ヘッダー値の検査

ライセンス： Protection

キーワードを使用すると、パケットの IP ヘッダーの中で攻撃やセキュリティ ポリシー違反の可能性を識別できます。詳細については、次の各項を参照してください。

• フラグメント ビットと予約済みビットの検査
• IP ヘッダー識別値の検索
• 指定された IP オプションの識別
• 指定された IP プロトコル番号の識別
• パケットのタイプ オブ サービスの検査
• パケットの存続可能時間値の検査

フラグメント ビットと予約済みビットの検査

ライセンス： Protection

fragbits キーワードは、IP ヘッダー内のフラグメント ビットと予約ビットを検査します。パケットごとに、予約ビット、More Fragments ビット、および Don't Fragment ビットを任意に組み合わせて検査できます。

fragbits キーワードを使ってルールを微調整するために、次の表に示す演算子をルール内の引数値の後ろに指定できます。

たとえば、（他のビットの有無とは無関係に）少なくとも予約済みビットが設定されたパケットに対してイベントを生成するには、 fragbits 値として R+ を使用します。

IP ヘッダー識別値の検索

ライセンス： Protection

id キーワードは、キーワード引数で指定される値に照らして IP ヘッダー フラグメント識別フィールドを検査します。一部のサービス拒否ツールやスキャナは、このフィールドを、容易に検出できる特定の番号に設定します。たとえば、Synscan ポートスキャンを検出する SID 630 では、 id 値が 39426 （スキャナから伝送されるパケットの ID 番号として使われる静的な値）に設定されます。

（注） id 引数値は数値でなければなりません。

指定された IP オプションの識別

ライセンス： Protection

IPopts キーワードを使用すると、指定された IP ヘッダー オプションをパケット内で検索できます。次の表に、使用可能な引数値を示します。

アナリストが最も頻繁に監視するのは、厳密な送信元ルーティングと厳密でない送信元ルーティングです。これらのオプションは送信元 IP アドレスのスプーフィングを示している可能性があるためです。

指定された IP プロトコル番号の識別

ライセンス： Protection

ip_proto キーワードを使用すると、キーワードの値として指定された IP プロトコルを含むパケットを識別できます。IP プロトコルは 0 ～ 255 の数値として指定できます。プロトコル番号の完全なリストについては、 http://www.iana.org/assignments/protocol-numbers を参照してください。これらの番号を、 < 、 > 、または ! 演算子と組み合わせることができます。たとえば、ICMP 以外のプロトコルを使用しているトラフィックを検査するには、 !1 を ip_proto キーワードの値として使用します。1 つのルール内で ip_proto キーワードを複数回にわたって使用できます。ただし、ルール エンジンはキーワードの複数インスタンスをブール和関係（AND）と解釈することに注意してください。たとえば、 ip_proto:!3; ip_proto:!6 を含むルールを作成した場合、このルールは GGP プロトコルおよび TCP プロトコルを使用するトラフィックを無視します。

パケットのタイプ オブ サービスの検査

ライセンス： Protection

一部のネットワークでは、ネットワーク上を移動するパケットの優先度を設定するタイプ オブ サービス（ToS）値が使用されます。 tos キーワードを使用すると、キーワードの引数で指定された値に照らしてパケットの IP ヘッダー ToS 値を検査できます。 tos キーワードを使用するルールは、ToS が指定の値に設定され、しかもルール内の残りの基準を満たすパケットに対してトリガーとして使用されます。

（注） tos の引数値は数値でなければなりません。

[ToS] フィールドは IP ヘッダー プロトコルでは非推奨になり、[Differentiated Services Code Point (DSCP)] フィールドに置き換えられています。

パケットの存続可能時間値の検査

ライセンス： Protection

パケットの存続可能時間（time-to-live、ttl）値は、パケットが破棄される前に生成できるホップ数を示します。 ttl キーワードを使用すると、キーワードの引数として指定された値または値の範囲に照らしてパケットの IP ヘッダー ttl 値を検査できます。 ttl キーワード パラメータを 0 や 1 などの低い値に設定すると役立つことがあります。これは、低い存続可能時間値がトレースルートや侵入回避の試みを示している場合があるためです（なお、このキーワードの適切な値はデバイスの配置やネットワーク トポロジによって異なります）。次の構文を使用します。

• TTL 値に特定の 1 つの値を設定するには、0 ～ 255 の整数を使用します。値の前に等号（=）を付けることもできます（たとえば 5 または =5 を指定できます）。
• TTL 値の範囲を指定するには、ハイフン（ - ）を使用します（たとえば、 0-2 は 0 ～ 2 のすべての値、 -5 は 0 ～ 5 のすべての値、 5- は 5 ～ 255 のすべての値をそれぞれ指定します）。
• 特定の値より大きい TTL 値を指定するには、「大なり」記号（>）を使用します（たとえば、 >3 は 3 より大きいすべての値を指定します）。
• 特定の値以上の TTL 値を指定するには、「大なりイコール」記号（>=）を使用します（たとえば、 >=3 は 3 以上のすべての値を指定します）。
• 特定の値より小さい TTL 値を指定するには、「小なり」記号（<）を使用します（たとえば、 <3 は 3 より小さいすべての値を指定します）。
• 特定の値以下の TTL 値を指定するには、「小なりイコール」記号（<=）を使用します（たとえば、 <=3 は 3 以下のすべての値を指定します）。

ICMP ヘッダー値の検査

ライセンス： Protection

ASA FirePOWER モジュールでサポートされるキーワードを使用すると、ICMP パケット ヘッダー内の攻撃やセキュリティ ポリシー違反を識別できます。なお、ほとんどの ICMP タイプおよびコードを検出する事前定義ルールがあることに注意してください。既存のルールを有効にするか、既存のルールに基づいてローカル ルールを作成することを考慮してください。ICMP ルールを最初から作成するよりも、ニーズを満たすルールを見つける方が時間の節約になる可能性があります。

ICMP 固有のキーワードの詳細については、以下の項を参照してください。

• 静的な ICMP ID 値とシーケンス値の識別
• ICMP メッセージ タイプの検査
• ICMP メッセージ コードの検査

静的な ICMP ID 値とシーケンス値の識別

ライセンス： Protection

ICMP の識別番号とシーケンス番号は、ICMP 応答と ICMP 要求を関連付けるうえで役立ちます。通常のトラフィックでは、これらの値はパケットに動的に割り当てられます。一部のコバート チャネルおよび Distributed Denial of Server（DDoS）プログラムは、静的な ICMP ID およびシーケンス値を使用します。次のキーワードを使用すると、静的な値を含む ICMP パケットを識別できます。

icmp_id

icmp_id キーワードは、ICMP エコー要求または応答パケットの ICMP ID 番号を検査します。ICMP ID 番号に対応する数値を icmp_id キーワードの引数として使用します。

icmp_seq

icmp_seq キーワードは、ICMP エコー要求または応答パケットの ICMP シーケンスを検査します。ICMP シーケンス番号に対応する数値を icmp_seq キーワードの引数として使用します。

ICMP メッセージ タイプの検査

ライセンス： Protection

itype キーワードを使用して、特定の ICMP メッセージ タイプ値を含むパケットを検索します。有効な ICMP タイプ値または無効な ICMP タイプ値を指定して、さまざまなタイプのトラフィックを検査できます（ICMP タイプ番号の完全なリストについては http://www.iana.org/assignments/icmp-parameters [英語]または http://www.faqs.org/rfcs/rfc792.html [英語]を参照してください）。たとえば、サービス拒否攻撃やフラッディング攻撃を発生させるために攻撃者が範囲外の ICMP タイプ値を設定することがあります。

「小なり」（<）と「大なり」（>）を使用して itype 引数値の範囲を指定できます。

次に例を示します。

• <35
• >36
• 3<>55

ヒント ICMP タイプ番号の完全なリストについては、http://www.iana.org/assignments/icmp-parameters [英語] または http://www.faqs.org/rfcs/rfc792.html [英語] を参照してください。

ICMP メッセージ コードの検査

ライセンス： Protection

ICMP メッセージには、宛先が到達不能である場合の詳細を示すコード値が含まれることがあります。（ICMP メッセージ コードの完全なリストと、それぞれに関連するメッセージ タイプについては、 http://www.iana.org/assignments/icmp-parameters [英語] の第 2 項を参照してください）。

icode キーワードを使用すると、特定の ICMP コード値を含むパケットを識別できます。有効な ICMP コード値と無効な ICMP コード値のいずれかを指定することにより、さまざまなタイプのトラフィックを検査できます。

「小なり」（<）と「大なり」（>）を使用して icode 引数値の範囲を指定できます。

次に例を示します。

• 35 より小さい値を検索するには <35 と指定します。
• 36 より大きい値を検索するには >36 と指定します。
• 3 ～ 55 の間にある値を検索するには、 3<>55 と指定します。

ヒント icode キーワードと itype キーワードを一緒に使用すると、両方に一致するトラフィックを識別できます。たとえば、ICMP 宛先到達不能コード タイプと ICMP ポート到達不能コード タイプを含む ICMP トラフィックを特定するには、値 3 の itype キーワード（宛先到達不能）と、値 3 の icode キーワード（ポート到達不能）を指定します。

TCP ヘッダー値とストリーム サイズの検査

ライセンス： Protection

ASA FirePOWER モジュールでは、パケットの TCP ヘッダーと TCP ストリーム サイズを使って試行される攻撃を識別するためのキーワードを使用できます。TCP 固有のキーワードの詳細については、以下の項を参照してください。

• TCP 確認応答値の検査
• TCP フラグ組み合わせの検査
• TCP または UDP クライアントまたはサーバ フローへのルールの適用
• 静的な TCP シーケンス番号の識別
• 特定のサイズの TCP ウィンドウの識別
• 特定のサイズの TCP ストリームの識別

TCP 確認応答値の検査

ライセンス： Protection

ack キーワードを使用すると、パケットの TCP 確認応答番号と特定の値を比較できます。パケットの TCP 確認応答番号が、 ack キーワードに指定された値と一致した場合に、ルールがトリガーとして使用されます。

ack の引数値は数値でなければなりません。

TCP フラグ組み合わせの検査

ライセンス： Protection

flags キーワードを使用すると、複数の TCP フラグを任意に組み合わせて指定できます。検査対象のパケットでこれらが設定されている場合、ルールがトリガーとして使用されます。

（注） 従来、flags の値として A+ を使用していたケースでは、代わりに値 established を含む flow キーワード使用してください。一般に、フラグのすべての組み合わせが検出されるようにするには、フラグの使用時に値 stateless を含む flow キーワードを使用する必要があります。flow キーワードの詳細については、TCP または UDP クライアントまたはサーバ フローへのルールの適用を参照してください。

次の表に示す flags キーワードの値を確認または無視することができます。

ヒント 明示的輻輳通知（ECN）の詳細については、http://www.faqs.org/rfcs/rfc3168.html で情報を参照してください。

flags キーワードを使用する場合、複数のフラグに対する照合方法をシステムに指示するための演算子を使用できます。次の表に、これらの演算子の説明を示します。

TCP または UDP クライアントまたはサーバ フローへのルールの適用

ライセンス： Protection

flow キーワードを使用すると、セッション特性に基づいてルールで検査されるパケットを選択できます。 flow キーワードを使用することで、ルールの適用対象となるトラフィック フロー方向を指定して、クライアント フローとサーバ フローのどちらかにルールを適用できます。 flow キーワードによるパケット検査の方法を指定するには、分析すべきトラフィックの方向、検査するパケットの状態、およびパケットが再構築ストリームの一部かどうかを設定できます。

ルールの処理時に、パケットのステートフル インスペクションが実行されます。ステートレス トラフィック（セッション コンテキストが確立されていないトラフィック）を TCP ルールで無視するには、 flow キーワードをルールに追加して、そのキーワードに Established 引数を選択する必要があります。UDP ルールでステートレス トラフィックを無視するには、 flow キーワードをルールに追加して、 Established 引数と方向引数のどちらか（または両方）を選択する必要があります。これにより、TCP または UDP ルールでパケットのステートフル インスペクションが実行されます。

方向引数を追加した場合、ルール エンジンは、指定された方向と一致するフローを伴う確立された状態のパケットだけを検査します。たとえば、TCP または UDP 接続が検出されたときトリガーとして使用されるルールに、 flow キーワードおよび established 引数と From Client 引数を追加した場合、ルール エンジンはクライアントから送信されたパケットだけを検査します。

ヒント パフォーマンスを最大にするには、必ず TCP ルールまたは UDP セッション ルールに flow キーワードを含めてください。

フローを指定するには、[ルールの作成（Create Rule）] ページの [検出オプション（Detection Options）] リストで [flow] キーワードを選択し、[オプションを追加（Add Option）] をクリックします。次に、フィールドごとに表示されるリストから引数を選択します。

次の表に、 flow キーワードで指定できるストリーム関連引数の説明を示します。

次の表に、 flow キーワードで指定できる方向オプションの説明を示します。

From Server と To Client の機能が同じであること、および To Server と From Client の機能も同じであることに注意してください。これらのオプションは、ルールに文脈と読みやすさを加味するために提供されています。たとえば、サーバからクライアントへの攻撃を検出するよう設計されたルールを作成する場合は、 From Server を使用します。一方、クライアントからサーバへの攻撃を検出するように設計されたルールを作成する場合は、 From Client を使用します。

次の表に、 flow キーワードで指定できるストリーム関連引数の説明を示します。

たとえば、 flow キーワードの値として To Server, Established, Only Stream Traffic を使用すると、ストリーム プリプロセッサで再構築された、確立済みセッションでクライアントからサーバに移動するトラフィックを検出できます。

静的な TCP シーケンス番号の識別

ライセンス： Protection

seq キーワードを使用すると、静的なシーケンス番号値を指定できます。パケットのシーケンス番号が、指定された引数と一致する場合、そのキーワードを含むルールがトリガーとして使用されます。このキーワードはあまり使用されませんが、静的シーケンス番号付きの生成済みパケットを使用する攻撃やネットワーク スキャンを識別するうえでこれが役立ちます。

特定のサイズの TCP ウィンドウの識別

ライセンス： Protection

window キーワードを使用すると、特定の TCP ウィンドウ サイズを指定できます。このキーワードを含むルールは、指定された TCP ウィンドウ サイズのパケットが検出されるたびにトリガーとして使用されます。このキーワードはあまり使用されませんが、静的 TCP ウィンドウ サイズ付きの生成済みパケットを使用する攻撃やネットワーク スキャンを識別するうえでこれが役立ちます。

特定のサイズの TCP ストリームの識別

ライセンス： Protection

次に示す形式で、 stream_size キーワードとストリーム プリプロセッサを組み合わせて使用すると、TCP ストリームのサイズをバイト単位で特定できます。

ここで、 bytes はバイト数です。引数内の各オプションをカンマ（,）で区切る必要があります。

次の表に、 stream_size キーワードで指定できる大文字/小文字を区別しない方向オプションについて説明します。

次の表に、 stream_size キーワードで使用できる演算子の説明を示します。

たとえば、クライアントからサーバに移動する 5001216 バイト以上の TCP ストリームを検出するには、 stream_size キーワードの引数として client, >=, 5001216 を使用できます。

TCP ストリーム再構築の有効化と無効化

ライセンス： Protection

stream_reassemble キーワードを使用すると、接続での検査対象トラフィックがルールの条件と一致した場合に、1 つの接続の TCP ストリーム再構築を有効/無効にすることができます。オプションで、このキーワードを 1 つのルール内で複数回使用することができます。

ストリーム再構築を有効または無効にするには、次の構文を使用します。

次の表に、 stream_reassemble キーワードで使用できるオプション引数の説明を示します。

たとえば、次のルールは、HTTP 応答で 200 OK ステータス コードが検出される接続に対してイベントを生成せずに、TCP クライアント側ストリーム再構築を無効にします。

stream_reassemble を使用するには、次の手順を実行します。

ステップ 1 [ルールの作成（Create Rule）] ページで、ドロップダウンリストから [stream_reassemble] を選択して、[オプションを追加（Add Option）] をクリックします。

[stream_reassemble] セクションが表示されます。

セッションからの SSL 情報の抽出

ライセンス： Protection

SSL ルール キーワードを使用すると、Secure Sockets Layer（SSL）プリプロセッサを呼び出し、暗号化セッションのパケットから SSL のバージョンとセッション状態に関する情報を抽出できます。

SSL または Transport Layer Security（TLS）を使用する暗号化セッションを確立するためにクライアントとサーバが通信するとき、ハンドシェイク メッセージが交換されます。セッション中に伝送されるデータは暗号化されますが、ハンドシェイク メッセージは暗号化されません。

SSL プリプロセッサは、特定のハンドシェイク フィールドから状態とバージョンの情報を抽出します。ハンドシェイク内の 2 つのフィールドは、セッション暗号化に使われる SSL または TLS のバージョンとハンドシェイクのステージを示します。

詳細については、次の項を参照してください。

• ssl_state
• ssl_version

ssl_state

ライセンス： Protection

ssl_state キーワードを使用すると、暗号化されたセッションの状態情報と照合することができます。同時に使用される複数の SSL バージョンを検査するには、1 つのルール内で複数の ssl_version キーワードを使用します。

ルールで ssl_state キーワードが使用されている場合、ルール エンジンは SSL プリプロセッサを呼び出して、トラフィック内の SSL 状態情報を検査します。

たとえば、チャレンジ長が非常に長く、データが多すぎる ClientHello メッセージを送信することによってサーバ上のバッファ オーバーフローを引き起そうとする攻撃者の試みを検出するには、 ssl_state キーワードと引数 client_hello を使用し、異常に大きなパケットを検査することができます。

SSL 状態に関する複数の引数を指定するには、カンマ区切りのリストを使用します。複数の引数を列挙した場合、システムは OR 演算子を使ってそれらを評価します。たとえば、引数として client_hello および server_hello を指定すると、システムは client_hello または server_hello のどちらかを含むトラフィックに照らしてルールを評価します。

次のように、引数を否定することもできます。

接続が一連の状態のそれぞれに到達したことを確認するには、ssl_state ルール オプションを使用する複数のルールを使う必要があります。 ssl_state キーワードは、次の識別子を引数として受け入れます。

ssl_version

ライセンス： Protection

ssl_version キーワードを使用すると、暗号化セッションのバージョン情報を照合できます。ルールで ssl_version キーワードが使用されている場合、ルール エンジンは SSL プリプロセッサを呼び出して、トラフィック内の SSL バージョン情報を検査します。

たとえば、SSL バージョン 2 にバッファ オーバーフロー脆弱性があることがわかっている場合、 ssl_version キーワードで sslv2 引数を使用して、その SSL バージョンを使用するトラフィックを識別できます。

SSL バージョンに関する複数の引数を指定するには、カンマ区切りのリストを使用します。複数の引数を列挙した場合、システムは OR 演算子を使ってそれらを評価します。たとえば、SSLv2 を使用していない暗号化トラフィックを識別するには、 ssl_version:ssl_v3,tls1.0,tls1.1,tls1.2 をルールに追加できます。このルールは、SSL バージョン 3、TLS バージョン 1.0、TLS バージョン 1.1、または TLS バージョン 1.2 を使用するトラフィックを評価します。

ssl_version キーワードは、次の SSL/TLS バージョン識別子を引数として受け入れます。

アプリケーション層プロトコル値の検査

ライセンス： Protection

アプリケーション層プロトコル値の正規化と検査はプリプロセッサによってほとんど実行されますが、以下の項で説明するキーワードを使用すると、アプリケーション層値をさらに検査できます。

• RPC
• ASN.1
• urilen
• DCE/RPC キーワード
• SIP キーワード
• GTP キーワード
• Modbus キーワード
• DNP3 キーワード

RPC

ライセンス： Protection

rpc キーワードは、TCP または UDP パケット内の Open Network Computing Remote Procedure Call（RPC ONC）サービスを識別します。これにより、ホスト上の RPC プログラムの識別試行を検出することができます。ネットワークで実行中のいずれかの RPC サービスを悪用できるかどうか判断するために、侵入者は RPC ポートマッパーを使用できます。また、ポートマッパーを使用せずに RPC を実行中の他のポートへのアクセスを試みることもできます。次の表に、 rpc キーワードで使用できる引数を列挙します。

rpc キーワードの引数を指定するには、次の構文を使用します。

ここで、 application は RPC アプリケーション番号、 procedure は RPC プロシージャ番号、 version は RPC バージョン番号です。 rpc キーワードのすべての引数を指定する必要があります。引数のいずれかを指定できない場合は、アスタリスク（ * ）で置き換えてください。

たとえば、任意のプロシージャまたはバージョンの RPC ポートマッパー（100000 という番号で示される RPC アプリケーション）を検索するには、引数として 100000,*,* を使用します。

ASN.1

ライセンス： Protection

asn1 キーワードを使用すると、さまざまな有害エンコードを検索しながら、パケットまたはパケットの一部分をデコードできます。

次の表に、 asn1 キーワードの引数について説明します。

たとえば、Microsoft ASN.1 ライブラリにおける既知の脆弱性ではバッファ オーバーフローが発生し、攻撃者は特別に細工した認証パケットを使ってその状態を悪用できます。システムが asn.1 データをデコードするとき、パケット内のエクスプロイト コードは、システム レベル特権付きでホスト上で動作したり、DoS 状態を引き起したりすることができます。次のルールは、 asn1 キーワードを使用して、この脆弱性を悪用する試みを検出します。

上記のルールの場合、任意のポートおよび $EXTERNAL_NET 変数で定義された任意の IP アドレスから発信され、ポート 445 を使用する $HOME_NET 変数で定義された任意の IP アドレスに向かう TCP トラフィックに対して、イベントが生成されます。加えて、サーバへの TCP 接続が確立された時点でのみルールを実行します。その後、ルールは特定の位置にある特定のコンテンツを検査します。最後に、ルールは asn1 キーワードを使用して、ビットストリング エンコードと二重 ASCII エンコードを検出し、最後に見つかったコンテンツ一致の末尾から 55 バイト目以降、長さ 100 バイトを超える asn.1 タイプ長を識別します（ offset カウンタがバイト 0 から始まることに注意してください。）

urilen

ライセンス： Protection

urilen キーワードと HTTP Inspect プリプロセッサを組み合わせて使用すると、特定の長さ、最大長を下回る、最小長を上回る、または指定された範囲内の URI を HTTP トラフィック内で検査できます。

HTTP Inspect プリプロセッサがパケットを正規化して検査した後、ルール エンジンはルールに照らしてそのパケットを評価し、 urilen キーワードで指定された長さ条件に URI が一致するかどうか判断します。このキーワードを使用すると、URI 長の脆弱性を悪用しようとする試みを検出できます。たとえばバッファ オーバーフローを発生させて、攻撃者が DoS 状態を引き起こしたり、システム レベル特権付きでホスト上でコードを実行したりしようと試みる可能性があります。

ルール内で urilen キーワードを使用するときには、次の点に注意してください。

• 必ず flow:established キーワードおよび他の 1 つ以上のキーワードを組み合わせて、 urilen キーワードを使用してください。
• ルール プロトコルは常に TCP です。詳細については、プロトコルの指定を参照してください。
• ターゲット ポートは常に HTTP ポートです。詳細については、「侵入ルールでのポートの定義」と「定義済みのデフォルトの変数の最適化」を参照してください。

URI 長を指定するときには、10 進のバイト数、「小なり」（<）、および「大なり」（>）を使用します。

次に例を示します。

• 5 バイト長の URI を検出するには、 5 を指定します。
• 5 バイト長を下回る URI を検出するには、 < 5 （1 つの空白文字で区切る）を指定します。
• 5 バイト長を上回る URI を検出するには、 > 5 （1 つの空白文字で区切る）を指定します。
• 3 ～ 5 バイト長の URI を検出するには、 3 <> 5 （ <> の前後に空白文字を 1 つずつ含む）を指定します。

たとえば、eDirectory バージョン 8.8 に同梱されている Novell のサーバ モニタリングおよび診断ユーティリティ iMonitor バージョン 2.4 に既知の脆弱性があるとします。長すぎる URI を含むパケットはバッファ オーバーフローを発生させるため、攻撃者はシステム レベル特権付きでホスト上で動作したり、DoS 状態を引き起こしたりできる特別に細工したパケットを使ってその状態を悪用できます。次のルールは、 urilen キーワードを使用して、この脆弱性を悪用する試みを検出します。

上記のルールの場合、任意のポートおよび $EXTERNAL_NET 変数で定義された任意の IP アドレスから発信され、$HTTP_PORTS 変数で定義されたポートを使用して、$HOME_NET 変数で定義された任意の IP アドレスに向かう TCP トラフィックに対して、イベントが生成されます。加えて、サーバへの TCP 接続が確立された時点でのみ、パケットがルールに照らして評価されます。ルールは、 urilen キーワードを使用して、長さ 8192 バイトを超える URI を検出します。最後に、ルールは、大文字/小文字を区別しない特定のコンテンツ /nds/ を URI で検索します。

DCE/RPC キーワード

ライセンス： Protection

次の表に示す 3 つの DCE/RPC キーワードを使用すると、DCE/RPC セッション トラフィックでエクスプロイトを監視できます。これらのキーワードを含むルールを処理するとき、システムは DCE/RPC プリプロセッサを呼び出します。詳細については、DCE/RPC トラフィックのデコードを参照してください。

表に示されているように、 dce_opnum の前に必ず dce_iface を配置し、 dce_stub_data の前に必ず dce_iface + dce_opnum を配置する必要があることに注意してください。

また、これらの DCE/RPC キーワードを他のルール キーワードと組み合わせて使用することもできます。DCE/RPC ルールでは、 DCE/RPC 引数が選択された状態で byte_jump 、 byte_test 、 byte_extract の各キーワードを使用することに注意してください。詳細については、Byte_Jump と Byte_Test の使用およびパケット データをキーワード引数の中に読み込むを参照してください。

シスコ では、DCE/RPC キーワードを含むルールに 1 つ以上の content キーワードを含めることを推奨しています。こうすると、ルール エンジンが常に高速パターン マッチ機能を使用することで処理速度が上がり、パフォーマンスが向上します。ルールに 1 つ以上の content キーワードが含まれている場合は、 content キーワードの 高速パターン マッチ機能を使用（Use Fast Pattern Matcher） 引数が有効になっているかどうかに関係なく、ルール エンジンが高速パターン マッチ機能を使用することに注意してください。詳細については、「コンテンツ一致の検索」と「高速パターン マッチ機能を使用（Use Fast Pattern Matcher）」を参照してください。

次のケースでは、DCE/RPC バージョンおよび隣接ヘッダー情報を一致コンテンツとして使用できます。

• ルールに他の content キーワードが含まれていない
• ルールにもう 1 つ content キーワードが含まれているが、DCE/RPC バージョンおよび隣接情報が、他方の content よりも特有のパターンを表している

たとえば、DCE/RPC バージョンおよび隣接情報は通常、1 バイトのコンテンツよりも特有です。

次に示すバージョンおよび隣接情報コンテンツ一致のいずれか 1 つを使用して、ルール限定を終了する必要があります。

• コネクション型 DCE/RPC ルールでは、コンテンツ |05 00 00| （メジャー バージョン 05、マイナー バージョン 00、および要求 PDU（プロトコル データ ユニット）タイプ 00 ）を使用します。
• コネクションレス型 DCE/RPC ルールでは、コンテンツ |04 00| （バージョン 04、要求 PDU タイプ 00）を使用します。

いずれの場合も、DCE/RPC プリプロセッサで完了済みの処理を繰り返すことなく高速パターン マッチ機能を呼び出すために、ルール内の最後のキーワードとしてバージョンおよび隣接情報の content キーワードを配置してください。ルールの末尾に配置される content キーワードは、高速パターン マッチ機能を呼び出す手段として使われるバージョン コンテンツに当てはまりますが、ルール内の他のコンテンツ一致には必ずしも当てはまらないことに注意してください。

詳細については、次の各項を参照してください。

• dce_iface
• dce_opnum
• dce_stub_data

dce_iface

ライセンス： Protection

dce_iface キーワードを使用すると、特定の DCE/RPC サービスを識別できます。

オプションで、 dce_iface キーワードを dce_opnum キーワードおよび dce_stub_data キーワードと組み合わせて使用すると、検査する DCE/RPC トラフィックをさらに限定することができます。詳細については、「dce_opnum」と「dce_stub_data」を参照してください。

固定型 16 バイト Universally Unique Identifier（UUID）は、それぞれの DCE/RPC サービスに割り当てられるアプリケーション インターフェイスを識別します。たとえば、UUID 4b324fc8-670-01d3-1278-5a47bf6ee188 は、srvsvc サービスとしても知られる DCE/RPC lanmanserver サービスを識別します。このサービスは、ピアツーピア プリンタ、ファイル、および SMB 名前付きパイプを共有するためのさまざまな管理機能を提供します。DCE/RPC プリプロセッサは UUID および関連するヘッダー値を使用して DCE/RPC セッションを追跡します。

インターフェイス UUID は、次のように、ハイフンで区切られた 5 つの 16 進文字列で構成されます。

次に示す netlogon インターフェイスの UUID のように、ハイフンを含む UUID 全体を入力することで、インターフェイスを指定します。

UUID 内の最初の 3 つの文字列はビッグ エンディアン バイト順で指定される必要があることに注意してください。通常、公開されたインターフェイス リストやプロトコル アナライザには UUID が正しいバイト順で表示されますが、それを入力する前に UUID バイト順を変更しなければならない場合もあります。次に示すメッセンジャー サービス UUID の場合、リトル エンディアン バイト順の最初の 3 つの文字列を含む未加工 ASCII テキストで表示されることがあります。

この同じ UUID を dce_iface キーワードに指定するには、次のようにハイフンを挿入し、最初の 3 つの文字列をビッグ エンディアン バイト順で配置できます。

1 つの DCE/RPC セッションに複数のインターフェイスへの要求を含めることができますが、1 つのルールには 1 つの dce_iface キーワードだけを含めてください。追加のインターフェイスを検出するには、追加のルールを作成します。

DCE/RPC アプリケーション インターフェイスにはインターフェイス バージョン番号も割り当てられます。オプションで、インターフェイス バージョンを指定できます。その際、バージョンが指定値に等しい、等しくない、指定値より小さい、または大きいことを示す演算子を使用します。

TCP セグメンテーションや IP フラグメンテーションに加えて、コネクション型とコネクションレス型の両方の DCE/RPC をフラグメント化することができます。通常、先頭以外の DCE/RPC フラグメントを指定のインターフェイスに関連付けるのはあまり効率的ではありません。このようにすると、多数の誤検出が発生する可能性があります。ただし、柔軟性を維持するために、オプションで、指定されたインターフェイスに照らしてすべてのフラグメントを評価できます。

次の表に、 dce_iface キーワードの引数を要約します。

dce_opnum

ライセンス： Protection

dce_opnum キーワードを DCE/RPC プリプロセッサと組み合わせて使用すると、DCE/RPC サービスが提供する 1 つ以上の特定のオペレーションを識別するパケットを検出できます。

クライアント関数呼び出しは、DCE/RPC 仕様で「 オペレーション 」と呼ばれる特定のサービス関数を要求します。オペレーション番号（opnum）は DCE/RPC ヘッダー内の特定のオペレーションを識別します。エクスプロイトは特定のオペレーションを標的にすることがあります。

たとえば UUID 12345678-1234-abcd-ef00-01234567cffb は、数十種類のオペレーションを提供する netlogon サービスのインターフェイスを識別します。その 1 つがオペレーション 6（NetrServerPasswordSet オペレーション）です。

オペレーション用のサービスを識別するには、 dce_opnum キーワードの前に dce_iface キーワードを指定する必要があります。詳細については、dce_ifaceを参照してください。

特定のオペレーションを示す 1 つの 10 進数値（0 ～ 65535 の範囲）、ハイフンで区切られたオペレーション範囲、またはカンマ区切りのオペレーション/範囲リストを任意の順序で指定できます。

次の例は、すべて有効な netlogon オペレーション番号を表しています。

dce_stub_data

ライセンス： Protection

dce_stub_data キーワードを DCE/RPC プリプロセッサと組み合わせて使用すると、他のルール オプションとは無関係に、スタブ データの先頭からインスペクションを開始するようルール エンジンに指示できます。 dce_stub_data キーワードの後に続くパケット ペイロード ルール オプションは、スタブ データ バッファを基準にして適用されます。

DCE/RPC スタブ データは、クライアント プロシージャ コールと DCE/RPC ランタイム システム（DCE/RPC の中核をなすルーチンとサービスを提供するメカニズム）の間のインターフェイスを提供します。DCE/RPC エクスプロイトは、DCE/RPC パケットのスタブ データ部分で識別されます。スタブ データは特定のオペレーションまたは関数呼び出しに関連付けられているため、必ず dce_stub_data の前に dce_iface と dce_opnum を指定して、関連するサービスとオペレーションを識別してください。

dce_stub_data キーワードには引数がありません。詳細については、「dce_iface」と「dce_opnum」を参照してください。

SIP キーワード

ライセンス： Protection

4 つの SIP キーワードを使用すると、SIP セッション トラフィックでエクスプロイトを監視できます。

SIP プロトコルはサービス拒否（DoS）攻撃に対して脆弱であることに注意してください。このような攻撃に対処するルールでは、レート ベース攻撃の防止を活用できます。詳細については、「動的ルール状態の追加」と「レート ベース攻撃の防止」を参照してください。

詳細については、次の各項を参照してください。

• sip_header
• sip_body
• sip_method
• sip_stat_code

sip_header

ライセンス： Protection

sip_header キーワードを使用すると、抽出された SIP 要求または応答ヘッダーの先頭から検査を開始し、検査対象をヘッダー フィールドに限定することができます。

sip_header キーワードには引数がありません。詳細については、「sip_method」と「sip_stat_code」を参照してください。

次の例のルール フラグメントは SIP ヘッダーを指し示し、CSeq ヘッダー フィールドに一致します。

sip_body

ライセンス： Protection

sip_body キーワードを使用すると、抽出された SIP 要求または応答メッセージ本文の先頭から検査を開始し、検査対象をメッセージ本文に限定することができます。

sip_body キーワードには引数がありません。

次の例のルール フラグメントは SIP メッセージ本文を指し示し、抽出された SDP データの c（接続情報）フィールド内の特定の IP アドレスに一致します。

ルールが SDP コンテンツの検索だけに限定されないことに注意してください。SIP プリプロセッサはメッセージ本文全体を抽出し、それをルール エンジンで使用できるようにします。

sip_method

ライセンス： Protection

各 SIP 要求内の method （メソッド）フィールドは要求の目的を識別します。 sip_method キーワードを使用すると、SIP 要求の中で特定のメソッドを検査することができます。複数のメソッドはカンマで区切ります。

次に示す現在定義されている SIP メソッドを指定できます。

メソッドでは大文字と小文字が区別されません。複数のメソッドをカンマで区切ることができます。

今後、新しい SIP メソッドが定義される可能性があるため、カスタム メソッド、つまり現在定義されている SIP メソッド以外のメソッドを指定することもできます。可能なフィールド値は RFC 2616 で定義されています。 = 、 ( 、 } などの制御文字と区切り文字を除いて、すべての文字を使用できます。除外されている区切り文字の完全なリストについては、RFC 2616 を参照してください。指定されたカスタム メソッドがトラフィックで検出されると、システムはパケット ヘッダーを検査しますが、メッセージは検査されません。

システムでは最大 32 個のメソッド（現在定義されている 21 個のメソッドと追加の 11 個のメソッド）がサポートされます。システムは、設定される未定義のメソッドをすべて無視します。合計 32 個のメソッドには、[Methods to Check] SIP プリプロセッサ オプションを使って指定されるメソッドが含まれることに注意してください。詳細については、SIP プリプロセッサ オプションの選択を参照してください。

否定を使用する場合は、1 つのメソッドだけを指定できます。次に例を示します。

ただし、1 つのルール内の複数の sip_method キーワードが AND 演算で結合されることに注意してください。たとえば、 invite と cancel を除くすべての抽出されたメソッドを検査するには、次のような 2 つの否定付き sip_method キーワードを使用します。

シスコ では、 sip_method キーワードを含むルールに 1 つ以上の content キーワードを含めることを推奨しています。こうすると、ルール エンジンが常に高速パターン マッチ機能を使用することで処理速度が上がり、パフォーマンスが向上します。ルールに 1 つ以上の content キーワードが含まれている場合は、 content キーワードの 高速パターン マッチ機能を使用（Use Fast Pattern Matcher） 引数が有効になっているかどうかに関係なく、ルール エンジンが高速パターン マッチ機能を使用することに注意してください。詳細については、「コンテンツ一致の検索」と「高速パターン マッチ機能を使用（Use Fast Pattern Matcher）」を参照してください。

sip_stat_code

ライセンス： Protection

各 SIP 応答内の 3 桁のステータス コードは、要求されたアクションの結果を示します。 sip_stat_code キーワードを使用すると、SIP 応答の中で特定のステータス コードを検査することができます。

1 桁の応答タイプ番号 1 ～ 9、特定の 3 桁の番号 100 ～ 999、またはこれらを任意に組み合わせたカンマ区切りリストを指定できます。リスト内のいずれか 1 つの番号が SIP 応答内のコードに一致する場合、そのリストが一致します。

次の表に、指定可能な SIP ステータス コード値の説明を示します。

また、ルールに content キーワードが含まれているかどうかに関係なく、 sip_stat_code キーワードを使って指定された値を検索するためにルール エンジンが高速パターン マッチ機能を使用しないことにも注意してください。

GTP キーワード

ライセンス： Protection

3 つの GSRP トンネリング プロトコル（GTP）キーワードを使用すると、GTP バージョン、メッセージ タイプ、および情報要素をコマンド チャネル内で検査できます。 content や byte_jump などの他の侵入ルール キーワードと組み合わせて GTP キーワードを使用することはできません。 gtp_info または gtp_type キーワードを使用するそれぞれのルールで、 gtp_version キーワードを使用する必要があります。

詳細については、次の各項を参照してください。

• gtp_version
• gtp_type
• gtp_info

gtp_version

gtp_version キーワードを使用すると、GTP 制御メッセージの中で GTP バージョン 0、1、または 2 を検査することができます。

定義されているメッセージ タイプと情報要素は GTP バージョンによって異なるため、 gtp_type または gtp_info キーワードを使用するときには、このキーワードを使用する必要があります。値として 0、1、または 2 を指定できます。

GTP バージョンを指定するには、次の手順を実行します。

ステップ 1 [ルールの作成（Create Rule）] ページで、ドロップダウンリストから [gtp_version] を選択して、 [オプションを追加（Add Option）] をクリックします。

gtp_version キーワードが表示されます。

ステップ 2 GTP バージョンを特定するために、 0 、 1 、または 2 を指定します。

gtp_type

それぞれの GTP メッセージは、数値と文字列で構成されるメッセージ タイプによって識別されます。 gtp_type キーワードを gtp_version キーワードと組み合わせて使用すると、トラフィック内で特定の GTP メッセージ タイプを検査できます。

次の例に示すように、メッセージ タイプとして定義済みの 10 進数値、定義済み文字列、あるいはどちらか（または両方）を任意に組み合わたカンマ区切りリストを指定できます。

リスト内のそれぞれの値または文字列を照合するとき、システムは OR 演算を使用します。値と文字列を列挙する順序は重要ではありません。リスト内のいずれか 1 つの値または文字列の一致により、キーワードが一致します。認識されない文字列または範囲外の値を含むルールを保存しようとすると、エラーが発生します。

表に示されているように、GTP バージョンに応じて、同じメッセージ タイプの値が異なる場合があることに注意してください。たとえば sgsn_context_request メッセージ タイプの値は GTPv0 と GTPv1 では 50 ですが、GTPv2 では 130 です。

パケット内のバージョン番号に応じて、 gtp_type キーワードは異なる値と一致します。上記の例の場合、GTPv0 または GTPv1 パケットではキーワードがメッセージ タイプ値 50 と一致しますが、GTPv2 パケットでは値 130 と一致します。パケット内のメッセージ タイプ値が、パケットで指定されたバージョンの既知の値でない場合は、キーワードがパケットと一致しません。

メッセージ タイプに整数を指定した場合、パケット内で指定されたバージョンとは無関係に、キーワード内のメッセージ タイプが GTP パケット内の値と一致すればキーワードが一致します。

次の表に、GTP メッセージ タイプごとにシステムで認識される定義済みの値と文字列を示します。