2013年のSpamhaus DDoSが示したオープンDNS再帰のネットワーク説明責任

要約

事象の範囲は2013年3月18日から27日までであり、Cloudflareが報告した約10、75～90、120、300 Gbit/sという値は、それぞれの観測地点に帰属する数字であって、インターネット全体の普遍的なピークではない。[1][2]
実行経路は、偽装された送信元IPアドレス、外部から利用できる再帰リゾルバー、小さな問い合わせ、増幅された応答、被害者または緩和事業者へ向かう共有経路から成っていた。[1][4]
再帰DNSと権威DNSは役割が異なる。問題の中心はDNSサーバー一般ではなく、任意の外部利用者に再帰処理を許したサービスと、偽装パケットを通過させたネットワークの組み合わせだった。[4][10]
RFC 5358は事件以前から再帰サービスの制限を勧告し、BCP 38とBCP 84はアクセス網、顧客境界、マルチホーム環境における送信元アドレス検証を具体化していた。[4][5][6]
Cloudflareによれば参加リゾルバーは3万台を超え、観測された問い合わせと応答の形では約100倍の増幅が生じた。ただし、これは全リゾルバーや全パケットの完全な調査結果ではない。[1][2]
Spamhausのウェブサイトや支援ネットワークの中断と、分散して提供されるDNSBLデータの可用性は分けて評価しなければならない。ウェブサイトの停止は、世界中の迷惑メール対策データが停止したことを意味しない。[3]
「インターネットをほとんど壊した」という表現は当時の広報的な枠付けであり、世界規模の停止を実証した技術的結論ではない。特定の交換拠点全体の停止、完全な送信元AS分布、第三者への全影響も確認されていない。[2]
説明責任の基準は運用可能で監査可能でなければならない。意図しない再帰を閉じ、送信元を検証し、AnycastとBGP経路の変化を記録し、サービス層を分けて測り、修復後の状態を外部から再確認する必要がある。[14][15][16][17][19]

1. 巨大な数字ではなく、実行された経路を見る

2013年のSpamhaus攻撃は、単に「非常に大きなDDoSが起きた」という逸話として読むと、最も重要な部分を見失う。運用上の核心は、誰か一者が巨大な送信能力を単独で保有していたことではない。小さな偽装問い合わせを送れる環境、任意の外部利用者に応答する再帰リゾルバー、問い合わせより大きなDNS応答、そして大量の応答を同じ宛先へ運ぶ相互接続経路が、別々の管理主体をまたいで接続されたことにある。

この連鎖を成立させた各要素には異なる管理者がいた。再帰リゾルバーの運用者は、誰に再帰処理を提供するかを設定できた。アクセス網や顧客収容網は、割り当てと一致しない送信元アドレスを持つパケットを境界で拒否できた。緩和事業者はAnycastによる分散、経路変更、スクラビング、上流との調整を管理した。Spamhausは自らのサービス構成と復旧時の情報発信を管理したが、遠隔地のリゾルバーや、偽装パケットを外へ通したネットワークを管理してはいなかった。

したがって、説明責任は「どの組織が有名か」「誰が攻撃対象だったか」「どの立場に共感するか」から配分できない。問うべきなのは、実際に動作していた経路のどの部分を誰が変更できたのか、その時点の状態を何によって証明できるのか、そして変更後に同じ失敗条件が消えたことを確認したのか、という三点である。

この見方はSpamhausのブロックリスト政策を支持も否定もしない。政策論とパケット経路の検証を混同すれば、運用上の不備が道徳的な評価の陰に隠れてしまう。ここで扱うのは、DNS、ルーティング、相互接続、サービス継続性という稼働中の基盤に限定された説明責任である。

2. 2013年3月18日から27日までという境界

本稿が対象とするのは、2013年3月18日から27日にかけてSpamhausを狙い、その後Cloudflareを支えるプロバイダー側およびピアリング側の経路にも圧力が及んだ一連の事象である。Cloudflareの同時期の説明によると、Spamhausは接続回線が飽和し、ウェブサイトへ到達できなくなった後、緩和を求めた。[1]

Cloudflareは初期段階について約10 Gbit/sを報告し、その後、主として外部に開かれた再帰DNSを介した75～90 Gbit/s程度の波を観測したとしている。[1] 続く説明では、負荷が120 Gbit/s方向へ増え、攻撃の焦点が保護対象の顧客アドレスだけでなく、プロバイダーや交換拠点に面する経路へ移ったと記されている。[2] 広く繰り返された300 Gbit/sという値も、同じプロバイダー側の記述に属する。

これらの数字を、一つの計測器が同じ場所で連続測定した単一曲線のように扱うことはできない。顧客回線、緩和網の内部、Anycast拠点、上流リンク、ピアリング接続では、観測している対象も障害境界も違う。約10 Gbit/sの初期負荷と、後に報告された300 Gbit/sを単純に並べても、同じ資源が30倍の負荷を受けたとは限らない。

日付の境界も重要である。後年に公表されたRFC、運用指針、測定研究は、現在の防御や検証方法を考える材料にはなるが、2013年3月の現場に同一の形で存在していた制御として扱うことはできない。歴史的評価では、当時すでに公開されていた対策と、後から整備された比較材料を明確に分ける必要がある。

3. Cloudflareの数字は何を示し、何を示さないか

帯域値を説明責任の証拠にするには、数字だけでなく観測者、場所、時間、対象インターフェース、集計方法を示さなければならない。約10 Gbit/sと75～90 Gbit/sは、Cloudflareによる顧客保護の説明に現れる。[1] 120 Gbit/sへの増加と300 Gbit/sというピークは、その後のプロバイダー側の説明に属する。[2] したがって、いずれもCloudflareが自らの観測範囲について述べた値として引用するのが正確である。

300 Gbit/sを「当時インターネット全体を流れた攻撃トラフィックの普遍的な最大値」と書き換えることはできない。その主張を成立させるには、関係する複数ネットワークの同期した測定、重複を除いた集計、観測地点間の対応、欠測の扱いが必要になる。公表記録はそこまでの全体測定を提供していない。

同じ制約は3万台を超えるリゾルバーという数にも当てはまる。Cloudflareは、自らが観測したキャンペーンに参加するリゾルバーが3万台を超えたと報告した。[1][2] これは大規模な分散性を示す有力な観測であるが、全世界の公開リゾルバーの完全な台帳でも、すべての応答パケットの送信元を確定した一覧でもない。NAT、アドレス共有、測定期間、再送、設定変更なども、単純な「IPアドレス数＝独立運用者数」という推定を難しくする。

「インターネットをほとんど壊した」という言葉も、Cloudflareの見出しを含む当時の広報的な枠付けとして扱うべきである。[2] 大規模な負荷がプロバイダー経路へ及んだことと、世界全体が停止寸前だったという判断は別の命題だ。引用された資料は、全世界的な停止、特定の交換拠点全体の停止、あるいはすべての利用者に共通する障害を実証していない。

数字を過小評価する必要はない。観測範囲を明示することは、規模を否定する行為ではなく、数字を運用上役立つ証拠に変える行為である。どこで何が測られたかが分かれば、その場所を管理した主体、容量の制約、ルーティング変更、修復後の結果を具体的に検討できる。

4. 反射と増幅を成立させた実行経路

反射経路は、IPヘッダー内の送信元アドレスを偽るところから始まる。攻撃側は小さなUDP DNS問い合わせを作り、その送信元をSpamhaus、または後の段階で緩和トラフィックを受ける基盤のアドレスに置き換える。UDPでは応答前に接続確立の手続きがないため、受信したDNSサービスはパケットに記載された偽の送信元へ応答を返す。

その中継点となったのが、任意のインターネット利用者から再帰問い合わせを受け付けるオープンな再帰リゾルバーだった。Cloudflareは、ripe.netのデータを求める問い合わせが使われ、観測した問い合わせと応答の形では増幅率が約100倍になったと説明している。[1][2] 小さな要求を送る側ではなく、リゾルバーが大きな応答を偽装された宛先へ送るため、攻撃トラフィックの向きが反射される。

一台のリゾルバーから出る量が小さくても、数万台が並行して応答すれば、同じ宛先へ流れ込む合計はリンク容量を圧迫できる。攻撃側から見れば、少量の送信でより大きな受信負荷を生成できる。被害側から見ると、応答は多数のDNSサーバーから到来するため、単一の送信源を遮断するだけでは止まらない。

ただし、反射応答を観測しただけでは、本来の問い合わせを生成したホスト、その完全な送信元AS分布、各運用者の認識、攻撃主体の法的責任まで判明するわけではない。リゾルバーから届いたパケットは、そのリゾルバーが応答したことを示す。偽装パケットがどの顧客境界を通過したかを証明するには、さらにアクセス網の記録や経路ごとの証拠が必要である。

EDNS(0)はDNSのUDP応答サイズを扱うためのプロトコル上の文脈を与えるが、その存在だけで個々の応答サイズ、設定、攻撃への寄与が確定するわけではない。[11] 同様に、NATにおけるUDP動作の一般的要件は観測やタイムアウトを理解する助けになるものの、特定のアドレスから特定の主体を直接導く根拠にはならない。[12]

5. 再帰DNSと権威DNSは同じ責任単位ではない

権威DNSサーバーは、自らが担当するゾーンのデータを公開する。再帰リゾルバーはクライアントから質問を受け、必要に応じてDNS階層をたどり、結果をキャッシュし、クライアントへ回答する。この二つは同じソフトウェアや同じ機器上で動作することがあっても、運用上の役割は異なる。[10]

2013年の経路で中心となった不備は、DNSサーバーが存在したことではない。外部の任意の利用者に再帰処理を提供できる状態があり、そのサービスへ偽装された送信元アドレスを持つ問い合わせが到達したことだった。「DNSが攻撃に使われた」という一般化だけでは、誰がどの設定を直せるのか分からなくなる。

RFC 5358は2008年、反射型DNS増幅の問題を説明し、再帰サービスを意図した利用者に限定することを勧告していた。[4] 公開の権威DNSを停止することと、意図しない公開再帰を閉じることは同じではない。権威応答を世界から利用可能に保ちながら、再帰問い合わせを内部ネットワークや認証された利用者に限定することは可能である。

再帰リゾルバーの運用者が管理するのは、待受インターフェース、アクセス制御、許可クライアント範囲、ソフトウェア、キャッシュ、応答動作、レート制御、権威機能との分離などである。一台の装置で両方を提供していても、再帰サービスに対する責任が消えるわけではない。外部利用者との契約関係がないことや、標的を選んだのが運用者ではないことも、外部から実行できる機能を放置したという技術的事実とは別問題である。

修復を証明するには、現在のリゾルバー一覧、許可されたクライアント範囲、外部ネットワークからの再帰試験、再起動やフェイルオーバー後の再試験が必要になる。「設定を変更した」という作業記録だけでは、別インターフェース、IPv6、予備機、古い構成管理、買収したネットワークなどに露出が残っていないことを示せない。

6. 送信元アドレス検証は別の制御である

オープン再帰を閉じることは、反射器を減らす。しかし、送信元アドレスの偽装そのものを止める制御ではない。偽装を止める最も有効な場所は、パケットの送信元に近く、顧客や内部ネットワークに割り当てられた正当なプレフィックスを把握できる境界である。

RFC 2827として公開されたBCP 38は、顧客または内部ネットワークから到来したパケットの送信元が、その接続から正当に到達可能な範囲と一致しない場合に拒否する考え方を示している。[5] プロバイダー側では「入口」で検査するが、その効果は偽装パケットを外部へ出さないための出口保護となる。顧客は自らのホストが生成する通信を管理し、アクセス事業者は顧客境界のフィルターを管理する。

マルチホーム環境では、正当な通信が非対称な経路を通ることがある。BCP 84は、この複雑さを理由に検証をすべて放棄するのではなく、インターフェースACLや異なる性質の逆方向経路確認など、トポロジーに適合した方法を選ぶ必要を説明する。[6] 厳格すぎる確認が正当な通信を落とす場合でも、接続関係から見て不可能な送信元を許す必然性はない。

責任の強さは、運用者がプレフィックスとインターフェースの関係をどれだけ把握し、実際に制御できるかに応じて変わる。顧客収容境界では、その関係が明確であることが多い。一方、遠く離れた中継ネットワークが、通過するすべてのパケットについて元の顧客割り当てを判断できるとは限らない。あるトランジット事業者が経路上にいたという理由だけで、あらゆる偽装パケットの責任を負わせることはできない。

必要な証拠は、対象インターフェース、許可プレフィックス、採用した検証方式、非対称経路の例外、ドロップカウンター、変更履歴、顧客通知、修復後の試験結果である。送信元検証の普及が現在も不完全であるという指摘は、責任が不要だという意味ではない。むしろ、一般的な「対策済み」という宣言ではなく、実際の境界ごとの証明を求める理由になる。[15]

7. 小さな設定不備が共有外部性へ変わるとき

反射型増幅では、各運用者が局所的に見る負荷と、被害側で集約される負荷の間に大きな差が生じる。一台のリゾルバーが数メガビット毎秒しか送っていなければ、自網の警報閾値に達しないこともある。一つのアクセス網における偽装問い合わせも、多数の顧客に薄く分散していれば目立ちにくい。

しかし、局所的に小さいからといって外部への影響が小さいとは限らない。Cloudflareが報告した3万台超のリゾルバーが並行して応答し、それぞれの問い合わせが観測条件下で約100倍に増幅されたなら、被害者側のリンクには大きな合計値が現れる。[1][2] 各参加者が全体を見ていなくても、設定の集合が一つの容量制約へ収束する。

これは典型的なネットワーク外部性である。再帰を開いたままにする運用者や、送信元検証を省略したネットワークは、改修費用を避けたり、管理を単純化したりできるかもしれない。一方、混雑、緩和費用、上流調整、障害対応の負担は、Spamhaus、Cloudflare、トランジット事業者、ピアリング相手、さらには同じリンクを共有する第三者へ移る。

外部性の存在は、個々のリゾルバーが不可欠だったという意味ではない。どの一台を取り除いても全体量への影響は小さいかもしれない。それでも、運用者が管理する全リゾルバーで再帰境界を維持すれば、利用可能な反射器の母集団は縮小する。同じく、一個の偽装パケットを落とす効果は小さくても、顧客境界全体で検証すれば攻撃の前提を大規模に取り除ける。

説明責任は、意図や個別の寄与率だけに依存すべきではない。標的を知らなかった運用者にも、外部から実行可能な再帰サービスを管理する能力はある。一方、能力のない主体へ結果だけを理由に責任を割り当てるべきでもない。実際に変更可能な制御面と、そこに残された証拠を結びつけることが必要である。

8. Anycast、BGP、ピアリング、トランジット

Anycastは、複数拠点から同じサービスプレフィックスを広告し、BGPで選ばれた経路に応じて利用者や攻撃トラフィックを各拠点へ引き寄せる。大規模な攻撃に対しては負荷を分散できるが、容量を無限に増やす技術ではない。どの拠点へどれだけ流入するかは、経路選択、地域的な接続、ピアリング、トランジット容量、ルートポリシーに左右される。

Cloudflareが保護対象をAnycast基盤へ載せた場合、負荷は複数拠点へ分散し得る。一方で、攻撃が顧客アドレスだけでなく、サービスを支えるプロバイダーや相互接続面へ向けば、障害境界はアプリケーションより手前へ移動する。[1][2] サーバーに余力があっても、その手前のピアリングポート、トランジット回線、スクラビングへの経路が飽和すればサービスは届かない。

「交換拠点に面した経路で負荷が観測された」ことと、「特定のインターネット交換拠点全体が停止した」ことは同義ではない。トラフィックはプライベートピア、交換拠点ポート、トランジット、またはそれらの組み合わせを通り得る。あるポートや接続の飽和だけから、共有ファブリック全体の停止、全会員への影響、攻撃量の帰属を導くことはできない。

経路上の主体ごとに証拠も異なる。緩和事業者は、どの拠点がプレフィックスを広告し、どこで流量が増え、いつルートを変更したかを示せる。ピアやトランジット事業者は、自らのインターフェースカウンター、顧客境界ポリシー、混雑対応、調整記録を示せる。交換拠点運用者は、共有設備と参加者ポートについて自らが観測した範囲を説明できる。

大きなピーク値だけでは、障害がどこからどこへ移ったかを再現できない。必要なのは、時刻を合わせたBGP広告、拠点別流量、インターフェース利用率、スクラビング記録、ピア／上流との連絡、サービス到達性である。Anycastの成功も失敗も、地図上の拠点数ではなく、実際に選ばれた経路と利用できた余力によって評価される。

9. ウェブサイト停止とDNSBLデータの可用性

最初に明確に報告された影響は、Spamhausの接続が飽和し、ウェブサイトに到達できなくなったことだった。[1] 後の段階ではCloudflareを支えるプロバイダー側の経路にも負荷が及んだ。[2] Spamhausは後年の説明で、ウェブサイト、ホスト、DNSパートナー、支援サービスが攻撃対象となった一方、分散された迷惑メール対策データは利用可能な状態を保ったとしている。[3]

ウェブサイトとDNSBLは異なるサービス層である。ウェブサイトは説明、連絡先、サポート、状況告知を提供する。DNSBLデータは別の問い合わせ先、複製、DNS経路、キャッシュ、更新手順を通じて配布される。ウェブの入口を失えば利用者との連絡や状況説明に深刻な支障が出るが、それだけで全DNSBL応答が消えるわけではない。

逆に、分散データが提供され続けたという説明から、すべての地域、利用者、リゾルバー、経路で一切の劣化がなかったと推定することもできない。世界規模のメールフィルタリング停止は確認されていないが、局所的な到達性低下が存在しなかったとも断言できない。公開記録が支えるのは、サービスを一括して「停止」または「正常」と呼べないという結論である。

可用性を検証するなら、HTTP到達性、権威DNSの応答、DNSBL問い合わせ成功率、データ更新時刻、遅延、エラー率、支援ホストの状態を分離して測るべきだ。観測地点と時間帯も記録しなければならない。一つの緑色のステータス表示で複数サービスの継続性を代表させることはできない。

後年のRFC 8767が扱う古いDNS応答の利用は、障害時の継続性を考える現代的な比較材料になり得る。[13] ただし、それを2013年のSpamhausの各サービスで同一条件の下に実装されていた制御として扱うことはできない。さらに、古い回答による一時的継続と、データが正しく更新され続けることも別の性質を持つ。

10. 運用主体ごとに異なる証拠

再帰リゾルバー運用者に求められる証拠は、管理対象の全リスナー、各アドレスファミリー、待受インターフェース、許可クライアント範囲、アクセス制御、ソフトウェア版、例外、変更時刻を結びつけた記録である。外部からの試験では再帰を提供せず、内部の正当な利用者には必要な機能を提供することを確認する。UDPだけでなくTCP、IPv4だけでなくIPv6、現用機だけでなく待機系も対象にする。

アクセス事業者や顧客網については、接続ごとの正当な送信元プレフィックス、ACLまたは逆方向経路確認の方式、マルチホーム例外、無効な送信元を用いた許可済み試験、ドロップ統計、障害後の再試験が重要になる。経路変更後にも確認しなければ、以前は正しかった規則が、正当な非対称通信を遮断したり、逆に偽装を許すようになったりする。

緩和事業者には、Anycast拠点ごとの広告、受信量、スクラビング動作、経路変更、容量判断、ピアや上流との調整、測定値の定義を示す責任がある。公開した数字について、どの地点、どの時間窓、どの集計方法に基づくかを明らかにすることも、運用上の説明責任に含まれる。

トランジット事業者は、自らが把握できる顧客境界の送信元検証、混雑したインターフェース、対応時刻、顧客への通知を示せる。しかし、経路上に存在したというだけで、攻撃の全量や攻撃主体の意図まで帰属させることはできない。ピアリング相手や交換拠点についても、自らが管理した接続と共有設備の範囲に結論を限定する必要がある。

Spamhausは、自らのサービス設計、ウェブサイトとDNSBLの区別、復旧連絡、依存する支援サービスを説明できる。一方、遠隔地の再帰ACLや顧客網の送信元検証は管理できない。被害者であることは、自らのサービス継続性を説明する責任を消さないが、他者の制御不備を被害者へ移す理由にもならない。

11. 2013年以前に存在した制御

歴史的な説明責任では、その時点ですでに知られていた制御を確認する必要がある。RFC 5358は2008年にDNS反射型増幅を記述し、再帰サービスを意図したクライアントへ限定することと、偽装送信元を持つパケットをネットワークから出さないことを別々の対策として示していた。[4]

BCP 38は2000年から、顧客側から到来するパケットの送信元が正当な割り当てと整合するかを境界で確認する方法を示していた。[5] BCP 84はマルチホームや非対称経路を考慮し、単純な厳格確認だけではない選択肢を説明していた。[6] したがって、2013年3月の時点で、公開再帰と送信元偽装という二つの主要な失敗面は、すでに標準文書で識別されていた。

しかし、標準が存在したことは、すべての運用者が実装済みだったことを証明しない。特定のリゾルバーがなぜ開いていたか、特定のアクセス網がどの検証方式を採用していたか、運用者が攻撃前に問題を認識していたかは、個別の記録なしには分からない。公開された対策と現場で動作していた設定を混同してはならない。

また、二つの制御は互いの代替ではない。再帰を閉じても、偽装パケットは別の反射サービスや別の攻撃へ利用され得る。送信元検証を実施しても、別のネットワークから偽装問い合わせが届く限り、公開リゾルバーの露出は残る。各運用者は、自らが支配できる制御について証明を持たなければならない。

当時利用可能だった対策を評価する際も、後知恵で完全性を要求するべきではない。公平な問いは、将来のRFCを予見したかどうかではなく、当時公開されていた制御をどう評価し、何を導入し、残る制約をどう記録し、事件後の修復をどう確認したかである。

12. 後年のRFCと運用資料をどう使うか

後年の技術資料は、2013年を書き換えるためではなく、現在どのような検証を追加できるかを考えるために使うべきである。DNS Cookiesは、対応する端点間の交換において偽装への耐性を高める方法を提供する。[7] ANY問い合わせへの最小応答は、歴史的に増幅へ利用されやすかった応答形状の一つを縮小する。[8] 大規模な権威DNSサービスの設計指針は、分散配置、容量、依存関係、運用継続性を考える比較軸になる。[9]

これらはいずれも、意図しない再帰を閉じることや、送信元アドレスを検証することの代わりではない。DNS Cookiesは相互対応が必要であり、すべての攻撃経路を一律に消すものではない。ANY応答の縮小も、別の問い合わせや応答形状による増幅可能性をゼロにしない。権威サービスの強靱化は、公開再帰の管理とは異なる責任面を扱う。

RIPEの運用文書は、DNS運用を資産一覧、役割、設定、監視、変更、継続性の面から確認するための現在的な参照点を提供する。[14] MANRSによる送信元アドレス検証の議論は、長年知られた対策がなお全面導入に至っていない理由と、実装証拠の必要性を示す。[15]

RIPE会合とDNS-OARCの資料は、DNS増幅が運用設備へ与える負荷、公開再帰の把握、応答制御、通知、修復確認を検討する材料になる。[16][17] 測定研究は、攻撃や防御を外部から観測するときの可能性と限界を示す。[18][19] それらから2013年当時の個々の運用者の知識、導入状況、因果関係を逆算することはできない。

後年の資料を適切に使うなら、結論は「2013年の運用者は現在の全機構を備えるべきだった」ではない。「現在の運用者は、過去に明らかになった失敗面が自網に残っていないことを、より精密な方法で証明できる」という形になる。

13. 修復を監査可能にする実務

最初の作業は、管理対象を数えることである。再帰DNSについては、IPアドレスだけでなく、機器、仮想インスタンス、コンテナ、インターフェース、IPv4／IPv6、現用／待機、顧客専用／社内用という単位で一覧を作る。各項目に所有者、設定源、許可クライアント、変更履歴、最終外部試験日を結びつける。

次に、管理外の場所から安全な再帰試験を行う。許可されていない送信元から再帰結果を取得できないことを確かめ、同時に正当な利用者の名前解決が維持されることも確認する。修復直後だけでなく、再起動、フェイルオーバー、ソフトウェア更新、ネットワーク統合の後にも繰り返す。

送信元検証については、顧客接続やアクセス区間ごとに正当なプレフィックスを定義し、許可を得た試験で不正な送信元を持つパケットが境界を越えないことを確認する。マルチホームでは、経路の非対称性を含めて方式を選ぶ。例外には、責任者、技術的理由、補完策、期限、再試験日を設定する。

テレメトリーはDNS側と境界側を結びつける必要がある。リゾルバー側では、異常な問い合わせ率、問い合わせ種別、応答サイズ、切り詰め、レート制御を把握する。境界側では、インターフェースごとの偽装疑いパケットの拒否、顧客ポリシー、フロー、経路変化を記録する。必要以上の利用者データを保持せずに、問題の再現に必要な粒度を確保する設計が求められる。

不正利用通知には、UTCの時間範囲、対象、プロトコル、代表的なパケット情報、測定方法、連絡可能な案件識別子を含める。単にIPアドレスの一覧を送るだけでは、受信側が自らのログと照合し、どの設定を修復すべきか判断できない。送信後には、対象が閉じられたかを再測定し、修復不能または所有者不明の項目を残存リスクとして管理する。

Anycastや相互接続については、攻撃前後の広告、拠点別流量、ピア／トランジット別の流入、容量警報、スクラビング、経路変更、復旧時刻を一つの時系列に並べる。これにウェブ、権威DNS、再帰DNS、DNSBL、支援サービスそれぞれの到達性を重ねれば、負荷が移動した場所と、継続したサービスを区別できる。

証拠は、変更前の状態、変更内容、変更直後の観測、時間を置いた再確認を相互に照合できる形で保全する。設定の抜粋だけを残すのではなく、その設定がどの機器、インターフェース、アドレスファミリー、経路、サービス層に適用されたかを示し、時刻、対象、観測地点、試験条件、結果を同じ記録に対応づける。保存期間を通じて意味が失われないよう、使用した測定方法や値の定義、例外の理由、判断した責任者も併記する必要がある。個々の記録が存在していても、前後関係が切れていれば、外部の確認者は設定変更と結果の改善を結びつけられない。反対に、対象と時系列が明確なら、修復時に見逃した予備系や別経路が後から判明した場合にも、どの確認をやり直すべきかを限定できる。外部からの再測定結果は内部の記録と突き合わせ、差がある場合は片方を都合よく採用せず、観測地点、経路、時刻、キャッシュ、切替状態の違いとして切り分ける。

フェイルオーバーの確認は、障害が起きてから初めて試すのではなく、影響範囲を制御した切替演習として扱う。現用系から待機系へ移した際に、再帰制限、送信元検証、レート制御、経路広告、サービス別の到達性が同じ条件を保つかを順に観測し、切替前、切替中、復帰後の結果を残す。演習では正当な問い合わせや通信が維持されることと、許可されていない再帰や不正な送信元が通過しないことを同時に確かめる必要がある。異常が出た場合は安全な状態へ戻し、その時点までの記録を保全して、どの構成差が結果を変えたかを確認する。修正後は同じ条件で再試験し、さらに管理外の複数の観測地点から検証して、内部監視だけでは見えない経路差や露出が残っていないことを確かめる。最後に、再起動、更新、経路変更、待機系への切替を経ても結果が維持されるかを追試し、その確認が終わるまで修復済みという判断を作業完了の記録だけで代替しない。

修復完了の基準は、変更が投入されたことではなく、失敗条件が外部から再現できなくなり、正当なサービスが維持され、予備系への切替後も結果が変わらないことである。独立した観測地点からの再試験と、一定期間後の再確認がなければ、設定変更は作業実績にとどまり、効果の証明にはならない。

14. 因果関係と法的評価の限界

公開記録から比較的強く言えるのは、反射型DNSの仕組み、Cloudflareが報告した観測値、オープン再帰と送信元偽装が結びついた経路、そしてウェブサイトと分散データの違いである。[1][2][3][4] 一方、完全な送信元AS分布、すべてのピーク測定点、第三者が受けた混雑の全体像、各運用者がいつ何を知ったかは確定していない。

特定の交換拠点で何が起きたかについても、個別ポート、共有ファブリック、ピア、トランジットを区別する証拠が必要である。プロバイダー側または交換拠点に面する経路へ負荷が移ったという説明から、交換拠点全体の停止を創作することはできない。[2][16][18]

攻撃主体についても、後年の逮捕に関する資料は関連する文脈を提供するが、それだけで本稿が扱うすべての技術的行為、パケット、法的責任を確定するものではない。[3] 公開記録に裁判上の確定が示されていない範囲では、個人名や組織名を最終的な攻撃者として断定すべきではない。

因果分担を数値化することも難しい。各リゾルバーの送信量、偽装問い合わせを通した各ネットワークの割合、特定経路の容量、緩和による経路変化、重複観測が揃わなければ、誰が全体の何パーセントを生じさせたかは計算できない。個別寄与の不明確さは、制御可能な設定に対する責任を消さないが、根拠のない配分を正当化もしない。

第三者影響も同様である。共有リンクの混雑が他の利用者へ影響した可能性はあるが、どのネットワーク、サービス、利用者が、いつ、どの程度の劣化を経験したかは資料から網羅できない。「広範囲に影響した可能性」と「具体的な全世界障害が実証された」を区別する必要がある。

不明な点を不明なまま残すことは、分析の弱さではない。説明責任を厳密にするための条件である。証拠が示す範囲を超えて断定すれば、修復可能な制御面の議論まで信頼性を失う。

15. ネットワーク説明責任の判定基準

この事件から導ける第一の判定基準は、能力である。再帰リゾルバー運用者は外部への再帰提供を制限できたか。アクセス網は顧客境界で不可能な送信元を拒否できたか。緩和事業者はAnycast、スクラビング、経路、容量を調整できたか。サービス運用者はウェブと分散データを分けて設計し、状態を正確に伝えられたか。

第二の基準は証拠である。設定の存在ではなく、その設定が全対象に適用され、実際に働いたことを示せるかが問われる。リゾルバー一覧、外部露出試験、送信元偽装試験、ドロップ記録、レート制御、BGP変更、上流調整、サービス別可用性、修復後の再試験が一つの時系列として説明できる必要がある。

第三の基準は継続性である。攻撃トラフィックを捨てるだけで正当な利用者まで切断したなら、技術的には別の失敗を作ったことになる。マルチホームの非対称性、Anycast拠点間の差、DNSの権威／再帰の分離、DNSBL更新の鮮度を考慮しながら、不要な機能を閉じ、必要なサービスを保つことが求められる。

第四の基準は外部確認である。管理者自身の画面が正常でも、外から再帰できる、偽装パケットが出る、特定地域からサービスへ届かないという状態はあり得る。異なる経路からの試験、フェイルオーバー後の再確認、時間を置いた追試によって、修復が継続していることを示さなければならない。

第五の基準は主張の範囲である。観測値には観測者と場所を付け、サービス停止には対象サービスを付け、障害には時間窓を付ける。300 Gbit/sを世界全体の値に広げず、ウェブサイト停止をDNSBL全停止に広げず、交換拠点に面した負荷を交換拠点全体の停止に広げない。この限定こそが、技術的説明を信頼できるものにする。

結論

2013年のSpamhaus攻撃が残した教訓は、一つの巨大な回線や一人の著名な当事者に集約できない。偽装された送信元、外部に開かれた再帰、増幅応答、Anycast、BGPが選ぶピアリング／トランジット経路、サービスの依存関係が、複数の運用主体を横断して一つの実行可能な攻撃経路を作った。

Cloudflareが報告した約10、75～90、120、300 Gbit/s、3万台超のリゾルバー、約100倍の増幅は、事件の規模と構造を理解する重要な証拠である。[1][2] しかし、それらは観測者に帰属する数字であり、インターネット全体の単一測定ではない。「インターネットをほとんど壊した」という言葉も、実証済みの世界停止ではなく、当時の広報的な表現として限定しなければならない。

責任は、組織の肩書きや制度的な立場ではなく、動作する構成を誰が変えられたかに従う。再帰運用者は利用境界を管理し、アクセス網は送信元を検証し、緩和事業者は分散と経路を管理し、相互接続事業者は自らのリンクと調整を記録し、サービス運用者は各サービス層の継続性を正確に説明する。

最終的な問いは簡潔である。どの運用者が失敗条件を制御できたのか。制御の実態を何で証明できるのか。修復後、外部から同じ失敗を再現できなくなったか。そして、必要なサービスは維持されたか。答えが証拠で示されるとき、説明責任は非難の言葉ではなく、再発を防ぐ運用能力になる。