Cloudflare WAFでWordPressを守る — カスタムルールの3例

2026-02-15

WordPressの手前にCloudflareを置くと、CDNやエッジのHTTPSが使える。読者が少ない時間帯にも小さなサーバーを重くする、自動リクエストの対処先も増える。

ログでまず見たいのは /wp-login.php と /xmlrpc.php だ。繰り返されるログイン試行やXML-RPCの悪用は、サーバーに余分な処理をさせる。これらのアクセスが増える時間と、サイトが遅くなる時間を比べてみる。

対象のホスト名がプロキシ経由なら、Cloudflareのウェブアプリケーションファイアウォールは、条件に合う通信をオリジンへ送る前に処理できる。以下の三例から、運用に合うものを選ぶ。

この記事で使った管理画面では、次の順で開く。

Cloudflareの管理画面 → Security → WAF → Custom rules → Create rule

対象サイトのカスタムルールを開く

  1. Cloudflareにログインする。
  2. 設定するサイトを選ぶ。
  3. 「Security」から「WAF」「Custom rules」と進む。新しい管理画面では「Security rules」を開く。
  4. 「Create rule」を選び、選択肢が出たら「Custom rules」に進む。

ルールは順に評価される。ブロックするルールで評価が止まることがあるため、既存ルールとの並び順を確認する。

ルール1 — 国・地域を条件にする

ここでは、中国または香港からと判定されたリクエストを条件にする。

地域で制限する運用上の理由がある場合の設定例だ。Blockは式に合う利用者の通信をすべて拒否する。Managed Challengeは該当リクエストをCloudflareが判定するため、正規の利用者にも影響することがある。

国・地域の条件を設定する

ルール名の例

  • China_HK_Block
  • チャレンジを試す場合は China_HK_Challenge

「When incoming requests match…」の下で最初の条件を追加する。

  1. フィールド — Country（ip.src.country）
  2. 演算子 — equals
  3. 値 — China

二つ目の条件を追加する。

  1. フィールド — Country
  2. 演算子 — equals
  3. 値 — Hong Kong

二つの条件はORでつなぐ。片方に当てはまれば一致する。

  • いずれかに一致（OR）

式エディターを使う場合は、以下のように入力する。

(ip.src.country eq "CN") or (ip.src.country eq "HK")

アクションを選ぶ

  • Block — 条件に一致するリクエストを拒否する。
  • Managed Challenge — ブラウザーにCloudflareの判定を通る機会を与える。

「Deploy」で反映するか、確認のために保存する。

ルール2 — XML-RPCの入り口を制限する

ここでは xmlrpc.php を含むパスを条件にする。WordPressをサイトのルートに置いているなら、/xmlrpc.php との完全一致に絞る方法もある。

Jetpack、モバイルアプリ、外部の投稿ツールがXML-RPCを使っていないか先に確認する。使うものがなければ、そのパスをBlockにできる。

XML-RPCの条件を設定する

ルール名の例

  • WP_Block_XMLRPC

条件を追加する。

  1. フィールド — URI Path
  2. 演算子 — contains
  3. 値 — xmlrpc.php

アクションを選ぶ

  • Block

「Deploy」で反映するか、確認のために保存する。

以下は部分一致を使った式の例だ。

(http.request.uri.path contains "xmlrpc.php")

ルール3 — ログインページへのリクエストを判定する

既定のWordPressログインパスを対象にする。変更済みなら、実際に使うパスに置き換える。

ログイン先を一律にブロックすると、自分やほかの管理者も入れなくなる。ブラウザーでログインする場合はManaged Challengeを選べる。反映前に、このパスを使う操作を試しておく。

ログイン先の条件を設定する

ルール名の例

  • WP_Login_ManagedChallenge

条件を追加する。

  1. フィールド — URI Path
  2. 演算子 — contains
  3. 値 — /wp-login.php

アクションを選ぶ

  • Managed Challenge

「Deploy」で反映するか、確認のために保存する。

式で設定する場合は、次のようになる。

(http.request.uri.path contains "/wp-login.php")

反映後にルールを確かめる

目指すのは、使い勝手を保ちながら不要な通信を減らすことだ。オリジンへのアクセスが大きく減ったグラフが出ても、ルールが広すぎることはある。

地域ルールの対象が分からない場合、プランで使えるならLogから始める。Managed Challengeで試し、イベントを見る方法もある。地域によるブロックは同じ場所にいる正規の読者とボットを区別できない。

ログイン先は必要な人が使える状態にしておく。ブラウザーではManaged Challengeを通れても、自動連携では通れないことがある。パスワードの再設定など、同じパスを使う操作も確認する。

管理者セッションを開いたまま、別のプライベートウィンドウでログインを試す。Jetpack、モバイルアプリ、外部投稿ツールも確認する。XML-RPCを使うものがあれば、どのパスにどの利用元からのアクセスが必要かを調べてからルールを反映する。

Cloudflareの「Security Events」で、どのルールに一致し、どのアクションが働いたかを見る。同じ時間帯のオリジンのログと比べると、まだ届いている通信が分かる。

ログで見えている通信を起点に、ルールが拾う範囲と、なおWordPressに届くリクエストを確かめる。不要な通信が減っても遅ければ、オリジンの状態も調べる。

記事を検索