〜安全なWindowsシステム環境の実現〜

2002年〜2003年のセキュリティ・トピック

　最初のセッションでは、国内のセキュリティ・コンサルタントとして活躍するラック コンピュータセキュリティ研究所の新井悠氏が、「不正アクセス手法の傾向」 と題し、2002年年初からこれまでに発生したさまざまなセキュリティ・トピックを振り返りながら、最近の不正アクセスの傾向に関して説明した。

ラック コンピュータセキュリティ研究所 ソフトウェア脆弱性研究員 新井 悠氏

　2002年以降に発生した主要なセキュリティ・トピックには以下のようなものがあった（表1）。

　このように2002年は、CodeRedやNimdaのように爆発的に広がるワームなどは発生しなかったものの、電子メールを媒介として感染するウイルス（Fbound、Klez、Bugbear）の被害が広がった。またOpenSSHやsendmail、tcpdump（パケット監視用ツール）／libpcap（パケット・キャプチャ・ライブラリ）といったオープン・ソフトウェアのソース・プログラムが改ざんされ、これをダウンロードしてビルドするとトロイの木馬が発生するという問題が起きた。そして年が明けた2003年には、CodeRed と同じように、バッファ・オーバーフローが正しく対策されていない状態で感染パケットを受信することで、爆発的に感染 を広げるSQL Slammerの事件が起こった。

　電子メールによって感染するKlezについては、いまだに感染メールが送信されている。このKlezは、MS01-020という2001年に明らかになったInternet Explorer（以下IE）5.01／5.5のセキュリティ・ホール＝「不適切な MIME ヘッダーが原因で Internet Explorer が電子メールの添付ファイルを実行する（MS01-020）」を利用して感染するものだ。セッションでは、このセキュリティ・ホールにより、Outlook Expressで感染メールをプレビューしただけで、ウイルスに感染するというデモンストレーションが行われた。

　このセキュリティ・ホールを解消するHotfixを適用すれば感染を防止できるが、新井氏によれば、ホーム・ユーザーはいまだに古いWindows 9xやOutlook Expressを使っており、こうしたユーザーが感染メールをいまなお発信し続けていると述べた。そしてKlezなどのウイルスからシステムを守るためには、IEのアップグレードやHotfixを適用し、最新の環境を維持することだとした。

　2002年の特徴的なセキュリティ問題としては、オープン・ソフトウェア（のソース・コード）に対する改ざんがあった。公開されていたソース・コードが改ざんされ、Webサイトからダウンロードできるようになっていたのである。オープン・ソースのソフトウェアだからといって、決して安心はできないということである。この例として、tcpdump／libpcapに対するトロイの木馬の埋め込みに関して詳しく解説があった。改ざんされたのはconfigureシェル・スクリプト（環境に応じてコンパイル環境を準備するためのスクリプト）で、これを実行すると、wgetやfetchなどのファイル転送プログラムを使って、トロイの木馬本体のソース・コードがダウン ロードされる。ダウンロードされたソース・コードをコンパイルすると、特定のIPアドレスのTCP 1963番ポートに接続し、接続先ホストから読み出した1byteのデータに応じて、シェルの制御を相手ホスト側に提供する（攻撃者がシステムを制御できるようにする）。

　このような感染手順を踏むため、ファイアウォールの設定で、外部から内部への制限だけでなく、内部から外部に対するアクセス制限（TCP 1963番への発信の制限）を行っていたサイトは、感染を防止できた。ファイアウォールというと、外部から内部へのパケットを制限することばかりに関心が向きがちだが、今後は内部から外部に向けた通信についても、不要なポートのアクセスなどは制限する必要がありそうだ。ただしこの場合でも、TCP 80番ポート（通常のWebアクセスで利用されているポート）などの、一般的なポートを使われたりすると、ファイアウォールを通過してしまう危険は残る。

　新井氏によれば、ソース・コードを改ざんしたtcpdump／libpcapのトロイの木馬混入などの攻撃に対しては、（1）root権限でビルトしない、（2）MD5チェックサムの比較などを行い、配布されているソースコードやバイナリの改ざんの有無を確認する、（3）PGP／GPGP署名を利用し、ソースコードの提供元を確認する、などの対策をとる必要があるという。またWindows関連のダウンロード・プログラムについては、Authenticode署名を活用して改ざんなどをチェックすることが可能だ。

　セッションの最後に、新井氏は、2003年1月末にインターネットを麻痺させたSQL Slammerの詳細について説明した。これは「SQL Server 2000解決サービスのバッファのオーバーランにより、コードが実行される（Q323875）（MS02-039）」のセキュリティ・ホールを利用して感染するワームである。SQL Slammerの詳細については、別稿Windows Insiderフォーラム記事「Insider's Eye：管理者のジレンマを突いて爆発的に繁殖したSQL Slammer」を参照されたい。

　ラックの調査によれば、SQL Slammerが発生したのは2002年1月25日 14時30分ごろで、30分後には感染活動の検出が25万件を超えたという。同じくラックの調査では、SQL Slammerの感染活動が開始される数時間前に、国内のとあるネットワークに対し、SQL Serverがデフォルトで使用するTCP 1433番ポートに大量のアクセスが発生していた。「裏付けはないが、セキュリティ・ホールが放置されている感染先を事前に探しておき、一挙に感染を広げたのではないか」と新井氏はみている。

運用こそ最後の要（人間が一番の脆弱性であり脅威）

　この第2セッション以降は、マイクロソフトでセキュリティ対策を担当しているセキュリティレスポンスチームより担当者が登壇し、Windowsセキュリティに関する実践的な解説を行った。セキュリティレスポンスチームは、Hotfix対応の現場で日夜格闘し、私たちが頼りにしているマイクロソフトのセキュリティ情報を発信している人々である。

マイクロソフト アジアリミテッド グローバルテクニカルサポートセンター セキュリティレスポンスチーム テクニカルリード 小野寺 匠氏

　第2セッションを担当したのはレスポンスチームのテクニカルリードである小野寺匠氏で、「Windows環境におけるセキュリティ強化のポイント」と題し、Windows 2000 Server、IIS（Internet Information Services） 5.0、SQL Server 2000を利用して、インターネット向けにサービスを提供するシステムを想定して、Windowsシステムを安全に運用するためのポイントについて解説を行った。

　Windows 2000 Serverは、すべてのサーバ・アプリケーションの基礎となるもので、これが安全でなければシステム全体を安全に運用することはできない。基本的には、Windows 2000 Serverベースライン・セキュリティ・チェックリストに従ってチェックすることになる。このチェック・リストをベースとし、前述したインターネット向けのサービスを提供するシステム向けに、より具体的な指摘がなされた。

　Windows 2000 Serverを安全に保つポイントとして、小野寺氏は以下の6つの項目を指摘した。

1. パスワード
2. 管理者アカウント
3. ファイルシステムの安全性
4. 匿名アクセスの拒否
5. 最小限のサービス
6. 不要なファイル共有の削除

　またWindowsシステムの管理者アカウントはデフォルトで「Administrator」となっているが、このままでは、攻撃者に対して、ユーザー認証を突破するための情報のうち半分を与えていることになる。従って管理者のユーザー名は、ほかのユーザーと区別がつかない、目立たない名前にすべきである。これが「2．管理者アカウント」である。

　「3．ファイルシステムの安全性」はセキュリティ機能の高いNTFSを必ず使うこと、IISのサービス用アカウント（IUSR_〜、IWAM_など）はWeb参照以外（プログラム実行など）は明示的に拒否すること、安易にEveryoneに権限を与えないこと。「4．匿名アクセスの拒否」は匿名ユーザー（Anonymous User）のアクセスを拒否すること。「5．最小限のサービス」は不要なサービスはすべて無効にすること。「6．不要なファイル共有の削除」は管理共有を無効にすること、作業が終わって不要となった共有フォルダはめんどうがらずに鋭意削除すること、をそれぞれ意味している。

　次にIISのセキュリティ・ポイントとして5つを挙げた。

1. IISのアクセス権（NTFSの機能を使ってIISのアクセス権を適切に管理する）
2. 不要な機能の停止（脆弱性のあるIISサンプルなどを削除する、WebDAV機能を停止するなど）
3. Lockdown／URLScanツール
4. Webアプリケーション
5. ログの記録

　最後のSQL Server 2000のセキュリティ・ポイントは以下の4つであるという。

1. saアカウントのパスワード（SQL Serverの管理者権限を正しく運用する）
2. システムSPの制限（SQL Serverの管理用ストアード・プロシージャの正しい管理）
3. サービス実行アカウント（Administratorなどの強力なアカントではなく、必要最小限の権限を持つ専用アカウントを作ってSQL Server用に使う）
4. SQLインジェクション（クエリ文字列にハッキング用の文字列を滑り込ませるSQLインジェクションからの防衛）

　このようにセッションでは、Windows 2000 Server、IIS 5、SQL Server 2000のそれぞれについて、非常に具体的なセキュリティ・ポイントの指摘があった。しかしセッションの最後に小野寺氏は、「（設定だけでなく）運用が最後の要。どんなセキュリティ設定を行っても、運用が適切でなければシステムは脆弱になってしまう。人間こそが一番の脆弱性であり脅威だ」と締めくくった。確かに、Klezにせよ、Code Red／Nimdaにせよ、SQL Slammerにせよ、Hotfixの適用を正しく行っていれば、いずれも感染を防止できたものばかりだ。初期設定ばかりに目を奪われるのではなく、日々の運用における地道な活動にも同じくらい目を向けるべきだろう。

Hotfix管理を支援するマイクロソフトの無償ツール群

　続く第3セッションでは、同じくマイクロソフト セキュリティセスポンスチームの山崎雅樹氏により、「セキュリティパッチを効果的に管理するベストプラクティス」と題した、HFNetChkやSoftware Update Services（SUS）、Microsoft Baseline Security Analyzer（MBSA）といったツール類を活用して、Hotfix管理をどのように実施するのかが効率的かというデモンストレーションを交えた説明がされた。周知のとおりこれらのツールは、煩雑なHotfix管理を支援するために、マイクロソフトが無償提供しているツールである。

マイクロソフト アジアリミテッド グローバルテクニカルサポートセンター セキュリティレスポンスチーム　山崎 雅樹氏

　Hotfix管理の日常業務は、以下のプロセスを経ることになるという。

　1. 適用状況の分析
　2. セキュリティ情報の確認
　3. 脆弱性の対応計画
　4. 修正プログラムの配布、状況確認

　このうち「1．適用状況の分析」で利用できるのが、HFNetChkとMBSAである。HFNetChkは、2001年秋から提供されているコマンドライン・ツールで、これを実行することで、管理対象となるコンピュータに現在どのHotfixが適用済みか、未適用かを確認できる。これはShavlik社が開発したツールで、これまではマイクロソフトが提供していたが、最新版はShavlikのサイトからのみ入手可能で、今後マイクロソフトからの提供は終了される。HFNetChkは、オンラインで提供されるHotfixの情報ファイル（XMLファイル）を頼りに、状況調査を行う（参照：日本語版XML DBファイルのダウンロードはマイクロソフトWebサイトから行える）。このHFNetChkを使い、複数のコンピュータに対して、Hotfixの適用漏れの有無を検査するスクリプトも提供されている（ただし、日本語環境でこのスクリプトを使うにはスクリプトの修正が必要）。

　HFNetChkはコマンドライン・ツールだが、グラフィカル・ユーザー・インターフェイスを持ったWindowsアプリケーションとして開発されたツールがMBSAである。MBSAでは、HFNetChkと同等のHotfix検査機能に加え、パスワードやサービスの起動状況などに関する各種セキュリティ設定を収集、確認できる。また後述するSUSと連携させてHotfix管理に使える。ただし現時点のMBSA 1.1は正式な日本語対応版ではなく、日本語版の情報データベースは提供されないため、Hotfix対応状況の正確な把握はできないという欠点がある（そのほかのセキュリティ設定情報の収集などには使える）。

　MBSAの日本語対応版は現在開発中とのことだが、提供時期については明らかにされていない。またHFNetChkに対するMBSAの欠点は、Hotfixの調査対象がOSやIE、IISに限定されることである。HFNetChkでは、これらに加えSQL ServerやExchange Server、Office、Media Playerに関連するHotfixの適用状況も調査できる。

　「2．セキュリティ情報の確認」では、マイクロソフトが提供するセキュリティ情報（セキュリティ情報のWebページ）やセキュリティ警告メール・サービス（サービスの申し込みページ）を利用する。新しいHotfixが提供されたり、以前のHotfixが更新されたりしたときには、これらのチャネルを使って情報が提供される。特にメールを使った警告サービスでは、Windowsセキュリティに関する新情報がタイムリーに入手できるので、ぜひとも登録しておきたい。セキュリティ情報については、速度を最優先にする概要の速報、詳細な情報を含むセキュリティ情報、よく寄せられる質問（FAQ）、サポート技術情報（Knowledge Base）という順に情報が発信される。このうちFAQでは、「セキュリティ情報に関するかなり詳細な情報がQ&A形式で説明されており、非常に有用なのだが、あまり利用されていないようなので、積極的に活用してほしい」と山崎氏は訴えた。

　「3．脆弱性の対応計画」では、Hotfixを実際に適用するか／しないか、どのように適用するのかといったことを検討する。ここで強調されたのは、何でも闇雲にHotfixを適用するのではなく、適用による副作用なども考慮に入れ、適用にかかるコストと、Hotfixを適用しないことで被るリスクをバランスすることが重要だということだ。場合によっては、設定や運用で問題回避するなども検討する必要がある。しかしこれらを的確に判断するには、自分が管理する情報システムを十分に把握していなければならない。また最終的な適用を決定する場合でも、事前に適用テストを実施しておく。

　「4．修正プログラムの配布、状況確認」では、実際にHotfixを管理対象となるコンピュータに適用する。個人ユーザーは、Windows Updateを使って自身でHotfixを適用できるが、この場合は各ユーザーがコンピュータの管理者権限を持っている必要があり、企業ユーザー向けとはいえない。この問題を解決し、企業におけるHotfix管理を自動化しようとするのがSUSである。SUSでは、Windows Updateの仕組みをベースとして、Hotfixを配布するサーバを社内LANの内部に配置し、ここからHotfixを適用できるようにする。Active Directoryのグループ・ポリシーを使って適用方法を設定する。ただしSUSは、Windows Updateをベースとしているため、MBSA同様、Exchange ServerやSQL Serverなどのサーバ製品用のHotfixは対象外である。セッションでは、実際の適用テストがデモンストレーションで披露された。

　HFNetChkやMBSA、SUSなど、Hotfix管理のためのさまざまなツールが提供されるようになった。しかしHotfix管理は、「問題など起こらないのが当たり前」という中での地道な作業になる。山崎氏は「セキュリティ対策は継続が重要」と締めくくった。

ログは“宝”、日常的な分析を怠らないこと

　セッションの最後は、セキュリティレスポンスチームの責任者である奥天陽司氏により「製品に用意された機能だけで行う不正アクセスの検出」というテーマで解説が行われた。

マイクロソフト アジアリミテッド グローバルテクニカルサポートセンター セキュリティレスポンスチーム マネージャー 奥天 陽司氏

　不正アクセスに適切に対応するには、不正アクセスがどのようなものかを知り、日ごろからアクセス・ログなどに目を光らす必要がある。外部からの攻撃では、ポート・スキャンなどによる攻撃対象の選定など、事前調査を含めてほとんどの場合で繰り返しサイトへのアクセスが発生する。ログから日ごろの状態を把握していれば、こうした事前調査のアクセスなどをキャッチして、実際の攻撃が開始される前に対応を施すことが可能だ。「事前調査もなく、1度で成功した攻撃は、内部犯行かソーシャル・エンジニアリングのいずれかの可能性が高い」（奥天氏）という。

　ログの収集では、Windows 2000標準のものを始め、大きく3種類を利用できる。これらはイベント・ログ、パフォーマンス・モニタ、アプリケーションのログ（IISのアクセス・ログ、SQL Serverのプロファイラなど）である。

　イベント・ログは、Windows付属のイベント・ビューアで確認することができる。不正アクセスを検知するには、イベント・ビューアのプロパティ設定を行い、必要な監査項目を有効化し（フォルダの監査やレジストリの監査）、加えて不正アクセスが発生した場合の処理について設定する。例えば、セキュリティ・オプションでの設定により、イベントの記録が不可能になった時点でコンピュータを停止するなどの設定が可能である。

　同じく標準ツールのパフォーマンス・モニタを使えば、さまざまなソースの情報を一元的にモニタできる。情報ソースとしては、Windows OSやIP関連情報、Active Directory、Web関連、SQL Server 2000などがある。システム構成に応じてパフォーマンス・モニタ用のオブジェクトが用意されており、パフォーマンス・モニタはこれらのオブジェクトを使って情報収集を行う。データ・サンプリングのタイミングはカスタマイズ可能であり、情報を時系列に沿って収集できるので、傾向を調べるのに適している。なお必要であれば、あるしきい値を超えた場合に外部アプリケーションを呼び出すこともできる。ただしパフォーマンス・モニタでは、詳細な情報は取得できないので、本格的な調査というより、一時的な調査、またはシステムの監視に向いている。

　最後のアプリケーションのログは、各アプリケーションが記録するもので、フォーマットや内容はアプリケーションごとにまちまちだが、一般的にはリクエストの追跡と重要情報の記録を行うことができる。具体的にはIIS 5.0にはアクセス・ログ（W3C形式）やURLScan（前出）によって破棄されたリクエストのログなどを記録できる。またSQL Serverのプロファイラは、ログオン試行やユーザー・アカウントの操作（権限の奪取など）、データへの不正アクセスなどを記録できる。

　「ログは宝だと思って、しっかり保護すること。また記録するだけではなく、日常的なログの調査を怠らないことだ」と奥天氏は述べる。セッションでは、実際のイベント・ログ、IIS 5.0のアクセス・ログなどを使った調査の例が紹介された。

　「重要なのは、攻撃を受けるということではなく、攻撃を受けていることを認識すること。将来的なトラブルに備え、証拠を確保することは危機管理の基本である。マイクロソフトが標準で提供する機能は最低限のものだが、可能な範囲での活用を検討していただきたい」と奥天氏は強調してセッションを終えた。

◇

　第2部のパネル･ディスカッションに続く。

「第2部 パネルディスカッション」へ

実践Windowsセキュリティセミナー協賛、協力企業 協賛： マイクロソフト株式会社 協力： アップデートテクノロジー株式会社 株式会社シマンテック 　 株式会社ネットジャパン 株式会社ラック NEC （※50音順）