Cloudflare WAFにHTTPトランザクション全体の検知機能を導入

本日、CloudflareのWebアプリケーションファイアウォール（WAF）に2つの新機能、「トランザクション全体の検知」と「レスポンスルール」を追加します。トランザクション全体の検知では、各HTTPリクエストおよびその対応レスポンスを併せて評価し、脆弱性が悪用された証拠を見つけます。この機能では、「このリクエストは悪意のあるものか」だけでなく、「アプリケーションが処理した結果、何が起きたか」も把握できます。「レスポンスルール」を使用することで、オリジンサーバーから送信されるリクエスト元へのレスポンスを阻止することができます。

こうした保護機能の重要性は、最新モデルが、広く使われているソフトウェアの奥深くに潜む脆弱性を発見していることから、ますます高まっています。フロンティアモデルは、防御側には修正すべき箇所が明確にする一方、攻撃者にとっての新たな侵入経路を発生させるという2面性を持っています。最近の​php2shellの脆弱性は、その影響の大きさと、一般的なソフトウェアコンポーネントの欠陥がインターネット上のさまざまなアプリケーションを危険にさらす可能性があることを示しています。脆弱性を探すAIエージェントは、フィードバックに応じてペイロードを変更し、脆弱性、認証情報、権限を組み合わせながら、非常に執拗に探索を続けます。アプリケーションのレスポンスを解析することで攻撃が成功したかどうかがわかるだけでなく、さらに深く侵入するための情報まで攻撃者に渡ってしまうことがあります。

既知の特徴を持つ攻撃をアプリケーションに到達する前に止めるには、受信リクエストの検査が引き続き欠かせません。ただし、リクエストとオリジンからのレスポンスの両方の情報を見てはじめて明らかになる脅威もあります。不審な入力の後に機密情報を含むレスポンスが返された場合と、同じ入力が拒否されたりエラーになったりした場合とでは、意味が異なります。

これらの新機能により、お客様はCloudflareが管理する保護機能を利用することも、リクエストとレスポンスのプロパティを組み合わせて独自のポリシーを作成することもできます。これは、常時稼働するCloudflareのアプリケーションセキュリティフレームワークを拡張するものです。検知結果はSecurity Analyticsで確認でき、調査に活用できます。この機能を利用する最初のマネージド保護機能は、最近公開されたphp2shellの脆弱性に対応します。

さらに、これらの新機能はFreeプランを含むすべてのCloudflareのお客様向けに一般提供します。

リクエストの検査だけでは不十分

Cloudflare WAFは、マネージドルール、カスタムルール、レート制限によってWebサイトとAPIを保護します。マネージドルールは既知の攻撃手法や脆弱性に対する保護を提供します。一方、カスタムルールでは、IPアドレス、URLパス、ヘッダー、リクエストボディなどのパラメーターを使用した、チーム独自のポリシーの作成が可能です。これらの制御はリクエストの段階で機能し、脆弱性の悪用や不要なトラフィックがオリジンに到達することを防ぎます。

多くの脅威に対しては、この段階で対処するのが適切です。しかし、疑わしいすべてのリクエストを悪意のあるものとして扱う広い範囲に一致するリクエストシグネチャを設定した場合、より多くの攻撃の可能性を捉えられますが、正当なトラフィックにも一致する「誤検知」が起こり、アプリケーションの動作を妨げることがあります。一方で、誤検知を起こさないルールだけを導入すれば、そのリスクは減りますが、攻撃かどうか判断しにくいトラフィックがサーバーに到達する余地が増える可能性があるという、難しい選択が生じます。

その判断に足りなかった証拠を補うのが、レスポンスです。Cloudflareは、レスポンスとその元となったリクエストを関連付け、HTTPトランザクション全体の処理結果を踏まえて検知できるようになりました。

例えば、利用者がファイルをダウンロードできるアプリケーションを考えてみましょう。攻撃者がファイルのパラメーターを操作し、許可されたディレクトリの外にある非公開の設定ファイルを要求します。

GET /download?file=../../config/database.ini

リクエストを検査することで、このディレクトリの走査の試みを認識し、アプリケーションに到達する前にブロックすることができますが、リクエストだけでは、アプリケーションが実際にファイルを公開してしまうかどうかは判断できません。アプリケーション側の挙動としては、要求の拒否、ディレクトリ走査を無視する、エラーを返すなどが考えられます。リクエストがオリジンに到達した場合、次のようなレスポンスが追加の証拠になります：

200 OK
Content-Type: text/plain
[database]
username=app_service
password=EXAMPLE_SECRET

トランザクション全体の検知は、これまで欠けていた判断材料を補います。ファイルへのアクセスの試みと、非公開の設定ファイルに特徴的なレスポンス内容を関連付けられるためです。設定のようなテキスト自体は、ドキュメントやダウンロード可能なサンプルに正当な理由で含まれることがあります。これを走査の試行と組み合わせることで、それぞれを単独で見るよりも、機密データが露出したことを示す強い証拠になります。その後、レスポンスルールによって、オリジンのレスポンスをCloudflare WAFのブロックページとHTTP 403に置き換え、リクエスト元に届く前に遮断できます。機密情報が攻撃者に渡るのを防ぐことで、脆弱性の悪用を実質的に阻止します。

検知と対処を意図的に分離

トランザクション全体の検知は、今年初めに導入した​常時稼働の検知フレームワークを拡張するものです。検知機能がトラフィックを分析してリクエストとレスポンスにメタデータを付与し、その結果に対して何をするかをルールが決定します。

これらの役割を分けることで、お客様はポリシーを設計する前に状況を把握できます。セキュリティチームは、自社のトラフィックでの検知結果を調べ、関係するエンドポイントとシグネチャを把握したうえで、アプリケーションに適した対処を選択できます。リクエストに基づく​Attack Signature Detectionと同様に、検知結果はフィールドに保存されます。これらのフィールドはレスポンスのカスタムルールから参照でき、マネージド検知でもトラフィックのブロックに利用できます。

リクエスト検知用のフィールドに対応する形で、次の新しいフィールドをプラットフォームに追加します：

最初のトランザクション全体の検知機能は、注目度の高い脆弱性の悪用を確認することに重点を置いています。不審な入力と、悪用が成功した可能性を示すレスポンスの兆候を関連付けます。

今後は、データの露出や持ち出しの兆候の検知など、ほかの用途にも対応し、対象範囲を拡大していきます。これは、個々のアプリケーションにとどまらず、インターネット全体にとって重要です。防御側は、単なる探索と実際の影響を示す証拠を区別できるようになります。また、各WAFルールを調整する専任のセキュリティチームがいないお客様にも、データやサービスの露出を検知する機能を届けることができます。

レスポンスに適用するルールを作成

脆弱性が悪用された証拠の検知は、それにリアルタイムで対処できてこそ、最大の効果を発揮します。レスポンスのカスタムルールは、条件に一致するオリジンのレスポンスをリクエスト元に届く前にブロックすることで、トランザクション全体の検知を通信経路上の保護につなげます。ただし、オリジンですでに実行された処理を取り消すことはできません。

セキュリティチームは、リクエストとレスポンスのプロパティに検知結果を組み合わせ、どのレスポンスをブロックするかを決定できるようになりました。ブロックルールの条件に一致すると、CloudflareはオリジンのレスポンスをWAFのブロックページまたはカスタムレスポンスに置き換えます。

レスポンス段階の制御は、Cloudflareダッシュボードの「Security > Security Rules」ページの下部にあり、マネージド保護機能とカスタムルールの両方を利用できます。

Freeプランを含むすべてのプランで、マネージドルールとカスタムルールの両方を提供しています。今後はリクエスト検知と同じ方針を採用し、Freeプランのマネージド検知は​注目度の高い脆弱性を中心とし、有料プランではより幅広い検知を提供していきます。

マネージド検知

すべてのお客様は、Cloudflare Managed Response Firewall Defaultルールセットを通じて、トランザクション検知の全機能による保護を利用できます。このルールセットは、ワンクリックで導入でき、設定も簡単になるよう設計されています。シグネチャに一致すると、マネージド検知機能がレスポンスをブロックし、標準のWAFブロックページを返します。

Cloudflare Managed Response Firewall Defaultの適用範囲を編集し、アプリケーションの一部だけで検知を実行することもできます。例えば、特定のパスを除外したり、特定のパスだけに検知を限定することなどが可能です。有料プランのお客様は、レスポンスのカスタムルールで検知フィールドを使用することで、より細かいポリシーを作成いただけます。

カスタムルール

カスタムのレスポンスルールは、お客様がルールのロジックを全面的に制御できるように設計されています。例えば、認証ゲートウェイがリクエストを内部からのものと判定していない場合に、管理画面が公開されるのを防ぐルールを作成することができます。たとえば：

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

このルールは未認証のリクエストが/adminを対象とし、実際にオリジンが正常なHTMLの管理ページを返した場合のみブロックし、通常の認証失敗、リダイレクト、管理画面に関係しないトラフィックは通過させます。

すべてのお客様が、Log（ログ記録）とBlock（ブロック）のアクションに対応するレスポンスのカスタムルールを、最大3つ作成できます。カスタムのレスポンスルールで利用できるフィールドと関数は、ご契約プランの​カスタムのリクエストルールで利用できるものに対応しています。レスポンスボディに基づくルールの作成には、まだ対応していません。

​Attack Signature Detectionと同様に、有料プランのお客様は、前述のcf.waf.signature.response.*フィールドを通じて攻撃の検知結果も参照できます。これらのフィールドを、ホスト名、URLパス、送信元IP、リクエストヘッダーなどのパラメーターと組み合わせることで、単一のパスに保護を適用したり、アプリケーション固有の条件にポリシーを限定することができます。現在、レスポンスフィールドをすべてのアカウントに順次展開しています。まだ利用できない場合は、担当チームにお問い合わせください。

条件に一致したリクエストを調査

マネージドまたはカスタムのレスポンスルールによって記録/ブロックされたトランザクションに関するイベントは、Security Eventsで確認でき、対応担当者は、どの検知についてもリクエスト全体の状況と、対処を実行した具体的なルールまでさかのぼって調査することができます。

現時点では、リクエストのみを対象とするルールと、トランザクション全体を対象とするルールが、同じ分析ページにまとめて表示されます。Security Eventsでは、レスポンスルールによって生成されたイベントは、Managed RulesまたはCustom Rulesサービスに含まれます。対応するルール一覧のセクションで、特定のルールIDに属するイベントを絞り込んで表示することができます。

今すぐ始めましょう

トランザクション全体の検知は、Cloudflare経由でトラフィックをプロキシするすべてのゾーンで一般提供されています。保護が有効であることを確認するには、Cloudflareダッシュボードの「Security > Security Rules」に移動してください。ポリシーをカスタマイズする場合は、まずSecurity Analyticsでトランザクション全体の検知結果を確認し、アプリケーションに適したレスポンス段階のポリシーを作成してください。