2015年のGitHub「Great Cannon」DDoSが、経路上コード注入の説明責任を問う試金石となった理由

要約

GitHubは、2015年3月26日02時ごろ（UTC）にDDoSが始まり、当時の同社史上最大規模だったと説明した。また、無関係な人々のブラウザーがGitHubへの大量の要求に利用されたと報告した。[1]
GreatFireは、それ以前の3月17日から自らのサービスが大量の要求を受けていたと述べ、後にBaidu Analyticsに関連する資源への応答が悪性JavaScriptへ置き換えられたと主張した。GreatFireは中国当局に帰属させた一方、Baiduは自社製品が侵害されたとの見方を否定した。[7][8]
Citizen Labなどの研究者は、暗号化されていないHTTP通信を選択的に捕捉し、別の応答を差し込む能力を持つシステムを観測した。そのシステムをGreat Cannonと呼び、中国政府による運用が有力との評価を示したが、公開研究は法的に確定した帰属や個人の指揮命令系統を証明していない。[2][3][4][5]
参加したブラウザーは、通常のボットネット端末のように事前侵害されていたとは限らない。注入されたコードを一時的に実行し、自身の正規の送信元アドレスから要求を送ったとみられる。
この機構は、送信元を偽る反射型攻撃とは異なる。そのため、送信元アドレス検証は依然重要であるものの、この種の実在するブラウザー通信を単独で排除する手段にはならない。[6][11][12][13][14][17]
認証付き暗号化は、経路上で応答を気づかれずに置き換える難度を大きく上げる。ただし、通信遮断、経路操作、端末侵害、接続妨害、別方式のDDoSまで一括して防ぐものではない。[15][16]
説明責任は、GitHubだけに集中しない。経路を管理する事業者、外部資源を配信または埋め込むサイト、ブラウザーベンダー、トランジット事業者、緩和サービス事業者には、それぞれ異なる観測可能性と制御権がある。
DNS、アドレス登録、リポジトリ名、ホスティング契約、ステータス表示は、意図された関係を示す重要な記録である。しかし、利用者が実際に受け取り実行した内容の真正性までは証明しない。
持続的な対策には、複数地点からの応答比較、暗号化状態、経路状況、ブラウザー動作、エッジ側の分類、緩和措置とサービス影響を、一つの時系列で結び付ける証拠が必要である。

規模よりも重大だった「制御点」

2015年3月、GitHubは大規模なDDoSの標的となった。しかし、この事件をネットワーク基盤の説明責任という観点から重要にしたのは、単純な通信量の大きさではない。公開された技術分析によれば、攻撃を生み出す主要な制御点は、GitHubのサーバーにも、参加した利用者の端末にもなく、第三者のウェブ資源が利用者へ届くまでの経路上にあった。

利用者は、別のウェブサイトを普通に閲覧していただけかもしれない。そのページが暗号化されていない外部資源を読み込むと、経路上のシステムが正規の内容とは異なるJavaScriptを返し、ブラウザーにGitHub上の特定ページへ繰り返し要求を送らせたと研究者は説明した。利用者がGitHubを攻撃しようと判断したわけではない。端末が恒久的に乗っ取られていたとも限らない。それでも、ブラウザーから発生した接続は実在し、送信元アドレスも通常の利用者のものだった。

ここに、従来のDDoS像では捉えにくい責任の分裂がある。GitHubは攻撃を受けるサービスと、そのエッジ防御を管理していた。第三者資源の発行者や埋め込み元は、暗号化の有無や依存関係を管理していた。ブラウザーベンダーはコード実行と異なる生成元への要求に関する境界を設計していた。そして経路上の事業者は、平文の内容を観測または変更できる設備、規則、ログを管理し得た。利用者本人は、その大半を選べなかった。

したがって、事件を「攻撃者と被害者」の二者関係だけで説明すると、実際の制御構造を見失う。問うべきなのは、誰がどの層を変更できたか、誰が異常を観測できたか、誰がその記録を保存できたか、そして誰が結果を第三者に検証可能な形で示せたかである。

公開記録から確実に言えること

最も安全な出発点はGitHub自身の発表である。同社は、DDoSが2015年3月26日木曜日の02時ごろ（UTC）に始まったと述べた。当時のGitHub史上最大のDDoSであり、一般的な攻撃手法に加え、無関係な人々のブラウザーを使って大量の要求を発生させる高度な手法が含まれていたという。GitHubはまた、入手した報告から、特定種類のコンテンツを削除するよう圧力をかけることが目的だったと考えていると説明した。[1]

この発表は、被害側が観測した発生時刻、運用上の重大性、ブラウザーを利用した要求、そしてGitHubが理解した攻撃目的を示す。一方で、完全な通信量、参加したブラウザーの総数、顧客ごとの被害、金銭的損失、正確な復旧時刻、すべての緩和変更は明らかにしていない。GitHubの目的解釈だけで、運用主体や具体的な命令者まで確定することもできない。

GreatFireは別の被害当事者として、先行する時系列を公表した。同団体は、3月17日から自らのサービスが非常に大きな要求の集中を受けていたと述べた。その後、Baidu Analyticsに関連する資源の代わりに悪性JavaScriptが送られ、ブラウザーがGreatFireのコンテンツとGitHubでホストされた二つのページへ向けられたと説明した。GreatFireはこの活動を中国当局に帰属させた。[7][8]

ただし、この帰属は被害当事者による主張として扱う必要がある。Baiduは自社製品が侵害されたとの見方を否定した。この否定は省略できない。Baiduのサーバー自体が侵害されたこと、Baiduが事情を知りながらコードを配信したこと、第三者が関連資源を悪用したこと、経路上で応答が置き換えられたことは、それぞれ別の命題だからである。公開研究が重視したのは、正規の配信元が悪性コードを提供したと直ちに決めつけるのではなく、平文応答が経路上で差し替えられた可能性を検証することだった。

Great Cannonに関する技術研究が示した範囲

Citizen Lab、International Computer Science Institute、UC Berkeley、Princetonの研究者らは、公開記録の中で最も詳細な技術的再構成を行った。研究者は、Great Cannonと名付けたシステムをGreat Firewallとは区別しつつ、コードやネットワーク上の位置に類似性があると報告した。暗号化されていない特定の要求を選択的に捕捉し、正規とは異なる応答を返して、国外のブラウザーに標的への要求を送らせる挙動を説明した。[2][3][4][5]

研究では、複数地点からの測定、応答の違い、タイミング上の特徴、システムが示す副次的な挙動を組み合わせ、注入機構が存在するとみられる位置を絞り込んだ。これは、政治的な名称だけで事件を説明するのではなく、観測可能な動作から制御点を推定する方法である。

研究者は、中国政府による運用が有力であるとの評価を示した。しかし、その表現は法的裁定と同じではない。公開研究から、政府内の特定人物による命令、完全な組織上の責任系統、すべての設備の所有関係までを断定することはできない。説明責任を厳密にするには、「研究上の測定が有力な運用主体評価を支持した」と述べるべきであり、「国家責任が裁定済みである」と書き換えてはならない。

GreatFireの主張、GitHubの被害認識、Baiduの否定、研究者の技術評価は、相互に関係するが同じ種類の証拠ではない。これらを一つの確定的物語へ溶かすのではなく、誰が何を観測し、どこから先が推論なのかを保つことが、帰属に関する最低限の規律となる。

ブラウザーが実行した内容こそ事件の中心である

この事件の核心は、ページに記載された資源名と、ブラウザーが実際に受け取って実行した内容との間に生じた断絶である。ページは通常の分析用スクリプトなどを参照していた。ブラウザーはその資源を平文HTTPで要求した。経路上のシステムが選択条件に一致する要求を見つけ、正規応答に代わる内容を送り込んだとみられる。ブラウザーは受け取ったJavaScriptを実行し、指定された標的へ繰り返し要求を送った。

ここでは三つのアイデンティティを分けなければならない。第一は、ページに記載された資源のアイデンティティである。ホスト名やDNS応答は、ブラウザーがどこから取得しようとしたかを示す。第二は、ブラウザーが受理した内容のアイデンティティである。暗号学的な認証のない平文通信では、その内容が途中で変更されていないことをブラウザーは証明できない。第三は、その後GitHubへ接続したブラウザーのアイデンティティである。送信元アドレスは接続元を示すが、利用者の意思や命令の由来までは示さない。

この区別を失うと、分析は誤った方向へ進む。GitHubへの要求を送ったすべての利用者を故意の攻撃者とみなせば、ブラウザーが一時的に利用された事実を見落とす。資源の名称だけを見て発行者のサーバーが侵害されたと決めつければ、経路上の差し替えを見落とす。送信元アドレスが本物であることを内容の正当性と混同すれば、利用者の意思が存在しない要求を正規アクセスと誤認する。

必要なのは、要求された資源、想定された配信元、複数地点で受信された内容、そのハッシュ、受信時刻、暗号化の有無、ブラウザーが続いて行った通信を結ぶ、再現可能な証拠連鎖である。名称や登録情報だけでは、その連鎖を代替できない。

Heng.luの「動いているコードを優先する」という基準

Heng.luの考え方をこの事件に適用すると、管理記録は台帳であって、稼働中の現実を支配する絶対的な証明ではないという結論になる。DNS記録、アドレス登録、リポジトリの名称、ホスティング契約は、期待された権限や関係を表す。それらは欠かせないが、利用者に到達した内容が真正だったことまでは保証しない。

2015年の事例では、ブラウザーが期待されたホスト名を解決し、想定された資源へ要求を送っていても、途中で挿入されたとみられる別の内容を実行し得た。管理面の記録が正しく見える一方、稼働中の結果は異なっていた。説明責任は、その差を見えるようにし、どの境界で生じたのかを検証するところから始まる。

「動いているコードを優先する」とは、登録情報を捨てることではない。DNS、経路表、アドレス台帳、証明書、応答ヘッダー、サービス状況は、期待された状態を再構成するために必要である。ただし、それらを複数地点の応答内容、時刻、経路の観測、ブラウザーの実行結果と照合しなければならない。

この観点で中心となるのが、ピアリングとトランジット、ホスティングとネットワーク・アイデンティティ、そして運用継続である。どの経路を通ったのか。どの事業者が平文通信を観測または変更できたのか。GitHubは標的コンテンツを維持しながら到達性を守れたのか。これらを取り除けば、事件の説明責任に関する論点そのものが成立しない。

現実層を優先する分析は、特定の国家、企業、活動団体、暗号化政策を支持する宣言ではない。実際に何が配信され、誰がどこを制御し、何を立証できるのかを問う方法である。政治的立場にかかわらず、その検証基準は変わらない。

送信元アドレス検証が直接の解決策にならない理由

BCP 38などの送信元アドレス検証は、偽装された送信元を使うDDoSへの重要な防御である。ある接続点の背後から正当に現れるはずのない送信元アドレスを検出し、転送を抑止することで、反射や増幅を悪用した攻撃を難しくする。複数経路を持つネットワークでの運用上の改善や、実現可能な経路に基づく検証方法も標準文書で論じられている。[12][13][14][17]

ところが、Great Cannonについて報告されたブラウザー利用型の機構では、ブラウザーは自分自身の正規のアドレスから接続した。ネットワーク層から見れば、その通信は到達可能な正しい方向から来ている。送信元を検証する設備が正常に機能しても、接続自体を正当と判断して通す可能性が高い。問題はアドレスの偽装ではなく、ブラウザーに要求を発生させた命令の出所にあった。

これは、送信元アドレス検証が不要だという意味ではない。現実のDDoSは複数の方式を組み合わせることがあり、偽装通信を減らせば、緩和設備の余力を他の通信に振り向けられる。送信元情報の証拠価値も高まる。しかし、この統制だけで2015年の機構を止められたと主張すれば、異なる層の問題を混同することになる。

統制は、その統制が変えられる性質に結び付けて評価すべきである。送信元検証はアドレス偽装を抑える。認証付き暗号化は内容の無断変更を困難にする。ブラウザーの制限はコード実行と要求生成を抑える。エッジ側の分類と制限はサービス資源の消費を管理する。緩和能力と経路調整は可用性の低下を抑える。どれか一つだけで、全体を覆うことはできない。

認証付き暗号化が変えるもの、変えないもの

平文HTTPでは、ブラウザーは、名前で指定した配信元から受け取った応答が途中で変更されていないことを暗号学的に確認できない。経路上に位置するシステムは要求を観測し、正規の応答より先に別の応答を受理させようとする余地を持つ。Great Cannonの公開再構成は、この露出を中心に据えている。

正しく構成された認証付きTLSでは、ブラウザーは意図した配信元との保護された通信路を確立し、内容の改変や偽造を検出できる。経路上のシステムが単純に応答を書き換えても、有効な認証結果を生成できなければ、ブラウザーは正規資源として受理しない。RFC 7258は広範な通信監視を設計上軽減すべき攻撃として扱い、TLS 1.3は認証された暗号化通信路の安全目標を示している。[15][16]

ただし、これらの標準は2015年の具体的実装を証明する資料ではない。後から確立された、または一般化された統制の文脈である。認証付き暗号化によって、平文応答の単純な差し替えは困難になるが、接続の遮断、リセット、経路変更、トラフィック分析、端末や配信元自体の侵害、別方式のDDoSまでは消えない。

したがって、「すべてを暗号化すれば同種の問題がなくなる」という結論は成り立たない。責任ある表現は、認証付き暗号化が、正規配信元を装った経路上の内容置換を大幅に難しくし、失敗を可視化しやすくする、という範囲にとどまる。実務では、どの外部資源が暗号化されていたか、証明書検証が成功したか、混在コンテンツが残っていたか、異なる地点で失敗の見え方が一致したかを記録する必要がある。

複数地点の観測が必要な理由

経路上の注入は、常にすべての通信へ作用するとは限らない。特定のホスト名、資源名、問い合わせ文字列、接続元、宛先、時間帯だけを選ぶことができる。ある経路では異常な応答が届き、別の経路では正規の応答が届く可能性がある。単一地点だけの観測では、異常が配信元、途中の事業者、利用者の端末、またはローカルな設備のどこで生じたかを区別しにくい。

複数のネットワークと地域から同じ資源を取得し、内容、ハッシュ、応答時刻、接続先、証明書の結果を比較すれば、可能性を絞り込める。一つの地点だけが異なる内容を受け取った場合、共有されていない経路区間が重要になる。先に届いた応答が異常で、遅れて正規応答が観測されるなら、競合する応答注入という仮説を検討できる。配信元の記録に異常な内容が存在しない場合、配信元侵害の可能性は低下するが、それだけで完全に排除されるわけではない。

観測事実と推論は別々に保存すべきである。観測事実には、時刻、要求内容、受信内容、ハッシュ、暗号化状態、証明書検証、経路情報、ブラウザーの挙動が含まれる。推論には、注入地点、既知の設備との関係、運用主体の可能性が含まれる。推論には確度と代替仮説を付けなければならない。

時刻の品質も決定的である。資源の取得、異常なコードの実行、その後のGitHubへの要求を関連付けるには、複数のシステムの時計を比較できなければならない。収集の遅延、時計のずれ、時差変換を記録せずに作られた図は、見た目が明快でも誤った順序を隠し得る。

一方、詳細な通信記録やブラウザー履歴には利用者の情報が含まれる。必要な証拠を残すことと、無関係な閲覧内容を大量に保持することは同義ではない。収集範囲を限定し、アクセスを制限し、加工前後のハッシュを残し、事件の検証に必要な期間だけ保持する設計が求められる。

GitHubが実際に制御できた境界

GitHubは、標的となったサービスの可用性と、ホストしたコンテンツの完全性を守る立場にあった。同社は、エッジでの通信分類、要求頻度の制限、処理能力の割り当て、キャッシュ、外部緩和事業者との連携、利用者への状況説明を制御できた。一方、遠隔地の平文応答が途中で置き換えられる経路を、GitHubが直接変更することはできなかった。

GitHubが2014年に公開したDDoS防御の説明には、ネットワーク処理の調整、ロードバランサー上の制限、専用のフィルタリング設備、外部緩和事業者との協力といった多層防御が含まれていた。[9] ただし、それは2015年の事件より前に書かれた設計上の文脈であり、すべての統制が同じ設定で稼働していたことや、各統制が事件中にどの程度機能したかを証明しない。

被害側の説明責任には、どの要求が集中したか、どのURLが標的となったか、エッジとアプリケーションの負荷がどう変化したか、どの分類規則をいつ変更したか、外部緩和へいつ切り替えたか、正規利用者への副作用がどの程度あったかを記録することが含まれる。公開資料に詳細がない部分は、不明として残すべきである。完全な通信量、追加能力の必要量、正確な回復時間を推測で埋めてはならない。

ブラウザーからの要求はGitHubにとって望ましくないが、通常のHTTP通信に似ていた可能性がある。激しい要求を送ったアドレスを一律に遮断すれば、同じネットワークを共有する無関係な利用者を巻き込む。計算負荷の高い応答を返し続ければ、サービス資源をさらに消費する。標的となったコンテンツを削除すれば、通信圧力がホスティング方針を左右する前例になる。

ここでの評価軸は、GitHubの政治的勇気や正しさではない。普通の利用者を故意の攻撃者と同一視せず、標的コンテンツの完全性を保ちながら、どの統制が可用性を回復させたかを示せるかである。各措置について、担当者、実施時刻、理由、期待効果、観測結果、解除条件が結び付いていれば、後から有効性と副作用を検証できる。

経路事業者が負う「検証可能な制御」の責任

公開研究が示した注入機構は、通信経路上の位置を必要とする。その位置には、平文要求を観測し、特定の条件に合う応答を差し込める技術的権限が伴う。そのような権限を持つ設備を運用する事業者には、何が許可され、誰が変更でき、いつ作動し、どの記録が残るかを説明できる体制が必要である。

具体的には、機能を正当化する規則、実装する設備、変更権限を持つ役割、設定変更の承認、稼働記録、管理アクセス、改ざん検知、緊急停止条件が対応していなければならない。関与を否定する場合も、技術的に検証可能な記録が、根拠を示さない包括的な否定より説得力を持つ。

もっとも、通信を運んだすべてのトランジット事業者が、すべての改変に責任を負うわけではない。インターネット経路は複数の管理領域を通り、事件中にも変化し得る。ある事業者は暗号化された内容を見られず、別の事業者は上流で起きた異常を特定できないかもしれない。責任は政治的位置や物理的な近さではなく、実際の制御権と証拠保存能力に結び付けるべきである。

BGPの観測は、どの自律システムが到達性を広告し、外部から見た経路がどう変化したかを示す。しかし、アプリケーション内容の差し替え地点を単独で証明するものではない。公開経路情報に現れない内部接続や設備を通る可能性もある。経路情報は、複数地点の応答比較やタイミングと組み合わせて初めて強い意味を持つ。

IPアドレスの登録や地理情報も同様である。登録は割り当て先や連絡先を記録する台帳であり、特定時刻にどの装置が応答を生成したか、誰がその装置を操作したかまでは示さない。台帳を判決として扱わず、稼働中の証拠と突き合わせることがHeng.luの現実層に沿った判断となる。

外部資源の発行者と埋め込み元

報告された攻撃経路は、ブラウザーが平文HTTPで外部資源を取得することに依存していた。したがって、資源の発行者と、それをページへ埋め込むサイトも制御図の一部になる。ただし、制御図に含まれることは、自動的に加害者と認定されることを意味しない。

資源の発行者は、暗号化された配信を提供し強制するか、キャッシュや更新方式をどう設計するか、異なる内容が届いたとの報告をどう調査するかを管理できる。埋め込み元は、保護されたページへ平文の実行可能資源を持ち込むかどうかを選べる。外部スクリプトの一覧、所有者、取得方式、更新条件、停止時の動作を把握することは、依存関係の説明責任として重要である。

Baiduの否定が重要なのは、経路上の差し替えが、正規の発行者自身が悪性コードを配信したように見せ得るからである。[8] 検証すべきなのは、配信元の記録に何が残っていたか、異なる経路の利用者が何を受け取ったか、暗号化が使われていたか、内容のハッシュが一致したかである。名称の関連だけで、Baiduが事情を知りながら参加したと推論してはならない。

サブリソース完全性やコンテンツ実行制限は、一部の設計で助けになる。しかし、完全性の基準値自体を安全に配布し、ページ側が強制し、更新頻度や動的内容に対応できなければならない。単独であらゆる注入を防ぐ魔法の統制ではなく、認証付き配信、依存関係管理、ブラウザー制約と組み合わせて評価すべきである。

ブラウザーは「感染端末」ではなく実行境界だった

この事件でブラウザーは、受信したコードと外部通信の間を仲介する実行環境だった。JavaScriptを実行するか、異なる生成元への要求をどう扱うか、混在コンテンツを許すか、証明書をどのように検証するか、バックグラウンド通信をどこまで認めるかは、標準、ベンダー、ページ作成者、利用者設定の組み合わせで決まる。

しかし、繰り返し行われる要求をすべて悪性と判断することはできない。現代のウェブアプリケーションは多数の非同期通信を行う。制限が厳しすぎれば正規サービスを壊し、緩すぎれば注入されたコードが帯域や標的資源を消費する。必要なのは、混在コンテンツの制限、安全な通信の既定化、異常なバックグラウンド活動の抑制、予期しない外部要求の可視化を組み合わせることである。

ブラウザーが担える責任には限界もある。ネットワークによる通信遮断は防げない。認証された配信元そのものが侵害されていれば、内容の意図までは判定できない。GitHubの代わりにDDoSを吸収することもできない。それでも、経路上で挿入されたコードが利用者に気づかれず大量の要求を発生させる余地を狭めることはできる。

事件を検証する際は、ブラウザーの種類と版、当時の混在コンテンツ規則、コードの実行条件、利用者操作の必要性、異なる実装間の挙動差を記録する必要がある。後年の保護機能を2015年当時から存在したものとして扱わず、事件時点の能力と、その後の改善を分けなければならない。

多層DDoS緩和と誤分類の危険

IETFのDDoSに関する指針は、資源枯渇、増幅、プロトコル設計、運用上の防御を考える基盤となる。[11] しかし、それ自体が2015年の具体的な機構を証明するわけではない。ブラウザー利用型の要求はアプリケーション層で正規通信に似るため、複数層での対応が必要になる。

ネットワーク側では通信を分散または吸収し、接続層では同時接続の圧力を管理し、アプリケーション側では反復要求や高コストの処理を識別する。安全にキャッシュできる応答はエッジで処理し、トランジット事業者や緩和サービスと連携する。どの層も、単独では完全ではない。

強い遮断には副作用がある。無関係な利用者を締め出し、共有アドレスの利用者をまとめて罰し、アクセシビリティやプライバシーに負担をかける可能性がある。通信を別経路へ移せば、移動先の処理能力を圧迫することもある。緩和の成功だけでなく、誤検知、巻き添え、応答時間、解除判断まで記録しなければ、可用性を守るために何を犠牲にしたのかが見えない。

外部の緩和事業者も重要な証拠を持つ。フィルタリング前後の通信特性、要求分類、経路変更、クリーンな処理能力の使用状況を観測し得るからである。契約には、顧客が事件データへアクセスできる条件、保存期間、時刻精度、データ保護、事後分析への協力を含める必要がある。緩和を外注しても、説明責任までは外注できない。

帰属と緩和を分離する

運用担当者は、帰属が固まる前にサービスを守らなければならない。GitHubは、注入システムを誰が運用したかにかかわらず、要求の集中と可用性低下に対応する必要があった。一方、研究者は後からネットワーク上の位置、コードの類似性、対象の選択、時間的特徴を分析できた。この二つの時間軸は関連するが、同一ではない。

緩和判断は、要求先、頻度、接続挙動、送信元分布、応答コスト、サービス健全性といった観測可能な性質に基づくべきである。政治的帰属に確信が持てるまで防御を遅らせてはならない。反対に、特定の緩和策が成功したことから、運用主体を推定することもできない。

帰属評価には、技術設備、コードの特徴、配置位置、対象選択、運用時刻、過去との類似性が使われる。それぞれに別の説明があり得る。強い評価とは、複数の証拠がなぜ一つの仮説を支持するか、どの情報があれば結論を変更するかを明示する評価である。

Citizen Labなどの研究が重要なのは、政治的名称だけでなく、観測方法と機構を示したからである。[2][3][4][5][6] それでも、研究上の有力評価を法的確定へ変換してはならない。GreatFireの帰属、GitHubの目的認識、Baiduの否定も、それぞれの主体が述べた範囲を超えて統合してはならない。

説明可能な対応に必要な最小証拠

同様の事件に備える事業者は、少なくとも次の証拠を相互に関連付けて保持すべきである。

1. 事件の識別と時刻

一貫した事件識別子を設け、最初の観測、事件確認、緩和開始、安定化、終了判断を分ける。UTCでの発生時刻と収集時刻、時計の基準、既知のずれ、収集遅延を記録し、書き出した資料にはハッシュを付ける。

2. 資源と通信路のアイデンティティ

要求した資源名、通信方式、ホスト名、名前解決結果、想定配信元、証明書情報、応答ヘッダー、内容のハッシュ、ブラウザーの判断を残す。法律とプライバシーの範囲内で、異常な内容と正規内容の双方を保存する。ホスト名だけで受信内容を証明しない。

3. 複数地点の経路状況

観測地点、接続ネットワーク、概略経路、名前解決、応答時刻を比較する。公開BGP情報と事業者内部の経路記録を保存しつつ、それだけでは注入地点を断定できないことを明示する。

4. ブラウザー実行の証拠

受信コードが何を行い、どの宛先へ、どの頻度で要求し、利用者操作を必要としたかを記録する。ブラウザーの版と関連する安全規則も残す。一時的なコード実行と恒久的な端末侵害を区別する。

5. 被害側サービスの証拠

要求の変化、標的となった経路、エッジとアプリケーションの健全性、フィルタリング、外部緩和への切り替え、エラー率、遅延、利用者影響を保存する。各措置を、実施後に観測された変化と結び付ける。

6. 事業者の制御記録

通信の検査や変更が可能な設備について、認可規則、設定変更、配備識別子、管理アクセス、完全性記録を残す。疑われた経路外の事業者も、自らの実際の境界を示せるだけの資料を保持する。

7. 帰属評価

観測事実、分析上の推論、確度、代替仮説を分離する。外部主体の主張には明確な帰属を付け、不明点を残す。後日の情報を追加する際は、当時の記録を黙って上書きしない。

8. 開示と保存

どの情報を公開でき、どの情報を限定された検証者へ示し、基礎資料をどの期間保存するかを定める。個人情報を減らしつつ、技術的な因果関係まで壊さない。結論を変える新事実が出た場合は、変更履歴を残す。

この証拠群があれば、GitHub、経路事業者、資源発行者、ブラウザーベンダー、緩和事業者の主張を、組織への信頼だけでなく、実際に観測された制御と結果から評価できる。

費用と責任が別の主体へ落ちる構造

ネットワーク防御では、統制を導入できる主体と、統制がないことで損失を受ける主体が一致しないことが多い。外部資源の発行者が平文配信を残せば、置換の危険を負うのはその発行者だけではなく、資源を読み込む利用者や、要求の標的となるサービスである。経路事業者が詳細な記録を保持しなくても、直ちに商業上の損失を負わない場合がある。GitHubは、自ら制御できないブラウザーから生じた通信を吸収する費用を負った。

契約は一部のずれを修正できる。ホスティングや緩和の契約に、事件データへのアクセス、経路変更記録、保存期間、検証への協力を含める。外部資源の調達条件に、認証付き配信、依存関係の把握、廃止時の通知を含める。ブラウザーやプラットフォームの方針で、安全でない実行依存を見えるようにする。

ただし、契約書が技術的な履行を証明するわけではない。契約は期待される行動を記す台帳であり、実際に暗号化が使われ、ログが保存され、緩和が機能したかは稼働中の証拠で確かめる必要がある。ここでも、管理上の正しさと現実の動作を分離して評価するHeng.luの原則が働く。

報告制度にも歪みが生じ得る。すべてを「ボットネット攻撃」と一括すれば分類は簡単になるが、ブラウザーを一時的に利用できた経路上の制御点を隠してしまう。集計のための分類が必要でも、発生機構は失わずに記録すべきである。

後年の再出現を2015年へ混ぜない

後年、Great Cannonと呼ばれる技術が再び使用されたとの報告が現れた。[10][18] これは、経路上注入の検知、認証付き配信、事業者間の証拠共有を一度限りの対応で終わらせない理由になる。しかし、後年の観測によって、2015年3月の事件の運用主体、標的一覧、設備、指揮命令系統が自動的に証明されるわけではない。

2015年のGreatFireからGitHubへ続く事象には、その時点の日時、標的、観測、公開主張がある。後年の事例には別の日時、標的、技術的特徴がある。同じ名称や似た手法が使われても、一つの連続した事件として扱うには追加の証拠が必要である。

時間がたつほど、複雑な観測は単純な名称に置き換えられやすい。その結果、事件ごとの差異や当初の不確実性が消える。説明責任に必要なのは逆であり、事件ごとの識別、変更履歴のある結論、後から追加された情報の明示である。

NTTの技術解説はGreat CannonとDDoS防御を考える独立した文脈を与え、後年のAT&T Alien Labsの報告は再出現を検討する材料となる。[10][18] いずれも2015年の被害当事者記録や当時の測定を置き換える資料ではない。

反実仮想から統制を評価する

事件後の分析では、「もし特定の統制があれば、何が変わったか」を考えることができる。ただし、観測されなかった別の歴史を確定的に語ってはならない。

外部資源が正しく認証された暗号化通信で配信されていれば、ブラウザーは有効な保護を持たない差し替え応答を拒否できた可能性が高い。それでも、通信遮断、接続妨害、別の平文資源、配信元侵害、異なるDDoS方式が選ばれた可能性は残る。

ブラウザーが予期しない反復通信をより厳しく制限していれば、生成される負荷を減らせたかもしれない。しかし、正規のウェブアプリケーションも頻繁な通信を必要とする。制限の効果は、誤検知と回避可能性を含めて測らなければならない。

GitHubにより多くのエッジ能力や緩和能力があれば、より大きな負荷を処理できた可能性はある。ただし、公開資料から必要な追加能力を具体的に算定することはできない。能力増強は遠隔地の内容完全性の失敗も修復しない。

複数地点の監視が充実していれば、異常応答の発生経路を早く絞り込み、帰属評価を強化できたかもしれない。それでも、観測は改変そのものを止めず、利用者のプライバシーに配慮する必要がある。

送信元検証が広く導入されていれば、偽装を使う反射型攻撃の多くは難しくなる。一方、注入コードに従ったブラウザーの要求は、正規の送信元を持ったまま残り得る。この差が、多層統制の必要性を示している。

経路上コード注入に対する説明責任の基準

同様の事件へ備えるため、事業者とプラットフォームには八つの実務基準が必要である。

第一に、実行可能な外部資源を認証する。平文で配信されるコードは、経路上で置き換えられる機会を生む。外部依存を一覧化し、暗号化されていない実行経路を段階的に除く。

第二に、複数のネットワークから測定する。配信元の記録だけでは、利用者が途中で何を受け取ったかを確認できない。異なる地点で内容とハッシュを比較し、経路ごとの差を残す。

第三に、層ごとの制御者を示す。資源の発行、DNS、経路、トランジット、ブラウザー実行、標的側エッジ、緩和、利用者への連絡を誰が管理するかを分ける。最も有名な企業へ全責任を集めない。

第四に、措置と結果を結ぶ。フィルタリング、経路変更、処理能力の追加、規則変更には、担当者、時刻、理由、期待効果、観測結果、解除条件を残す。

第五に、帰属の確度を見えるようにする。技術的位置やコードの類似性は強い評価を支え得るが、個人の命令系統を自動的に証明しない。表現の強さを証拠の強さに合わせる。

第六に、無関係な利用者を守る。ブラウザーから要求が送られたことと、利用者が攻撃を望んだことは同じではない。遮断の巻き添えとプライバシーへの影響を測る。

第七に、標的コンテンツを削除せずに継続できるかを試す。攻撃による通信コストがホスティング方針を自動的に決めないよう、事前に可用性、判断権限、緩和手順を検証する。

第八に、管理記録と稼働証拠を照合する。DNS、証明書、経路、登録、契約は期待状態を定める。実際の配信内容とサービス挙動が、その期待どおりだったかを証明する。

取締役、運用者、検証者が問うべきこと

利用者のブラウザーで実行できる外部資源は何か。それらはすべて認証付き通信で配信されていたか。
配信元侵害、経路上差し替え、端末上の悪性ソフトウェア、正規発行者の通常動作を、どの証拠で区別できるか。
どのネットワークと経路で異常な内容が届き、どこでは期待された内容が届いたか。
時刻、内容のハッシュ、証明書、名前解決、経路観測、ブラウザーの動作を一つの時系列へ結べるか。
疑われる注入設備を誰が変更でき、その制御を検証可能な記録で示せるか。
GitHub側は、ブラウザー由来の要求を、利用者の故意を前提とせずどのように分類したか。
フィルタリング、頻度制限、キャッシュ、能力増強、外部緩和によって、どの測定値がどう変化したか。
緩和により、無関係な利用者やサービスにどの副作用が生じたか。
運用主体の評価を支える事実は何か。代替仮説は何か。どの程度の確度が妥当か。
GreatFireの主張、GitHubの解釈、Baiduの否定、独立研究の観測を別々に保っているか。
どの統制が送信元偽装を抑え、どの統制が内容の完全性を守り、どの統制が標的の可用性を守るのか。
組織名への信頼に頼らず、資格を持つ第三者が事件の境界と結論を再検証できるか。

結論

2015年のGitHub DDoSは、意図されたウェブ資源と、ブラウザーが実際に実行したコードの間に制御点が存在し得ることを示した。普通の利用者、正規の送信元アドレス、共有されたネットワーク経路が、本人の意思とは無関係に可用性攻撃へ組み込まれた。そのため、端末名、アドレス、登録情報だけを見ても、事件の実体には届かない。

公開記録から導ける結論は慎重でなければならない。GitHubは、特定コンテンツへの圧力を伴うと理解した大規模DDoSを経験した。GreatFireは先行する被害と中国当局への帰属を主張した。研究者は平文応答を選択的に差し替えるシステムを測定し、有力な運用主体評価を示した。Baiduは自社製品が侵害されたとの見方を否定した。完全な通信量、総利用者数、金銭的損失、正確な回復時刻、個人の指揮命令系統は、公開資料から確定できない。

責任は実際の制御に従う。経路事業者は内容変更能力を持つ設備について検証可能な記録を残す。資源発行者と埋め込み元は、実行可能な依存関係と認証付き配信を管理する。ブラウザーは、利用者に見えない要求生成を難しくする。GitHubと緩和事業者は、エッジでの措置を観測結果と結び付ける。研究者と公的機関は、観測、推論、帰属を混同しない。

最終的に評価されるべきなのは、台帳上の名称や意図だけではない。経路が実際に運び、ブラウザーが実際に実行し、サービスが実際に示した挙動である。管理記録は期待される権限を示す。稼働中の証拠は、その権限が現実に保たれていたかを示す。Great Cannon事件が突き付けた説明責任は、両者のずれを観測し、再現し、制御できる形にすることから始まる。