セキュリティに関するご質問 ‐ 2000 年 12 月

  • [アーティクル]

Joel Scambray

今月は、読者の皆さんが年末年始のお休みに入る前に、Windows のセキュリティ技術に関する質問にお答えしたいと思います。

トピック

常に最新のパッチを! 常に最新のパッチを!

Windows 2000 のセキュリティに関する推奨書籍 Windows 2000 のセキュリティに関する推奨書籍

常に最新のパッチを!

Q&A に入る前に、Microsoft セキュリティ情報サイトを定期的にチェックし、最新のパッチをもれなく適用することの重要性を再度強調しておきたいと思います。情報の一覧を日付順に表示すると、セキュリティ パッチの更新担当者にとって 10 月と 11 月が特に多忙な月であったことがわかるはずです。これらのパッチはいずれも重要なものですが、IIS 4 および 5 のユーザーに向けた記事 MS00-078 に関しては注意が必要です。この記事には、できるだけ優先して解決すべき問題が記述されています。実際には、以前にリリースされたパッチがこの問題のフィックスとなります。そのパッチが既に適用されていればよいのですが、読者の皆さんは適用済みでしょうか?

たまたま筆者がこのパッチに関する Knowledge Base 文書を読んでいると、Exchange 2000 ユーザーの場合は、問題が生じることが確認されているので、このパッチを適用すべきではないという記述があることに気付きました。また、NT4 SP6a システム上で稼動している Microsoft Site Server LDAP ディレクトリ サービスがこのパッチの適用後に機能しなくなるという報告も受けています。筆者に知らされた非公式な Site Server フィックスは、以下のとおりでした。

  1. MS00-057 に記載されているホットフィックスを適用します。
  2. リブートします。
  3. コマンド プロンプトからホットフィックスをアンインストールします (KB Q184305 参照)。
  4. SP 6a を再インストールします。
  5. ホットフィックスを再インストールします。

不明な点については、いつもどおり Microsoft Product Support Services に問い合わせてください。

最新パッチをもれなく適用するには面倒なチェックが必要になりますが、IIS 5 Hotfix Checking Tool (HFCheck) を使うとそのような手間が省けます。HFCheck では、ローカルまたはリモートの IIS 5 サーバー上にインストールされたパッチを利用可能なフィックスのデータベースと比較します。利用可能なパッチのうち、まだインストールされていないパッチが検出されると、警告が画面に表示されるか、またはイベント ログに書き込まれます。こうして、IIS 5 の問題を簡単にフィックスできます。Windows 2000 と IIS 5 へのアップグレードにより、こんなに便利な機能が利用できるようになるのです。

では、質問への回答に進みましょう。

 

Windows 2000 のセキュリティに関する推奨書籍

Q: Windows 2000 プラットフォームのセキュリティに関するお勧めの書籍やリソースはありますか?

A: 先月は、ずうずうしく自著の宣伝をしてしまいましたが (Windows 2000 および Internet Explorer/Outlook に関する最新情報を盛り込んだ『Hacking Exposed 2nd Edition』を上梓しました)、今月は、筆者が最近読んだ書籍のうち、お勧めの書籍をいくつか紹介することにしましょう。

筆者がついさっき読み終えたばかりの『Designing Secure Web-Based Applications for Microsoft Windows 2000』は、現場で経験を積んだ Michael Howard が Marc Levy および Richard Waymire との共著で上梓した書籍です。IIS 5 上に Web アプリケーションを展開する際には、これが欠かせない一冊となるでしょう。エンド ツー エンドから、認証、SQL 統合に至るまで、IIS 5 セキュリティに関する情報が網羅されています。著者が認証環境内の IIS 5 を外部の攻撃から保護する作業に携わりながら培った経験が活かされており、わかりやすい文体で書かれています。

開発者向けとしては、これも最近読んだばかりの書籍ですが、Keith Brown 著の『Programming Windows Security』がお勧めです。Windows NT/2000 の組み込みセキュリティ機能を使用して、セキュリティで保護されたアプリケーションをコーディングする方法を地に足の着いた現実的な観点から解説しており、有用な情報が満載されていると同時に、読み物としても楽しめます。COM+ セキュリティについても、啓発に富んだ記述があります。

INC から ASP への名前変更

書籍の話題から離れる前に、上記の書籍で取り上げられていない情報について触れておきます。これは、ごく最近、上記の書籍の著者である Michael Howard から教示された情報です。実際、筆者は、過去数週間のうちに、これに関連する問題に何度か遭遇しているので、このコラムの読者の皆さんにもぜひお知らせしておくべきだと考えました。

多くの IIS 開発者は、外部のインクルード ファイル (拡張子 .inc) に保存された構成データを使用するように Active Server Pages (ASP) をコーディングしています。既定では、クライアント側のブラウザ上に ASP スクリプトがレンダリングされることはありませんが、.inc ファイルを名前で要求した場合は、普通のテキスト ファイルとして .inc ファイルの内容がブラウザ上に表示されることになります。これらのインクルード ファイルにプライベート データが格納されていると (本来は避けるべきことですが、一部で習慣化しているのも事実です)、その内容がリモート ユーザーの目にさらされることになります。この問題は、.inc ファイルの拡張子を .asp に変更するだけで簡単に回避できます。拡張子を .asp にしておけば、これらのファイルが Active Server Pages として扱われるので、クライアント側にそのまま表示されることがなくなります。もちろん、ASP スクリプト内で変更前の .inc ファイルの名前を参照している個所については修正が必要です。また、<% %> タグや RUNAT=Server 構文を ASP スクリプト内で注意深く使用すれば、サーバー上でのみ実行するコードを指定できるので、ビジネス ロジックが外部に漏洩するのを防止するのに役立ちます。従来から .htr ファイルに対する要求を悪用して ASP ソースを読み出す攻撃方法がありましたが、これらのタグがその種の攻撃に対する防止策として実際に使用されてきました。

Terminal Server のセキュリティ

Q: Windows 2000 のターミナル サービスを経由したリモート管理に認証がどのように関係しているかがよくわかりません。管理者は Windows 2000 ドメインへの認証を受けないと、サーバーにリモート アクセスできないのでしょうか?

A: 簡単に言うと、答えは NO です。サーバー コンピュータ自体への認証を受けることが可能なので、認証先となるドメインを展開する必要はありません。Foundstone 社の有能なスタッフの 1 人が最近多数のコンピュータに Terminal Server を展開しましたが、そのスタッフからアドバイスされたことを示しておきましょう。

まず最初に、TS のライセンス要件について明確にしておきたいと思います。Windows 2000 では、リモート管理モードかアプリケーション サーバー モードのいずれかで TS を展開できます。リモート管理モードで展開した場合 (この質問の場合は、このモードが該当するはずです)、TS が許可する同時セッション数は 2 つだけなので、複数の管理者が同時に接続してサーバーを管理することがないように計画する必要があります。より多くのユーザーに TS システム上のアプリケーションを共有させたい場合は、アプリケーション サーバー モードを使用してください。ただし、このモードは、ライセンス要件が複雑で、インストール先のサーバーのパフォーマンス特性に変化が生じます。

Windows 2000 上の TS に関して注意すべきもう 1 つの点は、初期ログオン交換とそれ以降のセッション データを保護するために暗号化が組み込まれていることです。既定の暗号化レベルは中レベルです。中レベルでは、56 ビット キー (旧バージョンの Terminal Server 4.0 クライアントを使用している場合は 40 ビット キー) と共に RSA セキュリティの RC4 暗号化アルゴリズムを使用してサーバーとクライアントの間で双方向に暗号化を行います。ターミナル サービスでは、128 ビットの双方向暗号化もサポートしていますが、Windows 2000 High Encryption Pack がインストールされている場合のみ利用可能です。2000 年初頭より、米国からの輸出が禁じられている地域を除き、米国国外の顧客に対しても強力な暗号化を輸出提供できるようになったので、グローバル環境への展開時に暗号化ビット数の違いが障壁になることが少なくなりました。クライアントの接続に 128 ビット セッション セキュリティを強制的に適用するには、ターミナル サービス構成 MMC スナップイン (tscc.msc /s) を使用します。[接続] コンテナを選択して、その中にある [RDP-Tcp] 接続オブジェクトを右クリックします。[プロパティ] を選択し、[一般] タブで [暗号化レベル] を [高] に設定します。

TS 特権についても注意が必要です。この特権の強力さを過小評価してはいけません。信頼できる人員だけに、この特権を付与するようにしてください。リモート管理モードでインストールされた TS に対する接続は、既定では、管理者グループのメンバにのみ許可されます。

UNIX システムでは、通常のユーザーとしてログインした後、"substitute user" (su) コマンドを使用して異なるユーザー アカウントのコンテキストでセッションを開始することが管理上の慣習として定着しています。ログオン時のアカウントよりも強力な特権を持つアカウント、つまり管理者アカウントをセッション開始時に使用するのが普通です。TS の場合も、これにならい、管理者に対しては TS へのアクセスを拒否し、通常のユーザー アカウントに対してのみ TS へのアクセス権を付与する方法が有力なセキュリティ対策となります。通常のユーザー アカウントで TS にアクセスしたら、runas コマンドを実行し、正しいパスワードを入力して、TS サーバー上の管理者としてセッションを開始します。これにより、二重のセキュリティ層が侵入者の前に立ちはだかることになります。通常のユーザーのパスワードを見破り、そのうえ、特権をエスカレートした上で管理者のパスワードを見破らない限り、TS に侵入することができません。リモート管理者が実行するタスクの範囲によっては、手順が煩雑になりすぎることもあるので、実際に問題がないかどうかを判断したうえで、この方法をとってください。TS へのユーザー アクセスを管理する場合も、ターミナル サービスの構成 MMC スナップイン (tscc.msc /s) を使用します。[接続] コンテナを選択して、その中にある [RDP-Tcp] 接続オブジェクトを右クリックします。[プロパティ] を選択し、[アクセス許可] タブで管理者グループを削除し、TS へのアクセス権を付与するグループまたはユーザーを追加します。すべてのユーザーに対して、「ゲスト アクセス」のアクセス許可だけを付与します。

リモート管理者によって実行されたすべてのアクティビティを追跡できるように監査を有効化しておく必要があることは言うまでもありません。さらに、作業完了時には単に接続を切断するだけでなく、TS セッションからログアウトしなければなりません。定義された時間が経過した後は、前述した tscc.msc を使って [セッション] タブの設定を行い、接続を強制切断するか、セッションを終了することができます。また、Windows 2000 の標準ユーザー管理ツール (compmgmt.msc または Active Directory ユーザーとコンピュータ スナップイン) を使用すると、この操作をユーザー別に実行できます。

以前のコラムで、セキュリティで保護されたその他の管理ツールについて説明したときに、Secure Shell (SSH) を取り上げました。SSH には、Secure Copy (scp) および Secure FTP (SFTP) がサブプロトコルとして用意されており、セキュリティで保護されたファイル転送とセキュリティで保護されたリモート コマンド ライン管理が可能であるという利点があります。これに対し、ターミナル サーバーには、リモート グラフィカル シェルだけが用意されており、セキュリティで保護されたファイル転送の機能は統合されていません。最近、Van Dyke Technologies から、市販品としては初となる Win32 SSH2 サーバーがリリースされました。これは、VShell と呼ばれており、現在ベータ 2 がリリースされています。要チェックです。

もちろん、Win32 プラットフォーム用のさまざまなリモート グラフィカル管理ツールがサードパーティから発売されています。出張先の環境では、Symantec の pcAnywhere、RemotelyAnywhere、AT&T Lab の VNC (フリーウェア) が使用されているのをよく見かけます。これらの製品のセキュリティ面での長所と短所について触れるのは、このコラムの範囲を超えていますが、『Hacking Exposed 2nd Ed.』の 第 13 章に説明があります。

今月のこのコラム、皆さんのお役に立てば幸いです。お寄せくださった質問には、来月のコラムでお答えしたいと思います。

筆者の Joel Scambray は、Foundstone の社長で、Osborne-McGraw Hill から発行されている『Hacking Exposed: Network Security Secrets & Solutions, Second Edition』の著者の 1 人です。

セキュリティに関する質問を Ask Us About Security メールボックスにお寄せください。ご質問が採用された場合、次回以降の記事でその回答をご紹介します。

ここに記載されている情報は、ユーザーに役立つことを目的として提供されています。ただし、本文書に記載されている情報を使用するにあたっては、ユーザーが責任を負うものとします。本文書の情報は "現状のまま" 提供されており、その正確性、完全性、特定の目的への適合性、名称や権利の遵守について、明示的または暗黙的を問わず、いかなる保証も致しません。また、本文書で言及した情報について、Microsoft 社ではサポートまたは保証を一切行っておりません。Microsoft 社では、本文書の情報を基に行った操作による直接的、間接的、偶発的、派生的、あるいは特殊な損害に対して、本文中に損害の可能性が記載されている場合も含めて、一切の責任を負いません。