マイクロソフトの Securing Windows 2000 Server ソリューション: 第 7 章 ‐ 特定サーバーの役割のハードニング

  • [アーティクル]

第 7 章 ‐ 特定サーバーの役割のハードニング

トピック

Active Directory ドメイン コントローラの役割

インフラストラクチャ サーバーの役割

ファイルとプリント サーバー の役割

IIS サーバー の役割

まとめ

第 6 章では Microsoft Windows 2000 サーバー用グループ ポリシーを使い、セキュリティで保護されたベースラインを開発および導入する方法を Contoso 社のシナリオで詳細に説明しました。このようなサーバー群にセキュリティで保護されたベースラインを確立した後に、組織のインフラストラクチャで果たす役割に従って各サーバーのセキュリティを保護する方法を考えます。

この章では、Windows 2000 Server を使用している組織の多くが運用している次の 4 つの重要な役割に必要な環境を作る上で推奨しているセキュリティ設定を示します。

  • Microsoft Active Directory ディレクトリ サービスのドメイン コントローラ

  • DHCP (Dynamic Host Configuration Protocol) と WINS (Windows Internet Naming Services) サービスを提供するインフラストラクチャ サーバー

  • ファイル サーバーとプリント サーバー

  • IIS (Internet Information Services)

このような環境の各サーバーでは、一連のアプリケーション サービスを提供しており、このサービスの指示により、最大限の可用性と信頼性を保証するうえでサービスに適用が必要な、補完的セキュリティ設定を定めています。このようなセキュリティ設定を適用することによって、サーバーからアクセス可能なデータの保護が保証されます。

第 6 章「Base Windows 2000 Server のハードニング」の MSBP (Member Server Baseline Policy) で詳述しているように、グループ ポリシーを使い、Windows 2000 Server にできるだけ多くのセキュリティ強化機能を適用します。

グループ ポリシー設定は、サーバー の役割ごとに対応する GPO (Group Policy Object) にインポートされる個々のセキュリティ テンプレートに格納されます。GPO は、グループ ポリシー設定の集まりであり、Windows 2000 ベース環境でセキュリティ設定を定義する際に使用されます。

たとえば、このシナリオの IIS サーバーのセキュリティを保護するには、グループ ポリシー設定は、MSS IIS Role.inf のセキュリティ テンプレートに格納されます。このテンプレートは IIS グループ ポリシー用の GPO にインポートされ、これは Contoso 社の子ドメイン内の Web 組織単位 (OU) にリンクされています。

Contoso 社の Active Directory 内における GPO の場所は次の図に示されています。

図 7.1: サーバー の役割ごとのセキュリティ テンプレートは、その役割に対応する OU にリンクした適切なグループ ポリシー オブジェクトにインポートされます

サーバー の役割ごとのセキュリティ テンプレートに含まれる上図の設定は、この章で定義します。ただし、セキュリティ強化手順の中にはグループ ポリシーで自動化できないものもあります。このような場合のために、この章の最後にポリシーごとの具体的な推奨手順を記載しています。

第 6 章「Base Windows 2000 Server のハードニング」セクションで詳述する MSS Baseline.inf のセキュリティ テンプレートは、MSS DCBaseline Role.inf. と呼ばれるセキュリティ テンプレートのベースとしても使用されます。MSS Baseline.inf と MSS DCBaseline Role.inf セキュリティ テンプレートの違いについては、この章の「ドメイン コントローラ グループ ポリシー」セクションで説明します。

Active Directory ドメイン コントローラの役割

ドメイン コントローラ サーバーの役割は、Windows 2000 Active Directory のエンタープライズ環境を防御する役割の中でも最も重要な役割の 1 つです。これはドメイン コンピュータが失われたり危害を受けると、ドメイン認証、グループ ポリシー、および中央にある LDAP (Lightweight Directory Access Protocol) ディレクトリなどを利用しているクライアント、サーバー、アプリケーションにとっては壊滅的な状況となるからです。

ドメイン コントローラは重要であるため、権限を持つ管理スタッフのみがアクセスできるセキュリティ保護施設に設置することをお勧めします。ドメイン コントローラを (たとえば支店などの) セキュリティ保護されていない場所に設置する必要がある場合は、物理的な脅威による被害が発生しないようにセキュリティ設定を変更できます。セキュリティ保護されていない場所に設置するドメイン コントローラへの推奨設定がある場合はこの章の中で注記しています。

ドメイン コントローラのベースライン ポリシー

ドメイン コントローラ の役割に対するグループ ポリシーは、この章で詳述している他のサーバー 役割 ポリシーとは異なり、ベースライン ポリシーであり、第 6 章「Base Windows 2000 Server のハードニング」で定義している MSBP (Member Server Baseline Policy) と同じクラスで取り扱われます。これはドメイン コントローラのグループ ポリシーでは、ドメイン コンテナから継承した既定のドメイン ポリシーと、ドメイン コントローラ OU で設定された既定のドメイン コントローラ ポリシー以外のセキュリティ ポリシーは必要ないことを意味します。

ドメイン コントローラのベースライン ポリシーは MSBP に基づいていることから、第 6 章を読んでドメイン コントローラのベースライン ポリシーにも含まれる多数の設定について理解しておくことをお勧めします。ドメイン コントローラ ベースライン ポリシーのほとんどは、MSBP をそのままコピーしたものです。ドメイン コントローラ ベースライン ポリシーの設定で、MSBP と異なるものについては、ここに記載されています。

注 : ディレクトリ サービス (Active Directory コンテンツでオブジェクト、クラス、および属性を含む) の保護については、第 5 章「ドメイン インフラストラクチャをセキュリティで保護する」で述べています。

監査ポリシー設定

ドメイン コントローラ ベースライン ポリシーの監査ポリシー設定は、MSBP で定められているものと同じです。このベースライン ポリシー設定を使用すると、ディレクトリ サービス アクセスを含め、すべての関係するセキュリティ監査情報は確実にドメイン コントローラにログされます。

イベント ログ設定

ドメイン コントローラ ベースライン ポリシーのイベント ログ設定は、MSBP で定められているものと同じです。

ユーザー権利の割り当て

既定のドメイン コントローラ ポリシーでは、ドメイン コントローラのユーザー権利の割り当てについていくつかの点で定義されています。既定の設定に加えて、ドメイン コントローラのセキュリティを強化させるために設定することをお勧めしているユーザー権利が 2 つあります。

  • ローカル ログオン

  • システムのシャットダウン

これらの権利の推奨設定を次の表に示します。

表 7.1 ドメイン コントローラ ベースライン ポリシーのユーザー権利設定

UI でユーザー権利設定 割り当てグループ 推奨
ローカル ログオン Administrators
Backup Operators
Server Operators		 アカウント管理のみに使用する Account Operators および Print Operators を削除。ドメイン コントローラ上でプリンタ共有を許可するべきではありません。
システムのシャットダウン Administrators
Server Operators		 ドメイン コントローラをシャットダウンする権限を持たない、Account Operators、Backup Operators、および Print Operators を削除。

ローカル ログオン

脆弱性

ローカル ログオンの権限があるアカウントであれば、ドメイン コントローラのコンソールからログオンできます。ネットワーク経由でターミナル サービスを利用するアカウントには、ローカル ログオンのユーザー権利も必要です。ユーザーがターミナル サービスを利用してサーバーにログオンを試みる場合には、ターミナル サービスの RDP (Remote Desktop Protocol) のゲスト アクセスまたはユーザー アクセス許可を持つアカウントを使用する必要があります。

認証されていないユーザーにはローカル ログオンを許可しないことがベスト プラクティスです。ドメイン コントローラの場合、通常、このベスト プラクティスは Account Operators と Printer Operators のグループにも適用されます。認証されていないユーザーがこの特権により、新しいコードをダウンロード、表示、およびインストールする権利を与えられることになれば、ローカル ログオン アクセスを必要とする特権の脆弱性が拡大されてしまいます。

対応策

既定で存在する Account Operators と Print Operators の 2 グループを削除します。いずれのグループにも、現在の環境ではドメイン コントローラにログオンする権利は不要です。これはドメイン コントローラ ベースライン ポリシーを通じて実施します。

または、これらのグループをドメイン コントローラ ベースライン ポリシーの「ローカル ログオンを拒否」設定に追加することもできます。この特権設定は、ドメイン コントローラ ベースライン ポリシーのテンプレートで構成できます。

予想される影響

これらの既定グループを削除すると、現在の環境でユーザー の役割として割り当てられている委任能力が制限される場合があります。委任活動が制限されないことを確認します。

Contoso 社のシナリオ

Administrators、Backup Operators、および Server Operators のみに Contoso 社のドメイン コントローラにローカル ログオンできる特権を与えます。Backup Operators はバックアップ ソフトウェアをサポートする際に、この特権とサービス アカウントを必要とします。Server Operators は、ドメイン コントローラをシャットダウンする際にこの特権を必要とします。ドメイン コントローラをシャットダウンするために、ログオンすることが必要になるからです。

この設定は、ドメイン コントローラ ベースライン ポリシーのテンプレートからこれらの既定グループを削除するために構成されました。

システムのシャットダウン

脆弱性

ドメイン コントローラをシャットダウンする権限を与えるのは、信頼できる少数の管理者のみに制限することをお勧めします。システムのシャットダウンには、サーバーへのログオン権限が必要ですが、ドメイン コントローラのシャットダウンを許可するアカウントとグループには特に注意を払うことをお勧めします。詳細については、第 6 章「システムをシャットダウンするのにログオンを必要としない」セクションの設定を参照してください。

ドメイン コントローラをシャットダウンすると、ログオン処理、グループ ポリシー サービス、および LDAP クエリへの応答のような機能を実行できなくなります。FSMO (Flexible Single-Master Operations) 役割を持つドメイン コントローラをシャットダウンすると、これらのサーバーが新パスワードによるログオン処理 (PDC エミュレータ 役割) などの主要ドメイン機能を無効にできるため影響があります。

対応策

システムのシャットダウン特権を許可するドメイン コントローラ グループ ポリシーから、Account Operators、Backup Operators、および Print Operators の 3 つの既定グループを削除します。これらの既定グループには、ドメイン コントローラをシャットダウンできる能力は必要ありません。

その代わり、ドメイン コントローラをシャットダウンする能力を別グループに委任したい場合には、委任できます。ただし、ユーザーがドメインで認証されなくなるため、通常は中央の認証データベースはシャットダウンしたくないものであることを認識しておいてください。

予想される影響

これらの既定グループを削除すると、現在の環境で割り当てている役割の委任能力を制限する場合があります。委任活動が制限されないことを確認します。

Contoso 社のシナリオ

Contoso 社のドメイン コントローラでは、Administrators と Server Operators のみがシステムをシャットダウンできる特権を持つものとします。Backup Operators は、ソフトウェアのバックアップ作業にこの特権を必要としません。Server Operators は、Administrators のメンバシップを許可されなくても、ドメイン コントローラをシャットダウンする権限を委任される場合がよくあるため、この特権を必要とします。

この設定は、これらの既定グループを削除するために、ドメイン コントローラ ベースライン ポリシーのテンプレートで構成されました。

セキュリティ オプション

次の表では、セキュリティ オプション設定の概要を示していますが、MSBP の設定とは異なり、ドメイン コントローラのコンテキストで特別な考慮を必要とします。これらの設定では、ドメイン コントローラとの接続性をサポートするために、既定のクライアント構成に特別な変更は必要としませんでした。

表 7.2 ドメイン コントローラ ベースライン ポリシーのセキュリティ オプション設定

UI を使用するセキュリティ オプション設定 推奨 コメント
匿名接続のための追加制限 SAM (Security Accounts Manager) アカウントと共有の列挙を許可しません。 第 6 章の MSBP 推奨に同じ。ドメイン コントローラの場合は特に重要です。
サーバー オペレータがタスクをスケジュールすることを許可します (ドメイン コントローラのみ) 無効。 サーバー オペレータはドメイン コントローラではこのレベルの特権を必要としません。
常にデジタル署名によるクライアント通信 無効。 第 6 章の MSBP と同様、この設定を有効にすることにより、サーバーの性能に明らかな影響があります。
常にデジタル署名によるサーバー通信 無効。 第 6 章の MSBP と同様、この設定を有効にすることにより、サーバーの性能に明らかな影響があります。
LAN マネージャ認証レベル NTLMv2 (NTLM version 2) 応答のみを送信。 第 6 章の MSBP と同様、Windows 98 SE クライアントのサポートに必要です。
キャッシュするログオン回数 (ドメイン コントローラを利用できない場合) 値を 0 に設定。 ドメイン アカウント ログオンのキャッシングをサポートする理由がありません。これらのサーバーこそがドメイン コントローラだからです。
セキュリティ保護されているチャネル : セキュリティ保護されているチャネル データを常にデジタル暗号化またはデジタル署名 無効。 第 6 章の MSBP に同じ。ローカル ドメインと信頼関係にあるドメインで Windows 98 SE クライアントおよび SP5 (Service Pack 5) 以下の Microsoftｮ Windows NTｮ Version 4.0 のドメイン コントローラ。

表 7.2 に示したセキュリティ オプションにはさらに説明を加えた方が良いものがあります。以下に、Contoso 社向けシナリオに合わせたドメイン コントローラに実装した設定の背景となる事柄を説明します。

匿名接続のための追加制限

ドメイン コントローラは、匿名アクセスを行うクライアントのニーズが特に重要であると考えています。この理由から、ドメイン コントローラでは次の種類の機能をサポートする匿名接続を許可する必要があります。

  • フォレスト間の信頼関係

  • Windows NT 4.0 ドメインとの信頼関係

  • ドメイン ユーザー アカウントのグループ メンバシップを参照するための Windows NT 4.0 RRAS (Routing and Remote Access Services) サーバー

  • ドメイン ログオンのためにセキュリティで保護された接続を有する Windows 98 SE と Windows NT 4.0 クライアント

サーバー オペレータによるタスクのスケジュールを許可 (ドメイン コントローラのみ)

脆弱性

Server Operators グループに属す正式ユーザーは、ドメイン コントローラ グループでタスクをスケジュールすることができます。Scheduler Service は既定により、システムとして動作するため、Server Operators のメンバシップを持つ攻撃者なら、この特権を活用できます。たとえば、攻撃者は攻撃者のアカウントを Domain Administrators グループに追加するタスクをスケジュールすることができます。

対応策

サーバー オペレータによるタスクのスケジュールを許可 (ドメイン コントローラのみ) の値を無効と設定する。

予想される影響

ドメイン管理者特権を有するユーザーのみが、ドメイン コントローラの Scheduler Service 経由でタスクをスケジュールできるようになります。

Contoso 社のシナリオ

Contoso 社のシナリオでは、管理者のみがドメイン コントローラでタスクをスケジュールする能力を必要とします。グループ ポリシーは、サーバー オペレータによるタスクのスケジュールを許可 (ドメイン コントローラのみ) を無効に設定するために利用されました。

デジタル署名によるクライアントとサーバー間の通信

系となる可能な場合にデジタル署名によるクライアント通信設定をすべてのクライアント コンピュータ上で有効にしてから、ドメイン コントローラで常にデジタル署名によるクライアント通信 設定を有効にすることをお勧めします。これらの設定をこの順序で有効にすることにより、ドメイン クライアントはドメイン コントローラと正常に通信できるようになります。

LAN Manager 認証レベル

Windows 2000 ドメイン コントローラの場合は、すべてのクライアントがまずドメインに参加できるだけでなく、ドメインに参加し続けられるようにするために、ドメイン コントローラによって認証可能であることが重要です。また、ドメイン コントローラは他のドメインにある (フォレスト間または Windows NT 4.0 ドメインを含む) ドメイン コントローラに認証され、フォレスト外で資格情報を確認できることも非常に重要です。このような操作には、両方とも LAN (Local Area Network) Manager (Kerberos version 5 ではない認証プロトコル) による認証が必要です。

(Windows 2000 および Microsoft Windows XP を含む) すべての Windows クライアントは、既定で LAN Manager (LM) および NTLM 認証応答を送信する構成となっています (LM のみを送信する Windows 9x クライアントを除く)。既定では、NTLMv2 認証応答は送信しません。したがって、Windows 2000 ドメイン コントローラで NTLMv2 認証を強制することは、すべてのクライアント (およびフォレスト外にあり、信頼関係でつながっているドメイン コントローラ) が NTLMv2 応答を送信できるように再構成されるまでは不可能です。

キャッシュするログオン回数

脆弱性

Windows ドメイン クライアントで、ログオンのキャッシュを許可するのは頻繁に見られますが、ドメイン コントローラでドメイン ログオンをキャッシュすることは原則として必要ありません。これは、ドメイン コントローラが自分自身のドメイン資格情報を確認しないということが不可能だからです。

対応策

ドメイン コントローラでは、キャッシュするログオン回数 (ドメイン コントローラを利用できない場合) 設定を 0 にして構成します。

予想される影響

ドメイン コントローラへのキャッシュ ログオンを無効にすることにより、他ドメインのすべてのドメイン コントローラにアクセス不能であれば、以前認証したアカウントを他のドメインからドメイン コントローラで認証することは不可能となります。たとえば、Contoso 社の子ドメインで Contoso 社のすべてのルート ドメイン コントローラにアクセス不能な場合、エンタープライズ管理のようなアカウントでも子ドメイン コントローラにログオンすることはできません。

このような事態の影響は継続するものではなく、アクセス不能であったドメイン コントローラへのアクセスが正常に戻るとすぐに解決されます。

Contoso 社のシナリオ

グループ ポリシーは、ドメイン コントローラ ベースライン ポリシーのキャッシュするログオン回数 (ドメイン コントローラが利用できない場合) 設定の値を 0 に構成するために使われました。

セキュリティ保護されているチャネル : 常にデジタル暗号化またはデジタル署名でセキュリティ保護されているチャネル データ

「セキュリティで保護されているチャネル」のデジタル暗号化とデジタル署名がサポートされている場合は、調べる価値があります。ただし、セキュリティで保護されたチャネルのデジタル暗号化とデジタル署名は、Windows NT 4.0 SP6a 以降でのみサポートされ、Windows 9x のクライアントではサポートされていません。このように、Windows 9x クライアントをドメイン メンバとしてサポートする必要がある場合には、この設定をドメイン コントローラで有効にすることはできません。

この設定と関係しているその他の「可能な場合の」設定が 1 つでもドメイン コントローラに適用されていれば、署名または暗号化が強制されるのみです。これらのいずれの設定も適用されていない場合、ドメイン コントローラには何の影響も与えません。ただし、その他設定のいずれかがドメイン コントローラで有効になった場合には、次の条件が満たされるまでこの設定を有効にできません。

この設定による影響としては、下位方向の信頼関係の作成、削除の無効化、下位クライアントからのログオンの無効化、および下位の信頼関係にあるドメインで他のドメイン ユーザーの認証ができなくなることが考えられます。

以下のすべての条件が真である場合、この設定は対象となるドメイン コントローラでのみ有効にすることをお勧めします。

  • すべての Windows 9x クライアントがドメインから削除されている。

  • (信頼関係にあるドメインまたは信頼しているドメインの) すべての Windows NT 4.0 クライアント、サーバー、およびドメイン コントローラが SP6a にアップグレードされている。

  • すべての Windows クライアントが、「セキュリティで保護されているチャネル： 可能ならデジタル暗号化でデジタル保護されているチャネル データ」または、「セキュリティで保護されているチャネル：可能ならデジタル暗号化でデジタル保護されているチャネル データ」を有効にする構成となっています。これらの設定のいずれかまたは両方をドメイン コントローラで有効にする必要があります。

システム サービス

ここにはすべての Windows 2000 ドメイン コントローラで有効にする必要があると定められているシステム サービスの要約を示しています。このシステム サービスは SCI DCBaseline Role.inf のポリシー テンプレートで構成され、ドメイン コントローラ ポリシーの GPO にインポートされます。

表 7.3 ベースライン ポリシーで必須のドメイン コントローラ サービス

UI のサービス名 スタートアップの種類 コメント
分散ファイル システム (DFS) 自動 Active Directory の Sysvol 共有に必要
ファイル複製サービス 自動 ドメイン コントローラ間のファイル複製に必要
サイト間メッセージング 自動 Active Directory による複製をサポートするために必要
Kerberos キー配布センター 自動 ユーザーが Kerberos V5 プロトコルを使用してネットワークにログオンできるようにします。
リモート プロシージャ コール (RPC) ロケータ 自動 ドメイン コントローラが RPC ネーム サービスを提供できるようにします。

この他にも Windows 2000 ドメイン コントローラで一般的に有効にするサービスがありますが、すべての組織で必須ではありません。これらのサービス向けに推奨される設定は、Contoso 社向けシナリオには適していますが、議論の対象となることが多く、検討中の環境には適用可能ではない場合があります。

表 7.4 ドメイン コントローラ サービスの追加検討項目

UI のサービス名 スタートアップの種類 コメント
DNS サーバー 自動 Contoso 社の環境では、Active Directory 統合 DNS が使用されています。
IIS Admin Service 無効 SMTP ベースの Active Directory 複製機能は Contoso 社環境では有効にされていないため、IIS Admin Service は必要ありません。
NT LM セキュリティ サポート プロバイダ 自動 名前付きパイプ以外のトランスポートを使用する RPC プログラムにセキュリティを提供。
SMTP (Simple Mail Transport Protocol) 無効 SMTP ベースの Active Directory 複製機能は、Contoso 社環境では有効ではありません。

注 : Windows 2000 サポート ツールから DCDiag.exe ユーティリティを作動すると、現在の環境のドメイン コントローラから作動できる全サービスをチェックします。IISADMIN、SMTPSVC、および TrkSvr を始め、ドメイン コントローラ ベースライン ポリシーで無効になっているサービスがあるため、DCDiag.exe はエラーを報告します。これは既に分かっていることなので、現在の構成では問題ありません。

DNS サーバー

脆弱性

DNS サーバーは、Active Directory 統合 DNS サービスのサポートに必要です。DNS サーバーは、Windows 2000 Server で動的 DNS 更新をサポートするために使用されます。

動作しているサービスやアプリケーションは潜在的な攻撃対象です。動作していないサービスとコンポーネントを効果的に攻撃することはできません。したがって、セキュリティでしっかりと保護されたシステムを作るには、攻撃可能な状態に「見えるところ」を削減するために不要な機能を停止するのがベスト プラクティスです。

対応策

なし。このサービスは必要。

別の方法として、「Active Directory 統合」 DNS が必要ない場合、このサービスはドメイン コントローラで無効とし、インフラストラクチャ サーバーの役割として有効にすることもできます。このインフラストラクチャ サーバー 役割は、DNS サーバー サービスをプライマリまたはセカンダリ DNS サーバーとして動作させることができます。

予想される影響

必要に応じて Active Directory 統合の DNS サービスを無効にすると、複製、ログオン、およびグループ ポリシーを含め、すべてのドメイン操作が失敗に終わります。これは Microsoftｮ Exchange 2000 など、Active Directory 統合アプリケーション機能のエラーも引き起こします。

Contoso 社のシナリオ

Contoso 社の環境では、Active Directory 統合 DNS を必要としますので、DNS サーバー サービスのスタートアップの種類を自動として構成します。

サイト間メッセージング

脆弱性

このサービスは、Active Directory KCC (Knowledge Consistency Checker) で必要です。このサービスは、サイト間における SMTP ベースの Active Directory 複製をサポートするためにも使います。複製で使用する個別のトランスポートは、別にあるアドイン用 DLL (Dynamic Link Library) で定義されます。アドイン用 DLL は、サイト間メッセージングにローディングされます。

サイト間メッセージング機能は、トランスポート用の適切なアドイン DLL への送受信要求を指示し、次に宛先コンピュータのサイト間メッセージング機能にメッセージをルーティングします。自分の環境で複製を行うために SMTP を使用する場合には、このサービスを有効にする必要があります。

動作しているサービスやアプリケーションは潜在的な攻撃対象です。逆に、動作していないサービスとコンポーネントを効果的に攻撃することはできません。したがって、セキュリティでしっかりと保護されたシステムを作るには、攻撃可能として見えているところを削減するために不要な機能を停止するのがベスト プラクティスです。

対応策

サイト間メッセージング サービスのオプションは、ドメイン コントローラ ベースライン ポリシーで、自動に設定することをお勧めします。

逆に、手動で複写するトポロジを生成することを望み、KCC サポートの必要性を感じないのであれば、このサービスを無効にすることができます。

予想される影響

なし。

Contoso 社のシナリオ

Contoso 社環境では、複製トポロジの計算を KCC に依存しており、サイト間メッセージング サービスは必要で、このサービスはドメイン コントローラ ベースライン ポリシーで有効となりました。

IIS Admin Service

脆弱性

SMTP サービスは IIS Admin サービスに依存するため、SMTP サービスを有効にする場合は、IIS Admin サービスも有効にする必要があります。

上述したように、動作しているサービスやアプリケーションは潜在的な攻撃対象です。したがって、現在の環境でセキュリティでしっかりと保護されたシステムを作るには、不要な機能を停止するのがベスト プラクティスです。

対応策

ドメイン コントローラ ベースライン ポリシーの IIS Admin サービス向けオプションを無効に設定します。

別の方法として、SMTP ベースで複製を行う必要があるなら、ドメイン コントローラ ベースライン ポリシーで、このサービスを自動スタートアップに設定することをお勧めします。

予想される影響

このサービスは SMTP サービスの正常動作に必要なサービスであるため、IIS Admin サービスを無効にすると、SMTP ベースでの Active Directory 情報の複製も無効になります。SMTP ベースの複製を行う際に、速度が遅く遅延の大きなリンクを通過する必要がある場合には、この設定ではこのような Active Directory 複製はできなくなります。このため、このサービスの設定は自動にすることをお勧めします。

Contoso 社のシナリオ

Contoso 社の環境は、Active Directory サイト間の高速リンクで構成されているため、SMTP ベースで複製する必要はなく、このサービスは無効としました。

NTLM セキュリティ サポート プロバイダ

脆弱性

NTLM セキュリティ サポート プロバイダは、RPC アプリケーション用の NTLM SSPI (Security Support Provider Interface) をサポートし、このアプリケーションは RPC メッセージ セキュリティ用の SSPI を呼び出します。このサービスは Windows 2000 サーバーが動作するためには必須です。

NTLM SSPI を使用すると、RPC アプリケーションは NTLMv2 認証プロトコルを使わなくても、これより弱い LM または NTLM 認証プロトコルを使って、ドメイン コントローラに認証を依頼できます。

対応策

なし。既定で有効となるこのサービスは、アプリケーションの互換性に必要な場合があります。

状況によって、このサービスは無効になっている場合がありますが、Windows 2000 で動作する一部の古いアプリケーションをサポートするサービスとしては必須です。このサービスを無効にしたい場合は、ドメイン コントローラで動作させるか、ドメイン コントローラにアクセスするすべてのアプリケーションをまずテストし、NTLM SSPI がなくてもアプリケーションが動作するかどうかを確認することをお勧めします。

(より強力な NTLMv2 と Kerberos 認証プロトコルを使うために) 現在の環境から LM と NTLM 認証を取り除くには、調査、計画、およびテストが必要となります。最初に以下のマイクロソフト サポート技術情報を参照することをお勧めします。

  • 147706 「Windows NT 上の LM 認証を無効にする方法」

  • 239869 「Windows 95/98/2000 および NT で NTLM-2 認証を有効にする方法」

予想される影響

このサービスを有効にすることにより、組織のドメイン コントローラで認証する、比較的弱い LM および NTLM プロトコルを使用できます。これはドメイン コントローラのクライアントで NTLMv2 を使用することにより緩和できます。

Contoso 社のシナリオ

Contoso 社環境の多数のシナリオに対応できる NTLM セキュリティ サポート プロバイダ サービスが必要です。このため、このサービスはドメイン コントローラ ベースライン ポリシーで有効になるように設定しました。

SMTP (Simple Mail Transport Protocol)

脆弱性

ドメイン コントローラで SMTP サービスを使用することにより、他のドメイン コントローラが、既定の RPC プロトコルではなく、SMTP プロトコルを使い、サイトにまたがって Active Directory 更新を複製できます。このサービスは、ドメイン コントローラを含み、サイト間で非常に遅いか、または遅延の大きいネットワーク リンクを使って複製を行う場合には便利であり、組織としてファイアウォールのような内部ネットワーク境界を超える RPC を許可していない場合に必要です。

RPC または SMTP を使うと、サイト間複製が発生する場合があります。使用している環境でサイト間複製を行うために SMTP を使用する場合は、この SMTP サービスを有効にする必要があります。

SMTP の脆弱性は次の 2 つの点です。

  1. リモートでデータを待ち受け、送信データに応じて動作するタイプのサービスであるため、SMTP はバッファ オーバーフローにより使えなくなる可能性があります。

  2. SMTP サーバーはドメイン ユーザー アカウントを使用し、入力 SMTP 要求の認証を行うことができます。ただし、SMTP サーバーには Active Directory のパスワード ポリシーが義務づけている通常のアカウント ロックアウト ロジックが適用されないため、攻撃者は通常のロックアウトや遅延を受けることなく、ドメイン アカウントのパスワードを何度も再試行することができます。

対応策

SMTP ベースの Active Directory 複製が必要ない場合、ドメイン コントローラ グループ ポリシーで SMTP サービスのオプションを無効に設定することをお勧めします。

あるいは、SMTP サービスを無効にしたくなければ、アクセス接続フィルタ — SMTP サーバー プロパティ、[アクセス] タブ、および [接続] ボタン — または指定 IP (Internet Protocol) アドレス以外からの TCP ポート 25 への接続をすべてブロックする IPSec (Internet Protocol Security) フィルタを使い、SMTP サービス自体のセキュリティを保護する方法を調べることができます。IPSec はネットワーク通信のネットワーク層またはパケット処理層向けに開発中のセキュリティ標準です。これは、VPN (Virtual Private Networks) の実装、および個々の IP ホスト間の IP データの認証や暗号化に役立ちます。

SMTP ベースの Active Directory 複製を行う必要があるドメイン間で複製を行う複製パートナーの場合にのみ、SMTP サービスを有効にすることも考慮することをお勧めします。

注 : SMTP 複製を可能にする場合、SMTP 複製パートナーシップに参加する各ドメイン コントローラでデジタル証明書を作成する必要があります。詳細については、付録 F 「セキュリティ保護された LDAP と SMTP 複製用にドメイン コントローラでデジタル証明書を作成」を参照してください。

予想される影響

ドメイン コントローラで SMTP を無効にすることにより予想される影響は、これらのドメイン コントローラで SMTP ベースの Active Directory 複製を構成している (この場合には複製は失敗します) 場合以外は最小限にとどまります。

Contoso 社のシナリオ

Contoso 社環境での Active Directory 複製はすべて、IP (別名 RPC) トランスポート経由で行われるように構成しました。このため、SMTP サービスは無効としました。

レジストリ アクセス コントロール リスト (ACL)

MSBP で推奨されているレジストリ ACL (Access Control List) を超える形での変更はしないことをお勧めします。

ファイル アクセス コントロール リスト (ACL)

脆弱性

%SystemDrive% (通常は C パーティション) 以外のすべての新規作成ボリュームに対するファイルアクセス許可 ACL は、既定の Everyone: フル コントロールです。これは、このようなボリュームに追加したファイルやフォルダは一般的に Everyone: フル コントロールのアクセス許可を引き継ぐことを意味します。

このようなボリューム上に作成されたファイル共有は、既定でファイル アクセス許可を持つユーザーに共有対象ファイルを露出します。これらのファイルは、次に STRIDE (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) モデルで定義され、データの情報開示と変更という脅威にさらされることになります。このような危険性の詳しい説明については、第 2 章「セキュリティの概要を定義する」の脅威の分類の箇所を参照してください。

ドメイン コントローラ ベースライン ポリシーで有効とする唯一のファイルアクセス許可 ACL の変更は、%SystemDrive% についてのものです。

%SystemDrive% (たとえば、D、E、および F パーティション) と一緒に作成した、追加固定ボリュームのファイル アクセス許可を更新することをお勧めします。これは、Active Directory データベース、DNS ログ ファイル、およびその他の機密情報データ ファイルを含むパーティションの場合に特に適しています。

対応策

Administrators、Creator/Owner、および SYSTEMが継承可能なフル コントロールを有効にすることにより、すべてのシステム外ディスク パーティションの既定のアクセス許可を構成します。他のグループまたはユーザーには許可を与えません。このようなアクセス許可を Creator/Owner に与えることで、システムは Administrators グループというよりはむしろ、個々の管理者に所有権を割り当てることができます。

また、各ボリュームのルートには別のアクセス許可を選択したいと思うかもしれません。ただし、少なくとも DNS ログおよび、Active Directory データベースとログ ファイルのフォルダへのアクセス許可はロックダウンされ、Administrators と SYSTEM に対してのみ、フル コントロール アクセス許可保証を与えることをお勧めします。

予想される影響

システム外パーティションに既にインストールされているアプリケーションは、既存のアクセス許可が上書きされると正しく動作できなくなります。Windows アプリケーションの中には、インストールされたディレクトリに自分自身のアクセス許可を明白に設定する構成のものがあります。このため、このようなアプリケーションの場合は、ここで推奨しているようにアクセス許可設定変更を適用した上で、常にラボ環境でテストすることをお勧めします。

Contoso 社のシナリオ

%SystemDrive% (通常は C パーティション) のルートへのアクセス許可は、ドメイン コントローラ ベースライン ポリシーで構成され、Administrators、Creator/Owner、および SYSTEM にのみフル コントロールが許可され、このアクセス許可を子フォルダとファイルに継承、伝播できます。他のディスク パーティションについては、アクセス許可は手作業で構成しました。

システム外ディスク パーティション (たとえば E パーティション) でルート フォルダへのアクセス許可を手作業で変更する方法を以下に示します。

  1. コマンド プロンプトを開きます。

  2. cacls e:\ /t /g administrators:F system:F "creator/owner":F というコマンドを入力します。

  3. 先へ進むためにプロンプトで Y と入力します。

セキュリティ設定の追加 — ディレクトリ サービス

ドメイン コントローラで NoLmHash 設定を無効化

脆弱性

NoLmHash 設定を行うと、アカウント データベースの LM ハッシュ記憶域の脆弱性を緩和し、LM チャレンジおよび応答認証の利用を防ぐことができます。

ただし、NoLmHash 設定が MSBP で有効になっている場合でも、Contoso 社のシナリオではドメイン コントローラでこの設定を有効にすることはできません。

これは、Contoso 社のシナリオでは NTLM または NTLMv2 認証を使用できない Windows 98 クライアントをサポートする必要があるからです。Contoso 社の Windows 98 クライアントは LM 認証プロトコルでのみ認証でき、ドメイン コントローラは LM を使った認証機能を持たざるを得ません。このためドメイン コントローラ上に LM ハッシュを格納して使用する必要があり、Contoso 社のすべてのドメイン コントローラで NoLmHash 設定の利用ができなくなっています。

対応策

ドメイン コントローラ上に NoLmHash レジストリ キーが存在しないことを確認します。

予想される影響

LM Hash の作成を無効にできないため、ユーザーのパスワードを代表する LM ハッシュ値を Active Directory に格納し続ける必要があります。ただし、通常はドメイン コントローラに物理的にアクセスすることが困難であるため、攻撃者がアクセスしてくる危険性は、サーバーやワークステーションよりも、ドメイン コントローラ上にあるこのハッシュ機構の方が低いと言えます。物理的なアクセス攻撃を緩和するための詳細情報については、この章の最後に記載している Syskey 利用トピックを参照してください。

LM ハッシュの作成を無効にできないため、ネットワークを超えて LM チャレンジ－応答の認証が発生します。これは Windows のチャレンジ－応答認証の中で最も脆弱なものです。これは Windows 98 SE クライアントのサポートのために必要ですが、ドメイン環境からすべての Windows 9x クライアントがなくなれば必要ありません。

Contoso 社のシナリオ

LM ハッシュ作成の無効化を手動で切り替えることは、ドメイン コントローラでは行われませんでした。NoLmHash キーは、ドメイン コントローラのレジストリの HKLM\SYSTEM\CurrentControlSet\Lsa キーに追加されませんでした。

データ再配置 — Active Directory データベースとログ ファイル

脆弱性

データベースとログ ファイル (ntds.dit、edb.log、および temp.edb) は、ディレクトリ サービスがオンラインの場合は、常に排他的にロックされています。すなわち、これらのファイルを直接読み書きすることはできません。ただし、攻撃者が何らかの方法で、ファイルをロックする (lsass.exe) プロセスを通じてファイルにアクセスできた場合、理論的にはファイルを破壊することは可能です。

Active Directory データベースとログ ファイルについては、システム外ディスク ボリュームに移し、ドメイン コントローラのパフォーマンスを改善するのがベスト プラクティスです。望ましいのはストライピング ボリュームまたは、ストライピング / ミラーリング ボリュームへの移動です。一般的なセキュリティのベストプラクティスでは、このような機密度の高いファイルはシステム ボリュームから別のボリュームに移し、これらのファイルへのディレクトリ走査攻撃のリスクを最小限にすることをお勧めします。

対応策

Active Directory ドメイン コントローラのインストール中に、[store the Database and Log directories on a nonsystem volume] (通常は C: ボリュームではない) を選択します。ストライピング機能またはストライピングやミラーリング配列の高性能ディスク ボリュームが最善の選択です。

または、既に存在しているドメイン コントローラに対しては (ファイルをシステム パーティションからまだ移動していないと仮定した場合)、次の方法で Active Directory データベースとログ ファイルを移動させることができます。

  • 対象ファイルの ACL をシステム外パーティションに変更します。

    注 : 以前にファイル アクセス コントロール リスト (ACL) の ACL を設定した場合、この作業は必要ありません。より高度なセキュリティで保護された ACL がルート フォルダ アクセス許可から伝播されるためです。

  • コンピュータの再起動構成を保護する boot.ini ファイルの ACL を変更することによって、攻撃者がディレクトリ サービスの復元モードを既定の再起動選択としてサーバーを再起動することを防ぎます。

予想される影響

充分なサイズとパフォーマンスを備えたボリュームを選択すれば、インストール中にデータベースとログをシステム外ボリュームに格納してもほとんど影響はありません。

データベースとログを既存のドメイン コントローラに移すと重大な影響を与える可能性があります。操作中にシステムをオフラインにする必要があり、移動手順中にハードウェアが障害を起こすリスクが小さいながらも必ず存在するからです。

このような操作を行う前には必ずシステム状態のバックアップを作成することをお勧めします。手順の詳細情報については、サポート技術情報記事 257420 「HOW TO: Move the Ntds.dit File or Log Files」を参照してください。

Contoso 社のシナリオ

Contoso 社環境では、データベースとログはインストール プロセス中にシステム外ボリュームにインストールされました。

ドメイン コントロールのインストール中に、Active Directory データベースとログの場所を変更する方法

  1. Dcpromo.exe を起動し、[データベースとログの場所] ダイアログ ボックスで望ましい構成を設定します。

  2. データベースの場所の変更先 (たとえば D:\NTDS)、およびログの場所の変更先 (たとえば E:\NTDSLogs) を入力します。

  3. DCPROMO の残りの手順に進みます。

既存のドメイン コントローラにあるデータベースとログを移動する方法

  1. ドメイン コントローラを再起動します。

  2. [スタートアップ] メニューで [F8] を押し、[ディレクトリ サービス復元モード] をクリックして、表示されたプロンプトで管理者としてログオンします。

  3. ntdsutil.exe ユーティリティを起動し、ntdsutil プロンプトで files と入力します。

  4. File Maintenance プロンプトで、次のいずれかまたは両方の手順を実行します。

    1. データベースを移すために、move db to %s (ここで %s は、データベースの移動先のドライブとフォルダを示します) と入力します。

    2. ログ ファイルを移すために、move logs to %s (ここで %s は、ログ ファイルの移動先のドライブとフォルダを示します) と入力します。

  5. ログ ファイルまたはデータベースを表示するには、info と入力し、新しい場所でデータベースの整合性を確認するには、integrity と入力します。

  6. quit と入力し、再び quit と入力してコマンド プロンプトに戻ります。

  7. 通常 モードでシステムを再起動します。

注 : 処理が正常に終了したドメイン コントローラの場合は、既定で Ntds フォルダ構造に Administrators および SYSTEM = Full Control アクセス許可が割り当てられます。これらのファイルにこれ以上のロックダウンを行わないことをお勧めします。

Windows 2000 以前の互換アクセス グループのセキュリティ保護

脆弱性

Active Directory のほとんどのオブジェクトへの既定アクセス許可では、Windows 2000 以前の互換アクセス グループに読み取りアクセスを許可しています。All User と Group オブジェクトはこのアクセス許可を持っており、ドメイン パーティションでは、このグループに内容の一覧表示アクセス許可を与えています。

Everyone という特殊グループが Active Directory ドメインの Windows 2000 以前の互換グループ メンバになった場合は、すべての User および Group オブジェクトは、各ユーザー オブジェクトのグループ メンバシップを含め、匿名ユーザーから LDAP 読み取り操作を行ってよいことになります。このような匿名ユーザーはドメインの内容をリストすることもできます。

対応策

既存ドメインの 「Windows 2000 以前の互換アクセス グループ」から Everyone エイリアスを削除します。

また、新ドメインを作成する場合には、最初のドメイン コントローラに対する DCPROMO プロセスの [アクセス許可] ダイアログ ボックスで、Windows 2000 サーバー設定と互換があるアクセス許可のみを選択します。

理論的には、ドメイン コントローラから継承した Windows 2000 以前の互換アクセス グループのアクセス許可を削除することもできます。ただし、包括的なアクセス許可を削除することには大きなリスクが伴います。これはこの代替手段がマイクロソフトによって十分にテストされておらず、将来的にこのアクセス許可を活用する柔軟性に制約を加えるためです。

Active Directory オブジェクトのアクセス許可を変更しても、Windows 2000 以前の互換アクセス グループが空であることを保証するためにまず空にすることと同じで、環境のセキュリティ強化にはなりません。

予想される影響

Active Directory に匿名アクセスが必要なアプリケーションは、期待どおりの動作をしなくなります。Windows 2000 以前のアクセス グループから Everyone グループを削除した場合に影響があることが判明しているサービスとアプリケーションには次のものがあります。

  • Windows NT 4.0 のバックアップ ドメイン コントローラ (BDC) で動作する RAS (Remote Access Service)。

  • Windows NT 4.0 サーバーで動作する RRAS (Routing and Remote Access Service)。

  • ユーザーのグループ メンバシップをバッチ モードで解決する Microsoft SQL Server 2000

    注 : Active Directory のメンバ サーバーで動作する SQL Server 2000 は、Everyone グループを追加するのではなく、Windows 2000 以前の互換アクセス グループにメンバ サーバーのコンピュータ アカウントを設定することで必要とするアクセスを得ることができます。

  • 信頼関係があるドメインからユーザーとグループ リストを表示する手順 — これができなければ、グループ名を手動で入力する必要があります。

Contoso 社のシナリオ

Contoso 社のシナリオでは、次の手順に従って、各ドメインの Windows 2000 以前の互換アクセス グループから Everyone エイリアスを削除しました。

Windows 2000 以前の互換アクセス グループから Everyone エイリアスを削除する方法

  1. グループを削除するドメインのドメイン コントローラでコマンド プロンプトを起動します。

  2. net localgroup "Pre-Windows 2000 Compatible Access" Everyone /DELETE というコマンドを入力します。

  3. 現時点でグループが空であることを確認するために net localgroup "Pre-Windows 2000 Compatible Access" というコマンドを入力します。

    結果は次のようになります。

    C:\>net localgroup "pre-windows 2000 compatible access"
Alias name     pre-windows 2000 compatible access
Comment        A backward compatibility group which allows read
access on all users and groups in the domain
Members
--------------------------------------------------------------------
-----------
The command completed successfully.
  1. この設定を有効にするために、ドメイン内の全ドメイン コントローラを再起動します。

ドメインにワークステーションを追加する権利を削除

脆弱性

すべての認証済みユーザーには、既定で Windows 2000 ドメインに 10 個までのコンピュータ アカウントを追加することができます。このような新しいコンピュータ アカウントは、Computers コンテナに作成されます。

Windows NT 4.0 ドメイン モデルとは異なり、Windows 2000 ドメインでは各コンピュータ アカウントは完全なセキュリティ プリンシパルで、コンピュータとしてドメイン リソースを認証し、アクセスすることができます。組織によっては、一貫した環境の構築と管理が行えるように、Active Directory 環境に配置するコンピュータ数を制限することを考えている場合があります。

ドメインにワークステーションを追加する権利をユーザーに与えると、この努力を妨げることになります。未承認ドメイン コンピュータの追加および作成を許可することにより、ユーザーの活動追跡をより困難にする手段をユーザーに与えることにもなります。

最後に既存のシステムがシャットダウンする場合には、Active Directory から SPN (Service Principal Name) の登録解除を行います。システムがダウンしている間に (たとえば、サービス拒否 (DoS) 攻撃後)、攻撃者は SPN に自分のコンピュータを登録し、正規サーバー向けのトラフィックを傍受できるからです。

対応策

既定のドメイン コントローラ ポリシーの「ドメインにワークステーションを追加」するユーザー権利から、Authenticated Users グループを削除します。

あるいは、別のもっと制約の強いユーザー グループにコンピュータ アカウント作成を許可したい場合には、既定のドメイン コントローラ ポリシーのドメインにワークステーションを追加するユーザー権利の値を変更できます。たとえば、Computer Account クリエータと呼ばれる新しいドメイン グループを作成し、この新グループにドメインにワークステーションを追加する権利を持つユーザーのアカウントを作成し、次に既定のドメイン コントローラ ポリシーのこのドメイン権利に新グループ名を追加します。

特定のユーザー グループにActive Directory ドメインの任意の OU (またはドメイン コンテナ) でのコンピュータ アカウント作成およびコンピュータ アカウント削除許可を与えることもできます。この許可が与えられているユーザーであれば、許可されているコンテナ (たとえば支店の OU) に任意の数のコンピュータ アカウントを作成することができます。

たとえば、「サーバー管理スタッフ」と呼ばれるセキュリティ グループには、メンバ サーバー OU でコンピュータ アカウント作成とコンピュータ アカウント削除の権利を与えます。したがって、サーバー管理スタッフのメンバであれば、メンバ サーバー OU に任意の数のコンピュータ アカウントを作成することができます。OU へのコンピュータ アカウント作成に関する詳細については、サポート技術情報記事 251335 「ドメイン ユーザーがワークステーションまたはサーバーをドメインに参加させられない」を参照してください。

最後に、すべての認証ユーザーがドメインにワークステーションを追加する特権を使い、コンピュータ アカウントを作成できるように許可したいけれども、既定の 10 アカウントよりも少ない設定を望む場合は、ms-DS-MachineAccountQuota 属性値を既定値の 10 から、0 以上の別の 10 進数値に変更できます。この値を 0 に設定すると、この特権は無効になります。

予想される影響

以前にドメインに独自のワークステーションを追加可能なユーザーは、その特権を使えなくなります。これは、頻繁にコンピュータ アカウントを作成することが仕事であるユーザーにとっては、特に作業上の能力に影響が出ます。

このステップがあると、新しいコンピュータを導入する前に組織としてコンピュータ アカウントを用意しておかなければならないため、環境へのオーバヘッドが増大します。このため、要求に応じてコンピュータ アカウントを作成する必要がある集中 IT (Information Technology) リリース管理チームと一緒にコンピュータを追加する作業では、連携作業の必要性も高まっています。

新しいコンピュータのためにあらかじめコンピュータ アカウントを作成することも、新たな脆弱性を作り出します。新しいコンピュータ アカウントを要求しない期間が長ければ長いほど、誰かがそのアカウントを「盗み」、ドメインに認証されていないコンピュータを追加し、要求されていないアカウントを利用して登録を行う可能性も高くなります。Windows 2000 では、コンピュータ アカウントの既定のパスワードが予想可能であるため、このようなことが可能です。Active Directory に登録されている未使用アカウントごとに発行される既定のパスワードは、新しいコンピュータがドメインに参加するために要求するまでは変わりません。

このコンピュータ アカウントの「盗用」は、通常、正当なユーザーが新しいコンピュータをドメインに参加させることができない時点で報告されます。しかし、この空白期間中に攻撃者はドメイン コンピュータを使用できます。

Contoso 社のシナリオ

Contoso 社のシナリオでは、企業ネットワークへの追加は、適切な OU で作成または削除の許可を得ている IT スタッフが行います。ドメインへのワークステーションの追加は、どのユーザーにも許可されていません。このため、この特権は全ユーザーで無効になっています。

Authenticated Users グループは、以下の手順に従う MSS DCBaseline Role.inf テンプレートで、ドメインにワークステーションを追加する権利を削除されました。

ドメインにワークステーションを追加する特権を持っているグループの修正方法

  1. 既定のドメイン コントローラ ポリシー GPO を編集する許可を持つユーザーとして [Active Directory ユーザーとコンピュータ] を開始します。

  2. [ドメイン コントローラ] OU を右クリックし、[プロパティ] を選択します。

  3. [グループ ポリシー] タブを選択し、[Default Domain Controllers Policy GPO] をクリックし、次に [編集] ボタンをクリックします。

  4. [Windows の設定] フォルダをダブルクリックし、[セキュリティの設定]、[ローカル ポリシー]、および [ユーザー権利の割り当て] の順に選択します。

  5. [ドメインにワークステーションを追加] 設定をダブルクリックします。

  6. メンバを削除するには、対象メンバ (たとえば Authenticated Users) をクリックし、次に [削除] ボタンをクリックします。

  7. メンバを追加するには、[追加] ボタンをクリックし、ユーザーまたはグループを選択し、次に [OK] をクリックします。

Kerberos/TCP へのサービス拒否攻撃から保護

脆弱性

Windows 2000 ドメイン コントローラが一時的に TCP 経由の Kerberos プロトコル要求の受付を停止する制限条件があります。これは既知の問題であり、SP3 以降の修正プログラムで解決されます。修正プログラムは、ある製品の 1 障害に対処する複数のファイルで構成される累積型パッケージです。修正プログラムは特定の顧客状況に対応するもので、マイクロソフトからの書面による正式な同意なしには顧客組織外へ配布してはなりません。

この脆弱性の詳細については、サポート技術情報記事 320903 「クライアントが TCP を介した Kerberos を使用してログオンできない」を参照してください。

極めて利用頻度の高いドメイン コントローラでさえ、正常な使い方でこのような問題にぶつかることは非常にまれなことです。ただし、攻撃者がこのサービス拒否攻撃状態を利用し、ドメイン コントローラが TCP 経由の Kerberos 要求をサービスする能力を一時的に枯渇させることは可能です。

既定と設計方針により、Kerberos 認証プロトコルのトラフィックは、UDP (User Datagram Protocol) ポート 88 で送受信しています。この Kerberos プロトコル パケットが (既定のサイズ限界である) 2000 バイトを超えるようなことがあれば、Windows 2000 は TCP ポート 88 へ切り替わります。

組織によっては、Kerberos プロトコル トラフィックについては、常に TCP (Transmission Control Protocol) を使うように、Windows 2000 と Windows XP クライアントを構成している場合もあります。サポート技術情報記事 244474 「Windows 2000 で Kerberos に UDP ではなく TCP を使用することを強制」では、この変更を正統化できる最も一般的な状況を説明しています。

対応策

使用している環境で起こりうる脅威、およびサポート技術情報記事 320903 に記載されている条件に合致する状況であれば、マイクロソフトからサポート技術情報記事で指示されている修正プログラムを入手し、影響がある全ドメイン コントローラに導入します。

または、ログオン時間が通常以上に長いかどうかを知るため、ヘルプ デスクへの通話をモニタすることもできます。これがこの問題に関する指標となります。ただし、通常よりも長いログオン時間は、他の多くの問題の結果という場合も考えられます。ログオン時間の長時間化を引き起こしているものを割り出すことは非常に困難です。

TCP 経由の Kerberos トラフィックのボリュームを最小限にするため、サポート技術情報記事 244474 に詳述されている回避策の使用を制限することもできます。ただし、244474 には、うまくいかなかったログオン問題が記載され、パケット断片の欠落が原因であったケースが多数あります。これらの問題は、TCP に切り替えることなく解決するのはさらに難しくなります。切り替えを意図的に選択している場合は、UDP に戻すことが困難になります。

さらに、Kerberos 認証プロトコルがエンタープライズ アプリケーションの鍵を握る手法になりつつあるため、この認証の信頼性を高めることを決定し、この信頼性を高める重要な手段として TCP へ切り替える組織が増えています。この理由から、サービス拒否攻撃の可能性を低くするために TCP の利用を制限しないことをお勧めします。

予想される影響

予想される影響は、いずれの修正プログラムでも同じです。通常どおり、修正プログラムを生産環境へと持ち込む前にテストすることをお勧めします。

Contoso 社のシナリオ

Contoso 社のシナリオでは、ログオン時間と内部ネットワーク攻撃の可能性は大きく関係しています。そのため、サポート技術情報記事 320903 の修正プログラムが予防措置として導入されました。

320903 の修正プログラムの入手と導入方法

  1. マイクロソフト プロダクト サポートまたはプレミア サポートのヘルプ デスクに連絡し、サポート技術情報記事 320903 で指示されている修正プログラムを要求します。

  2. 組織で規定されている修正プログラムのテストと導入プロセスに従い、修正プログラムをテストおよび導入します。

セキュリティの追加設定 — Active Directory 統合 DNS

マイクロソフトでは、Active Directory 統合 DNS の利用を推奨しています。理由の 1 つとして、ゾーンを Active Directory に統合することにより、DNS インフラストラクチャをセキュリティで保護するプロセスが単純化できることがあります。

DNS サーバーの保護

脆弱性

DNS サーバーが攻撃される場合、攻撃者の狙いの 1 つは DNS クライアントの問い合わせに応答して返却される DNS 情報をコントロールすることです。この状況が起こると、クライアントは認証されていないコンピュータに知らない間に接続されることになります。IP スプーフィングとキャッシュ汚染は、このタイプの攻撃の例です。

IP スプーフィングでは、コンピュータまたはネットワークにアクセスするため、正式ユーザーの IP アドレスで送信を行います。キャッシュ汚染は、次々と到着する DNS クエリを素早く解決する手助けとなるように、既定により照会への応答で追加する名前をキャッシュしていく際に発生します。

認証されていないコンピュータとの交信をクライアントが開始すると、相手のコンピュータはクライアント コンピュータに格納されている情報へのアクセスを試みようとする可能性があります。

すべての攻撃が DNS サーバーをスプーフィングすることを意図しているわけではありません。サービス拒否攻撃であっても、正式な DNS サーバーの DNS レコードを改変でき、クライアントのクエリに対して不正なアドレスを返すことができるものがあります。サーバーに不正なアドレス情報を応答させることにより、クライアントおよびサーバーは、ドメイン コントローラ、Web サーバー、またはファイル共有などの、機能する際に必要なリソースを見つけることができません。この問題については、後述の「DNS データ コンテナのセキュリティ保護」セクションで議論します。

対応策

すべての DNS クライアント構成は、IP アドレスに基づいているため、DNS サーバーの IP アドレスが他のコンピュータによりスプーフィングされていないことを保証するため、スプーフィングされた IP パケットを捨てるようにすべてのルーターを設定します。

あるいは、DNS サーバー パフォーマンスを監視することで、このような攻撃による DNS サーバーへの被害を限定することができます。

予想される影響

なし。

Contoso 社のシナリオ

Contoso 社の北米ドメインの DNS サーバー (ドメイン コントローラ) には、比較的高い資産優先度 (Asset Priority) が設定されているため、Contoso 社環境にあるすべてのルーターは、IP アドレス スプーフィングを防止できるように構成されました。

すべての Contoso 社クライアントが IPSec を使用できるわけではないため、IPSec 暗号化または署名は、DNS サーバーでは有効にしませんでした。ただし、いくつかの理由から、IPSec ブロッキング フィルタを有効にしました。詳細については、後述の「IPSec フィルタでポートをブロック」を参照してください。

ドメイン コントローラと DNS サーバーのパフォーマンスは、MOM (Microsoft Operations Manager) を使って監視しました。

セキュリティで保護された動的更新の構成

脆弱性

Windows 2000 の DNS サーバーとクライアントは、DDNS 更新をサポートしているので、クライアント システムは DNS サーバーをサポートするデータベースに DNS レコードを直接追加できます。

次の条件がそろえば、Windows 2000 DNS サーバーに対して未承認の DDNS 更新を行うことができます。

  • 攻撃者は DDNS プロトコルを使用するクライアントを操作します。

  • DNS サーバーは、セキュリティで保護されていない更新を受け取る構成となっています。

少なくとも、攻撃者は DNS データベースに偽のエントリを追加することができ、最悪の場合、DNS データベースを上書きしたり、正式なエントリを削除することができます。この種の攻撃結果としては、次のようなものがあります。

  • 未承認ドメイン コントローラにクライアントを誘導。

クライアントがドメイン コントローラのアドレスを尋ねる DNS クエリを送信すると、正常な応答ができない DNS サーバーは未承認サーバーのアドレスを返却する指示を与えられます。次に DNS とは関係のない他の攻撃を仕掛けることで、クライアントがだまされ、偽のサーバーにセキュリティ保護された情報を流すようになります。

  • DNS クエリに不正なアドレスで応答。

これによりクライアントとサーバーはお互いの場所が分からなくなります。クライアントはサーバーを探せず、ディレクトリにアクセスできません。ドメイン コントローラが他のドメイン コントローラを探せなくなると、ディレクトリの複製は停止します。

  • サービス拒否攻撃状態を作り出すことで、次のいずれかの状態が発生します。

  • ダミー レコードを詰め込んだ巨大なゾーン ファイルが生成され、サーバーのディスク スペースが枯渇します。

  • たとえば 50,000 エントリ以上の大量のエントリがディレクトリのゾーン コンテナに作成され、複製作業の速度を低下させます。

対応策

攻撃者が不正なレコードを登録することを防ぐため、セキュリティで保護された動的更新を使用することをお勧めします。セキュリティで保護された DDNS 更新を使用することで、登録要求はフォレスト内の正当なクライアントから送信された場合にのみ処理されます。これにより、攻撃者はこの種の攻撃を仕掛けることがより困難となります。こうなると攻撃者はまず、フォレストのメンバであるワークステーションへのアクセスを獲得しなければなりません。

あるいは、DDNS 更新を無効にすることもできます。これにより上で述べたような種類の搾取を防げます。ただし、すべての更新作業を手作業で行わなければならないため、DNS レコードを最新状態に維持するコストが大幅に増大します。Windows 2000 環境では、維持しなければならない DNS レコード数は、Windows 2000 以前の環境に慣れている DNS 管理者にとっては、かなり大きなものとなります。

このトピックに関する詳細については、次のサポート技術情報記事を参照してください。

  • 246804 「[NT] Windows 2000 で DNS の動的更新を有効/無効にする方法」

  • 198767 「ドメイン コントローラが DNS 名を動的に登録するのを防ぐ方法」

予想される影響

Active Directory 統合 DNS ゾーンがセキュリティ保護されると、非 Windows 2000 システムから、このゾーンに DDNS エントリを記録できない場合があります。この問題は、Windows 2000 DHCP サーバーが、DHCP クライアントの代わりに DNS レコードを登録すれば、DHCP (Dynamic Host Configuration Protocol) クライアントのケースでは緩和されます。

ただし、DDNS レコードを記録する目的で DHCP サーバーを使用しても、DHCP クライアントを使用していない場合は役に立ちません。セキュリティ保護された DDNS 更新をサポートしない、または Windows 2000 DHCP サーバーから IP アドレス情報を獲得しないけれどもセキュリティ保護された Active Directory 統合 DNS ゾーンに DNS 情報を登録しなければならないシステムに対しては、レコードを手作業で登録する必要があります。

Contoso 社のシナリオ

Contoso 社のシナリオにおける Active Directory 統合 DNS サーバーは、手作業で構成され、セキュリティ保護された DDNS 更新のみを受け付けるようにしました。

各 DNS ゾーンに対し、セキュリティで保護された DDNS 更新を有効にする方法 (前方参照ゾーンと逆引き参照ゾーン)

  1. DNS サーバー MMC スナップインおよび、処理したいフォルダを開きます (前方参照ゾーンまたは逆引き参照ゾーン)。

  2. 処理したいゾーン (たとえば、northamerica.corp.contoso.com) を右クリックし、[プロパティ] を選択します。

  3. [一般] タブから開く [動的更新を使用可能にしますか] ダイアログ ボックスで、[セキュリティで保護された更新のみ] を選択していることを確認します。

注 : この手順では目的とするゾーンの一般タブで、[種類] が [Active Directory 統合] として構成されていると仮定しています。

DNS データ コンテナのセキュリティ保護

脆弱性

アクセス許可関連の ACL をゾーン コンテナに設定可能で、DNS スナップインまたは ADSIEdit などの管理ツール経由で変更を試みるユーザーによるアクセスを制限します。管理者、ドメイン管理者、エンタープライズ管理者、および DNS 管理者は、既定ですべての DNS コンポーネントにフル コントロールのアクセス許可を持っています。その他すべての人には読み取りアクセスを許可しています。

既定の ACL が変更されると、自分の意志とは関係なく DNS データ コンテナを修正する許可を与えられたユーザーからの悪意のない脅威に遭遇することがあります。これにより、DNS サーバー プロパティ、または統合 DNS ゾーンに格納されたデータを変更することが可能となります。悪意のない脅威は、コンピュータに不慣れな従業員やセキュリティの脅威や脆弱性に気付いていない従業員からもたらされることが一般的です。

対応策

既定の ACL に Active Directory 統合 DNS を使用するドメインの マイクロソフト DNS コンテナの ACL を制限します。

または、既定でこれらの設定やデータを修正することが可能なグループのメンバシップ (すなわち、管理者、ドメイン管理者、エンタープライズ管理者、および DNS 管理者) を制限できます。

予想される影響

マイクロソフト DNS コンテナ、または任意の統合 DNS ゾーンに正しくないアクセス許可設定を行うと、組織に重大な影響を与えることになります。ルーズなアクセス許可を行うと、認証を得ていないユーザーが DNS サーバーやゾーンデータに影響を与える可能性があります。逆に、厳しすぎるアクセス許可を行うと、ディレクトリから DNS データのロードを試みる際、または新しい動的更新を追加する際に、理論的にはサービス拒否状態を作り出してしまいます。

注 : すべての場合に、SYSTEM がフル コントロールを持っていることを確認します。

Contoso 社のシナリオ

Contoso 社シナリオにおけるマイクロソフト DNS および従属ゾーンの既定のアクセス許可が確認されました。

Active Directory 統合 DNS 向けのアクセス許可の表示または編集方法

  1. [DNS サーバー] MMC を開き、[DNS サーバー] を右クリックし、[プロパティ] を選択します。

  2. [セキュリティ] タブをクリックし、[詳細] ボタンをクリックします。

DNS キャッシュ汚染に対する保護の構成

脆弱性

DNS サーバー上のキャッシュに未承認エントリを直接追加することが可能になり、クライアントは誤って未承認の場所に導かれる恐れがあります。これがキャッシュ汚染の原因です。

対応策

すべての DNS サーバーで [Secure cache against pollution] オプションの値を [有効] に設定します。この機能を有効にすることで、サーバーは参照されている名前が汚染されている可能性があるかどうか、セキュリティで保護されていないかどうかを判定し、不審なものを捨てることができます。

サーバーは、各参照名が元のクエリで記録されたものと、正確に同じ関連 DNS ドメイン名の一部として認識できるかどうかに基づき、各参照名をキャッシュすべきかどうかを決定します。詳細については、サポート技術情報記事 316786 「Description of the DNS Server Secure Cache Against Pollution Setting」を参照してください。

予想される影響

最小限。

Contoso 社のシナリオ

Active Directory 統合 DNS サーバーは、Contoso 社シナリオではキャッシュ汚染に対してセキュリティ保護されました。

DNS サーバー キャッシュ汚染に対してセキュリティ保護を有効にする方法

  1. [DNS サーバー] MMC を開き、[DNS サーバー] を右クリックし、[プロパティ] を選択します。

  2. [詳細] タブを選択し、[Secure cache against pollution] チェック ボックスがオンになっていることを確認します。

DNS データとログ ディレクトリのセキュリティ保護

脆弱性

Active Directory 統合 DNS 向けに構成した Windows 2000 DNS サーバーは、ゾーン データを Active Directory に格納します。ただし、プライマリまたはセカンダリ サーバーとして構成した DNS サーバーは、ゾーン データを既定で、%SystemRoot%\system32\dns のテキスト ファイルに格納します。

さらに、デバッグ ログが DNS サーバーで構成されている場合、このようなログは、既定で %SystemRoot%\system32\dns のテキスト ファイルにも格納されます。

これらの両方のファイルの既定では、Users には読み取りと実行のアクセス許可、Power Users には変更のアクセス許可が与えられます。

サーバーがバッファ オーバーフローまたはディレクトリ走査攻撃にさらされると、システム ボリューム内のデータへのアクセスが可能となり、DNS サーバー データは危険な状態に置かれます。バッファ オーバーフローは、システムへのアクセスを試みる攻撃者が採用する種類のものです。

対応策

%SystemRoot%\system32\dns フォルダへのアクセス許可を削減し、Administrators と SYSTEM のみがこのようなファイルへのアクセス許可を持つようにします。

あるいは、データとログ ファイルを別のディスク ボリュームに移すか、既定の場所よりも攻撃者に知られていない別のディレクトリに移すことができます。ファイルを移すことにより必ずしもそれらのファイルへのアクセス許可を改善することにはなりません。これは、これらのファイルには依然として探せる人にとっては攻撃可能な潜在的脆弱性があることを意味しています (たとえば、レジストリ情報を使って場所を探し出すことができます)。

予想される影響

Administrators と System のみがこれらのファイルへのアクセスを必要としているため、影響は最小限にとどまります。DNS サービスの管理を DNS サーバー管理者グループのメンバシップを持たない新しいグループに委任することも考えられます。この場合は、新しいグループが責任を果たせるように、これらのファイルへのアクセス許可を持っていることを確認する必要があります。

Contoso 社のシナリオ

Contoso 社のシナリオでは、すべての DNS データは Active Directory からもたらされるため、ファイル システムのアクセス許可変更は必要ありません。

既定の DNS ファイル ディレクトリでアクセス許可を制限する方法

  1. コマンド プロンプトを開きます。

  2. cacls.exe %systemroot%\system32\dns /t /

    g administrators:F system:F というコマンドを入力します。

  3. プロンプトで Y と入力し、先に進みます。

注 : DNS ファイルを新しいディレクトリに移していても、セキュリティ保護をまだ行っていない場合は、上記 cacls.exe コマンドで指定しているディレクトリを変更することを忘れないでください。

DNS データとログ ディレクトリの移動

脆弱性

Active Directory 統合 DNS 向けに構成した Windows 2000 DNS サーバーは、ゾーン データを Active Directory に格納します。ただし、プライマリ サーバーとして構成した DNS サーバーは、ゾーン データを既定で、%SystemRoot%\system32\dns のテキスト ファイルに格納します。

さらに、デバッグ ログが DNS サーバーで構成されている場合、ログは既定で %SystemRoot%\system32\dns のテキスト ファイルにも格納されます。

サーバーがバッファ オーバーフローまたはディレクトリ走査攻撃を受けると、システム ボリューム内のデータへのアクセスが可能となり、データが読まれたり危険にさらされたりします。

対応策

DNS ゾーン データ ファイルおよびログ ファイルをシステム外ディスク パーティションに移します。

または、%SystemRoot%\system32\dns フォルダにある DNS ファイルの既定ディレクトリへのアクセス許可レベルを下げることができます。ただし、この方法で必ずしもこれらのファイルに対する攻撃の可能性を制限できるとは限りません。攻撃の中には管理者レベルのアカウントまたは SYSTEM として動作する脆弱なサービス経由で起きるものがあります。

予想される影響

このようなファイルの新しい場所を記憶域管理チームに通知していない場合、定期的なバックアップの際に処理し忘れることがあります。バックアップ ソフトウェアが場所を変更したファイルをバックアップする構成になっていることを確認することで、可用性に関する問題の発生を回避できます。

Contoso 社のシナリオ

Contoso 社のシナリオでは、DNS ゾーン データは Active Directory に統合されているので、データ ファイルはディスクに格納されていませんでした。変更は必要ありませんでした。

Contoso 社のシナリオでは、DNS サービスのデバッグ ロギングを有効にしていません。ただし、このロギング機能が将来的に必要となることを予測して、デバッグ ログを別ディスクに格納するという形で前もって構成してあります。

DNS ゾーン データ ファイルを移動する方法

  1. Regedit.exe を起動し、HKLM\System\CurrentControlSet\Services\DNS\Parameters を表示します。

  2. [編集] メニューから [新規]、[文字列] を選択し、「DatabaseDirectory」という名前を付けます。

  3. この新しい DatabaseDirectory 値のエントリをダブルクリックし、[値のデータ] テキストボックスに、ゾーン データ ファイルを格納するフォルダへのフル パス名を入力します。

    注 : レジストリでこの変更を行っても、DNS は元のデータベースを移動させたり変更することはありません。

  4. DNS サーバーを停止します。

  5. Systemroot\System32\Dns フォルダにすでに DNS データベースが存在している場合は、新しい場所に手作業で移動させる必要があります。%systemroot%\system32\dns にあるファイルとフォルダを新しいドライブ フォルダ (たとえば d:\DNS) に移動させます。

  6. DNS サーバーを開始します。

DNS デバッグ ファイルを移動する方法

  1. Regedit.exe を起動し、HKLM\System\CurrentControlSet\Services\DNS\Parameters を表示します。

  2. [編集] メニューから [新規]、[文字列] を選択し、「LogFilePath」という名前を付けます。

  3. 新しい LogFilePath 値のエントリをダブルクリックし、[値のデータ] テキストボックスに、デバッグ ログ ファイルを格納するフォルダへのフル パス名を入力します。

  4. DNS サーバーを再開します。

ゾーン転送先を認証システムのみに制限

脆弱性

Active Directory 統合 DNS サーバー以外にも、プライマリまたはセカンダリ サーバーとして動作する DNS サーバーがあります。セカンダリ サーバーは、主にプライマリ サーバーからゾーン ファイル全体を転送し、コンテンツの同期を取ります。

ゾーン転送の要求元を制限する構成になっていない DNS サーバーは、どのような要求者にも DNS ゾーン全体を転送してしまいます。これは nslookup.exe のようなツールを使うと簡単に行うことができます。これはどのホストがドメイン コントローラ、ディレクトリ統合 Web サーバー、または SQL Server 2000 データベースとしてサービスを行っているかなどの情報を含めて、ドメインの DNS データセット全体を公開してしまうことを意味します。

対応策

DNS サーバーのゾーン転送先を既知のコンピュータのみに制限として構成 (つまり、セカンダリ DNS サーバーのみに制限) します。

あるいはゾーン転送自体を許可したくない場合もあります。ただし、階層的な DNS サーバーを計画またはセットアップし、セカンダリ DNS サーバーを多数のリモート コンピューティング ユーザーの近くで構成する予定であれば、大規模な分散ネットワークでこのような制限を正統化するのは困難です。

予想される影響

この構成では、DNS ゾーン全体を一度に要求する能力を必要とするサービスを制約することになります。これはまた、代替 DNS サーバーにクエリを行う必要がある DNS クライアントの応答時間を遅くすることにもなります。また、DNS インフラストラクチャにもよりますが、DNS クエリの失敗も発生します。

Contoso 社のシナリオ

Contoso 社のシナリオでは、子ドメインのドメイン コントローラにルート ドメインの _msdcs.corp.contoso.com zone をキャッシュする構成になっているセカンダリ DNS ゾーンがあります。ルート ドメインのドメイン コントローラは、認証された DNS サーバーの IP アドレスに従い、このゾーンのゾーン転送を子ドメインのドメイン コントローラにのみ許可する構成としました。他のすべての Active Directory 統合ゾーンは、ゾーン転送を許可しない既定構成のままにしてあります。

ゾーン転送を既知のサーバーのみに限定する方法

  1. [DNS administrative tool] を起動し、ゾーン転送を構成する [zone] を右クリックし、[プロパティ] をクリックします。

  2. [ゾーン転送を許可するサーバー] が有効になっていることを確認し、[次のサーバーのみ] または [ネーム サーバー タブの一覧にあるサーバーのみ] のいずれかを選択します。

    1. [次のサーバーのみ] を選択する場合は、認証されている DNS サーバーの IP アドレスをダイアログ ボックスに入力します (これは Contoso 社向けに選択した設定であり、子ドメインのドメイン コントローラの IP アドレスが追加されています)。

    2. [ネーム サーバー タブの一覧にあるサーバーのみ] タブを選んだ場合は、[ネーム サーバー] タブを選択し、このゾーンで認証されているだけでなく、この DNS サーバーからセカンダリ ゾーン転送を要求することを認証されているネーム サーバー (DNS サーバー) の情報を入力します。

IPSec フィルタでポートをブロック

脆弱性

オープン状態でサーバーをアクティブにリッスンしているポート数を組織内で減らすことは、各コンピュータへの攻撃対象エリアを大きく削減します。攻撃対象エリアとは、環境内にあり脆弱性を持つクライアントまたはサーバー コンピュータの中で攻撃にさらされるエリアを意味します。

オープン ポートは攻撃者に組織内の他のサーバーを攻撃する踏み台を提供します。たとえば、ワームやトロイの木馬は、サーバーの未承認ポートにバインドするアプリケーションをインストールし、入力コマンドをリッスンします。

対応策

以下に指定するネットワーク トラフィックのみを許可する IPSec ブロッキング フィルタを構成します。これにより、要求の受信に成功したり攻撃対象となる、予想していない未承認アプリケーション数を削減します。

ドメイン コントローラは、トラフィック マップに示されている複数機能に対する、RPC トラフィックを必要とします。このため、下のマップで示すように、いくつかのものは別々の項目として扱う必要があります。

各サービスはクライアント機能とサーバー機能に分けられます。これは必ずしもクライアント ワークステーションとサーバーのことを指しているわけではありません。上記サービスを利用するか提供するために作成する必要がある IPSec フィルタが対応して示されています。

たとえば、DNS クライアント ポリシーはネーム サービス機能を必要とするコンピュータに適用することをお勧めします。DNS サーバー規則は、DNS サービスを提供するコンピュータにのみ適用されます。SNMP (Simple Network Management Protocol) のような他のサービスは多少紛らわしくなっています。これは SNMP サーバーのポートは許可されていますが、SNMP クライアントのポートは許可されていないからです。ただし、SNMP のリモート ステーションは情報を求めて個々のコンピュータにアクセスする性格のものであるため、SNMP はドメイン コントローラではサーバー サービスとして動作し、この情報をリモート ステーションに提供します。

ドメイン コントローラ IPSec ネットワークのトラフィック マップ

表 7.5 ドメイン コントローラ IPSec ネットワークのトラフィック マップ

サービス プロトコル ソース ポート 宛先ポート ソース アドレス 宛先アドレス 動作
DNS クライアント TCP 任意 53 ホスト IP 任意 許可
  UDP 任意 53 ホスト IP 任意 許可
SNMP サーバー TCP 任意 161 任意 ホスト IP 許可
  UDP 任意 161 任意 ホスト IP 許可
CIFS/SMB クライアント TCP 任意 445 ホスト IP 任意 許可
  UDP 任意 445 ホスト IP 任意 許可
CIFS/SMB サーバー TCP 任意 445 任意 ホスト IP 許可
  UDP 任意 445 任意 ホスト IP 許可
RPC クライアント TCP 任意 135 ホスト IP 任意 許可
  UDP 任意 135 ホスト IP 任意 許可
RPC サーバー TCP 任意 135 任意 ホスト IP 許可
  UDP 任意 135 任意 ホスト IP 許可
FRS/AD 複製ポート アウト TCP 任意 57951 ホスト IP 任意 許可
  TCP 任意 57952 ホスト IP 任意 許可
FRS/AD 複製ポート イン TCP 任意 57951 任意 ホスト IP 許可
  TCP 任意 57952 任意 ホスト IP 許可
NetBIOS クライアント TCP 任意 137 ホスト IP 任意 許可
  UDP 任意 137 ホスト IP 任意 許可
  TCP 任意 139 ホスト IP 任意 許可
  UDP 任意 138 ホスト IP 任意 許可
NetBIOS サーバー TCP 任意 137 任意 ホスト IP 許可
  UDP 任意 137 任意 ホスト IP 許可
  TCP 任意 139 任意 ホスト IP 許可
  UDP 任意 138 任意 ホスト IP 許可
NTP クライアント TCP 任意 123 ホスト IP 任意 許可
  UDP 任意 123 ホスト IP 任意 許可
監視クライアント 任意 任意 任意 ホスト IP MOM サーバー 許可
LDAP クライアント TCP 任意 389 ホスト IP 任意 許可
  UDP 任意 389 ホスト IP 任意 許可
  TCP 任意 636 ホスト IP 任意 許可
  UDP 任意 636 ホスト IP 任意 許可
Kerberos クライアント TCP 任意 88 ホスト IP 任意 許可
  UDP 任意 88 ホスト IP 任意 許可
ターミナル サービス TCP 任意 3389 任意 ホスト IP 許可
グローバル カタログ クライアント TCP 任意 3268 ホスト IP 任意 許可
  TCP 任意 3269 ホスト IP 任意 許可
グローバル カタログ サーバー TCP 任意 3268 任意 ホスト IP 許可
  TCP 任意 3269 任意 ホスト IP 許可
DNS サーバー TCP 任意 53 任意 ホスト IP 許可
  UDP 任意 53 任意 ホスト IP 許可
Kerberos サーバー TCP 任意 88 任意 ホスト IP 許可
  UDP 任意 88 任意 ホスト IP 許可
LDAP サーバー TCP 任意 389 任意 ホスト IP 許可
  UDP 任意 389 任意 ホスト IP 許可
  TCP 任意 636 任意 ホスト IP 許可
  UDP 任意 636 任意 ホスト IP 許可
NTP サーバー TCP 任意 123 任意 ホスト IP 許可
  UDP 任意 123 任意 ホスト IP 許可
ICMP ICMP 任意 任意 ホスト IP 任意 許可
全受信トラフィック 任意 任意 任意 任意 ホスト IP ブロック

注 : 表 7.5 にリストされているホスト IP 宛先アドレスは、サーバーで構成している IP アドレスに設定します。

重要な注記事項として、Kerberos フィルタはサポート技術情報記事 254728 「IPSec Does Not Secure Kerberos Traffic Between Domain Controllers」で指定されている NoDefaultExempt 設定を実装した場合にのみ必要です。

ここに記載するすべての規則を実装時に反映させることをお勧めします。これにより、ドメイン コントローラに着信するどのようなトラフィックも、発信元サーバーに戻ることができます。

ここで分かるようにドメイン コントローラでは、いくつかのポートとサービスが開いています。ドメイン コントローラで最も厳密なセキュリティを設定すると、追加ポートをブロックできます。ただし、追加ポートは、コンピュータを管理しやすくするために提供されているだけでなく、下位にあるクライアントから NetBIOS (Network Basic Input/Output System) 機能を要求するために開かれていました。

最後に、Contoso 社は自社環境に MOM サーバーを実装しました。MOM サーバーと OnePoint クライアント (MOM コンソールに報告するクライアント アプリケーション) 間の通信は頻繁に起こるため、サーバーと MOM サーバー間ではすべてのネットワーク トラフィックを許可しています。

注 : Windows 2000 Server IPSec フィルタリングは、完全な機能を備えたファイアウォールを置き換えるようには設計されていません。IPSec フィルタリングは、サーバーを強化するツールとして検討することをお勧めします。IPSec を使うことで、静的なフィルタで防げる攻撃に対して防御策を提供できます。さらに、IPSec フィルタリングではワームやウイルスからの悪意のあるコード トラフィックを取り込み、制御することができます。IPSec フィルタリングには、ツールを使う前に理解しておくべき、セキュリティに関する重要な特性がいくつかあります。

  1. セキュリティで妥協すると、攻撃者が Local Administrator または Local System アクセスを握ることになり、IPSec ポリシーを無効にするかまたは変更できるようになります。

  2. ターゲットのコンピュータが適切にロックダウンされていることを保証するために、NoDefaultExempt のレジストリ値は 1 に設定しておく必要があります。この設定は、このセキュリティのガイダンスで使用するすべての IPSec フィルタリング シナリオで必要です。この IPSec ガイダンスでは、シナリオごとに NoDefaultExempt を設定したテストを実施していませんが、この設定の構成の違いで、動作に大きな差は出ません。このガイドは構成変更を反映して、可能な限り早く更新していきます。NoDefaultExempt 設定の構成に関する指示については、サポート技術情報記事 254728 「IPSec がドメイン コントローラ間の Kerberos トラフィックをセキュリティで保護されません。」を参照してください。

  3. IPSec では出力方向の接続に多様なフィルタリング機能を提供していません。このため、このセキュリティ ガイダンスの一環で、静的な入力フィルタが作成され、出力情報への応答を受信できるように保証しています。これにより、攻撃者が現在のシステムのサーバーのオープン ポートを走査し、接続を試みたとしても、その多くは効果的にブロックされます。ただし、攻撃者が IPSec 入力許可フィルタを通じて接続を可能にする特殊なツールを使う可能性はまだ存在しています。任意の宛先の IP (Internet Protocol) アドレスへの出力許可フィルタが必要な場合 (たとえば、出力フィルタリングを使用すれば、SMTP (Simple Mail Transfer Protocol) サーバーはインターネットに接続されている他の宛先 SMTP サーバーに電子メールを送信できます)、ファイアウォールまたは多様な機能を提供するフィルタリング装置をホスト コンピュータとインターネットの間に設置する必要があります。可能であれば、出力許可フィルタは、トラフィックの受信に必要な IP アドレスに対応させることをお勧めします。

重要 : IPSec であっても、コンピュータ起動中は完全なセキュリティを提供できません。TCP/IP (Transmission Control Protocol/Internet Protocol) スタックの応答が良い場合もまれにあり、IPSec ポリシーでブロックするアプリケーション ポートに自動攻撃でアクセスできてしまう場合があります。多くの場合、アプリケーションが接続処理を開始できないうちに、IPSec フィルタリングが有効になります。IPSec ポリシー エージェント サービスの開始と同期を取っても、フィルタがタイミング良く有効になることを保証するものではありません。

IPSec フィルタを使って最高レベルのセキュリティを実現するには、コンピュータの再起動中はコンピュータをネットワークから切り離すことをお勧めします。IPSec フィルタが有効になる正確な時間は、サーバー構成と IPSec ポリシーのサイズで決まる多くの要因に依存します。ローカルにテストを行い、サーバーをネットワークに再接続するまでの安全な時間間隔を決定します。テストを実施できない場合は、入力トラフィックを許可ポートのみに制限するためにファイアウォールやフィルタリング ルーターを使用します。

スクリプト コマンド

次のコマンドの実装は、ドメイン コントローラで実行することをお勧めします。これらのコマンドでは、特別に許可しているトラフィック以外のトラフィックをすべてブロックします。

このコマンドのセットは、このガイドに付属するバッチ ファイルにも含まれています。

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
   -f 192.168.100.11+*:53:TCP -f 192.168.100.11+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
   -f *+192.168.100.11:161:TCP -f *+192.168.100.11:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Client"
   -f 192.168.100.11+*:445:TCP -f 192.168.100.11+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Server"
   -f *+192.168.100.11:445:TCP -f *+192.168.100.11:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
   -f 192.168.100.11+*:135:TCP -f 192.168.100.11+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
   -f *+192.168.100.11:135:TCP -f *+192.168.100.11:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports IN"
   -f *+192.168.100.11:57951:TCP -f *+192.168.100.11:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports OUT"
   -f 192.168.100.11+*:57951:TCP -f 192.168.100.11:+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
   -f 192.168.100.11+*:137:TCP -f 192.168.100.11+*:137:UDP
   -f 192.168.100.11+*:139:TCP -f 192.168.100.11+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
   -f *+192.168.100.11:137:TCP -f *+192.168.100.11:137:UDP
   -f *+192.168.100.11:139:TCP -f *+192.168.100.11:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
   -f 192.168.100.11+*:123:TCP -f 192.168.100.11+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
   -f 192.168.100.31+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
   -f 192.168.100.11+*:389:TCP -f 192.168.100.11+*:389:UDP
   -f 192.168.100.11+*:636:TCP -f 192.168.100.11+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
   -f 192.168.100.11+*:88:TCP -f 192.168.100.11+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
   -f *+192.168.100.11:3389:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
   -f 192.168.100.11+*:3268:TCP -f 192.168.100.11+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
   -f 192.168.100.11+*:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Server"
   -f *+192.168.100.11:3268:TCP -f *+192.168.100.11:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DNS Server"
   -f *+192.168.100.11:53:TCP -f *+192.168.100.11:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Server"
   -f *+192.168.100.11:88:TCP -f *+192.168.100.11:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Server"
   -f *+192.168.100.11:389:TCP -f *+192.168.100.11:389:UDP
   -f *+192.168.100.11:636:TCP -f *+192.168.100.11:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Server"
   -f *+192.168.100.11:123:TCP -f *+192.168.100.11:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
   -f *+192.168.100.11 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

予想される影響

これらの設定では、ランダムな大きな番号のポートのトラフィックを許可していないので、RPC トラフィックは許可されません。したがって、サーバー管理は困難になります。ただし、CIFS (Common Internet File System) およびベーシックな NetBIOS ポートを使用すると、サーバーの使いやすさが大きく改善されます。CIFS プロトコルは、リモート ファイル アクセスの標準を定義します。CIFS を使用すると、プラットフォームやコンピュータが異なるユーザーでも、新ソフトウェアをインストールすることなく、ファイルを共有できます。

管理者は、ターミナル サービス (Terminal Services) クライアントに接続し、リモート管理を実行できるようにすることをお勧めします。ドメイン コントローラから見て、ドメイン コントローラのドライブとリモート コンピュータのドライブをマッピングできるようにすることをお勧めします。さらに、管理者は他のコンピュータからサーバー方向へのドライブのマッピングを行うことができます。上記のポリシーはこのような機能を制限する方向で厳しくすることができますが、サーバーの管理は難しくなります。

このような比較的少数の IPSec ポリシーの実装では、サーバーのパフォーマンスに目立った影響はありません。ただし、充分にテストを行ってからフィルタを環境に実装し、必要な機能と性能を検証することをお勧めします。これ以外のアプリケーションを使用している環境でサポートするには、さらに規則の追加が必要になるでしょう。

Contoso 社のシナリオ

Contoso 社シナリオでは、前述の IPSec フィルタが同社のドメイン コントローラに実装されました。スクリプト中やコマンド行に出てくる IP アドレスは各ドメイン コントローラに対応する適切なものに置き換えられました。

Active Directory のセキュリティ問題に関する議論

Syskey の利用

Syskey は、モード 1 (意味不明なキー) のすべての Windows 2000 サーバーで有効です。物理的脅威にさらされているドメイン コントローラには、モード 3 (Syskey パスワードをフロッピーに格納) またはモード 2 (コンソール パスワード) の Syskey を推める声が多くあがっています。ドメイン コントローラに修復ディスクを作成することもでき、そのフロッピー ディスクはセキュリティ保護されている場所に格納し、モード 2 の Syskey パスワードでさらにバックアップします。

たとえば、ドメイン コントローラ システムの物理記憶域に強力なセキュリティを施さない支店のドメイン コントローラには、Syskey モード 2 またはモード 3 が推奨されることがよくあります。セキュリティの観点から見ると、モード 1 のドメイン コントローラは、攻撃者がディレクトリの内容を読み取り、変更することを許してしまうので、攻撃者がドメイン コントローラに物理的にアクセスし、再起動可能な点で脆弱であることから、この方式は一見して理にかなっているように思えます。

しかし、再起動で利用可能となることがドメイン コントローラ運用上の要件であることは、Syskey モード 2 または 3 にした場合サポートを困難にします。Syskey がもたらす保護機能向上を活用するには、環境に運用プロセスを追加実装し、ドメイン コントローラの可用性要件に合致するように準備することをお勧めします。

まず、Syskey パスワードまたはフロッピー ディスク管理の手配は、特に支店の場合に極めて複雑になります。たとえば、支店のマネージャの 1 人またはローカルな管理スタッフが午前 3 時にオフィスにやってきて、他のユーザーがこのシステムを使えるようにするには、パスワードを入力するか、またはフロッピーを挿入することが必要です。これには人件費がかかり、可用性の高い SLA (Service Line Agreements) を達成することは非常に困難な課題となります。

また、中央集中型 IT の操作要員が Syskey パスワードを遠隔地から投入することを可能にするには、ハードウェアを別に用意する必要があります。ハードウェア ベンダの中にはサーバーのコンソールをリモートからアクセスするためのアドオン ハードウェア ソリューションを用意しているところがあり、これが必要となります。

2 つ目に、Syskey パスワードを忘れたり、フロッピー ディスクを紛失したりすると、ドメイン コントローラは再起動できない状態になります。Syskey パスワードやフロッピー ディスクを紛失すると、ドメイン コントローラを回復する方法はありません。このような事態が起きるとドメイン コントローラを再構築するしかありません。

ページのトップへ

インフラストラクチャ サーバーの役割

Contoso 社シナリオにおけるインフラストラクチャ サーバーの役割は、DHCP サーバーまたは WINS (Windows Internet Name Service) サーバーのいずれかです。

このガイドのインフラストラクチャ サーバーの定義と、MSA EDC (Microsoft Systems Architecture Enterprise Data Center) におけるインフラストラクチャ サーバーの役割には違いがあり、このガイドの役割には DNS が含まれていません。これは Contoso 社シナリオでは、すべての DNS サーバー機能が Active Directory 統合 DNS として構成され、ドメイン コントローラでホスティングされているからです。

しかし、DNS と Active Directory の統合を望まず、ドメイン コントローラとは別のサーバーでプライマリ ゾーンまたはセカンダリ ゾーンをホスティングしたいという会社もあります。このようなケースにあてはまる環境の場合には、前述の「追加セキュリティ設定 — Active Directory 統合 DNS」で紹介したアドバイスを忘れずに、非統合 DNS を実装する組織に提供する代替策と注意事項を活用してください。

インフラストラクチャ サーバーの増分ポリシー

インフラストラクチャ ポリシーの増分には、インフラストラクチャ サーバーで必要となるシステム サービスの設定も含みます。

システム サービス

次の表には、Windows 2000 インフラストラクチャ サーバーで無効か有効かを事前に決めてあるシステム サービスの要約を提供します。このサービスは MSS Infrastructure Role.inf のポリシー テンプレートで構成され、ドメイン コントローラ ポリシーの GPO にインポートされます。

表 7.6 インフラストラクチャ サーバーの増分ポリシー サービス設定

UI のサービス設定 スタートアップの種類 コメント
DHCPServer 自動 クライアントに DHCP サービスを提供
NTLMSSP 自動 名前付きパイプ以外のトランスポートを使用する RPC プログラムにセキュリティを提供。
WINS 自動 クライアントに WINS サービスを提供

注 : Contoso 社シナリオでは、DNS サーバーはドメイン コントローラで実行されるため、インフラストラクチャ サーバーの役割としては無効になっています。

Active Directory 統合 DNS を使用しない組織の中には、インフラストラクチャ サーバーでのプライマリ DNS サーバーとセカンダリ DNS サーバーの実行を望む組織もあります。

この場合は、インフラストラクチャ グループの増分ポリシー テンプレートを変更し、DNS サーバー サービスのスタートアップ種類を「自動」に設定できるようにします。

組織でこの設定が必要な場合は、前述の「追加セキュリティ設定 — Active Directory 統合 DNS」セクションで、Windows 2000 DNS サーバーをセキュリティ保護するための推奨事項を確認してください。

追加セキュリティ設定 — WINS

IPSec フィルタでポートをブロック

脆弱性

以前に述べたように、オープン状態のポート数を削減し、サーバーをアクティブにリッスンすることは、各コンピュータの攻撃対象エリアを大きく削減します。オープン ポートは攻撃者に組織内の他のサーバーを攻撃する踏み台を提供します。たとえば、ワームやトロイの木馬は、サーバーの未承認ポートにバインドするアプリケーションをインストールし、入力コマンドをリッスンします。

対応策

指定するネットワーク トラフィックのみを許可する IPSec ブロッキング フィルタを以下に設定します。これにより、要求を受信できたり攻撃対象となる、予想していない未承認アプリケーション数を削減します。

WINS サーバーの IPSec ネットワーク トラフィック マップ

表 7.7 WINS サーバーの IPSec ネットワーク トラフィック マップ

サービス プロトコル ソース ポート 宛先ポート ソース アドレス 宛先アドレス 動作
DNS クライアント TCP 任意 53 ホスト IP 任意 許可
  UDP 任意 53 ホスト IP 任意 許可
SNMP サーバー TCP 任意 161 任意 ホスト IP 許可
  UDP 任意 161 任意 ホスト IP 許可
CIFS クライアント TCP 任意 445 ホスト IP 任意 許可
  UDP 任意 445 ホスト IP 任意 許可
CIFS サーバー TCP 任意 445 任意 ホスト IP 許可
  UDP 任意 445 任意 ホスト IP 許可
RPC クライアント TCP 任意 135 ホスト IP 任意 許可
  UDP 任意 135 ホスト IP 任意 許可
RPC サーバー TCP 任意 135 任意 ホスト IP 許可
  UDP 任意 135 任意 ホスト IP 許可
追加 RPC ポート アウト TCP 任意 57952 ホスト IP 任意 許可
NetBIOS クライアント TCP 任意 137 ホスト IP 任意 許可
  UDP 任意 137 ホスト IP 任意 許可
  TCP 任意 139 ホスト IP 任意 許可
  UDP 任意 138 ホスト IP 任意 許可
NetBIOS サーバー TCP 任意 137 任意 ホスト IP 許可
  UDP 任意 137 任意 ホスト IP 許可
  TCP 任意 139 任意 ホスト IP 許可
  UDP 任意 138 任意 ホスト IP 許可
NTP クライアント TCP 任意 123 ホスト IP 任意 許可
  UDP 任意 123 ホスト IP 任意 許可
監視クライアント 任意 任意 任意 ホスト IP MOM サーバー 許可
LDAP クライアント TCP 任意 389 ホスト IP 任意 許可
  UDP 任意 389 ホスト IP 任意 許可
  TCP 任意 636 ホスト IP 任意 許可
  UDP 任意 636 ホスト IP 任意 許可
Kerberos クライアント TCP 任意 88 ホスト IP 任意 許可
  UDP 任意 88 ホスト IP 任意 許可
ターミナル サービス TCP 任意 3389 任意 ホスト IP 許可
グローバル カタログ クライアント TCP 任意 3268 ホスト IP 任意 許可
  TCP 任意 3269 ホスト IP 任意 許可
WINS 解決サーバー TCP 任意 1512 任意 ホスト IP 許可
  UDP 任意 1512 任意 ホスト IP 許可
WINS 複製クライアント TCP 任意 42 ホスト IP 任意 許可
  UDP 任意 42 ホスト IP 任意 許可
WINS 複製サーバー TCP 任意 42 任意 ホスト IP 許可
  UDP 任意 42 任意 ホスト IP 許可
ICMP ICMP 任意 任意 ホスト IP 任意 許可
全受信トラフィック 任意 任意 任意 任意 ホスト IP ブロック

注 : 表 7.7 にリストされているホスト IP 宛先アドレスは、サーバーで構成している IP アドレスに設定します。

ここにあげたすべての規則は、実装時に反映することをお勧めします。これにより、サーバーに着信するどのようなトラフィックも、発信元サーバーに戻ることができます。

上記に示すように、WINS サーバーでは多数のポートとサービスが開いています。WINS サーバーで最も厳密なセキュリティを設定すると、追加ポートをブロックできます。ただし、このような追加ポートは、コンピュータを管理しやすくするために開かれたものです。このような機能が追加になっても、WINS 管理とサーバー管理のすべての機能はターミナル サービス経由で実行できます。

また、Contoso 社は自社環境に MOM サーバーを実装しています。MOM サーバーと OnePoint クライアント (MOM コンソールに報告するクライアント アプリケーション) 間の通信が頻繁に発生するため、サーバーと MOM サーバー間ではすべてのネットワーク トラフィックを許可しています。

注 : Windows 2000 Server IPSec フィルタリングは、完全な機能を備えたファイアウォールを置き換えるようには設計されていません。IPSec フィルタリングは、サーバーを強化するツールとして検討することをお勧めします。IPSec を使うことで、静的なフィルタで防げる攻撃に対して防御策を提供できます。さらに、IPSec フィルタリングではワームやウイルスからの悪意のあるコード トラフィックを取り込み、制御できます。IPSec フィルタリングには、ツールを使う前に理解しておくべき、セキュリティに関する重要な特性がいくつかあります。

  1. セキュリティで妥協すると、攻撃者が Local Administrator または Local System アクセスを握ることになり、IPSec ポリシーを無効にするかまたは変更できるようになります。

  2. ターゲットのコンピュータが適切にロックダウンされていることを保証するには、NoDefaultExempt のレジストリの値は 1 に設定しておく必要があります。この設定は、このセキュリティのガイダンスで使用するすべての IPSec フィルタリング シナリオで必要です。この IPSec ガイダンスでは、シナリオごとに NoDefaultExempt を設定したテストを実施していませんが、この設定の構成の違いで、動作に大きな差は出ません。このガイドは構成変更を反映して、可能な限り早く更新していきます。NoDefaultExempt 設定の構成に関する指示については、サポート技術情報記事 254728 「IPSec がドメイン コントローラ間の Kerberos トラフィックをセキュリティで保護されません。」を参照してください。

  3. IPSec では出力方向の接続に多様なフィルタリング機能を提供していません。このため、このセキュリティ ガイダンスの一環で、静的な入力フィルタが作成され、出力情報への応答を受信できるように保証しています。これにより、攻撃者が現在のシステムのサーバーのオープン ポートを走査し、接続を試みたとしても、その多くは効果的にブロックされます。ただし、攻撃者が IPSec 入力許可フィルタを通じて接続を可能にする特殊なツールを使う可能性はまだ存在しています。任意の宛先の IP (Internet Protocol) アドレスへの出力許可フィルタが必要ば場合 (たとえば、出力フィルタリングを使用すれば、SMTP (Simple Mail Transfer Protocol) サーバーはインターネットに接続されている他の宛先 SMTP サーバーに電子メールを送信できます)、ファイアウォールまたは多様な機能を持つフィルタリング装置をホスト コンピュータとインターネットの間に設置する必要があります。可能であれば、出力許可フィルタは、トラフィックの受信に必要な IP アドレスに対応させることをお勧めします。

重要 : IPSec であっても、コンピュータを起動中は完全なセキュリティを提供できません。TCP/IP (Transmission Control Protocol/Internet Protocol) スタックの応答が良い場合もまれにあり、IPSec ポリシーでブロックするアプリケーション ポートに自動攻撃でアクセスできてしまう場合があります。多くの場合、アプリケーションが接続処理を開始できないうちに、IPSec フィルタリングが有効になります。IPSec ポリシー エージェント サービスの開始と同期を取っても、フィルタがタイミング良く有効になることを保証するものではありません。

IPSec フィルタを使って最高レベルのセキュリティを実現するには、コンピュータの再起動中はコンピュータをネットワークから切り離すことをお勧めします。IPSec フィルタが有効になる正確な時間は、サーバー構成と IPSec ポリシーのサイズで決まる多くの要因に依存します。ローカルにテストを行い、サーバーをネットワークに再接続するまでの安全な時間間隔を決定します。テストを実施できない場合は、入力トラフィックを許可ポートのみに制限するためにファイアウォールやフィルタリング ルーターを使用します。

スクリプト コマンド

次のコマンドの実装は、サーバーで実行することをお勧めします。これらのコマンドでは、特別に許可しているネットワーク トラフィック以外のトラフィックをすべてブロックします。このコマンドのセットは、このガイドに付属するバッチ ファイルにも含まれています。

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
   -f 192.168.100.22+*:53:TCP -f 192.168.100.22+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
   -f *+192.168.100.22:161:TCP -f *+192.168.100.22:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"
   -f 192.168.100.22+*:445:TCP -f 192.168.100.22+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
   -f *+192.168.100.22:445:TCP -f *+192.168.100.22:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
   -f 192.168.100.22+*:135:TCP -f 192.168.100.22+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
   -f *+192.168.100.22:135:TCP -f *+192.168.100.22:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
   -f 192.168.100.22+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
   -f 192.168.100.22+*:137:TCP -f 192.168.100.22+*:137:UDP -f
   192.168.100.22+*:139:TCP -f 192.168.100.22+*:138:UDP -n
   PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
   -f *+192.168.100.22:137:TCP -f *+192.168.100.22:137:UDP
   -f *+192.168.100.22:139:TCP -f *+192.168.100.22:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
   -f 192.168.100.22+*:123:TCP -f 192.168.100.22+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
   -f 192.168.100.22+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
   -f 192.168.100.22+*:389:TCP -f 192.168.100.22+*:389:UDP
   -f 192.168.100.22+*:636:TCP -f 192.168.100.22+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
   -f 192.168.100.22+*:88:TCP -f 192.168.100.22+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
   -f *+192.168.100.22:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
   -f 192.168.100.22+*:3268:TCP -f 192.168.100.22+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
   -f 192.168.100.22+*:*:ICMP -f *+192.168.100.22:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Resolution Server"
   -f *+192.168.100.22:1512:TCP -f *+192.168.100.22:1512:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Client"
   -f 192.168.100.22+*:42:TCP -f 192.168.100.22+*:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Server"
   -f *+192.168.100.22:42:TCP -f *+192.168.100.22:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
   -f *+192.168.100.22 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

予想される影響

これらの設定では、ランダムな大きな番号のポートのネットワーク トラフィックを許可していないので、RPC トラフィックは許可されません。これによりサーバー管理は困難になります。ただし、CIFS およびベーシックな NetBIOS ポートを使用すると、サーバーの使いやすさが大きく改善されます。管理者は、ターミナル サービス (Terminal Services) クライアントに接続し、リモート管理を実行できるようにすることをお勧めします。ターミナル サービス利用時には、リモート コンピュータにドライブをマッピングできるようにすることをお勧めします。さらに、管理者は他のコンピュータからもサーバー方向へのドライブのマッピングを行うことができます。上記のポリシーはこのような機能を制限するように厳しくすることができますが、サーバーの管理は難しくなります。

このような比較的少数の IPSec ポリシーの実装では、サーバーのパフォーマンスに目立った影響はありません。ただし、充分にテストを行ってからフィルタを環境に実装し、必要な機能と性能を検証することをお勧めします。これ以外のアプリケーションを使用している環境でサポートするには、さらに規則の追加が必要になるでしょう。

Contoso 社のシナリオ

Contoso 社では、WINS サーバー用に上記仕様の IPSec フィルタを実装しました。

追加セキュリティ設定 — DHCP

ロギングの設定

脆弱性

DHCP クライアントでは、多くのイベント ログの中に格納されている情報が、IP アドレスではなくコンピュータ名であるため、ログ エントリで追跡することは困難です。DHCP 監査ログは、法的な証拠となるものの中でも内部攻撃または不穏な行動の原因を突き止められるツールとなります。

ただし、このようなログ内の情報は、ホスト名と MAC (Media Access Control) アドレスの両方の偽造やスプーフィングが可能なため、必ずしも絶対であるとは言えません。いずれの場合でも、短い間に IP アドレスがどのように使用されたかを突き止めるのに IP アドレスとレコードしかないというギャップを埋められるようにする情報を収集することには、コストに見合う大きな利点があります。

DHCP 監査ロギング機能は既定では有効になっていないので、この情報は収集されません。

対応策

[DHCP audit logging] の値を [Enable] に設定します。

予想される影響

この情報はログ ファイルに特権アクセスを持つ人により悪用または変更される可能性があります。このようなファイルのアクセス許可も制限しておくことをお勧めします。

理論的には DHCP 監査ログは格納先のディスクを埋め尽くすことが可能ですが、既定の DHCP 監査ログ ディスク スペース チェックを設定するだけで、このようなことが起きないようにできます。設定をチェックし、ディスク上に他のアプリケーション向けの空きスペースが十分にあることを確認します。DhcpLogMinSpaceOnDisk 設定に関する詳細情報については、https://technet.microsoft.com/library/cc740115.aspx を参照してください。

Contoso 社のシナリオ

Contoso 社シナリオでは、この情報には実害はなく、ユーザー状況を監査する別の方法として使えそうです。

DHCP 監査ロギングを有効にする方法

  1. [DHCP Manager snap-in] を開始します。

  2. サーバー名を右クリックし、[プロパティ] をクリックし、[一般] タブをクリックします。

  3. [Enable Audit Log] のチェック ボックスをオンにし、監査ログを有効にします。

  4. DHCP サーバーを再開します。

DHCP へのサービス拒否攻撃から保護

脆弱性

DHCP サーバーは中心的なリソースなので、DHCP サーバーへのサービス拒否攻撃の影響は広範囲にわたります。DHCP サーバーが攻撃され、DHCP 要求に対するサービスを続けられなくなると、DHCP クライアントは、IP アドレスのリースを受けられなくなります。このようなクライアントが既存の IP アドレス リースを失うと、ネットワーク資源にアクセスすることができなくなります。

DHCP サーバー上のすべての利用可能なアドレスを要求する攻撃ツール スクリプトを作成するのはそれほど困難なことではありません。このような事態が起これば、後で DHCP クライアントから正式な要求が来ても、利用できる IP アドレスのプールは枯渇してなくなっています。クライアントが管理するコンピュータのネットワーク アダプタに対応するすべての DHCP IP アドレスを悪意ある 1 人のユーザーが使うことも可能で、こうなると DHCP サーバーは管理範囲内の全アドレスで IP アドレス衝突を検出し、DHCP リースを割り当てることを拒否する事態が引き起こされます。

さらに、他のすべてのネットワーク サービスと同じく、正常なトラフィックに応答する DHCP サーバー能力を枯渇させる サービス拒否 (DoS) 攻撃 (たとえば、CPU 枯渇や DHCP リスナーの要求バッファを埋め尽くす) があると、クライアントがリースや更新を要求することは不可能になります。ネットワーク ベースの サービス拒否攻撃のリスクを軽減する推奨事項としては、第 6 章「Base Windows 2000 Server のハードニング」のネットワーク攻撃に対するセキュリティの考慮事項の箇所を参照してください。

ただし、DHCP クライアントの動作上、有効なリースを持たないクライアント スタートアップ時を除き、定期的に停止することに問題はありません。DHCP 更新メッセージを送信しても DHCP サーバーが応答しない場合には、クライアントは少ししてから再試行し、最終的に更新または新しいリースを得るまで再試行を繰り返します。

一般に DHCP サーバーに対するサービス拒否攻撃は、内部の攻撃者でなければ可能ではありませんが、盗み出す機密データのあるシステムではなく、インフラストラクチャ サーバーを攻撃するというのは通常ではあまり考えられません。

対応策

DHCP サーバーを対にして構成し、割り当て IP アドレスは、ベスト プラクティスの 80/20 ルールに従い、サーバー間で分割します。80/20 ルールと DHCP プロトコルについては、https://technet.microsoft.com/library/dd143078.aspx

または、DHCP スコープのリース時間を増やし、DHCP サーバーが停止状態に陥っても、多数のクライアントが長い時間持ちこたえられるようにします。ただし、新しいコンピュータが LAN 上で再起動されると、クライアントがすぐに DHCP リースを必要とするため、この方法で対処してもサーバー停止は回避できません。

Windows 2000 サーバーと DHCP サービスのパフォーマンスと可用性を監視することもできます。

DHCP クラスタリングを構成することにより、クラスタリングされた DHCP リソースではなく、個々のホストの 1 台が攻撃される場合に、サービス拒否攻撃 (DoS) を軽減する働きをします。

最後に、環境をサブネットに分ける目的で、複数の DHCP サーバーを別々に実装して IP アドレスを振り分けることができます。各 DHCP サーバーは、任意の 1 サブネットにすべての IP アドレスを割り当てます。このアプローチを使えば、別のサブネットの DHCP サーバーに見られる問題を完全に切り離せますが、ほとんどのエンタープライズ環境で必要なフォールト トレランスを提供できません。

予想される影響

予想される影響としては、追加するサーバーの管理オーバヘッドが追加されることです。さらに、複数の DHCP サーバーにおける IP アドレスの割り当てを 80/20 ルールで注意深く設定しなければなりません。不正確に設定したサーバーが同じ IP アドレスを 2 クライアント以上に割り当てることは可能だからです。DHCP リース時間を増加させていくと、DHCP アドレス空間が枯渇した時間の長さになりますが、これは別種類のサービス拒否攻撃となります。

Contoso 社のシナリオ

Contoso 社シナリオでは、各サイトは 80/20 ルールに従って IP アドレスを割り当て、2 台の DHCP サーバーを構成しています。リース時間の規定は 8 日間で、DHCP サービスの停止が長期にわたっても、十分な時間であると考えられます。

DHCP リース時間の変更方法

  1. [DHCP Manager snap-in] を開始します。

  2. リース期間を変更する範囲を右クリックし、[プロパティ] をクリックします。

  3. [一般] タブにある [Lease duration for DHCP clients] ダイアログ ボックスで、[期間:] の値を実装したい時間幅に変更します。

    [無期限] リース期間オプションを選択することもできますが、制限された状況でのみこの設定を推奨できます。エンタープライズの DHCP の一般導入用には推奨しません。

IPSec フィルタでポートをブロック

脆弱性

以前に述べたように、オープン状態のポート数を削減し、サーバーをアクティブにリッスンすることは、各コンピュータの攻撃対象エリアを大きく削減します。オープン ポートは攻撃者に組織内の他のサーバーを攻撃する踏み台を提供します。たとえば、ワームやトロイの木馬は、サーバーの未承認ポートにバインドするアプリケーションをインストールし、入力コマンドをリッスンします。

対応策

指定するトラフィックのみを許可する IPSec ブロッキング フィルタを以下に設定します。これにより、要求を受信できたり攻撃対象となる、予想していない未承認アプリケーション数を削減します。

DHCP サーバーの IPSec ネットワーク トラフィック マップ

表 7.8 DHCP サーバーの IPSec ネットワーク トラフィック マップ

サービス プロトコル ソース ポート 宛先ポート ソース アドレス 宛先アドレス 動作
DNS クライアント TCP 任意 53 ホスト IP 任意 許可
  UDP 任意 53 ホスト IP 任意 許可
SNMP サーバー TCP 任意 161 任意 ホスト IP 許可
  UDP 任意 161 任意 ホスト IP 許可
CIFS クライアント TCP 任意 445 ホスト IP 任意 許可
  UDP 任意 445 ホスト IP 任意 許可
CIFS サーバー TCP 任意 445 任意 ホスト IP 許可
  UDP 任意 445 任意 ホスト IP 許可
RPC クライアント TCP 任意 135 ホスト IP 任意 許可
  UDP 任意 135 ホスト IP 任意 許可
RPC サーバー TCP 任意 135 任意 ホスト IP 許可
  UDP 任意 135 任意 ホスト IP 許可
追加 RPC ポート アウト TCP 任意 57952 ホスト IP 任意 許可
NetBIOS クライアント TCP 任意 137 ホスト IP 任意 許可
  UDP 任意 137 ホスト IP 任意 許可
  TCP 任意 139 ホスト IP 任意 許可
  UDP 任意 138 ホスト IP 任意 許可
NetBIOS サーバー TCP 任意 137 任意 ホスト IP 許可
  UDP 任意 137 任意 ホスト IP 許可
  TCP 任意 139 任意 ホスト IP 許可
  UDP 任意 138 任意 ホスト IP 許可
NTP クライアント TCP 任意 123 ホスト IP 任意 許可
  UDP 任意 123 ホスト IP 任意 許可
監視クライアント 任意 任意 任意 ホスト IP MOM サーバー 許可
LDAP クライアント TCP 任意 389 ホスト IP 任意 許可
  UDP 任意 389 ホスト IP 任意 許可
  TCP 任意 636 ホスト IP 任意 許可
  UDP 任意 636 ホスト IP 任意 許可
Kerberos クライアント TCP 任意 88 ホスト IP 任意 許可
  UDP 任意 88 ホスト IP 任意 許可
ターミナル サービス TCP 任意 3389 任意 ホスト IP 許可
グローバル カタログ クライアント TCP 任意 3268 ホスト IP 任意 許可
  TCP 任意 3269 ホスト IP 任意 許可
DHCP サーバー UDP 68 67 任意 ホスト IP 許可
ICMP ICMP 任意 任意 ホスト IP 任意 許可
全受信トラフィック 任意 任意 任意 任意 ホスト IP ブロック

注 : 表 7.8 にリストされているホスト IP 宛先アドレスは、サーバーで構成している IP アドレスに設定します。

ここにあげたすべての規則は、実装時に反映することをお勧めします。これにより、サーバーに着信するどのようなトラフィックも、発信元サーバーに戻ることができます。

上に示すように、DHCP サーバーでは多数のポートとサービスが開いています。DHCP サーバーで最も厳密なセキュリティを設定すると、追加ポートをブロックできます。ただし、このような追加ポートは、コンピュータを管理しやすくするために開かれたものです。このような機能が追加になっても、DHCP 管理とサーバー管理のすべての機能はターミナル サービス経由で実行できます。

また、Contoso 社は自社環境に MOM サーバーを実装しています。MOM サーバーと OnePoint クライアント (MOM コンソールに報告するクライアント アプリケーション) 間の通信は頻繁に行われるため、サーバーと MOM サーバー間ではすべてのネットワーク トラフィックを許可しています。

注 : Windows 2000 Server IPSec フィルタリングは、完全な機能を備えたファイアウォールを置き換えるようには設計されていません。IPSec フィルタリングは、サーバーを強化するツールとして検討することをお勧めします。IPSec を使うことで、静的なフィルタで防げる攻撃に対して防御策を提供できます。さらに、IPSec フィルタリングではワームやウイルスからの悪意のあるコード トラフィックを取り込み、制御することができます。IPSec フィルタリングには、ツールを使う前に理解しておくべき、セキュリティに関する重要な特性がいくつかあります。

  1. セキュリティで妥協すると、攻撃者が Local Administrator または Local System アクセスを握ることになり、IPSec ポリシーを無効にするかまたは変更できるようになります。

  2. ターゲットのコンピュータが適切にロックダウンされていることを保証するには、NoDefaultExempt のレジストリの値は 1 に設定しておく必要があります。この設定は、このセキュリティのガイダンスで使用するすべての IPSec フィルタリング シナリオで必要です。この IPSec ガイダンスでは、シナリオごとに NoDefaultExempt を設定してテストを実施していませんが、この設定の構成の違いによって、動きに大きな差は出ません。このガイドはこの構成変更を反映して、できるだけ早く更新していきます。NoDefaultExempt 設定の構成に関する指示については、サポート技術情報記事 254728 「IPSec がドメイン コントローラ間の Kerberos トラフィックをセキュリティで保護されません。」を参照してください。

  3. IPSec では出力方向の接続に多様なフィルタリング機能を提供していません。このため、このセキュリティ ガイダンスの一環で、静的な入力フィルタが作成され、出力情報への応答を受信できるように保証しています。これにより、攻撃者が現在のシステムのサーバーのオープン ポートを走査し、接続を試みたとしても、その多くは効果的にブロックされます。ただし、攻撃者が IPSec 入力許可フィルタを通じて接続を可能にする特殊なツールを使う可能性はまだ存在しています。任意の宛先の IP (Internet Protocol) アドレスへの出力許可フィルタが必要な場合は (たとえば、出力フィルタリングを使用すれば、SMTP (Simple Mail Transfer Protocol) サーバーはインターネットに接続されている他の宛先 SMTP サーバーに電子メールを送信できます)、ファイアウォールまたは多様な機能を持つフィルタリング装置をホスト コンピュータとインターネットの間に設置する必要があります。可能であれば、出力許可フィルタは、トラフィックの受信に必要な IP アドレスに対応させることをお勧めします。

重要 : IPSec であっても、コンピュータ起動中は完全なセキュリティを提供できません。TCP/IP (Transmission Control Protocol/Internet Protocol) スタックの応答が良い場合もまれにあり、IPSec ポリシーでブロックするアプリケーション ポートに自動攻撃でアクセスできてしまう場合があります。多くの場合、アプリケーションが接続処理を開始できないうちに、IPSec フィルタリングが有効になります。IPSec ポリシー エージェント サービスの開始と同期を取っても、フィルタがタイミング良く有効になることを保証するものではありません。

IPSec フィルタを使って最高レベルのセキュリティを実現するには、コンピュータの再起動中はコンピュータをネットワークから切り離すことをお勧めします。IPSec フィルタが有効になる正確な時間は、サーバー構成と IPSec ポリシーのサイズで決まる多くの要因に依存します。ローカルにテストを行い、サーバーをネットワークに再接続するまでの安全な時間間隔を決定します。テストを実施できない場合は、入力トラフィックを許可ポートのみに制限するためにファイアウォールやフィルタリング ルーターを使用します。

スクリプト コマンド

次のコマンドの実装は、サーバーで実行することをお勧めします。これらのコマンドでは、特別に許可しているネットワーク トラフィック以外のトラフィックをすべてブロックします。

このコマンドのセットは、このガイドに付属するバッチ ファイルにも含まれています。

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
   -f 192.168.100.21+*:53:TCP -f 192.168.100.21+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
   -f *+192.168.100.21:161:TCP -f *+192.168.100.21:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Client"
   -f 192.168.100.21+*:445:TCP -f 192.168.100.21+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Server"
   -f *+192.168.100.21:445:TCP -f *+192.168.100.21:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
   -f 192.168.100.21+*:135:TCP -f 192.168.100.21+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
   -f *+192.168.100.21:135:TCP -f *+192.168.100.21:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
   -f 192.168.100.21+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
   -f 192.168.100.21+*:137:TCP -f 192.168.100.21+*:137:UDP
      -f 192.168.100.21+*:139:TCP -f 192.168.100.21+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
   -f *+192.168.100.21:137:TCP -f *+192.168.100.21:137:UDP
   -f *+192.168.100.21:139:TCP -f *+192.168.100.21:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
   -f 192.168.100.21+*:123:TCP -f 192.168.100.21+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
   -f 192.168.100.31+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
   -f 192.168.100.21+*:389:TCP -f 192.168.100.21+*:389:UDP
   -f 192.168.100.21+*:636:TCP -f 192.168.100.21+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
   -f 192.168.100.21+*:88:TCP -f 192.168.100.21+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
   -f *+192.168.100.21:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
   -f 192.168.100.21+*:3268:TCP -f 192.168.100.21+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP IN OUT"
   -f 192.168.100.21+*:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DHCP Server"
   -f *:68:UDP+192.168.100.21:67:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
   -f *+192.168.100.21 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

予想される影響

これらの設定では、ランダムな大きな番号のポートのネットワーク トラフィックを許可していないので、RPC トラフィックは許可されません。これによりサーバー管理は困難になります。ただし、CIFS およびベーシックな NetBIOS ポートを使用すると、サーバーの使いやすさが大きく改善されます。管理者は、ターミナル サービス (Terminal Services) クライアントに接続し、リモート管理を実行できるようにすることをお勧めします。ターミナル サービス利用時には、リモート コンピュータにドライブをマッピングできるようにすることをお勧めします。さらに、管理者は他のコンピュータからサーバー方向へのドライブのマッピングを行うことができます。上記のポリシーはこのような機能を制限するように厳しくすることができますが、サーバーの管理は難しくなります。

このような比較的少数の IPSec ポリシーの実装では、サーバーのパフォーマンスに目立った影響はありません。ただし、充分にテストを行ってから、フィルタを環境に実装し、組織に必要な機能と性能を検証することをお勧めします。これ以外のアプリケーションを使用している環境でサポートするには、さらに規則の追加が必要になるでしょう。

Contoso 社のシナリオ

Contoso 社では、DHCP サーバー用に上記仕様の IPSec フィルタを実装しました。

ページのトップへ

ファイルとプリント サーバー の役割

ファイルとプリント サーバー の役割を有するサーバーで最も重要なサービスは、Windows NetBIOS 関連製品を必要とするサービスなので、セキュリティを強化することは困難です。SMB と CIFS のプロトコルは、未認証ユーザーにもかなりの情報を提供できるため、強力なセキュリティで保護されている Windows 環境では無効にしておくことをお勧めします。

ファイルおよびプリントの増分グループ ポリシー

ファイルおよびプリントのグループ ポリシーでは次の 2 つのことを行います。

  • スプーラ サービスを有効にします。これは印刷に使用されます。

  • [常にデジタル署名によるサーバー通信] のセキュリティ オプション設定を無効にします。この設定を無効にしておかないと、クライアントは印刷できてもプリント キューを表示できません。プリント キューの表示を試みると、「接続できません。アクセス拒否」のメッセージを受け取ります。

注 : Windows 2000 ファイルとプリント サーバーで、印刷クライアント向けにプリント キューの表示サポートを行うには、クライアント コンピュータ側で [常にデジタル署名によるクライアント通信] を無効に設定しておくことをお勧めします。

システム サービス

すべてのサービスおよびアプリケーションは潜在的な攻撃対象となるため、不要なサービスは無効にし、必要ない実行ファイルは削除しておくことをお勧めします。MSBP では、このようなオプション サービスだけでなく、すべての不要なサービスを無効にしています。ただし、ファイルとプリント サーバー の役割は、ここで無効にするプリント スプーラ サービスに依存しています。したがって、ファイルとプリント ポリシーでは、スタートアップ モードで自動に設定します。

注 : このスプーラ サービスは、プリント サーバーに印刷ジョブを送信する、または印刷ジョブを開始するクライアントでも利用されています。MSBP はスプーラ サービスを無効にするので、ファイルとプリント サーバー以外のサーバーからは印刷ジョブを依頼できません。別のサーバーから印刷したい場合は、対応するグループ ポリシーでスプーラ サービスを有効にする必要があります。

Windows 2000 のファイルとプリント サーバーで頻繁に有効にするサービスは他にもありますが、重要なものではありません。このようなサービスは Contoso 社シナリオでは無効にしていますが、こうしたサービスの利用とセキュリティについては議論の対象となります。このため、このガイドでのサーバー の役割に関する推奨事項は、異なる環境には適用できないと思われます。これらのファイルとプリント グループ ポリシーの推奨事項については組織の要件に合わせて調整してください。

分散ファイル システム (DFS)

分散ファイル システム (DFS) は、分散されたファイル共有を 1 つの論理的な名前空間に統合するサービスです。DFS では、LAN または WAN (Wide Area Network) 内に分散している論理ボリュームを管理しており、Active Directory SYSVOL 共有に必要とされています。

この名前空間はネットワーク ユーザーから利用可能なネットワーク記憶域リソースを論理的に表現したものです。DFS サービスが停止すると、ユーザーは論理的な名前空間を通じてネットワーク データにアクセスできなくなります。ユーザーがデータにアクセスするには、名前空間にある全サーバーと共有の名前を知り、これらのターゲットに個々にアクセスする必要があります。

DFS は、Contoso 社シナリオにおけるファイルとプリント ロールではサポートされていません。このため、DFS サービスは、ファイルとプリント グループ ポリシーでは無効になっています。組織が単に分散リソースにアクセスするためだけに、ファイル サーバーで DFS を使用するのなら、ファイルとプリント サーバー グループ ポリシーを修正するか、新しい GPO を作成して、このサービスを有効にし、DFS を有効とする必要があるファイル サーバーに適用する必要があります。

NT ファイル複製サービス

NTFRS (NT File Replication Service) では、複数のサーバー間でファイル ディレクトリ コンテンツの同期を保ちます。NTFRS は、Windows 2000 における自動ファイル複製サービスです。このサービスでは同時に複数のサーバーにファイルの複製を維持し、すべてのドメイン コントローラに Windows 2000 システム ボリューム SYSVOL も複製します。

NTFRS は、フォールト トレラントな DFS と関連した別ターゲット間でファイルを複製する設定にすることができます。このサービスが無効になると、ファイル複製は行われず、サーバー データの同期は取られません。

NTFRS は、Contoso 社シナリオにおけるファイルとプリント ロールではサポートされていません。このため、NTFRS サービスは、ファイルとプリント グループ ポリシーでは無効となっています。組織が単に複数サーバー上でデータを複製するためだけに、ファイル サーバーで NTFRS を使用するのなら、ファイルとプリント サーバーのグループ ポリシーを修正するか、新しい GPO を作成して、このサービスを有効にし、これを必要とするファイル サーバーに適用する必要があります。

追加セキュリティ設定

既定のファイル共有許可のリセット

脆弱性

既定で、ローカルの管理者、Power Users、および Server Operators groups のメンバは新しいファイル共有とプリンタ共有を作成できます。新しいファイル共有では、Everyone と呼ばれる特殊なビルトイン グループに、既定でフル コントロールの共有許可を与えています。IT チームのメンバがうっかり新しい共有を作成すると、誰でもその共有フォルダに接続でき、フォルダ内オブジェクトにアクセスしてオブジェクトをフル コントロールできるため、潜在的な脆弱性になります。

注 : ビルトインの Power Users グループはドメイン コントローラでは利用できませんが、ドメイン コントローラには同様の特権を有する Server Operators と呼ばれるグループがあります。

対応策

新しいファイル共有を作成できるすべての管理者を教育し、共有許可を手作業で設定し、共有にアクセスする必要があるユーザーのみがその共有を利用でき、しかもできるだけ制限する方向で許可を設定するようにします。

予想される影響

共有フォルダを作成、管理するユーザーは、その共有許可を手作業で設定する必要があります。

Contoso 社のシナリオ

ファイルとプリント サーバーで作成されたすべてのファイル共有は、認証されているユーザーのみに許可するように設定しました。許可の変更、および共有フォルダとファイルも、NTFS 許可を使い、適切にセキュリティ保護を行いました。

新しい共有向けに共有許可を手作業で変更する方法

  1. [MMC のコンピュータ管理スナップイン] を開始し、[共有フォルダ] から [共有] ノードを表示します。

  2. [共有] を右クリックし、[新しいファイル共有] を選択し、[参照] ボタンをクリックし、[共有するフォルダ] (たとえば、E:\Users) を探します。[共有名] ダイアログ ボックスで共有に名前を付けます。

  3. [共有フォルダの作成] ウィンドウで、[共有とフォルダのアクセス許可をカスタマイズする] のラジオ ボタンを選択し、[カスタム] ボタンをクリックします。

  4. [Everyone] をリストから削除するため、[削除] ボタンをクリックします。[追加] ボタンをクリックし、下部のテキスト領域で [Authenticated Users] と入力 (名前をセミコロンで区切って入力、またはリストから選択) し、[OK] ボタンをクリックします。

  5. [許可] 列にある [変更] チェック ボックスにチェックを付け、[OK] をクリックし、次に [完了] ボタンをクリックします。プロンプトで [No] を選択します。

既存ファイルの共有許可の監査

脆弱性

上で述べたように、新しいファイル共有では、Everyone と呼ばれる特殊なビルトイン グループに、既定でフル コントロールの共有許可を与えています。これは、Everyone グループにフル コントロールを許可している共有フォルダがネットワークに存在している可能性を示唆しています。

対応策

組織内のすべての共有フォルダを監査し、各フォルダに適切なアクセス許可が割り当てられていることを確認します。手作業で各ファイル サーバーを見ていくか、または net view のようなコマンドやサードパーティ製ツールを使用し、すべてのファイル共有のアクセス許可を自動的にドキュメントにしていきます。

予想される影響

共有フォルダのアクセス許可を訂正していく過程で、正当なユーザーがリソースへアクセスできなくなる可能性があります。このような状況は起き次第、対処する必要があります。

このケースは特に、SIDHistory に格納されている SID (Security ID) にアクセスできるアクセス許可を使ってアクセスしているユーザーに影響があります。SID は、ネットワークの各ユーザー、グループ、コンピュータ アカウント、およびログオン セッションを一意に識別する値です。

現在の Active Directory フォレストの一部ではない、古い Windows NT 4.0 ドメインまたは Windows 2000 ドメインから Windows ユーザー アカウントを移行してきている場合には、新しいドメイン ユーザー アカウントの SIDHistory 属性を使用し、ユーザーのアクセス許可をそのまま利用するツールを使って移行処理が行われます。SIDHistory 属性は、移行アカウントから以前の SID を記録し、既存のセキュリティ保護されたリソースへのアクセスを維持します。

SIDHistory の最も一般的な利用形態は、すべての ACL を更新しなくても、ファイルとプリンタ共有への既存のアクセスを維持できるようにするものです。

既存のファイルとプリンタ共有へのアクセス許可は、現在のユーザー アカウントまたはグループへのアクセスを許可する形に更新されていない場合があり、ユーザーはユーザーの SIDHistory 属性の SID が使えるアクセス許可に依存していることを知らない可能性があります。

移行アカウントや SIDHistory の知識がない管理者にとっては、前から存在しているファイルやプリンタ共有に、不必要なエントリ、またはドメイン内の既存ユーザーやグループには適合しないエントリが存在するように見えます。ただし、このようなエントリが削除されると、SIDHistory に依存してアクセスしていたユーザーはアクセスできなくなり、これらのファイルやプリンタ共有へのすべてのアクセス経路を失う可能性もあります。

環境内に古い Windows ドメインからユーザー アカウントを移行する前から存在しているファイルとプリント サーバーがある場合は、ACL の変更作業を実施する前に、ファイルとプリンタ共有への現在のアクセス許可を注意深くドキュメント化しておくことをお勧めします。同一のアクセスを提供する新 ACL の作成準備を進めるか、または削除した ACL エントリを保存するため、バックアップ メディアからファイルとプリント サーバーに復元できる準備をしておきます。

Contoso 社のシナリオ

Contoso 社環境には以前から存在するファイル サーバーがないため、既存のファイル共有許可を更新する必要はありませんでした。すべての新ファイル共有は、ユーザーに必要最低限の許可だけを与えるため、手作業で設定されました。

IPSec フィルタでポートをブロック

脆弱性

上で述べたように、オープン状態のポート数を削減し、サーバーをアクティブにリッスンすることは、各コンピュータの攻撃対象エリアを大きく削減します。オープン ポートは攻撃者に組織内の他のサーバーを攻撃する踏み台を提供します。たとえば、ワームやトロイの木馬は、サーバーの未承認ポートにバインドするアプリケーションをインストールし、入力コマンドをリッスンします。

対応策

指定するネットワーク トラフィックのみを許可する IPSec ブロッキング フィルタを以下に設定します。これにより、要求を受信できたり攻撃対象となったりする、予想していない未承認アプリケーション数を削減します。

ファイルとプリント サーバーがクライアント混在シナリオで動作するには RPC トラフィックが必要であり、このようなサーバーの役割は他のサーバー の役割とは多少異なります。このため、以下のネットワーク トラフィック マップで示すように、いくつかのものは別々の項目として取り扱う必要があります。

ファイルとプリント サーバーの IPSec ネットワーク トラフィック マップ

表 7.9 ファイルとプリント サーバーの IPSec ネットワーク トラフィック マップ

サービス プロトコル ソース ポート 宛先ポート ソース アドレス 宛先アドレス 動作
DNS クライアント TCP 任意 53 ホスト IP 任意 許可
  UDP 任意 53 ホスト IP 任意 許可
SNMP サーバー TCP 任意 161 任意 ホスト IP 許可
  UDP 任意 161 任意 ホスト IP 許可
CIFS クライアント TCP 任意 445 ホスト IP 任意 許可
  UDP 任意 445 ホスト IP 任意 許可
CIFS サーバー TCP 任意 445 任意 ホスト IP 許可
  UDP 任意 445 任意 ホスト IP 許可
RPC クライアント TCP 任意 135 ホスト IP 任意 許可
  UDP 任意 135 ホスト IP 任意 許可
RPC サーバー TCP 任意 135 任意 ホスト IP 許可
  UDP 任意 135 任意 ホスト IP 許可
追加 RPC ポート アウト TCP 任意 57952 ホスト IP 任意 許可
NetBIOS クライアント TCP 任意 137 ホスト IP 任意 許可
  UDP 任意 137 ホスト IP 任意 許可
  TCP 任意 139 ホスト IP 任意 許可
  UDP 任意 138 ホスト IP 任意 許可
NetBIOS サーバー TCP 任意 137 任意 ホスト IP 許可
  UDP 任意 137 任意 ホスト IP 許可
  TCP 任意 139 任意 ホスト IP 許可
  UDP 任意 138 任意 ホスト IP 許可
NTP クライアント TCP 任意 123 ホスト IP 任意 許可
  UDP 任意 123 ホスト IP 任意 許可
監視クライアント 任意 任意 任意 ホスト IP MOM サーバー 許可
LDAP クライアント TCP 任意 389 ホスト IP 任意 許可
  UDP 任意 389 ホスト IP 任意 許可
  TCP 任意 636 ホスト IP 任意 許可
  UDP 任意 636 ホスト IP 任意 許可
Kerberos クライアント TCP 任意 88 ホスト IP 任意 許可
  UDP 任意 88 ホスト IP 任意 許可
ターミナル サービス TCP 任意 3389 任意 ホスト IP 許可
グローバル カタログ クライアント TCP 任意 3268 ホスト IP 任意 許可
  TCP 任意 3269 ホスト IP 任意 許可
RPC ポート TCP 任意 RPC 範囲 任意 ホスト IP 許可
ICMP ICMP 任意 任意 ホスト IP 任意 許可
全受信トラフィック 任意 任意 任意 任意 ホスト IP ブロック

注 : 表 7.9 にリストされているホスト IP 宛先アドレスは、サーバーで設定している IP アドレスに構成します。

クライアントがファイルとプリント リソースにアクセスできるようにするには、ファイルとプリント サーバー に多数の RPC 接続が必要なので、RPC 専用として使用するポート範囲を指定することをお勧めします。環境内で RPC が一定数のポートに制限されるのであれば、選択するポート範囲は 50,000 以上のポートにすることをお勧めします。これは次のレジストリ設定により設定可能です。

まだ存在していなければ、HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet キーを作成する必要があります。

HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\Ports は、開くべきポート範囲を代表する値を持つ REG_MULTI_SZ で作成、設定する必要があります。

HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\PortsInternetAvailable は Y の値を持つ REG_SZ で作成、設定する必要があります。

HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\UseInternetPorts は Y の値を持つ REG_SZ で作成、設定する必要があります。

レジストリに上記変更を行った後は、サーバーを再起動することをお勧めします。

このような変更はパフォーマンスに影響を与えることがあり、製品に実装する前にテストすることをお勧めします。正確にいくつのポートが開かれるかは、サーバーの使用率と機能に依存しています。

ここにあげたすべての規則は、実装時に反映することをお勧めします。これにより、サーバーに着信するどのようなトラフィックも、発信元サーバーに戻ることができます。

これで分かるようにファイルとプリント サーバーでは、いくつかのポートとサービスが開いています。ファイルとプリント サーバーで最も厳密なセキュリティを設定すると、追加ポートをブロックできます。ただし、このような追加ポートは、コンピュータを管理しやすくするために開かれたものです。このような機能が追加になっても、DHCP 管理とサーバー管理のすべての機能はターミナル サービス経由で実行できます。

また、Contoso 社は自社環境に MOM サーバーを実装しています。MOM サーバーと OnePoint クライアント (MOM コンソールに報告するクライアント アプリケーション) 間の通信は頻繁に行われるため、サーバーと MOM サーバー間ではすべてのネットワーク トラフィックを許可しています。

注 : Windows 2000 Server IPSec フィルタリングは、完全な機能を備えたファイアウォールを置き換えるようには設計されていません。IPSec フィルタリングは、サーバーを強化するツールとして検討することをお勧めします。IPSec を使うことで、静的なフィルタで防げる攻撃に対する多層防御を提供できます。さらに、IPSec フィルタリングではワームやウイルスからの悪意のあるコード トラフィックを取り込み、制御することができます。IPSec フィルタリングには、ツールを使う前に理解しておくべき、セキュリティに関する重要な特性がいくつかあります。

  1. セキュリティで妥協すると、攻撃者が Local Administrator または Local System アクセスを握ることになり、IPSec ポリシーを無効にするかまたは変更できるようになります。

  2. ターゲットのコンピュータが適切にロックダウンされていることを保証するには、NoDefaultExempt のレジストリの値は 1 に設定しておく必要があります。この設定は、このセキュリティのガイダンスで使用するすべての IPSec フィルタリング シナリオで必要です。この IPSec ガイダンスでは、シナリオごとに NoDefaultExempt を設定してテストされていませんが、この設定の構成の違いで、動きに大きな差は出ません。このガイドはこの構成変更を反映して、できるだけ早く更新していきます。NoDefaultExempt 設定の構成に関する指示については、サポート技術情報記事 254728、「IPSec がドメイン コントローラ間の Kerberos トラフィックをセキュリティで保護されません。」を参照してください。

  3. IPSec では出力方向の接続に多様なフィルタリング機能を提供していません。このため、このセキュリティ ガイダンスの一環で、静的な入力フィルタが作成され、出力情報への応答を受信できるように保証しています。これにより、攻撃者が現在のシステムのサーバーのオープン ポートを走査し、接続を試みたとしても、その多くは効果的にブロックされます。ただし、攻撃者が IPSec 入力許可フィルタを通じて接続を可能にする特殊なツールを使う可能性はまだ存在しています。任意の宛先の IP (Internet Protocol) アドレスへの出力許可フィルタが必要な場合は (たとえば、出力フィルタリングを使用すれば、SMTP (Simple Mail Transfer Protocol) サーバーはインターネットに接続されている他の宛先 SMTP サーバーに電子メールを送信できます)、ファイアウォールまたは多様な機能を持つフィルタリング装置をホスト コンピュータとインターネットの間に設置する必要があります。可能であれば、出力許可フィルタは、トラフィックの受信に必要な IP アドレスに対応させることをお勧めします。

重要 : IPSec であっても、コンピュータ起動中は完全なセキュリティを提供できません。TCP/IP (Transmission Control Protocol/Internet Protocol) スタックの応答が良い場合もまれにあり、IPSec ポリシーでブロックするアプリケーション ポートに自動攻撃でアクセスできてしまう場合があります。多くの場合、アプリケーションが接続処理を開始できないうちに、IPSec フィルタリングが有効になります。IPSec ポリシー エージェント サービスの開始と同期を取っても、フィルタがタイミング良く有効になることを保証するものではありません。

IPSec フィルタを使って最高レベルのセキュリティを実現するには、コンピュータの再起動中はコンピュータをネットワークから切り離すことをお勧めします。IPSec フィルタが有効になる正確な時間は、サーバー構成と IPSec ポリシーのサイズで決まる多くの要因に依存します。ローカルにテストを行い、サーバーをネットワークに再接続するまでの安全な時間間隔を決定します。テストを実施できない場合は、入力トラフィックを許可ポートのみに制限するためにファイアウォールやフィルタリング ルーターを使用します。

スクリプト コマンド

IPSecPol は 1 度に 1 ポートしか追加できないという点で制約があります。RPC では広範囲にポートを開く必要があるので、開くべきポート数に応じて必要なコマンドをすべて備えたバッチ ファイルを自動生成するスクリプトを使用して処理するのが最も簡単な方法です。

以下のサンプル コードは、IPSec ポリシーに追加すべきポートごとに別のリストを含む c:\ipsec.bat というファイルを生成します。PORT_START 変数は RPC 範囲で最初に定義するポートを定義し、PORT_END は範囲の終わりを定義します。POLICY_NAME は IPSec ポリシーの名前で、ポート フィルタの追加先です。IP_ADDR の値は、ポリシーを実装するサーバーの IP アドレスを反映して修正する必要があります。

PPORT_START = 57901
PORT_END = 57950
POLICY_NAME = "Packet Filter"
RULE_NAME = "RPC Ports"
IP_ADDR = "192.168.100.31"
BATCH_FILE = "c:\ipsec.bat"
Dim fso
Dim tf
Const ForWriting = 2
Set fso = CreateObject("Scripting.FileSystemObject")
Set tf = fso.OpenTextFile(BATCH_FILE, ForWriting, True)
tf.Write "ipsecpol -w REG -p " & chr(34) & 
POLICY_NAME & chr(34) & " -r " 
& chr(34) & RULE_NAME & chr(34)
For i = PORT_START TO PORT_END
tf.Write " -f *+" & IP_ADDR & ":" & i & ":TCP"
Next
tf.WriteLine " -n PASS"
tf.Close

同様のコードを使用し、あまり手間をかけずに IPSec ポリシーを実行および確立するバッチ ファイルを生成できます。このバッチ ファイルはテーブル中の「RPC 範囲」という印より上の領域を扱います。ポートの残りについては、他のサーバー の役割で議論したものと同じ方法で扱う必要があります。

ポート範囲を決定し、フィルタを実装する IPSecPol ステートメントを作成してから、これらのものと残りのコマンドを組み合わせてサーバー上で実行することをお勧めします。以下にコマンドを 1 つにまとめたサンプルを記載します。このコマンドのセットは、このガイドに付属するバッチ ファイルにも含まれています。

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
   -f 192.168.100.31+*:53:TCP -f 192.168.100.31+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
   -f *+192.168.100.31:161:TCP -f *+192.168.100.31:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"
   -f 192.168.100.31+*:445:TCP -f 192.168.100.31+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
   -f *+192.168.100.31:445:TCP -f *+192.168.100.31:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
   -f 192.168.100.31+*:135:TCP -f 192.168.100.31+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
   -f *+192.168.100.31:135:TCP -f *+192.168.100.31:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
   -f *+192.168.100.31:57901:TCP -f *+192.168.100.31:57902:TCP
   -f *+192.168.100.31:57903:TCP -f *+192.168.100.31:57904:TCP
      -f *+192.168.100.31:57905:TCP -f *+192.168.100.31:57906:TCP
      -f *+192.168.100.31:57907:TCP -f *+192.168.100.31:57908:TCP
      -f *+192.168.100.31:57909:TCP -f *+192.168.100.31:57910:TCP
      -f *+192.168.100.31:57911:TCP -f *+192.168.100.31:57912:TCP
      -f *+192.168.100.31:57913:TCP -f *+192.168.100.31:57914:TCP
      -f *+192.168.100.31:57915:TCP -f *+192.168.100.31:57916:TCP
      -f *+192.168.100.31:57917:TCP -f *+192.168.100.31:57918:TCP
      -f *+192.168.100.31:57919:TCP -f *+192.168.100.31:57920:TCP
      -f *+192.168.100.31:57921:TCP -f *+192.168.100.31:57922:TCP
      -f *+192.168.100.31:57923:TCP -f *+192.168.100.31:57924:TCP
      -f *+192.168.100.31:57925:TCP -f *+192.168.100.31:57926:TCP
      -f *+192.168.100.31:57927:TCP -f *+192.168.100.31:57928:TCP
      -f *+192.168.100.31:57929:TCP -f *+192.168.100.31:57930:TCP
      -f *+192.168.100.31:57931:TCP -f *+192.168.100.31:57932:TCP
      -f *+192.168.100.31:57933:TCP -f *+192.168.100.31:57934:TCP
      -f *+192.168.100.31:57935:TCP -f *+192.168.100.31:57936:TCP
      -f *+192.168.100.31:57937:TCP -f *+192.168.100.31:57938:TCP
      -f *+192.168.100.31:57939:TCP -f *+192.168.100.31:57940:TCP
      -f *+192.168.100.31:57941:TCP -f *+192.168.100.31:57942:TCP
      -f *+192.168.100.31:57943:TCP -f *+192.168.100.31:57944:TCP
      -f *+192.168.100.31:57945:TCP -f *+192.168.100.31:57946:TCP
      -f *+192.168.100.31:57947:TCP -f *+192.168.100.31:57948:TCP
      -f *+192.168.100.31:57949:TCP -f *+192.168.100.31:57950:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Additional RPC Ports"
   -f 192.168.100.31+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
   -f 192.168.100.31+*:137:TCP -f 192.168.100.31+*:137:UDP
   -f 192.168.100.31+*:139:TCP -f 192.168.100.31+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
   -f *+192.168.100.31:137:TCP -f *+192.168.100.31:137:UDP
   -f *+192.168.100.31:139:TCP -f *+192.168.100.31:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
   -f 192.168.100.31+*:123:TCP -f 192.168.100.31+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
   -f 192.168.100.31+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
   -f 192.168.100.31+*:389:TCP -f 192.168.100.31+*:389:UDP
   -f 192.168.100.31+*:636:TCP -f 192.168.100.31+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
   -f 192.168.100.31+*:88:TCP -f 192.168.100.31+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
   -f *+192.168.100.31:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
   -f 192.168.100.31+*:3268:TCP -f 192.168.100.31+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
   -f 192.168.100.31+*:*:ICMP -f *+192.168.100.31:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
   -f *+192.168.100.31 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

予想される影響

この設定ではまだ RPC トラフィックが許可されているので、サーバーは設定がなくてもかなりの操作を行うことができます。これらの設定の大きな利点は、RPC トラフィックが特定範囲に制限されているということです。ただし、この場合、コンピュータに接続されているユーザー数と、確立する必要がある RPC 接続数に応じて、パフォーマンス問題を引き起こします。よくテストを行ってから、使用環境にフィルタを実装することをお勧めします。上記のポリシーはこうした機能を制限するように厳しくすることができますが、サーバーの管理は難しくなります。

このような比較的少数の IPSec ポリシーの実装では、サーバーのパフォーマンスに目立った影響はありません。ただし、充分にテストを行ってからフィルタを環境に実装し、必要な機能と性能を検証することをお勧めします。これ以外のアプリケーションを使用している環境でサポートするには、さらに規則の追加が必要になるでしょう。

Contoso 社のシナリオ

Contoso 社では、ファイルとプリント サーバー用に上記仕様の IPSec フィルタを実装しました。

ページのトップへ

IIS サーバー の役割

最近のレポートによると、9 台の IIS サーバーがあると、その中の 1 台は何らかの攻撃を受けやすいと言われています。IIS (Internet Information Services) 5.0 は、すべての Windows 2000 サーバーに既定でインストールされています。IIS 5.0 では、すぐに使える豊富なアプリケーション機能が有効になっていて、十分なセキュリティ保護を犠牲にして使いやすさを達成しているアプリケーション サービスの例になっています。この脆弱性が Nimda ワームにつけ込まれました。

セキュリティ保護レベルを上げるために、IIS の使いやすさがある程度失われる可能性があります。IIS 5.0 は極めて柔軟で、既定のインストールの一環で多数の機能を有効にしています。どのサーバーでも同じですが、有効になっているサービスや機能はすべて、その資産への攻撃対象エリアを増大させます。

IIS では堅牢なロックダウンが可能な上に、重要な機能の大部分を提供できます。以前は IIS サーバーのロックダウンと言えば時間のかかる作業でしたが、IISLockDown や URLScan のようなツールを使うことで非常に容易になりました。

IIS Lockdown Tool は、IIS に依存するマイクロソフト製品の機能の中で、使用していない機能を停止するマイクロソフトのユーティリティであり、攻撃者が利用できる攻撃対象エリアを削減します。URLScan は入力の HTTP (Hypertext Transfer Protocol) パケットを分析する ISAPI (Internet Server Application Programming Interface) フィルタで、設定したルールに基づいて Web 要求を拒否します。

このようなツールは優れた設計のサーバーと、IIS サーバーのクライアント側のネットワーク インターフェイスに設定する IPSec フィルタの利用を組み合わせることで、極めてセキュリティ保護レベルの高いソリューションを生み出します。

サーバーのパッチ処理

環境における IIS サーバー強化の第 1 ステップとして、すべてのサービス パックとセキュリティ修正プログラムを適用することは必須です。この手続きについては、第 8 章「修正プログラムの管理」で詳しく説明しています。

ネットワークに接続する前に、サーバーにすぐにパッチをあてることで、サーバーがワームや Code Red または Nimda のようなウイルスに感染することを大きく削減できます。したがって、サーバーには、ネットワークに繋ぐ前に可能な限りのパッチを適用し、セキュリティを強化しておくことをお勧めします。

IIS ロックダウン

必要なパッチを適用後、IIS サーバーを強化する第 2 ステップは、IISLockdown や URLScan のような推奨される自動化ツールを使ってサーバーを設定することです。

概要

IIS サーバーでは多くの機能を提供します。ただし、IIS サーバーをセキュリティ保護するには、このようなサーバーの機能は必要なものだけに限定することをお勧めします。これを達成する最も簡単な方法は、IIS Lockdown Tool を使うことです。

IIS Lockdown Tool は、対話的に IIS サーバーが果たすアプリケーション の役割 (たとえば、動的 Web サーバーまたは Exchange Server) を指定できる構成ユーティリティです。この指定に基づき、特定の Web サーバー の役割に必要ない機能を削除します。このような変更は運用環境に実装する前に徹底的にテストすることをお勧めします。

注 : IIS Lockdown Tool は、セキュリティ ツールキットの一部として利用可能であり、マイクロソフトのセキュリティ Web サイトから入手できます。詳細については、「詳細情報」セクションを参照してください。

IIS Lockdown Tool では、セキュリティ保護されている Web サーバーで役立つ多数のステップを実行可能です。これには次のようなものがあります。

  • サービスとコンポーネントの無効化

  • URLScan のインストール

  • 不要な ISAPI DLL スクリプト マッピングの削除

  • 不要なディレクトリの削除

  • ファイルとフォルダ ACL の変更

IIS ロックダウンは、多くの種類の IIS サーバー の役割をセキュリティで保護するために利用可能です。環境に応じて各 IIS サーバーでホスティングしているアプリケーションの種類に最も適した役割を選択することをお勧めします。

IIS ロックダウンのインストール

Contoso 社環境では、IIS は ASP (Active Server Pages) の利用をサポートする上で、最も典型的に使用される動的 Web サーバーです。IIS Lockdown Tool Version 2.1 を使って、Contoso 社環境におけるサーバーのセキュリティを保護しました。ツールのバージョンとしては、これが執筆時点で最新のものです。古いバージョンは同じような機能は提供されておらず、将来バージョンではこのガイドで利用できない新機能がサポート可能になるでしょう。

IIS Lockdown Tool を使い、手作業で動的 Web サーバーのセキュリティ保護を行う方法

  1. iislockd.exe を開始します。

  2. [次へ] をクリックします。

  3. [同意します] をクリックし、[次へ] をクリックします。

  4. [Dynamic Web server (ASP enabled)] をクリックし、[次へ] をクリックします。

  5. [Install URLScan filter on the server] が選択されていることを確認し、[次へ] をクリックします。

  6. [次へ] をクリックします。

  7. [デジタル署名が見つかりませんでした] ダイアログ ボックスが表示されたら [はい] をクリックします。

  8. [次へ] をクリックします。

  9. [完了] をクリックします。

注 : IIS Lockdown Tool は、選択した設定の導入を自動化する無人モードでも動作可能です。詳細については、iislockd.exe の自動解凍型 zip ファイルに含まれている RunLockdUnattended.doc のヘルプ ファイルを参照してください。

上記のステップに従うと、IIS サーバーを動的 Web サーバーとして設定します。設定プロセスの結果、次のように変更されます。

  • FTP サービスが無効となります。

  • 電子メール (SMTP) サービスが無効となります。

  • NNTP (Network News Transport Protocol) サービスが無効となります。

  • Index Server Web インターフェイス (.idq、.htw、.ida) スクリプト マップが無効になります。

  • サーバー サイド インクルード (.shtml、.shtm、.stm) であるスクリプト マップが無効になります。

  • Internet Data Connector (.idc) スクリプト マップが無効になります。

  • HTR スクリプティング (.htr) スクリプト マップが無効になります。

  • インターネット印刷 (.printer) スクリプト マップが無効になります。

  • プリンタ仮想ディレクトリが削除されます。

  • IIS サンプル仮想ディレクトリが削除されます。

  • スクリプト仮想ディレクトリが削除されます。

  • MSADC 仮想ディレクトリが削除されます。

  • IISAdmin 仮想ディレクトリが削除されます。

  • IISAdmin Web サイトが削除されます。

  • IISHelp 仮想ディレクトリが削除されます。

  • 匿名 IIS ユーザーがシステム ユーティリティを実行しないようにファイル アクセス許可が設定されます。

  • 匿名 IIS ユーザーがコンテンツ ディレクトリに書き込まないようにファイル アクセス許可が設定されます。

  • WebDAV (Web Distributed Authoring and Versioning) が無効になります。

  • URLScan フィルタは、サーバーにインストールされます。

注 : 別の IIS ロックダウン セキュリティ テンプレートが必要な場合、または選択した設定のカスタマイズが必要な場合は、MSBP により無効にした追加サービスを再び有効にする必要があるかもしれません。これに含まれるものとしては、SMTP、NNTP、または FTP があります。

ただし、IIS Lockdown Tool を単に実行し、これらのサービスから 1 つを選んだだけでは、次回のグループ ポリシーのリフレッシュ時に IIS グループ ポリシーがサービスを無効にしてしまうため、継続的に有効にしたことにはなりません。このサービスは、手作業により Web OU に導入した IIS グループ ポリシー内で有効にする必要があります。

サービス

脆弱性

動作しているサービスやアプリケーションは潜在的な攻撃対象です。動作していないサービスとコンポーネントを効果的に攻撃することはできません。したがって、セキュリティでしっかりと保護されたシステムを作るには、環境の IIS サーバーの攻撃対象エリアを削減するために、不要な機能を停止するのがベスト プラクティスです。

対応策

IIS Lockdown Tool を使用し、既定でインストールされている SMTP と FTP サービスを無効にします。IIS と一緒に NNTP もインストールされていれば、NNTP を無効にすることをお勧めします。

また、IIS Lockdown Tool は、これらのサービスをアンインストールするために使用できます。

予想される影響

iislockd.ini ファイルの UninstallServices 設定は慎重に検討する必要があります。この設定は、IIS Lockdown Tool Version 2.1 に対応するすべての事前構成テンプレートに対し、FALSE を設定します。iislockd.ini ファイルがこの設定を TRUE にするように修正されていれば、このようなサービスは IIS ロックダウンが適用されるサーバーにはインストールされません。これらのサービスを 1 つでもサーバーで再度有効にするには、プログラムの追加と削除を使い、手作業でインストールするか、またはサーバー導入手順に従い、サーバーを再構築する必要があります。

Contoso 社のシナリオ

この IIS Lockdown Tool は、組織の IIS サーバーの NNTP、FTP、および SMTP サービスを無効にするのみで、アンインストールはしない形で使用されました。

カスタム IISLockd.ini ファイルを使用し、IIS サーバーから NNTP、FTP、および SMTP サービスをアンインストールする方法

  1. WinZip のような解凍ユーティリティを使って IISLockd.exe ファイルを開き、すべてのファイルをハードディスクに取り出します。

  2. Notepad.exe で iislockd.ini を開きます。

  3. 設定する役割に対応する場所 (たとえば、動的 Web サーバー の役割に対する dynamicweb) を探し、その場所にある UninstallServices 設定を TRUE の値に変更します。

  4. Info で、使用するサーバー テンプレートに適合する名前を入力し、UnattendedServerType 設定を構成します。たとえば、動的 Web テンプレートを適用したいのであれば、UnattendedServerType を dynamicweb に等しくします。

  5. [無人] 設定を TRUE の値に変更します。

  6. iislockd.ini ファイルを保存します。

  7. iislockd.exe をコマンド ラインまたはスクリプト内から実行します。

スクリプト マッピングの無効化

脆弱性

IIS 関連のスクリプト マッピングは、機能性向上がセキュリティ低下を引き起こす原理を非常に良く示している例です。スクリプト マッピングは、Web サイトに多大な価値を与えてくれる非常に強力な仕掛けですが、ほとんどのマッピングは、Windows 2000 の提供開始後のある時点から、セキュリティの脅威にさらされ続けてきました。

  • .ida と .idq のスクリプト マッピングは、インデックス サーバーに拡張機能を提供する ISAPI 拡張です。数ある脆弱性の中でも、idq.dll ファイルのバッファをチェックしないことにより、攻撃者がサーバーのコントロールを完全に奪える弱点を含んでいます。この脆弱性が、Code Red ワームで利用されたのは非常に有名な話です。詳細については、マイクロソフト セキュリティ情報 MS01-033 を参照してください。

  • .htw ISAPI フィルタは、マイクロソフト インデックス サーバーに追加機能を提供します。関連する webhits.dll ファイルの脆弱性は、ブラウザや HTML 準拠の電子メール クライアントを通じ、攻撃的なリンクを開く可能性を作り出しました。これにより、Javascript などのアクティブ コンテンツの実行が引き起こされます。詳細については、マイクロソフト セキュリティ情報 MS01-025 を参照してください。

  • .shtml マッピングは Smart HTML インタープリタであり、サーバー サイド インクルードをサポートするために使用する Microsoftｮ FrontPageｮ Server Extensions の一部です。ssiinc.dll ファイルには、Web サーバー上にある攻撃者指定のコンテンツをブラウザに返すために利用される脆弱性が含まれていました。詳細についてはマイクロソフト セキュリティ情報 MS00-060 を参照してください。

  • .idc マッピングではエラー ページの URL 全体を返すという、クロス サイト間のスクリプティング脆弱性を利用される可能性があり、攻撃者はサーバーで任意のスクリプト コードを実行できます。この問題は Windows 2000 SP3 で解決されました。

  • .htr ISAPI 拡張は、ASP 開発向けに用意された第一世代のスクリプティング技術でしたが、広く採用されることはありませんでした。ファイルの脆弱性は、ASP ファイルのソース コードを公開するために利用可能でした。詳細については、マイクロソフト セキュリティ情報 MS00-031 と MS01-014 を参照してください。

  • プリンタ ISAPI 拡張は、インターネット プロトコルで印刷を利用するために作成されました。msw3prt.dll の脆弱性は、攻撃者にターゲットの IIS システムのリモート コンソールを提供するために利用可能でした。詳細については、マイクロソフト セキュリティ情報 MS01-023 を参照してください。

対応策

すべての不必要なマッピングと ISAPI フィルタ は、システムから削除することをお勧めします。

不必要なスクリプト マッピングは、404.dll ファイルにリダイレクトすることをお勧めします。404.dll ファイルは ISAPI フィルタで、このような未使用スクリプト マッピングの 1 つとして阻止した要求に対して、単純な 404 のエラー ページで応答します。

注 : 未使用の拡張を 404.dll にマッピングするのは、マッピングを単に削除するよりも優れています。マッピングを削除しても、ファイルが誤ってサーバーに残った (または誤って置かれた) 場合に要求されると、クリアテキストで表示されるか、不注意によって再マッピングされる可能性があります。

各スクリプト マッピングの関連ファイルやフォルダも、ファイル システムから削除することをお勧めします。これは IIS Lockdown Tool では行われませんが、以下の「仮想ディレクトリとサンプル アプリケーションの削除」セクションで説明しています。

予想される影響

スクリプトの再マッピングで考えられる影響としては、対象のスクリプト マッピングによって利用可能な機能が無効になることです。Web ベースのアプリケーションが機能するためにスクリプト マッピングが必要な場合に、このようなアプリケーションが誤って無効にされる可能性があります。

Contoso 社のシナリオ

IIS Lockdown Tool は、Contoso 社シナリオで使用され、すべての不要な ISAPI フィルタが組織の IIS サーバーから削除されました。.asp ファイルと静的コンテンツのみが、IIS サーバー上で有効のまま残っています。各スクリプト マッピングは、自動的に 404.dll フィルタにマッピングされました。

404.dll へのスクリプト マッピングは、新しい拡張を使う場合、または IIS Lockdown Tool が使用されていない場合に、手作業でも行うことができます。

拡張を 404.dll に手作業でマッピングする方法

  1. [Internet Services Manager MMC snap-in] を開始します。

  2. 左側のウィンドウで、サーバー (別名マスター サイト) を右クリックし、[プロパティ] をクリックします。

  3. [Master Properties] のドロップ ダウン リスト ボックスで、[WWWService] が選択されていることを確認し、隣にある [編集] ボタンをクリックします。

  4. [ホーム ディレクトリ] タブをクリックします。

  5. [構成] をクリックします。

  6. マッピングのリストから拡張を 1 つ選択し、[編集] をクリックします。

  7. [参照] をクリックし、c:\winnt\system32\inetsrv\404.dll へ移動します。

  8. [開く] をクリックし、次に [OK] をクリックします。

  9. 残りのファイル拡張のすべてに対して、ステップ 6、7、および 8 を繰り返します。

インターネット印刷

Windows 2000 Server では、インターネットから印刷する機能を提供します。プリンタは Web ページでサーバーに接続され、プリンタの管理機能へも Web ページからアクセスします。

脆弱性

インターネット印刷機能は、IIS サーバーの攻撃対象エリアを増大させます。さらに、インターネット印刷が Internet Service Manager から無効にされ、管理者がサーバーを再起動するかログアウトすると、インターネット印刷を有効にする GPO はこの機能を再起動します。

サーバーを導入する前にサーバーをコントロールする GPO を通じ、インターネット印刷を無効にできることを確認することが重要です。既定のグループ ポリシーでは、インターネット印刷を有効にも無効にもしません。

対応策

Contoso 社シナリオ用の手順を使用するグループ ポリシーを使って、[インターネット印刷] を無効にします。

また、インターネット印刷は Internet Services Manager 経由でも無効にできます。グループ ポリシー設定と Internet Services Manager による設定との間に矛盾がある場合には、グループ ポリシー設定が優先します。

インターネット印刷が Internet Services Manager 経由で削除される場合には、ローカル グループ ポリシーまたはドメイン グループ ポリシーのいずれかで再度有効にできるようなことがないことを検証します。この方法の詳細については、Contoso 社シナリオの手順を参照してください。

予想される影響

IPP (Internet Printing Protocol) 経由で IIS サーバーから共有するプリンタに印刷しているクライアントは、IPP を使って Web 共有プリンタから印刷することができなくなります。

Contoso 社のシナリオ

IIS Lockdown Tool を使い、Contoso 社環境でインターネット印刷を無効としました。IIS サーバーから共有しているプリンタはありません。

グループ ポリシーを使い、インターネット印刷を無効にする方法

  1. IPP を無効とする GPO を編集する許可を持つユーザーとして [Active Directory ユーザーとコンピュータ] を開始します。

  2. GPO が格納されている OU を右クリックし、[プロパティ] をクリックします。

  3. [グループ ポリシー] タブをクリックし、編集する GPO をクリックし、次に [編集] ボタンをクリックします。

  4. [コンピュータ構成] フォルダ、次に [管理用テンプレート] をダブルクリックし、[プリンタ] をダブルクリックします。

  5. [Web-based Printing] 設定をダブルクリックし、[無効] ラジオ ボタンを選択し、[OK] をクリックします。

仮想ディレクトリとサンプル アプリケーションの削除

脆弱性

IIS 5.0 には、既定ではインストールされないサンプル アプリケーションがいくつかありますが、IIS のフル インストールの一部として利用できます。さらに、サンプル IIS アプリケーションを含む IIS 5.0 にはいくつかの仮想ディレクトリが含まれています。

IIS 5.0 の既定のインストールに含まれていたサンプル アプリケーションは、高度にセキュリティ保護されて運用されている IIS サーバーでホスティングするものとして開発されていません。サンプル アプリケーションまたは構成に内在している弱点をハッカーが利用して Web サイトを攻撃するすることは可能です。サンプル アプリケーションを削除すると、Web サーバーの攻撃対象エリアを小さくすることが可能です。

さらに、仮想ディレクトリ自体が高度なセキュリティ保護を目指して構成されていません。たとえば、既定の \Scripts ディレクトリは、このディレクトリおよび潜在的に他のディレクトリでプログラムを実行する機能を誰にでも提供します。

対応策

仮想ディレクトリは、手作業または IIS Lockdown Tool を使用して削除することをお勧めします。仮想ディレクトリの配下にあるファイルとフォルダについても、手作業で削除することをお勧めします。

サンプル アプリケーションの削除方法

  1. [MMC の IIS スナップイン] を使用し、適切な仮想ディレクトリを削除します。

  2. [エクスプローラ] を使用し、配下のフォルダを物理的に削除します。

リモート IIS 管理アプリケーションを削除する方法

  1. [MMC の IIS スナップイン] を使用し、管理用 Web サイトを停止します。

  2. [スナップイン] を使用し、仮想ディレクトリを削除します。

  3. [エクスプローラ] を使用し、配下のフォルダを物理的に削除します。

予想される影響

思いもよらないような理由で、サンプル アプリケーションの 1 つを運用環境に採用していない限りは、特に影響はありません。

Contoso 社のシナリオ

Contoso 社シナリオで IIS Lockdown Tool を使用し、すべての仮想ディレクトリ サンプルを削除しました。

サンプル アプリケーションとその他の不要なファイルは手作業で削除しました。次のディレクトリを削除しました。

  • C:\inetpub\scripts

  • C:\inetpub\iissamples

  • C:\Program Files\Common files\system\msadc

  • C:\winnt\help\iishelp

  • C:\Winnt\system32\inetsrv\iisadmin

IIS ユーザーのファイルアクセス許可のロックダウン

脆弱性

システムに認証されていないアクセスが得られると、ハッカーはシステム コマンドを使用し、リモート Web サーバーでアクションの実行やデータの表示を行えるようになります。同じシステム コマンドを使って、攻撃者はサーバーにアプリケーションを追加してアップロード、実行することもできます。

対応策

次の 2 つの対応策を実施します。

  • C:\WINNT とすべてのサブフォルダにあるすべての実行可能ファイルに ACE (Access Control Entry) を追加します (つまり既存の ACL に ACE を追加します)。この ACE は、(IUSR_computername を含めて) コンピュータに設定されたすべての匿名ユーザー アカウントだけでなく、(IWAM_computername を含めて) Web アプリケーションの実行に使用する全ユーザー アカウントでサーバー上に定義されているものに対して、実行特権を拒否します。

  • ACE を仮想ディレクトリで参照されるすべてのファイルとフォルダの既存 ACL に追加し、リモート コンピュータに存在するファイルとフォルダを含めます。この ACE は、(IUSR_computername を含めて) コンピュータに設定されたすべての匿名ユーザー アカウントだけでなく、(IWAM_computername を含めて) Web アプリケーションの実行に使用する全ユーザー アカウントでサーバー上に定義されているものに対して、書き込み特権を拒否します。

これらのアクションは両方とも、IIS Lockdown Tool で自動的に実施可能です。

予想される影響

マイクロソフトの Web アプリケーションには、上記対応策で影響を受けるものはありませんが、拒否されたアクセス許可に依存するカスタム アプリケーションが影響を受ける可能性はあります。同じ変更を行ったラボ環境ですべてのカスタム アプリケーションをテストをしてから、運用 IIS サーバーに同じ変更を適用します。

Contoso 社のシナリオ

Contoso 社シナリオで IIS Lockdown Tool を使用し、必要な ACE 拒否設定を特定のファイルとディレクトリに設定しました。

WebDAVの無効化

脆弱性

WebDAV スレッドの現在のセキュリティ コンテキストで、スクリプトを実行されてしまうところに WebDAV の脆弱性があります。これは、攻撃者が組織のイントラネット内を表示し、本来なら WebDAV サービス アカウントのみが利用できる制限付き情報にアクセスできる可能性があることを意味しています。詳細については、マイクロソフト セキュリティ情報 MS01-022 を参照してください。

対応策

WebDAV 機能を無効にします。WebDAV 機能 (Httpext.Dll) を実装する DLL に ACE を設定し、この DLL が IIS プロセスにローディングされることを防止します。IIS Lockdown Tool はこの作業を自動的に実行できます。

Exchange 2000 と Microsoftｮ SharePoint・Portal Server 2001 のようなアプリケーションでは、製品内の機能で WebDAV を必要とします。このようなケースでは、最新のサービス パックを適用し、WebDAV 機能のパッチが完全に適用されていることを確認するのがベストです。

予想される影響

WebDAV に依存しているアプリケーションは、このアクションによって無効化されます。このような変更を作成後、WebDAV 機能を含むと思われるすべての Web アプリケーションをラボ環境でテストしてから、環境内の運用 IIS サーバーに変更を適用します。

Contoso 社のシナリオ

Contoso 社シナリオでは WebDAV アプリケーションを導入していなかったので、IIS Lockdown Tool を使用し、全サーバーから WebDAV 機能を削除しました。

URLScan

URLScan は ISAPI フィルタであり、IIS Lockdown Tool を実行した際にインストールされるか、または IIS Lockdown Tool からファイルを抽出し、単独でインストールできます。URLScan を使用すると、Web サイト管理者はサーバーが処理する HTTP 要求の種類を制限できます。特定の HTTP 要求をブロックするので、URLScan フィルタを使えば潜在的に危険な要求がサーバーに到達し、被害をもたらすことを防止できます。

概要

URLScan は普通ではない HTTP 要求や、潜在的に悪意が感じられる HTTP 要求など、さまざまな種類の HTTP 要求をブロックします。特に過去に脆弱性を利用された例では、ディレクトリ走査攻撃で使用された ".." のような文字を含む要求をブロックします。このような要求は、%systemroot%\system32\inetsrv\urlscan ディレクトリにロギングされます。

正当な Web アプリケーション URL のパス内にこのような文字が含まれていたとしても、URLScan は要求を拒否し、クライアントに 404 Not Found エラー応答を返します。Web アプリケーションのサポートに、このような文字を通す必要がある場合は、%systemroot%\system32\inetsrv\urlscan\ フォルダにある urlscan.ini の設定ファイル内の AllowDotInPath パラメータに 1 の値を設定します。URLScan が許可している既定の文字セットを変更すると、システム セキュリティの低下に繋がると認識することは重要です。

URLScan 設定

URLScan の大部分は、%systemroot%\system32\inetsrv\urlscan ディレクトリに存在する URLScan.ini ファイルを操作することによって設定できます。このファイルには、以下に示すパラメータ セクションがあります。

Options

urlscan.ini ファイルの Options セクションには、URLScan が使用する 16 種類の設定が含まれます。このような設定では urlscan.ini ファイル内のサブ設定で使用する設定を参照する場合があります。これらの設定には次のものがあります。

  • UseAllowVerbs

  • UseAllowExtensions

  • NormalizeUrlBeforeScan

  • VerifyNormalization

  • AllowHighBitCharacters

  • AllowDotInPath

  • RemoveServerHeader

  • AlternateServerName

  • EnableLogging

  • PerProcessLogging

  • PerDayLogging

  • LogLongUrls

  • LoggingDirectory

  • AllowLateScanning

  • RejectResponseUrl

  • UseFastPathReject.

これらの設定のほとんどは、1 (真) または 0 (偽) で設定します。詳細設定が必要なものについては以下で説明します。詳細については、マイクロソフト サポート技術情報 326444 「[HOW TO] Configure the URLScan Tool」を参照してください。

Allow Verbs と Deny Verbs

Verbs は、HTTP 要求の重要なコンポーネントです。GET と HEAD は Web ブラウザが単純な参照時に最も普通に使用する動詞です。たとえば、指定 URL から情報を得るには GET コマンドを使用します。

ブラウザでは、Web サイトのコンテンツ修正に、PUT、POST、および REPLY のような他の動詞も使えます。たとえば、FrontPage Server Extensions では、POST と OPTIONS の動詞を使い、Web コンテンツを公開します。

オプション セクションの UseAllowVerbs 設定は、.ini ファイルの Allow Verbs セクションを処理するかどうかを決定します。UseAllowVerbs の値が 1 に設定されていれば、URLScan は .ini ファイルの AllowVerbs セクションのみを調べ、DenyVerbs 部分を無視します。

UseAllowVerbs の値が 0 に設定されていれば、URLScan は DenyVerbs セクションを見て、AllowVerbs にあるエントリは無視します。IIS のセキュリティが最大限に保護されるのは、すべての HTTP 内動詞が拒否され、特定の例外だけがリストされている、URLScan の既定状態 (UseAllowVerbs = 1) です。

この機能は、Web サイトでユーザーに実行許可を与える作業を制限する際に便利です。

Allow Extensions と Deny Extensions

URLScan.ini ファイルの AllowExtensions と DenyExtensions の部分は、AllowVerbs や DenyVerbs 部分と同じような動きをします。ただし、urlscan.ini ファイルのこの部分は、入力要求でアクセス可能な特定のファイル拡張をコントロールします。

この設定を使うことにより、管理者は通常の Web ファイル種類へのアクセスは有効にできますが、実行可能ファイルやスクリプト ファイルをユーザーが実行する機能を拒否できます。

最もセキュリティ保護される設定は、UseAllowExtensions を 1 に設定し、AllowExtensions セクションで許可されている拡張をリストで示す設定です。この設定では、すべての他の拡張をブロックします。既定の設定は UseAllowExtensions = 0 であり、特定種類の拡張のみを拒否します。

ヘッダーの拒否

ファイルの DenyHeaders 部分を使用すれば、URLScan がどのクライアントの要求ヘッダーを許可するか拒否するかを指定できます。たとえば、このセクションでは、パッチが適用されていない IIS 5.0 のあるバージョンで特定の脆弱性を利用できる Translate: ヘッダーを拒否できます。

URLScan の実装

脆弱性

URLScan では脆弱性のリストを処理しますが、項目が多すぎるため、ここでは詳細を議論しません。ただし、対処する中でも最も一般的な脆弱性と考えられるものの 1 つが、IIS ファイル システム走査です。Contoso 社シナリオでは、同社の環境で最も重大なリスクの 1 つとして認識されました。

ファイル システム走査を行うと、攻撃者は IIS サーバーのファイル システムのレイアウトを表示できるだけでなく、ファイル内のデータを表示させることも、サーバーへの未承認アクセスを行うこともできます。これはさらに、攻撃者がコンピュータのコマンドを遠隔地から実行できる機能を得ることにもつながります。

対応策

この脆弱性に対する第 1 の対応策は、仮想サーバー ルートを含むディレクトリをシステム ドライブ以外のドライブに移動させることです。現時点では、ハッカーがシステム パーティションを超えてコマンドを実行する方法はありません。システム コマンドを実行できる手段がないドライブに Web アプリケーション データを移すことで、攻撃者がこのようなアクションを実行することを制限できます。

または、要求 URL に許されている特殊文字を制限するように URLScan を実装できます。URLScan には URL の処理前に URL の正規化を規定する機能があります。これにより、最も一般的なファイル システム走査の仕掛けを多数取り除くことができます。

予想される影響

データ ファイルをシステム以外のドライブにインストールしても、現時点ではマイクロソフト アプリケーションには影響がありません。ただし、カスタム アプリケーションの場合は、既定ではない場所にファイルがインストールされると、予期しない問題に遭遇する場合があります。アプリケーションのインストール後にアプリケーション ファイルを移動させると、たいていのアプリケーションでは何らかの再構成作業が必要になります。

このような変更を行う場合は、ラボ環境ですべてのアプリケーションを完全にテストしてから、運用 IIS サーバーに適用することをお勧めします。

Contoso 社のシナリオ

Contoso 社シナリオでは、inetpub ディレクトリとすべての仮想ディレクトリを、システム パーティション以外のディスク パーティションにインストールしました。

Contoso 社では URLScan も実装し、システムで実行を許される URL と実行可能プログラムを制限しました。

IIS の増分グループ ポリシー

第 6 章「Base Windows 2000 Server のハードニング」で議論したベースライン セキュリティ ポリシーにより、サーバーのセキュリティは既定のインストール直後に比べて大きく強化されていることが保証されます。ただし、他のサーバー の役割と同じで、コンピュータの他のセキュリティ面を強化させつつ、サーバー の役割にある種の機能性を加えるには、さらに設定を追加する必要があります。

システム サービス

IIS サーバー ロールは、ベースライン Windows 2000 サーバー ポリシーに Web サーバー機能を追加します。IIS サーバー上で他のいかなるサービスがホスティングされていても、Web サーバー機能をサポートするには次の 2 つのサービスを有効にする必要があります。IISAdmin サービスは、IIS Web サイトを管理するためだけでなく、このサービスが実際に IIS サーバーの Web 関連トラフィックの最初の接点であることから必要になります。したがって、このサービスを無効にすると、環境内のすべての Web サイト、FTP、SMTP、および NNTP を無効にしてしまいます。

このようなサービスは増分 IIS ポリシーで有効としました。

表 7.10 増分 IIS ポリシー サービス設定

サービス設定 スタートアップの種類 ポリシー正当化
IISAdmin 自動 Web サーバー管理
W3SVC 自動 Web サーバー機能の提供

手動セキュリティ設定

増分 IIS ポリシーに加えて、手作業で実装すべき改善ステップがいくつかあります。これには次のものがあります。

  • Web コンテンツ ディレクトリの再配置

  • ログ ファイルの再配置とセキュリティ保護

  • メタベース許可の強化

  • HTTP 応答でのコンテンツ場所の無効化

  • 詳細 ASP エラー メッセージの無効化

  • FrontPage 2000 Server Extensions の削除

  • 追加仮想サーバーの削除

  • IPSec フィルタの設定

Web コンテンツ ディレクトリの再配置

脆弱性

既定インストール直後の IIS には、ディレクトリ走査に対する弱点がありました。攻撃者が Web のルート フォルダから外に出て、Web フォルダの外側にファイルをアップロードする場合に、ディレクトリ走査が発生します。IIS アプリケーションはディレクトリ走査に脆弱で、既定の IIS インストールを利用すると、攻撃者は多くの便利なシステム コマンドや書き込み可能フォルダを含め、システム パーティションにあるフォルダやファイルにアクセスできるようになります。

既知の HTTP 構文では、システム パーティションを超えてファイルを要求する方法はありません。

対応策

ディレクトリ走査攻撃を防ぐには、\inetpub ディレクトリを再配置し、すべての仮想ディレクトリを、システム パーティション以外のドライブ パーティションに再配置します。

このステップは、誰も予想もしていない正規化問題の存在を攻撃者が見抜いて活用したとしても、攻撃者が cmd.exe のような基本システム コマンドにはアクセスできないことを保証し、攻撃者がたとえば \inetpub\Scripts フォルダのようなシステム パーティション上の書き込み可能フォルダに書き込もうとしても書き込めないことを保証するものです。

予想される影響

最小限。Web サーバー管理者は、IIS の構成を記録し、仮想サイトが新しい場所で再登録されることを保証する必要があります。

Contoso 社のシナリオ

Contoso 社の Research Web サイトがこの典型的な例として使用されました。この Web サイトの仮想ルートは、Research Web サーバーの C:\Inetpub\wwwroot\research でした。このファイルを E: のようなシステム外パーティションに移動させるため、次のステップを実施しました。

Research Web サイトのすべてのコンテンツ ディレクトリを移動する方法

  1. [MMC の IIS スナップイン] を開始します。

  2. [Web サイト] を右クリックし、[停止] を選択します (これによりロックされたファイルをすべて解除します)。

  3. コマンド プロンプトを開始します。

  4. 次のコマンドを入力します: xcopy c:\inetpub\wwwroot\research d:\wwwroot\research /s /i /o

  5. [MMC の IIS スナップイン] に戻ります。

  6. [Web サイト] を右クリックし、[プロパティ] を選択します。

  7. [ホーム ディレクトリ] タブをクリックし、[参照] ボタンをクリックし、ファイルをコピーする新ディレクトリを選択します (たとえば、d:\wwwroot\research)。

  8. [Web サイト] を右クリックし、[スタート] を選択します。

ログ ファイルの再配置とセキュリティ保護

脆弱性

IIS ログ ファイルを移動し、セキュリティ保護すれば、攻撃者がログを削除したり、ログの個別エントリを削除して足跡を消すことはさらに困難となります。

対応策

IIS ログ ファイル ディレクトリを Web サイト データ ファイルやシステム パーティションとは別のディスク パーティションに再配置します。次にログ ファイルのセキュリティ保護を高めるために、強固な NTFS アクセス許可を設定します。最後に、推奨しているロギング フィールドが設定されていることを確認します。

ログ ファイルの追加オプション

  • IIS ログ ファイルのオフライン分析を便利にするため、セキュリティ保護を行いながら各 IIS サーバーからログ ファイルを自動削除するスクリプトを利用できます。ログ ファイルは最低でも 24 時間ごとに削除し、中央サーバーに集めることをお勧めします。

  • コンピュータからログ ファイルを転送する際に利用する FTP、SMTP、HTTP、または SMB プロトコルを使用するため、自動化スクリプトを作成しますが、この作業はセキュリティによる保護を行いながら実施し、別の攻撃機会を作ることを防止する必要があります。IPSec ポリシーを使って、プロトコルで利用するポートと許可ホストのセキュリティ保護を行います。

  • IIS ログ ファイルは、同一メディアに何度も書き込める最新の CD-RW ドライブを使い、CD-R に蓄積可能です。これにより、書き込まれると削除できない記憶域に IIS エントリをロギングすることができます。このようにすれば、攻撃者は自分の足跡を消すことはできません。

  • IIS ログ ファイルは中央にある UNC (Universal Naming Convention) 共有にも格納可能です (たとえば、ログ ディレクトリは \\server\share\iislogs rather than %Windir%\system32\logfiles にすることができます)。こうすることで、1 か所の中央レポジトリから毎日ログ ファイルをバックアップすることができます。

  • 最後に、IIS ログ エントリは ODBC (Open Database Connectivity) に準拠するデータベースに蓄積可能です。これにより、IIS ログ エントリを中央の場所に蓄積することが可能となり、よりきめ細かいアクセス許可を有効にすることができます (たとえば、読み出し/書き込みはできても削除することはできなくするなど)。このログ エントリは既に分析に理想的なフォーマットで格納されています。

予想される影響

なし。

Contoso 社のシナリオ

Contoso 社の Web サーバー上の IIS ログ ファイルは、セキュリティで保護され、拡張ロギングが可能なシステム外パーティションに移動しました。

IIS ログ ファイルの場所をシステム外パーティションに移動する方法

  1. [MMC の IIS スナップイン] を開始します。

  2. [Web サイト] を右クリックし、[プロパティ] を選択します。

  3. [Web サイト] タブの [ログの記録を有効にする] フレームの [プロパティ] ボタンをクリックします。

  4. [全般プロパティ] タブで、[参照] ボタンをクリックし、IIS ログ ファイルを蓄積したい場所 (たとえば、E:\IISLogs) の [ドライブ] と [フォルダ] を選択します。

    注 : ステップの一部で選択操作を行うには、あらかじめフォルダを作成しておく必要があります。

  5. [OK] をクリックし、次に再び [OK] をクリックします。

    注 : 既に元の場所 (%Windir%\System32\logfiles) に IIS ログ ファイルがある場合は、これらのファイルを手作業で新しい場所に移す必要があります。IIS が、自動的にファイルを移行することはありません。

IIS ログ ファイルの場所 (たとえば、E:\IISLogs) へのアクセス許可の推奨を設定する方法

  1. コマンド プロンプトを開きます。

  2. 次のコマンドを入力します: cacls e:\iislogs /t /g administrators:F system:F everyone:R

  3. プロンプトで Y と入力します。

IIS W3C 拡張ログ ファイル フォーマット (監査用) を設定する方法

  1. [MMC の IIS マネージャ スナップイン] を開始します。

  2. 左側のウィンドウで、サーバーを右クリックし、[プロパティ] をクリックします。

  3. [Master Properties] のドロップ ダウン リスト ボックスで、[WWWService] が選択されていることを確認し、隣にある [編集] ボタンをクリックします。

  4. [ログの記録を有効にする] を選択し、[Active log format] のドロップダウン リストボックスが [W3C 拡張ログ ファイル フォーマット] に設定されていることを確認します。

  5. [プロパティ] をクリックします。

  6. [When file size reaches] のラジオ ボタンを選択し、[500 MB] のログ ファイル サイズを指定します。

  7. 既定の [ログ ファイル ディレクトリ] を変更します。現在の Web サイトとは異なるシステム外パーティションを使用することを推奨します。

  8. [拡張プロパティ] タブをクリックします。

  9. IIS が選択した既定フィールドに加えて、[Win32 status entry] も選択します。

  10. [OK] を 3 回クリックし、[properties dialog list boxes] を閉じます。

注 : このような監査ではシステム攻撃を防止できませんが、侵入者、進行中の攻撃を識別し、攻撃の足跡を診断する上で重要な手がかりとなります。

メタベース許可の強化

脆弱性

セキュリティとその他の IIS 構成設定は、IIS メタベース ファイル内に保持されています。既定のファイル アクセス許可では、攻撃者がメタベース ファイルを直接に編集可能です。IIS メタベース ファイル (およびバックアップ メタベース ファイル) への NTFS アクセス許可は、攻撃者が IIS 構成を修正できないように強化することをお勧めします。たとえば、攻撃者はメタベース設定を適切に修正することにより、特定の仮想ディレクトリへの認証を無効にしようと試みる可能性があります。

対応策

フル コントロールのアクセス許可は、Administrators および SYSTEM のみに許可されるように設定し、メタベース ファイルをセキュリティ保護します。

予想される影響

唯一の考えられる影響は、メタベース ファイルに制約の強いアクセス許可を設定することであり、これが強すぎるとシステムまたは管理者がファイルを読み取り、更新できなくなります。

Contoso 社のシナリオ

メタベース ファイルのセキュリティ保護を強化するために IIS の増分ポリシーが適用され、このメタベース ファイル中にメタベース ファイルへのアクセス許可が格納されました。

メタベースの NTFS アクセス許可を手作業で強化する方法

  1. コマンド プロンプトを開きます。

  2. 次のコマンドを入力します: cacls %systemroot%\system32\inetsrv\metabase.bin /g administrators:F system:F

  3. プロンプトで Y と入力します。

  4. 次のコマンドを入力します: cacls %systemroot%\system32\inetsrv\metaback /g administrators:F system:F

  5. プロンプトで Y と入力します。

このような設定は、このガイドの MSS IIS Role.inf ポリシー テンプレートに含まれています。

HTTP 応答でのコンテンツ場所の無効化

脆弱性

ASP ページではない静的な HTML ページが取得されると、IIS が応答にコンテンツ場所ヘッダーを付加します。既定により、このコンテンツ ヘッダーは IP アドレスを参照し、現在の Web サイトの完全修飾ドメイン名 (FQDN) を参照しません。これは内部の IP アドレスが無意識にさらされている脆弱性を作り出しています。

対応策

HTTP 応答ヘッダーに既定で返されてくるコンテンツ場所を隠します。IP アドレスを露出する既定動作を FQDN 送信に変更するには、IIS メタベース内の UseHostName の値を変更します。

予想される影響

なし。

Contoso 社のシナリオ

Contoso 社シナリオでは、Adsutil.vbs スクリプトを使用し、UseHostName 設定の値を真に再設定しました。このステップを実行するシンタックスは次のとおりです。

cscript Adsutil.vbs set w3svc/UseHostName True

ADSUtil.vbs スクリプトは、IIS サーバーの IIS Adminscripts ディレクトリにあります。このディレクトリは既定では、C:\Inetpub\Adminscripts です。

注 : このステップに必要な手作業プロセスの詳細については、マイクロソフト サポート技術情報記事 218180 「IIS が HTTP ヘッダー (Content-Location) で IP アドレスを返す」を参照してください。

詳細 ASP エラー メッセージの無効化

脆弱性

既定により、IIS は、内部アプリケーション エラーがある場合には常に、クライアント ブラウザに詳細な ASP エラー メッセージを送信します。これはアプリケーションのデバッグには非常に有効ですが、アプリケーションの動作方法の内部詳細を公開するので、攻撃者がアプリケーションの攻撃方法を良く理解できるようになります。

対応策

環境内の運用 IIS サーバーの詳細 ASP エラー メッセージを無効にします。

予想される影響

IIS がアプリケーション イベント ログにロギングするエラーが、詳細な ASP エラー メッセージほどには豊富な情報ではなく、アプリケーション問題への対応がより困難になります。再現可能な ASP エラーに直面している場合には、取るべき方法が 2 つあります。修正をテストするためにミラー開発環境を設定し (環境で詳細な ASP エラー メッセージを取得する構成とします)、または問題を解決するまでの間、一時的に運用で詳細な ASP エラー メッセージを有効とします。

Contoso 社のシナリオ

Research と HR の運用 IIS サーバーでは、以下に詳細を示す adsutil.vbs スクリプト パラメータを使用し、詳細 ASP エラー メッセージを無効にする設定としました。

詳細 ASP エラー メッセージを無効にする方法

  1. [Internet Services Manager MMC snap-in] を開始します。

  2. 左側のウィンドウで、サーバー (別名マスター サイト) を右クリックし、[プロパティ] をクリックします。

  3. [Master Properties] のドロップ ダウン リスト ボックスで、[WWWService] が選択されていることを確認し、次に隣にある [編集] ボタンをクリックします。

  4. [ホーム ディレクトリ] タブをクリックします。

  5. [構成] をクリックします。

  6. リストから拡張を 1 つ選択し、[編集] をクリックします。

  7. [参照] をクリックし、c:\winnt\system32\inetsrv\404.dll へ移動します。

  8. [開く] をクリックし、次に [OK] をクリックします。

  9. 残りのファイル拡張のすべてに対して、ステップ 6**、**7、および 8 を繰り返します。

または、このプロセスで Adsutil.vbs スクリプトを使用します。このステップを実行するシンタックスは次のとおりです。

cscript Adsutil.vbs set w3svc/AspScriptErrorSentToBrowser False

FrontPage 2000 Server Extensions の削除

脆弱性

FrontPage 2000 Server Extensions は、Office ユーザー チーム間での共同作業、および Web ページ コンテンツを遠隔地から操作する便利な方法を提供します。このようなリモート管理機能は、管理者が 1 人しかいない Web サイトでは一般的に必要がなく、この拡張機能は技術力の高い攻撃者による Web サイトの攻撃場所として利用可能です。

対応策

FrontPage 2000 Server Extensions をすべての運用 IIS サーバーで無効化。

予想される影響

仮想 Web サイトの管理を非管理者のスタッフに委任する必要がある場合に、FrontPage 2000 Server Extensions が必要になることがあります。この場合は、IIS Web サーバーに現時点で最新の FrontPage 2000 Server Extensions の全修正プログラムが導入していることを確認します。

Contoso 社のシナリオ

Contoso 社環境では、IIS Web サイトはすべて、少数の IT スタッフ チームで管理されていました。このチームは、MMC の Internet Services Manager スナップインをコンソールからでも、ターミナル サービス経由でも、またはネットワーク経由でも使いこなせました。したがって、すべての運用 IIS サーバー上の FrontPage 2000 Server Extensions は、手作業で無効にしました。

FrontPage 2000 Server Extensions を手作業で削除する方法

  1. [プログラムの追加と削除] のアプレットを開始し、[Windows コンポーネントの追加と削除] を選択します。

  2. [インターネット インフォメーション サービス (IIS)] を選択し、[詳細] ボタンをクリックします。

  3. [FrontPage 2000 Server Extensions] チェック ボックスをオフにし、[OK] をクリックし、次に [次へ] をクリックします。

  4. ターミナル サービス セットアップのダイアログ ボックスが表示されたら、[次へ] をクリックします。

    • または -
    1. [ファイルが必要] ダイアログ ボックスが表示された場合は、Windows 2000 をインストールした場所に [参照] を使って移動し、[OK] をクリックします。

  5. プロンプトで [完了] をクリックします。

  6. 必要に応じて、次のディレクトリを含め、FrontPage サーバーのディレクトリを削除します。

    • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40

    • C:\Inetpub\wwwroot\_private

    • C:\Inetpub\wwwroot\_vti_cnf

    • C:\Inetpub\wwwroot\_vti_log

    • C:\Inetpub\wwwroot\_vti_pvt

    • C:\Inetpub\wwwroot\_vti_script

追加仮想サーバーの削除

脆弱性

IIS の既定のインストールでは、既定の FTP サイト、既定の Web サイト、および管理用 Web サイトを作成します。このようなサイトにはたいていサンプル コードが含まれていて、このようなサービスのセキュリティ保護がなされていないインスタンスを必要とするリモート攻撃にとって潜在的なサイトにもなります。運用環境に必要ないものであれば、このような既定サイトは削除するか無効にするのがベスト プラクティスです。

対応策

既定の FTP サイトと 管理用 Web サイトを削除し、既定の Web サイトによる Web 要求応答を停止します。

予想される影響

既定の Web サイトのいずれかに、Web アプリケーションをインストールしている可能性があります。このようなサイトを削除する前に、このようなアプリケーションを IIS Web サーバー上の新しい Web サイトに移行していることを確認します。何らかの理由でこれらのサイトを削除できない場合には、これらの Web サイトからサンプル コードだけでも削除しておくことをお勧めします。この作業を実行するには IISLockdown Tool を使用します。

Contoso 社のシナリオ

Contoso 社環境では、運用機能をサポートするために既定の Web サイトは必要ありませんでした。すべての運用 Web サイトは、新しい仮想 Web サイトにインストールされています。したがって既定のサイトは削除されるか停止されました。

既定の FTP サイトを手作業で削除する方法

  1. [Internet Services Manager MMC snap-in] を開始します。

  2. [既定 FTP サイト] を右クリックし、[削除] を選択し、[はい] をクリックします。

管理用 Web サイトを手作業で削除する方法

  1. [Internet Services Manager MMC snap-in] を開始します。

  2. [管理 Web サイト] を右クリックし、[削除] を選択し、[はい] をクリックします。

既定の Web サイトを手作業で停止する方法

  1. [Internet Services Manager MMC snap-in] を開始します。

  2. [既定の Web サイト] を右クリックし、[停止] を選択します。

追加 IIS サーバー設定の検討

IUSR アカウントの無効化

既定の IIS インストールの一環で、IUSR_MACHINE と呼ばれる匿名インターネット ユーザーを代表するのに使用する Windows アカウントが作成されます。IIS がインストールされる際には、MACHINE がサーバーの NetBIOS 名です。Web サイトへの匿名アクセスを許可しない場合には、この匿名のユーザー アカウントを無効にすることをお勧めします。

匿名アクセスは、このアカウントだけではなく、他のアカウントでも許可されます。このアカウントは IIS がインストールされる際に作られるものです。逆に、このアカウントを無効にしたり削除しても、IIS は他のアカウントを使って Web ユーザーに匿名アクセスを提供できるように設定できるため、IIS から匿名アクセス機能を削除することにはなりません。

このアカウントは、公開 Web サイトの大多数で使用されていて、コンテンツへの匿名アクセスがサポートされている場合や、またはたとえば Forms 認証を使用してアプリケーション自身が認証を行っている場合などに使用されます。

注 : Web サーバーが複数の Web アプリケーションをホスティングしている場合は、(アプリケーションごとに 1 つで) 複数の匿名アカウントを使ってセキュリティを強化し、各アプリケーションの操作を個々に監査することもあります。

定期的にグループ メンバシップ監査を実行

ユーザー グループ メンバシップ、特に管理者のような特権グループについてはメンバシップを良く把握するようにします。管理者グループのメンバ数は最小限に抑えるようにし、特に新メンバは、管理者グループに追加する前に訓練しておくことをお勧めします。

ユーザーとグループをセキュリティ保護するための追加推奨事項

  • 特定の管理タスクには、特定のグループを作成し、

    • Server Operators のような特権グループの認証メンバをカタログします。

  • グループ メンバシップを定期的に監視します。

  • 厳密な雇用ポリシーと面接を適用してから、管理者グループに追加するようにします。

ASP の親のパス設定を無効化します

この IIS メタベース設定では、MapPath のような機能を呼び出すスクリプトやアプリケーションで ".." (2 個のピリオド) を使用することを防いでいます。これによりディレクトリ走査攻撃の可能性から保護されます。

親のパス設定を手作業で無効にする方法

  1. セキュリティ保護を施す [Web サイト] の [ルート] を右クリックし、[プロパティ] をクリックします。

  2. [ホーム ディレクトリ] タブをクリックします。

  3. [構成] をクリックします。

  4. [App Options] タブをクリックします。

  5. [Enable parent paths] チェック ボックスをオフにします。

注 : Application Center 2002 Admin Site を使用している場合は、マイクロソフト サポート技術情報記事 288309 「[PRB] ユーザー インターフェイスを区切り親パスの無効化」を参照してください。

IPSec フィルタでポートをブロック

脆弱性

以前に述べたように、オープン状態のポート数を削減し、サーバーをアクティブにリッスンすることは、各コンピュータの攻撃対象エリアを大きく削減します。オープン ポートは攻撃者に組織内の他のサーバーを攻撃する踏み台を提供します。たとえば、ワームやトロイの木馬は、サーバーの未承認ポートにバインドするアプリケーションをインストールし、入力コマンドをリッスンします。

対応策

指定するネットワーク トラフィックのみを許可する IPSec ブロッキング フィルタを以下に設定します。これにより、要求を受信したり攻撃対象となる、予想していない未承認アプリケーション数を削減します。

増分 IIS サーバーの IPSec ネットワーク トラフィック マップ

表 7.11 増分 IIS サーバーの IPSec ネットワーク トラフィック マップ

サービス プロトコル ソース ポート 宛先ポート ソース アドレス 宛先アドレス 動作
DNS クライアント TCP 任意 53 ホスト IP 任意 許可
  UDP 任意 53 ホスト IP 任意 許可
SNMP サーバー TCP 任意 161 任意 ホスト IP 許可
  UDP 任意 161 任意 ホスト IP 許可
CIFS クライアント TCP 任意 445 ホスト IP 任意 許可
  UDP 任意 445 ホスト IP 任意 許可
CIFS サーバー TCP 任意 445 任意 ホスト IP 許可
  UDP 任意 445 任意 ホスト IP 許可
RPC クライアント TCP 任意 135 ホスト IP 任意 許可
  UDP 任意 135 ホスト IP 任意 許可
RPC サーバー TCP 任意 135 任意 ホスト IP 許可
  UDP 任意 135 任意 ホスト IP 許可
追加 RPC ポート アウト TCP 任意 57952 ホスト IP 任意 許可
NetBIOS クライアント TCP 任意 137 ホスト IP 任意 許可
  UDP 任意 137 ホスト IP 任意 許可
  TCP 任意 139 ホスト IP 任意 許可
  UDP 任意 138 ホスト IP 任意 許可
NetBIOS サーバー TCP 任意 137 任意 ホスト IP 許可
  UDP 任意 137 任意 ホスト IP 許可
  TCP 任意 139 任意 ホスト IP 許可
  UDP 任意 138 任意 ホスト IP 許可
NTP クライアント TCP 任意 123 ホスト IP 任意 許可
  UDP 任意 123 ホスト IP 任意 許可
監視クライアント 任意 任意 任意 ホスト IP MOM サーバー 許可
LDAP クライアント TCP 任意 389 ホスト IP 任意 許可
  UDP 任意 389 ホスト IP 任意 許可
  TCP 任意 636 ホスト IP 任意 許可
  UDP 任意 636 ホスト IP 任意 許可
Kerberos クライアント TCP 任意 88 ホスト IP 任意 許可
  UDP 任意 88 ホスト IP 任意 許可
ターミナル サービス TCP 任意 3389 任意 ホスト IP 許可
グローバル カタログ クライアント TCP 任意 3268 ホスト IP 任意 許可
  TCP 任意 3269 ホスト IP 任意 許可
HTTP サーバー TCP 任意 80 任意 ホスト IP 許可
HTTPS サーバー TCP 任意 443 任意 ホスト IP 許可
ICMP ICMP 任意 任意 ホスト IP 任意 許可
全受信トラフィック 任意 任意 任意 任意 ホスト IP ブロック

注 : 表 7.11 にリストされているホスト IP 宛先アドレスは、サーバーで構成している IP アドレスに設定します。

ここにあげたすべての規則は、実装時に反映することをお勧めします。これにより、サーバーに着信するどのようなトラフィックも、発信元サーバーに戻ることができます。

上に示すように、ISS サーバーでは多数のポートとサービスが開いています。ISS サーバーで最も厳密なセキュリティを設定すると、追加ポートをブロックできます。ただし、このような追加ポートは、コンピュータを管理しやすくするために開かれたものです。このような機能が追加になっても、ISS 管理とサーバー管理のすべての機能はターミナル サービス経由で実行できます。

また、Contoso 社は自社環境に MOM サーバーを実装しています。MOM サーバーと OnePoint クライアント (MOM コンソールに報告するクライアント アプリケーション) 間の通信は頻繁に行われるため、サーバーと MOM サーバー間ではすべてのネットワーク トラフィックを許可しています。

注 : Windows 2000 Server IPSec フィルタリングは、完全な機能を備えたファイアウォールを置き換えるようには設計されていません。IPSec フィルタリングは、サーバーを強化するツールとして検討することをお勧めします。IPSec を使うことで、静的なフィルタで防げる攻撃に対して防御策を提供できます。さらに、IPSec フィルタリングではワームやウイルスからの悪意のあるコード トラフィックを取り込み、制御することができます。IPSec フィルタリングには、ツールを使う前に理解しておくべき、セキュリティに関する重要な特性がいくつかあります。

  1. セキュリティで妥協すると、攻撃者が Local Administrator または Local System アクセスを握ることになり、IPSec ポリシーを無効にするかまたは変更できるようになります。

  2. ターゲットのコンピュータが適切にロックダウンされていることを保証するには、NoDefaultExempt のレジストリの値を 1 に設定しておく必要があります。この設定は、このセキュリティのガイダンスで使用するすべての IPSec フィルタリング シナリオで必要です。この IPSec ガイダンスでは、シナリオごとに NoDefaultExempt を設定してテストを実施していませんが、この設定の構成の違いで、動きに大きな差は出ません。このガイドはこの構成変更を反映して、できるだけ早く更新していきます。NoDefaultExempt 設定の構成に関する指示については、サポート技術情報記事 254728 「IPSec がドメイン コントローラ間の Kerberos トラフィックをセキュリティで保護されません。」を参照してください。

  3. IPSec では出力方向の接続に多様なフィルタリング機能を提供していません。このため、このセキュリティ ガイダンスの一環で、静的な入力フィルタが作成され、出力情報への応答を受信できるように保証しています。これにより、攻撃者が現在のシステムのサーバーのオープン ポートを走査し、接続を試みたとしても、その多くは効果的にブロックされます。ただし、攻撃者が IPSec 入力許可フィルタを通じて接続を可能にする特殊なツールを使う可能性はまだ存在しています。任意の宛先の IP (Internet Protocol) アドレスへの出力許可フィルタが必要な場合は (たとえば、出力フィルタリングを使用すれば、SMTP (Simple Mail Transfer Protocol) サーバーはインターネットに接続されている他の宛先 SMTP サーバーに電子メールを送信できます)、ファイアウォールまたは多様な機能を持つフィルタリング装置をホスト コンピュータとインターネットの間に設置する必要があります。可能であれば、出力許可フィルタは、トラフィックの受信に必要な IP アドレスに対応させることをお勧めします。

重要 : IPSec であっても、コンピュータ起動中は完全なセキュリティを提供できません。TCP/IP (Transmission Control Protocol/Internet Protocol) スタックの応答が良い場合もまれにあり、IPSec ポリシーでブロックするアプリケーション ポートに自動攻撃でアクセスできてしまう場合があります。多くの場合、アプリケーションが接続処理を開始できないうちに、IPSec フィルタリングが有効になります。IPSec ポリシー エージェント サービスの開始と同期を取っても、フィルタがタイミング良く有効になることを保証するものではありません。

IPSec フィルタを使って最高レベルのセキュリティを実現するには、コンピュータの再起動中はコンピュータをネットワークから切り離すことをお勧めします。IPSec フィルタが有効になる正確な時間は、サーバー構成と IPSec ポリシーのサイズで決まる多くの要因に依存します。ローカルにテストを行い、サーバーをネットワークに再接続するまでの安全な時間間隔を決定します。テストを実施できない場合は、入力トラフィックを許可ポートのみに制限するためにファイアウォールやフィルタリング ルーターを使用します。

スクリプト コマンド

次のコマンドの実装は、サーバーで実行することをお勧めします。これらのコマンドでは、特別に許可しているネットワーク トラフィック以外のトラフィックをすべてブロックします。

このコマンドのセットは、このガイドに付属するバッチ ファイルにも含まれています。

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
   -f 192.168.100.41+*:53:TCP -f 192.168.100.41+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
   -f *+192.168.100.41:161:TCP -f *+192.168.100.41:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"
   -f 192.168.100.41+*:445:TCP -f 192.168.100.41+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
   -f *+192.168.100.41:445:TCP -f *+192.168.100.41:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
   -f 192.168.100.41+*:135:TCP -f 192.168.100.41+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
   -f *+192.168.100.41:135:TCP -f *+192.168.100.41:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Addl RPC Ports Out"
   -f 192.168.100.41+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
   -f 192.168.100.41+*:137:TCP -f 192.168.100.41+*:137:UDP
   -f 192.168.100.41+*:139:TCP -f 192.168.100.41+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
   -f *+192.168.100.41:137:TCP -f *+192.168.100.41:137:UDP
      -f *+192.168.100.41:139:TCP -f *+192.168.100.41:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
   -f 192.168.100.41+*:123:TCP -f 192.168.100.41+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
   -f 192.168.100.41+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
   -f 192.168.100.41+*:389:TCP -f 192.168.100.41+*:389:UDP
      -f 192.168.100.41+*:636:TCP -f 192.168.100.41+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
   -f 192.168.100.41+*:88:TCP -f 192.168.100.41+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
   -f *+192.168.100.41:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
   -f 192.168.100.41+*:3268:TCP -f 192.168.100.41+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f *+192.168.100.41:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTP Server"
   -f *+192.168.100.41:80:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTPS Server"
   -f *+192.168.100.41:443:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
   -f *+192.168.100.41 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

予想される影響

これらの設定では、ランダムな大きな番号のポートのトラフィックを許可していないので、RPC トラフィックは許可されません。これによりサーバー管理は困難になります。ただし、CIFS およびベーシックな NetBIOS ポートを使用すると、サーバーの使いやすさは大きく改善されます。

管理者は、ターミナル サービス (Terminal Services) クライアントに接続し、リモート 管理を実行できるようにすることをお勧めします。接続している間は、ドライブをリモート コンピュータにマッピングできます。さらに、管理者は他のコンピュータからサーバー方向へのドライブのマッピングを行うことができます。上記のポリシーはこのような機能を制限するように厳しくすることができますが、サーバーの管理は難しくなります。

このようなポリシーはまだ有効で、必要な認証ネットワーク トラフィックが、基本認証または NTLM 認証を必要とする任意の Web サイトで機能することを許可します。

このような比較的少数の IPSec ポリシーの実装では、サーバーのパフォーマンスに目立った影響はありません。ただし、充分にテストを行ってからフィルタを環境に実装し、必要な機能と性能を検証することをお勧めします。これ以外のアプリケーションを使用している環境でサポートするには、さらに規則の追加が必要になるでしょう。

Contoso 社のシナリオ

Contoso 社では、IIS サーバー用に上記仕様の IPSec フィルタを実装しました。

一般的な IIS ベスト プラクティス

ここでは、IIS サーバーを実装し、セキュリティで保護するための一般的なベスト プラクティスを記載します。

  • IIS はドメイン コントロールにはインストールしません。

  • (ネットワークのドメイン コントロールから指示される) グループ ポリシー変更の場合を除き、IIS サーバーに完全にパッチを適用し、可能な限り強化してからネットワークに接続します。

  • Web サーバーには専用コンピュータを使用します。

  • Web サーバー コンピュータはセキュリティ保護されたコンピュータ　ルームに入れて物理的に保護します。

  • 管理者を除き、ローカル ログオンは誰にも許可しません。

  • 管理者にはネットワークを超えてコンピュータにログオンすることを許可しません。ローカル管理ポリシーを採用します。

ページのトップへ

まとめ

この章では、Contoso 社シナリオを使って各サーバー の役割に適応するサーバー強化手順を説明してきました。紹介した手順のほとんどは、さまざまなセキュリティ テンプレートを作成し、各サーバー の役割に対応する適切な OU (Organizational Unit) にリンクする GPO (Group Policy Object) にインポートすることで達成しました。

強化手順の中には、グループ ポリシーを使って適用できないものがありました。その場合は、手作業で手順を設定する詳細を説明しました。

これで Windows 2000 サーバーの導入にあたってセキュリティを保護することができました。次のステップは、組織の環境でセキュリティ パッチの適用を継続する方法、システムのセキュリティを監視する方法、および将来サーバーに発生するセキュリティ インシデントに対応する方法を決定することです。

詳細情報

Active Directory への匿名アクセスを有効とする情報については、マイクロソフト サポート技術情報記事 257988 「Dcpromo におけるアクセス許可の選択について」を参照してください。

Windows NT 4.0 RAS、RRAS、および Active Directory に関する情報については、マイクロソフト サポート技術情報記事 240855 「Windows 2000 ドメインで Windows NT 4.0 RAS サーバーを使用します。」

Windows 2000 DNS に関する詳細については、https://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/plan/w2kdns2.mspx から「Windows 2000 DNS ホワイト ペーパー」を参照してください。

DHCP に関する 80/20 ルール モデルの詳細については、以下のサイトを参照してください。
https://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncb_dhc_ogjw.asp

URLScan に関する情報を含む IIS Lockdown Tool Version 2.1 の詳細については、以下のサイトを参照してください。
https://www.microsoft.com/japan/technet/security/tools/

IIS 5.0 に関する詳細については、以下のサイトにあるホワイト ペーパー「設計から堅固な実装へ : IIS 5.0 セキュリティ ガイド」を参照してください。
https://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/technologies/iis/deploy/depovg/securiis.mspx

IIS サービスのセキュリティを保護するチェックリストに関する詳細については、以下のサイトから「Internet Information Services 5 セキュリティのチェックリスト」を参照してください。
https://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/technologies/iis/tips/iis5chk.mspx

IIS 5 チェックリストのサブセットである、IIS 5.0 ベースライン セキュリティ チェックリストに関する詳細については、以下のサイトを参照してください。
https://www.microsoft.com/japan/technet/archive/security/chklist/iis5cl.mspx

IIS コンテンツとログ ファイルに対する適切なファイル システム アクセス許可設定の詳細情報については、マイクロソフト サポート技術情報記事 310361 「[HOW TO] Windows 2000 で IIS 5.0 のログ ファイルと仮想ディレクトリに安全な NTFS アクセス許可を設定する方法」を参照してください。

IIS のセキュリティ保護と保守に関する詳細については、以下の IIS Answers サイトを参照してください。
https://www.iisanswers.com

ページのトップへ

ページのトップへ