orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

2019/7/2 Cloudflare障害の根本原因はWAFのルール設定 中国のサイバー攻撃ではない

f:id:orangeitems:20190703111745j:plain

 

Cloudflareの度重なる障害

2019年7月2日 22:52(日本時間)から23:50まで、CDN大手のCloudflare社のサービスが停止し、広範な影響が発生しました。

 

jp.techcrunch.com

アップデート:Cloudflareの共同創設者かつCEOのMatthew Prince氏は、現在起きている状況を説明している。「CPU使用率の大幅な上昇により、プライマリとバックアップのシステムの両方が停止した。これにより、すべてのサービスが影響を受けた。ただ、アタックの兆候は認められない。CPU使用率の上昇の原因となったサービスを停止しており、通信トラフィックは通常レベルに戻った。現在、根本的な原因を解明している」

 

CloudFlare社の公式ページでも述べられています。

 

www.cloudflarestatus.com

HTTP 502エラー

 

解決済み - Cloudflareはこの問題を解決し、サービスは通常の運用を再開しました。

7月2日14時57分UTC

 

更新 - Cloudflareはこの問題に対する修正を実装し、現在結果を監視しています。

説明:

重大な機能停止は、全世界のすべてのCloudflareサービスに影響を与えました。CPUの急激な増加により、プライマリシステムとセカンダリシステムが機能停止しました。CPUスパイクを引き起こしていたプロセスをシャットダウンしました。サービスは30分以内に正常に回復しました。私たちは今起こったことの根本的な原因を調査しています。

7月2日14時50分UTC

 

監視 - Cloudflareはこの問題に対する修正を実装し、現在結果を監視しています。

問題が解決したら、ステータスを更新します。

7月2日14時15分UTC

 

調査中 - Cloudflareはネットワークパフォーマンスの問題を観察しています。Cloudflareのサイトにアクセスしている間に、顧客が502エラーを経験している可能性があります。

この地域のインターネットユーザーへの影響を軽減するために取り組んでいます。

7月2日13時52分UTC

 

なお、昨夜の件は6月24日21時(日本時間)に発生した件とは別件です。

 

gigazine.net

Cloudflareの調査の結果判明したこととは、Verizonが使用するNoctionの「BGP Optimizer」サービスが根本的な原因だということ。BGPとは「インターネットの経路検索」のようなもので、大阪から東京まで移動するときにわざわざ沖縄を経由することがないのと同じように、無駄のないインターネット上の経路を検索する際に使われるものです。今回、BGP OptimizerサービスはVerizonのネットワークがインターネット上で「最適」だと多数のユーザーに表示してしまいました。「Verizonを経由するのが最適な経路なんだ!」と誤表示が行われた結果、Verizonに流れ込むトラフィックは急激に増加しました。

 

原因の深堀り

Cloudflareのブログでさらに原因の深堀りがされていました。

 

blog.cloudflare.com

(日本語訳)

本日 13:42UTCから、Cloudflareでプロキシされたドメインへの訪問者が502エラー( "Bad Gateway")と表示されるという、ネットワーク全体でのグローバルな機能停止が発生しました。

この機能停止の原因は、新しいCloudflare WAF管理ルールの定期的な展開中に、Cloudflare Web Application Firewall(WAF)内に単一の誤った設定のルールを展開したことです。

これらの新しいルールの目的は、攻撃に使用されるインラインJavaScriptのブロックを改善することです。これらのルールは、ログに記録されるだけのシミュレートモードで展開されていました。このモードを利用すれば、顧客のトラフィックは実際にはブロックされないため、誤検知率を測定し、新しいルールが本番環境に展開されたときに問題が発生しないようにすることができます。

残念ながら、これらの規則の1つに正規表現が含まれていたため、世界中のコンピューターでCPUが100%に急上昇しました。この100%CPUスパイクはエンドユーザーに502エラーを引き起こしました。トラフィックは最高で82%減少しました。

このチャートは、当社のPoPの1つにおけるCPUスパイクを示しています(※リンク先を参照ください)。

これまでにない新しいCPU枯渇イベントが発生しました。これまでグローバルなCPUの枯渇を経験したことがないため、これは私たちにとっては斬新なことでした。

私たちは、ネットワーク全体でソフトウェアの導入を継続的に行い、テストスイートを実行するための自動化システムと、インシデントを防ぐために徐々に導入するための手順を実行します。残念ながら、これらのWAFルールは一度に世界中で展開され、今日の機能停止を引き起こしました。

14:02UTCに、何が起こっているのかを理解し、WAF管理ルールセットに対して「グローバルな強制終了」を発行することを決定しました。それは14:09UTCに実施しました。

次に、問題のあるプルリクエストを確認し、特定のルールをロールバックし、変更をテストして正しい修正が100%確実であることを確認し、14:52 UTCでWAF管理ルールセットを再度有効にしました。

私達はこのような事件が私達の顧客にとって非常に苦痛であることを認識します。この場合、当社のテストプロセスは不十分であり、今後このような事件を回避するために、テストおよび展開プロセスを見直して変更を加えています。

 

ということで、Cloudflareが利用しているWAFにて、シミュレーションモードで動かした新しいルールがその機器のCPUを使い果たし、その結果トラフィックが止まってしまったということです。

シミュレーションモードで実際には遮断しないから安全だ、というのは誤った考えだということですね。

 

感想

私もリアルタイムでこの問題を見ていたのですが、Twitterにて中国からのDDoSだ!というツイートがあふれていました。また今日も某まとめサイトでその類の記事が掲載されています。

これは非常に危険なことではないでしょうか。

米中間の緊張はかつてないものですが、だからといって連想的に中国に全て結びつけてしまうのは頂けないと思います。中国も人口14億人近くを抱え、彼らに全て原因を結びつけてしまうのは無理があると思います。

政治情勢はともかく、技術的な問題は技術的な裏を持って判断していきたいものです。

 

なお、今回の原因自体は少し稚拙に感じました。Cloudflare自体が預かっているサービスはかなり広範に渡り、インターネットのかなりの割合を握っています。

サービス変更に関しては、より慎重に行っていただきたいと思います。せめて全体障害を起こさないために、1リージョンで本番実施してから他リージョンに横展開するなど、デプロイの方法は考えるべきでしょうね。