SQL Slammerから学ぶ「376バイト」が世界を止めた10分間の衝撃

「昔のサイバー攻撃って、たった1つのワームでインターネット全体が止まることなんてあったの？」
「パッチを当てなかっただけで、そこまで大きな被害になるものなの？」

チップス

ボス、SQL Slammerってワーム、名前だけは聞いたことあるでしゅ。
でも「10分で世界中に広がった」って、さすがに盛ってないでしゅか？

ボス

盛ってなどいない。
376バイト、UDPパケットたった1発。
それだけで銀行のATMが止まり、航空便が欠航し、原子力発電所の監視システムまで落ちた。
しかも、パッチは半年前に出ていたんだ。
この話を「昔の話」で済ませるなら、お前はまた同じ失敗を繰り返すぞ。

2003年1月25日の早朝、インターネットの速度が世界規模で急激に低下しました。
原因は、Microsoft SQL Serverの脆弱性を突いたワーム「SQL Slammer」。
わずか376バイトのコードが、10分足らずで7万5,000台以上のサーバに感染し、ネットワークを飽和状態に追い込んだのです。

この記事では、SQL Slammerがどのように世界を混乱に陥れたのか、その技術的な仕組みから被害の実態、そして私たちが今も学ぶべき教訓まで掘り下げていきます。
20年以上前の事件ですが、パッチ管理やネットワーク設計の「落とし穴」は、形を変えて今も残っています。

2003年1月25日、インターネットが10分で麻痺した

SQL Slammerは、サイバーセキュリティ史上もっとも速く広がったワームとして記録されています。
その感染速度と、被害の規模を見ていきましょう。

史上最速のワーム「SQL Slammer」の出現

UTC（協定世界時）の2003年1月25日午前5時30分ごろ、SQL Slammerは活動を開始しました。
日本時間では同日の午後2時30分。
週末の昼下がりに、インターネットは突然おかしくなり始めます。

狙われたのは、Microsoft SQL Server 2000とMSDE 2000（Microsoft SQL Server Desktop Engine）のResolution Serviceです。
UDP 1434番ポートに届いたたった1つのパケットが、バッファオーバーフローを引き起こし、任意のコードを実行させる。
感染が成立するのに、相手からの応答すら必要ありませんでした。

感染の広がり方を時系列で見ると、その異常さがよく分かります。

10分で90%感染。
コーヒーを1杯淹れる間に、世界中の脆弱なサーバがほぼ全滅していた計算です。
CAIDAの研究チームは、SQL Slammerを「史上最速のコンピュータワーム」と結論づけています。

チップス

10分で90%って…！
パッチ当てようと思った頃にはもう手遅れじゃないでしゅか！

ボス

その通りだ。
だからこそ「攻撃が始まる前に備える」ことが全てなんだ。
始まってからでは、何もできん。

たった376バイトに込められた破壊力

SQL Slammerの最大の特徴は、その「小ささ」にあります。
ワーム全体がわずか376バイト。
UDPパケット1つにすっぽり収まるサイズです。
参考までに、この段落のテキストのほうがはるかに大きい。

この極端なコンパクトさが、SQL Slammerを凶悪なものにしていました。
従来のワームとの違いを整理してみましょう。

興味深いのは、SQL Slammer自体には破壊的なペイロード（攻撃用の仕掛け）が一切なかった点です。
ファイルを消すわけでもなければ、バックドアを仕掛けるわけでもない。
やっていたのは「感染先を見つけて自分のコピーを送りつける」、ただそれだけ。

では何が問題だったのかというと、感染したサーバが一斉にランダムなIPアドレスへパケットを送り続けたことで、ネットワーク帯域がパンクしたのです。
ワーム自体は「うるさいだけ」だったのに、その「うるささ」がインターネット全体を使いものにならなくしてしまった。
ディスクに何も書き込まないため、サーバを再起動すればワームは消えます。
しかし、ネットワークが詰まっている状態ではリモートからの再起動すらままならなかったのが実情です。

SQL Slammerはなぜこれほど速く広がれたのか

376バイトのワームが10分で世界を覆い尽くした背景には、UDPの特性と脆弱性の組み合わせがありました。
技術的な仕組みを掘り下げてみます。

UDP通信とバッファオーバーフローの組み合わせ

SQL Slammerが悪用した脆弱性は、CVE-2002-0649として登録されています。
Microsoft SQL Server 2000のResolution Serviceが待ち受けるUDP 1434番ポートに、特定の形式のパケットを送り込むと、バッファオーバーフローが発生。
攻撃者が指定したコード（この場合はワーム本体）がサーバ上で実行される仕組みです。

攻撃の流れを見てみましょう。

ここで決定的だったのが、UDPというプロトコルの性質です。
TCPであれば、通信を確立するためにSYN→SYN-ACK→ACKという3段階の手順（3ウェイハンドシェイク）が必要になります。
しかしUDPにはそれがない。
送る側は「送りっぱなし」でよく、返事を待つ必要がありません。

つまり、感染したサーバは「パケットを作って投げる」作業を、CPUとネットワーク帯域の限界まで延々と繰り返せたわけです。
1台のサーバが毎秒数千〜数万のパケットを撒き散らし、それが連鎖的に増幅されていきました。

8.5秒で倍増する指数関数的な感染拡大

CAIDAの分析によると、SQL Slammerの感染ホスト数は約8.5秒ごとに倍増していました。
この「倍増時間8.5秒」は、それまでのあらゆるワームの記録を大きく塗り替えるものです。
比較してみると、その速さが際立ちます。

Code Redの約260倍の速さで増殖した計算です。
ただし、この爆発的な拡散には自然なブレーキもかかりました。
感染が進むにつれ、ネットワーク帯域の飽和とパケットロスが増大し、新たな感染を阻害し始めたのです。

皮肉な話ですが、SQL Slammerがもう少し「お行儀よく」帯域を使っていたら、もっと多くのサーバに感染していた可能性があります。
あまりに暴力的な速度で拡散したがゆえに、自らトラフィック渋滞を引き起こして、ある意味「自分で自分の足を引っ張った」わけです。

チップス

自分で渋滞を起こして自分も遅くなるって、なんか間抜けでしゅね…。
でも、それでも10分で90%って十分やばいでしゅ！

ボス

ふふふ、間抜けに聞こえるか。
だが、もし攻撃者がスキャン速度を意図的に抑える「スロースキャン」型にしていたら、検知はもっと難しくなっていた。
速さが裏目に出たことで、むしろ発見は早まった。
攻撃の「効率」と「隠密性」はトレードオフなんだ。

世界中で発生した被害の実態

破壊的なペイロードを持たなかったSQL Slammerですが、ネットワーク帯域の飽和だけで社会インフラに深刻なダメージを与えました。
被害は想像以上に広範囲に及んでいます。

ATM停止・航空便欠航・911不通という連鎖障害

SQL Slammerの影響は、ITインフラだけにとどまりませんでした。
ネットワークの遅延や断絶が、私たちの生活に直結するサービスを次々とダウンさせたのです。

アメリカではBank of Americaが大きな被害を受けました。
全米約13,000台のATMのほぼすべてが一時的に使用不能に。
土曜日の朝、現金を引き出そうとした利用者は途方に暮れることになりました。
大半は当日夕方までに復旧しましたが、翌日になっても使えないATMがあったとの報告も残っています。

被害を受けた主なサービスは以下の通りです。

特に深刻だったのが、Davis-Besse原子力発電所のケースです。
SQL Slammerは外部の契約業者のネットワーク経由で発電所の社内ネットワークに侵入し、安全パラメータ表示システム（SPDS）を約5時間にわたって停止させました。
当時、同発電所は運転を停止していたため直接的な安全上の問題は起きていませんが、制御システムがインターネット経由の脅威にさらされうるという事実は、業界に大きな波紋を広げました。

Continental Airlinesでは、予約システムがダウンしたため、一部のスタッフがペンと紙で搭乗手続きを行うという事態に。
航空会社のシステムがたった376バイトのワームで紙に逆戻りするとは、誰も想像していなかったでしょう。

チップス

原発の監視システムまで！？
これ、もし運転中だったらどうなってたんでしゅか…？

ボス

停止中だったのは不幸中の幸いだ。
だが、この一件は「制御系ネットワークをインターネットから分離しろ」というメッセージそのものだった。
この教訓が、後のICS（産業制御システム）セキュリティの議論を加速させたんだ。

韓国2,700万人のインターネットが消えた

SQL Slammerの被害がもっとも集中したのは、当時世界有数のブロードバンド大国だった韓国です。
国民の大半がインターネットに接続している環境が、皮肉にも被害を増幅させる結果になりました。

韓国では約2,700万人がインターネット接続を失い、その状態は約10時間にわたって続きました。
主要ISPのKT Freetel CorpやSK Telecomの回線が軒並みダウンし、携帯電話のデータ通信にも影響が及んでいます。
国全体のインターネットがほぼ丸1日使えなくなるという、他国では見られなかった規模の被害です。

なぜ韓国でここまで被害が拡大したのか。
背景にはいくつかの要因が重なっています。

ロンドンの市場調査会社の推計では、SQL Slammerが最初の5日間で世界に与えた経済的損失は9億5,000万〜12億ドル（当時のレートで約1,100億〜1,400億円）に達しています。
破壊的なペイロードを持たないワームが、ネットワーク帯域を食い潰すだけでこれだけの損害を出したというのは、ある意味で衝撃的な事実です。

チップス

国全体のネットが10時間止まるって…。
今の日本でそれが起きたら、もう社会が回らないでしゅよ…。

ボス

その通りだ。
2003年の韓国でさえあの混乱だったんだから、あらゆるものがネットに依存している今の社会で同じことが起きたら、被害は桁違いになるだろうな。
だからこそ、インフラを守る側の責任は重い。

6か月前に出ていたパッチと、私たちへの教訓

SQL Slammerから得られる教訓は、技術的な巧妙さへの感嘆ではなく、「なぜ防げなかったのか」への反省です。
20年以上前の話とはいえ、同じ構造の失敗は今も繰り返されています。

MS02-039を適用しなかった理由と代償

SQL Slammerが悪用した脆弱性（CVE-2002-0649）に対するパッチは、Microsoftのセキュリティ情報MS02-039として2002年7月に公開されていました。
ワーム発生の約6か月前です。
つまり、パッチさえ当てていれば感染しなかった。
結果論ではなく、事実としてそうなのです。

ではなぜ、6か月もの猶予がありながらパッチは適用されなかったのか。
当時よく聞かれた理由は以下のようなものでした。

3つ目の理由は特に根深い問題でした。
MSDE 2000はVisual Studioや各種業務アプリケーションにバンドルされており、開発者やユーザが「SQL Serverが動いている」と認識していないケースが多かったのです。
自分の環境に何が入っているか把握していなければ、パッチを当てるべきかどうかの判断すらつきません。

この「資産の可視化」の問題は、2003年から20年以上経った今でもセキュリティの現場を悩ませ続けています。
Log4Shellのときも「うちのシステムのどこにLog4jが入っているか分からない」と慌てた組織は少なくなかったはずです。

チップス

うっ…「まさか自分が」って思っちゃう気持ち、分かるでしゅ…。
オイラも正直、パッチ当てを後回しにしたこと、あるでしゅ…。

ボス

正直に言ったのは評価するが、二度とやるなよ。
SQL Slammerは「後回し」のツケが9億5,000万ドルだった。
お前の管理するサーバで同じことが起きたら、言い訳は通用しないぞ。

現代に通じるネットワーク防御の原則

SQL Slammerの被害を振り返ると、パッチ管理だけでなく、ネットワーク設計そのものにも多くの課題があったことが見えてきます。
ワームの拡散を許した構造的な問題と、そこから導かれる防御原則を整理してみましょう。

これらの原則はどれも「当たり前」に聞こえるかもしれません。
しかし、SQL Slammerの時代にこれらが「当たり前」だったかというと、そうではなかった。
そして正直なところ、2026年の今でもすべてを完璧に実践できている組織がどれだけあるかは疑問です。

特にネットワークセグメンテーションは、SQL Slammerの被害を振り返ると非常に効果的だったはずの対策です。
ワームはランダムなIPアドレスにパケットを送るだけなので、セグメントを分けてファイアウォールでUDP 1434番ポートを遮断していれば、少なくとも組織内での拡散は防げていました。

SQL Slammerが突きつけた問いは、結局のところ「基本を怠っていないか？」というシンプルなものです。
派手なゼロデイ攻撃や高度なAPTばかりが注目されがちですが、実際に大きな被害をもたらすのは「既知の脆弱性にパッチが当たっていない」「不要なポートが開いている」といった基本の抜け漏れ。
地味だけれど、ここを押さえるだけで防げるインシデントは今も山ほどあります。

チップス

結局は基本が大事ってことでしゅね…！
パッチ管理と資産管理、オイラももう一回ちゃんと見直すでしゅ！

ボス

おっ、珍しくいいことを言うな。
SQL Slammerは「たった376バイトのコード」と「たったひとつのパッチ未適用」で世界を止めた。
裏を返せば、たったひとつのパッチを当てていれば、何も起きなかったんだ。
基本を守る重みを、忘れるなよ。

まとめ

2003年のSQL Slammerは、376バイトという驚くべき小ささと、8.5秒で倍増する爆発的な感染速度で世界のインターネットを麻痺させました。
破壊的なペイロードを持たないにもかかわらず、ATM・航空・緊急通報・原発監視まで巻き込む大規模な障害を引き起こし、最初の5日間だけで最大12億ドルの経済損失をもたらしています。

そして、この被害の根本原因はたったひとつ。
6か月前に公開されていたパッチが当たっていなかったこと。
技術的に高度な攻撃ではなく、既知の脆弱性を放置した「基本の怠慢」が、世界規模の混乱を招いたのです。

パッチは速やかに当てる。
自環境で何が動いているかを把握する。
不要なポートは閉じる。
SQL Slammerから20年以上が経ちましたが、この3つの基本は今も変わらずセキュリティの土台です。
次の「376バイト」がやってくる前に、足元を固めておきましょう。

チップス

ボス、今日も勉強になったでしゅ！
まずはオイラが管理してるサーバで開いてるポートの棚卸しから始めるでしゅ！

ボス

ふふふ、いい心がけだ。
ポートの棚卸しが終わったら、次はパッチの適用状況だな。
地味な作業の積み重ねが、お前のネットワークを守る。
一歩ずつやっていけ。

セキュリティの専門知識を活かして活躍したい方は、セキュリティフリーランス案件もぜひチェックしてみてください。