Webアプリケーション・ファイアウォールの保護

Webアプリケーション・ファイアウォール・ポリシーの保護を追加および管理する方法について学習します。

Web Application Firewallは、Webアプリケーションを脅威から保護します。Web Application Firewallは、強制ポイントにアタッチされているリージョンベースのサービスです。Web Application Firewallの保護機能を使用すると、重要なWebアプリケーションを悪意のあるサイバー攻撃から保護できます。保護機能を使用して、受信リクエストと比較するルールを設定すると、リクエストに攻撃ペイロードが含まれているかどうかが判断されます。リクエストが攻撃であると判断されると、Web Application Firewallによってそのリクエストがブロックされるか、そのリクエストの警告が出されます。これらの攻撃は多様で、SQL注入、クロスサイト・スクリプト、HTML注入などの脅威があり、そのすべてをWeb Application Firewallの保護機能で検出してブロックできます。

Web Application Firewallの保護は、Webアプリケーションのモニタリング、ロギングおよびアクセス制御を目的として設計されたツールキットです。ツールキットを使用すれば、使用可能なすべての保護機能をどのように利用するかを判断できます。OCIでは絶えず更新がプッシュされ、保護機能のセキュリティ範囲が拡大されているため、この柔軟性がWeb Application Firewallの保護の中心的な要素となります。

Web Application Firewall保護機能の基本原則は次のとおりです。

受動性: 必要な機能はユーザーが決定するため、完全に制御することが可能です。
柔軟性: Oracle Web Application Firewallのセキュリティ・チームは、Open Web Application Security Project (OWASP)の上位10個と、一般的なWebアプリケーションの重要なCVEの両方に対処する保護機能のリストをキュレートしました。
量より質: Web Application Firewallの保護ルールは、他のWAF機能(アクセス制御など)が対応するHTTPトラフィックを検査するように設計された専用モジュールです。
予測可能性: Web Application Firewallの保護機能を完全に制御できるため、期待どおりの結果を得ることができます。保護ルールを定義して調整し、設定をそのままにしておけば、構成したとおりに機能します。

保護ルールは、Webトラフィックとルール基準を照合し、条件が満たされたときに実行するアクションを決定します。

Web Application Firewallポリシーには約490のルールがあり、最新バージョンのルールのみが含まれています。WAFポリシーには、CRS 3.0以降に基づくルールのみが含まれています。

ノート

ルールの作成に加えて、既存のルールを継続的に更新および最適化します。脆弱性の問題のため、ルールに緩和パターンを提供できません。

Web Application Firewallポリシーでは、カスタム保護ルールは使用できません。

次の保護タスクを実行できます:

詳細は、次を参照してください:

除外

保護ルールによって誤検出がトリガーされる場合もあります。誤検出を生成するリクエストに特定の引数またはCookieが含まれ、それを使用してそのリクエストがルールに通常行われるアクションから除外されることを特定できる場合は、例外を構成できます。除外は、OCIコンソールまたはAPIを使用して作成できます。次の除外パラメータを使用します:


名前	値
REQUEST_COOKIES	Cookieの値
ARGS	引数(問合せパラメータまたはPOST/PUTデータ)

保護機能のチューニング

WAFのチューニングに関するこの基本情報では、ルールのチューニング、ログの検査、機能除外の設定の基礎について概要を説明します。チューニングは、次の理由で便利です:

正当なリクエストをブロックする可能性が低くなります。
標準的なWebアプリケーション攻撃から保護します。
特定のWebアプリケーション攻撃から保護します。
スキャンの量が少なくなり、パフォーマンスが向上します。

次の表に、保護機能の用語と定義を示します。

保護機能の定義
用語	定義
チューニング	お客様のエンジニアまたはアナリストが保護機能や保護アクションを変更するプロセスのことで、アプリケーション・サーバーを保護しながら稼働させることが可能になります。アプリケーション・サーバーのロック・ダウンと、アプリケーション・サーバーによる業務の実行とのバランスがとれます。最適なチューニングを行うには、保護対象のアプリケーション・サーバーと、そのアプリケーション・サーバーの保護に使用できる保護機能に関する深い知識が必要です。
誤検出	誤検出は、保護機能がHTTPトランザクションと照合され、そのHTTPトランザクションが正当な(悪意のない)トランザクションである場合に発生します。
除外	保護機能を変更して、CookieまたはHTTP引数の値や値の名前を無視できるようにすること。

コラボレイティブ保護機能

「コラボレイティブ」とタグ付けされた特別な保護機能を使用すると、誤検出を制限できます。コラボレイティブ機能の動作は、その他の保護機能とは異なります。

コラボレイティブ保護機能では、スコアリングとしきい値のシステムでトラフィックが評価されます。個々の機能は、HTTPトランザクションの要素と機能署名を照合することで機能します。一致した場合は、ルールのアクション(検出やブロックなど)が実行されます。

それぞれのコラボレイティブ機能では、機能ごとのグループが使用されます。コラボレイティブ保護機能では、HTTPトランザクションの要素と個々のルールが複数一致しないとアクションが実行されません。

コラボレイティブ機能のアクションが実行されるには、次に示すように、コラボレイティブ機能に設定されている重みとしきい値に関連して、HTTPトランザクションの要素がコラボレイティブ・グループの個々の機能と一致する必要があります:

重み: 個々の機能をコラボレイティブ機能のしきい値に、どの程度関与させるかを表す数値。
しきい値: コラボレイティブ機能と一致するそれぞれの機能の重みを合計した最小値。

ノート

重みとしきい値は、必要に応じて変更できます。

コラボレイティブ保護機能に除外を加えると、コラボレイティブ機能内の個々の機能すべてにその除外が適用されます。

例

IDが9420000 - SQLインジェクション(SQLi)コラボレイティブ・グループ - SQLiフィルタ・カテゴリのコラボレイティブ機能キーでは、受信HTTPリクエストで特定タイプのSQLインジェクションがチェックされます。このコラボレイティブ機能は、9421000、9421400、9421600など、複数の機能で構成され、デフォルトの重み値はそれぞれ4です。

このコラボレイティブ機能(9420000)を有効にすると、WAFでは、着信HTTPリクエストごとに、コラボレイティブ機能を個別に構成する個々の機能(9421000、9421400、9421600)が実行され、一致する機能が検索されます。

ルールが処理されると、一致した機能を使用して、その重み(この場合は4+4+4 = 12)が追加され、合計がしきい値(10)と照合されます。HTTPリクエストがコラボレイティブ機能(9420000)を構成する個々の機能と一致するため、コラボレイティブ機能はトリガー済とマークされます。ロギングが構成されている場合は、一致した機能がログに記録されます。機能がどのように構成されているかに応じて、HTTPレスポンスが返されます。

詳細は、保護機能のリファレンスに関する項を参照してください。

コラボレイティブ保護機能キー

次に、コラボレイティブ保護機能キーをリストします:

9300000 - Local File Inclusion (LFI)コラボレイティブ・グループ - LFIフィルタ・カテゴリ
9320000 - リモート・コード実行(RCE)コラボレイティブ・グループ - UNIX RCEフィルタ・カテゴリ
9320001 - リモート・コード実行(RCE)コラボレイティブ・グループ - Windows RCEフィルタ・カテゴリ
9330000 - PHPインジェクション攻撃コラボレイティブ・グループ - PHPフィルタ・カテゴリ
9410000 - クロスサイト・スクリプティング(XSS)コラボレイティブ・グループ - XSSフィルタ・カテゴリ
9420000 - SQLインジェクション(SQLi)コラボレイティブ・グループ - SQLiフィルタ・カテゴリ

その他の保護機能

次にリストするのは、偽陽性が発生する保護機能で、その機能で検出しようとしている内容の理解を助ける説明と推奨事項が記載されています。キーの中には、除外を適用できないものもあります。


機能キー	機能名	ノート
920310 920311	欠落しているAcceptヘッダー	AcceptヘッダーのないリクエストがHTTPプロトコルの違反を意味しない場合でも、Acceptヘッダーのないリクエストはほとんどの場合、本物のリクエストではありません。ルールは、APIまたはカスタム・アプリケーション・リクエストについて警告している可能性があります。 APIまたはカスタム・アプリケーション・リクエストのスキャンを回避するには、トラフィックを送信する既知のアプリケーションのリストを収集し、カスタム・ルールをリクエストします。詳細は、RFC 7231の5.3.2項を参照してください。
920280	欠落しているHostヘッダー	RFC 7230の5.4項で説明されているように、サーバーは、ホスト・ヘッダー・フィールドがないHTTP/1.1リクエスト・メッセージに対して、および複数のホスト・ヘッダー・フィールドまたは無効なフィールド値を持つホスト・ヘッダー・フィールドを含むリクエスト・メッセージに対して、400 (不正なリクエスト)ステータス・コードで応答する必要があります。これは重要な保護方法であると同時に、WAFサーバーがリクエストの対象となるWAFポリシーを適切に識別できるようにします。WAFではホスト・ヘッダーでトラフィックを適切なオリジンに渡す必要があるため、このルールによって、誤検出の割合が高くなる可能性があります。
920320 920330	欠落しているUser-Agentヘッダー	このルールは、識別されていないユーザーがWebアプリケーションにアクセスできないようにします。User-Agentは、ユーザー情報を提供する様々なRFCで定義されたリクエスト・ヘッダーの1つです。リクエストにユーザー・エージェントが含まれている場合でも、それが実際の人間からのリクエストであるとはかぎりません。このルールは、ボットまたは「RFCに準拠していない」アプリケーションから発生する可能性のある「ダミー」攻撃に対する第1レベルの軽減策として機能します。ノート: 一部のAPIには、User-Agentヘッダーが含まれていない場合があります。APIリクエストが予想される場合は、API IPアドレスを許可リストに追加するか、このトラフィックが検査されないようにするカスタムWAFルールがあることを確認してください。詳細は、RFC 7231の5.5.3項を参照してください。このルールは不正または悪意のあるトラフィックの指標となりますが、正当なアプリケーションにはUser-Agentがない可能性があります。該当する場合は、アプリケーション所有者にUser-Agentの使用を依頼します。
920170 920171	GET/HEADリクエスト検証	RFC 7231の4.3.1項および4.3.2項で説明されているように、HEADおよびGETはオリジン・サーバーから情報を取得することを目的としたHTTPメソッドです。RFCによって禁止されていない場合でも、これらのタイプのメソッドを使用して本文またはペイロードを送信することは一般的な方法ではありません。通常、これはRFCのベスト・プラクティスに従っていない不適切に定義されたアプリケーションが原因で、悪意のあるユーザーがバイパス手法として使用できます。また、RFC 2616の4.3項でも定義されています。リクエスト・メソッドにエンティティ本文の定義済セマンティクスが含まれていない場合、リクエストを処理するときにメッセージ本文は無視する必要があります。
920180	欠落しているContent-Typeヘッダー	RFC 2616の7.2.1項で定義されているように、エンティティ本文を含むHTTP/1.1メッセージには、その本文のメディア・タイプを定義するContent-Typeヘッダー・フィールドを含める必要があります。このベスト・プラクティスに従っていない場合は、MIMEタイプのスニッフィング攻撃につながる可能性があります。
911100	許可されているHTTPメソッド	デフォルトで許可されるHTTPメソッドは、GET、HEAD、POSTおよびOPTIONSです。 OPTIONSは、攻撃者がオリジン・サーバーから情報を収集するために頻繁に使用しているため、セキュアでないメソッドと呼ばれます。このメソッドは、一部のアプリケーションが正常に動作するためにも必要です。このメソッドが必要ない場合は、My Oracle Supportでサービス・リクエストを作成して無効にします。必要に応じて、サービス・リクエストで他のメソッドを追加することもできます。
920380	引数の最大数	RFCでは、リクエストに必要な引数の数は強制されませんが、多数の引数を使用することは、Webアプリケーションをオーバーフローさせようとする悪意のあるユーザーが使用する方法である可能性があります。このようなタイプの攻撃から保護するために、リクエストごとに許可されるARGの最大数を制限することをお薦めします。デフォルト値は255です。
920370	引数の最大長	RFCでは、リクエストに必要な引数当たりの長さは強制されませんが、引数長を大きくすることは、Webアプリケーションをオーバーフローさせようとする悪意のあるユーザーが使用する方法である可能性があります。このようなタイプの攻撃から保護するために、リクエストごとに許可されるARGの最大長を制限することをお薦めします。デフォルト値は400です。
920390	合計引数の最大長	RFCでは、リクエストに必要な合計(結合)引数サイズは強制されませんが、結合引数値を大きくすることは、Webアプリケーションをオーバーフローさせようとする悪意のあるユーザーが使用する方法である可能性があります。このようなタイプの攻撃から保護するために、リクエストごとに許可される最大結合引数値を制限することをお薦めします。デフォルト値は「64000」です。
920350	ホスト・ヘッダーがIPアドレスである	WAFではトラフィックをオリジンに送信するためにホスト・ヘッダーが必要であるため、通常、このルールはトリガーされません。
941120	クロスサイト・スクリプティング(XSS)攻撃: XSSフィルタ - カテゴリ2	大きいペイロードがある場合、このルールは処理に時間がかかります。たとえば、64,005バイトのペイロードの処理には約32秒かかります。

保護ルール

保護ルールは、Webトラフィックとルール基準を照合し、条件が満たされたときに実行するアクションを決定します。

WAFポリシーには約490のルールがあり、最新バージョンのルールのみが含まれています。WAFポリシーには、CRS 3.0以降に基づくルールのみが含まれています。

カスタム保護ルールは、WAFポリシーでは使用できません。