2004 年 10 月

著 Brett Hill

Internet Information Services に関してよく寄せられる質問と答え

トピック

完全な Web サイトをサーバー間で移動させる (FPSE を含む)
httperr.log のコンテンツの変更
IIS 6 のサーバー バナーの削除

完全な Web サイトをサーバー間で移動させる (FPSE を含む)

完全な Web サイトを FrontPage Server Extensions とセキュリティ設定とともに、サーバーからサーバーに完全に移動するにはどのようにしたらよいですか?

これを行う方法は多くありますが、どの方法をとるかは様々な詳細によって異なります。例えば、IIS 5 から IIS 5 に移行するのは、IIS 5 から IIS 6 への移行と比較して、いくつかの点で異なるタスクでありますが、共通点も多くあります。 1 つの可能性としては、(移行するサーバーの互いの類似点と使用するライセンスの詳細によって異なります) ソース サーバーのイメージを作成し、対象のサーバーでそのイメージを読み込む方法があります。これは、両方のコンピュータ上のハードウェアが理論上同じものであることを前提とするサーバー間の複雑な IIS のセットアップの移行をする役に立つ方法です。これは、ローカル ユーザーおよびグループが多くある場合、特に役立ちます。 すべてのほかの方法は、より労力を必要とします。FrontPage の Web に関しては、FrontPage クライアントを使用して、サーバーから他のサーバーに Web サイトを公開することを強く推奨します。これにより、非常に多くの機能を使用できるようになりますが、移行作業を行う前に、Web サイトを作成し、そのサイトに FrontPage Server Extensions を追加する必要があります。移行する必要のあるサイトの数によっては、これは、FrontPage の Web を移行するよりよい方法となります。 IIS 5 から IIS 6 に移行する際、コンテンツを移動し、IIS に Web サイトの複製を作成し、IIS 6 Resource Guide の IIS Migration Tool を使用して、まとめて周知のアカウント (ユーザー、すべてのユーザー、認証されたユーザーなど) のアクセス権を移動することができます。また、そのツールにあるスイッチにより、対象のサーバー上の新たな Web サイトに自動的に FrontPage Server Extensions を追加することができます。そのツールは、Microsoft.com/downloads から最新バージョンのツールをダウンロードしてください。(このページの作成時点では、バージョン 1.1 が最新版となっています) また、Adsonline の IIS Export を検索してください。このシェアウエア ユーティリティは、長い間、IIS の移行タスクで役に立つとの評判を得ています。 おっしゃっているローカルのアクセス権の移行に関しては、少し問題があります。ローカル ユーザーおよびローカル グループのアクセス権は、他のサーバーに直接移行することができません。これには、Web サイトを拡張する際に FrontPage Server Extensions で作成することができる IUSR アカウントおよび ローカル グループのようなユーザーが含まれます。対象のサーバーで新規のユーザーまたはグループを作成し、アクセス権を再度割り当てる必要があります。マイクロソフトは、ローカル ユーザーおよびグループをコンピュータ間で複製するためのユーティリティは提供していませんが、そのようなソフトウェアは、他のベンダから利用可能です。Small Wonders software から、Secure Copy という製品がリリースされており、この作業を行うことができます。おそらく他にも同様の製品があると思われます。 上記の問題だけでなく、証明書、Web アプリケーション、ODBC 接続、COM オブジェクト、またはセキュアなサーバーで使用されているそのほかの技術に関するプランも行う必要があります。それらのタスクは必ずしも単純ではありませんが、綿密な計画によりこれらの問題を管理することができます。 Microsoft Windows Server 2003 Deployment Kit の Deploying IIS 6.0 を参照ください。 (http://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx)

httperr.log のコンテンツの変更

	IIS 6.0 サーバーで発生するアプリケーション リサイクルのいくつかの問題のトラブルシューティングをしようとしています。httperr.log ファイルを確認すると、問題があるアプリケーション プールを識別するための情報が十分には含まれていません。IP アドレスおよび Web サイトのインスタンスは記録されますが、そのほかの役立つ情報は多くはありません。httperr.log ファイルのコンテンツは何らかの方法で変更することができますか?
	IIS 6.0 の httperr.log ファイルは、http.sys の動作およびエラーに関連するイベントを記録します。たとえば、アプリケーション ツールがオフラインの場合、Web サイトはリクエストに応答できないため、入力は http.sys に行われます。そのようなイベントには、無効な http リクエスト、タイムアウトしたクライアントの終了した接続、情報が受け取られるのが遅すぎて他の同様なイベントのログが記録されるために終了した有効な接続などがあります。

httperr ログ ファイルのファイル形式は、以下の通りです。

フィールド	説明
日付	日付 (UTC 時間) このエントリは、常に 10 文字となる。(例 : 2000-01-31)
時間	時間 (UTC 時間) このエントリは、常に 10 文字となる。 (例 : 00:12:23)
クライアント IP	クライアントの IP アドレス。IP アドレスのバージョンは、IPv4 または IPv6 のいずれかとなる。IPv6 の場合、スコープ ID フィールドも表示される。
クライアント ポート	クライアントのポート番号
サーバー IP	サーバーの IP アドレス。サーバーの IP アドレスは、IPv4 または IPv6 のいずれかとなる。IPv6 の場合、スコープ ID フィールドも表示される。
サーバー ポート	サーバーのポート番号
プロトコル バージョン	プロトコル バージョン (接続の最後のリクエストがプロトコル バージョンを識別できるように解析された場合) メジャーまたはマイナー バージョンが 10 以上の場合、ドライバは、バージョンが “HTTP/?.?” として記録する。
Verb	verb (解析された最新のリクエストが verb のステータスを渡した場合) 未知の verb も記録される。HTTP.sys は verb に 255 バイトの長さの制限があり、それより長い場合切り捨てられる。
Cooked URL およびクエリ	URL およびそのクエリ (両方ある場合) 疑問符 (?) により、クエリから URL を区別する。リクエストの URL が完全に処理される (または cooked と呼ばれる) 場合、処理された URL は、ローカル コード ページ変換で記録され、Unicode フィールドとして処理される。 ログが記録されるタイミングで処理されていない URL がある場合、ローカル コード ページ変換ではなく、そのまま記録される。HTTP.sys は、URL の 4096 バイトの長さの制限があり、それより長い場合切り捨てられる。
プロトコルのステータス	リクエストの応答のプロトコルのステータス。その値は 999 を超えない。
サイト ID	サイト ID (数値) たとえば、W3SVC1 を記録する代わりに、フィールドには “1” が含まれる。サイト ID の最大値はない。(この値は、MAX_ULONG と同じ数値にすることができる)
理由フレーズ	エラーの種類に従って、エラーの起こった理由に関する詳細な情報。このフィールドは、空欄となることはない。理由フレーズに関する詳細は、このページの後半に記載されている「HTTP.sys の理由フレーズ」をご覧ください。

Web サイト ID (イベントに関連する Web サイトを識別する) が記録されるが、サイトに複数のアプリケーション プールがある場合、リクエストが送られる Web サイトからプールを識別することができません。Windows Server 2003 の製品版のリリースでは、これらのフィールドは設定可能ではありません。

これらの問題に対応するために、マイクロソフトは、httperr ログ ファイルを大幅に変更する http.sys の更新プログラムをリリースしました。その更新プログラムを適用すると、記録されたフィールドで httperr ログ フィールドと W3SVC 標準ログ フィールドの組み合わせた構成をコントロールすることができます。これに、エラーに関連するアプリケーション プールに新たなエントリを追加すると、より多くの情報を含むログ ファイルが得られます。

この変更に関しては、http://support.microsoft.com/default.aspx?scid=kb;ja;832975&sd=tech に説明されています。またこの機能は、Windows Server 2003 Service Pack 1 に含まれる予定です。

IIS 6 のサーバー バナーの削除

	URLScan を使用して IIS 5 のサーバー バナーを削除できることを知っていますが、URLScan を必要としない IIS 6 でこれを行う方法はありますか?
	まず、IIS 6 がクライアントに戻すデータを確認してみましょう。Microsoft.com へのリクエストをする際、サーバーは、以下のようなデータを戻します。

HTTP/1.1 200 OKCache-Control: publicContent-Length: 13073Content-Type: 
text/htmlExpires: Fri, 08 Oct 2004 18:23:35 GMTLast-Modified: Fri, 08 Oct 2004 15:36:55 
GMTServer: Microsoft-IIS/6.0X-AspNet-Version: 1.1.4322P3P: CP="ALL IND DSP COR ADM CONo CUR 
CUSo IVAo IVDo PSA _PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR 
UNI"X-Powered-By: ASP.NETDate: Fri, 08 Oct 2004 15:56:26 GMT

サーバー バナーと呼ばれる、明らかに IIS 6.0 サーバーを示します。セキュリティ専門家の中には、このバナーを削除して、攻撃者が接続する Web サーバーの種類をわからないようにすることを推奨している人がいます。これは、単純にバナーを取得して、サーバーの攻撃を行う可能性のある「スクリプト キディ」のエンジンの場合、いくつかのメリットがあります。

ご覧のように、サーバーの応答には、X-ASPNet- バージョン番号および X-Powered-by: ASP.NET を含む Microsoft サーバーとして識別する多くのアイテムが含みまれます。

ASP.net がインストールされる際にこれらのタグが追加され、IIS 5 サーバーおよび IIS 6 サーバーで表示されます。また、FrontPage Server Extensions をインストールした場合、Microsoft Office Web サーバーにアクセスしていることを知らせるヘッダが表示されます。

これらのヘッダは、HTTP ヘッダ タブの IIS コンソールで削除することができます。それによって FrontPage に問題が発生するかどうかをテストしていませんが、そのほかには機能への影響はないものと考えられます。

サーバー ヘッダおよびアドオン タグを削除した場合、Asp または ASP.net のページを配信しているという事実によって、IIS サーバーを使用していることが攻撃者によって推測される可能性があります。これは、明らかに非常に細かいことです。その他、同様に簡単に使用しているサーバーの種類を認識するための方法があります。

そのため、サーバー バナーを削除または隠すことは、私はあまりお勧めしませんが、URLScan を使用して、(IIS 5 および IIS 6 の両方に対して) URLScan.ini ファイルの RemoveServerHeader 設定のバナーを削除することもできます。

関連情報

これまでの IIS Insider コラムの質問と答えの一覧は、ここをクリック してください。