セキュリティ

Windows Vista のファイアウォールを管理する

Jesper M. Johansson

 

概要:

• 規則の種類とシナリオ
• ファイアウォールのプロファイル
• ドメインの分離の規則
• 送信フィルタの問題

少し前に、私は自分のブログで Windows Vista のファイアウォールについての記事を書きました。そこでは、単にいくつかの便利な機能を紹介しただけで、展開上のアドバイスについてはあまり触れていませんでした。

この記事では、特にエンタープライズ管理を支援する Windows Vista® のファイアウォール機能の一部について詳しく説明します。また、管理作業を簡素化し、セキュリティを強化するうえで、これらの機能をどのように使用できるかについてのアドバイスも提供します。

最近リリースされた Windows Vista SP1 によって、皆さんは Windows Vista のエンタープライズ展開が進むと思われているかもしれません (企業では、最初のサービス パックがリリースされるまで、新しい OS への移行を控えるというのが一般的です)。現在、エンタープライズ環境への Windows Vista の導入について真剣に検討し始めている IT プロフェッショナルの方には、ファイアウォールの詳細を確認することをお勧めします。Windows Vista のファイアウォールの機能を理解すると、サードパーティ製のセキュリティ スイートの契約内容を見直して、ファイアウォールを契約から外したくなるかもしれません。

Windows ファイアウォールの過去と現在

Windows® XP の最初のリリースで提供されたファイアウォールは、多くの課題を抱えていました。当時市販されているホスト ベースのファイアウォールとは十分に渡り合えるセキュリティ機能は備えていましたが、新機能や革新的な機能は追加されていませんでした。

Windows XP SP2 で提供された後継バージョンは、抜本的に変更されました。このバージョンは、特にエンタープライズ管理が容易になるよう設計されていました。Windows XP SP2 のファイアウォールは、軽量、一元管理が可能、有効、干渉が少ないという特質を備えた、非常に魅力的なファイアウォールです。しかし、おそらく最も重要なことは、Windows XP SP2 のファイアウォールでは、起動時にシステムの保護という非常に重要な処理が行われることです。

この最後の点は、きわめて重要です。ファイアウォールが有効になっていても、起動時にマルウェアに感染してしまうシステムは少なくありませんでした。実際、Blaster が最も猛威を振るった期間の感染率は、4 分に 1 台という非常に高いものでした。つまり、保護されていないコンピュータをインターネットに接続した場合、そのコンピュータは平均して 4 分後にウイルスに感染する可能性があったということです。また、起動時にシステムを保護しないファイアウォールを利用していた場合、12 個のシステムにつき 1 つが再起動時に感染していた可能性がありました。このようなデータを踏まえて、Windows XP SP2 のファイアウォールでは起動時にシステムを保護するようになりました。

Windows Vista では、再びファイアウォールの抜本的な変更が行われました。最も顕著な管理上の変更は、インターネット プロトコル セキュリティ (IPsec) とファイアウォールの管理インターフェイスが統合されたことです。これは非常に理にかなった変更です。IPsec とファイアウォールは、どちらも許可されていないものをブロックすることを目的としています。違いは、ファイアウォールで許可しない対象を定義するパラメータでは、あまり詳細な設定ができず、IPsec では広い範囲のアドレス空間をブロックまたは許可するのが困難なことです。

これら 2 つの機能を 1 つの管理インターフェイスにまとめることで、管理者は、両方のテクノロジをシームレスに使用でき、IPsec の規則が必要なのか、ファイアウォール フィルタを使用すべきかについて、これまでほど悩まずに済みます。つまり、システムがネットワーク攻撃を受ける可能性のある領域を一元的に管理できるので、ミスを最小限に抑えるうえで有効です。

Windows Vista SP1 のファイアウォールでは、信頼性が強化されました。また、IPsec に新しいアルゴリズム (Suite B アルゴリズム) を採用しています。これは、暗号化関連のアルゴリズムで、AES (Advanced Encryption System)、楕円曲線暗号化 (ECC)、セキュア ハッシュ アルゴリズム (SHA) 256 および 384 で構成されています。

しかし、最も重要なのは、Windows Vista Service Pack 1 でネットワーク アクセス保護 (NAP) のサポートが追加されたことです。NAP は、侵害されていない管理クライアントであっても、最新のセキュリティ ポリシー、更新プログラム、マルウェア対策定義に準拠している状態でなければ、ネットワークへの接続を許可しないポリシー強制ツールです。NAP では悪意のあるホストがネットワークに接続することは阻止できませんが、すべての管理ホストが、侵害されていない限り、完全にポリシーに準拠していることを保証できます。

Windows Vista のファイアウォールは、"セキュリティが強化された Windows ファイアウォール" と呼ばれ、Windows Server® 2008 にも搭載されています。すべての機能をリモートからも管理できるだけでなく、グループ ポリシーを使用してネットワーク レベルで構成できます。

規則の種類とシナリオ

1 つの管理インターフェイスにファイアウォールと IPsec の機能が統合されたため、"方向の規則" および "接続の規則" という 2 種類の規則が使用されるようになりました。方向の規則は標準のファイアウォールの規則で、方向ごとに許可するトラフィックを定義します。接続の規則は、コンピュータ間の接続の保護パラメータを定義します。たとえて言うと、方向の規則は以前のファイアウォールでお馴染みのファイアウォールの規則にやや似ています。また、接続の規則は、Windows XP SP2 のファイアウォールと連携して使用していた IPsec の規則に似ています。

ファイアウォールと IPsec を同じインターフェイスに統合することで、いくつか非常に興味深いシナリオが可能になります。たとえば、ネットワーク上でシステムを互いに分離することは、現在最も有用なセキュリティ概念の 1 つです。マイクロソフトでは、これを "サーバーとドメインの分離" と呼んでいます。

サーバーとドメインの分離では、IPsec とファイアウォールの両方の機能を使用します。これを踏まえて、この新しいファイアウォール管理インターフェイスには、分離の規則用の機能が実装されています。この規則は、たとえば接続元または接続先のシステムの属性 (ドメイン メンバシップなど) を基に接続を制限する場合に適しています。

新規の接続セキュリティの規則ウィザードでは、まず作成する規則の種類を指定します (図 1 参照)。[分離] を選択すると、分離の規則に適した特定の設定が自動的に構成されます。

図 1** 新規の接続セキュリティの規則ウィザードを使用した分離規則の作成 **(画像を拡大するには、ここをクリックします)

また、図 1 を見ると、分離の規則の説明で正常性の状態に触れています。サーバーとドメインの分離に使用される規則は、実は NAP に使用する規則と同じです。

トラフィックの種類によっては、認証を強制できないものがあります。たとえば、DNS 解決では認証を要求するのは望ましくないでしょう。この種類のトラフィックのエンドポイントには、認証の除外規則が必要です。認証の除外規則では、文字どおり、IPsec 要件から特定のトラフィックを除外します。

サーバー間の規則は、少し不適切な名前です。一般的にはサーバーで使用されるものですが、クライアントにも使用できます。サーバー間の規則は、単に認証を要求するように接続を構成するものです。分離の規則は認証を要求するだけでなく、ドメイン メンバシップや正常性の状態など他の条件を満たすことも要件になる点で、サーバー間の規則とは異なります。

トンネル規則では、基本的にサイト間の仮想プライベート ネットワーク (VPN) と、ゲートウェイ間のトンネルを定義します。ただし、Windows Vista がゲートウェイ機能に使用される可能性は低いので、トンネル規則を Windows Vista で使用することはまれです。完全にカスタマイズした規則を作成できるため、規則のすべてのパラメータをカスタマイズできます。

規則の順序

規則の順序は、一見少し複雑です。規則の順序を理解する鍵は、まず順序について忘れることです。問題なのは順序ではなく、どの規則に一致するかです。受信トラフィックを例に考えてみましょう。既定では、受信トラフィックは、そのトラフィックを許可する規則がない場合、ブロックされます。"許可規則を最初に考慮する" という順序を使用することを考えるかもしれませんが、この考えは適切ではありません。あるパケットが許可規則とブロック規則の両方に一致する場合、ブロック規則が適用されます。つまり、一致した場合の動作を簡単にまとめると次のようになります。

1. ブロック規則 : パケットまたは接続がこの規則に一致すると、破棄されます。
2. 許可規則 : パケットまたは接続がこの規則に一致すると、許可されます。
3. 既定の方向のプロファイルの動作 : どのブロック規則と許可規則にも一致しない場合、トラフィックは、そのプロファイルの該当方向のトラフィックで、既定として指定されている動作に従って処理されます。すべてのプロファイルの既定の構成では、受信方向のトラフィックはブロックされます。送信方向の場合、既定の構成ではトラフィックが許可されます。

照合プロセスは、認証済みバイパス (IPsec) 規則によって調整されます。この規則を使用すると、この規則の他のパラメータに一致するすべての認証済みトラフィックが、他の規則に一致するかどうかに関係なく、許可されます。認証済みバイパス規則は、[ブロックの規則より優先する] チェック ボックスがオンになっている方向の規則です (図 2 参照)。この規則は、認証済みトラフィックが必ずシステムにアクセスできるように、最初に考慮されます。これにより、簡単に認証済みホストからのトラフィックを許可し、他のコンピュータからのトラフィックをブロックすることができます。このルールの順序は 0 番であると考えることができます。したがって、完全な規則の順序は、次のようになります。

図 2** 認証済みバイパス規則を構成するには、[ブロックの規則より優先する] チェック ボックスをオンにする **(画像を拡大するには、ここをクリックします)

0. 認証済みバイパス規則

1. ブロック規則

2. 許可規則

3. 既定の方向のプロファイルの動作

トラフィック パターンに一致する規則が各クラス内に複数あるかどうかは、それほど問題ではありません。いずれかの規則がトラフィックに一致した時点で、規則の処理は停止します。

パブリック、プライベート、およびドメイン

ネットワークの関連情報

• TechNet セキュリティ センター
• Netsh Advfirewall コマンドライン ツールを使用する
• Windows Vista および Windows Server 2008 における Windows ファイアウォール セキュリティの規則と IPSec ベースの接続セキュリティの規則
• セキュリティ ウォッチ : Windows Server 2008 で SCW を使用する

新しいファイアウォールには、パブリック、プライベート、およびドメインという 3 種類のプロファイルがあります。一方、Windows XP SP2 のファイアウォールのネットワーク プロファイルは 2 種類で、標準とドメインでした。ドメイン プロファイルは、コンピュータでドメイン コントローラが検出された場合、自動的に呼び出されます。Windows XP では、ドメインが検出できなかった場合には標準プロファイルが使用されました。これはセキュリティ管理者にとって強力な機能を提供し、コンピュータの移動中 (ローミング中) にはコンピュータを完全にロックダウンし、組織のネットワーク上にあるときは必要なリモート管理機能のすべてを利用できるようにすることができました。しかし、この方法は、一部のユーザー (特に自宅で個人のネットワークを構築しているユーザー) にとって問題がありました。システムがドメイン コントローラにアクセスできない場合には標準プロファイルが使用されたため、ユーザーが自宅でシステムを使用するときにはシステムがロック ダウンされてしまいました。

Windows Vista で導入された新しいプライベート プロファイルは、この問題を解決するのに役立ちます。システムを新しいネットワークに接続すると、ネットワークがパブリック (以前の標準プロファイルに付けられた新しい名前です) であるかプライベートであるかが確認され、システムが適切に構成されるようになりました。システムは、特定のネットワークに接続するたびに、ネットワークのインフラストラクチャ サーバーから提供されたネットワーク パラメータに基づいて適切な構成を適用します。これは完璧な対策ではありませんが、より多くのネットワークをより適切にロック ダウンできるという点で有用です。

システムがドメイン上にあるかどうかを検出するロジックも強化されています。その結果、より早く、かつ安定したネットワークの切り替えが実現され、実際にドメイン上にあるにもかかわらず、パブリック プロファイルやプライベート プロファイルを使用するという誤った判断をするシステムが少なくなりました。

規則を特定の種類のネットワークに関連付けて、システムが不要に情報を公開したり、信頼されていないネットワーク上のシステムに接続することを防止できます。これは、ファイアウォールと IPsec の統合が本領を発揮できる領域の 1 つです。

このような新しい規則を使用すると、これまでは不可能だったいくつかの制限を実現できます。たとえば、これまで長年にわたって、(Windows ネットワークの場合) 信頼されていないホストへのサーバー メッセージ ブロック (SMB) 接続を確立するようユーザーを誘導する攻撃が仕掛けられてきました。攻撃者は、このような接続をユーザーに確立させて、パスワードの解読に使用できるチャレンジ/レスポンス ペアを提供する認証シーケンスを強制的に実行していました。この攻撃は古くは、クリア テキスト認証へのダウングレードや、ユーザーのチャレンジ/レスポンス ペアを接続元のコンピュータに渡す手段としても使われていました。前者の手法については、かなり前に防止策が確立されました。後者の手法については、Windows XP SP2 で対応していますが、チャレンジ/レスポンス ペアを自発的に提供することは、やはり賢明ではありません。

これを防ぐには、Windows Vista のファイアウォールで導入された新機能である送信フィルタを使用できます。たとえば、パブリック プロファイルのすべての送信 SMB 接続 (TCP ポート 135、139、445、および UDP ポート 137、138、445 が宛先である接続) をブロックできます。この機能を使用すると、チャレンジ/レスポンス ペアの取得を図る誘導攻撃でシステムが悪用されにくくなるだけでなく、インターネット上の信頼されていない Windows ファイル共有へのアクセスを防止できます。

ただし、やはり、これも完璧な対策ではありません。たとえば、システムが既に侵害されている場合、攻撃者がこの規則を無効にできるため、この規則によってシステムの通信を阻止することはできません。しかし、これは、動作は適切でも攻撃を受ける可能性があるシステムの保護対策としては非常に有用な場合があります。

Windows XP SP2 と同様に、Windows Vista と Windows Server 2008 でも、一度にアクティブにできるプロファイルは 1 つだけであることを指摘しておきます。システムで 2 つのネットワーク インターフェイスが有効になっていて、そのうちの 1 つがドメインに接続し、もう 1 つがパブリック ネットワークに接続している場合、パブリック ファイアウォール プロファイルが両方のインターフェイスに適用されます。常に最も制限の厳しいプロファイルが使用されます。ご想像のとおり、パブリック プロファイルはプライベート プロファイルより、プライベート プロファイルはドメイン プロファイルよりも厳しい制限を適用します。ですから、送信 SMB ブロック規則を使用すると、VPN 接続上の大半のトラフィックが阻止される可能性があることに注意してください。

コンピュータがパブリック ネットワークまたはプライベート ネットワーク上にあるときに、VPN 接続経由のトラフィックを可能にするには、VPN インターフェイスにのみ適用する方向の規則を作成します。これが機能するには、VPN インターフェイスが Windows で VPN インターフェイスとして認識される必要があります。Microsoft® ルーティングとリモート アクセス サービス VPN サーバーを使用していない場合は、この機能を大々的に展開する前にテストを行ってください。これは基本的に、クライアントへの受信トラフィックとカスタムの送信規則との問題です。

ファイアウォール規則を作成する

新しいファイアウォールでは、ファイアウォール規則を格段に簡単に作成できるようになりました。新しい規則ウィザード (図 3) を使用して、一般的な種類の規則を定義できます。また、特定のサービス用の定義済みの規則も用意されています。

図 3** 新しい規則ウィザードの定義済みの規則 **(画像を拡大するには、ここをクリックします)

定義済みの規則は特に重要です。基本的に、サーバーの分離は、サービスを使用する必要があるシステムにのみ、当該サービスが提供されるように制限することを目的としています。完全に面倒な設定がなくなるわけではありませんが、サーバー製品では、Windows セキュリティの構成ウィザード (SCW) を使用して、この構成を簡単に行うことができます (SCW については、2008 年 3 月号の TechNet Magazine を参照してください)。

しかし、Windows のクライアント製品には、これまで同様の機能がありませんでした。定義済みの規則を使用すると、面倒な作業の大半 (つまりサービスが使用するエンドポイントを特定する作業) は、自動的に行われます。ファイアウォールはアプリケーションを識別できるだけでなく (たとえば、"iSCSI サービス" が表すプログラムがどれかを認識できる)、特定の機能を記述した定義済みの規則を提供しています。このため、管理者が対応する必要があるのは、規則の対象にする必要があるコンピュータを特定することだけです。これが難しく時間のかかる作業であることに変わりはありませんが、少なくとも環境に固有の作業の 1 つです。

また、カスタムの規則 (図 3 ではドロップダウンのリストで隠れています) もあり、これはファイアウォールの認証で必要だと思われる規則を非常に柔軟に設定できます。たとえば、IPsec 暗号化トラフィックのみを許可する規則が必要な場合、図 2 のウィザードの [アクション] ページでセキュリティで保護された接続のみを許可するオプションを選択します。

このオプションを選択すると、暗号化を有効にするかどうかも指定できます。このチェック ボックスをオフのままにすると、トラフィックは ESP-NULL (NULL キー付きカプセル化セキュリティ ペイロード) を使用します。これは、認証に IPsec を使用する場合の推奨方法です。この場合、トラフィックはネットワーク上で暗号化されずに転送されるため、ほとんどのネットワーク管理ツールの動作が妨げられることがありません。また、暗号化が必要な場合は、このチェック ボックスをオンにするだけでよいのです。

多くの場合、悪意のあるホストからトラフィックを受信することに比べたら、ネットワーク トラフィックの暗号化は些細なことです。ネットワーク トラフィックを暗号化すると、ネットワーク自体にアクセスできる攻撃者がパケット内の情報を盗み出すことを阻止できます。認証を要求すると、パケットの送信自体を防ぎ、攻撃を受けることを回避できます。ネットワーク レベルの暗号化が重要な状況が多数あるのも事実ですが、認証しか必要としない状況も多くあります。

ドメインの分離の規則を作成する

ほとんどの環境では、ワークステーションにトラフィックを送信できるコンピュータの数を制限する必要があります。少なくとも、すべてのワークステーションにドメインの分離の規則を構成する必要があります。これは Windows XP では複雑な作業でしたが、Windows Vista では簡単に行うことができます。

まず、任意の管理ツールを起動し、[接続セキュリティの規則] ノードを選択します。このノードを右クリックし、[新しい規則] をクリックします。図 1 のダイアログ ボックスが表示されたら、規則の種類として [分離] を選択し、[次へ] をクリックします。次に、規則を強制するかどうかを選択します。ほとんどのワークステーションでは、受信トラフィックに認証を要求することをお勧めします。このようにすると、ドメインに参加していないコンピュータからワークステーションにトラフィックが送信されることを防げます。ただし、インフラストラクチャ サービスを使用するには、システムは一部の送信トラフィックがクリア テキストで渡されることを許可する必要があります。したがって、受信接続では認証を必須とし、送信接続では認証を要求することが最適な構成です。

次は、認証方法を選択します。既定で選択されているのは、(あまり役に立たない名前ですが) [既定] というオプションです。IPsec のプロパティでは、コンピュータごとに既定の認証方法を構成できます (プロパティには、[セキュリティが強化された Windows ファイアウォール] ノードを右クリックし、[プロパティ] をクリックしてアクセスできます)。既定の認証方法は、最も簡潔で安全性が高い Kerberos が常に選択されます。ただし、規則を作成するときには、確認のため実際に認証方法を選択することをお勧めします。通常、認証するのはコンピュータのみで、ユーザーの認証は必要としません。両方の認証を必要とすると、匿名で転送される SNMP トラフィックなど、特定の管理トラフィックを受信できなくなる可能性があります。

認証方法を選択したら、後はこの規則を提供するプロファイルを選択するだけです。この規則はドメインに参加していて、Kerberos チケットを提供できるコンピュータに適用されるため、プライベート プロファイルやパブリック プロファイルにこの規則を公開してセキュリティ ホールを作るのは意味がありません。規則を保存したら、作業完了です。

基本的な分離規則は、複雑ではなくなりました。ただし、分離に IPsec を活用するには、ワークステーションにもサーバーの分離を実装する必要があります。これにより、ワークステーションと他のクライアントとの通信を制限し、ワークステーションが、適切な管理ステーションにのみ応答するようにできます。クライアント システムが他のクライアントとの通信を拒否することで、さまざまなマルウェアの発生による影響をどれほど抑えられたかを考えると、これがどれだけ優れた機能であるかをおわかりいただけるでしょう。

ファイアウォールをスクリプトで操作する

新しいファイアウォールには、展開と評価のスクリプト化を可能にする多数の API が用意されています。理想的には、展開にはグループ ポリシーを使用するのが適切ですが、グループ ポリシーは常に利用できるとは限らないので、適切な API セットを使用してファイアウォールを構成することが重要です。この新しいファイアウォールの API は、INetFWPolicy2 API セットとしてグループ化されています。ここでは、理解を助けるため、いくつかの使用例を紹介しますが、詳しい使用方法については、ソフトウェア開発キットと MSDN® ライブラリを参照してください。

よくある例の 1 つとして、規則のグループが有効かどうかを特定する必要がある場合があります。たとえば、アプリケーションや管理者が、あるシステムではファイルとプリンタ共有が許可されているかどうかを特定する必要があるとします。これは、INetFWPolicy2::IsRuleGroupCurrentlyEnabled を利用して確認できます。図 4 は、この処理を行う VBScript サンプルです。

Figure 4 INetFWPolicy2::IsRuleGroupCurrentlyEnabled の使用

' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

ファイルとプリンタの共有が無効になっていて、これを有効にする必要がある場合は、まず、この処理を実行できることを確認し、グループ ポリシーによって上書きされないようにする必要があります。これには、INetFWPolicy2::LocalPolicyModifyState API を使用できます。実際に使用するコードを追加できるコード スケルトンを以下に示します。

Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

コマンド ラインとインターフェイスの種類

管理用の適切なコマンド ラインがなければ、ファイアウォールは完璧とは言えません。netsh コマンドには advfirewall という名前のサブコンテキストがあります。advfirewall コンテキストを使用すると、GUI から実行できる操作をすべてコマンド ラインから実行できます。たとえば、送信ブロックをポート 445 に実装する場合、次のコマンドを昇格したコマンド プロンプトから実行します。

netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any

ブロックを完全なものにするには、TCP を UDP に置き換えて同じコマンドを実行する必要があります。この 2 つ目のコマンドを実行すると、規則の実装が完了します。

ファイアウォールの便利な機能の 1 つは、ネットワーク インターフェイスの種類に基づいて構成できることです。VPN 接続に影響する規則があることを思い出してください。Windows でインターフェイスが VPN インターフェイスとして認識されれば、この種類の規則を使用して、このインターフェイス経由のトラフィックを除外できます。

netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS

規則を作成すると、この処理を GUI から行うこともできます。作成した規則を右クリックし、[プロパティ] をクリックして、[詳細設定] タブをクリックします。インターフェイスの種類を選択するセクションで、適切なインターフェイスの種類を選択します。

送信フィルタ

Windows XP SP2 のファイアウォールに送信フィルタがないことが、組み込みのファイアウォールでは十分なセキュリティが確保できない最大の証拠として挙げられていました。送信フィルタがない Windows XP SP2 のファイアウォールがいかに安全でないかを記した記事の数は数千にも上るでしょう (しかし、Windows XP 対応ファイアウォールで送信フィルタを安全に提供できるものが、まったくないという事実は考慮されていませんでした)。

送信フィルタを単なる処理速度を遅らせるものから有用なセキュリティ機能に変えるための基本的な機能 (または、前述のようなポリシー強制ツール) は、Windows XP には用意されていません。しかし、Windows Vista では、この機能が導入され、新しいファイアウォールがこの機能を利用しているのはきわめて当然なことです。既定では、ほとんどの受信トラフィックはブロックされ、ほとんどの送信トラフィックは許可されます。

既定では、新しい Windows Vista のファイアウォールの送信フィルタは、サービスから発信された不要なトラフィックのみをブロックします。これは、実は送信フィルタを提供するホストの侵害を防ぐために実施できる唯一の対策ですが、Windows XP では、これを行っても意味がありませんでした。

Windows Vista のサービスは、非常に制限されたトークンで実行できます。基本的に、各サービスには、それぞれに一意な独自のセキュリティ識別子 (SID) があります。このサービス SID を使用して、ネットワーク ポートなどのリソースへのアクセスを制限できます。これは、前述のユーザーへのトラフィックの制限に関する箇所で取り上げた機能と同じものです。つまり、2 つのサービスが NetworkService として実行されていても、これらのサービスでは互いのプロセスを管理することはできず、一方の送信トラフィックしか許可しないようにファイアウォールを構成できます。ポートはサービス SID によって制限されているので、ブロックされている方のサービスが侵害されたとしても、許可されている方のサービスの制御を奪って、許可されているポートを使用して送信を行うことはできません。

この機能も、Windows Vista で追加された非常に便利なセキュリティ機能の 1 つです。新しいファイウォールでは、この機能を使用して、送信ファイアウォール フィルタによる本当のセキュリティの価値を実現しています。

実際、新しいファイアウォールでは、サービス SID に基づくファイアウォール フィルタが既定で有効になっています。これを構成するための GUI はなく、規則は、HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices レジストリ キーであらかじめ定義されています。ただし、このキーを手動で変更することは、サポートされていないため、慎重に行ってください。

送信フィルタが提供できるセキュリティの価値

セキュリティ コミュニティでは、送信フィルタで実際に提供されるセキュリティ価値が大きく誤解されています。これまで、送信フィルタによりセキュリティを確保する 2 つのシナリオを紹介しましたが、どちらも Windows Vista より前のバージョンでは提供されていなかった Windows Vista の新機能に依存しています。それにもかかわらず、一般に、送信フィルタは概ね良いもので、ファイアウォール製品の購入を決めるうえでの主要な検討事項の 1 つにするべきだと考えられています。

皮肉なことに、多くの組織では、送信フィルタ機能が購入の決め手になっているにもかかわらず、ファイアウォールの実装後に送信フィルタは使用されていません。このような考え方は適切ではなく、資金と情報セキュリティ グループの労力の無駄につながります。この考え方は、現実の脅威を実際に分析するのではなく、セキュリティに関する何かを行うことで安心したいという欲求によるものだと思われます。事実に基づいて決められるべきものが、このような "セキュリティ ショー" に対する欲求に基づいて決められているケースがあまりに多すぎます。

送信フィルタの支持者が見逃している非常に純然たる事実があります。多くのホスト ベースのファイアウォールのベンダは、ワームまたは悪意のある対話ユーザーによってシステムが侵害された場合、送信フィルタによって、ワームが他のシステムに感染したり、攻撃者が送信したりすることを回避できると主張しています。しかし、これは真実ではありません。

他のすべての条件が同じであって、送信フィルタを使用すれば、従来のマルウェアの一部は防止できたでしょう。しかし、Windows XP で送信フィルタが提供されていたとしたら、これまで出現したワームは送信フィルタを無効にするか迂回するように作成されていたと思います。

Windows XP (とそれ以前の Windows) では、サービスとして実行されるワームではこれが可能です (一般的に話題になったワームはすべてサービスとして実行されます)。従来のワームで送信フィルタが無効または迂回されなかったのは、単に送信フィルタを使用している環境がなく、これを無効にする必要がなかったからです。対話型攻撃では、攻撃者は自由に送信フィルタを迂回できます。攻撃者が任意のコードを実行できれば、これは簡単なことです。ただし、必要に応じて、攻撃者はユーザーを誘導して送信フィルタを迂回することもできます。

ホスト ベースのファイアウォールの送信フィルタを迂回する方法は複数あり、その方法は攻撃のシナリオによって異なります。最も簡単な方法は、過剰な特権を持つユーザーが攻撃者の代わりに送信フィルタを迂回するように "頼む" ことです。多くの環境では、管理者特権を必要としないユーザーに管理者特権を与えています。このようなユーザーは、自由にセキュリティ ポリシーを迂回する権限を持っています。攻撃者が行う必要のある作業は、不可解な緊急度の低いセキュリティ機能とユーザーにとってより価値のあるもの (つまり、おとり) のいずれかを選択するダイアログ ボックスを提示するだけです。

このようなダイアログ ボックスがあまりに多く表示されるため、多くの場合、ユーザーは実際に何が起きているかを理解することなく、すぐにクリックしてしまいます。これが、送信フィルタの第一の問題です。セキュリティか十分に魅力的な報酬のどちらかを選ぶように求められた場合、必ず後者が選ばれます。これは、セキュリティに関する判断を求めるダイアログ ボックスの大半は、そのような判断を下すのに必要な情報を提供していないためです。

セキュリティに関する判断を求めるダイアログ ボックスで、十分な判断材料となる情報を提供することは、ファイアウォールなどのセキュリティ製品側で、ポート、プロトコル、要求側のアプリケーションについて把握するだけでなく、要求の本当の狙いとそれがユーザーにとってどのような意味を持つかを理解することが必要になるため、実際には困難です。また、このような情報を、プログラムを使用して取得するのは非常に難しいことです。たとえば、Microsoft Word が送信接続を試行しているという事実は、その接続を利用して Word が実行しようとしている具体的な処理が何であるかということに比べたら重要ではありません。

意味のないダイアログ ボックスの数は増やすのではなく減らす必要がありますが、送信フィルタ ファイアウォールはこの点では役に立ちません。ユーザーに価値のある情報を提供するという点で最新の動向を知るために、ホスト ベースのファイアウォールの大手ベンダの販売資料に目を通しました。豪華なパンフレットでは、ファイアウォールの送信フィルタ機能とアドバイス機能が大々的に宣伝されています。アドバイス機能は、ユーザーの操作を検出して、適切なアドバイスを提供する機能です。理論的には、そのようになります。パンフレットには、「現時点では、このプログラムでは、アドバイス機能を利用できません。以下を選択するか、[詳細情報] をクリックしてください。」という文が表示されたスクリーンショットが添えられていました。販売資料の中であっても、ベンダは有用なダイアログ ボックスを提供できないようです。

ユーザーはセキュリティに関する正しい判断を下すのに必要な情報を持っていないので、エンド ユーザーが送信フィルタを構成することはできず、管理者がすべての送信フィルタを構成する責任を負うことになり、管理者の負荷が大幅に高くなります。

ファイアウォールによる確認ダイアログ ボックスで [いいえ、また後で確認する] をクリックしても、通常、マルウェアはファイアウォールを迂回できてしまいます。悪意のあるコードを実行するユーザーがいずれかのポートで送信接続を開くことができれば、有害なコードはそのポートを使用できます。したがって、どのプロセスでも、既存のプロセスに便乗できます。以前のオペレーティング システムでは、これが可能でした。Windows Vista と今後リリースされる Windows では、プロセスを適切に制限できるので、送信フィルタを使用して、サービス (既定の制限対象) を既定でブロックできます。

残念ながら、ほとんどの人が、ホスト ベースのファイアウォールの送信フィルタを使用すると、侵害された資産からの他の資産への攻撃を防げると考えています。しかし、それは不可能です。侵害された資産に保護対策を施して、他の資産を侵害しないことを望んでも、うまくいきません。保護対策は、その対策を講じた資産に属するもので、それ以外の資産を保護するのには役立ちません。既に家の中に侵入している不審者に何も盗まないように頼んでも、そもそも家の中に押し入られないための対策を講じた場合と同じ効果が得られないのと同じことです。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの Microsoft MVP でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。

© 2008 Microsoft Corporation and CMP Media, LLC.All rights reserved; 許可なしに一部または全体を複製することは禁止されています.