IIS 7.0 の要求のフィルタリングと URL 書き換え
IIS 7.0 以降には、IIS 6.0 の URLScan ISAPI フィルターに基づく要求のフィルタリング モジュールが含まれています。 このモジュールは、Web サーバーのセキュリティを強化するのに役立ちます。
IIS チームは、ルールベースの URL 操作の機能を提供する IIS 用のアドオン URL 書き換えモジュールもリリースしました。 URL 書き換えモジュールの主な目的は要求の URL パスの書き換えですが、書き換えモジュールは、Web サイト コンテンツへのアクセスを防ぐセキュリティ適用ツールとしても活用できます。
この記事では、これら 2 つのモジュールの違いについて説明し、Web サーバーのセキュリティを強化するためにどちらを選択すればいいかに関するガイダンスを提供します。
IIS 要求処理パイプラインでの要求のフィルタリングと URL の書き換え
まず第一に、要求のフィルタリング モジュールと書き換えモジュールが IIS パイプラインにどのように接続されるかを理解することが重要です。 次の図は、これら 2 つのモジュールの相対的な順序を示しています:
要求のフィルタリング モジュールは、BeginRequest イベントを処理することによって、要求処理パイプラインの先頭で実行されます。 モジュールは、要求メタデータが既存のフィルターと一致するかどうかを判断するために、要求メタデータ (ヘッダー、クエリ文字列、コンテンツの長さなど) を評価します。 一致するものがある場合、モジュールは 404 (ファイルが見つかりません) 応答を生成し、IIS パイプラインの残りの部分をショートカットします。
要求のフィルタリング モジュールが要求をフィルター処理していない場合、要求は IIS パイプラインの次のモジュール (URL 書き換えモジュール) に渡されます。 URL 書き換えモジュールは、書き換え規則に対して要求を評価します。 ルールの結果としてリダイレクトが行われるか、カスタム応答を送信するか、要求を中止した場合、書き換えモジュールは適切な応答を生成し、IIS パイプラインの残りの部分をショートカットします。
要求のフィルタリング モジュールは、URL 書き換えモジュールの前に配置されていることに注意してください。 これは、IIS アーキテクチャでは、要求のフィルタリング モジュールが悪意のある要求から Web サーバーを保護するゲートキーパー コンポーネントと見なされるためです。 URL 書き換えモジュールは、要求のフィルタリング モジュールによって既にフィルター処理されている URL で動作するサーバーベースの URL 操作コンポーネントと見なされます。 URL の書き換えは、書き換えやリダイレクトを実行できる ASP.NET アプリケーションと同様に、サーバー ベースのアプリケーション ロジックと考えることができます。 要求のフィルター処理が防御の最前線で、URL の書き換えは、アプリケーション固有の 2 つ目のセキュリティ バリアになると考えることができます。 詳細については、IIS Web サイトのブログ投稿「IIS7 の URL の書き換えと要求のフィルタリング モジュール間の相互作用」を参照してください。
要求のフィルタリングと URL 書き換えの違い
要求のフィルタリングと URL 書き換えの概念上の違いは次のとおりです:
- 要求のフィルタリングは、セキュリティ シナリオ専用に設計および最適化されています。
- URL の書き換えは、さまざまなシナリオに適用できます。セキュリティ シナリオは、これらのサブセットにすぎません。
これを念頭に置いて、セキュリティ シナリオに使用できる各モジュールの機能を比較できます。 次のカテゴリを考慮する必要があります:
- フィルター条件。 どのような種類の入力を使用して、要求のブロックに関する決定を行うことができますか? また、要求ブロック ロジックを表すために使用できる条件は何ですか?
- 要求ブロック アクション。 要求がフィルター条件を満たす場合に実行できるアクションは何ですか?
- パフォーマンスへの影響。 要求のフィルタリングと URL の書き換えは、Web サーバーのパフォーマンスにどのように影響しますか?
フィルター条件
次の表に、考えられるフィルター条件の一覧を示し、各モジュールがそれらをどのようにサポートする方法について説明します。
| 条件 | 要求のフィルタリング モジュールでサポートされていますか? | URL 書き換えモジュールでサポートされていますか? |
|---|---|---|
| 要求された URL パスをスキャンする | はい (部分文字列検索を使用) | はい (正規表現とワイルドカード パターンを使用) |
| URL の長さを確認する | はい | いいえ |
| クエリ文字列のスキャン | いいえ | はい (正規表現とワイルドカード パターンを使用) |
| クエリ文字列の長さを確認する | はい | いいえ |
| HTTP 動詞を確認する | はい | はい |
| 要求コンテンツの長さを確認する | はい | いいえ |
| HTTP ヘッダーをスキャンする | いいえ | はい (正規表現とワイルドカード パターンを使用) |
| HTTP ヘッダーの長さを確認する | はい | いいえ |
| サーバー変数をスキャンする | いいえ | はい |
| 送信者の IP アドレスまたはホスト名を確認する | いいえ* | はい |
* IIS の IP 制限モジュールは、特定の IP アドレスとホスト名からの要求をブロックするために使用できます。
要求ブロック アクション
要求のフィルタリング モジュールにはアクションが 1 つだけあり、要求がフィルター条件と一致したときに実行されます。 アクションは、状態コード 404 (ファイルが見つかりません) を返すことです。
URL 書き換えモジュールでは、要求をブロックする必要がある場合に、次のような、より広範なオプション セットが提供されます:
- 要求された URL は、他の URL に書き換えることができます。 たとえば、イメージのホット リンクを防ぐために、サード パーティのドメインからの要求に対して URL をプレースホルダー イメージ ファイルに書き換えることができます。
- Web クライアントを、別の URL にリダイレクトできます。
- 選択した HTTP 状態コードを Web クライアントに送信できます。 たとえば、特定のフィルター条件に一致する要求に対して、状態 401 (未承認) の応答を送信できます。
- ソケット接続を削除することで、HTTP 要求を中止できます。 そうすることで、Web クライアントは Web サーバーに関する情報をまったく取得しません。
パフォーマンスへの影響
どちらのモジュールも、IIS Web サーバーのパフォーマンスにできるだけ影響を与えないよう実装されています。 ただし、これらのモジュール間には、次の重要なパフォーマンスの違いがあります:
- URL 書き換えモジュールは、正規表現パターンに大きく依存します。 正規表現の評価はコストのかかる操作であり、複雑な書き換えルールを多数定義すると、Web サーバーのスループットに大きな影響を与える可能性があります。
- 要求のフィルタリング モジュールでは、正規表現やその他のパターン マッチングは使用されません。 単に部分文字列検索を実行するだけで、Web サーバーのスループットに対する影響が大幅に小さくなります。
要求のフィルタリングと URL 書き換えの選択
Web サーバーのセキュリティを強化するために要求のフィルタリングと URL の書き換えを選択する場合、一般的なルールは要求のフィルター処理から始めます。 要求のフィルター処理はセキュリティ シナリオ用に最適化されており、その機能セットは、セキュリティ要件を実装するのに十分である可能性が最も高くなります。 要求のフィルタリング モジュールで対処できない要件がある場合は、URL 書き換えモジュールを使用してその要件を実装し、残りのセキュリティ タスクを要求のフィルタリング モジュールに残します。 これにより、サーバーが処理する書き換え規則の量を最小限に抑えることで、URL 書き換えモジュールのパフォーマンスへの影響を軽減できます。