エンタープライズ:ニュース 2003/01/31 23:11:00 更新


Slammerが残した真の問題点と教訓

ちょうど1週間前に発生し、世界中のネットワークに大きな影響を与えた「Slammer」。そのSlammerへ対策を取るに当たって浮上してきた4つの問題点がある。

 ワーム「Slammer」が登場してから約1週間。まずはudp/1434ポートを塞ぐという一次対策が功を奏してか、当初のような爆発的なトラフィックはほとんど見られなくなった。

 Slammerによるネットワークへの影響はテレビ・新聞などでも報道された。一部では「CodeRed以来」という声もあがるほど、そのインパクトは大きいものだった。しかし、原因は単純だ。Microsoft SQL Serverの既知のセキュリティホールに対するパッチを適用せず、しかも不要なポート――データベースサーバをそのままインターネットにさらすなど言語道断のはずだが――を閉じることなく運用していたサーバがあったからだ。言うなれば人災である。

 セキュリティは鎖のようなものだとしばしば言われる。どんなにセキュリティ対策を施しても、1箇所でも弱い部分があれば、全体の強度はその弱い部分と変わらない。Slammerの場合も同じことが言える。100台のSQL Serverのうち、大半はきちんと対策がなされていたにもかかわらず、パッチを適用していないサーバが1台でもあったからこそ、これほどの被害が生じたわけだ(SlammerがUDPを吐き出す勢いが非常にすさまじかったというのも理由の1つだが)。

 したがってSlammerが残した教訓は、「常にセキュリティ意識を持ち、情報を収集しよう」「パッチは速やかに適用しよう」「不要なサービスは停止し、使わないポートは塞ごう」の3原則である――こう単純に結論付けてしまいたかった。しかし、情報を集めていくうちに考えは変わった。Slammerは、もっと深い問題を内包しているのだ。

問題1:パッチを適用できない

 セキュリティ対策の基本の1つとして、パッチの適用が挙げられる。新しいセキュリティホールが発見された場合には、なるべく速やかにパッチを適用し、脆弱性を修正すべきだということだ。

 しかしながらSlammerが悪用した「SQL Server 2000」と「Microsoft SQL Desktop Edition」(MSDE)の場合、話は単純ではない。セキュリティホールを修正してくれるはずの「SQL Server 2000 Service Pack 3」(SP3)や「MS02-039」、あるいは「MS02-061」のパッチをそのまま適用できないケースがある。

 例えば、「.NET Framework SDK 1.0」のサンプルに含まれるMSDE 2000には、素のSP3は適用できない。マイクロソフトより.NET Framework SDK専用のSP3として、「修正プログラム 813850」を公開している。同様に、専用のMSDEを用いている「Application Center 2000」でもSP3が適用できないため、専用プログラムが提供されている。

 また、あくまで動作検証用の評価版という位置付けだからかもしれないが、「SQL Server 2000 Enterprise Edition 120日間限定評価版」にもSP3は適用できない。

問題2:パッチ適用作業が複雑だ

 Windows OSそのものやInternet Explorerについては、Windows Updateを活用し、半自動的にパッチをダウンロードし、適用できるようになっている。しかしSQL Server 2000やMSDE 2000の場合、SP3はともかく、他の修正プログラムを適用するには、ファイルの入れ替えをはじめとする作業を手順に沿って行う必要がある。

 このため、作業中にミスが発生したり、自分では「修正プログラムを適用した」と思っていても実際には適用されていない、といった事態が起きる可能性がある。また、SP3のようにインストーラ形式になっていても、機器構成によっては、インストール作業が正常に進まないケースもあるという。

問題3:パッチの適用によって、かえって問題が発生する

 これまでも、SQL Serverをはじめとするサーバ製品に関して、最新パッチの適用によって稼動中のシステムが不安定になったり、エラーが発生したりするケースが報告されていた。個人的に活用しているならばともかく、業務システムともなれば、システムの安定運用は至上命題。パッチ適用作業にともなう一時停止でさえ、避けたいケースもあるだろう。

 余裕があれば、テスト用に同一構成の機器をもう1セット用意すればいい。しかしそれがかなわない場合、セキュリティ問題の修正とシステムの安定稼働を天秤にかけることになる。管理者にとっては非常につらい選択だ。どうしてもパッチを適用できない場合は、ファイアウォールの設定およびSQL Serverそのものの権限設定を変更し、防御を固めるしかない。

 なお、上記の修正プログラム「MS02-061」では現実に、これを適用した結果、ハンドルリークが生じるという問題(Q317748)が報告されている。1月26日以前にMS02-061を適用していた場合には、別途、問題修正のためのプログラムを適用する必要がある。これを踏まえて1月26日にバージョンアップされた新MS02-061は、Q317748や専用インストーラを含んだパッケージになっている。

 以上、3つの問題を踏まえると、「パッチを速やかに適用する」という従来の原則が、必ずしも問題解決に直結するわけではなく、かえって問題をややこしいものにしていると言えるだろう。それだけに、正確かつ分かりやすい情報がいっそう求められる。

 また、パッチ適用によってシステム運用が妨げられるのがいやだとしても、現実的に、セキュリティホールを塞ぐ手段はほかにない。パッチを適用しない道を選ぶのならば、そのサービスを利用するのをあきらめるか、あるいはファイアウォールなど他のセキュリティ対策を強化するしかない。

問題4:ユーザーが気づかないうちにMSDEをインストールしている可能性がある

 Slammerが登場した当初の速報記事では、「影響を受けるのはSQL Server 2000およびMSDE 2000」だと表現した。しかしそれでは、不十分な表現だったことをお詫びしたい。

 というのも、MSDE 2000は、広範なアプリケーションに含まれているからだ。

 まず、マイクロソフトが提供する製品だけでも、「Visio Enterprise Network Tools」や「Project Server 2002」「Application Center 2000」、組み込み機器向けの「Microsoft Windows XP Embedded」では、デフォルトでMSDE 2000がインストールされる。

 また、「Office XP」や「Access 2002」はもちろん、「Visual Studio .NET」や「Visual C++ .NET」では、自動的にインストールされることはないが、パッケージにMSDE 2000が同梱されている。詳細は、マイクロソフトが公開した「SQL Server および MSDE を標的とした SQL Slammer ワームに関する情報」に掲載されている。

 問題はそれだけではない。別記事のとおり、MSDE 2000は多数のサードパーティ製商用アプリケーションにも含まれているからだ。現在、セキュリティソフトウェア企業のF-SecureSQLSecurity.comなどが、MSDE 2000が含まれる製品リストを公開している。日本語での情報となるといっそう少なくなるが、例えばSQL Serverユーザーグループ(PASSJ)のWebページでは、商用パッケージへの同梱状況およびISVからの情報提供を呼びかけるとともに、随時、Slammer関連情報をアップデートしており、参考になる。

 セキュリティ管理ツールやシステム管理ツール、バックアップソフトウェア、会計ソフトにいたるまで、MSDE 2000を含むアプリケーションの種類は多岐に渡っており、その数は正確に把握できていないのが現実だ。マイクロソフト日本法人に確認したところ、広報担当者は「MSDEはOEM供給とは異なり、個別にライセンスを結んで提供するものではないため、マイクロソフトとしても、どの企業のどの製品に組み込まれているかは把握できていない」と述べている。

 この問題に対するベンダー側の対応もばらばらだ。例えば、日本ヒューレット・パッカードは、サポート用Webページで「緊急のお知らせ」を公開した。日本ネットワークアソシエイツでは、「1月29日の段階で、顧客およびパートナーに向け、危険性についてアナウンスを行った」という。これ以外に、顧客サポートの一環として、個別に情報を提供しているケースもあるという。

 しかし一方で、「ええ? うちの製品にMSDE 2000が含まれているんですか?」という具合に、取材によって初めてこの事実を知ったベンダーもあった(ただし、これは広報部門の対応であり、その後、技術部隊ではサポートをきちんと提供していることが判明)。逆に言えばこれは、MSDE 2000が含まれる製品についての情報は、Slammerそのものに関する情報ほど広く知られていない――むしろこの問題のほうが深刻であるにもかかわらず――ということの表れだろう。

 MSDEをインストールしているのだなどとは意識せずに、さまざまなアプリケーションをインストールしているエンドユーザーもいるはずだ。もし、それがノートパソコンならば、CodeRedやNimdaのときと同様に、自宅で感染したSlammerを社内ネットワークに――ファイアウォールの内部に持ち込む可能性がある。

 さらに、問題を深刻なものにするケースがある。独自開発のソフトウェア/システムにSQL Server 2000やMSDE 2000が組み込まれている場合だ。

 PASSJ事務局に確認したところ、外部に発注して開発したシステムや、Windows Embeddedを利用した特定業務専用機といった“専用システム”として購入するシステムに、SQL Server 2000やMSDE 2000が入っているケースが考えられるという。同事務局はメールで、「開発後の保守契約が十分に結ばれており、日ごろから、脆弱性情報も含む保守がなされていれば問題ありません。しかし、SI業者や開発者のセキュリティ知識、認識の不足も多く見かけられます」と述べている。

 システムの巨大化・複雑化にともない、どの部分に何が使われており、誰が開発したのかを把握するのはますます困難になりつつある。商用パッケージならばともかく、独自システムでセキュリティ問題が発生した場合、責任は誰が取るのか。対策やパッチ動作の検証作業は誰が行い、費用はどこが負担するのか。情報はどのように、誰に向けて公開されるべきなのか――まだ、明快な解は見えていない。これについてPASSJ事務局は、「発注側、納品側、開発側の脆弱性対策について、保守契約のガイドラインが早期に必要」とする考え方を示している。

 なお、セキュリティホールが残ったままのSQL Server 2000やMSDE 2000が存在するかどうかを確認するツールが、マイクロソフト(SQL Server 2000 SQL Scan ツール、MSDE検知機能は、近日中にリリース予定の次バージョンで対応)のほか、米ファウンドストーン(SQLScan v1.00)より提供されている。

関連記事
▼ワーム侵入ルートはいくつあったのか

関連リンク
▼マイクロソフト(SQL Server および MSDE を標的とした SQL Slammer ワームに関する情報)
▼SQL Serverユーザーグループ

[高橋睦美,ITmedia]