Windows Server 2003 セキュリティガイド

第 12 章 :要塞ホストの役割

最終更新日: 2005年8月14日

ダウンロード

Windows Server 2003 セキュリティガイドを入手する (英語情報)

トピック

概要
 監査ポリシーの設定
 ユーザー権利の割り当て
 セキュリティオプション
 イベントログの設定
 追加のセキュリティ設定
 SCW を使用してポリシーを作成する
 まとめ

概要

この章では、環境内の Microsoft® WindowsServer™2003**Service Pack 1 (SP1) を実行する要塞ホストのセキュリティを強化する方法について説明します。要塞ホストとは、組織の境界ネットワーク (DMZ、非武装地帯、スクリーンサブネットとも呼ばれます) の公開側に配置された、外部からのアクセスが可能なセキュリティ保護されたコンピュータのことです。要塞ホストはファイアウォールやフィルタリングルーターによって保護されていないため、あらゆる攻撃にさらされます。被害を受ける可能性を最小限に抑えるために、要塞ホストを慎重に設計および構成する必要があります。

一般に要塞ホストは、Web サーバー、DNS サーバー、ファイル転送プロトコル (FTP) サーバー、簡易メール転送プロトコル (SMTP) サーバー、および Network News Transfer Protocol (NNTP) サーバーとして使用されます。要塞ホストは、これらの機能のうち 1 つだけを実行する専用サーバーとして利用するのが理想的です。サーバーが提供する機能が増えるほど、セキュリティホールが見落とされる可能性が高くなります。1 台の要塞ホストで単一サービスを保護する方が複数のサービスを保護するよりセキュリティ対策が容易です。そのため、組織で複数台の要塞ホストを所有できる経済的余裕があれば、この種のネットワークアーキテクチャを利用する効果が上がります。

要塞ホストをセキュリティで保護する設定は、通常のホストの場合とまったく異なります。要塞ホストの場合は、不要なサービス、プロトコル、プログラム、ネットワークインターフェイスをすべて無効にするか削除し、その要塞ホストに割り当てられた役割だけを完全に満たすように設定します。この方法で要塞ホストのセキュリティを強化すると、攻撃に使用できる方法を制限できます。

ここでは、どのような環境でも要塞ホストのセキュリティを保護することが可能な各種セキュリティ設定について詳しく説明します。この章で説明する手順は、SMTP 要塞ホストの作成向けです。機能を追加する場合には、このガイドに付属の構成ファイルを変更する必要があります。

要塞ホストのローカルポリシー

このガイドでここまで説明してきたサーバーの役割では、サーバーの構成にグループポリシーを使用きましたが、要塞ホストにはグループポリシーを適用することはできません。要塞ホストは、Active**Directory® ディレクトリサービスドメインに属さないスタンドアロンホストとして構成されるからです。要塞ホストは公開され、他のデバイスによっては保護されないため、このガイドで定義している 3 種類の環境について、要塞ホストサーバーに規定されている指針のレベルは 1 つだけです。この章で説明するセキュリティ設定は、「第 4 章メンバサーバーベースラインポリシー」で SSLF 環境用に定義されているメンバサーバーベースラインポリシー (MSBP) に基づいています。この設定は、セキュリティテンプレートに含まれており、各要塞ホストの要塞ホストローカルポリシー (BHLP) に適用する必要があります。

表 12.1 要塞ホストサーバーセキュリティテンプレート

レガシクライアント環境	エンタープライズクライアント環境	セキュリティ強化 - 機能制限環境
SSLF-Bastion Host.inf	SSLF-Bastion Host.inf	SSLF-Bastion Host.inf

[](#mainsection)[ページのトップへ](#mainsection) ### 監査ポリシーの設定要塞ホスト用の BHLP 監査ポリシー設定は、SSLF-Bastion Host.inf ファイルに用意されています。これらの設定は、SSLF-Member Server Baseline.inf ファイルで指定されている設定と同じです。MSBP の詳細については、「第 4 章メンバサーバーベースラインポリシー」を参照してください。BHLP で設定すると、すべての関連するセキュリティ監査情報を、どの要塞ホストサーバーにも記録することができます。 [](#mainsection)[ページのトップへ](#mainsection) ### ユーザー権利の割り当て SSLF-Bastion Host.inf ファイルには、要塞ホスト用の BHLP ユーザー権利の割り当てが含まれています。これらのポリシー設定は、「第 4 章メンバサーバーベースラインポリシー」の SSLF-Member Server Baseline.inf ファイルで指定されているポリシー設定に基づいています。次の表では、BHLP と MSBP との違いをまとめています。詳細情報については、表に続いて説明します。 **表 12.2 ユーザー権利の割り当ての推奨設定**

ユーザー権利の割り当て	設定
ネットワーク経由でコンピュータへアクセスを拒否する	ANONYMOUS LOGON、ビルトイン Administrator、Support_388945a0、Guest、非オペレーティングシステムサービスアカウント

#### ネットワーク経由でコンピュータへアクセスを拒否する **注** :ANONOYMOUS LOGON、ビルトイン Administrator、Support\_388945a0、Guest およびすべての非オペレーティングシステムサービスアカウントはセキュリティテンプレートに含まれていません。これらのアカウントとグループには一意のセキュリティ識別子 (SID) があります。そのため、こうした SID は手動で BHLP に追加する必要があります。このポリシー設定では、ネットワーク経由でコンピュータにアクセスできないユーザーを指定します。このポリシーを有効にすると、サーバーメッセージブロック (SMB) ベースのプロトコル、NetBIOS、共通インターネットファイルシステム (CIFS)、HTTP、Component Object Model Plus (COM+) など、数多くのネットワークプロトコルが拒否されます。また、このポリシー設定と \[ネットワーク経由でコンピュータへアクセス\] の両方の対象となっているユーザーアカウントでは、このポリシー設定が優先されます。このユーザー権利を他のグループに構成した場合、環境で委任された管理タスクを実行するユーザーの権利が制限されます。このガイドの「第 4 章メンバサーバーベースラインポリシー」では、セキュリティレベルをできる限り上げるため、このユーザー権利を割り当てるユーザーとグループのリストに **Guests** グループを含めるよう推奨しています。しかし、IIS への匿名のアクセスに使用する IUSR アカウントが、既定で **Guests** グループのメンバに設定されています。そのため、このガイドで定義している SSLF 環境で、要塞ホストの \[ネットワーク経由でコンピュータへアクセスを拒否する\] は、ANONOYMOUS LOGON、ビルトイン Administrator、Support\_388945a0、Guest、および非オペレーティングシステムサービスアカウントが含まれるよう指定します。 [](#mainsection)[ページのトップへ](#mainsection) ### セキュリティオプション要塞ホスト用の BHLP セキュリティオプション設定は、「第 4 章メンバサーバーベースラインポリシー」の SSLF-Member Server Baseline.inf ファイルに指定されている設定と同じです。この BHLP 設定により、すべての関連セキュリティオプションがすべての要塞ホストサーバーで同一に設定されます。 [](#mainsection)[ページのトップへ](#mainsection) ### イベントログの設定要塞ホスト用の BHLP イベントログ設定は、「第 4 章メンバサーバーベースラインポリシー」の SSLF-Member Server Baseline.inf ファイルに指定されている設定と同じです。この BHLP 設定により、すべての関連イベントログ設定がすべての要塞ホストサーバーで同一に設定されます。 [](#mainsection)[ページのトップへ](#mainsection) ### 追加のセキュリティ設定 BHLP によって適用されるセキュリティ設定により、要塞ホストサーバーのセキュリティは大幅に強化されます。それでも、検討する必要のある追加の設定がいくつかあります。次に示す設定はローカルポリシーを使用して適用することができません。すべての要塞ホストサーバーに手動で適用する必要があります。 #### ユーザー権利の割り当てに独自のセキュリティグループを手動で追加する MSBP を使用して適用されるユーザー権利の割り当てのほとんどに対して、このガイドに付属のセキュリティテンプレートでは適切なセキュリティグループが指定されています。ただし、テンプレートに含まれていないアカウントとセキュリティグループもいくつかあります。これらのセキュリティ識別子 (SID) はそれぞれの Windows**Server**2003 のドメインに固有のものであるためです。以下の表に示すユーザー権利の割り当て設定は、手動で構成する必要があります。 **警告** :次の表には、ビルトイン Administrator アカウントの記載があります。このアカウントと、ビルトイン **Administrators** セキュリティグループを混同しないように注意してください。指定されている "アクセス拒否" ユーザー権利に **Administrators** セキュリティグループを追加した場合、ローカルにログオンしてその間違いを修正する必要があります。また、「第 4 章メンバサーバーベースラインポリシー」の推奨に従ってビルトイン Administrator アカウントの名前が変更されている場合があります。Administrator アカウントをユーザー権利に追加した場合は、名前の変更後のアカウントを指定していることを確認してください。 **表 12.3 手動で追加されるユーザー権利の割り当て**

設定	レガシクライアント環境	エンタープライズクライアント環境	セキュリティ強化 - 機能制限環境
ネットワーク経由でコンピュータへアクセスを拒否する	ビルトイン Administrator、Support_388945a0、 Guest、すべての非オペレーティングシステムサービスアカウント	ビルトイン Administrator、Support_388945a0、 Guest、すべての非オペレーティングシステムサービスアカウント	ビルトイン Administrator、Support_388945a0、 Guest、すべての非オペレーティングシステムサービスアカウント

重要 :"すべての非オペレーティングシステムサービスアカウント" には、企業全体において特定のアプリケーションで使用されるサービスアカウントが該当しますが、LOCAL SYSTEM アカウント、LOCAL SERVICE アカウント、および NETWORK SERVICE アカウント (オペレーティングシステムが使用するビルトインアカウント) は該当しません。

既知のアカウントを保護する

Windows Server 2003 SP1 には、削除できず、名前だけ変更できるビルトインユーザーアカウントがいくつかあります。Windows Server 2003 の最もよく知られているビルトインアカウントは、Guest と Administrator です。

既定では、Guest アカウントはメンバサーバーとドメインコントローラでは無効になっています。この設定は変更しないでください。悪意のあるコードの多くは、サーバーへの侵入で最初の試みとしてビルトイン Administrator アカウントを使用します。この理由から、ビルトイン Administrator アカウントの名前と説明を変更して、攻撃者がよく知られているアカウントを使用してリモートサーバーへ侵入することを防止してください。

ビルトイン Administrator アカウントのセキュリティ識別子 (SID) を指定し、その本当の名前を調べてサーバーに侵入しようとする攻撃ツールが出現して以来、この構成変更の価値はここ数年間で減少しています。SID は、各ユーザー、グループ、コンピュータアカウント、およびネットワークのログオンセッションをそれぞれ識別する値です。このビルトインアカウントの SID を変更することはできません。ただし、Administrator アカウント名を一意の名前に変更すると、運用グループが Administrator アカウントに対する攻撃を簡単に監視できるようになります。

要塞ホストサーバー上の既知のアカウントを保護するには

すべてのサーバーで Administrator と Guest のアカウント名を変更し、そのパスワードを長い複雑な値に変更します。
各サーバーで異なる名前とパスワードを使用します。すべてのサーバーで同じアカウント名とパスワードを使用する場合、攻撃者があるサーバーへのアクセスに成功した場合に、他のすべてのサーバーにもアクセスできるようになってしまいます。
アカウントを容易に識別できないように、アカウントの説明を既定以外に変更します。
変更した内容を安全な場所に記録します。

エラー報告

表 12.4 エラー報告に関する推奨設定

設定	レガシクライアント環境	エンタープライズクライアント環境	セキュリティ強化 - 機能制限環境
Windows エラーの報告をオフにする	有効	有効	有効

このサービスは、Microsoft がエラーを追跡して対処するのに役立ちます。このサービスは、オペレーティングシステムエラー、Windows コンポーネントエラー、またはプログラムエラーの報告を生成するように構成できます。このサービスは、Windows XP Professional および Windows Server 2003 でのみ使用できます。 \[Error Reporting service\] を使用すると、このようなエラーをインターネット経由で Microsoft に報告したり、社内のファイル共有に報告したりできます。エラー報告に重要なデータまたは機密データが格納される可能性がありますが、Microsoft はエラー報告に関するプライバシーポリシーに従って、そのようなデータを不正に使用しないことを保証します。ただし、データはプレーンテキスト HTTP で転送されるので、第三者によってインターネット上で傍受され、解読される可能性があります。 \[Windows エラーの報告をオフにする\] 設定では、\[Error Reporting service\] がデータを送信するかどうかを制御します。このポリシー設定は、Windows Server 2003 の場合、グループポリシーオブジェクトエディタを使用して、次の場所で指定できます。 **コンピュータの構成\\管理用テンプレート\\システム\\インターネット通信の管理\\インターネット通信の設定** このガイドで定義している 3 種類の環境すべての BHLP で、\[Windows エラーの報告をオフにする\] は \[有効\] に設定します。 [](#mainsection)[ページのトップへ](#mainsection) ### SCW を使用してポリシーを作成する必要なセキュリティ設定を展開するには、セキュリティの構成ウィザード (SCW) と、このガイドのダウンロードバージョンに付属のセキュリティテンプレートの両方を使用して、サーバーポリシーを作成する必要があります。独自のポリシーを作成する場合は、\[レジストリ設定\] セクションと \[監査ポリシー\] セクションをスキップします。これらの設定は、選択した環境のセキュリティテンプレートで提供されます。この方法は、テンプレートのポリシー要素が SCW によって構成されるポリシー要素より優先されるようにするために必要です。構成作業を始める際には、オペレーティングシステムの新規インストールを使用することをお勧めします。こうすることにより、以前の構成の古い設定やソフトウェアが残っていないことが保証されます。可能であれば、展開に使用するものと同様のハードウェアを使用することをお勧めします。これにより、互換性が向上します。このような新規インストールを*参照コンピュータ*と呼びます。サーバーポリシーの作成手順で、検出された役割の一覧からファイルサーバーの役割を削除することに注意してください。この役割は、それを必要としないサーバーに構成されていることが多く、セキュリティリスクになる可能性があります。ファイルサーバーの役割が必要なサーバーでそれを有効にするには、このプロセスの後半で別のポリシーを適用します。 **要塞ホストポリシーを作成するには** 1. Windows Server 2003 SP1 の新しいインストールを新しい参照コンピュータに作成します。 2. \[コントロールパネル\]、\[アプリケーションの追加と削除\]、\[Windows コンポーネントの追加と削除\] の順に選択して、セキュリティの構成ウィザードのコンポーネントをコンピュータにインストールします。 3. すべての要塞ホストに必要な必須アプリケーションのみをインストールし、構成します。ウイルス対策やスパイウェア対策のユーティリティなどが該当します。 4. SCW GUI を起動し、\[新しいセキュリティポリシーの作成\] を選択して、参照コンピュータを指定します。 5. Web サーバーなど、検出されたサーバーの役割が要塞ホストに適していることを確認します。その他のサーバーの役割はすべて削除します。 6. 検出されたクライアント機能が環境に適していることを確認します。不要なクライアント機能をすべて削除します。たとえば、**Microsoft ネットワーククライアント**機能と **DHCP クライアント**機能を削除して、サーバー攻撃の危険性を低くする必要があります。 7. 最大限の保護を実現するため、Windows ファイアウォールを除く管理オプションをすべて削除します。その他のオプションを残しておくと、要塞ホストを管理しやすくなりますが、反面、攻撃の危険性が増大します。要塞ホストの正常運用に必ずしも必要ではないオプションについては、その利点と潜在的なセキュリティリスクとを慎重に比較検討してください。 8. ベースラインに必要な追加サービス、たとえばバックアップエージェントやウイルス対策ソフトウェアが検出されていることを確認します。 9. 環境で指定されていないサービスの扱いを決定します。セキュリティをさらに向上させるため、このポリシー設定を \[無効\] にします。この設定は、運用ネットワークに展開する前にテストしてください。運用サーバーが、参照コンピュータに複製されていない追加サービスを実行する場合に、問題が発生することがあります。 10. \[ネットワークセキュリティ\] セクションで \[このセクションをスキップする\] チェックボックスがオフであることを確認し、\[次へ\] をクリックします。前の手順で特定した適切なポートとアプリケーションが、Windows ファイアウォールの例外として構成されます。要塞ホストの機能に必要なポートを除くポートをすべてオフにします。 11. \[レジストリの設定\] セクションで、\[このセクションをスキップする\] チェックボックスをオンにし、\[次へ\] をクリックします。これらのポリシー設定は、付属の INF ファイルからインポートされます。 12. \[監査ポリシー\] セクションで、\[このセクションをスキップする\] チェックボックスをオンにし、\[次へ\] をクリックします。これらのポリシー設定は、付属の INF ファイルからインポートされます。 13. 適切なセキュリティテンプレート (SSLF-Bastion Host.inf など) を含めます。 14. ポリシーを適切な名前 (Bastion Host.xml など) で保存します。 #### SCW を使用してポリシーをテストするポリシーを作成して保存したら、テスト環境に展開することを強くお勧めします。テストサーバーが運用サーバーと同じハードウェアおよびソフトウェア構成であることが理想的です。こうすることで、特定のハードウェアデバイスに予期しないサービスが必要になった場合などの、潜在的な問題を検出して解決できるようになります。要塞ホストの役割のコンピュータはドメインに接続されないので、設定の適用に SCW を使用する必要があります。ドメインなしでグループポリシーを使用することはできません。ポリシーをテストする目的は、そのポリシーを対象サーバーに適用しても重要な機能に悪影響が及ばないことを確認することです。構成の変更を適用したら、コンピュータの主要な機能を検証する必要があります。たとえば、証明機関 (CA) として構成されているサーバーの場合は、クライアントが証明書を要求して取得できること、証明書失効リストをダウンロードできることなどを確認します。ポリシーの構成に問題がないことを確認したら、次に示す手順に従って、Scwcmd を使用して、ポリシーを GPO に変換します。 SCW ポリシーのテスト方法の詳細については、https://technet2.microsoft.com/WindowsServer/ja/Library/5254f8cd-143e-4559-a299-9c723b3669461041.mspx?mfr=true* *の『[セキュリティの構成ウィザードの展開ガイド](https://technet2.microsoft.com/windowsserver/ja/library/5254f8cd-143e-4559-a299-9c723b3669461041.mspx?mfr=true)』および https://go.microsoft.com/fwlink/?linkid=43450 の「[Security Configuration Wizard Documentation](https://go.microsoft.com/fwlink/?linkid=43450)」(英語情報) を参照してください。 #### ポリシーを実装するポリシーを徹底的にテストしたら、次の手順に従って実装します。 1. SCW GUI を起動します。 2. \[既存のセキュリティポリシーの適用\] を選択します。 3. 前の手順で作成した XML ファイル (Bastion Host.xml など) を選択します。 4. SCW ウィザードを終了して、設定を適用します。 SCW セキュリティポリシーファイルに Windows ファイアウォールの設定が含まれている場合、この手順を正常に完了するには、ローカルコンピュータで Windows ファイアウォールが有効になっている必要があります。Windows ファイアウォールが有効であることを確認するには、\[コントロールパネル\] を開き、\[Windows ファイアウォール\] をダブルクリックします。次に、最後のテストを実行して、SCW により意図した設定が適用されることを確認します。この手順を完了させるために、設定が適切であること、機能がその影響を受けないことを確認します。 [](#mainsection)[ページのトップへ](#mainsection) ### まとめ Windows**Server**2003 SP1 を実行する要塞ホストサーバーは、ファイアウォールなどの他のデバイスによっては保護されず、外部からの攻撃にさらされます。要塞ホストサーバーは、できる限り、可用性を最大限にしながら、被害を受ける可能性を最小限に抑えるために、セキュリティ保護する必要があります。セキュリティが最高レベルの要塞ホストサーバーでは、そのサーバーへのアクセスを信頼できるアカウントのみに制限し、有効にするサービスもそのサーバーの機能を完全に実行するために必要なものだけに限定します。この章では、要塞ホストサーバーのセキュリティをさらに強化するために使用する設定と手順について説明しました。この設定の多くは、ローカルグループポリシーを使用して適用することができます。また、設定を手動で構成し適用する方法についても説明しました。 #### 関連情報 Windows Server 2003 SP1 を実行する要塞ホストサーバーのセキュリティ強化に関する詳細情報は、以下のリンクから参照できます。 - プライベートネットワーク構築の詳細については、www.wiley.com/legacy/compbooks/press/0471348201\_09.pdf の「[Firewalls and Virtual Private Networks](https://www.wiley.com/legacy/compbooks/press/0471348201_09.pdf)」(Elizabeth D. Zwicky、Simon Cooper、および Brent D. Chapman at 著) (英語情報) を参照してください。 - ファイアウォールとセキュリティの詳細については、https://www.itmweb.com/essay534.htm の「[Internet Firewalls and Security – A Technology Overview](https://www.itmweb.com/essay534.htm)」(Chuck Semeria 著) (英語情報) を参照してください。 - 多層防御モデルの詳細については、https://usmilitary.about.com/careers/usmilitary/library/glossary/d/bldef01834.htm にある、米軍の「[About defense in depth](https://usmilitary.about.com/careers/usmilitary/library/glossary/d/bldef01834.htm)」ページ (英語情報) を参照してください。 - 侵入者に対する防御策の詳細については、https://www.cert.org/tech\_tips/intruder\_detection\_checklist.html の「[Intruder Detection Checklist](https://www.cert.org/tech_tips/intruder_detection_checklist.html)」(Jay Beale 著) (英語情報) を参照してください。 - 要塞ホストをセキュリティ強化する方法については、https://www.sans.org/rr/whitepapers/basics/420.php にある、SANS Info Sec Reading Room の記事「[Hardening Bastion Hosts](https://www.sans.org/rr/whitepapers/basics/420.php)」(英語情報) を参照してください。 - セキュリティの構成と分析ツールのトラブルシューティングの詳細については、https://support.microsoft.com/?kbid=279125 のマイクロソフトサポート技術情報「[セキュリティの構成と分析ツールに複数のテンプレートをインポートした後に、問題](https://support.microsoft.com/?kbid=279125)」を参照してください。 - サイトのセキュリティの詳細については、https://www.faqs.org/rfcs/rfc2196.html の「[Site Security Handbook](https://www.faqs.org/rfcs/rfc2196.html)」(英語情報) を参照してください。

ページのトップへ

Last updated on 2019-12-06