URLScan セキュリティ ツール
最終更新日: 2004年5月28日
URLScan バージョン 2.5 は インターネット インフォメーション サービス (IIS) が処理する HTTP リクエストの種類を制限するセキュリティ ツールです。URLScan セキュリティ ツールは、特定の HTTP リクエストをブロックすることにより、不正なリクエストがサーバーに渡され、障害が起きるのを防ぐことができます。URLScan バージョン 2.5 は現在、IIS 4.0またはそれ以降を実行しているサーバーのクリーン インストールとしてインストールされます。
トピック
URLScan 2.5 の新しい機能
マイクロソフトは URLScan セキュリティ ツールのバージョン 2.5 を再リリースしました。これには、IIS 4.0 およびそれ以降を実行するコンピュータで URLScan 2.5 のクリーン インストールを実行する新しいインストーラが含まれています。
重要 : URLScan 2.5 セキュリティ ツールはお客様のサーバーを攻撃から保護する手助けとなりますが、お客様は常にマイクロソフトからの最新のセキュリティ更新プログラムを評価し、適用して下さい。新しいセキュリティ上の脆弱性が確認されると、マイクロソフトはサービス パック、修正プログラムなどの更新プログラムを公開します。脆弱性がもたらす危険性を緩和するために、セキュリティ更新プログラムが利用可能となった場合、それらを適用する必要があります。
URLScan セキュリティ ツールは UrlScan.dll および UrlScan.ini の 2 つのファイルを含み、これらのファイルはともに UrlScan.exe にパッケージされています。URLScan 2.5 のこの最新の更新は、URLScan 構成での制御を管理者に提供し、サーバーをさらにセキュアにし、ロック ダウンする手助けとなる機能を提供します。
URLScan 2.5 は、以前のバージョンでは利用可能ではない次の機能を導入します。
| • | ログ ファイル ディレクトリの変更機能 |
| • | 長い URL を記録する機能 |
| • | リクエストのサイズを制限する機能 |
ログファイルディレクトリの変更機能
LoggingDirectoryオプションは、ログ ファイルが保存されているフォルダを指定するために使用されます。この値はログ ファイル ディレクトリの絶対パスである必要があります。(例 : C:\Directory_Path) フォルダを指定しない場合、URLScan.dll が保存されているフォルダにログ ファイルを作成します。
長い URLを記録する機能
LogLongUrls オプションが追加され、記録される URL の長さを増やします。以前のバージョンでは、ログ ラインを 1024 バイトに切り捨てていました。この新たなオプションにより、その制限を 128 キロバイト (KB) に増やし、ログを拡張します。有効な値は、0 または 1 で、既定値 は 0 です。LogLongUrlsが 1 に設定された場合、URLScan はリクエストごとに 128 KB までログを残します。値を 0 に設定した場合、ログの入力には最初の 1024 バイトのみが含まれます。
リクエストのサイズを制限する機能
RequestLimits セクションが追加され、それにより、URLScan は、サーバーに送信されるリクエストの分離した部分のサイズ （バイト） の制限を強化することができます。この RequestLimits セクションには以下の 3 つの項目が含まれます。
| • | MaxAllowedContentLength : content-length の最大値を強制します。実際にはサーバーが、設定されたこの値より多くのデータを読み取ることを防ぐわけではありません。たとえば、クライアントがチャンク エンコードされた POST を行う場合、この URLScan オプションはリクエストのエンティティのサイズを監視していません。既定値は、~2 GB (2,000,000,000 バイト) です。 |
| • | MaxUrl : リクエスト URL の長さ （バイト） を制限します。ただし、クエリ文字列の長さは制限しません。インストーラを使用して URLScan をアップグレードする場合、既定値は 16 KB となります。 注 : Urlscan.exe から Urlscan.dll を手動で抽出し、Urlscan.ini を更新しない場合、既定の設定は、260 バイトとなります。この場合、Urlscan.ini に MaxUrl = 16384 を追加して、既定の設定を上書きする必要があります。 |
| • | MaxQueryString : クエリ文字列の長さ （バイト） を制限します。既定値は 4 KB です。 |
Max- をすべてのヘッダ名に付加することによって、特定のリクエスト ヘッダのサイズにバイト制限をすることができます。たとえば、Max-Content-Type=100 と入力することにより、'Content-Type' ヘッダに 100 バイトの制限を設定します。最大値を指定せずに、ヘッダを表示するためには、0 を使用します。たとえば、Max-User-Agent=0 のように指定します。また、RequestLimitsセクションの一覧に記述のないすべてのヘッダでは、長さの制限がチェックされません。
IIS 6.0 で URLScan 2.5 を使用するかどうかを決定する
MicrosoftR Windows Server? 2003 には IIS 6.0 サーバーをセキュアにする手助けとなる多くの組み込みの機能があります。URLScan は IIS 6.0 が提供する以上の動詞の制御などのいくつかの追加機能を提供します。また、URLScan 機能を組織の IIS およびそのほかのマイクロソフトのサーバーについてのサーバー管理方法に統合している組織もあります。URLScan 2.5 の追加の機能性および機能を活用したい場合、または単に現在のセキュリティ管理を保持したい場合、IIS 6.0 での URLScan のインストールおよび使用を検討して下さい。
URLScan 2.5 は IIS 6.0 に含まれていません。この理由は IIS 6.0 には URLScan 2.5 の機能のほとんどと同等、またはそれ以上のセキュリティ機能を提供する組み込みの機能があるためです。表 1 では、IIS 6.0 と URLScan 2.5 が特定のセキュリティ問題をどのように処理するかについて比較しています。この比較を検討し、IIS 6.0 を実行しているサーバーに URLScan 2.5 をインストールするかどうかの決定に役立ててください。
表 1 : URLScan 2.5 の機能と IIS 6.0 の組み込みの機能との比較
URLScan 2.5 の機能 | IIS 6.0 の組み込みの機能 |
DenyExtensions:この機能は、ファイル名の拡張子に基づき、特定のリクエストがサーバーで ISAPI または CGI コードを実行することを防ぐことにより、サーバーへの攻撃の側面を制限するために、URLScan に実装されました。 | IIS 6.0 は、管理者にサーバーで実行できる ISAPI および CGI コードを指定することを許可することにより、サーバーへの攻撃の側面を制限します。IIS 6.0 はコードを直接指定するため、URL のどのファイルがコードを呼び出すことができるかを知る必要はありません。 |
DenyVerbs : WebDAV コードは特定の HTTP 動詞の使用に基づき Web サーバーで呼び出されます。この機能は WebDAV を呼び出すリクエストを防ぐことにより、サーバーへの攻撃の側面を制限するために URLScan に実装されました。 | IIS 6.0 は、管理者が明示的に WebDAV を有効または無効にすることを許可します。このアクションは WebDAV の実行可能コードに直接影響を与えるため、各リクエストに関連する HTTP 動詞を検査する必要がありません。 |
DenyHeaders : WebDAV コードは、特定の HTTP ヘッダの存在に基づき Web サーバーで呼び出されることができます。この機能は WebDAV を呼び出すリクエストを防ぐことにより、サーバーへの攻撃の側面を制限するために実装されました。 | IIS 6.0 は、管理者が明示的に WebDAV を有効または無効にすることを許可します。このアクションは WebDAV 実行可能コードに直接影響を与えるため、各リクエストに関連する HTTP ヘッダを検査する必要がありません。 |
NormalizeUrlBeforeScan : この機能により、管理者はクライアントまたはサーバーで処理される正規化された URL により送信される未処理の URL を IIS が処理するかどうかを指定することができます。
注 : 運用サーバーでこの値を 0 に設定することは現実的ではありません。この値が 0 に設定されている場合、すべてのファイル名の拡張子および UrlScan.ini ファイルのそのほかの URL チェックは各文字の可能なエンコードを指定する必要があります。結果の順列の数は運用サーバーで管理することはほとんど不可能です。 | IIS 6.0 に組み込まれているロックダウン メカニズムは、実行が許可されている実行可能コードに基づいており、クライアントがリクエストした URL に基づくものではありません。この理由のため、NormalizeUrlBeforeScanは IIS 6.0 で必要ありません。 |
VerifyNormalization : URLScan は IISの多くのバージョンで実行されるようデザインされました。URL の正規化を処理するコードは、後のリリースおよび IIS のサービス パックで改善されました。この機能により、URLScan は修正プログラム未適用のコンピュータでの URL 正規化に関する潜在的な問題を検出することができます。 | IIS 6.0 により使用される HTTP.SYS コンポーネントは、URL の正規化の攻撃に対し保護する手助けとなるよう特別に書かれた正規化コードを向上させました。 |
DenyUrlSequences : この機能は、URLScan が Web サーバーでの URLをベースとした攻撃で悪用されるシーケンスを検出できるように URLScan に実装されました。 | IIS 6.0 が URL シーケンスを拒否することは必要ではありません。仕様上、IIS 6.0 は、マイクロソフトにより提供された UrlScan.ini ファイルの既定の DenyUrlSequences セクションに一覧表示されている文字シーケンスを悪用する URL をベースとした攻撃の影響を受けません。 |
AllowDotInPath : URLScan ロックダウン メカニズムは、リクエストの処理の非常に初期段階で発生するフィルタ通知に依存します。この時点で、URLScan には IIS が PATH_INFO について URL を解析するかどうかは分かりません。PATH_INFO が URL のファイル名の拡張子に影響を与える可能性があります。AllowDotInPathを 0に設定すると、URLScan は、「パスでドット文字を使用した」状態のため、ファイル拡張子があいまいな、いかなるリクエストも拒否します。 | AllowDotInPath機能は IIS 6.0 では必要ありません。この理由は IIS 6.0 はそのロックダウンメカニズムで、フィルタ通知に依存しないためです。 |
RemoveServerHeader : この機能により、URLScan が、クライアントへの応答で「サーバー」応答ヘッダからのサーバーの識別を削除または変更することができます。 | IIS 6.0 には RemoveServerHeader機能が含まれません。この理由は、この機能は実際のセキュリティ上の利点を提供しないためです。ほとんどのサーバー攻撃はオペレーティング システム特有ではありません。また、サーバー ヘッダに依存しないメカニズムにより、サーバーの識別およびオペレーティング システムに関する情報を検出することができます。 |
EnableLogging、PerProcessLogging および PerDayLogging : URLScan は中核となる IIS サーバーの一部ではありません。むしろ、URLScan はそれ自体のログ ファイルを作成するアドオン ユーティリティです。これらの設定は URLScan の作成方法およびそのログ ファイルに名前をつける方法を制御します。 | IIS 6.0 はそのロックダウン アクティビティのすべてを W3SVC に記録します。ロックダウンまたは実行可能コードのため拒否されたリクエストが 404 エラーおよびサブ エラー 2 (404.2) により識別されます。未知の種類であるため、拒否された静的ファイルはログで 404 およびサブ エラー 3 (404.3) により識別されます。 |
AllowLateScanning : この機能により、管理者は URLScan がそのほかのフィルタの前または後の URL をテストするかどうかを指定することができます。URL を変更する多くのフィルタがあります。また、URL が変更された後、URLScan がその URL をテストすることが望ましい場合もあります。FrontPage Server Extensions フィルタはこのようなフィルタの一例です。 | AllowLateScanning機能は IIS 6.0 で必要ありません。この理由は IIS 6.0 はそのロックダウンメカニズムについてフィルタ通知に依存しないためです。IIS 6.0 に組み込まれたロックダウンメカニズムは、クライアントがリクエストした URL ではなく、実行を許可される実行可能コードに基づいています。 |
RejectResponseUrl : この機能は UseFastPathReject と関連して動作します。UseFastPathReject が 0 に設定されている場合、拒否されたリクエストは RejectResponseUrl により指定された URL に再マップされます。指定された URL が存在しない場合、クライアントが存在しないページをリクエストしたように、クライアントは通常の 404 応答を受け取ります。指定された URL が存在する場合、サーバーはクライアントに送信される応答をカスタマイズすることができます。 | IIS 6.0 では、実行可能コードのロックダウンのため拒否されたリクエストは 404.2 カスタム エラーを生成します。未知の MIME の種類のため拒否された静的ファイルは 404.3 カスタム エラーを生成します。管理者は IIS カスタム エラー メカニズムを使用して、これらの応答を制御することができます。 |
UseFastPathReject : URLScan ロックダウン メカニズムはリクエスト処理の非常に早い段階で発生するフィルタ通知に依存しています。このため、URLScan はこの通知から直接リクエストを拒否する場合、通常の 404 応答が生成されません。むしろ、クライアントは、通常発生するカスタム エラーではなく、簡潔な 404 応答を受け取ります。UseFastPathReject が 0 に設定されている場合、URLScan は RejectResponseUrl により指定された URL にリクエストを再マップします。 | IIS 6.0 はそのロックダウン メカニズムについて、フィルタ通知に依存しません。IIS 6.0 では、実行可能コードのロックダウンのため拒否されたリクエストは 404.2 カスタム エラーを生成します。未知のファイルの種類のため拒否された静的ファイルは 404.3 カスタム エラーを生成します。管理者は IIS カスタム エラー メカニズムを使用してこれらの応答を制御することができます。 |
AllowHighBitCharacters:この機能により、URLScan は URL の ASCII 以外の文字列を検出することができます。 | 許可されている文字範囲は HTTP.SYS により処理されます。この値は次のレジストリ キーを変更することにより、変更することができます。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\EnableNonUTF8
警告 : レジストリを不正確に編集すると、コンピュータに深刻な損害がもたらされる可能性があります。レジストリへの変更を行う前に、コンピュータのすべての貴重なデータをバック アップして下さい。 |
MaxAllowedContentLength:この機能により、URLScan はサーバーに掲載されるリクエストのサイズに制限を設けることができます。 | IIS 6.0 はリクエストのサイズを制限するための組み込みの機能があり、これは MaxRequestEntityAllowed および ASPMaxRequestEntityAllowed メタベース プロパティにより構成することができます。 |
MaxUrl、MaxQueryString、およびMaxHeader:これらの設定により、URLScan は URL、クエリ文字列、およびサーバーに送られた特定のヘッダのサイズに制限を設けることができます。 | IIS 6.0 により使用される HTTP.SYS コンポーネントは、リクエストの様々な部分に設定されるサイズの制限を許可します。値は、次のレジストリ キーの下のレジストリの AllowRestrictedChars、MaxFieldLength、UrlSegmentMaxLength および UrlSegmentMaxCount を変更することにより、変更することができます。 | • | HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\AllowRestrictedChars | | • | HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\MaxFieldLength | | • | HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\UrlSegmentMaxLength | | • | HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\UrlSegmentMaxCount |
警告 : レジストリを不正確に編集すると、コンピュータに深刻な損害がもたらされる可能性があります。レジストリへの変更を行う前に、コンピュータのすべての貴重なデータをバック アップして下さい。 |
URLScan がなぜ IIS 6.0 との使用のために利用可能となったのでしょうか? URLScan は IIS 6.0 が提供する機能に加え、機能性の小規模なレベルの追加機能を提供します。URLScan は、このコラムで説明されていない目的のために使用することもできるフレキシブルなツールです。URLScan の機能を IIS およびそのほかのマイクロソフトのサーバーについてのサーバー管理方法に統合している組織もあります。これらのいずれの理由により、URLScan 2.5 をインストールし、IIS 6.0 と使用することを選択するお客様もいらっしゃるでしょう。
URLScan 2.5 に関する詳細情報は、マイクロソフト サポート技術情報 307608 「IIS の URLScan を使用する」 をご覧下さい。
URLScan 2.5 をインストールする
URLScan 2.5 は IIS 4.0 またはそれ以降を実行しているコンピュータにクリーン インストールとしてインストールされます。アップグレードのシナリオもまたサポートされています。
URLScan 2.5 をインストールするためには
1. | URLScan 2.5 の Setup.exe ファイルをダウンロードします |
2. | Setup.exe アイコンをダブルクリックします。 |
3. | UrlScan Installer Package の End User Agreement を読み、次に [Yes] をクリックし、同意書に同意し続行します。[No] をクリックした場合、インストーラは閉じます。 |
4. | インストーラが完了すると、次のメッセージが表示されます。"UrlScan has been successfully installed." [はい] をクリックして、インストーラを閉じます。 |
URLScan をアンインストールするためには
1. | [コントロール パネル] で [プログラムの追加と削除] をダブルクリックします。 |
2. | URLScan 2.5 を選択し、[変更/削除] ボタンをクリックします。 |
3. | URLScan 2.5 がサーバーから削除されると、次のメッセージが表示されます。"UrlScan has been successfully uninstalled."[OK] をクリックして、アンインストール プロセスを完了します。 |
URLScan 2.5 インストーラを理解する
URLScan 2.5 をインストールすると、URLScan 2.5 インストーラは次を行います。
| • | %windir%\system32\inetsrv\urlscan ディレクトリの UrlScan.dll および UrlScan.ini ファイルをインストールします。URLScan が既にコンピュータにインストールされている場合、UrlScan.ini ファイルは現在の構成ファイルに存在しない新しい設定で更新されます。 |
| • | URLScan を IIS にグローバル フィルタとして追加します。 |
URLScan を IIS 6.0 を実行しているサーバーにインストールすると、URLScan 2.5 インストーラはいくつかの追加の変更を行い、これにより、URLScan 2.5 が新しい IIS 6.0 プロセス モデルと動作できるようになります。これらの変更は次の通りです。
| • | PerProcessLoggingが UrlScan.ini ファイルで 1 に設定されます。これにより、2 つの URLScan プロセスが同時にログ ファイルに書き込みを行わないようになります。 |
| • | URLScan はメタベースでキャッシュ対応とマークされます。これにより、URLScan を実行する 2 つまたはそれ以上のワーカー プロセスが同時にログ ファイルに書き込みを行わないようになります。 |
| • | 新しいログ ディレクトリ (\inetsrv\urlscan ディレクトリの下のサブディレクトリ) が作成されます。これにより、URLScan ディレクトリが PerProcessLogging オプションが作成するすべてのログ ファイルで混乱しないようにします。 |
URLScan 2.5 を IIS にインストールすると、インストーラは UrlScan.dll、UrlScan.ini およびログ ファイルの許可を設定します。URLScan 2.5 を IIS にインストールすると、インストーラは同じファイルに追加のアクセス許可を設定し、URLScan 2.5 が IIS 6.0 のワーカー プロセス分離モードと動作できるようにします。表 2 は、URLScan 2.5 がインストールされた場合設定される IIS のアクセス許可の一覧です。
表 2 : URLScan 2.5 IIS 6.0 のアクセス許可
ファイル/ディレクトリ | アクセス許可 |
..\inetsrv\urlscan\urlscan.dll | 読み取りおよび実行 (IIS 6.0 のみに設定される) : LocalService、IIS_WPG および NetworkService
フル : 管理者および LocalSystem |
..\inetsrv\urlscan\urlscan.ini | 読み取り (IIS 6.0 のみに設定される) : IIS_WPG、LocalService および NetworkService
フル : 管理者、および LocalSystem |
..\inetsrv\urlscan\logs | 読み取りおよび書き込み (IIS 6.0 のみに設定される) : IIS_WPG、LocalService、および NetworkService
フル : 管理者、および LocalSystem |
URLScan のバージョンがコンピュータで検出された場合、インストール プログラムはアップグレードであると判断します。アップグレードのシナリオでは、インストーラが行う変更は、カスタム ログ ディレクトリが構成されていない限り、クリーン インストールと同じです。URLScan ログと異なる場所を定義した場合、新しいログ ディレクトリは作成されません。
よく寄せられる質問
次の質問をクリックして下さい。
| • | URLScan とは何ですか? |
| • | URLScan 2.5 は IIS 6.0 と動作しますか? |
| • | URLScan 2.0 を既に使用しています。なぜこのアップデートをダウンロードする必要があるのですか? |
| • | 自分のサイトに URLScan を設定しました。URLScan 2.5 により現在の設定は上書きされますか? |
| • | URLScan 2.5 が特定の脆弱性に対しサーバーを保護する手助けとなるのであれば、セキュリティ更新プログラムを引き続き適用する必要があるのですか? |
| • | チャンク エンコードをカスタム アプリケーションで使用しているかわかりません。チャンク エンコードとは何ですか? |
URLScan とは何ですか?
Answer: URLScan は、管理者が設定したルールに従ってリクエストをフィルタリングすることにより、サーバーに入力されるすべてのリクエストを検出します。リクエストのフィルタリングは有効なリクエストのみが処理されるようにすることにより、サーバーをセキュアにする手助けとなります。ほとんどの悪意のある攻撃は、ある共通の文字列を含み、何らかの方法で通常と異なるリクエストを使用するため、URLScan は Web サーバーを保護する手助けとなります。たとえば、リクエストには極端に長く、通常と異なる動作を要求し、別の文字セットを使用してエンコードされ、または正規のリクエストにはほとんど見られない文字列シーケンスが含まれている可能性があります。すべての不正なリクエストをフィルタリングすることによって、URLScan は、このようなリクエストがサーバーに送信され、サーバーにもたらさせる障害を防ぎます。
Question: URLScan 2.5は IIS 6.0 と動作しますか?
Answer: はい。URLScan 2.5 は、マイクロソフトが IIS 6.0 との使用をサポートする唯一の URLScan のバージョンです。
Question: URLScan 2.0 を既に使用しています。なぜこのアップデートをダウンロードする必要があるのですか?
Answer: URLScan 2.5 には URLScan に追加された新しい機能が含まれ、IIS を実行するサーバーのセキュリティを強化する手助けとなります。これらの機能は以下の通りです。
| • | ログ ファイル ディレクトリを変更する |
| • | 長い URL を記録する |
| • | リクエストのサイズを制限する |
Question : 自分のサイトに URLScan を設定しました。URLScan 2.5 により現在の設定は上書きされますか?
Answer: いいえ、上書きされません。インストーラは既存の構成ファイルに新たなエントリを追加するのみです。URLScan は、URLScan の以前のバージョンからの構成の設定のすべてをサポートします。
Question : URLScan 2.5 が特定の脆弱性に対しサーバーを保護する手助けとなるのであれば、セキュリティ更新プログラムを引き続き適用する必要があるのですか?
Answer: はい、引き続きセキュリティ更新プログラムを適用する必要があります。新たな、または既存のセキュリティ上の脆弱性からサーバーを保護するために、マイクロソフトは最新のセキュリティ更新プログラムが利用可能となり次第、それらを評価し、適用することを強く推奨します。
Question: チャンクエンコードをカスタムアプリケーションで使用しているかわかりません。チャンクエンコードとは何ですか?
Answer: チャンク エンコードとは、リクエストまたは応答内のメッセージの本文をそのサイズでスタンプされたチャンクとして伝送する HTTP/1.1 機能です。HTTP 1.1 により、チャンク エンコードを使用することにより、クライアントは POST リクエストを送ることができます。ほとんどの場合、IIS はこれらのリクエストが処理される前に自動的にこれらをデコードします。リクエストのサイズが特定のしきい値 (既定で 48 KB) を超える場合、リクエストが送られる ISAPI または CGI コードはチャンク エンコードが正しくリクエストを処理することを知る必要があります。POST リクエストを受け取るサーバーで実行されているコードがあり、それがチャンク エンコードをサポートするかどうか定かでない場合、URLScan を使用して "Transfer-Encoding" ヘッダを含むリクエストを禁止することを検討して下さい。チャンク エンコードに関する詳細情報は RFC 2616 の section 3.6.1 "Hypertext Transfer Protocol - HTTP/1.1." をご覧下さい。
