Namefi

Dyn DNS攻撃：ハッキングされたカメラのMiraiボットネットがインターネットの半分を壊した日

2016年10月21日、Mirai IoTボットネットによるDDoS攻撃がDNSプロバイダーDynに3波にわたって押し寄せ、Twitter・Netflix・Reddit・Spotify・GitHub・Airbnb・PayPalを数時間にわたってダウンさせた。DNSプロバイダー集中リスクのドメイン・メーデー事例研究。

公開日 2026年6月17日著者 Namefi Team
  • domains
  • security
  • dns
  • domain-security

2016年10月のある金曜日、数時間のあいだ、インターネットは自分自身の居場所を見失った。

Twitterは白紙のページを表示した。Netflixはくるくると読み込み続けて諦めた。Reddit、Spotify、GitHub、Airbnb、PayPal——どれも稼働中で、それぞれのサーバーは完全に正常に動いていたにもかかわらず、どこにも接続できなかった。ハッキングされたわけではない。データが盗まれたわけでもない。ウェブサイトはずっとそこにあった。壊れたのは、インターネットにおける「ものの場所を教える」部分だった。

攻撃はTwitterやNetflixに向けられたのではない。その標的は、利用者のほとんどが名前すら知らなかった企業——ニューハンプシャー州に本拠を置くDynだった。Dynは現代のウェブの大部分にとって、インターネットのアドレス帳であるDNSを運営していた。使われた武器はサーバーファームでも国家レベルのサイバー兵器でもなかった。ハッキングされたベビーモニター、ウェブカメラ、家庭用ルーター——ごく普通の家電製品が静かに徴集され、Miraiと呼ばれる軍隊を形成していたのだ。

これはドメイン・メーデー EP08——安全対策が不十分なスマートカメラがインターネットの電話帳を落とした日の記録である。

DNS：インターネットの電話帳と、その中でのDynの位置づけ

ドメイン名を入力するたびに、コンピューターはそれを数字のIPアドレスに変換してから接続を試みる。この変換を担うのがDNS、すなわちドメインネームシステムだ。人間が読みやすい名前と、その名前が指す実際のマシンをつなぐ参照レイヤーである。

DynはそのDNSルックアップサービスの主要なマネージドプロバイダーのひとつだった。サイトがDNSをDynに委託すると、Dynのネームサーバーが「このドメインはどこにあるのか」という問いへの権威ある回答者となる。The Registerは攻撃中にこう端的に説明した——Dynをオフラインに追い込むことで、GoogleやISPが運営するパブリックDNSリゾルバーはユーザーのホスト名を調べるためにDynへ接続できなくなり、DNSにDynを使っているサイトへのアクセスが遮断されたのだと。

これがこの物語の核心にある静かな脆弱性だ。ウェブサイトがどれほど完璧であっても——冗長なサーバー、完璧な稼働率、世界レベルのエンジニア——「どこにあるか」という問いに答えるプロバイダーが一社だけで、そこが落ちれば、インターネットから消えてしまう。カーネギーメロン大学のCyLabが後にまとめたように、影響を受けたドメインはサードパーティDNSであるDynに決定的に依存していた。つまり、Dyn一社のみに頼っていたため、Dynが落ちれば彼らも道連れになったのだ。

2016年10月21日：波状攻撃

荒れ狂うジャンクトラフィックの大波が巨大な光り輝く電話交換台に押し寄せ、暗い地図の上でディレクトリの灯りが次々と消えていく鮮やかなコンセプトアート

攻撃は2016年10月21日（金曜日）の朝に始まったが、一撃で終わることはなかった。一日をかけて、明確に区別できる複数の波として押し寄せた。

Wikipediaの事件記録によると、UTCで午前11時10分頃から始まった3回連続の分散型サービス妨害攻撃がDynに叩き込まれた。手口は教科書通りのDDoS攻撃だった——数千万のIPアドレスから膨大なDNSルックアップリクエストが送りつけられ、Dynのネームサーバーはジャンクトラフィックに溺れ、正規のリクエストが通らなくなった。

波状攻撃こそが、この攻撃を容赦ないと感じさせた理由だ。The Registerはリアルタイムで状況を伝え、Dynが持ち直したかに見えた瞬間——そして実はそうでなかった瞬間——をこう描写した。最初のジャンクトラフィックの津波から2時間後、Dynは攻撃を緩和し、サービスが通常に戻りつつあると発表した。しかし束の間の安堵に終わった。約1時間後、攻撃が再開されたのだ。終わったと思ったのは、ただのラウンドとラウンドの間隙だった。

規模の面では、この攻撃は当時としては前例のない巨大なものだった——The Registerは最大規模を1Tbpsを超えると表現している。（ただしDyn自身は、正規トラフィックの「リトライストーム」が初期の推計値を膨らませたと注意を促しており、この点については後で触れる。）

どのサービスが落ちたか、そしてそれはどう感じられたか

Dynのネームサーバーが応答できなくなると、障害は同社に依存していたすべての事業者へと連鎖した。影響を受けたのは、ウェブの無名の片隅ではない。一般向けインターネットのまさにフロントページだった。

The Registerのライブレポートは被害者を名指しした——Dynへの異例に集中した攻撃は、Twitterをはじめ、Amazon、Airbnb、Spotifyなど、数百の企業のインターネットサービスを断続的に麻痺させたと。Wikipediaが列挙した影響サービスは、当時最大規模のサイトの名鑑そのものだ——Airbnb、Amazon.com、CNN、GitHub、Netflix、PayPal、Reddit、Spotify、Twitter、そして数十もの企業が連なる。

数週間前に同じマルウェアで自らのサイトを攻撃されていたBrian Krebsは、ユーザー体験をこう描写した——攻撃はTwitter、Amazon、Tumblr、Reddit、Spotify、Netflixを含む多数のサイトへのアクセスに問題を引き起こし始めたと。一般ユーザーにとって、意味のあるエラーメッセージは何も表示されなかった。サイトがただ、読み込まれなかった。最初は米国東海岸で、やがて後続の波とともに米国全土、そしてヨーロッパへと障害が広がった。

どうやって起きたか：安全対策の甘いスマートデバイスで構成された軍隊

ハッキングされた何千もの小さなスマートカメラ、トースター、ベビーモニターが光る昆虫の群れのように、過負荷になった単一のディレクトリタワーへと殺到するカラフルなコンセプトアート

Dyn攻撃を転換点にした要素がここにある——攻撃力の源泉はコンピューターではなかった。モノだった。

Miraiは、IoT（モノのインターネット）デバイス——カメラ、ルーター、DVR——を狩り出してハイジャックするマルウェアだ。その手口は、コンシューマー向けハードウェアの最も怠慢な弱点を突く。出荷時のデフォルトパスワードだ。The Registerが説明したように、Miraiはデバイスの工場出荷時のデフォルトパスワードを使ってTelnetやSSH経由でログインし、従順なゾンビ部隊を増やしながらウェブ全体に広がる。Krebsも同じメカニズムを率直に説明した——Miraiは工場出荷時のデフォルトのユーザー名とパスワードしかかかっていないIoTデバイスをウェブ上でスキャンし、それらを攻撃に動員するのだと。

Dyn攻撃の中核にあったデバイスは主に安価なウェブカメラとDVRだった。Krebsはボットネットの出所を追跡し、中国のハイテク企業、雄迈技術（XiongMai Technologies）製のデジタルビデオレコーダー（DVR）とIPカメラが中心だったと突き止めた。それらのデバイスのデフォルト認証情報は、多くの場合、ユーザーには現実的に変更できない——パスワードがファームウェアにハードコードされていたからだ。

Miraiを厄介者から大惨事へと変えた要因は二つある。第一に、マルウェアの作者が2016年9月末にソースコードを公開し、事実上誰でも独自の攻撃軍を構築できるようにしたこと。第二に、脆弱なデバイスの数が膨大だったこと。Dynは攻撃の特徴を確認した——同社は攻撃トラフィックの相当量がMiraiベースのボットネットから発生したことを確認できたと。Wikipediaはそのボットネットを、プリンター、IPカメラ、家庭用ゲートウェイ、ベビーモニターなど、Miraiマルウェアに感染したインターネット接続デバイスの群れと表現している。

事後処理：群れの規模と実行犯を突き止める

騒動が収まった後、「規模はどれほどだったのか」というごく基本的な問いにさえ、明確な答えを出すのが難しかった。Dynが事後分析で示した、EVPスコット・ヒルトンによる推計では、ボットネットの規模は最大10万の悪意あるエンドポイント——大規模ではあるが、初期段階の「数千万のIPアドレス」という数字よりははるかに小さかった。この乖離はフィードバックループによるものだ。悪意ある攻撃は少なくとも一つのボットネットに由来していたが、リトライストームが、実際よりも大幅に多いエンドポイントの存在を示す偽の指標となったのだ。つまり、インターネット自身の「再試行」という自動的な挙動が、混乱をさらに増幅させた。

法的な後日談にも一捻りある。Miraiの背後にいた3人の若者——パラス・ジャ、ジョサイア・ホワイト、ダルトン・ノーマン——は最終的に、「Miraiボットネット」の作成・運営・アクセス販売への関与について有罪を認めた。しかしDyn攻撃が行われた時点で、ジャはすでにソースコードを公開していた。検察もメディアも、Dyn攻撃の実行犯が必ずしも元の3人組ではなかった可能性を慎重に指摘している。CyberScoopが報じたように、インターネット・パフォーマンス管理企業Dynへの最も注目すべきMirai関連攻撃の背後に誰がいたのか、例えばまだ明らかになっていない部分がある。武器がオープンソースになった瞬間、誰でも引き金を引けるようになった。

Dynへのビジネス的ダメージは現実のものだった。その後数か月で、数千のドメインがDNSを別のプロバイダーへ移転した。一日の失態が顧客の信頼をどれほど損なうか、高い代償を払って学んだ教訓だった。

DNSプロバイダーへの集中がはらむ教訓

Dyn攻撃はIoTセキュリティの問題として語られることが多く、確かにそれは正しい。しかしより深い教訓はアーキテクチャにある——インターネットのあまりにも多くの経路を一つのチョークポイントに集中させることの危うさだ。

10月21日に落ちたサービスのいずれもが、一見合理的な同じ判断を下していた——DNSを一社の優秀なプロバイダーに委託する。個別に見れば賢い選択だ。しかし集合的に見れば、一社を叩き落とすだけで、ウェブの相当な部分を一気に消滅させることができることを意味していた。CyLabの評価では、この攻撃から得られた教訓が直接被害を受けた一握りのサイトにしか活かされていないのは、数年後になっても変わらなかった。

防御の答えは冗長性だ——権威DNSを複数のプロバイダーに分散させることで、どの単一障害も致命傷にならないようにする。Dyn事件から2年後、The Registerは依然としてこの実践が稀であり、難しいままであることを伝えている。InfobloxのCricket Liuは、複数の権威DNSプロバイダーを使うこと（例えばDynとVerisignまたはNeustar）は依然として容易ではない。複数プロバイダーを使えるようになれば大きな違いが生まれると述べた。ドメインを保有するすべての人への教訓は次のとおりだ：

  1. ドメインの障害点はレジストラだけではない。 「この名前はどこを指しているか」に答えるプロバイダーは、その背後のサーバーと同じくらい重要な役割を担っている。
  2. 単一プロバイダーへのDNS集中は単一障害点を生む。 通常時の優れた稼働率は、1Tbpsの洪水に対する耐性については何も保証しない。
  3. 集中は便利だが脆弱だ。 一社のプロバイダーを魅力的にしているのと同じ効率性が、その障害を広く波及させる。
  4. 回復力は所有権の属性であり、ホスティングだけの話ではない。 何かが壊れたとき、素早く経路を切り替えられるよう、自分のドメイン設定を明確にコントロールできることが必要だ。

Namefiの視点

検証可能で回復力のあるドメイン所有権のカラフルなイラスト——グリーンのシールドで保護されたドメインカード、緑のNamefiトークン、DNSの継続性

Dyn攻撃は、ドメインを一つも盗まなかった。移転を偽造したわけでも、レジストラのアカウントをハイジャックしたわけでもない。それでも数時間のあいだ、それらのドメインを所有していた人々は、自分の名前がどこを指しているかについて事実上のコントロールを失った。所有権が疑われたからではなく、ドメインの下にある運用レイヤーが一斉に機能を停止したからだ。

「名前を所有すること」と「名前の解決先を確実にコントロールすること」の間にあるこのギャップ——これがまさに、今回のような攻撃が突いてくる継ぎ目だ。ドメインは企業が保有する最も価値ある資産の一つでありながら、そのコントロールは不透明で中央集権的なインフラの背後に置かれがちで、所有者はそれを検証することも、プレッシャー下で素早く再設定することもできない。

Namefiは、ドメインがインターネットネイティブな資産として振る舞うべきだという考えのもとに構築されている。暗号学的に検証可能でポータブルな所有権でありながら、DNSとの完全な互換性を維持する。検証可能で所有者がコントロールできるドメイン所有権はボットネットを止めることはできない——しかしそれは、名前のコントロールが証明可能で監査可能であり、一社のプロバイダーの最悪の一日に静かに依存しないインターネットへと世界を向かわせるものだ。Mirai-Dyn攻撃は、あなたが「所有している」ドメインは、それに代わって答えるレイヤーと同じくらいしか回復力を持たないことを、改めて示している。回復力の出発点は、所有権とコントロールを実際に検証できるものにすることだ。

参考資料・さらに読む

著者について

Namefi Team
Namefi Team • Namefi
TwitterLinkedIn

Namefi は、オンチェーンドメイン名の管理をもっと簡単にするツールづくりに取り組む、エンジニア、デザイナー、オペレーターのチームです。

関連ガイド