Cloudflareが2026年10月21日、WAFに「フルトランザクション検知」と「レスポンスルール」の2機能を加えたと公式ブログで発表しました。リクエストだけでなく、サーバーが返す応答まで見て攻撃を止められる仕組みで、自分のサイトをCloudflareに置いている人や、社内サイトのWAFを預かる情シスに関係します。
WAFが応答も見るようになった、その結論
結論から言うと、Cloudflare WAFは「怪しい入力が来たか」だけでなく「攻撃が成功した形跡が応答に出ているか」まで見られるようになり、Freeプランを含むすべての顧客が使えます。公式ブログには、Freeプランを含むすべてのCloudflare顧客に一般提供（GA）されると書かれています。
製品の全体像は、Cloudflare WAF（Cloudflare公式）と、WAFのドキュメント（Cloudflare公式）で確認できます。
| 機能 | 何をするか |
|---|---|
| フルトランザクション検知 | HTTPリクエストとその応答をあわせて評価し、攻撃が成功した証拠を探す |
| レスポンスルール | 条件に合った原点サーバー（オリジン）の応答を、リクエスト元に届く前にブロックする |
WAFのリクエスト検査だけでは足りなかった理由
従来のリクエスト検査では、不審な入力が実際に成功したのか、情報が漏れたのかは分かりません。広いシグネチャで厳しく見れば誤検知が増えて正常な通信を壊す恐れがあり、誤検知が出ないルールだけにすれば取りこぼしが増えます。
応答を判断材料に足すと、この板挟みを和らげられる、というのが公式の説明です。
パストラバーサルを例にしたWAFの動き
公式ブログの例は、ファイルのダウンロード機能に対するパストラバーサル攻撃です。file パラメータを操作して設定ファイルを取りに来る手口で、次のように動きます。
- リクエストが怪しいかどうかを見る
- 応答が設定ファイルらしい内容かどうかを見る
- 両方がそろったとき、応答をCloudflareのWAFブロックページ（HTTP 403）に差し替える
こうして、秘密情報が攻撃者に届く前に止めます。入口で疑わしいものを全部止めるのではなく、「出口で中身を見て止める」二段構えです。レストランにたとえるなら、受付で怪しい客を全員断るのではなく、厨房から出る皿の中身を最後に確認する係が増えた、という感じです。
最初のWAF保護はphp2shell脆弱性への対応
最初のマネージド保護は、最近公表されたphp2shell脆弱性への対応です。公式ブログは、共通ソフトの欠陥がネット全体のアプリを危険にする例として、この脆弱性を挙げています。
最初のフルトランザクション検知は、影響の大きい既知の脆弱性について「攻撃が成功した証拠」を確認することに絞られています。データの露出や持ち出しの検知は、今後追加する予定とされています。
設定の入口とWAFで使う検知フィールド
設定場所は、Cloudflareダッシュボードの「Security」の「Security Rules」です。レスポンス段階の制御は、同じページの下のほうに表示されます。イベントは「Security Events」で見られます。
検知と対処は分けて設計されています。検知がリクエストと応答にメタデータを付け、ルールがその結果で動作を決める形です。検知の結果は「Security Analytics」で確認でき、ポリシーをカスタマイズしたいときは、先に自分のトラフィックで検知結果を見てからレスポンス段階のルールを作る進め方が勧められています。
新しく使えるフィールドは次の3つです。
| フィールド | 内容 |
|---|---|
cf.waf.signature.response.confidence |
一致したシグネチャの信頼度 |
cf.waf.signature.response.categories |
分類 |
cf.waf.signature.response.ref |
シグネチャ参照ID（最大10個） |
プランごとのWAFでできること
| 項目 | 内容 |
|---|---|
| マネージドルールセット | 「Cloudflare Managed Response Firewall Default」。ワンクリックで展開でき、一致すると応答をブロックして標準のWAFブロックページを返す。対象はパスなどで絞り込める |
| カスタムのレスポンスルール | 全顧客が最大3つまで作れる。アクションはLogまたはBlock |
| 有料プラン | 検知フィールドをレスポンスルールで使え、より細かく制御できる |
現時点では、全顧客が「Cloudflare Managed Response Firewall Default」で一連のトランザクション検知を使えます。今後は、リクエスト検知と同じ方針で、Freeプランのマネージド検知は影響の大きい脆弱性に絞り、有料プランはより豊富な検知カタログを使える形にしていく、と書かれています。
使う前に知っておきたいWAFの制約
- レスポンスルールは、オリジンがすでに実行した処理を取り消せません。応答は止められても、サーバー側で起きたことは元に戻らないので、脆弱なソフトの更新は引き続き必要です
- 応答の本文（ボディ）を検査するルールは、まだ使えません
cf.waf.signature.response.*のフィールドは、全アカウントに順次展開中です。使えない場合は、Cloudflareのアカウント担当に連絡するよう案内されています- 日本での提供状況の違いや、Freeプランで使えるマネージド検知がカバーする脆弱性の一覧は、公式ブログに記載がありません
WAFのレスポンスルールで、まずやっておきたいこと
おすすめの順に並べます。
- ダッシュボードの「Security Rules」で、レスポンス段階の表示が出ているかを確認する: 順次展開中なので、まず自分のアカウントで使えるかを見ます
- ルールをカスタマイズする前に、Security Analyticsで自分のトラフィックの検知結果を見る: Defaultルールセットは既定で全リクエストに対して動作します。誤検知が心配なら、対象をパスなどで絞れます
- カスタムのレスポンスルールは、まずアクションをLogにする: 誤検知の様子を見てから、必要な範囲でBlockに切り替えます。対象はパスで絞ると影響を小さくできます
- オリジンのソフトの更新は、これまでどおり進める: 応答の遮断は最後の砦で、脆弱性そのものを直すものではありません
現場で起きそうなこと
「WAFを入れたから、もう大丈夫」と安心して、オリジンの更新が後回しになる。運用では、ありがちな落とし穴です。応答を見るWAFは心強い仕組みですが、公式も、オリジンがすでに実行した処理は取り消せないと説明しています。WAFは更新の代わりではなく、更新までの時間を稼ぐ道具と考えておくと、運用で迷いません。
ほかのITの話題は、技術ネタの記事一覧からどうぞ。
ITもごはんも、腹八分目が長続きのコツ！
コメント