保護ルールのチューニング

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

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

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

保護ルールの定義
用語	定義
チューニング	エンジニアまたはアナリストが保護ルールや保護アクションを変更するプロセスのことで、アプリケーション・サーバーを保護しながら稼働させることが可能になります。アプリケーション・サーバーのロック・ダウンと、アプリケーション・サーバーによる業務の実行とのバランスがとれます。最適なチューニングを行うには、保護対象のアプリケーション・サーバーと、そのアプリケーション・サーバーの保護に使用できる保護ルールに関する深い知識が必要です。
誤検出	誤検出は、保護ルールがHTTPトランザクションと照合され、そのHTTPトランザクションが正当な(悪意のない)トランザクションである場合に発生します。
除外	保護ルールを変更して、CookieまたはHTTP引数の値や値の名前を無視できるようにすること。
Oracle Recommendation Engine (ORE)	OREは、最初の推奨期間中にトリガーされないすべてのルールを有効にすることで、WAFセキュリティ・プロファイルの最適化に役立ちます。

WAF保護ルールの概要

WAFは、Webアプリケーションを脅威から保護します。WAFはクラウドベースで、500を超えるルール・セットと、Open Web Application Security Project (OWASP)のルール・セットをサポートしています。これらのルールを使用すると、重要なWebアプリケーションを悪意のあるサイバー攻撃から保護できます。これらのルールは受信リクエストと比較され、リクエストに攻撃ペイロードが含まれているかどうかを判断します。リクエストが攻撃だと判断されると、WAFによりそのリクエストがブロックされるか、そのリクエストの警告が出されます。これらの攻撃は多様で、SQLインジェクション、クロスサイト・スクリプティング、HTMLインジェクションなどの脅威があり、そのすべてをWAFルール・セットによって検出およびブロックできます。

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

ノート

WAF保護ルールは、各トランザクションに追加のCPUサイクルを追加するため、Webアプリケーション・トポロジ用に設計されたルールのみを有効にすることをお薦めします。

WAF保護ルールは、Webアプリケーションを識別して攻撃から防御するために、Webサーバーへのあらゆるリクエストおよびサーバーからのすべての関連レスポンスについて、ルールのセットに照らし合せてチェックを実行します。チェックが成功すると、関連コンテンツを取得するためにHTTPリクエストがWebサイトに送信されます。チェックに失敗すると、適切な事前定義済アクションが開始されます。

WAFの保護ルールの中核となる原則は次のとおりです:

受動性: 必要なルールはユーザーが決定するため、完全に制御することが可能です。
柔軟性: WAFの保護ルールは、250を超えるルールおよびカスタム保護ルールを導入する機能を提供したセキュリティの専門家によって作成されました。
量より質: WAFの保護ルールは、他のWAF機能(アクセス制御やボット管理など)が対応するHTTPトラフィックを検査するよう設計された専用モジュールです。
予測可能性: WAFの保護ルールを完全に制御できるため、期待どおりの結果を得られます。保護ルールを定義して調整し、設定をそのままにしておけば、構成したとおりに機能します。

オンボーディングおよび初期チューニング

まず、チューニング・プロセス用のWebアプリケーションに関する知識が必要です。そうしないと、Windowsサーバーまたはオリジンに対してLinux固有のルールを有効にしてしまい、ルールによってトラフィックが不必要にスキャンされ、パフォーマンスが低下する可能性があります。OREは、堅牢で安全な保護ルールのセットを提供することで、ユーザーを支援します。推奨期間は構成可能な設定で、デフォルトは10日です。Webアプリケーションの通常のトラフィック用のログの大規模なサンプルを取得するには、この値を15日に増やすことをお薦めします。WAFポリシーが作成されてから約24時間後、保護ルールの推奨事項が「推奨」タブに表示されます。推奨事項は、OWASP Top TenをカバーするためにWAFの専門家が選択したルールです。これらの推奨ルールが選択されているのは、一般に、誤検出の数を最小限に抑え、優れた保護機能を備えているためです。

推奨期間の変更および推奨の受入れ

次のステップに従って、推奨ルールを検出モードで有効にします。ルールが検出モードになった後、15日間待ってからブロック・モードに変更することをお薦めします。

ノート

評価期間中、すべてのルールが検出モードになります。検出モードは、保護ルールによってブロックされないことを意味します。ユーザー受入れテストおよび通常のアプリケーション使用を実行し、ログを生成してチューニング・プロセスに役立てることをお薦めします。ルールが検出モードの間、ログを確認し、誤検出がないかどうかをチェックします。保護ルールのトリガーとなるログを確認することで、ルールがブロック・モードに切り替えられたときにブロックの原因となるトラフィックを把握できます。評価期間中、アプリケーションはできるだけ通常または本番に近いトラフィックを受信する必要があります。通常のトラフィックは、ログを介してどのルールがトリガーされるかを示し、誤検出はフィルタで除外できます。

推奨期間を変更するには

ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Webアプリケーション・ファイアウォール」で、「ポリシー」をクリックします。
ルール設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
「保護ルール」をクリックします。
設定タブをクリックします。
「ルール設定の編集」をクリックします。
「ルール設定の編集」ダイアログ・ボックスで、「推奨期間」を10日から15日に増やします。
「変更の保存」をクリックします。

推奨を受け入れるには

ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Webアプリケーション・ファイアウォール」で、「ポリシー」をクリックします。
ルール設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
「保護ルール」をクリックします。
「推奨」タブをクリックします。
「推奨の受入れ」をクリックします。
「公開されていない変更」をクリックします。
「すべて公開」をクリックします。
「変更の公開」ダイアログ・ボックスで、「すべて公開」をクリックします。

APIを使用した特定のログの問合せ

APIには、ルールをフィルタするためのほとんどのオプションが用意されています。次に、CLIを使用してログをフィルタする方法の例を示します。

保護ルールIDでログをフィルタするには:

oci waas waf-log list --waas-policy-id <WASS Policy OCID> --protection-rule-key <protection rule id number>

ルール・タイプ(保護ルール・タイプやアクセス・ルール・タイプなど)でログをフィルタするには:

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type PROTECTION_RULES
oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type ACCESS

リクエストURLでログをフィルタするには:

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --request-url <request url>

ログ・アナリティクスの設定

ログ・アナリティクスを使用すると、注意が必要な保護ルールを絞り込むことができます。次のガイドを使用して、WAFでログ・アナリティクス・サービスを設定します。詳細は、OMC Log Analyticsを使用したWebアプリケーションのセキュリティ・インサイトおよびOCI WAFログをOCI Logging Analyticsに送信してセキュリティ・インサイトを取得する方法に関する記事を参照してください。

ノート

Security Operations Center (SOC)チームは、WAFポリシー・トラフィックに基づいて、OCI保護ルールのチューニングについて提案できます。この提案は、リクエストの複雑さに応じて15日以内に配信されます。

保護ルールの除外の作成

ログの確認は、チューニング・プロセスにおいて重要な作業です。ログには、一致したルールと、一致したHTTPトランザクションの部分が示されます。ログのサンプルと、それを使用して除外を作成する方法については、次の表を参照してください。

WafLogのprotectionRuleDetectionsオブジェクトは、検出メッセージの詳細への保護ルール・キーのマップを提供します。次の表に、保護ルールに対して設定できる4つの除外を示します。


ログ値	除外値	説明
ARGS	リクエスト・パラメータ	特定の引数の値に使用されます。
ARGS_NAMES	リクエスト・パラメータ名	引数の名前に使用されます。
REQUEST_COOKIES	リクエストcookie値	特定のcookieの値に使用されます。
REQUEST_COOKIES_NAMES	リクエストcookie名	cookieの名前に使用されます。

ログを含む除外のサンプル

次の項では、RAWログのサンプルと、各ルールの除外値の例を示します。

ルールID 9411000 - ARGS
この例では、ARGS:foo引数内にMatched Dataが見つかりました。除外対象はルールID 9411000です。作成する除外は、値がfooのリクエスト・パラメータの場合です。
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS:foo: <script>xss"
},
```

ルールID 9411000 - ARGS_NAMES
この例では、ARGS_NAMES引数内にMatched Dataが見つかりました。除外対象はルールID 9411000です。作成する除外は、値が<script>xssのリクエスト・パラメータ名の場合です。
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS_NAMES:<script>xss: <script>xss"
},
```

ルールID 9411100

この例では、REQUEST_COOKIES:a引数内にMatched Dataが見つかりました。除外対象はルールID 9411100です。作成する除外は、値がaのリクエストCookie値の場合です。

"protection-rule-detections": {
 "9411100": {
  "Message": "Pattern match \"(?i)([<\\xef\\xbc\\x9c]script[^>\\xef\\xbc\\x9e]*[>\\xef\\xbc\\x9e][\\\\s\\\\S]*?)\" at REQUEST_COOKIES:a.",
  "Message details": "Matched Data: <script> found within REQUEST_COOKIES:a: <script>xss"
},

除外を作成するには

ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Webアプリケーション・ファイアウォール」で、「ポリシー」をクリックします。
ルール設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
「保護ルール」をクリックします。
「ルール」タブをクリックします。
アクションを適用する保護ルールを検索します。
アクション・アイコン(3つのドット)をクリックして、「除外」を選択します。前述の「ログを含む除外のサンプル」の項から取得した情報を使用して、除外を含めます。
「変更の保存」をクリックします。
「公開されていない変更」をクリックします。
「すべて公開」をクリックします。
「変更の公開」ダイアログ・ボックスで、「すべて公開」をクリックします。

保護ルールの詳細情報

個別の保護ルールとコラボレイティブ保護ルール

誤検出を制限するために、「コラボレイティブ」としてタグ付けされた特別な保護ルールがあります。これらのルール・グループでは、スコアリングとしきい値のシステムでトラフィックが評価されるため、残りの保護ルールとは異なる方法で動作します。個々のルールは、HTTPトランザクションの要素をルール署名と照合することで機能します。一致した場合は、ルールのアクション(検出やブロックなど)が実行されます。それぞれのコラボレイティブ保護ルールでは、ルールごとのグループが使用されます。コラボレイティブ保護ルールでは、HTTPトランザクションの要素が個々のルールに対して複数一致しないと、アクション(検出やブロックなど)が実行されません。コラボレイティブ・ルールのアクションが実行されるには、HTTPトランザクションの3つ以上の要素がコラボレイティブ・グループの個々のルールと一致する必要があります。コラボレイティブ保護ルール・グループ内で除外を加えると、そのグループ内のすべてのルールに除外が適用されます。コラボレイティブ保護ルールIDのリストを次に示します。

コラボレイティブ保護ルールID

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

リクエスト本文検査のルールID

次のルールでは、レスポンス本文の検査を有効にする必要があります。レスポンス本文の検査では、トランザクション内のすべての情報がスキャンされるため、トランザクションが遅延することに注意してください。必要なルールのみを有効にします。

970014, 90005, 120133, 970008, 970016, 981080, 920020, 920006, 920008, 920010, 920012, 920014, 920016, 920018, 90017, 90018, 90020, 90019, 90014, 90021, 90015, 90016, 920021, 920022, 920023, 90024, 90022, 90023, 970013, 970011, 981177, 981000, 981001, 981003, 970018, 970004, 970904, 970010, 970118, 2100090, 970012, 970903, 970009, 970015, 970902, 981005, 981004, 981007, 981006, 970003, 970002, 950110, 950921, 950922, 90002, 90025, 970021, 970007

例外ルールなし

次のルールは、ARGS、ARGS_NAMES、REQUEST_COOKIEおよびREQUEST_COOKIE_VALUEとは異なるRAWログ値を作成します。ルールは要素が存在するかどうかに基づいているため、これらのルールの除外は存在しません。たとえば、content-typeヘッダーが存在する場合、このルールを除外する唯一のオプションは、My Oracle Supportでサービス・リクエストを開き、次のいずれかのルールを除外するカスタムWAFルールを要求することです。

960020, 960015, 960009, 950103

ログ値はREQUEST_URI、REQUEST_PROTOCOLおよびREQUEST_HEADERSであるため、これらのルールは簡単に見つかります。

その他の保護ルール

次に、偽陽性が発生する保護ルールのリストを示します。そのルールで検出しようとしている内容の理解を助ける説明と推奨事項が記載されています。これらのルールには除外を適用できません。


ルールID	ルール名	ノート
981318	文字列の終了/文の最後	このルールは、入力フィールドおよびqueryString [ARGS]またはcookie内で検出されたエスケープ文字について警告するため、重要です。アプリケーション側で行われた検証をレビューし、文字や数字などの適切な入力文字のみが許可されていることを確認します。別の入力値が必要な場合は、ルールへの除外をWAFに適用して許可できます。
960015 960021	欠落しているAcceptヘッダー	AcceptヘッダーのないリクエストがHTTPプロトコルの違反を意味しない場合でも、Acceptヘッダーのないリクエストはほとんどの場合、本物のリクエストではありません。ルールは、APIまたはカスタム・アプリケーション・リクエストについて警告している可能性があります。 APIまたはカスタム・アプリケーション・リクエストのスキャンを回避するには、トラフィックを送信する既知のアプリケーションのリストを収集し、カスタム・ルールをリクエストします。詳細は、RFC 7231の5.3.2項を参照してください。
960007 960008	欠落しているHostヘッダー	RFC 7230の5.4項で説明されているように、サーバーは、ホスト・ヘッダー・フィールドがないHTTP/1.1リクエスト・メッセージに対して、および複数のホスト・ヘッダー・フィールドまたは無効なフィールド値を持つホスト・ヘッダー・フィールドを含むリクエスト・メッセージに対して、400 (不正なリクエスト)ステータス・コードで応答する必要があります。これは重要な保護方法であると同時に、WAFサーバーがリクエストの対象となるWAFポリシーを適切に識別できるようにします。WAFではホスト・ヘッダーでトラフィックを適切なオリジンに渡す必要があるため、このルールによって、誤検出の割合が高くなる可能性があります。
960009 960006	欠落している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の使用を依頼します。
960011	GET/HEADリクエスト検証	RFC 7231の4.3.1項および4.3.2項で説明されているように、HEADおよびGETはオリジン・サーバーから情報を取得することを目的としたHTTPメソッドです。RFCによって禁止されていない場合でも、これらのタイプのメソッドを使用して本文またはペイロードを送信することは一般的な方法ではありません。通常、これはRFCのベスト・プラクティスに従っていない不適切に定義されたアプリケーションが原因で、悪意のあるユーザーがバイパス手法として使用できます。また、RFC 2616の4.3項でも定義されています。リクエスト・メソッドにエンティティ本文の定義済セマンティクスが含まれていない場合、リクエストを処理するときにメッセージ本文は無視する必要があります。
960904	欠落しているContent-Typeヘッダー	RFC 2616の7.2.1項で定義されているように、エンティティ本文を含むHTTP/1.1メッセージには、その本文のメディア・タイプを定義するContent-Typeヘッダー・フィールドを含める必要があります。このベスト・プラクティスに従っていない場合は、MIMEタイプのスニッフィング攻撃につながる可能性があります。
960032	許可されているHTTPメソッド	デフォルトで許可されるHTTPメソッドは、GET、HEAD、POSTおよびOPTIONSです。 OPTIONSは、攻撃者がオリジン・サーバーから情報を収集するために頻繁に使用しているため、セキュアでないメソッドと呼ばれます。このメソッドは、一部のアプリケーションが正常に動作するためにも必要です。このメソッドが必要ない場合は、My Oracle Supportでサービス・リクエストを作成して無効にします。必要に応じて、サービス・リクエストで他のメソッドを追加することもできます。
960335	引数の最大数	RFCでは、リクエストに必要な引数の数は強制されませんが、多数の引数を使用することは、Webアプリケーションをオーバーフローさせようとする悪意のあるユーザーが使用する方法である可能性があります。このようなタイプの攻撃から保護するために、リクエストごとに許可されるARGの最大数を制限することをお薦めします。デフォルト値は255です。
960208	引数の最大長	RFCでは、リクエストに必要な引数当たりの長さは強制されませんが、引数長を大きくすることは、Webアプリケーションをオーバーフローさせようとする悪意のあるユーザーが使用する方法である可能性があります。このようなタイプの攻撃から保護するために、リクエストごとに許可されるARGの最大長を制限することをお薦めします。デフォルト値は400です。
960341	合計引数の最大長	RFCでは、リクエストに必要な合計(結合)引数サイズは強制されませんが、結合引数値を大きくすることは、Webアプリケーションをオーバーフローさせようとする悪意のあるユーザーが使用する方法である可能性があります。このようなタイプの攻撃から保護するために、リクエストごとに許可される最大結合引数値を制限することをお薦めします。デフォルト値は「64000」です。
92035032	ホスト・ヘッダーがIPアドレスである	WAFではトラフィックをオリジンに送信するためにホスト・ヘッダーが必要であるため、通常、このルールはトリガーされません。
941120	クロスサイト・スクリプティング(XSS)攻撃: XSSフィルタ - カテゴリ2	大きいペイロードがある場合、このルールは処理に時間がかかります。たとえば、64,005バイトのペイロードの処理には約32秒かかります。

Oracle Cloud Infrastructureドキュメント