2026年9月3日
Fastly の WAF 設定は、サイト（ワークスペース）を Next-Gen WAF に追加し、既定の Logging（Not Blocking）モードで数日観察してしきい値とルールを調整し、Protection mode を Blocking に切り替えるという流れです。シグネチャの一致で即ブロックする従来型と違い、攻撃の「兆候」を IP ごとに数え、しきい値を超えた IP からの攻撃リクエストだけを止めるのが基本の動きです。
結論を先にまとめます。
- Fastly の WAF は 2026年11月現在 Next-Gen WAF（旧 Signal Sciences）と呼ばれ、Fastly のエッジで動く Edge WAF、Fastly が用意したクラウドで動く Cloud WAF、自分のサーバーにエージェントを置く On-Prem WAF の 3 方式があります。
- 判定の単位は「シグナル」です。SQL インジェクションなどの攻撃シグナル、異常を示すシグナル、自分で定義するカスタムシグナルがあり、1 つのリクエストに複数付きます。
- 既定はしきい値方式で、1 つの IP から一定時間に攻撃シグナルが一定数を超えると「フラグ付き IP」になり、Blocking モードならその IP の攻撃シグナル付きリクエストが止まります。1 件でも止める「Immediate blocking」も選べます。
- 新しいサイトは Logging（Not Blocking）で始まります。先に正規のトラフィックが誤って攻撃と判定されていないかを確認し、Blocking へ移します。
- WordPress で見るべき点は
wp-login.phpとxmlrpc.phpへの試行、wp-admin配下へのアクセス、プラグインの脆弱性を狙う既知のパスです。
Fastly Next-Gen WAF の仕組み
公式ドキュメントの Start here と用語集に沿って整理します。
| 用語 | 意味 |
|---|---|
| Corp | 契約単位のアカウント。コントロールパネルで管理する |
| Site（ワークスペース） | 保護対象のサイト。Corp の下に複数作れる |
| Protection mode（Agent mode） | Blocking（攻撃を止めて記録）/ Logging（別名 Not Blocking。記録だけ）/ Off |
| Signal（シグナル） | リクエストの特徴を表すラベル。攻撃シグナル、異常シグナル、カスタムシグナルなど |
| Attack threshold（攻撃しきい値） | 1 つの IP から見た攻撃シグナルの上限。超えるとその IP にフラグが付く |
| Threshold blocking | フラグ付き IP の攻撃リクエストを止める（既定の方式） |
| Immediate blocking | 攻撃シグナルが 1 つでも付いたリクエストを止める |
| Request rules | 条件に合うリクエストを許可・ブロック・タグ付けするルール |
| Rate limiting rules | 一定時間の回数を超えたクライアントに対して動くルール |
| Signal exclusion rules | 特定の条件でシグナルを付けないようにして誤検知を避けるルール |
公式ドキュメントはしきい値方式の理由を「攻撃の傾向が現れてからブロックすることで誤検知の危険を下げる」と説明しています。異常シグナルとカスタムシグナルだけが付いたリクエストはしきい値の計数に含まれません。
3 つの展開方式
| 方式 | 動く場所 | 向く場面 |
|---|---|---|
| Edge WAF | Fastly のエッジ（CDN）上 | すでに Fastly の CDN を使っている。サーバーに何も入れたくない |
| Cloud WAF | Fastly が用意したクラウド上。DNS を向けて通す | CDN は別でも WAF だけ使いたい |
| On-Prem WAF | 自分の Web サーバーにエージェント（とモジュール）を置く | リクエストがサーバーに届くまでの経路を変えられない。社内の構成を保ちたい |
どの方式でも判定ロジックと管理画面は共通で、Site 単位でモードやルールを持ちます。利用できる方式は契約パッケージによって異なるため、契約時に確認します。料金はこの記事では扱いません。
手順 1: 展開方式を決めてサイトを追加する
Fastly の CDN をすでに使っているなら Edge WAF が最短です。Fastly のサービスに WAF を紐づけるだけで、オリジン側の変更は要りません。CDN を使っていない、または他社の CDN を使っているなら Cloud WAF（DNS の向け先を変える）か On-Prem WAF（サーバーにエージェントを入れる）を選びます。
公式ドキュメントが推奨する順序は次のとおりです。
- 可能ならステージング環境のサイトに先に追加し、業務のロジックや正規のトラフィックが通るか確かめる。
- 本番のサイトを追加する。新しいサイトは
Logging（Not Blocking）で始まる。 - 検知を試し（公式の「attack tooling」でのテストが案内されています）、しきい値とルールを調整する。
- Protection mode を
Blockingに切り替え、動きを確認する。 - 本番トラフィックを監視し、必要に応じて調整する。
手順 2: Logging モードで観察する
Blocking にする前に、最低でも数日は Logging のまま置き、管理画面の監視画面で次を見ます。
- どのシグナルがどれくらい付いているか。正規の利用（たとえば管理画面からの投稿内容に SQL 文や HTML が含まれる）が攻撃シグナルになっていないか。
- フラグ付き IP になった IP が、本当に攻撃元か。社内の固定 IP や監視サービスの IP が含まれていないか。
wp-login.phpとxmlrpc.phpへの試行がどの程度あるか。
誤検知が見つかったら、Signal exclusion rules で「このパスのこのパラメーターには SQLi のシグナルを付けない」のように絞ります。サイト全体でシグナルを切るのではなく、条件を狭くするのが公式の意図です。
手順 3: しきい値とルールを調整する
攻撃しきい値
既定のしきい値は Site の設定（公式ドキュメント Configuring attack thresholds）で変えられます。しきい値を下げると早く止まり、誤検知の影響も大きくなります。Logging で観察した数を基に決めます。既知の脆弱性を狙う CVE 向けの「仮想パッチ」シグナルは、Immediate blocking の対象に指定できます。
リクエストルール
条件（パス、メソッド、国、ヘッダー、シグナルの有無など）に合うリクエストを、許可・ブロック・タグ付けします。WordPress では次のような使い方になります。
| 目的 | ルールの例 |
|---|---|
| 管理画面を特定の IP だけに | パスが /wp-admin/ または /wp-login.php で、送信元 IP が社内の範囲外ならブロック |
| XML-RPC を使っていないなら止める | パスが /xmlrpc.php ならブロック |
| 公開前のパスを隠す | パスが /staging/ 配下なら社内 IP 以外をブロック |
レート制限
Rate limiting rules で、一定時間に同じクライアントから wp-login.php への POST が一定数を超えたらブロックやタグ付けをします。パスワード総当たりはしきい値方式の攻撃シグナルには当たらないことがあるため、レート制限で補います。
手順 4: Blocking に切り替えて確認する
Site の Protection mode を Blocking に変えます。切り替え直後は次を確認します。
- 自分で管理画面にログインし、投稿の保存、メディアのアップロード、プラグインの更新が通るか。
- 問い合わせフォームの送信、コメントの投稿、決済があれば決済まで通るか。
- 監視画面でブロックされたリクエストの内訳を見て、正規の利用が混ざっていないか。
問題があれば Logging に戻して原因のシグナルを特定し、除外ルールを足してから再度 Blocking にします。モードの切り替えは即時に反映されます。
WordPress の観点
WordPress サイトへの攻撃は、サイトの知名度に関係なく自動化された探索として届きます。Next-Gen WAF で見ておくべき点は次のとおりです。
- ログインの試行:
wp-login.phpへの POST の回数。レート制限と、Blocking モードでの遮断の両方を使います。WordPress 側のログイン制限（セキュリティプラグイン）との二重化が基本です。 - XML-RPC: 使っていないなら WAF で
xmlrpc.phpを止めると、総当たりと増幅攻撃の経路が 1 つ減ります（「XML-RPC を無効化する方法」）。 - 既知の脆弱なパス: 古いプラグインの脆弱性を狙うリクエストは攻撃シグナルになります。WAF が止めても、プラグイン自体の更新は別に必要です。
- 実 IP: Edge WAF や Cloud WAF を通すと、オリジンから見た送信元は Fastly の IP になります。WordPress 側で IP を使う機能（コメントの IP 記録、ログイン制限）のために、Web サーバーで
X-Forwarded-Forから実 IP を復元します。
WAF は「届いた攻撃を止める」層であり、「侵入された後の復旧」は別の作業です。復旧の流れは「乗っ取り・マルウェア感染時の復旧依頼の流れ」にまとめています。
よくある質問
Fastly の WAF は Cloudflare の WAF と何が違いますか
どちらも CDN 事業者の WAF ですが、Fastly の Next-Gen WAF は IP ごとに攻撃シグナルを数えてしきい値で判定する方式を既定とし、エージェントをサーバーに置く On-Prem 方式も持つ点が特徴です。どちらが優れているかは構成と運用体制で変わるため、両方の公式ドキュメントで判定方式と展開方式を比べて選んでください。
Blocking にしたら管理画面が使えなくなりました
管理画面での投稿内容（HTML や SQL のような文字列）や、プラグインの通信が攻撃シグナルと判定されている可能性があります。いったん Logging に戻し、監視画面で自分の IP に付いたシグナルを確認し、該当のパスとパラメーターに対する Signal exclusion rule を作ってから戻します。
攻撃シグナルが 1 つ付いたら即ブロックできますか
できます。Immediate blocking を有効にすると、攻撃シグナルが 1 つでも付いたリクエスト（または指定した CVE 仮想パッチのシグナル）が止まります。既存のしきい値設定は保持されるので、戻すことも簡単です。ただし誤検知の影響は大きくなります。
WordPress 側のセキュリティプラグインは不要になりますか
役割が違います。WAF はリクエストが PHP に届く前に止める層で、プラグインはログインの保護、ファイル改ざんの検知、更新の管理など WordPress の内側を見ます。片方に寄せず併用します。
まとめ
- Fastly の WAF（Next-Gen WAF）はシグナルとしきい値で判定し、Edge・Cloud・On-Prem の 3 方式から選びます。
- 新しいサイトは Logging（Not Blocking）で始め、誤検知を除外ルールで潰し、しきい値とレート制限を決めてから Blocking へ切り替えます。
- WordPress では
wp-login.php、xmlrpc.php、既知の脆弱なパスへの試行を見て、実 IP の復元とプラグインの更新を併せて行います。
関連記事
参考: Fastly – Next-Gen WAF: Start here、Fastly – Next-Gen WAF Glossary、Fastly – Configuring attack thresholds
更新履歴: 2026-11-09 全面改訂（定型文を Fastly Next-Gen WAF の公式ドキュメントに沿った仕組みと導入手順に書き換え、Logging から Blocking への移行手順と WordPress で見るべき点を追加）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。