Cloudflareは、毎秒6,000万件以上のHTTPリクエストをグローバルに処理しており、その内約70%をTCP（残りはQUIC/UDP）接続で受信しています。理想的には、Cloudflareへのすべての新しいTCP接続で、少なくとも1つのリクエストが成功してデータ交換が行われるはずですが、現実はそうではありません。実際、世界全体で約20%の新しいTCP接続が、リクエストが完了する前や最初のリクエストの直後に、タイムアウトやTCPの「ABORT」メッセージによってクローズしています。
この記事では、さまざまな理由で、有用なデータ交換が行われる前に、サーバーから予期せず停止したように見える接続について探ります。接続は通常、クライアント側から終了しますが、調査を進める中で、第三者の介入によっても接続がクローズさせられることもあることが明らかになりました。本日、Cloudflare Radarに新しいダッシュボードとAPIエンドポイントが公開されました。れにより、リセットやタイムアウトによって最初の10個の受信パケット以内で終了したTCP接続をほぼリアルタイムでその状況を確認できるようになります。この記事では、これを「異常」なTCP接続と呼びます。この異常な動作を分析することで、スキャン、接続の改ざん、DoS攻撃、接続の問題、その他の動作に関する洞察を得ることができます。
Radar経由でこのデータを生成し共有することができるようになったのは、私たちが接続改ざんに関する世界的な調査を行ってきた結果と言えるでしょう。技術的な詳細については、査読済みの研究やその対応するプレゼンテーションをご覧ください。データの利用方法と解釈のしかた、ならびに関係者以外も私たちのアプローチを再現できるように、検出メカニズムをどのように設計し展開したかについての入門書をお読みください。
まず、通常のTCP接続と異常なTCP接続の見分け方について説明します。
TCP接続の確立からクローズまで
伝送制御プロトコル（TCP）は、インターネット上の2つのホスト間でデータを確実に送信するためのプロトコルです（RFC 9293）。TCP接続は、接続の確立からデータ転送、接続のクローズまで、いくつかの異なる段階を経て進行します。
TCP接続は、3ウェイハンドシェイクで確立されます。ハンドシェイクは、一方（クライアント）が「SYN」フラグを付けたパケットを送信して接続プロセスを初期化することから始まります。サーバーは、クライアントから送信された接続開始の「SYN」を「ACK」フラグで承認した「SYN+ACK」パケットで応答します。初期化パケットとその確認応答の両方には、追加の同期情報が含まれています。最後に、クライアントがサーバーの「SYN+ACK」パケットに対して最終的な「ACK」パケットを送り、ハンドシェイクが完了します。
これが完了すると、この接続を使用してデータ転送を開始することができます。通常、クライアントは最初のデータを含むパケットにPSHフラグを設定し、サーバーのTCPスタックにデータを即座にアプリケーションに渡すように指示します。両者は、接続が不要になるまでデータの転送と受信確認を続け、その後、接続がクローズします。
RFC 9293には、TCP接続をクローズする2つの方法について記載されています：
通常のTCP接続のクローズ手順では、FIN交換が使用されます。一方がデータの送信が完了したことを示すために、FINフラグが設定されたパケットを送信します。受信側がそのFINパケットを確認すると、その方向の接続をクローズします。接続の各方向は個別にクローズする必要があるため、確認側はデータの送信を終了すると、自分自身のFINパケットを送信してクローズします。
ABORTまたは「RESET」信号では、一方がRSTパケットを送信し、もう一方に接続を即座にクローズして接続状態を破棄するよう指示します。RESET信号は通常、回復不可能なエラーが発生した場合に送信されます。
FINで正しくクローズするまでの接続の全存続時間を、次のシーケンス図に示します。
通常のTCP接続は、3ウェイハンドシェイクで始まり、FINハンドシェイクで終了します
その他にも、TCP接続はタイムアウトによって終了することがあります。タイムアウトには、データや確認応答を受け取らずに接続がアクティブでいられる最大の時間を指定します。たとえば、Keep-Aliveメッセージを使用することで、アイドル状態の接続をオープンした状態に維持することができます。特に設定を変更しない限り、RFC 9293で指定されているグローバルデフォルトの期間は5分です。
クライアント側からのリセット要求またはタイムアウトのいずれかでクローズした場合、私たちはこのTCP接続を「異常」と判断します。
異常な接続の原因
異常なTCP接続自体が問題であるとは限りませんが、特に接続の初期（データ転送前）の段階で発生した場合は、より大きな問題の兆候となる可能性があります。以下に、リセットやタイムアウトが起こる可能性のある潜在的な理由の一部を紹介します。
スキャナー：インターネットスキャナーは、特定のポートでサーバーが応答するかを調べるためにSYNパケットを送信することがありますが、サーバーからの応答を受けた後に接続を適切に終了しないことがあります。
アプリケーションの突然のシャットダウン：アプリケーションは、接続が不要になった場合、突然クローズすることがあります。たとえば、Webブラウザでタブを閉じた時に接続を終了するためにRSTが送信されたり、デバイスの電源が切れたり接続が切れて接続がタイムアウトすることもあります。
ネットワークエラー：不安定なネットワーク状態（たとえば、ケーブル接続の切断により接続タイムアウトが発生することがあります）
攻撃：悪意のあるクライアントによって異常な接続と見える攻撃トラフィックが送信されることがあります。例えば、SYNフラッド（ハーフオープン）攻撃では、攻撃者は標的とするサーバーに対してSYNパケットを繰り返し送信し、サーバーにこれらのハーフオープン接続を維持させてリソースを過負荷状態にしようとします。
改ざん：クライアントとサーバー間のパケットを傍受できるファイアウォールなどの中間装置は、パケットを破棄することで通信相手にタイムアウトを引き起こすことがあります。ディープパケットインスペクション（DPI）機能を持つ中間装置は、TCPプロトコルが未認証かつ暗号化されていないことを利用して、パケットを注入して接続状態を破棄させることもできます。接続改ざんの詳細については、付随するブログ記事を参照してください。
異常な接続のネットワークの規模と根本理由を理解することで、障害を軽減し、より堅牢で信頼性の高いネットワークを構築することができます。私たちは、これらの洞察を公開することで、世界中のネットワークの透明性と説明責任が向上することを期待しています。
データセットの使用方法
このセクションでは、3つのユースケース（既知の動作の確認、フォローアップの新しい調査対象の模索、ネットワーク動作の経時的な変化を把握するための長期的な研究）を広く説明することで、TCPのリセットとタイムアウトのデータセットを解釈する方法と例を提供します。
各例では、プロットの線が異常な接続がクローズされた接続の段階に対応しており、これが異常の原因を探る貴重な手がかりとなります。各着信接続は、以下のいずれかの段階に分類されます。
Post-SYN（ハンドシェイクの途中）：サーバーがクライアントのSYNパケットを受信した後の接続リセットまたはタイムアウト。サーバーは応答していますが、リセットまたはタイムアウトの前に、確認ACKパケットがクライアントから返されていません。パケットスプーフィングはこの接続段階でよく行われるため、この接続がどこから行われたかについて信頼性のある情報を得ることは困難です。
Post-ACK（ハンドシェイク直後）：ハンドシェイクが完了して、接続が正常に確立された後の接続リセットまたはタイムアウト。それ以降のデータは（たとえ送信されたとしても）当社のサーバーに届いていません。
Post-PSH（最初のデータパケット後）：サーバーがPSHフラグが設定されたパケットを受信した後の接続リセットまたはタイムアウト。PSHフラグは、TCPパケットにアプリケーションへ配信する準備ができたデータ（TLS Client Helloメッセージなど）が含まれていることを示します。
Later（複数のデータパケットが送信された後）：クライアントからの最初の10パケット以内の接続リセット（サーバーが複数のデータパケットを受信した後）。
None：その他すべての接続。
正当な接続に焦点を当てるため、このデータセットは、Cloudflareの攻撃緩和システムによって接続が処理・フィルタリングされた後に作成されています。データセットの構築方法の詳細については、以下を参照してください。
自己評価から始める
まず、読者の皆様には、Radarのダッシュボードにアクセスして、全世界の結果、自国の結果、ISPの結果を確認していただくようお勧めします。
全世界では、以下に示すように、Cloudflareネットワークへの新しいTCP接続の約20%が、クライアントからの最初の10パケット以内にリセットまたはタイムアウトによってクローズされています。この数値は驚くほど高いように思われますが、以前の研究とも一致しています。後述するように、リセットとタイムアウトの発生率は国やネットワークによって大きく異なるため、この変動は世界平均の中では見逃されてしまいます。
私の母国である米国では、異常な接続率は世界平均よりもわずかに低くなっています。これは、主にPost-ACKとPost-PSHの段階でクローズされる接続の確率が低いためです（この段階は、中間装置での改ざん動作がより多く見受けられる場所です）。Post-SYNの割合が高いのはほとんどのネットワークで典型的で、スキャンが原因となっていますが、クライアントのIPアドレスを偽装したパケットも含まれることがあります。同様に、Laterの接続段階（最初のデータ交換後から最初の10パケット以内）での接続リセット率が高いのは、ブラウザのタブが閉じられた後にRSTを使用して不要なTCP接続を閉じるなど、人間の操作に応答しているアプリケーションである可能性があります。
私の利用しているISPであるAS2773（Cox Communications）は、米国全体に匹敵する割合を示しています。これは、米国で事業展開しているほとんどの家庭用ISPで一般的な傾向です。
これに対して、Googleのクローラーやフェッチャーを多く運用しているAS15169（Google LLC）は、Laterの接続段階でリセットの割合が大幅に低いことを示しています。これは、これは、ブラウザタブを閉じるなどの人間の操作に依存しない、自動化されたトラフィックが多いことが原因と考えられます。
実際に、当社のボット検出システムは、AS15169からのHTTPリクエストの99%以上を自動化されたものとして分類しています。これは、Radar上でさまざまなデータを照合することの重要性を示しています。
Radarに表示されるほとんどの攻撃と同様に、新しい異常な接続データセットは受動的です。観測可能なイベントのみを報告し、その原因については特定しません。そのため、上記のGoogleのネットワークに関するグラフは、次に説明する観測結果の裏付けとして役立ちます。
1つのビューで傾向を発見し、より多くのビューで裏付け
私たちの当社の受動的な測定アプローチは、Cloudflareの規模で機能していますが、それだけで根本原因や事実を特定することはできません。特定の段階で接続がクローズされた理由、特に、パケットのリセットやタイムアウトによってクローズされた場合、多くの妥当な理由があります。このデータソースだけに頼って説明しようとすると、推測することしかできません。
しかし、この制限は、有効な測定値など他のデータソースと組み合わせることで克服できます。たとえば、OONIやCensored Planetからのレポートや、現場のレポートと裏付けさせることで、より包括的な理解が得られます。したがって、TCPリセットおよびタイムアウトデータセットの主要な使用事例の1つは、以前に文書化された現象の規模と影響を理解することです。
インターネット規模の測定プロジェクトの裏付け
AS398324を見ると、接続の半数以上がPost-SYN段階で異常として表示されており、何か重大な問題があるように思えます。しかし、このネットワークは、インターネットスキャン会社CensysのCENSYS-ARIN-01であることが判明しました。Post-SYNの異常は、ネットワーク層のスキャンの結果である可能性があります。この場合、スキャナーはサーバーを探るために単一のSYNパケットを送信しますが、TCPハンドシェイクを完了しません。また、Laterの異常が高い割合で発生していることもあり、自動化された接続と分類される接続のほぼ100の割合が示すように、アプリケーション層のスキャンを示す可能性があります。
実際、AS15169と同様に、AS398324からのリクエストの99%以上を自動化しているものと分類しています。
ここまで、スクリプト化されたトラフィックや自動化されたトラフィックを大量に生成するネットワークについて見てきました。次は、もっと広い範囲を見てみましょう。
接続の改ざんの裏付け
このデータセットの出発点は、HTTPSインターセプションに関する私たちの取り組みと同様の精神で、アクティブな接続の改ざんを理解し検出するための研究プロジェクトでした。私たちがこのプロジェクトを始めた理由については、こちらのブログ記事で詳しく説明しています。
接続を強制的にクローズする広く知られた手法の一つにリセットインジェクションがあります。リセットインジェクションでは、宛先への経路の途中にある中間装置がパケットのデータ部分を検査し、中間装置が禁止されたドメイン名へのパケットを検知すると、偽造されたTCPリセット（RST）パケットを一方または両方の通信当事者に挿入して、接続を中断させます。中間装置が最初に禁止されたパケットを破棄しなかった場合、サーバーはクライアントからのパケット（これが中間装置の改ざんを引き起こした可能性があるTLS Client HelloメッセージやServer Name Indication（SNI）フィールドを含む）を受け取った後、すぐに偽のRSTパケットを受け取ることになります。
TCPリセットとタイムアウトデータセットにおいて、リセットインジェクションによって中断された接続は、通常、Post-ACK、Post-PSH、またはLaterの異常として表示されます（ただし、すべての異常がリセットインジェクションによるものとは限りません）。
例えば、リセットインジェクション技術は、いわゆる「中国のグレートファイアウォール（GFW）」で知られており、一般的に関連付けられています。実際、中国に地理的に位置するIPから発信される接続におけるPost-PSHの異常を見ると、世界平均よりも高い割合が見られます。しかし、中国の個々のネットワークを見ると、Post-PSHの割合は大きなばらつきがあります。これは、おそらく移動するトラフィックの種類や技術の実装の違いに起因すると思われます。対照的に、中国の主要なASのほとんどで、Post-SYNの異常発生率が一貫して高く、スキャナー、偽装SYNフラッド攻撃、または副次的な影響を伴う残存的なブロッキングが考えられます。
AS4134（CHINANET-BACKBONE）は、他の中国のASよりもPost-PSHの異常率は低いものの、それでも世界平均を十分に上回っています。
ネットワークAS9808（CHINAMOBILE-CN）とAS56046（CMNET-Jiangsu-AP）はどちらも、Post-PSH異常に一致する接続の割合が2桁台を示しています。
接続の改ざんの詳細については、深掘りしたブログ記事をご覧ください。
フォローアップ研究のための新たな知見とターゲットの調達
TCPリセットとタイムアウトのデータセットも「突出」しており、さらなる調査に値するネットワークを見つけるための手掛かりとなり、新しいネットワークの動作やこれまでに研究されなかったネットワークの動作を特定する情報源にもなり得ます。
属性不能なZMapスキャン
ここで説明できないことがあります。毎日同じ18時間の間に、英国のクライアントからの接続の10%以上が最初のSYNパケットを超えて進行することはなく、ただタイムアウトしています。
内部検査の結果、Post-SYNの異常のほぼすべてが、AS396982（GOOGLE-CLOUD-PLATFORM）でZMapを使用したスキャナーに起因することがわかりました。これは、全IPアドレス範囲に対するフルポートスキャンと思われます（ZMapクライアントは後で説明するZMapの責任ある自己識別機能に基づき、自らを適切に識別しています）。同様のスキャントラフィックが、米国に位置するAS396982のIPプレフィックスからのも確認されています。
モバイルネットワークでのゼロレーティング
国ごとの異常発生率を簡単に見てみると、興味深い発見がいくつかあります。例えば、メキシコからの接続を見ると、接続の改ざんに関連することが多いPost-ACKとPost-PSHの異常の発生率が世界平均よりも高くなっています。また、メキシコの接続状況は、この地域の他のものと類似しています。しかし、メキシコでは、「政府や他の当事者がインターネットのコンテンツをブロックしたり、フィルタリングしたりしているという文書的記録は存在しません」。
メキシコにおけるHTTPトラフィック量の上位ASを見ると、AS28403（RadioMovil Dipsa、SA de CV、Telcelとして運用）からの接続の50%近くが、TCPハンドシェイク完了直後（Post-ACK接続段階）でリセットやタイムアウトで終了していることがわかりました。この段階では、Cloudflareに到達する前に中間装置がデータパケットを確認してドロップした可能性があります。
このような動作の一因として考えられるのは「ゼロレーティング」です。これは、携帯ネットワークのプロバイダが特定のリソース（例えばメッセージングやSNSアプリ）へのアクセスを無料で提供する仕組みです。ユーザーがデータ転送制限を超えた場合、プロバイダはゼロレートの宛先へのトラフィックを許可し、それ以外のリソースへの接続をブロックする可能性があります。
ゼロレートポリシーを適用するために、ISPはTLS Server Name Indication（SNI）を使用して、接続をブロックするか許可するかを判断する場合があります。SNIは、TCPハンドシェイクの直後にデータを含むパケットとして送信されます。したがって、ISPがSNIを含むパケットをドロップすると、サーバーはクライアントからのSYNパケットとACKパケットを受け取るだけで後続のパケットは受け取りません。これはPost-ACK接続の異常と一致します。
データセットに同様のプロファイルを持つもう一つの国であるペルーに目を向けると、Post-ACKとPost-PSHの異常の発生率がメキシコに比べてさらに高いことがわかります。
特定のASに焦点を当てると、AS12252（Claro Peru）は、メキシコのAS28403と同様にPost-ACKの異常発生率が高いことがわかります。どちらのネットワークも同じ親会社であるAmérica Móvilが運営しているため、同様のネットワークポリシーとネットワーク管理技術が採用されていると考えられます。
興味深いことに、AS6147（Telefónica Del Perú）は、Post-PSHの接続異常の発生率が高いことを示しています。これは、このネットワークがネットワーク層で異なる技術を使用してポリシーを適用していることを示している可能性があります。
経時的な変化、長期的な視野
持続的パッシブ測定の最も強力な点の1つは、より長期間にわたってネットワークを測定できることです。
インターネットの遮断
2024年6月のブログ記事「シリア、イラク、アルジェリアで発生した最近のインターネットの遮断の検証」で、Cloudflareのネットワークの視点から、試験に関連する全国のインターネット遮断の状況をお伝えしました。当時、TCPリセットとタイムアウトのデータセットの準備を行っていたため、外部レポートを確認し、シャットダウンに使用される具体的な手法について知見を得るのに役立ちました。
行動の変化の例として、「過去に遡って」試験に関連するブロックが発生した当時を観察することができます。シリアでは、試験関連の遮断の間、Post-SYNの異常の発生率が急増したことがわかります。実際、これらの期間中にトラフィック（SYNパケットを含む）はほぼ完全に減少しています。
7月最終週から始まった2回目の遮断もかなり顕著です。
イラクからの接続を見ると、試験関連の遮断に関するCloudflareの考え方はシリアと似ており、Post-SYNに複数のスパイクが発生していますが、それほど顕著ではありません。
試験による遮断に関するブログでは、アルジェリアが試験期間中にインターネットのアクセスを制限する際、より細かな対応を取ったことが説明されています。インターネットを完全にシャットダウンするのではなく、アルジェリアは特定の接続をターゲットにしたことを示唆する証拠があります。実際、試験期間中にPost-ACKの接続異常が増加しています。この動作は、中間装置が禁止されているコンテンツを含むパケットを選択的に破棄し、他のパケット（最初のSYNやACKなど）には手を加えない場合に見られる動作です。
上記の例は、このデータが他の信号と関連付けることで最も有用になることを強調しています。このデータはAPIを通じて利用可能なので、関係者以外もより詳細な分析が可能です。当社の検出技術は、次に説明するように、他のサーバーやオペレーターにも移転できます。
異常なTCP接続を大規模に検出する方法
このセクションでは、私たちがTCPリセットとタイムアウトのデータセットをどのように構築したかについて説明します。Cloudflareのグローバルネットワークは大規模であるため、データ処理と分析に独自の課題があります。この記事の読者が私たちの方法論を理解し、データセットを解釈し、他のネットワークやサーバーで同様の仕組みを再現できるようにするために、私たちのテクニックを紹介します。
私たちの方法論をまとめると、以下のようになります：
クライアント向けサーバーに到着した接続のサンプルを記録します。このサンプリングシステムは完全にパッシブであり、トラフィックを復号したりすることはできず、ネットワーク上で送信された既存のパケットにのみアクセスできます。
キャプチャしたパケットから接続を再構築します。この設計の特徴は、クライアントからサーバーへの一方向だけを観察すればよいことです。
リセットまたはタイムアウトによって終了した異常な接続の署名セットと、再構築された接続を照合します。これらの署名は、接続段階と、文書と観察に基づく特定の動作を示すタグのセットの2つの部分で構成されています。
これらの設計の選択により、暗号化されたパケットが安全に保たれ、送信先サーバーへのアクセスを必要とせずに、どこでも再現できるようになります。
まず、接続をサンプリングします
私たちの主な目標は、Cloudflareのネットワークに到着するすべての接続を広く把握できる仕組みを作ることです。各クライアント向けサーバーでトラフィックをキャプチャすることもできますが、これでは規模を拡大できません。また、どこで、いつ見るべきかを正確に知る必要があるため、継続的なインサイトを得ることが困難になります。そこで、Cloudflareのすべてのサーバーから接続をサンプリングし、中央の場所に記録してオフラインで分析することにしました。
ここで、最初の壁にぶつかりました。Cloudflareの分析システムが使っている既存のパケットロギングパイプラインは、個々のパケットをログに記録しますが、接続は多数のパケットで構成されています。接続の異常を検出するには、特定の接続内のすべての、または少なくとも十分な数のパケットを見る必要がありました。幸いなことに、CloudflareのDDoSチームがDDoS攻撃に関与するパケットを分析するために構築した柔軟なログシステムを利用し、2つのiptablesルールを巧妙に組み合わせることで目標を達成することができました。
一つ目のiptablesルールは、サンプリングのために新しい接続をランダムに選択してマークします。私たちは、受信TCP接続10,000件ごとに1件の割合でサンプリングすることにしました。この数字に特別な意味はありませんが、Cloudflareの規模では、データ処理と分析パイプラインに負担をかけることなく、十分に捕捉できることとのバランスになっています。iptablesルールは、DDoS軽減システムを通過した後のパケットにのみ適用されます。TCP接続は長期間存続することがあるため、新しいTCP接続のみをサンプリングしています。サンプリングする接続をマーキングするためのiptablesルールは以下の通りです。
-t mangle -A PREROUTING -p tcp --syn -m state
--state NEW -m statistic --mode random
--probability 0.0001 -m connlabel --label <label>
--set -m comment --comment "Label a sample of ingress TCP connections"
これを詳しく説明すると、ルールはパケットを修正するための、受信パケットを処理するチェーン（-A PREROUTING）のmangleテーブルにインストールされます。接続の前の状態を除いた（--state NEW）SYNフラグが設定されたTCPパケットのみが対象となります（-p tcp--syn）。フィルターは、1万個のSYNパケットごとに1つを抽出し（-m statistic –mode random --probability 0.0001）、接続にラベルを適用します（-m connlabel --label<label> --set）。
2つ目のiptablesルールは、接続内の後続のパケットを最大10パケットまでログに記録します。繰り返しになりますが、「10」という数字自体に特別な意味はありませんが、通常、接続の確立、後続のリクエストパケット、および予期せず終了する接続のリセットを十分に捕捉できる数です。
-t mangle -A PREROUTING -m connlabel --label
<label> -m connbytes ! --connbytes 11
--connbytes-dir original --connbytes-mode packets
-j NFLOG --nflog-prefix "<logging flags>" -m
comment --comment "Log the first 10 incoming packets of each sampled ingress connection"
このルールは、前述のルールと同じチェーンにインストールされます。サンプリングされた接続からのパケットだけに一致し（-m connlabel --label <label>）、各接続の最初の10パケットのみを対象とします（-m connbytes ! --connbytes 11 --connbytes-dir original --connbytes-mode packets）。一致したパケットはNFLOGに送られ（-j NFLOG --nflog-prefix "<logging flags>"）、ログシステムで取得され、オフライン分析のために一元化された場所に保存されます。
サンプリングされたパケットから接続を再構築する
サーバーでログに記録されたパケットは、分析パイプラインの一部としてClickHouseのテーブルに挿入されます。ログに記録された各パケットは、データベース内の個別の行に保存されます。次なる課題は、さらなる分析のために、パケットを対応する接続に再構成することです。その前に、この分析の目的のために、「接続」が何であるかを定義する必要があります。
私たちは、接続の定義に通常のネットワーク5タプル（プロトコル番号、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号）を使用していますが、いくつかの調整を加えています。
接続の受信側（クライアントからサーバーへの通信）のパケットのみをサンプリングしているため、サーバーからクライアントへの応答パケットはありませんが、ほとんどの場合、サーバーの応答内容はサーバーの設定を基に推測できるため、受信パケットだけで異常なTCP接続の動きを把握することが可能です。
ClickHouseのデータセットを15分を一纏めに照会し、その間隔内で同じネットワーク5タプルを共有するパケットをグループ化します。そのため、クエリ間隔の終わりに向けて接続が切り捨てられる可能性があります。接続タイムアウトを分析する際、最新のパケットタイムスタンプがクエリの遮断の10秒以内にある不完全なフローは除外されます。
リセットとタイムアウトは新しい接続に影響を与える可能性が高いため、新しいTCPハンドシェイクの開始を示すSYNパケットで始まるパケットシーケンスのみを対象にします。そのため、長期的な接続は除外されます。
ロギングシステムは正確なパケットの到着時刻を保証しないため、到着順ではなく、到着したパケットのセットのみを考慮します。一部のケースでは、TCPシーケンス番号からパケットの順序を判断することができますが、結果に大きな影響はありません。
分析時のノイズを低減するために、複数のSYNパケットを持つ接続のごく一部をフィルタリングしています。
接続の定義方法に関する上記の条件を使用して、分析パイプラインをより詳細に説明する準備ができました。
接続クローズイベントを各段階にマッピング
TCP接続は、接続の確立から最終的なクローズまでのいくつかの段階を経て進行します。異常な接続がどの段階で終了したかは、異常が発生した理由を知る手掛かりを提供します。サーバーで受信したパケットの各着信接続を上記で詳細に説明した4つの段階「Post-SYN」、「Post-ACK」、「Post-PSH」、「later」の1つに分類します。
接続が終了する段階だけでも、さまざまなネットワークからの異常なTCP接続に関する有用な洞察を提供しており、これは現在Cloudflare Radarで表示されます。しかし、場合によっては、より具体的な署名と接続を照合することで、より深い洞察を提供できることもあります。
より具体的な接続動作を説明するためにタグを適用
上記のような接続の各段階へのグループ化は、接続内のパケットのTCPフラグのみに基づいて行われます。ですが、パケットの到着間隔やTCPフラグの正確な組み合わせ、他のパケットフィールド（IP識別番号、IP TTL、TCPシーケンス番号および確認応答番号、TCPウィンドウサイズなど）を考慮することで、特定の動作に対するより詳細に照合することができます。
たとえば、一般的なZMapスキャナーソフトウェアは、生成するSYNパケットのIP識別フィールドを54321に、TCPウィンドウサイズを65535に修正します（ソースコード）。ネットワークに到着したこれらのフィールドが設定されているパケットを見ると、そのパケットはZMapを使用したスキャナーによって生成された可能性が高いと考えられます。
タグは、改ざんを行う中間装置の既知の署名と接続を一致させるためにも使用できます。多数のアクティブな測定作業（Weaver、Sommer、Paxsonなど）の大部分では、クライアントによって送信された他のパケットとは異なるIP TTLフィールドを設定したり、RSTパケットとRST+ACKパケットの両方を送信するなど、リセットパケットの注入によって接続を中断する際に、一部のミドルボックスの展開が一貫した動作を示すことが確認されています。具体的な接続改ざんの特徴の詳細については、ブログ記事と査読付き論文を参照してください。
現在、私たちは以下のタグを定義しており、時間をかけて改良し、拡張していく予定です。一部のタグは、以下の階層的な表示でその関係を示すように、他のタグが設定されている場合にのみ適用されます（例えば、finタグはresetタグが設定されている場合にのみ適用されます）。
timeout：タイムアウトによる終了reset：リセットによる終了（RSTフラグが設定されたパケット）fin：少なくとも1つのFINパケットを1つまたは複数のRSTパケットとともに受信した
single_rst：単一のRSTパケットで終了multiple_rsts：複数のRSTパケットで終了acknumsame：RSTパケットの確認応答番号がすべて同一（ゼロ以外）acknumsame0：RSTパケットの確認応答番号がすべてゼロacknumdiff：RSTパケットの確認番号が異なる（すべてゼロ以外）acknumdiff0：RSTパケットの確認番号が異なる（1つがゼロ）
single_rstack：単一のRST+ACKパケット（RSTとACKフラグの両方が設定）で終了multiple_rstacks：複数のRST+ACKパケットで終了rst_and_rstacks：RSTパケットとRST+ACKパケットの組み合わせで終了
zmap：SYNパケットがZMapスキャナーで生成されたものと一致
現在、接続タグは現在、RadarダッシュボードとAPIには表示されませんが、今後この追加機能をリリースする予定です。
今後の展開は？
Cloudflareの使命は、より良いインターネットの構築を支援することであり、透明性と説明責任はその使命の重要な部分であると考えています。私たちが共有する洞察とツールが、世界中の異常なネットワーク挙動の解決に役立つことを願っています。
現在のTCPリセットとタイムアウトのデータセットは、ネットワーク事業者、研究者、そしてインターネット市民全体にとってすぐに役立つはずですが、ここで終わりではありません。今後、追加したい以下のような改善点がいくつかあります。
Cloudflareからお客様の配信元サーバーへの接続に知見を拡大する。
現在、世界中のCloudflareに対するHTTPリクエストの30%以上に使用されているQUICのサポートを追加する。
このブログに興味を持っていただけた場合、接続の改ざんについて深く掘り下げたブログ記事や論文をお読みいただき、Cloudflare RadarのTCPリセットとタイムアウトのダッシュボードとAPIについて調べることをお勧めします。ご質問やご意見がございましたら、radar@cloudflare.comまでお問い合わせください。