OVHを襲った2016年のMirai攻撃――DDoSスクラビング能力は「説明責任」の試金石になった

要約

OVHcloudは、2016年9月のMirai初期波において1Tbpsを超える攻撃を観測したと公表している。この数値はOVHcloud自身による報告値であり、攻撃対象、参加端末、顧客への影響、観測地点を網羅した独立のパケット単位監査ではない。[1][2]
USENIX Securityで発表された独立研究は、複数の観測点を用いてMiraiの成長と攻撃履歴を再構成した。研究によれば、OVHの基盤に対する攻撃は2016年9月18日に始まり、Miraiの感染規模はピーク時に約60万台、分析対象となった攻撃は1万5,000件を超えた。[3][4]
OVHに対する攻撃は、KrebsOnSecurityやDynに対する別個の攻撃と混同してはならない。同じマルウェア群が関係していても、標的、日付、通信経路、サービスへの作用、緩和対応は同一ではない。
Miraiに感染したカメラや録画装置などは、通常のルーティング可能な送信元アドレスを使って標的へ直接トラフィックを送ることができた。偽装アドレスを用いる反射・増幅型攻撃とは制御上の問題が異なるため、BCP 38だけでMiraiの直接型フラッドを阻止できたとはいえない。[15][16][19][20]
DDoS対策の実効容量は、一つの「Tbps」表示では測れない。ビットレートとパケットレートの観測、ルーターの転送能力、スクラビング能力、制御プレーンの安定性、緩和策の発動時間、正当な通信を戻す経路、顧客側でのサービス成功を一続きの系として検証する必要がある。
スクラビングの成果は、捨てた攻撃トラフィックの量だけでは証明できない。正当な利用者の通信が到達し、アプリケーション処理が完了し、地域別の損失や誤遮断が許容範囲に収まり、通常経路への復帰後も安定していることが必要である。
責任は分散している。機器メーカーは初期認証情報、公開サービス、更新手段、サポート期間を左右する。機器所有者とアクセス事業者は異常な発信通信を検知・抑制できる。トランジット事業者とホスティング事業者は容量、経路制御、フィルタリング、テレメトリー、復旧を担い、法執行機関はボットネット運営者への責任追及を担う。[5][9][10]
公開資料からは、OVHの完全なスクラビング構成、発動閾値、顧客別停止時間、契約上の義務、損害額、全発信元ASの対応状況までは分からない。したがって評価の中心に置くべきなのは断定的な過失判断ではなく、運用者がどの証拠を保持し、どの結果を再現可能な形で示せるかである。

「1Tbps超」は出発点であり、結論ではない

2016年9月、OVHcloudはMiraiの初期波に伴う攻撃が1Tbpsを超えたと公表した。現在の同社DDoS解説はこの出来事を大規模攻撃の年表に位置付け、後年の技術記事はMiraiを1Tbps超を生み出した最初のボットネットとして説明している。[1][2] 家庭や小規模事業所に置かれた多数の機器が、ホスティング基盤に巨大な負荷を集中させ得ることを示した点で、この数字は今なお重要である。

しかし、ピーク値だけではネットワークの状態を再現できない。どの境界で計測したのか、ピークがどれほど継続したのか、一つのインターフェースか複数拠点の合計か、フィルタリング前か後か、どのパケットサイズが支配的だったか、何件の顧客サービスが対象になったかは、この数値からは読み取れない。公開資料に補足情報がない以上、正確な表現は「OVHcloudが1Tbps超を報告した」にとどめるべきである。

この区別は言葉尻の問題ではない。DDoSで枯渇する資源は一つではない。物理回線の帯域が飽和する場合もあれば、ルーターのパケット処理能力、フィルタ装置の分類能力、接続状態を保持するメモリー、制御プレーン、あるいは最終的なアプリケーションが先に限界へ達する場合もある。同じビットレートでも、小さなパケットが大量に届く状況と、大きなパケットが比較的少数届く状況では、転送装置に要求される処理回数が異なる。

OVHcloudが後年公表したパケットレート攻撃に関する技術解説は、コアルーターが直面する処理上の圧力を理解するための有用な資料である。[2] ただし、後年の一般的解説を2016年当時の非公開構成へそのまま投影することはできない。どのルーター、ラインカード、フィルタ規則が当時の制約になったのかは、公表資料からは判定できない。

したがって容量の主張には、測定対象と測定地点、継続時間、パケットレート、発動中だった緩和状態、正当な通信の成功率、経路変更後に生じた次のボトルネックを併記する必要がある。大きな数字が事実であることと、サービス継続性が証明されたことは別の命題である。

1Tbps超という数字は、従来の想定が通用しなくなったことを経営陣、顧客、ネットワーク技術者へ知らせる警報だった。一方で、それ自体はOVHが十分に準備していたとも、不十分だったとも、過失があったとも証明しない。評価に必要なのは、攻撃中に実際の設備と運用手順がどう働いたかを示す記録である。

独立研究が明らかにした範囲

Miraiについて最も強い独立の技術記録は、USENIX Security 2017で発表された研究である。研究者らは、複数の測定データと観測点を組み合わせ、ボットネットの成長、走査、感染、指令基盤、攻撃活動を再構成した。[3][4]

同研究は、Miraiが2016年9月18日からOVHの基盤に対する攻撃を開始したと報告している。また、ボットネットの感染規模がピーク時に約60万台へ達したこと、観測期間を通じて1万5,000件を超える攻撃を分析したことを示している。[3][4] これは、一社のトラフィックグラフだけに依存せず、脆弱なインターネット接続機器が世界規模の攻撃源へ組み込まれる過程を測定した重要な記録である。

もっとも、約60万台という感染規模は、その全端末が同時にOVHへパケットを送ったことを意味しない。1万5,000件超という分析件数も、OVHへの攻撃件数だけを表すものではない。個別攻撃の参加端末、標的、継続時間、通信構成について、研究が示す以上の精度を付け加えてはならない。

同研究は、OVHの顧客別影響台帳、非公開のネットワーク経路、スクラビング発動閾値、商業契約、内部パケット記録を開示するものでもない。どの顧客が何分間到達不能だったのか、どの損失が発生したのか、どの容量をどの拠点に予約していたのかは、別の信頼できる資料がなければ確定できない。

ここには証拠の所在の違いがある。研究者はMiraiの生態系と攻撃履歴の重要な部分を観測した。OVHは自社ネットワークの状態、顧客側テレメトリー、緩和判断を保持していた。アクセス事業者は発信元回線の情報を持ち、機器所有者は端末の状態を知り得た。どの主体も、単独では全体を保有していない。

米司法省は後に、Miraiに関係する事件で被告らが有罪答弁を行ったことを公表した。[5] この資料は、特定の被告がMiraiに関する行為について刑事責任を認めたという限定的な事実を支える。しかし、OVHで観測された個々の攻撃を誰が指示したか、すべてのパケットにどのような意図があったかまで証明するものではない。

KrebsOnSecurity、OVH、Dynを一つの事件にしない

2016年のMiraiを語る際には、KrebsOnSecurity、OVH、Dynへの攻撃がしばしば一つの連続した出来事として要約される。しかし、同じマルウェア群や関連する運営者が関与したことと、各攻撃が同一事件であることは違う。

標的、日付、経路、依存サービス、利用者への作用はそれぞれ異なる。Dynへの攻撃は権威DNSの継続性と、それに依存する多数のサービスへの波及という性格を持つ。一方、OVHの事例で中心となるのは、ホスティング事業者のネットワークが分散型の直接トラフィックをどのように測り、吸収し、フィルタし、正当な通信を顧客へ戻したかである。

また、この事例を後年のmemcached反射・増幅型攻撃と同じ枠に入れることも適切ではない。反射・増幅は、送信元アドレスの偽装、第三者サービスからの応答、増幅率、反射器の管理が中核となる。Miraiの感染端末が直接送信するフラッドでは、発信元機器、アクセス回線、トランジット、標的側容量が別の形で結び付く。

出来事を分けて扱うことは、物語を細分化するためではない。攻撃機構を誤れば、有効な対策を担当できる主体も、残すべき証拠も誤るからである。

直接型ボットネットと反射・増幅型攻撃の違い

反射型攻撃では、攻撃者が被害者のIPアドレスを送信元として偽装し、第三者のサーバーへ要求を送る。そのサーバーが被害者へ応答し、応答が要求より大きければ増幅が生じる。偽装要求を発信元付近で遮断すること、不要な公開サービスを閉じること、反射器を適切に設定することが重要な対策になる。

Miraiの主要な攻撃能力は、この構造を必須としなかった。感染したカメラ、デジタルビデオレコーダーなどの機器は、割り当てられた通常のルーティング可能なアドレスから標的へ直接トラフィックを送ることができた。[3][4] 分散性は、多数の感染端末が参加することから生じたのであり、すべてのパケットが第三者の反射器を経由したからではない。

RFC 2827、すなわちBCP 38は、偽装送信元アドレスを持つパケットを発信側に近い地点で制限するためのイングレスフィルタリングを扱う。[15] RFC 3704、すなわちBCP 84は、マルチホーム環境や非対称経路で、単純な逆方向経路確認が正当な通信まで落とし得るという運用上の問題を含め、より広い実装方法を示す。[16] RFC 7039とMANRSのガイドも、送信元アドレス検証とアンチスプーフィングの改善を扱っている。[19][20]

これらの対策は、偽装に依存する攻撃を減らし、発信元証拠の品質を高める。だが、感染端末が自らに割り当てられたアドレスを使って直接フラッドを送れば、アドレスが正しいという理由だけでBCP 38はその通信を止めない。アンチスプーフィングは、脆弱な認証情報を修正せず、公開された管理サービスを閉じず、標的側ルーターの処理能力を増やさず、スクラビング後の正当な通信経路も保証しない。

したがって、BCP 38を「Miraiを止められたはずの唯一の対策」と表現するのは誤りである。一方で、反射・増幅が混在する攻撃、偽装通信を含む別の攻撃、発信元を判定する際の証拠品質という文脈では、アンチスプーフィングは依然として不可欠である。

直接型フラッドに対しては、送信元分布、プロトコル挙動、宛先集中、時間変化を観測し、アクセス事業者やトランジット事業者と連携して、正当な通信を巻き込まない範囲で異常な発信を制約する必要がある。反射型であれば、これに偽装対策、反射器の封鎖、プロトコル別の署名が加わる。複合攻撃なら両方が必要になる。

NISTの後年の相互接続レジリエンス指針は、DDoS対策をBGPセキュリティ、送信元アドレス検証、フィルタリング、リモート・トリガー型ブラックホール、FlowSpec、レート制御、検知、事業者間調整を含む多層の課題として扱う。[13][14] これは2016年のOVHがそれらをすべて実装していたという証拠ではなく、一つの対策を攻撃機構の範囲以上に万能視してはならないことを示す指針である。

ホスティング継続性を支える観測の連鎖

OVHが直接管理できた中心的な領域は、顧客へ提供していたホスティングネットワークである。分散型フラッドに直面した事業者は、障害になる前に異常を捉え、緩和策を発動するか判断し、ルーティングを不安定化させずに通信を移動またはフィルタし、正当なパケットの通り道を維持しなければならない。

必要なのは一つのダッシュボードではなく、複数の観測面を時刻で結び付けることである。インターフェースカウンターはビットレートとパケットレートを示す。フローレコードはプロトコル、ポート、送信元分布、宛先集中を示す。ルーターのカウンターはドロップ、キュー圧力、制御プレーンへの負荷を示す。スクラビング装置は分類と処置を示し、顧客側または外部のプローブは有用な取引が完了しているかを示す。

BGPおよび内部ルーティングの記録は、どの経路が攻撃通信とクリーントラフィックを運んだかを確認するために必要である。ただし、一部の経路収集点から見える情報は、すべてのプライベートピアリングや内部経路を表さない。経路が広告されていることと、アプリケーションが応答していることも同義ではない。

各観測には限界がある。急増は攻撃だけでなく、正当な需要、ソフトウェア公開、測定障害でも発生し得る。広い送信元分布はボットネットの兆候になり得るが、世界規模の正当な利用でも起こる。スクラビング装置が大量のドロップを報告していても、クリーン側の回線が混雑していれば顧客サービスは回復しない。

したがって説明責任には、異なる観測を突き合わせる作業が必要になる。ビットレート低下とパケットレート低下、ルーターの安定化、スクラビングの分類結果、外部到達性、アプリケーション成功率、顧客報告が整合して初めて、緩和が機能したと判断できる。

2016年当時のOVHの完全な構成は公開されていない。ここで評価できるのは、特定の非公開設計の優劣ではなく、運用者が保持すべき証拠の要件である。最終的な基準は、動作し続けた経路が正当な通信を運び、その結果を事業者が説明できたかどうかにある。

ビットレートとパケットレートは別の限界を示す

帯域容量は理解しやすいため、大規模DDoSは通常bpsで語られる。だが、転送装置はビットの総量だけを処理しているわけではない。各パケットについて、ヘッダーの解析、分類、キュー投入、転送または廃棄の判断が必要になる。同じbpsでも、パケットが小さければ単位時間当たりの判断回数は増える。

ルーターの限界は多次元である。ラインカード、転送ASIC、スイッチファブリック、バッファー、経路プロセッサー、フィルタテーブル、テレメトリー出力は、それぞれ異なる条件で限界に達する。あるプロトコルには安価な規則でも、別のプロトコルには高い処理負荷を生むことがある。攻撃中に詳細なフローデータを大量出力すること自体が、装置資源を消費する場合もある。

そのため、容量試験を集約スループットだけで終えてはならない。複数のパケットサイズ、プロトコル、送信元分布、宛先数、フィルタ規則、ログ設定を組み合わせる必要がある。小パケットによる高pps、大パケットによる高bps、両者が混在する状態では、最初に制約となる部品が異なり得る。

定常状態だけでなく、緩和へ移行する瞬間も試験対象である。通常時には十分な装置でも、フィルタの投入、経路変更、テレメトリー急増が同時に起きたときに失敗することがある。スクラビング拠点の一部停止、トランジット経路の混雑、監視系の遅延といった部分障害も含めるべきである。

試験記録には、上限値だけでなく、その前提を残さなければならない。パケットサイズ分布、規則数、対象プレフィックス数、ログ設定、拠点間の容量共有方法、障害時に残る予備容量を明記する。ベンダーの実験室値と、本番構成で観測した結果も区別する必要がある。

顧客や経営陣が知るべきなのは秘密のフィルタ規則ではない。関連する資源が現実的な条件で試験されているか、発動が演習されているか、容量が独立した障害領域に分かれているか、サービスレベルの証拠が保持されているかである。1Tbpsという一つの値では、これらの問いに答えられない。

スクラビングの成果は「捨てた量」ではなく「届いた通信」で測る

DDoS緩和には二つの結果がある。不要な通信を拒否することと、必要な通信を届けることである。攻撃量やドロップ数は示しやすいため、事業者の説明は前者へ偏りやすい。しかし、顧客が利用するのは後者である。スクラビング後の経路で有用な処理が完了しなければ、緩和が成功したとはいえない。

分類には、プロトコルの妥当性、送信元の挙動、評判情報、パケット形状、宛先の状況、レート、アプリケーション知識などを利用できる。どの方法にも誤検知と見逃しがある。広範なUDP遮断は攻撃を抑えながら、DNS、音声、ゲーム、監視通信を壊す可能性がある。送信元単位のレート制限は、共有アドレスの背後にいる多数の正当な利用者を巻き込むことがある。

ブラウザー向けのチャレンジ方式がAPIや機器間通信に適合するとは限らない。ホスティング事業者は多数の顧客を抱えるため、すべての正当なプロトコル挙動を事前に把握できない。顧客別の例外、緊急連絡先、規則を安全に変更する経路が必要であり、顧客側にもサービス要件を正確に伝える責任がある。

回復確認には、ネットワーク到達性だけでなく、合成監視と実取引に近いプローブを用いるべきである。経路が見えていてもオリジンが応答しないことがある。TCP接続が成立しても、アプリケーション処理が失敗することがある。世界平均が正常でも、特定地域や特定アクセス網からの通信が失われている場合がある。

事業者は複数地域、複数ネットワークからサービスを検査し、アプリケーション成功率をルーターおよびスクラビングの記録と照合する必要がある。最初の回復表示が出た後も、再発、経路振動、残存フィルタ、遅延の悪化を監視しなければならない。

誤遮断や副作用は、最終ステータスが「復旧」になったからといって記録から消してはならない。どのプロトコルや地域が制限されたか、どの顧客に例外が必要だったか、ある標的を守る規則が別の標的へ負荷を移したか、攻撃量の低下後もクリーントラフィックの劣化が続いたかを残すべきである。

すべての署名や閾値を公開する必要はない。詳細は攻撃者に利用され得る。一方、攻撃の種類、測定規模、主要な緩和処置、影響時間帯、回復を確認した指標、残された不明点は、境界を定めた形で公表できる。顧客、監査人、規制当局には、適切な守秘条件の下で、より詳細な証拠を提示できる。

OVHの公開資料は、攻撃規模と緩和の必要性を示すが、顧客ごとのクリーントラフィック配送結果までは開示していない。この欠落は「顧客が到達できなかった」という証拠でも、「全顧客が問題なく到達できた」という証拠でもない。明示すべき既知の不明点である。

責任は攻撃通信が被害者へ届く前から始まる

Miraiは、侵害された機器を攻撃者のネットワーク設備として利用した。したがって責任の連鎖は被害側ホスティング事業者より上流から始まるが、一人の主体へ集約されるわけではない。

機器メーカーとソフトウェア供給者は、初期認証情報、管理インターフェースの公開範囲、更新機構、認証方針、サポート終了後の扱いを設計する。固有の認証情報、制限された管理面、署名付き更新、明確なサポート期間は侵害可能性を下げる。ENISAは、日常的な接続機器がボットネットの構成要素になり得る危険を警告した。[9]

米商務省と国土安全保障省によるボットネット報告は、技術エコシステム全体での協調行動を求めた。[10][11] NISTのIoT型DDoS緩和プロジェクトも、機器セキュリティとネットワークの耐障害性を関連する課題として扱っている。[12] これらは責任分担を考えるための指針であり、特定メーカーがOVHへの攻撃を認識しながら放置したと証明する資料ではない。

機器所有者は、製品が許す範囲で認証情報の変更、不要な公開サービスの制限、更新、隔離、交換を行える。ただし、利用者に十分な技術知識がない場合や、メーカーが修正手段を提供していない場合もある。こうした制約は、実行可能な救済策と経済的インセンティブを考える上で重要である。

アクセス事業者は、顧客回線から出る走査、異常な接続先の広がり、長時間の攻撃トラフィックを観測できる場合がある。運用可能な不正利用窓口を維持し、顧客へ通知し、比例的な制限を行うことができる。しかし、攻撃通信で観測された一つのIPアドレスだけでは、機器所有者、共有アドレスの利用者、アクセス事業者の認識や対応を確定できない。

トランジット事業者は、容量、ブラックホール、FlowSpec、上流フィルタリングなどを提供し、被害者の接続回線へ届く前にトラフィックを制約できることがある。[13][14] その一方で、認可範囲を誤ったブラックホールや広すぎる規則は、守るべきサービス自体を消してしまう。迅速さだけでなく、対象プレフィックスと権限の正確さが必要である。

Akamaiの2016年第3四半期資料は、当時のDDoS脅威環境を理解するための業界的背景を提供する。[7][8] また、通信レジリエンスに関する政府資料は、相互接続された事業者間での継続性と協調の重要性を示す。[6] ただし、これらはOVHの非公開運用や個々の顧客影響を直接証明するものではない。

OVHは、自社のホスティング境界、内部容量、緩和策の発動、顧客連絡、復旧証拠を管理した。このため本件の中心的な運用者となるが、機器のファームウェアやすべての発信元回線を管理していたわけではない。法執行機関はボットネット運営者を捜査・訴追できるが、攻撃中のリアルタイムなパケット制御を担う主体ではない。[5]

説明責任は、各主体が現実に観測・変更できた範囲に従って配分されるべきである。最大のブランドへ結果をすべて帰属させるのでも、責任が分散していることを理由に誰も検証しないのでもない。各主体が保持していた制御、残した証拠、次の運用者へ与えた結果を問う必要がある。

発信元ネットワークの証拠を、根拠のない告発にしない

直接型ボットネット通信では、送信元アドレスが実在していても、それが攻撃を命じた人物を示すとは限らない。アドレスが指すのは、加入者回線、キャリアグレードNATの出口、企業の境界装置、侵害された端末、あるいは一時的な割り当てである可能性がある。

再発を抑えるために有用な報告には、タイムゾーン付きの時刻、送信元と宛先のアドレス、プロトコル、ポート、パケット数、バイト数、サンプリング方法、判定の確信度、実施した緩和処置、送信元偽装を評価したかどうかを含めるべきである。法的・比例的に許される範囲で、短いパケット標本や署名情報を添えれば、受信側ネットワークは正当な通信との区別を行いやすい。

ASN、WHOIS、RDAP、IPアドレスの登録記録は、アドレス範囲を管理するネットワークと公表された運用連絡先を探すために役立つ。しかし、それらは資源の委任と運用メタデータを記録する仕組みであり、誰がパケットを生成したかを断定する証明書ではない。あるASが経路を広告していた事実も、そのASが感染端末の存在を知っていたことや、攻撃を容認したことを証明しない。

登録情報の価値は、正確で最新であり、実際の運用窓口へつながるときに生まれる。登録項目や認証バッジだけではパケットは止まらない。担当者が報告を受け取り、対象回線または端末を特定し、比例的な措置を行い、その結果を記録して初めて制御として機能する。

MANRSのような業界規範は、アンチスプーフィングや事業者間調整を具体的な実務へ落とし込む点で有用である。[20] ただし、規範への参加表明を、現在のフィルタリングや対応結果の代わりにしてはならない。問われるのは肩書ではなく、実際の通信に対して制御が働いたかである。

不正利用報告は、検証可能で、時間範囲が限定され、意図に関する断定を避けたものでなければならない。送信側と受信側は、報告、対応、結果をともに残すべきである。反復する報告は構造的な問題を示す場合があるが、単発の観測は一時的な侵害や測定誤差の可能性も残す。

OVHにとって、この種の証拠は発信元ネットワークへの通知や、より精密な緩和に利用できた可能性がある。しかし、完全な発信元AS一覧や各事業者の対応状況は公表されていない。そこから先は、証拠を保有する主体に確認しなければならない。

緩和策の発動には権限、演習、ロールバックが要る

大規模攻撃中に通信処理を変更する瞬間は、それ自体が障害要因になる。新しいフィルタが正当なパケットを遮断し、経路変更が誤ったプレフィックスを撤回し、予定していたスクラビング経路が利用不能になり、複数の対応者が矛盾した変更を加える可能性がある。

発動方針では、誰が変更できるか、どのプレフィックスとサービスが対象か、どの観測が発動を正当化するか、成功を何で確認するかを定める必要がある。自動化は遅延を減らせるが、承認済みの対象と試験済みの経路に制約されるべきである。未知の状況には手動判断が必要となるが、その際にも一人の明確なインシデント責任者と共通の状況認識が要る。

事前試験では、経路認可、BGPセッション、コミュニティ、プレフィックスリスト、クリーン側の戻り経路、監視系を確認する。部分的な迂回が可能か、非対称経路で状態保持型サービスがどう動くか、一つのトランジットまたはスクラビング拠点を失った場合にも経路が成立するかを試す必要がある。

攻撃中の重要な変更は、時刻、実施者、対象、根拠、期待結果、確認結果、解除条件とともに共通の変更記録へ残す。これは、サービス停止中に形式的な承認を重ねるという意味ではない。どの処置が現在有効で、誰が次の判断を持ち、後で何を解除すべきかを全員が確認できるようにするためである。

ロールバックは発動と同じ重さで設計する必要がある。攻撃後に残ったフィルタは、気付かれないまま顧客通信を損なう可能性がある。早すぎる緩和解除は第二波へサービスをさらす。一定の安定観測期間、段階的な通常経路への復帰、再発時の再発動条件が必要である。

RFC 4732は、DoS対策そのものが有害な副作用を生み得ることを指摘する。[17] RFC 4948は、インターネットセキュリティにおける責任とインセンティブの分散を広い課題として扱う。[18] これらはOVHの非公開手順を示す資料ではないが、対策は設定の存在ではなく、稼働時の結果で評価すべきだという原則を支える。

計画書が論理的でも、実際の境界では失敗し得る。上流事業者が経路を受理しない、クリーン側トンネルが不足する、顧客依存先が迂回経路を通らない、といった問題は演習または実際のインシデントでしか判明しない。説得力のある証拠は、意図した経路が現実にサービスを運んだという実施記録である。

ピアリングとトランジットは容量の所在を変える

DDoS容量は、標的ネットワーク内の一つの装置だけで決まらない。攻撃通信がどのトランジット、ピアリング、交換点、拠点間回線を通り、どこでフィルタ経路へ移され、クリーントラフィックがどこから顧客側へ戻るかによって、実効的な上限は変わる。

上流で十分にフィルタできても、スクラビング拠点からホスティング網へ戻る接続が細ければ、正当な通信は届かない。標的ネットワーク内でフィルタしても、入口回線がすでに飽和していれば効果は限定される。複数拠点の容量を合算して宣伝していても、特定地域からその容量へ到達できなければ、地域別の実効容量は小さくなる。

経路変更の成功は、自社ルーターの設定だけでは証明できない。上流事業者が広告を受理したか、外部観測点から意図した経路が見えるか、攻撃トラフィックが実際に緩和側へ移ったか、正当な戻り通信が非対称性や状態不整合で失われていないかを確認する必要がある。

ブラックホールは、より広い基盤を守るために標的への通信を意図的に捨てる手段となる。これは攻撃の波及を止めることはできても、標的サービスの継続を証明しない。FlowSpecなどの細粒度制御も、規則の正確さ、伝播範囲、対応機器、解除手順が伴わなければ副作用を生む。[13][14]

トランジット事業者と緩和事業者には、利用可能容量、発動状態、受理した経路、フィルタ結果を被害側へ伝える役割がある。被害側には、対象プレフィックスと権限を正確に伝え、顧客サービスの成否を上流の観測へ戻す役割がある。片側のドロップ数だけでは、端から端までの成功は分からない。

OVHの公開資料からは、2016年当時の私的なピアリング関係、予備容量、経路優先順位、拠点別のスクラビング上限を確定できない。したがって本件から導けるのは特定構成への評価ではなく、容量主張を経路と障害領域へ結び付ける必要性である。

記録と稼働結果を分ける証拠パッケージ

インシデント後に最も価値があるのは、「同じ攻撃は二度と起きない」という約束ではない。何が起き、どの制御を変更し、どのように試験し、何が分からないまま残ったかを境界付きで示す証拠パッケージである。

制御領域	保持すべき証拠	稼働試験	重要な限界
トラフィック検知	時刻同期されたインターフェース、フロー、パケットレート、サービスの記録	複数の信号が重大障害前にフラッドを識別する	サンプリングや集約は短時間・局所的な影響を隠し得る
容量境界	所定のパケット構成に対する回線、転送、フィルタ、クリーン経路の上限	代表的な負荷が試験済み資源内に収まる	実験室値やベンダー値は本番と一致しない場合がある
緩和権限	承認済みプレフィックス、責任者、事業者セッション、発動条件	意図した経路とフィルタだけが変更される	承認は外部での経路収束を証明しない
経路・通信の迂回	変更前後の広告、外部観測、上流事業者の受理記録	対象通信が緩和経路へ到達する	公開収集点から全私的経路は見えない
攻撃分類	プロトコル、送信元分布、パケット標本、確信度	規則が観測された攻撃ベクトルを抑える	攻撃者はベクトルを変えられ、署名は過剰遮断を起こし得る
クリーントラフィック配送	地域別プローブ、アプリケーション成功率、遅延、オリジン状態	緩和中も正当な取引が完了する	合成監視は顧客固有の通信を見逃し得る
副作用	誤遮断された通信、例外、顧客報告	被害が明示した範囲内に収まる	障害を報告しない利用者もいる
発信元との調整	時間範囲付き不正利用報告、連絡先、対応、再観測	発信元側が対象機器または回線を発見し制約できる	アドレス証拠は人物の身元や意図を証明しない
ロールバック	変更記録、責任者、解除基準、段階的復帰	再発を招かず通常経路へ戻る	後続攻撃では再発動が必要になる
改善の持続性	演習、例外、容量レビュー、最新の対応手順	時間が経過しても制御が試験に合格する	一度の成功は恒久的な安全を意味しない

この表は、文書が存在することと、サービスが動作したことを分けている。チケットは行動の意図を記録する。容量計画は前提を記録する。ASNの登録は経路運用主体を探す手掛かりとなる。フィルタ設定は規則を記録する。しかし、いずれも利用者の要求が攻撃中に完了したことを単独では証明しない。

証拠は公開可能な部分と保護すべき部分に分けられる。一般向けには、時刻、規模、攻撃ベクトル、主要な処置、回復指標、不明点を示せる。詳細なトポロジー、閾値、パケット標本、契約、内部判断は、顧客、監査人、規制当局が守秘条件の下で確認できるよう保持すればよい。

中心となる作業は照合である。入口のインターフェースカウンターはスクラビング側の記録と整合するか。経路変更は外部観測と一致するか。フィルタリング後のオリジン状態とアプリケーション成功率は改善したか。地域プローブと顧客報告の差は、測定範囲の違いで説明できるかを確認する。

記録同士が一致しない場合、一方を都合よく捨てるべきではない。不一致は、観測地点、時刻同期、サンプリング、経路、顧客固有条件を再調査すべき信号である。説明責任は、きれいなグラフを作ることではなく、異なる証拠が示す境界を説明することにある。

公開記録が証明していないこと

公開記録は、OVHの基盤に対する大規模なMirai攻撃と、OVHcloudが公表した1Tbps超のピークを支える。[1]–[4] また、Miraiが多数の侵害機器から直接型トラフィックを生成できたこと、多層の機器・ネットワーク・経路・緩和対策が必要であることを支える。

一方、正確な標的、影響を受けた全顧客、顧客別の影響時間、非公開のスクラビング構成、フィルタ規則、発動閾値、予備容量、クリーン経路は明らかにしていない。1Tbps超という数値を、独立機関がパケット単位で監査した記録でもない。

顧客の金銭的損失、サービスクレジット、契約違反、法的な注意義務違反も立証していない。各攻撃に参加した全感染端末と全発信元AS、各アクセス事業者が何を検知し、どの措置を講じたかも分からない。

後年のOVH技術記事、NIST、NTIA、ENISA、MANRS、IETFの資料は、パケットレート、ルーティング、機器セキュリティ、アンチスプーフィング、緩和の副作用を理解するための指針となる。[2][9]–[20] これらを、2016年9月のOVHが特定制御を実装していた証拠として扱ってはならない。

司法省資料はMirai関連事件における有罪答弁という限定的事実を示す。[5] OVHが観測した各攻撃の指示者や、個々のパケットの意図まで帰属させる根拠にはならない。

これらの限界は分析を無意味にするものではない。むしろ、責任ある結論の範囲を定める。公開情報から架空の内部事後報告書を作るのではなく、ホスティング事業者とその接続先が示すべき制御と証拠を評価することができる。

運用者、顧客、監査者が問うべきこと

ホスティング・トランジット事業者

平常時の基準値に、bpsだけでなくpps、プロトコル、宛先分布、サービス成功率を含めているか。
小パケット、大パケット、混合通信で、それぞれどの部品が最初のボトルネックになるか。
プレフィックス、拠点、顧客単位で、迂回またはフィルタリングを独立して実施できるか。
スクラビング用セッション、経路認可、コミュニティ、クリーン側の戻り経路を定期的に試験しているか。
攻撃中に、上流事業者の受入状態、残存容量、フィルタ状態を確認できるか。
広範な規則から保護すべき正当なプロトコルを把握しているか。
発動とロールバックについて、一人の明確な責任者がいるか。
発信元ネットワークへ、プライバシーに配慮した精密な証拠を提供できるか。
回復確認が、攻撃で過負荷になり得る同じ監視系だけに依存していないか。
顧客報告と外部プローブを内部の正常表示と照合しているか。

機器メーカーと所有者

初期認証情報は機器ごとに固有か。
管理インターフェースは必要最小限に制限されているか。
製品の実用期間を通じて認証済み更新を受けられるか。
サポート終了が、機器の購入・運用判断に間に合う形で明示されているか。
所有者は異常な走査や攻撃通信を観測できるか。
修正不能な機器を隔離または交換する現実的な手段があるか。

顧客

事業者は、どの攻撃規模とパケット構成を本番に近い条件で試験したか。
緩和は常時型、オンデマンド型、混合型のいずれで、移行を何が引き起こすか。
緊急フィルタリングで制約される可能性がある顧客プロトコルは何か。
クリーントラフィック配送と地域別回復を、事業者はどう証明するか。
インシデント後に、どの証拠と説明を受け取れるか。
代替事業者、経路、オリジンは、名称だけでなく障害領域として独立し、試験されているか。

監査人と規制当局

容量主張は、測定地点、パケット構成、規則、日付へ結び付いているか。
証拠は攻撃通信のドロップだけでなく、正当なサービスの完了を示しているか。
緩和権限とロールバックは、承認済み資源へ限定されているか。
非公開のパケット・トポロジー証拠を、安全な条件で検証できるか。
改善策には、最新の演習結果、失敗記録、例外一覧があるか。
ASN、IPアドレス、経路、連絡先の記録は、実際の運用対応へ接続されているか。

これらの問いは、無限の容量や完全な無停止を要求するものではない。既知の脅威を検知し、限定された権限で行動し、重要サービスを守り、結果を説明できるかを問うものである。

結論――容量に責任を持つとは、正当な通信の生存を示すこと

OVHcloudが報告した1Tbps超のMirai攻撃は、DDoS規模の歴史に残る出来事である。独立研究は、多数の侵害機器が世界規模の直接トラフィックを生成できたことを示した。政府、標準化、業界の資料は、対応が機器セキュリティ、アクセス網、トランジット、ホスティング、フィルタリング、法執行にまたがることを示している。[1]–[20]

教訓は、一社が無限の帯域を購入すべきだったということではない。あらゆる攻撃を必ず吸収できると約束できるネットワークは存在しない。重要なのは、容量の主張を稼働中の証拠へ結び付けることである。

必要な証拠には、明示された境界でのbpsとpps、発動条件、限定された経路・フィルタ変更権限、クリーン側の容量、地域別サービスプローブ、副作用の記録、発信元ネットワークとの調整、演習済みのロールバックが含まれる。直接型ボットネットと反射・増幅型攻撃を区別し、アンチスプーフィングはその機構が実際に適合する範囲で用いなければならない。

責任は分散している。メーカーは安全でない初期設定を減らせる。所有者は更新または隔離を行える。アクセス事業者は異常な発信を検知・制約できる。トランジットと緩和事業者は容量とフィルタを提供できる。OVHはホスティング経路を運用し、回復を証明できる。法執行機関はボットネット運営者を追及できる。各主体は、実際に保持していた制御と作成できた証拠によって評価されるべきである。

トラフィックグラフ、ASN、容量計画、インシデント記録、フィルタ設定はいずれも重要である。しかし、それらはサービスそのものではない。最後に問われるのは、敵対的な通信を制約する間も、正当な仕事を持つパケットが目的地へ届いたかである。

ホスティングネットワークにおける説明責任の証明は、事後報告書に載った最大の数字ではない。クリーントラフィックが生き残り、制約資源が把握され、別の運用者が検証できる形で復旧記録が残されたことである。

出典

OVHcloud「DDoS攻撃とは」: https://www.ovhcloud.com/en-gb/security/anti-ddos/ddos-definition/
OVHcloud「パケットレート攻撃の台頭――コアルーターが牙をむくとき」: https://blog.ovhcloud.com/en/posts/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
USENIX Security 2017「Understanding the Mirai Botnet」発表ページ: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
Antonakakisほか「Understanding the Mirai Botnet」: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
米司法省、Mirai関連事件の訴追および有罪答弁に関する発表: https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
米国家安全保障電気通信諮問委員会、Internet and Communications Resilience報告書: https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20ICR%20FINAL%20%2810-12-17%29%20%281%29-%20508%20compliant_0.pdf
Akamai、2016年第3四半期State of the Internet Securityエグゼクティブサマリー: https://www.akamai.com/site/en/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-executive-summary.pdf
Akamai、2016年第3四半期State of the Internet Security報告書発表: https://www.akamai.com/content/akamai/it/newsroom/press-release/akamai-releases-third-quarter-2016-state-of-the-internet-security-report1
ENISA「洗濯機や血圧計がサイバー攻撃の標的になるとき」: https://www.enisa.europa.eu/news/enisa-news/the-internet-of-things-when-your-washing-machine-and-blood-pressure-monitor-become-a-target-for-cyberattacks
NTIA、米商務省・国土安全保障省によるボットネット対策報告書の発表: https://www.ntia.gov/press-release/2018/us-departments-commerce-homeland-security-release-report-president-promoting-action-against-botnets
米商務省・国土安全保障省、ボットネット報告書: https://www.ntia.gov/sites/default/files/publications/eo_13800_botnet_report_for_public_comment_0.pdf
NIST「Mitigating IoT-Based DDoS」: https://csrc.nist.gov/pubs/pd/2017/12/14/mitigating-iotbased-ddos/final
NIST「Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation」: https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation
NIST Special Publication 800-189: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
IETF、RFC 2827 / BCP 38、Network Ingress Filtering: https://datatracker.ietf.org/doc/rfc2827/
IETF、RFC 3704 / BCP 84、Ingress Filtering for Multihomed Networks: https://datatracker.ietf.org/doc/rfc3704/
IETF、RFC 4732、Internet Denial-of-Service Considerations: https://datatracker.ietf.org/doc/rfc4732/
IETF、RFC 4948、Internet Security Challenges: https://datatracker.ietf.org/doc/rfc4948/
IETF、RFC 7039、Source Address Validation Improvement: https://datatracker.ietf.org/doc/html/rfc7039
MANRS、Network Guide: Anti-Spoofing: https://docs.manrs.org/docs/network-guide/anti-spoofing/