IIS Insider

IIS では、URL をリダイレクトするためにIIS に指定する方法に関しては多くの選択肢があります。あまり知られてはいませんが、非常に役に立つIIS の機能の 1 つに、新しい URL に渡される値を高いレベルで厳密に制御するため、リダイレクトで変数を使用することができる機能があります。たとえば、この場合、古いbrowse.asp 上で右クリックをし、[ファイル] タブで、[URL へのリダイレクト] を選択し、http://servername/newfolder/browse.asp$Q と入力します。これは、ビルトインサーバーリダイレクト変数の $Q を使用して、元の URL のクエリ文字列の一部が新しい場所に送信されるものです。下のテーブルは、マイクロソフトサポート技術情報 313074 に記載されているオンラインIIS 5 ヘルプファイルで利用可能なクエリ文字列の詳細です。

私は「インプロセス」という言葉は少し紛らわしいと常々思っていました。すべてのアプリケーションは処理され、そのため実際には、「分離プロセス」で実行されるアプリケーションなどはありません。それでも、IIS アプリケーションに関連してこれらの言葉をよく耳にしますが、実際にはどのような意味なのでしょうか? IIS 4 および 5.x では、inetinfo というプロセスがあります。Web アプリケーションが「インプロセス」プロセスで実行される際、そのアプリケーションはinetinfo プロセスの内部で実行されています。IIS 4 アプリケーションでは、アプリケーションは既定でinetinfo プロセスで実行されます。

それはinetinfo で実行されない「分離プロセス」アプリケーションということになります。「分離プロセス」アプリケーションは、IIS 4 ではMTX、IIS 5.x ではdllhost いう名前のプロセスでホストされます。

すべてのプロセスは、ユーザーアカウントのセキュリティコンテキストで実行されます。Inetinfo プロセスは、システムアカウントとして実行されます。MTX (IIS 4) およびdllhost (IIS5.x) はIWAM_<サーバー名> アカウントとして実行されます。

この質問には完全にお答えすることができます。バッファオーバーランの攻撃が実行された場合には、攻撃者は異常終了したアプリケーションをホストしたプロセスのセキュリティコンテキストでコードが実行される恐れがあります。そのため、アプリケーションが「インプロセス」(inetinfo プロセス) で実行されている場合、攻撃者はサーバー上で広く使用されているアクセス権を持つシステムコンテキストである可能性があります。アプリケーションがMTX または dllhost の「分離プロセス」である場合、攻撃者はサーバー上で非常に限定されたアクセス権しか持たない IWAM アカウントのコンテキストにいる可能性があります。

IIS 5 の既定の構成では、すべてのアプリケーションをアプリケーション保護設定の「中」（プールされた分離プロセス）で、「分離プロセス」の状態ですべてのアプリケーションを実行されることに注意してください。これは、前述の理由により、アプリケーションをインプロセスで実行するよりもはるかに安全です。広く知られている、System アカウントでサーバーへアクセスするIIS 5 へのバッファオーバーフローの攻撃は、既定の設定よりもより脆弱性の影響を受ける構成になります。IIS Lockdown Tool を実行し、セキュリティを向上させ、IWAM アカウントおよび IUSR アカウントへの規制を適用することができます。

ところで、IIS 6 (Windows Server 2003 2003 の一部) は、既定のウォーカープロセス分離モードで、サーバーに高い権限のアカウントでアクセスできるようにするバッファオーバーフロー攻撃の可能性はありません。

興味深い問題ですが、憶測が含まれており、その点を明確にする必要があります。確かに、IIS では一般的には c:\windows\winnt\logfiles ディレクトリにログファイルフォルダが作成されます。また、ご指摘のように、Web サイトを削除し、再度作成する場合、ログファイルフォルダ名が変更されます。しかし、IIS は、ログファイルの前のセットと競合しないようにするためにファイルフォルダ名を基にインクリメントを行いません。正確には、ログファイルのフォルダ名は、メタベースの Web サイトの「サイト番号」（インスタンス番号と呼ばれる場合もあります）を基にしてつけられます。作成するすべてのサイトは、一意の番号が付けられており、新しい Web サイトを作成すると常にその番号でインクリメントが行われます。MetaEdit を使用するとこれをはっきりと確認することができます。MetaEdit では、Web サイトがフォルダ1、2、3 （この場合、メタベースキー）として表示されます。1 のフォルダは、通常既定の Web サイトで、2 は管理者 Web サイトのようになります。（以下の図 1 参照）

図 1: MetaEdit での表示のされ方

したがって、サイト1、2、3 が存在し、サイト 2 を削除し、IIS コンソールから新しい Web サイトを作成し、古い Web サイトを再度作成する場合、IIS は、次の最も大きいサイト番号（この場合5）を割り当てます。ログファイルは次に w3svc3 ではなく w3svc5 という名前のフォルダに置き換えられます。

サイトを作成したら、他のキー（サイトルートパスなど）が参照するため、サイト ID を変更しないことが重要です。この場合、古いログファイルフォルダから単純に新しいログファイルフォルダにコピーすることができます。

しかし、ユーザーインターフェイスではなく Web サイトを作成するためのスクリプトを使用した場合、「代わりの」 Web サイトに使用したいサイト ID を指定することができます。この方法で、目的を達成することができます。\Inetpub\Adminscripts フォルダに mkw3site.vbs というスクリプトがあります。（これは既定でインストールされます）そのスクリプトをメモ帳またはほかのテキストエディタで開き、使用されている構文を確認し、引数の 1 つがSitenumber となっていることを確認します。これにより、IIS コンソールによって確定するインクリメントが行われた次のサイト番号ではなく、指定したサイト番号で Web サイトを作成することができるようになります。