HTTP/2 Zero-Day 漏洞导致破纪录的 DDoS 攻击

今天早些时候，Cloudflare 与 Google 和 Amazon AWS 一起披露了一个名为 “HTTP/2 Rapid Reset” 攻击的新型 zero-day 漏洞的存在。此攻击利用 HTTP/2 协议中的弱点来生成巨大的超容量分布式拒绝服务 (DDoS) 攻击。近几个月来，Cloudflare 缓解了一系列攻击，其中一次攻击规模是我们之前观察到的任何攻击的三倍，每秒超过 2.01 亿个请求 (rps)。自 2023 年 8 月底以来，Cloudflare 已缓解了超过 1,100 起 RPS 超过 1000 万的其他攻击，其中 184 起攻击超过了我们之前 7100 万 RPS 的 DDoS 记录。

这个 zero-day 漏洞为威胁行为者提供了一个重要的新工具，即漏洞中的瑞士军刀，能够以前所未有的规模利用和攻击受害者。虽然这些攻击有时非常复杂且难以应对，但正是因为它们，Cloudflare 才有机会开发专用技术来缓解 zero-day 漏洞的影响。

如果您使用 Cloudflare 进行 HTTP DDoS 缓解，那么您已经受到保护。下面，我们将提供有关此漏洞的更多信息，以及如何确保自身安全的资源和建议。

解构攻击：每位 CSO 需要了解的内容

2023 年 8 月下旬，我们的 Cloudflare 团队注意到一个新的 zero-day 漏洞，该漏洞由未知威胁行为者开发，它所利用的标准 HTTP/2 协议是一种基本协议，对互联网和所有网站的正常运作至关重要。这种新型 zero-day 漏洞攻击被称为“Rapid Reset”，它利用 HTTP/2 的流取消功能，反复发送请求并立即取消该请求。  

透过大规模自动执行这种简单的“请求、取消、请求、取消”模式，威胁行为者能够建立拒绝服务并摧毁任何运行 HTTP/2 标准实施的服务器或应用程序。此外，关于这起破纪录的攻击，还有一个重要事项需要注意，它涉及一个中等规模的僵尸网路，由大约 20,000 台机器组成。 Cloudflare 会定期检测比这大几个数量级的僵尸网路——包括数十万甚至数百万台机器。对于一个相对较小的僵尸网络来说，输出如此大量的请求，有可能使几乎所有支持 HTTP/2 的服务器或应用程序瘫痪，这凸显了此漏洞对未受保护的网络的威胁有多大。

威胁行为者利用僵尸网络和 HTTP/2 漏洞，以前所未有的速度放大请求。因此，我们的 Cloudflare 团队经历了一些间歇性的边缘不稳定。虽然我们的系统能够缓解绝大多数传入攻击，但流量使我们网络中的某些组件过载，从而影响了少数客户的性能并出现间歇性 4xx 和 5xx 错误——所有这些都很快得到了解决。

在我们成功缓解了这些问题并阻止了所有客户的潜在攻击后，我们的团队立即启动了负责任的披露流程。在向公众公布这一漏洞之前，我们与业界同行进行了对话，探讨如何合作才能帮助我们完成使命，并保护依赖我们网络的大部分互联网用户的安全。

我们在另一篇博文中详细介绍了这次攻击的技术细节：HTTP/2 Rapid Reset：解构破纪录的攻击。

Cloudflare 和业界是如何遏止此次攻击的？

没有所谓的“完美披露”。阻止攻击和响应新出现的事件需要组织和安全团队以假定泄露的心态生活——因为总会有另一个 zero-day 漏洞、演变而来的新威胁行为者群体，以及前所未见的新型攻击和技术。

这种“假定泄露”的心态是信息共享和确保在这种情况下互联网保持安全的关键基础。在 Cloudflare 经历并缓解这些攻击的同时，我们还与行业合作伙伴合作，以确保整个行业能够抵御这种攻击。  

在缓解此攻击的过程中，我们的 Cloudflare 团队开发并专门构建了新技术来阻止这些 DDoS 攻击，并进一步改进我们针对此攻击和未来其他大规模攻击的缓解措施。这些努力显著提高了我们的整体缓解能力和弹性。如果您正在使用 Cloudflare，我们相信您会受到保护。

我们的团队还提醒正在开发补丁的 Web 服务器软件合作伙伴，以确保此漏洞不会被利用——请查看他们的网站以获取更多信息。

披露绝不是一劳永逸的。Cloudflare 的命脉是确保更好的互联网，这源于诸如此类的实例。我们有机会与行业合作伙伴和政府合作，确保互联网不会受到广泛影响，因此，我们正在尽自己的一份力量来提高每个组织的网络弹性，无论其规模或垂直领域如何。

要进一步了解缓解策略和后续修补措施，请登记参加我们的网络研讨会。

HTTP/2 Rapid Reset 和这些针对 Cloudflare 的破纪录攻击的起源是什么？

Cloudflare 是最先受到这些攻击的公司之一，这似乎有些奇怪。为什么威胁行为者要攻击一家拥有世界上最强大的 DDoS 攻击防御系统的公司？  

现实情况是，Cloudflare 经常在攻击转向更脆弱的目标之前就发现了它们。威胁行为者需要先开发和测试他们的工具，然后再将其实际部署。拥有破纪录攻击方法的威胁行为者可能会难以测试和了解它们的规模和有效性，因为他们没有基础结构来承担他们发起的攻击。由于我们分享网络性能的透明度，以及他们可以从我们的公开性能图表中收集到攻击测量结果，该威胁行为者很可能通过攻击我们来了解该漏洞的功能。

但这种测试以及尽早发现攻击的能力可以帮助我们开发针对攻击的缓解措施，从而使我们的客户和整个行业受益。

各位首席安全官的应对措施：您应该怎么做？

我担任首席安全官已有 20 多年，经历过无数次类似的披露和公告。但无论是 Log4J、Solarwinds、EternalBlue WannaCry/NotPetya、Heartbleed，还是 Shellshock，所有这些安全事件都有一个共同点。巨大的爆炸波及全球，并有可能彻底颠覆我所领导的任何组织——无论行业或规模如何。

其中许多是我们可能无法控制的攻击或漏洞。但无论问题的起因是否在我的控制范围之内，我所领导的任何成功计划与不利计划的区别在于，当识别这样的 zero-day 漏洞和利用时，我们能够做出回应。    

虽然我希望我可以说这次的 Rapid Reset 可能会有所不同，但事实并非如此。我呼吁所有的首席安全官，无论您是像我一样经历了数十年的安全事件，还是刚刚上任，现在都需要确保您受到保护，并支持您的网络事件响应团队 。

直到今天，我们一直对这些信息进行限制，以便让尽可能多的安全供应商有机会做出反应。不过，在某些时候，公开披露这样的 zero-day 威胁才是负责任的做法。今天就是公开的日子。这意味着今天之后，威胁行为者将在很大程度上意识到 HTTP/2 漏洞；攻击者将能够轻松利用这一漏洞，防御者与攻击者之间的竞赛也将无可避免——是先得到修补还是先被利用。组织应假定系统将受到攻击，并采取主动措施来进行保障。

对我来说，这让人想起像 Log4J 这样的漏洞，因为每天都会出现许多变体，并将在未来几周、几个月和几年内继续发挥作用。随着越来越多的研究人员和威胁行为者对该漏洞进行实验，我们可能会发现具有更短利用周期的不同变体，其中包含更高级的绕过方法。  

就像 Log4J 一样，管理此类事件并不像“运行补丁，大功告成”那么简单。您需要将事件管理、修补和发展安全保护转变为持续的流程，因为针对每个漏洞变体的修补程序可以降低您的风险，但并不能消除风险。

我无意危言耸听，但我要直截了当地说：你们必须认真对待这件事。将此视为一个完全活动的事件，以确保您的组织不会发生任何事情。

新变革标准的建议

虽然安全事件各不相同，但还是可以从中吸取教训。首席安全官们，以下是我提出的必须立即实施的建议。不仅是针对此次漏洞，今后几年也是如此：

• 了解您的外部网络和合作伙伴网络的连接情况，利用以下缓解措施修复任何面向互联网的系统。
• 了解您现有的安全保护措施以及保护、检测和应对攻击的能力，并立即修复网络中存在的任何问题。
• 确保 DDoS 防护位于数据中心之外，因为如果流量进入数据中心，将很难缓解 DDoS 攻击。
• 确保您拥有针对应用程序（第 7 层）的 DDoS 防护，并确保您拥有 Web 应用程序防火墙。此外，作为最佳实践，确保您拥有针对 DNS、网络流量（第 3 层）和 API 防火墙的完整 DDoS 防护。
• 确保在所有面向互联网的 Web 服务器上都部署了 Web 服务器和操作系统补丁。此外，请确保所有自动化（例如 Terraform 构建和映像）都已完全修补，以便旧版本的 Web 服务器不会意外地通过安全映像部署到生产环境中。
• 在万不得已的情况下，可以考虑关闭 HTTP/2 和 HTTP/3（可能也容易受到攻击）以减轻威胁。这只是最后的手段，因为如果降级到 HTTP/1.1，会出现严重的性能问题。
• 考虑在周边使用基于云的辅助 DDoS L7 提供商以提高弹性。

Cloudflare 的使命是帮助构建更好的互联网。如果您担心当前的 DDoS 防护状态，我们非常乐意免费为您提供我们的 DDoS 功能和弹性，以缓解任何成功的 DDoS 攻击尝试。我们知道您面临的压力，因为我们在过去 30 天里抵御了这些攻击，并使我们本已一流的系统变得更好。

如果您有兴趣了解更多信息，请观看我们的网络研讨会，了解 zero-day 的详细信息以及应对方式。如果您不确定自己是否受到保护或想了解如何受到保护，请联系我们。我们还在另一篇博文中详细介绍了这次攻击的更多技术细节：HTTP/2 Rapid Reset：解构破纪录的攻击。最后，如果您是攻击目标或需要立即保护，请联系您当地的 Cloudflare 代表或访问 https://www.cloudflare.com/zh-cn/under-attack-hotline/。

HTTP/2 zero-day脆弱性により史上最大のDDoS攻撃が発生

本日未明、Cloudflareは、GoogleおよびAmazon AWSとともに、「HTTP/2 Rapid Reset」攻撃と名付けられた新種の脆弱性（zero-day ）の存在を公表しました。この攻撃は、HTTP/2プロトコルの弱点を悪用し、巨大で超ボリューメトリックな分散サービス妨害（DDoS）攻撃を発生させます。Cloudflareはここ数カ月間、こうした嵐のような攻撃の軽減に取り組んでいました。その中には 、1秒間に2億100万リクエスト（rps）を超える、弊社がこれまでに観測した最大の攻撃の3倍ほどの規模となる攻撃も含まれています。2023年8月末以降、Cloudflareはその他の1,000万rpsを超える攻撃を1,100回以上軽減しましたが、この間DDoSの最大記録である7,100万rpsを超える攻撃が184回にも及びました。

攻撃を受けていますか？それとも、保護を追加したいですか？ ヘルプを受けるには、こちらをクリックしてください。

このzero-dayは、脅威アクターたちに、脆弱性の解析ツールであるスイスアーミーナイフを悪用して被害者を攻撃することができる、今までにない全く新しいツールを提供したのです。 これらの攻撃に対する対処は複雑で困難を伴うものでしたが、このような攻撃は、Cloudflareにとって、zero-dayの脆弱性の影響を軽減する特別な技術開発の機会となりました。

Cloudflareを使用しているのであれば、HTTPのDDoSは軽減され、保護されています。 以下、この脆弱性に関する詳細情報と、安全確保のためのリソースと推奨事項を掲載します。

攻撃のデコンストラクション（脱構築）：すべてのCSOが知るべきこと

2023年8月下旬、弊社のチーム（Cloudflare zero-day）は、Standard HTTP/2プロトコル（インターネットとすべてのWebサイトが機能するために重要な基本プロトコル）を悪用する、未知の脅威行為者によって開発された新たな脆弱性を観測しました。Rapid Resetと名付けられたこの新しいzero-day 脆弱性攻撃は、HTTP/2のStreamキャンセル機能を利用し、リクエストを送信して即座にキャンセルすることを何度も繰り返すものです。  

この単純な「リクエスト、キャンセル、リクエスト、キャンセル」パターンを大規模に自動化することで、脅威アクターはサービス拒否を作り出し、HTTP/2の実装（Standard ）を実行しているサーバーやアプリケーションを停止させることができるのです。 さらに、この記録的な攻撃について注目すべき重要な点は、およそ20,000台のマシンで構成される控えめな規模のボットネットが関与していたことです。 Cloudflareは、数十万台から数百万台のマシンで構成される、これよりも桁違いに大規模なボットネットを定期的に検出しています。 比較的小規模なボットネットが、HTTP/2をサポートするほぼすべてのサーバーやアプリケーションを無力化してしまうほどの可能性を秘め、これほど大量のリクエストを出力するという事実は、この脆弱性が無防備なネットワークにとっていかに脅威となるかを強調しています。

脅威アクターはHTTP/2の脆弱性とボットネットを併用し、これまでにない速度でリクエストを増幅させました。 その結果、Cloudflareのチームは、断続的にエッジが不安定になるという体験をしました。 当社のシステムは圧倒的多数の着信攻撃を軽減することができましたが、その量はネットワーク内のいくつかのコンポーネントに過負荷をかけ、断続的に4xxおよび5xxエラーが発生し、少数のお客様のパフォーマンスに影響を与えました。

これらの問題を軽減し、すべての顧客に対する潜在的な攻撃を停止させることに成功した後、弊社のチームは直ちに責任ある情報開示プロセスを開始しました。 この脆弱性を一般に公表する前に、どのように弊社のミッションを前進させ、弊社のネットワークに依存しているインターネットの大部分を保護するために協力できるかについて、同業者と話し合いました。

この攻撃の技術的な詳細については、別のブログ記事で取り上げています。 HTTP/2 Rapid Reset: 記録的な攻撃のデコンストラクション（脱構築）。

Cloudflareと業界はこの攻撃をどのように阻止しているのでしょうか？

「完全な情報開示」というものは存在しません。 攻撃を阻止し、新たなインシデントに対応するためには、組織やセキュリティチームが常に侵害を想定したマインドセットが必要です。なぜなら、zero-day 、新たな進化を遂げる脅威アクターグループ、今までにはないような斬新な攻撃やテクニックが常に存在するからです。

この「違反を想定」するマインドセットは、情報共有のための重要な基盤であり、インターネットの安全性を確保するものとなります。 Cloudflareは、このような攻撃を経験・軽減しつつ、業界全体がこの攻撃に耐えられることを保証するために、業界のパートナーと協力します。  

この攻撃を軽減する過程で、弊社のCloudflareチームは、このような DDoS攻撃を阻止するための新技術を開発・構築し、この攻撃のみならず今後発生するその他の大規模な攻撃に対しても、弊社独自の軽減策をさらに改善してきました。 こうした取り組みにより、全体的な軽減能力と回復力が大幅に向上した。 Cloudflareを使用している場合、保護されていると確信しています。

また、この脆弱性を悪用されないようにするためのパッチを開発しているWebサーバーソフトウェアパートナーにも警告を発しました。 — 詳細は同社のWebサイトを参照してください。

情報開示は1回で終わりません。 Cloudflareの生命線は、より良いインターネットを確保することであり、それはこのような事例から生じています。 インターネットに広範な影響が及ばないよう、業界パートナーや政府と協力する機会があれば、規模や業種を問わず、あらゆる組織のサイバー耐性を向上させる弊社の役割を果たします。

パッチを適用する際の緩和策や次のステップに関する理解を深めるために、弊社のウェビナーにご参加ください 。

HTTP/2 Rapid Resetと、Cloudflare に対するこれらの記録的な攻撃のオリジンは何ですか？

Cloudflareが、こうした攻撃を最初に観測した企業のひとつであることは奇妙に思えるかもしれません。 DDoS攻撃に対して世界で最も強固な防御を持つ企業を、なぜ脅威アクターが攻撃するのでしょうか？  

実際、Cloudflareは、攻撃がより脆弱なターゲットに向けられる前に、時折攻撃を観測します。 脅威アクターは、ツールを実際の攻撃のためにデプロイする前に、ツールを開発し、テストする必要があります。 記録的な攻撃手法を持つ脅威アクターにとって、その攻撃手法がどれほど大規模で効果的なものかをテストし、把握することは極めて困難といえるでしょう。その攻撃を受け止めるだけのインフラストラクチャがないからです。弊社はネットワークパフォーマンスに関する透明性を共有し、公開されているパフォーマンスチャートから攻撃の測定値を得ることがでるため、この脅威アクターは悪用能力を把握するために弊社をターゲットにしたと考えられます。

しかしこのテストと、攻撃の早期発見能力は、弊社の攻撃緩和策の開発に役立ち、顧客と業界全体の両方に利益をもたらすことになるのです。

CSOからCSOへ：何をすべきですか？

私は20年以上CSOを務めており、このような情報開示や発表を数え切れないほど経験しました。しかし 、 Log4J で あれ、 Solarwindsであれ、 EternalBlue WannaCry/NotPetyaであれ、Heartbleed であれ、 Shellshock であれ、セキュリティインシデントには共通点があります。凄まじい爆発が世界中に波及し、私が率いたあらゆる組織を完全に混乱させるおそれがあるのです—業界や規模に関わりなくです。

これらの多くは、私たちが制御できなかったかもしれない攻撃や脆弱性だったのです。 しかし、この問題が私の制御できるところから生じたか否かにかかわらず、私が主導して成功したイニシアチブを、私たちに有利に傾かなかった多層防御と区別したのは、このようなzero-day脆弱性やエクスプロイトが特定されたときに対応する能力だったのです。    

今回のRapid Resetは違うと言いたいところですが、そうではありません。 私はすべてのCSOにこう呼びかけています—私のように何十年もセキュリティインシデントを経験してきた人であっても、今日が勤務初日という人であっても、サイバーインシデント対応チームを立ち上げ、確実な保護対策を取るべきです—今こそその時なのです。

できるだけ多くのセキュリティベンダーに対して対応する機会を与えるため、今日まで情報を制限してきました。 しかし、ある時点で、このようなzero-day脅威を公開する責任が生じました。 今日がその日なのです。 つまり、今日以降、脅威アクターはHTTP/2の脆弱性をかなりの部分把握することになるので、その悪用は必然的に容易になり、防御側と攻撃側の間の競争—パッチを当てるのが先か、悪用するのが先かが始まるのです。 組織は、システムがテストされることを想定し、確実に保護するための事前対策を講じるべきなのです。

これはLog4Jのような脆弱性を思い出させます。多くの亜種が日々出現し、そして今後数週間、数カ月、数年と出現し続けることでしょう。 より多くのリサーチャーや脅威アクターがこの脆弱性を試すようになれば、さらに高度なバイパスを含む、より短い悪用サイクルを持つ別の亜種が見つかるかもしれません。  

Log4Jと同様、このようなインシデントの管理は「パッチを当てて完了」というような単純なものではありません。 インシデント管理、パッチ適用、セキュリティ保護の進化を、継続的なプロセスに変える必要があるのです。なぜなら、脆弱性の亜種ごとにパッチを適用してリスクを軽減させることはできても、解消されるわけではないからです。

警鐘を鳴らすつもりはないですが、単刀直入に言います。これを真剣に受け止めてください。 組織に何も起こらないように、必ずアクティブなインシデントとして扱ってください。

新たな変更基準のための推奨事項

セキュリティー上の出来事は、一つとして同じものはなく、またそれらから多くのことが学べます。 CSOの皆さん、すぐに実行に移さなければならない推奨事項をここでお伝えします。 今回だけでなく、この先何年間にも渡って実行してください。

• 外部ネットワークおよびパートナーネットワークの外部接続を理解し、インターネットに接続しているシステムは次の緩和策を実施してください。
• 既存のセキュリティ保護と、保護すべき能力を理解し、攻撃を検出し、対応し、ネットワークに問題があれば直ちに修復します。
• DDoS攻撃対策が、必ずデータセンターの外にあるようにしてください。トラフィックがデータセンターに到達してしまうと、DDoS攻撃を軽減することが難しくなるからです。
• DDoS攻撃対策アプリケーション（レイヤー7）、およびWebアプリケーションファイアウォールを確保してください。 さらに、ベストプラクティスとして、DNS、ネットワークTraffic（レイヤー3）、APIファイアウォールに対する完全なDDoS攻撃対策を確実に保持してください。
• Webサーバーおよびオペレーティングシステムのパッチが、インターネットに接続しているWebサーバーに導入されているようにします。 また、Terraformのビルドやイメージのようなすべての自動化が完全にパッチされていることを確認し、旧バージョンのWebサーバが誤ってセキュアなイメージ上でプロダクションにデプロイされないようにします。
• 最後の手段として、脅威を軽減するためにHTTP/2とHTTP/3（これも脆弱である可能性が高い）をオフにすることを検討してください。  なぜなら、HTTP/1.1にダウングレードすると、パフォーマンスに大きな問題が生じるからです。
• レジリエンスを持たせるために、セカンダリでクラウドベースの DDoS L7 プロバイダーをペリメータ―（境界）で検討してください。

Cloudflareのミッションは、より良いインターネットの構築を支援することです。 DDoS攻撃対策の現状に不安を感じるお客様には、DDoS攻撃を軽減するために、弊社のDDoS能力とレジリエンスを無料で提供させていただきます。この30日間、弊社はこのような攻撃と戦いながら、クラス最高のシステムをさらに向上させてきました。

さらに詳しくお知りになりたい方は、zero-dayの詳細と対応方法に関するウェビナーをご覧ください。保護されているかどうか不明な場合、またはどのように保護されるのか知りたい場合は、お問い合わせください。また、この攻撃の技術的な詳細につきましては、別のブログ記事HTTP/2 Rapid Reset: 記録的な攻撃を脱構築するで詳しく解説しております。最後に、攻撃の標的にされている場合、または早急な保護が必要な場合は、お近くのCloudflare 担当者にお問い合わせいただくか、 https://www.cloudflare.com/ja-jp/under-attack-hotline/をご覧ください。

HTTP/2 Rapid Reset: cómo desarmamos el ataque sin precedentes

El 25 de agosto de 2023, empezamos a observar algunos ataques de inundación HTTP inusualmente voluminosos que afectaban a muchos de nuestros clientes. Nuestro sistema DDoS automatizado detectó y mitigó estos ataques. Sin embargo, no pasó mucho tiempo antes de que empezaran a alcanzar tamaños sin precedentes, hasta alcanzar finalmente un pico de 201 millones de solicitudes por segundo, casi el triple que el mayor ataque registrado hasta ese momento.

Lo más inquietante es que el atacante fuera capaz de generar semejante ataque con una botnet de solo 20 000 máquinas. Hoy en día existen botnets formadas por cientos de miles o millones de máquinas. La web suele recibir solo entre 1000 y 3000 millones de solicitudes por segundo, por eso no parece imposible que utilizando este método se pudiera concentrar el volumen de solicitudes de toda una web en un pequeño número de objetivos.

Detección y mitigación

Se trataba de un vector de ataque novedoso a una escala sin precedentes, pero las soluciones de protección de Cloudflare pudieron mitigar en gran medida los efectos más graves de los ataques. Si bien Continue reading

HTTP/2 Zero-day 취약성은 이전에 없던 기록적인 DDoS 공격으로 이어집니다

오늘 Cloudflare는 Google, Amazon AWS와 함께 “HTTP/2 Rapid Reset” 공격이라는 새로운 zero-day 취약성의 존재를 공개했습니다. 이 공격은 HTTP/2 프로토콜의 약점을 악용하여 거대 하이퍼 볼류메트릭 분산 서비스 거부 (DDoS) 공격을 생성합니다. Cloudflare는 최근 몇 달간 이런 빗발치는 공격을 완화하였는데, 그중에는 이전에 우리가 목격한 것보다 규모가 3배 큰, 초당 2억 100만 요청(rps)을 넘어서는 공격도 있었습니다. Cloudflare는 2023년 8월 말부터 1,000만 rps가 넘는 기타 공격 1,100건 이상을 완화하였으며, 184건은 이전 DDoS 기록인 7,100만 rps보다도 큰 공격이었습니다.

위협 행위자들은 이러한 zero-day를 통해 취약성이라는 맥가이버 칼에 치명적인 도구를 새로 더하여 이전에 본 적 없는 규모로 피해자를 공격할 수 있게 되었습니다. 때로는 복잡하고 힘든 싸움이었지만, Cloudflare는 이러한 공격을 통해 zero-day 취약성의 영향을 완화하기 위한 기술을 개발할 수 있었습니다.

HTTP DDoS 완화를 위해 Cloudflare를 이용 중이시라면, 여러분은 보호받고 있습니다. 이 취약성에 대해 아래에서 더 알아보고, 스스로를 보호하기 위해 할 수 있는 리소스와 권장 사항을 확인해 보세요.

공격 분석: 모든 CSO가 알아야 할 사항

2023년 8월 말, Cloudflare 팀은 알 수 없는 위협 행위자가 개발한 새로운 zero-day 취약성을 발견하였습니다. 이 취약성은 인터넷 및 모든 웹 사이트의 작동에 필수적인 표준 HTTP/2 프로토콜을 악용합니다. Rapid Reset이라는 별명이 붙은 이 새로운 zero-day 취약성 공격은 요청 전송 후 즉각적 취소를 반복함으로써 HTTP/2 Continue reading

Alle Einzelheiten über HTTP/2 Rapid Reset

Am 25. August 2023 begannen wir, ungewöhnlich große HTTP-Angriffe auf viele unserer Kunden zu bemerken. Diese Angriffe wurden von unserem automatischen DDoS-System erkannt und abgewehrt. Es dauerte jedoch nicht lange, bis sie rekordverdächtige Ausmaße annahmen und schließlich einen Spitzenwert von knapp über 201 Millionen Anfragen pro Sekunde erreichten. Damit waren sie fast dreimal so groß wie der bis zu diesem Zeitpunkt größte Angriff, den wir jemals verzeichnet hatten.

Besorgniserregend ist die Tatsache, dass der Angreifer in der Lage war, einen solchen Angriff mit einem Botnetz von lediglich 20.000 Rechnern durchzuführen. Es gibt heute Botnetze, die aus Hunderttausenden oder Millionen von Rechnern bestehen. Bedenkt man, dass das gesamte Web in der Regel nur zwischen 1 bis 3 Milliarden Anfragen pro Sekunde verzeichnet, ist es nicht unvorstellbar, dass sich mit dieser Methode quasi die Anzahl aller Anfragen im Internet auf eine kleine Reihe von Zielen konzentrieren ließe.

Erkennen und Abwehren

Dies war ein neuartiger Angriffsvektor in einem noch nie dagewesenen Ausmaß, aber die bestehenden Schutzmechanismen von Cloudflare konnten die Wucht der Angriffe weitgehend bewältigen. Zunächst sahen wir einige Auswirkungen auf den Traffic unserer Kunden – Continue reading

HTTP/2 Zero-Day 漏洞導致破紀錄的 DDoS 攻擊

今天早些時候，Cloudflare 與 Google 和 Amazon AWS 一起披露了一個新型 zero-day 漏洞的存在，名為「HTTP/2 Rapid Reset」攻擊。此攻擊利用 HTTP/2 通訊協定中的弱點來產生巨大的超容量分散式阻斷服務 (DDoS) 攻擊。近幾個月來，Cloudflare 緩解了一系列此類攻擊，其中包括一起比我們之前觀察到的任何攻擊規模大三倍的攻擊，每秒要求數 (rps) 超過 2.01 億。自 2023 年 8 月底以來，Cloudflare 緩解了超過 1,100 起 rps 超過 1000 萬的其他攻擊，其中 184 起攻擊超過了我們之前 7100 萬 rps 的 DDoS 記錄。

這個 zero-day 漏洞為威脅執行者提供了一個重要的新工具，即漏洞中的瑞士軍刀，能夠以前所未有的規模利用和攻擊受害者。雖然這些攻擊有時非常複雜且難以應對，但正是因為它們，Cloudflare 才有機會開發專用技術來減輕 zero-day 漏洞的影響。

如果您使用 Cloudflare 進行 HTTP DDoS 緩解，則會受到保護。我們在下文提供了有關此漏洞的更多資訊，以及有關您可以採取哪些措施來保護自己的資源和建議。

解構攻擊：每個 CSO 需要瞭解的事情

2023 年 8 月下旬，我們的 Cloudflare 團隊注意到一個由未知威脅執行者開發的新 zero-day 漏洞，它所利用的標準 HTTP/2 通訊協定是一種基本通訊協定，對網際網路和所有網站的正常運作至關重要。這種新穎的 zero-day 漏洞攻擊稱為 Rapid Reset，它利用 HTTP/2 的串流取消功能，一次又一次地傳送要求並立即取消它。  

透過大規模自動執行這種簡單的「要求、取消、要求、取消」模式，威脅執行者能夠建立阻斷服務並摧毀任何執行 HTTP/2 標準實作的伺服器或應用程式。此外，關於這起破紀錄的攻擊，還有一個重要事項需要注意，它涉及一個中等規模的殭屍網路，由大約 20,000 台機器組成。Cloudflare 會定期偵測比它大幾個數量級的殭屍網路 — 包括數十萬甚至數百萬台機器。對於一個相對較小的殭屍網路來說，輸出如此大量的要求，有可能使幾乎所有支援 HTTP/2 的伺服器或應用程式癱瘓，這凸顯了此漏洞對未受保護的網路的威脅有多大。

威脅執行者將殭屍網路與 HTTP/2 漏洞結合使用，以我們從未見過的速度放大了要求。因此，我們的 Cloudflare 團隊經歷了某種間歇性的邊緣不穩定。雖然我們的系統能夠緩解絕大部分傳入的攻擊，但這些流量會使我們網路中的部分元件過載，從而影響少數客戶的效能，並出現間歇性的 4xx 和 5xx 錯誤，而所有這些錯誤都被迅速解決了。

在我們為所有客戶成功緩解這些問題並阻止潛在攻擊之後，我們的團隊立即開始了負責任的披露程序。我們與業內同行進行了對話，看看我們如何共同努力，幫助推進我們的使命，並在向公眾發布此漏洞之前保護依賴我們網路的大部分網際網路。

我們在另一篇部落格文章中更詳細地介紹了該攻擊的技術細節：HTTP/2 Rapid Reset：解構破紀錄的攻擊。

Cloudflare 和業界如何遏止這種攻擊？

「完美的披露」並不存在。而遏止攻擊和回應新出現的事件需要組織和網路安全團隊以假定違規的心態生活 — 因為總會有另一個 zero-day 漏洞、新發展的威脅執行者團體以及前所未見的新穎攻擊和技術。

這種「假定違規」的心態是資訊分享以及在這種情況下確保網際網路保持安全的重要基礎。在 Cloudflare 遭遇並緩解這些攻擊的同時，我們也與業界合作夥伴合作，以確保整個產業能夠抵禦這種攻擊。  

在緩解此攻擊的過程中，我們的 Cloudflare 團隊開發並專門構建了新技術來阻止這些 DDoS 攻擊，並進一步改進了我們自己的緩解措施來應對此攻擊和未來其他大規模攻擊。這些努力顯著提高了我們的整體緩解功能和復原能力。如果您使用 Cloudflare，我們相信您會受到保護。

我們的團隊也提醒正在開發修補程式以確保此漏洞不會被利用的 Web 伺服器軟體合作夥伴 — 請檢查網站以獲取更多資訊。

披露絕不是一勞永逸的事情。Cloudflare 的命脈是確保更好的網際網路，而這源於諸如此類的實例。當我們有機會與業界合作夥伴和政府合作，以確保網際網路不會受到廣泛影響時，我們正在盡自己的一份力量來提高每個組織的網路復原能力，無論其規模多大或類別為何。

若要深入瞭解緩解策略和下一步修補行動，請報名參加我們的網路研討會。

HTTP/2 Rapid Reset 和這些針對 Cloudflare 的破紀錄攻擊的起因是什麼？

奇怪的是，Cloudflare 竟然是最早目睹這些攻擊的公司之一。為什麼威脅執行者會攻擊一間擁有世界上最強大的 DDoS 攻擊防禦能力的公司？  

實際情況是，Cloudflare 經常在攻擊轉向更脆弱的目標之前就發現了攻擊。威脅執行者在將工具部署到外部環境之前，需要先進行開發和測試。威脅執行者雖然掌握了破紀錄攻擊方法，但很難測試並瞭解攻擊的規模和有效性，因為他們沒有基礎架構可以承受他們發起的攻擊。由於我們分享網路效能的透明度，而且他們可以從我們的公開效能圖表中收集到攻擊測量結果，因此，威脅執行者很可能針對我們發起攻擊，藉此來瞭解該漏洞利用的功能。

但這項測試以及提早發現攻擊的能力，有助於我們針對攻擊開發緩解措施，從而使我們的客戶和整個產業受益。

從 CSO 到 CSO：您應該怎麼做？

我擔任了 20 多年的 CSO，接受過無數這樣的披露和公告。不過，無論是 Log4J、Solarwinds、EternalBlue WannaCry/NotPetya、Heartbleed 還是 Shellshock，所有這些安全事件都有一個共通性。一場大爆炸在全球蔓延並創造機會，徹底顛覆了我所領導的任何組織，無論產業或規模如何。

其中許多攻擊或漏洞都是我們無法控制的。但無論問題的起因是否在我的控制範圍之內，我所領導的任何成功計畫與那些不利於我們的計畫的區別在於，當識別這樣的 zero-day 漏洞和利用時，我們能夠做出回應。    

雖然我希望我可以說這次的 Rapid Reset 可能會有所不同，但事實並非如此。無論你們是像我這樣經歷過數十年安全事件的洗禮，還是第一天從事這項工作，我都呼籲所有的 CSO，此刻正是確保你們受到保護，並支援網路事件回應團隊的時候。

我們直到今天才公開這些資訊，以讓盡可能多的安全廠商有機會做出反應。然而，在某些時候，公開披露這樣的 zero-day 威脅才是真正負責任的行為。而今天就是那一天。這意味著在今天之後，威脅執行者大多會意識到 HTTP/2 漏洞；而且，利用和啟動防禦者與攻擊者之間的競賽將不可避免地變得微不足道 — 先修補與先利用。組織應假設系統會遭受測試，並採取主動措施以確保保護。

對我來說，這會讓我想起像 Log4J 這樣的漏洞，由於每天都出現許多變體，因此，在未來幾週、幾個月甚至幾年內會不斷地取得成果。隨著越來越多的研究人員和威脅執行者對此漏洞進行實驗，我們可能會發現利用週期更短的不同變體，其中包含更高級的繞過方法。  

就像 Log4J 一樣，管理此類事件並不像「執行修補程式，現在就完成了」那麼簡單。您需要將事件管理、修補和發展安全保護措施轉變為持續進行的流程，這是因為針對每個漏洞變體的修補程式可以降低您的風險，但並不能消除風險。

我無意危言聳聽，但我會直接說：你必須認真對待此事。將此事視為一個完全活動的事件，以確保您的組織平安無事。

對新變革標準的建議

雖然沒有任何一個安全事件會與下一個完全相同，但我們可以從中汲取一些教訓。CSO 們，以下是我的建議，必須立即實施。不僅在這種情況下，而且在未來的幾年中也一樣：

• 瞭解您的合作夥伴網路的外部連線，來透過以下緩解措施補救任何面向網際網路的系統。
• 瞭解您現有的安全保護措施以及您擁有的用於保護、偵測和回應攻擊的功能，並立即修復您網路中遇到的任何問題。
• 確保將 DDoS 保護部署在您的資料中心外部，因為如果流量到達資料中心，DDoS 攻擊將很難緩解。
• 確保您為應用程式（第 7 層）提供 DDoS 保護，並確保部署了 Web 應用程式防火牆。此外，作為最佳做法，請確保您為 DNS、網路流量（第 3 層）和 API 防火牆提供完整的 DDoS 保護
• 確保在所有面向網際網路的 Web 伺服器上部署 Web 伺服器和作業系統修補程式。此外，請確保所有自動化（例如，Terraform）組建和映像均已完全修補，這樣舊版 Web 伺服器就不會意外地透過安全映像部署到生產環境中。
• 最後一招，請考慮關閉 HTTP/2 和 HTTP/3（可能也易受攻擊）來緩解威脅。這只是萬不得已才能使用的手段，因為如果降級到 HTTP/1.1，將會出現重大的效能問題
• 考慮在邊界使用基於雲端的輔助 DDoS 第 7 層提供者以提高復原能力。

Cloudflare 的使命是幫助構建更好的網際網路。如果您擔心目前的 DDoS 保護狀態，我們非常樂意免費為您提供 DDoS 功能和復原能力，以緩解任何成功的 DDoS 攻擊嘗試。我們知道您所面臨的壓力，因為我們在過去 30 天內擊退了這些攻擊，並使我們本已最佳的系統變得更加完美。

如果您有興趣瞭解更多資訊，請觀看我們的網路研討會，以詳細瞭解 zero-day 漏洞以及如何應對。如果您不確定自己是否受到保護或想瞭解如何受到保護，請與我們聯絡。我們也在另一篇部落格文章中更詳細地介紹了有關該攻擊的更多技術細節： HTTP/2 Rapid Reset：解構破紀錄的攻擊。最後，如果您成為攻擊目標或需要即時保護，請聯絡您當地的 Cloudflare 代表或造訪https://www.cloudflare.com/zh-tw/under-attack-hotline/。

Internet traffic patterns in Israel and Palestine following the October 2023 attacks

On Saturday, October 7, 2023, attacks from the Palestinian group Hamas launched from the Gaza Strip against the south of Israel started a new conflict in the region. Israel officially declared that it is at war the next day. Cloudflare's data shows that Internet traffic was impacted in different ways, both in Israel and Palestine, with two networks (autonomous systems) in the Gaza Strip going offline a few hours after the attacks. Subsequently, on October 9, two additional networks also experienced outages. We also saw an uptick in cyberattacks targeting Israel, including a 1.26 billion HTTP requests DDoS attack, and Palestine.

Starting with general Internet traffic trends, there was a clear increase in Internet traffic right after the attacks reportedly began (03:30 UTC, 06:30 local time). Traffic spiked at around 03:35 UTC (06:35 local time) in both Israel (~170% growth compared with the previous week) and Palestine (100% growth).

That growth is consistent with other situations, where we’ve seen surges in Internet traffic when countrywide events occur and people are going online to check for news, updates, and more information on what is happening, with social media and messaging also playing a role. However, in Palestine, that traffic growth Continue reading

Virtual networking 101: Bridging the gap to understanding TAP

It's a never-ending effort to improve the performance of our infrastructure. As part of that quest, we wanted to squeeze as much network oomph as possible from our virtual machines. Internally for some projects we use Firecracker, which is a KVM-based virtual machine manager (VMM) that runs light-weight “Micro-VM”s. Each Firecracker instance uses a tap device to communicate with a host system. Not knowing much about tap, I had to up my game, however, it wasn't easy — the documentation is messy and spread across the Internet.

Here are the notes that I wish someone had passed me when I started out on this journey!

A tap device is a virtual network interface that looks like an ethernet network card. Instead of having real wires plugged into it, it exposes a nice handy file descriptor to an application willing to send/receive packets. Historically tap devices were mostly used to implement VPN clients. The machine would route traffic towards a tap interface, and a VPN client application would pick them up and process accordingly. For example this is what our Cloudflare WARP Linux client does. Here's how it looks on my laptop:

$ ip link list
...
18: CloudflareWARP: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>  Continue reading

Uncovering the Hidden WebP vulnerability: a tale of a CVE with much bigger implications than it originally seemed

At Cloudflare, we're constantly vigilant when it comes to identifying vulnerabilities that could potentially affect the Internet ecosystem. Recently, on September 12, 2023, Google announced a security issue in Google Chrome, titled "Heap buffer overflow in WebP in Google Chrome," which caught our attention. Initially, it seemed like just another bug in the popular web browser. However, what we discovered was far more significant and had implications that extended well beyond Chrome.

Impact much wider than suggested

The vulnerability, tracked under CVE-2023-4863, was described as a heap buffer overflow in WebP within Google Chrome. While this description might lead one to believe that it's a problem confined solely to Chrome, the reality was quite different. It turned out to be a bug deeply rooted in the libwebp library, which is not only used by Chrome but by virtually every application that handles WebP images.

Digging deeper, this vulnerability was in fact first reported in an earlier CVE from Apple, CVE-2023-41064, although the connection was not immediately obvious. In early September, Citizen Lab, a research lab based out of the University of Toronto, reported on an apparent exploit that was being used to attempt to install spyware on the iPhone Continue reading

Cloudflare’s a Top 100 Most Loved Workplace for the second consecutive year in 2023

We have always strived to make Cloudflare somewhere where our entire team feels safe and empowered to bring their whole selves to work. It’s the best way to enable the many incredible people we have working here to be able to do their best work. With that as context, we are proud to share that Cloudflare has been certified and recognized as one of the Top 100 Most Loved Workplaces in 2023 by Newsweek and the Best Practice Institute (BPI) for the second consecutive year.  

Cloudflare’s ranking follows surveys of more than 2 million employees at companies with team sizes ranging from 50 to 10,000+, and includes US-based firms and international companies with a strong US presence. As part of the qualification for the certification, Cloudflare participated in a company-wide global employee survey — so this award isn’t a hypothetical, it’s driven by our employees’ sentiment and responses.

With this recognition, we wanted to reflect on what’s new, what’s remained the same, and what’s ahead for the team at Cloudflare. There are a few things that especially stand out:

It starts with our mission and people

Helping to build a better Internet.

If you speak to any member of Continue reading

1.1.1.1 lookup failures on October 4th, 2023

On 4 October 2023, Cloudflare experienced DNS resolution problems starting at 07:00 UTC and ending at 11:00 UTC. Some users of 1.1.1.1 or products like WARP, Zero Trust, or third party DNS resolvers which use 1.1.1.1 may have received SERVFAIL DNS responses to valid queries. We’re very sorry for this outage. This outage was an internal software error and not the result of an attack. In this blog, we’re going to talk about what the failure was, why it occurred, and what we’re doing to make sure this doesn’t happen again.

Background

In the Domain Name System (DNS), every domain name exists within a DNS zone. The zone is a collection of domain names and host names that are controlled together. For example, Cloudflare is responsible for the domain name cloudflare.com, which we say is in the “cloudflare.com” zone. The .com top-level domain (TLD) is owned by a third party and is in the “com” zone. It gives directions on how to reach cloudflare.com. Above all of the TLDs is the root zone, which gives directions on how to reach TLDs. This means that the root zone is important Continue reading

2023 年 10 月 4 日 1.1.1.1 查询失败

在 2023 年 10 月 4 日，从 7:00 UTC 到 11:00 UTC 的这段时间里，Cloudflare 出现了 DNS 解析问题。1.1.1.1 或 Warp、Zero Trust 等产品或使用 1.1.1.1 的第三方 DNS 解析器的一些用户可能会收到对有效查询的 SERVFAIL DNS 响应。对于本次故障，我们深表歉意。本次故障是内部软件错误造成的，不是遭到攻击所致。在这篇博文中，我们将讨论出现了什么故障、发生原因以及我们采取了哪些措施来确保这种情况不再发生。

背景

在域名系统 (DNS) 中，每个域名都位于一个 DNS 区域中。区域是一起控制的域名和主机名的集合。例如，Cloudflare 负责域名 cloudflare.com，我们称其为在 "cloudflare.com" 区域中。.com 顶级域名 (TLD) 归第三方所有，位于 "com" 区域中。它提供如何访问 cloudflare.com 的指示。对于 TLD，最重要的是根区，它提供如何访问 TLD 的指示。这意味着根区对于解析所有其他域名非常重要。与 DNS 的其他重要部分一样，根区也使用 DNSSEC 进行签名，这意味着根区本身包含加密签名。

根区在根服务器上发布，但 DNS 运营商通常也会自动检索并保留根区的副本，使得万一根服务器无法访问时，根区中的信息仍然可用。Cloudflare 的递归 DNS 基础设施也采用了这种方法，因为它还可以加快解析过程。根区的新版本通常每天发布两次。1.1.1.1 有一个名为 static_zone 的 WebAssembly 应用程序，它在主 DNS 逻辑的基础上运行，在新版本可用时为它们提供服务。

究竟发生了什么

在 9 月 21 日，作为根区管理已知和计划变更的一部分，根区中首次加入了一种新的资源记录类型。新资源记录名为 ZONEMD，实际上是根区内容的校验和。

根区通过在 Cloudflare 核心网络中运行的软件检索。随后，它被重新分配到 Cloudflare 遍布全球的数据中心。更改后，包含 ZONEMD 记录的根区仍可正常检索和分配。但是，使用该数据的 1.1.1.1 解析器系统在解析 ZONEMD 记录时遇到了问题。由于区域必须完整加载并提供，如果系统无法解析 ZONEMD，则意味着 Cloudflare 解析器系统未使用新版本的根区。一些托管 Cloudflare 解析器基础架构的服务器在未收到新的根区时，无法逐个请求直接查询 DNS 根服务器。然而，继续依赖于根区的已知正常工作版本的其他用户在内存缓存中仍可使用该版本，即在变更前于 9 月 21 日提取的版本。

在 2023 年 10 月 4 日 07:00 UTC，9 月 21 日发布的根区版本中的 DNSSEC 签名已过期。由于 Cloudflare 解析器系统无法使用本来应该可以使用的较新版本，Cloudflare 的一些解析器系统无法验证 DNSSEC 签名，因此开始发送错误响应 (SERVFAIL)。Cloudflare 解析器生成 SERVFAIL 响应的比率增长了 12%。下图说明了故障的发展过程以及用户如何看到故障。

事件时间线和影响

9 月 21 日 6:30 UTC：最后一次成功提取根区
10 月 4 日 7:00 UTC：在 9 月 21 日获得的根区中的 DNSSEC 签名过期，导致对客户端查询的 SERVFAIL 响应增加。
7:57：开始收到第一份关于意外 SERVFAIL 的外部报告。
8:03：宣布内部 Cloudflare 事件。
8:50：首次尝试通过覆盖规则阻止 1.1.1.1 使用过期的根区文件提供响应。10:30：完全阻止 1.1.1.1 预装根区文件。
10:32：响应恢复正常。
11:02：事件关闭。

下图显示了受影响的时间以及返回 SERVFAIL 错误的 Continue reading

2023 年 10 月 4 日 1.1.1.1 查詢失敗

2023 年 10 月 4 日，Cloudflare 於世界標準時 7:00 開始至 11:00 結束期間遇到 DNS 解析問題。1.1.1.1 或 Warp 、 Zero Trust 等產品的一些使用者，或使用 1.1.1.1 的第三方 DNS 解析程式可能已經收到對有效查詢的 SERVFAIL DNS 回應。對於此次服務中斷，我們深感抱歉。此次服務中斷為內部軟體錯誤，而非攻擊造成的結果。在這篇部落格中，我們將討論失敗的內容、發生的原因，以及我們可以採取哪些措施來確保這種情況不再發生。

背景

在 Domain Name System (DNS) 中，每一個網域名稱存在於 DNS 區域內。區域是在一起接受控制的網域名稱和主機名稱的集合。例如，Cloudflare 負責網域 cloudflare.com，我們稱之為「cloudflare.com」區域。頂級網域 (TLD) .com 由第三方擁有，位於「com」區域。它提供如何連線 cloudflare.com 的指示。所有 TLD 之上為根區域，提供如何連線 TLD 的指示。這意味著根區域對於解析所有其他網域名稱很重要。與 DNS 的其他重要部分一樣，根區域使用 DNSSEC 進行簽署，這也意味著根區域本身包含加密簽章。

根區域發布於根伺服器上，但 DNS 營運商自動擷取並保留根區域副本的情況也很常見， 以便在無法連線根伺服器的情況下，根區域中的資訊仍然可供使用。Cloudflare 的遞迴 DNS 基礎架構會採用此方法，因為它還可加速解析程序。新版根區域通常一天發布兩次。1.1.1.1 具有稱為 static_zone 的 WebAssembly 應用程式，該應用程式執行於主 DNS 邏輯之上，當新版本可供使用時，即可提供這些新的版本。

狀況說明

9 月 21 日，作為根區域管理中的已知計畫內變更的一部分，新的資源記錄類型首次納入根區域。新資源記錄稱為 ZONEMD，實際上是根區域內容的總和檢查碼。

藉由執行於 Cloudflare 核心網路的軟體來擷取根區域。隨後，根區域被重新分散到 Cloudflare 在世界各地的資料中心。變更之後，可繼續正常擷取和分散包含 ZONEMD 記錄的根區域。然而，使用該資料的 1.1.1.1 解析程式系統在剖析 ZONEMD 記錄時遇到問題。由於區域必須完整載入和提供，因此系統無法剖析 ZONEMD，這意味著新版根區域未在 Cloudflare 的解析程式系統中使用。若託管 Cloudflare 解析程式基礎架構的某些伺服器未收到新的根區域，則會發生容錯移轉，直接逐個請求地查詢 DNS 根伺服器。不過，其他伺服器會繼續依賴其記憶體快取仍然可用的已知工作版根區域，這是在變更之前於 9 月 21 日提取的版本。

2023 年 10 月 4 日世界標準時 7:00，根區域版本中自 9 月 21 日開始的 DNSSEC 簽章到期。由於 Cloudflare 解析程式系統沒有能夠使用的更新版本，某些 Cloudflare 解析程式系統無法驗證 DNSSEC 簽章，並因此開始傳送錯誤回應 (SERVFAIL)。Cloudflare 解析程式產生 SERVFAIL 回應的速度提升了 12%。下圖說明了失敗的進度，以及如何顯示給使用者。

事件時間表和影響

9 月 21 日世界標準時 6:30：根區最後一次成功提取
10 月 4 日世界標準時 7:00：根區域中於 9 月 21 日取得的 DNSSEC 簽章到期，導致對用戶端查詢的 SERVFAIL 回應增加。
7:57︰第一個外部非預期 SERVFAIL 報告開始出現。
8:03︰正式宣佈發生內部 Cloudflare 事件。
8:50：初次嘗試阻止 1.1.1.1 使用具有覆寫規則的過時根區域檔案來提供回應。
10:30：完全阻止 1.1.1.1 預先載入根區域檔案。
10:32：回應恢復正常。
11:02︰事件結束。

下圖顯示了影響時間表，以及傳回 SERVFAIL 錯誤的 DNS 查詢百分比：

我們預計，在正常操作期間，常規流量的 SERVFAIL 錯誤數量會達到基準。該比例通常在 Continue reading

2023年10月4日の1.1.1.1ルックアップ障害

2023年10月4日、Cloudflareで07:00～11:00 (協定世界時) にかけてDNS解決に関する障害が発生しました。一部の1.1.1.1の利用者、または1.1.1.1を使用するWarp 、Zero Trust、サードパーティDNSリゾルバなどの製品の一部の利用者が、有効なクエリに対して「SERVFAIL DNS」応答を受信した可能性があります。この度は、ご迷惑をおかけして大変申し訳ございませんでした。この障害は内部的なソフトウェアのエラーであり、攻撃によるものではありません。このブログでは、障害の経緯、発生理由、そして再発防止に対する当社の取り組みについて説明します。

背景

ドメインネームシステム（DNS）の仕組みでは、すべてのドメイン名はDNSゾーン内に存在します。ゾーンには、ドメイン名とホスト名のセットの集合体が管理されています。たとえば、Cloudflareはcloudflare.comというドメイン名を管理しており、これは「cloudflare.com」ゾーンにあると言えます。トップレベルドメイン（TLD）「.com」はサードパーティが所有し、「com」ゾーンにあります。comによってcloudflare.comへのアクセス方法が示されます。すべてのTLDの上位には各TLDへのアクセス方法を示す、ルートゾーンがあります。そのため、ルートゾーンは他のすべてのドメイン名を解決できるようにするために重要な存在です。DNSの他の重要な部分と同様に、ルートゾーンもDNSSECで署名されており、ルートゾーン自体には暗号署名が含まれています。

ルートゾーンはルートサーバーによって公開されていますが、多くのDNS運用者は一般的にルートサーバーに到達できない場合でもルートゾーンの情報を利用できるようにルートゾーンのコピーを自動的に取得して保持するようにしています。 Cloudflareの再帰DNSインフラストラクチャも解決プロセスを高速化するため、このアプローチを採用しています。ルートゾーンの新バージョンは通常1日2回公開されます。1.1.1.1では、 static_zoneと呼ばれるWebAssemblyアプリがメインのDNSロジックの上で動作しており、新バージョンが公開された段階で新バージョンを提供できるようにしています。

障害発生の原因

9月21日、ルートゾーン管理における既知の計画済みの変更の内容に、ルートゾーンに初めて、チェックサムとして機能する新たなリソースレコードタイプ「ZONEMD」が追加されるというものがありました。

ルートゾーンの情報は、Cloudflareのコアネットワークで動作するソフトウェアによって取得されます。その後、世界中のCloudflareのデータセンターに再配布されます。変更後も、ZONEMDレコードを含むルートゾーンは通常通り取得および配布は継続して実行されていました。しかし、そのデータを利用する1.1.1.1のリゾルバシステムに問題があり、ZONEMDレコードを解析することができませんでした。ゾーンは全体をロードして提供する必要があるため、システムがZONEMDを解析できなかったことにより、ルートゾーンの新バージョンをCloudflareのリゾルバシステムで使用することができなくなりました。Cloudflareのリゾルバインフラストラクチャをホストしているサーバーの中には、新しいルートゾーンの情報を受信できなかった場合、リクエストの都度、DNSルートサーバーに直接問い合わせるようにフェイルオーバーするものもあります。しかし、他のサーバーは、メモリキャッシュに保存されたルートゾーンの既知の動作バージョン（変更前の9月21日に引き出されたバージョン）の利用を続けました。

2023年10月4日7時（協定世界時）、9月21日バージョンのルートゾーンのDNSSECの有効期限が切れました。Cloudflareのリゾルバシステムで利用可能な新しいバージョンが無くなり、Cloudflareの一部のリゾルバシステムがDNSSECシグネチャを検証できなくなり、その結果、エラーレスポンス（SERVFAIL）を送信するようになりました。CloudflareリゾルバのSERVFAILレスポンス生成割合が12%増加する事態となりました。以下の図は、障害の進行と、ユーザーへの影響が表面化した経緯を示しています。

インシデントのタイムラインと影響

9月21 日6:30（協定世界時）：ルートゾーンからの最後の情報引き出しの成功
10月4日7:00（協定世界時）：9月21日に取得したルートゾーンのDNSSEC署名が期限切れとなり、クライアントからの問い合わせに対するSERVFAIL応答が増加。
7:57：予期せぬSERVFAILに対する最初の外部報告が入り始める。
06:32：Cloudflare社内でインシデントが宣言される。
8:50：オーバーライドルールを使用して、1.1.1.1が古いルートゾーンファイルを使用した応答を提供するのを防ぐ最初の試みを実施。
10:30：1.1.1.1のルートゾーンファイルの事前読み込みを完全に停止。10:32：応答が正常に回復。
11:02：インシデントをクローズ。

この下のグラフは、影響とSERVFAILエラーで返されたDNS問い合わせのパーセンテージを時系列で表したものです：

私たちは、平常時のトラフィックにおけるSERVFAILエラーの基準量（通常値）を3%程度と想定しています。この場合のSERVFAILは、DNSSECチェーンにおける正当な問題、権威サーバーへの接続の失敗、権威サーバーの応答のタイムアウト、その他多くの要因によって引き起こされる可能性があります。インシデントの間、SERVFAILの量は総クエリの15%でピークに達しましたが、その影響は世界中に均等に分散されたわけではなく、アッシュバーン（バージニア州）、フランクフルト（ドイツ）、シンガポールのような大規模なデータセンターに主に集中しました。

インシデント発生の理由

ZONEMDレコードの解析に失敗した理由

DNSは、リソースレコードの格納にバイナリ形式を採用しています。このバイナリ形式では、リソースレコードのタイプ（TYPE）は16ビットの整数として格納されます。リソースレコードのタイプが、リソースデータ（RDATA）の解析方法を決定します。レコードタイプ「1」はAレコードであることを意味し、RDATAはIPv4アドレスとして解析されます。レコードタイプ「28」はAAAAレコードを意味し、RDATAはIPv6アドレスとして解析されます。解析が未知のリソースタイプに遭遇した場合、RDATAの解析方法を判断することができないが、RDLENGTHフィールドがRDATAフィールドの長さを示すため、解析はそれを不明なデータ要素として扱うことができます。

                                   1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

static_zoneが新しいZONEMDレコードをサポートしなかった理由は、これまで私たちがルートゾーンをバイナリ形式ではなく、プレゼンテーション形式で内部配布することを選んできたためです。リソースレコードのテキスト表現をいくつか見てみると、異なるレコードの表示形式には、さらに多くのバリエーションがあることがわかります。

.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2023100400 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20231017050000 20231004040000 46780 . J5lVTygIkJHDBt6HHm1QLx7S0EItynbBijgNlcKs/W8FIkPBfCQmw5BsUTZAPVxKj7r2iNLRddwRcM/1sL49jV9Jtctn8OLLc9wtouBmg3LH94M0utW86dKSGEKtzGzWbi5hjVBlkroB8XVQxBphAUqGxNDxdE6AIAvh/eSSb3uSQrarxLnKWvHIHm5PORIOftkIRZ2kcA7Qtou9NqPCSE8fOM5EdXxussKChGthmN5AR5S2EruXIGGRd1vvEYBrRPv55BAWKKRERkaXhgAp7VikYzXesiRLdqVlTQd+fwy2tm/MTw+v3Un48wXPg1lRPlQXmQsuBwqg74Ts5r8w8w==
.			518400	IN	NS	a.root-servers.net.
.			86400	IN	ZONEMD	2023100400 1 241 E375B158DAEE6141E1F784FDB66620CC4412EDE47C8892B975C90C6A102E97443678CCA4115E27195B468E33ABD9F78C

未知のリソースレコードに遭遇した際の処理方法の判断は必ずしも単純なものではありません。このため、私たちがエッジで使用するルートゾーン解析用のライブラリは、解析を行わずに代わりに解析エラーを返します。

ルートゾーンの古いバージョンが使用された理由

static_zoneアプリは、ルートゾーンをローカルに提供（FC 7706）する目的で、ルートゾーンの読み込みと解析を行い、最新バージョンをメモリに保存します。新バージョンが公開されると、static_zoneアプリがそれを解析し、解析に成功すると旧バージョンを削除します。しかし、static_zoneアプリは解析に失敗し、新しいバージョンに切り替えることができないため、古いバージョンを延々と使用し続けることになりました。1.1.1.1サービスが最初に起動されたとき、static_zoneアプリは既存のバージョンをメモリ内に持ち合わせていません。ルートゾーンを解析しようとすると失敗するものの、ルートゾーンの古いバージョンも持ち合わせていないため、ルートサーバーに直接リクエストを問い合わせることになります。

static_zoneを無効にする最初の試みがうまくいかなかった理由

当初、1.1.1.1の動作をプログラム的に変更可能な仕組みであるオーバーライドルールによってstatic_zoneアプリの無効化が試行されました。私たちが展開したルールは以下のとおりです：

phase = pre-cache set-tag rec_disable_static

このルールは、受信したリクエストに「rec_disable_static」タグを付加します。static_zoneアプリの内部でこのタグをチェックし、設定されている場合、キャッシュされた静的ルートゾーンから応答を返しません。ただし、現在のノードが自身のキャッシュから応答を見つけられない場合、キャッシュパフォーマンス向上のために、問い合わせが別のノードに転送されることがあります。残念ながら、他のノードに転送される問い合わせにはrec_disable_staticタグが含まれないため、最終的にアプリを完全に無効にするまで、static_zoneアプリは古い情報を返し続けることとなりました。

影響が部分的だった理由

Cloudflareでは、カーネルアップデートなどのシステムを完全に再起動することで有効になるタスクのため、当社のサービスをホストするサーバーを定期的に順次の再起動を実施しています。今回の障害発生時、ZONEMDの変更とDNSSECの無効化の間に再起動されたリゾルバサーバインスタンスは、影響に寄与していません。もしこの2週間の間に再起動されていた場合、起動時にルートゾーンのロードに失敗し、代わりにルートサーバーにDNSクエリを送信して解決を試みることになったでしょう。加えて、リゾルバはserve-stale（RFC 8767）と呼ばれる技法を用い、影響を抑制する目的で、アクセス数の多いレコードを、最新ではない可能性のあるキャッシュから提供し続けることになります。レコードが上流から取得されてからTTL秒数が経過すると、そのレコードは最新ではないとみなされます。これにより、完全な停止を防ぎました。影響は主に、その時間枠内に1.1.1.1サービスを再起動しなかった多数サーバーを抱える最大規模のデータセンターで発生しました。

改善とフォローアップ手順

今回のインシデントは広範囲に影響を及ぼしており、当社では当社のサービスの可用性について非常に重く受け止めております。当社はいくつかの領域における改善点の特定に至りましたが、今後も再発の原因となるその他のギャップの発見に努めてまいります。

当社が直後から取り組んでいる内容は以下のとおりです。

可視性：static_zoneが古いルートゾーンファイルを提供した場合に通知するアラートを追加しました。古いルートゾーンファイルが提供された場合に長期間気づかれないという事態は防がれるべき事象でした。もし私たちがこの件をもっときちんと監視し、キャッシングが存在していれば、影響はなかったでしょう。上流で行われた変更からお客様とそのユーザーをお守りすることが私たちの目標です。

耐障害性：内部的なルートゾーンの取得と配布方法を見直します。取得および配布のパイプラインは、新しいRRTYPEをシームレスに処理し、パイプラインの短時間の中断はエンドユーザーが気付かない程度に抑える必要があります。

テスト：新しいZONEMDレコードの解析における未公表の変更に関連するテストを含め、この問題に関するテストを実施しているにもかかわらず、ルートゾーンの解析に失敗した場合のテスト内容が不十分でした。そのため、カバレッジと関連するプロセスを改善していきます。

設計：特定の期限を過ぎたルートゾーンの古いコピーを使用すべきではありません。古いルートゾーンデータも限られた時間であれば使用し続けることは確かに可能ですが、ある時点を過ぎると、許容できない運用上のリスクが生じます。RFC 8806「Running a Root Server Local to a Resolver（ルートサーバーをリゾルバに対してローカルで実行する）」に記述されているように、キャッシュされたルートゾーンデータの有効期間をより適切に管理するための対策を講じます。

まとめ

このようなインシデントを起こしてしまったことを深くお詫び申し上げます。このインシデントから学ぶべき教訓は「変更はないだろう」と思い込まないことです。現代のシステムの多くは、最終的な実行ファイルに組み込まれる長いライブラリ群の連鎖で構築されており、そのひとつひとつにバグがあったり、変更があっても更新に遅延が発生してプログラムが正しく動作しないなどと言った事象が発生することがあります。私たちは、変更によるリグレッションを適切に検出する優れたテストや、変更に対して正常に失敗するシステムやコンポーネントを用意することがいかに重要であるかを理解しています。私たちは、インターネットの最も重要なシステム（DNSやBGP）における「形式」の変更が影響を及ぼすことを常に想定する必要があることを理解しています。

社内でフォローアップすべきことはたくさんあり、私たちは現在、このようなことを二度と起こさないよう24時間体制で取り組んでいます。

Fallos de la búsqueda de 1.1.1.1 del 4 de octubre de 2023

El 4 de octubre de 2023, Cloudflare sufrió problemas en la resolución de DNS entre las 07:00 y las 11:00 UTC. Algunos usuarios de 1.1.1.1 o de productos como WARP, Zero Trust o de solucionadores DNS externos que utilicen 1.1.1.1 pueden haber recibido respuestas SERVFAIL DNS a consultas válidas. Lamentamos mucho esta interrupción. Fue debido a un error interno del software y no fue consecuencia de ningún ataque. En esta publicación del blog, hablaremos acerca de en qué consistió el fallo, por qué se produjo y qué estamos haciendo para garantizar que no se repita.

Antecedentes

En el sistema de nombres de dominio (DNS), cada nombre de dominio existe en una zona DNS, que está formada por un conjunto de nombres de dominio y nombres de servidor que se controlan juntos. Por ejemplo, Cloudflare es responsable del nombre de dominio cloudflare.com, que decimos que está en la zona "cloudflare.com". El dominio de nivel superior (TLD) .com es propiedad de un tercero y está en la zona "com". Proporciona indicaciones acerca de cómo llegar a cloudflare.com. Por encima de todos los TLD se encuentra la zona raíz, que ofrece indicaciones Continue reading

1.1.1.1 Lookup-Fehler am 4. Oktober 2023

Am 4. Oktober 2023 traten bei Cloudflare Probleme bei der DNS-Auflösung auf, die um 07:00 UTC begannen und um 11:00 UTC endeten. Einige Nutzer von 1.1.1.1 oder Produkten wie WARP, Zero Trust oder DNS-Resolvern von Drittanbietern, die 1.1.1.1 verwenden, haben möglicherweise SERVFAIL DNS-Antworten auf gültige Anfragen erhalten. Wir möchten uns vielmals für diesen Ausfall entschuldigen. Dieser Ausfall war ein interner Softwarefehler und nicht das Ergebnis eines Angriffs. In diesem Blogartikel werden wir erläutern, was der Fehler war, warum er auftrat und was wir unternehmen, um sicherzustellen, dass sich so etwas nicht wiederholt.

Hintergrund

Im Domain Name System (DNS) existiert jeder Domain-Name innerhalb einer DNS-Zone. Die Zone ist eine Sammlung von Domain-Namen und Host-Namen, die gemeinsam kontrolliert werden. So ist Cloudflare beispielsweise für die Domain cloudflare.com verantwortlich, die sich in der Zone „cloudflare.com“ befindet. Die Top-Level-Domain (TLD) .com gehört einer dritten Partei und befindet sich in der Zone „com“. Sie gibt Auskunft darüber, wie cloudflare.com zu erreichen ist. Über allen TLDs befindet sich die Root-Zone, die Hinweise darauf gibt, wie die TLDs erreicht werden. Das bedeutet, dass die Root-Zone wichtig ist, um alle anderen Domain-Namen auflösen zu können. Wie andere wichtige Continue reading

Les échecs des recherches sur le résolveur 1.1.1.1 le 4 octobre 2023

Le 4 octobre 2023, Cloudflare a rencontré des problèmes de résolution DNS à partir de 7 h UTC, et ce jusqu'à 11 h UTC. Certains utilisateurs de 1.1.1.1 ou de produits tels que WARP, Zero Trust ou d'autres résolveurs DNS tiers utilisant 1.1.1.1 peuvent avoir reçu des réponses SERVFAIL DNS à leurs requêtes, pourtant valides. Nous sommes sincèrement désolés pour cette panne. Celle-ci était due à une erreur logicielle interne et n'était aucunement le résultat d'une attaque. Cet article de blog va nous permettre de discuter de la nature de cette défaillance, des raisons pour lesquelles elle s'est produite et des mesures que nous avons mises en œuvre pour nous assurer qu'une telle situation ne se reproduise jamais.

Contexte

Dans le Domain Name System (DNS, système de noms de domaine), chaque nom de domaine existe au sein d'une zone DNS. Cette zone constitue un ensemble de noms de domaine et de noms d'hôte, contrôlés conjointement. Pour prendre un exemple, Cloudflare est responsable du nom de domaine cloudflare.com, que nous disons se trouver dans la zone « cloudflare.com ». Le domaine de premier niveau (TLD, Top-Level Domain) « .com » est détenu par Continue reading

All Cloudflare Customers Protected from Atlassian Confluence CVE-2023-22515

On 2023-10-04 at 13:00 UTC, Atlassian released details of the zero-day vulnerability described as “Privilege Escalation Vulnerability in Confluence Data Center and Server” (CVE-2023-22515), a zero-day vulnerability impacting Confluence Server and Data Center products.  

Cloudflare was warned about the vulnerability before the advisory was published and worked with Atlassian to proactively apply protective WAF rules for all customers. All Cloudflare customers, including Free, received the protection enabled by default. On 2023-10-03 14:00 UTC Cloudflare WAF team released the following managed rules to protect against the first variant of the vulnerability observed in real traffic.

When CVE-2023-22515 is exploited, an attacker could access public Confluence Data Center and Server instances to create unauthorized Confluence administrator accounts to access the instance. According to the advisory the vulnerability is assessed by Atlassian as critical. At the moment of writing a CVSS score is not yet known. More information can be found in the security advisory, including what versions of Confluence Server are affected.

Waiting Room adds multi-host and path coverage, unlocking broader protection and multilingual setups

Cloudflare Waiting Room protects sites from overwhelming traffic surges by placing excess visitors in a fully customizable virtual waiting room, admitting them dynamically as spots become available. Instead of throwing error pages or delivering poorly-performing site pages, Waiting Room empowers customers to take control of their end-user experience during unmanageable traffic surges.

A key decision customers make when setting up a waiting room is what pages it will protect. Before now, customers could select one hostname and path combination to determine what pages would be covered by a waiting room. Today, we are thrilled to announce that Waiting Room now supports coverage of multiple hostname and path combinations with a single waiting room, giving customers more flexibility and offering broader site coverage without interruptions to end-user flows. This new capability is available to all Enterprise customers with an Advanced Purchase of Waiting Room.

Waiting Room site placement

As part of the simple, no-coding-necessary process for deploying a waiting room, customers specify a hostname and path combination to indicate which pages are covered by a particular waiting room. When a site visitor makes a preliminary request to that hostname and path or any of its subpaths, they will be issued a Continue reading

Waiting Room ajoute la prise en charge d'hôtes et de chemins d'accès multiples, offrant une protection plus étendue et des configurations multilingues

Cloudflare Waiting Room protège les sites contre les surcharges liées aux pics de trafic en transférant l'excédent de visiteurs vers une salle d'attente virtuelle, entièrement personnalisable, dans laquelle les visiteurs sont admis dynamiquement, au fur et à mesure que des places se libèrent. Au lieu d'afficher des pages d'erreur ou de proposer une expérience insatisfaisante de l'affichage des pages du site, Waiting Room permet aux clients de prendre le contrôle de l'expérience de leurs utilisateurs finaux pendant les pics de trafic ingérables.

L'une des principales décisions que prennent les clients lors de la configuration d'une salle d'attente consiste à sélectionner les pages que protégera celle-ci. Jusqu'à présent, les clients pouvaient sélectionner un nom d'hôte et un chemin d'accès lors de la désignation des pages protégées par une instance de Waiting Room. Aujourd'hui, nous sommes ravis d'annoncer que Waiting Room propose désormais la prise en charge de combinaisons de noms d'hôtes et de chemins d'accès multiples pour une salle d'attente unique, offrant ainsi aux clients davantage de flexibilité et une prise en charge plus étendue des sites, sans interruption des flux des utilisateurs finaux.Cette nouvelle fonctionnalité est accessible à tous les clients Enterprise ayant préacheté Waiting Room.

Ajout d'un site Continue reading