第 2 部 : ネットワーク保護技術
最終更新日: 2005年3月2日
By Starr Andersen (テクニカル ライター)、Vincent Abella (テクニカル エディタ)
このドキュメントは「Windows XP Service Pack 2 での機能の変更点」の第 2 部です。ここでは、Microsoft® Windows XP Service Pack 2 に含まれるネットワーク保護技術について詳細に説明します。
このドキュメントの内容は、Windows XP Professional および Windows XP Home Edition の 32 ビット バージョン用 Microsoft Windows® XP Service Pack 2 (SP2) に適用されます。このドキュメントでは、Service Pack に含まれるすべての変更点について説明しているわけではありませんが、Windows XP SP2 の使用において大きな影響を持つ変更点を中心に説明し、必要に応じて追加情報の参照先も掲載されています。
トピック
Alerter サービスと Messenger サービス
クライアント管理ツール
DCOM セキュリティの強化
TCP/IP
RPC インターフェイスの制限
WebDAV リダイレクタ
Windows ファイアウォール
Windows Media Player
Windows Messenger
Wireless Provisioning Services
ワイヤレス ネットワーク セットアップ ウィザード
Alerter サービスと Messenger サービス
Alerter と Messenger の機能
Alerter サービスと Messenger サービスは Windows のコンポーネントであり、これらを使用してネットワーク上のコンピュータ間で簡単なメッセージをやり取りできます。Messenger サービスは別のアプリケーションやサービスからのメッセージを中継しますが、Alerter サービスは管理上の警告に特化したサービスです。
この機能の対象ユーザー
ユーザーとの通信を行う管理者は、このようなサービスに対する変更を把握しておく必要があります。また、このようなサービスを利用してユーザーにイベント通知を行ったり、ネットワークにメッセージをブロードキャストする開発者も、これらの変更を把握しておいてください。これらの変更は Microsoft Windows XP Service Pack 2 を実行しているすべてのコンピュータに適用されますが、影響を受けるのはネットワークに接続しているコンピュータだけです。
Windows XP Service Pack 2 で変更された既存機能
Alerter サービスと Messenger サービスの無効化
詳細説明
以前のバージョンの Windows では、Messenger サービスは自動的に開始され、Alerter サービスは手動で開始するように設定されていました。Windows XP Service Pack 2 では、どちらのサービスも無効に設定されます。これらのサービスに対するこれ以外の変更はありません。
この変更が重要な理由と軽減される脅威
このサービスが開始されると、着信方向のネットワーク接続が許可され、攻撃対象を提供することになります。そのため、セキュリティ上のリスクが高まります。また、現在のコンピューティング環境では、このようなサービスが使われることはあまりありません。サービスが攻撃対象を増やしていること、および一般的に利用される頻度が高くないことから、既定で無効化されるようになりました。
動作の相違点と依存関係の存在
Alerter または Messenger サービスを使用してユーザーとの通信を行うアプリケーションやサービスは、既定で正常に動作しません。
これらの問題の解決法
この問題を解決するには 2 つの方法があります。推奨される方法は、ユーザーとの通信に別の方法を使用するようソフトウェアを修正することです。これにより、Alerter または Messenger サービスを使わずに、強化されたセキュリティでユーザーと通信できます。
もう 1 つの方法は、Alerter または Messenger サービスを使用する前に、あらかじめアプリケーションで目的のサービスを開始しておくことです。サービスの開始方法については、オンライン ヘルプおよび MSDN を参照してください。例については、Microsoft Web サイトで、サービスを構成するためのサービス管理ツールについてのページ (http://go.microsoft.com/fwlink/?LinkId=25974) を参照してください。
Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか
コードで Messenger または Alerter サービスを使用している場合は、そのコードを変更する必要があります。詳細については、上記の「これらの問題の解決法」を参照してください。
Bluetooth
Bluetooth の機能
Bluetooth® ワイヤレス テクノロジは、モバイル デバイスを接続するための低価格な短距離ワイヤレス仕様で、さまざまなデバイスで利用可能なテクノロジです。Windows XP Service Pack 2 では、Bluetooth ワイヤレス テクノロジがサポートされます。このサポートは、これまで Microsoft から直接的には提供されていませんでした。このテクノロジを Windows オペレーティング システムのコア技術として追加してほしいという要望がユーザーより寄せられたため、サポートされるようになりました。
このリリースでは、次のことができるようになっています。
-
Bluetooth デバイスをコンピュータに接続する。
-
Bluetooth キーボードおよびマウスを使用してワイヤレス デスクトップを作成する。
-
Bluetooth デバイスとの間でファイルを転送する。
-
Bluetooth プリンタに出力する。
-
Bluetooth 携帯電話からコンピュータ ネットワークまたはインターネットに接続する。
-
Bluetooth 携帯電話経由でインターネットへのインターネット プロトコル (IP) 接続を設定する。
Microsoft または Microsoft 以外の適切なソフトウェア プログラムが Windows XP にインストールされている場合は、Bluetooth デバイスで以下のような操作も可能です。
このリリースでは、以下の Bluetooth プロファイルもサポートされています。
-
PAN (Personal Area Networking)。Bluetooth ワイヤレス テクノロジ経由の IP 接続を可能にします。
-
HCRP (Hard Copy Replacement Profile)。印刷を可能にします。
-
HID (Human Interface Device)。Bluetooth キーボード、マウス、およびジョイスティックを使用できるようにします。
-
DUN (Dial-Up Networking)。Bluetooth 携帯電話をモデムとして使用できるようにします。
-
OPP (Object Push Profile)。ファイル転送を可能にします。
-
SPP (仮想 COM ポート)。レガシ プログラムと Bluetooth デバイスとの通信を可能にします。
さらに、次の Bluetooth 機能も含まれています。
システムに Bluetooth トランシーバが存在していない場合は、システムの動作に変更はありません。WHQL (Windows Hardware Quality Labs) が承認している Bluetooth デバイスが存在する場合は、Bluetooth サポートが有効になります。
Bluetooth サポートが有効である場合は、コントロール パネルの [ネットワーク接続] の内容が変更になります。また、[Bluetooth デバイス] という新しいコントロール パネルの項目も追加されています。タスク バーの通知エリアにも Bluetooth アイコンが追加されます。このアイコンをクリックすると、実行可能な Bluetooth タスクのメニューが表示されます。新しい Bluetooth ファイル転送ウィザードも開始できます。これには、[スタート] ボタンをクリックし、[アクセサリ]、[通信] の順にポイントして、[Bluetooth ファイル転送ウィザード] をクリックします。
Microsoft 以外の Bluetooth ドライバが既にインストールされている場合、Windows XP Service Pack 2 にアップグレードすることによって既存のドライバが置き換えられることはありません。後から手作業またはプログラムで置き換えることができます。
Windows XP Service Pack 2 の Bluetooth に関する詳細なドキュメントについては、オンライン ヘルプを参照してください。
クライアント管理ツール
クライアント管理ツールの機能
クライアント管理ツールは、Microsoft 管理コンソール (MMC) のスナップインの集合で、ローカル コンピュータやリモート コンピュータ上のユーザー、コンピュータ、サービス、およびその他のシステム コンポーネントの管理に利用できます。これらのスナップインは、管理のために [ユーザー、コンピュータまたはグループの選択]、[ユーザー、連絡先およびグループの検索] という、システムによって生成される 2 つのダイアログ ボックスを使用します。[ユーザー、コンピュータまたはグループの選択] は、共有フォルダでのアクセス制御リスト (ACL) の設定、スナップインの対象を変更するためのリモート コンピュータの指定、ローカル ユーザーとローカル グループの管理に使用されます。[ユーザー、連絡先およびグループの検索] は、[マイ ネットワーク] での Active Directory の検索、プリンタの追加ウィザードでのプリンタの検索、[Active Directory ユーザーとコンピュータ] スナップイン内のディレクトリにおけるオブジェクトの検索に使用されます。
どちらのダイアログ ボックスでも、ローカル コンピュータまたは Active Directory から、ユーザー、コンピュータ、プリンタ、他のセキュリティ プリンシパルなどのオブジェクトを検索し、選択することができます。別のアプリケーションでもこのダイアログ ボックスを使用できますが、ここでは、クライアント管理ツールの変更点だけを説明します。
この機能の対象ユーザー
この機能は、以下に示す、変更の影響を受ける管理ツールを使用して、遠隔地から Windows XP を管理する必要のある管理者に適用されます。これらのツールをローカル コンピュータの管理に使用している管理者とユーザーには、影響はありません。
Windows XP Service Pack 2 で変更された既存機能
リモート接続
詳細説明
ここで挙げた管理ツールがリモート コンピュータに接続するには、リモート コンピュータにおいて TCP ポート 445 の着信方向のネットワーク トラフィックを許可する必要があります。ただし、Windows XP Service Pack 2 における Windows ファイアウォールの既定の設定では、TCP ポート 445 の着信方向のネットワーク トラフィックがブロックされます。結果的に、以下のような 1 つまたは複数のエラー メッセージを受け取る可能性があります。これらのメッセージを受け取る際、以下に記載されているメッセージ内で < > で囲まれているテキストは、エラー状態に応じて適切なシステム変数で置き換えられます。
-
コンピュータ <コンピュータ名> にアクセスできません。
エラー : アクセスは拒否されました。
-
コンピュータ <コンピュータ名> にアクセスできません。
エラー : ネットワーク パスが見つかりませんでした。
-
<コンピュータ名> のグループ ポリシー オブジェクトを開くことができませんでした。適切な権利がない可能性があります。
-
詳細 : ネットワーク パスが見つかりませんでした。
-
次の名前のオブジェクト (コンピュータ) が見つかりません : <コンピュータ名>。選択したオブジェクトの種類と場所が正確で、入力したオブジェクト名が正しいことを確認してください。または選択した項目からこのオブジェクトを削除してください。
-
コンピュータ <コンピュータ名> を管理できません。
ネットワーク パスが見つかりませんでした。[別のコンピュータへ接続] を [操作] メニューから選んで別のコンピュータを管理してください。
-
システム エラー 53 が発生しました。ネットワーク パスが見つかりませんでした。
上記のエラーは、リモート管理に以下の MMC スナップインのいずれかを使用した場合に発生する可能性があります。
-
証明書
-
コンピュータの管理
-
デバイス マネージャ
-
ディスクの管理
-
イベント ビューア
-
グループ ポリシー
-
インデックス サービス
-
IP セキュリティ モニタ
-
IP セキュリティ ポリシー
-
ローカル ユーザーとグループ
-
リムーバブル記憶域の管理
-
ポリシーの結果セット
-
サービス
-
共有フォルダ
-
WMI コントロール
MMC スナップイン以外に、次のダイアログ ボックスと管理ツールが影響を受けます。
-
ユーザー、コンピュータまたはグループの選択
-
ユーザー、連絡先およびグループの検索
-
Net.exe
これらの問題の解決法
これらのツールを使用して、Windows XP を実行しているコンピュータを Windows ファイアウォールを有効にしてリモート接続するには、リモート コンピュータのファイアウォールで TCP ポート 445 を開く必要があります。これは、以下の手順で行います。
-
[スタート] ボタンをクリックし、[すべてのプログラム]、[アクセサリ] の順にポイントして、[コマンド プロンプト] をクリックします。
-
コマンド プロンプトで、「netsh firewall set portopening TCP 445 ENABLE」と入力し、Enter キーを押します。
注 ファイアウォールのポートを開くことは、セキュリティの脆弱性につながる可能性があります。構成を変更する際は、注意深く計画し、テストしてから実装してください。
DCOM セキュリティの強化
DCOM の機能
Microsoft コンポーネント オブジェクト モデル (COM) は、対話可能なバイナリ ソフトウェア コンポーネントを作成するための、プラットフォームに依存しない分散型のオブジェクト指向システムです。分散コンポーネント オブジェクト モデル (DCOM) では、ユーザーとアプリケーションにとって最適な場所に、アプリケーションを分散させることが可能になります。DCOM ワイヤ プロトコルは、信頼性が高く、セキュリティ保護された効率的な、COM コンポーネント間通信を透過的に提供します。詳細については、Microsoft Web サイトで、コンポーネント オブジェクト モデルについてのページ (http://go.microsoft.com/fwlink/?LinkId=20922) を参照してください。
この機能の対象ユーザー
このセクションは、インプロセス COM コンポーネントの COM を使用するだけの場合については想定していません。
この機能は、以下の条件のいずれかに該当する COM サーバー アプリケーションがある場合に適用されます。
-
アプリケーションに対するアクセス許可は、実行に必要な許可ほど厳格ではない。
-
アプリケーションは通常、Microsoft Windows XP を実行しているコンピュータで、リモート COM クライアントによって管理者アカウントを使用せずにアクティブ化される。
-
アプリケーションは既定で、Windows XP を実行しているコンピュータで非認証のリモート コールバックを使用する。
-
アプリケーションは、ローカルでのみ使用されるように意図されている。つまり、COM サーバー アプリケーションにリモートでアクセスできないように制限できる。
Windows XP Service Pack 2 でこの機能に追加された新機能
コンピュータ全体にわたる制限
詳細説明
COM は、そのコンピュータ上のすべての呼び出し、アクティブ化、および起動の要求に対するアクセスを管理する、コンピュータ全体のアクセス制御を提供するよう変更されています。これらのアクセス制御をチェックする最も簡単な方法は、追加の AccessCheck 呼び出しを実行することです。この呼び出しは、コンピュータ上のすべての COM サーバーのそれぞれの呼び出し、アクティブ化、または起動を管理する、コンピュータ全体のアクセス制御リスト (ACL) に対して行われます。AccessCheck が失敗した場合、呼び出し、アクティブ化、または起動の要求は拒否されます (この AccessCheck は、サーバー固有の ACL に対して実行される AccessCheck とは別に実行されます)。実際には、コンピュータ上のいずれの COM サーバーにアクセスする場合にも満たす必要のある最低限の承認標準を提供します。アクティブ化権限と起動権限を対象とする起動許可用のコンピュータ全体の ACL と、呼び出し権限を対象とするアクセス許可用のコンピュータ全体の ACL があります。これらは、コンポーネント サービス Microsoft 管理コンソール (MMC) を使って設定できます。
これらのコンピュータ全体の ACL を使用すると、CoInitializeSecurity によってアプリケーションごとに指定されている脆弱なセキュリティ設定や、アプリケーション固有のセキュリティ設定を無効にすることができます。これは、特定のサーバーの設定に関係なく、満たす必要がある最低限のセキュリティ基準を提供します。
これらの ACL は、RPCSS によって公開されたインターフェイスへのアクセスが行われるときにチェックされます。したがって、このシステム サービスにアクセスできるユーザーを制御する手段となります。
これらの ACL は、管理者が、コンピュータ上のすべての COM サーバーに適用される全般的な承認ポリシーを一元的に設定できる場所として使用されます。
Windows XP コンピュータの制限の設定は、既定では次のとおりです。
|
許可
|
Administrator
|
Everyone
|
Anonymous
|
|---|
|
起動
|
ローカル (起動)
ローカル アクティブ化
リモート (起動)
リモート アクティブ化
|
ローカル (起動)
ローカル アクティブ化
|
|
|
アクセス
|
|
ローカル (呼び出し)
リモート (呼び出し)
|
ローカル (呼び出し)
|
この変更が重要な理由と軽減される脅威
多くの COM アプリケーションには、セキュリティ固有のコード (CoInitializeSecurity の呼び出しなど) が含まれていますが、脆弱な設定を使用しているために、プロセスへの非認証のアクセスが許可される場合がしばしばあります。以前のバージョンの Windows では、現在のところ、管理者がこれらの設定を無効にして、より強力なセキュリティを強制する方法はありません。
COM のインフラストラクチャには、RpcSs という、システムの起動時に実行され、その後も常に実行されるシステム サービスが含まれています。これは、COM オブジェクトのアクティブ化と実行中のオブジェクトのテーブルを管理し、DCOM リモート処理に対するヘルパー サービスを提供します。これは、リモートで呼び出し可能な RPC インターフェイスを公開します。前のセクションで説明したように、一部の COM サーバーは、非認証のリモート アクセスを許可するので、これらのインターフェイスは、認証されていないユーザーも含めてどのユーザーでも呼び出すことができます。その結果、RpcSs は、リモートの非認証コンピュータを使用する悪意のあるユーザーによる攻撃を受ける可能性があります。
以前のバージョンの Windows では、管理者がコンピュータ上の COM サーバーの公開レベルを判断する方法はありませんでした。コンピュータに登録されているすべての COM アプリケーションのセキュリティ設定を体系的にチェックすれば、公開レベルを把握することは可能ですが、Windows XP の既定のインストールには約 150 の COM サーバーがあるため、それは気の遠くなる作業です。ソフトウェアにセキュリティが組み込まれているサーバーの設定を知るには、そのソフトウェアのソースコードを調べること以外、方法はありません。
DCOM をコンピュータ全体で制限すれば、これらの 3 つの問題は軽減されます。また、管理者にとっては、着信方向の DCOM のアクティブ化、起動、および呼び出しを無効にする手段ともなります。
動作の相違点
ローカル起動、ローカル アクティブ化、およびローカル呼び出しの許可は、既定で Everyone グループに付与されます。これにより、すべてのローカル シナリオが、ソフトウェアまたはオペレーティング システムを変更することなく実現可能になります。
リモート呼び出しの許可は、既定で Everyone グループに付与されます。これにより、COM クライアントがリモート サーバーにローカル参照を渡し、事実上クライアントをサーバー化する一般的なケースも含めて、ほとんどの COM クライアントのシナリオが実現可能になります。これにより、非認証のリモート呼び出しを必要とするシナリオが無効になる可能性があります。
また、リモート アクティブ化および起動の許可は、既定で Administrators グループのメンバにのみ付与されます。これにより、管理者以外のユーザーが、インストールされている COM サーバーをリモートにアクティブ化することは不可能になります。
これらの問題の解決法
COM サーバーを実装し、管理者以外の COM クライアントによるリモート アクティブ化またはリモートの非認証呼び出しをサポートする必要がある場合は、それに伴うリスクを受け入れることができるかどうか、または管理者以外の COM クライアントによるリモート アクティブ化やリモートの非認証呼び出しを必要としないように実装方法を変更すべきかどうかを検討する必要があります。
リスクを受け入れることができ、管理者以外の COM クライアントによるリモート アクティブ化またはリモートの非認証呼び出しを有効にする場合は、この機能の既定の設定を変更する必要があります。
構成設定の変更は、コンポーネント サービス Microsoft 管理コンソール (MMC) または Windows レジストリを使用して行うことができます。
コンポーネント サービス MMC のスナップインを使用する場合は、管理対象コンピュータの [プロパティ] ダイアログ ボックスにある [COM セキュリティ] タブでこれらの設定を構成できます。[アクセス許可] 領域は、COM サーバーの標準的な既定の設定に加えて、コンピュータ全体にわたる制限を設定できるように変更されています。さらに、制限と既定値の両方に基づいて、ローカル用とリモート用に個別の ACL 設定を作成することもできます。
[起動とアクティブ化のアクセス許可] 領域では、コンピュータ全体にわたる制限と既定値のほかに、ローカルとリモートの許可を制御できます。[セキュリティの設定] では、ローカルとリモートの両方のアクティブ化と起動の許可を個別に指定できます。
これらの ACL の設定は、レジストリを使用して構成することもできます。
これらの ACL は、以下の場所にあるレジストリに格納されます。
HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Ole
¥MachineAccessRestriction= ACL
HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Ole
¥MachineLaunchRestriction= ACL
これは、REG_BINARY 型に設定される名前付きの値であり、コンピュータ上の任意の COM クラスおよび COM オブジェクトにアクセスできるプリンシパルの ACL を記述するデータを含みます。ACL 内のアクセス権は次のとおりです。
COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16
これらの ACL は、通常のセキュリティ機能を使って作成できます。COM_RIGHTS_EXECUTE 権限は、常に存在する必要があります。たとえば、COM_RIGHS_EXECUTE_REMOTE 権限を付加するには、COM_RIGHTS_EXECUTE との論理和である 5 を指定します。この権限が欠如していると、無効なセキュリティ記述子が生成されます。
これらの設定を変更できるのは、管理者権限を持つユーザーだけです。
Windows XP Service Pack 2 で変更された既存機能
ネットワーク サービスとして実行される RPCSS
詳細説明
Windows XP SP2 では、RPCSS は、RPC エンドポイント マッパーおよび DCOM インフラストラクチャに対する重要なサービスです。このサービスは、以前のバージョンの Windows ではローカル システムとして実行されていました。攻撃対象を減らし、縦深防御 (defense in depth) を提供するために、RPCSS サービスの機能は、2 つのサービスに分割されています。ローカル システム特権を必要としない元の機能をすべて備えた RPCSS サービスは、ネットワーク サービス アカウントで実行されるようになりました。ローカル システム特権を必要とする機能は、ローカル システム アカウントで実行される新しい DCOMLaunch サービスに組み込まれています。
この変更が重要な理由
この変更により、RPCSS サービスにおける特権の昇格はネットワーク サービス特権に制限されるため、RPCSS サービスの攻撃対象が減少し、縦深防御が実現します。
動作の相違点
Windows XP Service Pack 2 における RPCSS サービスと DCOMLaunch サービスの組み合わせは、以前のバージョンの Windows で提供されていた RPCSS サービスと同等のものであるため、ユーザーにとっては透過的な変更となっています。
きめ細かい COM 許可の設定
詳細説明
COM サーバー アプリケーションの許可の種類には、"起動許可" と "アクセス許可" の 2 つがあります。起動許可は、COM サーバーが常に実行されているわけではない場合、COM のアクティブ化中に COM サーバーを起動するための承認を制御します。この許可は、レジストリ設定で指定されるセキュリティ記述子として定義されます。アクセス許可は、実行中の COM サーバーを呼び出す承認を制御します。この許可はセキュリティ記述子として定義され、CoInitializeSecurity API またはレジストリ設定を通じて、COM インフラストラクチャに提供されます。起動許可とアクセス許可は、両方ともプリンシパルに基づいてアクセスを許可または拒否し、呼び出し元がサーバーにとってローカルであるかリモートであるかは区別しません。
別の変更では、距離に基づいて COM アクセス権を区別します。定義されている 2 つの距離は、ローカルとリモートです。ローカル COM メッセージは LRPC (ローカル リモート プロシージャ コール) プロトコル経由で到着し、リモート COM メッセージは TCP (伝送制御プロトコル) に類似している RPC (リモート プロシージャ コール) ホスト プロトコル経由で到着します。
COM のアクティブ化とは、CoCreateInstance またはこのバリアントを呼び出すことにより、クライアント上の COM インターフェイス プロキシを取得する処理です。このアクティブ化プロセスの副次的な影響として、クライアントの要求を満たすために、COM サーバーの起動が必要となることがあります。起動許可 ACL では、COM サーバーを起動できるユーザーをアサートします。アクセス許可 ACL では、COM オブジェクトをアクティブ化できるユーザー、または COM サーバーが実行されている場合に、そのオブジェクトを呼び出すことができるユーザーをアサートします。
その他の変更としては、呼び出し権限とアクティブ化権限を分離して、2 つの操作が別々のものであることを反映させたことと、アクセス許可 ACL から起動許可 ACL にアクティブ化権限を移動したことがあります。アクティブ化と起動はどちらもインターフェイス ポインタの取得に関係するので、アクティブ化と起動のアクセス権は、論理的には共に 1 つの ACL に属します。また、起動許可は (しばしばプログラムによって指定されるアクセス許可とは異なり) 常に構成を通じて指定されるので、アクティブ化権限を起動許可 ACL に配置すると、管理者にアクティブ化の制御手段を提供することになります。
起動許可の ACE は、次の 4 つのアクセス権に分かれています。
-
ローカル起動 (LL)
-
リモート起動 (RL)
-
ローカル アクティブ化 (LA)
-
リモート アクティブ化 (RA)
アクセス許可セキュリティ記述子は、次の 2 つのアクセス権に分かれています。
-
ローカル呼び出し (LC)
-
リモート呼び出し (RC)
この COM セキュリティにより、管理者はきめ細かいセキュリティ設定を適用できるようになります。たとえば、ローカル呼び出しはすべてのユーザーから受け入れ、リモート呼び出しは管理者からのみ受け入れるように、COM サーバーを構成することができます。こうした区別は、COM 許可セキュリティ記述子を変更することによって指定できます。
この変更が重要な理由と軽減される脅威
以前のバージョンの COM サーバー アプリケーションには、DCOM を経由してネットワーク上でアプリケーションを公開せずに、アプリケーションをローカルのみで使用できるよう制限する方法はありませんでした。COM サーバー アプリケーションにアクセスできるユーザーは、ローカルからもリモートからもアクセスできることになります。
COM サーバー アプリケーションでは、認証されていないユーザーに自分自身を公開して、COM コールバック シナリオを実装しなければならない場合があります。このようなシナリオでは、認証されていないユーザーにもアプリケーションのアクティブ化を可能にする必要があり、好ましくありません。なぜなら、悪意のあるユーザーがこのシナリオを使ってサーバーに承認されていないアクセスを行うことが可能になるからです。
緻密に設定された COM 許可を使用すれば、管理者は、コンピュータの COM 許可ポリシーを柔軟に制御できます。このような許可により、このようなシナリオのためのセキュリティが有効になります。
動作の相違点と依存関係の存在
下位互換性を維持するために、既存の COM セキュリティ記述子は、ローカル アクセスとリモート アクセスの両方を同時に許可または拒否するよう解釈されます。つまり、アクセス制御エントリ (ACE) は、ローカルとリモートの両方を許可するか、ローカルとリモートの両方を拒否します。
呼び出しまたは起動の権限については、下位互換性の問題はありません。しかし、アクティブ化権限には、互換性の問題があります。COM サーバーの既存のセキュリティ記述子で、構成されている起動許可がアクセス許可より限定的であり、クライアントのアクティブ化のシナリオで最低限必要とされるものより制限されている場合は、起動許可の ACL を変更して、承認されているクライアントに適切な許可を付与する必要があります。
既定のセキュリティ設定を使用する COM アプリケーションには、互換性の問題はありません。COM のアクティブ化を使用して動的に起動されるアプリケーションでは、オブジェクトをアクティブ化できるすべてのユーザーが起動許可に既に含まれているので、ほとんどの場合、互換性の問題はありません。これらの許可が正しく構成されていない場合は、COM サーバーがまだ実行されていないときに起動許可を持たない呼び出し元がオブジェクトをアクティブ化しようとすると、アクティブ化のランダム エラーが発生する場合があります。
互換性問題が最も懸念されるアプリケーションは、他の何らかの機構 (Windows エクスプローラやサービス コントロール マネージャなど) によって起動されている COM アプリケーションです。これらのアプリケーションは、前述の COM アクティブ化によっても起動できます。COM アクティブ化は、既定のアクセス許可と起動許可を無効にし、呼び出し許可より限定的な起動許可を指定します。この互換性問題の対処法については、次のセクションの「これらの問題の解決法」を参照してください。
Windows XP Service Pack 2 にアップグレードしたシステムを以前の Service Pack にロールバックすると、ローカル アクセス、リモート アクセス、またはその両方を許可するように編集されていたアクセス制御エントリは、ローカル アクセスとリモート アクセスの両方を許可するように解釈されます。ローカル アクセス、リモート アクセス、またはその両方を拒否するように編集されていた ACE は、ローカル アクセスとリモート アクセスの両方を拒否するように解釈されます。Service Pack をアンインストールした場合は、新しく設定した ACE がアプリケーションの停止を引き起こさないことを確認してください。
これらの問題の解決法
COM サーバーを実装して既定のセキュリティ設定を無効にする場合は、アプリケーション固有の起動許可 ACL が適切なユーザーにアクティブ化許可を与えるようになっていることを確認してください。そうなっていない場合には、アプリケーション固有の起動許可 ACL を変更して、適切なユーザーにアクティブ化許可を与えるようにし、DCOM を使用するアプリケーションと Windows コンポーネントが失敗しないようにする必要があります。これらのアプリケーション固有の起動許可は、レジストリに格納されます。起動許可の詳細については、MSDN Web サイトで、LaunchPermission についてのページ (http://msdn.microsoft.com/ja-jp/library/ms687202.aspx) を参照してください。
COM の ACL は、通常のセキュリティ機能を使って作成または変更できます。
Windows XP Service Pack 2 で追加または変更された設定
注意 以下の設定を誤って使用すると、DCOM を使用するアプリケーションおよび Windows コンポーネントが失敗する可能性があります。
この表では、次の省略形が使用されています。
LL - ローカル起動
LA - ローカル アクティブ化
RL - リモート起動
RA - リモート アクティブ化
LC - ローカル呼び出し
RC - リモート呼び出し
|
設定名
|
場所
|
以前の既定値
|
既定値
|
設定可能な値
|
|---|
|
MachineLaunch
Restriction
|
HKEY_LOCAL_MACHINE
¥SOFTWARE ¥Microsoft ¥Ole¥
|
Everyone - LL、LA、RL、RA
Anonymous -
LL、LA、RL、RA
(これは新しいレジストリ キーです。これらは、既存の動作に基づいて有効な値をとります。)
|
Administrator - LL、LA、RL、RA
|
ACL
|
|
MachineAccess
Restriction
|
HKEY_LOCAL_MACHINE
¥SOFTWARE ¥Microsoft ¥Ole¥
|
Everyone - LC、RC
Anonymous - LC、RC
(これは新しいレジストリ キーです。これらは、既存の動作に基づいて有効な値をとります。)
|
Everyone - LC、RC
Anonymous - LC
|
ACL
|
|
CallFailure
LoggingLevel
|
HKEY_LOCAL_MACHINE
¥SOFTWARE ¥Microsoft ¥Ole¥
|
該当なし
|
このレジストリ キーは存在しませんが、キーあるいは値が存在しない場合、2 であると見なされます。
既定では、このイベントはログに記録されません。この値を 1 に変更して情報のログを開始し、問題のトラブルシューティングに役立てる場合、このイベントでは大量のエントリが生成される可能性があるため、必ずイベント ログの大きさを監視してください。
|
1 - COM サーバー プロセスにおける呼び出し中、イベント ログの失敗を常にログに記録します。
2 - COM サーバー プロセスにおける呼び出し中、イベント ログの失敗をログに記録しません。
|
|
InvalidSecurity
Descriptor
LoggingLevel
|
HKEY_LOCAL_MACHINE
¥SOFTWARE ¥Microsoft¥Ole¥
|
該当なし
|
このレジストリ キーは存在しませんが、キーあるいは値が存在しない場合、1 であると見なされます。
既定では、このイベントはログに記録されます。このイベントはまれにしか発生しません。
|
1 - COM インフラストラクチャが無効なセキュリティ記述子を検出した場合、イベント ログの失敗を常にログに記録します。
2 - COM インフラストラクチャが無効なセキュリティ記述子を検出した場合、イベント ログの失敗をログに記録しません。
|
|
DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ起動制限
|
(グループ ポリシー オブジェクト) コンピュータの構成¥Windows の設定
¥ローカル ポリシー¥セキュリティ オプション
|
該当なし
|
未定義
|
SDDL 形式のアクセス制御リスト。このポリシーが存在する場合、上記のレジストリ キー MachineLaunch
Restriction の値を無効にします。
|
|
DCOM : セキュリティ記述子定義言語 (SDDL) でのコンピュータ アクセス制限
|
(グループ ポリシー オブジェクト) コンピュータの構成¥Windows の設定¥セキュリティの設定¥ローカル ポリシー¥セキュリティ オプション
|
該当なし
|
未定義
|
SDDL 形式のアクセス制御リスト。このポリシーが存在する場合、上記のレジストリ キー MachineAccess
Restriction の値を無効にします。
|
TCP/IP
TCP/IP の機能
TCP/IP (伝送制御プロトコル/インターネット プロトコル) は、ネットワーク間の各コンピュータを接続するための一連の標準プロトコルです。TCP/IP により、Windows ベースのコンピュータが、他の Microsoft システムまたは Microsoft 以外のシステムに接続し、情報を共有できるようになります。
この機能の対象ユーザー
TCP/IP を使用してネットワーク経由で情報をやり取りするユーザーはすべて、Windows XP Service Pack 2 に盛り込まれた変更点を理解しておく必要があります。
Windows XP Service Pack 2 でこの機能に追加された新機能
raw ソケット経由のトラフィックの制限
詳細説明
raw IP ソケットは、ごくわずかな Windows アプリケーションで使用されており、アプリケーションが TCP/IP スタックを使用するより少ない整合性およびセキュリティ チェックで TCP/IP パケットを作成するための、業界標準の手段を提供します。Windows の TCP/IP の実装では、raw IP ソケットでのトラフィックの受信は引き続きサポートされています。ただし、raw ソケット経由でのトラフィックの送信機能は、次の 2 つの方法で制限されています。
この変更が重要な理由と軽減される脅威
この変更により、悪意のあるコードによって分散化されたサービス拒否攻撃が作成されたり、偽造パケット、すなわち発信元 IP アドレスを偽造した TCP/IP パケットが送信される可能性が減少します。
不完全な送信 TCP 接続の同時試行数の制限
詳細説明
TCP/IP スタックで、同時に試行できる不完全な送信 TCP 接続の数が制限されるようになりました。上限に達した場合、後続の接続試行はキューに入れられ、一定の率で解決されます。通常の運用では、アプリケーションが有効な IP アドレスで使用可能なホストに接続を試みても、接続率の制限は発生しません。これが発生した場合は、新しいイベントが ID 4226 としてシステムのイベント ログに出力されます。
この変更が重要な理由と軽減される脅威
この変更は、ウイルスやワームなどの悪意のあるプログラムが未感染のコンピュータに広がる速度を抑制するのに役立ちます。悪意のあるプログラムは、一般に、ランダム IP アドレスへの同時接続を開くことによって未感染のコンピュータに到達しようとします。これらのランダム アドレスのほとんどは接続に失敗しますが、コンピュータでこのような現象が集中的に見られる場合は、悪意のあるプログラムによってコンピュータが感染した可能性があることを示します。
動作の相違点
ポート スキャナなどの特定のセキュリティ ツールの動作が遅くなる場合があります。
これらの問題の解決法
失敗した接続試行に関与しているアプリケーションを停止します。
Winsock の自己復旧
詳細説明
Windows のアプリケーション用ネットワーク ソケット機能である Winsock は、階層サービス プロバイダ (LSP) と呼ばれる機構によって拡張できます。Winsock の LSP は、インターネットの保護者による制限や Web コンテンツのフィルタ処理など、実用的な目的に幅広く利用できます。以前のバージョンの Windows XP では、形式の正しくない (バグのある) LSP を削除すると、レジストリ内の Winsock カタログが破損して、結果的にすべてのネットワーク接続が失われる可能性がありました。現在は、このような LSP をユーザーがアンインストールした後、Winsock が自己復旧するようになっています。
この変更が重要な理由と軽減される脅威
ユーザーは、問題のある LSP をシステムから安全に削除できる必要があります。
新しい Winsock Netsh コマンド
詳細説明
Windows XP Service Pack 2 には、次の 2 つの新しい Netsh コマンドが導入されています。
-
netsh winsock reset catalog
このコマンドは、Winsock カタログを既定の構成にリセットします。形式の正しくない LSP がインストールされていてネットワーク接続が失われる結果を招く場合に、これを使用すると便利です。このコマンドの使用により、ネットワーク接続は復元できますが、以前にインストールされていたすべての LSP を再インストールする必要があるため、注意が必要です。
この変更が重要な理由と軽減される脅威
これらのコマンドは、追加の管理機能として、Winsock LSP のメンテナンスやトラブルシューティングに利用できます。また、スクリプトで使用すれば、広範囲にインストールされた形式の正しくない LSP からの回復に役立ちます。
RPC インターフェイスの制限
RPC インターフェイスの制限の機能
Windows XP Service Pack 2 のリモート プロシージャ コール (RPC) サービスには、既定で RPC インターフェイスをセキュリティ保護し、Windows XP の攻撃対象を減らすのに役立つ、いくつかの変更が加えられています。最も重要な変更は、RestrictRemoteClients レジストリ キーが追加されたことです。このキーは、システム上のすべての RPC インターフェイスの動作を変更し、システム上の RPC インターフェイスに対するリモートの匿名アクセスを既定で削除します (ただしいくつかの例外もあります)。その他の変更としては、EnableAuthEpResolution レジストリ キーや、3 つの新しいインターフェイス登録フラグの追加などがあります。
この機能の対象ユーザー
この機能は、RPC アプリケーション開発者を対象としています。システム管理者も、RPC のこの変更について理解しておく必要があります。
Windows XP Service Pack 2 でこの機能に追加された新機能
RestrictRemoteClients レジストリ キー
詳細説明
RpcServerRegisterIf を使用してインターフェイスを登録すると、RPC によって、サーバー アプリケーションはそのインターフェイスへのアクセスを制限できるようになります。通常、この制限にはセキュリティ コールバックが使用されます。RestrictRemoteClients レジストリ キーは、登録済みのセキュリティ コールバックがインターフェイスになくても、RPC にすべてのインターフェイスに対する追加のセキュリティ チェックを実行させます。
名前付きパイプ プロトコル シーケンス (ncacn_np) を使用する RPC クライアントは、このセクションで説明するすべての制限の対象から除外されます。名前付きパイプ プロトコル シーケンスは、重要な下位互換性の問題があるため、既定では制限されません。
RestrictRemoteClients レジストリ キーには、rpcdce.h においてプログラムで制御することも可能な 3 つの DWORD 値のいずれかを設定できます。このキーが存在しない場合、DWORD = 1 (RPC_RESTRICT_REMOTE_CLIENT_DEFAULT) を設定した場合と同じことになります。
キー リファレンス
キー名 : RestrictRemoteClients
種類 : DWORD
ユーザー インターフェイスからの構成 : 可能。このキーは、グループ ポリシー オブジェクト エディタを使用して設定できます。
既定値 : 1
意味 : この値は、Windows XP Service Pack 2 における既定値であり、すべての RPC インターフェイスへのアクセスを制限します。リモートの匿名呼び出しはすべて、RPC ランタイムによって拒否されます。この値は、rpcdce.h における値 RPC_RESTRICT_REMOTE_CLIENT_DEFAULT に相当します。セキュリティ コールバックが登録され、RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH フラグが設定されているインターフェイスには、この制限は適用されません。
値 : 0
意味 : システムは、RPC インターフェイスの制限を無視します。この値は、rpcdce.h における値 RPC_RESTRICT_REMOTE_CLIENT_NONE に相当します。適切な RPC の制限を実行するのは、サーバー アプリケーションになります。この設定は、以前のバージョンの Windows と同じ動作になります。
値 : 2
意味 : すべてのリモートの匿名呼び出しは、例外なく RPC ランタイムによって拒否されます。この値は、rpcdce.h における値 RPC_RESTRICT_REMOTE_CLIENT_HIGH に相当します。この値を設定すると、システムは、RPC を使用してリモートの匿名呼び出しを受信することができなくなります。
この変更が重要な理由と軽減される脅威
呼び出しに認証の実行を要求すれば、比較的低いレベルの認証であっても、インターフェイスへの攻撃は大幅に難しくなります。これは特に、匿名接続を通じてリモートに起動できる、セキュリティ ホールとなるバッファ オーバーランを利用するワーム対策として役に立ちます。
動作の相違点
RPC アプリケーションがリモートの匿名 RPC クライアントからの呼び出しを想定している場合、この変更によってアプリケーションが正常に動作しなくなることがあります。その結果、この値を設定すると、DCOM を使用するアプリケーションが正常に動作しない可能性があります。
UDP や IPX (ncadg_ip_udp、ncadg_ipx) などのコネクションレス型プロトコル経由のセキュア RPC 呼び出しは、接続指向プロトコル経由の呼び出しよりも低レベルのセキュリティを使用するため、これらの呼び出しは常に、このポリシーの目的に対してセキュリティで保護されていないと見なされます。したがって、Windows XP SP2 では、コネクションレス型プロトコル経由の RPC 呼び出しは、既定で失敗します。
コネクションレス型プロトコル経由の RPC クライアント呼び出しを許可するには、RestrictRemoteClients の値を 0 (RPC_RESTRICT_REMOTE_CLIENT_NONE) に設定します。
これらの問題の解決法
これらの問題を解決するには 3 つの方法があります。以下に、望ましい順に記載します。
-
RPC クライアントがサーバー アプリケーションにアクセスするときに、RPC セキュリティを使用することを要求します。これは、セキュリティに対する脅威を軽減する最良の方法です。
-
インターフェイスの登録時に RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH フラグを設定して、そのインターフェイスの認証を免除します。これにより RPC は、そのアプリケーションのインターフェイスへの接続に限り、匿名接続を許可するように構成されます。
-
このレジストリ キーを RPC_RESTRICT_REMOTE_CLIENT_NONE (0) に設定して、RPC に以前のバージョンの Windows と同じ動作を強制します。これにより RPC は、すべてのインターフェイスへの匿名接続を受け入れます。このオプションは、コンピュータ全体のセキュリティを下げることになるので、可能な限り使わないでください。
EnableAuthEpResolution レジストリ キー
詳細説明
リモートから匿名でアクセスでき、既定で Windows XP に登録される RPC インターフェイスは、重大な攻撃対象となります。RPC 自体は、このようなインターフェイスを登録することで、動的なエンドポイントを使用する呼び出しに対してエンドポイント解決を提供する必要があります。
RestrictRemoteClients フラグが追加されたことにより、RPC エンドポイント マッパー インターフェイスは、既定で匿名アクセスができなくなっています。これはセキュリティの大きな強化ですが、エンドポイント解決のタスクを変化させることになります。現在、RPC クライアントは、動的なエンドポイントを使用する呼び出しを試行する場合、最初にサーバー上の RPC エンドポイント マッパーに照会し、どのエンドポイントに接続すべきかを決定します。RPC クライアント呼び出し自体が RPC セキュリティを使用して行われていても、このクエリは匿名で実行されます。
RPC エンドポイント マッパー インターフェイスへの匿名呼び出しは、Windows XP Service Pack 2 では、新しい RestrictRemoteClients キーの既定値によって、既定で失敗するようになっています。そのため、エンドポイント マッパーに認証済みクエリを実行するには、RPC クライアント ランタイムの変更が必要となります。EnableAuthEpResolution キーを設定すると、RPC クライアント ランタイムは、NTLM を使用してエンドポイント マッパーに対する認証を行います。この認証済みクエリは、実際の RPC クライアント呼び出しが RPC 認証を使用している場合のみ実行されます。
この変更が重要な理由
この変更は、RPC クライアントが、Windows XP Service Pack 2 を実行するシステムに動的なエンドポイントを登録している RPC サーバーに対する呼び出しを行えるようにするために必要です。クライアント コンピュータでこのレジストリ キーを設定して、RPC エンドポイント マッパーへの認証済みクエリを実行できるようにしてください。
動作の相違点
このレジストリ キーは、前のセクションで説明した特定のシナリオを実現するために使用されます。このキーを有効にすると、認証済み呼び出しのために実行されるすべての RPC エンドポイント マッパー クエリが、NTLM 認証を使用して実行されます。
グループ ポリシー オブジェクト エディタを使ってこの設定を指定して、コンピュータの構成¥管理用テンプレート¥システム¥リモート プロシージャ コール¥RPC エンド ポイント マッパー クライアント認証にあるグループ ポリシー オブジェクトを構成することもできます。
新しい RPC インターフェイスの登録フラグ
詳細説明
3 つの新しいインターフェイスの登録フラグが作成され、アプリケーション開発者は RPC インターフェイスをより簡単にセキュリティで保護できるようになりました。
-
RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
このフラグを登録すると、呼び出しのセキュリティ設定に関係なく、RPC ランタイムはすべての呼び出しに対して登録済みのセキュリティ コールバックを起動します。このフラグが登録されていない場合、RPC は非認証の呼び出しがセキュリティ コールバックに到達する前に、その呼び出しをすべて拒否します。このフラグは、セキュリティ コールバックが登録されている場合にのみ機能します。
-
RPC_IF_SEC_NO_CACHE
セキュリティ コールバックは、インターフェイスへのアクセスを制限するために、そのインターフェイスに対して登録されます。一般的なセキュリティ コールバックは、クライアントを偽装して、クライアントがそのインターフェイスを呼び出すための十分な権限を持っているかどうかを判定します。あるセキュリティ コールバックを一度パスしたクライアント ID は、通常、同じセキュリティ コールバックを毎回パスすることになります。
RPC ランタイムは、個々のクライアント ID がセキュリティ コールバックをパスしたときにそれを記憶することによって、このパターンを利用し、以降そのクライアントが同じインターフェイスへの呼び出しを行ったときは、セキュリティ コールバックを省略します。この機能は、"セキュリティ コールバック キャッシング" と呼ばれ、Windows 2000 から導入されています。Windows XP Service Pack 2 では、RPC_IF_SEC_NO_CACHE フラグを使用して、特定のインターフェイスのセキュリティ コールバック キャッシングを無効にすることができます。これは、セキュリティ チェックを変更する場合、つまり、以前は許可していたクライアント ID を拒否する場合などに役に立ちます。
この変更が重要な理由
この変更は、RPC アプリケーション開発者が RPC インターフェイスをセキュリティ保護するのに役立つ追加のセキュリティ ツールを提供します。
動作の相違点
これらのフラグを利用しても、既存の Windows XP アプリケーションに影響を与えることも、正常動作を妨げることもありません。これらの新しいフラグの使用は、アプリケーション開発者の裁量に任されます。
Windows XP Service Pack 2 で追加または変更された設定
|
設定名
|
場所
|
既定値
|
設定可能な値
|
|---|
|
Restrict
RemoteClients
|
HKEY_LOCAL_MACHINE
¥ SOFTWARE¥Policies¥ Microsoft¥Windows NT¥RPC
または
(グループ ポリシー オブジェクト)
コンピュータの構成¥管理用テンプレート¥システム¥リモート プロシージャ コール¥認証されていない RPC クライアントの制限
|
1 - 既定値
|
0 - なし
1 - 既定値
2 - 高
|
|
EnableAuthEp
Resolution
|
HKEY_LOCAL_MACHINE
¥SOFTWARE¥Policies ¥Microsoft¥Windows NT¥RPC
または
(グループ ポリシー オブジェクト)
コンピュータの構成¥管理用テンプレート¥システム¥リモート プロシージャ コール¥RPC エンド ポイント マッパー クライアント認証
|
0 - 無効
|
0 - 無効
1 - 有効
|
Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか
Windows XP Service Pack 2 で使用するには、コードの変更が必要になる場合があります。必要なアプリケーションの変更の詳細については、前のセクションで RestrictRemoteClients と EnableAuthEpResolution に関する説明を参照してください。
WebDAV リダイレクタ
WebDAV リダイレクタの機能
WebDAV リダイレクタ (DAVRdr) を使用することにより、Windows XP を実行しているコンピュータは、Windows SharePoint Services や MSN コミュニティのような WebDAV (Web-based Distributed Authoring and Versioning) サーバーを、標準のファイル サーバーであるかのように使用できるようになります。これは、Windows NT のリモート ファイル システム スタックに接続するカーネル コンポーネントと、ファイル システム要求を WebDAV 要求に変換するユーザーレベルのコンポーネント (Web クライアント サービス) から構成されます。
この機能の対象ユーザー
この機能は、リモート ファイル システムを使用して WebDAV サーバーにアクセスするユーザーによって使用されます。WebDAV リダイレクタは、リモート ファイル システム スタックに実装されます。クライアント管理者および各自のコンピュータの資格情報のセキュリティに関心があるユーザーは、WebDAV サーバー上のリモート ファイルに UNC (汎用名前付け規則) (¥¥<サーバー名>¥<共有名>¥File.txt など) でアクセスするたびに、WebDAV リダイレクタによって処理されることを理解しておく必要があります。
Windows XP Service Pack 2 でこの機能に追加された新機能
クリア チャネルでの基本認証の無効化
詳細説明
WebDAV は HTTP (ハイパーテキスト転送プロトコル) の拡張であるため、"基本認証" (BasicAuth) を使用します。BasicAuth はユーザー認証の一形態であり、サーバーがユーザーを識別するための方法です。BasicAuth では、クライアントはユーザーの資格情報 (ユーザー名とパスワード) をサーバーに転送します。通常の HTTP トラフィックなどのようにチャネルが暗号化されていない場合は、ネットワーク上のどのコンピュータからもユーザーのユーザー名とパスワードを見ることができるため、ID が盗まれる可能性があります。DAVRdr は、暗号化された HTTP (HTTPS または SSL) をサポートしていません。サーバーが基本認証をサポートしている場合は、ユーザーの資格情報はクリア テキスト (暗号化されていない状態) で転送されます。サーバーが基本認証を使用するように構成されることはほとんどありませんが、サーバーがユーザーの資格情報を取得するように明示的に設定される可能性はあります。
この可能性があるため、Windows XP Service Pack 2 (SP2) では、DAVRdr による BasicAuth の使用の有効/無効を切り替える機能が追加されました。SP2 では、既定で、BasicAuth の使用は無効になっています。BasicAuth が無効になっている場合、クライアントは、サーバーがサポートしている別の認証方法を使用しない限り、要求に失敗します。
この変更が重要な理由
ユーザーは、パスワードがクリア テキストで送信されることを心配しないで WebDAV サーバーにログオンでき、リモート ファイルにアクセスできます。
軽減される脅威
たとえば、Contoso Corporation の企業ユーザーが、社外のパブリック ネットワーク上のファイル共有である ¥¥Contoso_Server¥Sales に日常的にアクセスし、通常のバックグラウンド操作の一環でその共有にアクセスするアプリケーションを使用しているとします。ユーザーのポータブル コンピュータは企業ネットワーク外にあるため、要求は失敗するはずです。しかし、DAVRdr は、ポータブル コンピュータがアクセスを試行した実際のサーバーが SMB サーバーであったとしても、Contoso_Server という名前の DAV サーバーがあるかどうかを確認する要求を転送します。
攻撃者は、WINS 要求をスプーフィングするコンピュータを使って同じパブリック ネットワークを利用し、WINS 要求に対する応答に自分へのポインタを入れて返すことができます。すると、ユーザーのポータブル コンピュータは、この許可されていないサーバー上の DAV 共有に対してアクセスを試みます。許可されていないサーバーが認証方法として BasicAuth を使用して応答すると、ユーザーには資格情報の入力を求めるダイアログ ボックスが表示されます。ダイアログ ボックスではこのサーバーが Contoso_Server として識別されるため、ユーザーは要求が正当なものであると信じます。ユーザーが各自のユーザー名とパスワードを入力すると、クライアントはその情報をクリア テキストで転送するので、攻撃者はユーザーのログイン情報にアクセスできてしまいます。ユーザーには、チャネルがセキュリティで保護されていないことや、要求が DAVRdr で処理されること、ポータブル コンピュータがユーザー名とパスワードをクリア テキストで転送することなどは、何も知らされません。ただし、現在の Windows の既定の認証方法では、ユーザーのパスワードがクリア テキストで転送されることは決してありません。
動作の相違点
既定の動作に対する変更は DAVRdr にのみ影響するため、基本認証を必要とする場合と DAVRdr を使用する場合のみ、正常に動作しないシナリオが考えられます。たとえば、Notepad.exe を使用して、BasicAuth のみが許可された Web サイトにアクセスする場合などです。このシナリオはうまく行きません。また、サーバーが基本認証のみを使用するように構成されていたとしても、Office などの他のアプリケーションは、別の DAV クライアントを使用するので引き続き機能します。
これらの問題の解決法
次のレジストリ キーを追加し、それをゼロ以外の値に設定することによって、BasicAuth を有効にすることができます。
HKEY_LOCAL_MACHINE¥SYSTEM
¥CurrentControlSet¥Services ¥WebClient¥Parameters¥UseBasicAuth (DWORD)
レジストリ キーを削除するか、0 に設定すると、動作は既定に戻り、BasicAuth の使用は無効になります。
WININET : クリア チャネルでの基本認証の無効化
詳細説明
DAVRdr はリモート ファイル システム スタックの一部であるため、コンピュータはファイルへのリモート アクセスを試行するたびに攻撃にさらされます。インターネット API を使用する他のアプリケーションへの脅威は、DAVRdr に対するものほど深刻ではありませんが、アプリケーション (またはユーザー) が URL にアクセスしようとすると、常に、同様の攻撃の可能性が考えられます。この理由から、WinInet では、インターネット API の他ユーザーに対する BasicAuth を DAVRdr で無効にするための機構を公開しています。
Windows XP Service Pack 2 には、クリア チャネル (暗号化されていないチャネル) での基本認証の使用をブロックするために、次の 2 つの方法が用意されています。
-
次のレジストリ キーを作成し、ゼロ以外の値に設定する。
HKEY_CURRENT_USER¥SOFTWARE¥Microsoft¥Windows ¥CurrentVersion¥ Internet Settings¥DisableBasicOverClearChannel (DWORD)
これにより、チャネルがセキュリティで保護されている場合 (HTTPS または SSL) を除き、WININET が BasicAuth を使用することを防ぐことができます。
この変更が重要な理由
ユーザーは、パスワードがクリア テキストで送信されることを心配しないで WebDAV サーバーにログオンでき、リモート ファイルにアクセスできます。
軽減される脅威
http://www.contoso.com/sales のWeb サイトに日常的にアクセスしている企業ユーザーがいると仮定します。ユーザーは、社外のパブリック ネットワークから、Internet Explorer を使用してこのサイトへのアクセスを試みます。ラップトップは社外にあるため、要求は失敗し、"サーバーが見つかりません" というメッセージが表示されます。攻撃者は WINS 要求をスプーフィングするコンピュータを使って同じパブリック ネットワークを利用し、WINS 参照に対する応答に自分へのポインタを入れて返すことができます。すると、ラップトップは、許可されていないサーバーからページを読み込むための HTTP 要求を送信しようとします。許可されていないサーバーが認証方法として BasicAuth を使用して応答すると、ラップトップはユーザーに資格情報をたずねます。ラップトップではこのサイトが http://www.contoso.com/sales であると識別されるため、ユーザーは要求が正当なものであると信じます。ユーザーが各自のユーザー名とパスワードを入力すると、クライアントはその情報をクリア テキストで転送するので、攻撃者はユーザーのログイン情報にアクセスできてしまいます。特に、ユーザーには、チャネルがセキュリティで保護されていないことや、ラップトップ コンピュータがユーザー名とパスワードをクリア テキストで転送することなどは、何も知らされません。
動作の相違点
既定では、前述の DAVRdr 以外、WININET アプリケーションの動作には変更はありません。この設定を無効にすると、ユーザーは基本認証しかサポートしていない HTTP サーバーには接続できなくなります。
Windows XP Service Pack 2 で追加または変更された設定
|
設定名
|
場所
|
以前の既定値 (存在する場合)
|
既定値
|
設定可能な値
|
|---|
|
UseBasicAuth
|
HKEY_LOCAL_MACHINE
¥System ¥CurrentControlSet ¥Services ¥WebClient ¥Parameters ¥UseBasicAuth
|
該当なし
|
キーは存在しません。
(BasicAuth は DAVRdr では無効)
|
0、またはゼロ以外
|
|
DisableBasicOver
ClearChannel
|
HKCU¥SOFTWARE ¥Microsoft ¥Windows ¥CurrentVersion ¥Internet Settings ¥DisableBasicOver
ClearChannel
|
該当なし
|
キーは存在しません。(BasicAuth は他のすべてに対して有効)
|
0、またはゼロ以外
|
Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか
変更は必要ありません。インターネット API を使用するアプリケーションで、DAVRdr のように BasicAuth を無効にする場合は、InternetSetOptions() への呼び出しを追加することができます。
Windows ファイアウォール
Windows ファイアウォールの機能
Windows ファイアウォール (以前はインターネット接続ファイアウォールまたは ICF と呼ばれていました) は、Microsoft Windows XP 向けの、ソフトウェアベースのステートフル フィルタ ファイアウォールです。Windows ファイアウォールは、TCP/IP バージョン 4 (IPv4) および TCP/IP バージョン 6 (IPv6) を介した、要求していない着信接続を禁止することにより、ネットワークに接続されるコンピュータを保護します。以下の構成オプションがあります。
-
ポートベースの例外の構成と有効化
-
プログラムベースの例外の構成と有効化
-
基本 ICMP オプションの構成
-
削除されたパケットと成功した接続のログ
この機能の対象ユーザー
この機能は、以下のものに対して適用されます。
-
インターネットなどのネットワークに接続されるすべてのコンピュータ
-
ネットワーク上でリッスンするすべてのプログラム (アプリケーションとサービス)
-
ステートフル フィルタに対応していないすべてのプログラム
Windows XP Service Pack 2 でこの機能に追加された新機能
既定で有効
詳細説明
Windows ファイアウォールは、既定ですべてのネットワーク インターフェイスに対して有効に設定されます。したがって、新しいインストールやアップグレードを行う際、Windows XP では既定でネットワーク保護が強化されます。既定で有効であることにより、システムに追加される新しいネットワーク接続も保護されます。これは IPv4 と IPv6 の両方のトラフィックに適用され、システム上に別のファイアウォールが既に存在していても有効になります。
この変更が重要な理由と軽減される脅威
Windows XP Service Pack 2 より前にリリースされた Windows XP では、インターネット接続ファイアウォールは既定で無効に設定されていました。ユーザーは、ウィザードを実行するか [ネットワーク接続] フォルダに移動して、Windows ファイアウォールを手動で有効にする必要がありました。これは多くのユーザーには難しすぎたため、多数のコンピュータにファイアウォール保護機能が導入されませんでした。
Windows ファイアウォールを既定で有効にすることにより、ネットワークベースの多くの攻撃からコンピュータがより強力に保護されます。たとえば、Windows ファイアウォールが既定で有効になっていれば、ユーザーが最新の更新プログラムを適用しているかどうかに関わらず、最近の MSBlaster 攻撃の影響は大幅に軽減されます。
動作の相違点
Windows XP Service Pack 2 をインストールすると、Windows ファイアウォールは既定で有効になります。これにより、既定でステートフル フィルタに対応していないアプリケーションの場合には、アプリケーションの互換性の問題が生じる可能性があります。
これらの問題の解決法
アプリケーションを Windows ファイアウォールに対応させるための変更については、このドキュメントで後述する「Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか」で詳しく説明します。
起動時のセキュリティ
詳細説明
以前のバージョンの Windows では、ネットワーク スタックが起動してから、インターネット接続ファイアウォールによる保護が開始されるまでに時間差がありました。その結果、サービスとのパケットの送受信がインターネット接続ファイアウォールでフィルタ処理されずに行われる可能性があり、潜在的にコンピュータの脆弱性が存在していました。これは、ファイアウォールのユーザーモード サービスが読み込まれ、適切なポリシーが適用されるまで、ファイアウォール ドライバがフィルタ処理を開始しなかったことに起因します。ファイアウォール サービスには依存関係が多数存在します。その依存関係がクリアされるまで、サービスは待機状態になり、ポリシーがドライバに適用されません。この時間の間隔は、コンピュータの速度に基づいています。
Windows XP Service Pack 2 では、IPv4 および IPv6 のファイアウォール ドライバに、ステートフルなフィルタ処理を実行するための静的なルールがあります。この静的なルールは、"起動時ポリシー" と呼ばれます。これにより、コンピュータは DNS や DHCP などの基本的なネットワーク タスクを実行し、ドメイン コントローラと通信してポリシーを取得できるようになります。Windows ファイアウォール サービスが実行されると、実行時ポリシーが読み込まれて適用され、起動時フィルタが削除されます。起動時ポリシーを構成することはできません。
Windows ファイアウォール サービス (サービス コントロール マネージャに "Windows Firewall/Internet Connection Sharing (ICS)" として一覧表示されます) を停止し、[手動] または [無効] に設定した場合は、起動時のセキュリティは確保されません 。
この変更が重要な理由と軽減される脅威
この変更により、コンピュータが、起動時およびシャットダウン時に攻撃を受ける可能性は減少します。
動作の相違点
Windows ファイアウォール サービスが起動に失敗すると、起動時セキュリティが有効なままになります。これは、すべての着信接続がブロックされることを意味しています。この場合、リモート デスクトップで使用されるポートも含め、すべてのポートが閉じられるため、管理者はこの問題のトラブルシューティングをリモートで行うことはできません。
これらの問題の解決法
起動時のセキュリティを無効にするには、Windows ファイアウォール/インターネット接続の共有 (ICS) サービスを停止し、そのスタートアップの種類を [手動] または [無効] に設定します。
ファイアウォール サービスが開始されていないためにコンピュータが起動時セキュリティ モードで実行されている場合、管理者は、コンソールにログオンして障害の原因を解決し、ファイアウォール サービスを手動で開始する必要があります。
グローバルな構成
詳細説明
以前のバージョンの Windows では、ファイアウォールはインターフェイスごとに構成されていました。つまり、各ネットワーク接続には、ワイヤレス用の設定、イーサネット用の設定というように、それぞれ個別のファイアウォール設定のセットが存在していたということです。そのため、接続間でファイアウォール設定を同期することは困難でした。また、新しい接続には、既存の接続に適用された構成変更が何も反映されませんでした。ISP によって構成されたダイヤルアップ ネットワーク接続など、専用ダイヤラによって作成された接続を含め、非標準のネットワーク接続も保護できませんでした。
グローバル構成を使用すれば、構成変更が生じるたびに、その変更が Microsoft 以外のダイヤラを含む [ネットワーク接続] フォルダ内のすべてのネットワーク接続に自動的に適用されます。新しい接続が作成されると、構成はそれにも同様に適用されます。構成は、インターフェイスごとに行うことも可能です。非標準のネットワーク接続には、グローバル構成だけが適用されることになります。構成の変更は、IPv4 と IPv6 の両方にも適用されます。
この変更が重要な理由
グローバル ポリシーにより、ユーザーがすべてのネットワーク接続にわたってファイアウォール ポリシーを容易に管理でき、グループ ポリシーを使用した構成も可能になります。また、1 つの構成オプションで、複数のアプリケーションを任意のインターフェイスに対応させることもできます。
動作の相違点
以前のバージョンの Windows では、ファイアウォール構成はインターフェイスごとに行われていました。Windows XP Service Pack 2 では、構成はグローバルなものであり、IPv4 と IPv6 の両方に適用されます。
これらの問題の解決法
アプリケーションまたはサービスで静的に開くことが要求される場合は、このドキュメントで後述する「Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか」で説明するように、ポートをグローバルに開く必要があります。
例外のトラフィック スコーピング
詳細説明
ICF では、例外として設定されたトラフィックが任意の IPv4 アドレスから着信することを許可していました。Windows XP Service Pack 2 の Windows ファイアウォールでは、直接到達可能なアドレスからのみ着信トラフィックを許可する ([ユーザーのネットワーク (サブネット) のみ] のスコープ オプション) か、または特定の IPv4 アドレスと特定の IPv4 アドレス範囲からの着信トラフィックを許可する ([カスタムの一覧] のスコープ オプション) よう、例外を構成することもできます。
NetShare アプリケーション プログラミング インターフェイス (API)、[ネットワーク セットアップ ウィザード]、または Windows ファイアウォールのユーザー インターフェイスを介して [ファイルとプリンタの共有] の組み込み例外を有効にした場合、既定の着信方向のファイルとプリンタの共有接続要求は、直接到達可能なアドレスからの要求のみ許可されます。
ワークグループ内のコンピュータの場合、既定では、一部の例外が、ローカルに到達可能なアドレスに制限されます。これらの例外は、ファイルとプリンタの共有、およびユニバーサル プラグ アンド プレイ (UPnP™) フレームワークに必要なものです。また、これらの例外は、インターネット接続の共有のホスト上にあるローカルに到達可能なアドレスに対して開いているときは、ICS パブリック インターフェイス上では開きません。これらの例外を考えられるすべてのアドレスに対して有効にすれば、ICS パブリック インターフェイス上でも開きますが、この操作は推奨されません。
ローカル ネットワーク上の通信に使用するすべての例外には、ローカルに到達可能なアドレスの制限を適用することをお勧めします。これは、Windows ファイアウォール Netsh Helper または Windows ファイアウォール ユーザー インターフェイスを使用して、プログラムによって実行することができます。
この変更が重要な理由と軽減される脅威
アプリケーションによっては、ローカル ネットワーク上の他のホストとのみ通信し、インターネット上のホストとは通信する必要がないものがあります。ローカルに到達可能なアドレスから、またはローカルに到達可能なサブネットに対応する特定のアドレス範囲からのトラフィックのみを許可するよう Windows ファイアウォールを構成すると、要求していない着信トラフィックを許可する送信元アドレスのセットが制限されます。これにより、有効化された例外に対して起こりうる攻撃が減少します (ただし、完全になくなるわけではありません)。
動作の相違点
ワークグループのメンバであるコンピュータで [ファイルとプリンタの共有] の組み込み例外を有効にすると、4 つのポートが、ローカルに到達可能なアドレスの制限の影響を受けます。以下のポートは、ローカルに到達可能なアドレスからのトラフィックのみを受け取ります。
-
UDP ポート 137
-
UDP ポート 138
-
TCP ポート 139
-
TCP ポート 445
アプリケーションやサービスでもこれらのポートを使用する場合、そのアプリケーションまたはサービスは、ローカルに到達可能なアドレスが割り当てられている他のノードとだけ通信できるようになります。
UPnP フレームワークを有効にすると、次の 2 つのポートがローカルに到達可能なアドレスの制限の影響を受け、ローカルに到達可能なアドレスからのトラフィックのみを受信するようになります。
-
UDP ポート 1900
-
TCP ポート 2869
これらの問題の解決法
この制限を使用するとアプリケーションまたはサービスが機能しない場合は、このドキュメントで後述する「Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか」で説明するように、グローバル接続用のポートを開く必要があります。
コマンドラインのサポート
詳細説明
Windows ファイアウォール Netsh Helper は、Advanced Networking Pack for Windows XP で導入されました。このヘルパーは、IPv6 Windows ファイアウォールにのみ適用されます。Windows XP Service Pack 2 では、ヘルパーの構造と構文が変更され、Ipv4 の構成もサポートするように拡張されています。Netsh Helper を使用すると、以下のものを含め、Windows ファイアウォールの完全な構成が可能になります。
この変更が重要な理由
コマンドライン インターフェイスが提供されたことにより、管理者は、グラフィック ユーザー インターフェイスを使わずに、Windows ファイアウォールを構成できるようになりました。コマンドライン インターフェイスは、ログイン スクリプトおよびリモート管理で使用できます。
動作の相違点
Advanced Networking Pack for Windows XP で提供された Netsh Helper で作成したスクリプトは機能しなくなるため、更新する必要があります。
"例外を許可しない" 操作モード
詳細説明
Windows ファイアウォールでは、通常の使用時に、要求していない特定の着信トラフィックを許可するように例外が構成されることがあります。これは通常、ファイルとプリンタの共有などの重要なシナリオを実現する必要性によって生じます。コンピュータで実行されている 1 つ以上のリッスン サービスまたはアプリケーションにセキュリティ上の問題が見つかった場合は、コンピュータを "例外を許可しない" と呼ばれるクライアント専用モードに切り換えることが必要となる場合があります。このクライアント専用モードに切り換えると、Windows ファイアウォールは、要求していないすべての着信トラフィックを回避するよう構成されます。ファイアウォールの再構成は必要ありません。
このモードのときは、すべての例外が一時的に無効になり、既存のいかなる接続も切断されます。例外を作成するための Windows ファイアウォールへの API 呼び出しはすべて許可され、要求されたファイアウォール構成は格納されますが、操作モードが通常のモードに戻るまで、この構成は有効になりません。アプリケーションからのリッスン要求もすべて無視されます。
この変更が重要な理由と軽減される脅威
ウイルス、ワーム、攻撃者は、セキュリティ上の弱点を突くことのできるサービスを探します。この操作モードにすることで、Windows ファイアウォールは、この種の攻撃が成功することを防ぐのに役立ちます。
動作の相違点
この操作モードでは、コンピュータはネットワークから送られる要求をリッスンできません。既存の着信接続はすべて終了します。正常に実行されるのは送信接続のみです。
これらの問題の解決法
この操作モードでは、厳格なネットワーク セキュリティが実現されるため、一部の機能が失敗する可能性があります。操作モードを既定の状態である "有効" に戻すことにより、機能を復元することができます。この操作は、コンピュータのセキュリティ レベルを低下させることになるので、脅威を特定し、軽減したうえでのみ行うようにしてください。
プログラムベースの例外
詳細説明
一部のプログラム (アプリケーションまたはサービス) は、ネットワーク クライアントとサーバーの両方の機能を果たします。サーバーとして機能する場合、前もってピアを識別できないので、要求されない着信トラフィックを許可する必要があります。
以前のバージョンの Windows では、プログラムでファイアウォール API を呼び出して、必要なリッスン ポートを開くことができるようにする必要がありました。これは、あらかじめポートを識別できない場合、ピア ツー ピアの状況では明らかに困難です。通信が完了したらポートを再度閉じるかどうかは、プログラム次第でした。プログラムが予期せず終了した場合に、ファイアウォールに不必要なホールが残ることになります。
また、これらのポートは、プログラムがローカル管理者のセキュリティ コンテキスト内で実行されている場合にしか開くことができませんでした。そのため、プログラムを管理コンテキストで実行する必要があり、最小限必要な特権だけで実行するという最小限の特権の原則に違反していました。
Windows XP Service Pack 2 では、ネットワークをリッスンする必要があるプログラムを、Windows ファイアウォールの例外の一覧に追加することができます。プログラムが Windows ファイアウォールの例外の一覧に含まれている場合は、プログラムのセキュリティ コンテキストに関係なく、必要なリッスン ポートが自動的に開閉します。Windows ファイアウォールの例外の一覧にプログラムを追加することに関する詳細については、このドキュメントで後述する「これらの問題の解決法」を参照してください。
注 ステートフル フィルタに対応しているプログラムは、Windows ファイアウォールの例外の一覧に追加する必要はありません。Windows ファイアウォールの例外の一覧にプログラムを追加できるのは、管理者だけです。
この変更が重要な理由と軽減される脅威
プログラムが Windows ファイアウォールの例外の一覧に含まれている場合は、必要なポートだけが開きます。これらのポートは、プログラムがリッスンしている間のみ開かれています。意図的であれ偶然であれ、使用されていないポートから別のプログラムまたはサービスがネットワーク トラフィックに公開される可能性があるので、プログラムは、使用されていないポートを開くことはできません。
また、ネットワークをリッスンしているプログラムを、低い特権を持つアカウントで実行することも可能です。以前のバージョンの Windows では、このようなプログラムを実行するには管理者権限が必要でした。
動作の相違点
ネットワークをリッスンする必要があるプログラムは、Windows ファイアウォールの例外の一覧に含まれている必要があります。そうでない場合は、Windows ファイアウォールで必要なポートは開かれず、プログラムは要求していない着信トラフィックを受け取ることはできません。
これらの問題の解決法
プログラムは、次の 5 つの方法で Windows ファイアウォールの例外の一覧に追加できます。
-
プログラム。 独立系ソフトウェア ベンダ (ISV) の場合は、インストール時にプログラムを Windows ファイアウォールの例外の一覧に入れることをお勧めします。プログラムによって例外を追加する方法の詳細については、このドキュメントで後述する「Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか」を参照してください。
-
コマンドライン インターフェイス。 スクリプトや他のコマンドライン ツールを使用して Windows XP システムを管理する IT 管理者は、この方法を使用できます。
-
グループ ポリシーの設定。 この方法は、IT 管理者がグループ ポリシーによってプログラムを例外の一覧に追加する場合に使用できます。
-
Windows セキュリティの警告の通知メッセージ。 管理者権限を持つユーザーは、Windows セキュリティの警告の通知メッセージと対話することによって、アプリケーションを例外の一覧に追加できます。
アプリケーションが、ワイルドカードでないポートの TCP リッスンまたは UDP バインドを行う場合は、ネットワーク スタックによってアプリケーション名とポートが Windows ファイアウォールに渡されます。Windows ファイアウォールは、例外の一覧でそのアプリケーション名を探します。アプリケーションが例外の一覧にあり、有効になっていれば、対応するポートがファイアウォール内で開きます。アプリケーションが例外の一覧にあっても、無効になっている場合は、対応するポートは開きません。アプリケーションが例外の一覧にない場合は、ユーザーが選択するよう求められます。管理者権限を持つユーザーは、以下のことを実行できます。
-
アプリケーションのブロックを解除して、ネットワークでのリッスンを許可する。アプリケーションが例外の一覧に有効として追加され、ポートが開きます。
-
アプリケーションのネットワークでのリッスンをブロックする。アプリケーションが例外の一覧に無効として追加されます。ポートは開きません。ローカルの管理者が [例外] タブで例外を有効にしていない限り、アプリケーションに対する要求していない着信トラフィックはブロックされます。例外の一覧にアプリケーションを追加することにより、アプリケーションが実行されるたびに Windows ファイアウォールがユーザーに確認を求めることはなくなります。
-
後で選択できるようにする。アプリケーションは例外の一覧に追加されず、ポートも開きません。
管理者権限のないユーザーには、このアプリケーションのネットワークでのリッスンが許可されておらず、管理者がアプリケーションを有効にする必要があることが通知されます。この時点では、アプリケーションは例外の一覧に無効として追加されています。
-
手動による構成。 ユーザーは、手動でプログラムを有効にすることができます。[スタート] メニューに表示されるアプリケーションの一覧から選択するか、またはプログラムを参照して選択できます。
複数のプロファイル
詳細説明
Windows ファイアウォールは複数のプロファイルをサポートしているので、コンピュータが管理されたネットワークに接続しているときに適用するものと、そうでないときに適用するものという 2 つのファイアウォール ポリシーのセットを作成できます。コンピュータが企業ネットワークに接続しているときには、一連のビジネス アプリケーションが動作するように、より緩やかな設定を指定できます。また、コンピュータが管理されたネットワークに接続していないときは、より積極的なセキュリティ ポリシーを指定して、モバイル ユーザーの保護の強化に役立てることができます。
注 Windows ファイアウォールの複数のプロファイルは、ドメインに参加しているコンピュータにのみ適用されます。ワークグループ内のコンピュータには、1 つのプロファイルだけが適用されます。
この変更が重要な理由と軽減される脅威
モバイル コンピュータには、複数のファイアウォールを構成することが望ましいと言えます。企業ネットワークでは安全な構成でも、インターネット上では攻撃を受けやすいということはよくあります。したがって、いつでも必要なポートしか公開しないようにするには、企業ネットワーク上ではポートを開き、他のネットワーク上では開かないようにできることが、必要不可欠となります。
動作の相違点
アプリケーションを正常に実行するために Windows ファイアウォールの例外の一覧に追加する必要がある場合、2 つのプロファイルに同じポリシー セットが設定されていないために、アプリケーションがどちらのネットワークでも動作しないことがあります。アプリケーションをすべてのネットワークで動作させるためには、両方のプロファイルで一覧に追加する必要があります (Windows ファイアウォールの例外の一覧の詳細については、前のセクションを参照してください)。
これらの問題の解決法
コンピュータがドメインに参加している場合、アプリケーションは両方のファイアウォール構成において一覧に追加されている必要があります。
システム サービスに対する RPC のサポート
詳細説明
以前のバージョンの Windows では、インターネット接続ファイアウォールによってリモート プロシージャ コール (RPC) 通信がブロックされていました。インターネット接続ファイアウォールでは、RPC エンドポイント マッパーへのネットワーク トラフィックを許可するように構成できましたが、RPC に使用されるポートが認識されないため、アプリケーションは失敗していました。
RPC でネットワーク経由の通信が許可されていない場合、エンタープライズ アプリケーションやコンポーネントの多くは失敗します。以下はその一例です。
-
コンピュータ管理機能、多くのアプリケーションが使用する [ユーザー、コンピュータまたはグループの選択] ダイアログ ボックスなどのリモート管理
-
リモート Windows Management Instrumentation (WMI) 構成
-
リモート クライアントとサーバーを管理するスクリプト
RPC は、いくつかのポートを開き、多数の異なるサーバーをそれらのポート上で公開します。Windows XP には非常に多数の RPC サーバーが含まれているため、Windows ファイアウォールは、RPC を使用するシステム サービスに対して別のアプローチを採用しています。Windows ファイアウォールは、呼び出し元がローカル システム、ネットワーク サービス、またはローカル サービスのセキュリティ コンテキストで実行されている場合のみ、この要求を受け入れます。
この変更が重要な理由と軽減される脅威
リモート管理に関するシナリオを実現するために、多くの企業規模の展開では、RPC を使用するシステム サービスが既定で Windows ファイアウォールに対応していることが必要です。より精度の高い設定を使用することで、どの RPC サービスをネットワークに公開するかを制御できます。
動作の相違点
既定では、RPC は Windows ファイアウォール経由では機能しません。RPC を使用するすべてのシステム サービスが影響を受けます。ただし、Windows ファイアウォールは、これらのサービスに RPC を使用できるように構成することができます。
これらの問題の解決法
このドキュメントで後述する「Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか」を参照してください。
既定値の復元
詳細説明
これまでは、ユーザーが Windows ファイアウォールの構成をリセットする手段はありませんでした。時間の経過と共に、Windows ファイアウォールの例外の一覧にアプリケーションまたはポートが追加されていき、要求していない着信トラフィックを許可するように Windows ファイアウォールが構成されるようになります。そのため、ユーザーが簡単かつ迅速に既定の構成に戻すことが困難な場合もあります。
このオプション (Netsh Helper の reset コマンドを使用) により、ユーザーは Windows ファイアウォール設定を元の既定値に復元することが可能となります。また、Windows ファイアウォールの既定の設定は、OEM や各企業が提供するカスタムの既定構成オプションで変更することが可能です。
この変更が重要な理由
このオプションにより、エンド ユーザーは Windows ファイアウォールの設定を工場出荷時の既定値に戻すことができます。
動作の相違点
この追加に伴う Windows ファイアウォールの機能の変更はありません。ただし、この機能を使用すると、インターネット接続の共有とネットワーク ブリッジは無効になります。
無人セットアップのサポート
詳細説明
以前のバージョンの Windows では、インストール中にインターネット接続ファイアウォールを構成することはできませんでした。そのため、OEM や各企業では、コンピュータをエンド ユーザーに配布する前に、インターネット接続ファイアウォールを前もって構成しておくことが困難でした。Windows XP Service Pack 2 では、無人セットアップを使用して、Windows ファイアウォールの以下のオプションを構成できます。
この変更が重要な理由
Windows ファイアウォールを事前に構成できるようになったことで、Windows の再販業者や大規模な企業は、Windows ファイアウォールに関してより広範囲な柔軟性とカスタマイズ オプションを実現することができます。
動作の相違点
この機能により、Windows ファイアウォールをより柔軟に構成できます。これに伴う Windows ファイアウォールの機能の変更はありません。
Windows XP Service Pack 2 で変更された既存機能
マルチキャストおよびブロードキャスト サポートの強化
詳細説明
マルチキャストおよびブロードキャスト ネットワーク トラフィックは、未知のホストから応答を受け取るという点で、ユニキャスト トラフィックと異なります。そのため、ステートフル フィルタによって、応答の受け入れは拒否されます。これにより、ストリーミング メディアから検出まで、さまざまなシナリオが動作しなくなります。
このようなシナリオを有効にするために、Windows ファイアウォールは、マルチキャストまたはブロードキャスト トラフィックの送信元である同じポート上のどの送信元アドレスからのユニキャスト応答でも 3 秒間は許可します。
この変更が重要な理由と軽減される脅威
ユーザー、アプリケーション、またはサービスでファイアウォール ポリシーを変更しなくても、マルチキャストおよびブロードキャストを使用して通信を行うアプリケーションやサービスは正常に機能します。これは、NETBIOS over TCP/IP などには重要であり、ポート 135 などの危険性の高いポートは公開されないようになります。
動作の相違点と依存関係の存在
以前のバージョンの Windows では、インターネット接続ファイアウォールによるマルチキャストまたはブロードキャストのフィルタ処理は行われませんでした。Windows XP Service Pack 1 では、インターネット接続ファイアウォールでマルチキャストおよびブロードキャスト トラフィックがステートフルにフィルタ処理されるようになりましたが、そのために、ユーザーは、応答を受信するポートを手動で開く必要がありました。Service Pack 2 では、追加の構成を行わなくても、Windows ファイアウォールでマルチキャストまたはブロードキャスト トラフィックへの応答を受け入れることができます。
インターネット接続ファイアウォールと IPv6 Windows ファイアウォールの統合
詳細説明
Windows XP で導入されたバージョンのインターネット接続ファイアウォールでは、IPv4 トラフィックのみをフィルタ処理していました。IPv6 インターネット接続ファイアウォールは、Advanced Networking Pack for Windows XP で導入されたものです。これら 2 つのファイアウォールが個別に存在していた当時は、それぞれに固有の構成オプションが使用されていました。Windows XP Service Pack 2 では、インターネット接続ファイアウォールと IPv6 インターネット接続ファイアウォールが、Windows ファイアウォールと呼ばれる 1 つのコンポーネントに統合されています。
この変更により、構成の変更はすべて IPv4 と IPv6 の両方のトラフィックに適用されるようになりました。たとえば、静的ポートを開くと、そのポートは IPv4 と IPv6 の両方のトラフィックに対して開かれます。
この変更が重要な理由
これによって、構成管理とアプリケーション互換性維持が容易になります。
動作の相違点
個別のコンポーネントだった IPv6 ファイアウォール サービスは、システムから削除され、IPv4 と IPv6 の両方のトラフィックをフィルタ処理する Windows ファイアウォール サービスに置き換わっています。Advanced Networking Pack for Windows XP で導入された API はすべて、Windows XP Service Pack 2 で導入された新しい API に置き換えられます。
これらの問題の解決法
詳細については、このドキュメントで後述する「Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか」を参照してください。
更新された Netsh Helper
詳細説明
Netsh Helper のファイアウォール コンテキストは、Advanced Networking Pack for Windows XP で初めて導入されました。これは、IPv6 Windows ファイアウォールにのみ適用されていました。Windows ファイアウォールと IPv6 Windows ファイアウォールの統合により、Netsh Helper のファイアウォール コンテキストには、IPv6 コンテキストが含まれなくなりました。
この変更が重要な理由
この変更は、Windows ファイアウォールへの変更と、既存の Netsh Helper のファイアウォール コンテキストにおける IPv4 フィルタ構成オプションの統合に対応するためのものです。
動作の相違点
Advanced Networking Pack の付加に伴い導入されたファイアウォール コンテキストを使用する既存のスクリプトは、機能しなくなります。
これらの問題の解決法
新しいファイアウォール コンテキストと構文が含まれるように、既存のすべてのスクリプトを更新します。
更新されたユーザー インターフェイス
詳細説明
Windows XP Service Pack 2 では、Windows ファイアウォールのユーザー インターフェイスが更新され、新しい構成オプションと、統合された IPv6 インターネット接続ファイアウォールに対応するようになっています。これにより、ユーザーは、操作状態、グローバル構成、ログ オプション、および ICMP オプションを変更できます。
ユーザー インターフェイスへの主な入口は、接続の [プロパティ] ダイアログ ボックスからコントロール パネル アイコンに移動しました。古い場所からのリンクも提供されています。また、Windows XP Service Pack 2 では、[ネットワーク接続] フォルダからのリンクも作成されます。
この変更が重要な理由
Windows XP Service Pack 2 で追加された機能では、ユーザー インターフェイスの更新が必要でした。
動作の相違点
ユーザー インターフェイスは、ネットワーク接続の [プロパティ] ダイアログ ボックスにある [詳細設定] タブから、コントロール パネルに個別に表示される [Windows ファイアウォール] アイコンに移動しています。
新しいグループ ポリシーのサポート
詳細説明
以前のバージョンの Windows では、インターネット接続ファイアウォールのグループ ポリシー オブジェクト (GPO) は、"DNS ドメイン ネットワーク上でのインターネット接続ファイアウォールの使用を禁止する" の 1 つだけでした。Windows XP Service Pack 2 では、すべての構成オプションをグループ ポリシーを通じて設定できます。新しく追加された構成オプションには、以下のものがあります。
-
プログラムの例外を定義する
-
ローカル プログラムの例外を許可する
-
ICMP の例外を許可する
-
通知を禁止する
-
ファイルとプリンタの共有の例外を許可する
-
ログの記録を許可する
これらのオブジェクトは、それぞれ企業および標準の両方のプロファイルで設定できます。グループ ポリシー オプションの完全な一覧については、Microsoft ダウンロード センターの「Microsoft® Windows® XP Service Pack 2 向け Windows ファイアウォール設定の導入」(http://go.microsoft.com/fwlink/?linkid=23277) を参照してください。
この変更が重要な理由
管理者にとっては、Windows ファイアウォール ポリシーを管理して、アプリケーションおよびシナリオが企業環境で動作できるようにすることが重要です。
動作の相違点
IT 管理者が既定の Windows ファイアウォール ポリシー セットを決めることができるようになりました。これにより、アプリケーションおよびシナリオを使用可能または使用不可とすることができます。制御範囲は広がりますが、ポリシーによって Windows ファイアウォールの基盤となる機能が変更されることはありません。
Windows XP Service Pack 2 で追加または変更された設定
|
設定名
|
場所
|
以前の既定値
|
既定値
|
設定可能な値
|
|---|
|
ネットワーク接続をすべて保護する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
例外を許可しない
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
プログラムの例外を定義する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
プログラム パス
スコープ
|
|
ローカル プログラムの例外を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
リモート管理の例外を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
ファイルとプリンタの共有の例外を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
ICMP の例外を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
エコー要求 : オン、オフ
発信元の抑制 : オン、オフ
リダイレクト : オン、オフ
到達不可の宛先 : オン、オフ
ルーター要求 : オン、オフ
超過時間 : オン、オフ
パラメータの問題 : オン、オフ
マスク要求 : オン、オフ
タイムスタンプ要求 : オン、オフ
|
|
リモート デスクトップの例外を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
UPnP フレームワークの例外を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
通知を禁止する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
ログの記録を許可する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
|
マルチキャストまたはブロードキャスト要求に対するユニキャスト応答を禁止する
|
(グループ ポリシー オブジェクト) コンピュータの構成¥管理用テンプレート¥ネットワーク¥ネットワーク接続¥Windows ファイアウォール¥[ドメイン | 標準] プロファイル
|
該当なし
|
構成されません
|
有効
無効
|
Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか
送信接続
説明
典型的なユーザーとオフィス コンピュータにおいては、コンピュータはネットワーク上のクライアントです。コンピュータ上のソフトウェアは、サーバーに向けて接続 (送信接続) し、サーバーから応答を受信します。Windows ファイアウォールは、すべての送信接続を許可しますが、コンピュータで受け入れることを許可される通信の種類にはルールを適用します。伝送制御プロトコル (TCP) およびユーザー データ プロトコル (UDP) 送信接続の一部として Windows ファイアウォールが許可するネットワーク トラフィックについては、下記の「注」を参照してください。
必要な操作
ありません。Windows ファイアウォールは、プログラムおよびユーザー コンテキストに関係なく、すべての送信接続を自動的に許可します。
注
-
あるコンピュータが、対象となるコンピュータに対して TCP セッション要求を開始すると、その対象コンピュータからの応答のみを受け入れます。
-
コンピュータが UDP パケットを送信すると、Windows ファイアウォールは、その UDP パケットの送信元ポートへの、すべての IP アドレスからの UDP 応答を 90 秒間許可します。
-
マルチキャストおよびブロードキャスト トラフィックに対するユニキャスト応答は、その応答がマルチキャスト トラフィックの送信元ポート宛てのものであり、かつそのコンピュータと同じサブネット上の IP アドレスからのものであれば、Windows ファイアウォールで 3 秒間許可されます。この動作は、ファイアウォール設定によって制御されますが、これは既定で有効になっています。
例
-
Microsoft Internet Explorer を使用した Web サーフィン
-
Outlook Express での電子メールのチェック
-
MSN Messenger または Windows Messenger でのチャット
アプリケーションに対する、要求していない着信接続
説明
このシナリオには、TCP ソケット上でリッスン操作を実行するアプリケーション、または Winsock を使用して特定の UDP ソケットに正常にバインドするアプリケーションが該当します。このシナリオでは、Windows ファイアウォールは、アプリケーション側の必要に応じて自動的にポートを開閉できます。
必要な操作
1 つまたは複数のポートでリッスンするアプリケーションが管理者によってインストールされる際、ユーザーは、アプリケーションがファイアウォール内でポートを開くことを許可するかどうかを示す必要があります。
-
ユーザーが同意した場合、アプリケーションは、INetFwAuthorizedApplication API を使用して、自分自身を "有効" として AuthorizedApplications コレクションに追加する必要があります。
-
ユーザーが同意しない場合、アプリケーションは INetFwAuthorizedApplication API を使用して、自分自身を "無効" として AuthorizedApplications コレクションに追加する必要があります。
INetFwAuthorizedApplication API を使用してアプリケーションを AuthorizedApplications コレクションに追加するときは、以下の値が必要です。
INetFwAuthorizedApplication API の詳細については、Microsoft Platform Software Development Kit (SDK) の INetFwAuthorizedApplication についてのページ (http://go.microsoft.com/fwlink/?LinkId=32000) を参照してください。
Windows ファイアウォールは、Winsock を監視して、ポートでのリッスンの開始および終了のタイミングを確認します。その結果、アプリケーションのエントリが Windows ファイアウォールの例外の一覧で有効になっていれば、ポートはそのアプリケーションに対して自動的に開閉します。したがって、Winsock アプリケーションでは、ポートを実際に開閉する操作は必要ありません。
注
-
アプリケーションが自分自身を Windows ファイアウォールの例外の一覧に追加するには、管理者権限を持つユーザーのコンテキストで実行されている必要があります。
-
許可された Winsock アプリケーションの場合は、アプリケーションが実行されているユーザー コンテキストに関係なく、ポートが自動的に開閉します。
-
アプリケーションは、自分自身を AuthorizedApplications コレクションに追加する前に、ユーザーの同意を得る必要があります。
-
Svchost.exe は、AuthorizedApplications コレクションに追加することはできません。
例
このように、異なる動作をする Microsoft アプリケーションが関連するタスクの例としては、次のものがあります。
サービスに対する着信接続
説明
開発者には他のすべてのシナリオで AuthorizedApplication API を使用することをお勧めしますが、固定ポートをリッスンするサービスには、Windows ファイアウォールのグローバル ポート API を使用することをお勧めします。これらのポートは常に開いているため、ポートを動的に開いてもあまりメリットがありません。代わりに、グローバル ポート API を使用すれば、これらの固定ポートに対するファイアウォール設定をユーザーがカスタマイズできるようになります。
必要な操作
サービスが固定ポート上でリッスンする必要がある場合、そのサービスがファイアウォール内でポートを開くことを許可するかどうかをユーザーに確認する必要があります。理想的には、これはサービスのインストール時に行ってください。
ユーザーが同意した場合、サービスは INetFwOpenPort API を使用してルールを Windows ファイアウォールに追加し、サービスで必要な 1 つまたは複数の固定ポートを開く必要があります。これらのルールは有効にする必要があります。
ユーザーが同意しない場合も、サービスは INetFwOpenPort API を使用してルールを Windows ファイアウォールに追加し、サービスで必要な 1 つまたは複数の固定ポートを開く必要があります。ただし、これらのルールは有効にしないでおきます。
INetFwOpenPort API を使用して、ポートの開放を Windows ファイアウォールに追加する場合は、以下の値が必要です。
-
ポート。これは、開くポートの番号です。0 から 65,535 までの間の値であることが必要です。
-
フレンドリ名。これは、Windows ファイアウォールのユーザー インターフェイスに表示される、ポートの開放の説明です。
INetFwAuthorizedApplication API の詳細については、MSDN Web サイトで Platform Software Development Kit (SDK) の InetFwAuthorizedApplication についてのページ (http://go.microsoft.com/fwlink/?linkid=32000) を参照してください。
サービスが無効である場合は、再度 INetFwOpenPort API を使用して、開いた静的なポートを可能な限り閉じる必要があります。このサービスがそれらのポートを使用している唯一のサービスであれば、これは容易に行えます。しかし、他のサービスとポートを共有している可能性がある場合には、他のサービスがポートを使用していないことを確認できるまで、ポートを閉じないでください。
Windows ファイアウォールで静的にポートを開くには、アプリケーションが管理者権限を持つユーザーのコンテキストで実行されている必要があります。
注
例
以下は、着信接続を必要とするサービスの一例です。
-
ファイルとプリンタの共有
-
UPnP アーキテクチャ
-
リモート デスクトップ
システム サービスの RPC および DCOM ポートでの着信接続
説明
一部のシステム サービスでは、着信接続に、DCOM 経由で、または直接的に、RPC ポートを使用する必要があります。RPC ポートを開くときのセキュリティ上の重要な影響から、これらのポートは特殊なケースとして扱われます。開発者は、絶対に必要な場合に限り、Windows ファイアウォールでシステム サービス用の RPC を有効にする必要があります。
必要な操作
Windows ファイアウォールは、システム サービスに対して RPC および DCOM ポートを自動的に開閉するよう構成できます。ただし、既定では、RPC は Windows ファイアウォールによってブロックされるようになっています。したがって、RPC ポートを使用してシステム サービスにデータを転送するアプリケーションでは、Windows ファイアウォールを適切に構成する必要があります。アプリケーションでこの機能を有効にする必要がある場合は、サービスがファイアウォール内でポートを開くことを許可するかどうかをユーザーに確認する必要があります。理想的には、これはインストール時に行ってください。
ユーザーが RPC ポートを開くことに同意した場合、サービスは INetFwRemoteAdminSettings API を使用して、サービスで必要なポートを開く必要があります。
ユーザーが RPC ポートを開くことに同意しない場合、アプリケーションまたはサービスで、RPC ポートを許可するように Windows ファイアウォールを構成しないでください。
INetFwRemoteAdminSettings API の詳細については、MSDN Web サイトの INetFwAuthorizedApplication についてのページ (http://go.microsoft.com/fwlink/?linkid=32000) で、InetFwAuthorizedApplication の RemoteAddresses プロパティに関する項目を参照してください。
注
-
Windows ファイアウォールで RPC ポートの自動開放を有効または無効にするには、アプリケーションまたはサービスが管理者権限を持つユーザーのコンテキストで実行されている必要があります。
-
Windows ファイアウォールで RPC ポートを許可する前に、アプリケーションまたはサービスは、ユーザーの同意を得る必要があります。
-
アプリケーションまたはサービスは、絶対に必要な場合に限り、Windows ファイアウォールで RPC ポートを許可するようにしなければなりません。
-
RPC ポートが既に許可されている場合は、アプリケーションまたはサービスが正しく機能するために必要な操作はありません。
-
RPC ポートの設定は、ローカル システム、ネットワーク サービス、またはローカル サービスのコンテキストで実行されている RPC サーバー上でのみ機能します。他のユーザー コンテキストで実行されている RPC サーバーによって開かれたポートは、この設定から有効にすることはできません。このような RPC サーバーでは、Windows ファイアウォールの例外の一覧を使用してください。
Windows Media Player
Windows Media Player の機能
Windows Media Player は、メディア コンテンツを提供し、メディア ファイルを再生し、格納されているメディア ファイルの整理に役立つアプリケーションです。
この機能の対象ユーザー
Windows Media Player を使用するすべてのユーザーは、Windows XP Service Pack 2 に盛り込まれた変更点を理解しておく必要があります。
Windows XP Service Pack 2 でこの機能に追加された新機能
Windows Media Player 9 シリーズ
詳細説明
Windows Media Player 9 シリーズは、Windows XP Service Pack 2 の一部としてインストールされます。このバージョンの Windows Media Player には、セキュリティ関連修正プログラムと新機能が含まれます。
Windows XP Service Pack 2 のインストール中に、ファイルをアーカイブするオプションを選択しておくと、Windows Media Player 9 シリーズを後から削除できます。これを行うには、[プログラムの追加と削除] を使用して Service Pack を削除します。Windows Media Player 9 シリーズは Service Pack と共に削除され、Windows Media Player とオペレーティング システムの両方が以前のバージョンに復元されます。
以前のバージョンの Windows が実行されているコンピュータに Service Pack 2 が含まれる Windows XP を新規にインストールすると、オペレーティング システムが置き換わり、Windows Media Player 9 シリーズは削除できなくなります。詳細については、Windows Media 9 シリーズの Knowledge Center (http://go.microsoft.com/fwlink/?LinkId=32062) を参照してください。
この変更が重要な理由と軽減される脅威
以前のバージョンの Windows Media Player には、セキュリティ上の脆弱性が存在しました。この脆弱性はソフトウェア更新プログラムによって修正されていますが、以前のバージョンを Windows Media Player 9 シリーズにアップグレードすることにより、より完璧なソリューションを得ることができます。Windows Media Player 9 シリーズは、徹底したテストと更新を行っており、Windows XP Service Pack 2 に含まれる他のセキュリティ強化機能と連携して動作することが確認されています。
動作の相違点
Windows XP Service Pack 2 をアンインストールした場合に、既にライセンスを取得しているコンテンツであっても、再びライセンスを取得しないと再生できないことがあります。このケースが該当するのは、コンピュータを Windows 2000 または Windows XP から Windows XP Service Pack 2 にアップグレードした場合です。これは、Windows Media Player 9 シリーズでは、デジタル コンテンツ ライセンスの扱いが以前のバージョンと異なるためです。
これらの問題の解決法
Windows XP Service Pack 2 を削除した後でも、ランセンスを取得済みの既存のコンテンツを Windows Media Player で引き続き利用できるようにするには、次のいずれかを実行します。
-
コンピュータを Windows XP Service Pack 2 にアップグレードする前に、デジタル メディア ファイルのライセンスをバックアップします (これは Windows Media Player のライセンス管理機能で行います)。次に、Service Pack を削除する前に、取得している追加のライセンスがあれば、バックアップします。Service Pack の削除後に、すべてのライセンスを復元します。
-
Windows XP Service Pack 2 の削除後に、Microsoft Windows Media のダウンロード センターから Windows Media Player 9 シリーズをインストールできます。
Windows Messenger
Windows Messenger の機能
Windows Messenger は、Windows Messenger または MSN Messenger を使用する人とリアルタイムに通信することができるインスタント メッセージ プログラムです。
Windows Messenger を使用すると、次のことを実行できます。
-
同じく Messenger を使用している友人、家族、同僚の連絡先一覧を作成します。
-
Windows Messenger にサインインしたメンバを確認します。
-
メンバとテキスト メッセージをやり取りします。
-
非常に低料金で世界中ほぼどこにでも電話をかけ、マイクまたはヘッドフォンを使用して会話します。
-
メンバのコンピュータを無料で呼び出し、お互いの姿を見ながら会話します。
-
写真、音楽、またはドキュメントをメンバに送信します。
-
既定の電子メール プログラムの電子メール受信箱に直接リンクします。
-
他のユーザーを招待して、一緒にゲームを楽しんだり、自分のコンピュータ上のプログラムを見たり、1 つのホワイトボードを共用します。
-
リモート アシスタンスを利用して、コンピュータのことで他のユーザーに助けてもらうことができます。
-
Microsoft .NET Alerts を使用して、最新の情報を受け取ります。
この機能の対象ユーザー
Windows Messenger のすべてのユーザーは、Windows XP Service Pack 2 におけるこの機能の変更点について、理解しておく必要があります。
Windows XP Service Pack 2 でこの機能に追加された新機能
Windows XP Service Pack 2 で Windows Messenger に追加された機能は、以下のとおりです。
安全ではないファイル転送のブロック
詳細説明
コンピュータに損害を与える可能性があるコンテンツが含まれている場合、そのファイル転送はブロックされます。誰かがファイルを送信しようとすると、Windows Messenger はまず、送信者がユーザーの連絡先一覧に含まれているかどうかをチェックします。次に、ファイルに対してセキュリティ チェックを行います。
以下の両方に当てはまる場合は、ファイル転送がブロックされます。
拡張子が .jpg、.txt、.gif のファイルは一般に安全であると見なされ、連絡先一覧に載っていない人からでも受け取ることができます。
特定の種類のファイルの場合は、実行可能コードを含んでいる可能性があるため、送信者がわかっていても、注意して開くようにしてください。連絡先一覧に載っている人から特定の種類のファイルを受け取る場合には、そのファイルの処理方法をたずねられます。コンピュータのハード ディスクに保存できるならば、まず受け取り、その後ウイルス対策プログラムでスキャンしてから開くべきです。
次のファイルの種類を開くときは、その前にメッセージが表示されます。
-
.doc、.ppt、.xls などの Microsoft Office ファイル
-
.zip、.wpd、.pdf などの他のアプリケーションのファイル
-
コンピュータ アプリケーション、プログラム、またはマクロ、実行可能プログラム、JavaScript などのソフトウェア コードやスクリプトが含まれるファイル
-
拡張子が .exe、.cmd、.wsh、.bat、.vb、.vbs、.pif、.scr、.scf のファイル
-
その他のファイルの種類
一般的に安全でないと見なされるファイルの一覧については、Microsoft Web サイトの「Internet Explorer 6 の安全でないファイル (Unsafe File) 一覧に関する情報」(http://go.microsoft.com/fwlink/?LinkId=25999) を参照してください。
この変更が重要な理由と軽減される脅威
コンピュータに損害を与える可能性があるコンテンツが含まれている場合、そのファイル転送はブロックされます。
動作の相違点
一部のファイル転送はブロックされます。
これらの問題の解決法
以下の両方に当てはまる場合のみ、ファイルがブロックされます。
ファイルが安全であるとわかっている場合、そのユーザーを連絡先一覧に追加すれば、一覧に載っている人からのすべてのファイル転送は正常に実行されます。
ユーザーの表示名の要求
詳細説明
Windows Messenger では、ユーザーの電子メール アドレスとは異なるユーザーの表示名が要求されるようになりました。
これは、ユーザーが Windows Messenger にサインインするときと、[オプション] ダイアログ ボックスで表示名を更新するときに要求されます。
ユーザーが Windows Messenger にサインインする際、ログオンの前にユーザー表示名の入力が求められます。ユーザーは、表示名を入力しないと、ログオンできません。
[オプション] ダイアログ ボックスで表示名を更新するときは、Windows Messenger により、その表示名と電子メール アドレスが一致するかどうかが検証されます。
この変更が重要な理由と軽減される脅威
インスタント メッセージの会話を、後から参照できるように [ファイル] メニューの [名前を付けて保存] を使用して保存すると、ユーザーの表示名は、関連付けられているテキスト メッセージと共にテキスト ファイルに格納されます。ウイルス アプリケーションは、このテキスト ファイルから電子メール アドレスを検出し、そのアドレスを使用して、同じインスタント メッセージの会話を通じてユーザーの連絡先に広がる可能性があります。
動作の相違点
ユーザーは、ユーザーの表示名を入力するまでサインインできません。
これらの問題の解決法
サインイン中にプロンプトが表示された場合には、ユーザーはユーザーの表示名を入力する必要があります。
Windows Messenger と Windows ファイアウォール
詳細説明
Windows Messenger が Windows ファイアウォール経由でインターネットに接続するには、アクセス許可が必要です。
Windows Messenger にインターネットに接続するためのアクセス許可を与えるには、[スタート] ボタン、[コントロール パネル]、[セキュリティ オプション]、[Windows ファイアウォール]、[例外] の順にクリックし、[プログラムおよびサービス] で [Windows Messenger] をクリックします。
この変更が重要な理由と軽減される脅威
Windows ファイアウォールは、ユーザーのコンピュータを保護するために、既定で有効に設定されています。
動作の相違点
Windows Messenger は実行されません。
これらの問題の解決法
Windows Messenger を Windows ファイアウォールの例外の一覧に追加します。
Wireless Provisioning Services
Wireless Provisioning Services の機能
パブリック ワイヤレス ネットワークまたは Wi-Fi® (Wireless Fidelity) ホットスポットの数が増えるにつれ、それを介してインターネットにアクセスするユーザーの数も増加しています。Windows XP Service Pack 2 (SP2) の Wireless Provisioning Services (WPS) と Windows Server 2003 Service Pack 1 を組み合わせて使用すると、クライアントの自動プロビジョニングとシームレス ローミングにより、ワイヤレス ユーザーに一貫したエクスペリエンスとパブリック Wi-Fi ホットスポットへのシームレスな接続を提供できます。WPS を使用すると、ワイヤレス インターネット サービス プロバイダ (WISP) は、標準ベースの統合プラットフォームを利用して、使いやすく管理が容易でセキュリティ強化された Wi-Fi ホットスポットを提供できます。さらに、WPS によって、企業は、プライベート ワイヤレス ネットワークへのゲスト アクセスを、強化されたセキュリティのもとで容易に実現できるようになります。
WPS を使用して、WISP や企業は、モバイル クライアントがインターネットまたは企業ネットワークに接続する際、モバイル クライアントにプロビジョニング情報と構成情報を送信できます。これによりモバイル クライアントのシームレスでセキュリティ保護された構成を自動的に行うことが可能となり、企業において、またさまざまなパブリック ネットワーク プロバイダやホットスポットにまたがって、一貫したサインアップ エクスペリエンスを実現できます。
注 この機能を使用してここで説明するユーザー シナリオを実現するには、Windows Server 2003 Service Pack 1 が必要です。Windows Server 2003 Service Pack 1 は、まだリリースされていません。
この機能の対象ユーザー
ワイヤレス プロビジョニング サービスは、次の 3 種類の組織を対象として設計されています。
-
ホットスポット サービス プロバイダ (HSP)
HSP はショッピング モールや空港などの公共の場にワイヤレス アクセス ポイントを展開しますが、インターネット サービス プロバイダ (ISP) ではありません。HSP は、1 社または複数の ISP と契約することで、ユーザーがインターネット アクセス用のアカウントを確立するときに、選択可能な 1 つまたは複数のプランを提示します。
-
ワイヤレス インターネット サービス プロバイダ (WISP)
WISP は、公共の場に Wi-Fi ホットスポットを展開するか、または Wi-Fi ホットスポット サービスを HSP に外部委託します。
-
企業
企業は、WPS テクノロジを使用することで、管理されたゲスト アクセスを社内のネットワークに提供できます。
Windows XP Service Pack 2 でこの機能に追加された新機能
Wireless Provisioning Services
詳細説明
Wireless Provisioning Services は、Windows XP と Windows Server 2003 における既存のワイヤレス サービスとユーザー インターフェイスを拡張するものです。このサービスは、ワイヤレス自動構成などの Windows に既存のワイヤレス機能、および保護された拡張認証プロトコル (PEAP) や Wi-Fi Protected Access (WPA) といったワイヤレス セキュリティ機能に基づいて構築されています。WPS には、Windows Server 2003 への変更も含まれています。Windows 2003 IAS (インターネット認証サービス) コンポーネントは変更され、プロビジョニング プロセスでクライアントのゲスト認証が行えるようになりました。
WPS には、プロビジョニング サービス コンポーネントがあります。これにより、ワイヤレス インターネット サービス プロバイダ (WISP) や企業は、インターネットまたは企業ネットワークに接続を試みているモバイル クライアントにプロビジョニング情報と構成情報を送信することができます。WPS を使用することにより、WISP はネットワーク内の複数の場所でサービスを提供し、複数のネットワーク名 (サービス セット識別子または SSID) を使用できます。ユーザーがある場所から WISP へのサインアップを済ませるか事前プロビジョニングされ、プロビジョニング情報をダウンロードしておけば、以後さまざまなホットスポットで WISP が提供するネットワークを使用してインターネットに自動的に接続できます。ワイヤレス自動構成サービスは、提供されているプロビジョニング ファイルに基づいて、WISP に属しているネットワークを自動的に正しく選びます。WPS では、異なるプロバイダ間での自動的でシームレスなローミングが可能です。
さらに、WPS が使用されると、クライアント コンピュータは、自分のコンピュータに格納されているプロビジョニング情報を自動的に最新のものに保ちます。これによって、プロバイダはサービスを中断することも、ユーザーにシステムを再構成させることもなく、ネットワーク設定の変更や新しい場所の追加などを行うことができます。
ユーザーが WISP にコンピュータを接続し、初めてアカウントを確立すると、次の 4 段階の処理が行われます。
-
Wi-Fi ホットスポットで、コンピュータが WISP ネットワークを検出します。
-
ユーザーがゲスト アカウントを使用して認証され、コンピュータが Wi-Fi ネットワークに接続されます。
-
モバイル クライアントがプロビジョニングされ、ユーザーは WISP にアカウントを確立します。
-
ユーザーは、新しいユーザー アカウント資格情報を使用して Wi-Fi ネットワークで認証されます。
これらの各段階については、次のシナリオで詳しく説明します。
あるユーザーが、Windows XP SP2 と Wireless Provisioning Services を実行しているポータブル コンピュータを持って Wi-Fi ホットスポットに到着します。このコンピュータが WISP アクセス ポイント ビーコンの範囲内に入ると、次の処理が行われます。
-
クライアント コンピュータのワイヤレス自動構成 (WAC) サービスが、アクセス ポイントからのビーコン情報を検出します。これは、ブロードキャストのサービス セット識別子 (SSID) によって実現します。SSID はネットワーク名と同等のものです。
-
ユーザーは、Windows XP から、ワイヤレス ネットワークが利用可能であることを知らされます。Windows XP には、ネットワークのフレンドリ名などの情報が表示されます。この例では、ユーザーはアカウントの確立に使用するプロモーション コードを所有しており、[接続] をクリックして先に進みます。これにより、WPS クライアントは、権限が制限されているゲスト アカウントを使用して、ユーザーのコンピュータをワイヤレス ネットワークに接続します。
ゲスト アカウントが Wi-Fi ネットワークで認証されると、次の処理が行われます。
-
WAC は、802.1x および保護された拡張認証プロトコル (PEAP) を使用して、アクセス ポイント経由で WISP ネットワークにゲストとして接続し、認証を行います。このとき、ユーザー名とパスワードは空白のまま WISP の インターネット認証サービス (IAS) サーバーに自動的に渡されます (IAS は Microsoft RADIUS サーバーとしても知られています)。アクセス ポイントはゲートウェイ デバイスに接続されています。ゲートウェイ デバイスは、サインアップ プロセスを完了するためにクライアントからのトラフィックをネットワークのプロビジョニング サービスに渡しますが、クライアントによるインターネットへのアクセスはブロックします。
-
IAS サーバー (または RADIUS サーバー) は、ゲストとして接続するユーザーにとって、PEAP 認証であり、TLS (Transport Layer Security) エンドポイントでもあります。クライアントと IAS サーバー間に TLS トンネルが作成されます。クライアントとサーバー間でこれ以降にやり取りされるメッセージはすべて、このトンネルを通過します。このトンネルは、アクセス ポイントとゲートウェイ デバイスをスキャンします。
-
拡張キー使用法 (EKU) 拡張内のサーバー認証目的を含む証明書を使用して、IAS サーバーがクライアント コンピュータに対して ID を検証することによって、サーバー認証が行われます。この証明書は、クライアント コンピュータが信頼する、公的な信頼されたルート証明機関 (CA) から発行されます。
-
IAS サーバーは、ユーザーをゲストとして認証し、承認します。IAS サーバーがクライアントに送信する Access-Accept メッセージには、プロビジョニング情報への URL を含むコンテナがあります。この URL は、クライアントで実行されている Wireless Provisioning Services エンジンに、XML マスター ファイルの場所を提供します。
クライアントがプロビジョニングされると、ユーザーは次のようにしてアカウントを作成します。
-
クライアント コンピュータで、Wireless Provisioning Services がプロビジョニング サーバーから XML マスター ファイルとサブ ファイルをダウンロードします。このマスター ファイルには、処理中のクライアントの進捗状況を制御する XML サブ ファイルへのポインタが含まれています。XML サインアップ スキーマがダウンロードされる際、サインアップ ウィザードがクライアント上で起動します。ユーザーはこのウィザードを使用して、WISP のアカウントを作成し、支払いを行うことができます。
-
クライアント コンピュータ上のサインアップ ウィザードを使用して、ユーザーは、アカウントのサインアップ プロセスを進めます。ユーザーは、名前、住所、クレジット カード番号などの個人データに加えて、プロモーション コードも入力します。ユーザーが入力したデータは、Wireless Provisioning Services クライアントによって XML ドキュメントに変換されます。
-
ユーザーのサインアップ データが入った XML ドキュメントが、WISP プロビジョニング サーバー上の Web アプリケーションに送信されます。
-
Web アプリケーションは、ユーザーが入力したプロモーション コードをプロモーション コード データベース (SQL Server データベースなど) と照合してチェックします。プロモーション コードが有効であれば、Web アプリケーションはユーザー データの処理を続行します。
-
Web アプリケーションがユーザーの支払い情報を処理します。支払いについての確認が済み、サインアップ情報の処理が正常に終了すると、Web アプリケーションはプロモーション コード データベースからドメインおよびセキュリティ グループ情報を読み取り、Active Directory などの識別情報サービス内にユーザー アカウントを作成して、そのアカウントをセキュリティ グループに追加します。Web アプリケーションはまた、新しいユーザー名をプロモーション コード データベースに入力します。
-
新しいアカウントの資格情報を含む XML ドキュメントは、WISP プロビジョニング サーバーからクライアント コンピュータ上の Wireless Provisioning Services クライアントに送信されます。クライアント コンピュータは、この資格情報を使用して WISP の名前で WAC と 802.1x を構成します。新しいユーザー アカウントのパスワード ベースの資格情報 (ユーザー名とパスワード) を使用して、接続が再試行されます。
最後に、新しいアカウント資格情報を使用してユーザーが認証され、インターネット アクセスが可能になると、次の処理が行われます。
-
クライアント コンピュータ上のワイヤレス自動構成 (WAC) サービスは、WISP の SSID との関連付けを再開します。
-
WAC は、XML マスター ファイル内で、他の WISP 情報と共にダウンロードされた正しい 802.11 プロファイルを探します。WAC は、正しいプロファイルを使用して、アクセス ポイントを再び関連付けます。
-
WAC は 802.1x を使用して認証プロセスを開始します。この際、Wireless Provisioning Services クライアントから 802.1x に渡される新しいアカウント資格情報を利用して、保護された拡張認証プロトコルと Microsoft チャレンジ ハンドシェイク認証プロトコル バージョン 2 の組み合わせ (PEAP-MSCHAPv2) が使用されます。
-
クライアントが PEAP-MSCHAPv2 認証で認証プロセスを開始すると、ユーザーのクライアント コンピュータと WISP IAS サーバー間に TLS チャネルが作成されます。
-
PEAP-MSCHAPv2 認証の第 2 段階で、WISP IAS サーバーは、Active Directory などのユーザー アカウント データベースの新アカウントに対する接続要求を認証し、承認します。IAS サーバーは、アクセス ポイントに Access-Accept メッセージを送信します。Access-Accept メッセージには、ユーザーがインターネットにアクセスできるようになったことを示す属性が含まれます。
-
アクセス ポイントは、クライアントをインターネットにアクセス可能な論理ネットワーク セグメントに割り当てるようにゲートウェイ デバイスに指示します。
軽減される脅威とこの変更が重要な理由
Wireless Provisioning Services (WPS) を使用すると、セキュリティを損なうことなく、ワイヤレス ホットスポットを容易に利用できるようになります。WPS を、Windows Server 2003 Service Pack 1 および Microsoft IAS (RADIUS サーバー) と組み合わせて使用すれば、ユーザーのコンピュータは、強化されたセキュリティのもとで、ワイヤレス ホットスポットの検出、接続、およびローミングをより簡単に実行できます。
-
WISP のサインアップと使用に関する現在の接続モデルは、セキュリティで保護されていません。ほとんどの Wi-Fi ホットスポットは、オープン認証用に構成されており、データが暗号化されません。ユーザーは通常、Web ブラウザを起動して、WISP サービスの最初のサインアップと以降のログインを行う必要があります。WPS では、クライアントとワイヤレス ネットワーク間の通信に暗号化と認証を追加して、この脅威を軽減しています。
-
ブラウザのリダイレクト ベースの展開には、ユーザビリティに関する多数の問題があります。ユーザーは接続する際にブラウザを起動する必要があることさえ知らない可能性があります。また、インターネットにアクセスするためにプロキシ設定を使用するようブラウザが設定され、ユーザーが直接企業ネットワークに接続しているケースでは何が起こるでしょうか。この場合、ブラウザのリダイレクトはうまく行きません。ユーザーは、プロキシ設定を無効にしないとホットスポットに接続できないことを知る必要があります。結果的に、WISP への問い合わせの電話や企業のヘルプデスクをサポートするための費用がかかる可能性があります。
-
ブラウザ ベースの展開は、たとえば許可されていないアクセス ポイントを使用する悪意のあるフロントエンド サーバーによる man-in-the-middle 攻撃に対して脆弱です。このアクセス ポイントから照会を受けたユーザーは、知らないうちに個人情報やクレジット カード情報を渡してしまうことがあります。Web ログインの必要性をなくすことで、WPS は、この種の攻撃に対する WISP ユーザーの脆弱性を軽減します。
-
追加のホットスポット クライアント ソフトウェアがなければ、ユーザーは、簡単にホットスポットを検出することができず、ホットスポットにサインアップする統一的な機構も持たないことになります。ユーザーにとっては、WISP に関する情報を探したり、WISP のホットスポットの場所を調べることは容易ではありません。ユーザーがあるホットスポットでサインアップする場合、別のホットスポットを自動的に使用できるよう構成されているとは限りません。さらに、各自のプロビジョニング情報と構成情報を最新に保つ標準的な機構もありません。
-
アドオン型のホットスポット クライアント ソフトウェアは、特定の WISP のネットワークにアクセスするのには役立ちます。ただし、アドオン型のソフトウェアは、オペレーティング システムのネイティブなワイヤレス サービスと衝突する可能性もあり、別のプロバイダのクライアント ソフトウェアが潜在的に相互運用性の問題を引き起こしたり、システム全体のワイヤレス設定を制御しようとしてシステムの不安定さを招くことさえあります。WISP 構成の更新には、一般に、クライアント ソフトウェアの更新も必要となります。このような理由から、多くの企業の IT 部門は、自社のユーザーにサードパーティ製のホットスポット クライアント ソフトウェアを展開することに積極的になれずにいます。
-
WISP 間には、ユーザーのサインアップを処理し、構成を更新する標準機構がありません。そのため、ユーザー エクスペリエンスでは統一がとれず、複数のプロバイダ間で自動的かつシームレスなローミングを実現するのは困難です。
ワイヤレス ネットワーク登録ウィザード
詳細説明
[ワイヤレス ネットワーク登録ウィザード] は、ワイヤレス ホットスポットへのサインアップを行うためのユーザー インターフェイスを提供し、ユーザーがプロビジョニング プロセスを進めていく上でのガイダンスを提供します。このウィザードは、WISP が提供するプロビジョニング情報 (XML ファイル) からコンテンツを構築します。プロビジョニング情報は、動的にダウンロードすることもクライアント システムに前もってインストールしておくことも可能です。プレインストールは、新システム向けに OEM が行うことも、組織内の IT 部門が行うことも、WISP の Web サイトから行うこともできます。WISP は、プロビジョニング情報を所有および作成し、ユーザーのサインアップとプロビジョニングのエクスペリエンスを推進します。以下の例では、プリペイド コードで行う簡単な [ワイヤレス ネットワーク登録ウィザード] のエクスペリエンスを示します。XML スキーマとウィザードは柔軟です。これらによって、より複雑なサインアップ エクスペリエンスを実現できます。
まず、ユーザーは、通知エリアにあるワイヤレス ネットワーク アイコンを右クリックし、[利用できるワイヤレス ネットワークの表示] をクリックします。または、近くに新しいワイヤレス ネットワークが利用可能であることを示す通知エリアの通知メッセージに応答することもできます。[ワイヤレスネットワークの選択] が表示されたら、新しいワイヤレス ネットワークを選択し、優先ネットワークの一覧にそのネットワークを追加します。
次に、ユーザーは、ネットワーク名 (SSID) を選択し、[接続] をクリックしてワイヤレス ネットワークに接続します。WPS ベースの Wi-Fi ホットスポットの場合には、クライアントは、ネットワークとプロバイダに関するさらに詳細なプロビジョニング情報が XML ファイル形式で用意されていることを検出します。このプロビジョニング情報をダウンロードすべきかどうか、ユーザーに確認します。WPS 以外のネットワークでは、エクスペリエンスは現在の Windows XP と同じになります。すなわち、セキュリティで保護されているネットワークに接続するときは、セキュリティ キーが要求されます。そうでない場合は、接続しようとしているネットワークがセキュリティで保護されていないことが警告され、それでも接続するかどうかたずねられます。
ダウンロードが完了すると、[ワイヤレス ネットワーク登録ウィザード] が自動的に起動し、ユーザーは、ウィザードに従ってサインイン プロセスを実行することができます。最初の画面には、カスタマイズされたロゴ (またはバナー) とプロバイダ提供のコンテンツが表示されます。
その後、購読プランの選択画面、クレジット カード情報や個人情報などの入力画面が続きます。この例では、プランは 1 つしかなく、ユーザーは、プリペイド コードまたはプロモーション コードを入力してネットワークにアクセスするよう求められます。次に、Wi-Fi ホットスポットの展開では、サービス契約に関する条項とプライバシーに関する説明などの、選択されたプランに関する情報が表示されます。
最後の画面では、接続を行う際の設定についてウィザードがユーザーに問い合わせます。このような既定の設定は、プロバイダによる設定が可能ですが、ユーザーが上書きできます。たとえば、データ量に制限のない月決めの購読を選択している場合、ユーザーは、近くにネットワークがあるときは常に自動的にネットワークに接続することを望むと考えられます。従量制プランを選択した場合、ユーザーは、接続タイミングを自分で制御することを望み、基本設定として手動接続オプションを選択するでしょう。
2 番目のオプションは、クライアントがプロビジョニング情報を自動的に最新のものに保つようにするかどうかを決定します。たとえば、プロバイダが新しいネットワーク名、新しい場所を追加するか、またはネットワークやセキュリティ設定を変更すると、クライアントは、ネットワーク接続中にユーザーの手動操作を必要とせずにその情報を自動的に更新できます。
同じ場所でも違う場所でも、プロバイダまたはプロバイダのローミング パートナーが提供するホットスポットに何度も訪れる場合、自動接続を選択している場合には、ユーザーはモバイル コンピュータを起動するか、またはスタンバイ状態からレジューム操作を行うだけで、自動的に接続されます。接続されると、[ワイヤレス ネットワークの選択] ダイアログ ボックスに、意味不明なネットワーク名や SSID ではなく、見慣れたプロバイダ名とプロバイダのロゴが表示されます ([ワイヤレス ネットワークの選択] ダイアログ ボックスは、[利用できるワイヤレス ネットワークの表示] 通知ウィンドウから表示されます)。
このダイアログ ボックスでは、利用可能なホットスポットの場所を検索することも、WISP が提供するヘルプやサポート情報を表示することもできます。ヘルプとホットスポットの場所に関する情報は、いずれもプロビジョニング情報の一部としてダウンロードされます。ホットスポットの場所に関する情報は、オンラインでもオフラインでも検索および表示できます。
Windows XP Service Pack 2 で変更された既存機能
ワイヤレス ユーザー インターフェイスが変更され、既存のダイアログ ボックスは、新しい [利用できるワイヤレス ネットワークの表示] ダイアログ ボックスに置き換わりました。
Windows XP Service Pack 2 に対応するためにコードの変更が必要かどうか
Wireless Provisioning Services は、既存のアプリケーションの変更を必要としません。WPS には新しい API が 2 つあります。新しい API の 1 つでは、コンピュータ上の XML データの追加とクエリを実行できます。この API は、スタンドアロン アプリケーションを使用するユーザー、OEM、または IT 部門が、WISP Web サイトからクライアントを事前にプロビジョニングする際に使用できます。
ワイヤレス ネットワーク セットアップ ウィザード
ワイヤレス ネットワーク セットアップ ウィザードの機能
[ワイヤレス ネットワーク セットアップ ウィザード] は、ユーザーがセキュリティを強化したワイヤレス ネットワークを構成し、コンピュータやその他デバイスでワイヤレス ネットワーク接続を構成するプロセスを簡略化するのに役立ちます。このウィザードを使うと、構成やセキュリティ キーを含むワイヤレス設定を USB フラッシュ ドライブのようなリムーバブル メディアに格納できます。これを他のデバイスやコンピュータに転送して、ワイヤレス ネットワークを構成することができます。このウィザードでは、構成情報を簡単に印刷する方法も提供されているので、リムーバブル メディアから情報を読み取ることができないデバイスにも、構成情報を手動で入力することが可能です。
この機能の対象ユーザー
以下のようなハードウェア コンポーネントを備えたコンピュータを有するユーザー
Windows XP Service Pack 2 でこの機能に追加された新機能
ワイヤレス ネットワーク セットアップ ウィザード
詳細説明
ワイヤレス ネットワークが普及するにつれ、家庭にワイヤレス ネットワークを作成し、ワイヤレス ネットワークをサポートするコンピュータや他のデバイスをネットワーク化するユーザーが増えています。Windows XP Service Pack 2 がリリースされる以前は、セキュリティ保護されたワイヤレス ネットワークを作成して、そのワイヤレス設定をワイヤレス クライアントや追加のアクセス ポイントに適用することは非常に困難でした。[ワイヤレス ネットワーク セットアップ ウィザード] は、ワイヤレス ネットワーク ハードウェア (ワイヤレス アクセス ポイントまたは WAP) とワイヤレス クライアント (コンピュータのワイヤレス クライアントやその他デバイスなど) を構成して起動するための、簡単でしかも安全な方法へのニーズの増加に対応するために設計されました。
[ワイヤレス セットアップ ウィザード] は、Windows ユーザーにとって、XML (拡張マークアップ言語) スキーマとリムーバブル メディアを使用してネットワーク設定を簡単に作成し、適用する手段を提供します。今後は、ワイヤレス LAN (WLAN) だけでなく、広域ネットワーク (WAN) やローカル エリア ネットワーク (LAN) の転送設定にも、この XML スキーマが使用されるようになるでしょう。ただし、この Windows XP SP2 用の [ワイヤレス ネットワーク セットアップ ウィザード] で作成した XML ファイルは、WLAN の構成設定の転送にしか使用できません。
この変更が重要な理由
家庭用のワイヤレス ネットワークでは、ネットワーク化されたすべてのコンポーネントにセキュリティ識別子を付加する作業が複雑であるため、セキュリティ オプションなしで展開しているケースが多くあります。このウィザードを使用すれば、セキュリティを強化したワイヤレス ネットワークを容易に作成できます。ワイヤレス ハードウェアを標準でサポートするコンピュータやデバイスが多数製造されるようになるにつれ、この機能の構成と実装を簡略化する手段を求める声も増えています。多くの場合、デバイスには、セキュリティを強化したワイヤレス ネットワーク設定を入力する手段がありません。このウィザードは、そういったデバイスの構成を簡略化するので、セキュリティを強化したワイヤレス ネットワークの展開も、煩わしい作業ではなくなります。以下は、[ワイヤレス ネットワーク セットアップ ウィザード] を使用して構成できるデバイスの一例です。
-
ワイヤレス アクセス ポイント
-
デスクトップ コンピュータ
-
ネットワーク プリンタ
-
フォト ステーション
-
デジタル メディア レシーバー
-
デジタル写真立て
-
セットトップ ボックス
-
ポータブル コンピュータとポータブル デバイス
軽減される脅威
セキュリティ オプションなしで展開されるワイヤレス ネットワーク。セキュリティ保護されていないワイヤレス ネットワークは、悪意のあるユーザーがデジタル情報やその他のネットワーク資産にアクセスする入口を提供します。
動作の相違点
これは、ワイヤレス ネットワークを構成するための新しい機構を提供する新しいウィザードです。このアーキテクチャを直接サポートしていないコンピュータやデバイスの構成にも活用できます (ワイヤレス ネットワークを作成し、その設定を印刷すれば、ワイヤレス デバイスやワイヤレス コンピュータに手作業で設定を入力できるからです)。