エッジ・ポリシーの開始

Web Application Firewallを使用してエッジ・ポリシーを管理します。

開始する前に

WAFサービスに関する重要な概念については、Web Application Firewallの概要を参照してください。

WAFサービスの使用を開始するには、次が必要です:

  • 必要なIAMサービス・ポリシー権限があることを確認します。
  • 管理をより簡単かつ安全にするために、WAFポリシーには別のコンパートメントを使用することをお薦めします。
  • メインWebアプリケーション・ドメイン。
  • アプリケーションのLBaaSまたはその他のパブリック接続エンドポイントのIPアドレス。
  • ドメインのDNSレコードを更新する機能。
  • WAFサービスでは、ポート80/443のトラフィックのみがサポートされますが、リクエストがポート80/443のWAFに到達すると、必要な任意のポートでオリジン・サーバーにリクエストを送信できます。次に例を示します:

    エンド・ユーザー→ポート80/443→WAF→ポート443/8000/555/***→オリジン・サーバー

    アプリケーションが他のポートで実行されていないことを確認します。
    ノート

    SSH、FTP、SMTPなどのトラフィックにはWAFを使用できません。

また、HTTPS/443でサイトを実行する予定の場合は、次が必要です。

  • アプリケーションの完全修飾ドメイン名(FQDN)のパブリック証明書。
  • サイトに対応する秘密キー。
  • PEM形式の証明書。
  • フル・チェーン証明書(ルート、中間、オリジン・サーバー)
    ノート

    SSL証明書は、ポリシーのメイン・アプリケーションにのみ適用できます。

エッジ・ポリシーへの変更は、通常、変更に応じて伝播に10分から30分かかります。新しい構成がプッシュされるノードが数百個あるため、伝播には時間がかかります。通常、次の機能変更は10分から15分以内に伝播されます。

  • ボット・ポリシー
  • ヒューマン・インタラクション・チャレンジ(HIC)
  • デバイスのフィンガープリント・チャレンジ
  • Javascriptチャレンジ
  • CAPTCHAチャレンジ
  • 良好なボット・ホワイトリスト
  • アクセス・ルール
  • スレッド・インテリジェンス
  • IPリスト
  • IPホワイトリスト

Edgeポリシーを操作する場合は、次の情報を考慮してください。

  • IPv6は現在サポートされていません。

  • WAFは検査しますが、レスポンス本文を変更しません。
  • キャッシュの制限は、ポリシー当たり1GBです。
  • ファイル・サイズのアップロード制限の場合、制限は1 GBです。ファイル・サイズの制限については、次の点を考慮してください。
    • この制限は、イメージ、ビデオ、バイナリなどのアップロードのタイプに依存しません。
    • Content-Typeヘッダーは制限に影響しません。Content-Typeヘッダーに基づいて適用される保護ルールは異なります。
    • チャンク化またはストリームを使用したアップロードは制限に影響しません。バッファリング・モードでは、アップロードおよびダウンロードの制限は1GBです。ただし、レスポンス本文のストリーミングなど、他の一部のモードでは1つのGB制限は無視されます。
    • WAF接続は、ほとんど取り消されません。アップロードが大きいか、接続が遅いために、取り消すことができます。エッジ・ノードのリロード後、リクエストまたはレスポンスのサイクルに時間がかかりすぎる場合、クリーンアップ・プロセスの実行時に接続を取り消すことができます。
  • コンテンツ・ストリーミング・サービスでWAFを使用する場合、保護ルールでは分析前に完全なHTMLコンテンツをバッファリングする必要があるため、コンテンツ・ストリーミング・サービスが影響を受ける可能性があります。保護ルールのコア・エンジン内でコンテンツ全体をバッファする必要があるため、レスポンスが遅くなったり、ストリーミング・コンテンツが表示されないイベントが発生する可能性があります。
  • OCI CLIを使用して、WAFポリシー・バックアップを作成またはリストアできます。Webアプリケーションの完全なJSONファイルを抽出し、部分的に再作成します。まず主要な設定を再作成してから、Webアプリケーションのセキュリティ・チャレンジと機能を再作成することをお薦めします。
  • 次のコマンドを使用して、CLIを介して特定のURLに対してWebSocketを有効にできます:

    oci waas policy-config update --waas-policy-id ocid1.waaspolicy.oc1..[WAAS POLICY OCID] --websocket-path-prefixes '["/url/url/websocket"]'

    ノート

    WebSocketのサポートにより、指定したパスのWAF処理が防止されます。つまり、WAFルールが有効な場合、構成で除外されたURLに送信されるリクエストは分析されません。ただし、Human Interaction ChallengeやJavaScript Challengeなどの他の対応策を有効にすると、WebSocket URLのセキュリティをさらにレイヤーさせることができます。
  • 生成された脅威インテリジェンス・フィードのキーは、WAFポリシーごとに異なります。
  • エッジ・ポリシーを変更できるのは、ポリシー・ステータスがACTIVEの場合のみです。

WAFの使用に対する見積コスト

この情報を使用して、WAFサービスの使用コストを見積ります。
費用は次のように見積もることができます。
  1. https://www.oracle.com/cloud/cost-estimator.htmlにアクセスします。
  2. 「検索」をクリックし、Networking - WAFを検索します。
  3. 「追加」をクリックします。
  4. 「構成の追加」で、サービス名の横にあるメニューをクリックし、「SKUで追加」を選択してSKUを入力します。
  5. 「追加」をクリックします。

    コスト見積りツールで、「インスタンス」はWAFポリシーを表します。

WAFポリシーの初期設定

1. WAFを介してトラフィックをルーティングするエッジ・ポリシーの作成

まず、WAFを介してトラフィックをルーティングする、ルールが有効になっていないエッジ・ポリシーを作成します。ルールが有効になっていないポリシーを作成すると、アプリケーションの前面にリバース・プロキシを配置することによりパフォーマンス低下を回避できます。

エッジ・ポリシーを作成するには
  1. ポリシーを保持する必要があるリージョンとコンパートメントを選択します(Oracle Cloud Infrastructureロード・バランサまたはその他のアプリケーションのリソースと共存するWAFに関する制約はありません)。

  2. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  3. 「WAFポリシーの作成」をクリックします。

  4. 「基本情報」ページの下部で次のことを確認します:

    非OCI Webアプリケーションを保護する必要がある場合は、ここでレガシー・ワークフローを使用します。

  5. リンクをクリックして、「エッジ・ポリシーの作成」ダイアログ・ボックスを表示します。
  6. 次を完了します:
    • 名前: ポリシーの一意の名前。
    • ドメイン:
      • プライマリ・ドメイン: ポリシーが適用されるアプリケーションの完全修飾ドメイン名(FQDN)。
      • 追加のドメイン: (オプション)ポリシーが適用されるサブドメイン。
        ノート

        ただし、ワイルドカード・ドメインは、追加ドメインとして、およびAPIとCLIを介してのみ受け入れられます。

    • WAFソース:保護されるパブリック・インターネット接続アプリケーションのホストまたはIPアドレス。
      • オリジン名: オリジンの一意の名前。
      • URI: アプリケーションのパブリック接続エンドポイント(IPv4またはFQDN)を入力します。
      • HTTPSポート: セキュアなHTTP接続に使用されるポート。デフォルト・ポートは443です。
      • HTTPポート: オリジンがリスニングするHTTPポート。デフォルト・ポートは80です。
      • へッダー: (オプション)
        • ヘッダー名: HTTPリクエスト・ヘッダーに表示される名前と、すべてのリクエストでオリジン・サーバーに追加して渡すことができるヘッダー値。
        • ヘッダー値: ヘッダーで要求されるデータを指定します。
    • タグ: リソースを作成する権限がある場合、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか、管理者に問い合せてください。タグは後から適用できます。
  7. 「WAFポリシーの作成」をクリックします。WAFポリシーの概要が表示されます。ポリシーは、作成して15分以内にアクティブになります。

    詳細は、「エッジ・ポリシーの管理」を参照してください。

2. オリジンのキープ・アライブ・タイムアウトの更新

エッジ・ポリシーでは、アップストリームのタイムアウト値が300秒であるため、オリジン(ロード・バランサまたはWebサーバー)のキープ・アライブ・タイムアウトを301秒以上維持する必要があります。次に、ノードが接続を作成して接続の問題を回避するときに、接続の再ネゴシエーションのために十分な時間があることを確認します。TCPプロトコルを最適化することでネットワークのボトルネックを軽減し、パフォーマンスを向上させるために役立つOCIネットワーク多重化テクノロジを使用するため、これはAPIコールに適用されます。

アップストリームのキープ・アライブ・タイムアウトをテストするには

HTTPチェック:

  1. オリジンまたはアップストリーム・サーバーに対してリクエストを行います。次のコマンドを実行します。
    time telnet www-origin.example.com 80
    出力例:
    Trying 12.34.56.78...
    Connected to lb65-soc-191485947.us-east-1.elb.amazonaws.com.
    Escape character is '^]'.
  2. 次のHTTPヘッダーを入力して、GETリクエストを実行します:
    GET / HTTP/1.1
    Host: www.example.com
    Connection: keep-Alive
  3. [ENTER]を2回押して、セッションが閉じられるか切断されるまで待ちます。

HTTPSチェック:

  1. オリジンまたはアップストリーム・サーバーに対してリクエストを開始します。次のコマンドを実行します。
    time openssl s_client -connect www-origin.example.com:443
  2. 次のHTTPヘッダーを入力して、GETリクエストを実行します:
    GET / HTTP/1.1
    Host: www.example.com
    Connection: keep-Alive
  3. [ENTER]を2回押して、セッションが閉じられるか切断されるまで待ちます。
次の出力が表示されます。この例では、セッションが有効だった実際の時間(5.1分(301秒))がrealセクションに表示されています:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
... 

<!DOCTYPE html>
<html>
...
</html> 

Connection closed by foreign host.
real 5m1.962s
user 0m0.011s
sys 0m0.009s

詳細は、オリジン管理を参照してください。

3. 証明書とキーのアップロード

このステップでは、サイトがHTTPS/443で実行されることを前提としています。

証明書とキーをアップロードするには
  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。

    または、「Webアプリケーション・ファイアウォール」ページを開き、「リソース」の下の「ポリシー」をクリックします。

    「WAFポリシー」ページが表示されます。

  2. リストからコンパートメントを選択します。

    そのコンパートメント内のすべてのWAFポリシーが表形式でリストされます。

  3. (オプション)次のフィルタの1つ以上を適用して、表示されるWAFポリシーを制限します:
    • 都道府県

    • 名前

    • ポリシー・タイプ: エッジ・ポリシーを選択します。

  4. 証明書とキーをアップロードするエッジ・ポリシーを選択します。

    「エッジ・ポリシーの詳細」ダイアログ・ボックスが表示されます。

  5. 「WAFポリシー」の下の「設定」をクリックします。
    「設定」リストが表示されます。
  6. 「一般設定」を選択します。
  7. 「編集」をクリックします。
    「設定の編集」ダイアログ・ボックスが表示されます。
  8. 次を完了します:
    • HTTPSサポートの有効化: このチェック・ボックスをクリックすると、ブラウザとWebアプリケーションの間のすべての通信を暗号化できます。
      • 証明書ソース: 次のいずれかの方法を選択します:
        • 証明書の選択: ドロップダウン・メニューから既存の証明書を選択します。「コンパートメントの変更」をクリックして、別のコンパートメントから証明書を選択します。
        • 証明書と秘密キーのアップロードまたは貼付け
          • PEM形式の有効なSSL証明書をドラッグ・アンド・ドロップ、選択または貼付けします。中間証明書も含める必要があります(Webサイト証明書を最初にする必要があります)。次に例を示します:

            -----BEGIN CERTIFICATE-----
            <Base64_encoded_certificate>
            -----END CERTIFICATE-----
            -----BEGIN CERTIFICATE-----
            <Intermediate_Base64_encoded_certificate>
            -----END CERTIFICATE-----
          • 秘密キー: このフィールドには、PEM形式の有効な秘密キーをドラッグ・アンド・ドロップ、選択または貼付けします。秘密キーをパスフレーズで保護できません。次に例を示します:

            -----BEGIN PRIVATE KEY-----
            <Base64_encoded_private_key>
            -----END PRIVATE KEY-----
      • 自己署名証明書: 自己署名証明書を使用してブラウザにSSL警告を表示する場合は、このフィールドを有効にします。
      • HTTPからHTTPSへのリダイレクト: これを有効にすると、すべてのHTTPトラフィックが自動的にHTTPSにリダイレクトされます。
      • TLSプロトコル・サポート: ドロップダウン・リストからTLSプロトコルを選択します。
        注意

        TLSバージョン1および1.1は非推奨であり、ポリシー構成では使用できません。これらのバージョンを使用すると、検証エラーが発生する場合があります。かわりにバージョン1.2または1.3を使用してください。
      • SNIの有効化: Server Name Indication (SNI)はTLSプロトコルの拡張機能の1つであり、これを使用すると、1つのIPアドレスで複数のホスト名に安全に対応できます。
      • 拡張オプション
        • レスポンス・バッファリングの有効化: オリジンからのレスポンスのバッファリングを有効化または無効化します。
        • キャッシュ制御対応: レスポンスのcache-controlヘッダーに基づいて自動コンテンツ・キャッシュを有効化または無効化します。
        • CDNの背後: これを有効にすると、WAFがCDNに接続している場合に、クライアント・リクエストからのIPアドレスの収集が許可されます。
  9. 「変更の保存」をクリックします。
変更を有効にするには、変更を公開する必要があります。「変更の公開」を参照してください。

4. アプリケーションのテスト(本番環境にデプロイする前)

このステップでは、リクエストがWAFにルーティングされていること、およびアプリケーションがトポロジ内のリバース・プロキシで正常に機能し続けることを確認します。

ターミナル・コマンドを使用したアプリケーションのテスト
  1. ターミナルを開きます。

    HTTPの場合は次のコマンドを実行します:

    curl -lvk http://<OCI_WAF_CNAME> -H "Host: <WEBAPP_DOMAIN>" -so /dev/null

    HTTPSの場合は次のコマンドを実行します:

    curl -lvk https://<OCI_WAF_CNAME> -H "Host: <WEBAPP_DOMAIN>" -so /dev/null
  2. WAFポリシーの<OCI_WAF_CNAME>に対してDNS問合せを実行し、結果の出力からいずれかのIPアドレスの1つをコピーすることもできます。
    • DNS問合せを実行するには、次のいずれかのコマンドを使用できます:
      dig <OCI_WAF_CNAME>
      nslookup <OCI_WAF_CNAME>
    • 出力から任意のIPアドレスをコピーします。
  3. 次のコマンドを実行します。<WEBAPP_DOMAIN>をWAFポリシー・ドメインに置き換えます。ポート80または443を使用します。<OCI_NODE_IP>OCI_WAF_CNAMEのIPアドレスに置き換えます。
    Query curl -vso/dev/null --resolve <WEBAPP_DOMAIN>:<PORT_80_OR_443>:<OCI_NODE_IP> https://<WEBAPP_DOMAIN>

    200、301、302またはその他の予期されるHTTPレスポンス・コードが返されます。

    ノート

    5XX HTTPエラーが表示された場合、IPアドレスを許可するようにファイアウォール設定を更新したことを確認してください。それでも問題が発生する場合は、My Oracle Supportでサービス・リクエストを開きます。サポート・リクエストで、コンパートメントOCID、ポリシーOCID、発生している問題の説明、HARファイルおよび問題が開始した時刻を入力します。
Webブラウザを使用したアプリケーションのテスト

hostsファイルを使用してアプリケーションをテストするには、アプリケーションを指すことができるIPアドレスが必要です。ポリシーの下に、自分に割り当てられているCNAMEが表示されます。アプリケーションを指すことができるIPアドレスを取得できます。

  1. ターミナルを開きます。
  2. 次のいずれかのコマンドを使用して、DNS問合せを実行します:
    dig <OCI_WAF_CNAME>
    nslookup <OCI_WAF_CNAME>
  3. digコマンド出力のAnswerセクションから3つのIPアドレスのいずれかをコピーし、ドメイン名を指定してhostsファイルに貼り付けます。
  4. hostsファイルを保存した後、ブラウザでアプリケーションを開き、予想どおりに動作していることを確認します。

    200、301、302またはその他の予期されるHTTPレスポンス・コードが返されます。

    ノート

    5XX HTTPエラーが表示された場合、IPアドレスを許可するようにファイアウォール設定を更新したことを確認してください。それでも問題が発生する場合は、My Oracle Supportでサービス・リクエストを開きます。サポート・リクエストで、コンパートメントOCID、ポリシーOCID、発生している問題の説明、HARファイルおよび問題が開始した時刻を入力します。
SSLのテスト
次の便利なコマンド・ライン・ツールを使用して、特定のWebアプリケーションの証明書を検証できます:
echo | openssl s_client -showcerts -servername <Domain> -connect <Domain>:443 2>/dev/null | openssl x509 -inform pem -noout -text
接続の問題を引き起こす可能性のある証明書の有効日と失効日に特に注意してください:
..
Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Jun  5 03:15:10 2020 GMT
            Not After : Sep  3 03:15:10 2020 GMT
        Subject: CN = www.example.com
        Subject Public Key Info:
...

SSL ShooperやSSL labsなどのサードパーティのWebサイトから証明書を確認し、そこで検証を実行することもできます。

5. WAFを有効にするためのDNSの更新

WAFを介してWebアプリケーションが円滑に動作することを確認した後、DNSをグローバルに更新できるようになります。

このステップでは、インターネット・クライアントからのリクエストをWAFにルーティングするようにゾーンのCNAMEを更新します。コンソールでこのDNS変更を行う場合は、次の手順を使用します。DNSの設定が別のプロバイダと関連している場合は、そのプロバイダのドキュメントの指示を参照してください。

ゾーンのCNAMEを更新するには
  1. WAFポリシーの概要の「ポリシー情報」タブで、「CNAMEターゲット」を選択します。
  2. CNAMEターゲットをクリップボードにコピーします。
  3. ナビゲーション・メニューを開き、「ネットワーク」をクリックします。「DNS管理」で、「ゾーン」をクリックします。
  4. レコードを更新するプライマリ・ドメインの「ゾーン名」をクリックします。ゾーンの詳細およびレコードのリストが表示されます。

  5. CNAMEレコードのチェック・ボックスを選択し、「アクション」ドロップダウン・メニューから「編集」を選択します。
  6. 「レコードの編集」ダイアログ・ボックスで、クリップボードからのCNAMEターゲットが入力された「ターゲット」フィールドを更新します。
  7. 「送信」をクリックします。
  8. 「変更の公開」をクリックします。
  9. 確認ダイアログ・ボックスで、「変更の公開」をクリックします。

6. WAFの保護

WAFを保護するには、WAFサーバーからのトラフィックを受け入れるようにサーバーを構成する必要があります。オリジンのイングレス・ルールを、次のCIDR範囲からの接続のみを受け入れるように構成します

CIDR範囲
  • 129.146.12.128/25
  • 129.146.13.128/25
  • 129.146.14.128/25
  • 129.148.156.0/22
  • 129.213.0.128/25
  • 129.213.2.128/25
  • 129.213.4.128/25
  • 130.35.0.0/20
  • 130.35.112.0/22
  • 130.35.116.0/25
  • 130.35.120.0/21
  • 130.35.128.0/20
  • 130.35.144.0/20
  • 130.35.16.0/20
  • 130.35.176.0/20
  • 130.35.192.0/19
  • 130.35.224.0/22
  • 130.35.232.0/21
  • 130.35.240.0/20
  • 130.35.48.0/20
  • 130.35.64.0/19
  • 130.35.96.0/20
  • 130.35.228.0/22
  • 132.145.0.128/25
  • 132.145.2.128/25
  • 132.145.4.128/25
  • 134.70.16.0/22
  • 134.70.24.0/21
  • 134.70.32.0/22
  • 134.70.56.0/21
  • 134.70.64.0/22
  • 134.70.72.0/22
  • 134.70.76.0/22
  • 134.70.8.0/21
  • 134.70.80.0/22
  • 134.70.84.0/22
  • 134.70.88.0/22
  • 134.70.92.0/22
  • 134.70.96.0/22
  • 138.1.0.0/20
  • 138.1.104.0/22
  • 138.1.128.0/19
  • 138.1.16.0/20
  • 138.1.160.0/19
  • 138.1.192.0/20
  • 138.1.208.0/20
  • 138.1.224.0/19
  • 138.1.32.0/21
  • 138.1.40.0/21
  • 138.1.48.0/21
  • 138.1.64.0/20
  • 138.1.80.0/20
  • 138.1.96.0/21
  • 138.1.112.0/20
  • 140.204.0.128/25
  • 140.204.12.128/25
  • 140.204.16.128/25
  • 140.204.20.128/25
  • 140.204.24.128/25
  • 140.204.4.128/25
  • 140.204.8.128/25
  • 140.91.10.0/23
  • 140.91.12.0/22
  • 140.91.22.0/23
  • 140.91.24.0/22
  • 140.91.28.0/23
  • 140.91.30.0/23
  • 140.91.32.0/23
  • 140.91.34.0/23
  • 140.91.36.0/23
  • 140.91.38.0/23
  • 140.91.4.0/22
  • 140.91.40.0/23
  • 140.91.8.0/23
  • 147.154.0.0/18
  • 147.154.128.0/18
  • 147.154.192.0/20
  • 147.154.208.0/21
  • 147.154.224.0/19
  • 147.154.64.0/20
  • 147.154.80.0/21
  • 147.154.96.0/19
  • 192.157.18.0/24
  • 192.157.19.0/24
  • 192.29.0.0/20
  • 192.29.128.0/21
  • 192.29.138.0/23
  • 192.29.144.0/21
  • 192.29.152.0/22
  • 192.29.16.0/20
  • 192.29.160.0/21
  • 192.29.168.0/22
  • 192.29.172.0/25
  • 192.29.178.0/25
  • 192.29.180.0/22
  • 192.29.32.0/21
  • 192.29.40.0/22
  • 192.29.44.0/25
  • 192.29.48.0/21
  • 192.29.56.0/21
  • 192.29.60.0/23
  • 192.29.64.0/20
  • 192.29.96.0/20
  • 192.29.140.0/22
  • 192.69.118.0/23
  • 198.181.48.0/21
  • 199.195.6.0/23
  • 205.147.88.0/21

WAFによる受動的なルール検出の有効化

WAF保護ルールは、各トランザクションに追加のCPUサイクルを追加するため、Webアプリケーション・トポロジ用に設計されたルールのみを有効にすることをお薦めします。WAFには、サイトのパフォーマンスを損なわず、ほとんどのWebアプリケーションで動作する一連の推奨ルールが用意されています。WAFボット保護機能を使用すると、Webアプリケーションを脅威から完全に保護できます。

WAFの設定に関するヘルプが必要な場合は、My Oracle Supportを使用してサービス・リクエストを開き、OCI WAFチューニング・ヘルプをリクエストできます。エキスパートがプロセスをガイドします。

保護ルールの推奨を表示するには
  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  2. 保護ルールの推奨を表示するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
  3. 「保護ルール」をクリックします。
  4. 「推奨」タブをクリックします。このリストは、WAF経由で流れていることがWAFによって検出されたトラフィックに基づいて生成されます。このリストに何も表示されない場合は、アプリケーションのFQDNのテストを続行し、後で戻って確認してください。
  5. 「検出」推奨アクションを含む保護ルールを選択し、「推奨の受入れ」をクリックします。
ヒント

「推奨アクション」フィルタを使用して、「検出」による推奨を見つけることができます。
WAF保護ルールでモードを検出できるようにするには
  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  2. ルール設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
  3. 「保護ルール」をクリックします。
  4. 「保護ルール」表を使用して、検出するルールを見つけます。
  5. 表から見つけたルールIDを「ルールID」フィルタに入力します。この例では、「ルールID」フィルタに941110 (クロスサイト・スクリプティング)と入力します。
  6. フィルタ処理した保護ルールの「アクション」ドロップダウン・メニューから、「検出」を選択します。

詳細は、WAF保護ルールを参照してください。

WAFアクセス・ルールでモードを検出できるようにするには
  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  2. アクセス・ルールを構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
  3. 「アクセス制御」をクリックします。
  4. 「アクセス・ルールの追加」をクリックします。
  5. 「アクセス・ルールの追加」ダイアログ・ボックスで、次のように入力します:
    1. 名前: DetectRequestsFromMySpecificBrowser
    2. ルール・アクション: 「検出のみ」を選択します。
    3. 条件: メニューから「IPアドレスは次のとおりです」を選択し、アプリケーションのテスト中にクリップボードにコピーしたIPアドレスを「IPアドレス」フィールドに入力します。
    4. 「+Additional条件」をクリックします。
    5. 条件: メニューから「ユーザー・エージェントは次のとおりです」を選択し、アプリケーションのテスト中にクリップボードにコピーしたエージェント値を「ユーザー・エージェント・ヘッダー」フィールドに入力します。
    ノート

    ルールがトリガーされるためには、前出の例のIPアドレスとユーザー・エージェントの両方が一致している必要があります。アプリケーションのテストに別のユーザー・エージェントを使用する場合、リクエストは検出されません。

  6. 「アクセス・ルールの追加」をクリックします。
  7. 「公開されていない変更」をクリックします。
  8. 「すべて公開」をクリックします。

詳細は、「エッジ・ポリシーのアクセス制御」を参照してください。

WAF BOTルールでモードを検出できるようにするには(JavaScriptチャレンジ)
  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  2. JavaScriptチャレンジ設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
  3. 「ボット管理」をクリックします。
  4. 「JavaScriptチャレンジの編集」をクリックします。
  5. 「JavaScriptチャレンジ」ダイアログ・ボックスで、「JavaScriptチャレンジの有効化」チェック・ボックスを選択します。
  6. 「JavaScriptチャレンジ・アクション」セクションで、「検出のみ」を選択します。

  7. 次の情報を入力します:

    • 条件の有効化: 有効にすると、設定したアクションが実行されるには条件が一致する必要があります。条件およびルールの詳細は、「エッジ・ポリシーのアクセス制御」を参照してください。
    • アクションしきい値(リクエスト数): アクションの実行までに失敗するリクエストの数を指定します。ページのロード中にブラウザから非同期リクエストが発生するため、しきい値としてAjaxの基本的な利用のWebアプリケーションは10個、Ajaxを多用するアプリケーションは100個に設定することをお薦めします。
    • アクション失効時間(秒): 同じIPアドレスへのチャレンジの間隔(秒)を入力します。クライアントIPアドレスの変更のため、失効時間を、モバイル・ユーザーのアプリケーションには120秒、デスクトップ・ユーザーのみのアプリケーションには3,600秒に設定することをお薦めします。
    • リダイレクトのフォロー: 有効にすると、オリジンからのリダイレクト・レスポンスもチャレンジされます。
    • NATサポートの有効化: 有効にすると、ユーザーがIPアドレスのみでなく、一意の追加ハッシュによっても識別されるため、共有IPアドレスを持つビジターがブロックされることがなくなります。負荷の高いアプリケーション(200以上のRPS)では、このNATサポートを無効にすることをお薦めします。
  8. 「変更の保存」をクリックします。

JavaScriptチャレンジが、公開される変更のリストに追加されます。

詳細は、Bot Managementを参照してください。

WAF BOTルールでモードを検出できるようにするには(ヒューマン・インタラクション・チャレンジ)
  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  2. JavaScriptチャレンジ設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
  3. 「ボット管理」をクリックします。
  4. 「ヒューマン・インタラクション・チャレンジ」タブをクリックします。
  5. 「ヒューマン・インタラクション・チャレンジの編集」をクリックします。
  6. 「ヒューマン・インタラクション・チャレンジの編集」ダイアログ・ボックスで、「ヒューマン・インタラクション・チャレンジの有効化」チェック・ボックスを選択します。
  7. 「ヒューマン・インタラクション・アクション」セクションで、「検出のみ」を選択します。
  8. 次の情報を入力します:
    • アクションしきい値(リクエスト数): アクションの実行までに失敗するリクエストの数を指定します。ページのロード中にブラウザから非同期リクエストが発生するため、しきい値としてAjaxの基本的な利用のWebアプリケーションは10個、Ajaxを多用するアプリケーションは100個に設定することをお薦めします。
    • しきい値有効期間(秒): しきい値が期限切れになるまでの秒数。
    • アクション失効時間(秒): 同じIPアドレスへのチャレンジの間隔(秒)を入力します。クライアントIPアドレスの変更のため、失効時間を、モバイル・ユーザーのアプリケーションには120秒、デスクトップ・ユーザーのみのアプリケーションには3,600秒に設定することをお薦めします。
    • インタラクションしきい値(インタラクション数): しきい値が期限切れになるまでのインタラクション数。
    • 記録期間(秒): ユーザーのイベントを記録する期間。
    • NATサポート: 有効にすると、ユーザーがIPアドレスのみでなく、一意の追加ハッシュによっても識別されるため、共有IPアドレスを持つビジターがブロックされることがなくなります。負荷の高いアプリケーション(200以上のRPS)では、サポートを無効にすることをお薦めします。
  9. 「変更の保存」をクリックします。

ヒューマン・インタラクション・チャレンジが、公開する変更リストに追加されます。

詳細は、Bot Managementを参照してください。

WAFの処理順序については、「エッジ・ポリシーの管理」を参照してください。

ルールのテスト

ポリシーがアクティブになっている場合、WAFによってルールが検出されることをテストできます。

リクエストを開始するには
  1. アプリケーションをテストしたときに使用した同じブラウザを使用して、次のことを行います:
    • 次の問合せパラメータを追加して、アプリケーションのFQDNをリクエストします:
      ?id=<script>alert("TEST");</script>
  2. 同じマシン上で別のブラウザを使用し、前出のリクエストを繰り返します。すべてのリクエストはアプリケーションを経由する必要があります。
WAFがリクエストを検出していることを確認するには

WAFがリスクとして特定されたリクエストを検出していることを確認するには:

  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
  2. ログを表示するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
  3. 「ログ」をクリックします。WAFポリシーのログが表示されます。
  4. 「アクション」フィルタから「検出」チェック・ボックスを選択します。
  5. クロスサイト・スクリプティング・リクエストによってトリガーされる保護ルールに対するエントリが2つあり、ユーザー・エージェントとIPアドレスを検出するためのエントリが1つあることを確認します。