要約

  • 2019年7月2日、機能テストを通過したWAFルールが数秒でCloudflareの世界的エッジへ到達し、特定入力で正規表現の膨大なバックトラックを起こした。HTTP/HTTPS処理プロセスのCPUが枯渇し、利用者には27分間にわたり502が表示された。
  • 防御速度を捨てる必要はない。通常変更と緊急全世界配備を別の権限にし、最悪時の資源上限、段階的な実トラフィック、即時停止、障害対象に依存しない認証・操作面を組み合わせる必要がある。

配備成功が障害の入口になった

変更は小さく見えた。7月2日13時31分（UTC）、ファイアウォール担当者のプルリクエストがレビュー後にマージされた。13時37分にTeamCityのビルドとテストが走り、13時42分にはXSS検出ルールの軽微な変更が自動工程から配備された。

Cloudflareの設定配信システムQuicksilverは、その仕事を失敗しなかった。同社の事後検証では、当時180を超える都市へ平均毎秒約350件の変更を運び、全世界配信の99パーセンタイルは2.29秒だった。地理的な距離を設定の遅れにしないことが、この基盤の価値だった。

WAFにとって世界的な速さは合理的である。実際に悪用されている脆弱性なら、段階を待つ間にも被害は拡大する。CloudflareはSharePointの重大な脆弱性への対応を挙げ、迅速な全世界配備を不可欠な防御機能として説明している。

ところが、この変更は緊急対応ではなかった。通常の手順でも、承認済みルールを直接世界へ送れた。テストは「遮断すべき入力を遮断するか」「通すべき入力を通すか」を確認した。だが「ある一入力がどれほど長くCPUを占有できるか」は確認しなかった。

つまり、レビュー対象は判定内容であり、実行権限の大きさではなかった。ルールの承認は、知らないうちに全世界の共有計算資源を消費する権限まで含んだ。Quicksilverの速さは原因ではない。しかし、観測が追いつく前に未査定の権限を最大範囲へ届けた。

正しく判定しても安全とは限らない

問題の式はPCRE系のバックトラッキング実装で評価された。バックトラック方式は、候補となる一致経路を順に探索する。一般的な式と入力では効率よく答えに着く。しかし、入れ子や曖昧な繰り返しが特定の入力と組み合わさると、試す経路が爆発的に増えうる。

最終結果は正しいままである。「一致しない」という答えに到達するまでが致命的に長い。従って、セキュリティルールには二つの検証軸が要る。意味の軸は判定の妥当性を測り、資源の軸は最悪入力でも仕事量が限られるかを測る。前者だけでは、可用性を守れない。

WAFは大量のHTTP/HTTPS要求が通る経路にあり、何千ものルールを広いトラフィックに適用する。新しい式が一部の要求で指数的な処理時間を使うと、配信処理のCPUは各地で枯渇した。プロキシ、CDN、WAFという主要機能が同時に影響を受けた。

「すべてのサーバーのすべてのCPUが停止した」と要約するのは正確でない。502を生成した前段Webサーバーには利用可能なコアが残っていた。しかし、その先のHTTP/HTTPS処理プロセスへ到達できなかった。外殻は生きていても、サービスを成立させる中核が応答不能だった。

Cloudflare自身が挙げた不備は式だけではない。暴走CPUを抑える保護機構は以前存在したが、性能改善のリファクタリング中に誤って外されていた。式の評価器には複雑度の保証がなく、テスト群にはCPU消費を識別する手段がなく、非緊急ルールにも段階配備がなかった。一人の注意力では代替できない境界が、同時に失われていた。

三分後の警報は、世界配備には遅かった

13時45分、外部からWAFの機能を確かめる合成監視が最初のPagerDuty通知を発した。続いて他サービスのE2E試験、全世界トラフィックの低下、広範な502、各PoPからのCPU枯渇報告が重なった。短報によれば、最悪時にはCloudflare上のトラフィックが82%低下した。この数字を「インターネットの82%」へ膨らませてはいけない。

初動では未知の攻撃も疑われた。14時00分までに、性能データ、strace、エラーログがWAFを原因として指し示し、攻撃説は退けられた。14時02分、関係者は一つのコンポーネントを世界中で無効化する「global terminate」を選択肢にした。

通常のロールバックは遅すぎた。旧ルールへ戻すにはWAF全体のビルドを二度実行する必要があった。そこで個別ルールではなく、WAFそのものの権限を先に世界規模で止めることになった。

操作経路も障害の内側にあった。社内認証はCloudflare Accessを利用し、通常の制御画面、Jira、ビルド環境へ入りにくくなった。普段あまり使わない迂回手順が必要になり、一定期間制御画面を使っていなかったSREの資格情報が安全機能により失効していたことも分かった。

14時07分に全世界停止を実行し、14時09分にはCPUとトラフィックが正常域へ戻った。他の防御機能は継続した。その後、Cloudflareは一都市から有料顧客トラフィックを外し、限定流量で原因確認と修正確認を行った。14時52分にWAFを世界で再開した。

詳細報告は利用不能を27分、初期報告は約30分としている。対立する数字ではない。注目すべきは、配備が秒単位、検知が全世界露出後、緊急停止が27分後、個別修正を伴う再開がさらに後だったことである。与える経路と奪う経路の速度が釣り合っていなかった。

実行言語が権限を制限する

CloudflareはCPU保護の復帰、3,868ルールの点検、性能プロファイルの導入、RE2またはRust系正規表現実装への移行を掲げた。2020年の後続記事は、2019年7月にPCRE系からRE2に着想を得た評価器へ移ったと報告している。

RE2は安全性を第一目標とし、入力長に対して漸近的に線形な照合時間を保証する。メモリーは設定可能な予算内で使い、枯渇時は安全に失敗する。その代わり、後方参照や一般化された先読み・後読みなど、バックトラックなしでは保証できない機能を採用しない。

この制限は単なるライブラリ選定ではない。ルール作者が書ける表現の範囲を狭めることで、レビューの見落としが持てる実行権限も狭める。便利な機能の一部を失う代わりに、一つの式が共有CPUを無制限に請求する可能性を設計段階で削る。

RE2が常に最速という意味ではない。文書は複雑な式の定数コストを認めている。除外機能に依存する既存ルールは書き換えも必要になる。PCRE2にも照合回数、深さ、ヒープの上限があり、バックトラック実装を制限付きで運用する余地はある。ただし、2019年のCloudflare経路でそれらが有効だった証拠はない。

後続の測定は平均CPUの改善を確認しなかった一方、実行時間の95・99パーセンタイルの外れ値が減ったとする。これは失敗ではない。可用性に必要だったのは、通常時の平均を少し下げることより、稀な入力が極端な資源を奪う尾部を削ることだった。

それでも評価器だけでは十分でない。WAFはURLデコード、正規化、トークン化、キャッシュ、複数ルールの組合せも実行する。一個の正規表現が線形でも、前後処理全体の費用は別に測る必要がある。

緊急配備を例外として守る

Cloudflareは、通常変更には段階配備を導入し、進行中の攻撃には世界一斉配備を残す方針を示した。この二分は重要である。速度を全面的に落とせば、WAF本来の価値を壊す。すべてを緊急扱いすれば、今回の権限過大が残る。

通常ルールは、静的な複雑度検査、敵対入力、処理パイプライン全体の資源予算を通る。その後、判定のみを観測するシャドー状態、一拠点、小さな実トラフィック比率、地域という順序で進められる。各段階では命中精度だけでなく、ルール別CPU、末尾遅延、エラー、処理プロセスの到達性を見る。しきい値を越えたら、人の判断を待たず昇格を止める。

緊急経路は観測期間を短くできるが、無条件ではない。対象インシデント、脅威根拠、責任者、期限、資源上限、提案者とは別の停止権者を記録する。緊急性とは統制の消滅ではなく、二つの損失を比較して短時間で選ぶ権限である。

段階の独立性も必要だ。5%の拠点が同じ故障ドメインや同じ測定系を共有すれば、規模を縮めても証拠は得られない。代表的トラフィック、分離容量、対照群、独立テレメトリーがあって初めて、カナリアは権限を広げる根拠になる。

停止はビルド工程から切り離す。一ルールを即時無効化するキーと、コンポーネント全体を止めるキーを階層化する。定期演習では、通常のダッシュボード、認証、ビルドが同時に使えない前提を置く。便利な正常系だけで成功する停止機能は、危機時の能力を証明しない。

操作面は対象の外に残す

自社サービスへの依存は障害を始めた原因ではないが、復旧の負担を増やした。顧客のダッシュボードとAPIも同じエッジを通り、問題が最大のときに顧客側の操作余地も狭まった。

独立した操作面は第二の巨大ネットワークである必要はない。障害状況の公開、緊急認証、世界停止、最低限の設定変更、証拠取得、顧客が被害を減らすための操作という小さな生存面でよい。分離容量と別経路を持ち、資格情報を訓練で生かし続ける。平時に使わない迂回路も本番構成の一部である。

Heng LuのRunning-Code Primacyを当てると、承認票、成功したビルド、文書化された撤回手順は、現実を調整する資料にすぎない。稼働中のコードが共有CPUを使い切り、自分の操作経路まで閉じたなら、手続き上の承認は安全性を作らない。

技術上の所有と実際の支配も違う。停止コマンドを保有していても、その認証、担当者資格情報、コンソール、ビルドが障害対象に依存すれば、必要な瞬間の支配力は弱い。権限は平時に一覧化されているかではなく、危機時に実行できるかで測るべきである。

証拠の限界

内部時系列、構造、原因、改善策の中心資料はCloudflare自身の公開情報である。詳細な説明は分析価値が高いが、独立監査ではない。影響を受けた顧客、ドメイン、失敗要求、経済損失の完全な外部集計は確認できない。

Cloudflareは攻撃ではないと明記した。本稿も敵対者が意図して入力を作成・投入したとは主張しない。Quicksilverは式を壊さず、CPU保護を外してもいない。通常承認が全能力を呼び出せたため、結果の範囲を拡大した。

2020年の記事は評価器移行と末尾性能の改善を裏づけるが、2019年に掲げた全対策がその後ずっと完全だったことまでは証明しない。この事例から導けるのは統制の原則であり、特定企業や方式が将来無故障だという保証ではない。

情報源