フィールド形式のチェック
[フィールド形式]チェックは、ユーザーがWebフォームでWebサイトに送信するデータを確認します。データの長さと型の両方を調べて、データが表示されるフォームフィールドに適していることを確認します。Web App Firewall は、ユーザーリクエストで不適切な Web フォームデータを検出すると、リクエストをブロックします。
攻撃者が不適切なWebフォームデータをWebサイトに送信するのを防ぐことにより、フィールドフォーマットチェックはWebサイトおよびデータベースサーバーに対する特定の種類の攻撃を防ぎます。たとえば、特定のフィールドでユーザが電話番号を入力することが予想される場合、[Field Formats] チェックは、ユーザが送信した入力を調べ、データが電話番号の形式と一致することを確認します。特定のフィールドにファーストネームが必要な場合は、[Field Formats] チェックによって、そのフィールドのデータがファーストネームに適したタイプと長さであることが確認されます。これは、保護するように構成するフォームフィールドごとに同じことを行います。
このチェックは HTML リクエストにのみ適用されます。XML リクエストには適用されません。HTML プロファイルまたは Web 2.0 プロファイルでフィールド形式チェックを構成して、アプリケーションを保護するための HTML ペイロードを検査できます。Web App Firewall は、Google Web Toolkit (GWT) アプリケーションのフィールドフォーマットチェック保護もサポートしています。
[フィールド形式] チェックでは、1 つ以上のアクションを有効にする必要があります。Web App Firewall は、送信された入力を調べ、指定されたアクションを適用します。
注
フィールド書式ルールは締め付けルールです。学習したデータから緩和リストに追加すると、ブロック規則として機能します。
フィールド形式の規則を緩和するには、フィールド形式の緩和リストから特定の「フィールド名」を削除してください。
デフォルトのフィールド形式を設定して、保護する各 Web フォームの各フォームフィールドで想定されるデータの最小長と最大長を指定します。緩和ルールを展開して、特定のフォームの個々のフィールドに対して [フィールド形式] を設定できます。複数のルールを追加して、フィールド名、アクション URL、およびフィールド形式を指定できます。異なるフォームフィールドに異なるタイプの入力を受け入れるには、フィールドフォーマットを指定します。学習機能では、緩和規則の推奨事項を提供できます。
フィールド形式のアクション-ブロック、ログ、統計、学習の各アクションを有効にできます。フィールド形式チェック保護を使用するには、これらのアクションの少なくとも 1 つを有効にする必要があります。
- ブロック。ブロックを有効にすると、入力が指定されたフィールド形式に準拠していない場合に、ブロックアクションがトリガされます。ターゲットフィールドにルールが設定されている場合は、指定されたルールに対して入力がチェックされます。それ以外の場合は、デフォルトのフィールド形式指定と照らしてチェックされます。フィールドタイプまたは最小/最大長の指定に不一致があると、要求がブロックされます。
- ログ。ログ機能を有効にすると、Field Format チェックによって実行されるアクションを示すログメッセージが生成されます。ログを監視して、正当な要求に対する応答がブロックされているかどうかを判断できます。ログメッセージの数が大幅に増加すると、攻撃を開始しようとする悪意のある試みを示している可能性があります。
- 統計。有効にすると、統計機能によって違反とログに関する統計情報が収集されます。stats カウンタの予期しない急増は、アプリケーションが攻撃を受けていることを示しているか、指定されたフィールド形式が過度に制限されているかどうかを確認するために設定を再確認する必要がある可能性があります。
- 学ぶ。どのフィールドタイプまたは最小および最大長の値がアプリケーションに最適であるかが不明な場合は、学習機能を使用して、学習データに基づいて推奨事項を生成できます。Web App Firewall 学習エンジンは、トラフィックを監視し、観測値に基づいてフィールド形式の推奨事項を提供します。パフォーマンスを損なうことなく最適なメリットを得るには、ラーニングオプションを短時間有効にして、ルールの代表的なサンプルを取得してから、ルールを展開してラーニングを無効にします。 注:Web App Firewall の学習エンジンは、名前の最初の 128 バイトのみを区別できます。フォームに、最初の 128 バイトに一致する名前のフィールドが複数ある場合、学習エンジンはそれらを区別できないことがあります。同様に、展開された緩和ルールは、そのようなフィールドをすべて誤って緩和する可能性があります。
[Default Field Format]— アクションの設定に加えて、デフォルトの [Field Format] を設定して、アプリケーションのすべてのフォームフィールドで想定されるデータのタイプを指定できます。[フィールドタイプ] は、[フィールドフォーマット] タイプとして選択できます。[最小長] および [最大長] パラメータを使用して、許容される入力の長さを指定できます。[フィールドタイプ] の代わりに、キャラクタマップを使用して、フィールドで許可される内容を指定することもできます (クラスタ展開を除く)。
-
[Field Type]：フィールドタイプは名前付き式で、割り当てられたプライオリティ値を割り当てます。Field Type 式は、許可された入力を指定し、送信されたデータに対して照合され、受信した値が許可された値と一致しているかどうかを判断します。[フィールドタイプ] は、優先順位番号順にチェックされます。数値が小さいほど、プライオリティが高くなります。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 式がある場合に、Field Type をデフォルトのフィールド形式として設定すると便利です。例えば、申請書のすべての入力に数字と文字のみが含まれていることが予想される場合、デフォルトのフィールドタイプとして組み込みのフィールドタイプの英数字を使用することができます。バックスラッシュ（）やセミコロンなどの英数字以外の文字。入力では、違反が発生します。また、独自にカスタマイズしたフィールドタイプを追加し、それを使用してデフォルトのフィールド形式を構成することもできます。たとえば、小文字の「x」、「y」、および「z」を唯一のアルファ文字にする場合は、正規表現「^[x-z]+$」を使用して、カスタマイズされたフィールドタイプを設定できます。組み込みのフィールドタイプよりも高い優先度（低い優先度番号）を割り当てて、デフォルトのフィールドタイプとして使用できます。
-
「最小長 」— 明示的な設定を持たない Web フォームのフォームフィールドに割り当てられるデフォルトの最小データ長。このパラメータはデフォルトで 0 に設定されており、ユーザはフィールドを空白のままにできます。高い設定を行うと、ユーザーは強制的にフィールドに入力されます。
注意: 最小長の値が 0 で、[フィールドタイプ] が整数、アルファベット、または英数字の場合、最小長の設定にもかかわらず、入力フィールドが空のままであると、要求はブロックされます。これは、これらのフィールド型のregExには、1つ以上の文字を意味する+文字が含まれているためです。整数をアルファ文字と区別するには、少なくとも 1 文字が必要です。
-
最大長— 明示的な設定を持たない Web フォームのフォームフィールドに割り当てられるデフォルトの最大データ長。このパラメータは、デフォルトで 65535 に設定されています。
注： 文字対バイト。フィールド形式の最小長と最大長は、文字数ではなく、バイト数を表します。1 バイト文字表現よりも大きい言語では、最大値に設定された文字数よりも少ない文字数で制限を超えることがあります。たとえば、2 バイト文字表現の場合、最大値 9 では 4 文字以下を使用できます。 ヒント： GUIを使用すると、UTF-8文字を16進数に変換することなく、直接GUIにカットアンドペーストすることができます。
-
文字マップ: フィールドタイプの推奨に加えて、Web App Firewall 学習エンジンには、書式チェックルールを展開するための [文字マップの使用] という追加オプションがあります。文字コード表は、特定のフォームフィールドで使用できるすべての文字のセットです。文字マップを使用して、特定の文字を許可または禁止するように、フィールド形式の仕様を微調整できます。フォームフィールドごとに個別の文字コード表が生成されます。文字マップでは、英文字と数字の扱いが異なります。入力にアルファ文字がある場合、すべてのアルファ文字 [A-za-z] がキャラクタマップで推奨される PCRE 式によって許可されます。同様に、数字が含まれている場合は、 [0 ～ 9] の数字がすべて許可されます。印刷できない文字は、x 構造体を使用して指定します。0 ～ 255 の値を持つ 1 バイト文字のみが、文字コード表推奨の対象となります。
文字コード表は、対応するフィールドタイプの推奨事項よりも具体的に指定できます。状況によっては、キャラクタマップを使用すると、入力として許可されるキャラクタのセットをより厳密に制御できるため、より適切なオプションになる場合があります。展開された文字マップは、接頭辞「CM」で始まり、数字が続く文字列として表示されます。文字マップの優先順位は 10000 から始まります。ユーザーが追加したフィールドタイプと同様に、文字コード表を追加、編集、または削除できます。デプロイされたルールで現在使用されている文字マップは、変更または削除できません。
注：キャラクタマップは、クラスタ配置ではサポートされていません。
注
組み込みのフィールドタイプを含むフィールド書式ルールを追加し、フィールドタイプの代わりに文字マップを使用して保存すると、変更は保存されず、ルールが [フィールドタイプ] に表示されます。
文字マップが組み込み型の 1 つと一致すると、新しい文字マップを作成する代わりにフィールド型が再利用されます。
コマンドラインを使用したフィールド形式のチェックの設定
コマンドラインインターフェイスでは、add appfw fieldtype コマンドを使用して、新しいフィールドタイプを追加できます。set appfw profile コマンドまたは add appfw profile コマンドのいずれかを使用して、フィールド形式のチェックを設定し、実行するアクションを指定できます。unset appfw profile コマンドを使用して、構成済みの設定をデフォルトに戻すことができます。フィールド形式ルールを指定するには、bind appfw コマンドを使用して、フィールドの型をフォームの Field およびアクション URL に、最小長と最大長の指定とともにバインドします。
コマンドラインを使用して、フィールドの種類を追加、削除、または表示するには、次の操作を行います。
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」の使用はオプションです。たとえば、「フィールドタイプの追加」または「appfw フィールドタイプの追加」はどちらも有効なオプションです。フィールドタイプの名前は、正規化のために大文字と小文字を区別しません。上記の例に示すように、[郵便番号]、[郵便番号]、[郵便番号]、および [郵便番号] は、同じフィールドタイプを参照しています。
コマンドラインを使用してフィールド形式のチェックを構成するには
次のように、set appfw プロファイルコマンドまたは add appfw プロファイルコマンドを使用します。
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>
コマンドラインを使用してフィールド形式緩和ルールを構成するには
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では、フィールドタイプを管理できます。また、アプリケーションに関連付けられたプロファイルのペインで [Field Formats] セキュリティチェックを構成することもできます。
GUIを使用してフィールドタイプを追加、変更、または削除するには
- 「アプリケーションファイアウォール」ノードに移動します。「設定」で「 フィールドタイプの管理 」をクリックして、「アプリケーションファイアウォールのフィールドタイプの設定」ダイアログを表示します。
- [追加] をクリックして、新しいフィールドタイプを追加します。このペインの指示に従って、[Create] をクリックします。展開済みのルールで現在使用されていない場合は、ユーザーが追加したフィールドタイプを編集または削除することもできます。
GUI を使用してフィールド形式のセキュリティチェックを追加または変更するには
-
アプリケーションファイアウォールに移動 します > プロファイルをクリックし、ターゲットプロファイルを強調表示して、[ 編集]をクリックします。
-
[ 詳細設定 ] ウィンドウで、[ セキュリティチェック] をクリックします。
セキュリティチェックテーブルには、すべてのセキュリティチェックに対して現在構成されているアクション設定が表示されます。設定には2つのオプションがあります。
- [フィールド書式] の [ブロック]、[ログ]、[統計]、および [学習] アクションを有効または無効にするだけの場合は、テーブルのチェックボックスをオンまたはオフにして [OK] をクリックし、[保存して閉じる] をクリックして [セキュリティ][チェック] ペイン。
- このセキュリティー検査の追加オプションを構成する場合は、「フィールド書式」をダブルクリックするか、行を選択して「アクション設定」をクリックして、「 デフォルトのフィールド書式」に次のオプションを表示します。
-
[Field Type]：デフォルトのフィールドタイプとして設定するフィールドタイプを選択します。組み込みのフィールド型とユーザー定義フィールド型を選択できます。展開された文字マップもリストに含まれており、選択することができます。
-
[Minimum Length]：各フィールドに入力する必要がある最小文字数を指定します。指定可能な値は 0 ～ 65535 です。
-
「最大長」— 各フィールドに入力する必要がある最大文字数を指定します。指定可能な値は 1 ～ 65535 です。
[フィールド形式設定] ペインで、 ブロック、 ログ、 統計、および 学習アクションを編集することもできます。
-
上記の変更を行った後、[ OK ]をクリックして変更を保存し、[セキュリティチェック]テーブルに戻ります。必要に応じて、他のセキュリティー検査の設定に進むことができます。［ OK］ をクリックして［セキュリティチェック］ セクションで行ったすべての変更を保存し、［保存して閉じる ］をクリックして［セキュリティチェック］ウィンドウを閉じます。
GUIを使用してフィールドフォーマット緩和ルールを構成するには
-
アプリケーションファイアウォールに移動 します > プロファイルをクリックし、ターゲットプロファイルを強調表示して、[ 編集]をクリックします。
-
[詳細設定]ペインで、[緩和規則] をクリックします。[緩和規則] テーブルには、[フィールド形式] エントリがあります。[フィールド形式] [緩和規則] ダイアログにアクセスするには、ダブルクリックするか、この行を選択して [編集] ボタンをクリックします。リラクゼーションルールの追加、編集、削除、有効化、または無効化の 操作を実行できます。
すべての緩和規則をまとめて表示するには、[フィールド形式] 行をハイライト表示して [ビジュアライザー] をクリックします。展開されたリラクゼーションのビジュアライザーには、新しいルールを 追加 するか、既存のルールを 編集 するオプションがあります。ノードを選択し、緩和ビジュアライザの対応するボタンをクリックして、ルールのグループ を有効 または 無効に することもできます。
フィールド形式チェックでの学習機能の使用
学習アクションが有効の場合、Web App Firewall 学習エンジンはトラフィックを監視し、トリガーされた違反を学習します。これらの学習済みルールを定期的に検査できます。十分に検討した後、学習したルールをフィールド形式緩和ルールとして展開できます。
フィールド形式の学習機能拡張：リリース 11.0 で、Web App Firewall 学習機能拡張が導入されました。以前のリリースでは、学習されたフィールド形式の推奨事項がデプロイされると、Web App Firewall 学習エンジンは、新しいデータポイントに基づいて新しいルールを推奨する目的で、有効な要求の監視を停止します。これにより、設定済みのセキュリティ保護が制限されます。これは、学習データベースには、セキュリティチェックによって処理された有効な要求に見られる新しいデータの表現が含まれないためです。
違反は学習と結びつくことはなくなりました。学習エンジンは、違反に関係なく、フィールド形式の推奨事項を学習し、提示します。ブロックされたリクエストをチェックして現在のフィールド形式が制限的すぎて緩和する必要があるかどうかを判断するだけでなく、学習エンジンは許可されたリクエストを監視して、現在のフィールド形式が過度に許可されているかどうかを判断し、より多くの制限ルール。
次に、フィールド形式の学習動作の概要を示します。
[フィールド形式がバインドされていません]: このシナリオでは、動作は変更されません。すべての学習データは aslearn エンジンに送信されます。学習エンジンは、データセットに基づいてフィールド形式ルールを提案します。
フィールド形式がバインドされている: 以前のリリースでは、観察されたデータは違反の場合にのみaslearinエンジンに送信されます。学習エンジンは、データセットに基づいてフィールド形式ルールを提案します。11.0 リリースでは、違反がトリガーされなくても、すべてのデータがaslearn エンジンに送信されます。学習エンジンは、受信したすべての入力のデータセット全体に基づいて、フィールド形式ルールを提案します。
学習強化のためのユースケース：
学習した初期フィールド形式のルールがデータの小さなサンプルに基づいている場合、非典型的な値がいくつかあると、ターゲットフィールドに対して余りな勧告になることがあります。進行中の学習により、Web App Firewall は各リクエストのデータポイントを観察し、学習した推奨事項の代表的なサンプルを収集できます。これは、適切な範囲値で最適な入力フォーマットを展開するためのセキュリティをさらに強化するのに役立ちます。
フィールド形式の学習では、フィールドタイプのプライオリティと、次の学習しきい値の構成済み設定が使用されます。
- FieldFormatMinThreshold— 学習された緩和が生成されるまでに、特定のフォームフィールドが観察されなければならない最小回数。デフォルトは 1 です。
- FieldFormatPercentThreshold—学習された緩和が生成される前に、フォームフィールドが特定のフィールドタイプに一致した回数の割合。デフォルトは 0 です。
フィールド形式規則の推奨事項は、次の基準に基づいています。
- フィールドタイプの推奨事項：フィールドタイプの推奨は、既存のフィールドタイプの割り当てられた優先順位と、指定されたフィールドフォーマットのしきい値によって決まります。優先度によって、フィールドタイプが入力に対して照合される順序が決まります。数値が小さいほど、プライオリティが高くなります。たとえば、フィールドタイプ整数の方が優先度 (30) が高いため、フィールドタイプの英数字 (50) よりも先に評価されます。しきい値は、データポイントの代表的なサンプルを収集するために評価される入力の数を決定します。設定済みのフィールドタイプに適切な優先順位を割り当てて、 fieldFormatPercentThreshold パラメータおよび fieldFormatMinThreshold パラメータに適切な 学習設定 値を設定することは、正しいフィールドフォーマットの推奨事項を取得するために不可欠です。設定されたしきい値に基づいて、プライオリティが最も高いフィールドタイプが最初に入力と照合されます。一致がある場合は、他のフィールドタイプを考慮せずにこのフィールドタイプが提案されます。たとえば、3 つの既定のフィールドタイプ (整数、英数字、および any) は、すべての入力に数字のみが含まれている場合に一致します。ただし、整数は優先順位が最も高いため推奨されます。
- 最小長と最大長の推奨：フィールド・フォーマットの最小長と最大長の計算は、フィールド・タイプの決定とは無関係に行われます。フィールド形式の長さの計算は、観測されたすべての入力の平均長さに基づいています。この計算された平均値の半分が最小値として示唆され、この平均値の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 を使用して学習したデータを表示または使用するには
-
アプリケーションファイアウォールに移動 します > プロファイルをクリックし、ターゲットプロファイルを強調表示して、[ 編集]をクリックします。
-
[詳細設定] ウィンドウで、[学習ルール] をクリックします。「学習済みルール」(Learned Rules) テーブルの「フィールドフォーマット」(Field Formats) エントリを選択し、ダブルクリックすると、学習済みルールにアクセスできます。学習したルールを展開するか、緩和ルールとして展開する前にルールを編集できます。ルールを破棄するには、ルールを選択して [スキップ] ボタンをクリックします。一度に編集できるルールは 1 つだけですが、複数のルールを選択して展開またはスキップできます。
また、「学習済みルール」(Learned Rules) テーブルの「フィールドフォーマット」(Field Formats) エントリを選択し、「ビジュアライザー」(Visualizer) をクリックして、学習済みのすべての違反の統合ビューを表示することもできます。ビジュアライザーを使用すると、学習したルールを簡単に管理できます。データの包括的なビューを 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 を使用してログメッセージにアクセスするには
Citrix GUIには、ログメッセージを分析するための非常に便利なツール（Syslogビューア）が含まれています。Syslog ビューアには、次の複数のオプションがあります。
-
[アプリケーションファイアウォール] > [プロファイル] に移動し、ターゲットプロファイルを選択して [セキュリティチェック] をクリックします。[フィールド形式] 行をハイライト表示し、[ログ] をクリックします。プロファイルの Field Formats セキュリティ チェックから直接ログにアクセスすると、ログメッセージが除外され、これらのセキュリティチェック違反に関連するログのみが表示されます。
-
「 Citrix ADC 」>「 システム 」>「 監査 」の順に選択して、Syslogビューアにアクセスすることもできます。[ 監査メッセージ ] セクションで、[ Syslog メッセージ ] リンクをクリックして Syslog Viewerを表示します。このビューアーには、他のセキュリティチェック違反ログを含むすべてのログメッセージが表示されます。これは、要求処理中に複数のセキュリティー検査違反がトリガーされる可能性がある場合のデバッグに役立ちます。
-
[アプリケーションファイアウォール] > [ポリシー] > [監査] に移動します。[ 監査メッセージ ] セクションで、[Syslog メッセージ] リンクをクリックして 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|Citrix ADC|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-->
フィールド形式違反の統計情報
stats アクションが有効な場合、Web App Firewall がこのセキュリティチェックに対して何らかのアクションを実行すると、Field Formats チェックに対応するカウンタが増加します。統計は、トラフィック、違反、およびログのレートと合計数について収集されます。ログカウンタの増分は、構成された設定によって異なります。たとえば、ブロックアクションが有効になっている場合、3 つのフィールド形式違反を含むページに対する要求では、最初のフィールド形式違反が検出されるとすぐにページがブロックされるため、stats カウンタが 1 つ増えます。ただし、ブロックが無効になっている場合、同じ要求を処理すると、違反とログの統計カウンタが 3 ずつ増加します。これは、フィールド形式違反ごとに個別のログメッセージが生成されるためです。
コマンドラインを使用してフィールドフォーマットの統計を表示するには
コマンドプロンプトで入力します。
sh appfw stats
特定のプロファイルの統計情報を表示するには、次のコマンドを使用します。
stat appfw profile <profile name>
GUI を使用してフィールド形式の統計を表示するには
- [システム] > [セキュリティ] > [アプリケーションファイアウォール] に移動します。
- 右側のペインで、[統計 リンク] にアクセスします。
- スクロールバーを使用して、フィールド形式の違反とログに関する統計を表示します。統計テーブルはリアルタイムデータを提供し、7秒ごとに更新されます。
展開のヒント
- フィールド形式のアクションログ、学習および統計を有効にします。
- アプリケーションへのトラフィックの代表的なサンプルを実行した後、学習した推奨事項を確認します。
- 学習したルールの大部分でフィールドタイプが推奨される場合は、そのフィールドタイプをデフォルトのフィールドタイプとして設定します。最小長と最大長については、これらの規則で示されている最も広い範囲を使用してください。
- 異なるフィールドタイプまたは異なる最小/最大長が適している他のフィールドのルールを展開します。
- ブロッキングを有効にし、学習を無効にします。
- 統計とログを監視します。かなりの数の違反がまだトリガーされている場合は、ログメッセージを確認して、違反がブロックされているはずの悪意のある要求を表していることを確認することをお勧めします。有効なリクエストに違反のフラグが付けられている場合は、設定済みのフィールド形式ルールを編集してさらに緩和するか、再度学習を有効にして、新しいデータポイントに基づく推奨事項を取得できます。
注: 新しい推奨ラーニングを取得することで、設定を微調整できます。
ハイライト
フィールド形式のセキュリティチェックについては、次の点に注意してください。
- 保護：最適なフィールド形式ルールを設定することで、多くの攻撃から保護できます。たとえば、フィールドに整数のみを含めることができるように指定した場合、ハッカーはこのフィールドを使用してSQLインジェクションまたはクロスサイトスクリプティング攻撃を開始できません。このような攻撃を開始するために必要な入力は、構成されたフィールド形式の要件を満たさないためです。 。
- パフォーマンス：フィールド形式ルールで、入力に許容される最小長と最大長を制限できます。これにより、悪意のあるユーザーがサーバーに処理オーバーヘッドを追加しようとする際に過度に大きな入力文字列を入力するのを防ぎ、さらに悪いことに、スタックオーバーフローのためにサーバーがコアをダンプするのを防ぐことができます。入力サイズを制限することで、正当な要求の処理に要する時間を短縮できます。
- フィールド形式の設定：フィールド形式の保護を使用するには、いずれかのアクション（ブロック、ログ、統計、学習）を有効にする必要があります。また、フィールド書式ルールを指定して、フォームフィールドで許可される入力を識別することもできます。
- 文字マップの選択とフィールドタイプ：文字マップとフィールドタイプの両方で正規表現を使用します。ただし、文字コード表では、使用できる文字のリストを絞り込むことで、より具体的な式が得られます。たとえば、janedoe@citrix.com などの入力の場合、学習エンジンは Field Type nohtml ではなく、文字マップを推奨する場合があります [。@-za-Z] は、許可された非アルファ文字のセットを狭めるため、より具体的な場合があります。文字コード表オプションでは、アルファ文字の他に、ピリオド (.) とアットマーク (@) の 2 つの非英文字のみを使用できます。
- 継続的な学習：Web App Firewall は、すべての受信データ（違反および許可された入力）を監視して考慮し、ルールを推奨するための学習テーブルを構築します。新しい受信データが到着すると、ルールが改訂され、更新されます。バインドされたフィールド書式ルールがすでにある場合でも、新しいフィールド書式ルールがフィールドに対して提案されます。設定されたフィールド形式が制限的すぎて、有効な要求をブロックしている場合は、よりリラックスしたフィールド形式を展開できます。同様に、現在のフィールド形式が一般的すぎる場合は、より制限の厳しいフィールド形式を展開することで、セキュリティをさらに強化し、強化することができます。
- ルールの上書き：フィールドと URL の組み合わせに対してルールがすでに展開されている場合、GUI を使用してフィールド形式を更新できます。既存のルールを置き換えるかどうかを確認するダイアログボックスが表示されます。コマンドラインインターフェイスを使用している場合は、以前のバインドを明示的にバインド解除してから、新しいルールをバインドする必要があります。
- 複数一致：複数のフィールド形式が特定のフィールド名とそのアクション URL と一致する場合、Web App Firewall は、適用対象の 1 つを任意に選択します。
- バッファ境界：フィールド値が複数のストリーミングバッファにまたがり、フィールド値のこれら 2 つの部分の形式が異なる場合、「any」に対応するフィールド形式が学習データベースに送信されます。
- フィールド形式とフィールドコンシステンシチェック：フィールドフォーマットチェックとフィールドコンシステンシチェックはいずれも、フォームベースの保護チェックです。[フィールド形式] チェックでは、フォームフィールドの一貫性チェックとは異なる種類の保護が提供されます。フォームフィールドの一貫性チェックは、ユーザーから返される Web フォームの構造が損なわれていないこと、HTML で設定されたデータ形式の制限が尊重されていること、および非表示フィールドのデータが変更されていないことを確認します。これは、Webフォーム自体から派生したもの以外のWebフォームに関する特定の知識なしに行うことができます。[Field Formats] チェックでは、各フォームフィールドのデータが、手動で設定した特定の書式制限と一致しているか、学習機能が生成され、承認したことを確認します。言い換えれば、フォームフィールドの一貫性チェックは一般的な Web フォームのセキュリティを強化し、フィールドフォーマットチェックは Web フォームの許可された入力に特定のルールを適用します。