サーバレベル HTTP 正規化オプションの選択
ライセンス: Protection
サーバレベルのオプションは、モニタ対象サーバごとに設定するか、すべてのサーバに対してグローバルに設定するか、またはサーバ リストに対して設定することができます。また、事前定義のサーバ プロファイルを使用してこれらのオプションを設定するか、またはご使用の環境のニーズに合わせて個別に設定することができます。これらのオプション、またはこれらのオプションを設定するデフォルト プロファイルの 1 つを使用して、トラフィックを正規化する HTTP サーバ ポート、正規化するサーバ応答ペイロードの量、および正規化するエンコードのタイプを指定します。
以下の説明でプリプロセッサ ルールが言及されていない場合、オプションにはプリプロセッサ ルールが関連付けられていません。
ネットワーク
1 つ以上のサーバの IP アドレスを指定するには、このオプションを使用します。1 つの IP アドレスまたはアドレス ブロックを指定するか、そのいずれかまたは両方から成るカンマで区切ったリストを指定できます。
デフォルト プロファイルを含めてプロファイルの合計数は最大 255 ですが、さらに、HTTP サーバ リストに最大 496 文字(約 26 エントリ)を含めることができ、すべてのサーバ プロファイルに対して合計 256 のアドレス エントリを指定できます。ASA FirePOWER モジュール での IPv4 CIDR 表記と IPv6 プレフィクス長の使用法については、IP アドレスの表記規則を参照してください。
デフォルト ポリシーの default
設定では、別のターゲットベース ポリシーでカバーされていないモニタ対象ネットワーク セグメントのすべての IP アドレスが指定されることに注意してください。したがって、デフォルト ポリシーの IP アドレスまたは CIDR ブロック/プレフィックス長は指定できず、また指定する必要もありません。また、別のポリシーでこの設定を空白にしたり、 any
を表すアドレス表記(0.0.0.0/0 または ::/0)を使用したりすることはできません。
また、ターゲットベース ポリシーがトラフィックを処理するようにするには、識別するネットワークがターゲットベース ポリシーを設定するネットワーク分析ポリシーによって処理されるネットワーク、およびゾーンに一致するかまたはサブセットになっている必要があることにも注意してください。詳細については、ネットワーク分析ポリシーによる前処理のカスタマイズを参照してください。
ポート
プリプロセッサ エンジンが HTTP トラフィックを正規化するポート。ポート番号が複数ある場合は、カンマで区切ります。
サイズ超過のディレクトリ長(Oversize Dir Length)
指定された値よりも長い URL ディレクトリを検出します。
このオプションのイベントを生成するには、ルール 119:15 を有効にします。詳細については、ルール状態の設定を参照してください。
クライアント フローの深さ(Client Flow Depth)
[ポート(Ports)] で定義されているクライアント側 HTTP トラフィックについて、ルールで検査される raw HTTP パケットのバイト数(ヘッダーとペイロード データを含む)を指定します。ルール内の HTTP コンテンツ ルール オプションによって要求メッセージの特定の部分が検査される場合は、[クライアント フローの深さ(Client Flow Depth)] は適用されません。詳細については、HTTP コンテンツ オプションを参照してください。
-1 ~ 1460 の値を指定できます。シスコは、[クライアント フローの深さ(Client Flow Depth)] をその最大値に設定することを推奨しています。次のいずれかを指定します。
– 1 ~ 1460 を指定すると、最初のパケットで指定のバイト数が検査されます。最初のパケットのバイト数が指定のバイト数よりも少ない場合は、パケット全体が検査されます。指定された値は、セグメント化されたパケットと再構成されたパケットの両方に適用されることに注意してください。
また、値 300 を指定すると、通常は、多くのクライアント要求ヘッダーの終わりにある大きな HTTP Cookie のインスペクションが排除されることにも注意してください。
– 0 を指定すると、すべてのクライアント側トラフィックが検査されます。これにはセッション内の複数のパケットが含まれ、必要な場合には 1460 バイトの制限を超えることもあります。この値はパフォーマンスに影響する可能性があることに注意してください。
– -1 を指定すると、クライアント側のすべてのトラフィックが無視されます。
サーバ フローの深さ(Server Flow Depth)
[ポート(Ports)] で指定されたサーバ側 HTTP トラフィックについて、ルールで検査される raw HTTP パケットのバイト数を指定します。[HTTP 応答の検査(Inspect HTTP Responses)] が無効である場合は raw ヘッダーとペイロードが検査され、[HTTP 応答の検査(Inspect HTTP Response)] が有効である場合は、raw 応答ボディのみが検査されます。
[サーバ フローの深さ(Server Flow Depth)] では、[ポート(Ports)] で定義されているサーバ側 HTTP トラフィックについて、ルールで検査されるセッション内の raw サーバ応答データのバイト数を指定します。このオプションを使用して、HTTP サーバ応答データのインスペクションのレベルとパフォーマンスのバランスを調整できます。ルール内の HTTP コンテンツ オプションによって要求メッセージの特定の部分が検査される場合は、Server Flow Depth は適用されません。詳細については、HTTP コンテンツ オプションを参照してください。
クライアント フローの深さ(Client Flow Depth)とは異なり、サーバ フローの深さ(Server Flow Depth)では、ルールが検査するバイト数を、HTTP 要求パケットごとではなく、HTTP 応答ごとのバイト数として指定します。
-1 ~ 65535 の値を指定できます。シスコは、[サーバ フローの深さ(Server Flow Depth)] をその最大値に設定することを推奨しています。次のいずれかの値を指定できます。
– 1 ~ 65535 の範囲の値:
[HTTP 応答の検査(Inspect HTTP Responses)] が 有効 である場合、raw HTTP 応答ボディのみが検査され、raw HTTP ヘッダーは検査されません。また、[圧縮データの検査(Inspect Compressed Data)] が有効である場合は、圧縮解除データも検査されます。
[HTTP 応答の検査(Inspect HTTP Responses)] が 無効 である場合、raw パケット ヘッダーとペイロードが検査されます。
セッションの応答バイト数が指定の値よりも少ない場合は、そのセッションで、ルールにより(必要に応じて複数パケットにわたって)すべての応答パケットが完全に検査されます。セッションの応答バイト数が指定の値よりも多い場合、そのセッションで、ルールにより(必要に応じて複数パケットにわたって)指定のバイト数だけが検査されます。
フローの深さ(Flow Depth)の値が小さいと、[ポート(Ports)] で定義されているサーバ側トラフィックを対象とするルールで、検出漏れが発生する可能性があります。これらのルールのほとんどは HTTP ヘッダーまたはコンテンツ(通常、非ヘッダー データの先頭の約 100 バイト以内)を対象とします。通常はヘッダーの長さは 300 バイト未満ですが、ヘッダー サイズは異なることがあります。
指定された値は、セグメント化されたパケットと再構成されたパケットの両方に適用されることにも注意してください。
– 0 を指定すると、[ポート(Port)] で定義されているすべての HTTP サーバ側トラフィックでパケット全体が検査されます。これにはセッションでの 65535 バイトよりも大きな応答データも含まれます。
この値はパフォーマンスに影響する可能性があることに注意してください。
– -1
[HTTP 応答の検査(Inspect HTTP Responses)] が 有効 な場合、raw HTTP ヘッダーだけが検査され、raw HTTP 応答ボディは検査されません。
[HTTP 応答の検査(Inspect HTTP Responses)] が 無効 である場合、[ポート(Ports)] で定義されているすべてのサーバ側トラフィックは無視されます。
最大ヘッダー長(Maximum Header Length)
[HTTP 応答の検査(Inspect HTTP Responses)] が有効である場合は、HTTP 要求、および HTTP 応答で、指定されている最大バイト数よりも長いヘッダー フィールドを検出します。値 0 を指定すると、このオプションが無効になります。有効にするには、1 ~ 65535 の値を指定します。
このオプションのイベントを生成するには、ルール 119:19 を有効にします。詳細については、ルール状態の設定を参照してください。
最大ヘッダー数(Maximum Number of Headers)
HTTP 要求でヘッダー数がこの設定を超えている場合にそのことを検出します。有効にするには、1 ~ 1024 の値を指定します。
このオプションのイベントを生成するには、ルール 119:20 を有効にします。詳細については、ルール状態の設定を参照してください。
最大スペース数(Maximum Number of Spaces)
折りたたみ行のスペースの数が HTTP 要求のこの設定と等しいか、超えている場合にそのことを検出します。値 0 を指定すると、このオプションが無効になります。有効にするには、1 ~ 65535 の値を指定します。
このオプションのイベントを生成するには、ルール 119:26 を有効にします。詳細については、ルール状態の設定を参照してください。
HTTP クライアント ボディの抽出の深さ(HTTP Client Body Extraction Depth)
HTTP クライアント要求のメッセージ ボディから抽出するバイト数を指定します。侵入ルールを使用して抽出データを検査するには、 content
または protected_content
キーワードを [HTTP クライアント ボディ(HTTP Client Body)] オプションと共に選択します。詳細については、HTTP コンテンツ オプションを参照してください。
-1 ~ 65495 の値を指定します。クライアント ボディを無視するには、-1 を指定します。クライアント ボディ全体を抽出するには、0 を指定します。抽出対象のバイト数を指定すると、システム パフォーマンスが向上することがある点に注意してください。また、侵入ルールで [HTTP クライアント ボディ(HTTP Client Body)] オプションが機能するためには、0 ~ 65495 の値を指定する必要があります。
小さいチャンク サイズ(Small Chunk Size)
チャンクが小さいとみなされるサイズの最大バイト数を指定します。1 ~ 255 の値を指定します。値 0 を指定すると、異常な小さなセグメントの連続の検出が無効になります。詳細については、[連続する小さいチャンク(Consecutive Small Chunks)] オプションを参照してください。
連続する小さいチャンク(Consecutive Small Chunks)
チャンク転送エンコードを使用するクライアント トラフィックまたはサーバ トラフィックで異常に大量であるとみなされる、連続する小さなチャンクの数を指定します。[小さいチャンク サイズ(Small Chunk Size)] オプションは、小さなチャンクの最大サイズを指定します。
たとえば、10 バイト以下のチャンクが 5 つ連続していることを検出するには、[小さいチャンク サイズ(Small Chunk Size)] に 10 を設定し、[連続する小さいチャンク(Consecutive Small Chunks)] に 5 を設定します。
大量の小さなチャンクが検出される場合にイベントをトリガーするには、クライアント トラフィックの場合はプリプロセッサ ルール 119:27 を有効にし、サーバ トラフィックの場合はルール 120:7 を有効にします。[小さいチャンク サイズ(Small Chunk Size)] が有効であり、このオプションが 0 または 1 に設定されている場合にこれらのルールを有効にすると、指定されたサイズ以下のすべてのチャンクでイベントがトリガーとして使用されます。詳細については、ルール状態の設定を参照してください。
HTTP メソッド(HTTP Methods)
システムがトラフィックで検出すると予期される、GET および POST 以外の HTTP 要求メソッドを指定します。複数の値はカンマで区切ります。
侵入ルールでは、HTTP メソッドのコンテンツを検索するために、 content
または protected_content
キーワードが HTTP Method 引数と共に使用されます。HTTP コンテンツ オプションを参照してください。GET、POST、およびこのオプションで設定されているメソッド以外のメソッドがトラフィックで検出される場合にイベントを生成するには、ルール 119:31 を有効にします。
アラートなし(No Alerts)
関連するプリプロセッサ ルールが有効である場合に、侵入イベントを無効にします。
(注) このオプションでは、HTTP 標準テキスト ルールと共有オブジェクトのルールは無効になりません。
HTTP ヘッダーの正規化(Normalize HTTP Headers)
[HTTP 応答の検査(Inspect HTTP Responses)] が有効な場合は、要求ヘッダーと応答ヘッダーの非 cookie データの正規化が有効になります。[HTTP 応答の検査(Inspect HTTP Responses)] が有効 ではない 場合は、要求ヘッダーと応答ヘッダーで cookie を含む HTTP ヘッダー全体の正規化が有効になります。
HTTP Cookie の検査(Inspect HTTP Cookies)
HTTP 要求ヘッダーからの cookie の抽出を有効にします。また、[HTTP 応答の検査(Inspect HTTP Responses)] が有効な場合は、応答ヘッダーからの set-cookie データの抽出も有効になります。cookie の抽出が不要な場合は、このオプションを無効にするとパフォーマンスが向上します。
Cookie:
および Set-Cookie:
のヘッダー名、ヘッダー行の先頭のスペース、およびヘッダー行の末尾の CRLF
は、cookie の一部ではなくヘッダーの一部として検査されます。
HTTP ヘッダーの Cookie の正規化(Normalize Cookies in HTTP headers)
HTTP 要求ヘッダーの cookie の正規化を有効にします。[HTTP 応答の検査(Inspect HTTP Responses)] が有効な場合は、応答ヘッダーの set-cookie データの正規化も有効になります。このオプションを選択する前に、[HTTP Cookie の検査(Inspect HTTP Cookies)] を選択する必要があります。
HTTP プロキシの使用を許可(Allow HTTP Proxy Use)
モニタ対象 Web サーバを HTTP プロキシとして使用できるようにします。このオプションは、HTTP 要求のインスペクションでのみ使用されます。
URI のみの検査(Inspect URI Only)
正規化された HTTP 要求パケットの URI 部分のみを検査します。
HTTP 応答の検査(Inspect HTTP Responses)
HTTP 応答の拡張インスペクションが有効になり、プリプロセッサは、HTTP 要求メッセージのデコードと正規化の他に、ルール エンジンによるインスペクションのために応答フィールドを抽出します。このオプションを有効にすると、応答ヘッダー、ボディ、ステータス コードなどがシステムにより抽出されます。また [HTTP Cookie の検査(Inspect HTTP Cookies)] が有効な場合は、set-cookie データも抽出されます。詳細については、HTTP コンテンツ オプション、HTTP エンコードのタイプと位置によるイベントの生成、および特定のペイロード タイプを指し示すを参照してください。
このオプションのイベントを生成するには、ルール 120:2 および 120:3 を有効にします。詳細については、ルール状態の設定を参照してください。
UTF エンコードを UTF-8 に正規化(Normalize UTF Encodings to UTF-8)
[HTTP 応答の検査(Inspect HTTP Responses)] が有効な場合、HTTP 応答内の UTF-16LE、UTF-16BE、UTF-32LE、および UTF32-BE エンコードが検出され、UTF-8 に正規化されます。
このオプションのイベントを生成するには、ルール 120:4 を有効にします。詳細については、ルール状態の設定を参照してください。
圧縮データの検査(Inspect Compressed Data)
[HTTP 応答の検査(Inspect HTTP Responses)] が有効な場合は、HTTP 応答ボディ内の gzip および deflate 互換圧縮データの圧縮解除と、正規化された圧縮解除データのインスペクションが有効になります。システムは、チャンク HTTP 応答データと非チャンク HTTP 応答データを検査します。システムは、必要に応じて複数のパケットにわたり圧縮解除データをパケット単位で検査します。つまり、システムが異なるパケットの圧縮解除データをインスペクションのために結合させることはありません。[圧縮データの最大深さ(Maximum Compressed Data Depth)]、[圧縮解除データの最大深さ(Maximum Decompressed Data Depth)]、または圧縮データの終わりに到達すると、圧縮解除が終了します。[無制限の圧縮解除(Unlimited Decompression)] を選択していない場合は、[サーバ フローの深さ(Server Flow Depth)] に到達すると、圧縮解除データのインスペクションが終了します。圧縮解除データを検査するには、 file_data
ルール キーワードを使用できます。詳細については、特定のペイロード タイプを指し示すを参照してください。
無制限の圧縮解除(Unlimited Decompression)
[圧縮データの検査(Inspect Compressed Data)](および任意で、[SWF ファイルの圧縮解除(LZMA)(Decompress SWF File(LZMA))]、[SWF ファイルの圧縮解除(Deflate)(Decompress SWF File(Deflate))]、または [PDF ファイルの圧縮解除(Deflate)(Decompress PDF File(Deflate))])が有効な場合、複数のパケットにわたって [圧縮解除データの最大深さ(Maximum Decompressed Data Depth)] がオーバーライドされます。つまり、このオプションにより、複数のパケットにわたる無制限の圧縮解除が有効になります。このオプションを有効にしても、単一パケット内での [圧縮データの最大深さ(Maximum Compressed Data Depth)] または [圧縮解除データの最大深さ(Maximum Decompressed Data Depth)] には影響しないことに注意してください。また、このオプションを有効にすると、変更のコミット時に、[圧縮データの最大深さ(Maximum Compressed Data Depth)] と [圧縮解除データの最大深さ(Maximum Decompressed Data Depth)] が 65535 に設定されることにも注意してください。グローバル HTTP 正規化オプションの選択を参照してください。
Javascript の正規化(Normalize Javascript)
[HTTP 応答の検査(Inspect HTTP Responses)] が有効な場合、HTTP 応答ボディ内での Javascript の検出と正規化を有効にします。プリプロセッサは unescape 関数や decodeURI 関数、String.fromCharCode メソッドなどの難読化 Javascript データを正規化します。プリプロセッサは、unescape、decodeURI、および decodeURIComponent 関数内の次のエンコードを正規化します。
– %XX
– %uXXXX
– 0xXX
– \xXX
– \uXXXX
プリプロセッサは連続するスペースを検出し、1 つのスペースに正規化します。このオプションが有効である場合、設定フィールドでは、難読化 Javascript データで許容する連続スペースの最大数を指定できます。入力できる値は、1 ~ 65535 です。値 0 を指定すると、このフィールドに関連付けられているプリプロセッサ ルール(120:10)が有効かどうかに関係なく、イベントの生成が無効になります。
プリプロセッサは、Javascript の正符号(+)演算子も正規化し、この演算子を使用して文字列を連結します。
file_data
キーワードを使用して、侵入ルールに対し正規化された Javascript データを指し示すことができます。詳細については、特定のペイロード タイプを指し示すを参照してください。
このオプションのイベントを生成するには、次に示すように、ルール 120:9、120:10、および 120:11 を有効にします。
表 19-6 [Javascript の正規化(Normalize Javascript)] オプションのルール
|
|
120:9 |
プリプロセッサ内の難読化レベルが 2 以上である。 |
120:10 |
Javascript 難読化データで連続するスペースの数が、許容される連続スペースの最大数として設定された値以上である。 |
120:11 |
エスケープされたデータまたはエンコードされたデータに、複数のエンコード タイプが含まれている。 |
詳細については、ルール状態の設定を参照してください。
SWF ファイルの圧縮解除(LZMA)(Decompress SWF File(LZMA))および SWF ファイルの圧縮解除(Deflate)(Decompress SWF File(Deflate))
[HTTP Inspect の応答(HTTP Inspect Responses)] が有効な場合、これらのオプションは、HTTP 要求の HTTP 応答ボディ内にあるファイルの圧縮部分を圧縮解除します。
(注) HTTP GET 応答で見つかったファイルの圧縮部分のみを圧縮解除できます。
– [SWF ファイルの圧縮解除(LZMA)(Decompress SWF File(LZMA))] は、Adobe ShockWave Flash(.swf
)ファイルの LZMA 互換の圧縮部分を圧縮解除します。
– [SWF ファイルの圧縮解除(Deflate)(Decompress SWF File(Deflate))] は、Adobe ShockWave Flash(.swf
)ファイルの deflate 互換の圧縮部分を圧縮解除します。
[圧縮データの最大深さ(Maximum Compressed Data Depth)]、[圧縮解除データの最大深さ(Maximum Decompressed Data Depth)]、または圧縮データの終わりに到達すると、圧縮解除が終了します。[無制限の圧縮解除(Unlimited Decompression)] を選択していない場合は、[サーバ フローの深さ(Server Flow Depth)] に到達すると、圧縮解除データのインスペクションが終了します。圧縮解除データを検査するには、 file_data
ルール キーワードを使用できます。詳細については、特定のペイロード タイプを指し示すを参照してください。
このオプションのイベントを生成するには、次に示すように、ルール 120:12 および 120:13 を有効にします。
表 19-7 [SWF ファイルの圧縮解除(Decompress SWF File)] オプションのルール
|
|
120:12 |
deflate ファイルの圧縮解除に失敗 |
120:13 |
LZMA ファイルの圧縮解除に失敗 |
PDF ファイルの圧縮解除(Deflate)(Decompress PDF File(Deflate))
[HTTP Inspect の応答(HTTP Inspect Responses)] が有効な場合、[PDF ファイルの圧縮解除(Deflate)(Decompress PDF File(Deflate)] は、HTTP 要求の HTTP 応答ボディ内にある Portable Document Format(.pdf
)ファイルの deflate 互換の圧縮部分を圧縮解除します。システムは、 /FlateDecode
ストリーム フィルタが付いた PDF ファイルだけを圧縮解除できます。他のフィルタ( /FlateDecode /FlateDecode
など)はサポートしていません。
(注) HTTP GET 応答で見つかったファイルの圧縮部分のみを圧縮解除できます。
[圧縮データの最大深さ(Maximum Compressed Data Depth)]、[圧縮解除データの最大深さ(Maximum Decompressed Data Depth)]、または圧縮データの終わりに到達すると、圧縮解除が終了します。[無制限の圧縮解除(Unlimited Decompression)] を選択していない場合は、[サーバ フローの深さ(Server Flow Depth)] に到達すると、圧縮解除データのインスペクションが終了します。圧縮解除データを検査するには、 file_data
ルール キーワードを使用できます。詳細については、特定のペイロード タイプを指し示すを参照してください。
このオプションのイベントを生成するには、次に示すように、ルール 120:14、120:15、120:16、および 120:17 を有効にします。
表 19-8 [PDF ファイルの圧縮解除(Deflate)(Decompress PDF File(Deflate))] オプションのルール
|
|
120:14 |
ファイルの圧縮解除に失敗 |
120:15 |
圧縮タイプがサポート対象外のタイプであるため、ファイルの圧縮解除に失敗 |
120:16 |
PDF ストリーム フィルタがサポート対象外のフィルタであるため、ファイルの圧縮解除に失敗 |
120:17 |
ファイルの解析に失敗 |
元のクライアント IP アドレスの抽出(Extract Original Client IP Address)
X-Forwarded-For(XFF)ヘッダー、True-Client-IP、またはカスタム定義の HTTP ヘッダーから、元のクライアント IP アドレスを抽出できるようにします。侵入イベント ビューで、抽出された元のクライアント IP アドレスを表示できます。詳細については、イベントの表示を参照してください。
このオプションのイベントを生成するには、ルール 119:23、119:29、および 119:30 を有効にします。詳細については、ルール状態の設定を参照してください。
XFF ヘッダーの優先順位(XFF Header Priority)
[元のクライアント IP アドレスの抽出(Extract Original Client IP Address)] が有効な場合、システムが元のクライアント IP の HTTP ヘッダーを処理する順序を指定します。モニタ対象ネットワークで、X-Forwarded-For(XFF)または True-Client-IP 以外の元のクライアント IP ヘッダーが発生すると予測される場合は、[追加(Add)] をクリックしてプライオリティ リストに追加のヘッダー名を追加できます。追加したら、各ヘッダー タイプの横にある上下矢印アイコンを使用して、優先順位を調整します。HTTP 要求に複数の XFF ヘッダーがある場合は、優先順位が最も高いヘッダーだけが処理されます。
URI のログ(Log URI)
raw URI が存在する場合に、HTTP 要求パケットから raw URI を抽出できるようにし、このセッションで生成されるすべての侵入イベントにこの URI を関連付けます。
このオプションが有効である場合、侵入イベント テーブル ビューの [HTTP URI] 列に、抽出された URI の先頭 50 文字を表示できます。パケット ビューでは、URI 全体(最大 2048 バイト)を表示できます。詳細については、イベントの表示を参照してください。
ホスト名のログ(Log Hostname)
ホスト名が存在する場合に、HTTP 要求の Host ヘッダーからホスト名を抽出できるようにし、このセッションで生成されるすべての侵入イベントにこのホスト名を関連付けます。複数の Host ヘッダーがある場合は、1 番目のヘッダーからホスト名を抽出します。
このオプションが有効である場合、侵入イベント テーブル ビューの [HTTP ホスト名(HTTP Hostname)] 列に、抽出されたホスト名の先頭 50 文字を表示できます。パケット ビューでは、ホスト名全体(最大 256 バイト)を表示できます。詳細については、イベントの表示を参照してください。
このオプションのイベントを生成するには、ルール 119:25 を有効にします。詳細については、ルール状態の設定を参照してください。
プリプロセッサとルール 119:24 が有効である場合は、HTTP 要求で複数の Host ヘッダーが検出される場合でも、プリプロセッサはこのオプションの設定に関係なく、侵入イベントを生成することに注意してください。詳細については、追加の HTTP Inspect プリプロセッサ ルールの有効化を参照してください。
プロファイル(Profile)
HTTP トラフィック向けに正規化されたエンコードのタイプを指定します。システムには、ほとんどのサーバに適用できるデフォルト プロファイル、Apache サーバと IIS サーバ用のデフォルト プロファイル、およびモニタ対象トラフィックのニーズに合わせて調整できるカスタムのデフォルト設定があります。詳細については、サーバレベル HTTP 正規化エンコード オプションの選択を参照してください。
サーバレベル HTTP 正規化エンコード オプションの選択
ライセンス: Protection
サーバレベルの HTTP 正規化オプションを選択することで、HTTP トラフィック向けに正規化するエンコード タイプを指定し、このタイプのエンコードを含むトラフィックに対してイベントを生成させることができます。
以下の説明でプリプロセッサ ルールが言及されていない場合、オプションにはプリプロセッサ ルールが関連付けられていません。
ASCII エンコーディング
エンコードされた ASCII 文字をデコードし、ルール エンジンが ASCII エンコード URI でイベントを生成するかどうかを指定します。
このオプションのイベントを生成するには、ルール 119:1 を有効にします。詳細については、ルール状態の設定を参照してください。
UTF-8 エンコーディング
URI の標準 UTF-8 Unicode シーケンスをデコードします。
このオプションのイベントを生成するには、ルール 119:6 を有効にします。詳細については、ルール状態の設定を参照してください。
Microsoft %U エンコーディング
%u とその後に続く 4 文字を使用する IIS %u エンコード スキームをデコードします。この 4 文字は、IIS Unicode コードポイントに関連する 16 進数のエンコード値です。
ヒント 正規のクライアントが %u エンコードを使用することはほとんどないため、シスコは、%u エンコードによってエンコードされている HTTP トラフィックをデコードすることを推奨します。
このオプションのイベントを生成するには、ルール 119:3 を有効にします。詳細については、ルール状態の設定を参照してください。
ベア バイト UTF-8 エンコーディング
ベア バイト エンコードをデコードします。ベア バイト エンコードでは、UTF-8 値のデコード時に非 ASCII 文字が有効な値として使用されます。
ヒント ベア バイト エンコードにより、ユーザは IIS サーバをエミュレートし、非標準エンコードを正しく解釈することができます。正規のクライアントはこの方法で UTF-8 をエンコードしないため、シスコでは、このオプションを有効にすることを推奨しています。
このオプションのイベントを生成するには、ルール 119:4 を有効にします。詳細については、ルール状態の設定を参照してください。
Microsoft IIS エンコーディング
Unicode コードポイント マッピングを使用してデコードします。
ヒント これは主に攻撃と回避の試行で見られるため、シスコはこのオプションを有効にすることを推奨します。
このオプションのイベントを生成するには、ルール 119:7 を有効にします。詳細については、ルール状態の設定を参照してください。
二重エンコーディング
要求 URI を 2 回通過し、それぞれでデコードを実行するようにすることで、IIS 二重エンコード トラフィックをデコードします。これは通常は攻撃シナリオでのみ検出されるため、シスコはこのオプションを有効にすることを推奨します。
このオプションのイベントを生成するには、ルール 119:2 を有効にします。詳細については、ルール状態の設定を参照してください。
マルチスラッシュ難読化
1 つの行内の複数のスラッシュを 1 つのスラッシュに正規化します。
このオプションのイベントを生成するには、ルール 119:8 を有効にします。詳細については、ルール状態の設定を参照してください。
IIS バックスラッシュ難読化
バックスラッシュをスラッシュに正規化します。
このオプションのイベントを生成するには、ルール 119:9 を有効にします。詳細については、ルール状態の設定を参照してください。
ディレクトリ トラバーサル
ディレクトリ トラバーサルおよび自己参照用ディレクトリを正規化します。一部の Web サイトはディレクトリ トラバーサルを使用してファイルを参照するため、このタイプのトラフィックに対してイベントを生成するために、関連するプリプロセッサ ルールを有効にすると、誤検出が発生する可能性があります。
このオプションのイベントを生成するには、ルール 119:10 および 119:11 を有効にします。詳細については、ルール状態の設定を参照してください。
タブ難読化
スペース区切り記号としてタブを使用する非 RFC 標準を正規化します。Apache やその他の非 IIS Web サーバは、URL の区切り文字としてタブ文字(0x09)を使用します。
(注) このオプションの設定に関係なく、空白文字(0x20)がタブの前にある場合、HTTP Inspect プリプロセッサはそのタブをスペースとして扱います。
このオプションのイベントを生成するには、ルール 119:12 を有効にします。詳細については、ルール状態の設定を参照してください。
無効な RFC デリミタ
URI データの改行(\ n)を正規化します。
このオプションのイベントを生成するには、ルール 119:13 を有効にします。詳細については、ルール状態の設定を参照してください。
webroot ディレクトリ トラバーサル
URL の初期ディレクトリを越えて横断するディレクトリ トラバーサルを検出します。
このオプションのイベントを生成するには、ルール 119:18 を有効にします。詳細については、ルール状態の設定を参照してください。
タブ URI デリミタ
URI の区切り文字としてタブ文字(0x09)を有効にします。Apache、新しいバージョンの IIS、およびその他の一部の Web サーバは、URL の区切り文字としてタブ文字を使用します。
(注) このオプションの設定に関係なく、空白文字(0x20)がタブの前にある場合、HTTP Inspect プリプロセッサはそのタブをスペースとして扱います。
非 RFC 文字
対応するフィールドに追加された非 RFC 文字リストが、着信または発信 URI データ内に含まれている場合にそれを検出します。このフィールドを変更する場合は、バイト文字を表す 16 進表記を使用します。このオプションを設定する場合は、値を慎重に設定してください。非常に一般的な文字を使用すると、イベントが大量に発生する可能性があります。
このオプションのイベントを生成するには、ルール 119:14 を有効にします。詳細については、ルール状態の設定を参照してください。
最大チャンク エンコーディング サイズ
URI データで異常に大きなチャンク サイズを検出します。
このオプションのイベントを生成するには、ルール 119:16 および 119:22 を有効にします。詳細については、ルール状態の設定を参照してください。
パイプラインのデコードを無効にする
パイプライン処理された要求の HTTP デコードを無効にします。このオプションが無効である場合、パイプラインで待機する HTTP 要求には、デコードおよび分析は行われず、汎用パターン マッチングを使用した検査のみが行われるため、パフォーマンスが向上します。
Non-Strict URI 解析
Non-Strict URI 解析を有効にします。このオプションは、「GET /index.html abc xo qr \n」という形式の非標準 URI を受け入れるサーバでのみ使用します。このオプションを使用すると、デコーダは URI が 1 番目のスペースと 2 番目のスペースで囲まれているものと想定します。これは、2 番目のスペースの後に有効な HTTP 識別子がない場合でも同様です。
拡張 ASCII エンコーディング
HTTP 要求 URI の拡張 ASCII 文字の解析を有効にします。このオプションは、カスタム サーバ プロファイルでのみ使用可能であり、Apache、IIS、またはすべてのサーバ向けに提供されるデフォルト プロファイルでは使用できないことに注意してください。
HTTP サーバ オプションの設定
ライセンス: Protection
HTTP サーバ オプションを設定するには、次の手順に従います。HTTP サーバ オプションの詳細については、サーバレベル HTTP 正規化オプションの選択および サーバレベル HTTP 正規化エンコード オプションの選択を参照してください。
サーバレベルの HTTP 設定オプションの設定方法:
ステップ 1 [設定(Configuration)] > [ASA FirePOWER 設定(ASA FirePOWER Configuration)] > [ポリシー(Policies)] > [アクセス コントロール ポリシー(Access Control Policy)] の順に選択します。
[アクセス コントロール ポリシー(Access Control Policy)] ページが表示されます。
ステップ 2 編集するアクセス コントロール ポリシーの横にある編集アイコン( )をクリックします。
アクセス コントロール ポリシー エディタが表示されます。
ステップ 3 [詳細設定(Advanced)] タブを選択します。
アクセス コントロール ポリシーの詳細設定ページが表示されます。
ステップ 4 [ネットワーク分析と侵入ポリシー(Network Analysis and Intrusion Policies)] の横にある編集アイコン( )をクリックします。
[ネットワーク分析と侵入ポリシー(Network Analysis and Intrusion Policies)] ポップアップ ウィンドウが表示されます。
ステップ 5 [ネットワーク分析ポリシー リスト(Network Analysis Policy List)] をクリックします。
[ネットワーク分析ポリシー リスト(Network Analysis Policy List)] ポップアップ ウィンドウが表示されます。
ステップ 6 編集するポリシーの横にある編集アイコン( )をクリックします。
別のポリシーに未保存の変更がある場合に変更を破棄し、操作を続行するには、[OK] をクリックします。別のポリシーでの未保存の変更の保存方法については、競合の解決とポリシー変更の確定を参照してください。
[ポリシー情報(Policy Information)] ページが表示されます。
ステップ 7 左側のナビゲーション パネルで [設定(Settings)] をクリックします。
[設定(Settings)] ページが表示されます。
ステップ 8 [アプリケーション層プリプロセッサ(Application Layer Preprocessors)] の下の [HTTP 設定(HTTP Configuration)] を有効にしているかどうかに応じて、2 つの選択肢があります。
- 設定が有効な場合、[編集(Edit)] をクリックします。
- 設定が無効である場合、[有効(Enabled)] をクリックし、[編集(Edit)] をクリックします。
[HTTP 設定(HTTP Configuration)] ページが表示されます。ページ下部のメッセージには、設定を含むネットワーク分析ポリシー層が示されます。詳細については、ネットワーク分析ポリシーまたは侵入ポリシーでのレイヤの使用を参照してください。
ステップ 9 次の 2 つの対処法があります。
- 新しいサーバ プロファイルを追加します。ページの左側で [サーバ(Servers)] の横にある追加アイコン(
)をクリックします。[ターゲットの追加(Add Target)] ポップアップ ウィンドウが表示されます。クライアントの 1 つ以上の IP アドレスを [サーバ アドレス(Server Address)]
フィールドに指定し、[OK]
をクリックします。
単一の IP アドレスまたはアドレス ブロック、あるいはこれらのいずれかまたは両方をカンマで区切ったリストを指定できます。リストに入力できる文字数は最大 496 文字、すべてのサーバ プロファイルで指定できるアドレス項目の総数は 256、作成できるプロファイルの総数はデフォルト プロファイルを含めて 255 です。ASA FirePOWER モジュールでの IPv4 および IPv6 アドレス ブロックの使用については、IP アドレスの表記規則を参照してください。
ターゲットベース ポリシーがトラフィックを処理するようにするには、識別するネットワークがターゲットベース ポリシーを設定するネットワーク分析ポリシーによって処理されるネットワーク、およびゾーンに一致するかまたはサブセットになっている必要があることに注意してください。詳細については、ネットワーク分析ポリシーによる前処理のカスタマイズを参照してください。
ページの左側のサーバ リストに新しい項目が表示され、選択されていることを示すために強調表示されます。[設定(Configuration)] セクションが更新され、追加したプロフィールの現行設定が反映されます。
- 既存のプロファイルの設定を変更します。ページ左側の [サーバ(Servers)] の下で追加したプロファイルの設定済みアドレスをクリックするか、または [デフォルト(default)] をクリックします。
選択した項目が強調表示され、[設定(Configuration)] セクションが更新され、選択したプロファイルの現行設定が表示されます。既存のプロファイルを削除するには、削除するプロファイルの横にある削除アイコン( )をクリックします。
ステップ 10 オプションで、[ネットワーク(Networks)] フィールドにリストされているアドレスを変更し、ページの他の領域をクリックします。
ページの左側で、強調表示されているアドレスが更新されます。
デフォルト プロファイルでは [ネットワーク(Network)] の設定を変更できないことに注意してください。デフォルト プロファイルは、別のプロファイルで指定されていないネットワーク上のすべてのサーバに適用されます。
ステップ 11 [ポート(Ports)] フィールドに、HTTP Inspect でトラフィックを検査するポートを指定します。複数のポートを指定する場合は、カンマで区切ります。
ステップ 12 サーバレベル HTTP 正規化オプションの選択で説明するその他のオプションを変更できます。
ステップ 13 次の手順に従ってサーバ プロファイルを選択します。
- 独自のサーバ プロファイルを作成するには、[カスタム(Custom)] を選択します(詳細については、サーバレベル HTTP 正規化エンコード オプションの選択を参照)。
- すべてのサーバに対して適切な標準のデフォルト プロファイルを使用するには、[すべて(All)] を選択します。
- デフォルトの IIS プロファイルを使用するには、[IIS] を選択します。
- デフォルトの Apache プロファイルを使用するには、[Apache] を選択します。
ステップ 14 [カスタム(Custom)] を選択すると、カスタム オプションが表示されます。
ステップ 15 プロファイルで、使用する HTTP デコード オプションを設定します。
使用可能な正規化オプションの詳細についてはサーバレベル HTTP 正規化オプションの選択、参照してください。
ステップ 16 ポリシーを保存する、編集を続行する、変更を破棄する、基本ポリシーのデフォルト設定に戻す、変更をシステム キャッシュに残して終了する、のいずれかを行います。詳細については、競合の解決とポリシー変更の確定を参照してください。