IIS 10 で公開しているサイトに誤った URL でアクセスすると、「HTTP Error 404.0 – Not Found」やタイトルの「IIS 10.0 Detailed Error」からサーバーのバージョンが丸見えになることがあります。本記事では、IIS の設定だけでこれらの情報をきちんと隠しつつ、実運用で使える404エラーページを構成する手順を、サンプル設定付きで詳しく解説します。
IIS 10 の 404 エラーでバージョン情報が漏れる仕組み
まず、「どこから IIS のバージョンが見えているのか」を整理しておきます。典型的には次の 2 箇所です。
- HTTP レスポンスヘッダー
Server - IIS 標準の「詳細エラーページ」の HTML(タイトルなど)
誤った URL にアクセスしたときの情報漏えいポイントを表にすると、次のようになります。
| 確認箇所 | 例として見えてしまう情報 | 主な原因 |
|---|---|---|
レスポンスヘッダー Server | Microsoft-IIS/10.0 | IIS の既定設定(removeServerHeader が無効) |
ブラウザのタブ / <title> | IIS 10.0 Detailed Error - 404.0 - Not Found | 「詳細エラーページ」をインターネット側にも返している |
| HTML本文 | フッターの「Microsoft IIS 10.0」など | 同じく詳細エラーページの利用 |
多くの場合、「Server ヘッダーを消すだけ」または「詳細エラーをローカルだけにするだけ」で満足してしまいがちですが、本番運用では両方やって初めて“それらしい”セキュリティ設定になります。
IIS バージョンを隠すべき理由
「バージョンを隠したところで、どうせスキャンされたら分かるから意味がない」と言われることもありますが、実務上は次のような理由から「まずは隠す」のが一般的です。
- 既知の脆弱性(CVE)を突く自動攻撃は、バージョン文字列に強く依存するものが多い
- 情報セキュリティ監査や脆弱性診断(ペネトレーションテスト)で、「不要なサーバーバナーが出ている」こと自体が指摘事項になる
- 複数ベンダーや顧客企業との契約で「サーバーソフトウェアのバージョンを外部に表示しない」ことが要件に含まれる場合がある
もちろんこれだけでセキュリティが完成するわけではありませんが、「攻撃者に余計なヒントを与えない」最低限の設定としてやっておく価値は高いです。
対策の全体像
この記事で行う設定は、大きく分けて次の 3 つです。
- Server ヘッダーを削除して IIS バージョンを隠す
- IIS の詳細エラーページをインターネット側に返さない
- アプリケーションやフレームワークが付ける識別ヘッダーも削除する
ざっくりした作業フローをまとめると、以下のようになります。
| ステップ | 目的 | 主な設定箇所 |
|---|---|---|
| 1. Server ヘッダー削除 | IIS のバージョンをレスポンスヘッダーから消す | system.webServer/security/requestFiltering |
| 2. エラーページのモード変更 | 「IIS 10.0 Detailed Error」を外部に出さない | 「エラーページ」機能 / system.webServer/httpErrors |
| 3. カスタム404ページの設定 | 独自デザインの404を表示しつつ情報露出を抑える | httpErrors で statusCode="404" の定義 |
| 4. 追加ヘッダーの削除 | X-Powered-By 等のフレームワーク情報を隠す | system.webServer/httpProtocol, system.web |
| 5. 動作確認 | ブラウザ / curl でヘッダーと表示を検証 | ブラウザ開発者ツール, コマンドライン |
以下で、それぞれのステップを具体的な設定例付きで解説していきます。
Server ヘッダーから IIS バージョンを消す(IIS 10, 1709 以降)
IIS 10(Windows Server 2016/2019/2022 など)で OS のバージョンが 1709 以降なら、IIS 標準機能だけで Server ヘッダーを落とせます。
IIS マネージャー(GUI)から設定する
- IIS マネージャーを開き、対象サイト(もしくはサーバー全体)を選択します。
- 中央ペインから「構成エディター」を開きます。
- セクション欄に
system.webServer/security/requestFilteringを指定します。 - プロパティ一覧から
removeServerHeaderを探し、値をTrueに変更します。 - 右ペインの「適用」をクリックします。
- 必要に応じてアプリケーションプールの再起動や
iisresetを実行します。
これで新しいリクエストからは、IIS が自動で付与していた Server: Microsoft-IIS/10.0 が返らなくなります。
web.config で設定する
GUI ではなく構成ファイルから設定したい場合は、対象サイトの web.config に次の要素を追記します。
<configuration>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
</system.webServer>
</configuration>
サーバー全体に適用したい場合は applicationHost.config に記述する方法もありますが、まずは対象サイト単位で試してから段階的に広げると安全です。
リバースプロキシや CDN が Server ヘッダーを付け直すケース
最近は IIS の前段に、次のような機器やサービスを挟む構成が一般的です。
- ロードバランサ(HW LB / ソフトウェア LB)
- リバースプロキシ(nginx, Apache, ARR など)
- CDN(Azure Front Door, CloudFront 等)
これらが Server ヘッダーを上書きしたり追加したりしている場合、IIS 側で消しても最終的なレスポンスには Server: nginx や Server: Apache などが残ります。本当に消したいのは「インターネットに見える最後のサーバー」なので、必要に応じてそれぞれの機器側でもヘッダー削除設定を行ってください。
詳細エラーページをインターネット側に出さない
つぎに問題となるのが、IIS 既定の「詳細」エラーページです。404 エラーであれば、ブラウザのタブには例えば次のようなタイトルが表示されます。
IIS 10.0 Detailed Error - 404.0 - Not Found
このタイトルを含むページは内部の検証には便利ですが、インターネット公開には向きません。本番環境では、少なくとも「ローカルのみ詳細」、できれば「カスタム エラーページ」で運用するのが基本です。
IIS マネージャーでエラーページのモードを変更する
- IIS マネージャーで対象サイトを選択します。
- 中央ペインから「エラーページ」を開きます。
- 右ペインの「機能の設定の編集…」をクリックします。
- 「このサイトのエラー応答」の選択肢から、用途に応じてモードを変更します。
| 利用シーン | おすすめ設定 | 説明 |
|---|---|---|
| 開発・検証環境(社内のみ) | ローカルのみ詳細 | サーバーローカルからのアクセスには詳細エラー、外部からは簡易エラーを返す |
| 本番環境(インターネット公開) | カスタム エラーページ | 常に独自のエラーページを返す。IIS のバージョン情報は一切出ない |
本番では、「カスタム エラーページ」+独自 404 ページを組み合わせるのがもっとも安心です。
web.config でカスタム404ページを設定する
404 用の HTML ファイル(例:/errors/404.html)を用意したら、web.config に次のような設定を追加します。
<configuration>
<system.webServer>
<httpErrors errorMode="Custom" existingResponse="Replace">
<remove statusCode="404" />
<error statusCode="404" path="/errors/404.html" responseMode="File" />
</httpErrors>
</system.webServer>
</configuration>
各属性の意味を簡単に整理しておきます。
| 属性 | 値 | 説明 |
|---|---|---|
errorMode | Custom | 常にカスタムエラーページを使用する |
existingResponse | Replace | アプリケーションが返したエラー応答を IIS 側の設定で置き換える |
statusCode | 404 | 404 Not Found に対して適用される設定行であることを示す |
path | /errors/404.html | 返すべきカスタム404ページのパス |
responseMode | File | 指定パスを物理ファイルとして返す(その他に ExecuteURL などがある) |
この設定を有効にすると、HTML の <title> も自作の 404 ページのタイトルになります。つまり、タブに「IIS 10.0 Detailed Error …」と表示されることがなくなるというわけです。
アプリ側の 404 と IIS 側の 404 の整理
ASP.NET MVC や WebForms などアプリケーション側で 404 を返す場合、IIS 側の httpErrors と衝突することがあります。よくあるパターンをまとめておきます。
| 状況 | アプリの動作 | IIS httpErrors の挙動 |
|---|---|---|
| ルーティングで 404 を返す | アプリ内で 404 を生成 | existingResponse="Replace" の場合は IIS の 404 ページに差し替え |
| 物理ファイルが存在しない | アプリまで届かない | IIS が直接 404 を返し、httpErrors が適用される |
アプリが 200 を返してしまう | アプリ主導 | IIS 側ではエラーとして扱われないため 404 ページが出ない |
「アプリの 404 ページをそのまま使いたい」のか、「IIS のカスタム404に寄せたい」のかを決めてから設計すると混乱しません。本記事では「セキュリティ優先で IIS 側のカスタム404を前面に出す」方針で説明しています。
追加で隠しておきたい HTTP ヘッダー
Server ヘッダーと同じく、アプリやフレームワークが自動で付けるヘッダーも、可能な範囲で削除しておくと安心です。代表的なものは次の通りです。
X-Powered-By(例:ASP.NET)X-AspNet-VersionX-AspNetMvc-Version
IIS 共通のヘッダー削除(X-Powered-By 等)
IIS 側で X-Powered-By を削除するには、web.config に以下のように記述します。
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
すでに <customHeaders> を利用している場合は、そこに <remove /> 行を追加してください。
ASP.NET(.NET Framework)のバージョンヘッダーを消す
ASP.NET (.NET Framework) のバージョンヘッダーを抑止するには、web.config の system.web セクションで次の設定を行います。
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false" />
</system.web>
</configuration>
これにより X-AspNet-Version が付与されなくなります。
ASP.NET MVC のレスポンスヘッダーを抑止する
ASP.NET MVC を利用している場合、X-AspNetMvc-Version ヘッダーも削除しておくとよいでしょう。もっとも簡単なのは Global.asax などアプリケーション開始時に次の 1 行を追加する方法です。
// Global.asax の Application_Start など
System.Web.Mvc.MvcHandler.DisableMvcResponseHeader = true;
これで MVC バージョンを示すヘッダーがレスポンスに含まれなくなります。
ASP.NET Core / Kestrel 併用時の注意点
最近は IIS の背後で Kestrel(ASP.NET Core)が動作している構成も増えています。この場合、IIS と Kestrel の両方が Server ヘッダーを扱うため、片方だけ対策すると「Server: Kestrel」が残ることがあります。
- IIS 側:
removeServerHeader="true"で IIS のServerを削除 - ASP.NET Core 側:Kestrel の
AddServerHeaderを無効化
たとえば ASP.NET Core の Program.cs やホスト構成で、Kestrel に対して次のような設定を行うことで、Kestrel が Server を付与しないようにできます(実際のコードは使っているテンプレートやバージョンに応じて調整してください)。
webBuilder.ConfigureKestrel(options =>
{
options.AddServerHeader = false;
});
実際の挙動は curl -I などで確認しながら、最終的なレスポンスに不要なバナーが残っていないかをチェックしましょう。
リバースプロキシ・ロードバランサ・CDN 側の設定も確認する
前述の通り、IIS の前段に別の製品を置いているケースでは、その製品独自の Server ヘッダーが付与されることがあります。
- 例:
Server: nginx - 例:
Server: Apache - 例:
ViaやX-Cacheなどプロキシ固有のヘッダー
これらをすべて消すかどうかは運用ポリシー次第ですが、「IIS のバージョンは出さない」「アプリケーションやミドルウェアのバージョン番号は出さない」といったルールを決めておき、その範囲でヘッダー削除を行うと良いでしょう。
設定変更後の動作確認方法
設定が終わったら、必ず「ヘッダー」と「画面表示」の両方を確認します。よく使う確認方法をまとめておきます。
ブラウザの開発者ツールで確認する
- Chrome / Edge などでサイトを開きます。
- F12 キーやメニューから開発者ツールを開きます。
- [Network](ネットワーク) タブを選択します。
- 存在しないパス(例:
/this-page-does-not-exist)にアクセスし、404 レスポンスをクリックします。 - Response Headers(レスポンスヘッダー)の一覧から、次を確認します。
Serverが存在しないことX-Powered-ByやX-AspNet-Version等が不要であれば削除されていること
あわせて「Headers」タブでは Status Code: 404 になっていることも確認しましょう。
curl でヘッダーのみを取得する
サーバー側からコマンドで確認する場合は、curl が便利です。
curl -I https://example.com/notfound
-I オプションは「ヘッダーだけ取得」の意味です。この出力の中に次のような行がないかチェックします。
Server: Microsoft-IIS/10.0X-Powered-By: ASP.NET- その他、消すことにしたヘッダー
PowerShell での確認例
Windows からであれば、PowerShell を使ってヘッダーだけ取得する方法もあります。
powershell -Command "Invoke-WebRequest -Uri 'https://example.com/notfound' -Method Head | Select-Object -ExpandProperty Headers"
これも結果としてヘッダー一覧が出力されるので、同様に不要なヘッダーが残っていないか確認します。
よくあるハマりポイントとチェックリスト
実際に設定してみると、次のような「想定外の挙動」に遭遇することがあります。対処のための視点を簡単にまとめておきます。
| 症状 | 考えられる原因 | 確認ポイント |
|---|---|---|
| あるサイトだけ Server ヘッダーが消えない | 上位の web.config や applicationHost.config の設定に上書きされている | 構成エディターで「継承」を確認、または設定ファイルの階層を見直す |
| 404 ではカスタムページが出るが、500 では詳細エラーが出る | 404 だけカスタム指定している / errorMode が環境ごとに違う | 500 系のエラー設定も必要かどうか検討し、httpErrors に追加する |
| アプリの 404 画面が表示されなくなった | existingResponse="Replace" によって IIS 側に置き換えられている | アプリ側の画面を優先したい場合は PassThrough を検討する |
| CDN 経由の時だけ別の Server ヘッダーが見える | CDN や LB がヘッダーを付与・変換している | CDN 管理画面や設定ファイルを確認し、必要に応じて書き換えルールを追加 |
運用上のベストプラクティス
一度設定して終わりにせず、運用として次のようなポイントを押さえておくと、後から楽になります。
- 構成のテンプレート化 新しいサイトを立ち上げるたびに毎回手作業で設定するのではなく、「ベースとなる
web.config」をテンプレートとして用意しておくと設定漏れを防げます。 - インフラ構成図にヘッダー削除ポイントを明記 どの層でどのヘッダーを削除しているかを図示しておくと、障害解析時にも役立ちます。
- 定期的な診断の実施 年に一度程度、全公開サイトに対して自動スキャン(
curlのスクリプトでも可)を流し、不要なサーバーバナーが復活していないかチェックします。 - 開発環境と本番環境で方針を分ける 開発環境では詳細エラーを有効にしておき、本番ではカスタムエラー+ヘッダー削除とするなど、環境ごとのルールを明文化しておきましょう。
まとめ:IIS 10 の 404 エラーでバージョンを隠すポイント
最後に、本記事で紹介したポイントを整理します。
removeServerHeader="true"を設定し、Serverヘッダーから IIS バージョンを除去する。- IIS の「詳細エラーページ」をインターネット側に返さない。 「ローカルのみ詳細」や「カスタム エラーページ」を利用する。
- カスタム 404 ページを用意し、
httpErrorsで 404 を自前のページに差し替える。 これでタイトルの「IIS 10.0 Detailed Error …」も消える。 X-Powered-ByやX-AspNet-Version等のフレームワーク由来ヘッダーも削除する。- リバースプロキシ / CDN / Kestrel など、前段・背後のコンポーネントが付けるヘッダーも含めて最終レスポンスを確認する。
- 変更後はブラウザの開発者ツールや
curl -Iで必ず検証する。
ここまでの設定を行えば、「誤った URL でアクセスしただけで IIS のバージョンやフレームワークの種類が丸見え」という状態はほぼ解消できます。セキュリティ対策としては地味な部分ですが、チェックリストに含まれることが多い項目でもあるので、この機会に一度見直してみてください。

コメント