フィールドフォーマットのチェック
フィールド形式チェックは、ユーザーが Web フォームで Web サイトに送信するデータを検証します。データの長さと種類の両方を調べて、データが表示されるフォームフィールドに適していることを確認します。Web App Firewall は、ユーザーリクエストで不適切な Web フォームデータを検出すると、リクエストをブロックします。
フィールドフォーマットチェックは、攻撃者が不適切な Web フォームデータを Web サイトに送信するのを防ぐことで、Web サイトやデータベースサーバーに対する特定の種類の攻撃を防ぎます。たとえば、特定のフィールドでユーザーが電話番号を入力する必要がある場合、フィールド形式チェックはユーザーが送信した入力を調べて、データが電話番号の形式と一致していることを確認します。特定のフィールドにファーストネームが必要な場合、フィールドフォーマットチェックにより、そのフィールド内のデータがファーストネームに適したタイプと長さであることを確認します。保護するように設定した各フォームフィールドに対して同じ処理を行います。
このチェックは HTML リクエストにのみ適用されます。XML 要求には適用されません。HTML プロファイルまたは Web 2.0 プロファイルでフィールド形式チェックを設定して、HTML ペイロードを検査してアプリケーションを保護できます。Web App Firewall は、Google Web Toolkit（GWT）アプリケーションのフィールドフォーマットチェック保護もサポートしています。
フィールドフォーマットチェックでは、1 つ以上のアクションを有効にする必要があります。Web App Firewall は送信された入力を調べ、指定されたアクションを適用します。
注
フィールド形式のルールはルールを厳しくしています。学習したデータからそれらをリラクゼーションリストに追加すると、ブロッキングルールとして機能します。
フィールドフォーマットのルールを緩和するには、特定の「フィールド名」をフィールドフォーマット緩和リストから削除してください。
デフォルトのフィールド形式を設定して、保護する各ウェブフォームの各フォームフィールドに必要なフィールドタイプとデータの最小長と最大長を指定できます。緩和ルールを適用して、特定のフォームの個々のフィールドのフィールド形式を設定できます。複数のルールを追加して、フィールド名、アクション URL、およびフィールド形式を指定できます。フィールド形式を指定して、さまざまなフォームフィールドでさまざまなタイプの入力を受け入れます。学習機能では、緩和ルールに関する推奨事項を提示できます。
フィールドフォーマットアクション-ブロック、ログ、統計、学習アクションを有効にできます。フィールドフォーマットチェック保護を有効にするには、これらのアクションのうち少なくとも 1 つを有効にする必要があります。
- [ブロック]。ブロックを有効にすると、入力が指定されたフィールド形式に従わない場合にブロックアクションがトリガーされます。ターゲットフィールドにルールが設定されている場合、入力は指定されたルールと照合されます。それ以外の場合は、デフォルトのフィールド形式仕様と照合されます。フィールドタイプまたは最小/最大長の指定に不一致があると、リクエストがブロックされます。
- ログ。ログ機能を有効にすると、フィールド形式チェックによって実行されたアクションを示すログメッセージが生成されます。ログを監視して、正当な要求に対する応答がブロックされているかどうかを判断できます。ログメッセージの数が大幅に増えている場合は、悪意を持って攻撃を仕掛けようとしている可能性があります。
- 統計情報。有効にすると、統計機能が違反とログに関する統計を収集します。統計カウンタが予期せず急増した場合は、アプリケーションが攻撃を受けている可能性があります。また、設定を見直して、指定したフィールド形式の制限が厳しすぎないかどうかを確認する必要がある場合もあります。
- 学ぶ。どのフィールドタイプや最小長と最大長の値がアプリケーションに最適かわからない場合は、学習機能を使用して、学習したデータに基づいて推奨事項を生成できます。Web App Firewall 学習エンジンはトラフィックを監視し、観測された値に基づいて推奨されるフィールド形式を提供します。パフォーマンスを損なうことなく最適な効果を得るには、学習オプションを短時間有効にしてルールの代表的なサンプルを取得し、ルールを展開して学習を無効にすることをお勧めします。 注:Web App Firewall の学習エンジンは、名前の最初の 128 バイトしか区別できません。フォームに、最初の 128 バイトに一致する名前のフィールドが複数ある場合、学習エンジンはそれらを区別できないことがあります。同様に、展開された緩和ルールによって、このようなすべてのフィールドが誤って緩和される可能性があります。
デフォルトフィールドフォーマット-アクションを設定するだけでなく、デフォルトのフィールドフォーマットを設定して、アプリケーションのすべてのフォームフィールドに必要なデータのタイプを指定できます。フィールドタイプをフィールドフォーマットタイプとして選択できます。[最小長] パラメータと [最大長] パラメータを使用して、許容される入力の長さを指定できます。フィールドタイプの代わりに、文字マップを使用してフィールドで許可される内容を指定できます (クラスター展開を除く)。
-
フィールドタイプ—フィールドタイプは、割り当てられた優先順位値を割り当てる名前付きの式です。フィールドタイプ式は入力可能な値を指定し、送信されたデータと照合して、受信した値が許容値と一致しているかどうかを判断します。フィールドタイプは優先順位の順にチェックされます。数値が小さいほど優先度が高くなります。Web App Firewall では、独自のフィールドタイプを追加して、必要な優先順位を割り当てることができます。プライオリティ値の範囲は 0 ～ 64000 です。設定プロセスを簡略化するために、以下の組み込みフィールドタイプが用意されています。
> sh appfw fieldtype 1) Name: integer Regex: "^[+-]?[0-9]+$" Priority: 30 Comment: Integer Builtin: IMMUTABLE 2) Name: alpha Regex: "^[a-zA-Z]+$" Priority: 40 Comment: "Alpha characters" Builtin: IMMUTABLE 3) Name: alphanum Regex: "^[a-zA-Z0-9]+$" Priority: 50 Comment: "Alpha-numeric characters" Builtin: IMMUTABLE 4) Name: nohtml Regex: "^[^&<>]*$" Priority: 60 Comment: "Not HTML" Builtin: IMMUTABLE 5) Name: any Regex: "^.*$" Priority: 70 Comment: Anything Builtin: IMMUTABLE Done > <!--NeedCopy-->注: 組み込みのフィールドタイプは不変です。これらを変更したり削除したりすることはできません。追加したフィールドタイプはすべて変更可能です。これらは編集または削除できます。
アプリケーションのすべてまたはほとんどのフォームフィールドで有効な入力を識別し、無効な入力を除外できる PCRE 式がある場合は、フィールドタイプをデフォルトのフィールド形式として設定すると便利な場合があります。たとえば、申請フォームのすべての入力に数字と文字のみが含まれていることが予想される場合は、組み込みのフィールドタイプ英数字をデフォルトのフィールドタイプとして使用することをお勧めします。入力にバックスラッシュ () やセミコロンなどの英数字以外の文字が含まれていると、違反になります。また、独自にカスタマイズしたフィールドタイプを追加し、それを使用してデフォルトのフィールド形式を構成することもできます。たとえば、小文字の「x」、「y」、「z」のみを許可する英文字にする場合は、正規表現「^ [x-z] +$」でカスタマイズされたフィールドタイプを設定できます。組み込みのフィールドタイプよりも高い優先度（低い優先度番号）を割り当てて、デフォルトのフィールドタイプとして使用できます。
-
最小長 — 明示的に設定されていない Web フォームのフォームフィールドに割り当てられるデフォルトの最小データ長。このパラメータはデフォルトで 0 に設定されているため、ユーザーはフィールドを空白のままにしておくことができます。これより大きい値に設定すると、ユーザーはフィールドへの入力を強制されます。
注意:最小長値が 0 で、フィールドタイプが整数、アルファまたは英数字の場合、最小長の設定にかかわらず、入力フィールドのいずれかが空のままになるとリクエストはブロックされます。これは、これらのフィールドタイプの正規表現に+文字、つまり1つ以上の文字が含まれているためです。整数とアルファ文字を区別するには、少なくとも 1 文字が必要です。
-
最大長— 明示的に設定されていない Web フォームのフォームフィールドに割り当てられるデフォルトの最大データ長。このパラメータはデフォルトで 65535 に設定されています。
注:
文字とバイト。フィールドフォーマットの最小長と最大長は、文字数ではなくバイト数を表します。1 バイトを超える文字表現を使用する言語では、最大値に設定されている数よりも少ない文字数で制限を超えることがあります。たとえば、2 バイト文字表現の場合、最大値の 9 では 4 文字までしか使用できません。GUI では、UTF-8 文字を 16 進数に変換しなくても、直接 GUI にカットアンドペーストできます。
-
名前の最大出現回数 -リクエストで許可されるフォームフィールド名インスタンスの最大数。デフォルト値は 65535 です。
-
文字マップ:Web App Firewall の学習エンジンでは、フィールドタイプを推奨するほかに、「文字マップを使用」というオプションを追加して、フォーマットチェックルールをデプロイできます。文字コード表は、特定のフォームフィールドで使用できるすべての文字のセットです。文字マップを使用して、特定の文字を許可または禁止するようにフィールド形式の仕様を微調整できます。フォームフィールドごとに個別の文字コードマップが生成されます。文字マップでは、英文字と数字の扱いが異なります。入力にアルファ文字が含まれている場合は、文字コード表の推奨PCRE式ですべてのアルファ文字 [a-za-z] を使用できます。同様に、いずれかの数字が含まれている場合は、[0-9] のすべての数字を使用できます。印刷できない文字は、x 構造体を使用して指定します。文字コード表の推奨対象となるのは、0 ～ 255 の値の 1 バイト文字だけです。
文字コード表は、対応するフィールドタイプの推奨よりも具体的であり得ます。状況によっては、入力として使用できる文字セットをより厳密に制御できるため、文字マップの方が適している場合があります。展開されたキャラクタマップは、プレフィックス「CM」で始まり、その後に数字が続く文字列として表示されます。キャラクターマップの優先度は 10000 から始まります。ユーザーが追加したフィールドタイプと同様に、文字コードマップを追加、編集、削除できます。デプロイされたルールで現在使用されているキャラクタマップは変更も削除もできません。
メモ:
- キャラクターマップはクラスターデプロイメントではサポートされていません。
- 組み込みフィールドタイプの代わりに文字マップを使用してフィールドフォーマットルールを保存すると、ルールは変更を保存せず、引き続きフィールドタイプを表示します。
- 文字マップが組み込み型のいずれかと一致する場合、新しい文字コードマップを作成する代わりにフィールドタイプが再利用されます。
CLI を使用してフィールドフォーマットチェックを設定する
コマンドラインインターフェイスでは、add appfw fieldtype コマンドを使用して新しいフィールドタイプを追加できます。set appfw profile コマンドまたは add appfw profile コマンドのいずれかを使用して、フィールド形式チェックを設定し、実行するアクションを指定できます。unset appfw profile コマンドを使用して、設定した設定をデフォルトに戻すことができます。フィールドフォーマットルールを指定するには、bind appfw コマンドを使用して、フィールドタイプをフォームのフィールドとアクション URL にバインドし、最小長と最大長の指定を行います。
CLI を使用してフィールドタイプを追加、削除、または表示するには：
add コマンドを使用して、フィールドタイプを追加します。新しいフィールドタイプを追加するときは、名前、正規表現、優先度を指定する必要があります。コメントを追加することもできます。show コマンドを使用して、設定されているフィールドタイプを表示できます。remove コマンドを使用してフィールドタイプを削除することもできます。削除するには、フィールドタイプの名前のみが必要です。
add [appfw] fieldType <name> <regex> <priority> [-comment <string>]
各項目の意味は次のとおりです：
<regex> は正規表現です
<priority> は正の整数です
例：
add fieldtype "Cust_Zipcode" "^[0-9]{5}[-][0-9]{4}$" 4
- show [appfw] fieldType [<name>]
Example: sh fieldtype
sh appfw fieldtype
sh appfw fieldtype cust_zipcode
- `rm [appfw] fieldType <name>`
Example: rm fieldtype cusT_ziPcode
`rm appfw fieldtype cusT_ziPcode`
<!--NeedCopy-->
注:
例に示すように、コマンドでの
appfwの使用は任意です。たとえば、Add FieldTypeまたはAdd appfw fieldTypeは有効なオプションです。フィールドタイプの名前は、正規化されているため大文字と小文字が区別されません。例に示されているように、Cust_Zipcode、cust_zipcode、Cust_ZipCode は同じフィールドタイプを参照しています。
コマンドラインを使用してフィールドフォーマットチェックを設定するには
以下のように、set appfw profileコマンドまたはadd appfw profileコマンドのいずれかを使用します：
set appfw profile <name> -fieldFormatAction (([block] [learn] [log] [stats]) | [none])set appfw profile <name>-defaultFieldFormatType <string>set appfw profile <name> -defaultFieldFormatMinLength <integer>set appfw profile <name> -defaultFieldFormatMaxLength <integer>set appfw profile <name> -defaultFieldFormatMaxOccurrences <integer>
コマンドラインを使用してフィールド形式緩和ルールを設定するには
bind appfw profile <name> (-fieldFormat <string> <formActionURL> <fieldType>
[-fieldFormatMinLength <positive_integer>] [-fieldFormatMaxLength <positive_integer>]
[-isRegex ( REGEX | NOTREGEX )])
<!--NeedCopy-->
例：
bind appfw profile pr_ffc -fieldFormat "login_name" ".*/login.php" integer -fieldformatMinLength 3 -FieldformatMaxlength 6
<!--NeedCopy-->
GUI を使用してフィールド形式のセキュリティチェックを設定します
GUI では、フィールドタイプを管理できます。アプリケーションに関連付けられているプロファイルのペインで、フィールド形式のセキュリティチェックを設定することもできます。
GUI を使用してフィールドタイプを追加、変更、または削除するには
- 「アプリケーションファイアウォール」ノードに移動します。「設定」で、「 フィールドタイプの管理 」をクリックして、「アプリケーションファイアウォールのフィールドタイプの設定」ダイアログボックスを表示します。
- [ 追加 ] をクリックして、新しいフィールドタイプを追加します。このペインの指示に従い、「作成」をクリックします。ユーザーが追加したフィールドタイプがデプロイされたルールで現在使用されていない場合は、編集または削除することもできます。
GUI を使用してフィールドフォーマットのセキュリティチェックを追加または変更するには
-
[ アプリケーションファイアウォール ] > [ プロファイル] に移動し、ターゲットプロファイルを強調表示して [ 編集] をクリックします。
-
[ 詳細設定 ] ペインで、[ セキュリティチェック] をクリックします。
セキュリティー検査テーブルには、すべてのセキュリティー検査に対して現在構成されているアクション設定が表示されます。設定には次の 2 つのオプションがあります。
- フィールドフォーマットのブロック、 ログ、 統計、 学習アクションを有効または無効にするだけの場合は 、表のチェックボックスをオンまたはオフにして、「 OK」をクリックし、「 保存して閉じる 」をクリックしてセキュリティチェックペインを閉じます。
- このセキュリティチェックに追加のオプションを設定する場合は、「フィールドフォーマット」をダブルクリックするか、行を選択して「アクション設定」をクリックすると、 デフォルトフィールドフォーマットの次のオプションが表示されます。
-
フィールドタイプ-デフォルトのフィールドタイプとして設定するフィールドタイプを選択します。組み込みのフィールドタイプとユーザー定義のフィールドタイプを選択できます。展開されたキャラクターマップもリストに含まれており、選択できます。
-
最小文字数-各フィールドに入力する必要がある最小文字数を指定します。設定可能な値は 0 ～ 65535 です。
-
最大長— 各フィールドに入力する必要がある最大文字数を指定します。設定可能な値は 1 ～ 65535 です。
-
名前の最大出現回数 -リクエスト内のフォームフィールド名インスタンスの最大数を指定します。設定可能な値は 0 ～ 65535 です。
フィールドフォーマット設定ペインで、 ブロック、 ログ、 統計 、 学習アクションを編集することもできます 。
-
上記の変更を行った後、「 OK」 をクリックして変更を保存し、「Security Checks」テーブルに戻ります。必要に応じて、他のセキュリティー検査の設定に進むことができます。［ OK ］をクリックして［セキュリティチェック］セクションで行った変更をすべて保存し、［ 保存して閉じる ］をクリックしてセキュリティチェックウィンドウを閉じます。
GUI を使用してフィールドフォーマット緩和ルールを設定する
-
[ アプリケーションファイアウォール ] > [ プロファイル] に移動し、ターゲットプロファイルを強調表示して [ 編集] をクリックします。
-
[ 詳細設定 ] ウィンドウで、[ 緩和規則] をクリックします。緩和ルールテーブルには「フィールドフォーマット」エントリがあります。ダブルクリックするか、この行を選択して「編集」ボタンをクリックすると、フィールドフォーマット緩和ルールダイアログにアクセスできます。緩和ルールの [ 追加]、[編集]、[削除]、[ 有効化]、または [ 無効化 ] 操作を実行できます。
すべての緩和ルールをまとめて表示するには、「フィールドフォーマット」行を強調表示して「ビジュアライザー」をクリックします。デプロイされたリラクゼーションのビジュアライザーには、[ 新しいルールを追加 ] または [既存のルールを編集] のオプションがあります。ノードを選択し、緩和ビジュアライザの対応するボタンをクリックして、ルールのグループ を有効 または 無効に することもできます。
フィールドフォーマットチェックでの学習機能の使用
学習アクションが有効になると、Web App Firewall 学習エンジンはトラフィックを監視し、トリガーされた違反を学習します。学習したルールは定期的に検査できます。十分に検討したら、学習したルールをフィールド形式緩和ルールとして展開できます。
フィールド形式学習の強化— Web App Firewall の学習拡張機能がリリース11.0で導入されました。以前のリリースでは、学習したフィールド形式のレコメンデーションがデプロイされると、Web App Firewall 学習エンジンは、新しいデータポイントに基づいて新しいルールを推奨する目的で有効なリクエストの監視を停止していました。これにより、セキュリティチェックによって処理された有効なリクエストに含まれる新しいデータが学習データベースに含まれないため、設定されているセキュリティ保護が制限されます。
違反はもはや学習と結びついていません。学習エンジンは、違反に関係なく、フィールドフォーマットを学習して推奨します。学習エンジンは、ブロックされたリクエストをチェックして、現在のフィールド形式が制限が厳しすぎて緩和する必要があるかどうかを判断するだけでなく、許可されたリクエストを監視して現在のフィールド形式が許容範囲を超えているかどうかを判断し、より制限の厳しいルールを適用することでセキュリティを強化できます。
以下は、フィールドフォーマットの学習行動の概要です。
フィールド形式はバインドされていません— このシナリオでも動作は変わりません。すべての学習データは aslearn エンジンに送信されます。学習エンジンは、データセットに基づいてフィールド形式のルールを提案します。
フィールド形式は制限されています。以前のリリースでは、監視されたデータは違反の場合にのみaslearnエンジンに送信されていました。学習エンジンは、データセットに基づいてフィールド形式のルールを提案します。11.0 リリースでは、違反が発生しなくても、すべてのデータが aslearn エンジンに送信されます。学習エンジンは、受信したすべての入力のデータセット全体に基づいてフィールド形式のルールを提案します。
学習強化のユースケース:
最初に学習したフィールドフォーマットのルールが少数のデータサンプルに基づいている場合、標準的でない値がいくつかあると、ターゲットフィールドに対して寛大すぎる推奨結果になる可能性があります。継続的な学習により、Web App Firewall はすべてのリクエストのデータポイントを観察して、学習した推奨事項の代表的なサンプルを収集できます。これは、適切な範囲値を持つ最適な入力形式を導入するためのセキュリティをさらに強化するのに役立ちます。
フィールド形式の学習では、フィールドタイプの優先度と、次の学習しきい値の設定を利用します。
- FieldFormatMinThreshold—学習済みリラクゼーションが生成されるまでに特定のフォームフィールドを観察する必要がある最小回数。デフォルト:1
- FieldFormatPercentThreshold— 学習済み緩和が生成されるまでに、フォームフィールドが特定のフィールドタイプと一致した回数の割合。デフォルト:0。
フィールド形式ルールの推奨事項は、次の基準に基づいています。
- 推奨フィールドタイプ — 推奨フィールドタイプは、既存のフィールドタイプに割り当てられた優先順位と指定されたフィールドフォーマットのしきい値によって決まります。優先順位によって、フィールドタイプが入力と照合される順序が決まります。数字が小さいほど、プライオリティが高くなります。たとえば、フィールドタイプ整数の方が優先度が高く (30)、フィールドタイプアルファヌム (50) よりも先に評価されます。しきい値によって、データポイントの代表的なサンプルを収集するために評価される入力の数が決まります。設定したフィールドタイプに適切な優先順位を割り当て、 FieldFormatPercentThreshold パラメーターと FieldFormatMinThreshold**パラメーターに適切な学習設定値を設定することが 、正しいフィールドフォーマットの推奨値を得るために不可欠です** 。設定されたしきい値に基づいて、優先順位が最も高いフィールドタイプが最初に入力と照合されます。一致するものがあれば、他のフィールドタイプを考慮せずにこのフィールドタイプが候補として表示されます。たとえば、すべての入力に数値のみが含まれている場合は、整数、英字、および任意の 3 つのデフォルトフィールドタイプが一致します。ただし、整数の方が優先度が高いので推奨されます。
- 推奨される最小長と最大長— フィールドフォーマットの最小長と最大長の計算は、フィールドタイプの決定とは独立して行われます。フィールドフォーマットの長さの計算は、観測されたすべての入力の平均長に基づいています。この計算された平均の半分が最小値として推奨され、この平均値の 2 倍の値が最大値として推奨されます。[最小長] の範囲は 0 ～ 65535 で、[最大長] の範囲は 1 ～ 65535 です。最小長の設定値は最大長を超えることはできません。
- スペース文字の処理— フィールドフォーマットチェックでは、フィールドフォーマットの長さをチェックするときに、すべてのスペース文字がカウントされます。入力処理中に、先頭または末尾のスペースは削除されず、入力文字列の途中にある複数の連続したスペースが 1 つのスペースに統合されなくなりました。
フィールドフォーマットの推奨事項を説明する例:
Total requests: 100
Number of Req with Field Type:
Int : 22 (22 int values) – 22%
Alpha : 44 (44 alpha values) – 44%
Alphanum: 14 (14 + 44 + 22 = 80 alphanum values) = 80%
noHTML: 10 (80 + 10 = 90 noHTML values) = 90%
any : 10 (90 + 10 = 100 any values) = 100%
% threshold Suggested Field Type
0-22 int
23-44 alpha
45-80 alphanum
81-90 noHTML
91-100 any
<!--NeedCopy-->
コマンドラインインターフェイスを使用して学習データを表示または使用するには
show appfw learningdata <profilename> FieldFormat
rm appfw learningdata <profilename> -fieldFormat <string> <formActionURL>
export appfw learningdata <profilename> FieldFormat
<!--NeedCopy-->
GUI を使用して学習済みデータを表示または使用するには
-
[ アプリケーションファイアウォール ] > [ プロファイル] に移動し、ターゲットプロファイルを強調表示して [ 編集] をクリックします。
-
[ 詳細設定 ] ペインで、[ 学習済みルール] をクリックします。学習ルールテーブルの「フィールドフォーマット」エントリを選択してダブルクリックすると、学習したルールにアクセスできます。学習したルールを展開したり、緩和ルールとして展開する前にルールを編集したりできます。ルールを破棄するには、ルールを選択して「スキップ」( Skip ) ボタンをクリックします。一度に編集できるルールは 1 つだけですが、展開またはスキップするルールは複数選択できます。
また、「学習ルール」テーブルの「フィールドフォーマット」エントリを選択し、「ビジュアライザー」をクリックすると、学習したすべての違反をまとめて表示できます。ビジュアライザーを使用すると、学習したルールを非常に簡単に管理できます。1 つの画面でデータの包括的なビューを表示し、1 回のクリックでルールのグループに対するアクションの実行を容易にします。ビジュアライザーの最大の利点は、正規表現を推奨して複数のルールを統合できることです。デリミタとアクション URL に基づいて、これらのルールのサブセットを選択できます。ドロップダウンリストから番号を選択すると、ビジュアライザーに 25、50、または 75 個のルールを表示できます。学習したルールのビジュアライザーには、ルールを編集して緩和として展開するオプションがあります。または、ルールをスキップして無視することもできます。
フィールドフォーマットチェックでのログ機能の使用
ログアクションを有効にすると、フィールドフォーマットのセキュリティチェック違反が APPFW_FIELDFORMAT 違反として監査ログに記録されます。Web App Firewall は、ネイティブログ形式と CEF ログ形式の両方をサポートしています。ログをリモート syslog サーバに送信することもできます。
コマンドラインを使用してログメッセージにアクセスするには
シェルに切り替えて、/var/log/ フォルダー内の ns.logs を末尾に移動して、フィールドフォーマット違反に関するログメッセージにアクセスします。
Shelltail -f /var/log/ns.log | grep APPFW_FIELDFORMAT
GUI を使用してログメッセージにアクセスするには
GUI には、ログメッセージを分析するための非常に便利なツール (Syslog Viewer) が含まれています。Syslog ビューアにアクセスするには、複数のオプションがあります：
-
[ アプリケーションファイアウォール ] > [ プロファイル] に移動し、ターゲットプロファイルを選択して [ セキュリティチェック] をクリックします。[フィールドフォーマット] 行を強調表示して、[ ログ] をクリックします。 プロファイルのField Formatsセキュリティチェックから直接ログにアクセスすると 、ログメッセージが除外され、これらのセキュリティチェック違反に関連するログのみが表示されます。
-
「 NetScaler 」>「 システム 」>「 監査 」の順に選択して、Syslogビューアにアクセスすることもできます。「 監査メッセージ 」セクションで、「 Syslog messages 」リンクをクリックすると、 Syslog Viewerが表示されます。このビューアには、他のセキュリティチェック違反ログを含むすべてのログメッセージが表示されます。これは、要求処理中に複数のセキュリティチェック違反がトリガーされる可能性がある場合のデバッグに役立ちます。
-
アプリケーションファイアウォール > ポリシー > 監査に移動します。「 監査メッセージ 」セクションで、「Syslog messages」リンクをクリックすると、Syslog Viewer が表示されます。このビューアには、他のセキュリティチェック違反ログを含むすべてのログメッセージが表示されます。
HTML ベースの Syslog ビューアには、関心のあるログメッセージのみを選択するためのさまざまなフィルタオプションがあります。フィールドフォーマットのセキュリティチェック違反ログメッセージにアクセスするには、モジュールのドロップダウンオプションで APPFW を選択してフィルタリングします。[イベントタイプ] には、選択をさらに絞り込むための豊富なオプションセットが表示されます。たとえば、 APPFW_FIELDFORMAT チェックボックスを選択して [ **適用 ] ボタンをクリックすると、フィールド形式のセキュリティチェック違反に関するログメッセージのみが** Syslog Viewer に表示されます。
特定のログメッセージの行にカーソルを置くと、Module や EventType などの複数のオプションがログメッセージの下に表示されます。これらのオプションのいずれかを選択して、ログ内の対応する情報を強調表示できます。
リクエストがブロックされていない場合のネイティブ形式のログメッセージの例
Jun 10 22:32:26 <local0.info> 10.217.31.98 06/10/2015:22:32:26 GMT ns 0-PPE-0 :
default APPFW APPFW_FIELDFORMAT 97 0 : 10.217.253.62 562-PPE0
x1MV+YnNGzQFM3Bsy2wti4bhXio0001 pr_ffc http://aaron.stratum8.net/FFC/login_post.php
Field format check failed for field passwd="65568888sz-*_" <not blocked>
Example of a CEF format log message when the request is blocked
Jun 11 00:03:51 <local0.info> 10.217.31.98
CEF:0|Citrix|NetScaler|NS11.0|APPFW|APPFW_FIELDFORMAT|6|src=10.217.253.62 spt=27076
method=POST requet=http://aaron.stratum8.net/FFC/maxlen_post.php msg=Field format check
failed for field text_area="" cn1=108 cn2=644 cs1=pr_ffc cs2=PPE0
cs3=GaUROfl1Nx1jJTvja5twH5BBqI0000 cs4=ALERT cs5=2015 act=blocked
<!--NeedCopy-->
フィールドフォーマット違反の統計
統計アクションを有効にすると、Web App Firewall がこのセキュリティチェックに対して何らかのアクションを実行すると、フィールドフォーマットチェックに対応するカウンタが増えます。統計は、トラフィック、違反、およびログのレートと合計数について収集されます。ログカウンターのインクリメントは、構成された設定によって異なる場合があります。たとえば、ブロックアクションが有効な場合、フィールドフォーマット違反が 3 つあるページのリクエストでは、最初のフィールドフォーマット違反が検出されるとすぐにページがブロックされるため、統計カウンタが 1 つ増えます。ただし、ブロックが無効になっている場合、同じリクエストを処理すると、フィールドフォーマット違反ごとに個別のログメッセージが生成されるため、違反とログの統計カウンタが 3 ずつ増えます。
コマンドラインを使用してフィールドフォーマットの統計情報を表示するには
コマンドプロンプトで入力します：
sh appfw stats
特定のプロファイルの統計情報を表示するには、以下のコマンドを使用します。
stat appfw profile <profile name>
GUI を使用してフィールドフォーマットの統計情報を表示するには
- システム > セキュリティ > アプリケーションファイアウォールに移動します。
- 右側のペインで、[統計 リンク] にアクセスします。
- スクロールバーを使用して、フィールドフォーマットの違反とログに関する統計を表示します。統計テーブルはリアルタイムデータを提供し、7秒ごとに更新されます。
導入のヒント
- フィールド形式のアクションログ、学習、統計を有効にします。
- アプリケーションへのトラフィックの代表的なサンプルを実行したら、学習した推奨事項を確認します。
- 学習したルールのほとんどでフィールドタイプが推奨される場合は、そのフィールドタイプをデフォルトのフィールドタイプとして設定します。最小長と最大長については、これらのルールで推奨されている最も広い範囲を使用してください。
- 異なるフィールドタイプや異なる最小/最大長の方が適している他のフィールドにもルールをデプロイします。
- ブロッキングを有効にし、学習を無効にします。
- 統計とログを監視します。それでもかなりの数の違反が発生している場合は、ログメッセージを確認して、その違反がブロックされたはずの悪意のあるリクエストであるかどうかを確認することをお勧めします。有効なリクエストが違反としてフラグ付けされている場合は、設定したフィールド形式ルールを編集してさらに緩和するか、学習を再度有効にして新しいデータポイントに基づいて推奨事項を取得することができます。
注: 新しい学習推奨事項を入手することで、構成を微調整できます。
ハイライト
フィールドフォーマットのセキュリティチェックについては、次の点に注意してください。
- 保護— 最適なフィールド形式ルールを設定することで、多くの攻撃から保護できます。たとえば、フィールドに整数のみを指定した場合、ハッカーはこのフィールドを使用して SQL インジェクション攻撃やクロスサイトスクリプティング攻撃を仕掛けることはできません。このような攻撃を開始するのに必要な入力は、設定されたフィールド形式の要件を満たさないためです。
- パフォーマンス— フィールドフォーマットルールの入力の最小許容長と最大長を制限できます。これにより、悪意のあるユーザーがサーバーに処理オーバーヘッドを追加しようとして過度に大きな入力文字列を入力したり、さらに悪いことに、スタックオーバーフローのためにサーバーがコアをダンプしたりするのを防ぐことができます。入力サイズを制限することで、正当なリクエストの処理に必要な時間を短縮できます。
- フィールドフォーマットの設定— フィールドフォーマットの保護を行うには、いずれかのアクション (ブロック、ログ、統計、学習) を有効にする必要があります。また、フィールド形式のルールを指定して、フォームフィールドに入力できる内容を特定することもできます。
-
キャラクタマップの選択 vs. フィールドタイプ—文字マップとフィールドタイプはどちらも正規表現を使用します。ただし、文字コード表では、使用できる文字のリストを絞り込むことで、より具体的な式が得られます。たとえば、
janedoe@citrix.comなどの入力の場合、学習エンジンはフィールドタイプnohtmlを推奨するが、文字マップ[.@-Za-z] は、使用できる非英文字のセットを絞り込むため、より具体的かもしれません。文字コード表オプションでは、アルファ文字の他に、ピリオド (.) とアットマーク (@) の 2 つの非英文字のみを使用できます。 - 継続的な学習— Web App Firewall は、すべての受信データ (違反データおよび許容される入力データ) を監視および考慮して、推奨ルール用の学習テーブルを作成します。ルールは、新しい受信データが到着すると改訂および更新されます。既にバインドされたフィールド形式のルールがある場合でも、そのフィールドには新しいフィールド形式のルールが提案されます。設定したフィールドフォーマットの制限が厳しすぎて、有効なリクエストがブロックされている場合は、より緩和されたフィールドフォーマットを導入できます。同様に、現在のフィールドフォーマットが汎用的すぎる場合は、より制限の厳しいフィールドフォーマットを導入することで、セキュリティをさらに洗練し、強化することができます。
- ルールの上書き— フィールドと URL の組み合わせに対して既にルールが適用されている場合、ユーザは GUI を使用してフィールド形式を更新できます。既存のルールを置き換えるかどうかの確認を求めるダイアログボックスが表示されます。コマンドラインインターフェイスを使用している場合は、以前のバインディングを明示的にバインド解除してから、新しいルールをバインドする必要があります。
- 複数一致— 複数のフィールド形式が特定のフィールド名とそのアクション URL と一致する場合、Web App Firewall はそのうちの 1 つを任意に選択して適用します。
- バッファ境界— フィールド値が複数のストリーミングバッファにまたがっていて、フィールド値のこの 2 つの部分の形式が異なる場合、「任意」に対応するフィールド形式が学習データベースに送信されます。
- フィールドフォーマット vs. フィールド整合性チェック— フィールド形式チェックとフィールド整合性チェックはどちらもフォームベースの保護チェックです。フィールドフォーマットチェックは、フォームフィールドの一貫性チェックとは異なるタイプの保護を提供します。フォームフィールドの一貫性チェックでは、ユーザーから返された Web フォームの構造が損なわれていないこと、HTML に設定されているデータ形式の制限が守られていること、非表示フィールドのデータが変更されていないことを確認します。これは、Web フォーム自体から派生したもの以外の Web フォームに関する特別な知識がなくても実行できます。フィールドフォーマットチェックでは、各フォームフィールドのデータが、手動で設定した特定のフォーマット制限と一致しているか、または学習機能が生成されて承認されたかを確認します。言い換えれば、フォームフィールドの一貫性チェックは一般的な Web フォームのセキュリティを強化し、フィールドフォーマットチェックは Web フォームの許可された入力に特定のルールを適用します。