1月25日から26日にかけて，世界規模でネットワーク障害が発生した。ネットワークやセキュリティ関係者によるメーリング・リストやセキュリティ・ベンダーなどが公開している情報を総合すると，2002年7月に見つかったSQL Server 2000（米Microsoft製データベース管理システム）のセキュリティ・ホールを悪用するワーム（ウイルス）[注]が原因である可能性が高い（関連記事）。

　正直なところ筆者は，現時点ではまだ，SQL Server 2000のセキュリティ・ホールを悪用するワームが，障害を引き起こした唯一，あるいは最大の原因であったと断言することはできない。しかし，少なくとも問題の時間帯に，各地で，SQL Serverが利用するポートへの異常な量のアクセス（攻撃）があったことと，上記のワーム（SQL Slammer，Sapphire，SQLExp，SQLP1434などと呼ばれる）が広がっていたことは確かである。

　2001年に出現した「Code Red」や「Nimda」により，Internet Information Server/Services（IIS）のセキュリティは注目された。しかし，「まさかSQL Serverのセキュリティ・ホールが狙われるなんて・・・」と思われる読者も多いのではないだろうか。IISに注意を払うようになったユーザー（管理者）でも，SQL Serverについてはそれほど注意していなかった可能性がある。

　SQL Serverを利用されていない方も，今回の事件を決して“他人事”とは考えないでいただきたい。公開用のサーバーでなくても，インターネットからアクセス可能なマシンはいつでも攻撃される可能性がある。そしてワームが仕込まれると，被害は自分のマシンにとどまらない。インターネット全体を危機に陥れることになる。

　2002年11月に発生した，ルートDNSサーバーへの攻撃を思い出していただきたい（関連記事）。インターネットに存在するぜい弱なマシンが原因でネットワークの正常な通信が妨げられた事件は既に存在する。そして，被害がさらに大きかった今回の事件も，同じように多数のぜい弱なマシンが攻撃に利用された可能性が高いのである。

　自分のためだけではない。インターネット・ユーザー全員のために，セキュリティ・ホールをふさいでおかなければならないのである。今回はたまたまSQL Server 2000がターゲットとなったが，これは，すべてのソフトウエアについて言えることだ。今回のワーム被害を教訓に，個々のマシンのセキュリティ・レベルを上げるよう努める必要がある。

教訓にならなかった過去のワーム

　SQL Serverを狙うワームとしては，デフォルトではパスワードが設定されていない「sa」アカウントを使って感染を広げるワームがあった。このようなワームは，2001年11月および2002年5月に“流行”した（関連記事1，関連記事2）。ただし，このワームはsaアカウントにパスワードを設定すれば防げた。SQL Serverのセキュリティ・パッチを適用する必要はなかった。

　しかし今回被害をもたらしたワームは，SQL Serverのバッファ・オーバーフローのセキュリティ・ホールを悪用する。saアカウントにパスワードを設定したSQL Serverマシンでも，パッチを適用していないマシンは被害を受ける。

　saアカウントを悪用するワームが出現した際に，単にパスワードを設定するだけではなく，「SQL Serverも攻撃対象になるのだから，きちんとパッチを適用しよう」あるいは「SQL Serverが使用するポートをファイアウオールできちんと遮断しよう」――と，すべてのユーザーが考えて対策を施していれば，今回のような事態を招くことはなかっただろう。

　また，今回のワームは，IISを狙った「Code Red」によく似ている。既にパッチが公開されているセキュリティ・ホールを悪用して感染する。加えて，メモリー上でのみ動作して感染したマシンにファイルを作成しないので，ウイルス対策ソフトでは検出できない。

　「Code Red」およびそれに続いた「Nimda」により，IISサーバーにパッチを適用することの重要性は周知されたが，その際に「Webサーバーばかりではなく，他のサーバー（サービス）も攻撃対象になりうる。SQL Serverについてもきちんとパッチを適用しておこう」――と，すべてのユーザーが考えていれば，これほどまでに被害が大きくなることはなかったかもしれない。

　結局，過去のワームは教訓にはならなかった。

“予言”されていた深刻な事態

　SQL Serverのセキュリティ・ホールを狙うワームがまん延したことを意外に思われる読者がいるかもしれないが，今回の事態は予想されていた。2002年7月，SQL Serverの深刻なセキュリティ・ホールがマイクロソフトから相次いで公開され，米CERT/CCは警告を発していた。もちろん今回のワームが悪用した「（MS02-039）Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Executionの脆弱性」のセキュリティ・ホールも含まれている。

　IT Proでも，CERT/CCの警告をニュースとして取り上げるとともに，週刊コラム「今週のSecurity Check」において，「管理者は必見！SQL Serverのセキュリティを解説する」という記事で詳細に解説した。

今度こそ“教訓”に

　一部のメーリング・リストなどの情報によると，1月25日夜の段階で，今回のワーム騒動は収束に向かっているようである。UDPポート1434番への攻撃（アクセス）が減少しているという。しかし，だからといって安心はできない。起きてしまったことは仕方がないので，今回の騒動を教訓にして，再発を防止しなくてはならない。

　まず，SQL Server のユーザーは当然対策を施す必要がある。今回のワームが証明したように，今後はIISと同様にターゲットになると考える必要がある。そのため，今回のワームが狙った「（MS02-039）Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Executionの脆弱性」のセキュリティ・ホールをふさぐだけでは不十分である。SQL Server用の最新の累積パッチである「（MS02-061）SQL Server Web タスクで権限が昇格する」あるいはMS02-061のパッチを含む「SQL Server 2000 Service Pack 3 日本語版」を適用して，見つかっているセキュリティ・ホールをすべてふさがなくてはならない。

　今回のワームの影響を受けるSQL Server 2000／SQL Server Desktop Engine（MSDE）2000だけではなく，SQL Server の他のバージョンについてもセキュリティ・ホールをふさいでおく必要がある。また，ユーザー自身が意識していなくても，別の製品がSQL Server／MSDEを使用している場合がある。この場合も当然セキュリティ・ホールの影響を受けるので，パッチの適用は不可欠である。SQL Server／MSDEを使用する可能性のある製品については，マイクロソフトのページに詳しい。

　さて，問題はここからである。SQL Serverにパッチを適用しただけでは，今回のワームを教訓にできたとはいえない。「今後，SQL Server以外も攻撃を受ける恐れが十分にある」と考えて，他のソフトウエア――特にサーバー・ソフト――のセキュリティ対策を実施してこそ意味がある。パッチを適用できない，あるいは最新版が分からないといったサーバー・ソフト（サービス）は停止すべきだ。IT Pro読者ならば聞き飽きたセリフだろうが，本当に必要なサービスだけを稼働させるべきである。本当に必要なサービスだけならば，十分管理できるだろう。

　ファイアウオールなどによるアクセス・コントロールも同様である。本当に必要なポートだけを開けるようにする。今回狙われたのがUDP 1434番だからといって，そのポートを閉じるだけでは意味がない。他のポートを狙われたらおしまいである。これまた聞き飽きたセリフだろうが，まずはすべてのポートを閉じて，必要なポートだけを開けるようにする。

　注意してほしいのは，ポートを閉じればパッチを適用しなくてもいいことにはならないことである。内部のユーザーに意図的に攻撃されることもあるだろうが，それ以上に，無意識にワームを持ち込まれる恐れがあるからだ。「Nimda」ワームの被害で明らかになったように，ワームはどこから侵入するか分からない。ネットワークの“入り口”で守ることは重要だが，個々のマシンのセキュリティも高めておかなければならない。

　加えて，egress（出方向）フィルタリングも施しておく必要がある。前述のように，いくら守りを固めても，RAS経由やモバイル・マシン経由でワームが組織のネットワークに入り込む可能性がある。自組織が“加害者”にならないために，外向きのトラフィックについても制限を施す（ポートを閉じる）必要がある。

　今回のワーム被害で明らかになったように，“加害者”サイトはネットワークの正常な通信を妨げる恐れすらあるのだ。インターネットを利用したければ，“加害者”にならないことを第一に考えて，万全の対策を施す必要がある。

疑問が残る今回の騒動

　最後に，筆者が今回の事件に関して疑問に感じていることを述べさせていただく。UDP 1434番への大量の攻撃（アクセス）があったのは事実なのだから，SQL Serverを狙うワームが一因であったことは確かである。しかし筆者には，なぜこれほどまでに大きな被害が生じたのか疑問である。

　「Code Red」や「Nimda」のように，外部に対して公開しているWebサーバーを狙うワームの被害が拡大したことは理解できる。だが，今回のワームが侵入するのは，UDP 1434番ポートを介してである。UDP 1434番ポートを開けたままにしている組織は，それほどまでに多いのだろうか。それとも，感染したマシンはそれほど多くないものの，高トラフィックを発生させるワームだったために，各種メディアで報じられたような被害を招いたのだろうか。あるいは，これら以外の要因があったのだろうか。

　“よりよい教訓”にするために，今後詳細を調べようと考えている。

[注] 「ワーム」とは，自己増殖して，ネットワークで接続されたマシンへ自動的に感染を広げる単独のプログラムのこと。感染を広げる際には，マシン上で動作するソフトウエアのセキュリティ・ホールを悪用する場合が多い。1988年11月に“流行”して当時のインターネットをダウンさせた「Morris Worm」，2001年7月に大きな被害をもたらした「Code Red」などが代表的である。これに対してウイルス（コンピュータ・ウイルス）は，「他のファイルやプログラムに感染する」，「ウイルスが動き始めるには『ウイルス・ファイルを実行する』といったユーザーの操作を必要する」――などの特徴を持ち，ワームとは区別される。しかし近年では，他のファイルに感染せずに単独で動作するウイルスや，Internet Explorerのセキュリティ・ホールを悪用して自動的に動作するウイルスが出現しているために，両者の境界があいまいになっている。加えて，ウイルスとワーム両方の特徴を持つ「Nimda」のようなウイルス（ワーム）が出現している。そのため，ワームを含めた，ユーザーに被害をおよぼすプログラム全体をウイルスと呼ぶ場合が少なくない。また，厳密にはウイルスに分類されるものの，ワームの性質を持つウイルス（例えば，自分自身のコピーをメールなどを介して他のマシンに送信して感染を広げるようなウイルス）を「ワーム型ウイルス」と呼ぶ場合もある。

（勝村　幸博＝IT Pro）