ファイルのアップロードなどの大規模な要求の処理では、特定の要求がブロックされ、「413 要求エンティティが大きすぎます」というメッセージが表示されることがあります。
NSX Advanced Load Balancer は、次のような要求に対して、アラートをトリガしたり、アップロードをブロックしたりすることができます。
ファイル サイズが、仮想サービス HTTP プロファイルの [クライアントの最大本文サイズ] フィールドに設定されている制限を超えている。
バイナリ アップロード データに対する
System-Default-Policy
ルールのランダム一致により、WAF がモードに基づいて要求をブロックまたはフラグ付けする。入力に対するルールの実行時間が長すぎるために正規表現の一致の制限を超え、WAF が実行を終了する。
サイズの大きい要求(通常のファイルのアップロードなど)の場合、以下で説明するように一部が処理されるため、処理の方法が異なります。
サイズの大きなアップロードを処理するパラメータ
大きなファイルのアップロードでは、次の 2 つの構成パラメータが考慮されます。
[クライアントの最大本文サイズ]:NSX Advanced Load Balancer ユーザー インターフェイスで、 に移動して、HTTP ポリシーを構成します。[DDoS] タブの [クライアントの最大本文サイズ] フィールドは、クライアント要求の最大本文サイズを定義します。この値は、単一の HTTP 要求の一部としてのクライアント POST のサイズを制限します。WAF バイパス ルールの場合、この値はオーバーライドされ、考慮されません。それ以外の場合、構成された値が [WAF プロファイル] で構成された [クライアントの完全なヘッダーの最大サイズ] よりも小さい場合、WAF に到達する前に「413 エラー メッセージ」が表示され、プロキシでバッファリングが失敗します。これを回避するには、[クライアントの最大ヘッダー フィールド サイズ] で構成された値を更新して、[クライアントの完全なヘッダーの最大サイズ] で構成された値よりも大きくなるようにします。
注:[クライアントの最大本文サイズ] がデフォルト値のゼロ(制限なし)に設定されている場合、この値は常に [クライアントの完全なヘッダーの最大サイズ] よりも大きくなります。
[クライアントの完全なヘッダーの最大サイズ]:NSX Advanced Load Balancer ユーザー インターフェイスで、 に移動して、[WAF プロファイル] を構成します。 セクションの [クライアントの完全なヘッダーの最大サイズ] フィールドは、WAF によってスキャンされるクライアント要求本文で許可される最大サイズを定義します。クライアント要求のサイズがこのフィールドで構成された値よりも大きい場合、定義されたサイズに応じて、本文の一部が WAF を介してスキャンされます。
System-Default-Policy
ルールの一致が原因で WAF が要求を拒否すると、要求本文の残りは破棄されます。WAF が要求を許可すると、本文の残りがバックエンドでストリーミングされます。部分スキャンによってエラーがトリガされるのを回避するため、[部分スキャンによる要求本文の解析エラーを無視します] チェックボックスが選択されていることを確認します。
これは、HTTP 1.0 と HTTP 2.0 の両方でサポートされます。
これは、
content-length
要求でのみサポートされ、チャンク エンコードされた POST ではサポートされません。WAF が検出モードで有効になっていて、チャンク エンコードされた POST を受信した場合、POST のサイズが WAF プロファイルで定義されている [クライアントの完全なヘッダーの最大サイズ] よりも大きいと、その POST は拒否されます。
例
特定のアップロードおよび対応する WAF ログ エントリの例を次に示します。
例 1:
クライアント要求サイズが HTTP プロファイルで構成された最大値を超えているため、「413 メッセージ」が表示され、要求が拒否されました。
WAF が要求を検査しなかったため、WAF の状態は「パス」になります。
このエラーを回避するには、[クライアントの最大本文サイズ] の値を増やします。
例 2:
サイズ制限が増えているため、制限に達しませんでした。
要求が拒否され、「403 メッセージ」が表示されます。
同時に、PDF の一部が WAF CRS ルールに一致すると、要求は拒否され、状態は「拒否」になります。
WAF のバイパス
特定の大規模な要求や特定のアップロード要求が WAF を通過するのを回避できます。一部のファイル拡張子は静的コンテンツであるため、WAF チェックからバイパスされます。静的拡張子の構成の詳細については、「WAF プロファイルの構成」を参照してください。
次のセクションで説明するように、[Modsec バイパス ルール] を使用してアップロードを完全にバイパスすることもできます。
Modsec バイパス ルール
Modsec バイパス ルールのいくつかの例を次に示します。URL を使用してこれらを構成することをお勧めします。ID は、ModSecurity ハンドブックの説明に従って、0 ~ 99.999 のローカル範囲内にするか、プライベート予約された範囲内にする必要があります。ここでは、例を示すために数字が選択されています。展開内で一意のルール ID を確認してください。
単一の URL:
SecRule REQUEST_URI "@rx /app/upload/" id:90001,phase:1,t:none,nolog,pass,ctl:ruleEngine=off
複数の URL:
SecRule REQUEST_URI "@rx /app/upload/|/app/upload_two/|/app/upload_three/" id:90002,phase:1,t:none,nolog,pass,ctl:ruleEngine=off
このルールは、@contains
、@startwith
などの他の演算子を使用して変更できます。
Content-Length 別:
SecRule REQUEST_HEADERS:Content-Length “@gt 1048576” phase:1,id:90003,nolog,pass,ctl:ruleEngine=off
Content-Length ではなく、URL を使用してルールを構成することをお勧めします。
悪意のあるアップロードへの効果
これらは、攻撃者がサーバに対して悪意のあるアップロードを実行するケースです。このようなアップロードには、マルウェア、ランサムウェア、ウイルス、およびその他のファイルベースの攻撃(pdf リーダーのエクスプロイト)などがあります。攻撃を検出して回避するには、アプリケーションのアップロード ディレクトリでウイルス マルウェア スキャン ツールを使用することをお勧めします。
アプリケーション セキュリティに対するアップロード バイパスの効果
アップロード要求または URL の適切な範囲に基づいて大規模なバイナリ データ バイパスが構成されている場合、WAF はデータを検査できず、影響は最小限になります。
特定の大規模な要求や特定のアップロード要求をバイパスして WAF を通過するのを回避できます。一部のファイル拡張子は静的コンテンツであるため、WAF チェックからバイパスされます。
トラフィックの処理中に大量のアップロードがキャッシュされます。要求の一部が不要でバイパスされた場合でも、その要求の他の部分が検査されるまでキャッシュされます。したがって、アップロード パラメータのみを除外しても、最適な結果を得られるわけではありません。