エッジ・ポリシーの開始
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を使用するための見積コスト
- https://www.oracle.com/cloud/cost-estimator.htmlにアクセスします。
- 「検索」をクリックし、Networking - WAFを検索します。
- 「追加」をクリックします。
- 「構成の追加」で、サービスの横にあるメニューをクリックし、「SKUによる追加」を選択して、SKUを入力します。
- 「追加」をクリックします。
コスト見積りツールで、「インスタンス」はWAFポリシーを表します。
WAFポリシーの初期設定
1. WAFを介してトラフィックをルーティングするエッジ・ポリシーの作成
まず、WAFを介してトラフィックをルーティングする、ルールが有効になっていないエッジ・ポリシーを作成します。ルールが有効になっていないポリシーを作成すると、アプリケーションの前面にリバース・プロキシを配置することによりパフォーマンス低下を回避できます。
-
ポリシーを保持する必要があるリージョンとコンパートメントを選択します(Oracle Cloud Infrastructureのロード・バランサまたはその他のアプリケーションのリソースと共存するWAFに関する制約はありません)。
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
-
「WAFポリシーの作成」をクリックします。
-
「基本情報」ページの下部で次のことを確認します:
非OCI Webアプリケーションを保護する必要がある場合は、ここでレガシー・ワークフローを使用します。
- リンクをクリックして、「エッジ・ポリシーの作成」ダイアログ・ボックスを表示します。
- 次を完了します:
- 名前: ポリシーの一意の名前。
- ドメイン:
- プライマリ・ドメイン: ポリシーが適用されるアプリケーションの完全修飾ドメイン名(FQDN)。
- 追加のドメイン: (オプション)ポリシーが適用されるサブドメイン。ノート
ただし、ワイルドカード・ドメインは、追加ドメインとして、およびAPIとCLIを介してのみ受け入れられます。
- WAFソース:保護されるパブリック・インターネット接続アプリケーションのホストまたはIPアドレス。
- オリジン名: オリジンの一意の名前。
- URI: アプリケーションのパブリック接続エンドポイント(IPv4またはFQDN)を入力します。
- HTTPSポート: セキュアなHTTP接続に使用されるポート。デフォルト・ポートは443です。
- HTTPポート: オリジンがリスニングするHTTPポート。デフォルト・ポートは80です。
- へッダー: (オプション)
- ヘッダー名: HTTPリクエスト・ヘッダーに表示される名前と、すべてのリクエストでオリジン・サーバーに追加して渡すことができるヘッダー値。
- ヘッダー値: ヘッダーで要求されるデータを指定します。
- タグ: リソースを作成する権限がある場合、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか、管理者に連絡してください。タグは後で適用できます。
- 「WAFポリシーの作成」をクリックします。WAFポリシーの概要が表示されます。ポリシーは、作成して15分以内にアクティブになります。
詳細は、「エッジ・ポリシーの管理」を参照してください。
2. オリジンのキープ・アライブ・タイムアウトの更新
エッジ・ポリシーでは、アップストリームのタイムアウト値が300秒であるため、オリジン(ロード・バランサまたはWebサーバー)のキープ・アライブ・タイムアウトを301秒以上維持する必要があります。次に、ノードが接続を作成して接続の問題を回避するときに、接続の再ネゴシエーションのために十分な時間があることを確認します。TCPプロトコルを最適化することでネットワークのボトルネックを軽減し、パフォーマンスを向上させるために役立つOCIネットワーク多重化テクノロジを使用するため、これはAPIコールに適用されます。
HTTPチェック:
- オリジンまたはアップストリーム・サーバーに対してリクエストを行います。次のコマンドを実行します。
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 '^]'.
- 次のHTTPヘッダーを入力して、GETリクエストを実行します:
GET / HTTP/1.1 Host: www.example.com Connection: keep-Alive
- [ENTER]を2回押して、セッションが閉じられるか切断されるまで待ちます。
HTTPSチェック:
- オリジンまたはアップストリーム・サーバーに対してリクエストを開始します。次のコマンドを実行します。
time openssl s_client -connect www-origin.example.com:443
- 次のHTTPヘッダーを入力して、GETリクエストを実行します:
GET / HTTP/1.1 Host: www.example.com Connection: keep-Alive
- [ENTER]を2回押して、セッションが閉じられるか切断されるまで待ちます。
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で実行されることを前提としています。
4. アプリケーションのテスト(本番環境にデプロイする前)
このステップでは、リクエストがWAFにルーティングされていること、およびアプリケーションがトポロジ内のリバース・プロキシで正常に機能し続けることを確認します。
- ターミナルを開きます。
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
- WAFポリシーの
<OCI_WAF_CNAME>
に対してDNS問合せを実行し、結果の出力からいずれかのIPアドレスの1つをコピーすることもできます。-
DNS問合せを実行するには、次のいずれかのコマンドを使用できます:
dig <OCI_WAF_CNAME>
nslookup <OCI_WAF_CNAME>
- 出力から任意のIPアドレスをコピーします。
-
- 次のコマンドを実行します。
<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ファイルおよび問題が開始した時刻を入力します。
hostsファイルを使用してアプリケーションをテストするには、アプリケーションを指すことができるIPアドレスが必要です。ポリシーの下に、自分に割り当てられているCNAMEが表示されます。アプリケーションを指すことができるIPアドレスを取得できます。
- ターミナルを開きます。
- 次のいずれかのコマンドを使用して、DNS問合せを実行します:
dig <OCI_WAF_CNAME>
nslookup <OCI_WAF_CNAME>
- digコマンド出力のAnswerセクションから3つのIPアドレスのいずれかをコピーし、ドメイン名を指定してhostsファイルに貼り付けます。
- hostsファイルを保存した後、ブラウザでアプリケーションを開き、予想どおりに動作していることを確認します。
200、301、302またはその他の予期されるHTTPレスポンス・コードが返されます。
ノート
5XX HTTPエラーが表示された場合、IPアドレスを許可するようにファイアウォール設定を更新したことを確認してください。それでも問題が発生する場合は、My Oracle Supportでサービス・リクエストを開きます。サポート・リクエストで、コンパートメントOCID、ポリシーOCID、発生している問題の説明、HARファイルおよび問題が開始した時刻を入力します。
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の設定が別のプロバイダと関連している場合は、そのプロバイダのドキュメントの指示を参照してください。
- WAFポリシーの概要の「ポリシー情報」タブで、「CNAMEターゲット」を選択します。
- CNAMEターゲットをクリップボードにコピーします。
- ナビゲーション・メニューを開き、「ネットワーク」をクリックします。「DNS管理」で、「ゾーン」をクリックします。
-
レコードを更新するプライマリ・ドメインの「ゾーン名」をクリックします。ゾーンの詳細およびレコードのリストが表示されます。
- CNAMEレコードのチェック・ボックスを選択し、「アクション」ドロップダウン・メニューから「編集」を選択します。
- 「レコードの編集」ダイアログ・ボックスで、クリップボードからのCNAMEターゲットが入力された「ターゲット」フィールドを更新します。
- 「送信」をクリックします。
- 「変更の公開」をクリックします。
- 確認ダイアログ・ボックスで、「変更の公開」をクリックします。
6. WAFの保護
WAFを保護するには、WAFサーバーからのトラフィックを受け入れるようにサーバーを構成する必要があります。オリジンのイングレス・ルールを、次の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チューニング・ヘルプをリクエストできます。エキスパートがプロセスをガイドします。
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
- 保護ルールの推奨を表示するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
- 「保護ルール」をクリックします。
- 「推奨」タブをクリックします。このリストは、WAF経由で流れていることがWAFによって検出されたトラフィックに基づいて生成されます。このリストに何も表示されない場合は、アプリケーションのFQDNのテストを続行し、後で戻って確認してください。
- 「検出」推奨アクションを含む保護ルールを選択し、「推奨の受入れ」をクリックします。
「推奨アクション」フィルタを使用して、「検出」による推奨を見つけることができます。
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
- ルール設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
- 「保護ルール」をクリックします。
- 「保護ルール」表を使用して、検出するルールを見つけます。
- 表から見つけたルールIDを「ルールID」フィルタに入力します。この例では、「ルールID」フィルタに941110 (クロスサイト・スクリプティング)と入力します。
- フィルタ処理した保護ルールの「アクション」ドロップダウン・メニューから、「検出」を選択します。
詳細は、WAF保護ルールを参照してください。
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
- アクセス・ルールを構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
- 「アクセス制御」をクリックします。
- 「アクセス・ルールの追加」をクリックします。
- 「アクセス・ルールの追加」ダイアログ・ボックスで、次のように入力します:
- 名前: DetectRequestsFromMySpecificBrowser
- ルール・アクション: 「検出のみ」を選択します。
- 条件: メニューから「IPアドレスは次のとおりです」を選択し、アプリケーションのテスト中にクリップボードにコピーしたIPアドレスを「IPアドレス」フィールドに入力します。
- 「+Additional条件」をクリックします。
- 条件: メニューから「ユーザー・エージェントは次のとおりです」を選択し、アプリケーションのテスト中にクリップボードにコピーしたエージェント値を「ユーザー・エージェント・ヘッダー」フィールドに入力します。
ノート
ルールがトリガーされるためには、前出の例のIPアドレスとユーザー・エージェントの両方が一致している必要があります。アプリケーションのテストに別のユーザー・エージェントを使用する場合、リクエストは検出されません。
- 「アクセス・ルールの追加」をクリックします。
- 「公開されていない変更」をクリックします。
- 「すべて公開」をクリックします。
詳細は、「エッジ・ポリシーのアクセス制御」を参照してください。
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
- JavaScriptチャレンジ設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
- 「Bot Management」をクリックします。
- 「JavaScriptチャレンジの編集」をクリックします。
- 「JavaScriptチャレンジ」ダイアログ・ボックスで、「JavaScriptチャレンジの有効化」チェック・ボックスを選択します。
-
「JavaScriptチャレンジ・アクション」セクションで、「検出のみ」を選択します。
-
次の情報を入力します:
- 条件の有効化: 有効にすると、設定したアクションが実行されるには条件が一致する必要があります。条件およびルールの詳細は、「エッジ・ポリシーのアクセス制御」を参照してください。
- アクションしきい値(リクエスト数): アクションの実行までに失敗するリクエストの数を指定します。ページのロード中にブラウザから非同期リクエストが発生するため、しきい値としてAjaxの基本的な利用のWebアプリケーションは10個、Ajaxを多用するアプリケーションは100個に設定することをお薦めします。
- アクション失効時間(秒): 同じIPアドレスへのチャレンジの間隔(秒)を入力します。クライアントIPアドレスの変更のため、失効時間を、モバイル・ユーザーのアプリケーションには120秒、デスクトップ・ユーザーのみのアプリケーションには3,600秒に設定することをお薦めします。
- リダイレクトのフォロー: 有効にすると、オリジンからのリダイレクト・レスポンスもチャレンジされます。
- NATサポートの有効化: 有効にすると、ユーザーがIPアドレスのみでなく、一意の追加ハッシュによっても識別されるため、共有IPアドレスを持つビジターがブロックされることがなくなります。負荷の高いアプリケーション(200以上のRPS)では、このNATサポートを無効にすることをお薦めします。
- 「変更の保存」をクリックします
JavaScriptチャレンジが、公開される変更のリストに追加されます。
詳細は、Bot Managementを参照してください。
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
- JavaScriptチャレンジ設定を構成するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
- 「Bot Management」をクリックします。
- 「ヒューマン・インタラクション・チャレンジ」タブをクリックします。
- 「ヒューマン・インタラクション・チャレンジの編集」をクリックします。
- 「ヒューマン・インタラクション・チャレンジの編集」ダイアログ・ボックスで、「ヒューマン・インタラクション・チャレンジの有効化」チェック・ボックスを選択します。
- 「ヒューマン・インタラクション・アクション」セクションで、「検出のみ」を選択します。
- 次の情報を入力します:
- アクションしきい値(リクエスト数): アクションの実行までに失敗するリクエストの数を指定します。ページのロード中にブラウザから非同期リクエストが発生するため、しきい値としてAjaxの基本的な利用のWebアプリケーションは10個、Ajaxを多用するアプリケーションは100個に設定することをお薦めします。
- しきい値有効期間(秒): しきい値が期限切れになるまでの秒数。
- アクション失効時間(秒): 同じIPアドレスへのチャレンジの間隔(秒)を入力します。クライアントIPアドレスの変更のため、失効時間を、モバイル・ユーザーのアプリケーションには120秒、デスクトップ・ユーザーのみのアプリケーションには3,600秒に設定することをお薦めします。
- インタラクションしきい値(インタラクション数): しきい値が期限切れになるまでのインタラクション数。
- 記録期間(秒): ユーザーのイベントを記録する期間。
- NATサポート: 有効にすると、ユーザーがIPアドレスのみでなく、一意の追加ハッシュによっても識別されるため、共有IPアドレスを持つビジターがブロックされることがなくなります。負荷の高いアプリケーション(200以上のRPS)では、サポートを無効にすることをお薦めします。
- 「変更の保存」をクリックします
ヒューマン・インタラクション・チャレンジが、公開する変更リストに追加されます。
詳細は、Bot Managementを参照してください。
WAFの処理順序については、「エッジ・ポリシーの管理」を参照してください。
ルールのテスト
ポリシーがアクティブになっている場合、WAFによってルールが検出されることをテストできます。
- アプリケーションをテストしたときに使用した同じブラウザを使用して、次のことを行います:
- 次の問合せパラメータを追加して、アプリケーションのFQDNをリクエストします:
?id=<script>alert("TEST");</script>
- 次の問合せパラメータを追加して、アプリケーションのFQDNをリクエストします:
- 同じマシン上で別のブラウザを使用し、前出のリクエストを繰り返します。すべてのリクエストはアプリケーションを経由する必要があります。
WAFがリスクとして特定されたリクエストを検出していることを確認するには:
- ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「Web Application Firewall」で、「ポリシー」をクリックします。
- ログを表示するWAFポリシーの名前をクリックします。WAFポリシーの概要が表示されます。
- 「ログ」をクリックします。WAFポリシーのログが表示されます。
- 「アクション」フィルタから「検出」チェック・ボックスを選択します。
- クロスサイト・スクリプティング・リクエストによってトリガーされる保護ルールに対するエントリが2つあり、ユーザー・エージェントとIPアドレスを検出するためのエントリが1つあることを確認します。