CoreDashのボットをCDNやファイアウォールで許可する

2つのCoreDashボットをCDNやファイアウォールで許可する

サイトにアクセスするCoreDashのボットには、cRUM監査と稼働チェックの2種類があります。CoreDashを最大限に活用するには、CDNやファイアウォールで両方のボットを許可する必要があります。設定によってはブロックされることがありますが、このページでは、両方のボットを1つのルールでカバーし、CloudflareとAWS WAFで解決する方法を説明します。

それぞれのボットの役割は以下のとおりです。

• cRUM監査：CoreDashメニューの「cRUM (beta)」でページを選択すると、監査サーバー上のChromeで一般の訪問者と同様に対象ページを開き、表示を遅らせている要因を特定します。ユーザーエージェントはCoreDash/1.0 (audit; +https://www.coredash.app/bot)です。
• 稼働チェック：CoreDashが30分ごとに自社サーバーから監視対象の各サイトへリクエストを送信し、停止を検知して通知します。送信されるユーザーエージェントはCoreDash/1.0 (uptime; +https://www.coredash.app/bot)です。

ユーザーエージェントとは、ブラウザやボットが自身を識別させるためにリクエストごとに送信する名前です。CoreDashのボットはいずれもCoreDash/で始まるため、ルールではこの文字列を判定条件にします。

監査や稼働チェックがブロックされたときの表示

ファイアウォールやCDNは、データセンターからの訪問者のユーザーエージェントがブラウザのものではない場合、信頼できないボットとみなしてエラーコードやチャレンジページを返します。ブロックされたときの影響は、ボットごとに異なります。

ブロックされたcRUM監査は、「Audit failed」というメッセージとその下にエラーを表示して停止します。あるいは、ブロックページに対してそのまま監査が実行されることもあります。その場合、Page load filmstripには本来のページではなくチャレンジページやエラーページが表示され、監査の数値もすべてそのブロックページのものになります。

稼働モニターには「Blocked」と表示され、「A firewall blocks the checker」という通知に取得したステータスコードとブロック開始日時が表示されます。CoreDashはブロックされたチェックをダウンタイムから除外するため、ブロックによって稼働率が低下することはありません。ただし、すべてのチェックがブロックされている間はサイトに到達できていないため、サイトがダウンしても検知できなくなります。

Cloudflareがすべての稼働チェックに403を返しているときの、example-shop.comのモニター画面。

ファイアウォールがCoreDashを識別する仕組み

ファイアウォールやCDNにCoreDash用の例外を1つ作成します。通常はユーザーエージェントを条件に設定します。CoreDash/を対象にしたルールが1つあれば、監査と稼働チェックの両方を許可できます。プロジェクト固有のボットトークンを使用すれば、自社プロジェクトのボットのみが送信するため、より安全なルールになります。CoreDashのIPアドレスによる許可は、ほかの方法が使えない場合の最終手段です。サーバーの追加や移転に伴ってIPアドレスは変更されるため、自身でルールを最新状態に保つ必要があります。

どの設定で例外が必要かは、ファイアウォールのログで確認できます。Cloudflareのログ確認手順は次のセクションで説明します。AWS WAFについては、後述の「AWS WAFのBot Controlより上位でCoreDashを許可する」を参照してください。

CloudflareでCoreDashをブロックしている原因を特定する

Cloudflareで対象ドメインを開き、「Security」›「Analytics」の「Events」タブに移動します。「Sampled logs」の中から、CoreDashのユーザーエージェントを持つリクエストを探します。トラフィックの多いサイトでは、「Filter」をクリックしてフィールドに「User agent」を選択し、値として稼働チェックならCoreDash/1.0 (uptime; +https://www.coredash.app/bot)、監査ならCoreDash/1.0 (audit; +https://www.coredash.app/bot)の完全なユーザーエージェントを貼り付けます。

該当のリクエストをクリックして開きます。「Service」の行に、ブロックしたCloudflareの機能名が表示されています。

example-shop.comで、Browser Integrity Checkが稼働チェックをブロックした例。

この「Service」行の表示によって、対処方法が決まります。

• Bot fight mode：Cloudflare Freeプランのボット保護機能です。カスタムルールで例外を設定することはできません。後述のBot Fight Modeのセクションに進んでください。
• それ以外（スクリーンショットのBrowser integrity check、マネージドルール、Super Bot Fight Modeなど）：後述の手順でSkipルールを作成します。

CloudflareのSkipルールでCoreDashを許可する

Skipルールは、指定した機能について、CoreDashのユーザーエージェントを持つリクエストを検査対象から除外するようCloudflareに指示するルールです。監査と稼働チェックの両方を一度にカバーでき、すべてのCloudflareプランで作成できます。

1. 「Security」›「Security rules」に移動します。「Custom rules」配下の「Create rule」をクリックします。

最初のカスタムルールを作成する前の、example-shop.comのSecurity rules画面。

2. ルール名に「CoreDash」と入力します。「When incoming requests match」で「Edit expression」をクリックし、表示されたテキストボックスに次の行を貼り付けます。

   http.user_agent contains "CoreDash/"

「Edit expression」をクリックした後のルール名と条件式。CoreDashの後のスラッシュも必要です。

3. 「Then take action」で「Skip」を選択し、CoreDashに対してスキップする対象を選択します。「WAF components to skip」で「All managed rules」と「All Super Bot Fight Mode Rules」にチェックを入れます。「More components to skip」をクリックして展開し、「Browser Integrity Check」にもチェックを入れます。「Log matching requests」はオンのままにしておくと、後でEventsでルールの動作を確認できます。

アクション「Skip」を選択し、3つの項目にチェックを入れた状態。

4. 「Deploy」をクリックします。ドメインにすでにほかのカスタムルールがある場合、ルールの配置順を尋ねられます。必ず先頭に配置してください。

ほかにカスタムルールがなければ順序指定は不要で、「Deploy」のクリックで完了します。

5. CoreDashが通過できることを確認します。次回の監査または稼働チェックが届くと、CloudflareのEventsにアクション「Skip」として表示されます。CoreDash側でも、利用しているボット（または両方）を確認してください。

cRUM監査の場合は、「cRUM (beta)」でページを再度選択するか、開いているブラウザのタブを再読み込みすると、新しい監査が開始されます。ブロックが解除されていれば、Page load filmstripに実際のページがChromeで読み込まれる様子がコマ送りで表示されます。

完了した監査の例。各コマにTTFB、FCP、LCP、CLSがマークされています。

稼働チェックはクリック不要です。CoreDashは毎時0分と30分にチェックを実行するため、30分以内にモニターが「Up」になり、新しいバーが緑色になります。

example-shop.comが再び「Up」になった状態。38回のチェックで403が返されていましたが、ルール作成後はすべてのチェックで200が返されています。

CoreDashのボットトークンを使ったより安全なCloudflareルール

CoreDash/で始まるユーザーエージェントは誰でも送信できるため、CoreDashになりすました不正なボットもSkipルールを通過してしまいます。プロジェクトのボットトークンは秘密情報であり、すべての監査と稼働チェックでX-CoreDash-Botという名前のヘッダーに含めて送信されます。このトークンを条件にすれば、自身のプロジェクトのボットだけを通過させられます。

トークンを取得するには、CoreDashで「Project settings」を開き、「CoreDash bot token」タブに移動します。このタブはプロジェクトオーナーのみが開けます。モニターが「Blocked」になっている間は、通知内の「View your CoreDash bot token」リンクからも移動できます。「Copy Cloudflare rule」をクリックすると、トークンを含んだ完全な条件式がコピーされます。

「Copy Cloudflare rule」をクリックすると、トークンを含んだ条件式がクリップボードにコピーされます。

すでにSkipルールを作成済みの場合は、「Security」›「Security rules」で「CoreDash」ルールを開きます。条件式内のユーザーエージェントの行をコピーした内容に置き換え、ルールを保存します。アクションやチェックを入れた項目はそのまま変更不要です。まだルールを作成していない場合は、前述のSkipルールの手順に従い、ステップ2でトークンの行を貼り付けてください。

トークンは、プロジェクト自体のサイトとそのサブドメインにのみ送信されます。別ドメインのページを監視または監査する際にはトークンは送信されないため、そのドメインではユーザーエージェントによるルールを引き続き使用してください。万が一トークンが意図しない場所に漏洩した場合は、「Make a new token」をクリックします。古いトークンは即座に無効になるため、生成後すぐにCloudflareのルールを新しいトークンに更新してください。

Cloudflare FreeプランのBot Fight Mode

Eventsの「Service」行に「Bot fight mode」と表示されていた場合は、このセクションの手順を実施してください。

アクションが「Managed Challenge」、Serviceが「Bot fight mode」となっているCoreDash稼働チェックの例。

Bot Fight Modeはクラウドサーバー上で動作する単純なボットに対してチャレンジを発行する機能ですが、CloudflareからはCoreDashのボットもそうしたボットと判定されます。Cloudflareのドキュメントにあるとおり、SkipルールやAllowルールはこの機能に対して効果がありません。そのため、機能を無効にするか、有効にしたままCoreDashのIPアドレスを許可するかのいずれかを選択する必要があります。

Bot Fight Modeを無効にする

「Security」›「Settings」に移動し、「Bot traffic」で絞り込みます。「Bot fight mode」の行を探し、スイッチをオフにします。これで、サイト全体で単純なボットへのチャレンジ発行が停止します。ボット保護を維持したい場合は、Proプランの「Super Bot Fight Mode」を利用すればSkipルールを適用できます。スイッチをオフにした後は、Browser Integrity CheckやマネージドルールによってCoreDashがブロックされないよう、前述のSkipルールもあわせて作成してください。

Bot fight modeのスイッチは「Status」列にあります。このスクリーンショットではすでにオフになっています。

Bot Fight Modeを有効にしたままCoreDashのIPアドレスを許可する

設定前の注意点：これらのIPアドレスは固定ではありません。設定したIPアクセスルールは自動更新されませんが、最新のリストは常にapp.coredash.app/bot/ips.jsonで確認できます。将来CoreDashが再びブロックされた場合は、まずルールのIPアドレスをこのリストと照合してください。

IPアクセスルールを使うと、指定したIPアドレスをファイアウォールルールの検査から除外できます。このルールに一致したリクエストには、Bot Fight Modeも適用されません。「Security」›「Security rules」に移動し、「IP access rules」配下の「Create rule」をクリックします。カスタムルールとしての作成を促された場合は、「No, go to IP access rules」を選択してください。51.195.222.219を入力し、「Allow」と「This website」を選択して「Create」をクリックします。アドレスごとに1つずつルールを作成してください。稼働チェック用には51.195.222.219と51.195.222.220、cRUM監査用には135.125.202.210を設定します。

CoreDashのアドレスごとにIPアクセスルールを作成し、「This website」で「Allow」に設定します。

いずれの対処を行った後も、Skipルールのステップ5と同様の方法で、CoreDashが正しくアクセスできているか確認してください。

AWS WAFのBot Controlより上位でCoreDashを許可する

AWS WAFでCoreDashがブロックされる原因は、通常、AWSが提供するボット対策マネージドルールグループ「Bot Control」にあります。Bot Controlより上位にCoreDashのユーザーエージェントを許可するAllowルールを配置すれば、1つのルールで監査と稼働チェックの両方を通過させられます。ここでのAWSスクリーンショットは、この記事の解説用に作成したacme-aws.comのデモ環境のものです。

1. AWS WAFコンソールでサイトのWeb ACL（サイトを保護するルールセット）を開き、「Sampled requests」タブに移動します。リクエストのURIをクリックしてヘッダーを確認します。CoreDashのリクエストは、CoreDash/で始まるユーザーエージェントを持っています。「Rule inside rule group」列に、リクエストをブロックしたルール名が表示されます。

acme-aws.comで、Bot Controlの「SignalNonBrowserUserAgent」ルールがCoreDashの稼働チェックをブロックしている例。

2. Web ACLで「Add rules」›「Add my own rules and rule groups」をクリックし、Rule builder（新しいAWSコンソールでは「Custom rule」）を開きます。スクリーンショットのとおりに入力します。ルール名を「CoreDash」にし、user-agentヘッダーを検査して、CoreDash/で始まるすべてのリクエストを許可（Allow）する標準ルール（regular rule）を作成します。フォームの下部までスクロールし、「Add rule」をクリックします。

CoreDashルールの設定：Single header「user-agent」、Starts with string「CoreDash/」、アクション「Allow」。

3. 続いて「Set rule priority」画面が表示されます。「CoreDash」を選択し、「Move up」をクリックして最上位に移動させ、「Save」をクリックします。AWS WAFはルールを上から順に評価し、Allowルールに一致したリクエストは以降のルールで評価されないため、Bot Controlに届く前に処理されます。

Bot Controlルールグループより上位（最上位）に配置されたCoreDashルール。

4. CoreDashが通過できることを確認します。「Sampled requests」で最新のCoreDashリクエストを確認し、「CoreDash」ルールが適用され、アクションが「Allow」になっていることを確認します。

acme-aws.comで最新のCoreDashチェックがCoreDashルールに一致し、許可されている状態。

CoreDash側でも、CloudflareのSkipルールにおけるステップ5と同様に確認します。新しい監査を実行するとPage load filmstripに実際のページが表示され、次回の稼働チェック後にモニターが「Up」に変わります。

Cloudflareと同様に、プロジェクトのボットトークンを使用するとルールをより安全にできます。トークンを使用する理由や、トークンが送信されるサイトの範囲については、前述のCloudflareトークンのセクションを参照してください。AWSのルールをトークンに切り替える手順は以下のとおりです。

1. CoreDashで「Project settings」を開き、「CoreDash bot token」タブに移動して「Copy token」をクリックします。
2. AWS WAFで、Web ACL上の「CoreDash」ルールを再度開きます（前述のRule builderのフォームです）。
3. ヘッダーのフィールド名をuser-agentからx-coredash-botに変更します。AWS WAFはヘッダー名の大文字・小文字を区別しないため、これでX-CoreDash-Botヘッダーが対象になります。
4. Match typeを「Exactly matches string」に設定し、照合する文字列（String to match）にトークンを貼り付けてルールを保存します。

CDN背後でオリジンチェックがtimeoutする場合

このセクションは稼働チェックのみが対象であり、モニター設定の「Advanced」で「Origin IP」を指定している場合にのみ関係します。この設定を行うと、CoreDashはCDNを経由せず、オリジンサーバーへ直接チェックを実行します。一部のサーバーはCDNのIPアドレスからのリクエストのみを許可するように設定されているため、一般の訪問者にはCDNから正常にページが配信されているにもかかわらず、モニターには「The origin check fails: Connect timeout」と表示されて「Down」になってしまいます。

CDNはキャッシュページを配信し続けているものの、サーバー自体へのチェックがtimeoutしている状態。

ここでは、ユーザーエージェントやトークンに基づくルールは機能しません。サーバーはヘッダーを読み込む前の接続元IPの段階でパケットを破棄しているためです。したがって、IPアドレスによってCoreDashを認識させる必要があります。サーバーのファイアウォールで稼働チェック用の2つのIPアドレス（51.195.222.219および51.195.222.220）を許可するか、ホスティング事業者に許可を依頼してください。後日再びオリジンチェックがtimeoutするようになった場合は、IPアドレスが変更された可能性があるため、まずは最新のリストを確認してください。

それでもCoreDashがブロックされる場合

モニターが依然として「Blocked」のままだったり、監査が失敗し続けたりする場合は、再度ログを開いて最新のCoreDashリクエストをクリックしてください（CloudflareならEvents、AWSならSampled requests）。そこに表示されている機能が、現在CoreDashを停止させている原因です。主な原因には以下が挙げられます。

• 以前とは別の機能によるブロック：Bot Fight Modeを無効にした後にBrowser Integrity Checkでブロックされるようなケースです。Skipルールもあわせて作成してください。
• ルールが有効になっていない、またはAWSで最上位にない：Cloudflareでは、Custom rules配下のCoreDashルールが「Active」になっている必要があります。AWSでは、「Set rule priority」で最上位に配置されている必要があります。
• 設定内容が手順と異なっている：Cloudflareでは「contains」とスラッシュを含むCoreDash/が必要です。AWSではヘッダーに「user-agent」、照合条件に「Starts with string」を指定する必要があります。
• 自身で作成した別のCloudflareルール（国別ブロックルールなど）：Skipルールを適用しても、他のカスタムルールは実行されたままになります。CoreDashを対象外にするよう該当ルールを修正してください。アクセス元の国はEventsで確認できます。
• Under Attack Modeが有効になっている：オフにするまで、CoreDashを含むすべての訪問者に対してチャレンジが発行されます。
• リクエストが通過していると表示されるか、そもそもCoreDashのリクエストが記録されていない：CloudflareやAWSの前段または後段に、ホスティング事業者のファイアウォールやサーバー側の設定など、別のファイアウォールが存在します。そちらでもCoreDash/ユーザーエージェントを許可してください。

解決しない場合は、モニターまたは監査対象ページのURLと、ブロックが発生した日時を添えてCoreDashにお問い合わせください。

両方のボットが送信する内容とその理由については、CoreDashボットのページで解説しています。モニターの詳細については稼働監視、スクリプトでの利用についてはUptime APIを参照してください。