Cloudflareが緊急WAFルールを追加、運営者が確認すべき設定

Cloudflareは10月14日、ウェブフレームワークのリモートコード実行の脆弱性に対する悪用が進んでいるとして、Cloudflare Managed Rulesetに緊急のブロックルールを追加しました。サイト運営者が次に行うべきことは、自サイトを保護している実際のルールセットと設定の確認です。

リリース通知には、影響するフレームワーク名、脆弱なバージョン、ベンダーの修正パッチは記載されていません。そのため、この通知だけでは特定のサイトに脆弱性があるか判断できません。悪用が進んでいるという説明はCloudflareによるもので、個々の読者のサイトが攻撃された証拠ではありません。

どの保護が適用されているかを確認する

通知では、新しい検知をCloudflare Managed Rulesetに追加し、Blockアクションを適用したと説明しています。マネージドルールの公式資料では、このルールセットとFree Managed Rulesetを区別しています。より広い範囲を扱うCloudflare Managed Rulesetは、Pro、Business、Enterpriseプランで利用できます。

ドメインがCloudflareのネームサーバーを使っているだけで、保護が適用されていると判断してはいけません。アカウント管理者に、該当する通信が保護を通過していること、正しいルールセットが配置されていること、実効アクションが変更されていないことを確認してもらってください。

確認したホスト名、ルールセット、設定を書き留めます。漠然とした安心ではなく、別の管理者も確かめられる情報になります。管理付きホスティングを使っている場合は、アプリケーションと通信経路のどの部分を事業者が管理しているか尋ねてください。

Cloudflareの資料では、例外と上書き設定によって、実行するルールや動作が変わることも説明しています。フォームの不具合を直すために作った古い例外が、アプリケーションのセキュリティ確認を広く除外しているなら、再確認する必要があります。

ファイアウォールとアプリケーションを両方確認する

サイトの手前で通信を選別する仕組みと、アプリケーション自体の修正は別の対策です。今回の発表にはインストールすべき修正済みバージョンがないため、実際に使っているソフトウェアの公式勧告を確認してください。Cloudflareが名前を示していないフレームワークを推測して、パッチを選んではいけません。

サイトのCMS、フレームワーク、プラグイン、保守対象の独自アプリケーションを一覧にしておきます。後から勧告が出た際、記憶を頼りに調べ始めるのではなく、記載された製品とバージョンを導入済みの構成要素に照合できます。

セキュリティログにブロックされたリクエストがある場合は、調査用に記録してください。リクエストがブロックされたという事実だけで、侵入が成功したとは判断できません。一方、レポートに目立つ記録がないことも、アプリケーションの完全な評価にはなりません。不正な変更やアクセスの証拠があれば、インシデント対応の責任者に引き継いでください。

通常の公開作業が続けられるかを確かめる

ルールを確認した後は、読者や編集者が普段使う経路を試します。記事の表示、ログイン、下書きの保存、許可されたテストフォームの送信を確認してください。正当な操作がブロックされる場合は、関連するイベント情報を集め、保護設定を変更する前に調査範囲を絞ります。

最初の対処として保護を一括で無効にすることは避けてください。影響するリクエストを特定し、必要最小限の適切な修正を管理者と検討します。

設定とアプリケーションの確認を、サイトの定期保守に加えましょう。誰が担当しているかを説明できる人がいないなら、次のホスティング更新や移行までに責任の所在を明確にしてください。