💨

HTTP/2 Rapid Reset：記録的な攻撃を分解する(翻訳記事）

2023/10/11に公開

この記事は以下のブログの翻訳です。
公式翻訳が完了次第削除します。
技術情報に誤りがある場合、遠慮なく、むしろ積極的に@kameoncloudまで連絡下さい。

2023年8月25日から、多くのお客様を襲った異常に大規模なHTTP攻撃に気付き始めました。これらの攻撃は当社の自動DDoSシステムによって検知され、軽減されました。しかし、これらの攻撃が記録的な規模に達するまでそれほど時間はかかりませんでした。これは、過去最大の攻撃の約3倍の規模でした。

懸念されるのは、攻撃者がわずか2万台のボットネットでこのような攻撃を行えたという事実である。今日では、数十万台から数百万台のマシンで構成されるボットネットが存在する。ウェブ全体のリクエスト数は通常1秒間に10億から30億に過ぎないことを考えると、この方法を使えば、ウェブ全体のリクエストに相当するものを少数のターゲットに集中させることができる可能性も考えられなくはない。

検出と軽減

これは前例のない規模の斬新な攻撃ベクトルでしたが、Cloudflareの既存の保護機能により、攻撃の大部分を吸収することができました。当初はお客様のトラフィックに若干の影響が見られましたが（攻撃の初期波ではリクエストのおよそ1%に影響）、現在では緩和方法を改良し、当社のシステムに影響を与えることなく、Cloudflareのすべてのお客様の攻撃を阻止することができました。

私たちは、GoogleとAWSという他の2つの業界大手も同様の攻撃を受けていることに同時に気づきました。私たちはCloudflareのシステムを強化し、今日、すべてのお客様がこの新しいDDoS攻撃手法から保護されていることを確認しました。また、GoogleやAWSとともに、影響を受けるベンダーや重要インフラプロバイダーへの攻撃に関する協調的な情報開示にも参加しました。

この攻撃は、HTTP/2プロトコルのいくつかの機能とサーバー実装の詳細を悪用することで可能となりました（詳細はCVE-2023-44487を参照してください）。この攻撃はHTTP/2プロトコルの根本的な弱点を悪用しているため、HTTP/2を実装しているあらゆるベンダーがこの攻撃の対象になると考えられます。これにはあらゆる最新のウェブサーバーが含まれる。私たちは、GoogleとAWSとともに、攻撃方法をウェブサーバーベンダーに公開しました。それまでは、CloudflareのようなDDoS緩和サービスをウェブサーバーやAPIサーバーの前に設置することが最善の防御策です。

この投稿では、HTTP/2プロトコルの詳細、攻撃者がこれらの大規模な攻撃を発生させるために悪用した機能、およびすべてのお客様が保護されていることを保証するために私たちが講じた緩和策について掘り下げます。これらの詳細を公開することで、影響を受けた他のウェブサーバーやサービスが、緩和策を実施するために必要な情報を得られることを私たちは望んでいます。さらに、HTTP/2プロトコルの標準化チームや、将来のウェブ標準に取り組むチームは、このような攻撃を防ぐための設計を改善することができます。

RST 攻撃の詳細

HTTPはウェブを動かすアプリケーションプロトコルです。HTTP セマンティクスは HTTP のすべてのバージョンに共通で、リクエストとレスポンスのメッセージ、メソッド、ステータスコード、ヘッダーフィールドとトレーラフィールド、メッセージの内容など、全体的なアーキテクチャや用語、プロトコルの側面を指します。個々のHTTPバージョンは、セマンティクスをインターネット上でやりとりするための "ワイヤーフォーマット "に変換する方法を定義しています。例えば、クライアントはリクエストメッセージをバイナリデータにシリアライズして送信し、サーバはそれを解析して処理可能なメッセージに戻します。

HTTP/1.1は、テキスト形式のシリアライズを使用します。リクエストメッセージとレスポンスメッセージはASCII文字のストリームとしてやりとりされ、TCPのような信頼性の高いトランスポート層を介して、次のようなフォーマットで送信されます（CRLFはキャリッジリターンとラインフィードを意味します）：

 HTTP-message   = start-line CRLF
                   *( field-line CRLF )
                   CRLF
                   [ message-body ]

例えば、https://blog.cloudflare.com/ に対する非常に単純なGETリクエストは、ワイヤ上では次のようになります：

GET / HTTP/1.1 CRLFHost: blog.cloudflare.comCRLF

そして、レスポンスは次のようになります：

HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLF<100 bytes of data>

つまり、1つのTCPコネクションを使って、複数のリクエストとレスポンスをやり取りすることができます。さらに、リクエストとレスポンスを正しく関連付けるために、厳密な順序が要求されます。メッセージは直列に交換され、多重化することはできません。
https://blog.cloudflare.com/、https://blog.cloudflare.com/page/2/ の2つのGETリクエストは次のようになります。

GET / HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFGET /page/2 HTTP/1.1 CRLFHost: blog.cloudflare.comCRLF

そしてレスポンスは以下になります。

HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLF<100 bytes of data>HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLF<100 bytes of data>

ウェブページはこれらの例よりも複雑なHTTPインタラクションを必要とします。Cloudflareブログにアクセスすると、ブラウザは複数のスクリプト、スタイル、メディアアセットを読み込みます。HTTP/1.1を使用してフロントページにアクセスし、すぐにページ2に移動することを決めた場合、ブラウザは2つのオプションから選ぶことができます。ページ2が始まる前に、もう必要ないページに対するキューに入れられたレスポンスをすべて待つか、TCP接続を閉じて新しい接続を開くことで飛行中のリクエストをキャンセルするか。どちらもあまり現実的ではありません。ブラウザは、TCPコネクションのプール（ホストごとに最大6つ）を管理し、プール上で複雑なリクエスト・ディスパッチ・ロジックを実装することで、これらの制限を回避する傾向があります。

HTTP/2はHTTP/1.1の問題の多くに対処しています。各HTTPメッセージは、型、長さ、フラグ、ストリーム識別子(ID)、ペイロードを持つHTTP/2フレームのセットにシリアライズされます。ストリーム ID は、ワイヤ上のどのバイトがどのメッセージに適用されるかを明確にし、安全な多重化と同時実行を可能にします。ストリームは双方向で動作します。クライアントはフレームを送信し、サーバーは同じIDを使ったフレームを返信します。

HTTP/2では、https://blog.cloudflare.com のGETリクエストはストリームID 1でやり取りされ、クライアントは1つのHEADERSフレームを送信し、サーバーは1つのHEADERSフレームと、それに続く1つ以上のDATAフレームで応答します。クライアントのリクエストは常に奇数番号のストリームIDを使用するので、後続のリクエストはストリームID 3、5......を使用することになります。応答はどのような順番でも提供することができ、異なるストリームからのフレームをインターリーブすることもできます。

ストリームの多重化と同時実行は、HTTP/2の強力な機能です。これらは、単一のTCPコネクションをより効率的に使用することを可能にします。HTTP/2は、特にPrioratization組み合わせると、リソースの取得を最適化します。反面、クライアントが大量の並列作業を簡単に開始できるようにすることは、HTTP/1.1と比較して、サーバーリソースに対するピーク需要を増加させる可能性があります。これは明らかにサービス拒否のベクトルです。

いくつかのガードレールを提供するために、HTTP/2 は最大アクティブ同時ストリームの概念を提供します。SETTINGS_MAX_CONCURRENT_STREAMS パラメータにより、サーバーは同時処理数の上限を告知することができます。例えば、サーバーが上限を100とした場合、いつでもアクティブにできるのは100リクエストだけです。クライアントがこの制限を超えてストリームを開こうとした場合、RST_STREAM フレームを使用してサーバーによって拒否されなければなりません。ストリームの拒否は、接続中の他のストリームには影響しません。

本当のところはもう少し複雑です。ストリームにはライフサイクルがあります。下図はHTTP/2ストリームのステートマシンの図です。クライアントとサーバーはストリームの状態をそれぞれ管理します。HEADERS、DATA、RST_STREAM フレームが送受信されると遷移が発生します。ストリームの状態のビューは独立していますが、同期しています。

HEADERSとDATAフレームはEND_STREAMフラグを含み、このフラグが値1（真）にセットされると、ステート遷移のトリガーとなります。

メッセージコンテンツを持たないGETリクエストの例で説明します。クライアントはまずストリームを idle 状態から open 状態に遷移させ、すぐに half-closed 状態に遷移させます。クライアントのハーフクローズ状態は、もはや HEADERS や DATA を送信できないことを意味し、WINDOW_UPDATE、PRIORITY、RST_STREAM フレームのみを送信できます。しかし、任意のフレームを受信することはできます。

サーバーがHEADERSフレームを受信して解析すると、ストリームの状態をアイドル状態からオープン状態、そしてハーフクローズ状態に遷移させ、クライアントと一致させます。サーバーのハーフクローズ状態は、どんなフレームでも送信できますが、WINDOW_UPDATE、PRIORITY、またはRST_STREAMフレームしか受信できないことを意味します。

そのため、サーバーはEND_STREAMフラグを0に設定したHEADERSを送信し、次にEND_STREAMフラグを1に設定したDATAを送信する。クライアントがこのフレームを受信すると、ストリームもクローズドに遷移します。ストリームがクローズされると、フレームの送受信はできなくなります。

このライフサイクルを並行性の文脈に当てはめると、HTTP/2は次のように表現できます：

[open」状態のストリーム、または「half-closed」状態のストリームは、エンドポイントが開くことを許可されるストリームの最大数にカウントされます。これら3つの状態のいずれかにあるストリームは、SETTINGS_MAX_CONCURRENT_STREAMS設定でアドバタイズされる制限にカウントされます。

理論的には、同時実行数の制限は有用である。しかし、その有効性を妨げる現実的な要因があります。

HTTP/2 request cancellation

先に、リクエストのクライアントキャンセルについて説明しました。HTTP/2はHTTP/1.1よりもはるかに効率的な方法でこれをサポートします。接続全体を切断するのではなく、クライアントは単一のストリームに対して RST_STREAM フレームを送ることができます。これはサーバーにリクエストの処理を停止し、レスポンスを中止するよう指示するもので、サーバーのリソースを解放し、帯域幅の浪費を避けることができます。

前の例の3つのリクエストについて考えてみよう。今回は、すべてのHEADERSが送信された後に、クライアントはストリーム1 のリクエストをキャンセルしました。サーバーは応答を返す準備ができる前にこのRST_STREAMフレームを解析し、代わりにストリーム3と5にだけ応答します：

リクエストキャンセルは便利な機能です。例えば、複数の画像を含むウェブページをスクロールするとき、ウェブブラウザはビューポートの外にある画像をキャンセルすることができます。HTTP/2は、HTTP/1.1に比べてこの動作をより効率的にします。

キャンセルされたリクエストストリームは、ストリームのライフサイクルを急速に遷移します。END_STREAMフラグが1に設定されたクライアントのHEADERSは、状態を idleからopen、half-closedへと遷移させ、RST_STREAMは直ちにhalf-closedからcloseへと遷移させます。

ストリームの同時実行数制限に寄与するのは、open状態またはhalf-closed状態にあるストリームだけであることを思い出してください。クライアントがストリームをキャンセルすると、そのクライアントは即座に別のストリームをopenできるようになり、すぐに別のリクエストを送信できるようになる。これがCVE-2023-44487を機能させる要因となっています。

サービス拒否につながる急速なリセット

HTTP/2 リクエストキャンセルは、制限のない数のストリームを急速にリセットするために悪用される可能性があります。HTTP/2 サーバーがクライアントから送信された RST_STREAM フレームを処理し、十分に迅速に状態を取り壊すことができる場合、そのような迅速なリセットは問題を引き起こしません。問題が発生し始めるのは、片付けに何らかの遅延やタイムラグがある場合です。クライアントは非常に多くのリクエストを処理するため、作業のバックログが蓄積され、サーバーのリソースを過剰に消費することになります。

一般的なHTTPデプロイメントアーキテクチャは、HTTP/2プロキシやロードバランサーを他のコンポーネントの前で実行することです。クライアントリクエストが到着すると、それは素早くディスパッチされ、実際の作業はどこか別の場所で非同期アクティビティとして行われる。これにより、プロキシはクライアントのトラフィックを非常に効率的に扱うことができる。しかしながら、このような分離は、プロキシがプロセス中のジョブを整理することを困難にする可能性があります。したがって、このようなデプロイメントでは、急激なリセットの問題に遭遇する可能性が高くなってしまいます。

Cloudflareのリバースプロキシは、HTTP/2クライアントのトラフィックを処理する際、接続ソケットからデータをバッファにコピーし、バッファリングされたデータを順番に処理します。各リクエストが読み込まれると（HEADERSとDATAフレーム）、アップストリームサービスにディスパッチされます。RST_STREAMフレームが読み込まれると、リクエストのローカル状態が破棄され、リクエストがキャンセルされたことが上流に通知されます。バッファ全体が消費されるまで、この繰り返しを行います。しかしながら、このロジックは悪用される可能性があります。悪意のあるクライアントが膨大なリクエストの連鎖を送信し始め、接続の開始時にリセットされると、我々のサーバーはそれらすべてを熱心に読み、新しい着信リクエストを処理できなくなるほどアップストリームサーバーにストレスを与えてしまいます。

強調すべき重要な点は、ストリームの同時実行性だけでは、急激なリセットを緩和できないということです。サーバーがSETTINGS_MAX_CONCURRENT_STREAMSの値を選んだとしても、クライアントは高いリクエストレートを生成するためにリクエストを繰り返すことができます。

Rapid Reset 攻撃の詳細

以下は、合計1000リクエストを試みる概念実証クライアントを使用して再現された高速リセットの例です。テスト環境で443番ポートをlistenしています。トラフィックはWiresharkで解析し、HTTP/2トラフィックのみを表示するようにフィルタリングしています。pcapをダウンロードしてフォローしてください。

フレーム数が多いので、ちょっと見づらいですね。WiresharkのStatistics > HTTP2ツールで簡単な要約を得ることができます：

このトレースの最初のフレームであるパケット14は、サーバーのSETTINGSフレームであり、最大ストリーム同時実行数100をアドバタイズしています。パケット15では、クライアントはいくつかの制御フレームを送信し、その後急速にリセットされるリクエストを開始します。最初のHEADERSフレームは26バイト長で、それ以降のHEADERSはすべて9バイトです。このサイズの違いはHPACKと呼ばれる圧縮技術によるものです。合計で、パケット15はストリーム1051までの525のリクエストを含みます。

興味深いことに、ストリーム1051のRST_STREAMはパケット15に収まらないので、パケット16でサーバーが404応答で応答するのが見えています。それからパケット17でクライアントはRST_STREAMを送信し、残りの475リクエストの送信に移ります。

サーバーは100の同時ストリームをアドバタイズしていたが、クライアントが送信したパケットはいずれも、それよりも多くのHEADERSフレームを送信していたことに注意してください。クライアントはサーバーからの返送トラフィックを待つ必要はなく、送信できるパケットサイズによってのみ制限されていた。このトレースにはサーバーのRST_STREAMフレームは見られず、サーバーが同時ストリーム違反を観測しなかったことを示しています。

お客様への影響

上述したように、リクエストがキャンセルされると、上流サービスは通知を受け、そのリクエストに多くのリソースを浪費する前に、リクエストを中止することができる。今回の攻撃では、ほとんどの悪意のあるリクエストがオリジン・サーバーに転送されることはありませんでした。しかし、このような攻撃の規模が大きかったため、何らかの影響が生じています。

まず、リクエストの受信速度がこれまでにないピークに達したため、クライアントから502エラーのレベルが上昇したという報告がありました。これは、最も影響を受けたデータセンターで発生し、すべてのリクエストを処理するのに苦労しました。私たちのネットワークは大規模な攻撃にも対応できるようになっていますが、この脆弱性は私たちのインフラの弱点を露呈するものでした。詳細についてもう少し掘り下げてみます。当社のデータセンターのひとつにアクセスがあった場合、リクエストがどのように処理されるかに焦点を当てています：

Cloudflareのインフラストラクチャは、責任の異なるプロキシサーバのチェーンで構成されていることがわかります。特に、クライアントが HTTPS トラフィックを送信するために Cloudflare に接続すると、まず TLS 復号化プロキシに当たります。このプロキシは TLS トラフィックを復号化し、HTTP 1、2、または 3のトラフィックを処理した後、「ビジネスロジック」プロキシに転送します。このプロキシは、各顧客のすべての設定をロードし、リクエストを他のアップストリーム・サービスに正しくルーティングする役割を担っています。このプロキシは、L7攻撃緩和の処理をになっています。

この攻撃ベクターの問題点は、単一のコネクションの中で、非常に多くのリクエストを素早く送信することです。私たちがそれをブロックする機会を得る前に、それぞれのリクエストはビジネスロジックのプロキシに転送されなければなりませんでした。リクエストのスループットがプロキシのキャパシティより高くなるにつれて、これら2つのサービスを接続するパイプは、いくつかのサーバで飽和レベルに達していました。

これが発生すると、TLSプロキシは上流のプロキシに接続できなくなるため、最も深刻な攻撃時に "502 Bad Gateway "エラーが表示されるクライアントが生まれます。今日のところ、HTTPアナリティクスを作成するために使用されるログは、ビジネスロジックプロキシからも出力されることに注意することが重要です。その結果、これらのエラーはCloudflareのダッシュボードには表示されません。社内のダッシュボードによると、攻撃の初期波（緩和策を実施する前）にはリクエストの約1%が影響を受け、8月29日の最も深刻な攻撃では数秒間のピークが約12%に達しました。以下のグラフは、このようなエラーが発生していた2時間における比率を示しています：

この投稿で後ほど詳述するように、私たちはその後の数日間で、この数を劇的に減らすことに努めました。私たちのスタックの変更と、これらの攻撃のサイズを大幅に縮小するミティゲーションのおかげで、この数は今日、事実上ゼロとなっています。

499 エラーと HTTP/2 stream concurrency

一部の顧客から報告された別の症状は、499エラーの増加です。この原因は少し違っていて、この投稿で先に説明したHTTP/2接続の最大ストリーム同時実行数に関連しています。

HTTP/2の設定は、接続の開始時にSETTINGSフレームを使って交換されます。明示的なパラメータを受け取らない場合、デフォルト値が適用されます。クライアントがHTTP/2接続を確立すると、サーバーのSETTINGSを待つか(slow)、デフォルト値を想定してリクエストを開始します(fast)。SETTINGS_MAX_CONCURRENT_STREAMSでは、デフォルトは事実上無制限です（ストリームIDは31ビットの数値空間を使用し、リクエストは奇数を使用するため、実際の制限は1073741824です）。仕様では、サーバーが提供するストリーム数は100を下回らないことを推奨している。クライアントは一般的にスピードに偏っているため、サーバーの設定を待つ傾向がなく、ちょっとした競合状態が発生します。クライアントは、サーバーがどの制限を選ぶかについて賭けをすることになります。

1073741824ストリームに賭けるのは少しばかげています。その代わりに、多くのクライアントは、サーバーが仕様の推奨事項に従っていることを期待して、同時ストリームの発行を 100 個に制限することにしました。サーバーが 100 未満を選択すると、このクライアントのギャンブルは失敗し、ストリームがリセットされます。

サーバーが同時実行制限を超えてストリームをリセットする理由は数多くあります。HTTP/2は厳密であり、解析エラーまたはロジックエラーが発生した場合はストリームを閉じる必要があります。2019年、CloudflareはHTTP/2 DoS脆弱性に対応していくつかの緩和策を開発しました。これらの脆弱性のいくつかは、クライアントの不正な動作によって引き起こされ、サーバーがストリームをリセットします。このようなクライアントを取り締まる非常に効果的な戦略は、接続中のサーバーのリセット数をカウントし、それがしきい値を超えた場合に GOAWAY フレームで接続を閉じることです。正規のクライアントは接続中に1つまたは2つの間違いを犯す可能性がありますが、それは許容されます。間違いが多すぎるクライアントは、壊れているか悪意があるかのどちらかである可能性があり、接続を閉じることで両方のケースに対処できます。

CVE-2023-44487 によって可能になった DoS 攻撃に対応している間、Cloudflare は最大ストリーム同時実行数を64に削減しました。この変更を行う前は、クライアントが SETTINGS を待機せず、代わりに同時実行数 100 を想定していることを認識していませんでした。画像ギャラリーとしては、確かに、ブラウザーは接続の開始時にすぐに 100 件のリクエストを送信します。残念ながら、制限を超える 6個のストリームはすべてリセットする必要があったため、カウントの軽減がトリガーされました。これは、正規のクライアントでの接続を閉じ、ページの読み込みが完全に失敗することを意味しました。この相互運用性の問題を認識するとすぐに、最大ストリーム同時実行数を100に変更しました。

Cloudflare側からのアクション

2019年に、HTTP/2の実装に関連するいくつかのDoS脆弱性が発見されました。 Cloudflareは、これに対応して一連の検出と緩和策を開発、展開しました。CVE-2023-44487 は、HTTP/2脆弱性の別の現れです。ただし、それを軽減するために、クライアントから送信された RST_STREAMフレームを監視し、悪用された場合に接続を閉じるように既存の保護を拡張することができました。正当なクライアントによる RST_STREAM の使用は影響を受けません。

直接的な修正に加えて、サーバーのHTTP/2フレーム処理とリクエストディスパッチコードにいくつかの改善を実装しました。さらに、ビジネスロジックサーバーのキューイングとスケジューリングが改善され、不必要な作業が削減され、キャンセルの応答性が向上しました。これらを組み合わせることで、さまざまな潜在的な悪用パターンの影響が軽減され、飽和する前にリクエストを処理するための余地がサーバーに与えられます。

攻撃を早期に軽減する

Cloudflareは、より安価な方法で非常に大規模な攻撃を効率的に軽減するシステムをすでに導入していました。そのうちの1つは「IP刑務所」と名付けられています。ハイパーボリューム攻撃の場合、このシステムは攻撃に参加しているクライアントIPを収集し、IPレベルまたはTLSプロキシで、攻撃されたプロパティへの接続を阻止します。ただし、このシステムが完全に効果を発揮するには数秒かかります。この貴重な数秒間、オリジンはすでに保護されていますが、インフラストラクチャは依然としてすべてのHTTPリクエストを吸収する必要があります。この新しいボットネットには事実上立ち上げ期間がないため、問題になる前に攻撃を無効化できる必要があります。

これを達成するために、当社はIP刑務所システムを拡張してインフラストラクチャ全体を保護しました。IP が「隔離」されると、攻撃された資産への接続がブロックされるだけでなく、対応するIPが他のドメインに対して HTTP/2を使用することもCloudflare内部ではしばらくの間禁止されます。 HTTP/1.xを使用すると、このようなプロトコルの悪用は不可能であるため、攻撃者が大規模な攻撃を実行する能力は制限されますが、同じIPを共有する正規のクライアントでは、その間、ごくわずかなパフォーマンスの低下しか見られません。IPベースの緩和策は非常に鈍感なツールです。そのため、その規模でこれを使用する場合は細心の注意を払い、誤検知を可能な限り回避するように努める必要があります。さらに、ボットネット内の特定のIPの寿命は通常短いため、長期的な緩和策は良いことよりも害を及ぼす可能性が高くなります。次のグラフは、私たちが目撃した攻撃におけるIPの変化を示しています。

ご覧のとおり、特定の日に発見された多くの新しい IP は、その後すぐに消えてしまいます。

これらすべてのアクションは HTTPSパイプラインの開始時に TLSプロキシで実行されるため、通常の L7軽減システムと比較してかなりのリソースが節約されます。これにより、これらの攻撃をよりスムーズに乗り越えることができ、現在では、これらのボットネットによって引き起こされるランダム502エラーの数はゼロにまで減少しました。

可観測性の改善

私たちが変更を加えているもう 1 つの面は、可観測性です。顧客分析に表示されずにエラーをクライアントに返すのは満足のいくものではありません。幸いなことに、最近の攻撃のずっと前から、これらのシステムを徹底的に見直すプロジェクトが進行中です。最終的には、ビジネスロジックプロキシに依存してログデータを統合して出力するのではなく、インフラストラクチャ内の各サービスが独自のデータをログに記録できるようになります。この事件はこの取り組みの重要性を浮き彫りにし、私たちは努力を倍増させています。

また、接続レベルのログ記録の改善にも取り組んでおり、DDoS軽減機能を向上させるために、このようなプロトコルの悪用をより迅速に発見できるようになります。

まとめ

これは最新の記録破りの攻撃でしたが、これが最後ではないことはわかっています。攻撃がますます巧妙化する中、Cloudflare は新たな脅威を積極的に特定するために絶え間なく取り組み、グローバルネットワークに対策を展開し、数百万の顧客が即座に自動的に保護されるようにしていきます。

Cloudflareは、2017年以来、すべてのお客様に無料、従量制、無制限のDDoS保護を提供してきました。さらに、あらゆる規模の組織のニーズに合わせて、さまざまな追加のセキュリティ機能を提供しています。自分が保護されているかどうかわからない場合、またはどのように保護されるのか知りたい場合は、お問い合わせください。