Cisco ACE XML Gateway ユーザ ガイド
ルールと署名の作成
ルールと署名の作成
発行日;2012/02/01 | 英語版ドキュメント(2009/11/20 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

ルールと署名の作成

概要

メッセージの正規化

受動正規化

normalize() 関数

署名の作成

既存の署名の表示

基本の例

簡易パターンについて

組み込み署名の注意点

カスタム署名のアップロード

一般的な署名作成ガイドライン

署名構文

署名ファイルの例

ルールの作成

既存のルールの表示

カスタム ルールのアップロード

一般的なルール作成ガイドライン

ルール構文

ルール グループ宣言

メッセージ インスペクション ルールの形式

メッセージ リライト ルールの形式

ルール文の形式

ルールと署名の作成

この章では、カスタム Web アプリケーション セキュリティ ルールと署名を開発する方法について説明します。内容は次のとおりです。

「概要」

「メッセージの正規化」

「署名の作成」

「ルールの作成」

概要

Cisco ACE XML ゲートウェイ にはルールと署名の幅広いライブラリが含まれており、Web アプリケーション アウトオブザボックスをセキュリティ保護するために使用できます。クロスサイト スクリプティング攻撃、SQL および LDAP インジェクション攻撃、コマンド インジェクション攻撃など、さまざまな種類のサーバ攻撃を阻止するために組み込みルールが用意されています。

しかしながら、アプリケーションには固有のセキュリティおよびコンテンツのプライバシーの問題が発生することがあります。組み込みリソースでは、アプリケーションや環境に固有の要件すべてに対処できない場合があります。このような場合、Cisco ACE XML ゲートウェイ では、独自のカスタム ルールと署名を作成することができます。この拡張性により、それぞれの要件に合わせて Cisco ACE XML ゲートウェイ の機能を作成できます。

ここで説明するように、カスタム ルールと署名は、Reactor ルール言語を使用して作成します。ルールと署名を Manager にアップロードした後、組み込みルールと同じ方法で Web アプリケーション プロファイルに適用できます。

ほとんどの場合、ルール作成は、新しいまたは遭遇した攻撃パターンに基づいて新しい署名を適用する必要がある場合に行います。このため、ルール作成プロジェクトでは、一般的に新しいルールとともに新しい署名の作成を行います。

署名とルールを作成する一般的な手順は、次のとおりです。

1. ルールで処理または保護するトラフィックに一致する必要のある署名を作成します。

署名とルールはどちらもテキスト ファイルとして作成され、システムにロードされます。ただし、Manager はルールと署名を個別のリソースとして扱うため、別のテキスト ファイルに作成する必要があります。

2. 別のテキスト ファイルにカスタム ルールとルール グループを作成します。ルールは、組み込み署名またはカスタム署名に依存できます。

3. (カスタム署名に依存するルールをロードする前に)署名ファイルを Manager にロードします。Manager はファイルの署名を検証し、Web コンソール ページに問題を表示します。

4. カスタム ルール ファイルをアップロードします。ルールをインポートする場合、Manager はルールで参照される署名がシステムに存在することを確認し、ルールに対してその他の検証チェックを行います。

アップロードされると、カスタム ルールはプロファイルに適用できるようになります。また、ルールは後で Manager インターフェイスから直接変更できます。

この手順では、ルールとともに署名の作成についても説明していますが、新しいルールの作成が新しい署名に依存しない場合もあります。たとえば、未使用の組み込みルールの 1 つを適用する必要のある場合や、組み込みルールによって適用されるのとは異なる方法で組み込み署名を適用する場合などです。通常は、署名を使用しないルールを記述する必要があります。たとえば、データのオーバーフローをチェックするルールを実装するには、次のようなルール文を作成します。

REQUEST_PARAMS.count() gt 100

別の例として、正規表現に対して特定のパラメータをチェックするには、次のような表現で実行できます。

REQUEST_PARAM['username'] nre '[A-Za-z0-9]+'

以降のセクションでは、ルールの作成手順と要件について詳しく説明しています。

メッセージの正規化

ルールを簡単に作成するために、ACE XML Gateway は自動的にメッセージを正規化してから、ルールを評価します。これによって、作成するルールと署名で処理する必要のあるメッセージの種類が少なくなります。たとえば、ISO-8859-1 ベースの攻撃に対して署名やルールのバージョンを作成し、UTF-8 で同じ攻撃に対する別の署名やルールのバージョンを作成する必要はありません。これによって、メッセージ コンテンツもサニタイズできます。

メッセージの正規化は、実際に ACE XML Gateway をパス スルーして宛先に渡されるメッセージには影響しません(ヌルバイトのスクリーニングとヘッダーの展開を除く)。これは、メッセージのコピー、より正確には、REQUEST_PARAMS や REQUEST_URL など、ルール評価に使用される変数を読み込むために使用されるメッセージの値だけに実行されます(「ルール変数」を参照してください)。

正規化自体は出力メッセージを修正しませんが(ヘッダーの空白展開を除く)、カスタム エラー メッセージや HTTP ヘッダー処理など、ポリシーの別のコンテキストで変数を使用すると出力に影響する可能性があります。たとえば、要求の一部を正規化し、発信ヘッダー値を読み込むために使用できます。

メッセージには 2 種類のメッセージ正規化が行われます。1 つ目は 受動正規化 と呼ばれます。これはすべてのメッセージに自動的に行われます。2 つ目の正規化は、 normalize() 関数を使用してルールから直接呼び出されます。

受動正規化

受動正規化は、次のようにメッセージに影響を与えます。

ヌル バイトを含むメッセージは拒否されます(ヌル バイトの存在は、重大エラーとして処理されます。ACE XML Gateway は、400/クライアント エラーに応答し、不正形式の要求を示す警告レベルのイベントを生成します)。

要求 URL(GET 引数を含む)と POST の本文で、Gateway は次を行います。

URL エンコード(つまりパーセント エンコード)文字を UTF-8 エンコード文字にデコードします。ルールと署名の組み合わせで、これは次を意味します。

ASCII 文字の場合、%27 などパーセント エンコード文字(URL エンコード一重引用符)を含む引数と一致するために、カスタム署名は単純に「'」を探します。

アップロードした署名やルールのファイルは UTF-8 形式にする必要がありますが、ルールや署名では Unicode 文字(特定のキリル文字など)を使用できます。これによって正常に一致させられます。

署名で文字以外のデコード値を見つけるには、署名または正規表現に \x09 のような 16 進数の式を入れて、9 を示すバイトを見つけます。

%u エンコード(非正規 Microsoft 使用 Unicode エンコード)文字を UTF-8 にデコードします。

(クエリー ストリング、つまり「?」の後を含まない)要求パスでだけ、Gateway は自己参照(./)や後方参照(../)などの潜在的に不明瞭なパス コマンドを正規化します。これは、トラフィックを仮想 Web アプリケーションと正しく一致させるためにも役立ちます(つまり、「/app/../path」の要求は、「/app」プレフィクス ハンドラと間違って一致するのではなく、実際に「/path」のハンドラと一致します)。

HTTP ヘッダーでGateway は次を行います。

空白展開を適用します( http://www.w3.org/Protocols/rfc822/3_Lexical.html )。ここで複数行のヘッダーは一行に変換されます。


) 空白展開は、出力メッセージに影響する正規化の唯一の特徴です。


Host ヘッダーを除く、その他の HTTP ヘッダーは変更されません。Host ヘッダーの場合、Gateway は URL エンコードまたは %u エンコード値を UTF-8 に変更します。ホスト名は大文字と小文字を区別する方法で評価することを想定してないため、ヘッダー値全体は小文字に変換されます。Host ヘッダーの正規化は Referer ヘッダーのチェックを容易にします。

normalize() 関数

「受動正規化」 で説明している正規化プロセスの目的は、評価されるメッセージ コンテンツで多くの低レベルのエンコード問題に対処するよう署名とルールを記述する必要性を緩和することです。しかし、(要求をハンドラに割り当てるために役立つ)パスの正規化以外、このレベルの正規化に、過剰な空白、エンコードされたエンティティ(<script の代わりの &lt;script の使用など)、コメントによる攻撃ストリングの分割など、高レベルの不明瞭化を避ける目的はありません。

2 つ目のレベルの正規化である 直接正規化 は、まさにこのような不明瞭化を処理することを目的としています。直接正規化を使用するには、次のようにメッセージの一部で normalize() 関数を呼び出します。

VARIABLE [' fieldName '].normalize() op testvalue

次のようになります。

REQUEST_HEADER['My-Header'].normalize(charset|uunicode) re 'attack!'

この場合、HTTP ヘッダーの値、 My-Header は、正規表現「 attack! 」に対してテストされる前に正規化されます。

GET および POST パラメータと POST 本文の場合、ここで説明する正規化プロセスの多くは自動的に適用されるため、この関数で再度適用する必要はありません。ただし HTTP ヘッダー、マルチパート コンテンツ ディスポジションなどは、受動正規化で幅広く正規化されないため、正規化関数で手動の正規化を行います。

normalize() 関数は、GET または POST 引数に自動的に適用されるすべての処理(つまり、URL デコードと %u デコード)を適用できます。さらに、次も可能です。

1. 文字を小文字に変換します。

2. すべての空白実行(あらゆる種類の空白文字)を単一「スペース」の文字に分解します(ASCII 32 に準拠)。

3. HTML/XML コメント(<!-- ... --> の形式)と同様に C 言語と CSS スタイル コメント(/* ... */ の形式)を削除します。これらは、文字シーケンスを遮断することによって攻撃の偽装に使用できます。文字シーケンスは、宛先のパーサーによって最終的に無視される無関係の文字によって正規表現タイプのスキャナによってチェックされます。

4. HTML、16 進数(&#xNN)、および 10 進数(&#N...N;)エンティティをデコードします。

5. \t、\001、\xAA、\hHH、\0OOO などの、JavaScript および C 言語スタイルのエンコードをデコードします。

normalize() の第一の目的は、不明瞭化を防ぐことですが、署名やルールの作成を簡単にすることもできます。たとえば、アトリビュート名とその値の間で任意の数の空白を検出する正規表現を記述する代わりに、0 または 1 スペースと仮定できます。

(例の REQUEST_HEADER['My-Header'].normalize(charset|uunicode) re 'attack!' のように)値に対して式を実行している場合、これに normalize() を実行してもパラメータ Name の値は変わりません。正規化された値は、この特定の正規表現評価のためだけに作成され、使用されます。

一般に、コンテンツベースの署名(コマンド インジェクションなど)を実行する前に、値に normalize() を適用する必要があります。しかし、normalize() を実行すると、攻撃が認識されなくなり、攻撃が未加工の形式でしか捕らえられない場合があります。

また、 normalize() はカスタム エラー応答メッセージやヘッダーなど、コンテンツを出力する仮想 Web アプリケーション設定のどの場所でも使用できます。たとえば、HTTP ヘッダー処理設定で未加工のヘッダーをサニタイズしたバージョンに置き換えられます。つまり、ヘッダー Custom-header の値を REQUEST_HEADER['Custom-header'].normalize() に置き換えます。これにより、メッセージの正規化バージョンは発信要求に反映されませんが、HTTP ヘッダーの処理機能を使用して、発信メッセージに反映されるヘッダーを正規化できます。


) HTTP ヘッダー処理を使用してヘッダー リストを十分に再構築できますが、現時点で GET または POST パラメータを書き換えることはできないことに注意してください。


normalize() 関数を使用するには、パラメータとしてメッセージに適用する正規化の特徴を明らかにする必要があります。サポートされているパラメータは次のとおりです。パイプ演算子(「|」)を使用して複数のパラメータを渡せます。

url:URL デコードを実行します。つまり、% エンコード文字をバイナリに変換します。これによって、通常の読み取り可能な文字や文字以外のバイトになる場合があります。通常、このオプションは charset オプションとともに使用します。

charset :(元のエンコードが ISO-8859-1 であるという前提で)前の手順の文字以外のバイトを UTF-8 エンコードに変換します。このオプションは単独で使用される場合もありますが、一般的に url 引数とともに使用されます(たとえば、HTTP ヘッダーのように、拡張 ASCII インジェクションを調べたい、URL エンコードではない値がある場合)。

uunicode:%u エンコード文字を UTF-8 に変換します。

htmlent:10 進数や 16 進数を含むあらゆる種類のエンティティ(&...;)をエンティティ以外に変換します。

escapes:C スタイルのバックスラッシュエスケープ文字をエスケープ文字以外に変換します。

nullsp:組み込みヌル文字をスペースに変換します。受動正規化時にはヌル バイトを持つ要求は拒否されるため、通常は正規化のこの機能を要求で実行する必要はありません。ただし、これはその他の種類のコンテンツのヌル文字を調べるためのメカニズムとして用意されています。

nullremove:組み込みヌル文字を削除します。受動正規化時にはヌル バイトを持つ要求は拒否されるため、通常は正規化のこの機能を要求で実行する必要はありません。ただし、これはその他の種類のコンテンツのヌル文字を調べるためのメカニズムとして用意されています。

ccomment:C/Javascript スタイル コメントを削除します。

xmlcomment:XML/SGML スタイル コメントを削除します。

backslash:バックスラッシュ \ を削除します。

selfref :自己参照パス(./)を削除します。

backref:後方参照パス(../)を削除します。

trailingslash:末尾のスラッシュをパスから削除します。

white:空白実行を正規化し、単一スペースの文字(ASCII 32)に分解します。

lower:ストリングのすべての文字を小文字に変換します。

署名の作成

署名には、対象のメッセージをルールに一致させるために設計されたコンテンツ パターンが少なくとも 1 つ含まれています。署名に一致するメッセージには、ルール処理が行われます。システムには多数の組み込み署名があります。さらに、ここで説明するように、独自の署名を作成して適用できます。

まず、テキスト ファイルで署名を作成し、その後 Manager にアップロードします。テキスト ファイルには、1 つまたは複数の署名が含まれます。それぞれが署名グループに属している必要があります。図 27-1 に示すように、ルールは署名グループへの参照によって署名を適用します。

図 27-1 ルールセットと署名セット ファイル

 

システムがグループによって署名を組織化する方法について要件を課すことはありませんが、署名を適切に組織化すると、パフォーマンスを最適化しやすくなります。ACE Web Application Firewall は各署名グループを単一の実行可能ユニットにコンパイルするため、単一グループ内の複数の署名は複数のグループの同数の署名より迅速にトラフィックに適用できます。一般的に、特定クラスの攻撃をターゲットとする署名を 1 つの署名グループにまとめてグループ化します。グループ内の特定の署名が指定の Web アプリケーションに適用できない場合、ポリシーの作成者は修飾子を使用して、アプリケーションの適用できない署名を除外できることを覚えておいてください。

署名文は、署名の識別名、そのグループ、その他のいくつかのプロパティで構成されています。プロパティの 1 つは、 regex アトリビュートです。これには、メッセージ コンテンツに適用される正規表現が含まれます。Cisco ACE XML ゲートウェイ の Web アプリケーションのセキュリティ機能によって採用される正規表現の実装は、Perl-Compatible Regular Expressions(PCRE)です。正規表現には、ストリングの終了に相当するドル記号($)やストリングの開始に相当するキャレット記号(^)など、PRCE 正規表現特殊文字を含めることができます。バックスラッシュは特殊文字をエスケープし、単純な文字として評価されるようにします。すべての PCRE 機能がサポートされるわけではありません。特に、取り込んだグループの参照はサポートされません。


) PCRE 構文の詳細については、http://www.pcre.org/pcre.txt を参照してください。


既存の署名の表示

独自の署名やルールを作成する場合、通常、組み込みリソースの 1 つによって提供される例から開始すると簡単です。ポリシーにロードされる署名のソース コードには 2 つのビューがあります。形式化されたビューと未加工のビューです。

形式化されたビューについては、[Rules & Signatures] ページの [View Signatures] ボタンをクリックしてください。システムにロードされている署名グループがすべてウィンドウに表示されます。特定のグループの署名を表示するには、グループのエキスパンダ コントロールをクリックします。展開されると、署名を構成する正規表現パターンのソースが表示されます。

未加工のビューについては、[Rules & Signatures] メニュー リンクをクリックしてから [Manage Signatures] ボタンをクリックします。署名セット リソースの名前をクリックして、新しいブラウザ ウィンドウにリソース ファイルのソース コードを表示します。

署名ソース ファイルを最初に作成する場合は、未加工のビューが便利です。形式化されたビューは、システムで使用されている正規表現パターンでさまざまな攻撃署名をすばやく見つける場合に便利です。

基本の例

署名ソース コード ビューに示すように、基本的な署名宣言は次のようになります。

SQLInjection_m.drop:DROP
regex: ;\s*\bDROP\b
nocase: true
name: DROP

例には drop という署名が 1 つあります。これは、署名グループ SQLInjection_m に属しています。署名名とグループ宣言とともに署名には次のプロパティがあります。

この場合、名前宣言の後には、 簡易パターン 表現「DROP」があります。正規表現で使用すると、この表現は最適化された予備コンテンツ テストとして機能します。簡易パターン表現は、 regex アトリビュートに使用できる正規表現言語機能のサブセットを使用して作成します。詳細については、「簡易パターンについて」を参照してください。

regex は、対象のメッセージ コンテンツに一致させるための正規表現です。正規表現パターンには、単語の境界表現に囲まれた DROP ストリングが含まれます。

nocase は、正規表現が大文字と小文字を区別して適用されるかどうかを示します。デフォルトでは、比較は大文字と小文字を区別せずに実行されます。このアトリビュートを使用し、値を false に設定すると、大文字と小文字を区別した比較を指定できます。

name は、Web コンソール インターフェイスに表示される署名を説明する名前です。

次のように、ルールは署名グループの名前を参照して、署名をトラフィックに適用します。

RULEGROUPNAME.RuleName:REQUEST_ALL sig SQLInjection_m

sig キーワードの後の識別名SQLInjection_m は署名グループを特定します。

以降のセクションでは、署名のさまざまな点について詳しく説明しています。

簡易パターンについて

署名は正規表現を 2 段階でメッセージ コンテンツに適用できます。最初は簡易パターン表現です。メッセージが簡易パターンに一致し、 regex アトリビュートも署名に示されている場合、regex アトリビュートの完全な正規表現がメッセージ コンテンツに適用されます。

簡易パターンは、最適化された機能で、ACE XML Gateway がメッセージを署名に適用不可かどうかすばやく見なすことができるようにします。これは、限定された正規表現のような構文を使用して、メッセージの初期チェックを高速で行います。簡易パターンがメッセージと一致すると、ACE XML Gateway は完全な正規表現を適用します(存在する場合)。どちらの表現も起動するルールに一致する必要があります。署名は簡易パターンまたは regex プロパティを 1 つだけ使用できます。この場合、起動するルール処理に対してメッセージ コンテンツがその表現を満たしているだけでかまいません。


) リライト ルールは、コンテンツの一致に簡易パターン表現しか使用できません。つまり、簡易パターンを使用する署名しか参照できません。


実際には、DROP コマンドの組み込み SQL インジェクション署名に示されるように、簡易パターンは一般的に潜在的な対象のコンテンツを示す最小の文字シーケンスをチェックし、正規表現はコンテンツをより徹底的にテストします。

簡易パターン:DROP

Regex パターン:;\s*\bDROP\b

簡易パターン表現構文は PCRE 構文のサブセットで構成されています。文字の一致以外に、次をサポートします。

任意の文字に一致させるための、「.」(ドット)など、単純な文字クラス ワイルドカード

次を含む定義済みの文字クラス

\d:数字

\D:数字以外

\s:空白

\S:空白以外

\w:単語(アルファベット、数字、またはアンダースコア)

\W:単語以外

ユーザ定義の文字クラス([a-z] など)

16 進数エンコード文字(「a」に対する「\x61」など)

組み込み署名の注意点

次の注意点は、基本設定に含まれ、ルール作成に使用できる組み込み署名に適用されます。

未使用の署名

ほとんどの組み込み署名は組み込みルールの 1 つによって適用されますが、適用されないものもあります。これらは、基本設定に含まれ、カスタム ルールに使用できます。

Quotes.single

Quotes.double

Tab.Tab

SQLComment.dashdash

これらの署名は正規のメッセージにしばしば見られる文字と一致します。たとえば、一重引用符は、O'Neil のようにフォーム データとして入力された姓に表示される場合があります。そのため、これらを使用するのは、使用しているアプリケーション トラフィックに適していると確信している場合や、モニタ モードだけで署名を適用している場合に限定する必要があります。

クレジット カード署名グループ

組み込み署名グループには、さまざまな長さのクレジット カード番号を検索するクレジット カード署名グループがいくつか含まれます。署名が指定の長さの(スペースやハイフンで)適切に区切られた数字のセットに一致することに注意してください。これらは、疑わしいクレジット カード番号の数字のシーケンスが実際に有効なクレジット カード番号であるか確認するために、(Luhn アルゴリズムのような)チェックサム数式を適用しません。

カスタム署名のアップロード

署名の作成が完了したら、これらを Manager にアップロードしてポリシーで使用できるようにします。カスタム署名をアップロードするには、次の手順に従います。


ステップ 1 [Rules & Signatures] ページで [Manage Signatures] ボタンをクリックします。

ステップ 2 [New Signature Resource] ボタンをクリックします。

ステップ 3 署名リソースを説明する名前を入力します。名前は、ポリシー内の署名リソースで一意である必要があります。名前は、署名リソース リストに表示されるため、Web コンソールの他のユーザにもわかりやすくする必要があります。

ステップ 4 [Browse] ボタンをクリックし、ファイル システム上のファイルに移動して、アップロードされた署名を含むファイルを特定します。または、リソースが Web サーバから提供される場合は、その URL を入力します。Web サーバの場所からアップロードされたリソースにはリソース リフレッシュ機能が適用されます。これは、ポリシーの配布でリソースの自動リロードを行います。

ステップ 5 [Upload] をクリックします。Manager はファイルの署名を検証し、検出したエラーを表示します。終了すると、新しいリソースがリソース リストに表示されます。


 

署名がポリシーに正常にロードされた後、ACE XML Gateway によって処理されるメッセージ内の対象コンテンツを特定するために使用できるようになります。

署名リストのリソースの横にある [edit] リンクをクリックし、リソース編集ページの更新したファイルをアップロードするといつでもリソースをアップロードできます。

一般的な署名作成ガイドライン

アップロードした各署名ファイルがポリシー内の 1 つの名前のリソースを構成しています。このため、バージョンコントロールや Manager のポリシー アーカイブ機能の対象となります。

署名ファイル構成の一般的なガイドラインは次のとおりです。

署名ファイルの最初の行は次のとおりである必要があります。

# Cisco Signature File v.<majorversion>.<minorversion>

バージョン番号は、署名を作成したシステム パーサー バージョンに一致する必要があります。現在のリリースでは 1.0 です。

ファイルは改行区切りの形式です。

シャープ記号(#)で行を開始すると、ファイルに 1 行のコメントを追加できます。ファイルに必須の最初の行以外、シャープ記号で開始する行は署名の動作に影響しません。

各署名は、「署名構文」で説明している構文ルールに準拠している必要があります。

署名ファイルで拡張(7 ビット ASCII 以外の)文字を使用するには、テキスト エディタで UTF-8 エンコードを使用するよう署名ソース ファイルを設定する必要があります。

署名構文

署名の定義の形式は次のとおりです。

X-<sig_group_id>.<sig_id>: <quick_pattern>
<attribute-name>: <attribute-value>
<attribute-name>: <attribute-value>
...

上記のコマンドで、

<sig_group_id> は署名が属している署名グループの名前です。組み込みリソースに対して一意になるように、作成する署名グループ名は「X-」で開始する必要があります。「X-」のプレフィクスを含む名前全体は 15 文字以内にしてください。署名グループは個別に宣言する必要はありません。

<sig_id> は署名の識別名です。15 文字以内にしてください。署名グループまたは署名 ID では、文字(大文字と小文字を区別)、数字、アンダースコア文字(_)、およびハイフン文字(-)が使用できます。ID は同じグループの署名間で一意であり、署名を説明するものである必要があります。

<quick_pattern> は、正規表現構文のサブセットを使用して一致するコンテンツを識別するパターン表現です。署名には少なくとも 1 つの簡易パターンおよび正規表現(regex アトリビュート)のどちらかまたは両方が必要です。両方ある場合、簡易パターンが先に評価されます。メッセージに一致した場合、最終チェックとして regex パターンが一致した部分と比較されます。

署名のすべての行でコロン間の空白とトークンの後の最初の空白以外の文字はスキップされます。新規行までのその他の空白にはすべて意味があります。

署名には、次のオプションのアトリビュートを入れることができます。

regex、メッセージ コンテンツの一致のために使用される PCRE スタイルの正規表現。regex アトリビュートはオプションですが、署名には regex または簡易パターンが少なくとも 1 つ必要です。

name、Web コンソールに表示される署名を説明する名前。

cve は、署名が処理する脆弱性を説明するオプションの Common Vulnerabilities and Exposures(CVE)識別名です。この情報は署名を記述する場合に役立ちます。

nocase は、正規表現の比較で大文字と小文字を区別するかを指定します。デフォルトでは、比較は大文字と小文字を区別せずに実行されます。このアトリビュートを使用して false に設定すると、大文字と小文字を区別して評価できます。

各アトリビュートはそれぞれの行に記述し、前に 1 つまたは複数の空白を入れる必要があります。アトリビュートはオプションですが、Web コンソールで使いやすいようにどの署名にも name アトリビュートを使用することを推奨します。

Manager と正しく相互運用できるように、署名の固定文字部分は 31 文字以内にしてください。

署名グループ識別名はポリシー内で一意である必要がありますが、署名識別名はグループのコンテキスト内で一意であるだけでかまいません。ルールは個々の署名を完全修飾署名 ID によって参照できます。これは、<SigGroupID>.<SigID> のようにグループと署名の ID の両方で構成されます。ただしほとんどの場合、ルールは署名グループ全体を参照します。

署名ファイルの例

署名リスト ファイルの例は次のとおりです。

例 27-1 署名リスト ファイル

# Cisco Signature File v. 1.8
# Copyright Cisco Systems, Inc. All Rights Reserved

X-NextThreat_b.exec:exec
regex: ;\s*\bexec\b
nocase: true
name: exec nextthreat command attack
X-NextThreat_b.kick: kick
nocase: true
name: kick nextthreat command attack
X-NextThreat_m.start:start
nocase: true
name: start nextthreat command attack
X-NextThreat_m.cmd: cmdshell
nocase: true
name: cmdshell nextthreat command attack
X-PastThreat_m.cmd: dial
nocase: true
name: dial command attack
X-Privacy.USSocialSec:\d\d\d-\d\d-\d\d\d\d
name: Social Security number screening

例では、X-NextThreat_b、X-NextThreat_m、X-PastThreat_m、および X-Privacy という 4 つの署名グループを作成します 組み込み署名の表記に従って、署名グループには、basic には「b」、moderate「m」など、グループの重大度の最初の文字を使ったグループ名が付けられます。

例では nocase アトリビュートを true(つまり、署名が大文字と小文字を区別せずに適用される)に設定していますが、これはデフォルトの比較モードであるため、このアトリビュートを必ずしも true に設定する必要はありません。

「カスタム署名のアップロード」に説明しているように、例 27-1 のテキストをテキスト ファイルにコピーして、Manager にロードすると、例をロードできます。署名をロードした後、カスタム ルールで適用できます。

ルールの作成

ルールは、メッセージ コンテンツに適用される署名を指定します。カスタム メッセージ インスペクション ルールとメッセージ リライト ルールがサポートされています。メッセージ インスペクション ルールは要求にだけ適用できます。これに対し、メッセージ リライト ルールは応答メッセージにだけ適用できます。

ルールには、ルール処理の条件を定義する表現が含まれます。ほとんどの場合、表現はチェックされるメッセージの一部の識別名とチェックに使用される署名へのリファレンスで構成されます。また、関数、演算子、またはその他の高度な機能を含めることもできます。

署名と同様に、カスタム ルールもテキスト ファイルで作成されます。これは Manager にアップロードされると、Manager のネームド リソースを構成します。ルール ファイルは Manager で単一のリソースとして扱われるため、多くのアプリケーションに対して多数のルール グループを作成する必要がある場合は、複数のソース ファイルにまたがってルール グループを組織化すると有効です。

次の例は、ルール セット ファイルの形式を示しています。

例 27-2 ルール セット ファイルの形式

# Cisco Rule File v. <major_version>.<minor_version>
 
GROUP X-<rulegroup_id>:<rulegroup_name>
 
X-<rulegroup_id>.<rule_name>:<message_inspection_scope> sig <siggroup_name>
name: <rule_descriptive_name>
sev: <severity_level>

ルール セット ファイルは最初の行としてシスコ ルール ファイル宣言で始まる必要があります。バージョン番号はルールが記述されたルール セット パーサーのバージョンを反映する必要があります。ルール パーサーの現在のバージョンは 1.0 です。GROUP キーワードはルール グループを宣言します。これには、1 つまたは複数のルールを含めることができます。

ユーザが作成した署名グループとルール グループは、組み込みルール グループと同じにならないように「X-」文字で始まる必要があります。ルール定義は、所属するグループを宣言して開始します。その後、調査するメッセージの一部と調査に使用する署名を指定します。

例 27-3 ルール セット ファイルの例

# Cisco Rule File v. 1.0

# Group declarations
GROUP X-InspectRules: My Inspection Rule group
GROUP X-RewriteRules: My Message Rewrite Rule group

# rule declarations
X-InspectRules.NextThreat1:REQUEST_PARAM_ALL sig X-NextThreat_b
name: Parameter inspection for Next Threat
sev: 0

X-InspectRules.NextThreat2:REQUEST_HEADER sig X-NextThreat_b
name: Header inspection for Next Threat
sev: 0

X-InspectRules.NextThreat3:REQUEST_ALL sig X-NextThreat_m | X-PastThreat_m
name: Closer Inspection for Next Threat
sev: 1

# rewrite rules
X-RewriteRules.SsnMask: rewrite X-Privacy
name: Prevents SSN leak
rewriteChar: X
desc: Finds and rewrites SSN

例では、3 つのメッセージ インスペクション ルールとメッセージ リライト ルールを定義しています。メッセージ インスペクション ルールには、重大度プロパティ、 sev が含まれていることに注意してください。ルールの sev 値では、プロファイルが重大度に応じて 0(基本)、1(中程度)、または 2(厳密)という値で選択的にルール グループのルールを適用できます。メッセージ リライト ルールには rewriteChar 値が含まれます。これはメッセージ内の一致したコンテンツの各文字に置き換えるために使用されます。

最初の 2 つのメッセージ インスペクション ルールは、署名を調べるメッセージの一部によって識別されます。

「カスタム ルールのアップロード」に説明しているように、例 27-3 のテキストをテキスト ファイルにコピーして、Manager にロードすると、ルールの例をロードできます。ルールをロードする前に、例 27-1 の署名をアップロードする必要があります。ルールをロードした後、プロファイルでこれらを適用できます。

既存のルールの表示

署名と同様に、独自のルールを作成する場合、組み込みルール定義によって提供された例から開始すると便利です。ルール定義を表示するには、[Rules & Signature] ページでルールの横の [Details] リンクをクリックしてから、詳細ページの下部の [View Source] ボタンをクリックします。ルール セットの未加工のソース コードが表示されます。

カスタム ルールのアップロード

次に説明するように、ルールの作成が完了したら、これらを Manager にアップロードしてポリシーで使用できるようにする必要があります。

カスタム ルール ファイルをアップロードするには、次の手順に従います。


ステップ 1 [Rules & Signatures] ページで [New Custom Rules] ボタンをクリックします。

ステップ 2 ルール リソースを説明する名前を入力します。名前は、ポリシー内のルール リソースで一意である必要があります。名前は、ルール リソース リストに表示されるため、Web コンソールの他のユーザにもわかりやすくする必要があります。

ステップ 3 外部テキスト ファイルからルールをロードするには、[Browse] ボタンをクリックし、ファイル システム上のファイルに移動して、ファイルを特定します。

ステップ 4 [Load File Contents] ボタンをクリックします。

ルール ソース コードが [Rule Definitions] フィールドに表示されます。ルール ソース コードはこのフィールドに直接入力またはペーストできますが、ほとんどの場合、外部テキスト ファイルからロードされることに注意してください。

ステップ 5 必要であれば、[Rule Definitions] フィールドでルール ソース コードを直接変更できますが、このフィールドで行った変更は元のルール ソース ファイルへは反映されないことに注意してください。

ステップ 6 [Save Changes] をクリックします。

Manager がルールを検証します。検証エラーはページの最上部に表示されます。たとえば、ルールがロードされていない署名を参照していると、ルールの検証にエラーが発生します。


 

図 27-2 に示すように、カスタム ルールは Web コンソール ページに表示されるようになります。これらはプロファイルにもリストされます。ここで、ネットワーク トラフィックに適用できるようイネーブルにできます。

図 27-2 Web コンソールでのカスタム ルール

 

[Rules & Signatures] ページでカスタム ルールの名前の横にある [Details] リンクをクリックして、リソースのソース コードを表示できます。ポリシーにロードした後、詳細ページの下部にある [Edit Rule File] ボタンをクリックすると、ルール ソース コードは修正可能になります。ルール ファイルを編集して、新しいルールの追加、修正、ルール セット リソースからのルールの削除ができます。ルール グループを削除すると、ルール グループがイネーブルになっているものも含めすべてのプロファイルで使用できなくなります。

一般的なルール作成ガイドライン

アップロードした各ルール ファイルがポリシー内の 1 つの名前のリソースを構成しています。このため、バージョンコントロールや Manager のポリシー アーカイブ機能の対象となります。ルール ファイル構成の一般的なガイドラインは次のとおりです。

ルール ファイルの最初の行は次のとおりである必要があります。

# Cisco Rule File v.<majorversion>.<minorversion>

バージョンは、ルールを作成したシステムのパーサー バージョンに一致する必要があります。現在のリリースでは 1.0 です。

シャープ記号(#)で行を開始すると、ファイルに 1 行のコメントを追加できます。ファイルに必須の最初の行以外、シャープ記号で開始する行はルール セットの動作に影響しません。

ルール セットには 新規行区切り宣言の形式で、1 つまたは複数のルールとルール グループの宣言が含まれます。

管理性のために、リライト ルールとメッセージ インスペクション ルールは同じグループにできません。

ルール ファイルのほとんどの要素には desc プロパティを使用できます。これは、Manager ユーザ インターフェイス内の項目をドキュメントに提供するためのものです。

重大度は sev アトリビュートによって示されます。可能な値は 0(基本)、1(中程度)、2(厳密)です。

ルール構文

以前に述べたように、Web アプリケーション セキュリティに対して次の 2 種類のルールを作成できます。

メッセージ インスペクション ルール

メッセージ リライト ルール

2 種類の構文は若干異なります。しかし、どちらも属しているルール グループの特定から始まり、次のようにピリオドの後にルールの独自の識別名が続きます。

SQLINJECTION.SqlInjection1:REQUEST_ALL sig SQLInjection
...

例では、 SqlInjection1 という名前の新しいルールは、ルール グループ SQLINJECTION で宣言されています。名前の後はコロン(:)、ルール文が続きます。これには適用する署名とともに調査するメッセージの一部が含まれます。

この例はメッセージ インスペクション ルールです。メッセージ リライト ルールも、識別名の同様の配置で始まります。しかし、コロンの後にキーワード rewrite が続きます。

以降のセクションでは、メッセージ構文について詳しく説明しています。

ルール グループ宣言

グループ宣言はルール グループのプロパティを定義します。グループ宣言に適用できる唯一のプロパティは説明プロパティである desc です。

ルール宣言にルール グループ ID 参照の GROUP 宣言がない場合、ルール グループが自動的に作成されることに注意してください。名前はその ID と同じ値に設定され、説明は空白なります。

ルール グループは次の形式で宣言されます。

GROUP X-<rule_group_id>: <group name>
<wsp>desc: <description><newline>

宣言は、次の構成要素で成り立っています。

GROUP:文をグループ定義として特定するキーワード。

<rule_group_id>:ルール グループの識別名。識別名には次の特徴があります。

組み込みルール グループに対して一意になるように、グループ識別名は「X-」で始まる必要があります。

識別名は、必要な「X-」のプレフィクスを含む 15 文字以内にする必要があります。

ルール グループの識別名はすべてのルール グループで一意である必要があります。

識別名に使用できる文字は、大文字、小文字、数字、アンダースコア文字(_)、およびハイフン文字(-)です。

<group_name>:Manager インターフェイスで使用するルール グループのユーザフレンドリな名前(たとえば、「SQL Injection」など)。

<wsp>:グループ宣言アトリビュートの前の空白またはタブ(サポートされているグループ アトリビュートは desc だけです)。

<description>:ルール グループの説明。この説明は、ルール ファイルがアップロードされた後、ユーザ インターフェイスに表示されます。

メッセージ インスペクション ルールの形式

メッセージ インスペクション ルールは、次の形式を使用します。

<rule_group_id>.<rule_id>: <rule_statement>
<attribute-name>: <attribute-value>
<attribute-name>: <attribute-value>
...

ルールは、次で成り立っています。

<rule_group_id>:ルールが属しているルール グループの識別名。グループに個別のルール グループ定義がない場合、ルール グループが作成されます。組み込みルール グループに対して一意になるように、作成するグループ名は「X-」で開始する必要があります。「X-」のプレフィクスを含む名前全体は 15 文字以内にしてください。

<rule_id>:ルールの識別名。識別名には次の特徴があります。

ID は 15 文字以内にする必要があります。

ルール ID はグループ内のすべてのルールで一意である必要があります。

ID に使用できる文字は、大文字と小文字を区別した文字、数字、アンダースコア(_)、およびハイフン(-)です。

<rule_statement>:有効な Reactor 表現文を定義するストリング。この文の詳細については、「ルール文の形式」を参照してください。

ルール アトリビュート:ルールには、名前と値のペアの形式でルール アトリビュートを使用できます。各アトリビュートはそれぞれの行を占有し、前に 1 つまたは複数の空白を入れる必要があります。アトリビュートは、アトリビュート名の後にコロンを付け、アトリビュート値の後に改行を入れる形式です。

メッセージ インスペクション ルールは、次のアトリビュートを使用できます。

name:ルールのユーザフレンドリな名前。

desc:Web コンソール ユーザにルールを説明するルールの説明。

severity :ルールの重大度。重大度を使用する場合、複数のレベルの厳密性または徹底さで特定のセキュリティ タスクを処理する複数のルールを定義します。プロファイルはその後、特定のバックエンド アプリケーションに必要な重大度でルールを適用できます。

メッセージ リライト ルールの形式

メッセージ リライト ルールは、メッセージ全体に機能するのではなく、署名に一致するメッセージ コンテンツの一部を修正します。1 つのメッセージで署名が複数回一致する場合もあります。これらのルールは一般的にメッセージ内の機密情報を特定し、上書きするために使用されます。

リライト ルールは、コンテンツの一致に簡易パターン表現しか使用できません。詳細については、「簡易パターンについて」を参照してください。

メッセージ リライト ルールは、次の形式です。

<rule_group_id>.<rule_id>: rewrite <sig_group_id>
<attribute-name>: <attribute-value>
<attribute-name>: <attribute-value>
...

ルールは、次で成り立っています。

<rule_group_id>:ルールが属しているルール グループの識別名。グループに個別のルール グループ定義がない場合、ルール グループが作成されます。

<rule_id>:ルールの識別名。識別名には次の特徴があります。

ID は 15 文字以内にする必要があります。

ルール ID はグループ内のすべてのルールで一意である必要があります。

ID に使用できる文字は、大文字と小文字を区別した文字、数字、アンダースコア(_)、およびハイフン(-)です。

rewrite:rewrite キーワードはルールをメッセージ リライト ルールとして識別します。

<sig_group_id>:このルールで適用する署名の署名グループの識別名。署名は、このルールが適用されるメッセージ内でリライトされるコンテンツを決定します。

リライト ルールは、DFA 表現を使用する署名しか適用できません。PCRE 表現は適用できません。このため、正規表現「\d{4,6}」は使用できず、それぞれが異なるパターンの長さに対する 3 つの異なる署名に置き換える必要があります。

ルール アトリビュート:ルールには、名前と値のペアの形式でルール アトリビュートを使用できます。各アトリビュートはそれぞれの行を占有し、前に 1 つまたは複数の空白を入れる必要があります。アトリビュートは、アトリビュート名の後にコロンを付け、アトリビュート値の後に改行を入れる形式です。

リライト ルールは、次のアトリビュートを使用できます。

name:ルールのユーザフレンドリな名前。

desc:Web コンソール ユーザにルールを説明するルールの説明。

rewriteChar:署名内の一致したパターンに置き換えるために使用される値。rewriteChar は、一致したパターンのすべての文字に対して 1 回書き換えられます、このため、置き換える文字が「x」の場合、次の一致文字 123-456-789-1011 は xxxxxxxxxxxxxxxx に書き換えられます。

ルール文の形式

ルール文は一般的に条件式で、true になるとルール処理が起動します。ルール文はルール ID に続くコロンの後に表示されます。

<rule_group_id>.<rule_id>: <rule_statement>

ルール文の形式は次のとおりです。

<variable-expr> <operator> <test-value>

次に例を示します。

REQUEST_PARAM_ALL sig X-NextThreat_b

この場合、 sig は演算子です。これは、署名または署名グループ名によって指定されたテスト値(X-NextThreat_b)をテストする値(すべてのパラメータ)に適用します。ルール文はルールの一致以外の要因に基づいてテストを構成できます。たとえば、次の文は要求パラメータの数をチェックします。

REQUEST_PARAMS.count() gt 128

例は、要求内のパラメータ数が 128 を超えるかどうかをテストします。true の場合は、ルール処理が起動します。これは、次で構成されています。

変数、REQUEST_PARAMS

関数、count()、および

演算子、gt

これらのルール表現機能は、ここでリストしているように、カスタム ルール動作の定義で非常な柔軟性を発揮します。

ルールの演算子

ルール変数

ルール関数

ルールの演算子

次の演算子は特定のテストとテストされる値にバイナリ テストを適用します。テストが false になると、テストされたコンテンツはルールの適用外になります。次の表にルールの演算子を示します。

表 27-1 ルールの演算子

 

演算子
テストされる値が次の場合に True

eq

等しい

gt

より大きい

gte

より大きいまたは等しい

lt

より小さい

lte

より小さいまたは等しい

re

正規表現

nre

正規表現以外

sig

SignatureGroup の名前である値を持つ署名グループ

ルール変数

ルール変数によってランタイム情報にアクセスできます。たとえば、要求パラメータ、ヘッダー、クライアント IP などのクライアント情報に対する変数が存在します。変数によって、これらのランタイム値に基づいてルール条件を作成できます。

ルール構成に加え、変数はポリシーの他のエリアでも使用できます。たとえば、HTML 応答でこの形式($(varname))で変数を参照し、カスタム エラー応答メッセージに含めることができます。また、これらはヘッダー処理フィールドで使用できるため、変数値は HTTP ヘッダーとして発信メッセージに追加できます。


) ルールを作成する場合、カスタム エラー応答でルール変数をテストすると、トラフィックの各変数によって返される値のタイプをすばやく発見するのに役立つ場合があります。


特定の変数によって、次の形式で要求に関連付けられたネームド パラメータの値にアクセスすることができます。

VARIABLE_NAME['param']

ここで、 param は Web フォーム変数の名前です。

次に例を示します。

REQUEST_HEADER['Referer'] sig CrossScript_m

この場合、HTTP 要求ヘッダー Referer は CrossScript_m の署名に対するコンテンツの一致が具体的にチェックされます。要求パラメータ値は、パラメータの名前を渡し、POST 形式で識別されるのと同様の方法で取得できます。

次の表に、ルール作成に使用できる変数を示します。例の戻り値が示されている場合、次の要求 URL に基づいて戻されます。

http://example.com:8080/details.do?v1=value1&v2=value2&v3=value3

表 27-2 ルール変数

 

変数
説明

CLIENT_IP

ドット付きの 4 つの数字列形式で要求を作成するクライアントの IP。

CLIENT_PORT

クライアントが要求を作成するリスニング ポート。

SERVER_IP

ドット付きの 4 つの数字列形式でルーティングするサーバの IP。

SERVER_PORT

処理される宛先サーバのリスニング ポート。

REQUEST_ALL

それぞれ名前値形式の URL パス、すべてのパラメータ、すべてのヘッダーのコレクション(該当する場合)。

REQUEST_LINE

方式と HTTP バージョンを含む完全な要求行。

REQUEST_URL_RAW

次のような、正規化前の要求 URL。

/details.do?v1=value1&v2=value2&v3=value3

REQUEST_URL_FULL

次のような、正規化後の完全な要求 URL。

/details.do

REQUEST_QUERY_RAW

要求のクエリー ストリング部分。クエリー ストリングは、次のような要求 URL の疑問符の後の部分です。

v1=value1&v2=value2&v3=value3

REQUEST_URL_PATH

次のような、要求 URL のパス部分。

/details.do

REQUEST_URL_HOST

要求 URL のホスト部分(存在する場合)。

REQUEST_HOST

URL または Host ヘッダーからの要求のホスト。

REQUEST_PARAM

次のような、パラメータ名に入力された正規化後のすべてのパラメータ値のコレクション(メッセージに GET と POST 引数の両方が含まれる場合、どちらも存在します)。

value1, value2, value3

REQUEST_PARAM_NAMES

すべてのパラメータ名のコレクション。

REQUEST_PARAM_ALL

次のような、パラメータ名に入力されたすべてのパラメータ名と値のコレクション。

v1, v2, v3, value1, value2, value3

REQUEST_GETPARAM

次のような、パラメータ名に入力された正規化後のすべての GET パラメータ値のコレクション。

value1, value2, value3

REQUEST_GETPARAM_NAMES

パラメータ名に入力されたすべての GET パラメータ名のコレクション。

REQUEST_GETPARAM_ALL

次のような、パラメータ名に入力されたすべての GET パラメータ名と値のコレクション。

v1, v2, v3, value1, value2, value3

REQUEST_POSTPARAM

パラメータ名に入力された正規化後のすべての GET パラメータ値のコレクション。

REQUEST_POSTPARAM_NAMES

パラメータ名に入力されたすべての GET パラメータ名のコレクション。

REQUEST_POSTPARAM_ALL

パラメータ名に入力されたすべての GET パラメータ名と値のコレクション。

REQUEST_HEADER

ヘッダー名に入力された、すべての要求ヘッダー値のコレクション。

REQUEST_HEADER_NAMES

すべての要求ヘッダー名のコレクション。

REQUEST_HEADER_ALL

ヘッダー名に入力された、すべての要求ヘッダー名と値のコレクション。

COOKIE

クッキー名に入力されたクッキー値。

COOKIE_NAMES

すべてのクッキー名の順序付きリスト。

COOKIE_ALL

名前に入力されたすべてのクッキー名と値のコレクション。

REQUEST_METHOD

要求方式。

REQUEST_VERSION

要求 HTTP バージョン。

REQUEST_LENGTH

要求の長さ。

AUTH_RAW

方式と Base64 領域を含む、Authorization ヘッダーの未加工のデータ。

AUTH_METHOD

(Basic など、Authorization ヘッダーの)認証方式。

AUTH_USER

Authorization ヘッダーの Username 値。

AUTH_PASSWORD

Authorization ヘッダーの Password 値。

AUTH_DATA

Authorization ヘッダーのデータ、つまり、Auth 方式後の値。

SSL_CIPHER

クライアント SSL 接続に使用する暗号。

SSL_CERT

PEM エンコードクライアント証明書(存在する場合)。

SSL_CERT_VERIFIED

クライアント証明書が検証されたかどうかを示すブール値。

SSL_CERT_REVOKED

クライアント証明書が失効したかどうかを示すブール値。

SSL_DIGEST_SHA1

クライアントの SSL 証明書の SHA1 ダイジェスト(存在する場合)。

SSL_SUBJECT_DN

クライアントの SSL 証明書のサブジェクト認定者名(存在する場合)。

SSL_ISSUER_DN

クライアントの SSL 証明書の発行元認定者名(存在する場合)。

SSL_SUBJECT_ALTNAME

クライアントの SSL 証明書のサブジェクト代替名(存在する場合)。

SSL_SUBJECT_KEYID

クライアントの SSL 証明書のサブジェクト キー識別名(存在する場合)。

SSL_PEER_CERT_EXTENSION

名前に入力されたクライアントの SSL 証明書の拡張値のコレクション。

SSL_PEER_CERT_EXTENSION_OID

OID に入力されたクライアントの SSL 証明書の拡張値のコレクション。

SSL_PEER_CERT_EXTENSION_NAMES

名前に入力されたクライアントの SSL 証明書の拡張名のコレクション。

SSL_FINGERPRINT_CHAIN

クライアントの SSL CA 検証チェーン内のフィンガープリントの順序付きリスト。

SSL_VERSION

SSL セッションのバージョン。「TLSv1」、「SSLv2」、「SSLv3」のいずれかまたは空白のストリング。

REQUEST_MULTIPART_HEADERS

名前に入力された、マルチパート/フォームデータ メッセージのパートのすべてのヘッダーのコレクション。パートはすべて 1 つのコレクションに集約されるため、REQUEST_MULTIPART_HEADERS['Content-type'] はすべてのパートのコンテンツ タイプを返します。

REQUEST_MULTIPART_DISPOSITIONS

マルチパート/フォームデータ メッセージのすべてのパートの Content-Disposition ヘッダーの単純値。これは、一般的に「form-data」です。

REQUEST_MULTIPART_DISPOSITION_NAMES

マルチパート/フォームデータ メッセージのすべてのパートのすべての Content-Disposition ヘッダーの名前パラメータ。

REQUEST_MULTIPART_DISPOSITION_FILENAMES

マルチパート/フォームデータ メッセージのすべてのパートのすべての Content-Disposition ヘッダーのファイル名パラメータ。

REQUEST_BODY_RAW

正規化前の要求の本文部分。

REQUEST_BODY_XML

XML コンテンツとしての要求の本文部分。

RESPONSE_HEADER

ヘッダー名に入力された、すべての応答ヘッダー値のコレクション。

RESPONSE_HEADER_NAMES

すべての応答ヘッダー名のコレクション。

RESPONSE_HEADER_ALL

ヘッダー名に入力された、すべての応答ヘッダー名と値のコレクション。

REQUEST_PATH_AND_QUERY_RAW

正規化前の要求 URL のリソース パスおよびクエリー部分。

ルール関数

ルール関数は、ルールが評価される前に、特別な処理操作をルール値に適用します。

ルール構成には、次の関数が使用できます。これらは、カスタム エラー応答テキストやヘッダー処理フィールドなど、ポリシーのその他のコンテキストでも使用できることに注意してください。関数をエラー応答の変数値に適用するには、$( REQUEST_PARAMS.count()) のように $(varname.function) の形式でこれらを入力します。

表 27-3 ルール関数

 

関数
説明

count()

REQUEST_PARAMS.count() など、変数によって特定される項目の数を返します。

size()

変数によって参照される項目の合計サイズを返します。

maxsize()

変数によって参照される項目の最大値のサイズを返します。

urlencode()

変数によって参照されるすべての値をそれらの URL エンコード値に変換します。

normalize(expr)

expr パラメータによって指定された、正規化された項目。値を正規化することによって、関数はこれを標準的な形式に変換し、任意の変化や有害な可能性のあるコンテンツを削除します。詳細については、「normalize() 関数」を参照してください。