脅威とその対策

第 11 章 :追加の対策

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

ダウンロード

『脅威とその対策ガイド』をダウンロードします。

この章では、追加の対策 (アカウントのセキュリティ保護など) のいくつかを実装する方法について説明します。また、この章では、ネットワーク攻撃に対する効果的な対策として IP セキュリティ (IPSec) フィルタを使用する場合の一般的なバックグラウンド、参照情報、および構成ガイドについても説明します。

トピック

メンバ サーバーのセキュリティ強化手順
Windows ファイアウォールの設定
関連情報

メンバ サーバーのセキュリティ強化手順

このガイドで説明されている対策のほとんどはグループ ポリシーを使用して適用できますが、グループ ポリシーによる適用が困難または不可能な追加設定もあります。この後のセクションでは、ドメイン メンバ サーバーに対するこれらの追加設定を実装する方法の詳細を説明します。

アカウントのセキュリティ保護

Service Pack 1 (SP1) を適用した Microsoft® Windows Server™ 2003 には、削除はできませんが名前を変更できるさまざまなビルトイン ユーザー アカウントがあります。Windows 2003 の最も一般的なビルトイン アカウントには、Guest と Administrator があります。

脆弱性

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

ただし、設定を変更する対策は、近年その効果が弱くなっています。ビルトイン Administrator アカウントのセキュリティ識別子 (SID) を指定して実際の名前を判別し、サーバーに侵入しようとする攻撃ツールが出現しているからです。SID は、各ユーザー、グループ、コンピュータ アカウント、およびネットワークのログオン セッションをそれぞれ識別する値です。このビルトイン アカウントの SID を変更することはできません。

対策

すべてのサーバーで、"Administrator" アカウントの名前を変更し、パスワードを長く複雑にします。

:ビルトインの Administrator アカウントの名前は、グループ ポリシーを使用して変更できます。『Windows Server  *セキュリティ ガイド』*に含まれる基本ポリシーは、この設定を行いません。このアカウントの名前は、各組織が一意に選択する必要があるからです。アカウント名を変更するには、次の場所にある [Administrator アカウント名の変更] 設定を変更してください。
コンピュータの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\
セキュリティ\オプション
作業上のオーバーヘッドが発生しますが、サーバーごとに異なるパスワードを設定するのが理想的です。ただし、組織内のすべてのサーバーで同じアカウント名とパスワードを使用する場合、攻撃者があるメンバ サーバーへのアクセスに成功した場合に、他のすべてのサーバーにもアクセスできてしまうことに留意してください。すべての変更は安全な場所に記録しておきます。

考えられる影響

システム管理を担当するユーザーは、各コンピュータに割り当てられたアカウント名を記録する必要があります。ローカル管理者のアカウントを使用して特定のサーバーにログインする必要のあるユーザーは、このセキュリティで保護されたドキュメントを参照して、ログインするサーバーのユーザー名とパスワードを見つけてください。

NTFS

NTFS 設定のパーティションでは、アクセス制御リスト (ACL) をサポートしています。また、オプションで暗号化ファイル システム (EFS) を介したファイルおよびフォルダ レベルでの暗号化もサポートしています。ファイル アロケーション テーブル (FAT)、FAT32、FAT32x などのファイル システムでは、同様のサポートは行われていません。FAT32 は、FAT ファイル システムのバージョンの 1 つで、既定のクラスタ サイズを大幅に小さくし、最大 2 テラバイトのハード ディスク サイズをサポートするように更新されたものです。FAT32 は、Microsoft Windows® 95 OSR2、Windows 98、Windows Me、Windows Server 2003、および Windows XP で使用されています。

脆弱性

ACL で保護できないファイルは、ローカルまたはネットワークでこれらのファイルにアクセス可能な権限のないユーザーにより、簡単に閲覧、変更、または削除される可能性があります。その他のファイルは ACL で保護できますが、暗号化を使用するとセキュリティがさらに強化され、ファイルへのアクセスを 1 人のユーザーのみに限定する必要性がある場合に適しています。

対策

NTFS を使って、各サーバー上のすべてのパーティションをフォーマットします。変換ユーティリティを使用して、FAT パーティションを破壊せずに NTFS に変換します。ただし、変換ユーティリティにより変換されるドライブの ACL が "Everyone: フル コントロール" に設定される点に注意します。

Windows Server 2003 および Windows XP ベースのコンピュータの場合は、ローカルで次のセキュリティ テンプレートを適用し、既定のファイル システム ACL を構成します。

  • ワークステーションの場合 : %windir%\inf\defltwk.inf

  • サーバーの場合 : %windir%\inf\defltsv.inf

  • ドメイン コントローラの場合 : %windir%\inf\defltdc.inf

セキュリティ テンプレートをローカルに適用する方法の手順については、『Windows Server *2003 セキュリティ ガイド』*の「第 11 章 ‐ 要塞ホストのセキュリティ強化」を参照してください。

:既定のドメイン コントローラのセキュリティ設定は、サーバーのドメイン コントローラへの昇格中に適用されます。

考えられる影響

マイナスの影響はありません。

重要 :NTFS のアクセス許可を正しく設定すると、組織のデータを流出や不正な改ざんから保護するのに役立ちますが、物理的なセキュリティのことも忘れないでください。コンピュータを物理的に制御できる攻撃者は、そのコンピュータでブート可能な CD-ROM またはフロッピー ディスクを使用して代替オペレーティング システムをブートできます。攻撃者が組織のコンピュータの 1 つからハードディスクを取り外し、そのハード ディスクを別の管理されていないコンピュータへ移動させることができます。攻撃者がストレージ メディアの物理的な制御を実行すると、そのデータを保護するのは非常に困難になります。

これはコンピュータ セキュリティの基本的な問題であり、他のオペレーティング システムのファイル システムにも同じ問題が存在します。攻撃者がディスクに物理的にアクセスすると、NTFS のアクセス許可やその他ほとんどの保護手段は簡単にバイパスされます。組織で実装できる目に見える物理的なセキュリティ対策 (建物への入室制限、サーバー ルームへの磁気ロックの設置、サーバーのサーバー ラックへの固定、ラップトップ コンピュータのドッキング ステーションへの固定など) に加えて、このようなタイプの攻撃の影響を少なくするために役立つ次のテクノロジをお勧めします。

  • Syskey とオフライン パスワードを使用して、許可されていない人物が Windows オペレーティング システムを起動するのを防ぎます。

  • EFS を使用してユーザー データを暗号化します。ユーザーに自分のドメイン アカウントを使用するように指導し、さらに回復エージェントをまったく構成しないか、またはローカル管理者のアカウントではなく、ドメイン管理者のアカウントに対して回復エージェントを構成します。

  • 許可されていないユーザーによる組織内のコンピュータの起動の機能を拒否する BIOS パスワードを使用します。

  • CD-ROM ドライブやフロッピー ディスク ドライブからコンピュータを起動できないようにシステム BIOS を構成します。この構成では、許可されていないユーザーによるオペレーティング システムの起動の機能は、そのシステム自体の BIOS により拒否されます。

データおよびアプリケーションのセグメンテーション

長い間、コンピュータのパフォーマンスを向上させるためには、データ、アプリケーション、およびオペレーティング システム ファイルを個別の記憶装置に配置するのが良い方法だとされてきました。このようなタイプのファイルをサーバー上で分離するもう 1 つの大きな理由は、アプリケーション、データ、およびオペレーティング システムのディレクトリ トラバーサル攻撃からの保護にも役立つためです。

脆弱性

オペレーティング システムと同じ記憶域ボリューム上にアプリケーション、データ、およびログ ファイルを格納すると、2 つのタイプの脆弱性が発生します。1 つは、ユーザーが、偶然または故意にドライブをアプリケーション ログ ファイルでいっぱいにしたり、サーバーにファイルをアップロードして記憶域ボリュームをデータでいっぱいにしてしまったりすることです。

2 つ目に考えられる脆弱性は、ディレクトリ トラバーサルの悪用があります。この攻撃では、攻撃者がネットワーク サービスのバグを利用して、ディレクトリ ツリーをシステム ボリュームのルートまで移動します。次に、攻撃者はオペレーティング システム ファイルのフォルダを検索し、リモートでユーティリティを実行します。

脆弱なアプリケーションやオペレーティング システムを利用するディレクトリ トラバーサル攻撃には、何千ものバリエーションがあります。ここ数年の間、IIS はそのうちのいつくかの攻撃に対して脆弱でした。たとえば、NIMDA および Code Red ワームの場合、バッファ オーバーフローを悪用して Web サイトのディレクトリ ツリーをトラバースし、次にリモートで Cmd.exe を実行してリモート シェルへアクセスして、その他のコマンドを実行します。

対策

可能な場合は常に、Web コンテンツ、アプリケーション、データ、およびアプリケーション ログ ファイルをシステム ボリュームとは別のパーティションに移動します。

考えられる影響

一貫した方法でサーバーの構築および管理を行っている組織の場合、影響は最小限で済みます。この情報を管理していない組織については、管理者が各システムの設定方法を調査する必要が生じるため、影響は若干大きくなります。

SNMP コミュニティ名の構成

SNMP (Simple Network Management Protocol) は、TCP/IP ネットワークにおいて広く使用されているネットワーク管理標準です。SNMP では、中央のホストからネットワーク ノード (サーバー、ワークステーション、ルーター、ブリッジ、およびハブ) を管理する方法を提供します。また、SNMP では、管理システムおよびエージェントの分散アーキテクチャを使用して、管理サービスを実行します。ネットワーク管理ソフトウェアを実行するコンピュータは、SNMP 管理システムまたは SNMP マネージャと呼ばれます。管理されるネットワーク ノードは SNMP エージェントと呼ばれます。

SNMP サービスでは、コミュニティ名と認証トラップを使用したセキュリティの基本形を提供します。エージェントの SNMP 通信を制限して SNMP 管理システムの特定のリストにのみ通信できるように設定できます。また、コミュニティ名は SNMP メッセージの認証に使用できます。ホストは同時に複数のコミュニティに属することができますが、SNMP エージェントでは受け付け可能なコミュニティ名のリストに含まれていないコミュニティの管理システムからの要求は受け付けません。コミュニティ名とドメイン名またはワークグループ名の間には何の関係もありません。コミュニティ名は SNMP 管理コンソールと管理されているコンピュータで共有されているパスワードと考えることができます。システム管理者は、SNMP サービスをインストールする際に、簡単には推測できないコミュニティ名を作成する責任があります。

脆弱性

SNMP プロトコルは、セキュリティという点においては本質的に脆弱です。SNMP における最大の脆弱性は、ほとんどすべてのベンダが既定のコミュニティ文字列名を設定していることです。このような既定のコミュニティ名はよく知られています。たとえば、マイクロソフトでは「Public」という語句を使用しています。

2 番目の脆弱性は、さらに解決が困難です。SNMP トラフィックはプレーンテキスト形式で送信されるため、SNMP 管理デバイスが SNMP クライアントに接続すると、コミュニティ文字列は暗号化またはハッシュされずにネットワークで転送されます。サーバー間のすべてのトラフィックを暗号化することにより、この 2 番目の脆弱性に対処することは可能ですが、そのような対処法はこのガイドの範囲外となります。

対策

すべてのコンピュータで読み取りアクセスに使用する SNMP コミュニティ文字列を、ランダムな英数字値として構成します。

SNMP コミュニティ文字列の構成方法

  1. サービス コンソールから [SNMP Service] をダブルクリックします。

  2. [SNMP サービスのプロパティ] ダイアログ ボックスの [セキュリティ] タブをクリックします。

  3. [受け付けるコミュニティ名] リストから [public] を選択します。

  4. [編集] ボタンをクリックし、[SNMP サービスの構成] の [コミュニティ名] ダイアログ ボックスが表示されたら新しいコミュニティ名を入力します。

  5. [OK] ボタンをクリックして、各ダイアログ ボックスを閉じます。

SNMP を使用した書き込みアクセスを無効のままにします。

:コミュニティ名は、DWORD 値が 4 に設定されたレジストリ値としてレジストリ内に格納されます。そのため、スクリプトを作成するか、またはセキュリティ テンプレートに行を追加して、そのテンプレートをドメインベースのグループ ポリシーにインポートすれば、このような変更を自動化できます。この値は、HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities に格納されます。

考えられる影響

SNMP プロトコルを使用するすべての管理ツールでもコミュニティ文字列を再構成する必要があります。

外部からアクセス可能なインターフェイス上の NetBIOS および SMB の無効化

ここでは、完全に制御できないネットワークに配置されているサーバー (外部からアクセス可能な Web サーバーまたは電子メール ゲートウェイなど) に対する推奨事項について特に説明します。このようなタイプのサーバーは、しばしば要塞ホストと呼ばれます。この種のサーバーを運用している場合、「対策」で説明する推奨手順を検討する必要があります。ただし、各変更について徹底的にテストし、NetBIOS を無効にしたコンピュータの管理は困難であるということを理解する必要があります。

脆弱性

サーバー メッセージ ブロック (SMB) および NetBIOS over TCP/IP を無効にすることで、攻撃される可能性のある箇所を大幅に削減し、要塞ホストのセキュリティを強化できます。この構成で運用されているサーバーは管理が難しく、ネットワークで共有しているフォルダにアクセスできなくなりますが、これらの対策により、SMB や NetBIOS プロトコル経由で簡単に侵入されないようにサーバーを効果的に保護できます。このため、インターネットからアクセスできるサーバーのネットワーク接続には、SMB と NetBIOS over TCP/IP を無効に設定するようにお勧めします。

対策

NetBIOS を無効にすると、SMB 通信は阻止されません。標準の NetBIOS ポートがない場合に、SMB では TCP ポート 445 が使用されます。このポートは SMB のダイレクト ホストまたは Common Internet File System (CIFS) ポートと呼ばれています。そのため、NetBIOS と SMB の両方を個別に無効化する明示的な手順を実行する必要があります。

NetBIOS で使用されるポートは次のとおりです。

  • UDP/137 (NetBIOS ネーム サービス)

  • UDP/138 (NetBIOS データグラム サービス)

  • TCP/139 (NetBIOS セッション サービス)

SMB で使用されるポートは次のとおりです。

  • TCP/139

  • TCP/445

インターネットからアクセス可能なサーバー上では、次の手順を実行して [Microsoft ネットワーク共有サービス] と [Microsoft ネットワーク クライアント] を削除します。

SMB を無効にするには

  1. [コントロール パネル] の [ネットワーク接続] をダブルクリックします。

  2. インターネットにアクセス可能な任意の接続を右クリックし、[プロパティ] をクリックします。

  3. [プロパティ] ダイアログ ボックスで、[Microsoft ネットワーク クライアント] をクリックして選択し、[アンインストール] をクリックします。

  4. アンインストールの手順に従います。

  5. [Microsoft ネットワーク用ファイルとプリンタ共有] を選択し、[アンインストール] をクリックします。

  6. アンインストールの手順に従います。

NetBIOS over TCP/IP を無効にするには

  1. [コントロール パネル] で [システム] をダブルクリックし、[ハードウェア] タブをクリックして、[デバイス マネージャ] ボタンをクリックします。

  2. [表示] メニューで [非表示のデバイスの表示] をクリックします。

  3. [プラグ アンド プレイではないドライバ] を展開します。

  4. [NetBios over Tcpip] を右クリックしてから、[無効] をクリックします。

この手順より、TCP/445 と UDP 445 で SMB のダイレクト ホスト リスナが無効になります。

:この手順により Nbt.sys ドライバが無効になります。NetBIOS Session Service (TCP ポート 139 でリスン) は無効になりますが、SMB は完全に無効になっていません。SMB を完全に無効にするには、前述の「SMB を無効にするには」の手順に従います。

考えられる影響

SMB を使用してサーバーに接続できなくなります。サーバーがネットワーク上で共有されているフォルダにアクセスできなくなります。接続時に NetBIOS や SMB に依存する管理ツールは、サーバーに接続できなくなります。

ターミナル サービスのポートの構成

ターミナル サービスではリモート サーバーおよびエンド ユーザーのコンピュータを管理できるため、ネットワーク管理者にとって便利なツールです。リモート デスクトップ クライアントは、既定ですべての Windows Server 2003 および Windows XP コンピュータにインストールされており、Windows 2000 Server のインストール メディアではオプションのコンポーネントとして使用できます。Internet Explorer または Microsoft 管理コンソール (MMC) 内で実行する Microsoft ActiveX® クライアントをダウンロードすることもできます。リモート デスクトップ クライアントおよび ActiveX クライアントはまとめてターミナル サービス アドバンスト クライアント (TSAC) と呼ばれます。

脆弱性

ターミナル サービスでは既定で TCP ポート 3389 をリッスンし、すべてのバージョンのリモート デスクトップ クライアントがこのポートへの接続を試みます。ユーザー認証を含むセッション全体が暗号化されますが、ターミナル サービス クライアントではサーバー認証が行われません。正規のターミナル サービス サーバーを偽装できた攻撃者は、ユーザーが本物のシステムではなく攻撃者のサーバーに接続するように仕向けることができます。攻撃者は、DNS レコードを変更してユーザーを攻撃者のサーバーにリダイレクトするか、他の方法を使用してユーザーを騙します。

対策

ターミナル サービスで使用する TCP ポートを変更するか、または IPSec ポリシーを実装して信頼を要求し、IPSec のトンネル モードではなく IPSec のトランスポート モードを使用して認証ヘッダー (AH) またはカプセル化セキュリティ ペイロード (ESP) のネゴシエートを行います。シナリオによっては、VPN ゲートウェイの後ろにターミナル サービスを分離し、ターミナル サーバーへのアクセスには Point to Point Tunneling Protocol (PPTP) または L2TP/IPSec でセキュリティが保護された VPN トンネルが必要となるように構成することもできます。

ターミナル サービスおよびリモート デスクトップ クライアントで使用するポートの変更方法については、https://support.microsoft.com/default.aspx?scid=kb;ja-jp;187623 のマイクロソフト サポート技術情報の記事「Terminal Server のリスニング ポートの変更方法」を参照してください。このサポート技術情報では、通常のデスクトップ クライアントでのリスン ポートの変更方法を説明しています。ターミナル サービス アドバンスト クライアントの Web クライアントでポートを変更するには、Web ページに以下のスクリプト行を追加する必要があります。

MsRdpClient.RDPport = xxx

(xxx は、対象の TCP ポート番号を表します)Microsoft Internet Explorer 内でターミナル サービス セッションを実行するためにリモート デスクトップの Web 接続を使用およびカスタマイズする方法の詳細については、https://msdn2.microsoft.com/en-us/library/aa382994.aspx の「Providing for RDP Client Security」(英語情報) を参照してください。

考えられる影響

IPSec および AH を実装してもシステムのパフォーマンスにはごくわずかな影響しか与えませんが、これにより、クライアントとサーバーの IPSec 構成の管理という新たなオーバーヘッドが発生します。また、IPSec のセキュリティ アソシエーションを確立する前にインターネット キー交換 (IKE) のセキュリティ ネゴシエーションで使用する、クライアントおよびサーバー コンピュータ間の相互信頼方法を管理するためのオーバーヘッドも必要になります。IPSec ポリシーは、サーバーへ向かうすべてのトラフィックを保護するか、または TCP ポート 3389 への接続に対してのみ IPSec を要求するように設計する必要があります。サーバー側で IPSec を要求すると、互換性のある IPSec 構成および信頼を備えていないクライアント コンピュータへのアクセスが拒否されます。IPSec ポリシーを使用して TCP/IP トラフィックのセキュリティをネゴシエートする方法の詳細については、この章で後述する「IPSec ポリシーの構成」を参照してください。

ターミナル サービス サーバーおよびクライアントの既定のポートを変更すると、クライアント ソフトウェアが新しいポートを使うように設定されていない正規ユーザーは、ポート割り当てが変更されたコンピュータに接続できなくなります。また、TSAC の現在のバージョンでは、TCP ポートを変更する方法がありません。

ワトソン博士の無効化 :ワトソン博士のシステム デバッガの自動実行を無効にする

システム デバッガは、コンピュータとアプリケーションのトラブルシューティングを容易にします。これらのプログラムは、コンピュータの実行中にデータを集め、システム管理者やアプリケーション開発者に提供します。Windows Server 2003 および Windows XP に組み込まれているワトソン博士のツールは自動システム デバッガで、プログラムにエラーが発生するとアクティブになり、システムの状態とアプリケーションの情報を記録します。

脆弱性

重要な運用コンピュータにはデバッガをインストールする必要がないと考える組織もあります。管理者権限を持たないユーザーにより実行されるワトソン博士関連の脆弱性はありません。つまり、攻撃者がワトソン博士を他のユーザーやプロセスに対する攻撃ツールとして使おうとする場合、ローカルの Administrators グループに属している必要があります。攻撃者が管理者権限を手に入れ、コンピュータをほぼ完全に支配できる状態になってしまった状態では、ワトソン博士の機能が無効化されていても、他の方法を使って攻撃が行われてしまいます。

対策

ワトソン博士のシステム デバッガを無効化する詳細については、https://support.microsoft.com/?kbid=188296 のマイクロソフト サポート技術情報の記事「Windows NT でワトソン博士を無効にする方法」を参照してください。

考えられる影響

プログラムがクラッシュした際にシステム デバッガが実行されず、レポートも自動的に作成されません。システム管理者と開発者は、問題の原因を診断するためのプログラムのクラッシュに関して入手できる情報が少なくなります。エラー報告機能も動作しません。

SSDP/UPNP の無効化 :SSDP/UPNP を無効にする

ユニバーサル プラグ アンド プレイ (UPnP™) ホスト サービスを無効にしていても、Windows Messenger など他のアプリケーションは Simple Service Discovery Protocol (SSDP) Discovery Service の検出プロセスを使用してネットワーク ゲートウェイや他のネットワーク デバイスを識別できます。

詳細については、https://support.microsoft.com/?kbid=317843 のマイクロソフト サポート技術情報の記事「SSDP Discover Service および Universal Plug and Play Device Host を無効にしても SSDP トラフィックが送信される」を参照してください。

脆弱性

Windows XP および Windows Server 2003 に組み込まれた UPnP 機能は、UPnP デバイスのローカル ネットワークへの接続時にインストールを自動化できるため、小規模ビジネスまたはホーム ユーザーには非常に有用です。UPnP または SSDP トラフィックをネットワーク上に流したくない組織もあります。これらの機能について現在既知の脆弱性はありませんが、2 年前に Windows XP で、アプリケーションのホットフィックスを必要とする重要な問題が発見されました。

対策

Windows XP に組み込まれている SSDP および UPnP 機能を、どのアプリケーションも使用しないようにするには、次のレジストリ キーに UPnPMode と呼ばれる REG_DWORD レジストリ値を追加します。

HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlayNATHelp\DPNHUPnP\

次に、値を 2 に設定します。

考えられる影響

UPnP と SSDP 機能が完全に無効になります。UPnP デバイスがネットワークに接続されたときは、ユーザーが手動で設定し管理する必要があります。

IPSec ポリシーの構成

Windows 2000、Windows XP、および Microsoft Windows Server 2003 System オペレーティング システムで使用可能な IPSec は、ネットワーク セキュリティの管理者が TCP/IP トラフィックを許可、ブロック、またはセキュリティのネゴシエートをするためのツールです。IPSec は、アプリケーションに対して独立した透過的なツールです。Windows 2000 における設計上の目標は、IPSec プロトコルの AH 形式または ESP 形式を使用してネットワーク トラフィックをセキュリティで保護する方法を提供することでした。IPSec ポリシーでは、IKE を使用したセキュリティのネゴシエーションに必要な静的 TCP/IP トラフィック フィルタ (別名セレクタ) を提供します。

IPSec の最新機能の詳細な説明については、『Windows Server 2003 Deployment Kit:Deploying Network Services』の「Chapter 6 Deploying IPsec」(英語情報) を参照してください。「Determining Your IPSec Needs」のセクション (英語情報) で、IPSec の使用法を説明しています。展開キットは www.microsoft.com/downloads/details.aspx?FamilyID=d91065ee-e618-4810-a036-de633f79872e&DisplayLang=en からダウンロード可能です。

ほとんどのアプリケーションで、Windows ファイアウォール コンポーネントは悪意ある受信トラフィックに対する適切なホストレベルの保護を提供します。Windows Server 2003 SP1 のセキュリティの構成ウィザード (SCW) を使用すると、大規模な展開の Windows ファイアウォール設定のセットアップや管理が大幅に容易になります。IPSec はホスト間やホストとクライアント間のトラフィックをセキュリティ保護するために必要に応じて使用し、Windows ファイアウォールは通常多くの組織の追加の防護層として広く展開されます。

脆弱性

ほとんどのネットワーク セキュリティ戦略は、組織ネットワーク外からの攻撃を防ぐことに焦点を当てていますが、多くの機密情報は内部からの攻撃により失われます。このような内部からの攻撃では、ネットワーク上のデータの変換、上位層プロトコルの設計や実装の弱点を悪用したコンピュータへのアクセスなどが行われます。攻撃者は、管理者パスワードの不正取得に役立つ情報を得るために、NetBT の Null セッションを使用する場合があります (他のセキュリティ設定が使用されていない場合または偶然オフになっていた場合)。

攻撃者は 1 つのアプリケーション ポートで 1 つの脆弱性を見つけるだけで、コンピュータにアクセスして、場合によってはコンピュータを完全に制御することができます。よく知られているように、多くの種類のデータはネットワーク上で送信されるときに保護されないため、従業員、サポート スタッフ、訪問者がデータをコピーし、分析に使用できます。内部ネットワークとインターネットの間に配置されているファイアウォールでは、このような内部の脅威に対する保護は提供されません。内部のファイアウォールでは、クライアントおよびサーバーの保護に必要な認証によるアクセス制御や、コンピュータ間のネットワーク トラフィックのエンドツーエンド セキュリティを提供できない場合も多くあります。

対策

IPSec フィルタでは、送信元および宛先の IP アドレス、IP プロトコル タイプ、および TCP ポートと UDP ポートにより TCP/IP トラフィックを認識します。IPSec フィルタはワームやウイルスのトラフィックをブロックすることで、悪意のあるコードの伝染を抑制して制御するのに役立ちます。また、攻撃者がリモート シェルやその他の攻撃ユーティリティを利用して、侵入したアプリケーションの内部からコンピュータにアクセスするのが非常に困難になります。IPSec ポリシーを Windows 2000 に適用してポートをブロックする方法の詳細については、https://support.microsoft.com/?scid=813878 のマイクロソフト サポート技術情報の記事「IPSec を使用して特定のネットワーク プロトコルとポートをブロックする方法」を参照してください。また、www.microsoft.com/technet/itsolutions/network/security/ipsecld.mspx のホワイトペーパー『Using IPSec to Lock Down a Server』でも、このガイドと同様の Windows Server 2003 の IPSec の許可/ブロック フィルタリングの手順を追った構成ガイドが提供されています。ただし、Windows 2000 では、マイクロソフト サポート技術情報の 813878 で推奨されている NoDefaultExempt レジストリ設定を追加する必要があります。

Windows Server 2003 では MMC IP セキュリティ ポリシーの管理スナップインが提供されます。このスナップインは、IPSec ポリシーの管理に使用できるグラフィカル ユーザー インターフェイス (GUI) を備えています。このツールは、Windows 2000 および Windows XP のものと非常に似ています。Windows Server 2003 では、IPSec ポリシー フィルタのコンピュータへの適用時にこれらを表示するために、MMC IPSec モニタ のスナップインと NETSH IPSec コマンドライン ユーティリティが用意されています。許可およびブロック フィルタは、IKE クイック モードの構成に表示されます。IKE クイック モードの一般的なフィルタは、割り当てられた IPSec ポリシーで定義されているフィルタです。IKE クイック モード固有のフィルタは、コンピュータの特定の IP 構成に適用されるポリシーから決定されます。IKE クイック モード固有の機能である [一致フィルタの検索] は、許可およびブロック フィルタの一致には使用できません。ネゴシエート アクションを行うフィルタのみが対象です。

以下の用語については、セクションの後半部分で説明します。

  • フィルタ一覧 : ポート、プロトコル、および方向を含みます。フィルタ一覧は、トラフィックがこの一覧で指定された内容と一致している場合の決定をトリガします。1 つのリストは複数のフィルタを含むことができます。

  • フィルタ操作 : トラフィックがフィルタ一覧と一致している場合に要求される応答です。指定された操作には、特定のトラフィックのブロックまたは許可が含まれます。

  • ルール : ルールはフィルタ一覧とフィルタ操作の相関関係です。

  • IPsec ポリシー : ルールの集まりです。一度に 1 つのポリシーだけをアクティブにすることができます。

この情報を記録する簡単な方法は、ネットワーク トラフィック マップと呼ばれるテーブルに記録することです。ネットワーク トラフィック マップには、サーバー ロール、ネットワーク トラフィックの方向、トラフィックの宛先、インターフェイスの IP アドレス、IP プロトコル、TCP ポート、および関連する User Datagram Protocol (UDP) ポートに関する基本的な情報が格納されます。ネットワーク トラフィック マップのサンプルを次の表に示します。

ネットワーク トラフィック マップは、特定のサーバーで送受信されるネットワーク トラフィックの種類を理解するのに役立ちます。IPSec ポリシーを作成する前に、サーバーが正常に機能するために必要なトラフィックについて正しく理解しておくことが重要です。正しく理解しておかないと、厳密過ぎるフィルタを作成してしまい、アプリケーションのエラーにつながる可能性があります。

トラフィック マップを作成するには

  1. サーバー ロールに必要なベース ネットワーク サービスを決定します。

  2. 各サービスで必要なプロトコルとポートを特定します。このプロセスでは、ネットワーク モニタを使用してネットワーク トラフィックのキャプチャと分析を行って、宛先アドレス、プロトコル、およびポートを決定する場合もあります。また、Netstat.exe コマンドなどのツールを使用して、開いているポートとアクティブな接続を表示することもできます。

  3. 特定されたトラフィックのみを許可するために必要な IPSec フィルタ ルールを文書化します。

最も制限の厳しい IPSec フィルタから開始して、必要に応じて追加ポートを開くようにすると、これらの設定で可能な最高レベルのセキュリティを実現できます。サービスをクライアント サービスとサーバー サービスに分けている場合、このプロセスはさらに容易になります。サーバー サービスは、コンピュータが他のホストに提供している任意のサービスに対して定義する必要があります。

表 11.1 ネットワーク トラフィック マップのサンプル

サービス プロトコル 発信元ポート 宛先ポート 発信元アドレス 宛先アドレス 処理 ミラー
HTTP サーバー TCP 任意 80 任意 ME 許可 あり
HTTPS サーバー TCP 任意 443 任意 ME 許可 あり
DNS クライアント TCP 任意 53 ME DNS 許可 あり
Block everything 任意 任意 任意 任意 任意 ブロック あり
上記サンプルのトラフィック マップでは、Web サーバーにより任意の送信元 IP アドレスからコンピュータに HTTP および HTTPS サービスが提供されるため、適切なトラフィックが許可されます。宛先の ME は IPSec サービスで変換され、コンピュータ上の各 IP アドレスに対するフィルタが作成されます。これらの各フィルタは、トラフィックが元のコンピュータに戻ることができるようにミラーされます。これにより、実質的に HTTP サーバー ルールによって任意のホストの任意の送信元ポートからのトラフィックが IIS サーバーのポート 80 に接続することが許可されます。このルールのミラーリングにより、IIS サーバーのポート 80 からの TCP トラフィックが任意のホストの任意のポートに対して送信されることが許可されます。 クライアント サービスには、コンピュータで実行され、ポリシーで別のホストを使用しているサービスならどれでも指定できます。たとえば、上記サンプルのトラフィック マップでは、サーバーで Web アプリケーションの 1 つに対して名前の参照を行うために、DNS クライアント サービスを必要とする場合があります。この例では、DNS サーバーへのトラフィックとこのサーバーからのトラフィックを許可するようにフィルタが作成されています。Windows Server 2003 では、この種類の構成に対する Windows 2000 Server のポリシーが強化され、DNS およびその他のインフラストラクチャ サーバーへのトラフィックが許可されています。Windows 2000 では、IPSec ポリシーに、ポリシー内の各 DNS サーバーの IP アドレスを含める必要があります。Windows Server 2003 では、ポリシーで論理名 DNS を使用できます。論理名 DNS は、サーバーのローカル IP 構成に基づいて、各 DNS サーバーの IP アドレスのフィルタに拡張されます。 **注** :Windows Server 2003 のこのような機能を使用する IPSec ポリシーは、Windows 2000 または Windows XP コンピュータには割り当てることができません。 任意の IP からコンピュータの IP アドレスへのミラーされたブロック フィルタにより、コンピュータ上の IP アドレスと送受信されるその他すべてのユニキャスト IP トラフィックがブロックされます。このフィルタは、DNS、HTTP、および HTTPS に対して定義されたプロトコルおよびポート固有のフィルタより一般的です。既定の除外は Windows Server 2003 では削除されたため、このフィルタは送信マルチキャストおよびブロードキャスト パケットを一致させ、その結果これらのパケットはブロックされます。これは、送信元 IP がコンピュータの IP アドレスで、宛先アドレスが任意の IP アドレスと一致したためです。ただし、受信マルチキャストおよびブロードキャスト トラフィックについては、このフィルタによる一致は行われません。送信元アドレスは任意の IP に設定できますが、マルチキャストまたはブロードキャスト パケットの宛先アドレスはコンピュータ上の特定の IP アドレスではなく、マルチキャストまたはブロードキャスト IP アドレスとなります。このため、このルールにより Windows Server 2003 上で受信マルチキャストまたはブロードキャスト トラフィックはブロックされません。このフィルタ定義は Windows 2000 および Windows XP でもサポートされています。ただし、この定義はユニキャスト IP トラフィックのみに一致します。このようなプラットフォームは、ブロードキャストおよびマルチキャスト パケットと IPSec フィルタを一致させるようには設計されていません。そのため、このフィルタが Windows 2000 および Windows XP コンピュータ上で適用されても、マルチキャストおよびブロードキャストの送受信パケットは許可されることになります。 最後のルールの "Block Everything" では、Windows Server 2003 の別のフィルタ拡張機能が実行されます。このルールは Windows 2000 または Windows XP ではサポートされていません。このルールでは、マルチキャストおよびブロードキャストの送受信トラフィックと、より詳細に指定されたフィルタと一致しないその他のユニキャスト トラフィックがブロックされます。このルールが使用された場合、前述の "任意の IP から ME へ" ルールは必要ありません。 このようなポリシーが実施された場合は、コンピュータがリースを更新するために DHCP サーバーと通信したり、ドメイン コントローラ、WINS サーバー、CRL 失効サイト、またはサーバー監視ステーションと通信したりできなくなる点に注意してください。また、このポリシーでは RPC ベースの MMC スナップインまたはリモート デスクトップ クライアント接続を使用した管理者によるリモート管理を許可していません。さらに、例として使用した IIS サーバーに 2 枚のネットワーク インターフェイス カード (インターネット アクセス用と内部アクセス用) がある場合、両方のインターフェイスを介したすべてのトラフィックは同じ方法でフィルタされる点にも注意してください。そのため、このポリシーを運用環境に合わせて大幅にカスタマイズする必要があります。ネットワーク トラフィックは、内部 IP アドレスまたはサブネット用に別途フィルタ処理する必要があります。特定の管理ステーションから IPSec で暗号化されたリモート管理を要求するために使用されるフィルタのルールを適用できる場合は常に使用して、攻撃を受けた他のサーバーが内部インターフェイスを介してサーバーへアクセスしたり、オフライン攻撃用の管理ログイン ネットワーク トラフィックをキャプチャしたりするのを防ぎます。 接続を特定の宛先サーバーや限られた数の宛先サーバーに制限できないクライアント サービスが必要な場合は、IPSec フィルタによるセキュリティのレベルが大幅に低下します。次のネットワーク トラフィック マップのサンプルでは、ルールを 1 つ追加して、管理者が Web ブラウザを使用して任意のインターネット サイトにアクセスして、ヘルプ情報の閲覧やパッチのダウンロードをできるようにしています。この機能には、TCP 宛先ポート 80 のトラフィックに使用する、ミラー化された送信の静的許可フィルタが必要です。 **表 11.2 送信方向の Web ブラウジングが可能なネットワーク トラフィック マップのサンプル**

サービス プロトコル 発信元ポート 宛先ポート 発信元アドレス 宛先アドレス 処理 ミラー
Inbound ICMP for TCP PMTU ICMP 任意 任意 任意 ME 許可 不可
Inbound IIS Server HTTP:80 TCP 任意 80 任意 ME 許可 あり
Inbound IIS Server FTP:21 TCP 任意 21 任意 ME 許可 あり
Inbound Terminal Server TCP 任意 3389 任意 ME 許可 あり
Me to Domain DCs all traffic 任意 任意 任意 ME ドメイン名 許可 あり
Outbound DNS UDP/TCP UDP 任意 53 ME DNS 許可 あり
Outbound DNS UDP/TCP TCP 任意 53 ME DNS 許可 あり
Outbound WINS UDP 137 137 ME WINS 許可 あり
Outbound DHCP UDP 68 67 ME DHCP 許可 あり
Outbound HTTP:80 TCP 任意 80 ME 任意 許可 あり
Block everything 任意 任意 任意 任意 任意 ブロック あり
このサンプルのトラフィック マップは正しい構成のように見えますが、実際には TCP 送信元ポート 80 を通って任意の IP アドレスから受信接続を開始する攻撃者に対して、ポリシー全体がまったくセキュリティを提供しなくなるという結果になります。この攻撃者は受信許可フィルタを通して任意の開いている TCP ポートにアクセス可能で、返信は送信許可フィルタを通って TCP 送信元ポート 80 に戻ることができます。 受信攻撃をブロックするには、次のどのソリューションでも使用できます。 - 他の IPSec フィルタ ルールを追加で使用し、攻撃者がポート 80 を使用して開いているポートへの受信アクセスを行わないようにブロックします。 - フロントエンドのステートフル フィルタ ファイアウォールまたはルーターを使用して、送信元ポート 80 からの受信トラフィックをブロックします。ただし、送信接続に対応している場合は除きます。 - この IPSec ポリシーに加えて、サーバーの外部ネットワーク アダプタ上で Windows ファイアウォールを構成し、IPSec フィルタで許可されているすべての送信トラフィックのステートフル フィルタを提供します。Windows ファイアウォールは IPSec の上位層であるため、Windows ファイアウォールも TCP ポート 80 および 443 の受信を許可するように構成する必要があります (これは既定の構成です)。 次の表のトラフィック マップのサンプルでは、追加の IPSec フィルタを使用して、ポート 80 から開いているポートへのアクセスを試みる攻撃者をブロックしています。まず、Netstat –ano コマンドを使用して、攻撃者が接続する可能性のあるサーバーで開く必要のある TCP ポートを判定します。このコマンドの出力は次のようになります。
    C:\Documents and Settings\testuser.domain.000>netstat -ano Active Connections

    Proto  Local Address       Foreign Address     State         PID TCP
    0.0.0.0:135     0.0.0.0:0     LISTENING     740 TCP    0.0.0.0:445
    0.0.0.0:0    LISTENING     4 TCP      0.0.0.0:1025      0.0.0.0:0
    LISTENING     884 TCP    0.0.0.0:1046    0.0.0.0:0      LISTENING
    508 TCP    192.168.0.5:139     0.0.0.0:0     LISTENING     4 UDP
    0.0.0.0:445      :              4 UDP    0.0.0.0:500    :      508 UDP
    0.0.0.0:1026       :         816 UDP    0.0.0.0:1029     :       508 UDP
    0.0.0.0:1051    :    452 UDP        0.0.0.0:4500      :  508 UDP
    127.0.0.1:123       :     884 UDP    192.168.0.5:123        :
    884 UDP    192.168.0.5:137      :          4 UDP    192.168.0.5:138
    :      4 

次に、TCP 送信元ポート 25 から開いている各 TCP ポートへの特定の攻撃をブロックするために、以下の表のルールが定義されます。

表 11.3 送信方向の Web ブラウジングが可能なネットワーク トラフィック マップのサンプル (改定)

サービス プロトコル 送信元ポート 宛先ポート 発信元アドレス 宛先アドレス 処理 ミラー
Inbound ICMP for TCP PMTU ICMP 任意 任意 任意 ME 許可 不可
Inbound IIS Server HTTP:80 TCP 任意 80 任意 ME 許可 あり
Inbound IIS Server FTP:21 TCP 任意 21 任意 ME 許可 あり
Inbound Terminal Server TCP 任意 3389 任意 ME 許可 あり
Me to Domain DCs all traffic 任意 任意 任意 ME ドメイン名 許可 あり
Outbound DNS UDP/TCP UDP 任意 53 ME DNS 許可 あり
Outbound DNS UDP/TCP TCP 任意 53 ME DNS 許可 あり
Outbound WINS UDP 137 137 ME WINS 許可 あり
Outbound DHCP UDP 68 67 ME DHCP 許可 あり
Outbound HTTP:80 TCP 任意 80 ME 任意 許可 あり
Mitigation from inbound src 80 attack TCP 80 135 任意 ME ブロック 不可
Mitigation from inbound src 80 attack TCP 80 139 任意 ME ブロック 不可
Mitigation from inbound src 80 attack TCP 80 445 任意 ME ブロック 不可
Mitigation from inbound src 80 attack TCP 80 1025 任意 ME ブロック 不可
Mitigation from inbound src 80 attack TCP 80 1046 任意 ME ブロック 不可
Block everything 任意 任意 任意 任意 任意 ブロック あり
この例では、一方向のフィルタを作成して送信元ポート 80 からコンピュータ上の任意のアクティブ ポートへのトラフィックをブロックすることにより、受信攻撃をブロックする方法を示しています。これは、送信元ポート 80 を偽装して RPC、NetBT、SMB (CIFS) で必要とされるポートに接続するのを制限します。 IPsec ポリシーの適用方法はいくつかあります。 - 個別にコンピュータに適用する。 - グループ ポリシーを使用して OU またはドメインに設定する。 - netsh ipsec コマンドのスクリプトを記述し、選択したコンピュータにスクリプトを適用する。 IPSec ポリシーは、グループ ポリシーに基づいて配布できます。ただし、IPSec ポリシーを特定のコンピュータに合わせて調整する必要がある場合は、ローカル ポリシーを使用した方が良いでしょう。または、ローカルまたはドメイン ベースのポリシーと NETSH IPSec スクリプト化された固定ポリシーを組み合わせたものが最も管理しやすい場合もあります。特に、コンピュータ起動中のセキュリティを提供する固定ポリシーの設定には、NETSH を使用する必要があります。詳細については、「*Windows* *Server* *2003 Deployment Kit:Deploying Network Services*」の第 6 章「Deploying IPSec」のセクション「Assigning Domain-based, OU-Level, and Local IPSec Policies」(英語情報) を参照してください。 ###### トラフィックに対する IPSec 保護のネゴシエーション IKE プロトコルと IPSec フィルタを統合すると、IPSec フィルタと一致するユニキャスト IP トラフィックに対する IPSec の暗号化による保護について、ポリシーベースの自動ネゴシエーションが可能となります。IPSec で保護されたパケットには、ポリシー構成に応じて決定されるセキュリティ オプションで AH 形式または ESP 形式を使用できます。IPSec ポリシーを使用して、上位層プロトコルおよびアプリケーションの IPSec でセキュリティが保護されたトランスポートをネゴシエートすると、次の利点があります。 - ネットワーク攻撃に対する徹底的な防御。IPSec は、IETF (Internet Engineering Task Force) によって設計された、成熟した最先端のセキュリティ プロトコルです。IPSec を使用すると、すべてのユニキャスト IP 通信下に強力な防御層を追加できるため、アプリケーションベースのセキュリティが強化されます。この方法で、IPSec は上位層プロトコルのセキュリティにおける脆弱性に対する防御を提供し、通信セキュリティを大幅に強化します。たとえば、SMB ファイル共有プロトコルは、Active Directory® ディレクトリ サービスのレプリケーション、ファイル転送、印刷、およびグループ ポリシーのダウンロードに広く使用されています。ただし、SMB ではプライバシーは提供されません。SMB 内で送信されるすべてのデータは、パッシブ ネットワークのオブザーバに表示されます。SMB ではデジタル署名が提供されていますが、1 つの設定がすべての SMB 通信パスに影響を与えるため、デジタル署名を要求できない場合もあります。IPSec は、特定のネットワーク パスまたはパスのセットをセキュリティで保護するために適用できます。既に明らかにされている 2 つの SMB セキュリティ問題は、Windows 2000 および Windows XP で特定されたものです。これらのセキュリティの問題に対しては、マイクロソフトからサポートされている修正モジュールを入手できるようになりましたが、SMB などのプロトコルへの攻撃に対して、IPSec を最初の防御層として使用することにより、セキュリティを強化することができます。判明している SMB セキュリティの 2 つの脆弱性およびWindows 2000 と Windows XP 用のサポートされている修正モジュールの詳細については、次のマイクロソフト サポート技術情報を参照してください。 - “https://support.microsoft.com/?kbid=329170 の「[\[MS02-070\] SMB 署名の問題により、グループ ポリシーが変更される](https://support.microsoft.com/?kbid=329170)」 - “https://support.microsoft.com/?kbid=326830 の「[\[MS02-045\] ネットワーク共有プロバイダの未チェックのバッファが原因でサービス拒否が発生する](https://support.microsoft.com/?kbid=326830)」 - データの管理所有者がネットワーク転送中もデータを完全に制御できる、複数のコンピュータ間のすべてのトラフィックに対するホストベースの認証と暗号化。ネットワーク トラフィック内のデータには、所有者固有の重要なコア情報資産が格納されています。ネットワークでの転送中にこの情報を盗まれると、組織のビジネスまたは任務に重大な損害を与える可能性があります。ネットワーク パスの信頼性と整合性を管理するビジネス上および法的な信頼関係が完全に適用されていない場合や、知らないうちに侵害されている場合でも、IPSec によって暗号化された通信のセキュリティは保護されます。 - シンプルかつセキュリティ保護されたファイアウォールのトラバーサル。ドメイン コントローラ間、サーバー間、またはクライアントとサーバー間の通信で使用されている多くのプロトコルは、IPSec ESP (プロトコル 50) トラフィックまたは AH (プロトコル 51) トラフィックとしてのみファイアウォールで変換されます。ファイアウォールは、これらのプロトコルのトラフィック (および IKE トラフィック) のみを許可するように構成でき、これらのプロトコルは攻撃に対して強化されます。 - 3DES 暗号化アルゴリズムおよび SHA1 整合性アルゴリズムを使用する IPSec は、セキュリティ共通評価基準 (Common Criteria) および FIPS 140-1 で認定されています。多くの政府、軍、金融、および医療機関において、トラフィックのセキュリティ保護にセキュリティ共通評価基準または FIPS 140-1 で認定されたアルゴリズムを使用することが義務付けられています。RC4 ストリーム暗号アルゴリズムは、RPC、Kerberos 認証プロトコル、LDAP (Lightweight Directory Access Protocol) など、ほとんどの Windows プロトコルのトラフィックを暗号化するために既定で使用されています。RC4 は、セキュリティ共通評価基準または FIPS 140-1 で認定されたアルゴリズムの 1 つではありません。 - ソフトウェアベースの Windows ソリューションである IPSec は、ハードウェアベースのソリューションと比べて、ホスト間の通信のセキュリティ保護に対するコスト パフォーマンスが高くなっています。仮想プライベート ネットワーク (VPN) または専用リース回線といったハードウェア ベースのセキュリティ ソリューションは、Windows IPSec を使用するより費用がかかる場合があります。 - IPSec では、SMB 署名などのプロトコル固有のセキュリティ対策を使用する場合に比べて、CPU の使用率を下げることができます。IPSec の処理をオフロードするネットワーク アダプタを使用すると、IPSec パケットのセキュリティ保護に使用する暗号化処理が高速になるため、暗号化のパフォーマンス コストが最小限に抑えられます。その結果、IPSec でセキュリティが保護された TCP/IP 接続では、設備費はかかるものの、IPSec を使用してセキュリティが保護されていない TCP/IP 接続と同じスループットを実現できます。このようなアダプタをを使用できない場合は、IPSec の暗号化機能によりドメイン コントローラ上の CPU の負荷が増加します。CPU の負荷が増大すると、追加の CPU 容量が必要になる場合と、ならない場合があります。利用可能な CPU およびネットワーク トラフィックの量により異なります。特定のシナリオでドメイン コントローラに与える影響のパフォーマンスのテストを行う必要があります。 ##### 考えられる影響 IPSec は、ネットワーク攻撃に対してサーバーを強化するための 1 つのツールです。唯一のツールまたは完全なソリューションとは考えないでください。IPSec フィルタは、完全な機能を備えた境界領域のファイアウォールやルーター フィルタの代わりになるようには設計されていません。簡単なパケット フィルタのシナリオで、静的フィルタが有効になるクライアントおよびサーバーを強化する場合にのみ、IPSec フィルタを使用することをお勧めします。さらに、IPSec フィルタは、多くのコンピュータに適用されるディレクトリベースのポリシー用に設計されています。そのため、MMC IPSec ポリシーの管理スナップインでは、特定のコンピュータへのポリシーの適用方法について、構成プロセス中に詳細な情報を提供できません。IPsec フィルタの制限には、次のものがあります。 - IPSec フィルタは特定のアプリケーションに対しては適用できません。アプリケーションで使用されるプロトコルおよびポートに対してのみ定義できます。 - IPsec フィルタは、静的です。"ステートフル" な送信トラフィック フィルタは提供されません。送信のネットワーク トラフィックを許可するには、通常、静的な送信および受信許可フィルタが必要です。そのため、IPSec を使用しても、静的な受信許可フィルタを使用して開いている任意のポートにアクセスする攻撃者に対する防御はできません。したがって、送信許可フィルタは、IP アドレスまたは必要とされる範囲に固有である必要があります。 - IPSec フィルタでは、ICMP メッセージの種類は区別されません。 - IPSec フィルタでは、攻撃検出のために IP パケットの内容を検査することはありません。 - IPSec フィルタはオーバーラップ可能ですが、手動で順序付けることはできません。IPSec サービスでは、内部で重要度を計算して、自動的にフィルタの順序付けを行います。フィルタのアドレス部分が最優先され、次にプロトコル、その次に送信元および宛先ポートが続きます。 - IPSec フィルタはインターフェイスに固有ではありません。IP アドレスに固有になるように構成できますが、各インターフェイス上のすべてのトラフィックは、フィルタ一覧に照合されます。 - IPSec フィルタは、受信用または送信用として明示的に構成することはできません。受信および送信の方向は、フィルタで指定されているアドレスに基づいて自動的に決定されます。受信および送信フィルタの両方が自動的に生成される場合もあります。 - IPSec ポリシーでは重複フィルタをサポートしていません。 - Windows Server 2003 では IPSec フィルタのパフォーマンスが大幅に向上しましたが、ホストベースのフィルタによって、CPU に非常に大きなトラフィック ボリュームの負荷が追加される可能性があります。最適化されたフロントエンド ルーターまたはファイアウォールを使用すると、トラフィックのフィルタ処理が速くなります。 IPSec (またはその他のネットワーク デバイス) のフィルタによってネットワーク トラフィックがブロックされると、異常なアプリケーション動作が見られたり、イベント メッセージが表示されたりする場合があります。IPSec フィルタでは、破棄された受信および送信トラフィックの読みやすいログは提供されません。ネットワーク モニタ (Netmon) によるネットワーク トラフィックのキャプチャでは、ブロックされた送信トラフィックは表示されません。Netmon ではブロックされた受信トラフィックが表示できるため、キャプチャ ファイルでは特定のパケットが破棄されたことは示されません。IPSec ポリシーが割り当てられていないときの正常なアプリケーション動作、イベント、およびネットワーク トラフィック フローの知識に基づいて、有効な診断が下されます。 さらに、アプリケーションでのネットワークの使用方法を理解するために、アプリケーション トラフィックに対する IPSec フィルタは、ネットワーク トラフィック フローの詳細な分析に基づいて設計されます。たとえば、SMB プロトコルでは、ファイルの転送、ファイルの共有、および印刷の共有に TCP ポート 139 が使用されます。このポートが IPsec によってブロックされる場合、SMB が TCP ポート 445 を使うこともできます。また、別の例としては、アプリケーションで宛先の異なる複数のネットワーク トラフィック フローが必要な場合が挙げられます。SMB などのプロトコルでは、通常、ユーザーの認証を行います。これにより、コンピュータで Kerberos トラフィックの検出やドメイン コントローラとの Kerberos トラフィックの交換が透過的に行われます。Kerberos プロトコルは、DNS UDP 53 または TCP 53 を使用してドメイン コントローラの IP アドレスのリストを検出し、次に LDAP UDP 389 と、UDP および TCP ポート 88 を使用して、考えられる任意のドメイン コントローラ の IP アドレスを検出します。そのため、そのドメイン コントローラへのパケットがブロックされると、実際に印刷エラーが発生する可能性があります。RPC などの一部のプロトコルでは、コンピュータの起動時またはアプリケーションの実行時に動的に決定される広範な TCP ポートを使用します。したがって、RPC アプリケーションで静的ポートの使用を必要とする構成が提供されている場合を除き、ポート上の静的フィルタでは RPC アプリケーションを効果的に制御できません。 Windows 2000 および Windows XP では、ポリシー構成で指定されているフィルタの既定の除外は、各種 IP ネットワーク トラフィックを対象に設計されています。このようなトラフィックの種類には、IKE を使用したセキュリティ保護ができないもの (ブロードキャストおよびマルチキャスト IP パケット)、IPSec トラフィックに対して提供されるサービス品質 (QoS) のために除外する必要があるもの (RSVP プロトコル)、および IPSec システムが機能するために必要なもの (IKE 自体と IKE 認証方法としての Kerberos プロトコル) があります。このような例外を削除するためにレジストリ キーが提供されていましたが、IPSec フィルタがファイアウォール シナリオの許可とブロックに使用されているときに、これらの除外が無効にされていないことも多くありました。このため、Windows Server 2003 では IKE トラフィックの例外のみが提供されています。マイクロソフトでは、Windows 2000 および Windows XP を使用して、すべての IPSec シナリオの既定の除外を削除することをお勧めします。既定の例外の詳細については、https://support.microsoft.com/?kbid=811832 のマイクロソフト サポート技術情報の記事「[一部の状況で、IPSec のデフォルトの適用除外項目が IPsec 保護の回避に利用されることがある](https://support.microsoft.com/?kbid=811832)」および https://support.microsoft.com/?kbid=810207 の 「[既定の IPSec 除外は、Windows Server 2003 で削除されます。](https://support.microsoft.com/?kbid=810207)」を参照してください。 Windows 2000 コンピュータがインターネットに接続されているときは、ミラー化された送信許可フィルタ (この章で前述したポート 80 など) では、攻撃者が送信元ポートを使用してインターネットからサーバー上の任意の開いている TCP ポートに接続できます。そのため、IPSec 構成を間違えると、期待していたセキュリティが失われる結果となります。構成をテストし、攻撃に対して期待どおりのセキュリティと保護が得られることを確認する必要があります。 セキュリティの侵害によって、攻撃者がローカル Administrator またはローカル システムのアクセス権を取得すると、IPSec ポリシーを無効にしたり変更したりできるようになります。 Windows 2000 の IPSec では、コンピュータの起動中は完全なフィルタを提供できません。TCP/IP スタックが応答する短い時間帯が発生します。自動攻撃によって、本来 IPSec ポリシーによりブロックされるはずのアプリケーション ポートがアクセスされてしまうことがあります。多くの場合、アプリケーションは、IPSec フィルタが実施される前に接続処理を開始できません。IPSec フィルタを使用して最高レベルのセキュリティを実現するには、起動中はコンピュータをネットワークから切断します。 Windows Server 2003 では、IPSec ドライバがコンピュータの起動中に TCP/IP によってロードされる際に使用する初期スタートアップ ポリシーを提供しています。IPSec サービスが起動すると、ただちに継続ポリシーが適用されます。次に、ローカルまたはドメイン ポリシーの割り当てが指定されると、サービスは継続ポリシーに加えてこれらのポリシーの割り当てを適用します。これで、セキュリティで保護された既定の継続ポリシー (管理トラフィックを除くすべてのトラフィックをブロックなど) を構成する NETSH IPSec スクリプトにより、起動からローカルまたはドメインで割り当てられた IPSec ポリシーへの移行中に完全な保護を提供できます。詳細は、Windows Server 2003 のオンライン ヘルプおよび展開キットで説明されています。 ただし、Windows 2000 と Windows Server 2003 のどちらも、サービスが IPSec ポリシー エージェント サービスの起動に依存する設定を許可するようには設計されていません。サービスの依存を設定することにより、依存サービスの開始前にフィルタが用意されるという事実上の保証はありません。 Windows Server 2003 および Windows XP with SP2 では、Windows ファイアウォール サービスを提供しています。Windows ファイアウォールでは、送信トラフィックに対するステートフル フィルタが実行され、ポートへの受信アクセスおよび ICMP メッセージの種類に対する基本制御が提供されます。また、Windows ファイアウォールでは、ブロックされた送受信パケットの読みやすいログも提供します。管理者は Windows ファイアウォールの機能を調査して、トラフィックのフィルタに対する組織のニーズに適合しているかどうかを判断する必要があります。Windows ファイアウォールで提供されているステートフル フィルタは、IPSec フィルタと組み合わせて使用することで、トラフィックの許可にミラー化された送信フィルタを使用するように IPSec を構成する必要がある場合の保護ができます。フロントエンド ルーターまたはファイアウォール フィルタは、可能な場合、防御フィルタの最初の防御として使用する必要があります。 許可されたネットワーク トラフィックおよびアプリケーション内での感染や攻撃を検知し、未然に防ぐためには、ホストベースの侵入検出システムやその他のウイルス対策システムも検討してみる価値があります。サード パーティのホストベース ファイアウォールまたはエッジ ファイアウォールが、複雑なフィルタ ニーズに対して最適なソリューションを提供する場合もあります。 ###### トラフィックに対する IPSec 保護のネゴシエーション IPSec のエンドツーエンドの保護によりセキュリティは大幅に強化されますが、IPSec でセキュリティが保護された通信をネットワークに展開するには、追加のトレーニングと管理コストが必要になります。IPSec ハードウェアであるオフロード ネットワーク アダプタの購入や CPU の処理能力の拡大が必要な場合には、追加でハードウェアのコストがかかる場合もあります。このため、特定のシナリオで IPSec を展開する前に、IPSec の対象範囲となるセキュリティ上の脅威、セキュリティ要件、IPSec 展開のコスト、および予期されるビジネス上の利点を検討して、文書化します。 IPSec および AH を実装すると、クライアント/サーバー IPSec 構成およびクライアント/サーバー コンピュータ間の相互信頼方法を管理するために、新たなオーバーヘッドが発生します。2 台のコンピュータが常に同じドメインまたは相互に信頼関係のある複数のドメイン内に置かれている場合は、グループ ポリシーによって必要な IPSec ポリシー設定を提供し、Kerberos 認証によって IPSec のセキュリティ アソシエーションの信頼を確立できます。コンピュータで Kerberos を使用できない場合は、コンピュータ証明書または事前に共有された認証キーを使用できます。ただし、このガイドでは事前に共有された認証キーの使用は推奨していません。これは、IPSec ポリシー構成ではキー値が保護されない状態で格納されるためです。 ローカル IPSec ポリシーはそのポリシーを定義した管理者のみが読み取ることができますが、Active Directory に格納されたポリシーはすべてのドメイン コンピュータからアクセス可能でなければなりません。したがって、事前に共有されたキー値のプライバシーの維持が難しくなります。マイクロソフトでは、IKE 認証で Kerberos プロトコルが使用できない場合には、デジタル証明書の使用をお勧めします。IPSec ポリシーは、すべてのトラフィックを保護するか、または特定の TCP ポートや UDP ポートに対してのみ IPSec のネゴシエートを行うように設計する必要があります。クライアント側の IPSec ポリシーは、通常、サーバーの静的 IP アドレスを使用して構成する必要があります。サーバー側で IPSec を要求すると、互換性のある IPSec ポリシー構成および相互信頼方法を備えていないクライアント コンピュータへのアクセスが拒否される場合があります。 Windows での IPsec の実装の詳細については、www.microsoft.com/windows2000/technologies/communications/ipsec/default.mspx の「[Windows 2000 IPsec](https://www.microsoft.com/windows2000/technologies/communications/ipsec/default.mspx)」(英語情報) を参照してください。 [](#mainsection)[ページのトップへ](#mainsection) ### Windows ファイアウォールの設定 インターネット ファイアウォールは、部外者がインターネット経由で組織のコンピュータにアクセスするのを阻止するのに役立ちます。Windows XP SP2 および Windows Server 2003 SP1 には Windows ファイアウォールが組み込まれています。Windows ファイアウォールは、ワームや DoS 攻撃のようなネットワークベースの攻撃から多くの組織を保護するセキュリティの層を追加します。 1. \[スタート\] をクリックして \[コントロール パネル\] をクリックします。 2. \[Windows ファイアウォール\] をダブルクリックします。 3. \[有効 (推奨)\] ラジオ ボタンをクリックします。 4. 必要に応じて \[例外\] タブをクリックして、ファイアウォールの通過を許可する例外プロトコルを設定します。 5. \[OK\] をクリックして Windows ファイアウォールを有効にします。 Windows ファイアウォールは、基本的な侵入防止機能の目的で設計されたので、他の多数のサードパーティ製品のように、数多くの機能はありません。Windows ファイアウォールは PC からデータを収集することを許可せず、不要な接続試行をブロックします。ただし、Windows ファイアウォールは広範囲にわたる送信フィルタリングは行いません。 Windows ファイアウォールは、以前のバージョンの Windows に組み込まれていたインターネット接続ファイアウォール (ICF) にいくつかの主要な改良を加えたものです。特に、Windows ファイアウォールはグループ ポリシーで集中的に管理が可能です。利用可能な管理ツールおよび設定の詳細については、www.microsoft.com/downloads/details.aspx?FamilyID=4454e0e1-61fa-447a-bdcd-499f73a637d1&DisplayLang=ja のホワイト ペーパー『[Microsoft® Windows® XP Service Pack 2 向け Windows ファイアウォール設定の導入](https://www.microsoft.com/download/details.aspx?familyid=4454e0e1-61fa-447a-bdcd-499f73a637d1&displaylang=ja)』を参照してください。 [](#mainsection)[ページのトップへ](#mainsection) ### 関連情報 次のリンクは、Windows Server 2003 と Windows XP のセキュリティの強化方法の追加情報を提供しています。 - https://www.microsoft.com/japan/technet/security/prodtech/windowsserver2003/w2003hg/sgch01.mspx の『[*Windows Server 2003 セキュリティ ガイド*](https://technet.microsoft.com/ja-jp/library/cc163108)』は、Windows Server 2003 のセキュリティ機能の設定および管理に関す包括的なガイドです。 - Active Directory ドメインの Exchange Server* *コンピュータのセキュリティ強化手順の詳細は『[*Exchange Server 2003 セキュリティ強化ガイド*](https://go.microsoft.com/fwlink/?linkid=37804)』で説明されています。https://go.microsoft.com/fwlink/?LinkId=37804* *からダウンロードできます。 - ISA Server 2004 コンピュータのセキュリティ強化に必要な手順は『[*ISA Server 2004 セキュリティ強化ガイド*](https://download.microsoft.com/download/6/9/8/6982898e-67e8-4c21-8975-ef492d50ad13/isasecurityguide.doc)』で説明されています。https://download.microsoft.com/download/6/9/8/6982898e-67e8-4c21-8975-ef492d50ad13/ISASecurityGuide.doc からダウンロードできます。 - www.microsoft.com/downloads/details.aspx?FamilyID=4454e0e1-61fa-447a-bdcd-499f73a637d1 のホワイト ペーパー『[Microsoft® Windows® XP Service Pack 2 向け Windows ファイアウォール設定の導入](https://www.microsoft.com/download/details.aspx?familyid=4454e0e1-61fa-447a-bdcd-499f73a637d1&displaylang=ja)』では、Windows ファイアウォールの適切な設定と展開方法の決定に役立つプロセスを概説しています。 [](#mainsection)[ページのトップへ](#mainsection) ##### 目次 - [概要](https://technet.microsoft.com/ja-jp/library/75849e66-9f52-4ceb-874e-cace62110b09(v=TechNet.10)) - [第 1 章 : 脅威とその対策 : Windows Server 2003 と Windows XP のセキュリティ設定](https://technet.microsoft.com/ja-jp/library/18593f91-27d4-49a8-a266-8fa587000c9f(v=TechNet.10)) - [第 2 章 :ドメイン レベルのポリシー](https://technet.microsoft.com/ja-jp/library/5d9e1e11-b8c8-4cd4-a9d6-9f4c25fb6031(v=TechNet.10)) - [第 3 章 :監査ポリシー](https://technet.microsoft.com/ja-jp/library/75931b0b-03b4-4dd5-a0a1-c8035c69916d(v=TechNet.10)) - [第 4 章 : ユーザー権](https://technet.microsoft.com/ja-jp/library/173734d6-0926-4736-b56d-7b5e2756f441(v=TechNet.10)) - [第 5 章 : セキュリティ オプション](https://technet.microsoft.com/ja-jp/library/5a9e0351-4fa5-40a1-a363-de18dc27a55b(v=TechNet.10)) - [第 6 章 : イベント ログ](https://technet.microsoft.com/ja-jp/library/4ee53fe7-4cd1-47ef-bfb9-6705c8f59aa9(v=TechNet.10)) - [第 7 章 : システム サービス](https://technet.microsoft.com/ja-jp/library/7a0506f6-5fc1-4f2f-8e0a-329a4b826769(v=TechNet.10)) - [第 8 章 : ソフトウェア制限ポリシー](https://technet.microsoft.com/ja-jp/library/9d5abd4f-6699-4c8b-b3f5-b00e43366d82(v=TechNet.10)) - [第 9 章 :Windows XP と Windows Server 2003 の管理用テンプレート](https://technet.microsoft.com/ja-jp/library/2c86440d-41f4-479e-8072-0f0b4693e885(v=TechNet.10)) - [第 10 章 :追加のレジストリ エントリ](https://technet.microsoft.com/ja-jp/library/d148d54d-a020-4aef-9664-11b9a7d81c0c(v=TechNet.10)) - 第 11 章 :追加の対策 - [第 12 章 :結論](https://technet.microsoft.com/ja-jp/library/f631bd53-ba1c-4d73-8ff9-c5f870ec5551(v=TechNet.10)) - [謝辞](https://technet.microsoft.com/ja-jp/library/161ab5c8-f118-4c7e-95c0-3ce7c3e49136(v=TechNet.10)) [](#mainsection)[ページのトップへ](#mainsection)