IIS Insider

匿名ユーザー アカウントには、既定で設定される 「パスワードが無制限」 および 「ユーザーはパスワードを変更できない」 プロパティがあります。これはスタンドアロンおよびドメイン コントローラの両方に当てはまります。そのため、それらの設定を変更するアカウント上で何らかの操作を実行しない限り、パスワードは有効期限切れになりません。これはパスワードの有効期限を無効にするサーバーにセキュリティ ポリシーが適用されている場合に発生します。管理者は新しい匿名ユーザー アカウントを作成するか、またはアカウントを無効に設定し、その特別な目的を実行しないようにした可能性があります。（その IWAM アカウントが IIS には必要なく、削除することができるとセキュリティ管理者に言われたことがあります） また、パスワード ポリシーのセットを実行するセキュリティ スクリプトが実行されており、匿名ユーザーを含むすべてのユーザーにアカウント ポリシーがリセットされている可能性があります。「アカウントの管理とポリシー変更を監視する」 の監査を有効にし、これらの設定を変更している動作を確認する必要がある場合があります。

すべてが適切に設定されているように見えるのにも関わらず、うまく動作しないという問題に遭遇した際、私は一瞬立ち止まって大きな視点で考えるようにします。一般的に言って、構成上の問題とサーバーの問題の 2 種類の問題が存在します。まずすべきことは、その問題がどちらの種類の問題であるかを迅速に確認することです。

最初に考えることは、ホスト ヘッダーの機能を持つこのアプリケーション （IIS） の歴史についてです。IIS 5 でホスト ヘッダーを使用すると、非常に強力で信頼度の高い機能が提供されることが証明されています。私が確認した問題のほとんどは、構成上の問題です。したがって、メタベースの破損などのより解決しにくい何らかの可能性を確認する前に、誤った構成の問題を排除することに焦点を当てようと思います。

もちろん、ここに挙げられているものと同じ状況は、ホスト ヘッダーと SSL を連携して使用している場合に起こる可能性があります。サイトを識別するためにホスト ヘッダーを使用する際に、ホスト ヘッダー ベースの Web サイトとともに SSL を使用することはできません。

SSL が使用されていないと仮定し、次に私が恐らくすることは、すべての Web サイトから "未使用の IP アドレスすべて" の設定を削除し、それらを適切な IP アドレスに関連付けることです。これにより、そのような場合に応答する Web サイトがなくなるため、DNS IP アドレスが異なるアドレスにポイントされる可能性が排除されます。一般的な法則として、私は未使用の IP アドレスすべての設定を使用するのを避けています。その理由は、それにより他の Web サイトの構成方法によって、その Web サイトが開始されたり、停止する可能性があるためです。このサイトを使用するアドレスをはっきりとさせておくほうが良いといえます。

管理している Web サイトのすべてがホスト ヘッダーを使用する構成にされている場合、IP アドレスを使用すると Web サイトは応答しません。その代わり、「このアドレスでは Web サイトは構成されていません」 というメッセージが表示されます。そのため次は、Internet Explorer を起動し、FQDN ではなく IP アドレスによって Web サーバーにアクセスするという動作を確認してください。（http://サーバー名 ではなく http://<IIS IP アドレス> を使用してください。） Web サイトの応答があった場合、そのサイトの構成を詳細に確認します。（1 つの IP アドレスのみが入力された場合に応答するのを避けるため）

IIS のユーザー インターフェースは、この特定の誤った構成が必要以上に起こるように動作します。

上記のように構成された場合、Web サイトはその IP アドレスに応答し、ホスト ヘッダーは効果的に使用されません。これは、[Web サイトの詳細構成] ウインドウ （Web サイト プロパティ、Web サイト、詳細） を最初に開いた際に、有効なボタンは[追加] のみです。[追加] ではなく、(未使用の IP アドレスすべて) 80 の既存の入力を選択し、次に [編集] をクリックします。すべての Web サイトの [詳細] タブが適切に構成されていることを確認してください。

次のテストは、多くのサイトをお持ちの場合には実行できないかもしれません。できる場合、1 つを除きすべての Web サイトを停止し、名前と IP アドレスによってその Web サイトにアクセスしてみます。IP アドレスではアクセスできず、名前ではアクセスできます。それが問題なく実行できた場合、テストしたばかりの Web サイトを停止し、他の Web サイトを起動し、そのテストを行います。このプロセスを繰り返し、それぞれのサイトが適切に動作されることを確認します。どちらの場合でも Web サイトが IP アドレスに応答してしまう場合、そのサイトは適切に動作していない、または構成が誤っていることになります。

すべてのサイトが適切に構成されているにも関わらず、適切に動作しない場合、トラブルシューティング システムの問題にあると考えられます。残念ながら一般的にはこれらはより極端な方法です。

以下の方法のいずれかを行うことができます。

両方とも失敗した場合には、有償サポートが必要になるかも知れません。

悪い知らせを伝える役割なのが残念ですが、このレベルまでシステムが侵害された方に、私が今できる最善のアドバイスとしては、ドライブの再フォーマットと再起動を行うことです。確認した事象を修正するための対策には 2 つの大きな問題があります。

まず、攻撃者が行ったシステムへの変更を確認したというのは仮定の話です。（それはすべてのファイルおよびネットワークの動作の一部始終のログを取得していなければほとんど不可能です。） 攻撃者が、トロイの木馬、キーボード ロガー (キーボードの入力を記録するソフトウェアまたはハードウェア)、見覚えのない管理コンソールをインストールしたという可能性があります。最新のハッキング技術では、オペレーティング システムの一部のように見えるカーネル モード ドライバを仕込むというものがあります。（これは、高度な技術をもってしても検出するのが困難です。）

第 2 に、すべて修正したとしても、攻撃者によって既にユーザー名およびパスワードなどの高い権限を持つ情報にアクセスされている可能性があります。攻撃者は、フル コントロールが割り当てられ、作成した名前またはクラッキングしたパスワードでログオンすることができるファイル ストラクチャで、ファイル ツリーの深くにある場所を作成している可能性があります。

IIS サーバーに接続している他のコンピュータを直ちに確認することが必要です。ドメイン コントローラは、IIS サーバーが通信する他のサーバー （例 : SQL、Exchange、IIS） と同様に、最初に確認する必要があります。攻撃者が IIS サーバーで権限を取得している場合、攻撃者が既にネットワークに侵入している可能性があります。

明らかに、これらの方法にかかる時間および費用は少なくありません。この理由で、私は企業と管理者に必要な専門知識と技術を備え、攻撃の可能性をできる限り低くしておくことを強くお勧めします。また、システムの監視の体制を整え、できる限り早急に管理者に警告するようにしておく必要があります。

高度なセキュリティを早急に実装する方法の 1 つに、マイクロソフトの Internet Security and Acceleration Server を使用して、ご使用の Web サーバーを ISA サーバーに "発行" することがあります。そのように構成した場合、ISA サーバーは、IIS サーバーを攻撃から保護するファイアウォールの役割を果たし、同時に必要なコンテンツをクライアントに配信します。このようにして、攻撃者は IIS サーバーに直接アクセスできなくなります。ISA サーバーの製品ガイドを以下のサイトでご覧ください。
http://www.microsoft.com/isaserver/prodinfo/guide.mspx (英語)

もちろん、ISA サーバーまたは他の安定したファイアウォールを設定しても、これは Web サーバーを効果的にセキュリティで保護するための代用とはなりません。このトピックに関して良いアドバイスが多くあります。以下のサイトをご覧ください。